1. 08 12月, 2010 1 次提交
  2. 01 12月, 2010 7 次提交
  3. 25 11月, 2010 3 次提交
    • A
      arm: omap2: timer-gp: delete unused variable · 2862945b
      Aaro Koskinen 提交于
      Delete a redundant local variable.
      Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      2862945b
    • P
      OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled · 0d8e2d0d
      Paul Walmsley 提交于
      The console semaphore must be held while the OMAP UART devices are
      disabled, lest a console write cause an ARM abort (and a kernel crash)
      when the underlying console device is inaccessible.  These crashes
      only occur when the console is on one of the OMAP internal serial
      ports.
      
      While this problem has been latent in the PM idle loop for some time,
      the crash was not triggerable with an unmodified kernel until commit
      6f251e9d ("OMAP: UART: omap_device
      conversions, remove implicit 8520 assumptions").  After this patch, a
      console write often occurs after the console UART has been disabled in
      the idle loop, crashing the system.  Several users have encountered
      this bug:
      
          http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38396.html
      
          http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36602.html
      
      The same commit also introduced new code that disabled the UARTs
      during init, in omap_serial_init_port().  The kernel will also crash
      in this code when earlyconsole and extra debugging is enabled:
      
          http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36411.html
      
      The minimal fix for the -rc series is to hold the console semaphore
      while the OMAP UARTs are disabled.  This is a somewhat overbroad fix,
      since the console may not be located on an OMAP UART, as is the case
      with the GPMC UART on Zoom3.  While it is technically possible to
      determine which devices the console or earlyconsole is actually
      running on, it is not a trivial problem to solve, and the code to do
      so is not really appropriate for the -rc series.
      
      The right long-term fix is to ensure that no code outside of the OMAP
      serial driver can disable an OMAP UART.  As I understand it, code to
      implement this is under development by TI.
      
      This patch is a collaboration between Paul Walmsley <paul@pwsan.com>
      and Tony Lindgren <tony@atomide.com>.  Thanks to Ming Lei
      <tom.leiming@gmail.com> and Pramod <pramod.gurav@ti.com> for their
      feedback on earlier versions of this patch.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
      Cc: Ming Lei <tom.leiming@gmail.com>
      Cc: Pramod <pramod.gurav@ti.com>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Jean Pihet <jean.pihet@newoldbits.com>
      Cc: Govindraj.R <govindraj.raja@ti.com>
      0d8e2d0d
    • K
      OMAP: UART: don't resume UARTs that are not enabled. · f910043c
      Kevin Hilman 提交于
      Add additional check to omap_uart_resume_idle() so that only
      enabled (specifically, idle-enabled) UARTs are allowed to resume.
      This matches the existing check in prepare idle.
      
      Without this patch, the system will hang if a board is
      configured to register only some uarts instead of all of
      them and PM is enabled.
      
      Cc: Govindraj R. <govindraj.raja@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      [tony@atomide.com: updated description]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      f910043c
  4. 22 11月, 2010 1 次提交
  5. 17 11月, 2010 8 次提交
    • D
      OMAP: mux: Add __func__ macro to pr_xxx macros · 032a6424
      Dan Murphy 提交于
      Removed mux: and added the __func__ macro to make debugging
      easier.
      Signed-off-by: NDan Murphy <dmurphy@ti.com>
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      032a6424
    • S
      OMAP4: pandaboard: Select CBL & CBS package and initialize mux · fc63de82
      sricharan 提交于
      The mux framework allows the change of pad configuration by drivers
      when needed. Prior to this the mux framework has to be initialised
      with all the mux parameters specific to the board. The mux init is
      already present in the board file for SDP. Adding the mux init
      for panda boards.
      Signed-off-by: Nsricharan <r.sricharan@ti.com>
      Acked-by: NAnand Gadiyar <gadiyar@ti.com>
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      fc63de82
    • B
      OMAP4: sdp4430: Select CBS package for ES2 · 6fea7b0a
      Benoit Cousson 提交于
      Select the CBS package if SDP4430 is enabled during config.
      Use the proper package (CBL or CBS) based on chip revision.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Anand Gadiyar <gadiyar@ti.com>
      6fea7b0a
    • B
      OMAP4: mux: Add CBS package data for OMAP4430 ES2 · a7722d87
      Benoit Cousson 提交于
      Please note that the full muxmodes are re-defined for ES2 instead
      of using the subset. There are 81 differences among 204 pins.
      The subset fixup will have to iterate over the whole list for each
      subset entry, which can lead to an important number of iteration.
      On the other hand, it will take much more memory at boot time.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Anand Gadiyar <gadiyar@ti.com>
      a7722d87
    • B
      OMAP4: sdp4430: Select CBL package for ES1 and initialize mux · fb6bf632
      Benoit Cousson 提交于
      Select the CBL package if SDP4430 is enabled during config.
      Initialize the mux framework during the board init.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      fb6bf632
    • B
      OMAP4: mux: Add CBL package data for OMAP4430 ES1 · a041a52c
      Benoit Cousson 提交于
      Add data for OMAP4430 generated from HW pinout & register database.
      The data set is split in two partitions for both core and wkup.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      a041a52c
    • B
      OMAP: mux: Add support for control module split in several partitions · 112485e9
      Benoit Cousson 提交于
      Starting on OMAP4, the pin mux configuration is located in two
      different partitions of the control module (CODE_PAD and WKUP_PAD).
      The first one is inside the core power domain whereas the second
      one is inside the wakeup.
      - Add the capability to add any number of partition during board init
      time depending of Soc partitioning.
      - Add some init flags as well in order to avoid explicit Soc version
      check inside the mux core code.
      - Add a comment with mux0 mode on top of omap_mux/board/<partition>
      if the current mux mode is not the default one.
      
      Thanks to Tony Lindgren <tony@atomide.com> for the following improvements:
      - Add omap_mux_get for getting the partition data so platform level
      device code can use it.
      - Fix the rx51 board code to use the new API.
      - Do not store the partition for each mux entry. Look up the partition
      for debugfs instead.
      
      Thanks to Dan Murphy <dmurphy@ti.com> for testing on OMAP4 and reporting
      a couple of bugs.
      Thanks to Anand Gadiyar <gadiyar@ti.com> for testing on OMAP3 zoom and
      bug report.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Tested-by: NMurphy Dan <dmurphy@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Anand Gadiyar <gadiyar@ti.com>
      112485e9
    • B
      OMAP: mux: Replace printk with pr_xxx macros · 1cbb3a9a
      Benoit Cousson 提交于
      Replace all the printk(KERN_XXX... with pr_xxx macros.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      1cbb3a9a
  6. 10 11月, 2010 3 次提交
  7. 06 11月, 2010 2 次提交
  8. 29 10月, 2010 2 次提交
  9. 26 10月, 2010 1 次提交
  10. 23 10月, 2010 3 次提交
  11. 20 10月, 2010 2 次提交
  12. 12 10月, 2010 2 次提交
    • S
      omap: serial: Fix the boot-up crash/reboot without CONFIG_PM · a1b04cc1
      Santosh Shilimkar 提交于
      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: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NCharulatha V <charu@ti.com>
      Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
      Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      a1b04cc1
    • K
      OMAP3: PM: fix scratchpad memory accesses for off-mode · de658158
      Kevin Hilman 提交于
      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: NJean Pihet <jean.pihet@newoldbits.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: NJean Pihet <jean.pihet@newoldbits.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      de658158
  13. 09 10月, 2010 5 次提交