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

[Mike Leach]

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

> >
> > Could you please help to provide your comments on this requirement ?
> >
> > Thanks
> > Jinlong Mao
> >
>


-- 
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK