1. 25 Nov, 2010 2 commits
    • Paul Walmsley's avatar
      OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled · 0d8e2d0d
      Paul Walmsley authored
      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: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Acked-by: default avatarKevin 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
    • Kevin Hilman's avatar
      OMAP: UART: don't resume UARTs that are not enabled. · f910043c
      Kevin Hilman authored
      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: default avatarKevin Hilman <khilman@deeprootsystems.com>
      [tony@atomide.com: updated description]
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      f910043c
  2. 24 Nov, 2010 38 commits