Re: [PATCH 1/2] regulator: core: add support to get VSEL register from hw driver

[Laxman Dewangan]

On Thursday 28 May 2015 07:22 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Wed, May 27, 2015 at 08:10:20PM +0530, Laxman Dewangan wrote:
>
> > Add callback on the regulator ops to get the voltage selection
> > register address and mask from device regulator driver. Use this
> > new callback in regulator_get_hardware_vsel_register().
> It's not entirely clear to me that this is a good idea - the expected
> use case for getting the vsel register is to hand it off to something
> like a microcontroller for it to use but if the vsel register might
> change at runtime then we also need infrastructure to synchronize those
> changes with whatever is using the register.  How does your system keep
> them in sync?

VOUT register address get changed based on DVS pin level. Say we have 
VOUT0 and VOUT1 register here for DVS pin state 0 and 1.
DVS pin can be used in two ways:
1. For dynamic voltage scaling and reducing the i2c command by using 
VOUT0 and VOUT1.
2. For sleep control like when rail is active, use the VOUT0 and when it 
is in sleep use the VOUT1 and control DVS for sleep entry/exit.
3. Some cases, DVS pin is tied to some level.

In our system, CPU-DFLL is another HW module which controls the CPU 
voltage based on CPU frequency request. It issues the i2c command to the 
device for voltage change when frequency get change. For this reason, 
CPU-DFLL need the VSEL register address. The CPU DVFS SW driver controls 
the DVS input pin to control sleep entry/exit and VOUT0 for voltage 
change. So on this case, we really donot need to change the VSEL 
register address for active state voltage change and use the DVS for 
sleep entry/exit.

The problem will be there when external controller use the DVS pin for 
DVFS and need two register address here. In this case, I think external 
controller need to get information from different mechanism rather than 
via regulator driver to avoid complication on regulator driver/framework.

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