From: l.stach@pengutronix.de (Lucas Stach)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 2/2] soc/imx: Add GPCv2 power gating driver
Date: Thu, 23 Mar 2017 15:35:49 +0100 [thread overview]
Message-ID: <1490279749.29056.33.camel@pengutronix.de> (raw)
In-Reply-To: <20170324062451.GB12604@b29396-OptiPlex-7040>
Hi Dong,
Am Freitag, den 24.03.2017, 14:24 +0800 schrieb Dong Aisheng:
[...]
> > +static struct platform_driver imx7_pgc_domain_driver = {
> > + .driver = {
> > + .name = "imx7-pgc",
> > + },
> > + .probe = imx7_pgc_domain_probe,
> > + .remove = imx7_pgc_domain_remove,
> > + .id_table = imx7_pgc_domain_id,
> > +};
> > +builtin_platform_driver(imx7_pgc_domain_driver)
>
> Again, i have a fundamental question about this patch implementation
> that why we choose above way to register the power domain?
>
> I'm sorry that i did not know too much history.
> Would you guys please help share some information?
>
> Because AFAIK this way will register each domain as a power domain
> provider which is a bit violate the real HW and current power domain
> framework design. And it is a bit more complicated to use than before.
>
> IMHO i would rather prefer the old traditional and simpler way that one
> provider (GPC) supplies multiple domains (PCIE/MIPI/HSIC PHY domain)
> than this patch does.
>
> However, i might be wrong. Please help to clear.
This way we can properly describe each power domain with the regulator
supplying the domain and the clocks of the devices inside the domain in
the device tree.
This is needed as for the upstream version we are controlling the
regulator from the GPC driver, as opposed to the downstream version,
where each device has to implement the regulator handling and power
up/down sequencing.
See the rationale in the commits adding the multidomain support to the
i.MX6 GPC.
Regards,
Lucas
next prev parent reply other threads:[~2017-03-23 14:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-21 14:50 [PATCH v7 0/2] GPCv2 power gating driver Andrey Smirnov
2017-03-21 14:50 ` [PATCH v7 1/2] dt-bindings: Add " Andrey Smirnov
2017-03-24 6:32 ` Dong Aisheng
2017-03-27 18:42 ` Andrey Smirnov
2017-03-30 7:15 ` Dong Aisheng
2017-03-21 14:50 ` [PATCH v7 2/2] soc/imx: " Andrey Smirnov
2017-03-24 6:24 ` Dong Aisheng
2017-03-23 14:35 ` Lucas Stach [this message]
2017-03-30 7:51 ` Dong Aisheng
2017-03-29 16:08 ` Lucas Stach
2017-04-01 4:10 ` Dong Aisheng
2017-03-31 12:28 ` Lucas Stach
2017-04-11 3:22 ` Dong Aisheng
2017-03-27 18:42 ` Andrey Smirnov
2017-03-30 6:58 ` Dong Aisheng
2017-03-30 7:04 ` Dong Aisheng
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=1490279749.29056.33.camel@pengutronix.de \
--to=l.stach@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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).