From mboxrd@z Thu Jan  1 00:00:00 1970
From: szabolcs.nagy@arm.com (Szabolcs Nagy)
Date: Tue, 16 Feb 2016 12:57:26 +0000
Subject: [PATCH] arm64: Add support for Half precision floating point
In-Reply-To: <20160216115335.GE14509@arm.com>
References: <1453823566-26742-1-git-send-email-suzuki.poulose@arm.com>
 <20160126160257.GB28238@arm.com>
 <20160126161151.GE14823@e104818-lin.cambridge.arm.com>
 <20160128160022.GM775@arm.com> <56C30C7E.1030005@arm.com>
 <20160216115335.GE14509@arm.com>
Message-ID: <56C31CB6.7090901@arm.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On 16/02/16 11:53, Will Deacon wrote:
> On Tue, Feb 16, 2016 at 11:48:14AM +0000, Szabolcs Nagy wrote:
>> On 28/01/16 16:00, Will Deacon wrote:
>>> On Tue, Jan 26, 2016 at 04:11:51PM +0000, Catalin Marinas wrote:
>>>> On Tue, Jan 26, 2016 at 04:02:58PM +0000, Will Deacon wrote:
>>>>> On Tue, Jan 26, 2016 at 03:52:46PM +0000, Suzuki K Poulose wrote:
>>>>>> +#define HWCAP_FPHP		(1 << 9)
>>>>>> +#define HWCAP_ASIMDHP		(1 << 10)
>>>>>
>>>>> Where did we get to with the mrs trapping you proposed here?
>>>>>
>>>>>   http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374609.html
>>>>>
>>>>> At some point, we need to consider whether or not we want to continue
>>>>> adding new HWCAPs or whether your suggestion above is actually useful
>>>>> to userspace.
>>>>
>>>> IMO, even if we merge the MRS emulation, I would still like to see
>>>> HWCAPs exported. We are not short on bits yet (53 to go ;)).
>>>
>>> I'm less keen. HWCAPs don't align well with the way that the ARM
>>> architecture versions features and we should be encouraging people to
>>> use the MRS emulation if it exists.
>>>
>>>>> Did the libc guys get anywhere with a prototype? What do we need to do
>>>>> to make progress with it?
>>>>
>>>> This investigation should indeed continue but I think it is orthogonal.
>>>
>>> Not if its intended to replace HWCAPs in the longterm.
>>>
>>
>> userspace needs HWCAP bits independently of the MIDR emulation.
>>
>> MIDR cannot replace HWCAP:
>>
>> - MIDR does not map to features in a future-proof way
>>   (we don't know which MIDR will indicate fp16 availability)
>>
>> - MIDR would be useful for more fine-grained uarch specific
>>   tuning decisions, HWCAP is for arch extensions like fp16.
>>
>> - We don't yet know if the proposed MIDR emulation solves
>>   all userspace issues we want it to solve. I'll try to
>>   investigate that as well as the alternative VDSO based
>>   approach (if VDSO can work, that would be better for
>>   userspace). There are nasty issues here so the conclusion
>>   might take a while, but that should not hold up HWCAPs.
> 
> I'm not solely proposing MIDR as an alternative to HWCAP. I'm proposing
> that the feature registers, e.g. ID_AA64MMFR0_EL1 are used instead.
> 

if the ID_* system registers are made available to userspace
(with fixup for heterogeneous systems), that works too.

hwcap is still more accessible in userspace:

- libc gets it without additional syscall/trap
- user code can get it with getauxval(AT_HWCAP)
- ifunc resolvers take a hwcap argument.
- HWCAP_ bits are already exposed in uapi headers.

i'm not familiar with the ID_ regs though.