1. 28 Oct, 2008 7 commits
    • Paul Mundt's avatar
      sh: Simplify and lock down the ISA tuning. · b2d86a3f
      Paul Mundt authored
      The ISA tuning as it is today can not cope with all of the different
      variations that are possible, so all we can do is a best attempt based on
      the CPU family. The DSP and FPU generation are already at odds with each
      other, and the nommu tuning we weren't handling at all.  Additionally,
      for platforms that never had an FPU, the -nofpu variant never existed,
      meaning that we would lose out on family granular tuning completely in
      certain cases.
      
      With tat out of the way, we were also using -up versions, allowing for
      later instructions that branched off of a particular subset of the ISA,
      but are not actually reflected on the hardware being targetted. This
      leads to some confusion, and the possibility of bogus instructions on
      older parts. Kill that off and lock it down to the family being built
      for specifically.
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      b2d86a3f
    • Paul Mundt's avatar
      1a306032
    • Paul Mundt's avatar
      sh: Add on-chip RTC support for SH7722. · b4d36a25
      Paul Mundt authored
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      b4d36a25
    • Kuninori Morimoto's avatar
      SH 7366 needs SCIF_ONLY · 5ca8c485
      Kuninori Morimoto authored
      SH 7366 has compile bug.
      because there is no SCIF_ONLY for SH 7366.
      this patch add it.
      Signed-off-by: default avatarKuninori Morimoto <morimoto.kuninori@renesas.com>
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      5ca8c485
    • Nobuhiro Iwamatsu's avatar
      gdrom: Fix compile error · 545727f3
      Nobuhiro Iwamatsu authored
      Return value and argument of block_device_operations.release of gdrom
      was changed.
      This patch fix this problem.
      Signed-off-by: default avatarNobuhiro Iwamatsu <iwamatsu@nigauri.org>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      545727f3
    • Kuninori Morimoto's avatar
    • Paul Mundt's avatar
      sh: Fix FPU tuning on toolchains with mismatched multilib targets. · 8a2fd5f3
      Paul Mundt authored
      Presently there is very little standing in the way of using an SH-4
      toolchain for building an SH-2 kernel, and vice versa. Binutils itself
      has no limitations whatsoever and supports explicit ISA hinting, which
      we already use with varying degrees of success today.
      
      This leaves GCC as the odd one out, due to a rather dubious policy
      decision by the GCC folks to not include all of the CPU family variants
      in the default list of multilib targets in GCC4. Despite best efforts to
      the contrary, libgcc itself already contains awareness of the various CPU
      types and remains generally usable, allowing it to safely be referenced
      even on a mismatched target (and indeed, explicit ISA tuning by binutils
      keeps us honest in terms of ensuring that we do not link incompatible
      objects in).
      
      In order to support this, a couple of changes had to be made. Firstly,
      the introduction of MAYBE_DECLARE_EXPORT(), which provides a __weak
      extern reference for libgcc resident routines when finer-grained
      -m<cpu-family> based tuning is not supported by the toolchain. This
      fixes up the __sdivsi3_i4i and __udivsi3_i4i references when dealing
      with SH-2 kernels linked with an SH-4 libgcc. Secondly, in case where we
      are unable to find a suitable match for CPU family tuning but still
      have a toolchain that defaults to FP instruction generation, a suitable
      nofpu target must be selected. This is accomplished by selecting the
      first nofpu multilib target supported by the toolchain, which is
      also necessary for selecting the proper libgcc to link against.
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      8a2fd5f3
  2. 27 Oct, 2008 33 commits