Re: [linux-pm] Power Domain Framework
From: Mark Brown
Date: Mon May 17 2010 - 13:04:43 EST
On Mon, 2010-05-17 at 22:05 +0530, Sundar R Iyer wrote:
> +/* locks held by regulator_set_operating_point() */
> +static int _regulator_set_operating_point(struct regulator_dev *rdev,
> + unsigned int opp)
> +{
> + int ret, regulator_curr_opp = 0;
> +
> + if (!(rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_OPP)) {
> + printk(KERN_ERR "%s: operation not allowed for %s\n",
> + __func__, rdev->desc->name);
> + return -EPERM;
> + }
> +
> + /* sanity checks */
> + if (!rdev->desc->ops->set_operating_point) {
> + return -EINVAL;
> + }
> +
> + if (rdev->desc->ops->get_operating_point)
> + regulator_curr_opp = rdev->desc->ops->get_operating_point(rdev);
> +
> + /* we have no issues with upgrading the opp */
> + if (opp == REGULATOR_OPERATINGPOINT_FULL) {
> + if (rdev->constraints->opp_constraint_count < 1) {
> + if (rdev->supply)
> + ret = _regulator_set_operating_point(rdev->supply, opp);
> + ret = rdev->desc->ops->set_operating_point(rdev, opp);
> + }
> + rdev->constraints->opp_constraint_count++;
> + }
This implementation is assuming that the implementation in hardware only
has two levels, and that the decision to go to the higher level is done
by a simple or of requests for the full level from the consumers. I'm
not convinced that this will be true in general, or that it's always
going to be true that the different power domains are all isolated from
each other. There doesn't seem to be any immediate reason why hardware
won't ever implement more than two modes, and I'm not convinced that the
straight or of requests will always be sufficient to determine the
operating mode for the entire power domain. For example, I can see
hardware requiring that if more than a given number of blocks are
enabled at any level a higher operating point is selected.
Are you sure that this interface is sufficiently general to work with
all hardware, not just your own? How does this map on to the OMAP or SH
hardware, for example?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/