1. 26 8月, 2022 2 次提交
    • D
      regulator: core: Don't err if allow-set-load but no allowed-modes · 57919f4a
      Douglas Anderson 提交于
      Apparently the device trees of some boards have the property
      "regulator-allow-set-load" for some of their regulators but then they
      don't specify anything for "regulator-allowed-modes". That's not
      really legit, but...
      
      ...before commit efb0cb50 ("regulator: qcom-rpmh: Implement
      get_optimum_mode(), not set_load()") they used to get away with it, at
      least on boards using RPMH regulators. That's because when a regulator
      driver implements set_load() then the core doesn't look at
      "regulator-allowed-modes" when trying to automatically adjust things
      in response to the regulator's load. The core doesn't know what mode
      we'll end up in, so how could it validate it?
      
      Said another way: before commit efb0cb50 ("regulator: qcom-rpmh:
      Implement get_optimum_mode(), not set_load()") some boards _were_
      having the regulator mode adjusted despite listing no allowed
      modes. After commit efb0cb50 ("regulator: qcom-rpmh: Implement
      get_optimum_mode(), not set_load()") these same boards were now
      getting an error returned when trying to use their regulators, since
      simply enabling a regulator tries to update its load and that was
      failing.
      
      We don't really want to go back to the behavior from before commit
      efb0cb50 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not
      set_load()"). Boards shouldn't have been changing modes if no allowed
      modes were listed. However, the behavior after commit efb0cb50
      ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()")
      isn't the best because now boards can't even turn their regulators on.
      
      Let's choose to detect this case and return "no error" from
      drms_uA_update(). The net-result will be _different_ behavior than we
      had before commit efb0cb50 ("regulator: qcom-rpmh: Implement
      get_optimum_mode(), not set_load()"), but this new behavior seems more
      correct. If a board truly needed the mode switched then its device
      tree should be updated to list the allowed modes.
      Reported-by: NAndrew Halaney <ahalaney@redhat.com>
      Fixes: efb0cb50 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()")
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Tested-by: NAndrew Halaney <ahalaney@redhat.com>
      Link: https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeidSigned-off-by: NMark Brown <broonie@kernel.org>
      57919f4a
    • D
      regulator: core: Require regulator drivers to check uV for get_optimum_mode() · 55841199
      Douglas Anderson 提交于
      The get_optimum_mode() for regulator drivers is passed the input
      voltage and output voltage as well as the current. This is because, in
      theory, the optimum mode can depend on all three things.
      
      It turns out that for all regulator drivers in mainline only the
      current is looked at when implementing get_optimum_mode(). None of the
      drivers take the input or output voltage into account. Despite the
      fact that none of the drivers take the input or output voltage into
      account, though, the regulator framework will error out before calling
      into get_optimum_mode() if it doesn't know the input or output
      voltage.
      
      The above behavior turned out to be a probelm for some boards when we
      landed commit efb0cb50 ("regulator: qcom-rpmh: Implement
      get_optimum_mode(), not set_load()"). Before that change we'd have no
      problems running drms_uA_update() for RPMH regulators even if a
      regulator's input or output voltage was unknown. After that change
      drms_uA_update() started to fail. This is because typically boards
      using RPMH regulators don't model the input supplies of RPMH
      regulators. Input supplies for RPMH regulators nearly always come from
      the output of other RPMH regulators (or always-on regulators) and RPMH
      firmware is initialized with this knowledge and handles enabling (and
      adjusting the voltage of) input supplies. While we could model the
      parent/child relationship of the regulators in Linux, many boards
      don't bother since it adds extra overhead.
      
      Let's change the regulator core to make things work again. Now if we
      fail to get the input or output voltage we'll still call into
      get_optimum_mode() and we'll just pass error codes in for input_uV
      and/or output_uV parameters.
      
      Since no existing regulator drivers even look at input_uV and
      output_uV we don't need to add this error handling anywhere right
      now. We'll add some comments in the core so that it's obvious that (if
      regulator drivers care) it's up to them to add the checks.
      Reported-by: NAndrew Halaney <ahalaney@redhat.com>
      Fixes: efb0cb50 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()")
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Tested-by: NAndrew Halaney <ahalaney@redhat.com>
      Link: https://lore.kernel.org/r/20220824142229.RFT.v2.1.I137e6bef4f6d517be7b081be926059321102fd3d@changeidSigned-off-by: NMark Brown <broonie@kernel.org>
      55841199
  2. 25 8月, 2022 1 次提交
  3. 24 8月, 2022 11 次提交
  4. 22 8月, 2022 1 次提交
  5. 18 8月, 2022 2 次提交
  6. 15 8月, 2022 1 次提交
  7. 10 8月, 2022 1 次提交
  8. 27 7月, 2022 3 次提交
  9. 20 7月, 2022 1 次提交
  10. 15 7月, 2022 2 次提交
  11. 11 7月, 2022 4 次提交
  12. 07 7月, 2022 1 次提交
  13. 06 7月, 2022 1 次提交
  14. 05 7月, 2022 1 次提交
  15. 30 6月, 2022 1 次提交
  16. 29 6月, 2022 4 次提交
  17. 23 6月, 2022 2 次提交
  18. 13 6月, 2022 1 次提交
新手
引导
客服 返回
顶部