1. 16 7月, 2012 2 次提交
    • S
      m68knommu: Add support for the Coldfire m5441x. · bea8bcb1
      Steven King 提交于
      Add support for the Coldfire 5441x (54410/54415/54416/54417/54418).  Currently
      we only support noMMU mode.  It requires the PIT patch posted previously as it
      uses the PIT instead of the dma timer as a clock source so we can get all that
      GENERIC_CLOCKEVENTS goodness.  It also adds some simple clk definitions and
      very simple minded power management.  The gpio code is tweeked and some
      additional devices are added to devices.c.  The Makefile uses -mv4e as
      apparently, the only difference a v4m (m5441x) and a v4e is the later has a
      FPU, which I don't think should matter to us in the kernel.
      Signed-off-by: NSteven King <sfking@fdwdc.com>
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      bea8bcb1
    • S
      m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips. · eac57949
      Steven King 提交于
      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: NSteven King <sfking@fdwdc.com>
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      eac57949
  2. 24 12月, 2011 1 次提交
  3. 31 3月, 2011 1 次提交
  4. 05 1月, 2011 1 次提交
    • G
      m68knommu: make Coldfire 548x support more generic · 5b2e6555
      Greg Ungerer 提交于
      The ColdFire 547x family of processors is very similar to the ColdFire
      548x series. Almost all of the support for them is the same. Make the
      code supporting the 548x more gneric, so it will be capable of
      supporting both families.
      
      For the most part this is a renaming excerise to make the support
      code more obviously apply to both families.
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      5b2e6555
  5. 21 10月, 2010 1 次提交
  6. 10 9月, 2009 1 次提交