linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: sid@reserved-bit.com (Siddhesh Poyarekar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: Add support for Half precision floating point
Date: Thu, 28 Jan 2016 23:14:28 +0530	[thread overview]
Message-ID: <20160128174428.GD17552@devel.intra.reserved-bit.com> (raw)
In-Reply-To: <20160128172705.GC20099@e104818-lin.cambridge.arm.com>

On Thu, Jan 28, 2016 at 05:27:05PM +0000, Catalin Marinas wrote:
> Suzuki's MRS emulation only exposes the CPU feature registers and not
> the MIDR. So this would help with choosing implementation based on
> features (e.g. crypto) but not for micro-architecture tuning.

Umm, I'm pretty sure it does, at least the patchset I tested back in
October did.  I think you may be confusing with revidr.

> I don't think you would get such assurance. Basically how the CPUs are
> connected on a system is the property of a SoC and not of the CPU (nor
> MIDR). I know it's not helpful but we don't really have an option (other
> than using made-up MIDR values with some reserved vendor id field and a
> central, OS-agnostic database to describe the real MIDRs).

... which means we would end up traversing all of /sysfs and/or check
CPU feature registers for this information, which makes a more optimal
API even more important.

> So are you only interested in MIDR for microarchitecture tuning? Would
> glibc make any use of the feature registers exposed via MRS emulation
> (and so far mirrored by HWCAP bits, well, as long as we can still do
> this sanely)?

My primary interest is exploring the ability to identify CPUs of
specific vendors (and specific make/models) based on their MIDR.
However, we would definitely also like to use the CPU feature bits to
enhance specific parts of glibc, like vectorized string/memory
routines for processors that support them.

Siddhesh

  reply	other threads:[~2016-01-28 17:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-26 15:52 [PATCH] arm64: Add support for Half precision floating point Suzuki K Poulose
2016-01-26 16:02 ` Will Deacon
2016-01-26 16:11   ` Catalin Marinas
2016-01-28 16:00     ` Will Deacon
2016-02-16 11:48       ` Szabolcs Nagy
2016-02-16 11:53         ` Will Deacon
2016-02-16 12:57           ` Szabolcs Nagy
2016-01-26 16:21   ` Suzuki K. Poulose
2016-01-26 16:55     ` Siddhesh Poyarekar
2016-01-28 16:07       ` Will Deacon
2016-01-28 16:46         ` Siddhesh Poyarekar
2016-01-28 17:27           ` Catalin Marinas
2016-01-28 17:44             ` Siddhesh Poyarekar [this message]
2016-01-28 17:55               ` Suzuki K. Poulose
2016-01-28 16:51         ` Adhemerval Zanella
2016-02-02 17:31           ` Szabolcs Nagy
2016-02-02 18:12             ` Adhemerval Zanella
2016-02-02 18:25               ` Szabolcs Nagy
2016-02-02 18:28                 ` Adhemerval Zanella
2016-02-26 15:37 ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160128174428.GD17552@devel.intra.reserved-bit.com \
    --to=sid@reserved-bit.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).