1. 16 9月, 2009 1 次提交
  2. 04 9月, 2009 5 次提交
    • P
      OMAP2/3/4 core: create omap_device layer · b04b65ab
      Paul Walmsley 提交于
      The omap_device code provides a mapping of omap_hwmod structures into
      the platform_device system, and includes some details on external
      (board-level) integration.  This allows drivers to enable, idle, and
      shutdown on-chip device resources, including clocks, regulators, etc.
      The resources enabled and idled are dependent on the device's maximum
      wakeup latency constraint (if present).
      
      At the moment, omap_device functions are intended to be called from
      platform_data function pointers.  Ideally in the future these
      functions will be called from either subarchitecture-specific
      platform_data activate, deactivate functions, or via an custom
      bus/device type for OMAP.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Vikram Pandita <vikram.pandita@ti.com>
      Cc: Sakari Poussa <sakari.poussa@nokia.com>
      Cc: Anand Sawant <sawant@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Eric Thomas <ethomas@ti.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      b04b65ab
    • P
      OMAP2/3/4: create omap_hwmod layer · 63c85238
      Paul Walmsley 提交于
      OMAP SoCs can be considered a collection of hardware IP blocks
      connected by various interconnects.  The bus topology and device
      integration data is somewhat more complex than platform_device can
      encode.  This patch creates code and structures to manage information
      about OMAP on-chip devices ("hardware modules") and their integration
      to the rest of the chip.  Hardware module data is intended to be
      generated dynamically from the TI hardware database for the OMAP4
      chips and beyond, easing Linux support for new chip variants.
      
      This code currently:
      
      - resets and configures all hardware modules upon startup, reducing bootloader
        dependencies;
      
      - provides hooks for Linux driver model code to enable, idle, and shutdown
        hardware modules (forthcoming patch);
      
      - waits for hardware modules to leave idle once their clocks
        are enabled and OCP_SYSCONFIG bits are set appropriately.
      
      - provides a means to pass arbitrary IP block configuration data (e.g.,
        FIFO size) to the device driver (via the dev_attr void pointer)
      
      In the future this code is intended to:
      
      - estimate interconnect bandwidth and latency characteristics to
        ensure constraints are satisfied during DVFS
      
      - provide *GRPSEL bit data to the powerdomain code
      
      - handle pin/ball muxing for devices
      
      - generate IO mapping information dynamically
      
      - supply device firewall configuration data
      
      - provide hardware module data to other on-chip coprocessor software
      
      - allow the removal of the "disable unused clocks" code in the OMAP2/3
        clock code
      
      This patch represents a collaborative effort involving many people from TI,
      Nokia, and the Linux-OMAP community.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Vikram Pandita <vikram.pandita@ti.com>
      Cc: Sakari Poussa <sakari.poussa@nokia.com>
      Cc: Anand Sawant <sawant@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Eric Thomas <ethomas@ti.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      63c85238
    • P
      OMAP2/3 board-*.c files: read bootloader configuration earlier · b3c6df3a
      Paul Walmsley 提交于
      Most board-*.c files read configuration data from the bootloader in
      their .init_machine() function.  This needs to happen earlier, at some
      point before omap2_init_common_hw() is called.  This is because a
      future patch will use the bootloader serial console port information
      to enable the UART clocks earlier, immediately after omap2_clk_init().
      This is in turn necessary since otherwise clock tree usecounts on
      clocks like dpll4_m2x2_ck will be bogus, which can cause the
      currently-active console UART clock to be disabled during boot.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b3c6df3a
    • P
      OMAP2/3 PM: create the OMAP PM interface and add a default OMAP PM no-op layer · c0407a96
      Paul Walmsley 提交于
      The interface provides device drivers, CPUFreq, and DSPBridge with a
      means of controlling OMAP power management parameters that are not yet
      supported by the Linux PM PMQoS interface.  Copious documentation is
      in the patch in Documentation/arm/OMAP/omap_pm and the interface
      header file, arch/arm/plat-omap/include/mach/omap-pm.h.
      
      Thanks to Rajendra Nayak <rnayak@ti.com> for adding CORE (VDD2) OPP
      support and moving the OPP table initialization earlier in the event
      that the clock code needs them.  Thanks to Tero Kristo
      <tero.kristo@nokia.com> for fixing the parameter check in
      omap_pm_set_min_bus_tput().  Jouni signed off on Tero's patch.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NTero Kristo <tero.kristo@nokia.com>
      Signed-off-by: NJouni Högander <jouni.hogander@nokia.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Igor Stoppa <igor.stoppa@nokia.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      Cc: Anand Sawant <sawant@ti.com>
      Cc: Sakari Poussa <sakari.poussa@nokia.com>
      Cc: Veeramanikandan Raju <veera@ti.com>
      Cc: Karthik Dasu <karthik-dp@ti.com>
      c0407a96
    • T
      OMAP: SDRC: Add several new register definitions · 6dda2d4b
      Tero Kristo 提交于
      Add missing SDRC register offset macros.
      Signed-off-by: NTero Kristo <tero.kristo@nokia.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      [paul@pwsan.com: added commit message]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      6dda2d4b
  3. 03 9月, 2009 4 次提交
  4. 29 8月, 2009 7 次提交
  5. 25 8月, 2009 1 次提交
  6. 21 8月, 2009 8 次提交
  7. 10 8月, 2009 1 次提交
  8. 07 8月, 2009 1 次提交
    • J
      ARM: OMAP: McBSP: Fix ASoC on OMAP1510 by fixing API of omap_mcbsp_start/stop · c12abc01
      Jarkko Nikula 提交于
      Simultaneous audio playback and capture on OMAP1510 can cause that second
      stream is stalled if there is enough delay between startup of the audio
      streams.
      
      Current implementation of the omap_mcbsp_start is starting both transmitter
      and receiver at the same time and it is called only for firstly started
      audio stream from the OMAP McBSP based ASoC DAI driver.
      
      Since DMA request lines on OMAP1510 are edge sensitive, the DMA request is
      missed if there is no DMA transfer set up at that time when the first word
      after McBSP startup is transmitted. The problem hasn't noted before since
      later OMAPs are using level sensitive DMA request lines.
      
      Fix the problem by changing API of omap_mcbsp_start and omap_mcbsp_stop by
      allowing to start and stop individually McBSP transmitter and receiver
      logics. Then call those functions individually for both audio playback
      and capture streams. This ensures that DMA transfer is setup before
      transmitter or receiver is started.
      
      Thanks to Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> for detailed problem
      analysis and Peter Ujfalusi <peter.ujfalusi@nokia.com> for info about DMA
      request line behavior differences between the OMAP generations.
      Reported-and-tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
      Signed-off-by: NJarkko Nikula <jhnikula@gmail.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NPeter Ujfalusi <peter.ujfalusi@nokia.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      c12abc01
  9. 06 8月, 2009 1 次提交
    • T
      OMAP3: Fixed crash bug with serial + suspend · 2466211e
      Tero Kristo 提交于
      It was possible for an unhandled interrupt to occur if there was incoming
      serial traffic during wakeup from suspend. This was caused by the code
      in arch-arm/mach-omap2/serial.c keeping interrupt enabled all the time,
      but not acking its interrupts. Applies on top of PM branch.
      
      Use the PM begin/end hooks to ensure that the "serial idle" interrupts
      are disabled during the suspend path.  Also, since begin/end hooks are
      now used, use the suspend_state that is passed in the begin hook instead
      of the enter hook as per the platform_suspend_ops docs.
      Signed-off-by: NTero Kristo <tero.kristo@nokia.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      2466211e
  10. 28 7月, 2009 1 次提交
  11. 25 7月, 2009 3 次提交
    • P
      OMAP2/3 clock: split, rename omap2_wait_clock_ready() · 72350b29
      Paul Walmsley 提交于
      Some OMAP2/3 hardware modules have CM_IDLEST attributes that are not
      handled by the current omap2_wait_clock_ready() code.  In preparation
      for patches that fix the unusual devices, rename the function
      omap2_wait_clock_ready() to omap2_wait_module_ready() and split it
      into three parts:
      
      1. A clkops-specific companion clock return function (by default,
         omap2_clk_dflt_find_companion())
      
      2. A clkops-specific CM_IDLEST register address and bit shift return
         function (by default, omap2_clk_dflt_find_idlest())
      
      3. Code to wait for the CM to indicate that the module is ready
         (omap2_cm_wait_idlest())
      
      Clocks can now specify their own custom find_companion() and find_idlest()
      functions; used in subsequent patches.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      72350b29
    • J
      OMAP3: Setup MUX settings for SDRC CKE signals · 9fb97412
      Jean Pihet 提交于
      This patches ensures the MUX settings are correct for the SDRC
      CKE signals to SDRAM. This allows the self-refresh to work when
      2 chip-selects are in use.
      
      A warning is thrown away in case the initial muxing is incorrect,
      in order to track faulty or old-dated bootloaders.
      Note: The CONFIG_OMAP_MUX and CONFIG_OMAP_MUX_WARNINGS options
      must be enabled for the mux code to have effect.
      Signed-off-by: NJean Pihet <jpihet@mvista.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      9fb97412
    • J
      OMAP3 SDRC: add support for 2 SDRAM chip selects · 58cda884
      Jean Pihet 提交于
      Some OMAP3 boards (Beagle Cx, Overo, RX51, Pandora) have 2
      SDRAM parts connected to the SDRC.
      
      This patch adds the following:
      - add a new argument of type omap_sdrc_params struct*
      to omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params
      - adapted the OMAP boards files to the new prototype of
      omap2_init_common_hw
      - add the SDRC 2nd CS registers offsets defines
      - adapt the sram sleep code to configure the SDRC for the 2nd CS
      
      Note: If the 2nd param to omap2_init_common_hw is NULL, then the
      parameters are not programmed into the SDRC CS1 registers
      
      Tested on 3430 SDP and Beagleboard rev C2 and B5, with
      suspend/resume and frequency changes (cpufreq).
      Signed-off-by: NJean Pihet <jpihet@mvista.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      58cda884
  12. 24 7月, 2009 1 次提交
  13. 23 6月, 2009 3 次提交
  14. 20 6月, 2009 3 次提交