1. 12 3月, 2012 7 次提交
  2. 27 9月, 2011 9 次提交
  3. 16 9月, 2011 1 次提交
  4. 11 7月, 2011 1 次提交
    • P
      ASoC: omap: McBSP: fix build breakage on OMAP1 · 69d042d1
      Paul Walmsley 提交于
      After commits d1358657 ("OMAP: McBSP:
      implement functional clock switching via clock framework") and
      cf4c87ab ("OMAP: McBSP: implement
      McBSP CLKR and FSR signal muxing via mach-omap2/mcbsp.c"), any OMAP1
      board (such as the AMS Delta) that uses the ASoC McBSP driver will no
      longer build:
      
      sound/built-in.o: In function `omap_mcbsp_dai_set_dai_sysclk':
      last.c:(.text+0x24ff8): undefined reference to `omap2_mcbsp1_mux_clkr_src'
      last.c:(.text+0x2500c): undefined reference to `omap2_mcbsp1_mux_fsr_src'
      make: *** [vmlinux] Error 1
      
      Fix by defining three OMAP1-only dummy functions for
      omap2_mcbsp1_mux_clkr_src(), omap2_mcbsp1_mux_fsr_src(), and
      omap2_mcbsp_set_clks_src().
      
      Normally, code that is OMAP SoC-revision-specific like this should go
      under the arch/arm/*omap* directories, and get abstracted away from
      drivers via struct platform_data function pointers.  This doesn't work
      in this case since there doesn't appear to be any convenient way to access
      struct platform_data (or something like it) in the current design of
      the sound/soc/omap/omap-mcbsp.c driver.
      
      Reported by Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> and Tony Lindgren
      <tony@atomide.com>.  Janusz also posted a patch to fix this at:
      
         http://www.spinics.net/lists/linux-omap/msg39560.html
      
      (among other places), but the following approach seems less dependent
      on compiler behavior.
      
      This patch passes build tests for ams_delta_defconfig and omap2plus_defconfig,
      but since I don't have an AMS Delta here, I can't boot test it on that
      platform.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Jarkko Nikula <jhnikula@gmail.com>
      Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
      Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: Liam Girdwood <lrg@slimlogic.co.uk>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      69d042d1
  5. 08 7月, 2011 1 次提交
  6. 29 6月, 2011 2 次提交
  7. 31 3月, 2011 1 次提交
  8. 25 2月, 2011 5 次提交
  9. 22 12月, 2010 2 次提交
  10. 08 12月, 2010 2 次提交
  11. 09 10月, 2010 4 次提交
    • P
      OMAP: control: move plat-omap/control.h to mach-omap2/control.h · 4814ced5
      Paul Walmsley 提交于
      Only OMAP2+ platforms have the System Control Module (SCM) IP block.
      In the past, we've kept the SCM header file in plat-omap.  This has
      led to abuse - device drivers including it; includes being added that
      create implicit dependencies on OMAP2+ builds; etc.
      
      In response, move the SCM headers into mach-omap2/.
      
      As part of this, remove the direct SCM access from the OMAP UDC
      driver.  It was clearly broken.  The UDC code needs an indepth review for
      use on OMAP2+ chips.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Cory Maccarrone <darkstar6262@gmail.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      4814ced5
    • P
      OMAP: McBSP: implement functional clock switching via clock framework · d1358657
      Paul Walmsley 提交于
      Previously the OMAP McBSP ASoC driver implemented CLKS switching by
      using omap_ctrl_{read,write}l() directly.  This is against policy; the OMAP
      System Control Module functions are not intended to be exported to drivers.
      These symbols are no longer exported, so as a result, the OMAP McBSP ASoC
      driver does not build as a module.
      
      Resolve the CLKS clock changing portion of this problem by creating a
      clock parent changing function that lives in
      arch/arm/mach-omap2/mcbsp.c, and modify the ASoC driver to use it.
      Due to the unfortunate way that McBSP support is implemented in ASoC
      and the OMAP tree, this symbol must be exported for use by
      sound/soc/omap/omap-mcbsp.c.
      
      Going forward, the McBSP device driver should be moved from
      arch/arm/*omap* into drivers/ or sound/soc/* and the CPU DAI driver
      should be implemented as a platform_driver as many other ASoC CPU DAI
      drivers are.  These two steps should resolve many of the layering
      problems, which will rapidly reappear during a McBSP hwmod/PM runtime
      conversions.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Acked-by: NJarkko Nikula <jhnikula@gmail.com>
      Acked-by: NPeter Ujfalusi <peter.ujfalusi@nokia.com>
      Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      d1358657
    • P
      OMAP: McBSP: implement McBSP CLKR and FSR signal muxing via mach-omap2/mcbsp.c · cf4c87ab
      Paul Walmsley 提交于
      The OMAP ASoC McBSP code implemented CLKR and FSR signal muxing via
      direct System Control Module writes on OMAP2+.  This required the
      omap_ctrl_{read,write}l() functions to be exported, which is against
      policy: the only code that should call those functions directly is
      OMAP core code, not device drivers.  omap_ctrl_{read,write}*() are no
      longer exported, so the driver no longer builds as a module.
      
      Fix the pinmuxing part of the problem by removing calls to
      omap_ctrl_{read,write}l() from the OMAP ASoC McBSP code and
      implementing signal muxing functions in arch/arm/mach-omap2/mcbsp.c.
      Due to the unfortunate way that McBSP support is implemented in ASoC
      and the OMAP tree, these symbols must be exported for use by
      sound/soc/omap/omap-mcbsp.c.
      
      Going forward, the McBSP device driver should be moved from
      arch/arm/*omap* into drivers/ or sound/soc/*, and the CPU DAI driver
      should be implemented as a platform_driver as many other ASoC CPU DAI
      drivers are.  These two steps should resolve many of the layering
      problems, which will rapidly reappear during a McBSP hwmod/PM runtime
      conversion.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Acked-by: NJarkko Nikula <jhnikula@gmail.com>
      Acked-by: NPeter Ujfalusi <peter.ujfalusi@nokia.com>
      Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      cf4c87ab
    • M
      OMAP: plat-omap: Fix static function warnings · b0a330dc
      Manjunath Kondaiah G 提交于
      This patch fixes sparse warnings due non declarations of static functions.
      
      arch/arm/plat-omap/sram.c:130:13: warning: symbol 'omap_detect_sram' was not declared. Should it be static?
      arch/arm/plat-omap/sram.c:216:13: warning: symbol 'omap_map_sram' was not declared. Should it be static?
      arch/arm/plat-omap/sram.c:450:12: warning: symbol 'omap_sram_init' was not declared. Should it be static?
      arch/arm/plat-omap/sram.c:348:12: warning: symbol 'omap242x_sram_init' was not declared. Should it be static?
      arch/arm/plat-omap/sram.c:369:12: warning: symbol 'omap243x_sram_init' was not declared. Should it be static?
      arch/arm/plat-omap/sram.c:425:12: warning: symbol 'omap34xx_sram_init' was not declared. Should it be static?
      arch/arm/plat-omap/sram.c:441:12: warning: symbol 'omap44xx_sram_init' was not declared. Should it be static
      
      arch/arm/plat-omap/mcbsp.c:36:6: warning: symbol 'omap_mcbsp_write' was not declared. Should it be static?
      arch/arm/plat-omap/mcbsp.c:50:5: warning: symbol 'omap_mcbsp_read' was not declared. Should it be static?
      arch/arm/plat-omap/mcbsp.c:65:6: warning: symbol 'omap_mcbsp_st_write' was not declared. Should it be static?
      arch/arm/plat-omap/mcbsp.c:70:5: warning: symbol 'omap_mcbsp_st_read' was not declared. Should it be static?
      arch/arm/plat-omap/mcbsp.c:1648:15: warning: symbol 'omap_st_add' was not declared. Should it be static?
      
      arch/arm/plat-omap/fb.c:414:15: warning: symbol 'omapfb_reserve_sram' was not declared. Should it be static?
      arch/arm/plat-omap/cpu-omap.c:43:5: warning: symbol 'omap_verify_speed' was not declared. Should it be static?
      arch/arm/plat-omap/cpu-omap.c:61:14: warning: symbol 'omap_getspeed' was not declared. Should it be static?
      Signed-off-by: NManjunath Kondaiah G <manjugk@ti.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Nishanth Menon <nm@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      b0a330dc
  12. 28 9月, 2010 1 次提交
  13. 24 9月, 2010 1 次提交
  14. 03 6月, 2010 3 次提交