linux-kernel - Re: [PATCH v3] PM / AVS: rockchip-io: add driver handling Rockchip io domains

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7hy4tog61r.fsf@deeprootsystems.com>
Date:	Fri, 12 Sep 2014 09:25:04 -0700
From:	Kevin Hilman <khilman@...nel.org>
To:	Doug Anderson <dianders@...omium.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Heiko Stuebner <heiko@...ech.de>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	Nishanth Menon <nm@...com>,
	Linus Walleij <linus.walleij@...aro.org>, olof@...om.net,
	Arnd Bergmann <arnd@...db.de>, Mark Brown <broonie@...nel.org>,
	Addy Ke <addy.ke@...k-chips.com>,
	Sonny Rao <sonnyrao@...omium.org>,
	linux-arm-kernel@...ts.infradead.org, robh+dt@...nel.org,
	pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	sre@...nel.org, Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	dwmw2@...radead.org, grant.likely@...aro.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-pm@...r.kernel.org, linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH v3] PM / AVS: rockchip-io: add driver handling Rockchip io domains

Rafael,

Doug Anderson <dianders@...omium.org> writes:

> From: Heiko Stübner <heiko@...ech.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@...ech.de>
> Signed-off-by: Doug Anderson <dianders@...omium.org>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@...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@...aro.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.

Kevin

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286276.html

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/