* Re: AMU extension v1 support for cortex A76, A77, A78 CPUs
@ 2020-11-20 9:09 ` Vladimir Murzin
0 siblings, 0 replies; 14+ messages in thread
From: Vladimir Murzin @ 2020-11-20 9:09 UTC (permalink / raw)
To: Marc Zyngier, Neeraj Upadhyay
Cc: mark.rutland, Will Deacon, suzuki.poulose, MSM, lkml,
catalin.marinas, ionela.voinescu, valentin.schneider,
linux-arm-kernel
On 11/20/20 8:56 AM, Marc Zyngier wrote:
> On 2020-11-20 04:30, Neeraj Upadhyay wrote:
>> Hi,
>>
>> For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
>> AA64PFR0[47:44] field is not set, and AMU does not get enabled for
>> them.
>> Can you please provide support for these CPUs in cpufeature.c?
>
> If that was the case, that'd be an erratum, and it would need to be
> documented as such. It could also be that this is an optional feature
> for these cores (though the TRM doesn't suggest that).
>
> Can someone at ARM confirm what is the expected behaviour of these CPUs?
Not a confirmation, but IIRC, these are imp def features, while our cpufeatures
catches architected one.
Cheers
Vladimir
>
> M.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: AMU extension v1 support for cortex A76, A77, A78 CPUs
2020-11-20 9:09 ` Vladimir Murzin
@ 2020-11-20 9:54 ` Marc Zyngier
-1 siblings, 0 replies; 14+ messages in thread
From: Marc Zyngier @ 2020-11-20 9:54 UTC (permalink / raw)
To: Vladimir Murzin
Cc: Neeraj Upadhyay, mark.rutland, suzuki.poulose, ionela.voinescu,
MSM, lkml, catalin.marinas, Will Deacon, valentin.schneider,
linux-arm-kernel
On 2020-11-20 09:09, Vladimir Murzin wrote:
> On 11/20/20 8:56 AM, Marc Zyngier wrote:
>> On 2020-11-20 04:30, Neeraj Upadhyay wrote:
>>> Hi,
>>>
>>> For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
>>> AA64PFR0[47:44] field is not set, and AMU does not get enabled for
>>> them.
>>> Can you please provide support for these CPUs in cpufeature.c?
>>
>> If that was the case, that'd be an erratum, and it would need to be
>> documented as such. It could also be that this is an optional feature
>> for these cores (though the TRM doesn't suggest that).
>>
>> Can someone at ARM confirm what is the expected behaviour of these
>> CPUs?
>
> Not a confirmation, but IIRC, these are imp def features, while our
> cpufeatures
> catches architected one.
Ah, good point. So these CPUs implement some sort of AMU, and not *the*
AMU.
Yet the register names are the same. Who thought that'd be a good idea?
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: AMU extension v1 support for cortex A76, A77, A78 CPUs
@ 2020-11-20 9:54 ` Marc Zyngier
0 siblings, 0 replies; 14+ messages in thread
From: Marc Zyngier @ 2020-11-20 9:54 UTC (permalink / raw)
To: Vladimir Murzin
Cc: mark.rutland, Will Deacon, suzuki.poulose, MSM, lkml,
valentin.schneider, catalin.marinas, ionela.voinescu,
Neeraj Upadhyay, linux-arm-kernel
On 2020-11-20 09:09, Vladimir Murzin wrote:
> On 11/20/20 8:56 AM, Marc Zyngier wrote:
>> On 2020-11-20 04:30, Neeraj Upadhyay wrote:
>>> Hi,
>>>
>>> For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
>>> AA64PFR0[47:44] field is not set, and AMU does not get enabled for
>>> them.
>>> Can you please provide support for these CPUs in cpufeature.c?
>>
>> If that was the case, that'd be an erratum, and it would need to be
>> documented as such. It could also be that this is an optional feature
>> for these cores (though the TRM doesn't suggest that).
>>
>> Can someone at ARM confirm what is the expected behaviour of these
>> CPUs?
>
> Not a confirmation, but IIRC, these are imp def features, while our
> cpufeatures
> catches architected one.
Ah, good point. So these CPUs implement some sort of AMU, and not *the*
AMU.
Yet the register names are the same. Who thought that'd be a good idea?
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: AMU extension v1 support for cortex A76, A77, A78 CPUs
2020-11-20 9:54 ` Marc Zyngier
@ 2020-11-20 10:14 ` Vladimir Murzin
-1 siblings, 0 replies; 14+ messages in thread
From: Vladimir Murzin @ 2020-11-20 10:14 UTC (permalink / raw)
To: Marc Zyngier
Cc: Neeraj Upadhyay, mark.rutland, suzuki.poulose, ionela.voinescu,
MSM, lkml, catalin.marinas, Will Deacon, valentin.schneider,
linux-arm-kernel
On 11/20/20 9:54 AM, Marc Zyngier wrote:
> On 2020-11-20 09:09, Vladimir Murzin wrote:
>> On 11/20/20 8:56 AM, Marc Zyngier wrote:
>>> On 2020-11-20 04:30, Neeraj Upadhyay wrote:
>>>> Hi,
>>>>
>>>> For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
>>>> AA64PFR0[47:44] field is not set, and AMU does not get enabled for
>>>> them.
>>>> Can you please provide support for these CPUs in cpufeature.c?
>>>
>>> If that was the case, that'd be an erratum, and it would need to be
>>> documented as such. It could also be that this is an optional feature
>>> for these cores (though the TRM doesn't suggest that).
>>>
>>> Can someone at ARM confirm what is the expected behaviour of these CPUs?
>>
>> Not a confirmation, but IIRC, these are imp def features, while our cpufeatures
>> catches architected one.
>
> Ah, good point. So these CPUs implement some sort of AMU, and not *the* AMU.
>
> Yet the register names are the same. Who thought that'd be a good idea?
IMO, it is the case where imp def has been generalized into arch extension, so
something have been moved over.
Cheers
Vladimir
>
> M.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: AMU extension v1 support for cortex A76, A77, A78 CPUs
@ 2020-11-20 10:14 ` Vladimir Murzin
0 siblings, 0 replies; 14+ messages in thread
From: Vladimir Murzin @ 2020-11-20 10:14 UTC (permalink / raw)
To: Marc Zyngier
Cc: mark.rutland, Will Deacon, suzuki.poulose, MSM, lkml,
valentin.schneider, catalin.marinas, ionela.voinescu,
Neeraj Upadhyay, linux-arm-kernel
On 11/20/20 9:54 AM, Marc Zyngier wrote:
> On 2020-11-20 09:09, Vladimir Murzin wrote:
>> On 11/20/20 8:56 AM, Marc Zyngier wrote:
>>> On 2020-11-20 04:30, Neeraj Upadhyay wrote:
>>>> Hi,
>>>>
>>>> For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
>>>> AA64PFR0[47:44] field is not set, and AMU does not get enabled for
>>>> them.
>>>> Can you please provide support for these CPUs in cpufeature.c?
>>>
>>> If that was the case, that'd be an erratum, and it would need to be
>>> documented as such. It could also be that this is an optional feature
>>> for these cores (though the TRM doesn't suggest that).
>>>
>>> Can someone at ARM confirm what is the expected behaviour of these CPUs?
>>
>> Not a confirmation, but IIRC, these are imp def features, while our cpufeatures
>> catches architected one.
>
> Ah, good point. So these CPUs implement some sort of AMU, and not *the* AMU.
>
> Yet the register names are the same. Who thought that'd be a good idea?
IMO, it is the case where imp def has been generalized into arch extension, so
something have been moved over.
Cheers
Vladimir
>
> M.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: AMU extension v1 support for cortex A76, A77, A78 CPUs
2020-11-20 9:09 ` Vladimir Murzin
@ 2020-11-20 10:13 ` Mark Rutland
-1 siblings, 0 replies; 14+ messages in thread
From: Mark Rutland @ 2020-11-20 10:13 UTC (permalink / raw)
To: Vladimir Murzin
Cc: Marc Zyngier, Neeraj Upadhyay, suzuki.poulose, ionela.voinescu,
MSM, lkml, catalin.marinas, Will Deacon, valentin.schneider,
linux-arm-kernel
On Fri, Nov 20, 2020 at 09:09:00AM +0000, Vladimir Murzin wrote:
> On 11/20/20 8:56 AM, Marc Zyngier wrote:
> > On 2020-11-20 04:30, Neeraj Upadhyay wrote:
> >> Hi,
> >>
> >> For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
> >> AA64PFR0[47:44] field is not set, and AMU does not get enabled for
> >> them.
> >> Can you please provide support for these CPUs in cpufeature.c?
> >
> > If that was the case, that'd be an erratum, and it would need to be
> > documented as such. It could also be that this is an optional feature
> > for these cores (though the TRM doesn't suggest that).
> >
> > Can someone at ARM confirm what is the expected behaviour of these CPUs?
>
> Not a confirmation, but IIRC, these are imp def features, while our cpufeatures
> catches architected one.
We generally don't make use of IMP-DEF featurees because of all the pain
it brings.
Looking at the Cortex-A76 TRM, the encoding for AMCNTENCLR is:
Op0: 3 (0b11)
Op1: 3 (0b011)
CRn: 15 (0b1111)
CRm: 9 (0b1001)
Op2: 7 (0b111)
... whereas the architected encoding (from our sysreg.h) is:
Op0: 3
Op1: 3
CRn: 13
CRm: 2
Op2: 4
... so that's a different register with the same name, which is
confusing and unfortunate.
The encodings are different (and I haven't checked whether the fields /
semantics are the same), so it's not just a matter of wiring up new
detection code. There are also IMP-DEF traps in ACTLR_EL3 and ACTLR_EL2
which we can't be certain of the configuration of, and as the registers
are in the IMP-DEF encoding space they'll be trapped by HCR_EL2.TIDCP
and emulated as UNDEFINED by a hypervisor. All of that means that going
by the MIDR alone is not sufficient to know we can safely access the
registers.
So as usual for IMP-DEF stuff I don't think we can or should make use of
this.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: AMU extension v1 support for cortex A76, A77, A78 CPUs
@ 2020-11-20 10:13 ` Mark Rutland
0 siblings, 0 replies; 14+ messages in thread
From: Mark Rutland @ 2020-11-20 10:13 UTC (permalink / raw)
To: Vladimir Murzin
Cc: catalin.marinas, Will Deacon, suzuki.poulose, Marc Zyngier, lkml,
valentin.schneider, MSM, ionela.voinescu, Neeraj Upadhyay,
linux-arm-kernel
On Fri, Nov 20, 2020 at 09:09:00AM +0000, Vladimir Murzin wrote:
> On 11/20/20 8:56 AM, Marc Zyngier wrote:
> > On 2020-11-20 04:30, Neeraj Upadhyay wrote:
> >> Hi,
> >>
> >> For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
> >> AA64PFR0[47:44] field is not set, and AMU does not get enabled for
> >> them.
> >> Can you please provide support for these CPUs in cpufeature.c?
> >
> > If that was the case, that'd be an erratum, and it would need to be
> > documented as such. It could also be that this is an optional feature
> > for these cores (though the TRM doesn't suggest that).
> >
> > Can someone at ARM confirm what is the expected behaviour of these CPUs?
>
> Not a confirmation, but IIRC, these are imp def features, while our cpufeatures
> catches architected one.
We generally don't make use of IMP-DEF featurees because of all the pain
it brings.
Looking at the Cortex-A76 TRM, the encoding for AMCNTENCLR is:
Op0: 3 (0b11)
Op1: 3 (0b011)
CRn: 15 (0b1111)
CRm: 9 (0b1001)
Op2: 7 (0b111)
... whereas the architected encoding (from our sysreg.h) is:
Op0: 3
Op1: 3
CRn: 13
CRm: 2
Op2: 4
... so that's a different register with the same name, which is
confusing and unfortunate.
The encodings are different (and I haven't checked whether the fields /
semantics are the same), so it's not just a matter of wiring up new
detection code. There are also IMP-DEF traps in ACTLR_EL3 and ACTLR_EL2
which we can't be certain of the configuration of, and as the registers
are in the IMP-DEF encoding space they'll be trapped by HCR_EL2.TIDCP
and emulated as UNDEFINED by a hypervisor. All of that means that going
by the MIDR alone is not sufficient to know we can safely access the
registers.
So as usual for IMP-DEF stuff I don't think we can or should make use of
this.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: AMU extension v1 support for cortex A76, A77, A78 CPUs
2020-11-20 10:13 ` Mark Rutland
(?)
@ 2020-11-24 5:22 ` Neeraj Upadhyay
-1 siblings, 0 replies; 14+ messages in thread
From: Neeraj Upadhyay @ 2020-11-24 5:22 UTC (permalink / raw)
To: Mark Rutland, Vladimir Murzin, Marc Zyngier, sudeep.holla
Cc: suzuki.poulose, ionela.voinescu, MSM, lkml, catalin.marinas,
Will Deacon, valentin.schneider, linux-arm-kernel
Thanks Marc, Vladimir, Mark, Sudeep for your inputs!
Thanks
Neeraj
On 11/20/2020 3:43 PM, Mark Rutland wrote:
> On Fri, Nov 20, 2020 at 09:09:00AM +0000, Vladimir Murzin wrote:
>> On 11/20/20 8:56 AM, Marc Zyngier wrote:
>>> On 2020-11-20 04:30, Neeraj Upadhyay wrote:
>>>> Hi,
>>>>
>>>> For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
>>>> AA64PFR0[47:44] field is not set, and AMU does not get enabled for
>>>> them.
>>>> Can you please provide support for these CPUs in cpufeature.c?
>>>
>>> If that was the case, that'd be an erratum, and it would need to be
>>> documented as such. It could also be that this is an optional feature
>>> for these cores (though the TRM doesn't suggest that).
>>>
>>> Can someone at ARM confirm what is the expected behaviour of these CPUs?
>>
>> Not a confirmation, but IIRC, these are imp def features, while our cpufeatures
>> catches architected one.
>
> We generally don't make use of IMP-DEF featurees because of all the pain
> it brings.
>
> Looking at the Cortex-A76 TRM, the encoding for AMCNTENCLR is:
>
> Op0: 3 (0b11)
> Op1: 3 (0b011)
> CRn: 15 (0b1111)
> CRm: 9 (0b1001)
> Op2: 7 (0b111)
>
> ... whereas the architected encoding (from our sysreg.h) is:
>
> Op0: 3
> Op1: 3
> CRn: 13
> CRm: 2
> Op2: 4
>
> ... so that's a different register with the same name, which is
> confusing and unfortunate.
>
> The encodings are different (and I haven't checked whether the fields /
> semantics are the same), so it's not just a matter of wiring up new
> detection code. There are also IMP-DEF traps in ACTLR_EL3 and ACTLR_EL2
> which we can't be certain of the configuration of, and as the registers
> are in the IMP-DEF encoding space they'll be trapped by HCR_EL2.TIDCP
> and emulated as UNDEFINED by a hypervisor. All of that means that going
> by the MIDR alone is not sufficient to know we can safely access the
> registers.
>
> So as usual for IMP-DEF stuff I don't think we can or should make use of
> this.
>
> Thanks,
> Mark.
>
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 14+ messages in thread