Re: [PATCH v4 5/7] coresight: tmc: Re-enable sink after buffer update

[Leo Yan]

Hi Mike,

On Wed, Apr 02, 2025 at 04:05:10PM +0100, Mike Leach wrote:

[...]

> > @@ -482,6 +482,7 @@ static unsigned long tmc_update_etf_buffer(struct coresight_device *csdev,
> >         unsigned long offset, to_read = 0, flags;
> >         struct cs_buffers *buf = sink_config;
> >         struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
> > +       struct perf_event *event = handle->event;
> >
> >         if (!buf)
> >                 return 0;
> > @@ -586,6 +587,14 @@ static unsigned long tmc_update_etf_buffer(struct coresight_device *csdev,
> >          * is expected by the perf ring buffer.
> >          */
> >         CS_LOCK(drvdata->base);
> > +
> > +       /*
> > +        * If the event is active, it is triggered during an AUX pause.
> > +        * Re-enable the sink so that it is ready when AUX resume is invoked.
> > +        */
> > +       if (!event->hw.state)
> > +               __tmc_etb_enable_hw(drvdata);
> > +
> 
> Think that the  refcnt should be checked here too.

No, ETF driver uses spinlock to guard the entire region for checking
refcnt and updating buffer, here it is still in the same critical
region.  This is why the checking refcnt is not needed.

> Does the  ETB case need to be handled? - somewhat confusingly the
> coresight-tmc-etf.c file handles both ETF and ETB.

ETF is for the link mode, and ETB is for sink.  Updating buffer is only
for sink mode, this is why here I use __tmc_etb_enable_hw().  Does it
make sense?

I also have a question for the paired operations (this is applied for
both ETF and ETR drivers).

Now the flow is:

  tmc_update_etf_buffer()  {

    tmc_flush_and_stop();

    update buffer;

    __tmc_etb_enable_hw();
  }

The operations are not paired between tmc_flush_and_stop() and
__tmc_etb_enable_hw().

The tmc_flush_and_stop() function only controls the TMC_FFCR register.
I'm not sure whether I need to extract the TMC_FFCR operations from
__tmc_etb_enable_hw() to use them for recovery in the update buffer.
Or do you think re-enabling the hardware in this patch is the safer
approach?

Thanks,
Leo