1. 05 Feb, 2009 8 commits
    • Kevin Hilman's avatar
      IDE: palm_bk3710: use ioremap instead of arch-specific IO_ADDRESS() · 83824d0a
      Kevin Hilman authored
      Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      83824d0a
    • David Brownell's avatar
      drivers/ide/palm_bk3710.c buildfix · 6fc285cf
      David Brownell authored
      CC      drivers/ide/palm_bk3710.o
      drivers/ide/palm_bk3710.c: In function 'palm_bk3710_probe':
      drivers/ide/palm_bk3710.c:382: warning: assignment makes integer from pointer without a cast
      
      Someone should fix hw_regs_t to neither be a typedef, nor
      use "unsigned long" where it should use "void __iomem *".
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      (cherry picked from commit ef183f6b)
      6fc285cf
    • Kevin Hilman's avatar
      watchdog: davinci: convert to ioremap() + io[read|write] · b15b0df2
      Kevin Hilman authored
      Remove davinci platform-specific IO accessor macros in favor
      of standard ioremap + io[read|write]* functions.
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      b15b0df2
    • Kevin Hilman's avatar
      davinci: add arch_ioremap() which uses existing static mapping · b523bb95
      Kevin Hilman authored
      Add arch-specific ioremap() which uses any existing static mappings
      in place of doing a new mapping.  From now on, drivers should always
      use ioremap() instead of IO_ADDRESS().
      
      In addition, remove the davinci_[read|write]* macros in favor of using
      ioremap + io[read|write]*.
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      b523bb95
    • David Brownell's avatar
      davinci_nand: clean up the A1CR hacks · d776fbaa
      David Brownell authored
      The A1CR hacks aren't really needed on the DM355 EVM; NAND timings
      set by UBL (or whatever) are a bit slower than needed, but that's
      not too bad.  Remove, but add a comment in board setup.
      
      For the DM6446 EVM, the problem is how to cope with re-jumpering
      in the default boot-from-NOR case.  Boards modified to boot from
      NAND should already have A1CR timings set up.  Comment this; for
      the moment it's a bit nasty to move this code to board setup.
      (And remove pointless AWRCC setting.  The "Extended Wait" mode
      doesn't work with NAND chips.)
      
      Related -- make board-dm6446-evm.c warn about trying to make NAND
      and NOR coexist, and only set up one of them.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      d776fbaa
    • David Brownell's avatar
      davinci_nand: chipselects, we got your chipselects · 07a05972
      David Brownell authored
      Support various flavors of chipselect:
      
       - EMIF chipselects, controlled by platform_device.id;
         now uses a spinlock for NANDFCR mutual exclusion.
      
       - NAND packages with multiple chipselects, with a new
         platform data field; use that for the dm355 EVM.
      
      The EMIF CS support is only sanity tested; needs more, on a
      board using NAND and HWECC on a nonzero chipselect.
      
      Update the "no NAND chip" message so it doesn't presume a hack
      specific to the dm6446evm:  "boot via NOR, then swap CS0 jumper";
      and use the errno returned from nand_scan.
      
      Plus minor tweaks:  rename 1-bit ECC procedures to match current
      method names, not old 2.6.10 ones; and include marker comments
      between driver sections.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      07a05972
    • David Brownell's avatar
      davinci_nand: allow board-specific config · 2acdf27b
      David Brownell authored
      Define and use a DaVinci-specific NAND platform_data structure,
      instead of reusing generic NOR platform_data.  Improvements:
      
       - ALE and CLE bits are no longer hard-wired
       - ECC mode is in board-specific data, not a Kconfig option
       - Supports board-specific options like BUSWIDTH_16 and FLASH_BBT
      
      Plus:
      
       - Don't force the use of MTD partitioning
       - Make that platform data be optional
       - Now pdev->id specifies chipselect (must be zero for now)
       - Add missing iounmap calls on probe failure
      
      And corresponding updates for NAND support on the two EVM boards
      that now have it.  Note that dm355 evm boards will fail cleanly
      on boot now, pending 4-bit ECC support.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      2acdf27b
    • David Brownell's avatar
      davinci_nand: use standard badblock support · 7ab1eee5
      David Brownell authored
      Make the DaVinci NAND driver use standard Linux badblock
      table support, by removing a mangled clone of that code.
      
      NAND_USB_FLASH_BBT is a better (faster, clearer) and more
      widely used solution for speedier boot than such needless
      hacks.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      7ab1eee5
  2. 31 Jan, 2009 3 commits
  3. 29 Jan, 2009 3 commits
  4. 27 Jan, 2009 4 commits
  5. 19 Jan, 2009 8 commits
    • David Brownell's avatar
      EDMA TC selection updates · 3c8fcf77
      David Brownell authored
      Minor tweaks:
      
        - Bugfix handling of EVENTQ_DEFAULT ... recognize it, and
          implement as EVENTQ_1 instead of reserved/illegal value
      
        - Use the defined enum type internally
      
        - Have MMC use TC1, as appropriate for "longer, nonreal-time
          sensitive transfers" (per docs) ... instead of using TC0,
          as for "urgent, small, real-time sensitive transfers".
      
      Arguably, TC0 priority should be increased (to 0) to be
      higher priority than the ARM ... matching "urgent" etc.
      
      The added TCs on DM646x chips are still not recognized.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      3c8fcf77
    • David Brownell's avatar
      EDMA renames: all remaining operations · 9df2a6b8
      David Brownell authored
      This patch primarily renames functions to use an edma_ prefix and remove
      a needless infix "_dma_" token.  Again, parameters which identify parameter
      RAM slots were renamed as "slot" from "lch".
      
      Also, edma_get_position() was moved to be adjacent to the other operations
      that rely on just a few fields of a parameter RAM slot.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      9df2a6b8
    • David Brownell's avatar
      EDMA renames: remaining parameter RAM ops · 18478af5
      David Brownell authored
      This patch primarily renames functions to use an edma_ prefix and remove
      a needless infix "_dma_" token ... except that "src_params" became "src",
      and "dest_params" became "dest".  Parameters which identify parameter RAM
      slots were renamed as "slot" from "lch".
      
      Also, the slot numbers become unsigned (supporting a minor code shrink),
      and a handful of needless temporary variables were removed.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      18478af5
    • David Brownell's avatar
      EDMA renames: edma_start(), edma_stop() · b69e435d
      David Brownell authored
      These functions now only accept channels, since reload slots can
      never be independently active.  Change parameter to unsinged, to
      allow a minor code shrink.  Remove pointless foof in edma_stop():
      the channel's parameter RAM slot must be reinitialized, so there
      is no reason to modify it unless chaining is being misused; and
      just updating the link register can't protect aginst chain bugs.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      b69e435d
    • David Brownell's avatar
      EDMA: split channel/slot resource management · 62ef2b07
      David Brownell authored
      EDMA interface update for channel and parameter RAM slot alloc/free.
      This is the biggest of these changes, since it's non-cosmetic.
      
       - Stop talking about "master" and "slave"!  Instead, use the notions
         exposed by the hardware:  a DMA "channel", and a PaRAM slot.  This
         is a general doc/comment update, and affects calling conventions.
      
       - Split davinci_request_dma() into two simpler routines:
           * edma_alloc_channel() with three fewer parameters
           * edma_alloc_slot() with just one parameter (may be a wildcard)
         The test for successful returns is "value < 0", not "value != 0";
         non-negative values are the returned channel or slot number.
      
       - Split davinci_free_dma() into two routines, both of which update
         the now-free parameter RAM slot to hold a dummy transfer.
           * void edma_free_channel(unsigned channel)
           * void edma_free_slot(unsigned slot);
      
       - Fill all PaRAM slots with dummy transfers when they're not in use.
      
       - Change the channel and slot numbers to "unsigned" in some cases so
         we can avoid some tests for invalid parameters.
      
      A key notion here is to *stop* fuzzing distinctions between DMA channels
      and parameter RAM slots.  This makes it easier to match these calls to
      hardware docs, and harder to get confused by differences; channels are
      (potentially) active, while slots are always passive.
      
      Transfer Completion Code (TCC) values are no longer supported except
      through the calls which manipulate entire parameter RAM sets.  This
      means that completion IRQ setup (for audio) is a bit different.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      62ef2b07
    • David Brownell's avatar
      EDMA interface renames: edma_link(), edma_unlink() · ff2f60e6
      David Brownell authored
      Another EDMA interface update.  Fixes documentation for the linking
      calls to be kerneldoc style.  Rename parameters so they're meaningful
      (from/to vs lch/lch_que) and unsigned (eliminates some error checks).
      Remove unused edma_unlink() parameter.  Move this code so it's grouped
      with the other calls which only modify parameter RAM.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      ff2f60e6
    • David Brownell's avatar
      EDMA renames: edma_read_slot(), edma_write_slot() · ce31af1d
      David Brownell authored
      This renames two parameter RAM calls that read and write entire param
      sets, and re-focusses their descriptions on the fact that they update
      parameter RAM.  That has nothing *directly* to do with any hardware DMA
      channel.  Switch to unsigned params, letting some error checks be removed.
      
      It also starts updating the dma.c comments to reflect the different
      structural blocks of the programming interface, calling out the two
      groups of parameter RAM operations and channel control operations.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      ce31af1d
    • Chaithrika U S's avatar
      ARM DaVinci: Low level debug macros for DaVinci Platforms · e890af73
      Chaithrika U S authored
      This patch defines debug macros for low-level debugging for Davinci based
      platforms
      
      Tested on :
              - DM644x DaVinci EVM
              - DM646X DaVinciHD EVM
      	- DM355 EVM
      
      This patch attempts to solve the low-level debug issue in DM646x. The UART
      on DM646x SoC allows only 32-bit access. The existing debug-macro.S uses the
      macros from debug-8250.S file. This led to garbage serial out in the case of
      DM646x.
      
      The inclusion of debug-8250.S does not allow for run time fix for this issue.
      There are compile time errors due to multiple definitions of the macros.
      Also when building a single image for multiple DaVinci Platforms, the ifdefs
      cannot be relied upon.
      
      The solution below does not include the debug-8250.S file and defines the
      necessary macros. This solution was arrived at after observing that word
      access does not affect the low-level debug messages on DM644x/DM355.
      
      The other approach to this issue is to use the UART module information
      available in the peripheral registers to decide the access mechanism. But this
      will have to be done for every access of UART specifically for DM646x. Also
      this calls for a modification of the debug-8250.S file.
      Signed-off-by: default avatarChaithrika U S <chaithrika@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      e890af73
  6. 16 Jan, 2009 5 commits
  7. 12 Jan, 2009 2 commits
  8. 09 Jan, 2009 1 commit
  9. 08 Jan, 2009 6 commits