1. 27 11月, 2013 1 次提交
  2. 26 11月, 2013 1 次提交
    • T
      ARM: OMAP2+: Fix eMMC on n900 with device tree · edd5eb4e
      Tony Lindgren 提交于
      Looks like we need to configure the regulators and use the pdata
      quirk to make eMMC work with device tree.
      
      It seems that mostly vaux3 is used, and only some earlier revisions
      used vmmc2. This has been tested to work on devices where the
      system_rev passed by the bootloader has versions 0x0010, 0x2101
      and 0x2204.
      
      Cc: devicetree@vger.kernel.org
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NSebastian Reichel <sre@debian.org>
      [tony@atomide.com: updated with pinctrl changes and comments from Sebastian]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      edd5eb4e
  3. 16 11月, 2013 1 次提交
  4. 15 11月, 2013 3 次提交
    • N
      ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume · 3522bf7b
      Nishanth Menon 提交于
      OMAP device hooks around suspend|resume_noirq ensures that hwmod
      devices are forced to idle using omap_device_idle/enable as part of
      the last stage of suspend activity.
      
      For a device such as i2c who uses autosuspend, it is possible to enter
      the suspend path with dev->power.runtime_status = RPM_ACTIVE.
      
      As part of the suspend flow, the generic runtime logic would increment
      it's dev->power.disable_depth to 1. This should prevent further
      pm_runtime_get_sync from succeeding once the runtime_status has been
      set to RPM_SUSPENDED.
      
      Now, as part of the suspend_noirq handler in omap_device, we force the
      following: if the device status is !suspended, we force the device
      to idle using omap_device_idle (clocks are cut etc..). This ensures
      that from a hardware perspective, the device is "suspended". However,
      runtime_status is left to be active.
      
      *if* an operation is attempted after this point to
      pm_runtime_get_sync, runtime framework depends on runtime_status to
      indicate accurately the device status, and since it sees it to be
      ACTIVE, it assumes the module is functional and returns a non-error
      value. As a result the user will see pm_runtime_get succeed, however a
      register access will crash due to the lack of clocks.
      
      To prevent this from happening, we should ensure that runtime_status
      exactly indicates the device status. As a result of this change
      any further calls to pm_runtime_get* would return -EACCES (since
      disable_depth is 1). On resume, we restore the clocks and runtime
      status exactly as we suspended with. These operations are not expected
      to fail as we update the states after the core runtime framework has
      suspended itself and restore before the core runtime framework has
      resumed.
      
      Cc: stable@vger.kernel.org # v3.4+
      Reported-by: NJ Keerthy <j-keerthy@ti.com>
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Acked-by: NRajendra Nayak <rnayak@ti.com>
      Acked-by: NKevin Hilman <khilman@linaro.org>
      Reviewed-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      3522bf7b
    • W
      ARM: OMAP3: Beagle: fix return value check in beagle_opp_init() · c27f2de7
      Wei Yongjun 提交于
      In case of error, the function get_cpu_device() returns NULL pointer
      not ERR_PTR(). The IS_ERR() test in the return value check should be
      replaced with NULL test.
      Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      c27f2de7
    • W
      ARM: OMAP2+: smsc911x: fix return value check in gpmc_smsc911x_init() · 30e3488c
      Wei Yongjun 提交于
      In case of error, the function platform_device_register_resndata()
      returns ERR_PTR() and never returns NULL. The NULL test in the return
      value check should be replaced with IS_ERR().
      Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Acked-by: NIgor Grinberg <grinberg@compulab.co.il>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      30e3488c
  5. 07 11月, 2013 2 次提交
    • P
      mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes · c66d0391
      Pekon Gupta 提交于
      OMAP NAND driver currently supports multiple flavours of 1-bit Hamming
      ecc-scheme, like:
      - OMAP_ECC_HAMMING_CODE_DEFAULT
      	1-bit hamming ecc code using software library
      - OMAP_ECC_HAMMING_CODE_HW
      	1-bit hamming ecc-code using GPMC h/w engine
      - OMAP_ECC_HAMMING_CODE_HW_ROMCODE
      	1-bit hamming ecc-code using GPMC h/w engin with ecc-layout compatible
      	to ROM code.
      
      This patch combines above multiple ecc-schemes into single implementation:
      - OMAP_ECC_HAM1_CODE_HW
      	1-bit hamming ecc-code using GPMC h/w engine with ROM-code compatible
      	ecc-layout.
      Signed-off-by: NPekon Gupta <pekon@ti.com>
      Reviewed-by: NFelipe Balbi <balbi@ti.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      c66d0391
    • P
      ARM: OMAP2+: cleaned-up DT support of various ECC schemes · ac65caf5
      Pekon Gupta 提交于
      OMAP NAND driver support multiple ECC scheme, which can used in different
      flavours, depending on in-build Hardware engines present on SoC.
      
      This patch updates following in DT bindings related to sectionion of ecc-schemes
      - ti,elm-id: replaces elm_id (maintains backward compatibility)
      - ti,nand-ecc-opts: selection of h/w or s/w implementation of an ecc-scheme
      	depends on ti,elm-id. (supported values ham1, bch4, and bch8)
      - maintain backward compatibility to deprecated DT bindings (sw, hw, hw-romcode)
      
      Below table shows different flavours of ecc-schemes supported by OMAP devices
      +---------------------------------------+---------------+---------------+
      | ECC scheme                            |ECC calculation|Error detection|
      +---------------------------------------+---------------+---------------+
      |OMAP_ECC_HAM1_CODE_HW                  |H/W (GPMC)     |S/W            |
      +---------------------------------------+---------------+---------------+
      |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW     |H/W (GPMC)     |S/W            |
      |(requires CONFIG_MTD_NAND_ECC_BCH)     |               |               |
      +---------------------------------------+---------------+---------------+
      |OMAP_ECC_BCH8_CODE_HW                  |H/W (GPMC)     |H/W (ELM)      |
      |(requires CONFIG_MTD_NAND_OMAP_BCH &&  |               |               |
      | ti,elm-id in DT)                      |               |               |
      +---------------------------------------+---------------+---------------+
      
      To optimize footprint of omap2-nand driver, selection of some ECC schemes
      also require enabling following Kconfigs, in addition to setting appropriate
      DT bindings
      - Kconfig:CONFIG_MTD_NAND_ECC_BCH        error detection done in software
      - Kconfig:CONFIG_MTD_NAND_OMAP_BCH       error detection done by h/w engine
      Signed-off-by: NPekon Gupta <pekon@ti.com>
      Reviewed-by: NFelipe Balbi <balbi@ti.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      ac65caf5
  6. 26 10月, 2013 4 次提交
  7. 24 10月, 2013 3 次提交
  8. 22 10月, 2013 5 次提交
  9. 20 10月, 2013 5 次提交
  10. 19 10月, 2013 4 次提交
  11. 16 10月, 2013 2 次提交
  12. 15 10月, 2013 1 次提交
  13. 14 10月, 2013 8 次提交