On Tue, Jul 09, 2013 at 11:04:23AM -0500, Nishanth Menon wrote:
On 07/09/2013 10:29 AM, Mark Brown wrote:
This seems like something we should be able to cope with by for example
adding a bus for the custom PMIC interface or otherwise finding a way to
I had considered introducing a custom bus
On Mon, Jul 08, 2013 at 12:22:36PM -0500, Nishanth Menon wrote:
case #1 - TPS62361 has a single SMPS and a single generic i2c bus,
one can talk on. In this case, you'd associate the regulator device
in one place - i2cX or on custom SoC hardware interface.
When used with custom SoC hardware
On 07/09/2013 10:29 AM, Mark Brown wrote:
On Mon, Jul 08, 2013 at 12:22:36PM -0500, Nishanth Menon wrote:
case #1 - TPS62361 has a single SMPS and a single generic i2c bus,
one can talk on. In this case, you'd associate the regulator device
in one place - i2cX or on custom SoC hardware
On 07/05/2013 12:47 PM, Mark Brown wrote:
On Fri, Jul 05, 2013 at 12:33:10PM -0500, Nishanth Menon wrote:
Taking an example of twl-regulator and omap_pmic, are you suggesting
omap_pmic to be a user twl-regulator using
include/linux/regulator/consumer.h? or are you suggesting that
omap_pmic
On 16:41-20130704, Mark Brown wrote:
On Fri, Jun 21, 2013 at 04:25:42PM -0500, Nishanth Menon wrote:
+static const struct omap_pmic_info omap_twl4030_vdd1 = {
+ .slave_addr = 0x12,
+ .voltage_reg_addr = 0x00,
+ .cmd_reg_addr = 0x00,
+ .i2c_timeout_us = 200,
+ .slew_rate_uV
On Fri, Jul 05, 2013 at 08:55:07AM -0500, Nishanth Menon wrote:
Please write in paragraphs, an enormous wall of unbroken text isn't
helpful for legibility.
On 16:41-20130704, Mark Brown wrote:
So, this still has the thing where all the data about the PMIC is
replicated (but now in this
On 07/05/2013 09:08 AM, Mark Brown wrote:
On Fri, Jul 05, 2013 at 08:55:07AM -0500, Nishanth Menon wrote:
Please write in paragraphs, an enormous wall of unbroken text isn't
helpful for legibility.
Apologies on the same. Will try to do better.
On 16:41-20130704, Mark Brown wrote:
So,
On Fri, Jul 05, 2013 at 09:50:34AM -0500, Nishanth Menon wrote:
On 07/05/2013 09:08 AM, Mark Brown wrote:
option 1) we just bypass get_voltage/set_voltage to point through to
this function. result will be something similar to what we got here[1]
I don't really know what you mean when you say
On 07/05/2013 11:52 AM, Mark Brown wrote:
On Fri, Jul 05, 2013 at 09:50:34AM -0500, Nishanth Menon wrote:
On 07/05/2013 09:08 AM, Mark Brown wrote:
option 1) we just bypass get_voltage/set_voltage to point through to
this function. result will be something similar to what we got here[1]
I
On Fri, Jul 05, 2013 at 12:33:10PM -0500, Nishanth Menon wrote:
Taking an example of twl-regulator and omap_pmic, are you suggesting
omap_pmic to be a user twl-regulator using
include/linux/regulator/consumer.h? or are you suggesting that
omap_pmic should not be a regulator at all?
No, I'm
On Fri, Jun 21, 2013 at 04:25:42PM -0500, Nishanth Menon wrote:
+static const struct omap_pmic_info omap_twl4030_vdd1 = {
+ .slave_addr = 0x12,
+ .voltage_reg_addr = 0x00,
+ .cmd_reg_addr = 0x00,
+ .i2c_timeout_us = 200,
+ .slew_rate_uV = 4000,
+ .step_size_uV =
Texas Instrument's OMAP SoC generations since OMAP3-5 introduced
an TI custom hardware block to better facilitate and standardize
integration of Power Management ICs which communicate over I2C.
In fact, many custom PMICs were designed to be usable over this
interface. On the other hand, generic
12 matches
Mail list logo
