Thread (1 message) 1 message, 1 author, 2014-09-24

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

From: khilman@kernel.org (Kevin Hilman)
Date: 2014-09-24 23:27:15
Also in: linux-devicetree, linux-pm, lkml

Kevin Hilman [off-list ref] writes:
Rafael,

Doug Anderson [off-list ref] writes:
quoted
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 <redacted>
---
Changes in v3:
- Changed compatible string as per Santosh.
Thanks, I like the new string better.
quoted
- 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 <redacted>

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help