linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Chen-Yu Tsai <wens@csie.org>
To: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: linux-gpio@vger.kernel.org,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Mylène Josserand" <mylene.josserand@bootlin.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH 0/2] pinctrl: sunxi: Account for per-bank GPIO regulators
Date: Fri, 7 Dec 2018 00:01:18 +0800	[thread overview]
Message-ID: <CAGb2v65wEMd0iCMBD83Sr5fpEkTte6S9-sJyoYLJmGzEOFYJNQ@mail.gmail.com> (raw)
In-Reply-To: <20181206154748.45iqfnlirm6blt4k@flea>

On Thu, Dec 6, 2018 at 11:47 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Hi,
>
> On Thu, Dec 06, 2018 at 11:28:21PM +0800, Chen-Yu Tsai wrote:
> > On Thu, Dec 6, 2018 at 10:02 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > The main interogation I have currently is whether we should always try to
> > > get the regulator for the current branch, or if we should restrict it to
> > > the one available on the SoCs.
> >
> > Not sure what you mean here, but we should probably just list the actual
> > names.
>
> The A20 for example doesn't have a VCC-PB regulator, so do we want to
> try to grab it if we request a PB* pin, or should we just know that
> somehow and not do it?

AFAIK, pin banks that don't have a separate supply are powered collectively
by VCC-IO, as mentioned below in my previous reply.

> > For pre-A20 SoCs (A10/A10s/A13), they aren't even named VCC-Px. Instead
> > they are named after the primary function of the pin bank, such as
> > VCC-CARD, VCC-NAND, VCC-CSI0, VCC-CSI1.
>
> I'd really prefer to stick to vcc-pX, that's pretty obvious even for
> those older SoCs, and we can maintain some consistency that way.

IRRC Mark said that supply names should match design names, not what is
convenient. And then again there's the fallback for those that don't have
separate rails.

> > For pin banks that don't have per-bank power inputs, you should fall back
> > to VCC-IO, or VCC-RTC in the case of the PL pins.
> >
> > So here's the rub: On A33 and later SoCs that are paired with a PMIC, VCC-PL
> > or VCC-RTC is powered by the RTC regulator of the PMIC, which only gets
> > registered when the PMIC regulator driver is probed, which needs the RSB
> > controller, which needs the pin controller and the PL pins...
>
> I haven't seen any VCC-P* on the A33, do you have a reference?

The A33 has a VCC-PD. This is not listed in the datasheet, but is shown in
schematics. Other pins would be powered by VCC-IO, with the exception of PL,
which would be power by VCC-RTC. The last bit is just a guess. We should
probably ask Allwinner, or try to do some tests.

ChenYu

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2018-12-06 16:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-06 14:02 [PATCH 0/2] pinctrl: sunxi: Account for per-bank GPIO regulators Maxime Ripard
2018-12-06 14:02 ` [PATCH 1/2] pinctrl: sunxi: Deal with per-bank regulators Maxime Ripard
2018-12-14 15:08   ` Linus Walleij
2018-12-14 15:11   ` Linus Walleij
2018-12-17 13:16     ` Maxime Ripard
2019-01-07  5:20   ` Chen-Yu Tsai
2019-01-09  4:36     ` Chen-Yu Tsai
2018-12-06 14:02 ` [PATCH 2/2] ARM: dts: sun7i: bananapi: Add GPIO banks regulators Maxime Ripard
2018-12-14 15:10   ` Linus Walleij
2018-12-06 15:28 ` [PATCH 0/2] pinctrl: sunxi: Account for per-bank GPIO regulators Chen-Yu Tsai
2018-12-06 15:47   ` Maxime Ripard
2018-12-06 16:01     ` Chen-Yu Tsai [this message]
2018-12-11 17:01       ` Maxime Ripard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGb2v65wEMd0iCMBD83Sr5fpEkTte6S9-sJyoYLJmGzEOFYJNQ@mail.gmail.com \
    --to=wens@csie.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=maxime.ripard@bootlin.com \
    --cc=mylene.josserand@bootlin.com \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).