kernel/linux.git/include/linux/regulator/driver.h, branch v3.5.3

regulator: core: Allow drivers to set simple linear voltage maps as data

2012-05-12T10:11:32+00:00

A lot of regulator hardware maps selectors on to voltages with a simple linear mapping function selector = base + (selector * step size) Provide off the shelf list_voltage() and map_voltage() operations which use new min_uV and uV_step members in the regulator_desc to implement this function. Signed-off-by: Mark Brown Acked-by: Liam Girdwood

regulator: core: Allow regulators to provide a voltage to selector mapping

2012-05-12T10:11:23+00:00

In order to allow more drivers to factor things out into data allow drivers to provide a mapping function to convert voltages into selectors. This allows any driver to use set_voltage_sel(). The existing mapping based on iterating over list_voltage() is provided as an operation which can be assigned to the new map_voltage() function though for ease of transition it is treated as the default. Signed-off-by: Mark Brown Acked-by: Liam Girdwood

regulator: core: Provide standard enable operations for regmap users

2012-04-16T18:52:42+00:00

Since the enable(), disable() and is_enabled() operations for most regmap based regulators come down to reading and updating a single register bit we can factor out the code and allow these drivers to just define which bit to update using the enable_reg and enable_mask fields in their desc and then use operations provided by the core. As well as the code saving this opens the door to future optimisation of the bulk operations - if the core can realise that we are updating a single register for multiple regulators then it should be able to combine these updates into a single physical operation. Signed-off-by: Mark Brown Acked-by: Liam Girdwood

regulator: core: Provide regmap based voltage_sel operations

2012-04-16T18:52:03+00:00

Since the voltage selector operations are intended to directly map a bitfield in the device register map into regulator API operations the code for implementing them is usually very standard we can save some code by providing standard implementations for devices using the regmap API. Drivers using regmap can pass their regmap in in the regmap_config struct, set vsel_reg and vsel_mask in their regulator_desc and then use regulator_{get,set}_voltage_sel_regmap in their ops. This saves a small amount of code from each driver. Signed-off-by: Mark Brown Acked-by: Liam Girdwood

regulator: core: Allow drivers to pass in a regmap

2012-04-16T18:51:53+00:00

Since many regulators use regmap for register I/O and since there's quite a few very common patterns in the code allow drivers to pass in a regmap to the core for use in generic code. Signed-off-by: Mark Brown Acked-by: Liam Girdwood

regulator: core: Use a struct to pass in regulator runtime configuration

2012-04-09T11:37:09+00:00

Rather than adding new arguments to regulator_register() every time we want to add a new bit of dynamic information at runtime change the function to take these via a struct. By doing this we avoid needing to do further changes like the recent addition of device tree support which required each regulator driver to be updated to take an additional parameter. The regulator_desc which should (mostly) be static data is still passed separately as most drivers are able to configure this statically at build time. Signed-off-by: Mark Brown

regulator: core: Constify the regulator_desc passed in when registering

2012-04-04T10:43:26+00:00

Drivers should be able to declare their descriptors const and the framework shouldn't ever be modifying the desciptor. Make the parameter and the pointer in regulator_dev const to enforce this. Signed-off-by: Mark Brown

regulator: Remove ifdefs for debugfs code

2012-02-21T09:56:51+00:00

If CONFIG_DEBUG_FS=y debugfs functions will never return an ERR_PTR. Instead they'll return NULL. The intent is to remove ifdefs in calling code. Update the code to reflect this. We gain an extra dentry pointer per struct regulator and struct regulator_dev but that should be ok because most distros have debugfs compiled in anyway. Signed-off-by: Stephen Boyd Signed-off-by: Mark Brown

regulator: fix wrong header name in description

2012-02-17T07:08:32+00:00

The 'mode' is defined in consumer.h. * patch base version : linux-3.2.4 Signed-off-by: Milo(Woogyom) Kim Signed-off-by: Mark Brown

regulator: map consumer regulator based on device tree

2011-11-23T18:47:31+00:00

Device nodes in DT can associate themselves with one or more regulators/supply by providing a list of phandles (to regulator nodes) and corresponding supply names. For Example: devicenode: node@0x0 { ... ... vmmc-supply = <®ulator1>; vpll-supply = <®ulator2>; }; The driver would then do a regulator_get(dev, "vmmc"); to get regulator1 and do a regulator_get(dev, "vpll"); to get regulator2. of_get_regulator() extracts the regulator node for a given device, based on the supply name. Use it to look up the regulator for a given consumer from device tree, during a regulator_get(). If not found fallback and lookup through the regulator_map_list instead. Also, since the regulator dt nodes can use the same binding to associate with a parent regulator/supply, allow the drivers to specify a supply_name, which can then be used to lookup dt to find the parent phandle. Signed-off-by: Rajendra Nayak Acked-by: Grant Likely Signed-off-by: Mark Brown