04 Mar, 2014

1 commit

  • Commit bcf24e1daa94 ("mmc: omap_hsmmc: use the generic config for
    omap2plus devices"), enabled the build for other platforms for compile
    testing.

    sh-allmodconfig now fails with:

    include/linux/omap-dma.h:171:8: error: expected identifier before numeric constant
    make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1

    This happens because SuperH #defines "CCR", which is one of the enum
    values in include/linux/omap-dma.h. There's a similar issue with "CCR2"
    on sh2a.

    As "CCR" and "CCR2" are too generic names for global #defines, prefix
    them with "SH_" to fix this.

    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Geert Uytterhoeven
     

15 Jul, 2013

1 commit

  • 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
    Cc: linux-sh@vger.kernel.org
    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

29 Mar, 2012

1 commit


26 Oct, 2010

1 commit

  • CPUs can be in either the legacy 29-bit or 32-bit physical addressing
    modes. This follows the x86 approach of tracking the phys bits in cpuinfo
    and exposing it to userspace through procfs.

    This change was requested to permit kexec-tools to detect the physical
    addressing mode in order to determine the appropriate address mangling.

    Signed-off-by: Paul Mundt

    Paul Mundt
     

21 Apr, 2010

2 commits


17 Feb, 2010

1 commit

  • vmemmap and the vmsplit code amongst others need to be able to take page
    faults much earlier than trap_init() time, so move this in to the early
    CPU initialization. VBR setup for secondary CPUs is already handled
    through start_secondary(), so we only need to do this for the boot CPU.

    Signed-off-by: Paul Mundt

    Paul Mundt
     

26 Jan, 2010

1 commit

  • The old ctrl in/out routines are non-portable and unsuitable for
    cross-platform use. While drivers/sh has already been sanitized, there
    is still quite a lot of code that is not. This converts the arch/sh/ bits
    over, which permits us to flag the routines as deprecated whilst still
    building with -Werror for the architecture code, and to ensure that
    future users are not added.

    Signed-off-by: Paul Mundt

    Paul Mundt
     

21 Jan, 2010

1 commit


13 Jan, 2010

2 commits

  • Paul Mundt
     
  • This follows the x86 xstate changes and implements a task_xstate slab
    cache that is dynamically sized to match one of hard FP/soft FP/FPU-less.

    This also tidies up and consolidates some of the SH-2A/SH-4 FPU
    fragmentation. Now fpu state restorers are commonly defined, with the
    init_fpu()/fpu_init() mess reworked to follow the x86 convention.
    The fpu_init() register initialization has been replaced by xstate setup
    followed by writing out to hardware via the standard restore path.

    As init_fpu() now performs a slab allocation a secondary lighterweight
    restorer is also introduced for the context switch.

    In the future the DSP state will be rolled in here, too.

    More work remains for math emulation and the SH-5 FPU, which presently
    uses its own special (UP-only) interfaces.

    Signed-off-by: Paul Mundt

    Paul Mundt
     

05 Jan, 2010

1 commit


04 Dec, 2009

1 commit


24 Nov, 2009

1 commit

  • A number of small optimisations to FPU handling, in particular:

    - move the task USEDFPU flag from the thread_info flags field (which
    is accessed asynchronously to the thread) to a new status field,
    which is only accessed by the thread itself. This allows locking to
    be removed in most cases, or can be reduced to a preempt_lock().
    This mimics the i386 behaviour.

    - move the modification of regs->sr and thread_info->status flags out
    of save_fpu() to __unlazy_fpu(). This gives the compiler a better
    chance to optimise things, as well as making save_fpu() symmetrical
    with restore_fpu() and init_fpu().

    - implement prepare_to_copy(), so that when creating a thread, we can
    unlazy the FPU prior to copying the thread data structures.

    Also make sure that the FPU is disabled while in the kernel, in
    particular while booting, and for newly created kernel threads,

    In a very artificial benchmark, the execution time for 2500000
    context switches was reduced from 50 to 45 seconds.

    Signed-off-by: Stuart Menefy
    Signed-off-by: Paul Mundt

    Stuart Menefy
     

16 Oct, 2009

1 commit

  • This code was added for some ancient SH-4 solution engines with peculiar
    boot ROMs that did silly things to the UBC MSTP bits. None of these have
    been in the wild for years, and these days the clock framework wraps up
    the MSTP bits, meaning that the UBC code is one of the few interfaces
    that is stomping MSTP bits underneath the clock framework. At this point
    the risks far outweigh any benefit this code provided, so just kill it
    off.

    Signed-off-by: Paul Mundt

    Paul Mundt
     

19 Aug, 2009

1 commit


15 Aug, 2009

2 commits

  • This does a bit of reorganizing for allowing nommu to use the new
    and generic cache.c, no functional changes.

    Signed-off-by: Paul Mundt

    Paul Mundt
     
  • This implements EXPMASK initialization code for SH-4A parts, where it is
    possible to disable compat features that will go away in newer cores.
    Presently this includes disabling support for non-nop instructions in the
    rte delay slot, as well as a sleep instruction being placed in a delay
    slot (neither of which the kernel does any longer). As a result of this,
    any future offenders will have illegal slot exceptions generated for
    them.

    Associative writes for the memory-mapped cache array are still left
    enabled, until such a point that special cache operations for SH-4A are
    provided to move off of the current (and rather dated) SH-4 versions.

    Signed-off-by: Paul Mundt

    Paul Mundt
     

02 Jun, 2009

1 commit


22 Dec, 2008

1 commit


06 Mar, 2008

1 commit


28 Jan, 2008

4 commits


21 Sep, 2007

2 commits

  • There was a very preliminary bunch of SMP code scattered around for the
    SH7604 microcontrollers from way back when, and it has mostly suffered
    bitrot since then. With the tree already having been slowly getting
    prepped for SMP, this plugs in most of the remaining platform-independent
    bits.

    Signed-off-by: Magnus Damm
    Signed-off-by: Paul Mundt

    Paul Mundt
     
  • This reworks the cache mode configuration in Kconfig, and allows for
    explicit selection of write-back/write-through/off configurations.
    All of the cache flushing routines are optimized away for the off
    case.

    Signed-off-by: Paul Mundt

    Paul Mundt
     

11 Jun, 2007

1 commit

  • 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

    Paul Mundt
     

07 May, 2007

1 commit

  • SH7780 has a speculative execution mode where it can speculatively
    perform an instruction fetch for subroutine returns, this allows it
    to be enabled. There are some various pitfalls associated with this
    mode, so it's left as depending on CONFIG_EXPERIMENTAL and not
    enabled by default.

    Signed-off-by: Paul Mundt

    Paul Mundt
     

12 Mar, 2007

1 commit


13 Feb, 2007

2 commits


06 Dec, 2006

1 commit


27 Sep, 2006

2 commits


01 Apr, 2006

1 commit

  • The boot cmdline is parsed in parse_early_param() and
    parse_args(,unknown_bootoption).

    And __setup() is used in obsolete_checksetup().

    start_kernel()
    -> parse_args()
    -> unknown_bootoption()
    -> obsolete_checksetup()

    If __setup()'s callback (->setup_func()) returns 1 in
    obsolete_checksetup(), obsolete_checksetup() thinks a parameter was
    handled.

    If ->setup_func() returns 0, obsolete_checksetup() tries other
    ->setup_func(). If all ->setup_func() that matched a parameter returns 0,
    a parameter is seted to argv_init[].

    Then, when runing /sbin/init or init=app, argv_init[] is passed to the app.
    If the app doesn't ignore those arguments, it will warning and exit.

    This patch fixes a wrong usage of it, however fixes obvious one only.

    Signed-off-by: OGAWA Hirofumi
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    OGAWA Hirofumi
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds