1. 03 Jan, 2013 1 commit
    • Greg Kroah-Hartman's avatar
      ARM: drivers: remove __dev* attributes. · 351a102d
      Greg Kroah-Hartman authored
      
      
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, __devinitdata,
      and __devexit from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Russell King <linux@arm.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      351a102d
  2. 26 Oct, 2012 1 commit
  3. 06 Oct, 2012 4 commits
  4. 14 Sep, 2012 1 commit
  5. 05 May, 2012 1 commit
  6. 24 Feb, 2012 2 commits
    • Manjunath Hadli's avatar
      ARM: davinci: streamline sysmod access · 5cfb19ac
      Manjunath Hadli authored
      
      
      There are instances of IO_ADDRESS() being used for system module
      (sysmod) register access. Eliminate this in favor of a ioremap()
      based access. ioremap() the entire sysmod address space once during
      boot-up and provide a helper macro to access specific register
      offsets within the address space.
      
      With this, also eliminate ioremap() of specific sysmodule registers
      related to VPIF happening in DM646x EVM code.
      
      While at it, also eliminate some duplicate sysmod register offset macros
      defined in code and place offset definitions at one place in davinci.h
      Signed-off-by: default avatarManjunath Hadli <manjunath.hadli@ti.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      [nsekhar@ti.com: removed the addition of ifndef __ASSEMBLER__
      in davinci.h, eliminate IO_ADDRESS() usage left out in dm646x.c,
      cleanup VPIF sysmodule register access as part of this patch and
      keep all sysmod offsets in davinci.h Also, convert the WARN_ON()
      on failure to setup sysmod base to BUG_ON()]
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      5cfb19ac
    • Manjunath Hadli's avatar
      ARM: davinci: create new common platform header for davinci · 39c6d2d1
      Manjunath Hadli authored
      Remove individual platform header files for dm365, dm355, dm644x
      and dm646x and consolidate it into a single and common
      header file davinci.h placed in arch/arm/mach-davinci.
      
      This reduces the pollution in the include/mach and is consistent
      with Russell's suggestions as part of his "pet peaves" mail.
      (See #4 in: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/071516.html
      
      )
      
      While at it, fix the forward declaration of spi_board_info,
      and include the right header file instead.
      
      The further patches in the series take  advantage of this consolidation
      for easy implementation of IO_ADDRESS elimination.
      Signed-off-by: default avatarManjunath Hadli <manjunath.hadli@ti.com>
      [nsekhar@ti.com: make davinci.h the first local include file,
      fix forward declaration of spi_board_info and add back Deep Root
      Systems, LLC copyright]
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      39c6d2d1
  7. 27 Jan, 2012 1 commit
    • Sekhar Nori's avatar
      ARM: davinci: update mdio bus name · f6f97588
      Sekhar Nori authored
      Commit 5a05a820
      
       ("davinci_emac:
      use an unique MDIO bus name") introduced during the v3.3 merge
      window updated the davinci mdio bus name to make it unique.
      
      Update the bus name in board files which use DaVinci MDIO bus
      to match the new name. Without this PHY is not detected with
      error like:
      
      PHY 0:01 not found
      net eth0: could not connect to phy 0:01
      
      Tested on DM365 and DA850 EVMs.
      
      Cc: Florian Fainelli <florian@openwrt.org>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      f6f97588
  8. 05 Jan, 2012 1 commit
  9. 05 Dec, 2011 1 commit
  10. 24 Nov, 2011 1 commit
  11. 31 Oct, 2011 1 commit
  12. 21 Aug, 2011 1 commit
  13. 18 Jul, 2011 1 commit
  14. 06 Jul, 2011 1 commit
  15. 20 Oct, 2010 1 commit
    • Nicolas Pitre's avatar
      arm: remove machine_desc.io_pg_offst and .phys_io · 6451d778
      Nicolas Pitre authored
      
      
      Since we're now using addruart to establish the debug mapping, we can
      remove the io_pg_offst and phys_io members of struct machine_desc.
      
      The various declarations were removed using the following script:
      
        grep -rl MACHINE_START arch/arm | xargs \
        sed -i '/MACHINE_START/,/MACHINE_END/ { /\.\(phys_io\|io_pg_offst\)/d }'
      
      [ Initial patch was from Jeremy Kerr, example script from Russell King ]
      Signed-off-by: default avatarNicolas Pitre <nicolas.pitre@linaro.org>
      Acked-by: Eric Miao <eric.miao at canonical.com>
      6451d778
  16. 24 Sep, 2010 2 commits
  17. 05 Aug, 2010 1 commit
  18. 20 Jul, 2010 1 commit
    • Sekhar Nori's avatar
      ASoC: davinci: let platform data define edma queue numbers · 48519f0a
      Sekhar Nori authored
      
      
      Currently the EDMA queue to be used by for servicing ASP through
      internal RAM is fixed to EDMAQ_0 and that to service internal RAM
      from external RAM is fixed to EDMAQ_1.
      
      This may not be the desirable configuration on all platforms. For
      example, on DM365, queue 0 has large fifo size and is more suitable
      for video transfers. Having audio and video transfers on the same
      queue may lead to starvation on audio side.
      
      platform data as defined currently passes a queue number to the driver
      but that remains unused inside the driver.
      
      Fix this by defining one queue each for ASP and RAM transfers in the
      platform data and using it inside the driver.
      
      Since EDMAQ_0 maps to 0, thats the queue that will be used if
      the asp queue number is not initialized. None of the platforms
      currently utilize ping-pong transfers through internal RAM so that
      functionality remains unchanged too.
      
      This patch has been tested on DM644x and OMAP-L138 EVMs.
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Acked-by: default avatarLiam Girdwood <lrg@slimlogic.co.uk>
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      48519f0a
  19. 13 May, 2010 1 commit
    • Cyril Chemparathy's avatar
      Davinci: aintc/cpintc - use ioremap() · bd808947
      Cyril Chemparathy authored
      
      
      This patch implements the following:
      
       - interrupt initialization uses ioremap() instead of passing a virtual address
         via davinci_soc_info.
      
       - machine definitions directly point to cp_intc_init() or davinci_irq_init()
      
       - davinci_intc_type and davinci_intc_base now get initialized in controller
         specific init functions instead of davinci_common_init()
      
       - minor fix in davinci_irq_init() to use intc_irq_num instead of
         DAVINCI_N_AINTC_IRQ
      Signed-off-by: default avatarCyril Chemparathy <cyril@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      bd808947
  20. 06 May, 2010 2 commits
  21. 01 Mar, 2010 1 commit
  22. 04 Feb, 2010 3 commits
    • Nageswari Srinivasan's avatar
      davinci: add CDCE949 support on DM6467 EVM · 77a92c71
      Nageswari Srinivasan authored
      
      
      This patch adds the CDCE949 reference oscillator to
      the davinci clock list.
      
      On the DM6467T EVM, the CDCE949 is responsible for
      generating the pixel clock for display. On the DM6467
      EVM, this pixel clock was being obtained from an
      internal source. This is not possible on the DM6467T
      EVM because of the presence of a 33MHz oscillator.
      
      The TSIF module also requires the CDCE949 to generate
      the data clocks.
      
      The actual clock definitions will be added by patches
      adding support for DM6467T VPIF and TSIF. This patch
      mearly lays the foundation for that work.
      Signed-off-by: default avatarNageswari Srinivasan <nageswari@ti.com>
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      77a92c71
    • Sekhar Nori's avatar
      davinci: add support for DM6467T EVM · c1978e1d
      Sekhar Nori authored
      DM6467T (T for Turbo) is a newer and faster DM6467
      part from TI. The new part supports 1080p video and
      has the ARM running at 495MHz. More SoC information:
      
      http://focus.ti.com/docs/prod/folders/print/tms320dm6467t.html
      
      
      
      Spectrum Digital, Inc has a new EVM for this part.
      It is _mostly_ same as the older DM6467 EVM except
      for a 33MHz crystal input and THS8200 video encoder
      for 1080p support.
      
      The meat of this patch is dedicated to initializing
      the crystal frequency from EVM board file.
      
      Additional notes:
      I did consider some alternative ways to make the crystal
      input board specific including - (1) having board code
      initialize the crystal frequency using the first member
      of soc_info->cpu_clks array (2) introducing a new ref_clk_rate
      member in soc_info structure.
      
      But, the current way seems to be the simplest and least
      intruding considering that both the clock array and SoC
      info structure are actually private to the SoC file. Also
      the fact that davinci_common_init() initializes both the
      soc_info and clocks in one go.
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      c1978e1d
    • Sekhar Nori's avatar
      davinci: board-dm646x-evm.c: arrange related code together · b73b526e
      Sekhar Nori authored
      
      
      Currently all the #defines and static variables in the
      board-dm646x-evm.c file are located right at the start
      of the file because of which the related code is not
      together - making reading the code difficult.
      
      This patch moves around the code keeping related code
      together.
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      b73b526e
  23. 25 Nov, 2009 3 commits
  24. 16 Sep, 2009 1 commit
  25. 26 Aug, 2009 4 commits
  26. 25 Jul, 2009 1 commit
  27. 28 May, 2009 1 commit