Re: Power Domain Framework

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux