On Fri, May 13, 2011 at 09:27:03AM -0700, David Collins wrote: > vreg = regulator_get(dev, "foo_vdd"); > regulator_set_voltage(vreg, 1000000, 2000000); > regulator_set_optimum_mode(vreg, 50000); > regulator_enable(vreg); > The problem that arises is that the "regulator" it is supplied by may in > fact be a voltage switch. The driver for this switch is set up so that > only enable, disable, and is_enabled callbacks are specified. This has > the effect of making all regulator_set_voltage and > regulator_set_optimum_mode calls return an error. The switch driver should be doing a better job here, at least reporting the voltage that the parent has. This is going to need core support to dance around the locking, we need a property the driver can set to say that it is a voltage switch. In fact, we ideally need a dynamic thing which the driver can set at runtime as some regulators have passthrough modes. As with several of the other things it'd be really helpful if you could provide actual system examples - without seeing the system it's hard to know what makes sense. My first question looking at your above code is why a consumer which cares if it's setting the mode is sharing a regulator with other devices in the system in the first place - as I'm fairly sure I've mentioned previously you're then relying on every device involved participating in optimising the mode which is in general optimistic. I'm guessing from a grep of the kernel that this is for your OTG driver? For set_optimum_mode() I'd not expect the consumer driver to care too much about failures unless it's succesfully lowered the optimum mode in the past and is trying to raise things. I'll just send a patch out which makes us report success if there's no support for set_mode(), it's mostly ornamental anyway. I've sent a patch for that. > Is there a mechanism in the regulator framework that will allow a consumer > to determine if these APIs are available for a given regulator? For the voltage setting the consumer driver can enumerate the range of voltages which it can set - if it can't control voltage this should come out as the empty set. The consumer is going to need to know about particular voltages as well as the general ability to set voltages at all. This is good practice anyway to ensure the consumer interoperates well with boards that don't allow them the full range of voltages they may want or with regulators with coarse grained voltage steps. For the mode optimisation the patch I sent should mean that the API is always available. > I considered changing the switch drivers to provide dummy voltage and mode > callbacks. The voltage range would then be any positive integer > (including 0). However, this results in a problem if one consumer calls This obviously isn't at all good - it's totally not what the consumer asked for and it's not really useful as we're not joined up with anything else in the parent domain, including basic error checking if the parent domain voltage is allowed to vary. > only regulator_enable and then a second consumer calls > regulator_set_voltage with some range, perhaps [1000000, 2000000], > followed by regulator_enable. regulator_check_consumers will fail inside > of regulator_set_voltage for the second consumer because the implicit [0, > 0] request of the first consumer does not overlap [1000000, 2000000]. This just seems like a generic and largely unrelated issue; it's just that you can't have consumers that set and don't set voltages sharing a regulator. I've sent a patch which should address the issue. -- 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
