Re: [PATCH V3 11/14] coresight: sink: Add TRBE driver

Hello Mike,

On 2/16/21 2:30 PM, Mike Leach wrote:

Hi Anshuman,

There have been plenty of detailed comments so I will restrict mine to
a few general issues:-

1) Currently there appears to be no sysfs support (I cannot see the
MODE_SYSFS constants running alongside the MODE_PERF ones present in
the other sink drivers). This is present on all other coresight
devices, and must be provided for this device. It is useful for
testing, and there are users out there who will have scripts to use
it. It is not essential it makes it into this set, but should be a
follow up set.

Sure, will try and add it in a follow up series.

2) Using FILL mode for TRBE means that the trace will by definition be
lossy. Fill mode will halt collection without cleanly stopping and
flushing the source. This will result in the sink missing the last of
the data from the source as it stops. Even if taking the exception
moves into a prohibited region there is still the possibility the last
trace operations will not be seen. Further it is possible that the
last few bytes of trace will be an incomplete packet, and indeed the
start of the next buffer could contain incomplete packets too.

Just wondering why TRBE and ETE would not sync with each other in order
for the ETE to possibly resend all the lost trace data, when the TRBE
runs out of buffer and wrappers around ? Is this ETE/TRBE behavior same
for all implementations in the FILL mode ? Just wondering.

This operation differs from the other sinks which will only halt after
the sources have stopped and the path has been flushed. This ensures
that the latest trace is complete. The weakness with the older sinks
is the lack of interrupt meaning buffers were frequently wrapped so
that only the latest trace is available.

Right.

By using TRBE WRAP mode, with a watermark as described in the TRBE
spec, using the interrupts it is possible to approach lossless trace
in a way that is not possible with earlier ETR/ETB. This is somethin

Using TRBTRG_EL1 as the above mentioned watermark ?

that has been requested by partners since trace became available in
linux systems. (There is still a possibility of loss due to filling
the buffer completely and overflowing the watermark, but that can be
flagged).

While FILL mode trace is a good start, and suitable for some scenarios
- WRAP mode needs implementing as well.

I would like to understand this mechanism more. Besides how the perf
interface suppose to choose between FILL and WRAP mode ? via a new
event attribute ?

3) Padding: To be clear, it is not safe for the decoder to run off the
end of one buffer, into the padding area and continue decoding, or
continue through the padding into the next buffer. However I believe
the buffer start / stop points are demarked by the aux_output_start /
aux_output_end calls?

Yes.

With upcoming perf decode updates this should enable the decoder to
correctly be started and stopped on the buffer boundaries. The padding
is there primarily to ensure that the decoder does not synchronize
with the data stream until a genuine sync point is found.

Right.

4) TRBE needs to be a loadable module like the rest of coresight.

Even though the driver has all the module constructs, the Kconfig was
missing a tristate value, which is being fixed for the next version.

- Anshuman

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel