1. 25 2月, 2012 2 次提交
    • M
      ARM: davinci: streamline sysmod access · 5cfb19ac
      Manjunath Hadli 提交于
      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: NManjunath Hadli <manjunath.hadli@ti.com>
      Acked-by: NArnd 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: NSekhar Nori <nsekhar@ti.com>
      5cfb19ac
    • M
      ARM: davinci: create new common platform header for davinci · 39c6d2d1
      Manjunath Hadli 提交于
      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: NManjunath 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: NSekhar Nori <nsekhar@ti.com>
      39c6d2d1
  2. 05 1月, 2012 1 次提交
  3. 17 9月, 2011 1 次提交
    • I
      ARM: davinci: Explicitly set channel controllers' default queues · f23fe857
      Ido Yariv 提交于
      Davinci platforms may define a default queue for each channel
      controller. If one is not defined, the default queue is set to EVENTQ_1.
      However, there's no way to distinguish between an unset default queue to
      one that is set to EVENTQ_0, as EVENTQ_0 = 0.
      
      Explicitly specify the default queue for all channel controllers on all
      Davinci platforms to EVENTQ_1, and don't overwrite it in the EDMA probe
      function.
      
      One exception is the DA850 board, for which EVENTQ_1 is not a valid
      option for its second channel controller. Use EVENTQ_0 instead for that
      channel controller.
      Signed-off-by: NIdo Yariv <ido@wizery.com>
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      f23fe857
  4. 22 8月, 2011 1 次提交
  5. 27 4月, 2011 1 次提交
  6. 31 3月, 2011 1 次提交
  7. 01 3月, 2011 1 次提交
  8. 18 11月, 2010 6 次提交
    • B
      spi: davinci: remove non-useful "clk_internal" platform data · 3409e408
      Brian Niebuhr 提交于
      The "clk_internal" platform data member which contols the
      CLKMOD bit in Global Control Register 1 is not useful
      since CLKMOD needs be set to 1 *always* to ensure master
      mode operation.
      
      Remove this platform data.
      Signed-off-by: NBrian Niebuhr <bniebuhr@efjohnson.com>
      Tested-By: NMichael Williamson <michael.williamson@criticallink.com>
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      3409e408
    • B
      spi: davinci: always start transmit DMA · c29e3c60
      Brian Niebuhr 提交于
      Due to the full duplex nature of the SPI bus, the SPI master
      on DaVinci needs transmit to be active even if the tranfer is
      only meant to collect receive data.
      
      The current code achieves this by using a temporary zeroed buffer
      to provide DMA data in case the transfer does not have a transmit
      buffer provided.
      
      However, the transmit DMA is started only if transmit buffer is
      provided rendering the temporary buffer unused. Instead the code
      relies on a write to SPIDAT1 register to trigger transmit operation.
      This however only sends two bytes of data.
      
      Fix this by starting transmit DMA always.
      
      This changes exposes a bug on DM355 where the CSHOLD bit in
      SPIDAT1 needs to be written to in between transfers. Handle
      that by introducing a "cshold_bug" platform data which is
      set to true for DM355.
      Signed-off-by: NBrian Niebuhr <bniebuhr@efjohnson.com>
      Tested-By: NMichael Williamson <michael.williamson@criticallink.com>
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      c29e3c60
    • B
      spi: davinci: remove non-useful interrupt mode support · cf90fe73
      Brian Niebuhr 提交于
      The interrupt mode support as it stands is another version
      of poll mode. Even when interrupt mode is selected, the code
      tight loops on interrupt status register, rendering it totally
      useless. A completion variable is initialized, but never used.
      
      Remove this fake interrupt mode since users can anyway use
      poll mode with no functional difference. A usefully implemented
      interrupt mode support can be added later.
      Signed-off-by: NBrian Niebuhr <bniebuhr@efjohnson.com>
      Tested-By: NMichael Williamson <michael.williamson@criticallink.com>
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      cf90fe73
    • B
      spi: davinci: make chip-slect specific parameters really chip-select specific · 53a31b07
      Brian Niebuhr 提交于
      Some chip-select specific paramterers like wdelay, parity, usage of
      chip-select timers (and the actual timer values) are included in
      platform data forcing the same behaviour across all chip-selects.
      
      Create a new davinci_spi_config data structure which can be passed
      along using controller_data member of spi_device data structure
      on a per-device basis.
      Signed-off-by: NBrian Niebuhr <bniebuhr@efjohnson.com>
      Tested-By: NMichael Williamson <michael.williamson@criticallink.com>
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      53a31b07
    • B
      spi: davinci: enable both activation and deactivation of chip-selects · 7978b8c3
      Brian Niebuhr 提交于
      Let davinci_spi_chipselect() perform both activation and
      deactivation of chip selects. This lets spi_bitbang fully
      control chip select activation, as intended by the SPI API.
      
      With this change, the chip select activation code need not
      be duplicated in davinci_spi_bufs_{pio|dma}().
      
      Also, keeping chip select active control is removed as a
      platform data and simply controlled using information from
      spi_bitbang on whether chip slect should be activated or
      de-activated.
      Signed-off-by: NBrian Niebuhr <bniebuhr@efjohnson.com>
      Tested-By: NMichael Williamson <michael.williamson@criticallink.com>
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      7978b8c3
    • C
      ASoC: davinci: fixes for multi-component · bedad0ca
      Chris Paulson-Ellis 提交于
      Multi-component commit f0fba2ad broke a few things which this patch should
      fix. Tested on the DM355 EVM. I've been as careful as I can, but it would be
      good if those with access to other Davinci boards could test.
      
      --
      
      The multi-component commit put the initialisation of
      snd_soc_dai.[capture|playback]_dma_data into snd_soc_dai_ops.hw_params of the
      McBSP, McASP & VCIF drivers (davinci-i2s.c, davinci-mcasp.c & davinci-vcif.c).
      The initialisation had to be moved from the probe function in these drivers
      because davinci_*_dai changed from snd_soc_dai to snd_soc_dai_driver.
      
      Unfortunately, the DMA params pointer is needed by davinci_pcm_open (in
      davinci-pcm.c) before hw_params is called. I have moved the initialisation to
      a new snd_soc_dai_ops.startup function in each of these drivers. This fix
      indicates that all platforms that use davinci-pcm must have been broken and
      need to test with this fix.
      
      --
      
      The multi-component commit also changed the McBSP driver name from
      "davinci-asp" to "davinci-i2s" in davinci-i2s.c without updating the board
      level references to the driver name. This change is understandable, as there
      is a similarly named "davinci-mcasp" driver in davinci-mcasp.c.
      
      There is probably no 'correct' name for this driver. The DM6446 datasheet
      calls it the "ASP" and describes it as a "specialised McBSP". The DM355
      datasheet calls it the "ASP" and describes it as a "specialised ASP". The
      DM365 datasheet calls it the "McBSP". Rather than fix this problem by
      reverting to "davinci-asp", I've elected to avoid future confusion with the
      "davinci-mcasp" driver by changing it to "davinci-mcbsp", which is also
      consistent with the names of the functions in the driver. There are other
      fixes required, so it was never going to be as simple as a revert anyway.
      
      --
      
      The DM365 only has one McBSP port (of the McBSP platforms, only the DM355 has
      2 ports), so I've changed the the id of the platform_device from 0 to -1.
      
      --
      
      In davinci-evm.c, the DM6446 EVM can no longer share a snd_soc_dai_link
      structure with the DM355 EVM as they use different cpu DAI names (the DM355
      has 2 ports and the EVM uses the second port, but the DM6446 only has 1 port).
      This also means that the 2 boards need different snd_soc_card structures.
      
      --
      
      The codec_name entries in davinci-evm.c didn't match the i2c ids in the board
      files. I have only checked and fixed the details of the names used for the
      McBSP based platforms. Someone with a McASP based platform (eg DA8xx) should
      check the others.
      Signed-off-by: NChris Paulson-Ellis <chris@edesix.com>
      Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      bedad0ca
  9. 25 9月, 2010 1 次提交
  10. 06 8月, 2010 1 次提交
  11. 14 5月, 2010 5 次提交
  12. 07 5月, 2010 4 次提交
  13. 02 3月, 2010 1 次提交
  14. 27 2月, 2010 1 次提交
  15. 05 2月, 2010 2 次提交
  16. 26 11月, 2009 1 次提交
  17. 17 9月, 2009 1 次提交
  18. 26 8月, 2009 5 次提交
  19. 29 5月, 2009 4 次提交