Re: [PATCH] coresight: dynamic-replicator: Fix handling of multiple connections

[Sai Prakash Ranjan]

Hi Suzuki, Mike,

On 2020-04-29 22:41, Sai Prakash Ranjan wrote:
> Hi Mike,
>
> On 2020-04-29 22:28, Mike Leach wrote:
> > Hi,
>
> [...]
>
> > > >> > You need to find what is resetting the IDFILTERs to 0 for replicator1.
> > > >> >
> > > >>
> > > >> That is right.
> > > >>
> > > >
> > > > By default all replicators have the IDFILTER registers set to 0 out of
> > > > hardware reset. This ensures that programmable replicators behave in
> > > > the same way as non-programmable replicators out of reset.
> > > >
> > > > The  dynamic_replicator_reset() is of course a driver state reset -
> > > > which filters out all trace on the output ports. The trace is then
> > > > enabled when we set the trace path from source to sink.
> > > >
> > >
> > > Thanks for these explanations.
> > >
> > > > It seems to me that you have 2 problems that need solving here:
> > > >
> > > > 1) Why does the reset_replicator() called from probe() _not_ work
> > > > correctly on replicator 1? It seems to work later if you introduce a
> > > > reset after more of the system has powered and booted. This is
> > > > startiing to look a little like a PM / clocking issue.
> > >
> > > reset_replicator() does work in probe correctly for both replicators,
> > > below logs is collected before and after reset in probe. It is later
> > > that it's set back to 0x0 and hence the suggestion to look at 
> > > firmware
> > > using this replicator1.
> > OK - sorry I read your statement saying that replicator1 was 0 after
> > the reset in probe(), rather than look at the logs.
> >
> > From the logs it is working at the time probe() occurs, but by the
> > time we come to enable the replicator later, something has reset these
> > registers / hardware outside the control of the replicator driver.
>
> Yes, I will try to get some more information from the firmware side if
> there is anything messing up.

This turned out to be a clock/pm issue. To confirm, I just marked clk as 
critical
so that it won't be gated and I saw the replicator1(swao_replicator) 
registers
intact after probe. Also alternatively, I tried to comment out disabling 
pclk
to check if there is something wrong in amba pm and this keeps the 
registers
intact as well.

@@ -288,7 +295,7 @@ static int amba_probe(struct device *dev)
                pm_runtime_set_suspended(dev);
                pm_runtime_put_noidle(dev);

-               amba_put_disable_pclk(pcdev);
+               //amba_put_disable_pclk(pcdev);
                dev_pm_domain_detach(dev, true);
        } while (0);

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation