1. 22 Oct, 2010 2 commits
  2. 12 Oct, 2010 3 commits
  3. 11 Oct, 2010 4 commits
    • Peter Ujfalusi's avatar
      OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish · 0e4905c0
      Peter Ujfalusi authored
      Implement the suggested workaround for OMAP3 regarding to sDMA draining
      issue, when the channel is disabled on the fly.
      This errata affects the following configuration:
      sDMA transfer is source synchronized
      Buffering is enabled
      SmartStandby is selected.
      
      The issue can be easily reproduced by creating overrun situation while
      recording audio.
      Either introduce load to the CPU:
      nice -19 arecord -D hw:0 -M -B 10000 -F 5000 -f dat > /dev/null & \
      dd if=/dev/urandom of=/dev/null
      
      or suspending the arecord, and resuming it:
      arecord -D hw:0 -M -B 10000 -F 5000 -f dat > /dev/null
      CTRL+Z; fg; CTRL+Z; fg; ...
      
      In case of overrun audio stops DMA, and restarts it (without reseting
      the sDMA channel). When we hit this errata in stop case (sDMA drain did
      not complete), at the coming start the sDMA will not going to be
      operational (it is still draining).
      This leads to DMA stall condition.
      On OMAP3 we can recover with sDMA channel reset, it has been observed
      that by introducing unrelated sDMA activity might also help (reading
      from MMC for example).
      
      The same errata exists for OMAP2, where the suggestion is to disable the
      buffering to avoid this type of error.
      On OMAP3 the suggestion is to set sDMA to NoStandby before disabling
      the channel, and wait for the drain to finish, than configure sDMA to
      SmartStandby again.
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@nokia.com>
      Acked-by: default avatarJarkko Nikula <jhnikula@gmail.com>
      Acked-by : Santosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by : Manjunath Kondaiah G <manjugk@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      0e4905c0
    • Jarkko Nikula's avatar
      omap: dma: Fix buffering disable bit setting for omap24xx · 3e57f162
      Jarkko Nikula authored
      An errata workaround for omap24xx is not setting the buffering disable bit
      25 what is the purpose but channel enable bit 7 instead.
      
      Background for this fix is the DMA stalling issue with ASoC omap-mcbsp
      driver. Peter Ujfalusi <peter.ujfalusi@nokia.com> has found an issue in
      recording that the DMA stall could happen if there were a buffer overrun
      detected by ALSA and the DMA was stopped and restarted due that. This
      problem is known to occur on both OMAP2420 and OMAP3. It can recover on
      OMAP3 after dma free, dma request and reconfiguration cycle. However, on
      OMAP2420 it seems that only way to recover is a reset.
      
      Problem was not visible before the commit c12abc01. That commit changed that
      the McBSP transmitter/receiver is released from reset only when needed. That
      is, only enabled McBSP transmitter without transmission was able to prevent
      this DMA stall problem in receiving side and underlying problem did not show
      up until now. McBSP transmitter itself seems to no be reason since DMA
      stall does not recover by enabling the transmission after stall.
      
      Debugging showed that there were a DMA write active during DMA stop time and
      it never completed even when restarting the DMA. Experimenting showed that
      the DMA buffering disable bit could be used to avoid stalling when using
      source synchronized transfers. However that could have performance hit and
      OMAP3 TRM states that buffering disable is not allowed for destination
      synchronized transfers so subsequent patch will implement a method to
      complete DMA writes when stopping.
      
      This patch is based on assumtion that complete lock-up on OMAP2420 is
      different but related problem. I don't have access to OMAP2420 errata but
      I believe this old workaround here is put for a reason but unfortunately
      a wrong bit was typed and problem showed up only now.
      Signed-off-by: default avatarJarkko Nikula <jhnikula@gmail.com>
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@nokia.com>
      Acked-by: default avatarManjunath Kondaiah G <manjugk@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      3e57f162
    • Santosh Shilimkar's avatar
      omap: serial: Fix the boot-up crash/reboot without CONFIG_PM · a1b04cc1
      Santosh Shilimkar authored
      The omap2plus_defconfig doesn't boot up when built with CONFIG_PM
      disabled on the latest linux-omap master. Below are the observations
      1. OMAP3 reboots in the middle of boot
      --------------------------------------------------
      [    0.000000] Calibrating delay loop... 494.72 BogoMIPS (lpj=1933312)
      [    0.000000] pid_max: default: 32768 minimum: 301
      [    0.000000] Security Framework initialized
      [    0.000000] Mount-cache hash table entries: 512
      [    0.000000] CPU: Testing write buffer coherency: ok
      [    0.000000] Brought up 1 CPUs
      [    0.000000] SMP: Total of 1 processors activated (494.72 BogoMIPS).
      [    0.000000] regulator: core version 0.5
      [    0.000000] NET: Registered protocol family 16
      
      U-Boot 1.1.4 (Feb 11 2009 - 16:10:23)
      
      OMAP3430-GP rev 2, CPU-OPP2 L3-165MHz
      TI 3430SDP 1.0 Version + mDDR (Boot NOR)
      DRAM:  128 MB
      Flash: 128 MB
      NAND:128 MiB
      --------------------------------------------------
      
      2. OMAP4 does a kernel PANIC
      -------------------------------------
      [    0.000000] Calibrating delay loop... 1195.29 BogoMIPS (lpj=4669440)
      [    0.000000] pid_max: default: 32768 minimum: 301
      [    0.000000] Security Framework initialized
      [    0.000000] Mount-cache hash table entries: 512
      [    0.000000] CPU: Testing write buffer coherency: ok
      [    0.000000] L310 cache controller enabled
      [    0.000000] l2x0: 16 ways, CACHE_ID 0x410000c2, AUX_CTRL 0x0e050000
      [    0.000000] CPU1: Booted secondary processor
      [    0.000000] Brought up 2 CPUs
      [    0.000000] SMP: Total of 2 processors activated (2395.78 BogoMIPS).
      [    0.000000] regulator: core version 0.5
      [    0.000000] NET: Registered protocol family 16
      [    0.000000] mux: Could not set signal i2c2_scl.i2c2_scl
      [    0.000000] mux: Could not set signal i2c2_sda.i2c2_sda
      [    0.000000] mux: Could not set signal i2c3_scl.i2c3_scl
      [    0.000000] mux: Could not set signal i2c3_sda.i2c3_sda
      [    0.000000] mux: Could not set signal i2c4_scl.i2c4_scl
      [    0.000000] mux: Could not set signal i2c4_sda.i2c4_sda
      -------------------------------------
      
      This is happening because 'omap_serial_init()' is hanging in the boot.
      On OMAP3 the watchdog is generating reboot because devices_init doesn't
      happens where as on OMAP4 it just hangs without reboot.
      The uart clock is not getting enabled after omap_device_idle as part
      of omap_serial_init.
      The omap_device_idle(will disable the clock) then omap_uart_block_sleep()
      should enable clock back disabled during the boot up phase.
      But omap_uart_block_sleep() stuffed version is binded only under
      CONFIG_PM and other version is just empty. Hence it is not enabling
      clock back as expected
      
      This patch adds uart clock enable code to omap_uart_block_sleep() function
      built with CONFIG_PM disabled.
      Thanks to Charulatha and Govindraj for their help on this debug.
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: default avatarCharulatha V <charu@ti.com>
      Signed-off-by: default avatarGovindraj.R <govindraj.raja@ti.com>
      Acked-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      a1b04cc1
    • Kevin Hilman's avatar
      OMAP3: PM: fix scratchpad memory accesses for off-mode · de658158
      Kevin Hilman authored
      Commit 914bab936fe0388a529079679e2f137aa4ff548d (OMAP: mach-omap2: Fix
      incorrect assignment warnings) changed a pointer from 'u32 *' to
      'void *' without also fixing up the pointer arithmetic.
      
      Fix the scratchpad offsets so they are byte offsets instead of
      word offsets and thus work correctly with a void pointer base.
      
      Special thanks to Jean Pihet for taking the time track down this
      problem and propose an initial solution.
      
      Tested with off-idle and off-suspend on 36xx/Zoom3 and 34xx/omap3evm.
      
      Cc: Manjunath Kondaiah G <manjugk@ti.com>
      Reported-by: default avatarJean Pihet <jean.pihet@newoldbits.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: default avatarJean Pihet <jean.pihet@newoldbits.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      de658158
  4. 08 Oct, 2010 31 commits