1. 11 11月, 2014 1 次提交
  2. 30 7月, 2013 1 次提交
    • R
      ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL · 7dedd346
      Rajendra Nayak 提交于
      With commit '82702ea1' "ARM: OMAP2+:
      Fix serial init for device tree based booting" stubbing out
      omap_serial_early_init() for Device tree based booting, there was a
      crash observed on AM335x based devices when hwmod does a
      _setup_reset() early at boot.
      
      This was rootcaused to hwmod trying to reset console uart while
      earlycon was using it.  The way to tell hwmod not to do this is to
      specify the HWMOD_INIT_NO_RESET flag, which were infact set by the
      omap_serial_early_init() function by parsing the cmdline to identify
      the console device.
      
      Parsing the cmdline to identify the uart used by earlycon itself seems
      broken as there is nothing preventing earlycon to use a different one.
      
      This patch, instead, attempts to populate the requiste flags for hwmod
      based on the CONFIG_DEBUG_OMAPxUARTy FLAGS. This gets rid of the need
      for cmdline parsing in the DT as well as non-DT cases to identify the
      uart used by earlycon.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Reported-by: NMark Jackson <mpfj-list@newflow.co.uk>
      Reported-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
      Tested-by: NMark Jackson <mpfj-list@newflow.co.uk>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      7dedd346
  3. 13 6月, 2013 1 次提交
  4. 20 5月, 2013 1 次提交
  5. 16 5月, 2013 1 次提交
  6. 26 1月, 2013 1 次提交
    • P
      ARM: OMAP2+: omap_device: remove obsolete pm_lats and early_device code · c1d1cd59
      Paul Walmsley 提交于
      Remove now-obsolete code from arch/arm/mach-omap2/omap_device.c.  This
      mostly consists of removing the first attempt at device PM latency
      handling.  This was never really used, has been replaced by the common
      dev_pm_qos code, and needs to go away as part of the DT conversion.
      Also, the early platform_device creation code has been removed, as it
      appears to be unused.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      c1d1cd59
  7. 12 1月, 2013 1 次提交
    • T
      ARM: OMAP2+: Use omap initcalls · b76c8b19
      Tony Lindgren 提交于
      This way the initcalls don't run on other SoCs on multiplatform
      kernels. Otherwise we'll get something like this when booting
      on vexpress:
      
      omap_hwmod: _ensure_mpu_hwmod_is_setup: MPU initiator hwmod mpu not yet registered
      ...
      WARNING: at arch/arm/mach-omap2/pm.c:82 _init_omap_device+0x74/0x94()
      _init_omap_device: could not find omap_hwmod for mpu
      ...
      omap-dma-engine omap-dma-engine: OMAP DMA engine driver
      ...
      Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      b76c8b19
  8. 15 12月, 2012 1 次提交
  9. 01 12月, 2012 1 次提交
    • T
      ARM: OMAP: Move plat-omap/dma-omap.h to include/linux/omap-dma.h · 45c3eb7d
      Tony Lindgren 提交于
      Based on earlier discussions[1] we attempted to find a suitable
      location for the omap DMA header in commit 2b6c4e73 (ARM: OMAP:
      DMA: Move plat/dma.h to plat-omap/dma-omap.h) until the conversion
      to dmaengine is complete.
      
      Unfortunately that was before I was able to try to test compile
      of the ARM multiplatform builds for omap2+, and the end result
      was not very good.
      
      So I'm creating yet another all over the place patch to cut the
      last dependency for building omap2+ for ARM multiplatform. After
      this, we have finally removed the driver dependencies to the
      arch/arm code, except for few drivers that are being worked on.
      
      The other option was to make the <plat-omap/dma-omap.h> path
      to work, but we'd have to add some new header directory to for
      multiplatform builds.
      
      Or we would have to manually include arch/arm/plat-omap/include
      again from arch/arm/Makefile for omap2+.
      
      Neither of these alternatives sound appealing as they will
      likely lead addition of various other headers exposed to the
      drivers, which we want to avoid for the multiplatform kernels.
      
      Since we already have a minimal include/linux/omap-dma.h,
      let's just use that instead and add a note to it to not
      use the custom omap DMA functions any longer where possible.
      
      Note that converting omap DMA to dmaengine depends on
      dmaengine supporting automatically incrementing the FIFO
      address at the device end, and converting all the remaining
      legacy drivers. So it's going to be few more merge windows.
      
      [1] https://patchwork.kernel.org/patch/1519591/#
      
      cc: Russell King <linux@arm.linux.org.uk>
      cc: Kevin Hilman <khilman@ti.com>
      cc: "Benoît Cousson" <b-cousson@ti.com>
      cc: Herbert Xu <herbert@gondor.apana.org.au>
      cc: "David S. Miller" <davem@davemloft.net>
      cc: Vinod Koul <vinod.koul@intel.com>
      cc: Dan Williams <djbw@fb.com>
      cc: Mauro Carvalho Chehab <mchehab@infradead.org>
      cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
      cc: David Woodhouse <dwmw2@infradead.org>
      cc: Kyungmin Park <kyungmin.park@samsung.com>
      cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
      cc: Hans Verkuil <hans.verkuil@cisco.com>
      cc: Vaibhav Hiremath <hvaibhav@ti.com>
      cc: Lokesh Vutla <lokeshvutla@ti.com>
      cc: Rusty Russell <rusty@rustcorp.com.au>
      cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
      cc: Afzal Mohammed <afzal@ti.com>
      cc: linux-crypto@vger.kernel.org
      cc: linux-media@vger.kernel.org
      cc: linux-mtd@lists.infradead.org
      cc: linux-usb@vger.kernel.org
      cc: linux-fbdev@vger.kernel.org
      Acked-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      45c3eb7d
  10. 25 10月, 2012 1 次提交
  11. 23 10月, 2012 1 次提交
    • K
      ARM: OMAP2: UART: fix console UART mismatched runtime PM status · 44b1d42a
      Kevin Hilman 提交于
      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: NRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Sourav Poddar <sourav.poddar@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      44b1d42a
  12. 19 10月, 2012 3 次提交
  13. 18 10月, 2012 1 次提交
  14. 16 10月, 2012 1 次提交
  15. 13 9月, 2012 1 次提交
    • T
      ARM: OMAP2+: Prepare for irqs.h removal · 7d7e1eba
      Tony Lindgren 提交于
      As the interrupts should only be defined in the platform_data, and
      eventually coming from device tree, there's no need to define them
      in header files.
      
      Let's remove the hardcoded references to irqs.h and fix up the includes
      so we don't rely on headers included in irqs.h. Note that we're
      defining OMAP_INTC_START as 0 to the interrupts. This will be needed
      when we enable SPARSE_IRQ. For some drivers we need to add
      #include <plat/cpu.h> for now until these drivers are fixed to
      remove cpu_is_omapxxxx() usage.
      
      While at it, sort som of the includes the standard way, and add
      the trailing commas where they are missing in the related data
      structures.
      
      Note that for drivers/staging/tidspbridge we just define things
      locally.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      7d7e1eba
  16. 12 9月, 2012 2 次提交
    • P
      ARM: OMAP: unwrap strings · 7852ec05
      Paul Walmsley 提交于
      Find and unwrap wrapped strings in the style:
      
      	pr_debug("clockdomain: hardware cannot set/clear wake up of "
      		 "%s when %s wakes up\n", clkdm1->name, clkdm2->name);
      
      Keeping these strings contiguous seems to be the current Linux kernel
      policy.
      
      The offending lines were found with the following command:
      
          pcregrep -rnM '"\s*$\s*"' arch/arm/*omap*
      
      While here, some messages have been clarified, some pr_warning(
      ... calls have been converted to pr_warn( ..., and some printk(KERN_*
      ... have been converted to pr_*.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      7852ec05
    • P
      ARM: OMAP: clean up some smatch warnings, fix some printk(KERN_ERR ... · a032d33b
      Paul Walmsley 提交于
      Resolve the following warnings from smatch:
      
      arch/arm/mach-omap2/gpmc.c:282 gpmc_cs_set_timings() info: why not propagate 'div' from gpmc_cs_calc_divider() instead of -1?
      arch/arm/mach-omap2/serial.c:328 omap_serial_init_port() error: 'pdev' dereferencing possible ERR_PTR()
      arch/arm/mach-omap2/timer.c:213 omap2_gp_clockevent_init() Error invalid range 4096 to -1
      arch/arm/mach-omap2/gpio.c:63 omap2_gpio_dev_init() warn: possible memory leak of 'pdata'
      arch/arm/mach-omap2/omap_hwmod.c:1478 _assert_hardreset() warn: assigning -22 to unsigned variable 'ret'
      arch/arm/mach-omap2/omap_hwmod.c:1487 _assert_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same.
      arch/arm/mach-omap2/omap_hwmod.c:1545 _read_hardreset() warn: assigning -22 to unsigned variable 'ret'
      arch/arm/mach-omap2/omap_hwmod.c:1554 _read_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same.
      arch/arm/mach-omap2/dpll3xxx.c:629 omap3_clkoutx2_recalc() error: we previously assumed 'pclk' could be null (see line 627)
      arch/arm/mach-omap2/board-n8x0.c:422 n8x0_mmc_late_init() Error invalid range 14 to 13
      arch/arm/mach-omap1/leds-h2p2-debug.c:71 h2p2_dbg_leds_event() error: potentially derefencing uninitialized 'fpga'.
      arch/arm/plat-omap/mux.c:79 omap_cfg_reg() Error invalid range 4096 to -1
      
      Thanks to Tony Lindgren <tony@atomide.com> for pointing out that BUG()
      can be disabled.  The changes in the first version that removed the
      subsequent return() after BUG() states have been dropped.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      a032d33b
  17. 11 9月, 2012 1 次提交
  18. 07 9月, 2012 1 次提交
  19. 17 8月, 2012 1 次提交
  20. 05 6月, 2012 1 次提交
    • G
      OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup · 91930652
      Govindraj.R 提交于
      The commit (bce492c0  ARM: OMAP2+: UART: Fix incorrect population of
      default uart pads) removed default uart pads that where getting populated
      and which was making rx pin wakeup capable. If uart pads were used in
      different mode by any other module then it would fail since the default
      pads took over all the uart pins forcefully. With removal of default pads
      the rx_pad wakeup for console uart while waking up from off mode is broken.
      
      Utilise the mux api available to probe the availability of mux pins
      in uart mode and probe for availability of uart pin in mux mode0
      if uart is available as uart pin itself then configure rx pin
      as wakeup capable.
      
      This patch itself doesn't cater to all boards. Boards using uart rx wakeup
      mechanism should ensure the usage of omap_serial_init_port by configuring
      required uart ports and pass necessary mux data, till then this probing of
      uart pins can cater to enabling of rx pad wakeup to most of the boards.
      
      This patch can also throw some boot warning from _omap_mux_get_by_name
      if pin is requested for availability is not present while dynamically probing
      the uart pins availability such boot warnings can be addressed only when board
      files are patched with omap_serial_init_port calls passing the right pads
      needed for a given port.
      
      Discussion Threads for reference:
      http://www.spinics.net/lists/linux-omap/msg69859.html
      http://www.spinics.net/lists/linux-omap/msg68659.html
      
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Russ Dill <russ.dill@gmail.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Ameya Palande <ameya.palande@ti.com>
      Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
      [tony@atomide.com: updated to fix compile when CONFIG_OMAP_MUX is not set]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      91930652
  21. 19 4月, 2012 1 次提交
  22. 18 4月, 2012 2 次提交
  23. 13 4月, 2012 1 次提交
    • P
      ARM: OMAP2+: declare file-local functions as static · 8c3d4534
      Paul Walmsley 提交于
      Several function declarations used only in the files in which they're
      declared should include the static keyword, but don't:
      
          arch/arm/mach-omap2/serial.c:248:6: warning: symbol 'cmdline_find_option' was not declared. Should it be static?
          arch/arm/mach-omap2/omap-wakeupgen.c:259:6: warning: symbol 'irq_sar_clear' was not declared. Should it be static?
          arch/arm/mach-omap2/board-rx51-peripherals.c:878:27: warning: symbol 'rx51_vibra_data' was not declared. Should it be static?
          arch/arm/mach-omap2/board-rx51-peripherals.c:882:27: warning: symbol 'rx51_audio_data' was not declared. Should it be static?
          arch/arm/mach-omap2/board-omap4panda.c:201:29: warning: symbol 'omap_panda_wlan_data' was not declared. Should it be static?
          arch/arm/mach-omap2/board-omap4panda.c:393:24: warning: symbol 'omap4_panda_dvi_device' was not declared. Should it be static?
          arch/arm/mach-omap2/board-omap4panda.c:403:12: warning: symbol 'omap4_panda_dvi_init' was not declared. Should it be static?
          arch/arm/mach-omap2/board-omap4panda.c:464:6: warning: symbol 'omap4_panda_display_init' was not declared. Should it be static?
          arch/arm/mach-omap2/hsmmc.c:434:6: warning: symbol 'omap_init_hsmmc' was not declared. Should it be static?
          arch/arm/mach-omap2/hwspinlock.c:31:12: warning: symbol 'hwspinlocks_init' was not declared. Should it be static?
          arch/arm/mach-omap1/timer.c:58:12: warning: symbol 'omap1_dm_timer_init' was not declared. Should it be static?
          arch/arm/mach-omap1/fpga.c:90:6: warning: symbol 'innovator_fpga_IRQ_demux' was not declared. Should it be static?
      
      Mark all of these as static.
      
      Thanks to Arnd Bergmann <arnd@arndb.de> for pointing out a typo in the
      original patch description.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Govindraj R <govindraj.raja@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: David Anders <x0132446@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      8c3d4534
  24. 22 2月, 2012 1 次提交
  25. 10 2月, 2012 1 次提交
    • P
      tty: serial: OMAP: block idle while the UART is transferring data in PIO mode · be4b0281
      Paul Walmsley 提交于
      Prevent OMAP UARTs from going idle while they are still transferring
      data in PIO mode.  This works around an oversight in the OMAP UART
      hardware present in OMAP34xx and earlier: an idle UART won't send a
      wakeup when the TX FIFO threshold is reached.  This causes long delays
      during data transmission when the MPU powerdomain enters a low-power
      mode.  The MPU interrupt controller is not able to respond to
      interrupts when it's in a low-power state, so the TX buffer is not
      refilled until another wakeup event occurs.
      
      This fix changes the erratum i291 DMA idle workaround.  Rather than
      toggling between force-idle and no-idle, it will toggle between
      smart-idle and no-idle.  The important part of the workaround is the
      no-idle part, so this shouldn't result in any change in behavior.
      
      This fix should work on all OMAP UARTs.  Future patches intended for
      the 3.4 merge window will make this workaround conditional on a
      "feature" flag, and will use the OMAP36xx+ TX event wakeup support.
      
      Thanks to Kevin Hilman <khilman@ti.com> for mentioning the erratum i291
      workaround, which led to the development of this approach.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NGovindraj.R <govindraj.raja@ti.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Tested-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be4b0281
  26. 03 2月, 2012 1 次提交
    • P
      tty: serial: OMAP: block idle while the UART is transferring data in PIO mode · edbe5dbe
      Paul Walmsley 提交于
      Prevent OMAP UARTs from going idle while they are still transferring
      data in PIO mode.  This works around an oversight in the OMAP UART
      hardware present in OMAP34xx and earlier: an idle UART won't send a
      wakeup when the TX FIFO threshold is reached.  This causes long delays
      during data transmission when the MPU powerdomain enters a low-power
      mode.  The MPU interrupt controller is not able to respond to
      interrupts when it's in a low-power state, so the TX buffer is not
      refilled until another wakeup event occurs.
      
      This fix changes the erratum i291 DMA idle workaround.  Rather than
      toggling between force-idle and no-idle, it will toggle between
      smart-idle and no-idle.  The important part of the workaround is the
      no-idle part, so this shouldn't result in any change in behavior.
      
      This fix should work on all OMAP UARTs.  Future patches intended for
      the 3.4 merge window will make this workaround conditional on a
      "feature" flag, and will use the OMAP36xx+ TX event wakeup support.
      
      Thanks to Kevin Hilman <khilman@ti.com> for mentioning the erratum i291
      workaround, which led to the development of this approach.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NGovindraj.R <govindraj.raja@ti.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Tested-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      edbe5dbe
  27. 15 12月, 2011 10 次提交
    • G
      ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos · 2fd14964
      Govindraj.R 提交于
      Omap_uart_can_sleep function blocks system wide low power state until
      uart is active remove this func and add qos requests to prevent
      MPU from transitioning.
      
      Keep qos request to default value which will allow MPU to transition
      and while uart baud rate is available calculate the latency value
      from the baudrate and use the same to hold constraint while uart clocks
      are enabled, and if uart is auto-idled the constraint is updated with
      default constraint value allowing MPU to transition.
      
      Qos requests are blocking notifier calls so put these requests to
      work queue, also the driver uses irq_safe version of runtime API's
      and callbacks can be called in interrupt disabled context.
      So to avoid warn on slow path warning while using qos update
      API's from runtime callbacks use the qos_work_queue.
      
      During bootup the runtime_resume call backs might not be called and runtime
      callback gets called only after uart is idled by setting the autosuspend
      timeout. So qos_request from runtime resume callback might not activated during
      boot if uart baudrate is calculated during bootup for console uart, so schedule
      the qos_work queue once we calc_latency while configuring the uart port.
      
      Flush and complete any pending qos jobs in work queue while suspending.
      Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
      Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes)
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      2fd14964
    • G
      ARM: OMAP2+: UART: Do not gate uart clocks if used for debug_prints · 36fc2d15
      Govindraj.R 提交于
      If OMAP UART is used as console uart and debug is enabled,
      avoid gating of uart clocks to print all debug prints.
      
      If uart clocks are gated then the debug prints from omap_device
      framework or hwmod framework can cause uart to enter recursive
      pm_runtime calls, which can cause a deadlock over power lock usage.
      
      For example: Say, uart clocks are cut and we get a print from
      omap_device_disable stating disabling uart clocks. This print
      calls omap_uart driver console_write which will call runtime API
      get_sync which means we enter from runtime API put context to
      runtime API get context.
      
      --> runtime put (take power lock)
          --> print disabling uart clocks
              --> call uart console write
                  --> call get_sync (try to take power lock)
      
      Also any clock enable API call from uart driver should not call any uart
      operation until clocks are enabled back. Like get_sync having debug print
      calling uart console write even before clocks are enabled.
      
      So to avoid these scenarios, identify from bootargs if OMAP_UART(ttyO) is used
      in debug mode. If so, do not set device_may_wakeup. This will prevent
      pm_runtime_enable in uart driver and will avoid uart clock gating.
      Debug is enabled either by adding debug word in bootarg or by setting
      loglevel=10
      Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      36fc2d15
    • G
      ARM: OMAP2+: UART: Avoid uart idling on suspend for no_console_suspend usecase · 08f86b3e
      Govindraj.R 提交于
      If no_console_suspend is used we have prevent uart idling during suspend
      to provide debug prints.
      
      Power domain hooks can idle uarts if left enabled during system wide suspend
      so re-use the omap_device_disable_idle_on_suspend API's to ensure console_uart
      is not idled during suspend.
      
      omap_device_disable_idle_on_suspend API was used on all uarts since the uart
      driver was not runtime adapted, now with runtime adaptation we can re-use this
      API only for no_console_suspend use cases.
      Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      08f86b3e
    • G
      ARM: OMAP2+: UART: Avoid console uart idling during bootup · 8612bd22
      Govindraj.R 提交于
      Omap-uart can be used as console uart to print early boot messages using
      earlyprintk so for console uart prevent hwmod reset or idling during bootup.
      
      Identify omap-uart used as console and avoid idling rather than preventing
      all omap-uarts from idling during bootup. Update the comments for the same.
      
      Remove the uart idling and enabling back using hwmod_idle/omap_device_enable
      for all uarts that where left enabled from boot to set the hwmod framework
      state machine right. This need not be taken care any more serial.c rather
      can be handled within the hwmod framework.
      Reference: http://www.spinics.net/lists/linux-omap/msg60300.htmlSigned-off-by: NGovindraj.R <govindraj.raja@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      8612bd22
    • G
      ARM: OMAP2+: UART: remove temporary variable used to count uart instance · 969996a5
      Govindraj.R 提交于
      Reuse the num_uarts variable itself to count number of uarts.
      Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      969996a5
    • J
      ARM: OMAP2+: UART: Make the RX_TIMEOUT for DMA configurable for each UART · a9e210e0
      Jon Hunter 提交于
      When using DMA there are two timeouts defined. The first timeout,
      rx_timeout, is really a polling rate in which software polls the
      DMA status to see if the DMA has finished. This is necessary for
      the RX side because we do not know how much data we will receive.
      The secound timeout, RX_TIMEOUT, is a timeout after which the
      DMA will be stopped if no more data is received. To make this
      clearer, rename rx_timeout as rx_poll_rate and rename the
      function serial_omap_rx_timeout() to serial_omap_rxdma_poll().
      
      The OMAP-Serial driver defines an RX_TIMEOUT of 3 seconds that is
      used to indicate when the DMA for UART can be stopped if no more
      data is received. The value is a global definition that is applied
      to all instances of the UART.
      
      Each UART may be used for a different purpose and so the timeout
      required may differ. Make this value configurable for each UART so
      that this value can be optimised for power savings.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
      Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes)
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      a9e210e0
    • D
      ARM: OMAP2+: UART: Allow UART parameters to be configured from board file. · c86845db
      Deepak K 提交于
      The following UART parameters are defined within the UART driver:
      
      1). Whether the UART uses DMA (dma_enabled), by default set to 0
      2). The size of dma buffer (set to 4096 bytes)
      3). The time after which the dma should stop if no more data is received.
      4). The auto suspend delay that will be passed for pm_runtime_autosuspend
          where uart will be disabled after timeout
      
      Different UARTs may be used for different purpose such as the console,
      for interfacing bluetooth chip, for interfacing to a modem chip, etc.
      Therefore, it is necessary to be able to customize the above settings
      for a given board on a per UART basis.
      
      This change allows these parameters to be configured from the board file
      and allows the parameters to be configured for each UART independently.
      
      If a board does not define its own custom parameters for the UARTs, then
      use the default parameters in the structure "omap_serial_default_info".
      The default parameters are defined to be the same as the current settings
      in the UART driver to avoid breaking the UART for any cuurnelty supported
      boards. By default, make all boards use the default UART parameters.
      Signed-off-by: NDeepak K <deepak.k@ti.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
      Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes)
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      c86845db
    • G
      ARM: OMAP2+: UART: Remove old and unused clocks handling funcs · 634bd6e4
      Govindraj.R 提交于
      With runtime adaptation done remove clock_enable/disbale API's
      Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      634bd6e4
    • G
      ARM: OMAP2+: UART: Add wakeup mechanism for omap-uarts · 62f3ec5f
      Govindraj.R 提交于
      From the runtime callbacks enable hwmod wakeups for uart which will
      internally enable io-pad wakeups for uarts if they have rx-pad pins
      set as wakeup capabale.
      
      Use the io-ring wakeup mechanism after uart clock gating and leave
      the PM_WKST set for uart to default reset values cleanup the
      code in serial.c which was handling PM_WKST reg.
      Irq_chaing(PRM_DRIVER) is used to wakeup uart after uart clocks are gated
      using pad wakeup mechanism.
      Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
      Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes)
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      62f3ec5f
    • G
      ARM: OMAP2+: UART: Move errata handling from serial.c to omap-serial · 94734749
      Govindraj.R 提交于
      Move the errata handling mechanism from serial.c to omap-serial file
      and utilise the same func in driver file.
      
      Errata i202, i291 are moved to be handled with omap-serial
      Moving the errata macro from serial.c file to driver header file
      as from on errata will be handled in driver file itself.
      Corrected errata id from chapter reference 2.15 to errata id i291.
      
      Removed errata and dma_enabled fields from omap_uart_state struct
      as they are no more needed with errata handling done within omap-serial.
      Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
      Acked-by: NAlan Cox <alan@linux.intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      94734749