On 1 October 2015 at 22:47, Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx> wrote: > 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. Function "etm_os_unlock()" deals with ETMOSLAR and "CS_UNLOCK()" with ETMLAR. Both are called from "etm_init_arch_data()", which runs on the target CPU. One thing that I will do here is move "etm_os_unlock()" to the beginning of "etm_init_arch_data()". Other than that I may be missing your point. > > 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
