1. 01 12月, 2020 8 次提交
  2. 30 11月, 2020 2 次提交
  3. 26 11月, 2020 3 次提交
  4. 25 11月, 2020 1 次提交
  5. 24 11月, 2020 6 次提交
    • C
      regulator: add SCMI driver · 0fbeae70
      Cristian Marussi 提交于
      Add a simple regulator based on SCMI Voltage Domain Protocol.
      Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
      ----
      v6 --> v7
      - add proper blank lines between semantic blocks
      - fix return value on error path of scmi_reg_is_enabled()
      - use generic Failure message on err path of info_get()
      - fix comment containing apostrophe
      
      v3 --> v4
      - using of_match_full_name core regulator flag
      - avoid coccinelle falde complaints about pointer-sized allocations
      
      v2 --> v3
      - remove multiple linear mappings support
      - removed duplicated voltage name printout
      - added a few comments
      - simplified return path in scmi_reg_set_voltage_sel()
      
      v1 --> v2
      - removed duplicate regulator naming
      - removed redundant .get/set_voltage ops: only _sel variants implemented
      - removed condexpr on fail path to increase readability
      
      v0 --> v1
      - fixed init_data constraint parsing
      - fixes for v5.8 (linear_range.h)
      - fixed commit message content and subject line format
      - factored out SCMI core specific changes to distinct patch
      - reworked Kconfig and Makefile to keep proper alphabetic order
      - fixed SPDX comment style
      - removed unneeded inline functions
      - reworked conditionals for legibility
      - fixed some return paths to properly report SCMI original errors codes
      - added some more descriptive error messages when fw returns invalid ranges
      - removed unneeded explicit devm_regulator_unregister from .remove()
      Link: https://lore.kernel.org/r/20201123202336.46701-4-cristian.marussi@arm.comSigned-off-by: NMark Brown <broonie@kernel.org>
      0fbeae70
    • C
      dt-bindings: arm: remove optional properties for SCMI Regulators · e8056bf0
      Cristian Marussi 提交于
      Remove optional properties bindings descriptions for SCMI Regulators.
      Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
      Link: https://lore.kernel.org/r/20201123202336.46701-2-cristian.marussi@arm.comSigned-off-by: NMark Brown <broonie@kernel.org>
      e8056bf0
    • M
      Merge series "Add support for SCMIv3.0 Voltage Domain Protocol and... · 5d16a4f9
      Mark Brown 提交于
      Merge series "Add support for SCMIv3.0 Voltage Domain Protocol and SCMI-Regulator" from Cristian Marussi <cristian.marussi@arm.com>:
      
      Hi,
      
      this series introduces the support for the new SCMI Voltage Domain Protocol
      defined by the upcoming SCMIv3.0 specification, whose BETA release is
      available at [1].
      
      Afterwards, a new generic SCMI Regulator driver is developed on top of the
      new SCMI VD Protocol.
      
      In V4 Patch 3/5 introduced a needed fix in Regulator framework to cope with
      generic named nodes.
      
      The series is currently based on for-next/scmi [2] on top of:
      
      commit b141fca08207 ("firmware: arm_scmi: Fix missing destroy_workqueue()")
      
      Any feedback welcome,
      
      Thanks,
      
      Cristian
      
      ---
      v5 --> v6
      - reordered dt bindings patch
      - removed single field struct
      - reviewed args to scmi_init_voltage_levels()
      - allocating scmi_voltage_info_array contiguously
      
      v4 --> v5
      - rebased
      - VD Protocol
       - removed inline
       - moved segmented intervals defines
       - fixed some macros complaints by checkpatch
      
      v3 --> v4
      - DT bindings
       - using generic node names
       - listing explicitly subset of supported regulators bindings
      - SCMI Regulator
       - using of_match_full_name core regulator flag
       - avoid coccinelle false flag complaints
      - VD Protocol
       - avoid coccinelle false flag complaints
       - avoiding fixed size typing
      
      v2 --> v3
      - DT bindings
        - avoid awkard examples based on _cpu/_gpu regulators
      - SCMI Regulator
        - remove multiple linear mappings support
        - removed duplicated voltage name printout
        - added a few comments
        - simplified return path in scmi_reg_set_voltage_sel()
      - VD Protocol
        - restrict segmented voltage domain descriptors to one triplet
        - removed unneeded inline
        - free allocated resources for invalid voltage domain
        - added __must_check to info_get voltage operations
        - added a few comments
        - removed fixed size typing from struct voltage_info
      
      v1 --> v2
      - rebased on for-next/scmi v5.10
      - DT bindings
        - removed any reference to negative voltages
      - SCMI Regulator
        - removed duplicate regulator naming
        - removed redundant .get/set_voltage ops: only _sel variants implemented
        - removed condexpr on fail path to increase readability
      - VD Protocol
        - fix voltage levels query loop to reload full cmd description
          between iterations as reported by Etienne Carriere
        - ensure transport rx buffer is properly sized calli scmi_reset_rx_to_maxsz
          between transfers
      
      [1]:https://developer.arm.com/documentation/den0056/c/
      [2]:https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/log/?h=for-next/scmi
      
      Cristian Marussi (5):
        firmware: arm_scmi: Add Voltage Domain Support
        firmware: arm_scmi: add SCMI Voltage Domain devname
        regulator: core: add of_match_full_name boolean flag
        dt-bindings: arm: add support for SCMI Regulators
        regulator: add SCMI driver
      
       .../devicetree/bindings/arm/arm,scmi.txt      |  43 ++
       drivers/firmware/arm_scmi/Makefile            |   2 +-
       drivers/firmware/arm_scmi/common.h            |   1 +
       drivers/firmware/arm_scmi/driver.c            |   3 +
       drivers/firmware/arm_scmi/voltage.c           | 380 ++++++++++++++++
       drivers/regulator/Kconfig                     |   9 +
       drivers/regulator/Makefile                    |   1 +
       drivers/regulator/of_regulator.c              |   8 +-
       drivers/regulator/scmi-regulator.c            | 409 ++++++++++++++++++
       include/linux/regulator/driver.h              |   3 +
       include/linux/scmi_protocol.h                 |  64 +++
       11 files changed, 920 insertions(+), 3 deletions(-)
       create mode 100644 drivers/firmware/arm_scmi/voltage.c
       create mode 100644 drivers/regulator/scmi-regulator.c
      
      --
      2.17.1
      
      _______________________________________________
      linux-arm-kernel mailing list
      linux-arm-kernel@lists.infradead.org
      http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
      5d16a4f9
    • G
      regulator: as3722: Fix fall-through warnings for Clang · b52b417c
      Gustavo A. R. Silva 提交于
      In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
      by explicitly adding a fallthrough pseudo-keyword instead of letting the
      code fall through to the next case.
      
      Link: https://github.com/KSPP/linux/issues/115Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
      Link: https://lore.kernel.org/r/c0efb81064f71837f19408f65b52d155103ee514.1605896059.git.gustavoars@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>
      b52b417c
    • C
      regulator: core: add of_match_full_name boolean flag · e7095c35
      Cristian Marussi 提交于
      During regulators registration, if .of_match and .regulators_node are
      defined as non-null strings in struct regulator_desc the core searches the
      DT subtree rooted at .regulators_node trying to match, at first, .of_match
      against the 'regulator-compatible' property and, then, falling back to use
      the name of the node itself to determine a good match.
      
      Property 'regulator-compatible', though, is now deprecated and falling back
      to match against the node name, works fine only as long as the involved
      nodes are named in an unique way across the searched subtree; if that's not
      the case, like when using <common-name>@<unit> style naming for properties
      indexed via 'reg' property (as advised by the standard), the above matching
      mechanism based on the simple common name will lead to multiple matches and
      the only viable alternative would be to properly define the now deprecated
      'regulator-compatible' as the node full name, i.e. <common-name>@<unit>.
      
      In order to address this case without using such deprecated binding, define
      a new boolean flag .of_match_full_name in struct regulator_desc to force
      the core to match against the node full-name instead of the plain name.
      Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
      Link: https://lore.kernel.org/r/20201119191051.46363-4-cristian.marussi@arm.comSigned-off-by: NMark Brown <broonie@kernel.org>
      e7095c35
    • M
      Merge tag 'scmi-voltage-5.11' of... · ce10f6ca
      Mark Brown 提交于
      Merge tag 'scmi-voltage-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into regulator-5.11
      
      SCMI voltage domain management protocol support for v5.11
      
      SCMI v3.0 voltage domain protocol support to discover the voltage levels
      supported by the domains and to set/get the configuration and voltage
      level of any given domain.
      ce10f6ca
  6. 20 11月, 2020 3 次提交
  7. 14 11月, 2020 8 次提交
  8. 11 11月, 2020 6 次提交
    • M
      Merge branch 'for-5.10' of... · 811c732f
      Mark Brown 提交于
      Merge branch 'for-5.10' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-5.11
      811c732f
    • M
      Merge series "regulator: bd718x7: support voltage scaling" from Matti... · 51c0a0c6
      Mark Brown 提交于
      Merge series "regulator: bd718x7: support voltage scaling" from Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>:
      
      RFC for adding a support for typical voltage scaling connection
      
      In few occasions there has been a need to scale the voltage output
      from bucks on BD71837. Usually this is done when buck8 is used to
      power specific GPU which can utilize voltages down to 0.7V. As lowest
      the buck8 on BD71837 can go is 0.8V, and external connection is used to
      scale the voltages.
      
      The BD71837, BD71847 and BD71850 bucks can be adjusted by pulling up the
      feedback pin using suitable voltage/resistors.
      
      	|---------------|
      	|       buck 8  |-------+----->Vout
      	|               |       |
      	|---------------|       |
      	       |                |
      	       |                |
      	       +-------+--R2----+
      	               |
      	               R1
      	               |
      	       V FB-pull-up
      
      This will scale the voltage as follows:
       - Vout_o = Vo - (Vpu - Vo)*R2/R1
       - Linear_step = step_orig*(R1+R2)/R1
      where:
      Vout_o is adjusted voltage output at vsel reg value 0
      Vo is original voltage output at vsel reg value 0
      Vpu is the pull-up voltage V FB-pull-up in the picture
      R1 and R2 are resistor values.
      
      >From HW point of view this does not need to be limited to buck 8. This
      connection can be used to adjust output from any of the bucks on
      BD71837/47/50.
      
      As this seems to be a 'de-facto' way to scale the voltages on BD71837 it
      might be a good idea to support computing the new voltage ranges for
      bucks based on the V-pull-up and resistor R1/R2 values given from
      device-tree. This allows describing the external HW connection using DT
      to correctly scale the voltages.
      
      This RFC uses "rohm,feedback-pull-up-r1-ohms" and
      "rohm,feedback-pull-up-r2-ohms" to provide the resistor values - but
      these names (without the picture) might not be too descriptive. I am
      grateful for all suggestions as better and more descriptive names.
      
      This patch series is an RFC because this connection feels somewhat
      "hacky". OTOH - when hack becomes widely used, it is less of an hack and
      more of a standard - and occasionally supporting HW hacks using SW may
      benefit us all, right? :)
      
      The other thing some projects do is allowing the change of BD71837 buck8
      voltages when buck8 is enabled. This however will introduce voltage
      spikes as buck8 was not originally designed for this. The specific HW
      platform must be evaluated to be able to tolerate these spikes. Thus
      this patch series does not support buck8 voltage changes when buck8 is
      enabled. I wonder if this should be allowed per some config option(?) I
      don't want to help people frying their boards... Opinions? Is there
      suggested way of allowing this type of features at own risk? Config or
      even Some #ifdef which is not listed in Kconfig? Device-tree property?
       If you have (good) suggestions I could add the optional (non default)
      DVS support for non DVS bucks on BD71837.
      
      Matti Vaittinen (3):
        dt-bindings: regulator: BD71837 support commonly used feedback
          connection
        dt-bindings: regulator: BD71847 support commonly used feedback
          connection
        regulator: bd718x7: Support external connection to scale voltages
      
       .../regulator/rohm,bd71837-regulator.yaml     |  48 +++++
       .../regulator/rohm,bd71847-regulator.yaml     |  49 ++++++
       drivers/regulator/bd718x7-regulator.c         | 164 +++++++++++++++++-
       3 files changed, 254 insertions(+), 7 deletions(-)
      
      base-commit: 3cea11cd
      --
      2.21.3
      
      --
      Matti Vaittinen, Linux device drivers
      ROHM Semiconductors, Finland SWDC
      Kiviharjunlenkki 1E
      90220 OULU
      FINLAND
      
      ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
      Simon says - in Latin please.
      ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
      Thanks to Simon Glass for the translation =]
      51c0a0c6
    • M
      regulator: bd718x7: Support external connection to scale voltages · d2ad9811
      Matti Vaittinen 提交于
      Setups where regulator (especially the buck8) output voltage is scaled
      by adding external connection where some other regulator output is
      connected to feedback-pin (over suitable resistors) is getting popular
      amongst users of BD71837. This allows for example scaling down the
      buck8 voltages to suit lover GPU voltages for projects where buck8 is
      (ab)used to supply power for GPU. As a note - some setups do allow DVS
      for buck8. This do produce voltage spikes and the HW must be evaluated
      to be able to survive them. Thus this commit still keep the DVS disabled
      for non DVS bucks by default. Let's not help you burn your proto board.
      
      Allow describing this external connection from DT and scale the
      voltages accordingly. This is what the connection should look like:
      
      |------------|
      |    buck 8  |-------+----->Vout
      |            |       |
      |------------|       |
           | FB pin        |
           |               |
           +-------+--R2---+
                   |
                   R1
                   |
           V FB-pull-up
      
           Here the buck output is sifted according to formula:
      
      Vout_o = Vo - (Vpu - Vo)*R2/R1
      Linear_step = step_orig*(R1+R2)/R1
      
      where:
      Vout_o is adjusted voltage output at vsel reg value 0
      Vo is original voltage output at vsel reg value 0
      Vpu is the pull-up voltage V FB-pull-up in the picture
      R1 and R2 are resistor values.
      
      Bring support for specifying the Vpu, R1 and R2 from device tree and
      scale voltages if they are given.
      Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
      Link: https://lore.kernel.org/r/89b2be87074f307a8823f15f34e1f662023cbf36.1604994184.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by: NMark Brown <broonie@kernel.org>
      d2ad9811
    • M
      regulator: BD71847 support commonly used feedback connection · b54a27d8
      Matti Vaittinen 提交于
      The BD71847 buck output voltages are in a few cases scaled using external
      connection which adds a pull-up to regulator feedback pin. This connection
      will adjust output voltage from regulator in a deterministic way.
      
      Add support for describing this HW connection so that driver can adjust
      voltage ranges accordingly.
      Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
      Link: https://lore.kernel.org/r/9b6b3d8233071d478f7d1e93b498f5a2141941e6.1604994184.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by: NMark Brown <broonie@kernel.org>
      b54a27d8
    • M
      regulator: BD71837 support commonly used feedback connection · 1e908b24
      Matti Vaittinen 提交于
      The BD71837 buck output voltages are in a few cases scaled using external
      connection which adds a pull-up to regulator feedback pin. This connection
      will adjust output voltage from regulator in a deterministic way.
      
      Add support for describing this HW connection so that driver can adjust
      voltage ranges accordingly.
      Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
      Link: https://lore.kernel.org/r/9959924313db7c7165598604f9a07bf227f471a8.1604994184.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by: NMark Brown <broonie@kernel.org>
      1e908b24
    • P
      regulator: core: don't disable regulator if is_enabled return error. · c088a498
      Pi-Hsun Shih 提交于
      In regulator_late_cleanup when is_enabled failed, don't try to disable
      the regulator since it would likely to fail too and causing confusing
      error messages.
      Signed-off-by: NPi-Hsun Shih <pihsun@chromium.org>
      Link: https://lore.kernel.org/r/20201106064817.3290927-1-pihsun@chromium.orgSigned-off-by: NMark Brown <broonie@kernel.org>
      c088a498
  9. 10 11月, 2020 1 次提交
  10. 03 11月, 2020 2 次提交