1. 30 11月, 2010 1 次提交
  2. 29 11月, 2010 7 次提交
  3. 25 11月, 2010 4 次提交
  4. 24 11月, 2010 12 次提交
  5. 22 11月, 2010 5 次提交
  6. 21 11月, 2010 1 次提交
  7. 19 11月, 2010 2 次提交
  8. 18 11月, 2010 4 次提交
    • P
      ARM: mach-shmobile: Add ag5evm defconfig. · 89ba4d12
      Paul Mundt 提交于
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      89ba4d12
    • P
      ARM: mach-shmobile: Split out entry-macros in to GIC and INTC variants. · 45bbaae0
      Paul Mundt 提交于
      Presently the entry macros are all globbed together, this simply splits
      them out in to their insular variants. Future work such as the GIC
      generalization will replace some of these and tidy the abstraction up
      further.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      45bbaae0
    • M
      ARM: mach-shmobile: Initial AG5 and AG5EVM support · 6d9598e2
      Magnus Damm 提交于
      This patch adds initial support for Renesas SH-Mobile AG5.
      
      At this point the AG5 CPU support is limited to the ARM
      core, SCIF serial and a CMT timer together with L2 cache
      and the GIC. The AG5EVM board also supports Ethernet.
      
      Future patches will add support for GPIO, INTCS, CPGA
      and platform data / driver updates for devices such as
      IIC, LCDC, FSI, KEYSC, CEU and SDHI among others.
      
      The code in entry-macro.S will be cleaned up when the
      ARM IRQ demux code improvements have been merged.
      
      Depends on the AG5EVM mach-type recently registered but
      not yet present in arch/arm/tools/mach-types.
      
      As the AG5EVM board comes with 512MiB memory it is
      recommended to turn on HIGHMEM.
      
      Many thanks to Yoshii-san for initial bring up.
      Signed-off-by: NMagnus Damm <damm@opensource.se>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      6d9598e2
    • 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. 16 11月, 2010 1 次提交
    • P
      ARM: mach-shmobile: Tidy up the Kconfig bits. · 6d72ad35
      Paul Mundt 提交于
      Presently each one of the CPUs manually selects the same feature set, and
      there's a reasonable expectation that none of these will change for
      future CPUs in the SH-Mobile / R-Mobile family, so we move those over to
      the top-level ARCH_SHMOBILE.
      
      While we're at it, all of the CPUs support optional GPIOs via the PFC,
      do not have I/O ports, and expect sparse IRQ, so we bring the
      configuration in line across the board.
      
      This more or less brings the ARM-based parts in sync with their SH
      counterparts.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      6d72ad35
  10. 15 11月, 2010 3 次提交