Commit Graph

12 Commits

Author SHA1 Message Date
Rich Felker 6cb465972c sh: fix build failure for J2 cpu with SMP disabled
The sh asm/smp.h defines a fallback hard_smp_processor_id macro for
the !SMP case, but linux/smp.h never includes asm/smp.h in the !SMP
case.

Signed-off-by: Rich Felker <dalias@libc.org>
2018-05-05 16:51:40 -04:00
Rich Felker 834da19705 sh: add AT_HWCAP flag for J-Core cas.l instruction
The J-Core cpu has, as an ISA extension, an atomic compare-and-swap
instruction cas.l which applications need to use (instead the imask or
gusa atomic models, which are fundamentally limited to UP) for
synchronization in order to be compatible with SMP systems. Provide a
hwcap flag so that it's possible to do runtime selection and support
both.

Signed-off-by: Rich Felker <dalias@libc.org>
2016-08-05 03:29:32 +00:00
Rich Felker 5a846abad0 sh: add support for J-Core J2 processor
At the CPU/ISA level, the J2 is compatible with SH-2, and thus the
changes to add J2 support build on existing SH-2 support. However, J2
does not duplicate the memory-mapped SH-2 features like the cache
interface. Instead, the cache interfaces is described in the device
tree, and new code is added to be able to access the flat device tree
at early boot before it is unflattened.

Support is also added for receiving interrupts on trap numbers in the
range 16 to 31, since the J-Core aic1 interrupt controller generates
these traps. This range was unused but nominally for hardware
exceptions on SH-2, and a few values in this range were used for
exceptions on SH-2A, but SH-2A has its own version of the relevant
code.

No individual cpu subtypes are added for J2 since the intent moving
forward is to represent SoCs with device tree rather than as
hard-coded subtypes in the kernel. The CPU_SUBTYPE_J2 Kconfig item
exists only to fit into the existing cpu selection mechanism until it
is overhauled.

Signed-off-by: Rich Felker <dalias@libc.org>
2016-08-05 03:29:31 +00:00
Paul Gortmaker 4603f53a1d sh: delete __cpuinit usage from all sh files
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

Note that some harmless section mismatch warnings may result, since
notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
are flagged as __cpuinit  -- so if we remove the __cpuinit from
arch specific callers, we will also get section mismatch warnings.
As an intermediate step, we intend to turn the linux/init.h cpuinit
content into no-ops as early as possible, since that will get rid
of these warnings.  In any case, they are temporary and harmless.

This removes all the arch/sh uses of the __cpuinit macros from
all C files.  Currently sh does not have any __CPUINIT used in
assembly files.

[1] https://lkml.org/lkml/2013/5/20/589

Cc: Paul Mundt <lethal@linux-sh.org>
Cc: linux-sh@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2013-07-14 19:36:53 -04:00
Paul Mundt a9079ca0cb sh: Tidy CPU probing and fixup section annotations.
This does a detect_cpu_and_cache_system() -> cpu_probe() rename, tidies
up the unused return value, and stuffs it under __cpuinit in preparation
for CPU hotplug.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2010-04-21 12:01:06 +09:00
Paul Mundt e82da214d2 sh: Track the CPU family in sh_cpuinfo.
This adds a family member to struct sh_cpuinfo, which allows us to fall
back more on the probe routines to work out what sort of subtype we are
running on. This will be used by the CPU cache initialization code in
order to first do family-level initialization, followed by subtype-level
optimizations.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2009-08-15 10:48:13 +09:00
Paul Mundt cb7af21f7d sh: Use boot_cpu_data for CPU probe.
This moves off of smp_processor_id() and only sets the probe
information for the boot CPU directly. This will be copied out
for the secondaries, so there's no reason to do this each time.

This also allows for some header tidying.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2007-09-27 18:18:39 +09:00
Paul Mundt 357d59469c sh: Tidy up dependencies for SH-2 build.
SH-2 can presently get in to some pretty bogus states, so
we tidy up the dependencies a bit and get it all building
again.

This gets us a bit closer to a functional allyesconfig
and allmodconfig, though there are still a few things to
fix up.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2007-06-11 15:32:07 +09:00
Paul Mundt b9601c5e59 sh: Kill off dead SH7604 support.
This was added during 2.5.x, but was never moved along. This
can easily be resurrected if someone has one they wish to work
with, but it's not worth keeping around in its current form.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2007-06-08 11:55:28 +09:00
Paul Mundt 11c1965687 sh: Fixup cpu_data references for the non-boot CPUs.
There are a lot of bogus cpu_data-> references that only end up working
for the boot CPU, convert these to current_cpu_data to fixup SMP.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2007-02-13 10:54:45 +09:00
Yoshinori Sato 9d4436a6fb sh: Add support for SH7206 and SH7619 CPU subtypes.
This implements initial support for the SH7206 (SH-2A) and SH7619
(SH-2) MMU-less CPUs.

Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2006-12-06 10:45:36 +09:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00