Re: [PATCH] remoteproc: Fix spelling error in remoteproc.rst

[Mathieu Poirier]

Good morning,

This is a case of old english vs. new english.  Using "implementors" is still
correct.  Moreover, there are 33 instances of the word "implementor" in the
kernel tree.  Unless there is an effor to change all occurences I will not move
forward with this patch.

Thanks,
Mathieu

On Tue, Oct 08, 2024 at 01:15:57AM -0600, Everest K.C. wrote:
> Following spelling error reported by codespell
> was fixed:
>   implementors ==> implementers
> 
> Signed-off-by: Everest K.C. 
> ---
>  Documentation/staging/remoteproc.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/staging/remoteproc.rst 
> b/Documentation/staging/remoteproc.rst
> index 348ee7e508ac..5c226fa076d6 100644
> --- a/Documentation/staging/remoteproc.rst
> +++ b/Documentation/staging/remoteproc.rst
> @@ -104,7 +104,7 @@ Typical usage
>   rproc_shutdown(my_rproc);
>}
>  
> -API for implementors
> +API for implementers
>  
>  
>  ::
> -- 
> 2.43.0
> 

Re: [PATCH] doc: rmpsg: update with rpmsg_endpoint

[Mathieu Poirier]

On Sun, Dec 03, 2023 at 12:06:04PM -0800, Adrien Leravat wrote:
> It seems the documentation was not updated when `rpmsg_sendto`
> and related switched from `rpmsg_channel` to `rpmsg_endpoint`.
> This change updates the proper calls, text, and the sample.
> 
> Signed-off-by: Adrien Leravat 
> ---
>  Documentation/staging/rpmsg.rst | 50 ++---
>  1 file changed, 27 insertions(+), 23 deletions(-)
>

Thanks for the refactoring.  I have applied this patch.

Mathieu

> diff --git a/Documentation/staging/rpmsg.rst b/Documentation/staging/rpmsg.rst
> index 1ce353cb232a..dba3e5f65612 100644
> --- a/Documentation/staging/rpmsg.rst
> +++ b/Documentation/staging/rpmsg.rst
> @@ -68,13 +68,14 @@ User API
>  
>  ::
>  
> -  int rpmsg_send(struct rpmsg_channel *rpdev, void *data, int len);
> +  int rpmsg_send(struct rpmsg_endpoint *ept, void *data, int len);
>  
> -sends a message across to the remote processor on a given channel.
> -The caller should specify the channel, the data it wants to send,
> +sends a message across to the remote processor from the given endpoint.
> +The caller should specify the endpoint, the data it wants to send,
>  and its length (in bytes). The message will be sent on the specified
> -channel, i.e. its source and destination address fields will be
> -set to the channel's src and dst addresses.
> +endpoint's channel, i.e. its source and destination address fields will be
> +respectively set to the endpoint's src address and its parent channel
> +dst addresses.
>  
>  In case there are no TX buffers available, the function will block until
>  one becomes available (i.e. until the remote processor consumes
> @@ -87,17 +88,18 @@ Returns 0 on success and an appropriate error value on 
> failure.
>  
>  ::
>  
> -  int rpmsg_sendto(struct rpmsg_channel *rpdev, void *data, int len, u32 
> dst);
> +  int rpmsg_sendto(struct rpmsg_endpoint *ept, void *data, int len, u32 dst);
>  
> -sends a message across to the remote processor on a given channel,
> +sends a message across to the remote processor from a given endpoint,
>  to a destination address provided by the caller.
>  
> -The caller should specify the channel, the data it wants to send,
> +The caller should specify the endpoint, the data it wants to send,
>  its length (in bytes), and an explicit destination address.
>  
>  The message will then be sent to the remote processor to which the
> -channel belongs, using the channel's src address, and the user-provided
> -dst address (thus the channel's dst address will be ignored).
> +endpoints's channel belongs, using the endpoints's src address,
> +and the user-provided dst address (thus the channel's dst address
> +will be ignored).
>  
>  In case there are no TX buffers available, the function will block until
>  one becomes available (i.e. until the remote processor consumes
> @@ -110,18 +112,19 @@ Returns 0 on success and an appropriate error value on 
> failure.
>  
>  ::
>  
> -  int rpmsg_send_offchannel(struct rpmsg_channel *rpdev, u32 src, u32 dst,
> +  int rpmsg_send_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst,
>   void *data, int len);
>  
>  
>  sends a message across to the remote processor, using the src and dst
>  addresses provided by the user.
>  
> -The caller should specify the channel, the data it wants to send,
> +The caller should specify the endpoint, the data it wants to send,
>  its length (in bytes), and explicit source and destination addresses.
>  The message will then be sent to the remote processor to which the
> -channel belongs, but the channel's src and dst addresses will be
> -ignored (and the user-provided addresses will be used instead).
> +endpoint's channel belongs, but the endpoint's src and channel dst
> +addresses will be ignored (and the user-provided addresses will
> +be used instead).
>  
>  In case there are no TX buffers available, the function will block until
>  one becomes available (i.e. until the remote processor consumes
> @@ -134,13 +137,14 @@ Returns 0 on success and an appropriate error value on 
> failure.
>  
>  ::
>  
> -  int rpmsg_trysend(struct rpmsg_channel *rpdev, void *data, int len);
> +  int rpmsg_trysend(struct rpmsg_endpoint *ept, void *data, int len);
>  
> -sends a message across to the remote processor on a given channel.
> -The caller should specify the channel, the data it wants to send,
> +sends a message across to the remote processor from a given endpoint.
> +The caller should specify the endpoint, the data it wants to send,
>  and its length (in bytes). The message will be sent on the specified
> -channel, i.e. its source and destination address fields will be
> -set to the channel's src and dst addresses.
> +endpoint's channel, i.e. its source and destination address fields will be
> +respectively set to the endpoint's src address and its parent channel
> +dst addresses.
>  
>  In case there are no TX buffers available, the functio

Re: [REBASE PATCH v5 04/17] remoteproc: qcom: Remove minidump related data from qcom_common.c

[Mathieu Poirier]

On Fri, Oct 06, 2023 at 08:38:52PM +0530, Mukesh Ojha wrote:
> Hi Bjorn/Mathieu,
> 
> Patches from 2/17-4/17  is just a movement of functions to separate
> config/file.
> 
> Do you think, these can be picked independently from this series ?
> I can send them separately, if required.

Bjorn handles submissions for Qualcomm - I will defer to him.

> 
> @Bjorn: I have sent 13/17-15/17 separately [1] as it is needed
> by some folks and independent from this series.
> 
> [1]
> https://lore.kernel.org/all/1696440338-12561-1-git-send-email-quic_mo...@quicinc.com/
> 
> -Mukesh
> 
> On 9/11/2023 4:23 PM, Mukesh Ojha wrote:
> > As minidump specific data structure and functions move under
> > config QCOM_RPROC_MINIDUMP, so remove minidump specific data
> > from driver/remoteproc/qcom_common.c .
> > 
> > Signed-off-by: Mukesh Ojha 
> > ---
> >   drivers/remoteproc/qcom_common.c | 160 
> > ---
> >   1 file changed, 160 deletions(-)
> > 
> > diff --git a/drivers/remoteproc/qcom_common.c 
> > b/drivers/remoteproc/qcom_common.c
> > index 03e5f5d533eb..085fd73fa23a 100644
> > --- a/drivers/remoteproc/qcom_common.c
> > +++ b/drivers/remoteproc/qcom_common.c
> > @@ -17,7 +17,6 @@
> >   #include 
> >   #include 
> >   #include 
> > -#include 
> >   #include "remoteproc_internal.h"
> >   #include "qcom_common.h"
> > @@ -26,61 +25,6 @@
> >   #define to_smd_subdev(d) container_of(d, struct qcom_rproc_subdev, subdev)
> >   #define to_ssr_subdev(d) container_of(d, struct qcom_rproc_ssr, subdev)
> > -#define MAX_NUM_OF_SS   10
> > -#define MAX_REGION_NAME_LENGTH  16
> > -#define SBL_MINIDUMP_SMEM_ID   602
> > -#define MINIDUMP_REGION_VALID  ('V' << 24 | 'A' << 16 | 'L' << 
> > 8 | 'I' << 0)
> > -#define MINIDUMP_SS_ENCR_DONE  ('D' << 24 | 'O' << 16 | 'N' << 
> > 8 | 'E' << 0)
> > -#define MINIDUMP_SS_ENABLED('E' << 24 | 'N' << 16 | 'B' << 
> > 8 | 'L' << 0)
> > -
> > -/**
> > - * struct minidump_region - Minidump region
> > - * @name   : Name of the region to be dumped
> > - * @seq_num:   : Use to differentiate regions with same name.
> > - * @valid  : This entry to be dumped (if set to 1)
> > - * @address: Physical address of region to be dumped
> > - * @size   : Size of the region
> > - */
> > -struct minidump_region {
> > -   charname[MAX_REGION_NAME_LENGTH];
> > -   __le32  seq_num;
> > -   __le32  valid;
> > -   __le64  address;
> > -   __le64  size;
> > -};
> > -
> > -/**
> > - * struct minidump_subsystem - Subsystem's SMEM Table of content
> > - * @status : Subsystem toc init status
> > - * @enabled : if set to 1, this region would be copied during coredump
> > - * @encryption_status: Encryption status for this subsystem
> > - * @encryption_required : Decides to encrypt the subsystem regions or not
> > - * @region_count : Number of regions added in this subsystem toc
> > - * @regions_baseptr : regions base pointer of the subsystem
> > - */
> > -struct minidump_subsystem {
> > -   __le32  status;
> > -   __le32  enabled;
> > -   __le32  encryption_status;
> > -   __le32  encryption_required;
> > -   __le32  region_count;
> > -   __le64  regions_baseptr;
> > -};
> > -
> > -/**
> > - * struct minidump_global_toc - Global Table of Content
> > - * @status : Global Minidump init status
> > - * @md_revision : Minidump revision
> > - * @enabled : Minidump enable status
> > - * @subsystems : Array of subsystems toc
> > - */
> > -struct minidump_global_toc {
> > -   __le32  status;
> > -   __le32  md_revision;
> > -   __le32  enabled;
> > -   struct minidump_subsystem   subsystems[MAX_NUM_OF_SS];
> > -};
> > -
> >   struct qcom_ssr_subsystem {
> > const char *name;
> > struct srcu_notifier_head notifier_list;
> > @@ -90,110 +34,6 @@ struct qcom_ssr_subsystem {
> >   static LIST_HEAD(qcom_ssr_subsystem_list);
> >   static DEFINE_MUTEX(qcom_ssr_subsys_lock);
> > -static void qcom_minidump_cleanup(struct rproc *rproc)
> > -{
> > -   struct rproc_dump_segment *entry, *tmp;
> > -
> > -   list_for_each_entry_safe(entry, tmp, &rproc->dump_segments, node) {
> > -   list_del(&entry->node);
> > -   kfree(entry->priv);
> > -   kfree(entry);
> > -   }
> > -}
> > -
> > -static int qcom_add_minidump_segments(struct rproc *rproc, struct 
> > minidump_subsystem *subsystem,
> > -   void (*rproc_dumpfn_t)(struct rproc *rproc, struct 
> > rproc_dump_segment *segment,
> > -   void *dest, size_t offset, size_t size))
> > -{
> > -   struct minidump_region __iomem *ptr;
> > -   struct minidump_region region;
> > -   int seg_cnt, i;
> > -   dma_addr_t da;
> > -   size_t size;
> > -   char *name;
> > -
> > -   if (WARN_ON(!list_empty(&rproc->dump_segments))) {
> > -   dev_err(&rproc->dev, "dump segment list already populated\n");
> > -   return -EUCLEAN;
> 

Re: [PATCH v3 10/11] coresight: docs: Create common sub-directory for coresight trace.

[Mathieu Poirier]

On Fri, 18 Oct 2019 at 10:20, Mathieu Poirier
 wrote:
>
> On Tue, Oct 15, 2019 at 10:20:03PM +0100, Mike Leach wrote:
> > There are two files in the Documentation/trace directory relating to
> > coresight, with more to follow, so create a Documentation/trace/coresight
> > directory and move existing files there. Update MAINTAINERS to reference
> > this sub-directory rather than the individual files.
> >
> > Signed-off-by: Mike Leach 
> > ---
> >  Documentation/trace/{ => coresight}/coresight-cpu-debug.rst | 0
> >  Documentation/trace/{ => coresight}/coresight.rst   | 2 +-
> >  Documentation/trace/{ => coresight}/stm.rst | 0
> >  MAINTAINERS | 3 +--
> >  4 files changed, 2 insertions(+), 3 deletions(-)
> >  rename Documentation/trace/{ => coresight}/coresight-cpu-debug.rst (100%)
> >  rename Documentation/trace/{ => coresight}/coresight.rst (99%)
> >  rename Documentation/trace/{ => coresight}/stm.rst (100%)
> >
> > diff --git a/Documentation/trace/coresight-cpu-debug.rst 
> > b/Documentation/trace/coresight/coresight-cpu-debug.rst
> > similarity index 100%
> > rename from Documentation/trace/coresight-cpu-debug.rst
> > rename to Documentation/trace/coresight/coresight-cpu-debug.rst
> > diff --git a/Documentation/trace/coresight.rst 
> > b/Documentation/trace/coresight/coresight.rst
> > similarity index 99%
> > rename from Documentation/trace/coresight.rst
> > rename to Documentation/trace/coresight/coresight.rst
> > index 72f4b7ef1bad..835e8aa0bf8c 100644
> > --- a/Documentation/trace/coresight.rst
> > +++ b/Documentation/trace/coresight/coresight.rst
> > @@ -493,6 +493,6 @@ Details on how to use the generic STM API can be found 
> > here [#second]_.
> >
> >  .. [#first] Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
> >
> > -.. [#second] Documentation/trace/stm.rst
> > +.. [#second] Documentation/trace/coresight/stm.rst
> >
> >  .. [#third] https://github.com/Linaro/perf-opencsd
> > diff --git a/Documentation/trace/stm.rst 
> > b/Documentation/trace/coresight/stm.rst
> > similarity index 100%
> > rename from Documentation/trace/stm.rst
> > rename to Documentation/trace/coresight/stm.rst
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 296de2b51c83..f903160b507c 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -1608,8 +1608,7 @@ R:  Suzuki K Poulose 
> >  L:   linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
> >  S:   Maintained
> >  F:   drivers/hwtracing/coresight/*
> > -F:   Documentation/trace/coresight.rst
> > -F:   Documentation/trace/coresight-cpu-debug.rst
> > +F:   Documentation/trace/coresight/*
> >  F:   Documentation/devicetree/bindings/arm/coresight.txt
> >  F:   Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
> >  F:   Documentation/ABI/testing/sysfs-bus-coresight-devices-*
>
> Reviewed-by: Mathieu Poirier 

I'm taking that back - please remove mentions of coresight files in
Documentation/trace/index.rst.

Since you do have to respin, please split patch 09.  And now that I
have applied all the other patches, your next revision should be a
documentation set.

Thanks,
Mathieu
>
> > --
> > 2.17.1
> >

Re: [PATCH v3 11/11] coresight: etm4x: docs: Adds detailed document for programming etm4x.

[Mathieu Poirier]

nted 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.

This is quite usefull - thanks for putting it together:

Reviewed-by: Mathieu Poirier 

> -- 
> 2.17.1
> 

Re: [PATCH v3 10/11] coresight: docs: Create common sub-directory for coresight trace.

[Mathieu Poirier]

On Tue, Oct 15, 2019 at 10:20:03PM +0100, Mike Leach wrote:
> There are two files in the Documentation/trace directory relating to
> coresight, with more to follow, so create a Documentation/trace/coresight
> directory and move existing files there. Update MAINTAINERS to reference
> this sub-directory rather than the individual files.
> 
> Signed-off-by: Mike Leach 
> ---
>  Documentation/trace/{ => coresight}/coresight-cpu-debug.rst | 0
>  Documentation/trace/{ => coresight}/coresight.rst   | 2 +-
>  Documentation/trace/{ => coresight}/stm.rst | 0
>  MAINTAINERS | 3 +--
>  4 files changed, 2 insertions(+), 3 deletions(-)
>  rename Documentation/trace/{ => coresight}/coresight-cpu-debug.rst (100%)
>  rename Documentation/trace/{ => coresight}/coresight.rst (99%)
>  rename Documentation/trace/{ => coresight}/stm.rst (100%)
> 
> diff --git a/Documentation/trace/coresight-cpu-debug.rst 
> b/Documentation/trace/coresight/coresight-cpu-debug.rst
> similarity index 100%
> rename from Documentation/trace/coresight-cpu-debug.rst
> rename to Documentation/trace/coresight/coresight-cpu-debug.rst
> diff --git a/Documentation/trace/coresight.rst 
> b/Documentation/trace/coresight/coresight.rst
> similarity index 99%
> rename from Documentation/trace/coresight.rst
> rename to Documentation/trace/coresight/coresight.rst
> index 72f4b7ef1bad..835e8aa0bf8c 100644
> --- a/Documentation/trace/coresight.rst
> +++ b/Documentation/trace/coresight/coresight.rst
> @@ -493,6 +493,6 @@ Details on how to use the generic STM API can be found 
> here [#second]_.
>  
>  .. [#first] Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>  
> -.. [#second] Documentation/trace/stm.rst
> +.. [#second] Documentation/trace/coresight/stm.rst
>  
>  .. [#third] https://github.com/Linaro/perf-opencsd
> diff --git a/Documentation/trace/stm.rst 
> b/Documentation/trace/coresight/stm.rst
> similarity index 100%
> rename from Documentation/trace/stm.rst
> rename to Documentation/trace/coresight/stm.rst
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 296de2b51c83..f903160b507c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1608,8 +1608,7 @@ R:  Suzuki K Poulose 
>  L:   linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>  S:   Maintained
>  F:   drivers/hwtracing/coresight/*
> -F:   Documentation/trace/coresight.rst
> -F:   Documentation/trace/coresight-cpu-debug.rst
> +F:   Documentation/trace/coresight/*
>  F:   Documentation/devicetree/bindings/arm/coresight.txt
>  F:   Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
>  F:   Documentation/ABI/testing/sysfs-bus-coresight-devices-*

Reviewed-by: Mathieu Poirier 

> -- 
> 2.17.1
> 

Re: [PATCH v3 09/11] coresight: etm4x: docs: Update ABI doc for sysfs features added.

[Mathieu Poirier]

On Tue, Oct 15, 2019 at 10:20:02PM +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.

In most cases describing different actions in a changelog is a good indication
that more than one patch is needed.  This case is somewhat on the fence since
changes are trivial.  

Since Jonathan maintains the documentation subsystem the decision is left to
him.  Whether Jonathan wants the patch split or will simply take it as is:

Reviewed-by: Mathieu Poirier   

> 
> Signed-off-by: Mike Leach 
> ---
>  .../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/.etm/enable_source
> +What:/sys/bus/coresight/devices/etm/enable_source
>  Date:    April 2015
>  KernelVersion:  4.01
>  Contact:Mathieu Poirier 
> @@ -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/.etm/cpu
> +What:/sys/bus/coresight/devices/etm/cpu
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) The CPU this tracing entity is associated with.
>  
> -What:/sys/bus/coresight/devices/.etm/nr_pe_cmp
> +What:/sys/bus/coresight/devices/etm/nr_pe_cmp
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) Indicates the number of PE comparator inputs that are
>   available for tracing.
>  
> -What:/sys/bus/coresight/devices/.etm/nr_addr_cmp
> +What:        /sys/bus/coresight/devices/etm/nr_addr_cmp
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) Indicates the number of address comparator pairs that are
>   available for tracing.
>  
> -What:/sys/bus/coresight/devices/.etm/nr_cntr
> +What:/sys/bus/coresight/devices/etm/nr_cntr
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) Indicates the number of counters that are available for
>   tracing.
>  
> -What:/sys/bus/coresight/devices/.etm/nr_ext_inp
> +What:/sys/bus/coresight/devices/etm/nr_ext_inp
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) Indicates how many external inputs are implemented.
>  
> -What:        /sys/bus/coresight/devices/.etm/numcidc
> +What:/sys/bus/coresight/devices/etm/numcidc
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) Indicates the number of Context ID comparators that are
>   available for tracing.
>  
> -What:/sys/bus/coresight/devices/.etm/numvmidc
> +What:/sys/bus/coresight/devices/etm/numvmidc
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) Indicates the number of VMID comparators that are available
>       for tracing.
>  
> -What:/sys/bus/coresight/devices/.etm/nrseqstate
> +What:/sys/bus/coresight/devices/etm/nrseqstate
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) Indicates the number of sequencer states that are
>   implemented.
>  
> -What:/sys/bus/coresight/devices/.etm/nr_resource
> +What:/sys/bus/coresight/devices/etm/nr_resource
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) Indicates the number of resource selection pairs that are
>   available for tracing.
>  
> -What:/sys/bus/coresight/devices/.etm/nr_ss_cmp
> +What:/sys/bus/coresight/devices/etm/nr_ss_c

Re: [PATCH v3 08/11] coresight: etm4x: Add missing single-shot control API to sysfs

[Mathieu Poirier]

On Tue, Oct 15, 2019 at 10:20:01PM +0100, Mike Leach wrote:
> An API to control single-shot comparator operation was missing from sysfs.
> This adds the parameters to sysfs to allow programming of this feature.
> 
> Signed-off-by: Mike Leach 
> ---
>  .../coresight/coresight-etm4x-sysfs.c | 122 ++
>  drivers/hwtracing/coresight/coresight-etm4x.c |  26 +++-
>  drivers/hwtracing/coresight/coresight-etm4x.h |   2 +
>  3 files changed, 149 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c 
> b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index ca1a54411225..43b3f0976034 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -239,6 +239,7 @@ static ssize_t reset_store(struct device *dev,
>   for (i = 0; i < drvdata->nr_resource; i++)
>   config->res_ctrl[i] = 0x0;
>  
> + config->ss_idx = 0x0;
>   for (i = 0; i < drvdata->nr_ss_cmp; i++) {
>   config->ss_ctrl[i] = 0x0;
>   config->ss_pe_cmp[i] = 0x0;
> @@ -1717,6 +1718,123 @@ static ssize_t res_ctrl_store(struct device *dev,
>  }
>  static DEVICE_ATTR_RW(res_ctrl);
>  
> +static ssize_t sshot_idx_show(struct device *dev,
> +   struct device_attribute *attr, char *buf)
> +{
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + val = config->ss_idx;
> + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> +}
> +
> +static ssize_t sshot_idx_store(struct device *dev,
> +struct device_attribute *attr,
> +const char *buf, size_t size)
> +{
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + if (kstrtoul(buf, 16, &val))
> + return -EINVAL;
> + if (val >= drvdata->nr_ss_cmp)
> + return -EINVAL;
> +
> + spin_lock(&drvdata->spinlock);
> + config->ss_idx = val;
> + spin_unlock(&drvdata->spinlock);
> + return size;
> +}
> +static DEVICE_ATTR_RW(sshot_idx);
> +
> +static ssize_t sshot_ctrl_show(struct device *dev,
> +struct device_attribute *attr,
> +char *buf)
> +{
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + spin_lock(&drvdata->spinlock);
> + val = config->ss_ctrl[config->ss_idx];
> + spin_unlock(&drvdata->spinlock);
> + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> +}
> +
> +static ssize_t sshot_ctrl_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t size)
> +{
> + u8 idx;
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + if (kstrtoul(buf, 16, &val))
> + return -EINVAL;
> +
> + spin_lock(&drvdata->spinlock);
> + idx = config->ss_idx;
> + config->ss_ctrl[idx] = val & GENMASK(24, 0);
> + /* must clear bit 31 in related status register on programming */
> + config->ss_status[idx] &= ~BIT(31);
> + spin_unlock(&drvdata->spinlock);
> + return size;
> +}
> +static DEVICE_ATTR_RW(sshot_ctrl);
> +
> +static ssize_t sshot_status_show(struct device *dev,
> +  struct device_attribute *attr, char *buf)
> +{
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + spin_lock(&drvdata->spinlock);
> + val = config->ss_status[config->ss_idx];
> + spin_unlock(&drvdata->spinlock);
> + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> +}
> +static DEVICE_ATTR_RO(sshot_status);
> +
> +static ssize_t sshot_pe_ctrl_show(struct device *dev,
> +   struct device_attribute *attr,
> +   char *buf)
> +{
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + spin_lock(&drvdata->spinlock);
> + val = config->ss_pe_cmp[config->ss_idx];
> + spin_unlock(&drvdata->spinlock);
> + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> +}
> +
> +static ssize_t sshot_pe_ctrl_store(struct device *dev,
> +struct device_attribute *attr,
> +const char *buf, size_t size)
> +{
> + u8 idx;
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> +

Re: [PATCH v3 03/11] coresight: etm4x: Add missing API to set EL match on address filters

[Mathieu Poirier]

On Thu, 17 Oct 2019 at 12:00, Mathieu Poirier
 wrote:
>
> On Tue, Oct 15, 2019 at 10:19:56PM +0100, Mike Leach wrote:
> > TRCACATRn registers have match bits for secure and non-secure exception
> > levels which are not accessible by the sysfs API.
> > This adds a new sysfs parameter to enable this - addr_exlevel_s_ns.
> >
> > Reviewed-by: Suzuki K Poulose 
> > Signed-off-by: Mike Leach 
> > ---
> >  .../coresight/coresight-etm4x-sysfs.c | 42 +++
> >  1 file changed, 42 insertions(+)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c 
> > b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > index cc8156318018..45fa7743eea4 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > @@ -1233,6 +1233,47 @@ static ssize_t addr_context_store(struct device *dev,
> >  }
> >  static DEVICE_ATTR_RW(addr_context);
> >
> > +static ssize_t addr_exlevel_s_ns_show(struct device *dev,
> > +   struct device_attribute *attr,
> > +   char *buf)
> > +{
> > + u8 idx;
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + idx = config->addr_idx;
> > + val = BMVAL(config->addr_acc[idx], 14, 8);
> > + spin_unlock(&drvdata->spinlock);
> > + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > +}
> > +
> > +static ssize_t addr_exlevel_s_ns_store(struct device *dev,
> > +struct device_attribute *attr,
> > +const char *buf, size_t size)
> > +{
> > + u8 idx;
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + if (kstrtoul(buf, 0, &val))
> > + return -EINVAL;
> > +
> > + if (val & ~((GENMASK(14, 8) >> 8))
>
> This patch isn't compiling for me.  A parenthesis is missing to close the 
> if().

I will fix it because:

1) I've reviewed this patch several times already.
2) The solution is trivial.
3) I want to pickup patch 04/11 and there is a dependency with this one.

>
>
> > + return -EINVAL;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + idx = config->addr_idx;
> > + /* clear Exlevel_ns & Exlevel_s bits[14:12, 11:8], bit[15] is res0 */
> > + config->addr_acc[idx] &= ~(GENMASK(14, 8));
> > + config->addr_acc[idx] |= (val << 8);
> > + spin_unlock(&drvdata->spinlock);
> > + return size;
> > +}
> > +static DEVICE_ATTR_RW(addr_exlevel_s_ns);
> > +
> >  static ssize_t seq_idx_show(struct device *dev,
> >   struct device_attribute *attr,
> >   char *buf)
> > @@ -2038,6 +2079,7 @@ static struct attribute *coresight_etmv4_attrs[] = {
> >   &dev_attr_addr_stop.attr,
> >   &dev_attr_addr_ctxtype.attr,
> >   &dev_attr_addr_context.attr,
> > + &dev_attr_addr_exlevel_s_ns.attr,
> >   &dev_attr_seq_idx.attr,
> >   &dev_attr_seq_state.attr,
> >   &dev_attr_seq_event.attr,
> > --
> > 2.17.1
> >

Re: [PATCH v3 03/11] coresight: etm4x: Add missing API to set EL match on address filters

[Mathieu Poirier]

On Tue, Oct 15, 2019 at 10:19:56PM +0100, Mike Leach wrote:
> TRCACATRn registers have match bits for secure and non-secure exception
> levels which are not accessible by the sysfs API.
> This adds a new sysfs parameter to enable this - addr_exlevel_s_ns.
> 
> Reviewed-by: Suzuki K Poulose 
> Signed-off-by: Mike Leach 
> ---
>  .../coresight/coresight-etm4x-sysfs.c | 42 +++
>  1 file changed, 42 insertions(+)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c 
> b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index cc8156318018..45fa7743eea4 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -1233,6 +1233,47 @@ static ssize_t addr_context_store(struct device *dev,
>  }
>  static DEVICE_ATTR_RW(addr_context);
>  
> +static ssize_t addr_exlevel_s_ns_show(struct device *dev,
> +   struct device_attribute *attr,
> +   char *buf)
> +{
> + u8 idx;
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + spin_lock(&drvdata->spinlock);
> + idx = config->addr_idx;
> + val = BMVAL(config->addr_acc[idx], 14, 8);
> + spin_unlock(&drvdata->spinlock);
> + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> +}
> +
> +static ssize_t addr_exlevel_s_ns_store(struct device *dev,
> +struct device_attribute *attr,
> +const char *buf, size_t size)
> +{
> + u8 idx;
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + if (kstrtoul(buf, 0, &val))
> + return -EINVAL;
> +
> + if (val & ~((GENMASK(14, 8) >> 8))

This patch isn't compiling for me.  A parenthesis is missing to close the if().


> + return -EINVAL;
> +
> + spin_lock(&drvdata->spinlock);
> + idx = config->addr_idx;
> + /* clear Exlevel_ns & Exlevel_s bits[14:12, 11:8], bit[15] is res0 */
> + config->addr_acc[idx] &= ~(GENMASK(14, 8));
> + config->addr_acc[idx] |= (val << 8);
> + spin_unlock(&drvdata->spinlock);
> + return size;
> +}
> +static DEVICE_ATTR_RW(addr_exlevel_s_ns);
> +
>  static ssize_t seq_idx_show(struct device *dev,
>   struct device_attribute *attr,
>   char *buf)
> @@ -2038,6 +2079,7 @@ static struct attribute *coresight_etmv4_attrs[] = {
>   &dev_attr_addr_stop.attr,
>   &dev_attr_addr_ctxtype.attr,
>   &dev_attr_addr_context.attr,
> + &dev_attr_addr_exlevel_s_ns.attr,
>   &dev_attr_seq_idx.attr,
>   &dev_attr_seq_state.attr,
>   &dev_attr_seq_event.attr,
> -- 
> 2.17.1
> 

Re: [PATCH v3 02/11] coresight: etm4x: Fix input validation for sysfs.

[Mathieu Poirier]

On Tue, Oct 15, 2019 at 10:19:55PM +0100, Mike Leach wrote:
> A number of issues are fixed relating to sysfs input validation:-
> 
> 1) bb_ctrl_store() - incorrect compare of bit select field to absolute
> value. Reworked per ETMv4 specification.
> 2) seq_event_store() - incorrect mask value - register has two
> event values.
> 3) cyc_threshold_store() - must mask with max before checking min
> otherwise wrapped values can set illegal value below min.
> 4) res_ctrl_store() - update to mask off all res0 bits.
> 
> Reviewed-by: Leo Yan 
> Reviewed-by: Mathieu Poirier 
> Signed-off-by: Mike Leach 
> Fixes: a77de2637c9eb ("coresight: etm4x: moving sysFS entries to a dedicated 
> file")
> Cc: stable  # 4.9+
> ---
>  .../coresight/coresight-etm4x-sysfs.c | 21 ---
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c 
> b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index b6984be0c515..cc8156318018 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -652,10 +652,13 @@ static ssize_t cyc_threshold_store(struct device *dev,
>  
>   if (kstrtoul(buf, 16, &val))
>   return -EINVAL;
> +
> + /* mask off max threshold before checking min value */
> + val &= ETM_CYC_THRESHOLD_MASK;
>   if (val < drvdata->ccitmin)
>   return -EINVAL;
>  
> - config->ccctlr = val & ETM_CYC_THRESHOLD_MASK;
> + config->ccctlr = val;
>   return size;
>  }
>  static DEVICE_ATTR_RW(cyc_threshold);
> @@ -686,14 +689,16 @@ static ssize_t bb_ctrl_store(struct device *dev,
>   return -EINVAL;
>   if (!drvdata->nr_addr_cmp)
>   return -EINVAL;
> +
>   /*
> -  * Bit[7:0] selects which address range comparator is used for
> -  * branch broadcast control.
> +  * Bit[8] controls include(1) / exclude(0), bits[0-7] select
> +  * individual range comparators. If include then at least 1
> +  * range must be selected.
>*/
> - if (BMVAL(val, 0, 7) > drvdata->nr_addr_cmp)
> + if ((val & BIT(8)) && (BMVAL(val, 0, 7) == 0))
>   return -EINVAL;
>  
> - config->bb_ctrl = val;
> + config->bb_ctrl = val & GENMASK(8, 0);
>   return size;
>  }
>  static DEVICE_ATTR_RW(bb_ctrl);
> @@ -1324,8 +1329,8 @@ static ssize_t seq_event_store(struct device *dev,
>  
>   spin_lock(&drvdata->spinlock);
>   idx = config->seq_idx;
> - /* RST, bits[7:0] */
> - config->seq_ctrl[idx] = val & 0xFF;
> + /* Seq control has two masks B[15:8] F[7:0] */
> + config->seq_ctrl[idx] = val & 0x;
>   spin_unlock(&drvdata->spinlock);
>   return size;
>  }
> @@ -1580,7 +1585,7 @@ static ssize_t res_ctrl_store(struct device *dev,
>   if (idx % 2 != 0)
>   /* PAIRINV, bit[21] */
>   val &= ~BIT(21);
> - config->res_ctrl[idx] = val;
> + config->res_ctrl[idx] = val & GENMASK(21, 0);
>   spin_unlock(&drvdata->spinlock);
>   return size;

This one too, no need to send again.

>  }
> -- 
> 2.17.1
> 

Re: [PATCH v3 01/11] coresight: etm4x: Fixes for ETM v4.4 architecture updates.

[Mathieu Poirier]

Hi Mike,

On Tue, Oct 15, 2019 at 10:19:54PM +0100, Mike Leach wrote:
> ETMv4.4 adds in support for tracing secure EL2 (per arch 8.x updates).
> Patch accounts for this new capability.
> 
> Reviewed-by: Leo Yan 
> Signed-off-by: Mike Leach 
> ---
>  .../hwtracing/coresight/coresight-etm4x-sysfs.c   | 12 ++--
>  drivers/hwtracing/coresight/coresight-etm4x.c |  5 -
>  drivers/hwtracing/coresight/coresight-etm4x.h | 15 +++
>  3 files changed, 21 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c 
> b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index 219c10eb752c..b6984be0c515 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -738,7 +738,7 @@ static ssize_t s_exlevel_vinst_show(struct device *dev,
>   struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
>   struct etmv4_config *config = &drvdata->config;
>  
> - val = BMVAL(config->vinst_ctrl, 16, 19);
> + val = (config->vinst_ctrl & ETM_EXLEVEL_S_VICTLR_MASK) >> 16;
>   return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>  }
>  
> @@ -754,8 +754,8 @@ static ssize_t s_exlevel_vinst_store(struct device *dev,
>   return -EINVAL;
>  
>   spin_lock(&drvdata->spinlock);
> - /* clear all EXLEVEL_S bits (bit[18] is never implemented) */
> - config->vinst_ctrl &= ~(BIT(16) | BIT(17) | BIT(19));
> + /* clear all EXLEVEL_S bits  */
> + config->vinst_ctrl &= ~(ETM_EXLEVEL_S_VICTLR_MASK);
>   /* enable instruction tracing for corresponding exception level */
>   val &= drvdata->s_ex_level;
>   config->vinst_ctrl |= (val << 16);
> @@ -773,7 +773,7 @@ static ssize_t ns_exlevel_vinst_show(struct device *dev,
>   struct etmv4_config *config = &drvdata->config;
>  
>   /* EXLEVEL_NS, bits[23:20] */
> - val = BMVAL(config->vinst_ctrl, 20, 23);
> + val = (config->vinst_ctrl & ETM_EXLEVEL_NS_VICTLR_MASK) >> 20;
>   return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>  }
>  
> @@ -789,8 +789,8 @@ static ssize_t ns_exlevel_vinst_store(struct device *dev,
>   return -EINVAL;
>  
>   spin_lock(&drvdata->spinlock);
> - /* clear EXLEVEL_NS bits (bit[23] is never implemented */
> - config->vinst_ctrl &= ~(BIT(20) | BIT(21) | BIT(22));
> + /* clear EXLEVEL_NS bits  */
> + config->vinst_ctrl &= ~(ETM_EXLEVEL_NS_VICTLR_MASK);
>   /* enable instruction tracing for corresponding exception level */
>   val &= drvdata->ns_ex_level;
>   config->vinst_ctrl |= (val << 20);
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c 
> b/drivers/hwtracing/coresight/coresight-etm4x.c
> index 8f98701cadc5..efe120925f9d 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> @@ -648,6 +648,7 @@ static void etm4_init_arch_data(void *info)
>* TRCARCHMAJ, bits[11:8] architecture major versin number
>*/
>   drvdata->arch = BMVAL(etmidr1, 4, 11);
> + drvdata->config.arch = drvdata->arch;
>  
>   /* maximum size of resources */
>   etmidr2 = readl_relaxed(drvdata->base + TRCIDR2);
> @@ -799,6 +800,7 @@ static u64 etm4_get_ns_access_type(struct etmv4_config 
> *config)
>  static u64 etm4_get_access_type(struct etmv4_config *config)
>  {
>   u64 access_type = etm4_get_ns_access_type(config);
> + u64 s_hyp = (config->arch & 0x0f) >= 0x4 ? ETM_EXLEVEL_S_HYP : 0;
>  
>   /*
>* EXLEVEL_S, bits[11:8], don't trace anything happening
> @@ -806,7 +808,8 @@ static u64 etm4_get_access_type(struct etmv4_config 
> *config)
>*/
>   access_type |= (ETM_EXLEVEL_S_APP   |
>   ETM_EXLEVEL_S_OS|
> - ETM_EXLEVEL_S_HYP);
> + s_hyp   |
> + ETM_EXLEVEL_S_MON);
>  
>   return access_type;
>  }
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h 
> b/drivers/hwtracing/coresight/coresight-etm4x.h
> index 546d790cb01b..b873df38e7d8 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.h
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.h
> @@ -181,17 +181,22 @@
>  /* PowerDown Control Register bits */
>  #define TRCPDCR_PU   BIT(3)
>  
> -/* secure state access levels */
> +/* secure state access levels - TRCACATRn */
>  #define ETM_EXLEVEL_S_APPBIT(8)
>  #define ETM_EXLEVEL_S_OS BIT(9)
> -#define ETM_EXLEVEL_S_NA BIT(10)
> -#define ETM_EXLEVEL_S_HYPBIT(11)
> -/* non-secure state access levels */
> +#define ETM_EXLEVEL_S_HYPBIT(10)
> +#define ETM_EXLEVEL_S_MONBIT(11)
> +/* non-secure state access levels - TRCACATRn */
>  #define ETM_EXLEVEL_NS_APP   BIT(12)
>  #define ETM_EXLEVEL_NS_OSBIT(13)
>  #define ETM_EXLEVEL_NS_HYP   BIT(14)
>  #define ETM_EXLEVEL_NS_NA  

Re: [PATCH v2 09/11] coresight: etm4x: docs: Update ABI doc for sysfs features added.

[Mathieu Poirier]

On Wed, 4 Sep 2019 at 10:17, Greg KH  wrote:
>
> On Wed, Sep 04, 2019 at 10:05:51AM -0600, Mathieu Poirier wrote:
> > On Tue, 3 Sep 2019 at 23:48, Greg KH  wrote:
> > >
> > > On Tue, Sep 03, 2019 at 04:51:40PM -0600, Mathieu Poirier wrote:
> > > > On Tue, 3 Sep 2019 at 13:59, Greg KH  wrote:
> > > > >
> > > > > 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 
> > > > > > ---
> > > > > >  .../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/.etm/enable_source
> > > > > > +What:
> > > > > > /sys/bus/coresight/devices/etm/enable_source
> > > > >
> > > > > You are renaming sysfs directories that have been around since:
> > > > >
> > > > > >  Date:April 2015
> > > > >
> > > > > ???
> > > > >
> > > > > Really?
> > > > >
> > > > > That's brave.
> > > >
> > > >
> > > > When I worked on the coresight sysfs ABI a while back I specifically
> > > > added it at the "testing" level as I was well aware that things could
> > > > change in the future.  According to the guidelines in the
> > > > documentation userspace can rely on it which was accurate since the
> > > > interface didn't change for 4 years.  But the guidelines also mention
> > > > that changes can occur before the interfaces are move to stables, and
> > > > that programs are encouraged to manifest their interest by adding
> > > > their name to the "users" field.
> > > >
> > > > The interface was changed in 5.2 to support coresight from ACPI and
> > > > make things easier to understand for users.  It is a lot more
> > > > intuitive to associate an ETM tracer with the CPU it belongs to by
> > > > referring to the CPU number than the memory mapped address.  Given the
> > > > "testing" status of the interface and the absence of registered users
> > > > I decided to move forward with the change.  If "testing" is too strict
> > > > for that I suggest to add an "experimental" category where it would be
> > > > more acceptable to change things as subsystems mature.
> > >
> > > "testing" is not really "testing" if you have userspace tools/programs
> > > assuming the location and contents of specific files in sysfs.
> > >
> > > You can change things in sysfs by creating new files, but to do
> > > wholesale renaming like you did here can be very dangerous as you might
> > > be breaking things.
> >
> > Yes, something I have definitely considered.
> >
> > > Usually new files are created, not existing ones
> > > moved.
> >
> > In this case it would have meant a new symbolic link for every
> > coresight device, so twice a many entries under
> > $(SYS)/bus/coresight/device/.  That would have been a lot of clutter
> > and an increasing source of problems as the number of CPU and sinks
> > increases.  To me, and given the permissive definition of "testing"
> > found in the documentation, a clean break was a better option.
>
> Well, "testing" doesn't really matter in the end, if a tool/user relies
> on it, we have to keep it working properly.
>
> > > What tools use these today?  What is going to break?
> >
> > Other than local shell scripts I am not aware of any tools using these
> > today.  I am certainly open to discuss a better alternative but right
> > now, I just don't see one.
>
> Be aware that you might have to change this back if there is any
> objections.
>

We have an agreement.

Regards,
Mathieu

Re: [PATCH v2 11/11] coresight: etm4x: docs: Adds detailed document for programming etm4x.

[Mathieu Poirier]

On Tue, 3 Sep 2019 at 16:47, Mike Leach  wrote:
>
> Hi Mathieu,
>
> On Tue, 3 Sep 2019 at 20:38, Mathieu Poirier  
> wrote:
> >
> > 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 
> > > ---
> > >  .../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 ..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
> > > +
> > > +
> > > +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
> >
>
> Problem is I am not seeing any difference between what you say I am
> writing and what you prefer. When i looked at the file in my text
> editor the fields where aligned - I would not have submitted it
> otherwise.

Indeed - I suspected that much.

> I am happy to revisit it but we need a way of seeing a common view.

Agreed

>
>
> > I'm also not sure about the prompt, i.e "$>".  I suspect it should be "$" 
> > and
> > an additional ">" got inserted.
>
> prompt came from examples lifted from a DB410 session. Don't really
> have any strong preference for what represents a prompt in the docs,
> so happy to change it to anything appropriate.

Ok, I wasn't sure if this was really the prompt you were getting of corruption.

>
> Regards
>
> Mike
>
> >
> > 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
> >
&

Re: [PATCH v2 09/11] coresight: etm4x: docs: Update ABI doc for sysfs features added.

[Mathieu Poirier]

On Tue, 3 Sep 2019 at 23:48, Greg KH  wrote:
>
> On Tue, Sep 03, 2019 at 04:51:40PM -0600, Mathieu Poirier wrote:
> > On Tue, 3 Sep 2019 at 13:59, Greg KH  wrote:
> > >
> > > 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 
> > > > ---
> > > >  .../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/.etm/enable_source
> > > > +What:/sys/bus/coresight/devices/etm/enable_source
> > >
> > > You are renaming sysfs directories that have been around since:
> > >
> > > >  Date:April 2015
> > >
> > > ???
> > >
> > > Really?
> > >
> > > That's brave.
> >
> >
> > When I worked on the coresight sysfs ABI a while back I specifically
> > added it at the "testing" level as I was well aware that things could
> > change in the future.  According to the guidelines in the
> > documentation userspace can rely on it which was accurate since the
> > interface didn't change for 4 years.  But the guidelines also mention
> > that changes can occur before the interfaces are move to stables, and
> > that programs are encouraged to manifest their interest by adding
> > their name to the "users" field.
> >
> > The interface was changed in 5.2 to support coresight from ACPI and
> > make things easier to understand for users.  It is a lot more
> > intuitive to associate an ETM tracer with the CPU it belongs to by
> > referring to the CPU number than the memory mapped address.  Given the
> > "testing" status of the interface and the absence of registered users
> > I decided to move forward with the change.  If "testing" is too strict
> > for that I suggest to add an "experimental" category where it would be
> > more acceptable to change things as subsystems mature.
>
> "testing" is not really "testing" if you have userspace tools/programs
> assuming the location and contents of specific files in sysfs.
>
> You can change things in sysfs by creating new files, but to do
> wholesale renaming like you did here can be very dangerous as you might
> be breaking things.

Yes, something I have definitely considered.

> Usually new files are created, not existing ones
> moved.

In this case it would have meant a new symbolic link for every
coresight device, so twice a many entries under
$(SYS)/bus/coresight/device/.  That would have been a lot of clutter
and an increasing source of problems as the number of CPU and sinks
increases.  To me, and given the permissive definition of "testing"
found in the documentation, a clean break was a better option.

>
> What tools use these today?  What is going to break?

Other than local shell scripts I am not aware of any tools using these
today.  I am certainly open to discuss a better alternative but right
now, I just don't see one.

>
> thanks,
> greg k-h

Re: [PATCH v2 09/11] coresight: etm4x: docs: Update ABI doc for sysfs features added.

[Mathieu Poirier]

On Tue, 3 Sep 2019 at 13:59, Greg KH  wrote:
>
> 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 
> > ---
> >  .../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/.etm/enable_source
> > +What:/sys/bus/coresight/devices/etm/enable_source
>
> You are renaming sysfs directories that have been around since:
>
> >  Date:April 2015
>
> ???
>
> Really?
>
> That's brave.


When I worked on the coresight sysfs ABI a while back I specifically
added it at the "testing" level as I was well aware that things could
change in the future.  According to the guidelines in the
documentation userspace can rely on it which was accurate since the
interface didn't change for 4 years.  But the guidelines also mention
that changes can occur before the interfaces are move to stables, and
that programs are encouraged to manifest their interest by adding
their name to the "users" field.

The interface was changed in 5.2 to support coresight from ACPI and
make things easier to understand for users.  It is a lot more
intuitive to associate an ETM tracer with the CPU it belongs to by
referring to the CPU number than the memory mapped address.  Given the
"testing" status of the interface and the absence of registered users
I decided to move forward with the change.  If "testing" is too strict
for that I suggest to add an "experimental" category where it would be
more acceptable to change things as subsystems mature.

Thanks,
Mathieu

>
>
> What tool did you just break?
>
> greg k-h

Re: [PATCH v2 09/11] coresight: etm4x: docs: Update ABI doc for sysfs features added.

[Mathieu Poirier]

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 
> ---
>  .../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/.etm/enable_source
> +What:/sys/bus/coresight/devices/etm/enable_source
>  Date:    April 2015
>  KernelVersion:  4.01
>  Contact:Mathieu Poirier 
> @@ -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/.etm/cpu
> +What:/sys/bus/coresight/devices/etm/cpu
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) The CPU this tracing entity is associated with.
>  
> -What:/sys/bus/coresight/devices/.etm/nr_pe_cmp
> +What:/sys/bus/coresight/devices/etm/nr_pe_cmp
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) Indicates the number of PE comparator inputs that are
>   available for tracing.
>  
> -What:/sys/bus/coresight/devices/.etm/nr_addr_cmp
> +What:        /sys/bus/coresight/devices/etm/nr_addr_cmp
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) Indicates the number of address comparator pairs that are
>   available for tracing.
>  
> -What:/sys/bus/coresight/devices/.etm/nr_cntr
> +What:/sys/bus/coresight/devices/etm/nr_cntr
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) Indicates the number of counters that are available for
>   tracing.
>  
> -What:/sys/bus/coresight/devices/.etm/nr_ext_inp
> +What:/sys/bus/coresight/devices/etm/nr_ext_inp
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) Indicates how many external inputs are implemented.
>  
> -What:        /sys/bus/coresight/devices/.etm/numcidc
> +What:/sys/bus/coresight/devices/etm/numcidc
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) Indicates the number of Context ID comparators that are
>   available for tracing.
>  
> -What:/sys/bus/coresight/devices/.etm/numvmidc
> +What:/sys/bus/coresight/devices/etm/numvmidc
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) Indicates the number of VMID comparators that are available
>       for tracing.
>  
> -What:/sys/bus/coresight/devices/.etm/nrseqstate
> +What:/sys/bus/coresight/devices/etm/nrseqstate
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) Indicates the number of sequencer states that are
>   implemented.
>  
> -What:/sys/bus/coresight/devices/.etm/nr_resource
> +What:/sys/bus/coresight/devices/etm/nr_resource
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) Indicates the number of resource selection pairs that are
>   available for tracing.
>  
> -What:/sys/bus/coresight/devices/.etm/nr_ss_cmp
> +What:/sys/bus/coresight/devices/etm/nr_ss_cmp
>  Date:April 2015
>  KernelVersion:   4.01
>  Contact: Mathieu Poirier 
>  Description: (R) Indicates the number of single-shot comparator controls that
>   are available for tracing.
>  
> -What:/sys/bus/coresight/devices/.etm/reset
> +What:/sys/bus/coresigh

Re: [PATCH v2 11/11] coresight: etm4x: docs: Adds detailed document for programming etm4x.

[Mathieu Poirier]

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 
> ---
>  .../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 ..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
> +
> +
> +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 0x 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
> + gener

Re: [Patch V4] Documentation: coresight: covert txt to rst

[Mathieu Poirier]

On Wed, 10 Jul 2019 at 09:01, Phong Tran  wrote:
>
> as doc-guide of kernel documentation, use Sphinx tool to
> generate the html/pdf... files.
>
> This changes the plan text txt to rst format.
>

I agree with Mauro - although the changelong has already been improved
it is still below the minimum requirements.

> Signed-off-by: Phong Tran 

As for the content of the patch:

Acked-by: Mathieu Poirier 


> ---
> ChangeLog:
> V2: review points from Mathieu, Jonathan
>   * Add coresight-cpu-debug
>   * Update MAINTAINERS file
>   * Avoid use markup as much as posible
> V3: review points from Mauro
>   * add the colon author, date
>   * change to use  in the struct
>   * add line for the acronyms
> V4:
>   * Rebase on linux-next tree
> ---
>  ...sight-cpu-debug.txt => coresight-cpu-debug.rst} |  67 ++--
>  .../trace/{coresight.txt => coresight.rst} | 372 
> +++--
>  Documentation/trace/index.rst  |   2 +
>  MAINTAINERS|   4 +-
>  4 files changed, 234 insertions(+), 211 deletions(-)
>  rename Documentation/trace/{coresight-cpu-debug.txt => 
> coresight-cpu-debug.rst} (84%)
>  rename Documentation/trace/{coresight.txt => coresight.rst} (56%)
>
> diff --git a/Documentation/trace/coresight-cpu-debug.txt 
> b/Documentation/trace/coresight-cpu-debug.rst
> similarity index 84%
> rename from Documentation/trace/coresight-cpu-debug.txt
> rename to Documentation/trace/coresight-cpu-debug.rst
> index 1a660a39e3c0..993dd294b81b 100644
> --- a/Documentation/trace/coresight-cpu-debug.txt
> +++ b/Documentation/trace/coresight-cpu-debug.rst
> @@ -1,8 +1,9 @@
> -   Coresight CPU Debug Module
> -   ==
> +==
> +Coresight CPU Debug Module
> +==
>
> -   Author:   Leo Yan 
> -   Date: April 5th, 2017
> +   :Author:   Leo Yan 
> +   :Date: April 5th, 2017
>
>  Introduction
>  
> @@ -69,6 +70,7 @@ Before accessing debug registers, we should ensure the 
> clock and power domain
>  have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
>  Debug registers', the debug registers are spread into two domains: the debug
>  domain and the CPU domain.
> +::
>
>  +---+
>  |   |
> @@ -125,18 +127,21 @@ If you want to enable debugging functionality at boot 
> time, you can add
>  "coresight_cpu_debug.enable=1" to the kernel command line parameter.
>
>  The driver also can work as module, so can enable the debugging when insmod
> -module:
> -# insmod coresight_cpu_debug.ko debug=1
> +module::
> +
> +  # insmod coresight_cpu_debug.ko debug=1
>
>  When boot time or insmod module you have not enabled the debugging, the 
> driver
>  uses the debugfs file system to provide a knob to dynamically enable or 
> disable
>  debugging:
>
> -To enable it, write a '1' into /sys/kernel/debug/coresight_cpu_debug/enable:
> -# echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable
> +To enable it, write a '1' into /sys/kernel/debug/coresight_cpu_debug/enable::
> +
> +  # echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable
> +
> +To disable it, write a '0' into 
> /sys/kernel/debug/coresight_cpu_debug/enable::
>
> -To disable it, write a '0' into /sys/kernel/debug/coresight_cpu_debug/enable:
> -# echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable
> +  # echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable
>
>  As explained in chapter "Clock and power domain", if you are working on one
>  platform which has idle states to power off debug logic and the power
> @@ -154,34 +159,34 @@ subsystem, more specifically by using the 
> "/dev/cpu_dma_latency"
>  interface (see Documentation/power/pm_qos_interface.rst for more
>  details).  As specified in the PM QoS documentation the requested
>  parameter will stay in effect until the file descriptor is released.
> -For example:
> +For example::
>
> -# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
> -...
> -Do some work...
> -...
> -# exec 3<>-
> +  # exec 3<> /dev/cpu_dma_latency; echo 0 >&3
> +  ...
> +  Do some work...
> +  ...
> +  # exec 3<>-
>
>  The same can also be done from an application program.
>
>  Disable specific CPU's specific idle state from cpuidle sysfs (see
> -Documentation/admin-guide/pm/cpuidle.rst):
> -# echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
> +Documentation/admin-guide/pm

Re: [PATCH] Documentation: coresight: covert txt to rst

[Mathieu Poirier]

Hi Tran,

Thank you for doing this - it adds much needed consistency to this
file.  A few of comments below

On Fri, 5 Jul 2019 at 14:45, Phong Tran  wrote:
>
> change the format file and adpate the text style

This changtelog is a little short and mentions what you are doing
rather than why.

>
> Signed-off-by: Phong Tran 
> ---
>  .../trace/{coresight.txt => coresight.rst} | 296 
> -
>  Documentation/trace/index.rst  |   1 +
>  2 files changed, 167 insertions(+), 130 deletions(-)
>  rename Documentation/trace/{coresight.txt => coresight.rst} (59%)

File "coresight.txt" is referenced in the MAINTAINERS file and should
probably be changed there as well.

Did you look at coresight-cpu-debug.txt?  In my opinion both files
should be changed in the same patchset.

Thanks,
Mathieu

>
> diff --git a/Documentation/trace/coresight.txt 
> b/Documentation/trace/coresight.rst
> similarity index 59%
> rename from Documentation/trace/coresight.txt
> rename to Documentation/trace/coresight.rst
> index efbc832146e7..bea24e70cfba 100644
> --- a/Documentation/trace/coresight.txt
> +++ b/Documentation/trace/coresight.rst
> @@ -1,5 +1,6 @@
> -   Coresight - HW Assisted Tracing on ARM
> -   ==
> +==
> +Coresight - HW Assisted Tracing on ARM
> +==
>
> Author:   Mathieu Poirier 
> Date: September 11th, 2014
> @@ -26,7 +27,7 @@ implementation, either storing the compressed stream in a 
> memory buffer or
>  creating an interface to the outside world where data can be transferred to a
>  host without fear of filling up the onboard coresight memory buffer.
>
> -At typical coresight system would look like this:
> +At typical coresight system would look like this::
>
>*
>    AMBA AXI  ===||
> @@ -95,6 +96,7 @@ Acronyms and Classification
>
>  Acronyms:
>
> + =
>  PTM: Program Trace Macrocell
>  ETM: Embedded Trace Macrocell
>  STM: System trace Macrocell
> @@ -104,6 +106,7 @@ TPIU:Trace Port Interface Unit
>  TMC-ETR: Trace Memory Controller, configured as Embedded Trace Router
>  TMC-ETF: Trace Memory Controller, configured as Embedded Trace FIFO
>  CTI: Cross Trigger Interface
> + =
>
>  Classification:
>
> @@ -118,7 +121,7 @@ Misc:
>
>
>  Device Tree Bindings
> ---
> +
>
>  See Documentation/devicetree/bindings/arm/coresight.txt for details.
>
> @@ -133,57 +136,63 @@ The coresight framework provides a central point to 
> represent, configure and
>  manage coresight devices on a platform.  Any coresight compliant device can
>  register with the framework for as long as they use the right APIs:
>
> -struct coresight_device *coresight_register(struct coresight_desc *desc);
> -void coresight_unregister(struct coresight_device *csdev);
> +.. c:function:: struct coresight_device *coresight_register(struct 
> coresight_desc *desc);
> +.. c:function:: void coresight_unregister(struct coresight_device *csdev);
>
> -The registering function is taking a "struct coresight_device *csdev" and
> +The registering function is taking a :code:`struct coresight_device *csdev` 
> and
>  register the device with the core framework.  The unregister function takes
> -a reference to a "struct coresight_device", obtained at registration time.
> +a reference to a :code:`struct coresight_device`, obtained at registration 
> time.
>
>  If everything goes well during the registration process the new devices will
>  show up under /sys/bus/coresight/devices, as showns here for a TC2 platform:
>
> -root:~# ls /sys/bus/coresight/devices/
> -replicator  2003.tpiu2201c000.ptm  2203c000.etm  2203e000.etm
> -2001.etb 2004.funnel  2201d000.ptm  2203d000.etm
> -root:~#
> +.. code:: console
>
> -The functions take a "struct coresight_device", which looks like this:
> +root:~# ls /sys/bus/coresight/devices/
> +replicator  2003.tpiu2201c000.ptm  2203c000.etm  2203e000.etm
> +2001.etb 2004.funnel  2201d000.ptm  2203d000.etm
> +root:~#
>
> -struct coresight_desc {
> -enum coresight_dev_type type;
> -struct coresight_dev_subtype subtype;
> -const struct coresight_ops *ops;
> -struct coresight_platform_data *pdata;
> -   

Re: [PATCH v3] coresight: documentation: update sysfs section

[Mathieu Poirier]

On 14 May 2018 at 13:18, Kim Phillips  wrote:
> - Align and show updated ls devices output from the TC2, based on
>   current driver
>
> - Provide an example from an ETMv4 based system (Juno)
>
> - Reflect changes to the way the RAM write pointer is accessed since
>   it got changed in commit 7d83d17795ef ("coresight: tmc: adding sysFS
>   management entries").
>
> Cc: Mathieu Poirier 
> Cc: Randy Dunlap 
> Cc: Jonathan Corbet 
> Signed-off-by: Kim Phillips 

I'm good with this version - Jonathan, should I take this through my
tree of you'll take care of it?

In case of the former:
Acked-by: Mathieu Poirier 

> ---
> v3: address Randy Dunlap's showns->shown,  corrected - and + line merging
> v2: address Mathieu's comment about clarifying the sinks on the Juno
> vs. TC2 platforms.
>
>  Documentation/trace/coresight.txt | 43 +++
>  1 file changed, 26 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/trace/coresight.txt 
> b/Documentation/trace/coresight.txt
> index 6f0120c3a4f1..15d2a0f1e1b8 100644
> --- a/Documentation/trace/coresight.txt
> +++ b/Documentation/trace/coresight.txt
> @@ -141,13 +141,25 @@ register the device with the core framework.  The 
> unregister function takes
>  a reference to a "struct coresight_device", obtained at registration time.
>
>  If everything goes well during the registration process the new devices will
> -show up under /sys/bus/coresight/devices, as showns here for a TC2 platform:
> +show up under /sys/bus/coresight/devices, as shown here for a TC2 platform:
>
>  root:~# ls /sys/bus/coresight/devices/
> -replicator  2003.tpiu2201c000.ptm  2203c000.etm  2203e000.etm
> -2001.etb 2004.funnel  2201d000.ptm  2203d000.etm
> +2001.etb   2004.funnel 2201d000.ptm  2203d000.etm  replicator
> +2003.tpiu  2201c000.ptm2203c000.etm  2203e000.etm
>  root:~#
>
> +and here for a Juno platform:
> +
> +root@juno:~# ls /sys/bus/coresight/devices/
> +2001.etf2012.replicator  2204.etm 230c.funnel
> +2003.tpiu   2013.funnel  220c.funnel  2314.etm
> +2004.funnel  2014.etf2214.etm 2324.etm
> +2007.etr2015.funnel  2304.etm 2334.etm
> +root@juno:~#
> +
> +Note that on Juno users can select the ETF, ETR and TPIU as a sink target 
> while
> +on TC2, the ETB and TPIU can be selected.
> +
>  The functions take a "struct coresight_device", which looks like this:
>
>  struct coresight_desc {
> @@ -193,16 +205,16 @@ the information carried in "THIS_MODULE".
>  How to use the tracer modules
>  -
>
> -Before trace collection can start, a coresight sink needs to be identify.
> +Before trace collection can start, a coresight sink needs to be identified.
>  There is no limit on the amount of sinks (nor sources) that can be enabled at
>  any given moment.  As a generic operation, all device pertaining to the sink
>  class will have an "active" entry in sysfs:
>
>  root:/sys/bus/coresight/devices# ls
> -replicator  2003.tpiu2201c000.ptm  2203c000.etm  2203e000.etm
> -2001.etb 2004.funnel  2201d000.ptm  2203d000.etm
> +2001.etb   2004.funnel 2201d000.ptm  2203d000.etm  replicator
> +2003.tpiu  2201c000.ptm2203c000.etm  2203e000.etm
>  root:/sys/bus/coresight/devices# ls 2001.etb
> -enable_sink  status  trigger_cntr
> +enable_sink  mgmt  power  subsystem  trigger_cntr  uevent
>  root:/sys/bus/coresight/devices# echo 1 > 2001.etb/enable_sink
>  root:/sys/bus/coresight/devices# cat 2001.etb/enable_sink
>  1
> @@ -216,16 +228,13 @@ trigger a trace capture:
>  root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
>  root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
>  1
> -root:/sys/bus/coresight/devices# cat 2001.etb/status
> -Depth:  0x2000
> -Status: 0x1
> -RAM read ptr:   0x0
> -RAM wrt ptr:0x19d3   <- The write pointer is moving
> -Trigger cnt:0x0
> -Control:0x1
> -Flush status:   0x0
> -Flush ctrl: 0x2001
> -root:/sys/bus/coresight/devices#
> +
> +Observe the write pointer moving:
> +
> +root:/sys/bus/coresight/devices# cat 2001.etb/mgmt/rwp
> +0x1a8
> +root:/sys/bus/coresight/devices# cat 2001.etb/mgmt/rwp
> +0x19a6
>
>  Trace collection is stopped the same way:
>
> --
> 2.17.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: coresight: documentation: update sysfs section

[Mathieu Poirier]

On 7 May 2018 at 16:29, Kim Phillips  wrote:
> - Align and show updated ls devices output from the TC2, based on
>   current driver
>
> - Provide an example from an ETMv4 based system (Juno)
>
> - Reflect changes to the way the RAM write pointer is accessed since
>   it got changed in commit 7d83d17795ef ("coresight: tmc: adding sysFS
>   management entries").
>
> Cc: Mathieu Poirier 
> Cc: Jonathan Corbet 
> Signed-off-by: Kim Phillips 
> ---
>  Documentation/trace/coresight.txt | 40 ++-
>  1 file changed, 24 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/trace/coresight.txt 
> b/Documentation/trace/coresight.txt
> index 6f0120c3a4f1..d23d6354b372 100644
> --- a/Documentation/trace/coresight.txt
> +++ b/Documentation/trace/coresight.txt
> @@ -144,10 +144,21 @@ If everything goes well during the registration process 
> the new devices will
>  show up under /sys/bus/coresight/devices, as showns here for a TC2 platform:
>
>  root:~# ls /sys/bus/coresight/devices/
> -replicator  2003.tpiu2201c000.ptm  2203c000.etm  2203e000.etm
> -2001.etb 2004.funnel  2201d000.ptm  2203d000.etm
> +2001.etb   2004.funnel 2201d000.ptm  2203d000.etm  replicator
> +2003.tpiu  2201c000.ptm2203c000.etm  2203e000.etm
>  root:~#
>
> +and here for a Juno platform:
> +
> +root@juno:~# ls /sys/bus/coresight/devices/
> +2001.etf2012.replicator  2204.etm 230c.funnel
> +2003.tpiu   2013.funnel  220c.funnel  2314.etm
> +2004.funnel  2014.etf2214.etm 2324.etm
> +2007.etr2015.funnel  2304.etm 2334.etm
> +root@juno:~#
> +
> +Note the Juno uses an Embedded Trace Router (ETR) instead of an ETB.

The above is not entirely correct.  On Juno users can select the ETF,
ETR and TPIU as a sink target while on TC2, the ETB and TPIU can be
selected.


> +
>  The functions take a "struct coresight_device", which looks like this:
>
>  struct coresight_desc {
> @@ -193,16 +204,16 @@ the information carried in "THIS_MODULE".
>  How to use the tracer modules
>  -
>
> -Before trace collection can start, a coresight sink needs to be identify.
> +Before trace collection can start, a coresight sink needs to be identified.
>  There is no limit on the amount of sinks (nor sources) that can be enabled at
>  any given moment.  As a generic operation, all device pertaining to the sink
>  class will have an "active" entry in sysfs:
>
>  root:/sys/bus/coresight/devices# ls
> -replicator  2003.tpiu2201c000.ptm  2203c000.etm  2203e000.etm
> -2001.etb 2004.funnel  2201d000.ptm  2203d000.etm
> +2001.etb   2004.funnel 2201d000.ptm  2203d000.etm  replicator
> +2003.tpiu  2201c000.ptm2203c000.etm  2203e000.etm
>  root:/sys/bus/coresight/devices# ls 2001.etb
> -enable_sink  status  trigger_cntr
> +enable_sink  mgmt  power  subsystem  trigger_cntr  uevent
>  root:/sys/bus/coresight/devices# echo 1 > 2001.etb/enable_sink
>  root:/sys/bus/coresight/devices# cat 2001.etb/enable_sink
>  1
> @@ -216,16 +227,13 @@ trigger a trace capture:
>  root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
>  root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
>  1
> -root:/sys/bus/coresight/devices# cat 2001.etb/status
> -Depth:  0x2000
> -Status: 0x1
> -RAM read ptr:   0x0
> -RAM wrt ptr:0x19d3   <- The write pointer is moving
> -Trigger cnt:0x0
> -Control:0x1
> -Flush status:   0x0
> -Flush ctrl: 0x2001
> -root:/sys/bus/coresight/devices#
> +
> +Observe the write pointer moving:
> +
> +root:/sys/bus/coresight/devices# cat 2001.etb/mgmt/rwp
> +0x1a8
> +root:/sys/bus/coresight/devices# cat 2001.etb/mgmt/rwp
> +0x19a6
>
>  Trace collection is stopped the same way:
>
> --
> 2.17.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] coresight: Remove %px for printing pcsr value

[Mathieu Poirier]

On 1 May 2018 at 23:00, Leo Yan  wrote:
> The driver prints pcsr twice: the first time it uses specifier %px to
> print hexadecimal pcsr value and the second time uses specifier %pS for
> output kernel symbols.
>
> As suggested by Kees, using %pS should be sufficient and %px isn't
> necessary; the reason is if the pcsr is a kernel space address, we can
> easily get to know the code line from %pS format, on the other hand, if
> the pcsr value doesn't fall into kernel space range (e.g. if the CPU is
> stuck in firmware), %pS also gives out pcsr hexadecimal value.
>
> So this commit removes useless %px and update section "Output format"
> in the document for alignment between the code and document.
>
> Suggested-by: Kees Cook 
> Cc: Mathieu Poirier 
> Signed-off-by: Leo Yan 

Applied - thanks,
Mathieu


> ---
>  Documentation/trace/coresight-cpu-debug.txt   | 4 ++--
>  drivers/hwtracing/coresight/coresight-cpu-debug.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/trace/coresight-cpu-debug.txt 
> b/Documentation/trace/coresight-cpu-debug.txt
> index 2b9b51c..89ab09e 100644
> --- a/Documentation/trace/coresight-cpu-debug.txt
> +++ b/Documentation/trace/coresight-cpu-debug.txt
> @@ -177,11 +177,11 @@ Here is an example of the debugging output format:
>  ARM external debug module:
>  coresight-cpu-debug 85.debug: CPU[0]:
>  coresight-cpu-debug 85.debug:  EDPRSR:  0001 (Power:On DLK:Unlock)
> -coresight-cpu-debug 85.debug:  EDPCSR:  [] 
> handle_IPI+0x174/0x1d8
> +coresight-cpu-debug 85.debug:  EDPCSR:  handle_IPI+0x174/0x1d8
>  coresight-cpu-debug 85.debug:  EDCIDSR: 
>  coresight-cpu-debug 85.debug:  EDVIDSR: 9000 (State:Non-secure 
> Mode:EL1/0 Width:64bits VMID:0)
>  coresight-cpu-debug 852000.debug: CPU[1]:
>  coresight-cpu-debug 852000.debug:  EDPRSR:  0001 (Power:On DLK:Unlock)
> -coresight-cpu-debug 852000.debug:  EDPCSR:  [] 
> debug_notifier_call+0x23c/0x358
> +coresight-cpu-debug 852000.debug:  EDPCSR:  debug_notifier_call+0x23c/0x358
>  coresight-cpu-debug 852000.debug:  EDCIDSR: 
>  coresight-cpu-debug 852000.debug:  EDVIDSR: 9000 (State:Non-secure 
> Mode:EL1/0 Width:64bits VMID:0)
> diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
> b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> index 9cdb3fb..78a054e 100644
> --- a/drivers/hwtracing/coresight/coresight-cpu-debug.c
> +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> @@ -315,7 +315,7 @@ static void debug_dump_regs(struct debug_drvdata *drvdata)
> }
>
> pc = debug_adjust_pc(drvdata);
> -   dev_emerg(dev, " EDPCSR:  [<%px>] %pS\n", (void *)pc, (void *)pc);
> +   dev_emerg(dev, " EDPCSR:  %pS\n", (void *)pc);
>
> if (drvdata->edcidsr_present)
> dev_emerg(dev, " EDCIDSR: %08x\n", drvdata->edcidsr);
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/3] coresight: Add section for integration with the perf tools

[Mathieu Poirier]

Adding a section that document how to use the Coresight framework and
drivers from the perf tools.

Signed-off-by: Mathieu Poirier 
---
 Documentation/trace/coresight.txt | 52 ++-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/Documentation/trace/coresight.txt 
b/Documentation/trace/coresight.txt
index 710c75b6c73f..ab0d0f2d5cec 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -187,10 +187,19 @@ that can be performed on them (see "struct 
coresight_ops").  The
 specific to that component only.  "Implementation defined" customisations are
 expected to be accessed and controlled using those entries.
 
+
 How to use the tracer modules
 -
 
-Before trace collection can start, a coresight sink needs to be identify.
+There are two ways to use the Coresight framework: 1) using the perf cmd line
+tools and 2) interacting directly with the Coresight devices using the sysFS
+interface.  Preference is given to the former as using the sysFS interface
+requires a deep understanding of the Coresight HW.  The following sections
+provide details on using both methods.
+
+1) Using the sysFS interface:
+
+Before trace collection can start, a coresight sink needs to be identified.
 There is no limit on the amount of sinks (nor sources) that can be enabled at
 any given moment.  As a generic operation, all device pertaining to the sink
 class will have an "active" entry in sysfs:
@@ -295,6 +304,47 @@ Instruction 135708310x8026B584  E28DD00C   
 false   ADD
 Instruction 0   0x8026B588  E8BD8000trueLDM  
sp!,{pc}
 Timestamp   Timestamp: 17107041535
 
+2) Using perf framework:
+
+Coresight tracers are represented using the Perf framework's Performance
+Monitoring Unit (PMU) abstraction.  As such the perf framework takes charge of
+controlling when tracing gets enabled based on when the process of interest is
+scheduled.  When configured in a system, Coresight PMUs will be listed when
+queried by the perf command line tool:
+
+   linaro@linaro-nano:~$ ./perf list pmu
+
+   List of pre-defined events (to be used in -e):
+
+   cs_etm//[Kernel PMU event]
+
+   linaro@linaro-nano:~$
+
+Regardless of the number of tracers available in a system (usually equal to the
+amount of processor cores), the "cs_etm" PMU will be listed only once.
+
+A Coresight PMU works the same way as any other PMU, i.e the name of the PMU is
+listed along with configuration options within forward slashes '/'.  Since a
+Coresight system will typically have more than one sink, the name of the sink 
to
+work with needs to be specified as an event option.  Names for sink to choose
+from are listed in sysFS under ($SYSFS)/bus/coresight/devices:
+
+   root@linaro-nano:~# ls /sys/bus/coresight/devices/
+   2001.etf   2004.funnel  2010.stm  2204.etm
+   2214.etm  230c.funnel  2324.etm 2003.tpiu
+   2007.etr 2012.replicator  220c.funnel
+   2304.etm  2314.etm 2334.etm
+
+   root@linaro-nano:~# perf record -e cs_etm/@2007.etr/u --per-thread 
program
+
+The syntax within the forward slashes '/' is important.  The '@' character
+tells the parser that a sink is about to be specified and that this is the sink
+to use for the trace session.
+
+More information on the above and other example on how to use Coresight with
+the perf tools can be found in the "HOWTO.md" file of the openCSD gitHub
+repository [3].
+
 How to use the STM module
 -
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/3] coresight: Grouping all perf tools oriented section together

[Mathieu Poirier]

This patch groups together section pertaining to the perf tools.  That way
everything is at the same place rather than spread out.

Signed-off-by: Mathieu Poirier 
---
 Documentation/trace/coresight.txt | 72 +++
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/Documentation/trace/coresight.txt 
b/Documentation/trace/coresight.txt
index ab0d0f2d5cec..1d74ad0202b6 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -345,42 +345,7 @@ More information on the above and other example on how to 
use Coresight with
 the perf tools can be found in the "HOWTO.md" file of the openCSD gitHub
 repository [3].
 
-How to use the STM module
--
-
-Using the System Trace Macrocell module is the same as the tracers - the only
-difference is that clients are driving the trace capture rather
-than the program flow through the code.
-
-As with any other CoreSight component, specifics about the STM tracer can be
-found in sysfs with more information on each entry being found in [1]:
-
-root@genericarmv8:~# ls /sys/bus/coresight/devices/2010.stm
-enable_source   hwevent_select  port_enable subsystem   uevent
-hwevent_enable  mgmtport_select traceid
-root@genericarmv8:~#
-
-Like any other source a sink needs to be identified and the STM enabled before
-being used:
-
-root@genericarmv8:~# echo 1 > 
/sys/bus/coresight/devices/2001.etf/enable_sink
-root@genericarmv8:~# echo 1 > 
/sys/bus/coresight/devices/2010.stm/enable_source
-
-From there user space applications can request and use channels using the devfs
-interface provided for that purpose by the generic STM API:
-
-root@genericarmv8:~# ls -l /dev/2010.stm
-crw---1 root root   10,  61 Jan  3 18:11 /dev/2010.stm
-root@genericarmv8:~#
-
-Details on how to use the generic STM API can be found here [2].
-
-[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
-[2]. Documentation/trace/stm.txt
-
-
-Using perf tools
-
+2.1) AutoFDO analysis using the perf tools:
 
 perf can be used to record and analyze trace of programs.
 
@@ -428,3 +393,38 @@ sort example is from the AutoFDO tutorial 
(https://gcc.gnu.org/wiki/AutoFDO/Tuto
$ taskset -c 2 ./sort_autofdo
Bubble sorting array of 3 elements
5806 ms
+
+
+How to use the STM module
+-
+
+Using the System Trace Macrocell module is the same as the tracers - the only
+difference is that clients are driving the trace capture rather
+than the program flow through the code.
+
+As with any other CoreSight component, specifics about the STM tracer can be
+found in sysfs with more information on each entry being found in [1]:
+
+root@genericarmv8:~# ls /sys/bus/coresight/devices/2010.stm
+enable_source   hwevent_select  port_enable subsystem   uevent
+hwevent_enable  mgmtport_select traceid
+root@genericarmv8:~#
+
+Like any other source a sink needs to be identified and the STM enabled before
+being used:
+
+root@genericarmv8:~# echo 1 > 
/sys/bus/coresight/devices/2001.etf/enable_sink
+root@genericarmv8:~# echo 1 > 
/sys/bus/coresight/devices/2010.stm/enable_source
+
+From there user space applications can request and use channels using the devfs
+interface provided for that purpose by the generic STM API:
+
+root@genericarmv8:~# ls -l /dev/2010.stm
+crw---1 root root   10,  61 Jan  3 18:11 /dev/2010.stm
+root@genericarmv8:~#
+
+Details on how to use the generic STM API can be found here [2].
+
+[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
+[2]. Documentation/trace/stm.txt
+[3]. https://github.com/Linaro/perf-opencsd
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/3] coresight: Remove obsolete reference to "owner" in CoreSight descriptor

[Mathieu Poirier]

Field "owner" of struct coresight_desc has been removed a while back but
the documentation was not updated to reflect the changes.

Signed-off-by: Mathieu Poirier 
---
 Documentation/trace/coresight.txt | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/Documentation/trace/coresight.txt 
b/Documentation/trace/coresight.txt
index 6f0120c3a4f1..710c75b6c73f 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -187,9 +187,6 @@ that can be performed on them (see "struct coresight_ops"). 
 The
 specific to that component only.  "Implementation defined" customisations are
 expected to be accessed and controlled using those entries.
 
-Last but not least, "struct module *owner" is expected to be set to reflect
-the information carried in "THIS_MODULE".
-
 How to use the tracer modules
 -
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/3] coresight: Refresh documenation

[Mathieu Poirier]

Now that the perf tools CoreSight support is upstream this set adds
documentation to go with it and move things around so that topics 
are located together.


Changes for V2:
* Addressed grammatical problems highlighted by Randy

Mathieu Poirier (3):
  coresight: Remove obsolete reference to "owner" in CoreSight
descriptor
  coresight: Add section for integration with the perf tools
  coresight: Grouping all perf tools oriented section together

 Documentation/trace/coresight.txt | 103 +++---
 1 file changed, 75 insertions(+), 28 deletions(-)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] coresight: Add section for integration with the perf tools

[Mathieu Poirier]

On 16 April 2018 at 13:48, Randy Dunlap  wrote:
> On 04/16/2018 12:35 PM, Mathieu Poirier wrote:
>> Adding a section that document how to use the Coresight framework and
>> drivers from the perf tools.
>>
>> Signed-off-by: Mathieu Poirier 
>> ---
>>  Documentation/trace/coresight.txt | 50 
>> +++
>>  1 file changed, 50 insertions(+)
>>
>> diff --git a/Documentation/trace/coresight.txt 
>> b/Documentation/trace/coresight.txt
>> index 710c75b6c73f..8caae8050a60 100644
>> --- a/Documentation/trace/coresight.txt
>> +++ b/Documentation/trace/coresight.txt
>> @@ -187,9 +187,18 @@ that can be performed on them (see "struct 
>> coresight_ops").  The
>>  specific to that component only.  "Implementation defined" customisations 
>> are
>>  expected to be accessed and controlled using those entries.
>>
>> +
>>  How to use the tracer modules
>>  -
>>
>> +There is two ways to use the Coresight framework: 1) using the perf cmd line
>
>There are two ways
>
>> +tools and 2) interacting directly with the Coresight devices using the sysFS
>> +interface.  Preference is given to the former as using the sysFS interface
>> +requires a deep understanding of the Coresight HW.  The following sections
>> +provide details on using both methods.
>> +
>> +1) Using the sysFS interface:
>> +
>>  Before trace collection can start, a coresight sink needs to be identify.
>
>identified.
>
>>  There is no limit on the amount of sinks (nor sources) that can be enabled 
>> at
>>  any given moment.  As a generic operation, all device pertaining to the sink
>> @@ -295,6 +304,47 @@ Instruction 135708310x8026B584  
>> E28DD00Cfalse   ADD
>>  Instruction 0   0x8026B588  E8BD8000trueLDM  
>> sp!,{pc}
>>  Timestamp   Timestamp: 17107041535
>>
>> +2) Using perf framework:
>> +
>> +Coresight tracers are represented using the Perf framework's Performance
>> +Monitoring Unit (PMU) abstraction.  As such the perf framework takes charge 
>> of
>> +controlling when tracing gets enabled based on when the process of interest 
>> is
>> +scheduled.  When configured in a system, Coresight PMUs will be listed when
>> +queried by the perf command line tool:
>> +
>> + linaro@linaro-nano:~$ ./perf list pmu
>> +
>> + List of pre-defined events (to be used in -e):
>> +
>> + cs_etm//[Kernel PMU event]
>> +
>> + linaro@linaro-nano:~$
>> +
>> +Regardless of the number of tracers available in a system (usually equal to 
>> the
>> +amount of processor core), the "cs_etm" PMU will be listed only once.
>
> ?  cores),
>
>> +
>> +A Coresight PMU works the same way as any other PMUs, i.e the name of the 
>> PMU is
>
>  any other PMU, i.e.
>
>> +listed along with configuration options within forward slashes '/'.  Since a
>> +Coresight system will typically have more than one sink, the name of the 
>> sink to
>> +work with needs to be specified as an event option.  Names for sink to 
>> choose
>> +from are listed in sysFS under ($SYSFS)/bus/coresight/devices:
>> +
>> + root@linaro-nano:~# ls /sys/bus/coresight/devices/
>> + 2001.etf   2004.funnel  2010.stm  2204.etm
>> + 2214.etm  230c.funnel  2324.etm 2003.tpiu
>> + 2007.etr 2012.replicator  220c.funnel
>> + 2304.etm  2314.etm 2334.etm
>> +
>> + root@linaro-nano:~# perf record -e cs_etm/@2007.etr/u --per-thread 
>> program
>> +
>> +The syntax within the forward slashes '/' is important.  The '@' character
>> +tells the parser that a sink is about to be specified and that this is the 
>> IP
>
> Can we get away from using "IP" and call it a device or (hardware) module or
> something more descriptive?

Sure thing.

Thanks for taking the time to read the patch and providing comments.

Mathieu

>
>> +to use for the trace session.
>> +
>> +More information on the above and other example on how to use Coresight with
>> +the perf tools can be found in the "HOWTO.md" file of the openCSD gitHub
>> +repository [3].
>
>
> --
> ~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] coresight: Remove obsolete reference to "owner" in CoreSight descriptor

[Mathieu Poirier]

Field "owner" of struct coresight_desc has been removed a while back but
the documentation was not updated to reflect the changes.

Signed-off-by: Mathieu Poirier 
---
 Documentation/trace/coresight.txt | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/Documentation/trace/coresight.txt 
b/Documentation/trace/coresight.txt
index 6f0120c3a4f1..710c75b6c73f 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -187,9 +187,6 @@ that can be performed on them (see "struct coresight_ops"). 
 The
 specific to that component only.  "Implementation defined" customisations are
 expected to be accessed and controlled using those entries.
 
-Last but not least, "struct module *owner" is expected to be set to reflect
-the information carried in "THIS_MODULE".
-
 How to use the tracer modules
 -
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] coresight: Add section for integration with the perf tools

[Mathieu Poirier]

Adding a section that document how to use the Coresight framework and
drivers from the perf tools.

Signed-off-by: Mathieu Poirier 
---
 Documentation/trace/coresight.txt | 50 +++
 1 file changed, 50 insertions(+)

diff --git a/Documentation/trace/coresight.txt 
b/Documentation/trace/coresight.txt
index 710c75b6c73f..8caae8050a60 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -187,9 +187,18 @@ that can be performed on them (see "struct 
coresight_ops").  The
 specific to that component only.  "Implementation defined" customisations are
 expected to be accessed and controlled using those entries.
 
+
 How to use the tracer modules
 -
 
+There is two ways to use the Coresight framework: 1) using the perf cmd line
+tools and 2) interacting directly with the Coresight devices using the sysFS
+interface.  Preference is given to the former as using the sysFS interface
+requires a deep understanding of the Coresight HW.  The following sections
+provide details on using both methods.
+
+1) Using the sysFS interface:
+
 Before trace collection can start, a coresight sink needs to be identify.
 There is no limit on the amount of sinks (nor sources) that can be enabled at
 any given moment.  As a generic operation, all device pertaining to the sink
@@ -295,6 +304,47 @@ Instruction 135708310x8026B584  E28DD00C   
 false   ADD
 Instruction 0   0x8026B588  E8BD8000trueLDM  
sp!,{pc}
 Timestamp   Timestamp: 17107041535
 
+2) Using perf framework:
+
+Coresight tracers are represented using the Perf framework's Performance
+Monitoring Unit (PMU) abstraction.  As such the perf framework takes charge of
+controlling when tracing gets enabled based on when the process of interest is
+scheduled.  When configured in a system, Coresight PMUs will be listed when
+queried by the perf command line tool:
+
+   linaro@linaro-nano:~$ ./perf list pmu
+
+   List of pre-defined events (to be used in -e):
+
+   cs_etm//[Kernel PMU event]
+
+   linaro@linaro-nano:~$
+
+Regardless of the number of tracers available in a system (usually equal to the
+amount of processor core), the "cs_etm" PMU will be listed only once.
+
+A Coresight PMU works the same way as any other PMUs, i.e the name of the PMU 
is
+listed along with configuration options within forward slashes '/'.  Since a
+Coresight system will typically have more than one sink, the name of the sink 
to
+work with needs to be specified as an event option.  Names for sink to choose
+from are listed in sysFS under ($SYSFS)/bus/coresight/devices:
+
+   root@linaro-nano:~# ls /sys/bus/coresight/devices/
+   2001.etf   2004.funnel  2010.stm  2204.etm
+   2214.etm  230c.funnel  2324.etm 2003.tpiu
+   2007.etr 2012.replicator  220c.funnel
+   2304.etm  2314.etm 2334.etm
+
+   root@linaro-nano:~# perf record -e cs_etm/@2007.etr/u --per-thread 
program
+
+The syntax within the forward slashes '/' is important.  The '@' character
+tells the parser that a sink is about to be specified and that this is the IP
+to use for the trace session.
+
+More information on the above and other example on how to use Coresight with
+the perf tools can be found in the "HOWTO.md" file of the openCSD gitHub
+repository [3].
+
 How to use the STM module
 -
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] coresight: Refresh documenation

[Mathieu Poirier]

Now that the perf tools CoreSight support is upstream this set adds
documentation to go with it and move things around so that topics 
are located together. 

Mathieu Poirier (3):
  coresight: Remove obsolete reference to "owner" in CoreSight
descriptor
  coresight: Add section for integration with the perf tools
  coresight: Grouping all perf tools oriented section together

 Documentation/trace/coresight.txt | 101 --
 1 file changed, 74 insertions(+), 27 deletions(-)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] coresight: Grouping all perf tools oriented section together

[Mathieu Poirier]

This patch groups together section pertaining to the perf tools.  That way
everything is at the same place rather than spread out.

Signed-off-by: Mathieu Poirier 
---
 Documentation/trace/coresight.txt | 72 +++
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/Documentation/trace/coresight.txt 
b/Documentation/trace/coresight.txt
index 8caae8050a60..32c5b159e8fc 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -345,42 +345,7 @@ More information on the above and other example on how to 
use Coresight with
 the perf tools can be found in the "HOWTO.md" file of the openCSD gitHub
 repository [3].
 
-How to use the STM module
--
-
-Using the System Trace Macrocell module is the same as the tracers - the only
-difference is that clients are driving the trace capture rather
-than the program flow through the code.
-
-As with any other CoreSight component, specifics about the STM tracer can be
-found in sysfs with more information on each entry being found in [1]:
-
-root@genericarmv8:~# ls /sys/bus/coresight/devices/2010.stm
-enable_source   hwevent_select  port_enable subsystem   uevent
-hwevent_enable  mgmtport_select traceid
-root@genericarmv8:~#
-
-Like any other source a sink needs to be identified and the STM enabled before
-being used:
-
-root@genericarmv8:~# echo 1 > 
/sys/bus/coresight/devices/2001.etf/enable_sink
-root@genericarmv8:~# echo 1 > 
/sys/bus/coresight/devices/2010.stm/enable_source
-
-From there user space applications can request and use channels using the devfs
-interface provided for that purpose by the generic STM API:
-
-root@genericarmv8:~# ls -l /dev/2010.stm
-crw---1 root root   10,  61 Jan  3 18:11 /dev/2010.stm
-root@genericarmv8:~#
-
-Details on how to use the generic STM API can be found here [2].
-
-[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
-[2]. Documentation/trace/stm.txt
-
-
-Using perf tools
-
+2.1) AutoFDO analysis using the perf tools:
 
 perf can be used to record and analyze trace of programs.
 
@@ -428,3 +393,38 @@ sort example is from the AutoFDO tutorial 
(https://gcc.gnu.org/wiki/AutoFDO/Tuto
$ taskset -c 2 ./sort_autofdo
Bubble sorting array of 3 elements
5806 ms
+
+
+How to use the STM module
+-
+
+Using the System Trace Macrocell module is the same as the tracers - the only
+difference is that clients are driving the trace capture rather
+than the program flow through the code.
+
+As with any other CoreSight component, specifics about the STM tracer can be
+found in sysfs with more information on each entry being found in [1]:
+
+root@genericarmv8:~# ls /sys/bus/coresight/devices/2010.stm
+enable_source   hwevent_select  port_enable subsystem   uevent
+hwevent_enable  mgmtport_select traceid
+root@genericarmv8:~#
+
+Like any other source a sink needs to be identified and the STM enabled before
+being used:
+
+root@genericarmv8:~# echo 1 > 
/sys/bus/coresight/devices/2001.etf/enable_sink
+root@genericarmv8:~# echo 1 > 
/sys/bus/coresight/devices/2010.stm/enable_source
+
+From there user space applications can request and use channels using the devfs
+interface provided for that purpose by the generic STM API:
+
+root@genericarmv8:~# ls -l /dev/2010.stm
+crw---1 root root   10,  61 Jan  3 18:11 /dev/2010.stm
+root@genericarmv8:~#
+
+Details on how to use the generic STM API can be found here [2].
+
+[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
+[2]. Documentation/trace/stm.txt
+[3]. https://github.com/Linaro/perf-opencsd
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 6/6] coresight: etm4x: Support panic kdump

[Mathieu Poirier]

On Fri, Mar 30, 2018 at 11:15:24AM +0800, Leo Yan wrote:
> ETMv4 hardware information and configuration needs to be saved as
> metadata; the metadata format should be compatible with 'perf' tool and
> finally is used by tracing data decoder.  ETMv4 works as tracer per CPU,
> we cannot wait for gathering ETM info after CPU panic has happened in
> case there have CPU is locked up and can't response inter-processor
> interrupt for execution dump operations; so it's more reliable to gather
> tracer metadata when all of the CPUs are alive.
> 
> This patch saves ETMv4 metadata but with the different method for
> different registers.  Since values in TRCIDR{0, 1, 2, 8} and
> TRCAUTHSTATUS are read-only and won't change afterward, thus those
> registers values are filled into metadata structure when tracers are
> instantiated.  The configuration and control registers TRCCONFIGR and
> TRCTRACEIDR are dynamically configured, their values are recorded during
> tracer enabling phase.
> 
> To avoid unnecessary overload introduced by set/clear operations for
> updating kdump node, we only set ETMv4 metadata info for the
> corresponding kdump node at initialization and won't be cleared anymore.
> 
> Suggested-by: Mathieu Poirier 
> Signed-off-by: Leo Yan 
> ---
>  drivers/hwtracing/coresight/coresight-etm4x.c | 27 
> +++
>  drivers/hwtracing/coresight/coresight-etm4x.h | 15 +++
>  2 files changed, 42 insertions(+)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c 
> b/drivers/hwtracing/coresight/coresight-etm4x.c
> index cf364a5..88b1e19 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> @@ -288,6 +288,8 @@ static int etm4_enable(struct coresight_device *csdev,
>   int ret;
>   u32 val;
>   struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
> + struct etmv4_config *config = &drvdata->config;
> + struct etmv4_metadata *metadata = &drvdata->metadata;
>  
>   val = local_cmpxchg(&drvdata->mode, CS_MODE_DISABLED, mode);
>  
> @@ -306,6 +308,10 @@ static int etm4_enable(struct coresight_device *csdev,
>   ret = -EINVAL;
>   }
>  
> + /* Update tracer meta data after tracer configuration */
> + metadata->trcconfigr = config->cfg;
> + metadata->trctraceidr = drvdata->trcid;
> +
>   /* The tracer didn't start */
>   if (ret)
>   local_set(&drvdata->mode, CS_MODE_DISABLED);
> @@ -438,6 +444,7 @@ static void etm4_init_arch_data(void *info)
>   u32 etmidr4;
>   u32 etmidr5;
>   struct etmv4_drvdata *drvdata = info;
> + struct etmv4_metadata *metadata = &drvdata->metadata;
>  
>   /* Make sure all registers are accessible */
>   etm4_os_unlock(drvdata);
> @@ -590,6 +597,16 @@ static void etm4_init_arch_data(void *info)
>   drvdata->nrseqstate = BMVAL(etmidr5, 25, 27);
>   /* NUMCNTR, bits[30:28] number of counters available for tracing */
>   drvdata->nr_cntr = BMVAL(etmidr5, 28, 30);
> +
> + /* Update metadata */
> + metadata->magic = ETM4_METADATA_MAGIC;
> + metadata->cpu = drvdata->cpu;
> + metadata->trcidr0 = readl_relaxed(drvdata->base + TRCIDR0);
> + metadata->trcidr1 = readl_relaxed(drvdata->base + TRCIDR1);
> + metadata->trcidr2 = readl_relaxed(drvdata->base + TRCIDR2);
> + metadata->trcidr8 = readl_relaxed(drvdata->base + TRCIDR8);
> + metadata->trcauthstatus = readl_relaxed(drvdata->base + TRCAUTHSTATUS);
> +
>   CS_LOCK(drvdata->base);
>  }
>  
> @@ -957,6 +974,7 @@ static int etm4_probe(struct amba_device *adev, const 
> struct amba_id *id)
>   struct device *dev = &adev->dev;
>   struct coresight_platform_data *pdata = NULL;
>   struct etmv4_drvdata *drvdata;
> + struct etmv4_metadata *metadata;
>   struct resource *res = &adev->res;
>   struct coresight_desc desc = { 0 };
>   struct device_node *np = adev->dev.of_node;
> @@ -1027,6 +1045,15 @@ static int etm4_probe(struct amba_device *adev, const 
> struct amba_id *id)
>   goto err_arch_supported;
>   }
>  
> + /* Set source device handler and metadata into kdump node */
> + metadata = &drvdata->metadata;
> + ret = coresight_kdump_source(drvdata->cpu, drvdata->csdev,
> +  (char *)metadata, sizeof(*metadata));
> + if (ret) {
> + coresight_unregister(drvdata->csdev);
> + goto err_arch_supported;
> + }
> +
> 

Re: [PATCH v4 5/6] coresight: Set and clear sink device handler for kdump node

[Mathieu Poirier]

On Fri, Mar 30, 2018 at 11:15:23AM +0800, Leo Yan wrote:
> If Coresight path is enabled for specific CPU, the sink device handler
> need to be set to kdump node; on the other hand we also need to clear
> sink device handler when path is disabled.
> 
> This patch sets sink devices handler for kdump node for two separate
> Coresight enabling modes: CS_MODE_SYSFS and CS_MODE_PERF; and clear the
> handler when Coresight is disabled.
> 
> Signed-off-by: Leo Yan 
> ---
>  drivers/hwtracing/coresight/coresight-etm-perf.c |  5 +
>  drivers/hwtracing/coresight/coresight.c  | 16 ++--
>  2 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c 
> b/drivers/hwtracing/coresight/coresight-etm-perf.c
> index 8a0ad77..f8b159c 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -139,6 +139,8 @@ static void free_event_data(struct work_struct *work)
>   for_each_cpu(cpu, mask) {
>   if (!(IS_ERR_OR_NULL(event_data->path[cpu])))
>   coresight_release_path(event_data->path[cpu]);
> +
> + coresight_kdump_sink(cpu, NULL);
>   }
>  
>   kfree(event_data->path);
> @@ -238,6 +240,9 @@ static void *etm_setup_aux(int event_cpu, void **pages,
>   event_data->path[cpu] = coresight_build_path(csdev, sink);
>   if (IS_ERR(event_data->path[cpu]))
>   goto err;
> +
> + if (coresight_kdump_sink(cpu, sink))
> + goto err;

I remember telling you to use free_event_data() and etm_setup_aux().  _Maybe_ it
made sense in the previous patchset but in this one it won't work.  We need to
reflect the current trace context, as such use etm_event_start() and
etm_event_stop().

In etm_event_start() call coresight_kdump_sink(cpu, sink) just before
source_ops(csdev)->enable().  Similarly call coresight_kdump_sink(cpu, NULL)
right after source_ops(csdev)->disable() in etm_event_stop().

Find me on IRC if you want more information on this.

>   }
>  
>   if (!sink_ops(sink)->alloc_buffer)
> diff --git a/drivers/hwtracing/coresight/coresight.c 
> b/drivers/hwtracing/coresight/coresight.c
> index 389c4ba..483a1f7 100644
> --- a/drivers/hwtracing/coresight/coresight.c
> +++ b/drivers/hwtracing/coresight/coresight.c
> @@ -272,6 +272,7 @@ static int coresight_enable_source(struct 
> coresight_device *csdev, u32 mode)
>  static bool coresight_disable_source(struct coresight_device *csdev)
>  {
>   if (atomic_dec_return(csdev->refcnt) == 0) {
> +

This newline shouldn't be part of this set.

>   if (source_ops(csdev)->disable)
>   source_ops(csdev)->disable(csdev, NULL);
>   csdev->enable = false;
> @@ -612,6 +613,13 @@ int coresight_enable(struct coresight_device *csdev)
>   if (ret)
>   goto err_source;
>  
> + cpu = source_ops(csdev)->cpu_id(csdev);
> +
> + /* Set sink device handler into kdump node */
> + ret = coresight_kdump_sink(cpu, sink);
> + if (ret)
> + goto err_kdump;
> +

Call coresight_kdump_sink() just before coresight_enable_source().  That way if
there is a dump just after coresight_enable_source() is called we get the chance
of getting some traces in the dump file. 

>   switch (subtype) {
>   case CORESIGHT_DEV_SUBTYPE_SOURCE_PROC:
>   /*
> @@ -621,7 +629,6 @@ int coresight_enable(struct coresight_device *csdev)
>* be a single session per tracer (when working from sysFS)
>* a per-cpu variable will do just fine.
>*/
> - cpu = source_ops(csdev)->cpu_id(csdev);
>   per_cpu(tracer_path, cpu) = path;
>   break;
>   case CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE:
> @@ -636,6 +643,9 @@ int coresight_enable(struct coresight_device *csdev)
>   mutex_unlock(&coresight_mutex);
>   return ret;
>  
> +err_kdump:
> + coresight_disable_source(csdev);
> +
>  err_source:
>   coresight_disable_path(path);
>  
> @@ -659,9 +669,10 @@ void coresight_disable(struct coresight_device *csdev)
>   if (!csdev->enable || !coresight_disable_source(csdev))
>   goto out;
>  
> + cpu = source_ops(csdev)->cpu_id(csdev);
> +
>   switch (csdev->subtype.source_subtype) {
>   case CORESIGHT_DEV_SUBTYPE_SOURCE_PROC:
> - cpu = source_ops(csdev)->cpu_id(csdev);
>   path = per_cpu(tracer_path, cpu);
>   per_cpu(tracer_path, cpu) = NULL;
>   break;
> @@ -674,6 +685,7 @@ void coresight_disable(struct coresight_device *csdev)
>   break;
>   }
>  
> + coresight_kdump_sink(cpu, NULL);
>   coresight_disable_path(path);
>   coresight_release_path(path);
>  
> -- 
> 2.7.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kern

Re: [PATCH v4 4/6] coresight: tmc: Hook callback for panic kdump

[Mathieu Poirier]

On Fri, Mar 30, 2018 at 11:15:22AM +0800, Leo Yan wrote:
> Since Coresight panic kdump functionality has been ready, this patch is
> to hook panic callback function for ETB/ETF driver.  The driver data
> structure has allocated a buffer when the session started, so simply
> save tracing data into this buffer when panic happens and update buffer
> related info for kdump.
> 
> Signed-off-by: Leo Yan 
> ---
>  drivers/hwtracing/coresight/coresight-tmc-etf.c | 30 
> +
>  1 file changed, 30 insertions(+)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c 
> b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> index e2513b7..d20d546 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> @@ -504,6 +504,35 @@ static void tmc_update_etf_buffer(struct 
> coresight_device *csdev,
>   CS_LOCK(drvdata->base);
>  }
>  
> +static void tmc_panic_cb(void *data)

I would call the function tmc_kdump_panic_cb()... That way there is absolutely
no confusion as to what it does.

> +{
> + struct coresight_device *csdev = (struct coresight_device *)data;
> + struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
> + unsigned long flags;
> +
> + if (WARN_ON_ONCE(drvdata->config_type != TMC_CONFIG_TYPE_ETB &&
> +  drvdata->config_type != TMC_CONFIG_TYPE_ETF))
> + return;
> +
> + if (drvdata->mode == CS_MODE_DISABLED)
> + return;

This is racy - between the check and acquiring the spinlock someone may beat you
to it.

> +
> + spin_lock_irqsave(&drvdata->spinlock, flags);

if (drvdata->mode == CS_MODE_DISABLED)
goto out;

drvdata->mode = CS_MODE_DISABLED

> +
> + CS_UNLOCK(drvdata->base);
> +
> + tmc_flush_and_stop(drvdata);
> + tmc_etb_dump_hw(drvdata);
> +
> + CS_LOCK(drvdata->base);
> +
> + /* Update buffer info for panic dump */
> + csdev->kdump_buf = drvdata->buf;
> + csdev->kdump_buf_sz = drvdata->len;

out:
> +
> + spin_unlock_irqrestore(&drvdata->spinlock, flags);
> +}
> +
>  static const struct coresight_ops_sink tmc_etf_sink_ops = {
>   .enable = tmc_enable_etf_sink,
>   .disable= tmc_disable_etf_sink,
> @@ -512,6 +541,7 @@ static const struct coresight_ops_sink tmc_etf_sink_ops = 
> {
>   .set_buffer = tmc_set_etf_buffer,
>   .reset_buffer   = tmc_reset_etf_buffer,
>   .update_buffer  = tmc_update_etf_buffer,
> + .panic_cb   = tmc_panic_cb,
>  };
>  
>  static const struct coresight_ops_link tmc_etf_link_ops = {
> -- 
> 2.7.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/6] coresight: Support panic kdump functionality

[Mathieu Poirier]

On Fri, Mar 30, 2018 at 11:15:21AM +0800, Leo Yan wrote:
> After kernel panic happens, Coresight tracing data has much useful info
> which can be used for analysis.  For example, the trace info from ETB
> RAM can be used to check the CPU execution flows before the crash.  So
> we can save the tracing data from sink devices, and rely on kdump to
> save DDR content and uses "crash" tool to extract Coresight dumping
> from the vmcore file.
> 
> This patch is to add a simple framework to support panic dump
> functionality; it registers panic notifier, and provide the helper
> functions coresight_kdump_source()/coresight_kdump_sink() so Coresight
> source and sink devices can be recorded into Coresight kdump node for
> kernel panic kdump.
> 
> When kernel panic happens, the notifier iterates dump array and invoke
> callback function to dump tracing data.  Later the tracing data can be
> used to reverse execution flow before the kernel panic.
> 
> Signed-off-by: Leo Yan 
> ---
>  drivers/hwtracing/coresight/Kconfig|   9 +
>  drivers/hwtracing/coresight/Makefile   |   1 +
>  .../hwtracing/coresight/coresight-panic-kdump.c| 199 
> +
>  drivers/hwtracing/coresight/coresight-priv.h   |  12 ++
>  include/linux/coresight.h  |   4 +
>  5 files changed, 225 insertions(+)
>  create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c
> 
> diff --git a/drivers/hwtracing/coresight/Kconfig 
> b/drivers/hwtracing/coresight/Kconfig
> index ef9cb3c..3089abf 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -103,4 +103,13 @@ config CORESIGHT_CPU_DEBUG
> properly, please refer Documentation/trace/coresight-cpu-debug.txt
> for detailed description and the example for usage.
>  
> +config CORESIGHT_PANIC_KDUMP
> + bool "CoreSight Panic Kdump driver"
> + depends on ARM || ARM64
> + help
> +   This driver provides panic kdump functionality for CoreSight devices.
> +   When kernel panic happen Coresight device supplied callback function

s/Coresight/CoreSight

> +   is to dump trace data to memory. From then on, kdump can be used to
> +   extract the trace data from kernel dump file.
> +
>  endif
> diff --git a/drivers/hwtracing/coresight/Makefile 
> b/drivers/hwtracing/coresight/Makefile
> index 61db9dd..946fe19 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -18,3 +18,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
>  obj-$(CONFIG_CORESIGHT_DYNAMIC_REPLICATOR) += coresight-dynamic-replicator.o
>  obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
>  obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
> +obj-$(CONFIG_CORESIGHT_PANIC_KDUMP) += coresight-panic-kdump.o
> diff --git a/drivers/hwtracing/coresight/coresight-panic-kdump.c 
> b/drivers/hwtracing/coresight/coresight-panic-kdump.c
> new file mode 100644
> index 000..f4589e9
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-panic-kdump.c
> @@ -0,0 +1,199 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2017~2018 Linaro Limited.

I don't remember if I commented on this before but the above line (not the SPDX)
should be enclosed with C style comments (/* */) rather than C++ (//).

I would also add a new line between the copyright statement and the header file
listing.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "coresight-priv.h"
> +
> +/**
> + * struct coresight_kdump_node - Node information for dump
> + * @source_csdev:Handler for source coresight device
> + * @sink_csdev:  Handler for sink coresight device
> + */
> +struct coresight_kdump_node {
> + struct coresight_device *source_csdev;
> + struct coresight_device *sink_csdev;
> +};
> +
> +static DEFINE_SPINLOCK(coresight_kdump_lock);
> +static struct coresight_kdump_node *coresight_kdump_nodes;
> +static struct notifier_block coresight_kdump_nb;
> +
> +/**
> + * coresight_kdump_source - Set source dump info for specific CPU
> + * @cpu: CPU ID
> + * @csdev:   Source device structure handler
> + * @data:Pointer for source device metadata buffer
> + * @data_sz: Size of source device metadata buffer
> + *
> + * This function is a helper function which is used to set/clear source 
> device
> + * handler and metadata when the tracer is enabled; and it can be used to 
> clear
> + * source device related info when the tracer is disabled.
> + *
> + * Returns:  0 on success, negative errno otherwise.
> + */
> +int coresight_kdump_source(int cpu, struct coresight_device *csdev,
> +char *data, unsigned int data_sz)
> +{
> + struct coresight_kdump_node *node;
> + unsigned long flags;
> +
> + if (!coresight_kdump_nodes)
> + return -EPROBE_DEFER;

Before grabbing the lock you 

Re: [PATCH v4 2/6] doc: Add documentation for Coresight panic kdump

[Mathieu Poirier]

On Fri, Mar 30, 2018 at 11:15:20AM +0800, Leo Yan wrote:
> Add detailed documentation for Coresight panic kdump, which contains
> the idea for why need Coresight panic kdump and introduce the
> implementation of Coresight panic kdump framework; the last section is
> to explain what's usage.
> 
> Credits to Mathieu Poirier for many suggestions since the first version
> patch reviewing.  The suggestions include using an array to manage dump
> related info, this makes code scalable for more CPUs; the Coresight
> kdump driver and integration kdump flow with other Coresight devices
> also have many ideas from Mathieu.

Please remove the above paragraph.

> 
> Suggested-by: Mathieu Poirier 

And the above line too.

> Signed-off-by: Leo Yan 
> ---
>  .../trace/coresight/coresight-panic-kdump.txt  | 130 
> +
>  MAINTAINERS|   1 +
>  2 files changed, 131 insertions(+)
>  create mode 100644 Documentation/trace/coresight/coresight-panic-kdump.txt
> 
> diff --git a/Documentation/trace/coresight/coresight-panic-kdump.txt 
> b/Documentation/trace/coresight/coresight-panic-kdump.txt
> new file mode 100644
> index 000..c02e520
> --- /dev/null
> +++ b/Documentation/trace/coresight/coresight-panic-kdump.txt
> @@ -0,0 +1,130 @@
> + Coresight Panic Kdump
> + =
> +
> +   Author:   Leo Yan 
> +   Date: March 29th, 2018
> +
> +Introduction
> +
> +
> +Coresight has different sinks for trace data, the trace data is quite useful
> +for postmortem debugging.  Embedded Trace Buffer (ETB) is one type sink which
> +provides on-chip storage of trace data, usually uses SRAM as the buffer with
> +several KBs size; if the SoC designs to support 'Local ETF' (ARM DDI 0461B,
> +chapter 1.2.7), every CPU has one local ETB buffer so the per CPU trace data
> +can avoid being overwritten by each other.  Trace Memory Controller (TMC) is
> +another kind sink designed as a successor to the CoreSight ETB to capture 
> trace
> +into DRAM.

I don't think details about the sinks themselves is worth adding here.  In my
opinion we can simply stick with the abstract notion of a sink and achieve the
same result. 

> +
> +After Linux kernel panic has occurred, the trace data keeps the last 
> execution
> +flow before issues happen.  We could consider the trace data is quite useful 
> for
> +postmortem debugging, especially when we can save trace data into DRAM and 
> rely on

Even in documentation files please keep line wrapped to 80 characters (note that
checkpatch won't complain).  Console text from the command line (as added below)
is exempt from this rule.

> +kdump to preserve them into vmcore file; at the end, we can retrieve trace 
> data
> +from vmcore file and "offline" to analyze the execution flow.
> +
> +
> +Implementation
> +--
> +
> +Coresight panic kdump is a simple framework to support Coresight dump
> +functionality when panic happens, it maintains an array for the dump, every 
> array
> +item is dedicated to one specific CPU by using CPU number as an index.  For
> +'offline' recovery and analysis Coresight tracing data, except should to 
> recovery

This paragraph as a whole is hard to read and the usage of the word 'except'
above doesn't not work in this context.  Please consider reviewing and/or get in
touch with me if you want to work on it together.  

> +tracing data for sinks, we also need to know CPU tracer configurations; for 
> this
> +purpose, the array item is a structure which combines source and sink device
> +handlers, the device handler points to Coresight device structure which 
> contains
> +dump info: dump buffer base address and buffer size.  Below diagram is to
> +present data structures relationship:
> +
> +  array: coresight_kdump_nodes
> +  +--+--+--+
> +  | CPU0 | CPU1 |   ...|
> +  +--+--+--+
> + |
> + V
> +  coresight_kdump_node  coresight_device
> +  +---+ +---+
> +  |source_csdev   | --> |kdump_buf  |
> +  +---+  /  +---+
> +  |sink_csdev | '   |kdump_buf_sz   |
> +  +---+ +---+
> +
> +Every CPU has its own tracer, we need save tracer registers for tracer ID and
> +configuration related information as metadata, the metadata is used by 
> tracing
> +decoder.  But the tracer has the different configuration at the different 
> phase,
> +below diagram explains tracer configurat

Re: [PATCH v4 0/6] Coresight: Support panic kdump

[Mathieu Poirier]

Hi Leo,

Please see below (and in upcoming patches) my comments related to your latest
work.

Thanks,
Mathieu

On Fri, Mar 30, 2018 at 11:15:18AM +0800, Leo Yan wrote:
> This patch set is to explore Coresight tracing data for postmortem
> debugging.  When kernel panic happens, the Coresight panic kdump can
> help to save on-chip tracing data and tracer metadata into DRAM, later
> relies on kdump and crash/perf tools to recovery tracing data for
> "offline" analysis.
> 
> The documentation is important to understand the purpose of Coresight
> panic kdump, the implementation of framework and usage. Patches 0001
> and patch 0002 are used for creating new sub directory for placing
> Coresight docs and add a new doc for Coresight panic kdump.
> 
> Patch 0003 introduces the simple panic kdump framework which provides
> helper functions can be used by Coresight devices, and it registers
> panic notifier for dump tracing data.
> 
> Patches 0004/0005 support panic kdump for ETB; Patch 0006 supports the
> kdump for ETMv4.
> 
> This patch set has been reworked by following suggestions at Linaro
> HKG18 connect (mainly suggestions from Mathieu, thanks a lot!), and
> it's rebased on acme git tree [1] with last commit 109d59b900e7 ('perf
> vendor events s390: Add JSON files for IBM z14').
> 
> Due Coresight kdump data structure has been changed significantly, the
> corresponding crash extension program also has been updated for this
> reason [2]; furthermore the crash extension program is updated to
> dynamically generate kernel buildid according to vmlinux elf info [3],
> this is a fixing for the old code which uses hard-coded buildid value.
> 
> This patch set has been verified on 96boards Hikey620 with Coresight
> enabling by the sysFS interface.  Also the updated crash extension
> program has been verified to cowork with Coresight panic kdump and it
> successfully extracts tracing data from the vmcore and finally can be
> decoded by perf tool.
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> [2] https://git.linaro.org/people/leo.yan/crash.git/tree/extensions/csdump.c
> [3] 
> https://git.linaro.org/people/leo.yan/crash.git/tree/extensions/csdump_buildid.c
> 
> Changes from v3:
> * Following Mathieu suggestion, reworked the panic kdump framework,
>   used kdump array to maintain source and sink device handlers;
> * According to Mathieu suggestion, optimized panic notifier to
>   firstly dump panic CPU tracing data and then dump other CPUs tracing
>   data;
> * Refined doc to reflect these implementation changes;
> * Changed ETMv4 driver to add source device handler at probe phase;
> * Refactored crash extension program to reflect kernel changes.
> 
> Changes from v2:
> * Add the two patches for documentation.
> * Following Mathieu suggestion, reworked the panic kdump framework,
>   removed the useless flag "PRE_PANIC".
> * According to comment, changed to add and delete kdump node operations
>   in sink enable/disable functions;
> * According to Mathieu suggestion, handle kdump node
>   addition/deletion/updating separately for sysFS interface and perf
>   method.
> 
> Changes from v1:
> * Add support to dump ETMv4 meta data.
> * Wrote 'crash' extension csdump.so so rely on it to generate 'perf'
>   format compatible file.
> * Refactored panic dump driver to support pre & post panic dump.
> 
> Changes from RFC:
> * Follow Mathieu's suggestion, use general framework to support dump
>   functionality.
> * Changed to use perf to analyse trace data.
> 
> Leo Yan (6):
>   doc: Add Coresight documentation directory
>   doc: Add documentation for Coresight panic kdump
>   coresight: Support panic kdump functionality
>   coresight: tmc: Hook callback for panic kdump
>   coresight: Set and clear sink device handler for kdump node
>   coresight: etm4x: Support panic kdump
> 
>  Documentation/trace/coresight-cpu-debug.txt| 187 --
>  Documentation/trace/coresight.txt  | 383 
> -
>  .../trace/coresight/coresight-cpu-debug.txt| 187 ++
>  .../trace/coresight/coresight-panic-kdump.txt  | 130 +++
>  Documentation/trace/coresight/coresight.txt| 383 
> +

Please use the -M option with git format-patch in order to prevent the metrics
associated with the renaming of files to be tallied.

>  MAINTAINERS|   5 +-
>  drivers/hwtracing/coresight/Kconfig|   9 +
>  drivers/hwtracing/coresight/Makefile   |   1 +
>  drivers/hwtracing/coresight/coresight-etm-perf.c   |   5 +
>  drivers/hwtracing/coresight/coresight-etm4x.c  |  27 ++
>  drivers/hwtracing/coresight/coresight-etm4x.h  |  15 +
>  .../hwtracing/coresight/coresight-panic-kdump.c| 199 +++
>  drivers/hwtracing/coresight/coresight-priv.h   |  12 +
>  drivers/hwtracing/coresight/coresight-tmc-etf.c|  30 ++
>  drivers/hwtracing/coresight/coresight.c|  16 +-
>

Re: [PATCH v3 6/6] coresight: etm4x: Support panic kdump

[Mathieu Poirier]

On 9 January 2018 at 22:33, Leo Yan  wrote:
> On Tue, Jan 09, 2018 at 01:21:28PM -0700, Mathieu Poirier wrote:
>> On Thu, Dec 21, 2017 at 04:20:15PM +0800, Leo Yan wrote:
>> > ETMv4 hardware information and configuration needs to be saved as
>> > metadata; these metadata should be compatible with tool 'perf' and
>> > can be used for tracing data analysis.  ETMv4 usually works as tracer
>> > per CPU, we cannot wait to gather ETM info after the CPU has been panic
>> > and cannot execute dump operations for itself; so should gather
>> > metadata when the corresponding CPU is alive.
>> >
>> > Since values in TRCIDR{0, 1, 2, 8} and TRCAUTHSTATUS are read-only and
>> > won't change at the runtime.  Those registers value are filled when
>> > tracers are instantiated.
>> >
>> > The configuration and control registers TRCCONFIGR and TRCTRACEIDR are
>> > dynamically configured, we record their value when enabling coresight
>> > path.  When operating from sysFS tracer these two registers are recorded
>> > in etm4_enable_sysfs() and add kdump node into list, and remove the
>> > kdump node in etm4_disable_sysfs().  When operating from perf,
>> > etm_setup_aux() adds all tracers to the dump list and etm4_enable_perf()
>> > is used to record configuration registers and update dump buffer info,
>> > this can avoid unnecessary list addition and deletion operations.
>> > Removal of the tracers from the dump list is done in function
>> > free_event_data().
>> >
>> > Suggested-by: Mathieu Poirier 
>> > Signed-off-by: Leo Yan 
>> > ---
>> >  drivers/hwtracing/coresight/coresight-etm-perf.c | 12 +++-
>> >  drivers/hwtracing/coresight/coresight-etm4x.c| 23 
>> > +++
>> >  drivers/hwtracing/coresight/coresight-etm4x.h| 15 +++
>> >  3 files changed, 49 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c 
>> > b/drivers/hwtracing/coresight/coresight-etm-perf.c
>> > index 8a0ad77..fec779b 100644
>> > --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
>> > +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
>> > @@ -137,6 +137,12 @@ static void free_event_data(struct work_struct *work)
>> > }
>> >
>> > for_each_cpu(cpu, mask) {
>> > +   struct coresight_device *csdev;
>> > +
>> > +   csdev = per_cpu(csdev_src, cpu);
>> > +   if (csdev)
>> > +   coresight_kdump_del(csdev);
>> > +
>> > if (!(IS_ERR_OR_NULL(event_data->path[cpu])))
>> > coresight_release_path(event_data->path[cpu]);
>> > }
>> > @@ -195,7 +201,7 @@ static void etm_free_aux(void *data)
>> >  static void *etm_setup_aux(int event_cpu, void **pages,
>> >int nr_pages, bool overwrite)
>> >  {
>> > -   int cpu;
>> > +   int cpu, ret;
>> > cpumask_t *mask;
>> > struct coresight_device *sink;
>> > struct etm_event_data *event_data = NULL;
>> > @@ -238,6 +244,10 @@ static void *etm_setup_aux(int event_cpu, void 
>> > **pages,
>> > event_data->path[cpu] = coresight_build_path(csdev, sink);
>> > if (IS_ERR(event_data->path[cpu]))
>> > goto err;
>> > +
>> > +   ret = coresight_kdump_add(csdev, cpu);
>>
>> Aren't you missing the configuration for trcconfigr and trctraceidr?
>
> Ah, should update these two configurations in function
> etm4_enable_perf()?

Looking at what you've done for etm4_enable_sysfs() that is probably a
better choice.

>
>> > +   if (ret)
>> > +   goto err;
>> > }
>> >
>> > if (!sink_ops(sink)->alloc_buffer)
>> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c 
>> > b/drivers/hwtracing/coresight/coresight-etm4x.c
>> > index cf364a5..cbde398 100644
>> > --- a/drivers/hwtracing/coresight/coresight-etm4x.c
>> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
>> > @@ -258,10 +258,19 @@ static int etm4_enable_perf(struct coresight_device 
>> > *csdev,
>> >  static int etm4_enable_sysfs(struct coresight_device *csdev)
>> >  {
>> > struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>> > +   struct etmv4_config *config = &drvdata-&g

Re: [PATCH v3 3/6] coresight: Support panic kdump functionality

[Mathieu Poirier]

On 9 January 2018 at 22:19, Leo Yan  wrote:
> On Tue, Jan 09, 2018 at 11:41:26AM -0700, Mathieu Poirier wrote:
>> On Thu, Dec 21, 2017 at 04:20:12PM +0800, Leo Yan wrote:
>> > After kernel panic happens, coresight has many useful info can be used
>> > for analysis.  For example, the trace info from ETB RAM can be used to
>> > check the CPU execution flows before crash.  So we can save the tracing
>> > data from sink devices, and rely on kdump to save DDR content and uses
>> > "crash" tool to extract coresight dumping from vmcore file.
>> >
>> > This patch is to add a simple framework to support panic dump
>> > functionality; it registers panic notifier, and provide the general APIs
>> > {coresight_kdump_add|coresight_kdump_del} as helper functions so any
>> > coresight device can add itself into dump list or delete as needed.
>> >
>> > This driver provides helper function coresight_kdump_update() to update
>> > the dump buffer base address and buffer size.  This function can be used
>> > by coresight driver, e.g. it can be used to save ETM meta data info at
>> > runtime and these info can be prepared pre panic happening.
>> >
>> > When kernel panic happens, the notifier iterates dump list and calls
>> > callback function to dump device specific info.  The panic dump is
>> > mainly used to dump trace data so we can get to know the execution flow
>> > before the panic happens.
>> >
>> > Signed-off-by: Leo Yan 
>> > ---
>> >  drivers/hwtracing/coresight/Kconfig|   9 ++
>> >  drivers/hwtracing/coresight/Makefile   |   1 +
>> >  .../hwtracing/coresight/coresight-panic-kdump.c| 154 
>> > +
>> >  drivers/hwtracing/coresight/coresight-priv.h   |  13 ++
>> >  include/linux/coresight.h  |   7 +
>> >  5 files changed, 184 insertions(+)
>> >  create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c
>> >
>> > diff --git a/drivers/hwtracing/coresight/Kconfig 
>> > b/drivers/hwtracing/coresight/Kconfig
>> > index ef9cb3c..4812529 100644
>> > --- a/drivers/hwtracing/coresight/Kconfig
>> > +++ b/drivers/hwtracing/coresight/Kconfig
>> > @@ -103,4 +103,13 @@ config CORESIGHT_CPU_DEBUG
>> >   properly, please refer Documentation/trace/coresight-cpu-debug.txt
>> >   for detailed description and the example for usage.
>> >
>> > +config CORESIGHT_PANIC_KDUMP
>> > +   bool "CoreSight Panic Kdump driver"
>> > +   depends on ARM || ARM64
>>
>> At this time only ETMv4 supports the feature, so it is only ARM64.
>
> Thanks for reviewing, Mathieu.
>
> Will change to only for ARM64.
>
>> > +   help
>> > + This driver provides panic kdump functionality for CoreSight
>> > + devices.  When a kernel panic happen a device supplied callback 
>> > function
>> > + is used to save trace data to memory. From there we rely on kdump to 
>> > extract
>> > + the trace data from kernel dump file.
>> > +
>> >  endif
>> > diff --git a/drivers/hwtracing/coresight/Makefile 
>> > b/drivers/hwtracing/coresight/Makefile
>> > index 61db9dd..946fe19 100644
>> > --- a/drivers/hwtracing/coresight/Makefile
>> > +++ b/drivers/hwtracing/coresight/Makefile
>> > @@ -18,3 +18,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += 
>> > coresight-etm4x.o \
>> >  obj-$(CONFIG_CORESIGHT_DYNAMIC_REPLICATOR) += 
>> > coresight-dynamic-replicator.o
>> >  obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
>> >  obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
>> > +obj-$(CONFIG_CORESIGHT_PANIC_KDUMP) += coresight-panic-kdump.o
>> > diff --git a/drivers/hwtracing/coresight/coresight-panic-kdump.c 
>> > b/drivers/hwtracing/coresight/coresight-panic-kdump.c
>> > new file mode 100644
>> > index 000..c21d20b
>> > --- /dev/null
>> > +++ b/drivers/hwtracing/coresight/coresight-panic-kdump.c
>> > @@ -0,0 +1,154 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +// Copyright (c) 2017 Linaro Limited.
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +
>> > +#include "coresight-priv.h"
>> > +
>> > +typed

Re: [PATCH v3 6/6] coresight: etm4x: Support panic kdump

[Mathieu Poirier]

On Thu, Dec 21, 2017 at 04:20:15PM +0800, Leo Yan wrote:
> ETMv4 hardware information and configuration needs to be saved as
> metadata; these metadata should be compatible with tool 'perf' and
> can be used for tracing data analysis.  ETMv4 usually works as tracer
> per CPU, we cannot wait to gather ETM info after the CPU has been panic
> and cannot execute dump operations for itself; so should gather
> metadata when the corresponding CPU is alive.
> 
> Since values in TRCIDR{0, 1, 2, 8} and TRCAUTHSTATUS are read-only and
> won't change at the runtime.  Those registers value are filled when
> tracers are instantiated.
> 
> The configuration and control registers TRCCONFIGR and TRCTRACEIDR are
> dynamically configured, we record their value when enabling coresight
> path.  When operating from sysFS tracer these two registers are recorded
> in etm4_enable_sysfs() and add kdump node into list, and remove the
> kdump node in etm4_disable_sysfs().  When operating from perf,
> etm_setup_aux() adds all tracers to the dump list and etm4_enable_perf()
> is used to record configuration registers and update dump buffer info,
> this can avoid unnecessary list addition and deletion operations.
> Removal of the tracers from the dump list is done in function
> free_event_data().
> 
> Suggested-by: Mathieu Poirier 
> Signed-off-by: Leo Yan 
> ---
>  drivers/hwtracing/coresight/coresight-etm-perf.c | 12 +++-
>  drivers/hwtracing/coresight/coresight-etm4x.c| 23 +++
>  drivers/hwtracing/coresight/coresight-etm4x.h| 15 +++
>  3 files changed, 49 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c 
> b/drivers/hwtracing/coresight/coresight-etm-perf.c
> index 8a0ad77..fec779b 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -137,6 +137,12 @@ static void free_event_data(struct work_struct *work)
>   }
>  
>   for_each_cpu(cpu, mask) {
> + struct coresight_device *csdev;
> +
> + csdev = per_cpu(csdev_src, cpu);
> + if (csdev)
> + coresight_kdump_del(csdev);
> +
>   if (!(IS_ERR_OR_NULL(event_data->path[cpu])))
>   coresight_release_path(event_data->path[cpu]);
>   }
> @@ -195,7 +201,7 @@ static void etm_free_aux(void *data)
>  static void *etm_setup_aux(int event_cpu, void **pages,
>  int nr_pages, bool overwrite)
>  {
> - int cpu;
> + int cpu, ret;
>   cpumask_t *mask;
>   struct coresight_device *sink;
>   struct etm_event_data *event_data = NULL;
> @@ -238,6 +244,10 @@ static void *etm_setup_aux(int event_cpu, void **pages,
>   event_data->path[cpu] = coresight_build_path(csdev, sink);
>   if (IS_ERR(event_data->path[cpu]))
>   goto err;
> +
> + ret = coresight_kdump_add(csdev, cpu);

Aren't you missing the configuration for trcconfigr and trctraceidr?

> + if (ret)
> + goto err;
>   }
>  
>   if (!sink_ops(sink)->alloc_buffer)
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c 
> b/drivers/hwtracing/coresight/coresight-etm4x.c
> index cf364a5..cbde398 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> @@ -258,10 +258,19 @@ static int etm4_enable_perf(struct coresight_device 
> *csdev,
>  static int etm4_enable_sysfs(struct coresight_device *csdev)
>  {
>   struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
> + struct etmv4_config *config = &drvdata->config;
> + struct etmv4_metadata *metadata = &drvdata->metadata;
>   int ret;
>  
>   spin_lock(&drvdata->spinlock);
>  
> + /* Update meta data and add into kdump list */
> + metadata->trcconfigr = config->cfg;
> + metadata->trctraceidr = drvdata->trcid;
> +
> + coresight_kdump_add(csdev, drvdata->cpu);
> + coresight_kdump_update(csdev, (char *)metadata, sizeof(*metadata));
> +
>   /*
>* Executing etm4_enable_hw on the cpu whose ETM is being enabled
>* ensures that register writes occur when cpu is powered.
> @@ -384,6 +393,9 @@ static void etm4_disable_sysfs(struct coresight_device 
> *csdev)
>*/
>   smp_call_function_single(drvdata->cpu, etm4_disable_hw, drvdata, 1);
>  
> + /* Delete from kdump list */
> + coresight_kdump_del(csdev);
> +
>   spin_unlock(&drvdata->spinlock);
>   cpus_read_unlock();
>  
&

Re: [PATCH v3 3/6] coresight: Support panic kdump functionality

[Mathieu Poirier]

On Thu, Dec 21, 2017 at 04:20:12PM +0800, Leo Yan wrote:
> After kernel panic happens, coresight has many useful info can be used
> for analysis.  For example, the trace info from ETB RAM can be used to
> check the CPU execution flows before crash.  So we can save the tracing
> data from sink devices, and rely on kdump to save DDR content and uses
> "crash" tool to extract coresight dumping from vmcore file.
> 
> This patch is to add a simple framework to support panic dump
> functionality; it registers panic notifier, and provide the general APIs
> {coresight_kdump_add|coresight_kdump_del} as helper functions so any
> coresight device can add itself into dump list or delete as needed.
> 
> This driver provides helper function coresight_kdump_update() to update
> the dump buffer base address and buffer size.  This function can be used
> by coresight driver, e.g. it can be used to save ETM meta data info at
> runtime and these info can be prepared pre panic happening.
> 
> When kernel panic happens, the notifier iterates dump list and calls
> callback function to dump device specific info.  The panic dump is
> mainly used to dump trace data so we can get to know the execution flow
> before the panic happens.
> 
> Signed-off-by: Leo Yan 
> ---
>  drivers/hwtracing/coresight/Kconfig|   9 ++
>  drivers/hwtracing/coresight/Makefile   |   1 +
>  .../hwtracing/coresight/coresight-panic-kdump.c| 154 
> +
>  drivers/hwtracing/coresight/coresight-priv.h   |  13 ++
>  include/linux/coresight.h  |   7 +
>  5 files changed, 184 insertions(+)
>  create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c
> 
> diff --git a/drivers/hwtracing/coresight/Kconfig 
> b/drivers/hwtracing/coresight/Kconfig
> index ef9cb3c..4812529 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -103,4 +103,13 @@ config CORESIGHT_CPU_DEBUG
> properly, please refer Documentation/trace/coresight-cpu-debug.txt
> for detailed description and the example for usage.
>  
> +config CORESIGHT_PANIC_KDUMP
> + bool "CoreSight Panic Kdump driver"
> + depends on ARM || ARM64

At this time only ETMv4 supports the feature, so it is only ARM64.

> + help
> +   This driver provides panic kdump functionality for CoreSight
> +   devices.  When a kernel panic happen a device supplied callback 
> function
> +   is used to save trace data to memory. From there we rely on kdump to 
> extract
> +   the trace data from kernel dump file.
> +
>  endif
> diff --git a/drivers/hwtracing/coresight/Makefile 
> b/drivers/hwtracing/coresight/Makefile
> index 61db9dd..946fe19 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -18,3 +18,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
>  obj-$(CONFIG_CORESIGHT_DYNAMIC_REPLICATOR) += coresight-dynamic-replicator.o
>  obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
>  obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
> +obj-$(CONFIG_CORESIGHT_PANIC_KDUMP) += coresight-panic-kdump.o
> diff --git a/drivers/hwtracing/coresight/coresight-panic-kdump.c 
> b/drivers/hwtracing/coresight/coresight-panic-kdump.c
> new file mode 100644
> index 000..c21d20b
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-panic-kdump.c
> @@ -0,0 +1,154 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2017 Linaro Limited.
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "coresight-priv.h"
> +
> +typedef void (*coresight_cb_t)(void *data);
> +
> +/**
> + * struct coresight_kdump_node - Node information for dump
> + * @cpu: The cpu this node is affined to.
> + * @csdev:   Handler for coresight device.
> + * @buf: Pointer for dump buffer.
> + * @buf_size:Length of dump buffer.
> + * @list:Hook to the list.
> + */
> +struct coresight_kdump_node {
> + int cpu;
> + struct coresight_device *csdev;
> + char *buf;
> + unsigned int buf_size;
> + struct list_head list;
> +};
> +
> +static DEFINE_SPINLOCK(coresight_kdump_lock);
> +static LIST_HEAD(coresight_kdump_list);
> +static struct notifier_block coresight_kdump_nb;
> +
> +int coresight_kdump_update(struct coresight_device *csdev, char *buf,
> +unsigned int buf_size)
> +{
> + struct coresight_kdump_node *node = csdev->dump_node;
> +
> + if (!node) {
> + dev_err(&csdev->dev, "Failed to update dump node.\n");
> + return -EINVAL;
> + }
> +
> + node->buf = buf;
> + node->buf_size = buf_size;
> + return 0;
> +}
> +
> +int coresight_kdump_add(struct coresight_device *csdev, int cpu)
> +{
> + struct coresight_kdump_node *node;
> + unsigned long flags;
> +
> + node = kzalloc(sizeof(*node), GFP_KERNEL);
> + if (!node)
> 

Re: [PATCH v2] sched/deadline: fix runtime accounting in documentation

[Mathieu Poirier]

Hi Claudio,

On 14 November 2017 at 04:19, Claudio Scordino  wrote:
> Signed-off-by: Claudio Scordino 
> Signed-off-by: Luca Abeni 
> Acked-by: Daniel Bristot de Oliveira 
> CC: Jonathan Corbet 
> CC: "Peter Zijlstra (Intel)" 
> CC: Ingo Molnar 
> CC: linux-doc@vger.kernel.org
> Cc: Tommaso Cucinotta 
> Cc: Mathieu Poirier 
> ---

Please add a short description for your change, even if it is trivial.


>  Documentation/scheduler/sched-deadline.txt | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/scheduler/sched-deadline.txt 
> b/Documentation/scheduler/sched-deadline.txt
> index e89e36e..8ce78f8 100644
> --- a/Documentation/scheduler/sched-deadline.txt
> +++ b/Documentation/scheduler/sched-deadline.txt
> @@ -204,10 +204,17 @@ CONTENTS
>   It does so by decrementing the runtime of the executing task Ti at a pace 
> equal
>   to
>
> -   dq = -max{ Ui, (1 - Uinact) } dt
> +   dq = -max{ Ui / Umax, (1 - Uinact - Uextra) } dt
>
> - where Uinact is the inactive utilization, computed as (this_bq - 
> running_bw),
> - and Ui is the bandwidth of task Ti.
> + where:
> +
> +  - Ui is the bandwidth of task Ti;
> +  - Umax is the maximum reclaimable utilization (subjected to RT throttling
> +limits);
> +  - Uinact is the (per runqueue) inactive utilization, computed as
> +(this_bq - running_bw);
> +  - Uextra is the (per runqueue) extra reclaimable utilization
> +(subjected to RT throttling limits).

I think there would be value in defining 'dq' and 'dt'.  That way
people know exactly what they are and it leaves no room for
interpretation.

Thanks,
Mathieu

>
>
>   Let's now see a trivial example of two deadline tasks with runtime equal
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] doc: coresight: correct usage for disabling idle states

[Mathieu Poirier]

On 19 September 2017 at 21:46, Leo Yan  wrote:
> In the coresight CPU debug document it suggests to use 'echo' command
> to set latency request to /dev/cpu_dma_latency so can disable all CPU
> idle states, but in fact this doesn't work.
>
> This is because when the command 'echo' exits, it releases the device
> node's file descriptor and the kernel release function removes the QoS
> constraint; finally when the command 'echo' finished there have no
> constraint imposed on cpu_dma_latency.
>
> This patch changes to use 'exec' to access '/dev/cpu_dma_latency', the
> command 'exec' can avoid the file descriptor to be closed so we can
> keep the constraint on cpu_dma_latency.
>
> This patch also adds the info for reference docs for PM QoS and cpuidle
> sysfs.
>
> Cc: Jonathan Corbet 
> Cc: Sudeep Holla 
> Reported-by: Kim Phillips 
> Suggested-by: Mathieu Poirier 
> Signed-off-by: Leo Yan 
> ---
>  Documentation/trace/coresight-cpu-debug.txt | 22 +-
>  1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/trace/coresight-cpu-debug.txt 
> b/Documentation/trace/coresight-cpu-debug.txt
> index b3da1f9..2b9b51c 100644
> --- a/Documentation/trace/coresight-cpu-debug.txt
> +++ b/Documentation/trace/coresight-cpu-debug.txt
> @@ -149,11 +149,23 @@ If you want to limit idle states at boot time, you can 
> use "nohlt" or
>
>  At the runtime you can disable idle states with below methods:
>
> -Set latency request to /dev/cpu_dma_latency to disable all CPUs specific idle
> -states (if latency = 0uS then disable all idle states):
> -# echo "what_ever_latency_you_need_in_uS" > /dev/cpu_dma_latency
> -
> -Disable specific CPU's specific idle state:
> +It is possible to disable CPU idle states by way of the PM QoS
> +subsystem, more specifically by using the "/dev/cpu_dma_latency"
> +interface (see Documentation/power/pm_qos_interface.txt for more
> +details).  As specified in the PM QoS documentation the requested
> +parameter will stay in effect until the file descriptor is released.
> +For example:
> +
> +# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
> +...
> +Do some work...
> +...
> +# exec 3<>-
> +
> +The same can also be done from an application program.
> +
> +Disable specific CPU's specific idle state from cpuidle sysfs (see
> +Documentation/cpuidle/sysfs.txt):
>  # echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
>

Applied.

Thanks,
Mathieu

>
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] doc: coresight: correct usage for disabling idle states

[Mathieu Poirier]

On 15 September 2017 at 04:16, Leo Yan  wrote:
> In the coresight CPU debug document it suggests to use 'echo' command
> to set latency request to /dev/cpu_dma_latency so can disable all CPU
> idle states, but in fact this doesn't work.
>
> This is because when the command 'echo' exits, it releases the device
> node's file descriptor and the kernel release function removes the QoS
> constraint; finally when the command 'echo' finished there have no
> constraint imposed on cpu_dma_latency.
>
> This patch changes to use 'exec' to access '/dev/cpu_dma_latency', the
> command 'exec' can avoid the file descriptor to be closed so we can
> keep the constraint on cpu_dma_latency.
>
> This patch also adds the info for reference docs for PM QoS and cpuidle
> sysfs.
>
> Cc: Jonathan Corbet 
> Cc: Mathieu Poirier 
> Cc: Sudeep Holla 
> Reported-by: Kim Phillips 
> Signed-off-by: Leo Yan 
> ---
>  Documentation/trace/coresight-cpu-debug.txt | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/trace/coresight-cpu-debug.txt 
> b/Documentation/trace/coresight-cpu-debug.txt
> index b3da1f9..205ff95 100644
> --- a/Documentation/trace/coresight-cpu-debug.txt
> +++ b/Documentation/trace/coresight-cpu-debug.txt
> @@ -149,11 +149,15 @@ If you want to limit idle states at boot time, you can 
> use "nohlt" or
>
>  At the runtime you can disable idle states with below methods:
>
> -Set latency request to /dev/cpu_dma_latency to disable all CPUs specific idle
> -states (if latency = 0uS then disable all idle states):
> -# echo "what_ever_latency_you_need_in_uS" > /dev/cpu_dma_latency
> -
> -Disable specific CPU's specific idle state:
> +By using PM QoS interface '/dev/cpu_dma_latency', we can set latency
> +constraint to disable all CPUs specific idle states (see
> +Documentation/power/pm_qos_interface.txt, section 'From user mode');
> +below is one example to set latency constraint to '', it is
> +hexadecimal format with microsecond unit:
> +# exec 3<> /dev/cpu_dma_latency; echo '' >&3

Since doing echo '' >&3 or simply echo 0 >&3 yields the same
result I would go for the latter.  I also think it is important to
specify that using an "echo" command without holding the file open
won't give the desired result.  I would reformat your paragraph as
follow:

>>> Begin >>>

It is possible to disable CPU idle states by way of the PM QoS
subsystem, more specifically by using the "/dev/cpu_dma_latency"
interface (see Documentation/power/pm_qos_interface.txt for more
details).  As specified in the PM QoS documentation the requested
parameter will stay in effect until the file descriptor is released.
For example:

# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
...
Do some work...
...
# exec 3<>-

The same can also be done from an application program.

<<< End <<<


> +
> +Disable specific CPU's specific idle state from cpuidle sysfs (see
> +Documentation/cpuidle/sysfs.txt):
>  # echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
>
>
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v13 8/9] arm64: dts: hi6220: register debug module

[Mathieu Poirier]

On 5 June 2017 at 02:33, Wei Xu  wrote:
> Hi Leo,
>
> On 2017/5/25 16:57, Leo Yan wrote:
>> Bind debug module driver for Hi6220.
>>
>> Reviewed-by: Mathieu Poirier 
>> Signed-off-by: Leo Yan 
>
> Thanks!
> Fine to me.
> Acked-by: Wei Xu 
>
> Hi Mathieu,
>
> Can you help to pick up this patch as well?
> Thanks!

Sure - I'll add this to my tree.

>
> Best Regards,
> Wei
>
>> ---
>>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 64 
>> +++
>>  1 file changed, 64 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
>> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> index 1e5129b..21805b9 100644
>> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> @@ -916,5 +916,69 @@
>>   };
>>   };
>>   };
>> +
>> + debug@f659 {
>> + compatible = "arm,coresight-cpu-debug","arm,primecell";
>> + reg = <0 0xf659 0 0x1000>;
>> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
>> + clock-names = "apb_pclk";
>> + cpu = <&cpu0>;
>> + };
>> +
>> + debug@f6592000 {
>> + compatible = "arm,coresight-cpu-debug","arm,primecell";
>> + reg = <0 0xf6592000 0 0x1000>;
>> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
>> + clock-names = "apb_pclk";
>> + cpu = <&cpu1>;
>> + };
>> +
>> + debug@f6594000 {
>> + compatible = "arm,coresight-cpu-debug","arm,primecell";
>> + reg = <0 0xf6594000 0 0x1000>;
>> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
>> + clock-names = "apb_pclk";
>> + cpu = <&cpu2>;
>> + };
>> +
>> + debug@f6596000 {
>> + compatible = "arm,coresight-cpu-debug","arm,primecell";
>> + reg = <0 0xf6596000 0 0x1000>;
>> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
>> + clock-names = "apb_pclk";
>> + cpu = <&cpu3>;
>> + };
>> +
>> + debug@f65d {
>> + compatible = "arm,coresight-cpu-debug","arm,primecell";
>> + reg = <0 0xf65d 0 0x1000>;
>> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
>> + clock-names = "apb_pclk";
>> + cpu = <&cpu4>;
>> + };
>> +
>> + debug@f65d2000 {
>> + compatible = "arm,coresight-cpu-debug","arm,primecell";
>> + reg = <0 0xf65d2000 0 0x1000>;
>> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
>> + clock-names = "apb_pclk";
>> + cpu = <&cpu5>;
>> + };
>> +
>> + debug@f65d4000 {
>> + compatible = "arm,coresight-cpu-debug","arm,primecell";
>> + reg = <0 0xf65d4000 0 0x1000>;
>> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
>> + clock-names = "apb_pclk";
>> + cpu = <&cpu6>;
>> + };
>> +
>> + debug@f65d6000 {
>> + compatible = "arm,coresight-cpu-debug","arm,primecell";
>> + reg = <0 0xf65d6000 0 0x1000>;
>> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
>> + clock-names = "apb_pclk";
>> + cpu = <&cpu7>;
>> + };
>>   };
>>  };
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v13 0/9] coresight: enable debug module

[Mathieu Poirier]

itialization
>   code to distinguish hardware implementation features, refactored
>   flow for forcing CPU powered up, supported pm_runtime operations.
> * Added one new doc file: Documentation/trace/coresight-cpu-debug.txt,
>   which is used to describe detailed info for implementation, clock
>   and power domain impaction on debug module, and exmaples for common
>   usage.
> * Removed "idle constraints" from debug driver.
>
> Changes from v4:
> * This version is mainly credit to ARM colleagues many contribution
>   ideas for better quality (Thanks a lot Suzuki, Mike and Sudeep!).
> * According to Suzuki suggestion, refined debug module driver to avoid
>   memory leak for drvdata struct, handle PCSAMPLE_MODE=1, use flag
>   drvdata.pc_has_offset to indicate if PCSR has offset, minor fixes.
> * According to Mathieu suggestion, refined dt binding description.
> * Changed driver to support module mode;
> * According to Mike suggestion and very appreciate the pseudo code,
>   added support to force CPU powered up with register EDPRCR;
> * According to discussions, added command line and debugfs nodes to
>   support enabling debugging for boot time, or later can dynamically
>   enable/disable debugging by debugfs.
> * According to Rob Herring suggestion, one minor fixes in DT binding.
> * According to Stephen Boyd suggestion, add const quality to structure
>   device_node. And used use of_cpu_device_node_get() to replace
>   of_get_cpu_node() in patch 0003.
>
> Changes from v3:
> * Added Suzuki K Poulose's patch to fix issue for the func
>   of_get_coresight_platform_data() doesn't properly drop the reference
>   to the CPU node pointer.
> * According to Suzuki suggestion, added code to handl the corner case
>   for ARMv8 CPU with aarch32 mode.
> * According to Suzuki suggestion, changed compatible string to
>   "arm,coresight-cpu-debug".
> * According to Mathieu suggestion, added "power-domains" as optional
>   properties.
>
> Changes from v2:
> * According to Mathieu Poirier suggestion, applied some minor fixes.
> * Added two extra patches for enabling debug module on Hikey.
>
> Changes from v1:
> * According to Mike Leach suggestion, removed the binding for debug
>   module clocks which have been directly provided by CPU clocks.
> * According to Mathieu Poirier suggestion, added function
>   of_coresight_get_cpu() and some minor refactors for debug module
>   driver.
>
> Changes from RFC:
> * According to Mike Leach suggestion, added check for EDPRSR to avoid
>   lockup; added supporting EDVIDSR and EDCIDSR registers.
> * According to Mark Rutland and Mathieu Poirier suggestion, rewrote
>   the documentation for DT binding.
> * According to Mark and Mathieu suggestion, refined debug driver.
>
> Leo Yan (8):
>   coresight: bindings for CPU debug module
>   doc: Add documentation for Coresight CPU debug
>   doc: Add coresight_cpu_debug.enable to kernel-parameters.txt
>   MAINTAINERS: update file entries for Coresight subsystem
>   coresight: refactor with function of_coresight_get_cpu
>   coresight: add support for CPU debug module
>   arm64: dts: hi6220: register debug module
>   arm64: dts: qcom: msm8916: Add debug unit
>
> Suzuki K Poulose (1):
>   coresight: of_get_coresight_platform_data: Add missing of_node_put
>
>  Documentation/admin-guide/kernel-parameters.txt|   7 +
>  .../bindings/arm/coresight-cpu-debug.txt   |  49 ++
>  Documentation/trace/coresight-cpu-debug.txt| 175 ++
>  MAINTAINERS|   2 +
>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  64 ++
>  arch/arm64/boot/dts/qcom/msm8916.dtsi  |  32 +
>  drivers/hwtracing/coresight/Kconfig|  14 +
>  drivers/hwtracing/coresight/Makefile   |   1 +
>  drivers/hwtracing/coresight/coresight-cpu-debug.c  | 700 
> +
>  drivers/hwtracing/coresight/of_coresight.c |  40 +-
>  include/linux/coresight.h  |   3 +
>  11 files changed, 1075 insertions(+), 12 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
>  create mode 100644 Documentation/trace/coresight-cpu-debug.txt
>  create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c
>
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v11 7/9] coresight: add support for CPU debug module

[Mathieu Poirier]

On 23 May 2017 at 08:16, Leo Yan  wrote:
> Coresight includes debug module and usually the module connects with CPU
> debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
> description for related info in "Part H: External Debug".
>
> Chapter H7 "The Sample-based Profiling Extension" introduces several
> sampling registers, e.g. we can check program counter value with
> combined CPU exception level, secure state, etc. So this is helpful for
> analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
> loop with IRQ disabled. In this case the CPU cannot switch context and
> handle any interrupt (including IPIs), as the result it cannot handle
> SMP call for stack dump.
>
> This patch is to enable coresight debug module, so firstly this driver
> is to bind apb clock for debug module and this is to ensure the debug
> module can be accessed from program or external debugger. And the driver
> uses sample-based registers for debug purpose, e.g. when system triggers
> panic, the driver will dump program counter and combined context
> registers (EDCIDSR, EDVIDSR); by parsing context registers so can
> quickly get to know CPU secure state, exception level, etc.
>
> Some of the debug module registers are located in CPU power domain, so
> this requires the CPU power domain stays on when access related debug
> registers, but the power management for CPU power domain is quite
> dependent on SoC integration for power management. For the platforms
> which with sane power controller implementations, this driver follows
> the method to set EDPRCR to try to pull the CPU out of low power state
> and then set 'no power down request' bit so the CPU has no chance to
> lose power.
>
> If the SoC has not followed up this design well for power management
> controller, the user should use the command line parameter or sysfs
> to constrain all or partial idle states to ensure the CPU power
> domain is enabled and access coresight CPU debug component safely.
>
> Reviewed-by: Suzuki K Poulose 
> Signed-off-by: Leo Yan 
> ---
>  drivers/hwtracing/coresight/Kconfig   |  14 +
>  drivers/hwtracing/coresight/Makefile  |   1 +
>  drivers/hwtracing/coresight/coresight-cpu-debug.c | 696 
> ++
>  3 files changed, 711 insertions(+)
>  create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c
>
> diff --git a/drivers/hwtracing/coresight/Kconfig 
> b/drivers/hwtracing/coresight/Kconfig
> index 130cb21..8d55d6d 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -89,4 +89,18 @@ config CORESIGHT_STM
>   logging useful software events or data coming from various entities
>   in the system, possibly running different OSs
>
> +config CORESIGHT_CPU_DEBUG
> +   tristate "CoreSight CPU Debug driver"
> +   depends on ARM || ARM64
> +   depends on DEBUG_FS
> +   help
> + This driver provides support for coresight debugging module. This
> + is primarily used to dump sample-based profiling registers when
> + system triggers panic, the driver will parse context registers so
> + can quickly get to know program counter (PC), secure state,
> + exception level, etc. Before use debugging functionality, platform
> + needs to ensure the clock domain and power domain are enabled
> + properly, please refer Documentation/trace/coresight-cpu-debug.txt
> + for detailed description and the example for usage.
> +
>  endif
> diff --git a/drivers/hwtracing/coresight/Makefile 
> b/drivers/hwtracing/coresight/Makefile
> index af480d9..433d590 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
> coresight-etm4x-sysfs.o
>  obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
>  obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
> +obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
> diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
> b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> new file mode 100644
> index 000..3589174
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> @@ -0,0 +1,696 @@
> +/*
> + * Copyright (c) 2017 Linaro Limited. All rights reserved.
> + *
> + * Author: Leo Yan 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public Licens

Re: [PATCH v11 9/9] arm64: dts: qcom: msm8916: Add debug unit

[Mathieu Poirier]

On 23 May 2017 at 08:16, Leo Yan  wrote:
> Add debug unit on Qualcomm msm8916 based platforms, including the
> DragonBoard 410c board.
>
> Reviewed-by: Mathieu Poirier 
> Signed-off-by: Leo Yan 

Andy and David,

Would you mind taking a look a this when you have a minute?  If it's
fine with you we can make this go through my tree with the rest of the
driver.

Regards,
Mathieu


> ---
>  arch/arm64/boot/dts/qcom/msm8916.dtsi | 32 
>  1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index ab30939..17691ab 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -1116,6 +1116,38 @@
> };
> };
>
> +   debug@85 {
> +   compatible = 
> "arm,coresight-cpu-debug","arm,primecell";
> +   reg = <0x85 0x1000>;
> +   clocks = <&rpmcc RPM_QDSS_CLK>;
> +   clock-names = "apb_pclk";
> +   cpu = <&CPU0>;
> +   };
> +
> +   debug@852000 {
> +   compatible = 
> "arm,coresight-cpu-debug","arm,primecell";
> +   reg = <0x852000 0x1000>;
> +   clocks = <&rpmcc RPM_QDSS_CLK>;
> +   clock-names = "apb_pclk";
> +   cpu = <&CPU1>;
> +   };
> +
> +   debug@854000 {
> +   compatible = 
> "arm,coresight-cpu-debug","arm,primecell";
> +   reg = <0x854000 0x1000>;
> +   clocks = <&rpmcc RPM_QDSS_CLK>;
> +   clock-names = "apb_pclk";
> +   cpu = <&CPU2>;
> +   };
> +
> +   debug@856000 {
> +   compatible = 
> "arm,coresight-cpu-debug","arm,primecell";
> +   reg = <0x856000 0x1000>;
> +   clocks = <&rpmcc RPM_QDSS_CLK>;
> +   clock-names = "apb_pclk";
> +   cpu = <&CPU3>;
> +   };
> +
> etm@85c000 {
> compatible = "arm,coresight-etm4x", "arm,primecell";
> reg = <0x85c000 0x1000>;
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v11 8/9] arm64: dts: hi6220: register debug module

[Mathieu Poirier]

On 23 May 2017 at 08:16, Leo Yan  wrote:
> Bind debug module driver for Hi6220.
>
> Reviewed-by: Mathieu Poirier 
> Signed-off-by: Leo Yan 

Wei and Mark,

I think it makes sense to have this go through the coresight tree
along with the rest of the driver.  Please have a look and let me
know.

Thanks,
Mathieu

> ---
>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 64 
> +++
>  1 file changed, 64 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 1e5129b..21805b9 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -916,5 +916,69 @@
> };
> };
> };
> +
> +   debug@f659 {
> +   compatible = 
> "arm,coresight-cpu-debug","arm,primecell";
> +   reg = <0 0xf659 0 0x1000>;
> +   clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> +   clock-names = "apb_pclk";
> +   cpu = <&cpu0>;
> +   };
> +
> +   debug@f6592000 {
> +   compatible = 
> "arm,coresight-cpu-debug","arm,primecell";
> +   reg = <0 0xf6592000 0 0x1000>;
> +   clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> +   clock-names = "apb_pclk";
> +   cpu = <&cpu1>;
> +   };
> +
> +   debug@f6594000 {
> +   compatible = 
> "arm,coresight-cpu-debug","arm,primecell";
> +   reg = <0 0xf6594000 0 0x1000>;
> +   clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> +   clock-names = "apb_pclk";
> +   cpu = <&cpu2>;
> +   };
> +
> +   debug@f6596000 {
> +   compatible = 
> "arm,coresight-cpu-debug","arm,primecell";
> +   reg = <0 0xf6596000 0 0x1000>;
> +   clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> +   clock-names = "apb_pclk";
> +   cpu = <&cpu3>;
> +   };
> +
> +   debug@f65d {
> +   compatible = 
> "arm,coresight-cpu-debug","arm,primecell";
> +   reg = <0 0xf65d 0 0x1000>;
> +   clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> +   clock-names = "apb_pclk";
> +   cpu = <&cpu4>;
> +   };
> +
> +   debug@f65d2000 {
> +   compatible = 
> "arm,coresight-cpu-debug","arm,primecell";
> +   reg = <0 0xf65d2000 0 0x1000>;
> +   clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> +   clock-names = "apb_pclk";
> +   cpu = <&cpu5>;
> +   };
> +
> +   debug@f65d4000 {
> +   compatible = 
> "arm,coresight-cpu-debug","arm,primecell";
> +   reg = <0 0xf65d4000 0 0x1000>;
> +   clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> +   clock-names = "apb_pclk";
> +   cpu = <&cpu6>;
> +   };
> +
> +   debug@f65d6000 {
> +   compatible = 
> "arm,coresight-cpu-debug","arm,primecell";
> +   reg = <0 0xf65d6000 0 0x1000>;
> +   clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> +   clock-names = "apb_pclk";
> +   cpu = <&cpu7>;
> +   };
> };
>  };
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 4/9] MAINTAINERS: update file entries for Coresight subsystem

[Mathieu Poirier]

On Tue, May 09, 2017 at 10:49:57AM +0800, Leo Yan wrote:
> Update document file entries for Coresight debug module.
> 
> Signed-off-by: Leo Yan 

Reviewed-by: Mathieu Poirier 

> ---
>  MAINTAINERS | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b948dfa..a4b1f60 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1191,7 +1191,9 @@ L:  linux-arm-ker...@lists.infradead.org (moderated 
> for non-subscribers)
>  S:   Maintained
>  F:   drivers/hwtracing/coresight/*
>  F:   Documentation/trace/coresight.txt
> +F:   Documentation/trace/coresight-cpu-debug.txt
>  F:   Documentation/devicetree/bindings/arm/coresight.txt
> +F:   Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
>  F:   Documentation/ABI/testing/sysfs-bus-coresight-devices-*
>  F:   tools/perf/arch/arm/util/pmu.c
>  F:   tools/perf/arch/arm/util/auxtrace.c
> -- 
> 2.7.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 3/9] doc: Add coresight_cpu_debug.enable to kernel-parameters.txt

[Mathieu Poirier]

On Tue, May 09, 2017 at 10:49:56AM +0800, Leo Yan wrote:
> Add coresight_cpu_debug.enable to kernel-parameters.txt, this flag is
> used to enable/disable the CPU sampling based debugging.
> 
> Signed-off-by: Leo Yan 

Reviewed-by: Mathieu Poirier 

> ---
>  Documentation/admin-guide/kernel-parameters.txt | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index e4c9e0e..010ae02 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -649,6 +649,13 @@
>   /proc//coredump_filter.
>   See also Documentation/filesystems/proc.txt.
>  
> + coresight_cpu_debug.enable
> + [ARM,ARM64]
> + Format: 
> + Enable/disable the CPU sampling based debugging.
> + 0: default value, disable debugging
> + 1: enable debugging at boot time
> +
>   cpuidle.off=1   [CPU_IDLE]
>   disable the cpuidle sub-system
>  
> -- 
> 2.7.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 2/9] doc: Add documentation for Coresight CPU debug

[Mathieu Poirier]

On Tue, May 09, 2017 at 10:49:55AM +0800, Leo Yan wrote:
> Add detailed documentation for Coresight CPU debug driver, which
> contains the info for driver implementation, Mike Leach excellent
> summary for "clock and power domain". At the end some examples on how
> to enable the debugging functionality are provided.
> 
> Suggested-by: Mike Leach 
> Signed-off-by: Leo Yan 

Reviewed-by: Mathieu Poirier 

> ---
>  Documentation/trace/coresight-cpu-debug.txt | 174 
> 
>  1 file changed, 174 insertions(+)
>  create mode 100644 Documentation/trace/coresight-cpu-debug.txt
> 
> diff --git a/Documentation/trace/coresight-cpu-debug.txt 
> b/Documentation/trace/coresight-cpu-debug.txt
> new file mode 100644
> index 000..0426d50
> --- /dev/null
> +++ b/Documentation/trace/coresight-cpu-debug.txt
> @@ -0,0 +1,174 @@
> + Coresight CPU Debug Module
> + ==
> +
> +   Author:   Leo Yan 
> +   Date: April 5th, 2017
> +
> +Introduction
> +
> +
> +Coresight CPU debug module is defined in ARMv8-a architecture reference 
> manual
> +(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate
> +debug module and it is mainly used for two modes: self-hosted debug and
> +external debug. Usually the external debug mode is well known as the external
> +debugger connects with SoC from JTAG port; on the other hand the program can
> +explore debugging method which rely on self-hosted debug mode, this document
> +is to focus on this part.
> +
> +The debug module provides sample-based profiling extension, which can be used
> +to sample CPU program counter, secure state and exception level, etc; usually
> +every CPU has one dedicated debug module to be connected. Based on 
> self-hosted
> +debug mechanism, Linux kernel can access these related registers from mmio
> +region when the kernel panic happens. The callback notifier for kernel panic
> +will dump related registers for every CPU; finally this is good for assistant
> +analysis for panic.
> +
> +
> +Implementation
> +--
> +
> +- During driver registration, use EDDEVID and EDDEVID1 two device ID
> +  registers to decide if sample-based profiling is implemented or not. On 
> some
> +  platforms this hardware feature is fully or partialy implemented; and if
> +  this feature is not supported then registration will fail.
> +
> +- When write this doc, the debug driver mainly relies on three sampling
> +  registers. The kernel panic callback notifier gathers info from EDPCSR
> +  EDVIDSR and EDCIDSR; from EDPCSR we can get program counter, EDVIDSR has
> +  information for secure state, exception level, bit width, etc; EDCIDSR is
> +  context ID value which contains the sampled value of CONTEXTIDR_EL1.
> +
> +- The driver supports CPU running mode with either AArch64 or AArch32. The
> +  registers naming convention is a bit different between them, AArch64 uses
> +  'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses
> +  'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to
> +  use AArch64 naming convention.
> +
> +- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different
> +  register bits definition. So the driver consolidates two difference:
> +
> +  If PCSROffset=0b, on ARMv8-a the feature of EDPCSR is not implemented;
> +  but ARMv7-a defines "PCSR samples are offset by a value that depends on the
> +  instruction set state". For ARMv7-a, the driver checks furthermore if CPU
> +  runs with ARM or thumb instruction set and calibrate PCSR value, the
> +  detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter
> +  C11.11.34 "DBGPCSR, Program Counter Sampling Register".
> +
> +  If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have
> +  no offset applied and do not sample the instruction set state in AArch32
> +  state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates
> +  in AArch32 state, EDPCSR is not sampled; when the CPU operates in AArch64
> +  state EDPCSR is sampled and no offset are applied.
> +
> +
> +Clock and power domain
> +--
> +
> +Before accessing debug registers, we should ensure the clock and power domain
> +have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
> +Debug registers', the debug registers are spread into two domains: the debug
> +domain and the CPU domain.
> +
> +   

Re: [PATCH v9 9/9] arm64: dts: qcom: msm8916: Add debug unit

[Mathieu Poirier]

On Tue, May 09, 2017 at 10:50:02AM +0800, Leo Yan wrote:
> Add debug unit on Qualcomm msm8916 based platforms, including the
> DragonBoard 410c board.
> 
> Signed-off-by: Leo Yan 

Reviewed-by: Mathieu Poirier 

> ---
>  arch/arm64/boot/dts/qcom/msm8916.dtsi | 32 
>  1 file changed, 32 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index 68a8e67..3af814b 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -1104,6 +1104,38 @@
>   };
>   };
>  
> + debug@85 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0x85 0x1000>;
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&CPU0>;
> + };
> +
> + debug@852000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0x852000 0x1000>;
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&CPU1>;
> + };
> +
> + debug@854000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0x854000 0x1000>;
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&CPU2>;
> + };
> +
> + debug@856000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0x856000 0x1000>;
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&CPU3>;
> + };
> +
>   etm@85c000 {
>   compatible = "arm,coresight-etm4x", "arm,primecell";
>   reg = <0x85c000 0x1000>;
> -- 
> 2.7.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 8/9] arm64: dts: hi6220: register debug module

[Mathieu Poirier]

On Tue, May 09, 2017 at 10:50:01AM +0800, Leo Yan wrote:
> Bind debug module driver for Hi6220.
> 
> Signed-off-by: Leo Yan 

Reviewed-by: Mathieu Poirier 

> ---
>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 64 
> +++
>  1 file changed, 64 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 470461d..467aa15 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -913,5 +913,69 @@
>   };
>   };
>   };
> +
> + debug@f659 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf659 0 0x1000>;
> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&cpu0>;
> + };
> +
> + debug@f6592000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf6592000 0 0x1000>;
> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&cpu1>;
> + };
> +
> + debug@f6594000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf6594000 0 0x1000>;
> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&cpu2>;
> + };
> +
> + debug@f6596000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf6596000 0 0x1000>;
> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&cpu3>;
> + };
> +
> + debug@f65d {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf65d 0 0x1000>;
> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&cpu4>;
> + };
> +
> + debug@f65d2000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf65d2000 0 0x1000>;
> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&cpu5>;
> + };
> +
> + debug@f65d4000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf65d4000 0 0x1000>;
> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&cpu6>;
> + };
> +
> + debug@f65d6000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf65d6000 0 0x1000>;
> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&cpu7>;
> + };
>   };
>  };
> -- 
> 2.7.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 7/9] coresight: add support for CPU debug module

[Mathieu Poirier]

On Tue, May 09, 2017 at 10:50:00AM +0800, Leo Yan wrote:
> Coresight includes debug module and usually the module connects with CPU
> debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
> description for related info in "Part H: External Debug".
> 
> Chapter H7 "The Sample-based Profiling Extension" introduces several
> sampling registers, e.g. we can check program counter value with
> combined CPU exception level, secure state, etc. So this is helpful for
> analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
> loop with IRQ disabled. In this case the CPU cannot switch context and
> handle any interrupt (including IPIs), as the result it cannot handle
> SMP call for stack dump.
> 
> This patch is to enable coresight debug module, so firstly this driver
> is to bind apb clock for debug module and this is to ensure the debug
> module can be accessed from program or external debugger. And the driver
> uses sample-based registers for debug purpose, e.g. when system triggers
> panic, the driver will dump program counter and combined context
> registers (EDCIDSR, EDVIDSR); by parsing context registers so can
> quickly get to know CPU secure state, exception level, etc.
> 
> Some of the debug module registers are located in CPU power domain, so
> this requires the CPU power domain stays on when access related debug
> registers, but the power management for CPU power domain is quite
> dependent on SoC integration for power management. For the platforms
> which with sane power controller implementations, this driver follows
> the method to set EDPRCR to try to pull the CPU out of low power state
> and then set 'no power down request' bit so the CPU has no chance to
> lose power.
> 
> If the SoC has not followed up this design well for power management
> controller, the user should use the command line parameter or sysfs
> to constrain all or partial idle states to ensure the CPU power
> domain is enabled and access coresight CPU debug component safely.
> 
> Signed-off-by: Leo Yan 
> ---
>  drivers/hwtracing/coresight/Kconfig   |  14 +
>  drivers/hwtracing/coresight/Makefile  |   1 +
>  drivers/hwtracing/coresight/coresight-cpu-debug.c | 693 
> ++
>  3 files changed, 708 insertions(+)
>  create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c
> 
> diff --git a/drivers/hwtracing/coresight/Kconfig 
> b/drivers/hwtracing/coresight/Kconfig
> index 130cb21..8d55d6d 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -89,4 +89,18 @@ config CORESIGHT_STM
> logging useful software events or data coming from various entities
> in the system, possibly running different OSs
>  
> +config CORESIGHT_CPU_DEBUG
> + tristate "CoreSight CPU Debug driver"
> + depends on ARM || ARM64
> + depends on DEBUG_FS
> + help
> +   This driver provides support for coresight debugging module. This
> +   is primarily used to dump sample-based profiling registers when
> +   system triggers panic, the driver will parse context registers so
> +   can quickly get to know program counter (PC), secure state,
> +   exception level, etc. Before use debugging functionality, platform
> +   needs to ensure the clock domain and power domain are enabled
> +   properly, please refer Documentation/trace/coresight-cpu-debug.txt
> +   for detailed description and the example for usage.
> +
>  endif
> diff --git a/drivers/hwtracing/coresight/Makefile 
> b/drivers/hwtracing/coresight/Makefile
> index af480d9..433d590 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
>   coresight-etm4x-sysfs.o
>  obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
>  obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
> +obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
> diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
> b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> new file mode 100644
> index 000..ab12ec1
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> @@ -0,0 +1,693 @@
> +/*
> + * Copyright (c) 2017 Linaro Limited. All rights reserved.
> + *
> + * Author: Leo Yan 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If

Re: [PATCH v8 5/7] coresight: add support for CPU debug module

[Mathieu Poirier]

On 5 May 2017 at 09:04, Sudeep Holla  wrote:
>
>
> On 05/05/17 15:48, Mathieu Poirier wrote:
>> On Fri, May 05, 2017 at 02:55:17PM +0100, Sudeep Holla wrote:
>
> [...]
>
>>>
>>> Just curious as why this is not registered under coresight bus using
>>> coresight_register ? It would be good to group all the coresight devices
>>> under that bus if possible.
>>
>> The only thing this driver has in common with the coresight framework is the
>> name, everything else is completely different.  Coupling them together 
>> (because
>> of the name) would introduce a lot of hacks and make the code unintelligible.
>>
>
> I guessed so from the quick glance at it as it needs descriptors with
> notion of source, sink and links to register. However I felt odd to not
> group under the same "coresight" bus. As someone with least knowledge
> on coresight, I would check under "sys/bus/coresight" to check available
> devices on the system.

2 years ago when implementing the coresight framework, using
"coresight" sounded like a logical choice but in hindsight it probably
should have been something like coresight-hat (HW Assisted Tracing).
That would have been a better representation of the reality, i.e the
term "coresight" being an umbrella for many kind of technology.  Leo
has done the right thing here with "coresight-cpu-debug".

>
> Anyways that's just my thoughts though I agree with you. It may need
> more refactoring to support that and it will look hackish if we try to
> do that with the code as it stands.
>
> --
> Regards,
> Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 5/7] coresight: add support for CPU debug module

[Mathieu Poirier]

On Fri, May 05, 2017 at 02:55:17PM +0100, Sudeep Holla wrote:
> 
> 
> On 02/05/17 11:08, Leo Yan wrote:
> > Coresight includes debug module and usually the module connects with CPU
> > debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
> > description for related info in "Part H: External Debug".
> > 
> > Chapter H7 "The Sample-based Profiling Extension" introduces several
> > sampling registers, e.g. we can check program counter value with
> > combined CPU exception level, secure state, etc. So this is helpful for
> > analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
> > loop with IRQ disabled. In this case the CPU cannot switch context and
> > handle any interrupt (including IPIs), as the result it cannot handle
> > SMP call for stack dump.
> > 
> > This patch is to enable coresight debug module, so firstly this driver
> > is to bind apb clock for debug module and this is to ensure the debug
> > module can be accessed from program or external debugger. And the driver
> > uses sample-based registers for debug purpose, e.g. when system triggers
> > panic, the driver will dump program counter and combined context
> > registers (EDCIDSR, EDVIDSR); by parsing context registers so can
> > quickly get to know CPU secure state, exception level, etc.
> > 
> > Some of the debug module registers are located in CPU power domain, so
> > this requires the CPU power domain stays on when access related debug
> > registers, but the power management for CPU power domain is quite
> > dependent on SoC integration for power management. For the platforms
> > which with sane power controller implementations, this driver follows
> > the method to set EDPRCR to try to pull the CPU out of low power state
> > and then set 'no power down request' bit so the CPU has no chance to
> > lose power.
> > 
> > If the SoC has not followed up this design well for power management
> > controller, the user should use the command line parameter or sysfs
> > to constrain all or partial idle states to ensure the CPU power
> > domain is enabled and access coresight CPU debug component safely.
> > 
> > Signed-off-by: Leo Yan 
> > ---
> >  drivers/hwtracing/coresight/Kconfig   |  14 +
> >  drivers/hwtracing/coresight/Makefile  |   1 +
> >  drivers/hwtracing/coresight/coresight-cpu-debug.c | 670 
> > ++
> >  3 files changed, 685 insertions(+)
> >  create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c
> > 
> > diff --git a/drivers/hwtracing/coresight/Kconfig 
> > b/drivers/hwtracing/coresight/Kconfig
> > index 130cb21..8d55d6d 100644
> > --- a/drivers/hwtracing/coresight/Kconfig
> > +++ b/drivers/hwtracing/coresight/Kconfig
> > @@ -89,4 +89,18 @@ config CORESIGHT_STM
> >   logging useful software events or data coming from various entities
> >   in the system, possibly running different OSs
> >  
> > +config CORESIGHT_CPU_DEBUG
> > +   tristate "CoreSight CPU Debug driver"
> > +   depends on ARM || ARM64
> > +   depends on DEBUG_FS
> > +   help
> > + This driver provides support for coresight debugging module. This
> > + is primarily used to dump sample-based profiling registers when
> > + system triggers panic, the driver will parse context registers so
> > + can quickly get to know program counter (PC), secure state,
> > + exception level, etc. Before use debugging functionality, platform
> > + needs to ensure the clock domain and power domain are enabled
> > + properly, please refer Documentation/trace/coresight-cpu-debug.txt
> > + for detailed description and the example for usage.
> > +
> >  endif
> > diff --git a/drivers/hwtracing/coresight/Makefile 
> > b/drivers/hwtracing/coresight/Makefile
> > index af480d9..433d590 100644
> > --- a/drivers/hwtracing/coresight/Makefile
> > +++ b/drivers/hwtracing/coresight/Makefile
> > @@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o 
> > \
> > coresight-etm4x-sysfs.o
> >  obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
> >  obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
> > +obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
> > diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
> > b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> > new file mode 100644
> > index 000..b77456d
> > --- /dev/null
> > +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> 
> [...]
> 
> > +static int debug_probe(struct amba_device *adev, const struct amba_id *id)
> > +{
> > +   void __iomem *base;
> > +   struct device *dev = &adev->dev;
> > +   struct debug_drvdata *drvdata;
> > +   struct resource *res = &adev->res;
> > +   struct device_node *np = adev->dev.of_node;
> > +   int ret;
> > +
> > +   drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> > +   if (!drvdata)
> > +   return -ENOMEM;
> > +
> > +   drvdata->cpu = np ? of_coresight_get_cpu(np) : 0;
> > 

Re: [PATCH v8 2/7] doc: Add documentation for Coresight CPU debug

[Mathieu Poirier]

On Tue, May 02, 2017 at 06:08:32PM +0800, Leo Yan wrote:
> Update kernel-parameters.txt to add new parameter:
> coresight_cpu_debug.enable is a knob to enable debugging at boot time.
> 
> Add detailed documentation, which contains the implementation, Mike
> Leach excellent summary for "clock and power domain". At the end some
> examples on how to enable the debugging functionality are provided.
> 
> Suggested-by: Mike Leach 
> Signed-off-by: Leo Yan 
> ---
>  Documentation/admin-guide/kernel-parameters.txt |   7 +
>  Documentation/trace/coresight-cpu-debug.txt | 174 
> 

Please add coresight-cpu-debug.txt to the list of maintained files in
MAINTAINERS.  Moreover I'm pretty sure John will want you to split this patch in
two, i.e one patch for kernel-parameters.txt and another for
coresight-cpu-debug.txt

>  2 files changed, 181 insertions(+)
>  create mode 100644 Documentation/trace/coresight-cpu-debug.txt
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index facc20a..cf90146 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -650,6 +650,13 @@
>   /proc//coredump_filter.
>   See also Documentation/filesystems/proc.txt.
>  
> + coresight_cpu_debug.enable
> + [ARM,ARM64]
> + Format: 
> + Enable/disable the CPU sampling based debugging.
> + 0: default value, disable debugging
> + 1: enable debugging at boot time
> +
>   cpuidle.off=1   [CPU_IDLE]
>   disable the cpuidle sub-system
>  
> diff --git a/Documentation/trace/coresight-cpu-debug.txt 
> b/Documentation/trace/coresight-cpu-debug.txt
> new file mode 100644
> index 000..0426d50
> --- /dev/null
> +++ b/Documentation/trace/coresight-cpu-debug.txt
> @@ -0,0 +1,174 @@
> + Coresight CPU Debug Module
> + ==
> +
> +   Author:   Leo Yan 
> +   Date: April 5th, 2017
> +
> +Introduction
> +
> +
> +Coresight CPU debug module is defined in ARMv8-a architecture reference 
> manual
> +(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate
> +debug module and it is mainly used for two modes: self-hosted debug and
> +external debug. Usually the external debug mode is well known as the external
> +debugger connects with SoC from JTAG port; on the other hand the program can
> +explore debugging method which rely on self-hosted debug mode, this document
> +is to focus on this part.
> +
> +The debug module provides sample-based profiling extension, which can be used
> +to sample CPU program counter, secure state and exception level, etc; usually
> +every CPU has one dedicated debug module to be connected. Based on 
> self-hosted
> +debug mechanism, Linux kernel can access these related registers from mmio
> +region when the kernel panic happens. The callback notifier for kernel panic
> +will dump related registers for every CPU; finally this is good for assistant
> +analysis for panic.
> +
> +
> +Implementation
> +--
> +
> +- During driver registration, use EDDEVID and EDDEVID1 two device ID
> +  registers to decide if sample-based profiling is implemented or not. On 
> some
> +  platforms this hardware feature is fully or partialy implemented; and if
> +  this feature is not supported then registration will fail.
> +
> +- When write this doc, the debug driver mainly relies on three sampling
> +  registers. The kernel panic callback notifier gathers info from EDPCSR
> +  EDVIDSR and EDCIDSR; from EDPCSR we can get program counter, EDVIDSR has
> +  information for secure state, exception level, bit width, etc; EDCIDSR is
> +  context ID value which contains the sampled value of CONTEXTIDR_EL1.
> +
> +- The driver supports CPU running mode with either AArch64 or AArch32. The
> +  registers naming convention is a bit different between them, AArch64 uses
> +  'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses
> +  'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to
> +  use AArch64 naming convention.
> +
> +- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different
> +  register bits definition. So the driver consolidates two difference:
> +
> +  If PCSROffset=0b, on ARMv8-a the feature of EDPCSR is not implemented;
> +  but ARMv7-a defines "PCSR samples are offset by a value that depends on the
> +  instruction set state". For ARMv7-a, the driver checks furthermore if CPU
> +  runs with ARM or thumb instruction set and calibrate PCSR value, the
> +  detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter
> +  C11.11.34 "DBGPCSR, Program Counter Sampling Register".
> +
> +  If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have
> +  no offset 

Re: [PATCH v8 5/7] coresight: add support for CPU debug module

[Mathieu Poirier]

On Tue, May 02, 2017 at 06:08:35PM +0800, Leo Yan wrote:
> Coresight includes debug module and usually the module connects with CPU
> debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
> description for related info in "Part H: External Debug".
> 
> Chapter H7 "The Sample-based Profiling Extension" introduces several
> sampling registers, e.g. we can check program counter value with
> combined CPU exception level, secure state, etc. So this is helpful for
> analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
> loop with IRQ disabled. In this case the CPU cannot switch context and
> handle any interrupt (including IPIs), as the result it cannot handle
> SMP call for stack dump.
> 
> This patch is to enable coresight debug module, so firstly this driver
> is to bind apb clock for debug module and this is to ensure the debug
> module can be accessed from program or external debugger. And the driver
> uses sample-based registers for debug purpose, e.g. when system triggers
> panic, the driver will dump program counter and combined context
> registers (EDCIDSR, EDVIDSR); by parsing context registers so can
> quickly get to know CPU secure state, exception level, etc.
> 
> Some of the debug module registers are located in CPU power domain, so
> this requires the CPU power domain stays on when access related debug
> registers, but the power management for CPU power domain is quite
> dependent on SoC integration for power management. For the platforms
> which with sane power controller implementations, this driver follows
> the method to set EDPRCR to try to pull the CPU out of low power state
> and then set 'no power down request' bit so the CPU has no chance to
> lose power.
> 
> If the SoC has not followed up this design well for power management
> controller, the user should use the command line parameter or sysfs
> to constrain all or partial idle states to ensure the CPU power
> domain is enabled and access coresight CPU debug component safely.
> 
> Signed-off-by: Leo Yan 
> ---
>  drivers/hwtracing/coresight/Kconfig   |  14 +
>  drivers/hwtracing/coresight/Makefile  |   1 +
>  drivers/hwtracing/coresight/coresight-cpu-debug.c | 670 
> ++
>  3 files changed, 685 insertions(+)
>  create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c
> 
> diff --git a/drivers/hwtracing/coresight/Kconfig 
> b/drivers/hwtracing/coresight/Kconfig
> index 130cb21..8d55d6d 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -89,4 +89,18 @@ config CORESIGHT_STM
> logging useful software events or data coming from various entities
> in the system, possibly running different OSs
>  
> +config CORESIGHT_CPU_DEBUG
> + tristate "CoreSight CPU Debug driver"
> + depends on ARM || ARM64
> + depends on DEBUG_FS
> + help
> +   This driver provides support for coresight debugging module. This
> +   is primarily used to dump sample-based profiling registers when
> +   system triggers panic, the driver will parse context registers so
> +   can quickly get to know program counter (PC), secure state,
> +   exception level, etc. Before use debugging functionality, platform
> +   needs to ensure the clock domain and power domain are enabled
> +   properly, please refer Documentation/trace/coresight-cpu-debug.txt
> +   for detailed description and the example for usage.
> +
>  endif
> diff --git a/drivers/hwtracing/coresight/Makefile 
> b/drivers/hwtracing/coresight/Makefile
> index af480d9..433d590 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
>   coresight-etm4x-sysfs.o
>  obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
>  obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
> +obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
> diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
> b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> new file mode 100644
> index 000..b77456d
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> @@ -0,0 +1,670 @@
> +/*
> + * Copyright (c) 2017 Linaro Limited. All rights reserved.
> + *
> + * Author: Leo Yan 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If

Re: [PATCH v2 1/3] rtmutex: update rt-mutex-design

[Mathieu Poirier]

On 21 April 2017 at 08:12, Alex Shi  wrote:
> The rt-mutex-design documents didn't gotten meaningful update from its
> first version. Even after owner's pending bit was removed in commit 
> 8161239a8bcc
> ("rtmutex: Simplify PI algorithm and make highest prio task get lock")
> and priority list 'plist' changed to rbtree. So the documents are far
> late of real code.
>
> Update it to latest code and make it meaningful.
>
> Signed-off-by: Alex Shi 
> Cc: Steven Rostedt 
> Cc: Sebastian Siewior 
> To: linux-doc@vger.kernel.org
> To: linux-ker...@vger.kernel.org
> To: Jonathan Corbet 
> To: Ingo Molnar 
> To: Peter Zijlstra 
> Cc: Thomas Gleixner 
> ---
>  Documentation/locking/rt-mutex-design.txt | 390 
> +++---
>  1 file changed, 88 insertions(+), 302 deletions(-)
>
> diff --git a/Documentation/locking/rt-mutex-design.txt 
> b/Documentation/locking/rt-mutex-design.txt
> index 8666070..11beb55 100644
> --- a/Documentation/locking/rt-mutex-design.txt
> +++ b/Documentation/locking/rt-mutex-design.txt
> @@ -97,9 +97,9 @@ waiter   - A waiter is a struct that is stored on the stack 
> of a blocked
> a process being blocked on the mutex, it is fine to allocate
> the waiter on the process's stack (local variable).  This
> structure holds a pointer to the task, as well as the mutex that
> -   the task is blocked on.  It also has the plist node structures to
> -   place the task in the waiter_list of a mutex as well as the
> -   pi_list of a mutex owner task (described below).
> +  the task is blocked on.  It also has a rbtree node structures to

Here I assume we are talking about struct rt_mutex_waiter[1].  If so I
suggest to replace rbtree with rb_node.

> +  place the task in waiters rbtree of a mutex as well as the
> +  pi_waiters rbtree of a mutex owner task (described below).

Also following the comment for @pi_tree_entry, s/"a mutex owner
task"/"a mutex owner waiters tree" .

[1]. http://lxr.free-electrons.com/source/kernel/locking/rtmutex_common.h#L25


>
> waiter is sometimes used in reference to the task that is waiting
> on a mutex. This is the same as waiter->task.
> @@ -179,53 +179,35 @@ again.
>   |
> F->L5-+
>
> -
> -Plist
> --
> -
> -Before I go further and talk about how the PI chain is stored through lists
> -on both mutexes and processes, I'll explain the plist.  This is similar to
> -the struct list_head functionality that is already in the kernel.
> -The implementation of plist is out of scope for this document, but it is
> -very important to understand what it does.
> -
> -There are a few differences between plist and list, the most important one
> -being that plist is a priority sorted linked list.  This means that the
> -priorities of the plist are sorted, such that it takes O(1) to retrieve the
> -highest priority item in the list.  Obviously this is useful to store 
> processes
> -based on their priorities.
> -
> -Another difference, which is important for implementation, is that, unlike
> -list, the head of the list is a different element than the nodes of a list.
> -So the head of the list is declared as struct plist_head and nodes that will
> -be added to the list are declared as struct plist_node.
> -
> +If the G process has highest priority in the chain, then all the tasks up

If process G has the highest priority in the chain, ...

> +the chain (A and B in this example), must have their priorities increased
> +to that of G.
>
>  Mutex Waiter List
>  -
>
>  Every mutex keeps track of all the waiters that are blocked on itself. The 
> mutex
> -has a plist to store these waiters by priority.  This list is protected by
> +has a rbtree to store these waiters by priority.  This tree is protected by
>  a spin lock that is located in the struct of the mutex. This lock is called
> -wait_lock.  Since the modification of the waiter list is never done in
> +wait_lock.  Since the modification of the waiter tree is never done in
>  interrupt context, the wait_lock can be taken without disabling interrupts.
>
>
> -Task PI List
> +Task PI Tree
>  
>
> -To keep track of the PI chains, each process has its own PI list.  This is
> -a list of all top waiters of the mutexes that are owned by the process.
> -Note that this list only holds the top waiters and not all waiters that are
> +To keep track of the PI chains, each process has its own PI rbtree.  This is
> +a tree of all top waiters of the mutexes that are owned by the process.
> +Note that this tree only holds the top waiters and not all waiters that are
>  blocked on mutexes owned by the process.
>
> -The top of the task's PI list is always the highest priority task that
> +The top of the task's PI tree is always the highest priority task that
>  is waiting on a mutex that is owned by the task.  So if the task has
>  inherited a priority, it wil

Re: [PATCH v6 6/8] coresight: add support for CPU debug module

[Mathieu Poirier]

On 6 April 2017 at 07:30, Leo Yan  wrote:
> Coresight includes debug module and usually the module connects with CPU
> debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
> description for related info in "Part H: External Debug".
>
> Chapter H7 "The Sample-based Profiling Extension" introduces several
> sampling registers, e.g. we can check program counter value with
> combined CPU exception level, secure state, etc. So this is helpful for
> analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
> loop with IRQ disabled. In this case the CPU cannot switch context and
> handle any interrupt (including IPIs), as the result it cannot handle
> SMP call for stack dump.
>
> This patch is to enable coresight debug module, so firstly this driver
> is to bind apb clock for debug module and this is to ensure the debug
> module can be accessed from program or external debugger. And the driver
> uses sample-based registers for debug purpose, e.g. when system triggers
> panic, the driver will dump program counter and combined context
> registers (EDCIDSR, EDVIDSR); by parsing context registers so can
> quickly get to know CPU secure state, exception level, etc.
>
> Some of the debug module registers are located in CPU power domain, so
> this requires the CPU power domain stays on when access related debug
> registers, but the power management for CPU power domain is quite
> dependent on SoC integration for power management. For the platforms
> which with sane power controller implementations, this driver follows
> the method to set EDPRCR to try to pull the CPU out of low power state
> and then set 'no power down request' bit so the CPU has no chance to
> lose power.
>
> If the SoC has not followed up this design well for power management
> controller, the user should use the command line parameter or sysfs
> to constrain all or partial idle states to ensure the CPU power
> domain is enabled and access coresight CPU debug component safely.
>
> Signed-off-by: Leo Yan 
> ---
>  drivers/hwtracing/coresight/Kconfig   |  14 +
>  drivers/hwtracing/coresight/Makefile  |   1 +
>  drivers/hwtracing/coresight/coresight-cpu-debug.c | 667 
> ++
>  3 files changed, 682 insertions(+)
>  create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c
>
> diff --git a/drivers/hwtracing/coresight/Kconfig 
> b/drivers/hwtracing/coresight/Kconfig
> index 130cb21..8d55d6d 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -89,4 +89,18 @@ config CORESIGHT_STM
>   logging useful software events or data coming from various entities
>   in the system, possibly running different OSs
>
> +config CORESIGHT_CPU_DEBUG
> +   tristate "CoreSight CPU Debug driver"
> +   depends on ARM || ARM64
> +   depends on DEBUG_FS
> +   help
> + This driver provides support for coresight debugging module. This
> + is primarily used to dump sample-based profiling registers when
> + system triggers panic, the driver will parse context registers so
> + can quickly get to know program counter (PC), secure state,
> + exception level, etc. Before use debugging functionality, platform
> + needs to ensure the clock domain and power domain are enabled
> + properly, please refer Documentation/trace/coresight-cpu-debug.txt
> + for detailed description and the example for usage.
> +
>  endif
> diff --git a/drivers/hwtracing/coresight/Makefile 
> b/drivers/hwtracing/coresight/Makefile
> index af480d9..433d590 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
> coresight-etm4x-sysfs.o
>  obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
>  obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
> +obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
> diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
> b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> new file mode 100644
> index 000..8470e31
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> @@ -0,0 +1,667 @@
> +/*
> + * Copyright (c) 2017 Linaro Limited. All rights reserved.
> + *
> + * Author: Leo Yan 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this progr

Re: [PATCH v6 2/8] doc: Add documentation for Coresight CPU debug

[Mathieu Poirier]

On 6 April 2017 at 07:30, Leo Yan  wrote:
> Update kernel-parameters.txt to add new parameter:
> coresight_cpu_debug.enable is a knob to enable debugging at boot time.
>
> Add detailed documentation, which contains the implementation, Mike
> Leach excellent summary for "clock and power domain". At the end some
> examples on how to enable the debugging functionality are provided.
>
> Suggested-by: Mike Leach 
> Signed-off-by: Leo Yan 
> ---
>  Documentation/admin-guide/kernel-parameters.txt |   7 +
>  Documentation/trace/coresight-cpu-debug.txt | 173 
> 
>  2 files changed, 180 insertions(+)
>  create mode 100644 Documentation/trace/coresight-cpu-debug.txt
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index facc20a..cf90146 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -650,6 +650,13 @@
> /proc//coredump_filter.
> See also Documentation/filesystems/proc.txt.
>
> +   coresight_cpu_debug.enable
> +   [ARM,ARM64]
> +   Format: 
> +   Enable/disable the CPU sampling based debugging.
> +   0: default value, disable debugging
> +   1: enable debugging at boot time
> +
> cpuidle.off=1   [CPU_IDLE]
> disable the cpuidle sub-system
>
> diff --git a/Documentation/trace/coresight-cpu-debug.txt 
> b/Documentation/trace/coresight-cpu-debug.txt
> new file mode 100644
> index 000..e7ad05e
> --- /dev/null
> +++ b/Documentation/trace/coresight-cpu-debug.txt
> @@ -0,0 +1,173 @@
> +   Coresight CPU Debug Module
> +   ==
> +
> +   Author:   Leo Yan 
> +   Date: April 5th, 2017
> +
> +Introduction
> +
> +
> +Coresight CPU debug module is defined in ARMv8-a architecture reference 
> manual
> +(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate
> +debug module and it is mainly used for two modes: self-hosted debug and
> +external debug. Usually the external debug mode is well known as the external
> +debugger connects with SoC from JTAG port; on the other hand the program can
> +explore debugging method which rely on self-hosted debug mode, this document
> +is to focus on this part.
> +
> +The debug module provides sample-based profiling extension, which can be used
> +to sample CPU program counter, secure state and exception level, etc; usually
> +every CPU has one dedicated debug module to be connected. Based on 
> self-hosted
> +debug mechanism, Linux kernel can access these related registers from mmio
> +region when the kernel panic happens. The callback notifier for kernel panic
> +will dump related registers for every CPU; finally this is good for assistant
> +analysis for panic.
> +
> +
> +Implementation
> +--
> +
> +- During driver registration, use EDDEVID and EDDEVID1 two device ID
> +  registers to decide if sample-based profiling is implemented or not. On 
> some
> +  platforms this hardware feature is fully or partialy implemented; and if
> +  this feature is not supported then registration will fail.
> +
> +- When write this doc, the debug driver mainly relies on three sampling
> +  registers. The kernel panic callback notifier gathers info from EDPCSR
> +  EDVIDSR and EDCIDSR; from EDPCSR we can get program counter, EDVIDSR has
> +  information for secure state, exception level, bit width, etc; EDCIDSR is
> +  context ID value which contains the sampled value of CONTEXTIDR_EL1.
> +
> +- The driver supports CPU running mode with either AArch64 or AArch32. The
> +  registers naming convention is a bit different between them, AArch64 uses
> +  'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses
> +  'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to
> +  use AArch64 naming convention.
> +
> +- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different
> +  register bits definition. So the driver consolidates two difference:
> +
> +  If PCSROffset=0b. ARMv8-a doesn't apply offset on PCSR, but ARMv7-a
> +  defines "PCSR samples are offset by a value that depends on the instruction
> +  set state".

I had to look in the documentation (ID092916) a little here.  On ARMv8
if DEVID1.PCSROffset is 0 then the feature is not implemented - as
such the first part of the sentence should be corrected.  The rest of
the sentence about ARMv7 is correct.

> For ARMv7-a, the driver checks furthermore if CPU runs with ARM
> +  or thumb instruction set and calibrate PCSR value, the detailed description
> +  for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter C11.11.34 "DBGPCSR,
> +  Program Counter Sampling Register".
> +
> +  If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have
> +  no offset ap

Re: [PATCH v6 6/8] coresight: add support for CPU debug module

[Mathieu Poirier]

On 19 April 2017 at 09:30, Leo Yan  wrote:
> On Wed, Apr 19, 2017 at 08:52:12AM -0600, Mathieu Poirier wrote:
>
> [...]
>
>> >> > +static bool debug_enable;
>> >> > +module_param_named(enable, debug_enable, bool, 0600);
>> >> > +MODULE_PARM_DESC(enable, "Knob to enable debug functionality "
>> >> > +"(default is 0, which means is disabled by default)");
>> >>
>> >> For this driver we have a debugFS interface so I question the validity of 
>> >> a
>> >> kernel module parameter.  Other than adding complexity to the code it 
>> >> offers no
>> >> real added value.  If a user is to insmod a module, it is just as easy to 
>> >> switch
>> >> on the functionality using debugFS in a second step.
>> >
>> > This module parameter can be used for kernel command line, so
>> > it's useful when user wants to dynamically turn on/off the
>> > functionality at boot up time.
>> >
>> > Does this make sense for you? Removing this parameter is okay for
>> > me, but this means users need to decide if use it by Kernel config
>> > with static building in. This is a bit contradictory with before's
>> > discussion.
>>
>> My hope was to use the kernel command line and the debugFS interface,
>> avoiding the module parameter.  Look at what the baycom_par and
>> blacklist drivers are doing with the "__setup()" function and see if
>> we can void a module parameter.  If not then let it be, unless someone
>> else has a better idea.
>>
>> [1]. drivers/net/hamradio/baycom_par.c
>> [2]. drivers/s390/cio/blacklist.c
>
> This driver supports module mode. So we can choose to use either module
> parameter or __setup(). But as described in the file
> Documentation/admin-guide/kernel-parameters.rst, the module parameter
> is more flexible to be used at boot time or insmod the module:
>
> "Parameters for modules which are built into the kernel need to be
> specified on the kernel command line.  modprobe looks through the
> kernel command line (/proc/cmdline) and collects module parameters
> when it loads a module, so the kernel command line can be used for
> loadable modules too."
>
> __setup() cannot support module mode, and when use __setup(), we need
> register one callback function for it. The callback function is
> friendly to parse complex parameters rather than module parameter.
> but it's not necessary for this case.

__setup() definitely supports module - the baycom driver is a good
example of that.

But as you pointed out kernel-parameters.rst is pretty clear on how to
proceed.  As such disregard my comment and proceed with a module
parameter.

>
> So I'm bias to use module parameter :)
>
> Thanks,
> Leo Yan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 6/8] coresight: add support for CPU debug module

[Mathieu Poirier]

On 18 April 2017 at 18:18, Leo Yan  wrote:
> On Tue, Apr 18, 2017 at 11:40:50AM -0600, Mathieu Poirier wrote:
>> On Thu, Apr 06, 2017 at 09:30:59PM +0800, Leo Yan wrote:
>> > Coresight includes debug module and usually the module connects with CPU
>> > debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
>> > description for related info in "Part H: External Debug".
>> >
>> > Chapter H7 "The Sample-based Profiling Extension" introduces several
>> > sampling registers, e.g. we can check program counter value with
>> > combined CPU exception level, secure state, etc. So this is helpful for
>> > analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
>> > loop with IRQ disabled. In this case the CPU cannot switch context and
>> > handle any interrupt (including IPIs), as the result it cannot handle
>> > SMP call for stack dump.
>> >
>> > This patch is to enable coresight debug module, so firstly this driver
>> > is to bind apb clock for debug module and this is to ensure the debug
>> > module can be accessed from program or external debugger. And the driver
>> > uses sample-based registers for debug purpose, e.g. when system triggers
>> > panic, the driver will dump program counter and combined context
>> > registers (EDCIDSR, EDVIDSR); by parsing context registers so can
>> > quickly get to know CPU secure state, exception level, etc.
>> >
>> > Some of the debug module registers are located in CPU power domain, so
>> > this requires the CPU power domain stays on when access related debug
>> > registers, but the power management for CPU power domain is quite
>> > dependent on SoC integration for power management. For the platforms
>> > which with sane power controller implementations, this driver follows
>> > the method to set EDPRCR to try to pull the CPU out of low power state
>> > and then set 'no power down request' bit so the CPU has no chance to
>> > lose power.
>> >
>> > If the SoC has not followed up this design well for power management
>> > controller, the user should use the command line parameter or sysfs
>> > to constrain all or partial idle states to ensure the CPU power
>> > domain is enabled and access coresight CPU debug component safely.
>> >
>> > Signed-off-by: Leo Yan 
>>
>> This is coming along well - a few comment below.  In your next revision 
>> please
>> add GKH to the 'To' list.
>
> Sure. Will send out in this week and add Greg in 'To' list.
>
>> > ---
>> >  drivers/hwtracing/coresight/Kconfig   |  14 +
>> >  drivers/hwtracing/coresight/Makefile  |   1 +
>> >  drivers/hwtracing/coresight/coresight-cpu-debug.c | 667 
>> > ++
>> >  3 files changed, 682 insertions(+)
>> >  create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c
>> >
>> > diff --git a/drivers/hwtracing/coresight/Kconfig 
>> > b/drivers/hwtracing/coresight/Kconfig
>> > index 130cb21..8d55d6d 100644
>> > --- a/drivers/hwtracing/coresight/Kconfig
>> > +++ b/drivers/hwtracing/coresight/Kconfig
>> > @@ -89,4 +89,18 @@ config CORESIGHT_STM
>> >   logging useful software events or data coming from various entities
>> >   in the system, possibly running different OSs
>> >
>> > +config CORESIGHT_CPU_DEBUG
>> > +   tristate "CoreSight CPU Debug driver"
>> > +   depends on ARM || ARM64
>> > +   depends on DEBUG_FS
>> > +   help
>> > + This driver provides support for coresight debugging module. This
>> > + is primarily used to dump sample-based profiling registers when
>> > + system triggers panic, the driver will parse context registers so
>> > + can quickly get to know program counter (PC), secure state,
>> > + exception level, etc. Before use debugging functionality, platform
>> > + needs to ensure the clock domain and power domain are enabled
>> > + properly, please refer Documentation/trace/coresight-cpu-debug.txt
>> > + for detailed description and the example for usage.
>> > +
>> >  endif
>> > diff --git a/drivers/hwtracing/coresight/Makefile 
>> > b/drivers/hwtracing/coresight/Makefile
>> > index af480d9..433d590 100644
>> > --- a/drivers/hwtracing/coresight/Makefile
>> > +++ b/drivers/hwtracing/coresight/Makefile
>> > @@ -16,3 +16,4 @@ obj-$(CONFIG_CO

Re: [PATCH v6 6/8] coresight: add support for CPU debug module

[Mathieu Poirier]

On Thu, Apr 06, 2017 at 09:30:59PM +0800, Leo Yan wrote:
> Coresight includes debug module and usually the module connects with CPU
> debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
> description for related info in "Part H: External Debug".
> 
> Chapter H7 "The Sample-based Profiling Extension" introduces several
> sampling registers, e.g. we can check program counter value with
> combined CPU exception level, secure state, etc. So this is helpful for
> analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
> loop with IRQ disabled. In this case the CPU cannot switch context and
> handle any interrupt (including IPIs), as the result it cannot handle
> SMP call for stack dump.
> 
> This patch is to enable coresight debug module, so firstly this driver
> is to bind apb clock for debug module and this is to ensure the debug
> module can be accessed from program or external debugger. And the driver
> uses sample-based registers for debug purpose, e.g. when system triggers
> panic, the driver will dump program counter and combined context
> registers (EDCIDSR, EDVIDSR); by parsing context registers so can
> quickly get to know CPU secure state, exception level, etc.
> 
> Some of the debug module registers are located in CPU power domain, so
> this requires the CPU power domain stays on when access related debug
> registers, but the power management for CPU power domain is quite
> dependent on SoC integration for power management. For the platforms
> which with sane power controller implementations, this driver follows
> the method to set EDPRCR to try to pull the CPU out of low power state
> and then set 'no power down request' bit so the CPU has no chance to
> lose power.
> 
> If the SoC has not followed up this design well for power management
> controller, the user should use the command line parameter or sysfs
> to constrain all or partial idle states to ensure the CPU power
> domain is enabled and access coresight CPU debug component safely.
> 
> Signed-off-by: Leo Yan 

This is coming along well - a few comment below.  In your next revision please
add GKH to the 'To' list.  

Thanks,
Mathieu

> ---
>  drivers/hwtracing/coresight/Kconfig   |  14 +
>  drivers/hwtracing/coresight/Makefile  |   1 +
>  drivers/hwtracing/coresight/coresight-cpu-debug.c | 667 
> ++
>  3 files changed, 682 insertions(+)
>  create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c
> 
> diff --git a/drivers/hwtracing/coresight/Kconfig 
> b/drivers/hwtracing/coresight/Kconfig
> index 130cb21..8d55d6d 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -89,4 +89,18 @@ config CORESIGHT_STM
> logging useful software events or data coming from various entities
> in the system, possibly running different OSs
>  
> +config CORESIGHT_CPU_DEBUG
> + tristate "CoreSight CPU Debug driver"
> + depends on ARM || ARM64
> + depends on DEBUG_FS
> + help
> +   This driver provides support for coresight debugging module. This
> +   is primarily used to dump sample-based profiling registers when
> +   system triggers panic, the driver will parse context registers so
> +   can quickly get to know program counter (PC), secure state,
> +   exception level, etc. Before use debugging functionality, platform
> +   needs to ensure the clock domain and power domain are enabled
> +   properly, please refer Documentation/trace/coresight-cpu-debug.txt
> +   for detailed description and the example for usage.
> +
>  endif
> diff --git a/drivers/hwtracing/coresight/Makefile 
> b/drivers/hwtracing/coresight/Makefile
> index af480d9..433d590 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
>   coresight-etm4x-sysfs.o
>  obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
>  obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
> +obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
> diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
> b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> new file mode 100644
> index 000..8470e31
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> @@ -0,0 +1,667 @@
> +/*
> + * Copyright (c) 2017 Linaro Limited. All rights reserved.
> + *
> + * Author: Leo Yan 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * mor

Re: [PATCH v6 5/8] coresight: use const for device_node structures

[Mathieu Poirier]

On Thu, Apr 06, 2017 at 09:30:58PM +0800, Leo Yan wrote:
> Almost low level functions from open firmware have used const to
> qualify device_node structures, so add const for device_node
> parameters in of_coresight related functions.
> 
> Reviewed-by: Stephen Boyd 
> Signed-off-by: Leo Yan 

I agree with these changes but the patch needs to be split up - please see
below.

> ---
>  drivers/hwtracing/coresight/of_coresight.c | 6 +++---
>  include/linux/coresight.h  | 8 
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/of_coresight.c 
> b/drivers/hwtracing/coresight/of_coresight.c
> index 78d2399..46eec0f 100644
> --- a/drivers/hwtracing/coresight/of_coresight.c
> +++ b/drivers/hwtracing/coresight/of_coresight.c
> @@ -52,7 +52,7 @@ of_coresight_get_endpoint_device(struct device_node 
> *endpoint)
>  endpoint, of_dev_node_match);
>  }
>  
> -static void of_coresight_get_ports(struct device_node *node,
> +static void of_coresight_get_ports(const struct device_node *node,
>  int *nr_inport, int *nr_outport)

Move this to a patch by itself as it is not related to this driver.

>  {
>   struct device_node *ep = NULL;
> @@ -101,7 +101,7 @@ static int of_coresight_alloc_memory(struct device *dev,
>   return 0;
>  }
>  
> -int of_coresight_get_cpu(struct device_node *node)
> +int of_coresight_get_cpu(const struct device_node *node)

Move this to the previous patch in this set.  There is not need to undo what you
just did there.

>  {
>   int cpu;
>   bool found;
> @@ -128,7 +128,7 @@ int of_coresight_get_cpu(struct device_node *node)
>  EXPORT_SYMBOL_GPL(of_coresight_get_cpu);
>  
>  struct coresight_platform_data *of_get_coresight_platform_data(
> - struct device *dev, struct device_node *node)
> + struct device *dev, const struct device_node *node)

Same here, move this to a new patch (the same one as of_coresight_get_ports()).

>  {
>   int i = 0, ret = 0;
>   struct coresight_platform_data *pdata;
> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
> index bf96678..4915254 100644
> --- a/include/linux/coresight.h
> +++ b/include/linux/coresight.h
> @@ -263,13 +263,13 @@ static inline int coresight_timeout(void __iomem *addr, 
> u32 offset,
>  #endif
>  
>  #ifdef CONFIG_OF
> -extern int of_coresight_get_cpu(struct device_node *node);
> +extern int of_coresight_get_cpu(const struct device_node *node);
>  extern struct coresight_platform_data *of_get_coresight_platform_data(
> - struct device *dev, struct device_node *node);
> + struct device *dev, const struct device_node *node);
>  #else
> -static inline int of_coresight_get_cpu(struct device_node *node) { return 0; 
> }
> +static inline int of_coresight_get_cpu(const struct device_node *node) { 
> return 0; }
>  static inline struct coresight_platform_data *of_get_coresight_platform_data(
> - struct device *dev, struct device_node *node) { return NULL; }
> + struct device *dev, const struct device_node *node) { return NULL; }
>  #endif
>  
>  #ifdef CONFIG_PID_NS
> -- 
> 2.7.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 3/8] coresight: of_get_coresight_platform_data: Add missing of_node_put

[Mathieu Poirier]

On Thu, Apr 06, 2017 at 09:30:56PM +0800, Leo Yan wrote:
> From: Suzuki K Poulose 
> 
> The of_get_coresight_platform_data iterates over the possible CPU nodes
> to find a given cpu phandle. However it does not drop the reference
> to the node pointer returned by the of_get_coresight_platform_data.
> 
> This patch also introduces another minor fix is to use
> of_cpu_device_node_get() to replace of_get_cpu_node().
> 
> Cc: Mathieu Poirier 
> Signed-off-by: Suzuki K Poulose 
> [Leo: minor tweaks for of_get_coresight_platform_data]
> Signed-off-by: Leo Yan 

Suzuki sent a Reviewed-by for this, it should be added here.

> ---
>  drivers/hwtracing/coresight/of_coresight.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/of_coresight.c 
> b/drivers/hwtracing/coresight/of_coresight.c
> index 629e031..1a77280 100644
> --- a/drivers/hwtracing/coresight/of_coresight.c
> +++ b/drivers/hwtracing/coresight/of_coresight.c
> @@ -108,7 +108,8 @@ struct coresight_platform_data 
> *of_get_coresight_platform_data(
>   struct coresight_platform_data *pdata;
>   struct of_endpoint endpoint, rendpoint;
>   struct device *rdev;
> - struct device_node *dn;
> + bool found;
> + struct device_node *dn, *np;
>   struct device_node *ep = NULL;
>   struct device_node *rparent = NULL;
>   struct device_node *rport = NULL;
> @@ -175,17 +176,19 @@ struct coresight_platform_data 
> *of_get_coresight_platform_data(
>   } while (ep);
>   }
>  
> - /* Affinity defaults to CPU0 */
> - pdata->cpu = 0;
>   dn = of_parse_phandle(node, "cpu", 0);
> - for (cpu = 0; dn && cpu < nr_cpu_ids; cpu++) {
> - if (dn == of_get_cpu_node(cpu, NULL)) {
> - pdata->cpu = cpu;
> + for_each_possible_cpu(cpu) {
> + np = of_cpu_device_node_get(cpu);
> + found = (dn == np);
> + of_node_put(np);
> + if (found)
>   break;
> - }
>   }
>   of_node_put(dn);
>  
> + /* Affinity to CPU0 if no cpu nodes are found */
> + pdata->cpu = found ? cpu : 0;
> +
>   return pdata;
>  }
>  EXPORT_SYMBOL_GPL(of_get_coresight_platform_data);
> -- 
> 2.7.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 6/9] coresight: add support for CPU debug module

[Mathieu Poirier]

On 29 March 2017 at 19:59, Leo Yan  wrote:
> On Wed, Mar 29, 2017 at 10:55:35AM -0600, Mathieu Poirier wrote:
>
> [...]
>
>> > So this is why add "idle_constraint" as a central place to control
>> > power domain for CPU debug purpose and I also think this is more
>> > friendly for hardware design, e.g. some platforms can enable partial
>> > low power states to save power and avoid overheat after using this
>> > driver.
>> >
>> > How about you think for this?
>>
>> Like Sudeep pointed out we should concentrate on doing the right thing,
>> that is work with EDPRSR.PU, EDPRCR.COREPURQ and EDPRCR.CORENPDRQ.
>
> Agree, and I think we have aligned for this.
>
>> Anything outside of that becomes platform specific and can't be handled in
>> this driver.
>
> Sorry I argue a bit for this just want to make things more clear and
> if can have better method.
>
> Though the issue is platform specific, but the code is to seek common
> method to handle them. So the driver has no any platform specific code.

Seeking a common way to handle platform specific problems doesn't
scale and will never be encompassing.  There will always be a quirk
somewhere to deal with, hence the idea of keeping things separate.

>
> I read again for Suziki's suggestion: "4) Should document the fact that,
> on some platforms, the user may have to disable CPUidle explicitly to
> get the driver working. But let us not make it the default. The user
> with a not so ideal platform could add "nohlt" and get it working."

Suzuki and I are expressing the same view using different words.

>
> So I'm not strong to resist and if this is alignment yet, I should
> document well for this but doesn't handle it in driver (keep driver
> simple).
>
> Thanks,
> Leo Yan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 6/9] coresight: add support for CPU debug module

[Mathieu Poirier]

On Wed, Mar 29, 2017 at 09:54:23AM +0800, Leo Yan wrote:
> Hi Mathieu,
> 
> On Tue, Mar 28, 2017 at 10:50:10AM -0600, Mathieu Poirier wrote:
> > On Sun, Mar 26, 2017 at 02:23:14AM +0800, Leo Yan wrote:
> 
> [...]
> 
> > > +static void debug_force_cpu_powered_up(struct debug_drvdata *drvdata)
> > > +{
> > > + int timeout = DEBUG_WAIT_TIMEOUT;
> > > +
> > > + drvdata->edprsr = readl_relaxed(drvdata->base + EDPRSR);
> > > +
> > > + CS_UNLOCK(drvdata->base);
> > > +
> > > + /* Bail out if CPU is powered up yet */
> > > + if (drvdata->edprsr & EDPRSR_PU)
> > > + goto out_powered_up;
> > > +
> > > + /*
> > > +  * Send request to power management controller and assert
> > > +  * DBGPWRUPREQ signal; if power management controller has
> > > +  * sane implementation, it should enable CPU power domain
> > > +  * in case CPU is in low power state.
> > > +  */
> > > + drvdata->edprsr = readl(drvdata->base + EDPRCR);
> > > + drvdata->edprsr |= EDPRCR_COREPURQ;
> > > + writel(drvdata->edprsr, drvdata->base + EDPRCR);
> > 
> > Here ->edprsr is used but EDPRCR is accessed.  Is this intentional or a
> > copy/paste error?  The same is true for accesses in the out_powered_up 
> > section.
> 
> Thanks for pointing out. This is a typo error and will fix.
> 
> > > +
> > > + /* Wait for CPU to be powered up (timeout~=32ms) */
> > > + while (timeout--) {
> > > + drvdata->edprsr = readl_relaxed(drvdata->base + EDPRSR);
> > > + if (drvdata->edprsr & EDPRSR_PU)
> > > + break;
> > > +
> > > + usleep_range(1000, 2000);
> > > + }
> > 
> > See if function readx_poll_timeout() can be used.
> 
> Will use it.
> 
> > > +
> > > + /*
> > > +  * Unfortunately the CPU cannot be powered up, so return
> > > +  * back and later has no permission to access other
> > > +  * registers. For this case, should set 'idle_constraint'
> > > +  * to ensure CPU power domain is enabled!
> > > +  */
> > > + if (!(drvdata->edprsr & EDPRSR_PU)) {
> > > + pr_err("%s: power up request for CPU%d failed\n",
> > > + __func__, drvdata->cpu);
> > > + goto out;
> > > + }
> > > +
> > > +out_powered_up:
> > > + debug_os_unlock(drvdata);
> > > +
> > > + /*
> > > +  * At this point the CPU is powered up, so set the no powerdown
> > > +  * request bit so we don't lose power and emulate power down.
> > > +  */
> > > + drvdata->edprsr = readl(drvdata->base + EDPRCR);
> > > + drvdata->edprsr |= EDPRCR_COREPURQ | EDPRCR_CORENPDRQ;
> > 
> > If we are here the core is already up.  Shouldn't we need to set
> > EDPRCR_CORENPDRQ only?
> 
> Yeah. Will fix.
> 
> > > + writel(drvdata->edprsr, drvdata->base + EDPRCR);
> > 
> > This section is a little racy - between the time the PU bit has been
> > checked and the time COREPDRQ has been flipped, the state of PU may have
> > changed.  You can probably get around this by checking edprsr.PU rigth 
> > here.  If
> > it is not set you go through the process again.  Note that doing this will
> > probably force a refactoring of the whole function.  
> 
> Agree. Will handle this.
> 
> [...]
> 
> > > +static ssize_t debug_func_knob_write(struct file *f,
> > > + const char __user *buf, size_t count, loff_t *ppos)
> > > +{
> > > e u8 on;
> > > + int ret;
> > > +
> > > + ret = kstrtou8_from_user(buf, count, 2, &on);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + mutex_lock(&debug_lock);
> > > +
> > > + if (!on ^ debug_enable)
> > > + goto out;
> > 
> > I had to read this condition too many times - please refactor.
> 
> Will do it.
> 
> > > +
> > > + if (on) {
> > > + ret = debug_enable_func();
> > > + if (ret) {
> > > + pr_err("%s: unable to disable debug function: %d\n",
> > > +__func__, ret);
> > 
> > Based on the semantic this is the wrong error message.
> 
> Yeah. Will fix.
> 
> > > + goto err;
> > > + }
> > > + } else
> > > + debug_disable_func();
>

Re: [PATCH v5 6/9] coresight: add support for CPU debug module

[Mathieu Poirier]

On Wed, Mar 29, 2017 at 11:07:35AM +0800, Leo Yan wrote:
> Hi Suzuki,
> 
> On Mon, Mar 27, 2017 at 05:34:57PM +0100, Suzuki K Poulose wrote:
> > On 25/03/17 18:23, Leo Yan wrote:
> 
> [...]
> 
> > Leo,
> > 
> > Thanks a lot for the quick rework. I don't fully understand (yet!) why we 
> > need the
> > idle_constraint. I will leave it for Sudeep to comment on it, as he is the 
> > expert
> > in that area. Some minor comments below.
> 
> Thanks a lot for quick reviewing :)
> 
> > >Signed-off-by: Leo Yan 
> > >---
> > > drivers/hwtracing/coresight/Kconfig   |  11 +
> > > drivers/hwtracing/coresight/Makefile  |   1 +
> > > drivers/hwtracing/coresight/coresight-cpu-debug.c | 704 
> > > ++
> > > 3 files changed, 716 insertions(+)
> > > create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c
> > >
> > >diff --git a/drivers/hwtracing/coresight/Kconfig 
> > >b/drivers/hwtracing/coresight/Kconfig
> > >index 130cb21..18d7931 100644
> > >--- a/drivers/hwtracing/coresight/Kconfig
> > >+++ b/drivers/hwtracing/coresight/Kconfig
> > >@@ -89,4 +89,15 @@ config CORESIGHT_STM
> > > logging useful software events or data coming from various entities
> > > in the system, possibly running different OSs
> > >
> > >+config CORESIGHT_CPU_DEBUG
> > >+  tristate "CoreSight CPU Debug driver"
> > >+  depends on ARM || ARM64
> > >+  depends on DEBUG_FS
> > >+  help
> > >+This driver provides support for coresight debugging module. This
> > >+is primarily used to dump sample-based profiling registers when
> > >+system triggers panic, the driver will parse context registers so
> > >+can quickly get to know program counter (PC), secure state,
> > >+exception level, etc.
> > 
> > May be we should mention/warn the user about the possible caveats of using
> > this feature to help him make a better decision ? And / Or we should add a 
> > documentation
> > for it. We have collected some real good information over the discussions 
> > and
> > it is a good idea to capture it somewhere.
> 
> Sure, I will add a documentation for this.
> 
> [...]
> 
> > >+static struct pm_qos_request debug_qos_req;
> > >+static int idle_constraint = PM_QOS_DEFAULT_VALUE;
> > >+module_param(idle_constraint, int, 0600);
> > >+MODULE_PARM_DESC(idle_constraint, "Latency requirement in microseconds 
> > >for CPU "
> > >+   "idle states (default is -1, which means have no limiation "
> > >+   "to CPU idle states; 0 means disabling all idle states; user "
> > >+   "can choose other platform dependent values so can disable "
> > >+   "specific idle states for the platform)");
> > 
> > Correct me if I am wrong,
> > 
> > All we want to do is disable the CPUIdle explicitly if the user knows that 
> > this
> > could be a problem to use CPU debug on his platform. So, in effect, we 
> > should
> > only be using idle_constraint = 0 or -1.
> > 
> > In which case, we could make it easier for the user to tell us, either
> > 
> >  0 - Don't do anything with CPUIdle (default)
> >  1 - Disable CPUIdle for me as I know the platform has issues with CPU 
> > debug and CPUidle.
> 
> The reason for not using bool flag is: usually SoC may have many idle
> states, so if user wants to partially enable some states then can set
> the latency to constraint.
> 
> But of course, we can change this to binary value as you suggested,
> this means turn on of turn off all states. The only one reason to use
> latency value is it is more friendly for hardware design, e.g. some
> platforms can enable partial states to save power and avoid overheat
> after using this driver.
> 
> If you guys think this is a bit over design, I will follow up your
> suggestion. I also have some replying in Mathieu's reviewing, please
> help review as well.
> 
> > than explaining the miscrosecond latency etc and make the appropriate calls 
> > underneath.
> > something like (not necessarily the same name) :
> > 
> > module_param(broken_with_cpuidle, bool, 0600);
> > MODULE_PARAM_DESC(broken_with_cpuidle, "Specifies whether the CPU debug has 
> > issues with CPUIdle on"
> >" the platform. Non-zero value implies 
> > CPUIdle has to be"
> >" explicitly disabled.",);
> 
> [...]
> 
> > >+  /*
> > >+   * Unfortunately the CPU cannot be powered up, so return
> > >+   * back and later has no permission to access other
> > >+   * registers. For this case, should set 'idle_constraint'
> > >+   * to ensure CPU power domain is enabled!
> > >+   */
> > >+  if (!(drvdata->edprsr & EDPRSR_PU)) {
> > >+  pr_err("%s: power up request for CPU%d failed\n",
> > >+  __func__, drvdata->cpu);
> > >+  goto out;
> > >+  }
> > >+
> > >+out_powered_up:
> > >+  debug_os_unlock(drvdata);
> > 
> > Question: Do we need a matching debug_os_lock() once we are done ?
> 
> I have checked ARM ARMv8, but there have no detailed description for
> 

Re: [PATCH v5 6/9] coresight: add support for CPU debug module

[Mathieu Poirier]

Hi Leo,

On Sun, Mar 26, 2017 at 02:23:14AM +0800, Leo Yan wrote:
> Coresight includes debug module and usually the module connects with CPU
> debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
> description for related info in "Part H: External Debug".
> 
> Chapter H7 "The Sample-based Profiling Extension" introduces several
> sampling registers, e.g. we can check program counter value with
> combined CPU exception level, secure state, etc. So this is helpful for
> analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
> loop with IRQ disabled. In this case the CPU cannot switch context and
> handle any interrupt (including IPIs), as the result it cannot handle
> SMP call for stack dump.
> 
> This patch is to enable coresight debug module, so firstly this driver
> is to bind apb clock for debug module and this is to ensure the debug
> module can be accessed from program or external debugger. And the driver
> uses sample-based registers for debug purpose, e.g. when system triggers
> panic, the driver will dump program counter and combined context
> registers (EDCIDSR, EDVIDSR); by parsing context registers so can
> quickly get to know CPU secure state, exception level, etc.
> 
> Some of the debug module registers are located in CPU power domain, so
> this requires the CPU power domain stays on when access related debug
> registers, but the power management for CPU power domain is quite
> dependent on SoC integration for power management. For the platforms
> which with sane power controller implementations, this driver follows
> the method to set EDPRCR to try to pull the CPU out of low power state
> and then set 'no power down request' bit so the CPU has no chance to
> lose power.
> 
> If the SoC has not followed up this design well for power management
> controller, the driver introduces module parameter "idle_constraint".
> Setting this parameter for latency requirement in microseconds, finally
> we can constrain all or partial idle states to ensure the CPU power
> domain is enabled, this is a backup method to access coresight CPU
> debug component safely.
> 
> Signed-off-by: Leo Yan 
> ---
>  drivers/hwtracing/coresight/Kconfig   |  11 +
>  drivers/hwtracing/coresight/Makefile  |   1 +
>  drivers/hwtracing/coresight/coresight-cpu-debug.c | 704 
> ++
>  3 files changed, 716 insertions(+)
>  create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c
> 
> diff --git a/drivers/hwtracing/coresight/Kconfig 
> b/drivers/hwtracing/coresight/Kconfig
> index 130cb21..18d7931 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -89,4 +89,15 @@ config CORESIGHT_STM
> logging useful software events or data coming from various entities
> in the system, possibly running different OSs
>  
> +config CORESIGHT_CPU_DEBUG
> + tristate "CoreSight CPU Debug driver"
> + depends on ARM || ARM64
> + depends on DEBUG_FS
> + help
> +   This driver provides support for coresight debugging module. This
> +   is primarily used to dump sample-based profiling registers when
> +   system triggers panic, the driver will parse context registers so
> +   can quickly get to know program counter (PC), secure state,
> +   exception level, etc.
> +
>  endif
> diff --git a/drivers/hwtracing/coresight/Makefile 
> b/drivers/hwtracing/coresight/Makefile
> index af480d9..433d590 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
>   coresight-etm4x-sysfs.o
>  obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
>  obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
> +obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
> diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c 
> b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> new file mode 100644
> index 000..fbec1d1
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
> @@ -0,0 +1,704 @@
> +/*
> + * Copyright (c) 2017 Linaro Limited. All rights reserved.
> + *
> + * Author: Leo Yan 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + *
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#incl

[PATCH 10/10] coresight: documenting range and start/stop filtering

[Mathieu Poirier]

To reduce the amount of traces generated by tracers range
and start/stop address filtering has been implemented.  This
patch provides example on how to use the various options
currently supported.

Signed-off-by: Mathieu Poirier 
Cc: linux-doc@vger.kernel.org
---
 Documentation/trace/coresight.txt | 48 +++
 1 file changed, 48 insertions(+)

diff --git a/Documentation/trace/coresight.txt 
b/Documentation/trace/coresight.txt
index a2e7ccb62c2b..a19d7e60937a 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -408,6 +408,54 @@ Instruction 135708310x8026B584  E28DD00C   
 false   ADD
 Instruction 0   0x8026B588  E8BD8000trueLDM  
sp!,{pc}
 Timestamp   Timestamp: 17107041535
 
+Address filtering
+-
+
+CoreSight tracers produce an astonishing amount of traces, more often than not
+much more than trace buffers can handle, and definilty far beyond the
+processing capabilities of humans.  To trim down the amount of trace generated
+address filters can be specified from the perf command line.
+
+Currently supported filters include range and start/stop address.  When a
+range is specified traces will be collected when the instruction pointer falls
+within the specified addresses.  For start and stop filters, traces collection
+start when the instuction pointer matches the start address, and stop when
+the stop address has been reached.
+
+Filters can be specified from the perf command line as follow:
+
+- To start trace collection when the IP equal a specific function in a binary
+  executable or library:
+
+   perf record -e cs_etm// --filter 'start 
0x72c@/opt/lib/libcstest.so.1.0' --per-thread ./main
+
+- To stop trace collection when the IP equal a specific function in a binary
+  executable of library:
+
+   perf record -e cs_etm// --filter 'stop 0x790@/opt/lib/libcstest.so.1.0' 
--per-thread ./main
+
+- To start and stop tracing at various stages of kernel execution:
+
+   perf record -e cs_etm// --filter 'start 0xff800856bc50,stop 
0xff800856bcb0,start 0xff8008562d0c,stop 0xff8008562d30' 
--per-thread uname
+
+The only requirement on the number of start/stop filters is that they don't go
+beyond the amount of comparator implemented on the system.  Range filters are
+specified using a slightly different syntax:
+
+- To collect traces in a specific range in a binary executable or a library:
+
+   perf record -e cs_etm// --filter 'filter 
0x72c/0x40@/opt/lib/libcstest.so.1.0' --per-thread ./main
+
+- To collect traces in a specific range in kernel space:
+
+   perf record -e cs_etm// --filter 'filter 0xff8008562d0c/0x48' 
--per-thread  uname
+
+This time the number of comparator _pairs_ implemented in the trace engine is
+the only restriction on the amount of filters that can be specified.
+
+It is possible to mix user and kernel space filters, as long as they are the
+same type.  Mixing range and start/stop filters is currently not supported.
+
 How to use the STM module
 -
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V5 0/4] Introduce CoreSight STM support

[Mathieu Poirier]

On 6 April 2016 at 20:51, Chunyan Zhang  wrote:
> This patchset adds support for the CoreSight STM IP block.

This has been out there long enough - I'm picking this up.

Alex, I'll have 1/4 go through my tree.  Get back to me if you want to
proceed differently.

Thanks,
Mathieu

>
> Changes from V4:
>  - Rebased the whole patch set onto [4] (v4.6-rc1).
>  - Made a few minor modifications according to the code changes since v4.5.
>  - Replaced the original 1/4 with a new patch the Alex provided.
>  - Another new patch 2/4 in this set is for storing path from CS-STM to sink.
>  - Addressed comments from V4.
>  - Removed coresight_simple_func() from CS-STM driver, used the common 
> definition instead.
>  - Modified STM tracer-id from an arbitrary value 0x20 to 0x1.
>  - Replaced module_amba_driver() with builtin_amba_driver() according to [5].
>  - Used driver->suppress_bind_attr to prevent CS-STM being unbound from the 
> driver.
>  - Updated the kernel version (4.7) and month in 
> sysfs-bus-coresight-devices-stm.
>  - Replaced 'mshared' with 'hw_override' in CS-STM driver.
>  - Initialized sw_start and sw_end with 1.
>  - Returned a size of '1' after processing FLAG packets.
>  - Removed pre-compile option 'CONFIG_64BIT' for the packet size of 8.
>  - Added Michael Williams's Reviewed-by in 4/4.
>
> Changes from V3:
>  - Removed ioctl get_options interface from the generic STM code and 
> CoreSight STM driver.
>  - Removed 'write_max' from the structure 'stm_drvdata', and changed 
> 'write_64bit' to 'write_bytes'.
>  - Revised stm_fundamental_data_size() to return the fundamental data size 
> instead of 0/1.
>  - Removed stm_remove() from the driver.
>  - Revised the return value of ::packet() callback function according to [2].
>  - Modified stm_send() to send one STP packet at a time.
>  - Added comments to invariant/guaranteed CoreSight STM transaction mode.
>
> Changes from V2:
>  - Changed to return -EFAULT if failed on the command STP_GET_OPTIONS.
>  - Used Alex's patch [1] instead of the last 2/6.
>  - Removed the while loop from stm_send(), since the packet size passed
>to it isn't larger than 4 bytes on 32-bit system and 8 bytes on
>64-bit system.
>  - Removed stm_send_64bit(), since the process of packets on 64-bit
>CS-STM should be basically the same with on 32-bit system, except the
>maximum length of writing STM at a time.
>  - Removed the support of writing 64-bit to CoreSight STM buffer at a time
>on 32-bit ARM architecture according to an ARM engineer suggestion.  As
>he said that the STM might receive a 64-bit write, or might receive a
>pair of 32-bit writes to the two addressed words in either order.
>So 64-bit write isn't guaranteed to work on the ARM 32-bit architecture.
>
> Changes from v1:
>  - Added a definition of coresight_simple_func() in CS-STM driver to
>avoid the kbuild test robot error for the time being.  This
>modification will be removed when merging the code in which the
>coresight_simple_func() has been moved to the header file.
>  - Calculate the channel number according to the channel memory space size.
>
>
> Thanks,
> Chunyan
>
> [1] https://lkml.org/lkml/2016/2/4/652
> [2] https://lkml.org/lkml/2016/2/12/397
> [3] https://lkml.org/lkml/2015/12/22/348
> [4] https://git.linaro.org/kernel/coresight.git/shortlog/refs/heads/next
> [5] http://www.spinics.net/lists/kernel/msg2187320.html
>
> Alexander Shishkin (1):
>   stm class: Support devices that override software assigned masters
>
> Mathieu Poirier (2):
>   coresight: adding path for STM device
>   coresight-stm: Bindings for System Trace Macrocell
>
> Pratik Patel (1):
>   coresight-stm: adding driver for CoreSight STM component
>
>  .../ABI/testing/sysfs-bus-coresight-devices-stm|  53 ++
>  Documentation/ABI/testing/sysfs-class-stm  |  10 +
>  .../devicetree/bindings/arm/coresight.txt  |  28 +
>  Documentation/trace/coresight.txt  |  37 +-
>  drivers/hwtracing/coresight/Kconfig|  11 +
>  drivers/hwtracing/coresight/Makefile   |   1 +
>  drivers/hwtracing/coresight/coresight-stm.c| 918 
> +
>  drivers/hwtracing/coresight/coresight.c| 106 ++-
>  drivers/hwtracing/stm/core.c   |  15 +
>  include/linux/coresight-stm.h  |   6 +
>  include/linux/stm.h|   3 +
>  include/uapi/linux/coresight-stm.h |  21 +
>  12 files changed, 1183 insertions(+), 26 deletions(-)
>  create mode 100644 Documentation/ABI/

Re: [RESEND PATCH V4 1/4] stm class: provision for statically assigned masterIDs

[Mathieu Poirier]

On 31 March 2016 at 07:20, Alexander Shishkin
 wrote:
> Mathieu Poirier  writes:
>
>> On 21 March 2016 at 01:47, Alexander Shishkin
>>  wrote:
>>> Chunyan Zhang  writes:
>>>
>>>> From: Mathieu Poirier 
>>>>
>>>> Some architecture like ARM assign masterIDs at the HW design
>>>> phase.  Those are therefore unreachable to users, making masterID
>>>> management in the generic STM core irrelevant.
>>>>
>>>> In this kind of configuration channels are shared between masters
>>>> rather than being allocated on a per master basis.
>>>>
>>>> This patch adds a new 'mshared' flag to struct stm_data that tells the
>>>> core that this specific STM device doesn't need explicit masterID
>>>> management.
>>>
>>> There are two kinds of 'masterIDs' that we're talking about here: the
>>> ones that turn up in the STP stream and the ones that are accessible to
>>> trace-side software (sw_start/sw_end). So in this case we want to
>>> reflect the fact that there is no correlation between the two, because
>>> hardware assigns STP channels dynamically based on the states of the
>>> trace/execution environment. And although the trace side software can do
>>> very little with this information, it does make sense to provide it.
>>>
>>> The sw_start==sw_end situation, on the other hand, is a side effect of
>>> the above and, as I said in one of the previous threads, may not even be
>>> the case, or at least I don't see why it has to. And when it is the
>>> case, I don't see the point in handling it differently from
>>> sw_start
> [snip]
>
>> Other than the above, is there anything you'd like to see modified in
>> this patch, i.e how the mshared flag is used to modify the output in
>> sysFS/configFS?
>
> Yes, the two paragraphs quoted above that had gone unnoticed. I've
> been thinking some more about this and came up with the following. No
> need to do any extra handling in the policy code or anywhere else.

I read the above two paragraphs many times but simply couldn't find
anything actionable in there.

>
> From 8be22a8e391b94ec13d428976e7b1410aa59991e Mon Sep 17 00:00:00 2001
> From: Alexander Shishkin 
> Date: Thu, 31 Mar 2016 15:51:29 +0300
> Subject: [PATCH] stm class: Support devices that override software assigned
>  masters
>
> Some STM devices adjust software assigned master numbers depending on
> the trace source and its runtime state and whatnot. This patch adds
> a sysfs attribute to inform the trace-side software that master numbers
> assigned to software sources will not match those in the STP stream,
> so that, for example, master/channel allocation policy can be adjusted
> accordingly.
>
> Signed-off-by: Alexander Shishkin 
> ---
>  Documentation/ABI/testing/sysfs-class-stm | 10 ++
>  drivers/hwtracing/stm/core.c  | 15 +++
>  include/linux/stm.h   |  3 +++
>  3 files changed, 28 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-stm 
> b/Documentation/ABI/testing/sysfs-class-stm
> index c9aa4f3fc9..77ed3da0f6 100644
> --- a/Documentation/ABI/testing/sysfs-class-stm
> +++ b/Documentation/ABI/testing/sysfs-class-stm
> @@ -12,3 +12,13 @@ KernelVersion:   4.3
>  Contact:   Alexander Shishkin 
>  Description:
> Shows the number of channels per master on this STM device.
> +
> +What:  /sys/class/stm//hw_override
> +Date:  March 2016
> +KernelVersion: 4.7
> +Contact:   Alexander Shishkin 
> +Description:
> +   Reads as 0 if master numbers in the STP stream produced by
> +   this stm device will match the master numbers assigned by
> +   the software or 1 if the stm hardware overrides software
> +   assigned masters.
> diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
> index 2591442e2c..ff31108b06 100644
> --- a/drivers/hwtracing/stm/core.c
> +++ b/drivers/hwtracing/stm/core.c
> @@ -67,9 +67,24 @@ static ssize_t channels_show(struct device *dev,
>
>  static DEVICE_ATTR_RO(channels);
>
> +static ssize_t hw_override_show(struct device *dev,
> +   struct device_attribute *attr,
> +   char *buf)
> +{
> +   struct stm_device *stm = to_stm_device(dev);
> +   int ret;
> +
> +   ret = sprintf(buf, "%u\n", stm->data->hw_override);
> +
> +   return ret;
> +}
> +
> +static DEVICE_ATTR_RO(hw_override

Re: [RESEND PATCH V4 0/4] Introduce CoreSight STM support

[Mathieu Poirier]

On 7 March 2016 at 23:33, Chunyan Zhang  wrote:
> This patchset adds support for the CoreSight STM IP block.
>
> In the fourth version, comments from various people have been
> addressed.  Representing configurations where channels are shared
> between multiple masterIDs has been kept unchanged from the previous
> version because a viable alternative hasn't been suggested.
>
> This RESEND PATCH 1/4 depends on the patch [3] which has been
> merged into linux-next.

We are not going anywhere with 1/4.  Since the functionality conveyed
by that patch isn't strictly needed simply drop it (along with 2/4).
Please take into consideration the comments I made on 4/4 and respin
on 4.6-rc1 when it comes out.

Thanks,
Mathieu

>
> Changes from V3:
>  - Removed ioctl get_options interface from the generic STM code and 
> CoreSight STM driver.
>  - Removed 'write_max' from the structure 'stm_drvdata', and changed 
> 'write_64bit' to 'write_bytes'.
>  - Revised stm_fundamental_data_size() to return the fundamental data size 
> instead of 0/1.
>  - Removed stm_remove() from the driver.
>  - Revised the return value of ::packet() callback function according to [2].
>  - Modified stm_send() to send one STP packet at a time.
>  - Added comments to invariant/guaranteed CoreSight STM transaction mode.
>
> Changes from V2:
>  - Changed to return -EFAULT if failed on the command STP_GET_OPTIONS.
>  - Used Alex's patch [1] instead of the last 2/6.
>  - Removed the while loop from stm_send(), since the packet size passed
>to it isn't larger than 4 bytes on 32-bit system and 8 bytes on
>64-bit system.
>  - Removed stm_send_64bit(), since the process of packets on 64-bit
>CS-STM should be basically the same with on 32-bit system, except the
>maximum length of writing STM at a time.
>  - Removed the support of writing 64-bit to CoreSight STM buffer at a time
>on 32-bit ARM architecture according to an ARM engineer suggestion.  As
>he said that the STM might receive a 64-bit write, or might receive a
>pair of 32-bit writes to the two addressed words in either order.
>So 64-bit write isn't guaranteed to work on the ARM 32-bit architecture.
>
> Changes from v1:
>  - Added a definition of coresight_simple_func() in CS-STM driver to
>avoid the kbuild test robot error for the time being.  This
>modification will be removed when merging the code in which the
>coresight_simple_func() has been moved to the header file.
>  - Calculate the channel number according to the channel memory space size.
>
>
> Thanks,
> Chunyan
>
> [1] https://lkml.org/lkml/2016/2/4/652
> [2] https://lkml.org/lkml/2016/2/12/397
> [3] https://lkml.org/lkml/2015/12/22/348
>
> Chunyan Zhang (1):
>   Documentations: Add explanations of the case for non-configurable
> masters
>
> Mathieu Poirier (2):
>   stm class: provision for statically assigned masterIDs
>   coresight-stm: Bindings for System Trace Macrocell
>
> Pratik Patel (1):
>   coresight-stm: adding driver for CoreSight STM component
>
>  .../ABI/testing/sysfs-bus-coresight-devices-stm|  53 ++
>  .../devicetree/bindings/arm/coresight.txt  |  28 +
>  Documentation/trace/coresight.txt  |  37 +-
>  Documentation/trace/stm.txt|   6 +
>  drivers/hwtracing/coresight/Kconfig|  11 +
>  drivers/hwtracing/coresight/Makefile   |   1 +
>  drivers/hwtracing/coresight/coresight-stm.c| 890 
> +
>  drivers/hwtracing/stm/core.c   |  17 +-
>  drivers/hwtracing/stm/policy.c |  18 +-
>  include/linux/coresight-stm.h  |   6 +
>  include/linux/stm.h|   8 +
>  include/uapi/linux/coresight-stm.h |  21 +
>  12 files changed, 1090 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>  create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
>  create mode 100644 include/linux/coresight-stm.h
>  create mode 100644 include/uapi/linux/coresight-stm.h
>
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH V4 4/4] coresight-stm: adding driver for CoreSight STM component

[Mathieu Poirier]

On 7 March 2016 at 23:33, Chunyan Zhang  wrote:
> From: Pratik Patel 
>
> This driver adds support for the STM CoreSight IP block, allowing any
> system compoment (HW or SW) to log and aggregate messages via a
> single entity.
>
> The CoreSight STM exposes an application defined number of channels
> called stimulus port.  Configuration is done using entries in sysfs
> and channels made available to userspace via configfs.
>
> Signed-off-by: Pratik Patel 
> Signed-off-by: Mathieu Poirier 
> Signed-off-by: Chunyan Zhang 
> ---
>  .../ABI/testing/sysfs-bus-coresight-devices-stm|  53 ++
>  Documentation/trace/coresight.txt  |  37 +-
>  drivers/hwtracing/coresight/Kconfig|  11 +
>  drivers/hwtracing/coresight/Makefile   |   1 +
>  drivers/hwtracing/coresight/coresight-stm.c| 890 
> +
>  include/linux/coresight-stm.h  |   6 +
>  include/uapi/linux/coresight-stm.h |  21 +
>  7 files changed, 1017 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>  create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
>  create mode 100644 include/linux/coresight-stm.h
>  create mode 100644 include/uapi/linux/coresight-stm.h
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm 
> b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
> new file mode 100644
> index 000..c519056
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
> @@ -0,0 +1,53 @@
> +What:  /sys/bus/coresight/devices/.stm/enable_source
> +Date:  February 2016
> +KernelVersion: 4.5
> +Contact:   Mathieu Poirier 
> +Description:   (RW) Enable/disable tracing on this specific trace macrocell.
> +   Enabling the trace macrocell implies it has been configured
> +   properly and a sink has been identified for it.  The path
> +   of coresight components linking the source to the sink is
> +   configured and managed automatically by the coresight 
> framework.

Please update the kernel version (4.7) and month.

> +
> +What:      /sys/bus/coresight/devices/.stm/hwevent_enable
> +Date:  February 2016
> +KernelVersion: 4.5
> +Contact:   Mathieu Poirier 
> +Description:   (RW) Provides access to the HW event enable register, used in
> +   conjunction with HW event bank select register.
> +
> +What:  /sys/bus/coresight/devices/.stm/hwevent_select
> +Date:  February 2016
> +KernelVersion: 4.5
> +Contact:   Mathieu Poirier 
> +Description:   (RW) Gives access to the HW event block select register
> +   (STMHEBSR) in order to configure up to 256 channels.  Used in
> +   conjunction with "hwevent_enable" register as described above.
> +
> +What:  /sys/bus/coresight/devices/.stm/port_enable
> +Date:  February 2016
> +KernelVersion: 4.5
> +Contact:   Mathieu Poirier 
> +Description:   (RW) Provides access to the stimulus port enable register
> +   (STMSPER).  Used in conjunction with "port_select" described
> +   below.
> +
> +What:  /sys/bus/coresight/devices/.stm/port_select
> +Date:  February 2016
> +KernelVersion: 4.5
> +Contact:   Mathieu Poirier 
> +Description:   (RW) Used to determine which bank of stimulus port bit in
> +   register STMSPER (see above) apply to.
> +
> +What:  /sys/bus/coresight/devices/.stm/status
> +Date:  February 2016
> +KernelVersion: 4.5
> +Contact:   Mathieu Poirier 
> +Description:   (R) List various control and status registers.  The specific
> +   layout and content is driver specific.
> +
> +What:  /sys/bus/coresight/devices/.stm/traceid
> +Date:  February 2016
> +KernelVersion: 4.5
> +Contact:   Mathieu Poirier 
> +Description:   (RW) Holds the trace ID that will appear in the trace stream
> +   coming from this trace entity.
> diff --git a/Documentation/trace/coresight.txt 
> b/Documentation/trace/coresight.txt
> index 0a5c329..a33c88c 100644
> --- a/Documentation/trace/coresight.txt
> +++ b/Documentation/trace/coresight.txt
> @@ -190,8 +190,8 @@ expected to be accessed and controlled using those 
> entries.
>  Last but not least, "struct module *owner" is expected to be set to reflect
>  the information carried in "THIS_MODULE".
>
> -How to use
> ---
> +How to use the tracer modules
> +-
>
>  Before trace collection can start, a coresight 

Re: [RESEND PATCH V4 1/4] stm class: provision for statically assigned masterIDs

[Mathieu Poirier]

On 21 March 2016 at 01:47, Alexander Shishkin
 wrote:
> Chunyan Zhang  writes:
>
>> From: Mathieu Poirier 
>>
>> Some architecture like ARM assign masterIDs at the HW design
>> phase.  Those are therefore unreachable to users, making masterID
>> management in the generic STM core irrelevant.
>>
>> In this kind of configuration channels are shared between masters
>> rather than being allocated on a per master basis.
>>
>> This patch adds a new 'mshared' flag to struct stm_data that tells the
>> core that this specific STM device doesn't need explicit masterID
>> management.
>
> There are two kinds of 'masterIDs' that we're talking about here: the
> ones that turn up in the STP stream and the ones that are accessible to
> trace-side software (sw_start/sw_end). So in this case we want to
> reflect the fact that there is no correlation between the two, because
> hardware assigns STP channels dynamically based on the states of the
> trace/execution environment. And although the trace side software can do
> very little with this information, it does make sense to provide it.
>
> The sw_start==sw_end situation, on the other hand, is a side effect of
> the above and, as I said in one of the previous threads, may not even be
> the case, or at least I don't see why it has to. And when it is the
> case, I don't see the point in handling it differently from
> sw_start
>> In the core sw_start/end of masterID are set to '1',
>> i.e there is only one masterID to deal with.
>
> Why does this need to be done in the core and why '1'? IOW,
> sw_{start,end} come straight from the driver, this new 'mshared' comes
> straight from the driver, why do we need the core to modify the former
> based on the latter?

The logic here was to account for drivers that only set the 'mshared'
flag.  One could (wrongly) assume that if mshared is set in the
driver, sw_{start,end} are don't need to be set.  That way errors are
caught quicker.  I'm fine with removing that part.

Other than the above, is there anything you'd like to see modified in
this patch, i.e how the mshared flag is used to modify the output in
sysFS/configFS?

Thanks,
Mathieu

>
>> Also this patch depends on [1], so that the number of masterID
>> is '1' too.
>
> It's 7b3bb0e753 in Linus' tree, but I don't see the logical connection
> in the statement above.

That statement should have appeared in the cover letter rather than
this patch's blurb - that way it applies cleanly.

>
> Regards,
> --
> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

[Mathieu Poirier]

On 12 February 2016 at 13:33, Mathieu Poirier
 wrote:
> On 12 February 2016 at 09:27, Alexander Shishkin
>  wrote:
>> Mathieu Poirier  writes:
>>
>>> On 8 February 2016 at 06:26, Alexander Shishkin
>>>  wrote:
>>>> This $end==$start situation itself may be ambiguous and can be
>>>> interpreted either as having just one *static* master ID fixed for all
>>>> SW writers (what I assumed from your commit message) or as having a
>>>> floating master ID, which changes of its own accord and is not
>>>> controllable by software.
>>>
>>> Some clarification here.
>>>
>>> On ARM from a SW point of view $end == $start and that doesn't change
>>> (with regards to masterIDs) .  The ambiguity comes from the fact that
>>> on other platforms where masterID configuration does change and is
>>> important, the condition $end == $start could also be valid.
>>
>> Yes, that's what I was saying. The thing is, on the system-under-tracing
>> side these two situations are not very different from one
>> another. Master IDs are really just numbers without any semantics
>> attached to them in the sense that they are not covered by the mipi spec
>> or any other standard (to my knowledge).
>
> We are definitely on the same page here, just using slightly different terms.
>
>>
>> The difference is in the way we map channels to masters. One way is to
>> allocate a distinct set of channels for each master (the way Intel Trace
>> Hub does it); another way is to share the same set of channels between
>> multiple masters.
>
> We are in total agreement.
>
>> So we can describe this as "hardware implements the
>> same set of channels across multiple masters" or something along those
>> lines.
>
> I suggest "Shared channels"?  In the end, that's really what it is...
>
> The outstanding issue is still how to represent these to different way
> of mapping things in the STM core.  I suggested a flag, called
> "mstatic" (but that can be changed), and a representation of '-1' in
> for masterIDs sysFS.  Whether we stick with that or not is irrelevant,
> I'd be fine with another mechanism.  What I am keen on is that from
> sysFS users can quickly tell which heuristic is enacted on that
> specific architecture.

Alex,

How do you want to proceed with the above?  Do you agree with my
current proposal or can you think of a better way?

Thanks,
Mathieu


>
>>
>> Actually, in the latter scheme of things you can also have multiple
>> masters, at least theoretically. Say, you have masters [0..15], each
>> with distinct set of channels, but depending on hardware state these
>> masters actually end up as $state*16+$masterID in the STP stream.
>>
>> So we might also think about differentiating between the hardware
>> masters (0 though 15 in the above example) and STP masters.
>
> I'm not sure I get what you mean here.  On ARM the masterIDs assigned
> in HW, which will depend on the state, will show up in the STP stream.
> But again, I might be missing your point.
>
> Thanks,
> Mathieu
>
>>
>> Regards,
>> --
>> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

[Mathieu Poirier]

On 12 February 2016 at 09:27, Alexander Shishkin
 wrote:
> Mathieu Poirier  writes:
>
>> On 8 February 2016 at 06:26, Alexander Shishkin
>>  wrote:
>>> This $end==$start situation itself may be ambiguous and can be
>>> interpreted either as having just one *static* master ID fixed for all
>>> SW writers (what I assumed from your commit message) or as having a
>>> floating master ID, which changes of its own accord and is not
>>> controllable by software.
>>
>> Some clarification here.
>>
>> On ARM from a SW point of view $end == $start and that doesn't change
>> (with regards to masterIDs) .  The ambiguity comes from the fact that
>> on other platforms where masterID configuration does change and is
>> important, the condition $end == $start could also be valid.
>
> Yes, that's what I was saying. The thing is, on the system-under-tracing
> side these two situations are not very different from one
> another. Master IDs are really just numbers without any semantics
> attached to them in the sense that they are not covered by the mipi spec
> or any other standard (to my knowledge).

We are definitely on the same page here, just using slightly different terms.

>
> The difference is in the way we map channels to masters. One way is to
> allocate a distinct set of channels for each master (the way Intel Trace
> Hub does it); another way is to share the same set of channels between
> multiple masters.

We are in total agreement.

> So we can describe this as "hardware implements the
> same set of channels across multiple masters" or something along those
> lines.

I suggest "Shared channels"?  In the end, that's really what it is...

The outstanding issue is still how to represent these to different way
of mapping things in the STM core.  I suggested a flag, called
"mstatic" (but that can be changed), and a representation of '-1' in
for masterIDs sysFS.  Whether we stick with that or not is irrelevant,
I'd be fine with another mechanism.  What I am keen on is that from
sysFS users can quickly tell which heuristic is enacted on that
specific architecture.

>
> Actually, in the latter scheme of things you can also have multiple
> masters, at least theoretically. Say, you have masters [0..15], each
> with distinct set of channels, but depending on hardware state these
> masters actually end up as $state*16+$masterID in the STP stream.
>
> So we might also think about differentiating between the hardware
> masters (0 though 15 in the above example) and STP masters.

I'm not sure I get what you mean here.  On ARM the masterIDs assigned
in HW, which will depend on the state, will show up in the STP stream.
But again, I might be missing your point.

Thanks,
Mathieu

>
> Regards,
> --
> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 6/6] coresight-stm: adding driver for CoreSight STM component

[Mathieu Poirier]

On 12 February 2016 at 08:28, Alexander Shishkin
 wrote:
> Chunyan Zhang  writes:
>
>> +static long stm_generic_set_options(struct stm_data *stm_data,
>> + unsigned int master,
>> + unsigned int channel,
>> + unsigned int nr_chans,
>> + unsigned long options)
>> +{
>> + struct stm_drvdata *drvdata = container_of(stm_data,
>> +struct stm_drvdata, stm);
>> + if (!(drvdata && drvdata->enable))
>> + return -EINVAL;
>> +
>> + if (channel >= drvdata->numsp)
>> + return -EINVAL;
>> +
>> + switch (options) {
>> + case STM_OPTION_GUARANTEED:
>> + set_bit(channel, drvdata->chs.guaranteed);
>> + break;
>> +
>> + case STM_OPTION_INVARIANT:
>> + clear_bit(channel, drvdata->chs.guaranteed);
>> + break;
>
> This is a bad interface. Firstly, neither option is described
> anywhere. Secondly, I'm pretty sure "invariant" does not mean "not
> guaranteed" in english, although this function seems to imply this.

Regardless of the semantic associated to the word "invariant" in the
English language, the documentation characterises a channel configured
in best effort delivery mode as "invariant".  This is also the
opposite of the "guaranteed" mode where packets are guaranteed to be
delivered.  Adding a few comments here is probably a good idea.

>
>> +
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static long stm_generic_get_options(struct stm_data *stm_data,
>> + unsigned int master,
>> + unsigned int channel,
>> + unsigned int nr_chans,
>> + u64 *options)
>> +{
>> + struct stm_drvdata *drvdata = container_of(stm_data,
>> +struct stm_drvdata, stm);
>> + if (!(drvdata && drvdata->enable))
>> + return -EINVAL;
>> +
>> + if (channel >= drvdata->numsp)
>> + return -EINVAL;
>> +
>> + switch (*options) {
>> + case STM_OPTION_GUARANTEED:
>> + *options = test_bit(channel, drvdata->chs.guaranteed);
>> + break;
>
> This just doesn't work. @options here is an on-stack variable in
> stm_char_ioctl(), hitherto uninitialized. The get_options ioctl command
> as you implemented it doesn't fetch @options from userspace either, it
> just passes a pointer to it to this callback, expecting that the
> callback will set it so that it can be copy_to_user()ed back to the
> user.

Yes, that was the intended behaviour - to allow user space to see in
what mode channels are configured (guaranteed/invariant).

>
> Then, when we figure this out, there is again the question of what
> should one make of STM_OPTION_{GUARANTEED,INVARIANT} and how do they fit
> into *options.

The interface asks if the channel is configured in "guaranteed" mode.
If not and because there isn't another mode available, it is
automatically in "invariant" mode.

But as I pointed out in my earlier email this may no longer needed.
One has to issue a system call anyway, might as well just go ahead
with the configuration request.

Thanks,
Mathieu

>
> The idea behind set_options ioctl is that the user specifies a bit mask
> of options that he/she wants to set.
>
> [snip]
>
>> +#ifndef __UAPI_CORESIGHT_STM_H_
>> +#define __UAPI_CORESIGHT_STM_H_
>> +
>> +#define STM_FLAG_TIMESTAMPED   BIT(3)
>> +#define STM_FLAG_GUARANTEEDBIT(7)
>> +
>> +enum {
>> + STM_OPTION_GUARANTEED = 0,
>> + STM_OPTION_INVARIANT,
>> +};
>
> Each of these guys could also use an explanation.
>
> Regards,
> --
> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 1/6] stm class: Add ioctl get_options interface

[Mathieu Poirier]

On 12 February 2016 at 08:18, Alexander Shishkin
 wrote:
> Chunyan Zhang  writes:
>
>> There is already an interface of set_options, but no get_options yet.
>> Before setting any options, one would may want to see the current
>> status of that option by means of get_options interface. This
>> interface has been used in CoreSight STM driver.
>
> I'm not sure I understand the reasoning behind this. If a userspace
> program opens a communication channel and wants to configure certain
> features on it, why does its choice depend on what has been configured
> for this channel previously? It can be anything at all. Most likely,
> it's either unconfigured or configured to its default values, but why
> does this matter for a new writer?

A client may wish to change the settings (invariant/guaranteed) it has
on a specific channel - it may even want to so do multiple times.  The
idea behind introducing a get_options() was to probe the specific
settings of a channel before going a head with a new configuration.
In hindsight it may not be needed as a client should simply go ahead
and push down the configuration it wants.

>
> Regards,
> --
> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 6/6] coresight-stm: adding driver for CoreSight STM component

[Mathieu Poirier]

On 12 February 2016 at 07:55, Michael Williams  wrote:
> Mathieu Poirier [mailto:mathieu.poir...@linaro.org] wrote:
>> On 6 February 2016 at 04:04, Chunyan Zhang  wrote:
>>> From: Pratik Patel 
>>>
>>> This driver adds support for the STM CoreSight IP block, allowing any
>>> system compoment (HW or SW) to log and aggregate messages via a
>>> single entity.
>>>
>>> The CoreSight STM exposes an application defined number of channels
>>> called stimulus port.  Configuration is done using entries in sysfs
>>> and channels made available to userspace via configfs.
>>>
>>> Signed-off-by: Pratik Patel 
>>> Signed-off-by: Mathieu Poirier 
>>> Signed-off-by: Chunyan Zhang 
>>> ---
>>>  .../ABI/testing/sysfs-bus-coresight-devices-stm|  53 ++
>>>  Documentation/trace/coresight.txt  |  37 +-
>>>  drivers/hwtracing/coresight/Kconfig|  11 +
>>>  drivers/hwtracing/coresight/Makefile   |   1 +
>>>  drivers/hwtracing/coresight/coresight-stm.c| 928 
>>> +
>>>  include/linux/coresight-stm.h  |   6 +
>>>  include/uapi/linux/coresight-stm.h |  12 +
>>>  7 files changed, 1046 insertions(+), 2 deletions(-)
>>>  create mode 100644 
>>> Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>>>  create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
>>>  create mode 100644 include/linux/coresight-stm.h
>>>  create mode 100644 include/uapi/linux/coresight-stm.h
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm 
>>> b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>>> new file mode 100644
>>> index 000..a1d7022
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>>> @@ -0,0 +1,53 @@
>>> +What:  /sys/bus/coresight/devices/.stm/enable_source
>>> +Date:  February 2016
>>> +KernelVersion: 4.5
>>> +Contact:   Mathieu Poirier 
>>> +Description:   (RW) Enable/disable tracing on this specific trace 
>>> macrocell.
>>> +   Enabling the trace macrocell implies it has been configured
>>> +   properly and a sink has been identidifed for it.  The path
>>> +   of coresight components linking the source to the sink is
>>> +   configured and managed automatically by the coresight 
>>> framework.
>>> +
>>> +What:  /sys/bus/coresight/devices/.stm/hwevent_enable
>>> +Date:  February 2016
>>> +KernelVersion: 4.5
>>> +Contact:   Mathieu Poirier 
>>> +Description:   (RW) Provides access to the HW event enable register, used 
>>> in
>>> +   conjunction with HW event bank select register.
>>> +
>>> +What:  /sys/bus/coresight/devices/.stm/hwevent_select
>>> +Date:  February 2016
>>> +KernelVersion: 4.5
>>> +Contact:   Mathieu Poirier 
>>> +Description:   (RW) Gives access to the HW event block select register
>>> +   (STMHEBSR) in order to configure up to 256 channels.  Used 
>>> in
>>> +       conjunction with "hwevent_enable" register as described 
>>> above.
>>> +
>>> +What:  /sys/bus/coresight/devices/.stm/port_enable
>>> +Date:  February 2016
>>> +KernelVersion: 4.5
>>> +Contact:   Mathieu Poirier 
>>> +Description:   (RW) Provides access to the stimlus port enable register
>>> +   (STMSPER).  Used in conjunction with "port_select" described
>>> +   below.
>>> +
>>> +What:  /sys/bus/coresight/devices/.stm/port_select
>>> +Date:  February 2016
>>> +KernelVersion: 4.5
>>> +Contact:   Mathieu Poirier 
>>> +Description:   (RW) Used to determine which bank of stimulus port bit in
>>> +   register STMSPER (see above) apply to.
>>> +
>>> +What:  /sys/bus/coresight/devices/.stm/status
>>> +Date:  February 2016
>>> +KernelVersion: 4.5
>>> +Contact:   Mathieu Poirier 
>>> +Description:   (R) List various control and status registers.  The specific
>>> +   layout and content is driver specific.
>>> +
>>> +What:  /sys/bus/coresight/devices/.stm/traceid
>>> +Date:  February 2016
>

Re: [PATCH V3 6/6] coresight-stm: adding driver for CoreSight STM component

[Mathieu Poirier]

On 6 February 2016 at 04:04, Chunyan Zhang  wrote:
> From: Pratik Patel 
>
> This driver adds support for the STM CoreSight IP block, allowing any
> system compoment (HW or SW) to log and aggregate messages via a
> single entity.
>
> The CoreSight STM exposes an application defined number of channels
> called stimulus port.  Configuration is done using entries in sysfs
> and channels made available to userspace via configfs.
>
> Signed-off-by: Pratik Patel 
> Signed-off-by: Mathieu Poirier 
> Signed-off-by: Chunyan Zhang 
> ---
>  .../ABI/testing/sysfs-bus-coresight-devices-stm|  53 ++
>  Documentation/trace/coresight.txt  |  37 +-
>  drivers/hwtracing/coresight/Kconfig|  11 +
>  drivers/hwtracing/coresight/Makefile   |   1 +
>  drivers/hwtracing/coresight/coresight-stm.c| 928 
> +
>  include/linux/coresight-stm.h  |   6 +
>  include/uapi/linux/coresight-stm.h |  12 +
>  7 files changed, 1046 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>  create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
>  create mode 100644 include/linux/coresight-stm.h
>  create mode 100644 include/uapi/linux/coresight-stm.h
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm 
> b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
> new file mode 100644
> index 000..a1d7022
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
> @@ -0,0 +1,53 @@
> +What:  /sys/bus/coresight/devices/.stm/enable_source
> +Date:  February 2016
> +KernelVersion: 4.5
> +Contact:   Mathieu Poirier 
> +Description:   (RW) Enable/disable tracing on this specific trace macrocell.
> +   Enabling the trace macrocell implies it has been configured
> +   properly and a sink has been identidifed for it.  The path
> +   of coresight components linking the source to the sink is
> +   configured and managed automatically by the coresight 
> framework.
> +
> +What:      /sys/bus/coresight/devices/.stm/hwevent_enable
> +Date:  February 2016
> +KernelVersion: 4.5
> +Contact:   Mathieu Poirier 
> +Description:   (RW) Provides access to the HW event enable register, used in
> +   conjunction with HW event bank select register.
> +
> +What:  /sys/bus/coresight/devices/.stm/hwevent_select
> +Date:  February 2016
> +KernelVersion: 4.5
> +Contact:   Mathieu Poirier 
> +Description:   (RW) Gives access to the HW event block select register
> +   (STMHEBSR) in order to configure up to 256 channels.  Used in
> +   conjunction with "hwevent_enable" register as described above.
> +
> +What:  /sys/bus/coresight/devices/.stm/port_enable
> +Date:  February 2016
> +KernelVersion: 4.5
> +Contact:   Mathieu Poirier 
> +Description:   (RW) Provides access to the stimlus port enable register
> +   (STMSPER).  Used in conjunction with "port_select" described
> +   below.
> +
> +What:  /sys/bus/coresight/devices/.stm/port_select
> +Date:  February 2016
> +KernelVersion: 4.5
> +Contact:   Mathieu Poirier 
> +Description:   (RW) Used to determine which bank of stimulus port bit in
> +   register STMSPER (see above) apply to.
> +
> +What:  /sys/bus/coresight/devices/.stm/status
> +Date:  February 2016
> +KernelVersion: 4.5
> +Contact:   Mathieu Poirier 
> +Description:   (R) List various control and status registers.  The specific
> +   layout and content is driver specific.
> +
> +What:  /sys/bus/coresight/devices/.stm/traceid
> +Date:  February 2016
> +KernelVersion: 4.5
> +Contact:   Mathieu Poirier 
> +Description:   (RW) Holds the trace ID that will appear in the trace stream
> +   coming from this trace entity.
> diff --git a/Documentation/trace/coresight.txt 
> b/Documentation/trace/coresight.txt
> index 0a5c329..a33c88c 100644
> --- a/Documentation/trace/coresight.txt
> +++ b/Documentation/trace/coresight.txt
> @@ -190,8 +190,8 @@ expected to be accessed and controlled using those 
> entries.
>  Last but not least, "struct module *owner" is expected to be set to reflect
>  the information carried in "THIS_MODULE".
>
> -How to use
> ---
> +How to use the tracer modules
> +-
>
>  Before trace collection can start, a coresight sink needs to be identify.
>

Re: [PATCH v11 4/4] Watchdog: introduce ARM SBSA watchdog driver

[Mathieu Poirier]

em counter from the cp15 interface of ARM
> +* Generic timer. We don't need to check it, because if it returns 
> "0",
> +* system would panic in very early stage.
> +*/
> +   gwdt->clk = arch_timer_get_cntfrq();
> +   gwdt->refresh_base = rf_base;
> +   gwdt->control_base = cf_base;
> +
> +   wdd = &gwdt->wdd;
> +   wdd->parent = dev;
> +   wdd->info = &sbsa_gwdt_info;
> +   wdd->ops = &sbsa_gwdt_ops;
> +   watchdog_set_drvdata(wdd, gwdt);
> +   watchdog_set_nowayout(wdd, nowayout);
> +
> +   wdd->min_timeout = 1;
> +   wdd->max_timeout = U32_MAX / gwdt->clk;
> +   /*
> +* In the single stage mode, The first signal (WS0) is ignored,
> +* the timeout is (WOR * 2), so the maximum timeout should be double.
> +*/
> +   if (!action)
> +   wdd->max_timeout *= 2;
> +
> +   wdd->timeout = DEFAULT_TIMEOUT;
> +   watchdog_init_timeout(wdd, timeout, dev);
> +
> +   status = readl(gwdt->control_base + SBSA_GWDT_WCS);
> +   if (status & SBSA_GWDT_WCS_WS1) {
> +   dev_warn(dev, "System reset by WDT.\n");
> +   wdd->bootstatus |= WDIOF_CARDRESET;
> +   }
> +
> +   ret = watchdog_register_device(wdd);
> +   if (ret)
> +   return ret;
> +
> +   /*
> +* Update timeout to WOR.
> +* Because of the explicit watchdog refresh mechanism,
> +* it's also a ping, if watchdog is enabled.
> +*/
> +   sbsa_gwdt_set_timeout(wdd, wdd->timeout);
> +
> +   dev_info(dev, "Initialized with %ds timeout @ %u Hz, action=%d.%s\n",
> +wdd->timeout, gwdt->clk, action,
> +status & SBSA_GWDT_WCS_EN ? " [enabled]" : "");
> +
> +   return 0;
> +}
> +
> +static void sbsa_gwdt_shutdown(struct platform_device *pdev)
> +{
> +   struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
> +
> +   sbsa_gwdt_stop(&gwdt->wdd);
> +}
> +
> +static int sbsa_gwdt_remove(struct platform_device *pdev)
> +{
> +   struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
> +
> +   watchdog_unregister_device(&gwdt->wdd);
> +
> +   return 0;
> +}
> +
> +/* Disable watchdog if it is active during suspend */
> +static int __maybe_unused sbsa_gwdt_suspend(struct device *dev)
> +{
> +   struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
> +
> +   if (watchdog_active(&gwdt->wdd))
> +   sbsa_gwdt_stop(&gwdt->wdd);
> +
> +   return 0;
> +}
> +
> +/* Enable watchdog and configure it if necessary */
> +static int __maybe_unused sbsa_gwdt_resume(struct device *dev)
> +{
> +   struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
> +
> +   if (watchdog_active(&gwdt->wdd))
> +   sbsa_gwdt_start(&gwdt->wdd);
> +
> +   return 0;
> +}
> +
> +static const struct dev_pm_ops sbsa_gwdt_pm_ops = {
> +   SET_SYSTEM_SLEEP_PM_OPS(sbsa_gwdt_suspend, sbsa_gwdt_resume)
> +};
> +
> +static const struct of_device_id sbsa_gwdt_of_match[] = {
> +   { .compatible = "arm,sbsa-gwdt", },
> +   {},
> +};
> +MODULE_DEVICE_TABLE(of, sbsa_gwdt_of_match);
> +
> +static const struct platform_device_id sbsa_gwdt_pdev_match[] = {
> +   { .name = "sbsa-gwdt", },
> +   {},
> +};
> +MODULE_DEVICE_TABLE(platform, sbsa_gwdt_pdev_match);
> +
> +static struct platform_driver sbsa_gwdt_driver = {
> +   .driver = {
> +   .name = "sbsa-gwdt",
> +   .pm = &sbsa_gwdt_pm_ops,
> +   .of_match_table = sbsa_gwdt_of_match,
> +   },
> +   .probe = sbsa_gwdt_probe,
> +   .remove = sbsa_gwdt_remove,
> +   .shutdown = sbsa_gwdt_shutdown,
> +   .id_table = sbsa_gwdt_pdev_match,
> +};
> +
> +module_platform_driver(sbsa_gwdt_driver);
> +
> +MODULE_DESCRIPTION("SBSA Generic Watchdog Driver");
> +MODULE_AUTHOR("Fu Wei ");
> +MODULE_AUTHOR("Suravee Suthikulpanit ");
> +MODULE_AUTHOR("Al Stone ");
> +MODULE_AUTHOR("Timur Tabi ");
> +MODULE_LICENSE("GPL v2");
> --
> 2.5.0
>

For this patch:

Reviewed-by: Mathieu Poirier 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

[Mathieu Poirier]

On 8 February 2016 at 10:44, Al Grant  wrote:
>> Mike did write "master IDs are hardwired to individual cores and core 
>> security
>> states", which make assignment for one platform very static.
>> On the flip side those will change from one system to another.
>
> It depends on your perspective.  From the perspective of a userspace
> process not pinned to a core, the master id will appear to vary
> dynamically and unpredictably as the thread migrates from one
> core to another.  (That's actually useful if the decoder wants to know
> where the thread is running at any given point, as it can find that out
> for free, without the need to track migration events.)

Right, that's the expected (and desired) behaviour.

>
> On the other hand if you are pinned (e.g. you're the kernel on a
> particular core, or you're a per-core worker thread in some thread
> pooling system) then you have a fixed master id, and then you can
> have one instance per core all using the same range of channel
> numbers, with the master id indicating the core - this saves on
> channel space compared to having to give each core its own
> range of channel space.

>From an STM core and driver point of view channel mapping works the
same way - pinning of tasks is  a kernel artefact.  The problem of
representing masterIDs in the STM core for an architecture with HW
assigned masterIDs is still unresolved.

>
> Al
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

[Mathieu Poirier]

On 8 February 2016 at 06:26, Alexander Shishkin
 wrote:
> Mathieu Poirier  writes:
>
>> On 5 February 2016 at 05:52, Alexander Shishkin
>>  wrote:
>>> Chunyan Zhang  writes:
>>>
>>>> From: Mathieu Poirier 
>>>>
>>>> Some architecture like ARM assign masterIDs statically at the HW design
>>>> phase, making masterID manipulation in the generic STM core irrelevant.
>>>>
>>>> This patch adds a new 'mstatic' flag to struct stm_data that tells the
>>>> core that this specific STM device doesn't need explicit masterID
>>>> management.
>>>
>>> So why do we need this patch? If your STM only has master 42 allocated
>>> for software sources, simply set sw_start = 42, sw_end = 42 and you're
>>> good to go, software will have exactly one channel to choose from. See
>>> also the comment from :
>>
>> On ARM each source, i.e entity capable of accessing STM channels, has
>> a different master ID set in HW.  We can't assume the IDs are
>> contiguous and from a SW point of view there is no way to probe the
>> values.
>
> Ok, it's the 'static' word that got me confused. From Mike's explanation
> it seems to me that it's the antithesis of static; the master ID
> assignment is so dynamic that it's not controllable by the software and
> may or may not reflect core id, power state, phase of the moon, etc.

Mike did write "master IDs are hardwired to individual cores and core
security states", which make assignment for one platform very static.
On the flip side those will change from one system to another.

>
>>>> In the core sw_start/end of masterID are set to '1',
>>>> i.e there is only one masterID to deal with.
>>>
>>> This is also a completely arbitrary and unnecessary requirement. Again,
>>> you can set both to 42 and it will still work.
>>
>> True - any value will do. The important thing to remember is that on
>> ARM, there is only one masterID channel (from an STM core point of
>> view).  But we could also proceed differently, see below for more
>> details.
>
> Well, we have the masters attribute with two numbers in it that define
> the range of master IDs that the software can choose from. More
> specifically to this situation:
>
>  * the number of channel ID spaces available to the SW is
>$end - $start + 1, that is, in your case, just 1;
>  * the number of master IDs for the SW to choose from is $end - $start;
>  * if $end==$start, their actual numeric value doesn't really matter,
>either for the policy definition or for the actual writers.
>
> This $end==$start situation itself may be ambiguous and can be
> interpreted either as having just one *static* master ID fixed for all
> SW writers (what I assumed from your commit message) or as having a
> floating master ID, which changes of its own accord and is not
> controllable by software.

Some clarification here.

On ARM from a SW point of view $end == $start and that doesn't change
(with regards to masterIDs) .  The ambiguity comes from the fact that
on other platforms where masterID configuration does change and is
important, the condition $end == $start could also be valid.

>From configFS, how do we tell users when masterIDs are set in HW?
That's what I wanted to highlight with the '-1'.  Regardless of the
solution we choose I think it is important that we inform, at the very
least, users when masterIDs don't matter.  We could also leave thing
as is, kill this patch and document things thoroughly.  With the
former things are obvious.

>
> These two situations are really the same thing from the perspective of
> the system under tracing. Also, both of these situations should already
> work if the driver sets both sw_start and sw_end to the same
> value.
>
> Regards,
> --
> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

[Mathieu Poirier]

On 5 February 2016 at 05:52, Alexander Shishkin
 wrote:
> Chunyan Zhang  writes:
>
>> From: Mathieu Poirier 
>>
>> Some architecture like ARM assign masterIDs statically at the HW design
>> phase, making masterID manipulation in the generic STM core irrelevant.
>>
>> This patch adds a new 'mstatic' flag to struct stm_data that tells the
>> core that this specific STM device doesn't need explicit masterID
>> management.
>
> So why do we need this patch? If your STM only has master 42 allocated
> for software sources, simply set sw_start = 42, sw_end = 42 and you're
> good to go, software will have exactly one channel to choose from. See
> also the comment from :

On ARM each source, i.e entity capable of accessing STM channels, has
a different master ID set in HW.  We can't assume the IDs are
contiguous and from a SW point of view there is no way to probe the
values.

>
>  * @sw_start:   first STP master available to software
>  * @sw_end: last STP master available to software
>
> particularly the "available to software" part. Any other kinds of
> masters the STM class code doesn't care about (yet).
>
>> In the core sw_start/end of masterID are set to '1',
>> i.e there is only one masterID to deal with.
>
> This is also a completely arbitrary and unnecessary requirement. Again,
> you can set both to 42 and it will still work.

True - any value will do. The important thing to remember is that on
ARM, there is only one masterID channel (from an STM core point of
view).  But we could also proceed differently, see below for more
details.

>
>> Also this patch depends on [1], so that the number of masterID
>> is '1' too.
>>
>> Finally the lower and upper bound for masterIDs as presented
>> in ($SYSFS)/class/stm/XYZ.stm/masters and
>> ($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters
>> are set to '-1'.  That way users can't confuse them with
>> architecture where masterID management is required (where any
>> other value would be valid).
>
> Why is this a good idea? Having the actual master there will allow
> software to know what it is and also tell the decoding side what it is
> (assuming you have more than one source in the STP stream, it might not
> be easy to figure out, unless you know it in advance).

In the ARM world masterIDs are irrelevant so why bother with them?
Writing a '-1' simply highlight this reality.

Another way of approaching the problem would be to change sw_start/end
to a bitfield that represent the valid masterIDs but in my opinion, it
is a lot of code churn for information that isn't used outside of the
decoder.

Thanks,
Mathieu

>
> I don't see how one master statically assigned to software sources is
> different from two masters or 32 masters. And I don't see any benefit of
> hiding the master id from userspace. Am I missing something?
>
> Regards,
> --
> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support

[Mathieu Poirier]

On 3 February 2016 at 10:18,   wrote:
> From: Fu Wei 
>
> This patch registers the WS0 interrupt routine to trigger panic,
> when the watchdog reachs the first stage (the half timeout).
> This function can help administrator to backup the system context
> info by panic console output or kdump (if supported), once system
> goes wrong (doesn't feed the watchdog in the half timeout).
>
> User also can skip panic by setting panic_enabled (module parameter) as 0
>
> Signed-off-by: Fu Wei 
> ---
>  Documentation/watchdog/watchdog-parameters.txt |  1 +
>  drivers/watchdog/Kconfig   | 10 +
>  drivers/watchdog/sbsa_gwdt.c   | 54 
> +++---
>  3 files changed, 60 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/watchdog/watchdog-parameters.txt 
> b/Documentation/watchdog/watchdog-parameters.txt
> index 300eb4d..31641e2 100644
> --- a/Documentation/watchdog/watchdog-parameters.txt
> +++ b/Documentation/watchdog/watchdog-parameters.txt
> @@ -286,6 +286,7 @@ nowayout: Watchdog cannot be stopped once started
>  -
>  sbsa_gwdt:
>  timeout: Watchdog timeout in seconds. (default 20s)
> +panic_enabled: Enable panic at half timeout. (default=true)
>  nowayout: Watchdog cannot be stopped once started
> (default=kernel config parameter)
>  -
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 4ab1b05..42adfdf 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -218,6 +218,16 @@ config ARM_SBSA_WATCHDOG
>   To compile this driver as module, choose M here: The module
>   will be called sbsa_gwdt.
>
> +config ARM_SBSA_WATCHDOG_PANIC
> +   bool "ARM SBSA Generic Watchdog triggers panic at the half timeout"
> +   depends on ARM_SBSA_WATCHDOG
> +   help
> + ARM SBSA Generic Watchdog will trigger panic in the first signal
> + (WS0) interrupt routine when the half timeout is reached.
> + This function can help administrator to backup the system context
> + info by panic console output or kdump (if supported).
> + But user can skip panic by setting moduleparam panic_enabled as 0.
> +
>  config ASM9260_WATCHDOG
> tristate "Alphascale ASM9260 watchdog"
> depends on MACH_ASM9260
> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
> index 5a2dba3..d18cf37 100644
> --- a/drivers/watchdog/sbsa_gwdt.c
> +++ b/drivers/watchdog/sbsa_gwdt.c
> @@ -16,18 +16,22 @@
>   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>   * GNU General Public License for more details.
>   *
> - * This SBSA Generic watchdog driver is a single stage timeout version.
> + * This SBSA Generic watchdog driver is a two stages version.
>   * Since this watchdog timer has two stages, and each stage is determined
>   * by WOR. So the timeout is (WOR * 2).
> - * When first timeout is reached, WS0 is triggered, the interrupt
> - * triggered by WS0 will be ignored, then the second watch period starts;
> - * when second timeout is reached, then WS1 is triggered, system reset.
> + * When the first stage(the half timeout) is reached, WS0 interrupt is
> + * triggered, at this moment the second watch period starts;
> + * In the WS0 interrupt routine, panic will be triggered for saving the
> + * system context.
> + * If the system is getting into trouble and cannot be reset by panic or
> + * restart properly by the kdump kernel(if supported), then the second
> + * stage (the timeout) will be reached, system will be reset by WS1.
>   *
>   * More details about the hardware specification of this device:
>   * ARM DEN0029B - Server Base System Architecture (SBSA)
>   *
>   * SBSA GWDT: |WOR---WS0WOR---WS1
> - *|timeoutreset
> + *|--half_timeout--(panic)--half_timeout--reset
>   *
>   */
>
> @@ -84,6 +88,13 @@ MODULE_PARM_DESC(timeout,
>  "Watchdog timeout in seconds. (>=0, default="
>  __MODULE_STRING(DEFAULT_TIMEOUT) ")");
>
> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
> +static bool panic_enabled = true;
> +module_param(panic_enabled, bool, 0);
> +MODULE_PARM_DESC(panic_enabled,
> +"enable panic at half timeout. (default=true)");
> +#endif
> +
>  static bool nowayout = WATCHDOG_NOWAYOUT;
>  module_param(nowayout, bool, S_IRUGO);
>  MODULE_PARM_DESC(nowayout,
> @@ -159,6 +170,16 @@ static int sbsa_gwdt_stop(struct watchdog_device *wdd)
> return 0;
>  }
>
> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
> +static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
> +{
> +   if (panic_enabled)
> +   panic("SBSA Watchdog half timeout");
> +
> +   return IRQ_HANDLED;
> +}
> +#endif
> +
>  static struct watchdog_info sbsa_gwdt_info = {
> .identity   = "SBSA Generic Watchdog",
> .options 

Re: [PATCH v10 4/5] Watchdog: introduce ARM SBSA watchdog driver

[Mathieu Poirier]

On 3 February 2016 at 10:18,   wrote:
> From: Fu Wei 
>
> According to Server Base System Architecture (SBSA) specification,
> the SBSA Generic Watchdog has two stage timeouts: the first signal (WS0)
> is for alerting the system by interrupt, the second one (WS1) is a real
> hardware reset.
>
> This patch initially implements a simple single stage watchdog driver:
> when the timeout is reached, your system will be reset by the second
> signal (WS1).
> The first signal (WS0) is ignored in this driver.
>
> This driver bases on linux kernel watchdog framework, so it can get
> timeout from module parameter and FDT at the driver init stage.
>
> Signed-off-by: Fu Wei 
> Reviewed-by: Graeme Gregory 
> Tested-by: Pratyush Anand 
> ---
>  drivers/watchdog/Kconfig |  17 +++
>  drivers/watchdog/Makefile|   1 +
>  drivers/watchdog/sbsa_gwdt.c | 322 
> +++
>  3 files changed, 340 insertions(+)
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 4f0e7be..4ab1b05 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -201,6 +201,23 @@ config ARM_SP805_WATCHDOG
>   ARM Primecell SP805 Watchdog timer. This will reboot your system 
> when
>   the timeout is reached.
>
> +config ARM_SBSA_WATCHDOG
> +   tristate "ARM SBSA Generic Watchdog"
> +   depends on ARM64
> +   depends on ARM_ARCH_TIMER
> +   select WATCHDOG_CORE
> +   help
> + ARM SBSA Generic Watchdog has two stage timeouts:
> + the first signal (WS0) is for alerting the system by interrupt,
> + the second one (WS1) is a real hardware reset.
> + More details: ARM DEN0029B - Server Base System Architecture (SBSA)
> +
> + This is a simple single stage driver: when the timeout is reached,
> + your system will be reset by WS1. The first signal (WS0) is ignored.
> +
> + To compile this driver as module, choose M here: The module
> + will be called sbsa_gwdt.
> +
>  config ASM9260_WATCHDOG
> tristate "Alphascale ASM9260 watchdog"
> depends on MACH_ASM9260
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index f566753..f9826d4 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
>
>  # ARM Architecture
>  obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
> +obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
>  obj-$(CONFIG_ASM9260_WATCHDOG) += asm9260_wdt.o
>  obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
>  obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
> new file mode 100644
> index 000..5a2dba3
> --- /dev/null
> +++ b/drivers/watchdog/sbsa_gwdt.c
> @@ -0,0 +1,322 @@
> +/*
> + * SBSA(Server Base System Architecture) Generic Watchdog driver
> + *
> + * Copyright (c) 2015, Linaro Ltd.
> + * Author: Fu Wei 
> + * Suravee Suthikulpanit 
> + * Al Stone 
> + * Timur Tabi 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License 2 as published
> + * by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * This SBSA Generic watchdog driver is a single stage timeout version.
> + * Since this watchdog timer has two stages, and each stage is determined
> + * by WOR. So the timeout is (WOR * 2).
> + * When first timeout is reached, WS0 is triggered, the interrupt
> + * triggered by WS0 will be ignored, then the second watch period starts;
> + * when second timeout is reached, then WS1 is triggered, system reset.
> + *
> + * More details about the hardware specification of this device:
> + * ARM DEN0029B - Server Base System Architecture (SBSA)
> + *
> + * SBSA GWDT: |WOR---WS0WOR---WS1
> + *|timeoutreset
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* SBSA Generic Watchdog register definitions */
> +/* refresh frame */
> +#define SBSA_GWDT_WRR  0x000
> +
> +/* control frame */
> +#define SBSA_GWDT_WCS  0x000
> +#define SBSA_GWDT_WOR  0x008
> +#define SBSA_GWDT_WCV  0x010
> +
> +/* refresh/control frame */
> +#define SBSA_GWDT_W_IIDR   0xfcc
> +#define SBSA_GWDT_IDR  0xfd0
> +
> +/* Watchdog Control and Status Register */
> +#define SBSA_GWDT_WCS_EN   BIT(0)
> +#define SBSA_GWDT_WCS_WS0 

Re: [PATCH 6/6] coresight-stm: adding driver for CoreSight STM component

[Mathieu Poirier]

On 1 February 2016 at 05:44, Chunyan Zhang  wrote:
> Hi Mathieu,
>
> So sorry that I forgot this patch depends on [1] which hasn't been upstreamed.
> How about adding the definition of coresight_simple_func() like [1]
> does in the STM driver for the time being? It can be simply removed
> once [1] is upstreamed. If you agree with this idea, I'll add the
> definition of coresight_simple_func() in the next version of patches.

I'm fine with proceeding this way - with the Perf integration work
there is simply too much churn in the Coresight subsystem to deal with
that immediately.

Mathieu

>
> Thanks,
> Chunyan
>
> [1] 
> https://git.linaro.org/people/mathieu.poirier/coresight.git/blobdiff/59aadd3319527addcf8dbc6e6064b15f74b244fe..76dda3d0d313a4676d43adef52ad8faec0c61b61:/drivers/hwtracing/coresight/coresight-priv.h
>
> On Mon, Feb 1, 2016 at 6:01 PM, kbuild test robot  wrote:
>> Hi Pratik,
>>
>> [auto build test ERROR on robh/for-next]
>> [also build test ERROR on v4.5-rc2 next-20160201]
>> [if your patch is applied to the wrong git tree, please drop us a note to 
>> help improving the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Chunyan-Zhang/Introduce-CoreSight-STM-support/20160201-160437
>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
>> config: arm-allmodconfig (attached as .config)
>> reproduce:
>> wget 
>> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>>  -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> # save the attached .config to linux build tree
>> make.cross ARCH=arm
>>
>> All errors (new ones prefixed by >>):
>>
 drivers/hwtracing/coresight/coresight-stm.c:671:27: error: unknown type 
 name 'tcsr'
>> coresight_stm_simple_func(tcsr, STMTCSR);
>>   ^
>>drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition 
>> of macro 'coresight_stm_simple_func'
>>  coresight_simple_func(struct stm_drvdata, name, offset)
>>^
 drivers/hwtracing/coresight/coresight-stm.c:57:20: error: expected 
 declaration specifiers or '...' before numeric constant
>> #define STMTCSR0xe80
>>^
>>drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition 
>> of macro 'coresight_stm_simple_func'
>>  coresight_simple_func(struct stm_drvdata, name, offset)
>>  ^
>>drivers/hwtracing/coresight/coresight-stm.c:671:33: note: in expansion of 
>> macro 'STMTCSR'
>> coresight_stm_simple_func(tcsr, STMTCSR);
>> ^
 drivers/hwtracing/coresight/coresight-stm.c:672:27: error: unknown type 
 name 'tsfreqr'
>> coresight_stm_simple_func(tsfreqr, STMTSFREQR);
>>   ^
>>drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition 
>> of macro 'coresight_stm_simple_func'
>>  coresight_simple_func(struct stm_drvdata, name, offset)
>>^
>>drivers/hwtracing/coresight/coresight-stm.c:59:22: error: expected 
>> declaration specifiers or '...' before numeric constant
>> #define STMTSFREQR   0xe8c
>>  ^
>>drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition 
>> of macro 'coresight_stm_simple_func'
>>  coresight_simple_func(struct stm_drvdata, name, offset)
>>  ^
>>drivers/hwtracing/coresight/coresight-stm.c:672:36: note: in expansion of 
>> macro 'STMTSFREQR'
>> coresight_stm_simple_func(tsfreqr, STMTSFREQR);
>>^
 drivers/hwtracing/coresight/coresight-stm.c:673:27: error: unknown type 
 name 'syncr'
>> coresight_stm_simple_func(syncr, STMSYNCR);
>>   ^
>>drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition 
>> of macro 'coresight_stm_simple_func'
>>  coresight_simple_func(struct stm_drvdata, name, offset)
>>^
>>drivers/hwtracing/coresight/coresight-stm.c:60:20: error: expected 
>> declaration specifiers or '...' before numeric constant
>> #define STMSYNCR   0xe90
>>^
>>drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition 
>> of macro 'coresight_stm_simple_func'
>>  coresight_simple_func(struct stm_drvdata, name, offset)
>>  ^
>>drivers/hwtracing/coresight/coresight-stm.c:673:34: note: in expansion of 
>> macro 'STMSYNCR'
>> coresight_stm_simple_func(syncr, STMSYNCR);
>>  ^
 drivers/hwtracing/coresight/coresight-stm.c:674:27: error: unknown type 
 name 'sper'
>> coresight_stm_simple_func(sper, STMSPER);
>> 

Re: [PATCH V8 18/23] coresight: etm-perf: new PMU driver for ETM tracers

[Mathieu Poirier]

On 28 January 2016 at 08:42, Alexander Shishkin
 wrote:
> Mathieu Poirier  writes:
>
>>> I'd like to understand all the potential failures here, because it's
>>> really a good idea to keep those to a minimum for the sake of
>>> consistency. That is, if the user succeeded in creating an event, about
>>> the only good reason for the event not starting is a filled up buffer.
>>
>> Enabling a path should fail when one or many components of that path
>> are already enabled by an ongoing trace session.  This situation is
>> quite likely to happen since in a lot of design tracers share the link
>> and sinks.
>
> Yes, but provided that we don't get interference from sysfs users
> (which, I guess, could be blocked out while etm perf events exist), this
> part shouldn't fail, as nobody else should be using these links and
> sinks but etm events and those are safe from overlapping because of
> PERF_PMU_CAP_EXCLUSIVE. Or am I missing something?

Interference from sysfs are being dealt with by drvdata->mode.  As
such a user can't muddle with perf sessions so things are good on that
front.

Reading the comment in [1], mutual exclusion rules aren't that clear
to me.  Perf is aware of the context and CPUs a session is slated for
but has no insight on the path from source to sink.  Tracing an "ls"
command on CPU1 and "uname" on CPU3 might look very distinct to Perf
but can easily share the same plumbing.  If setting
PERF_PMU_CAP_EXCLUSIVE in the PMU definition guarantees that a single
session on that PMU can be active at any given time, then yes, the
only cause of failutre is a buffer full condition.

[1]. http://lxr.free-electrons.com/source/kernel/events/core.c#L3608

>
>>> This is why it makes a lot of sense to keep all the
>>> coresight_build_path()/coresight_enable_path() to the .event_init()
>>> phase and let them fail early, if they should fail.
>>
>> If we do enable enable paths in .event_init() we can't support
>> multiple concurrent trace session (see explanation above).  The
>> ultimate design is to have a source directly connected to a sink but
>> so far none of the coresight topologies I've seen have been wired like
>> that.
>
> So if we call dibs on those paths early (like event_init early), in such
> a way that nobody but other etm events can use them, we should be ok, I
> think.

Elements get out of reach from sysfs as soon as a path is built, so we
are already covered there.

>
> Regards,
> --
> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V8 16/23] coresight: etb10: implementing AUX API

[Mathieu Poirier]

On 26 January 2016 at 08:53, Alexander Shishkin
 wrote:
> Mathieu Poirier  writes:
>
>> Adding an ETB10 specific AUX area operations to be used
>> by the perf framework when events are initialised.
>>
>> Part of this operation involves modeling the mmap'ed area
>> based on the specific ways a sink buffer gathers information.
>
> I don't mind being CC'd on the rest of the patches too, btw. :)

Most definitely.

>
>> +static unsigned long etb_reset_buffer(struct coresight_device *csdev,
>> +   struct perf_output_handle *handle,
>> +   void *sink_config, bool *lost)
>> +{
>> + unsigned long size = 0;
>> + struct cs_buffers *buf = sink_config;
>> +
>> + if (buf) {
>> + /*
>> +  * In snapshot mode ->data_size holds the new address of the
>> +  * ring buffer's head.  The size itself is the whole address
>> +  * range since we want the latest information.
>> +  */
>> + if (buf->snapshot)
>> + handle->head = local_xchg(&buf->data_size,
>> +   buf->nr_pages << PAGE_SHIFT);
>> +
>> + /*
>> +  * Tell the tracer PMU how much we got in this run and if
>> +  * something went wrong along the way.  Nobody else can use
>> +  * this cs_buffers instance until we are done.  As such
>> +  * resetting parameters here and squaring off with the ring
>> +  * buffer API in the tracer PMU is fine.
>> +  */
>> + *lost = local_xchg(&buf->lost, 0);
>
> This is a thin ice, you can't really make assumptions about bool's
> storage size or even type, afaict.

You are theoretically correct but I wonder if the value of &buf->lost
can get to a size where it won't fit in *lost... Nevertheless I'll fix
it with:

*lost = !!local_xchg(&buf->lost, 0);

>
>> + size = local_xchg(&buf->data_size, 0);
>> + }
>> +
>> + return size;
>> +}
>> +
>> +static void etb_update_buffer(struct coresight_device *csdev,
>> +   struct perf_output_handle *handle,
>> +   void *sink_config)
>> +{
>> + int i, cur;
>> + u8 *buf_ptr;
>> + u32 read_ptr, write_ptr, capacity;
>> + u32 status, read_data, to_read;
>> + unsigned long flags, offset;
>> + struct cs_buffers *buf = sink_config;
>> + struct etb_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>> +
>> + if (!buf)
>> + return;
>> +
>> + capacity = drvdata->buffer_depth * ETB_FRAME_SIZE_WORDS;
>> +
>> + spin_lock_irqsave(&drvdata->spinlock, flags);
>
> This spinlock seems to be held over the entire readout operation,
> however, I can't find clear rules wrt what structures etc are serialized
> on it. Instead, the comment says "only one at a time pls". Same for
> etm's big drvdata spinlock.

That spinlock is there to serialise actions coming from sysFS.  I
originally added the spinlock to 'etb_update_buffer()' to guard
against reading the internal RAM buffer from sysfs while a perf
session is active.  But after supplementing 'etb_dump()' with 'mode'
awareness this spinlock it is no longer required.

>
> Regards,
> --
> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V8 18/23] coresight: etm-perf: new PMU driver for ETM tracers

[Mathieu Poirier]

On 26 January 2016 at 08:27, Alexander Shishkin
 wrote:
> Mathieu Poirier  writes:
>
>> +static int etm_event_init(struct perf_event *event)
>> +{
>> + if (event->attr.type != etm_pmu.type)
>> + return -ENOENT;
>> +
>> + if (event->cpu >= nr_cpu_ids)
>> + return -EINVAL;
>
> perf_event_alloc() already does this. Except for this one doesn't cover
> the negative space.

Ack

>
> [snip]
>
>> +static void etm_free_aux(void *data)
>> +{
>> + struct etm_event_data *event_data = data;
>> +
>> + pr_err("Queing work\n");
>
> Probably not pr_err().

That's an old debug message - I've removed it already.

>
>> + schedule_work(&event_data->work);
>> +}
>
> [snip]
>
>> +static void etm_event_start(struct perf_event *event, int flags)
>> +{
>> + int cpu = smp_processor_id();
>> + struct etm_event_data *event_data;
>> + struct perf_output_handle *handle = this_cpu_ptr(&ctx_handle);
>> + struct coresight_device *sink, *csdev = per_cpu(csdev_src, cpu);
>> +
>> + if (!csdev)
>> + goto fail;
>> +
>> + /*
>> +  * Deal with the ring buffer API and get a handle on the
>> +  * session's information.
>> +  */
>> + event_data = perf_aux_output_begin(handle, event);
>> + if (WARN_ON_ONCE(!event_data))
>> + goto fail;
>
> There really shouldn't be a warning here. I understand that the 'no
> buffer' case is taped over by the !csdev check above, but there are
> other ligitimate reasons for perf_aux_output_begin() to return NULL,
> like no-space-left.

That's too harsh yes.

>
>> +
>> + /* We need a sink, no need to continue without one */
>> + sink = coresight_get_sink(event_data->path[cpu]);
>> + if (!sink || !sink_ops(sink)->set_buffer)
>> + goto fail_end_stop;
>
> Is this possible after the coresight_build_path() things in setup_aux?
> Might be a better candidate for WARN_*ONCE().
>
>> +
>> + /* Configure the sink */
>> + if (sink_ops(sink)->set_buffer(sink, handle,
>> +event_data->snk_config))
>> + goto fail_end_stop;
>> +
>> + /* Nothing will happen without a path */
>> + if (coresight_enable_path(event_data->path[cpu], CS_MODE_PERF))
>> + goto fail_end_stop;
>
> I'd like to understand all the potential failures here, because it's
> really a good idea to keep those to a minimum for the sake of
> consistency. That is, if the user succeeded in creating an event, about
> the only good reason for the event not starting is a filled up buffer.

Enabling a path should fail when one or many components of that path
are already enabled by an ongoing trace session.  This situation is
quite likely to happen since in a lot of design tracers share the link
and sinks.

>
> This is why it makes a lot of sense to keep all the
> coresight_build_path()/coresight_enable_path() to the .event_init()
> phase and let them fail early, if they should fail.

If we do enable enable paths in .event_init() we can't support
multiple concurrent trace session (see explanation above).  The
ultimate design is to have a source directly connected to a sink but
so far none of the coresight topologies I've seen have been wired like
that.

>
> Regards,
> --
> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V8 20/23] perf tools: making function set_max_cpu_num() non static

[Mathieu Poirier]

On 26 January 2016 at 11:51, Arnaldo Carvalho de Melo  wrote:
> Em Tue, Jan 26, 2016 at 10:08:21AM -0700, Mathieu Poirier escreveu:
>> On 25 January 2016 at 14:29, Arnaldo Carvalho de Melo  
>> wrote:
>> > Em Mon, Jan 25, 2016 at 06:12:42PM -0300, Arnaldo Carvalho de Melo 
>> > escreveu:
>> >> Em Mon, Jan 25, 2016 at 01:46:22PM -0700, Mathieu Poirier escreveu:
>> >> > On 14 January 2016 at 14:46, Mathieu Poirier 
>> >> >  wrote:
>> >> > I can't queue this patch for 4.6 without at least a reviewed by from 
>> >> > you.
>> >>
>> >> This one I remember, looks ugly, the name set_max_cpu_num() looks
>> >> strange, when that was restricted (static) to that cpumap.c file, it
>> >> wasn't a problem, exporting it for wider usage looks bad.
>> >>
>> >> You've been waiting for this for quite a while, it seems, lemme stop
>> >> what I am doing to check this...
>> >
>> > So, please check the patch below, what you need then is just to use
>> > cpu__max_cpu().
>>
>> I like your approach - thanks for the review.  I will spin V9 when I
>> have received Adrian's comments.
>
> I'll take that as an Acked-by: and since this improves the current
> situation by hiding needlessly exported global variables, I'll get it in
> now, thanks.

I would have added this code in my patchset with the right authorship
- whatever works best for you.

Thanks,
Mathieu

>
> - Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V8 20/23] perf tools: making function set_max_cpu_num() non static

[Mathieu Poirier]

On 25 January 2016 at 14:29, Arnaldo Carvalho de Melo  wrote:
> Em Mon, Jan 25, 2016 at 06:12:42PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Mon, Jan 25, 2016 at 01:46:22PM -0700, Mathieu Poirier escreveu:
>> > On 14 January 2016 at 14:46, Mathieu Poirier  
>> > wrote:
>> > > For memory allocation purposes, code located in other places
>> > > then util/cpumap.c may want to know how many CPUs the system has.
>> > >
>> > > This patch is making function set_max_cpu_num() available to
>> > > other parts of the perf tool so that global variable
>> > > 'max_cpu_num' gets the right value when referenced by cpu__max_cpu().
>> > >
>> > > Cc: Peter Zijlstra 
>> > > Cc: Ingo Molnar 
>> > > Cc: Arnaldo Carvalho de Melo 
>> > > Signed-off-by: Mathieu Poirier 
>> > > ---
>> > >  tools/perf/util/cpumap.c | 2 +-
>> > >  tools/perf/util/cpumap.h | 1 +
>> > >  2 files changed, 2 insertions(+), 1 deletion(-)
>> > >
>> > > diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c
>> > > index 10af1e7524fb..ae179320c0c0 100644
>> > > --- a/tools/perf/util/cpumap.c
>> > > +++ b/tools/perf/util/cpumap.c
>> > > @@ -380,7 +380,7 @@ out:
>> > >  }
>> > >
>> > >  /* Determine highest possible cpu in the system for sparse allocation */
>> > > -static void set_max_cpu_num(void)
>> > > +void set_max_cpu_num(void)
>> > >  {
>> > > const char *mnt;
>> > > char path[PATH_MAX];
>> > > diff --git a/tools/perf/util/cpumap.h b/tools/perf/util/cpumap.h
>> > > index 85f7772457fa..45fa963345eb 100644
>> > > --- a/tools/perf/util/cpumap.h
>> > > +++ b/tools/perf/util/cpumap.h
>> > > @@ -14,6 +14,7 @@ struct cpu_map {
>> > > int map[];
>> > >  };
>> > >
>> > > +void set_max_cpu_num(void);
>> > >  struct cpu_map *cpu_map__new(const char *cpu_list);
>> > >  struct cpu_map *cpu_map__empty_new(int nr);
>> > >  struct cpu_map *cpu_map__dummy_new(void);
>> > > --
>> > > 2.1.4
>> > >
>> >
>> > Arnaldo,
>> >
>> > I can't queue this patch for 4.6 without at least a reviewed by from you.
>>
>> This one I remember, looks ugly, the name set_max_cpu_num() looks
>> strange, when that was restricted (static) to that cpumap.c file, it
>> wasn't a problem, exporting it for wider usage looks bad.
>>
>> You've been waiting for this for quite a while, it seems, lemme stop
>> what I am doing to check this...
>
> So, please check the patch below, what you need then is just to use
> cpu__max_cpu().

I like your approach - thanks for the review.  I will spin V9 when I
have received Adrian's comments.

Mathieu

>
> - Arnaldo
>
> diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c
> index fa935093a599..9bcf2bed3a6d 100644
> --- a/tools/perf/util/cpumap.c
> +++ b/tools/perf/util/cpumap.c
> @@ -8,6 +8,10 @@
>  #include 
>  #include "asm/bug.h"
>
> +static int max_cpu_num;
> +static int max_node_num;
> +static int *cpunode_map;
> +
>  static struct cpu_map *cpu_map__default_new(void)
>  {
> struct cpu_map *cpus;
> @@ -486,6 +490,32 @@ out:
> pr_err("Failed to read max nodes, using default of %d\n", 
> max_node_num);
>  }
>
> +int cpu__max_node(void)
> +{
> +   if (unlikely(!max_node_num))
> +   set_max_node_num();
> +
> +   return max_node_num;
> +}
> +
> +int cpu__max_cpu(void)
> +{
> +   if (unlikely(!max_cpu_num))
> +   set_max_cpu_num();
> +
> +   return max_cpu_num;
> +}
> +
> +int cpu__get_node(int cpu)
> +{
> +   if (unlikely(cpunode_map == NULL)) {
> +   pr_debug("cpu_map not initialized\n");
> +   return -1;
> +   }
> +
> +   return cpunode_map[cpu];
> +}
> +
>  static int init_cpunode_map(void)
>  {
> int i;
> diff --git a/tools/perf/util/cpumap.h b/tools/perf/util/cpumap.h
> index 71c41b9efabb..81a2562aaa2b 100644
> --- a/tools/perf/util/cpumap.h
> +++ b/tools/perf/util/cpumap.h
> @@ -57,37 +57,11 @@ static inline bool cpu_map__empty(const struct cpu_map 
> *map)
> return map ? map->map[0] == -1 : true;
>  }
>
> -int max_cpu_num;
> -int max_node_num;
> -int *cpunode_map;
> -
>  int cpu__setup_cpunode_map(void);
&

Re: [PATCH V8 20/23] perf tools: making function set_max_cpu_num() non static

[Mathieu Poirier]

On 14 January 2016 at 14:46, Mathieu Poirier  wrote:
> For memory allocation purposes, code located in other places
> then util/cpumap.c may want to know how many CPUs the system has.
>
> This patch is making function set_max_cpu_num() available to
> other parts of the perf tool so that global variable
> 'max_cpu_num' gets the right value when referenced by cpu__max_cpu().
>
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Cc: Arnaldo Carvalho de Melo 
> Signed-off-by: Mathieu Poirier 
> ---
>  tools/perf/util/cpumap.c | 2 +-
>  tools/perf/util/cpumap.h | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c
> index 10af1e7524fb..ae179320c0c0 100644
> --- a/tools/perf/util/cpumap.c
> +++ b/tools/perf/util/cpumap.c
> @@ -380,7 +380,7 @@ out:
>  }
>
>  /* Determine highest possible cpu in the system for sparse allocation */
> -static void set_max_cpu_num(void)
> +void set_max_cpu_num(void)
>  {
> const char *mnt;
> char path[PATH_MAX];
> diff --git a/tools/perf/util/cpumap.h b/tools/perf/util/cpumap.h
> index 85f7772457fa..45fa963345eb 100644
> --- a/tools/perf/util/cpumap.h
> +++ b/tools/perf/util/cpumap.h
> @@ -14,6 +14,7 @@ struct cpu_map {
> int map[];
>  };
>
> +void set_max_cpu_num(void);
>  struct cpu_map *cpu_map__new(const char *cpu_list);
>  struct cpu_map *cpu_map__empty_new(int nr);
>  struct cpu_map *cpu_map__dummy_new(void);
> --
> 2.1.4
>

Arnaldo,

I can't queue this patch for 4.6 without at least a reviewed by from you.

It has been rebased to 4.5-rc1 here [1] for your convenience.  I will
be happy to use another baseline should that be more adequate for you.
The same goes for [2]

Thanks,
Mathieu

[1]. 
https://git.linaro.org/people/mathieu.poirier/coresight.git/shortlog/refs/heads/perf-v4.5-rc1-V8
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html