Re: [PATCH 1/6] dt-bindings: regulator: pca9450: Document new usage of sd-vsel-gpios

On 16.02.23 03:30, Rob Herring wrote:

On Wed, Feb 15, 2023 at 7:27 PM Marek Vasut [off-list ref] wrote:

quoted

On 2/15/23 21:02, Rob Herring wrote:

quoted

On Mon, Feb 13, 2023 at 04:58:19PM +0100, Frieder Schrempf wrote:

quoted

From: Frieder Schrempf <redacted>

The sd-vsel-gpios property is abandoned in its current meaning as an
output. We now use it to specify an optional signal that can be
evaluated by the driver in order to retrieve the current status
of the SD_VSEL signal that is used to select the control register
of LDO5.

Signed-off-by: Frieder Schrempf <redacted>
---
  .../regulator/nxp,pca9450-regulator.yaml      | 23 ++++++++++++++-----
  1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
index 835b53302db8..c86534538a4e 100644
--- a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml

@@ -40,8 +40,24 @@ properties:
      description: |
        list of regulators provided by this controller

+    properties:
+      LDO5:
+        type: object
+        $ref: regulator.yaml#
+        description:
+          Properties for single LDO5 regulator.
+
+        properties:
+          sd-vsel-gpios:

It is a pin on the device, right? Then it belongs in the device node as
it was.

Physically it's a pin on the PCA9450 chip. If you look at the block
diagram in the datasheet [1] (page 3) you can see though, that the
SD_VSEL signal is routed to the LD05 regulator block inside the chip.
This makes me think that the signal is best described inside the LDO5 node.

quoted

quoted

Can't the direction of the signal tell you how it is used? Assuming the
pin is bidirectional?

The pin is input to the PMIC, it is unidirection, i.e.

SoC(output)---->(input)PMIC

quoted

The binding should support any possible way the device is wired, not
just what's been seen so far on some boards.

The usage is always the above as far as I can tell.

There is only one usage that is likely to occur and that is the one we
describe here.

There are other ways to wire up the signal of course and in some
unlikely event a hardware engineer might have the idea to hard-wire the
SD_VSEL to a fixed level or wire it up to a SoC pin that doesn't have
the VSELECT mux option.

But I don't really see a good reason for covering these cases in the
binding/driver if there are good chances we won't ever need them.

This patch is saying the opposite though. Something else drives the
signal, but the signal is also routed to the SoC to sample the state.

SoC                                  PMIC
+-----------------------+           +-------------------+
|                       |           |                   |
|                       |           |                   |
|  GPIO <----------+    |           |                   |
|                  |    |    SD_VSEL|   +-------+       |
|  USHC_VSELECT -->+------------------->| LDO5  |       |
|                       |           |   +-------+       |
|                       |           |                   |
+-----------------------+           +-------------------+

This is how the setup looks like. The SD_VSEL on the PMIC is always an
input. It's driven by the SoC's VSELECT signal (controlled by the USDHC
controller) and we use the SION bit in the IOMUX to internally loop back
the signal in order to sample it using the GPIO.

[1] https://www.nxp.com/docs/en/data-sheet/PCA9450DS.pdf