Skip to content

PM / OPP: Parse opp-supported-hw/opp-<prop>-<name> bindings

Viresh Kumar linux-pm lkml 3 versions – In review

Get series with b4
b4 am [email protected]

Versions newest first · linked by author and title

  1. v3 Latest2 patches 6 repliesIn review
  2. v23 patches 11 repliesApplied
  3. v13 patches 7 repliesSuperseded

Changes in v3 from the cover letter

- Stephen had an interesting point to make for V2, as the patches created the dev_opp first and then updated it within the OPP-list lock. But a simultaneous reader of the dev_opp list need a rcu way of handling this.
- The big difference, why its not a problem here, is that the platform needs to call this routine before the OPPs are parsed from DT and the opp-list will be empty. And so no-readers.
- It wasn't guaranteed earlier, but now we have installed few WARN_ON() to make sure about that there are no OPPs while these routines are called.
- It should be pretty safe to get these merged now.
- Lee's work depends on this to be merged,
http://marc.info/?l=linux-kernel&m=144958553611215&w=2

Patches in v3 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/2PM / OPP: Parse 'opp-supported-hw' bindingdrivers/base/power/opp/core.c drivers/base/power/opp/opp.h include/linux/pm_opp.h+166 -01 reply
2/2PM / OPP: Parse 'opp-<prop>-<name>' bindingsdrivers/base/power/opp/core.c drivers/base/power/opp/opp.h include/linux/pm_opp.h+161 -155 replies

Reviews trailers per patch

None of the 2 patches has a Reviewed-by or Acked-by.

PatchLee Jones
1/2T-b
2/2T-b

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v3 thread

Cover letter [PATCH V3 0/2] PM / OPP: Parse opp-supported-hw/opp-<prop>-<name> bindings

Hi Rafael,

These patches parse the newly added opp-supported-hw/opp-<prop>-<name> bindings.

Rebased over: Latest pm/linux-next
Tested-on: Exynos 5250, dual core A15.

V2->V3:
- Stephen had an interesting point to make for V2, as the patches created the dev_opp first and then updated it within the OPP-list lock. But a simultaneous reader of the dev_opp list need a rcu way of handling this.
- The big difference, why its not a problem here, is that the platform needs to call this routine before the OPPs are parsed from DT and the opp-list will be empty. And so no-readers.
- It wasn't guaranteed earlier, but now we have installed few WARN_ON() to make sure about that there are no OPPs while these routines are called.
- It should be pretty safe to get these merged now.
- Lee's work depends on this to be merged,
http://marc.info/?l=linux-kernel&m=144958553611215&w=2

V1->V2:
- Fixed locking
- NUL terminate strings instead of sprintf
- Remove NULL checkers for the routines
- constify 'versions'
- s/EINVAL/EBUSY
- updated comments over routines
- Use of_property_read_u32_index() instead of allocating arrays
- remove dev_opp for failures

Viresh Kumar (2):
PM / OPP: Parse 'opp-supported-hw' binding
PM / OPP: Parse 'opp-<prop>-<name>' bindings

 drivers/base/power/opp/core.c | 313 ++++++++++++++++++++++++++++++++++++++++--
 drivers/base/power/opp/opp.h  |   7 +
 include/linux/pm_opp.h        |  22 +++
 3 files changed, 327 insertions(+), 15 deletions(-)
Signature · 1 line
2.6.2.198.g614a2ac

Read the cover letter in its thread