1. 27 12月, 2017 1 次提交
  2. 07 12月, 2017 1 次提交
  3. 10 11月, 2017 1 次提交
  4. 30 10月, 2017 1 次提交
  5. 25 10月, 2017 1 次提交
  6. 18 10月, 2017 2 次提交
  7. 07 10月, 2017 1 次提交
  8. 22 9月, 2017 1 次提交
  9. 20 9月, 2017 1 次提交
  10. 05 9月, 2017 1 次提交
  11. 23 8月, 2017 4 次提交
  12. 23 6月, 2017 2 次提交
    • T
      dt-bindings: gpmc: Correct location of generic gpmc binding · a7adb70a
      Tom Rini 提交于
      The binding bus/ti-gpmc.txt has been moved to
      memory-controllers/omap-gpmc.txt.  Update all references to this in
      order to make reading and understanding a given binding easier.
      
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Brian Norris <computersforpeace@gmail.com>
      Cc:Boris Brezillon <boris.brezillon@free-electrons.com>
      Cc: Marek Vasut <marek.vasut@gmail.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: NTom Rini <trini@konsulko.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      a7adb70a
    • T
      dt-bindings: mtd: elm: Correct compatible string requirement · fe496e23
      Tom Rini 提交于
      The binding says that the compatible string must be "ti,am33xx-elm"
      but the code checks only for, and all functioning users set, this as
      "ti,am3352-elm" so correct the binding.
      
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Brian Norris <computersforpeace@gmail.com>
      Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
      Cc: Marek Vasut <marek.vasut@gmail.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: NTom Rini <trini@konsulko.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      fe496e23
  13. 21 6月, 2017 1 次提交
  14. 10 6月, 2017 2 次提交
    • M
      mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants · 91300dd6
      Masahiro Yamada 提交于
      Add two compatible strings for UniPhier SoC family.
      
      "socionext,uniphier-denali-nand-v5a" is used on UniPhier sLD3, LD4,
      Pro4, sLD8.
      
      "socionext,uniphier-denali-nand-v5b" is used on UniPhier Pro5, PXs2,
      LD6b, LD11, LD20.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      91300dd6
    • M
      mtd: nand: denali: avoid hard-coding ECC step, strength, bytes · 7de117fd
      Masahiro Yamada 提交于
      This driver was originally written for the Intel MRST platform with
      several platform-specific parameters hard-coded.
      
      Currently, the ECC settings are hard-coded as follows:
      
        #define ECC_SECTOR_SIZE 512
        #define ECC_8BITS       14
        #define ECC_15BITS      26
      
      Therefore, the driver can only support two cases.
       - ecc.size = 512, ecc.strength = 8    --> ecc.bytes = 14
       - ecc.size = 512, ecc.strength = 15   --> ecc.bytes = 26
      
      However, these are actually customizable parameters, for example,
      UniPhier platform supports the following:
      
       - ecc.size = 1024, ecc.strength = 8   --> ecc.bytes = 14
       - ecc.size = 1024, ecc.strength = 16  --> ecc.bytes = 28
       - ecc.size = 1024, ecc.strength = 24  --> ecc.bytes = 42
      
      So, we need to handle the ECC parameters in a more generic manner.
      Fortunately, the Denali User's Guide explains how to calculate the
      ecc.bytes.  The formula is:
      
        ecc.bytes = 2 * CEIL(13 * ecc.strength / 16)  (for ecc.size = 512)
        ecc.bytes = 2 * CEIL(14 * ecc.strength / 16)  (for ecc.size = 1024)
      
      For DT platforms, it would be reasonable to allow DT to specify ECC
      strength by either "nand-ecc-strength" or "nand-ecc-maximize".  If
      none of them is specified, the driver will try to meet the chip's ECC
      requirement.
      
      For PCI platforms, the max ECC strength is used to keep the original
      behavior.
      
      Newer versions of this IP need ecc.size and ecc.steps explicitly
      set up via the following registers:
        CFG_DATA_BLOCK_SIZE       (0x6b0)
        CFG_LAST_DATA_BLOCK_SIZE  (0x6c0)
        CFG_NUM_DATA_BLOCKS       (0x6d0)
      
      For older IP versions, write accesses to these registers are just
      ignored.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      7de117fd
  15. 09 6月, 2017 1 次提交
  16. 02 6月, 2017 1 次提交
  17. 01 6月, 2017 2 次提交
  18. 31 5月, 2017 1 次提交
  19. 15 5月, 2017 1 次提交
  20. 11 5月, 2017 1 次提交
  21. 02 5月, 2017 1 次提交
  22. 25 4月, 2017 3 次提交
  23. 24 3月, 2017 1 次提交
  24. 11 2月, 2017 1 次提交
  25. 10 2月, 2017 3 次提交
  26. 09 2月, 2017 1 次提交
  27. 03 1月, 2017 1 次提交
  28. 07 11月, 2016 2 次提交