From: Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>,
Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"Rafael J. Wysocki"
<rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Santosh Shilimkar
<santosh.shilimkar-l0cyMroinI0@public.gmane.org>,
Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>,
Linus Walleij
<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Addy Ke <addy.ke-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
Sonny Rao <sonnyrao-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
pawel.moll-5wv7dgnIgG8@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
Dmitry Eremin-Solenikov
<dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v3] PM / AVS: rockchip-io: add driver handling Rockchip io domains
Date: Wed, 24 Sep 2014 16:27:07 -0700 [thread overview]
Message-ID: <7hwq8sk3as.fsf@deeprootsystems.com> (raw)
In-Reply-To: <7hy4tog61r.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org> (Kevin Hilman's message of "Fri, 12 Sep 2014 09:25:04 -0700")
Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:
> Rafael,
>
> Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> writes:
>
>> From: Heiko Stübner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
>>
>> IO domain voltages on some Rockchip SoCs are variable but need to be
>> kept in sync between the regulators and the SoC using a special
>> register.
>>
>> A specific example using rk3288:
>> - If the regulator hooked up to a pin like SDMMC0_VDD is 3.3V then
>> bit 7 of GRF_IO_VSEL needs to be 0. If the regulator hooked up to
>> that same pin is 1.8V then bit 7 of GRF_IO_VSEL needs to be 1.
>>
>> Said another way, this driver simply handles keeping bits in the SoC's
>> general register file (GRF) in sync with the actual value of a voltage
>> hooked up to the pins.
>>
>> Note that this driver specifically doesn't include:
>> - any logic for deciding what voltage we should set regulators to
>> - any logic for deciding whether regulators (or internal SoC blocks)
>> should have power or not have power
>>
>> If there were some other software that had the smarts of making
>> decisions about regulators, it would work in conjunction with this
>> driver. When that other software adjusted a regulator's voltage then
>> this driver would handle telling the SoC about it. A good example is
>> vqmmc for SD. In that case the dw_mmc driver simply is told about a
>> regulator. It changes the regulator between 3.3V and 1.8V at the
>> right time. This driver notices the change and makes sure that the
>> SoC is on the same page.
>>
>> Signed-off-by: Heiko Stübner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
>> Signed-off-by: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> Reviewed-by: Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>
>> ---
>> Changes in v3:
>> - Changed compatible string as per Santosh.
>
> Thanks, I like the new string better.
>
>> - Added code docs about the slop in 1.8V and 3.3V as per Santosh.
>> - Moved some #defines to the top as per Santosh.
>
> All nice changes, thanks Santosh!
>
> Reviewed-by: Kevin Hilman <khilman-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> Rafael, how do you want to handle drivers/avs/* ? Along with Nishanth,
> I'm maintaining everything there currently (only one driver :)), and
> since I recommended $SUBJECT driver go into drivers/avs[1], I'm happy to
> queue it for you and update MAINTAINERS to cover drivers/avs/* instead
> of just smartreflex.c.
>
> Let me know how you'd like to proceed.
For the benefit of the archives... Rafael and I talked off-list and
agreed that I'll queue it up for him and update MAINTAINERS to reflect
maintenance of drivesr/power/avs
Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: khilman@kernel.org (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3] PM / AVS: rockchip-io: add driver handling Rockchip io domains
Date: Wed, 24 Sep 2014 16:27:07 -0700 [thread overview]
Message-ID: <7hwq8sk3as.fsf@deeprootsystems.com> (raw)
In-Reply-To: <7hy4tog61r.fsf@deeprootsystems.com> (Kevin Hilman's message of "Fri, 12 Sep 2014 09:25:04 -0700")
Kevin Hilman <khilman@kernel.org> writes:
> Rafael,
>
> Doug Anderson <dianders@chromium.org> writes:
>
>> From: Heiko St?bner <heiko@sntech.de>
>>
>> IO domain voltages on some Rockchip SoCs are variable but need to be
>> kept in sync between the regulators and the SoC using a special
>> register.
>>
>> A specific example using rk3288:
>> - If the regulator hooked up to a pin like SDMMC0_VDD is 3.3V then
>> bit 7 of GRF_IO_VSEL needs to be 0. If the regulator hooked up to
>> that same pin is 1.8V then bit 7 of GRF_IO_VSEL needs to be 1.
>>
>> Said another way, this driver simply handles keeping bits in the SoC's
>> general register file (GRF) in sync with the actual value of a voltage
>> hooked up to the pins.
>>
>> Note that this driver specifically doesn't include:
>> - any logic for deciding what voltage we should set regulators to
>> - any logic for deciding whether regulators (or internal SoC blocks)
>> should have power or not have power
>>
>> If there were some other software that had the smarts of making
>> decisions about regulators, it would work in conjunction with this
>> driver. When that other software adjusted a regulator's voltage then
>> this driver would handle telling the SoC about it. A good example is
>> vqmmc for SD. In that case the dw_mmc driver simply is told about a
>> regulator. It changes the regulator between 3.3V and 1.8V at the
>> right time. This driver notices the change and makes sure that the
>> SoC is on the same page.
>>
>> Signed-off-by: Heiko St?bner <heiko@sntech.de>
>> Signed-off-by: Doug Anderson <dianders@chromium.org>
>> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>> Changes in v3:
>> - Changed compatible string as per Santosh.
>
> Thanks, I like the new string better.
>
>> - Added code docs about the slop in 1.8V and 3.3V as per Santosh.
>> - Moved some #defines to the top as per Santosh.
>
> All nice changes, thanks Santosh!
>
> Reviewed-by: Kevin Hilman <khilman@linaro.org>
>
> Rafael, how do you want to handle drivers/avs/* ? Along with Nishanth,
> I'm maintaining everything there currently (only one driver :)), and
> since I recommended $SUBJECT driver go into drivers/avs[1], I'm happy to
> queue it for you and update MAINTAINERS to cover drivers/avs/* instead
> of just smartreflex.c.
>
> Let me know how you'd like to proceed.
For the benefit of the archives... Rafael and I talked off-list and
agreed that I'll queue it up for him and update MAINTAINERS to reflect
maintenance of drivesr/power/avs
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@kernel.org>
To: Doug Anderson <dianders@chromium.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Heiko Stuebner <heiko@sntech.de>,
Ulf Hansson <ulf.hansson@linaro.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
Nishanth Menon <nm@ti.com>,
Linus Walleij <linus.walleij@linaro.org>,
olof@lixom.net, Arnd Bergmann <arnd@arndb.de>,
Mark Brown <broonie@kernel.org>, Addy Ke <addy.ke@rock-chips.com>,
Sonny Rao <sonnyrao@chromium.org>,
linux-arm-kernel@lists.infradead.org, robh+dt@kernel.org,
pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
sre@kernel.org, Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
dwmw2@infradead.org, grant.likely@linaro.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, linux-rockchip@lists.infradead.org
Subject: Re: [PATCH v3] PM / AVS: rockchip-io: add driver handling Rockchip io domains
Date: Wed, 24 Sep 2014 16:27:07 -0700 [thread overview]
Message-ID: <7hwq8sk3as.fsf@deeprootsystems.com> (raw)
In-Reply-To: <7hy4tog61r.fsf@deeprootsystems.com> (Kevin Hilman's message of "Fri, 12 Sep 2014 09:25:04 -0700")
Kevin Hilman <khilman@kernel.org> writes:
> Rafael,
>
> Doug Anderson <dianders@chromium.org> writes:
>
>> From: Heiko Stübner <heiko@sntech.de>
>>
>> IO domain voltages on some Rockchip SoCs are variable but need to be
>> kept in sync between the regulators and the SoC using a special
>> register.
>>
>> A specific example using rk3288:
>> - If the regulator hooked up to a pin like SDMMC0_VDD is 3.3V then
>> bit 7 of GRF_IO_VSEL needs to be 0. If the regulator hooked up to
>> that same pin is 1.8V then bit 7 of GRF_IO_VSEL needs to be 1.
>>
>> Said another way, this driver simply handles keeping bits in the SoC's
>> general register file (GRF) in sync with the actual value of a voltage
>> hooked up to the pins.
>>
>> Note that this driver specifically doesn't include:
>> - any logic for deciding what voltage we should set regulators to
>> - any logic for deciding whether regulators (or internal SoC blocks)
>> should have power or not have power
>>
>> If there were some other software that had the smarts of making
>> decisions about regulators, it would work in conjunction with this
>> driver. When that other software adjusted a regulator's voltage then
>> this driver would handle telling the SoC about it. A good example is
>> vqmmc for SD. In that case the dw_mmc driver simply is told about a
>> regulator. It changes the regulator between 3.3V and 1.8V at the
>> right time. This driver notices the change and makes sure that the
>> SoC is on the same page.
>>
>> Signed-off-by: Heiko Stübner <heiko@sntech.de>
>> Signed-off-by: Doug Anderson <dianders@chromium.org>
>> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>> Changes in v3:
>> - Changed compatible string as per Santosh.
>
> Thanks, I like the new string better.
>
>> - Added code docs about the slop in 1.8V and 3.3V as per Santosh.
>> - Moved some #defines to the top as per Santosh.
>
> All nice changes, thanks Santosh!
>
> Reviewed-by: Kevin Hilman <khilman@linaro.org>
>
> Rafael, how do you want to handle drivers/avs/* ? Along with Nishanth,
> I'm maintaining everything there currently (only one driver :)), and
> since I recommended $SUBJECT driver go into drivers/avs[1], I'm happy to
> queue it for you and update MAINTAINERS to cover drivers/avs/* instead
> of just smartreflex.c.
>
> Let me know how you'd like to proceed.
For the benefit of the archives... Rafael and I talked off-list and
agreed that I'll queue it up for him and update MAINTAINERS to reflect
maintenance of drivesr/power/avs
Kevin
next prev parent reply other threads:[~2014-09-24 23:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-11 22:48 [PATCH v3] PM / AVS: rockchip-io: add driver handling Rockchip io domains Doug Anderson
2014-09-11 22:48 ` Doug Anderson
2014-09-12 16:25 ` Kevin Hilman
2014-09-12 16:25 ` Kevin Hilman
[not found] ` <7hy4tog61r.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
2014-09-24 23:27 ` Kevin Hilman [this message]
2014-09-24 23:27 ` Kevin Hilman
2014-09-24 23:27 ` Kevin Hilman
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=7hwq8sk3as.fsf@deeprootsystems.com \
--to=khilman-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=addy.ke-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=nm-l0cyMroinI0@public.gmane.org \
--cc=olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org \
--cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
--cc=rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=santosh.shilimkar-l0cyMroinI0@public.gmane.org \
--cc=sonnyrao-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.