summaryrefslogtreecommitdiffstats
path: root/include/linux/regulator/driver.h
Commit message (Collapse)AuthorAgeFilesLines
...
*-----. Merge remote-tracking branches 'regulator/topic/drivers', ↵Mark Brown2014-09-301-1/+11
|\ \ \ \ | | | | | | | | | | | | | | | 'regulator/topic/enable', 'regulator/topic/fan53555', 'regulator/topic/hi6421' and 'regulator/topic/isl9305' into regulator-next
| | | | * Merge branch 'topic/of' of ↵Mark Brown2014-09-101-0/+4
| | | |/| | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-isl9305
| | | | * regulator: of: Provide simplified DT parsing methodMark Brown2014-09-101-0/+4
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently regulator drivers which support DT all repeat very similar code to supply a list of known regulator identifiers to be matched with DT, convert that to platform data which is then matched up with the regulators as they are registered. This is both fiddly to get right and for devices which can use the standard helpers to provide their operations is the main source of code in the driver. Since this code is essentially identical for most drivers we can factor it out into the core, moving the identifiers in the match table into the regulator descriptors and also allowing drivers to pass in the name of the subnode to search. When a driver provides an of_match string for the regulator the core will attempt to use that to obtain init_data, allowing the driver to remove all explicit code for DT parsing and simply provide data instead. The current code leaks the phandles for the child nodes, this will be addressed incrementally and makes no practical difference for FDT anyway as the DT data structures are never freed. Signed-off-by: Mark Brown <broonie@linaro.org>
| | * | regulator: core: Add back the const qualifier for ops of struct regulator_descAxel Lin2014-08-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix below build warning: CC [M] drivers/regulator/hi6421-regulator.o drivers/regulator/hi6421-regulator.c:356:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] This is a revert of commit 716845ebeb50 ("regulator: core: Fix build error due to const qualifier for ops"). The build error was fixed by commit 39f5460d7f9c ("regulator: core: add const to regulator_ops and fix build error in mc13892"). Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| | * | regulator: core: Fix build error due to const qualifier for opsAxel Lin2014-08-181-1/+1
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Drop const qualifier for ops of struct regulator_desc. Allow regulator drivers to update ops before registering regulator. Fix below build error: CC [M] drivers/regulator/mc13892-regulator.o drivers/regulator/mc13892-regulator.c: In function 'mc13892_regulator_probe': drivers/regulator/mc13892-regulator.c:586:3: error: assignment of member 'set_mode' in read-only object drivers/regulator/mc13892-regulator.c:588:3: error: assignment of member 'get_mode' in read-only object make[2]: *** [drivers/regulator/mc13892-regulator.o] Error 1 make[1]: *** [drivers/regulator] Error 2 make: *** [drivers] Error 2 Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| | * regulator: core: add guard delay between calling regulator_disable and _enableGuodong Xu2014-08-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some regulator require a minimum delay between its disable and next enable. This is to avoid damages when out-of-range frequent disable/enable of a single regulator can bring to the regulator chip. Add @off_on_delay to struct regulator_desc. Device drivers' can use this field to set this guard time. Add @last_off_jiffy to struct regulator_dev. When @off_on_delay is set by driver, regulator core can store its last off (disable) time into this field. Signed-off-by: Guodong Xu <guodong.xu@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
| | * regulator: core: add const qualifier to ops in struct regulator_descGuodong Xu2014-08-161-1/+1
| |/ | | | | | | | | | | | | | | | | | | struct regulator_ops *ops is a member in struct regulator_desc, which gets its value from individual regulator driver upon regulator_register() and is used by regulator core APIs. It's not allowed for regulator core to modify any of these callbacks in *ops. Add 'const' qualifier to enforce that. Signed-off-by: Guodong Xu <guodong.xu@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
* / regulator: fix kernel-doc warnings in header filesRandy Dunlap2014-08-281-0/+2
|/ | | | | | | | | | | Fix kernel-doc warnings in regulator header files: Warning(..//include/linux/regulator/machine.h:140): No description found for parameter 'ramp_disable' Warning(..//include/linux/regulator/driver.h:279): No description found for parameter 'linear_ranges' Warning(..//include/linux/regulator/driver.h:279): No description found for parameter 'n_linear_ranges' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Mark Brown <broonie@linaro.org>
* regulator: helpers: Modify helpers enabling multi-bit controlCarlo Caione2014-03-061-0/+8
| | | | | | | | | | | | | | | | | | This patch extends the regulator helpers to account for device that use multiple bits for control when using regmap enable/disable/bypass ops. The actual regulator helpers wrongly assume that the regulator control is always performed using single bits, using in the regulator_desc struct only two parameters *_reg and *_mask defining register and mask for control. This patch extends this struct and introduces the helpers to take into account devices where control is performed using multiple bits and specific multi-bit values are used for enabling/disabling/bypassing the regulator. Signed-off-by: Carlo Caione <carlo@caione.org> Signed-off-by: Mark Brown <broonie@linaro.org>
* Merge remote-tracking branch 'regulator/topic/linear' into regulator-nextMark Brown2013-10-241-2/+9
|\
| * regulator: Add REGULATOR_LINEAR_RANGE macroAxel Lin2013-10-111-0/+9
| | | | | | | | | | | | | | Add REGULATOR_LINEAR_RANGE macro and convert regulator drivers to use it. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
| * regulator: Remove max_uV from struct regulator_linear_rangeAxel Lin2013-10-111-2/+0
| | | | | | | | | | | | | | | | | | linear ranges means each range has linear voltage settings. So we can calculate max_uV for each linear range in regulator core rather than set the max_uV field in drivers. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
* | Merge remote-tracking branch 'regulator/topic/fixed' into regulator-nextMark Brown2013-10-241-0/+2
|\ \
| * | regulator: core: provide fixed voltage in desc for single voltage railLaxman Dewangan2013-09-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If given rail has the single voltage (n_voltages = 1) then provide the rail voltage through regulator descriptor so that core can use this value for finding voltage. This will avoid the implementation of the callback for get_voltage() or list_voltage() callback on regulator driver. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
* | | Merge remote-tracking branch 'regulator/topic/alias' into regulator-nextMark Brown2013-10-241-0/+5
|\ \ \ | |_|/ |/| |
| * | regulator: core: Provide managed regulator registrationMark Brown2013-09-171-0/+5
| |/ | | | | | | | | | | | | | | | | Many regulator drivers have a remove function that consists solely of calling regulator_unregister() so provide a devm_regulator_register() in order to allow this repeated code to be removed and help eliminate error handling code. Signed-off-by: Mark Brown <broonie@linaro.org>
* / regulator: fix fatal kernel-doc errorRandy Dunlap2013-09-171-0/+2
|/ | | | | | | | | | Fix fatal kernel-doc error in <linux/regulator/driver.h>: Error(include/linux/regulator/driver.h:52): cannot understand prototype: 'struct regulator_linear_range ' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> [Rewrote first line -- broonie] Signed-off-by: Mark Brown <broonie@linaro.org>
* regulator: core: Add helpers for multiple linear rangesMark Brown2013-07-151-0/+25
| | | | | | | | | | | | | Many regulators have several linear ranges of selector with different step sizes, for example offering better resolution at lower voltages. Provide regulator_{map,list}_voltage_linear_range() allowing these regulators to use generic code. To do so a table of regulator_linear_range structs needs to be pointed to from the descriptor. This was inspired by similar code included in a driver submission from Chao Xie and Yi Zhang at Marvell. Signed-off-by: Mark Brown <broonie@linaro.org>
* Merge remote-tracking branch 'regulator/topic/gpio' into v3.9-rc8Mark Brown2013-04-281-2/+2
|\
| * regulator: core: use regulator_ena_pin memberKim, Milo2013-03-041-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The regulator_dev has regulator_enable_gpio structure. 'ena_gpio' and 'ena_gpio_invert' were moved to in regulator_enable_gpio. regulator_dev ---> regulator_enable_gpio .ena_gpio .gpio .ena_gpio_invert .ena_gpio_invert Pointer, 'ena_pin' is used for checking valid enable GPIO pin. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Reviewed-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
| * regulator: core: support shared enable GPIO conceptKim, Milo2013-03-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A Regulator can be enabled by external GPIO pin. This is configurable in the regulator_config. At this moment, the GPIO can be owned by only one regulator device. In some devices, multiple regulators are enabled by shared one GPIO pin. This patch extends this limitation, enabling shared enable GPIO of regulators. New list for enable GPIO: 'regulator_ena_gpio_list' This manages enable GPIO list. New structure for supporting shared enable GPIO: 'regulator_enable_gpio' The enable count is used for balancing GPIO control count. This count is incremented when GPIO is enabled. On the other hand, it's decremented when GPIO is disabled. Reference count: 'request_count' The reference count, 'request_count' is incremented/decremented on requesting/freeing the GPIO. This count makes sure only free the GPIO when it has no users. How it works If the GPIO is already used, skip requesting new GPIO usage. The GPIO is new one, request GPIO function and add it to the list of enable GPIO. This list is used for balancing enable GPIO count and pin control. Updating a GPIO and invert code moved 'ena_gpio' and 'ena_gpio_invert' of the regulator_config were moved to new function, regulator_ena_gpio_request(). Use regulator_enable_pin structure rather than regulator_dev. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Reviewed-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | Merge remote-tracking branch 'regulator/topic/enable-invert' into v3.9-rc8Mark Brown2013-04-281-0/+3
|\ \
| * | regulator: core: Add enable_is_inverted flag to indicate set enable_mask ↵Axel Lin2013-03-051-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bits to disable Add enable_is_inverted flag to indicate set enable_mask bits to disable when using regulator_enable_regmap and friends APIs. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Haojian Zhuang <haojian.zhuang@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | | regulator: core: Add regulator_map_voltage_ascend() APIAxel Lin2013-04-181-0/+2
|/ / | | | | | | | | | | | | | | | | | | | | | | A lot of regulator hardware has ascendant voltage list. This patch adds regulator_map_voltage_ascend() and export it. Drivers that have ascendant voltage list can use this as their map_voltage() operation, this is more efficient than default regulator_map_voltage_iterate() function. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* / regulator: core: update kernel documentation for regulator_descNishanth Menon2013-03-011-0/+2
|/ | | | | | | | | | | | | | | | | commit df367931 (regulator: core: Provide regmap get/set bypass operations) introduced regulator_[gs]et_bypass_regmap However structure documentation for regulator_desc needs an update. ./scripts/kernel-doc include/linux/regulator/driver.h >/dev/null generates: Warning(include/linux/regulator/driver.h:233): No description found for parameter 'bypass_reg' Warning(include/linux/regulator/driver.h:233): No description found for parameter 'bypass_mask' Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: linux-kernel@vger.kernel.org Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* regulator: core: Allow specify apply_[reg|bit] for regmap based voltage_sel ↵Axel Lin2012-12-241-0/+6
| | | | | | | | | | | | | operations Some DVM regulators needs to update apply_bit after setting vsel_reg to initiate voltage change on the output. This patch adds apply_reg and apply_bit to struct regulator_desc and update regulator_set_voltage_sel_regmap() to set apply_bit of apply_reg when apply_bit is set. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* Merge remote-tracking branch 'regulator/topic/min' into regulator-nextMark Brown2012-12-101-0/+2
|\
| * regulator: core: Allow specific minimal selector for starting linear mappingAxel Lin2012-11-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some drivers (at least 3 drivers) have such variant of linear mapping that the first few selectors are invalid and the reset are linear mapping. Let's support this case in core. This patch adds linear_min_sel in struct regulator_desc, so we can allow specific minimal selector for starting linear mapping. Then extends regulator_[map|list]_voltage_linear() to support this feature. Note that for selectors less than min_linear_index, we need count them to n_voltages so regulator_list_voltage() won't fail while checking the boundary for selector before calling list_voltage callback. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | regulator: core: Support for continuous voltage rangePawel Moll2012-10-151-0/+3
|/ | | | | | | | | | | Some regulators can set any voltage within the constraints range, not being limited to specified operating points. This patch makes it possible to describe such regulator and makes the regulator_is_supported_voltage() function behave correctly. Signed-off-by: Pawel Moll <pawel.moll@arm.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
*---. Merge remote-tracking branches 'regulator/topic/core', ↵Mark Brown2012-09-281-1/+17
|\ \ \ | | | | | | | | | | | | 'regulator/topic/bypass', 'regulator/topic/tol', 'regulator/topic/drivers' and 'regulator/topic/tps6586x' into regulator-next
| | | * regulator: Update comment for set_current_limit callback of struct regulator_opsAxel Lin2012-08-281-0/+1
| |_|/ |/| | | | | | | | | | | | | | | | | | | | The regulators should be tending to the maximum in the available range and consumers should specify the widest range possible. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
| | * regulator: core: Provide regmap get/set bypass operationsMark Brown2012-09-101-0/+4
| | | | | | | | | | | | Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
| | * regulator: core: Support bypass modeMark Brown2012-09-101-0/+10
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many regulators support a bypass mode where they simply switch their input supply to the output. This is mainly used in low power retention states where power consumption is extremely low so higher voltage or less clean supplies can be used. Support this by providing ops for the drivers and a consumer API which allows the device to be put into bypass mode if all consumers enable it and the machine enables permission for this. This is not supported as a mode since the existing modes are rarely used due to fuzzy definition and mostly redundant with modern hardware which is able to respond promptly to load changes. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by: Graeme Gregory <gg@slimlogic.co.uk>
| * regulator: Clarify documentation for regmap in the configMark Brown2012-08-311-1/+2
|/ | | | Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* Merge branch 'regulator-drivers' into regulator-nextMark Brown2012-07-221-0/+23
|\
| * regulator: core: Add core support for GPIO controlled enable linesMark Brown2012-07-031-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is very common for regulators to support having their enable signal controlled by a GPIO. Since there are a bunch of fiddly things to get right like handling the operations when the enable signal is tied to a rail and it's just replicated code add support for this to the core. Drivers should set ena_gpio in their config if they have a GPIO control, using ena_gpio_flags to specify any flags (including GPIOF_OUT_INIT_ for the initial state) and ena_gpio_invert if the GPIO is active low. The core will then override any enable and disable operations the driver has and instead control the specified GPIO. This will in the future also allow us to further extend the core by identifying when several enable signals have been tied together and handling this properly. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
| * regulator: core: Allow fixed enable_time to be set in the regulator_descMark Brown2012-07-031-0/+4
| | | | | | | | | | | | | | | | Many regulators have a fixed specification for their enable time. Allow this to be set in the regulator_desc as a number to save them having to implement an explicit operation. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
| * regulator: core: Change the unit of ramp_delay from mV/uS to uV/uSAxel Lin2012-06-181-1/+1
| | | | | | | | | | | | | | | | This change makes it possible to set ramp_delay with 0.xxx mV/uS without truncation issue. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
| * regulator: Add ramp_delay configuration to constraintsYadwinder Singh Brar2012-06-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For some hardwares ramp_delay for BUCKs is a configurable parameter which can be configured through DT or board file.This patch adds ramp_delay to regulator constraints and allow user to configure it for regulators which supports this feature, through DT or board file. It will provide two ways of setting the ramp_delay for a regulator: First, by setting it as constraints in board file(for configurable regulators) and set_machine_constraints() will take care of setting it on hardware by calling(the provided) .set_ramp_delay() operation(callback). Second, by setting it as data in regulator_desc(as fixed/default ramp_delay rate) for a regulator in driver. regulator_set_voltage_time_sel() will give preference to constraints->ramp_delay while reading ramp_delay rate for regulator. Similarly users should also take care accordingly while refering ramp_delay rate(in case of implementing their private .set_voltage_time_sel() callbacks for different regulators). [Rewrote subject for 80 columns -- broonie] Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
| * regulator: core: Add regulator_set_voltage_time_sel to calculate ramp delay.Yadwinder Singh Brar2012-06-111-0/+5
| | | | | | | | | | | | | | | | | | | | This patch adds regulator_set_voltage_time_sel(), to move into core, the commonly used code by drivers to provide the .set_voltage_time_sel callback. It will also allow us to configure different ramp delay for different regulators easily. Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | regulator: Add REGULATOR_STATUS_UNDEFINED.Krystian Garbaciak2012-07-121-0/+2
|/ | | | | | | | REGULATOR_STATUS_UNDEFINED is to be returned by regulator, if any other state doesn't really apply. Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* regulator: core: Allow drivers to set voltage mapping table in regulator_descAxel Lin2012-06-031-0/+5
| | | | | | | | | | Some regulator hardware use table based mapping can set volt_table in regulator_desc and use regulator_list_voltage_table() for their list_voltage callback. Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* regulator: core: Allow drivers to set simple linear voltage maps as dataMark Brown2012-05-121-2/+13
| | | | | | | | | | | | | | 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 <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* regulator: core: Allow regulators to provide a voltage to selector mappingMark Brown2012-05-121-0/+4
| | | | | | | | | | | | 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 <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* regulator: core: Provide standard enable operations for regmap usersMark Brown2012-04-161-0/+7
| | | | | | | | | | | | | | | | 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 <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* regulator: core: Provide regmap based voltage_sel operationsMark Brown2012-04-161-0/+9
| | | | | | | | | | | | | | | | 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 <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* regulator: core: Allow drivers to pass in a regmapMark Brown2012-04-161-0/+4
| | | | | | | | | 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 <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* regulator: core: Use a struct to pass in regulator runtime configurationMark Brown2012-04-091-5/+26
| | | | | | | | | | | | | | 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 <broonie@opensource.wolfsonmicro.com>
* regulator: core: Constify the regulator_desc passed in when registeringMark Brown2012-04-041-2/+3
| | | | | | | | 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 <broonie@opensource.wolfsonmicro.com>
* regulator: Remove ifdefs for debugfs codeStephen Boyd2012-02-211-2/+0
| | | | | | | | | | | | | 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 <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
OpenPOWER on IntegriCloud