1. 22 8月, 2011 1 次提交
  2. 19 7月, 2011 1 次提交
  3. 06 7月, 2011 1 次提交
  4. 20 10月, 2010 1 次提交
    • N
      arm: remove machine_desc.io_pg_offst and .phys_io · 6451d778
      Nicolas Pitre 提交于
      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: NNicolas Pitre <nicolas.pitre@linaro.org>
      Acked-by: Eric Miao <eric.miao at canonical.com>
      6451d778
  5. 24 9月, 2010 2 次提交
  6. 06 8月, 2010 1 次提交
  7. 20 7月, 2010 1 次提交
    • S
      ASoC: davinci: let platform data define edma queue numbers · 48519f0a
      Sekhar Nori 提交于
      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: NSekhar Nori <nsekhar@ti.com>
      Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      48519f0a
  8. 14 5月, 2010 1 次提交
    • C
      Davinci: aintc/cpintc - use ioremap() · bd808947
      Cyril Chemparathy 提交于
      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: NCyril Chemparathy <cyril@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      bd808947
  9. 07 5月, 2010 2 次提交
  10. 02 3月, 2010 1 次提交
  11. 05 2月, 2010 3 次提交
    • N
      davinci: add CDCE949 support on DM6467 EVM · 77a92c71
      Nageswari Srinivasan 提交于
      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: NNageswari Srinivasan <nageswari@ti.com>
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      77a92c71
    • S
      davinci: add support for DM6467T EVM · c1978e1d
      Sekhar Nori 提交于
      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: NSekhar Nori <nsekhar@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      c1978e1d
    • S
      davinci: board-dm646x-evm.c: arrange related code together · b73b526e
      Sekhar Nori 提交于
      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: NSekhar Nori <nsekhar@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      b73b526e
  12. 26 11月, 2009 3 次提交
  13. 17 9月, 2009 1 次提交
  14. 26 8月, 2009 4 次提交
  15. 26 7月, 2009 1 次提交
  16. 29 5月, 2009 3 次提交
  17. 26 5月, 2009 3 次提交
    • M
      davinci: Encapsulate SoC-specific data in a structure · 79c3c0b7
      Mark A. Greer 提交于
      Create a structure to encapsulate SoC-specific information.
      This will assist in generalizing code so it can be used by
      different SoCs that have similar hardware but with minor
      differences such as having a different base address.
      
      The idea is that the code for each SoC fills out a structure
      with the correct information.  The board-specific code then
      calls the SoC init routine which in turn will call a common
      init routine that makes a copy of the structure, maps in I/O
      regions, etc.
      
      After initialization, code can get a pointer to the structure
      by calling davinci_get_soc_info().  Eventually, the common
      init routine will make a copy of all of the data pointed to
      by the structure so the original data can be made __init_data.
      That way the data for SoC's that aren't being used won't consume
      memory for the entire life of the kernel.
      
      The structure will be extended in subsequent patches but
      initially, it holds the map_desc structure for any I/O
      regions the SoC/board wants statically mapped.
      Signed-off-by: NMark A. Greer <mgreer@mvista.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      79c3c0b7
    • K
      davinci: EMAC platform support · ac7b75b5
      Kevin Hilman 提交于
      Add SoC and platform-specific data and init for DaVinci EMAC network
      driver.
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      ac7b75b5
    • K
      davinci: DM646x: add base SoC and board support · e38d92fd
      Kevin Hilman 提交于
      Add support for DM646x SoC (a.k.a DaVinci HD) and its Evalution
      Module (EVM.)
      
      Original support done by Sudhakar Rajashekhara.
      Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      e38d92fd