[lkml]   [2020]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 00/13] MIPS: Convert Ingenic to a generic board

Le sam. 22 août 2020 à 3:29, Maciej W. Rozycki <>
a écrit :
> 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.

Would run-time patching allow to drop dead code?

>> > 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.

Yes, Ingenic CPUs have a few bloopers here and there...


 \ /
  Last update: 2020-08-22 15:19    [W:1.528 / U:26.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site