1. 11 Dec, 2018 12 commits
  2. 06 Dec, 2018 1 commit
    • Rob Herring's avatar
      regulator: Use of_node_name_eq for node name comparisons · c32569e3
      Rob Herring authored
      Convert string compares of DT node names to use of_node_name_eq helper
      instead. This removes direct access to the node name pointer.
      
      For instances using of_node_cmp, this has the side effect of now using
      case sensitive comparisons. This should not matter for any FDT based
      system which all of these are.
      
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Support Opensource <support.opensource@diasemi.com>
      Cc: Sangbeom Kim <sbkim73@samsung.com>
      Cc: Krzysztof Kozlowski <krzk@kernel.org>
      Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Cc: linux-samsung-soc@vger.kernel.org
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Acked-by: default avatarAdam Thomson <Adam.Thomson.Opensource@diasemi.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      c32569e3
  3. 04 Dec, 2018 2 commits
  4. 03 Dec, 2018 1 commit
  5. 26 Nov, 2018 1 commit
    • Douglas Anderson's avatar
      regulator: core: Apply system load even if no consumer loads · fa94e48e
      Douglas Anderson authored
      Prior to commit 5451781d ("regulator: core: Only count load for
      enabled consumers") we used to always add up the total load on every
      enable in _regulator_enable().  After that commit we only updated the
      total load when enabling / disabling a regulator where a consumer
      specified a load or when changing the consumer load on an enabled
      regulator.
      
      The problem with the new scheme is that if there is a system load
      specified for a regulator but no consumers specify a load then we
      never account for it.
      
      Let's account for the system load in set_machine_constraints().
      
      NOTE: with the new scheme we end up with a bit of a quandry.  What if
      someone specifies _both_ an initial mode and a system load?  If we
      take the system load into account right at init time then it will
      effectively clobber the initial mode.  We'll resolve this by saying
      that if both are specified then the initial mode will win.  The system
      load will then only take effect if/when a consumer specifies a load.
      If no consumers ever specify a load then the initial mode will persist
      and the system load will have no effect.
      
      Fixes: 5451781d ("regulator: core: Only count load for enabled consumers")
      Reported-by: default avatarBrian Masney <masneyb@onstation.org>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Tested-by: default avatarBrian Masney <masneyb@onstation.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      fa94e48e
  6. 22 Nov, 2018 3 commits
    • Ryan Case's avatar
      spi: spi-qcom-qspi: Fix remaining driver nits · 478652f3
      Ryan Case authored
      Address remaining comments from original driver patch series
      
      * Move RD_FIFO_CFG to be ordered corretly
      * Expand spinlock comment
      Signed-off-by: default avatarRyan Case <ryandcase@chromium.org>
      Reviewed-by: default avatarStephen Boyd <swboyd@chromium.org>
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      478652f3
    • Douglas Anderson's avatar
      regulator: core: Avoid propagating to supplies when possible · 1fc12b05
      Douglas Anderson authored
      When we called regulator_enable() on a regulator we'd end up
      propagating that call all the way up the chain every time.  This is a
      bit of a waste of time.  A child regulator already refcounts its own
      enables so it should avoid passing on to its parent unless the
      refcount transitioned between 0 and 1.
      
      Historically this hasn't been a huge problem since we skipped dealing
      with enable for always-on regulators.  In a previous patch, however,
      we removed the always-on optimization.  On one system, the debugfs
      regulator_summary was now showing a "use_count" of 33 for a top-level
      regulator.
      
      Let's implement this optimization.  This turns out to be fairly
      trivial with the recent reorganization of the regulator core.
      
      NOTE: as part of this patch I'll make "always-on" regulators start
      with a use count of 1.  This keeps the counts clean when recursively
      resolving regulators.
      
      ALSO NOTE: this commit also contains somewhat of a bug fix to
      regulator_force_disable().  It was incorrectly looping over
      "rdev->open_count" when it should have been looping over use_count.
      We have to touch that code anyway (since we should no longer loop at
      all), so we'll fix it together in one patch.  Also: since this comes
      after commit f8702f9e ("regulator: core: Use ww_mutex for
      regulators locking") we can now move to use _regulator_disable() for
      our supply and keep it in the lock.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      1fc12b05
    • Douglas Anderson's avatar
      regulator: core: Only count load for enabled consumers · 5451781d
      Douglas Anderson authored
      In general when the consumer of a regulator requests that the
      regulator be disabled it no longer will be drawing much load from the
      regulator--it should just be the leakage current and that should be
      very close to 0.
      
      Up to this point the regulator framework has continued to count a
      consumer's load request for disabled regulators.  This has led to code
      patterns that look like this:
      
        enable_my_thing():
          regular_set_load(reg, load_uA)
          regulator_enable(reg)
      
        disable_my_thing():
          regulator_disable(reg)
          regulator_set_load(reg, 0)
      
      Sometimes disable_my_thing() sets a nominal (<= 100 uA) load instead
      of setting a 0 uA load.  I will make the assertion that nearly all (if
      not all) places where we set a nominal load of 100 uA or less we end
      up with a result that is the same as if we had set a load of 0 uA.
      Specifically:
      - The whole point of setting the load is to help set the operating
        mode of the regulator.  Higher loads may need less efficient
        operating modes.
      - The only time this matters at all is if there is another consumer of
        the regulator that wants the regulator on.  If there are no other
        consumers of the regulator then the regulator will turn off and we
        don't care about the operating mode.
      - If there's another consumer that actually wants the regulator on
        then presumably it is requesting a load that makes our nominal
        <= 100 uA load insignificant.
      
      A quick survey of the existing callers to regulator_set_load() to see
      how everyone uses it:
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      5451781d
  7. 21 Nov, 2018 1 commit
  8. 20 Nov, 2018 4 commits
  9. 19 Nov, 2018 5 commits
  10. 15 Nov, 2018 4 commits
  11. 14 Nov, 2018 3 commits
  12. 13 Nov, 2018 3 commits