mbox series

[v5,0/6] Mediatek thermal sensor driver support for MT8186 and MT8188

Message ID 20240524-mtk-thermal-mt818x-dtsi-v5-0-56f8579820e7@baylibre.com
Headers show
Series Mediatek thermal sensor driver support for MT8186 and MT8188 | expand

Message

Julien Panis May 24, 2024, 9:04 a.m. UTC
This is a bunch of patches to support the MT8186 and MT8188 thermal
sensor configurations.

Since the patches of v3 were applied except those related to the SoC
device trees, this series includes mainly patches for 'mt8186.dtsi'
and 'mt8188.dtsi'. Due to some thermal zone renaming in these 2 device
trees, the related definitions were also renamed in the dt-bindings and
in the driver.

[RFC] When PATCH 1/6 and 2/6 are squashed, checkpatch raises this WARNING:
"DT binding docs and includes should be a separate patch." That's why I
split them in this v5. The problem is that the driver can't be compiled
any more at PATCH 1/6. It needs PATCH 2/6 to be compiled. Should the
checkpatch warning be ignored here ? Should I finally squash PATCH 1/6
and PATCH 2/6 ?

[NOTE] Before being applied, PATCH 6/6 needs a 'gpu' node in 'mt8188.dtsi',
but this node does not exist yet. A series will be submitted by Angelo to
add this GPU support in MT8188.

Signed-off-by: Julien Panis <jpanis@baylibre.com>
---
Changes in v5:
- Rename some thermal zones
  (mfg -> gpu / soc1 -> adsp / soc2 -> vdo / soc3 -> infra).
- Add cooling-device for GPUs.
- Link to v4: https://lore.kernel.org/r/20240521-mtk-thermal-mt818x-dtsi-v4-0-b91ee678411c@baylibre.com

Changes in v4:
- Fix wrong thermal zone names.
- Lower 'polling-delay-passive' values.
- Set 'hysteresis' value to 0 for 'critical' trips.
- Add a 'hot' trip point in between 'passive' and 'critical' trips.
- Link to v3: https://lore.kernel.org/all/20240402032729.2736685-1-nico@fluxnic.net/

Changes in v3:
- use meaningful name for binding index definitions
- reuse LVTS_COEFF_*_MT7988 on MT8186 per reviewer request
- do similarly for MT8188 that now reuses LVTS_COEFF_*_MT8195
- use thermal zone names the svs driver wants
- adjust some DT node names and iospace length
- remove variable .hw_tshut_temp as it is constant across all SOCs
- Link to v2: https://lore.kernel.org/all/20240318212428.3843952-1-nico@fluxnic.net/

Changes in v2:
- renamed CPU cluster thermal zones in DT
- fixed logic to cope with empty controller slots at the beginning
- isolated bindings to their own patches
- added MT8188 default thermal zones
- Link to v1: https://lore.kernel.org/all/20240111223020.3593558-1-nico@fluxnic.net/T/

---
Julien Panis (2):
      dt-bindings: thermal: mediatek: Rename thermal zone definitions for MT8186 and MT8188
      thermal/drivers/mediatek/lvts_thermal: Use renamed thermal zone definitions for MT8186 and MT8188

Nicolas Pitre (4):
      arm64: dts: mediatek: mt8186: add lvts definitions
      arm64: dts: mediatek: mt8186: add default thermal zones
      arm64: dts: mediatek: mt8188: add lvts definitions
      arm64: dts: mediatek: mt8188: add default thermal zones

 arch/arm64/boot/dts/mediatek/mt8186.dtsi           | 316 ++++++++++++++
 arch/arm64/boot/dts/mediatek/mt8188.dtsi           | 481 +++++++++++++++++++++
 drivers/thermal/mediatek/lvts_thermal.c            |  12 +-
 .../dt-bindings/thermal/mediatek,lvts-thermal.h    |  12 +-
 4 files changed, 809 insertions(+), 12 deletions(-)
---
base-commit: 632483ea8004edfadd035de36e1ab2c7c4f53158
change-id: 20240520-mtk-thermal-mt818x-dtsi-eca378f9b6a0

Best regards,

Comments

Julien Panis May 27, 2024, 8:38 a.m. UTC | #1
On 5/24/24 19:19, Russell King (Oracle) wrote:
> On Fri, May 24, 2024 at 01:04:38PM -0400, Nicolas Pitre wrote:
>> On Fri, 24 May 2024, Julien Panis wrote:
>>
>>> [RFC] When PATCH 1/6 and 2/6 are squashed, checkpatch raises this WARNING:
>>> "DT binding docs and includes should be a separate patch." That's why I
>>> split them in this v5. The problem is that the driver can't be compiled
>>> any more at PATCH 1/6. It needs PATCH 2/6 to be compiled. Should the
>>> checkpatch warning be ignored here ? Should I finally squash PATCH 1/6
>>> and PATCH 2/6 ?
>> IMHO it might be preferable to preserve successful compilation across
>> bisection than to appeal to checkpatch in this case.
> Or, patch 1 adds the new definitions, subsequent patches convert the
> users, and the last patch removes the old, now unused, definitions.
>

Thanks for this suggestion. I'll do something like that in next version.