Mathieu Poirier <mathieu.poirier@xxxxxxxxxx> writes: > On 30 September 2015 at 05:33, Alexander Shishkin > <alexander.shishkin@xxxxxxxxxxxxxxx> wrote: >> Mathieu Poirier <mathieu.poirier@xxxxxxxxxx> writes: >> >>> Calling function 'smp_call_function_single()' to unlock the >>> tracer and calling it right after to perform the default >>> initialisation doesn't make sense. >>> >>> Moving 'etm_os_unlock()' just before making the default >>> initialisation results in the same outcome while saving >>> one call to 'smp_call_function_single()'. >>> >>> Signed-off-by: Mathieu Poirier <mathieu.poirier@xxxxxxxxxx> >>> --- >>> drivers/hwtracing/coresight/coresight-etm3x.c | 8 +++++--- >>> 1 file changed, 5 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c >>> index c6880c1ade55..a4c158df0fef 100644 >>> --- a/drivers/hwtracing/coresight/coresight-etm3x.c >>> +++ b/drivers/hwtracing/coresight/coresight-etm3x.c >>> @@ -1867,6 +1867,11 @@ static void etm_init_arch_data(void *info) >>> * certain registers might be ignored. >>> */ >>> etm_clr_pwrdwn(drvdata); >>> + >>> + /* Make sure all registers are accessible */ >>> + etm_os_unlock(drvdata); >> >> In case of co-processor register access, this will end up unlocking the >> local ETM instead of the one on target cpu, by the looks of it. > > "etm_init_arch_data()" is also called from "smp_function_calls()" and > as such, will end up executing the correct CPU. Yes, but it doesn't unlock the OSLAR register, which also needs to be done on target cpu. Regards, -- Alex -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
