RFC: Regulator Framework Voltage Setting
in [Kernel]
|
Prev: [PATCH 6/9] PM / Hibernate: split snapshot_read_next
Next: [PATCH 5/5] Document unknown_nmi_dump_log variable
From: Linus WALLEIJ on 2 Jun 2010 05:20 Hello, we have a question regarding the regulator_set_voltage function in the regulator framework (drivers/regulator/core.c). The current implementation checks the input min and max arguments against the constraints and then calls the driver set_voltage operation directly without checking the other consumer requests. In our view it should respect all consumer voltage settings. Then, the implementation would (roughly) be to iterate through all consumers and make sure all of their latest requests are satisfied. Our questions: - Is this the correct interpretation of the current functionality? - Is the proposed behaviour what you would expect? - Any other problems to consider? Below we have given an example to clarify. Best regards, Bengt JONSSON Sundar R IYER Linus WALLEIJ Here is an example with three users (consumers) connected to the same regulator_dev: rdev ------ xreg (User X) |--- yreg (User Y) |--- zreg (User Z) The users call the regulator framework like this: 1. User X calls regulator_set_voltage(xreg, 2000000, 3000000) 2. User Y calls regulator_set_voltage(yreg, 2100000, 3100000) 3. User Z calls regulator_set_voltage(zreg, 1900000, 2900000) 4. User Y calls regulator_set_voltage(yreg, 1900000, 3100000) 5. User Z calls regulator_set_voltage(zreg, 1900000, 3100000) 6. User X calls regulator_set_voltage(xreg, 4000000, 5000000). Here the call should fail. Assuming there are no constraints, with current implementation, the requests would be sent unchanged to the driver. What we would expect from the regulator framework is this: 1. The framework calls rdev->desc->ops->set_voltage(rdev, 2000000, 3000000) 2. The framework calls rdev->desc->ops->set_voltage(rdev, 2100000, 3000000) 3. The framework calls rdev->desc->ops->set_voltage(rdev, 2100000, 2900000) 4. The framework calls rdev->desc->ops->set_voltage(rdev, 2000000, 2900000) 5. The framework calls rdev->desc->ops->set_voltage(rdev, 2000000, 3000000) 6. Failed because the ranges do not overlap. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mark Brown on 2 Jun 2010 06:10
On Wed, Jun 02, 2010 at 11:18:00AM +0200, Linus WALLEIJ wrote: > Our questions: > - Is this the correct interpretation of the current functionality? > - Is the proposed behaviour what you would expect? > - Any other problems to consider? The current expectation is that a consumer that really needs a voltage setting will have exclusive use of the regulator and won't share it with other consumers. There was some support for combining constraints from multiple consumers originally but it got removed due to requests from David Brownell (there's not actually much demand for this feature anyway, finding devices which support but do not required DVS is actually quite hard and generally the power requirments for shared rails get fixed at hardware build tiem). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |