Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
To:     Marco Felsch <m.felsch@pengutronix.de>,
        Mark Brown <broonie@kernel.org>
CC:     Support Opensource <Support.Opensource@diasemi.com>,
        "lee.jones@linaro.org" <lee.jones@linaro.org>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "linus.walleij@linaro.org" <linus.walleij@linaro.org>,
        "bgolaszewski@baylibre.com" <bgolaszewski@baylibre.com>,
        "joel@jms.id.au" <joel@jms.id.au>,
        "andrew@aj.id.au" <andrew@aj.id.au>,
        "lgirdwood@gmail.com" <lgirdwood@gmail.com>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
        "linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "kernel@pengutronix.de" <kernel@pengutronix.de>
Subject: RE: [PATCH v3 3/6] dt-bindings: mfd: da9062: add regulator voltage
 selection documentation
Thread-Topic: [PATCH v3 3/6] dt-bindings: mfd: da9062: add regulator voltage
 selection documentation
Thread-Index: AQHVptoKIWnW5XGNx0qiesHaa7KQWaeqBMOAgAkpmQCAAfp+EA==
Date:   Wed, 11 Dec 2019 16:14:09 +0000
Message-ID: <AM5PR1001MB099497419E4DCA69D424EC35805A0@AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM>
References: <20191129172537.31410-1-m.felsch@pengutronix.de>
 <20191129172537.31410-4-m.felsch@pengutronix.de>
 <20191204134631.GT1998@sirena.org.uk>
 <20191210094144.mxximpuouchy3fqu@pengutronix.de>
In-Reply-To: <20191210094144.mxximpuouchy3fqu@pengutronix.de>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [193.240.73.196]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0ba1fc48-a343-4396-6502-08d77e552796
x-ms-traffictypediagnostic: AM5PR1001MB0993:
x-ms-exchange-sharedmailbox-routingagent-processed: True
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM5PR1001MB09933A83114E60F8B00C477BA75A0@AM5PR1001MB0993.EURPRD10.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 024847EE92
x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(366004)(136003)(39860400002)(396003)(346002)(376002)(199004)(189003)(53546011)(66476007)(66446008)(186003)(2906002)(52536014)(76116006)(64756008)(9686003)(55016002)(66946007)(26005)(86362001)(66556008)(8936002)(5660300002)(6506007)(54906003)(110136005)(478600001)(7696005)(33656002)(71200400001)(966005)(81156014)(8676002)(7416002)(4326008)(81166006)(316002);DIR:OUT;SFP:1101;SCL:1;SRVR:AM5PR1001MB0993;H:AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:0;MX:1;
received-spf: None (protection.outlook.com: diasemi.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: J3sMxB7NYJyFdUcdBWzTaLsyf/I6yD+Kyi+oAz5uXiPKXwDylbhQvR30AVnXAtIJypLkOmYLuXOPaPLHslDod9K/S1yTlNS5gLbeUtmBd5h0QQBe2tkyM7jxq9BEL+X015J8bPKXho42/dbPB9Vxi2Je0XkaEJAvBSd6tsBIwXaus7TufnlOFxDZMtKVk0wsHEGkhJWL057SH/Rght1bj1Y0ArhqKcdzKpUvZ338NBTztpjRhm96XQMhnfzYnKoCJLsuHioTCnUHdevedhV9xu5ObBsCp5vt2GpEr96yBjrc7RCBRgnOenv2MpIgRLA6fd+R+STjbYtnJclyb0LKd0LSMkyXWavsXgUSLADeOeHlliTMuBZqkLS2AQo1IzkLKl1NhF6zdHDpzGwPa00NwUUK1SqvNDrCNE4xBKsEfZUg3YTuW3O9CaVDFWppheWl97VoaJSDUjl+WboYhDDus2fbItdLc2TcBeVW+nxCPEE=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: diasemi.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0ba1fc48-a343-4396-6502-08d77e552796
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2019 16:14:09.5882
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 511e3c0e-ee96-486e-a2ec-e272ffa37b7c
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4VWJQ23V7FoYM5Gh3qCXrR4JtPCu6Lf4obwBSx08HRV1S51HSXNikG+uprB8oXz9nP+AIoCTCtzvHERu0U4Hwjk8jvTyVpav2ntto3goBGw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR1001MB0993
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 10 December 2019 09:42, Marco Felsch wrote:

> Hi Mark,
>=20
> On 19-12-04 13:46, Mark Brown wrote:
> > On Fri, Nov 29, 2019 at 06:25:34PM +0100, Marco Felsch wrote:
> >
> > > +  Optional regulator device-specific properties:
> > > +  - dlg,vsel-sense-gpios : A GPIO reference to a local general purpo=
se input,
> > > +    the datasheet calls it GPI. The regulator sense the input signal=
 and select
> > > +    the active or suspend voltage settings. If the signal is active =
the
> > > +    active-settings are applied else the suspend-settings are applie=
d.
> > > +    Attention: Sharing the same GPI for other purposes or across mul=
tiple
> > > +    regulators is possible but the polarity setting must equal.
> >
> > I'm really confused by this.  As far as I understand it it seems
> > to be doing pinmuxing on the chip using the GPIO bindings which
> > is itself a bit odd and I don't see anything here that configures
> > whatever sets the state of the pins.  Don't we need another GPIO
> > to set the vsel-sense inputs on the PMIC?
>=20
> Yes the PMIC is very configurable and it took a while till I understand
> it.. @Adam please correct me if I'm wrong.
>=20
> The PMIC regulators regardless of the type: ldo or buck can be
> simplified drawn as:
>=20
>=20
>=20
> da9062-gpio               da9062-regulator
>=20
>   +-------------------------------------------------------
>   |                  PMIC
>   |
>   > GPIO0            +--------------------------+
>   |                  |         REGULATOR-0      |
>   > GPIO1 -------+   |                          |
>   |              +-- > vsel-in    voltage-a-out <
>   > GPIO2        |   |                          |
>   |              |   > enable-in  voltage-b-out <
>   |              |   |                          |
>   |              |   +--------------------------+
>   |              |
>   |              |   +--------------------------+
>   |              |   |         REGULATOR-1      |
>   |              |   |                          |
>   |              +-- > vsel-in    voltage-a-out <
>   |                  |                          |
>   |                  > enable-in  voltage-b-out <
>   |                  |                          |
>   |                  +--------------------------+
>   |
>=20
> The 'vsel-in' and 'enable-in' regulator inputs must be routed to the
> PMIC GPIOs which must be configured as input. If this is a pinmux in
> your opinion, then yes we need to do that. IMHO it isn't a pinmux
> because from the regulator point of view it is just a GPIO which comes
> from our own gpio-dev (da9062-gpio). So the abstraction is vald. Anyway
> I'm with you that this isn't the typical use-case.

We've had this discussion before and to me it felt more like pinmux than GP=
IO
although I understand we're configuring the GPIO pin as input before then
configuring a regulator to take that specific internal GPIO as the control
signal. We're defining a specific role to this pin in HW rather than it bei=
ng a
general software handled GPI so it feels like this would be neater under pi=
nmux.
There does still need to be a mapping between that pin and the regulator wh=
ich I
guess would be served by passing the pin to the regulator through generic p=
inmux
bindings and then in the regulator code you're simply just enabling the
regulator to be controlled from that pin. The HW lets you control multiple
regulators from the same input pin so there's a flexibility there to be
captured, as you mention.

>=20
> Regards,
>   Marco
>=20
> --
> Pengutronix e.K.                           |                             =
|
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  =
|
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    =
|
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 =
|