1. 14 2月, 2014 2 次提交
    • P
      ARM: OMAP2+: gpmc: fix: DT ONENAND child nodes not probed when MTD_ONENAND is built as module · 980386d2
      Pekon Gupta 提交于
      Fixes: commit 75d3625e
             ARM: OMAP2+: gpmc: add DT bindings for OneNAND
      
      OMAP SoC(s) depend on GPMC controller driver to parse GPMC DT child nodes and
      register them platform_device for ONENAND driver to probe later. However this does
      not happen if generic MTD_ONENAND framework is built as module (CONFIG_MTD_ONENAND=m).
      
      Therefore, when MTD/ONENAND and MTD/ONENAND/OMAP2 modules are loaded, they are unable
      to find any matching platform_device and remain un-binded. This causes on board
      ONENAND flash to remain un-detected.
      
      This patch causes GPMC controller to parse DT nodes when
      CONFIG_MTD_ONENAND=y || CONFIG_MTD_ONENAND=m
      
      CC: <stable@vger.kernel.org> # 3.9.x+
      Signed-off-by: NPekon Gupta <pekon@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      980386d2
    • P
      ARM: OMAP2+: gpmc: fix: DT NAND child nodes not probed when MTD_NAND is built as module · 6b187b21
      Pekon Gupta 提交于
      Fixes: commit bc6b1e7b
             ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
      
      OMAP SoC(s) depend on GPMC controller driver to parse GPMC DT child nodes and
      register them platform_device for NAND driver to probe later. However this does
      not happen if generic MTD_NAND framework is built as module (CONFIG_MTD_NAND=m).
      
      Therefore, when MTD/NAND and MTD/NAND/OMAP2 modules are loaded, they are unable
      to find any matching platform_device and remain un-binded. This causes on board
      NAND flash to remain un-detected.
      
      This patch causes GPMC controller to parse DT nodes when
      CONFIG_MTD_NAND=y || CONFIG_MTD_NAND=m
      
      CC: <stable@vger.kernel.org> # 3.9.x+
      Signed-off-by: NPekon Gupta <pekon@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      6b187b21
  2. 16 11月, 2013 1 次提交
    • T
      ARM: OMAP2+: Fix GPMC and simplify bootloader timings for 8250 and smc91x · fd4446f2
      Tony Lindgren 提交于
      Commit f2bf0e72 (ARM: OMAP2+: Add minimal 8250 support
      for GPMC) added support for using bootloader timings for some
      devices. Turns out we can do the same by looking at the compatible
      flags of the child without adding a new function as smc91x has
      a similar issue as 8250 with the bootloader timings.
      
      And let's fix the 8250 naming, we should use the device type as
      the name like uart instead of 8250 for zoom dts file.
      
      Cc: "Benoît Cousson" <bcousson@baylibre.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      fd4446f2
  3. 07 11月, 2013 1 次提交
    • 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
  4. 12 10月, 2013 1 次提交
  5. 19 9月, 2013 1 次提交
  6. 22 8月, 2013 1 次提交
  7. 04 7月, 2013 1 次提交
  8. 18 6月, 2013 1 次提交
  9. 13 6月, 2013 2 次提交
  10. 17 5月, 2013 1 次提交
    • J
      ARM: dts: OMAP2+: Simplify NAND support · f40739fa
      Jon Hunter 提交于
      Commit 8c8a7771 (ARM: OMAP2+: Add function to read GPMC settings from
      device-tree) added a device-tree property "gpmc,device-nand" to indicate
      is the GPMC child device is NAND. This commit should have updated the
      GPMC NAND documentation (Documentation/devicetree/bindings/mtd/gpmc-nand.txt)
      to list the property "gpmc,device-nand" as a required property and also
      updated the example. However, this property is redundant and not needed
      because the GPMC child device node for NAND is called "nand". Therefore,
      remove this property.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      f40739fa
  11. 16 5月, 2013 1 次提交
  12. 03 5月, 2013 1 次提交
    • R
      ARM: OMAP: use consistent error checking · c48cd659
      Russell King 提交于
      Consistently check errors using the usual method used in the kernel
      for much of its history.  For instance:
      
      int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
      {
      	int div;
      	div = gpmc_calc_divider(t->sync_clk);
      	if (div < 0)
      		return div;
      static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
      {
      ...
      	return gpmc_cs_set_timings(cs, t);
      
      .....
      	ret = gpmc_set_async_mode(gpmc_onenand_data->cs, &t);
      	if (IS_ERR_VALUE(ret))
      		return ret;
      
      So, gpmc_cs_set_timings() thinks any negative return value is an error,
      but where we check that in higher levels, only a limited range are
      errors...
      
      There is only _one_ use of IS_ERR_VALUE() in arch/arm which is really
      appropriate, and that is in arch/arm/include/asm/syscall.h:
      
      static inline long syscall_get_error(struct task_struct *task,
      				     struct pt_regs *regs)
      {
      	unsigned long error = regs->ARM_r0;
      	return IS_ERR_VALUE(error) ? error : 0;
      }
      
      because this function really does have to differentiate between error
      return values and addresses which look like negative numbers (eg, from
      mmap()).
      
      So, here's a patch to remove them from OMAP, except for the above.
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c48cd659
  13. 30 4月, 2013 2 次提交
  14. 04 4月, 2013 8 次提交
  15. 02 4月, 2013 10 次提交
  16. 14 3月, 2013 1 次提交
    • R
      ARM: OMAP: use consistent error checking · 71856843
      Russell King 提交于
      Consistently check errors using the usual method used in the kernel
      for much of its history.  For instance:
      
      int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
      {
      	int div;
      	div = gpmc_calc_divider(t->sync_clk);
      	if (div < 0)
      		return div;
      static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
      {
      ...
      	return gpmc_cs_set_timings(cs, t);
      
      .....
      	ret = gpmc_set_async_mode(gpmc_onenand_data->cs, &t);
      	if (IS_ERR_VALUE(ret))
      		return ret;
      
      So, gpmc_cs_set_timings() thinks any negative return value is an error,
      but where we check that in higher levels, only a limited range are
      errors...
      
      There is only _one_ use of IS_ERR_VALUE() in arch/arm which is really
      appropriate, and that is in arch/arm/include/asm/syscall.h:
      
      static inline long syscall_get_error(struct task_struct *task,
      				     struct pt_regs *regs)
      {
      	unsigned long error = regs->ARM_r0;
      	return IS_ERR_VALUE(error) ? error : 0;
      }
      
      because this function really does have to differentiate between error
      return values and addresses which look like negative numbers (eg, from
      mmap()).
      
      So, here's a patch to remove them from OMAP, except for the above.
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      71856843
  17. 05 3月, 2013 1 次提交
  18. 02 2月, 2013 4 次提交