[PATCH 15/27] arm64/sve: Probe SVE capabilities and usable vector lengths
Suzuki K Poulose
Suzuki.Poulose at arm.com
Thu Aug 17 03:46:12 PDT 2017
On 17/08/17 11:04, Dave Martin wrote:
> On Wed, Aug 16, 2017 at 06:48:01PM +0100, Suzuki K Poulose wrote:
>> On 09/08/17 13:05, Dave Martin wrote:
>>> [This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
>
> Any idea what this is ^ ? I don't know if this is caused by me or you,
> but I only seem to see it on subthreads you've replied to.
>
Dave,
Sorry about that, should have trimmed that. It looks like the mail server is unhappy
about email received via kvmarm list and I don't know why.
>>
>>> +void __init sve_setup(void)
>>> +{
>>> + u64 zcr;
>>> + unsigned int max_vl;
>>> +
>>> + if (!system_supports_sve())
>>> + return;
>>> +
>>> + /*
>>> + * The architecture mandates 128-bit vectors be supported, and
>>> + * the code assumes elsewhere that sve_vq_map is non-empty:
>>> + */
>>> + BUG_ON(!test_bit(vq_to_bit(1), sve_vq_map));
>>> +
>>> + sve_vq_map_finalised = true;
>>
>> We have something local in cpufeature.c, sys_caps_initialised. May be we could
>> reuse it here ? With or without that change, FWIW.
>
> I'll take a look at that. Inventing that here seemed a little ugly, and
> this is all driven from the cpufreatures code anyway now which ensures a
> certain ordering.
>
> If I can reuse sys_caps_initialised for this, I will -- seems pointless
> to reinvent it.
Suzuki
More information about the linux-arm-kernel
mailing list