From: Peter Chen <hzpeterchen@gmail.com>
To: Rob Herring <robh@kernel.org>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>,
Mark Brown <broonie@kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Sebastian Reichel <sre@kernel.org>,
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Hans de Goede <hdegoede@redhat.com>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
Heiko Stuebner <heiko@sntech.de>,
linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-pm@vger.kernel.org,
linux-usb@vger.kernel.org, linux-fbdev@vger.ke
Subject: Re: [RFC v4 01/14] regulator: of: Add helper for getting all supplies
Date: Sun, 12 Jun 2016 15:29:01 +0800 [thread overview]
Message-ID: <20160612072901.GD22054@shlinux2> (raw)
In-Reply-To: <20160610173056.GA16503@rob-hp-laptop>
On Fri, Jun 10, 2016 at 12:30:56PM -0500, Rob Herring wrote:
> On Thu, Jun 09, 2016 at 01:42:02PM +0200, Krzysztof Kozlowski wrote:
> > On 06/09/2016 12:29 PM, Mark Brown wrote:
> > > On Thu, Jun 09, 2016 at 11:44:18AM +0200, Krzysztof Kozlowski wrote:
> > >> Few drivers have a need of getting regulator supplies without knowing
> > >> their names:
> > >> 1. The Simple Framebuffer driver works on setup provided by bootloader
> > >> (outside of scope of kernel);
> > >> 2. Generic power sequence driver may be attached to any device node.
> > >>
> > >> Add a Device Tree helper for parsing "-supply" properties and returning
> > >> allocated bulk regulator consumers.
> > >
> > > I'm still very concerned that this is just an invitation to people to
> > > write half baked regulator consumers and half baked DTs to go along with
> > > it, making it a standard API that doesn't have big red flags on it that
> > > will flag up when "normal" drivers use it is not good. Right now this
> > > just looks like a standard API and people are going to just start using
> > > it. If we are going to do this perhaps we need a separate header or
> > > something to help flag this up.
> >
> > No problem, I can move it to a special header. Actually, if you dislike
> > this as an API, it does not have to be in header at all. I can just
> > duplicate the simplefb code.
> >
> > > In the case of power sequences I'd expect the sequences to perform
> > > operations on named supplies - the core shouldn't know what the supplies
> > > are but the thing specifying the sequence should.
> >
> > Hm, so maybe passing names like:
> >
> > usb3503@08 {
> > reset-gpios = <&gpx3 5 GPIO_ACTIVE_HIGH>;
> > initial-mode = <1>;
> > vdd-supply = <&buck8_reg>;
> > foo-supply = <&buck9_reg>;
> >
> > power-sequence;
> > power-sequence-supplies = "vdd", "foo";
>
> This alone would be fine as it is just one property, but then what's
> next? power-sequence-delay, power-sequence-clocks, etc. What if you
> need to express ordering relationship of supplies, clocks, gpios? We end
> up with a scripting language in DT and we don't want to have that.
>
Can we do things like below:
- DT describes hardware elements (clock, gpios, etc) for power sequence, and we
need a node for power sequence.
- Power sequence framework handles getting hardware elements.
- Power sequence platform driver handles special sequence for devices,
and we can create some generic drivers for generic devices.
--
Best Regards,
Peter Chen
next prev parent reply other threads:[~2016-06-12 7:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-09 9:44 [RFC v4 00/14] usb/mmc/power: Generic power sequence (and fix USB/LAN when TFTP booting) Krzysztof Kozlowski
2016-06-09 9:44 ` [RFC v4 01/14] regulator: of: Add helper for getting all supplies Krzysztof Kozlowski
2016-06-09 10:29 ` Mark Brown
2016-06-09 11:42 ` Krzysztof Kozlowski
2016-06-10 17:30 ` Rob Herring
2016-06-10 18:49 ` Heiko Stübner
2016-06-12 7:29 ` Peter Chen [this message]
2016-06-13 3:44 ` Peter Chen
2016-06-09 12:50 ` Rafael J. Wysocki
[not found] ` <CAJZ5v0hiyyOhU7AjOEjFHjTKhT+pqWZheUG77c6u2HV9dNQ0Gg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-06-09 15:57 ` Mark Brown
2016-06-09 9:44 ` [RFC v4 02/14] simplefb: Use new devm_of_regulator_all_get helper and bulk API Krzysztof Kozlowski
2016-06-09 9:44 ` [RFC v4 03/14] power/mmc: Move pwrseq drivers to power/pwrseq Krzysztof Kozlowski
2016-06-09 9:44 ` [RFC v4 04/14] MAINTAINERS: Retain Ulf Hansson as the same maintainer of pwrseq Krzysztof Kozlowski
2016-06-09 9:44 ` [RFC v4 05/14] power: pwrseq: Enable COMPILE_TEST for drivers Krzysztof Kozlowski
[not found] ` <1465465471-28740-1-git-send-email-k.kozlowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-06-09 9:44 ` [RFC v4 06/14] power: pwrseq: Remove mmc prefix from mmc_pwrseq Krzysztof Kozlowski
2016-06-09 9:44 ` [RFC v4 07/14] power: pwrseq: Generalize mmc_pwrseq operations by removing mmc prefix Krzysztof Kozlowski
2016-06-09 9:44 ` [RFC v4 08/14] power: pwrseq: simple: Add support for regulators and generic property Krzysztof Kozlowski
2016-06-09 9:44 ` [RFC v4 09/14] power: pwrseq: Add support for USB hubs with external power Krzysztof Kozlowski
2016-06-09 9:44 ` [RFC v4 10/14] usb: hub: Handle deferred probe Krzysztof Kozlowski
2016-06-09 9:44 ` [RFC v4 11/14] EXAMPLE CODE: usb: port: Parse pwrseq phandle from Device Tree Krzysztof Kozlowski
2016-06-09 9:44 ` [RFC v4 12/14] EXAMPLE CODE: usb: hub: Power sequence the ports on activation Krzysztof Kozlowski
2016-06-09 9:44 ` [RFC v4 13/14] ARM: dts: exynos: Switch the buck8 to GPIO mode on Odroid U3 Krzysztof Kozlowski
2016-06-09 9:44 ` [RFC v4 14/14] ARM: dts: exynos: Fix LAN and HUB after bootloader initialization " Krzysztof Kozlowski
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=20160612072901.GD22054@shlinux2 \
--to=hzpeterchen@gmail.com \
--cc=broonie@kernel.org \
--cc=dbaryshkov@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=galak@codeaurora.org \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=heiko@sntech.de \
--cc=ijc+devicetree@hellion.org.uk \
--cc=k.kozlowski@samsung.com \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fbdev@vger.ke \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=plagnioj@jcrosoft.com \
--cc=robh@kernel.org \
--cc=sre@kernel.org \
--cc=tomi.valkeinen@ti.com \
--cc=ulf.hansson@linaro.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).