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: <5567FE68.5070006@nvidia.com>
Date:	Fri, 29 May 2015 11:21:36 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Mark Brown <broonie@...nel.org>
CC:	<lgirdwood@...il.com>, <linux-kernel@...r.kernel.org>,
	<cfreeman@...dia.com>, <abrestic@...omium.org>, <afrid@...dia.com>
Subject: Re: [PATCH 1/2] regulator: core: add support to get VSEL register
 from hw driver


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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ