[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7c3d9e84-d14f-4cf0-b376-6fdde6f586f5@linaro.org>
Date: Thu, 7 Aug 2025 10:16:33 +0200
From: neil.armstrong@...aro.org
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
sboyd@...nel.org
Cc: jic23@...nel.org, dlechner@...libre.com, nuno.sa@...log.com,
andy@...nel.org, arnd@...db.de, gregkh@...uxfoundation.org,
srini@...nel.org, vkoul@...nel.org, kishon@...nel.org, sre@...nel.org,
krzysztof.kozlowski@...aro.org, u.kleine-koenig@...libre.com,
linux-arm-msm@...r.kernel.org, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-phy@...ts.infradead.org,
linux-pm@...r.kernel.org, kernel@...labora.com, wenst@...omium.org,
casey.connolly@...aro.org
Subject: Re: [PATCH v3 0/7] SPMI: Implement sub-devices and migrate drivers
On 30/07/2025 13:26, AngeloGioacchino Del Regno wrote:
> Changes in v3:
> - Fixed importing "SPMI" namespace in spmi-devres.c
> - Removed all instances of defensive programming, as pointed out by
> jic23 and Sebastian
> - Removed explicit casting as pointed out by jic23
> - Moved ida_free call to spmi_subdev_release() and simplified error
> handling in spmi_subdevice_alloc_and_add() as pointed out by jic23
>
> Changes in v2:
> - Fixed missing `sparent` initialization in phy-qcom-eusb2-repeater
> - Changed val_bits to 8 in all Qualcomm drivers to ensure
> compatibility as suggested by Casey
> - Added struct device pointer in all conversion commits as suggested
> by Andy
> - Exported newly introduced functions with a new "SPMI" namespace
> and imported the same in all converted drivers as suggested by Andy
> - Added missing error checking for dev_set_name() call in spmi.c
> as suggested by Andy
> - Added comma to last entry of regmap_config as suggested by Andy
>
> While adding support for newer MediaTek platforms, featuring complex
> SPMI PMICs, I've seen that those SPMI-connected chips are internally
> divided in various IP blocks, reachable in specific contiguous address
> ranges... more or less like a MMIO, but over a slow SPMI bus instead.
>
> I recalled that Qualcomm had something similar... and upon checking a
> couple of devicetrees, yeah - indeed it's the same over there.
>
> What I've seen then is a common pattern of reading the "reg" property
> from devicetree in a struct member and then either
> A. Wrapping regmap_{read/write/etc}() calls in a function that adds
> the register base with "base + ..register", like it's done with
> writel()/readl() calls; or
> B. Doing the same as A. but without wrapper functions.
>
> Even though that works just fine, in my opinion it's wrong.
>
> The regmap API is way more complex than MMIO-only readl()/writel()
> functions for multiple reasons (including supporting multiple busses
> like SPMI, of course) - but everyone seemed to forget that regmap
> can manage register base offsets transparently and automatically in
> its API functions by simply adding a `reg_base` to the regmap_config
> structure, which is used for initializing a `struct regmap`.
>
> So, here we go: this series implements the software concept of an SPMI
> Sub-Device (which, well, also reflects how Qualcomm and MediaTek's
> actual hardware is laid out anyway).
>
> SPMI Controller
> | ______
> | / Sub-Device 1
> V /
> SPMI Device (PMIC) ----------- Sub-Device 2
> \
> \______ Sub-Device 3
>
> As per this implementation, an SPMI Sub-Device can be allocated/created
> and added in any driver that implements a... well.. subdevice (!) with
> an SPMI "main" device as its parent: this allows to create and finally
> to correctly configure a regmap that is specific to the sub-device,
> operating on its specific address range and reading, and writing, to
> its registers with the regmap API taking care of adding the base address
> of a sub-device's registers as per regmap API design.
>
> All of the SPMI Sub-Devices are therefore added as children of the SPMI
> Device (usually a PMIC), as communication depends on the PMIC's SPMI bus
> to be available (and the PMIC to be up and running, of course).
>
> Summarizing the dependency chain (which is obvious to whoever knows what
> is going on with Qualcomm and/or MediaTek SPMI PMICs):
> "SPMI Sub-Device x...N" are children "SPMI Device"
> "SPMI Device" is a child of "SPMI Controller"
>
> (that was just another way to say the same thing as the graph above anyway).
>
> Along with the new SPMI Sub-Device registration functions, I have also
> performed a conversion of some Qualcomm SPMI drivers and only where the
> actual conversion was trivial.
>
> I haven't included any conversion of more complex Qualcomm SPMI drivers
> because I don't have the required bandwidth to do so (and besides, I think,
> but haven't exactly verified, that some of those require SoCs that I don't
> have for testing anyway).
>
> AngeloGioacchino Del Regno (7):
> spmi: Implement spmi_subdevice_alloc_and_add() and devm variant
> nvmem: qcom-spmi-sdam: Migrate to devm_spmi_subdevice_alloc_and_add()
> power: reset: qcom-pon: Migrate to devm_spmi_subdevice_alloc_and_add()
> phy: qualcomm: eusb2-repeater: Migrate to
> devm_spmi_subdevice_alloc_and_add()
> misc: qcom-coincell: Migrate to devm_spmi_subdevice_alloc_and_add()
> iio: adc: qcom-spmi-iadc: Migrate to
> devm_spmi_subdevice_alloc_and_add()
> iio: adc: qcom-spmi-iadc: Remove regmap R/W wrapper functions
>
> drivers/iio/adc/qcom-spmi-iadc.c | 109 ++++++++----------
> drivers/misc/qcom-coincell.c | 38 ++++--
> drivers/nvmem/qcom-spmi-sdam.c | 37 ++++--
> .../phy/qualcomm/phy-qcom-eusb2-repeater.c | 51 +++++---
> drivers/power/reset/qcom-pon.c | 34 ++++--
> drivers/spmi/spmi-devres.c | 24 ++++
> drivers/spmi/spmi.c | 79 +++++++++++++
> include/linux/spmi.h | 16 +++
> 8 files changed, 278 insertions(+), 110 deletions(-)
>
Tested-by: Neil Armstrong <neil.armstrong@...aro.org> # on SM8650-QRD
Tested patch 1, 2, 3 & 4, I can see the :
/sys/kernel/debug/regmap/0-00.0.auto
/sys/kernel/debug/regmap/0-00.1.auto
/sys/kernel/debug/regmap/0-07.2.auto
And it still functional.
Neil
Powered by blists - more mailing lists