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

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