1. 27 Oct, 2012 4 commits
  2. 26 Oct, 2012 2 commits
  3. 25 Oct, 2012 11 commits
  4. 24 Oct, 2012 10 commits
  5. 22 Oct, 2012 6 commits
    • Kevin Hilman's avatar
      ARM: OMAP3: Beagle: fix OPP customization and initcall ordering · 65bf7ca0
      Kevin Hilman authored
      After commit 24d7b40a (ARM: OMAP2+:
      PM: MPU DVFS: use generic CPU device for MPU-SS), OPPs are registered
      using an existing CPU device, not the omap_device for MPU-SS.
      
      First, fix the board file to use get_cpu_device() as required by the
      above commit, otherwise custom OPPs will be added to the wrong device.
      
      Second, the board files OPP init is called from the its init_machine
      method, and the generic CPU devices are not yet created when
      init_machine is run.  Therefore OPP initialization will fail.  To fix,
      use a device_initcall() for the board file's OPP customization, and
      make the device_initcall board-specific by using a machine_is check.
      Reported-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
      65bf7ca0
    • Tony Lindgren's avatar
      ARM: OMAP3: Fix 3430 legacy mux names for ssi1 signals. · 1d8643dd
      Tony Lindgren authored
      On n900 uart1 pins are not not used for uart, instead they are
      used to connect to a cell modem over ssi. Looks like we're
      currently missing these signal names for 3430 for some reason,
      and only have some of them listed for 3630. Obviously the signals
      are there for 3430 if n900 is using them and they are documented
      in some TRMs.
      
      Note that these will eventually be replaced by device tree
      based pinctrl-single.c driver. But for now these are needed
      to verify the SSI pins for devices like Nokia N900.
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      1d8643dd
    • Tony Lindgren's avatar
      ARM: OMAP2+: Fix location of select PINCTRL · 24942e8a
      Tony Lindgren authored
      Commit 8f31cefe (ARM: OMAP2+: select PINCTRL in Kconfig)
      added select PINCTRL, but accdentally added it to a wrong
      location.
      
      We want to select if for ARCH_OMAP2PLUS, not for
      ARCH_OMAP2PLUS_TYPICAL.
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      24942e8a
    • Peter Ujfalusi's avatar
      ARM/dts: omap3: Fix mcbsp2/3 hwmods to be able to probe the drivers for audio · eef6fcaa
      Peter Ujfalusi authored
      Fixes the following errors:
      [    2.318084] omap-mcbsp 49022000.mcbsp: invalid rx DMA channel
      [    2.324432] omap-mcbsp 49024000.mcbsp: invalid rx DMA channel
      
      Which is because we failed to link the sidetone hwmod for McBSP2/3. The
      missing sidetone hwmod link will prevent omap_device_alloc() to append the
      DMA resources since we - accidentally - end up having the same number of
      resources provided from DT (IO/IRQ) as we have in hwmod for the McBSP ports
      without the ST resources.
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Acked-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      eef6fcaa
    • Kevin Hilman's avatar
      ARM: OMAP2: UART: fix console UART mismatched runtime PM status · 44b1d42a
      Kevin Hilman authored
      The runtime PM framework assumes that the hardware state of devices
      when initialized is disabled.  For all omap_devices, we idle/disable
      device by default.  However, the console uart uses a "no idle" option
      during omap_device init in order to allow earlyprintk usage to work
      seamlessly during boot.
      
      Because the hardware is left partially enabled after init (whatever
      the bootloader settings were), the omap_device should later be fully
      initialized (including mux) and the runtime PM framework should be
      told that the device is active, and not disabled so that the hardware
      state is in sync with runtime PM state.
      
      To fix, after the device has been created/registered, call
      omap_device_enable() to finialize init and use pm_runtime_set_active()
      to tell the runtime PM core the device is enabled.
      
      Tested on 2420/n810, 3530/Overo, 3530/Beagle, 3730/OveroSTORM,
      3730/Beagle-xM, 4460/PandaES.
      Suggested-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Sourav Poddar <sourav.poddar@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
      44b1d42a
    • Paul Walmsley's avatar
      ARM: OMAP3: PM: apply part of the erratum i582 workaround · 856c3c5b
      Paul Walmsley authored
      On OMAP34xx/35xx, and OMAP36xx chips with ES < 1.2, if the PER
      powerdomain goes to OSWR or OFF while CORE stays at CSWR or ON, or if,
      upon chip wakeup from OSWR or OFF, the CORE powerdomain goes ON before
      PER, the UART3/4 FIFOs and McBSP2/3 SIDETONE memories will be
      unusable.  This is erratum i582 in the OMAP36xx Silicon Errata
      document.
      
      This patch implements one of several parts of the workaround: the
      addition of the wakeup dependency between the PER and WKUP
      clockdomains, such that PER will wake up at the same time CORE_L3
      does.
      
      This is not a complete workaround.  For it to be complete:
      
      1. the PER powerdomain's next power state must not be set to OSWR or
         OFF if the CORE powerdomain's next power state is set to CSWR or
         ON;
      
      2. the UART3/4 FIFO and McBSP2/3 SIDETONE loopback tests should be run
         if the LASTPOWERSTATEENTERED bits for PER and CORE indicate that
         PER went OFF while CORE stayed on.  If loopback tests fail, then
         those devices will be unusable until PER and CORE can undergo a
         transition from ON to OSWR/OFF and back ON.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
      856c3c5b
  6. 21 Oct, 2012 1 commit
  7. 20 Oct, 2012 6 commits