Skip to content
  1. Dec 10, 2010
  2. Dec 01, 2010
    • Hema Kalliguddi's avatar
      usb: musb: add names for IRQs in structure resource · fcf173e4
      Hema Kalliguddi authored
      
      
      Soon resource data will get automatically
      populated from a set of autogenerated data
      from TI's hardware database for the OMAP
      platform.
      
      Such database, might not have resources at
      the expected order by the current drivers.
      
      While we could hack in some exceptions to
      that tool to generate resources in a specific
      order, it seems less fragile to use the
      resource name instead. That way, no matter
      what order the resources are generated, the
      driver still work.
      
      Modified the OMAP, Blackfin and Davinci
      architecture files to add the name of the IRQs
      in the resource structures and musb driver to
      use the platform_get_irq_byname() api to get
      the device and dma irq numbers instead of using
      the index.
      
      Cc: Tony Lindgren <tony@atomide.com>
      Acked-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Acked-by: default avatarMike Frysinger <vapier@gentoo.org>
      Signed-off-by: default avatarHema HK <hemahk@ti.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      fcf173e4
  3. Nov 30, 2010
  4. Oct 28, 2010
  5. Oct 26, 2010
  6. Oct 22, 2010
  7. Oct 20, 2010
  8. Oct 11, 2010
    • 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
  9. Oct 08, 2010
Loading