From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: [PATCH v3] PM / AVS: rockchip-io: add driver handling Rockchip io domains Date: Wed, 24 Sep 2014 16:27:07 -0700 Message-ID: <7hwq8sk3as.fsf@deeprootsystems.com> References: <1410475735-10278-1-git-send-email-dianders@chromium.org> <7hy4tog61r.fsf@deeprootsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <7hy4tog61r.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org> (Kevin Hilman's message of "Fri, 12 Sep 2014 09:25:04 -0700") Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Doug Anderson Cc: "Rafael J. Wysocki" , Heiko Stuebner , Ulf Hansson , "Rafael J. Wysocki" , Santosh Shilimkar , Nishanth Menon , Linus Walleij , olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org, Arnd Bergmann , Mark Brown , Addy Ke , Sonny Rao , 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 , 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 List-Id: linux-pm@vger.kernel.org Kevin Hilman writes: > Rafael, > > Doug Anderson writes: > >> From: Heiko St=C3=BCbner >> >> 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 volta= ge >> 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 the= n >> this driver would handle telling the SoC about it. A good example i= s >> 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=C3=BCbner >> Signed-off-by: Doug Anderson >> Reviewed-by: Santosh Shilimkar >> --- >> 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 > > Rafael, how do you want to handle drivers/avs/* ? Along with Nishant= h, > 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/* instea= d > of just smartreflex.c. > > Let me know how you'd like to proceed. =46or 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" i= n the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: khilman@kernel.org (Kevin Hilman) Date: Wed, 24 Sep 2014 16:27:07 -0700 Subject: [PATCH v3] PM / AVS: rockchip-io: add driver handling Rockchip io domains In-Reply-To: <7hy4tog61r.fsf@deeprootsystems.com> (Kevin Hilman's message of "Fri, 12 Sep 2014 09:25:04 -0700") References: <1410475735-10278-1-git-send-email-dianders@chromium.org> <7hy4tog61r.fsf@deeprootsystems.com> Message-ID: <7hwq8sk3as.fsf@deeprootsystems.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Kevin Hilman writes: > Rafael, > > Doug Anderson writes: > >> From: Heiko St?bner >> >> 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 >> Signed-off-by: Doug Anderson >> Reviewed-by: Santosh Shilimkar >> --- >> 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 > > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751450AbaIXX1P (ORCPT ); Wed, 24 Sep 2014 19:27:15 -0400 Received: from mail.kernel.org ([198.145.19.201]:44176 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751134AbaIXX1N convert rfc822-to-8bit (ORCPT ); Wed, 24 Sep 2014 19:27:13 -0400 From: Kevin Hilman To: Doug Anderson Cc: "Rafael J. Wysocki" , Heiko Stuebner , Ulf Hansson , "Rafael J. Wysocki" , Santosh Shilimkar , Nishanth Menon , Linus Walleij , olof@lixom.net, Arnd Bergmann , Mark Brown , Addy Ke , Sonny Rao , 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 , 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 References: <1410475735-10278-1-git-send-email-dianders@chromium.org> <7hy4tog61r.fsf@deeprootsystems.com> Date: Wed, 24 Sep 2014 16:27:07 -0700 In-Reply-To: <7hy4tog61r.fsf@deeprootsystems.com> (Kevin Hilman's message of "Fri, 12 Sep 2014 09:25:04 -0700") Message-ID: <7hwq8sk3as.fsf@deeprootsystems.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Kevin Hilman writes: > Rafael, > > Doug Anderson writes: > >> From: Heiko Stübner >> >> 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 >> Signed-off-by: Doug Anderson >> Reviewed-by: Santosh Shilimkar >> --- >> 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 > > 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