1. 05 2月, 2015 1 次提交
  2. 19 11月, 2014 1 次提交
  3. 20 10月, 2014 6 次提交
  4. 13 10月, 2014 1 次提交
  5. 30 9月, 2014 1 次提交
  6. 28 9月, 2014 2 次提交
  7. 27 9月, 2014 1 次提交
  8. 19 9月, 2014 1 次提交
  9. 17 9月, 2014 1 次提交
  10. 12 9月, 2014 1 次提交
  11. 08 9月, 2014 1 次提交
  12. 31 8月, 2014 1 次提交
  13. 28 8月, 2014 1 次提交
    • G
      regmap: Split regmap_get_endian() in two functions · cf673fbc
      Geert Uytterhoeven 提交于
      Split regmap_get_endian() in two functions, regmap_get_reg_endian() and
      regmap_get_val_endian().
      
      This allows to:
        - Get rid of the three switch()es on "type", incl. error handling in
          three "default" cases,
        - Get rid of the regmap_endian_type enum,
        - Get rid of the non-NULL check of "config" (regmap_init() already
          checks for that),
        - Get rid of the "endian" output parameters, and just return the
          regmap_endian enum value, as the functions can no longer fail.
      
      This saves 21 lines of code (despite the still-present
      one-comment-per-line over-documentation), and 30 bytes of code on ARM
      V7.
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      cf673fbc
  14. 27 8月, 2014 1 次提交
    • M
      regmap: Fix handling of volatile registers for format_write() chips · 5844a8b9
      Mark Brown 提交于
      A previous over-zealous factorisation of code means that we only treat
      registers as volatile if they are readable. For most devices this is fine
      since normally most registers can be read and volatility implies
      readability but for format_write() devices where there is no readback from
      the hardware and we use volatility to mean simply uncacheability this means
      that we end up treating all registers as cacheble.
      
      A bigger refactoring of the code to clarify this is in order but as a fix
      make a minimal change and only check readability when checking volatility
      if there is no format_write() operation defined for the device.
      Signed-off-by: NMark Brown <broonie@linaro.org>
      Tested-by: NLars-Peter Clausen <lars@metafoo.de>
      Cc: stable@vger.kernel.org
      5844a8b9
  15. 26 8月, 2014 1 次提交
    • L
      regmap: Fix regcache debugfs initialization · 5e0cbe78
      Lars-Peter Clausen 提交于
      Commit 6cfec04b ("regmap: Separate regmap dev initialization") moved the
      regmap debugfs initialization after regcache initialization. This means
      that the regmap debugfs directory is not created yet when the cache
      initialization runs and so any debugfs files registered by the regcache are
      created in the debugfs root directory rather than the debugfs directory of
      the regmap instance. Fix this by adding a separate callback for the
      regcache debugfs initialization which will be called after the parent
      debugfs entry has been created.
      
      Fixes: 6cfec04b (regmap: Separate regmap dev initialization)
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      Cc: stable@vger.kernel.org
      5e0cbe78
  16. 20 8月, 2014 1 次提交
    • S
      regmap: of_regmap_get_endian() cleanup · 45e1a279
      Stephen Warren 提交于
      Commit d647c199 ("regmap: add DT endianness binding support") had
      some issues. Commit ba1b53fe ("regmap: Fix DT endianess parsing
      logic") fixed the main problem. This patch fixes the other.
      
      Specifically, restore the overall default of REGMAP_ENDIAN_BIG if none of
      the config, DT, or the bus specify any endianness. Without this,
      of_regmap_get_endian() could return REGMAP_ENDIAN_DEFAULT, which the
      calling code can't handle. Since all busses do specify an endianness in
      the current code, this makes no difference right now, but I saw no
      justification in the patch description for removing this final default.
      
      Also, clean up the code a bit:
      
      * s/of_regmap_get_endian/regmap_get_endian/ since the function isn't DT-
        specific, even if the reason it was originally added was to add some
        DT-specific features.
      * After potentially reading an endianess specification from DT, the code
        checks whether DT did specify an endianness, and if so, returns it. Move
        this test outside the whole switch statement so that if the
        REGMAP_ENDIAN_REG case ever modifies *endian, this check will pick that
        up. This partially reverts part of commit ba1b53fe ("regmap: Fix DT
        endianess parsing logic"), while maintaining the bug-fix that commit
        made to this code.
      * Make the comments briefer, and only refer to the specific action taken
        at their location. This makes most of the comments independent of DT,
        and easier to follow.
      
      Cc: Xiubo Li <Li.Xiubo@freescale.com>
      Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
      Cc: Thierry Reding <treding@nvidia.com>
      Fixes: d647c199 ("regmap: add DT endianness binding support")
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      45e1a279
  17. 19 8月, 2014 1 次提交
    • J
      regmap: Fix DT endianess parsing logic · ba1b53fe
      Javier Martinez Canillas 提交于
      Commit d647c199 ("regmap: add DT endianness binding support.")
      added support to parse the device endianness from the device tree
      but unfortunately the added logic doesn't have the same semantics
      than the old code. This leads to a NULL dereference pointer error
      when these properties are not provided by the Device Tree:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000044
      pgd = c0004000
      [00000044] *pgd=00000000
      Internal error: Oops: 5 [#1] PREEMPT SMP ARM
      Modules linked in:
      CPU: 5 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc1-next-20140818ccu #671
      task: ea412800 ti: ea484000 task.ti: ea484000
      PC is at regmap_update_bits+0xc/0x5c
      
      The problem is that platforms that rely on the default value now
      gets different values due two related issues in the current code:
      
      a) It only parses the endianness from DT for the regmap registers
         and not for the regmap values but it checks unconditionally in
         both cases if the resulting endiannes is REGMAP_ENDIAN_NATIVE.
      
      b) REGMAP_ENDIAN_NATIVE is not even a valid DT property according
         to the regmap DT binding documentation so it shouldn't be set.
      Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      ba1b53fe
  18. 17 8月, 2014 2 次提交
    • G
      regmap: Add explicit dependencies to catch "select" misuse · 9ba1e456
      Geert Uytterhoeven 提交于
      Add explicit dependencies for the various regmap modules, so Kconfig
      will print a warning message when another module selects a regmap module
      without fulfilling its dependencies.
      
      Without this, it's much more difficult to find out which module did the
      offending select.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      9ba1e456
    • X
      regmap: add DT endianness binding support. · d647c199
      Xiubo Li 提交于
      For many drivers which will support rich endianness of Devices
      need define DT properties by itself with the binding support.
      
      The endianness using regmap:
      Index      Device     Properties if needs bytes-swap,
                            or just ignore it
      -------------------------------------------------------------
      1          BE         'big-endian'
      2          LE         'little-endian'
      
      The properties include all the register values and the buffers.
      And these properties are very usful for the MMIO devices:
      
      Such as: a memory-mapped device, on one SoC is in BE mode, while
      in another SoC will be in LE mode, and the CPU will always in LE
      mode.
      
      For the first case, we must use cpu_to_be32/be32_to_cpu for
      32-bit registers accessing, so the 'big-endian' property is needed.
      
      For the second case, we can just ignore the bytes-swap
      functions like cpu_to_le32/le32_to_cpu, so the 'little-endian'
      property could be abscent.
      
      And vice versa...
      Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      d647c199
  19. 26 7月, 2014 2 次提交
  20. 26 5月, 2014 2 次提交
  21. 01 5月, 2014 2 次提交
  22. 22 4月, 2014 1 次提交
  23. 18 4月, 2014 1 次提交
  24. 14 4月, 2014 3 次提交
  25. 01 4月, 2014 1 次提交
  26. 28 3月, 2014 1 次提交
  27. 27 3月, 2014 2 次提交