On 25/03/2019 15:08, Mathieu Poirier wrote:
On Mon, 25 Mar 2019 at 05:49, Suzuki K Poulose suzuki.poulose@arm.com wrote:
On 22/03/2019 19:14, Mathieu Poirier wrote:
On Tue, 19 Mar 2019 at 04:00, Suzuki K Poulose suzuki.poulose@arm.com wrote:
Hi Mathieu,
On 06/03/2019 22:57, Mathieu Poirier wrote:
In preparation to support CPU-wide trace scenarios, add the notion of process ID to ETR devices so that memory buffers can be shared between events.
The PID only matters to the perf buffers. And etr_buf is really a representation of the ETR Hw buffer and I prefer to keep it that way. Please could we have all the "perf" related book keeping in the etr_perf_buf, which holds the perf session specific data ?
As for enforcing the FLAT mode in the later series, we don't necessarily need to force it for double buffering. Even our SG mode uses double buffering. Even otherwise, we may be able to force a mode, than passing down perf specific data to the generic ETR buffer.
Signed-off-by: Mathieu Poirier mathieu.poirier@linaro.org
.../hwtracing/coresight/coresight-tmc-etr.c | 26 +++++++++++++++---- drivers/hwtracing/coresight/coresight-tmc.h | 6 +++++ 2 files changed, 27 insertions(+), 5 deletions(-)...
diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h index 487c53701e9c..d3657acb6cbf 100644 --- a/drivers/hwtracing/coresight/coresight-tmc.h +++ b/drivers/hwtracing/coresight/coresight-tmc.h @@ -9,6 +9,8 @@
#include <linux/dma-mapping.h> #include <linux/miscdevice.h>+#include <linux/refcount.h> +#include <linux/types.h>
#define TMC_RSZ 0x004 #define TMC_STS 0x00c@@ -133,6 +135,8 @@ struct etr_buf_operations;
/** * struct etr_buf - Details of the buffer used by ETR
- @pid : The pid this etr_buf belongs to.
- @refcount : Number of sources currently using this etr_buf.
- @mode : Mode of the ETR buffer, contiguous, Scatter Gather etc.
- @full : Trace data overflow
- @size : Size of the buffer.
@@ -143,6 +147,8 @@ struct etr_buf_operations; * @private : Backend specific information for the buf */ struct etr_buf {
pid_t pid;refcount_t refcount;As mentioned above, those are better suited for etr_perf_buf.
Thoughts ?
Going back on this, I definitely agree with you that pid should be in the etr_perf_buf structure. On the flip side I think refcount should stay in etr_buf as it counts the number of users of this buffer.
I see, you're right, since we could be creating multiple output handles and thus aux-pages per event ? Did I miss something ?
In CPU-wide mode a struct etr_perf_buffer is instantiated for each CPU that is part of the trace session. If the HW enacts an 1:1 topology each etr_perf_buffer has its own etr_buf, otherwise the etr_buf is shared between etr_perf_buffer, hence the need to keep the refcount at that level.
Oh ! Thats nice and makes perfect sense. So we are covered for the 1:1 topology.
I'll spin another revision of this set today. After that I'm charging in your ACPI work.
Thanks. Np, take your time.
Cheers Suzuki