Skip to content

L
linux
Switch branch/tag
  1. 15 Jul, 2012 4 commits
    • Steven King's avatar
      m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips. · eac57949
      Steven King authored 
      If we're not connecting external GPIO extenders via i2c or spi or whatever, we
probably don't need GPIOLIB.  If we provide an alternate implementation of
the GPIOLIB functions to use when only on-chip GPIO is needed, we can change
ARCH_REQUIRE_GPIOLIB to ARCH_WANTS_OPTIONAL_GPIOLIB so that GPIOLIB becomes
optional.

The downside is that in the GPIOLIB=n case, we lose all error checking done by
gpiolib, ie multiply allocating the gpio, free'ing gpio etc., so that the
only checking that can be done is if we reference a gpio on an external part.
Targets that need the extra error checking can still select GPIOLIB=y.

For the case where GPIOLIB=y, we can simplify the table of gpio chips to use a
single chip, eliminating the tables of chips in the 5xxx.c files.  The
original motivation for the definition of multiple chips was to match the way
many of the Coldfire variants defined their gpio as a spare array in memory.
However, all this really gains us is some error checking when we request a
gpio, gpiolib can check that it doesn't fall in one of the holes.  If thats
important, I think we can still come up with a better way of accomplishing
that.

Also in this patch is some general cleanup and reorganizing of the gpio header
files (I'm sure I must have had a reason why I sometimes used a prefix of
mcf_gpio and other times mcfgpio but for the life of me I can't think of it
now).
Signed-off-by: default avatarSteven King <sfking@fdwdc.com>
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      eac57949
    • Greg Ungerer's avatar
      m68k: merge the MMU and non-MMU versions of the entry.S code · 14be4252
      Greg Ungerer authored 
      Some of the entry.S code is common to both MMU and non-MMU builds.
So merge the entry_no.S and entry_mm.S files back into a single file.
With a little code movement we only need a single #ifdef.
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      14be4252
    • Greg Ungerer's avatar
      m68k: use jbsr to call functions instead of bsrl · 28d5445e
      Greg Ungerer authored 
      There is a few places that the m68k entry code uses the bsrl instruction
to call other functions. That instruction is only supported on 68020 and
higher CPU types. If we use jbsr instead the code will be clean for all
68k and ColdFire CPU types.
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      28d5445e
    • Greg Ungerer's avatar
      m68k: use some direct calls to ret_from_exception in entry code · 5bd9dd45
      Greg Ungerer authored 
      The ret_from_excption code is referenced by its function name, or by a label
set at the start of its code. The non-MMU code can share some of this code
if we make direct calls to ret_from_exception instead of the associated label.
The effected function paths are: buserr, trap and ret_from_fork. So change
these to branch directly to ret_from_exception.
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      5bd9dd45
  3. 14 Jul, 2012 11 commits
  5. 13 Jul, 2012 19 commits
  7. 12 Jul, 2012 5 commits
  9. 11 Jul, 2012 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7