1. 09 9月, 2014 18 次提交
  2. 08 9月, 2014 6 次提交
  3. 28 8月, 2014 2 次提交
  4. 26 8月, 2014 5 次提交
    • T
      ARM: OMAP2+: hwmod: Rearm wake-up interrupts for DT when MUSB is idled · cc824534
      Tony Lindgren 提交于
      Looks like MUSB cable removal can cause wake-up interrupts to
      stop working for device tree based booting at least for UART3
      even as nothing is dynamically remuxed. This can be fixed by
      calling reconfigure_io_chain() for device tree based booting
      in hwmod code. Note that we already do that for legacy booting
      if the legacy mux is configured.
      
      My guess is that this is related to UART3 and MUSB ULPI
      hsusb0_data0 and hsusb0_data1 support for Carkit mode that
      somehow affect the configured IO chain for UART3 and require
      rearming the wake-up interrupts.
      
      In general, for device tree based booting, pinctrl-single
      calls the rearm hook that in turn calls reconfigure_io_chain
      so calling reconfigure_io_chain should not be needed from the
      hwmod code for other events.
      
      So let's limit the hwmod rearming of iochain only to
      HWMOD_FORCE_MSTANDBY where MUSB is currently the only user
      of it. If we see other devices needing similar changes we can
      add more checks for it.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: stable@vger.kernel.org # v3.16
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      cc824534
    • M
      ARM: OMAP2+: omap_device: remove warning that clk alias already exists · 9a02ae4e
      Markus Pargmann 提交于
      When an alias for a clock already exists the warning is printed. For
      every module with a main_clk defined, a clk alias for fck is added.
      There are some components that have the same main_clk defined, so this
      is a really normal situation.
      
      For example the am33xx edma device has 4 components using the same main
      clock. So there are three warnings in the boot log for this already
      existing clock alias:
      	platform 49000000.edma: alias fck already exists
      	platform 49000000.edma: alias fck already exists
      	platform 49000000.edma: alias fck already exists
      
      As this is only interesting for developers, this patch changes the
      message to a debug message.
      Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      9a02ae4e
    • H
      ARM: OMAP: fix %d confusingly prefixed with 0x in format string · 6953faf9
      Hans Wennborg 提交于
      Fix %d confusingly prefixed with 0x in format string.
      Signed-off-by: NHans Wennborg <hans@hanshq.net>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      6953faf9
    • R
      ARM: OMAP2+: GPMC: Support Software ECC scheme via DT · a3e83f05
      Roger Quadros 提交于
      For v3.14 and prior, 1-bit Hamming code ECC via software was the
      default choice for some boards e.g. 3430sdp.
      Commit ac65caf5 in v3.15 changed the behaviour
      to use 1-bit Hamming code via Hardware using a different ECC layout
      i.e. (ROM code layout) than what is used by software ECC.
      
      This ECC layout change causes NAND filesystems created in v3.14
      and prior to be unusable in v3.15 and later. So don't mark "sw" scheme
      as deperecated and support it.
      Signed-off-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      a3e83f05
    • R
      mtd: nand: omap: Revert to using software ECC by default · 7d5929c1
      Roger Quadros 提交于
      For v3.12 and prior, 1-bit Hamming code ECC via software was the
      default choice. Commit c66d0391 in v3.13 changed the behaviour
      to use 1-bit Hamming code via Hardware using a different ECC layout
      i.e. (ROM code layout) than what is used by software ECC.
      
      This ECC layout change causes NAND filesystems created in v3.12
      and prior to be unusable in v3.13 and later. So revert back to
      using software ECC by default if an ECC scheme is not explicitely
      specified.
      
      This defect can be observed on the following boards during legacy boot
      
      -omap3beagle
      -omap3touchbook
      -overo
      -am3517crane
      -devkit8000
      -ldp
      -3430sdp
      Signed-off-by: NRoger Quadros <rogerq@ti.com>
      Tested-by: NGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      7d5929c1
  5. 09 8月, 2014 1 次提交
  6. 01 8月, 2014 2 次提交
  7. 29 7月, 2014 1 次提交
  8. 25 7月, 2014 1 次提交
    • P
      ARM: OMAP2+: clock: allow omap2_dpll_round_rate() to round to next-lowest rate · 0a263444
      Paul Walmsley 提交于
      Change the behavior of omap2_dpll_round_rate() to round to either the
      exact rate requested, or the next lowest rate that the clock is able to
      provide.
      
      This is not an ideal fix, but is intended to provide a relatively safe
      way for drivers to set PLL rates, until a better solution can be
      implemented.
      
      For the time being, omap3_noncore_dpll_set_rate() is still allowed to
      set its rate to something other than what the caller requested; but will
      warn when this occurs.
      
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Mike Turquette <mturquette@linaro.org>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      0a263444
  9. 23 7月, 2014 4 次提交