[PATCH v3 0/7] Fix BWMONv4 for <SDM845

[Konrad Dybcio]

v2 -> v3:
- Rename: "DDR BWMON" -> "CPU BWMON" [2, 6/7]
- Set F_IRQ_STATUS = F_NUM_GLOBAL_FIELDS in enum bwmon_fields to save
  one space in the enum
- Correct the struct icc_bwmon->global_regs array size
- Reorder the "Remove unused struct member" patch to come before the big
  one

v2: https://lore.kernel.org/r/20230304-topic-ddr_bwmon-v2-0-04db989db059@xxxxxxxxxx

v1 -> v2:
- Un-mess-up the example in bindings
- Correctly limit reg/-names in bindings
- Introduce "qcom,sdm845-cpu-bwmon"
- Fix incorrect register assignment in msm8998_bwmon_reg_noread_ranges
- Clean up the code around setting global registers on <=8998
  - Don't add a separate enum for global registers
  - Don't use _GLOBAL vs _GLB
  - Add of match entries for targets that abused qcom,msm8998-bwmon before
    to keep old DTs working
  - Add comments near of match entries to make things clearer
  - Instead of if (...) { write to x } else { write to y } make the global
    register variable to keep the code more readable
- Add dts patches to stop improperly using the 8998 compatible
- (grumpily) drop Fixes from [2/7]
- Pick up rb on [3/7]
- Re-test on MSM8998 and SM6375 (OOT, uses 845-style BWMONv4)

v1: https://lore.kernel.org/r/20230304-topic-ddr_bwmon-v1-0-e563837dc7d1@xxxxxxxxxx

BWMONv4 (the one used for DDR scaling on all SoCs from msm8998 to sm8550)
features two register regions: "monitor" and "global" with the first one
containing registers specific to the throughput monitor itself and the
second one containing some sort of a head switch.

The register layout on all BWMON versions an implementations up to that
looked like this:

|..........[GLOBAL].........[MONITOR]........|

however with SDM845 somebody thought it would be a good idea to turn it
into this:

|................[GLOBAL]....................|
|....................[MONITOR]...............|

Sadly, the existing upstream driver was architected with SDM845 in mind,
which means it doesn't support the global registers being somewhere else
than near the beginning of the monitor space. This series tries to address
that in the hopefully least painful way. Tested on msm8998 (the count unit
seems to be wrong, should probably be 1MiB and not 64 KiB but the point is
that this series makes it work at all, as without it the headswitch is
never turned on) and SM6375 (with the "combined" layout introduced in
SDM845). Equally sadly, everybody uses the qcom,msm8998-bwmon compatible
(which frankly should have been just qcom,bwmon-v4) that never actually
worked on MSM8998 , which prevents us from handling it in a simpler way..

While at it, an unused struct member is removed.

One suboptimal feature of this patchset is that it introduces an "invalid
resource" print from within devres. This could be solved with an
introduction of devm_ioremap_resource_optional or by dropping devres
functions in place of manual handling, which also doesn't sound great..
I'll leave it up to the reviewers to decide.

Signed-off-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>
---
Konrad Dybcio (7):
      dt-bindings: interconnect: qcom,msm8998-bwmon: Resolve MSM8998 support
      soc: qcom: icc-bwmon: Remove unused struct member
      soc: qcom: icc-bwmon: Handle global registers correctly
      arm64: dts: qcom: sc7280: Use the correct BWMON fallback compatible
      arm64: dts: qcom: sc8280xp: Use the correct BWMON fallback compatible
      arm64: dts: qcom: sdm845: Use the correct BWMON compatible
      arm64: dts: qcom: sm8550: Use the correct BWMON fallback compatible

 .../bindings/interconnect/qcom,msm8998-bwmon.yaml  |  41 +++-
 arch/arm64/boot/dts/qcom/sc7280.dtsi               |   2 +-
 arch/arm64/boot/dts/qcom/sc8280xp.dtsi             |   2 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi               |   2 +-
 arch/arm64/boot/dts/qcom/sm8550.dtsi               |   2 +-
 drivers/soc/qcom/icc-bwmon.c                       | 231 +++++++++++++++++++--
 6 files changed, 247 insertions(+), 33 deletions(-)
---
base-commit: 24469a0e5052ba01a35a15f104717a82b7a4798b
change-id: 20230304-topic-ddr_bwmon-609022cd5e35

Best regards,
-- 
Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>