On Wed, Apr 13, 2011 at 02:43:21PM +0100, Liam Girdwood wrote: > On Wed, 2011-04-13 at 14:22 +0200, Michael Hennerich wrote: > > Contrast control for LC Displays typically use negative voltages, too > > I agree that demand for this on typical mobile devices is low, however > > we like Yeah, that and the eInk displays are the only application I'm aware of. > > to use the regulator framework in the IIO subsystem where negative voltages > > are quite common. Are these regulators software controlled? > > Updating the core to allow negative and zero voltages, is not straight > > forward. > > There are more issues with constrain checking and I currently can't > > oversee all side What are the issues that you see? > > effects. I think we need to introduce a new constrains flag > > (maybe add to valid_modes_mask?), indicating a bipolar regulator. > > This flag is then used to keep the current implementation untouched for > > unipolar positive > > regulators. > My preference is to keep it simple and the API consistent with unipolar > regulators. I agree, though if people do ever use the same regulators for both polarities (with the polarity determined by supply) then we'll need a way of dealing with this in the constraints as the regulators might not know they're running negative voltages with respect to the system. > One of the problem areas will be regulator_get_voltage() since it > returns negative errors. It may be desirable to deprecate this API call > in favour of a new call that we pass in an int for the voltage (e.g. > get_voltage(reg, &voltage)). I'm not sure deprecating it is ideal - it's quite a convenient API. We could just implement a new API and leave that one as an adaption layer. Transition issues would mean that we'd want to do that for at least one kernel release anyway. -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
