[Linux-stm32] [RFC] Add trig_ts function in STM to generate TRIG_TS packet periodically

[Al Grant]

> From: Jinlong Mao <quic_jinlmao at quicinc.com>
> Sent: 23 February 2023 06:41
> On 2/22/2023 8:19 PM, Mike Leach wrote:
> > Hi
> >
> > A couple additional points...
> >
> > On Wed, 22 Feb 2023 at 11:00, Suzuki K Poulose <suzuki.poulose at arm.com>
> wrote:
> >> On 21/02/2023 06:53, Jinlong Mao wrote:
> >>> Hi all,
> >>>
> >>> When there is some small packet sent from STM to ETR, the small
> >>> packet could be stuck between source and sink even if manual flush
> >>> is set when disable ETR.
> >> Why ? The manual flush should trigger a flush request upstream and
> >> eventually cause a flush ? If this doesn't work as expected we should
> >> try to get to the bottom of that first, before jumping into "software
> >> work arounds".
> >>
> >>> So there is requirement that flush the STM trace periodically after
> >>> enabling STM to ETR.
> >>>
> >>> STM can generate TRIG_TS packet by writing to offset 0xF0 of the
> >>> driver STM stimulus port.
> >>> ETR has ability to initiate a flush on seeing a TRIG_TS packet.
> >> Why is this different from the "manual flush" and how does it help ?
> >> Is it because one of the components doesn't respond properly to the
> >> flush request ?
> >>
> >>
> >> Kind regards
> >> Suzuki
> >>
> >>> For this requirement, I want to create a sysfs node like trig_ts for STM.
> >>> When writing 1 to this sysfs node, a timer with 1 second periodicity
> >>> in STM will start to generate the trig_ts packet to ETR.
> > If this is really needed, then the source writing the data you wish to
> > flush should write to the relevant STM stimulus port. There is no
> > justification for a polling mechanism when the client itself can do
> > the write at a  time you believe it to be needed.
> >
> >>> Once ETR receive the TRIG_TS packet, it will initiate a flush.
> > The ETR does not interpret STM packets - this alone will not initiate a flush.
> >
> > It is possible to program the ETR to respond to the FLUSHIN or TRIGIN
> > signals via the ECT/CTI network of signals, or a trigger event in the
> > trace stream (ATID=0x7D) if a source (in this case the STM) is
> > programmed to output these specific packets when it generates trigger
> > packets in its own protocol.
> > Programming bits in the FFCR control these operations, STM must be
> > programmed separately to generate appropriate output responses on
> > trigger packets.
> >
> > Regards
> >
> > Mike
> 
> Hi Suzuki & Mike,
> 
> There is USB case support in our internal device.
> Data path is that  STM data ---> ETR -----> USB ----> PC tool.
> 
> On PC tool, it can show the logs from ETR in real time.
> 
> When one small packet send from STM to ETR, it can be stuck between STM and
> ETR.
> When the packet stuck happens, it will be flushed to ETR only when some other
> packets generated from STM source or CTI flush commands are sent. If the time
> is too long to wait for next packets coming, user will consider that issue happens
> with previous small packet.
> And user's requirement is that packet from STM can be flushed to ETR
> automatically instead of sending commands manually.

The point of initiating an ATB flush from the ETR is to flush
out packets between upstream trace sources and the ETR.
The ETR tells upstream sources to flush out their data and
acknowledge when complete and this request is passed upwards
to all trace sources. In effect the ETR is "pulling" data from
all its sources. The mechanism is the same whether it is
initiated manually (by writing FFCR) or in response to a trigger
on the ATB stream. If it's not working (e.g. because some
device between the STM and ETR is not passing on the
flush request due to a hardware issue), it doesn't matter
how you initiate it at the ETR. So if a manual flush doesn't
work then it's not going to work if the flush is in response
to an ATB trigger.

Maybe you are simply seeing the effect of sending more
data from the STM, that bumps out whatever is ahead of it?
So you could achieve the same effect by sending out any
kind of data from the STM e.g. a padding packet.

> Is it appropriate to add a sysfs node for STM to generate the trigger packet
> periodically for such case ?

It seems to be solving the problem at the wrong place.
If it's useful for the ETR to do a periodic ATB flush, then that
would be better done by the kernel periodically initiating
the flush manually at the ETR, not by periodically telling
one particular trace source (out of many) to send a trigger.

If ATB flush is broken, then a workaround would be to
have each trace source periodically send a null packet of
some kind - but in that case it there is nothing special
about triggers, they could be any kind of padding, and for
STM you might be able to generate that by stimulus.

Al


> 
> 
> Thanks
> Jinlong Mao
> 
> 
> >
> >>> Could you please help to provide your comments on this requirement ?
> >>>
> >>> Thanks
> >>> Jinlong Mao
> >>>
> >
> _______________________________________________
> CoreSight mailing list -- coresight at lists.linaro.org
> To unsubscribe send an email to coresight-leave at lists.linaro.org