regulator voltage aggregation
I'm looking to upstream a new feature in which the regulator core
aggregates voltage requests from multiple consumers and applies the best
fitting voltage (e.g. max voltage) to a shared supply. The core would
recompute the best fitting voltage when a consumer requests a voltage
change or requests to enable/disable the regulator (similar logic to
DRMS).
The reason we need this feature is for power savings. It would allow two
or more consumers to vote on a voltage that's lower than the normal
operating voltage.
I've got a couple implementations in mind.
1. Introduce a new API:
int regulator_set_optimum_voltage(struct regulator *regulator,
int min_uV, int max_uV);
2. Add a flag to the regulation_constraints structure and reuse the
existing regulator_set_voltage API.
struct regulation_constraints {
...
unsigned aggregate_uV:1;
...
};
Does this sound like a reasonable feature? And if so, are there any
preferences as to how the feature is implemented and exposed?
Bobby Crabtree
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] input: mouse: add qci touchpad driver
Hi Neil, On Aug 17, 2010, at 10:14 AM, Neil Leeder nlee...@codeaurora.org wrote: On 8/13/2010 8:54 PM, Dmitry Torokhov wrote: Also it is not a simple coincidence that to enable device you send 0xf4 to it (which is PSMOUSE_CMD_ENABLE - standard PS/2 command). This tends to suggest that interface is not actually hidden and that the device (touchpad) could be replaced with other kinds of devices. Anyway, please try the driver (you may need to hardcode the IRQ trigger type for now) and see if psmouse is able to talk to the touchpad. If it is then serio is the proper solution. Dmitri, I fixed one line in the wpce775x_serio driver which looked like a typo - hope I got that right: for (i = 0; i count; i++) -serio_interrupt(ps2if-serio, ps2if-data_in[1], 0); +serio_interrupt(ps2if-serio, ps2if-data_in[i], 0); } Yep, that was a typo. I tried running with psmouse but it didn't work. The touchpad was never detected as a synaptics touchpad. I looked at the dataflow from the device and it wasn't responding to the commands that synaptics_detect() was sending it. It eventually showed up as an unknown logitech mouse. That suggests that the device responds to at least basic PS/2 queries. I can see data being passed through the serio driver but the logitech driver can't process it. What about loading psmouse module with proto=bare? Could you also dump the data received from touchpad during probing? -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regulator voltage aggregation
On Tue, Aug 17, 2010 at 11:06:10AM -0700, Bobby Crabtree wrote:
I'm looking to upstream a new feature in which the regulator core
aggregates voltage requests from multiple consumers and applies the best
fitting voltage (e.g. max voltage) to a shared supply. The core would
It's unlikely that the highest voltage would ever be the best choice...
recompute the best fitting voltage when a consumer requests a voltage
change or requests to enable/disable the regulator (similar logic to
DRMS).
The reason we need this feature is for power savings. It would allow two
or more consumers to vote on a voltage that's lower than the normal
operating voltage.
This was actually a feature of the regulator API when originally
proposed, it got dropped for ease of review but there's some remanants
of this in the code so it shouldn't be hard to resurrect. Whenever a
voltage was set the code stored the range on the consumer then iterated
over all consumers applying their ranges plus the machine constraints
rather than just using the immediate value.
1. Introduce a new API:
int regulator_set_optimum_voltage(struct regulator *regulator,
int min_uV, int max_uV);
Why would you want to do this? This is just the same arguments as the
standard regulator_set_voltage() call and if we're ever setting anything
other than the optimal voltage we probably ought to just stop doing
that.
2. Add a flag to the regulation_constraints structure and reuse the
existing regulator_set_voltage API.
struct regulation_constraints {
...
unsigned aggregate_uV:1;
...
};
Does this sound like a reasonable feature? And if so, are there any
preferences as to how the feature is implemented and exposed?
If we were going to add something for this it should be a capability,
however I don't think there's any need to add anything to the API since
this is the only sane interpretation of allowing voltage changes on a
regulator with more than one consumer.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regulator voltage aggregation
Mark Brown wrote: On Tue, Aug 17, 2010 at 11:06:10AM -0700, Bobby Crabtree wrote: I'm looking to upstream a new feature in which the regulator core aggregates voltage requests from multiple consumers and applies the best fitting voltage (e.g. max voltage) to a shared supply. The core would It's unlikely that the highest voltage would ever be the best choice... We do need the highest voltage. Let's say we have two consumers (A and B). Both require 1.3V for normal operations. Then let's say that consumer A can save power by reducing the voltage to 1.1V (but it doesn't require 1.1V). If the core were to immediately apply 1.1V, then the 1.3V requirement of consumer B would not be satisfied. recompute the best fitting voltage when a consumer requests a voltage change or requests to enable/disable the regulator (similar logic to DRMS). The reason we need this feature is for power savings. It would allow two or more consumers to vote on a voltage that's lower than the normal operating voltage. This was actually a feature of the regulator API when originally proposed, it got dropped for ease of review but there's some remanants of this in the code so it shouldn't be hard to resurrect. Whenever a voltage was set the code stored the range on the consumer then iterated over all consumers applying their ranges plus the machine constraints rather than just using the immediate value. I noticed some of the remnants. But I'm not sure I follow what you are saying. What range would the core actually propagate to the driver? The minimum min_uV and the maximum max_uV? We need the core to propagate the maximum min_uV and the maximum max_uV. 1. Introduce a new API: int regulator_set_optimum_voltage(struct regulator *regulator, int min_uV, int max_uV); Why would you want to do this? This is just the same arguments as the standard regulator_set_voltage() call and if we're ever setting anything other than the optimal voltage we probably ought to just stop doing that. Optimum was a bad choice of words. Seems that a new API isn't preferred, so let's scrap this option. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
