From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Paul Cercueil <paul@crapouillou.net>
Cc: "Zhou Yanjie" <zhouyanjie@wanyeetech.com>,
"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
"Paul Burton" <paulburton@kernel.org>,
"Krzysztof Kozlowski" <krzk@kernel.org>,
od@zcrc.me, linux-kernel@vger.kernel.org,
linux-mips@vger.kernel.org, 漆鹏振 <aric.pzqi@ingenic.com>,
dongsheng.qiu@ingenic.com, rick.tyliu@ingenic.com,
yanfei.li@ingenic.com, xuwanhao@wanyeetech.com
Subject: Re: [PATCH 00/13] MIPS: Convert Ingenic to a generic board
Date: Sat, 22 Aug 2020 03:29:36 +0100 (BST) [thread overview]
Message-ID: <alpine.LFD.2.21.2008220310130.3460685@eddie.linux-mips.org> (raw)
In-Reply-To: <4SSFFQ.3I498N5I41LP3@crapouillou.net>
Hi Paul,
> > FAOD <cpu-feature-overrides.h> is not a hack, but an optimisation measure
> > so that features known to be hardwired for a given machine/CPU do not have
> > to be dynamically queried every time referred. In some cases that results
> > in large portions of code being optimised away by the compiler as well.
>
> Fair enough. Bloat-o-meter reports about ~100 KiB saved when that file is
> present. But we can't use it in a generic kernel, unfortunately.
Well, run-time patching might be an alternative to get the best of both
worlds, but someone would have to reimplement our feature selection system
to use it.
> > The hardcoded value for a feature defined in <cpu-feature-overrides.h>
> > always has to be the same as one in the corresponding bit of the `options'
> > member of `struct cpuinfo_mips', in this case MIPS_CPU_TLBINV.
>
> In theory yes, in practice the CPU detection code is lagging behind...
I wasn't aware of that. In that case it has been a design abuse which
has been missed by the maintainer when accepting patches. It used to be
the case that run-time detection was accurate and overrides were rather
lazily added.
Also I note Ingenic must have had a CPU erratum if our `decode_configs'
doesn't just work, as the interpretation of CP0.Config[5:0] registers has
been architectural and mandatory, and that for a reason. It's only legacy
MIPS I-IV processors that should require special attention here.
Maciej
next prev parent reply other threads:[~2020-08-22 2:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-03 17:01 [PATCH 00/13] MIPS: Convert Ingenic to a generic board Paul Cercueil
2020-08-03 17:01 ` [PATCH 01/13] MIPS: cpu-probe: Set Ingenic's writecombine to _CACHE_CACHABLE_WA Paul Cercueil
2020-08-03 17:01 ` [PATCH 02/13] MIPS: cpu-probe: Mark XBurst CPU as having vtagged caches Paul Cercueil
2020-08-03 17:01 ` [PATCH 03/13] MIPS: cpu-probe: ingenic: Fix broken BUG_ON Paul Cercueil
2020-08-03 17:01 ` [PATCH 04/13] MIPS: Kconfig: add MIPS_GENERIC_KERNEL symbol Paul Cercueil
2020-08-03 17:01 ` [PATCH 05/13] MIPS: machine: Add get_system_type callback Paul Cercueil
2020-08-03 17:01 ` [PATCH 06/13] MIPS: generic: Call the machine's .get_system_type callback if provided Paul Cercueil
2020-08-11 12:43 ` Paul Cercueil
2020-08-03 17:01 ` [PATCH 07/13] MIPS: generic: Support booting with built-in or appended DTB Paul Cercueil
2020-08-03 17:01 ` [PATCH 08/13] MIPS: generic: Add support for zboot Paul Cercueil
2020-08-03 17:01 ` [PATCH 09/13] MIPS: generic: Increase NR_IRQS to 256 Paul Cercueil
2020-08-03 17:01 ` [PATCH 10/13] MIPS: generic: Add support for Ingenic SoCs Paul Cercueil
2020-08-03 17:01 ` [PATCH 11/13] MIPS: jz4740: Drop folder Paul Cercueil
2020-08-03 17:01 ` [PATCH 12/13] MIPS: configs: Regenerate configs of Ingenic boards Paul Cercueil
2020-08-03 17:01 ` [PATCH 13/13] MAINTAINERS: Update paths to Ingenic platform code Paul Cercueil
2020-08-07 17:22 ` Zhou Yanjie
2020-08-07 17:43 ` Zhou Yanjie
2020-08-07 16:23 ` [PATCH 00/13] MIPS: Convert Ingenic to a generic board Zhou Yanjie
2020-08-07 16:45 ` Paul Cercueil
2020-08-07 17:20 ` Zhou Yanjie
2020-08-08 2:39 ` Jiaxun Yang
2020-08-21 19:23 ` Maciej W. Rozycki
2020-08-21 23:19 ` Paul Cercueil
2020-08-22 2:29 ` Maciej W. Rozycki [this message]
2020-08-22 13:17 ` Paul Cercueil
2020-08-22 14:00 ` Maciej W. Rozycki
2020-10-26 14:25 ` Zhou Yanjie
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=alpine.LFD.2.21.2008220310130.3460685@eddie.linux-mips.org \
--to=macro@linux-mips.org \
--cc=aric.pzqi@ingenic.com \
--cc=dongsheng.qiu@ingenic.com \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=od@zcrc.me \
--cc=paul@crapouillou.net \
--cc=paulburton@kernel.org \
--cc=rick.tyliu@ingenic.com \
--cc=tsbogend@alpha.franken.de \
--cc=xuwanhao@wanyeetech.com \
--cc=yanfei.li@ingenic.com \
--cc=zhouyanjie@wanyeetech.com \
/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).