[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On 4/2/2012 2:22 PM, Mark Brown wrote:
On Mon, Apr 02, 2012 at 10:35:22AM -0700, Michael Bohan wrote:Some of our regulators take inputs from other regulators. Some regulators take their input from the battery. We support both typesOh, if that's all it is that's totally normal and unsurprising. Just tell the regulator API about the battery supply, typically people use a fixed regulator for this. You don't have to specify a voltage when you use them.
One problem here is the added run-time overhead. This includes the callbacks for the battery device which serve no functional purpose. And then there's the contention for a single mutex on the battery regulator, which all regulators using it as a supply would have to contend for. That is actually a sizable number of devices in our configuration; And these operations are frequent and time sensitive.
Plus, then there's other complexities that arise here by introducing yet another regulator driver into the configuration. The 'fixed' regulator driver initializes at subsys_initcall, but our other regulator drivers are registered at arch_initcall. This is because with Device Tree configurations we are forced to explicitly register drivers in a precise sequence in order to satisfy device dependencies and early probe times. But using 'fixed' would complicate this process, since we don't have control over it.
And generally speaking, why incur a larger memory footprint by linking another driver when there's no technical need to?
Thus it seems like there are use cases to have a single driver that can support regulators with or without supplies specified. I see adding a few lines of ugly code in the driver more ideal than accepting the problems above. But it would be nice if the regulator Device Tree support could handle it natively.
Thanks, Mike -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html