[RFC PATCH 06/20] coresight: etm3x: unlocking tracer in default arch init
alexander.shishkin at linux.intel.com
Thu Oct 1 21:47:56 PDT 2015
Mathieu Poirier <mathieu.poirier at linaro.org> writes:
> On 30 September 2015 at 05:33, Alexander Shishkin
> <alexander.shishkin at linux.intel.com> wrote:
>> Mathieu Poirier <mathieu.poirier at linaro.org> 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 at linaro.org>
>>> 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.
>>> + /* 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.
More information about the linux-arm-kernel