summaryrefslogtreecommitdiffstats
path: root/drivers/regulator/core.c
Commit message (Collapse)AuthorAgeFilesLines
...
| * | regulator: make the dummy regulator's print_constraint more helpfulUwe Kleine-König2012-08-081-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This prevents the output of just dummy: in the boot log. Now it says: regulator-dummy: no parameters which at least doesn't make it look like an accidental printk and also doesn't only use "dummy" which could mean anything. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
| * | regulator: core: Fix cast to pointer from integer of different size warningAxel Lin2012-08-071-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is to address the following warning during compilation time: (Compile on x86_64) CC drivers/regulator/core.o drivers/regulator/core.c: In function '_regulator_do_set_voltage': drivers/regulator/core.c:2183:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] This patch adds a temporary variable to avoid double cast. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
| * | regulator: core: increment open_count when regulator supply is setLaxman Dewangan2012-08-041-0/+1
| |/ | | | | | | | | | | | | | | When registering the regulator and setting supply for the regulator then increment open_count to reflect correct number of users. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* / regulator: core: request only valid gpio pins for regulator enableMarek Szyprowski2012-08-091-1/+1
|/ | | | | | | | | | | | | Commit 65f735082de3 ("regulator: core: Add core support for GPIO controlled enable lines") introduced enable gpio entry in regulator configuration structure. Some drivers use '-1' as a placeholder for marking that such gpio line is not available, because '0' is considered as a valid gpio number. This patch fixes initialization of such drivers (like MAX8952 on UniversalC210 board), when '-1' is provided as enable gpio pin in the regulator's platform data. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds2012-07-241-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull first round of SCSI updates from James Bottomley: "The most important feature of this patch set is the new async infrastructure that makes sure async_synchronize_full() synchronizes all domains and allows us to remove all the hacks (like having scsi_complete_async_scans() in the device base code) and means that the async infrastructure will "just work" in future. The rest is assorted driver updates (aacraid, bnx2fc, virto-scsi, megaraid, bfa, lpfc, qla2xxx, qla4xxx) plus a lot of infrastructure work in sas and FC. Signed-off-by: James Bottomley <JBottomley@Parallels.com>" * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (97 commits) [SCSI] Revert "[SCSI] fix async probe regression" [SCSI] cleanup usages of scsi_complete_async_scans [SCSI] queue async scan work to an async_schedule domain [SCSI] async: make async_synchronize_full() flush all work regardless of domain [SCSI] async: introduce 'async_domain' type [SCSI] bfa: Fix to set correct return error codes and misc cleanup. [SCSI] aacraid: Series 7 Async. (performance) mode support [SCSI] aha152x: Allow use on 64bit systems [SCSI] virtio-scsi: Add vdrv->scan for post VIRTIO_CONFIG_S_DRIVER_OK LUN scanning [SCSI] bfa: squelch lockdep complaint with a spin_lock_init [SCSI] qla2xxx: remove unnecessary reads of PCI_CAP_ID_EXP [SCSI] qla4xxx: remove unnecessary read of PCI_CAP_ID_EXP [SCSI] ufs: fix incorrect return value about SUCCESS and FAILED [SCSI] ufs: reverse the ufshcd_is_device_present logic [SCSI] ufs: use module_pci_driver [SCSI] usb-storage: update usb devices for write cache quirk in quirk list. [SCSI] usb-storage: add support for write cache quirk [SCSI] set to WCE if usb cache quirk is present. [SCSI] virtio-scsi: hotplug support for virtio-scsi [SCSI] virtio-scsi: split scatterlist per target ...
| * [SCSI] async: introduce 'async_domain' typeDan Williams2012-07-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is in preparation for teaching async_synchronize_full() to sync all pending async work, and not just on the async_running domain. This conversion is functionally equivalent, just embedding the existing list in a new async_domain type. The .registered attribute is used in a later patch to distinguish between domains that want to be flushed by async_synchronize_full() versus those that only expect async_synchronize_{full|cookie}_domain to be used for flushing. [jejb: add async.h to scsi_priv.h for struct async_domain] Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Arjan van de Ven <arjan@linux.intel.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Tested-by: Eldad Zack <eldad@fogrefinery.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
* | Merge branch 'regulator-drivers' into regulator-nextMark Brown2012-07-221-48/+163
|\ \
| * | Merge tag 'v3.5-rc7' into regulator-driversMark Brown2012-07-151-5/+5
| |\| | | | | | | | | | Linux 3.5-rc7
| | * regulator: Fix recursive mutex lockdep warningStephen Boyd2012-07-031-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A recursive lockdep warning occurs if you call regulator_set_optimum_mode() on a regulator with a supply because there is no nesting annotation for the rdev->mutex. To avoid this warning, get the supply's load before locking the regulator's mutex to avoid grabbing the same class of lock twice. ============================================= [ INFO: possible recursive locking detected ] 3.4.0 #3257 Tainted: G W --------------------------------------------- swapper/0/1 is trying to acquire lock: (&rdev->mutex){+.+.+.}, at: [<c036e9e0>] regulator_get_voltage+0x18/0x38 but task is already holding lock: (&rdev->mutex){+.+.+.}, at: [<c036ef38>] regulator_set_optimum_mode+0x24/0x224 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&rdev->mutex); lock(&rdev->mutex); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by swapper/0/1: #0: (&__lockdep_no_validate__){......}, at: [<c03dbb48>] __driver_attach+0x40/0x8c #1: (&__lockdep_no_validate__){......}, at: [<c03dbb58>] __driver_attach+0x50/0x8c #2: (&rdev->mutex){+.+.+.}, at: [<c036ef38>] regulator_set_optimum_mode+0x24/0x224 stack backtrace: [<c001521c>] (unwind_backtrace+0x0/0x12c) from [<c00cc4d4>] (validate_chain+0x760/0x1080) [<c00cc4d4>] (validate_chain+0x760/0x1080) from [<c00cd744>] (__lock_acquire+0x950/0xa10) [<c00cd744>] (__lock_acquire+0x950/0xa10) from [<c00cd990>] (lock_acquire+0x18c/0x1e8) [<c00cd990>] (lock_acquire+0x18c/0x1e8) from [<c080c248>] (mutex_lock_nested+0x68/0x3c4) [<c080c248>] (mutex_lock_nested+0x68/0x3c4) from [<c036e9e0>] (regulator_get_voltage+0x18/0x38) [<c036e9e0>] (regulator_get_voltage+0x18/0x38) from [<c036efb8>] (regulator_set_optimum_mode+0xa4/0x224) ... Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
| * | regulator: core: Add core support for GPIO controlled enable linesMark Brown2012-07-031-1/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Factor out enable and disable operations some moreMark Brown2012-07-031-42/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | Create new _regulator_do_enable() and _regulator_do_disable() operations which deal with the mechanics of performing the enable and disable, partly to cut down on the levels of indentation and partly to support some future work. 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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | Merge tag 'v3.5-rc4' into regulator-driversMark Brown2012-06-251-0/+3
| |\| | | | | | | | | | | | | Linux 3.5-rc4 contains patches which conflict with some of the development work.
| * | regulator: Use list_voltage() to get voltage in regulator_set_voltage_time_selAxel Lin2012-06-231-14/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | With this change, regulator_set_voltage_time_sel() can be more generic and not limited to linear and table based mapping now. One side-effect of this change is that list_voltage() must be implemented. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
| * | regulator: core: Add export of regulator_set_voltage_time_sel()Mark Brown2012-06-231-0/+1
| | | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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: core: Support table based mapping in regulator_set_voltage_time_selAxel Lin2012-06-181-12/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For table based mapping, we can calculate voltage difference by below equation: abs(rdev->desc->volt_table[new_selector] - rdev->desc->volt_table[old_selector]) Thus we can make regulator_set_voltage_time_sel work for table based mapping. regulator_set_voltage_time_sel() only supports linear or table based mapping. In case it is misused, also warn if neither linear nor table based mapping is used with regulator_set_voltage_time_sel(). 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-4/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Return correct delay time in regulator_set_voltage_time_selAxel Lin2012-06-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rdev->desc->uV_step * abs(new_selector - old_selector) returns uV. The unit of ramp_delay is mV/us. Current code multiples 1000 at wrong place. Signed-off-by: Axel Lin <axel.lin@gmail.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/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: core: Handle fixed voltage in map_voltage_linearAxel Lin2012-06-081-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed voltage is a kind of linear mapping where n_voltages is 1. This change allows [list|map]_voltage_linear to be used for fixed voltage. For fixed voltage, n_voltages is 1 and the only valid selector is 0. Thus we actually don't care the uV_step setting. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
| | |
| \ \
*-. \ \ Merge branches 'regulator-core', 'regulator-dt' and 'regulator-dummy' into ↵Mark Brown2012-07-221-0/+12
|\ \ \ \ | | | |/ | | |/| | | | | regulator-next
| * / | regulator: core: Mark all DT based boards as having full constraintsMark Brown2012-07-061-0/+9
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | Since DT doesn't provide an idiomatic mechanism for enabling full constraints and since it's much more natural with DT to provide them just assume that a DT enabled system has full constraints. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
| * | regulator: core: Properly handle the case min_uV < rdev->desc->min_uV in ↵Axel Lin2012-06-081-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | map_voltage_linear Properly handle the case if the specified min_uV is less than the voltage given by the lowest selector. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | | regulator: Add REGULATOR_STATUS_UNDEFINED.Krystian Garbaciak2012-07-121-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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: Fix a typo in regulator_mode_to_status() core function.Krystian Garbaciak2012-07-121-1/+1
| | | | | | | | | | | | | | | | | | | | | Case REGULATOR_STATUS_STANDBY -> REGULATOR_MODE_STANDBY. Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | | regulator: core: remove sysfs entry properly in regulator_putShawn Guo2012-07-051-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With changes introduced by commit 222cc7b (regulator: core: Allow multiple requests of a single supply mapping) on create_regulator, regulator_put needs a corresponding update on sysfs entry removing. Also regulator->dev still needs to get assigned in create_regulator, otherwise, sysfs_remove_link call in regulator_put will get bypassed. Reported-by: Fabio Estevam <festevam@gmail.com> Tested-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | | regulator: core: Check that the selector from map_voltage() is validMark Brown2012-07-031-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lots of regulator drivers have checks in their map_voltage() functions to verify that the result of the mapping is in the range originally specified. Factor these out in the core and provide a bit of extra defensiveness for other drivers by doing the check in the core. Since we're now doing a list_voltage() earlier move the current mapping back to a voltage out into the set_voltage() call to save redoing it. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | | regulator: core: Support fixed voltages in regulator_is_supported_voltage()Mark Brown2012-07-031-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently regulator_is_supported_voltage() works by enumerating the set of voltages which can be set by the regulator but the checks we're doing to impose constraints mean that if we can't vary the voltage we'll not report any voltages as supported even though the regulator is actually set at that voltage. We could fix the voltage listing but this would mean that list_voltage() could end up going to the hardware to get the current voltage which isn't expected (it's supposed to be very cheap) so instead special case things when we can't change the voltage and compare the requested range against the current voltage. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | | regulator: core: Remove unused get_device_regulatorFabio Estevam2012-06-271-22/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 222cc7b1 (regulator: core: Allow multiple requests of a single supply mapping) removed the usage of get_device_regulator(). Remove the function definition too amd get rid of the following warning: drivers/regulator/core.c:112:26: warning: 'get_device_regulator' defined but not used [-Wunused-function] Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | | regulator: core: Allow multiple requests of a single supply mappingMark Brown2012-06-261-44/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes it may be useful to allow a device to request a supply multiple times, for example in order to allow framework management of some uses of the supply with some additional driver specific management or in order to allow multiple children of an MFD to work with the supply. Currently this is not possible due to the creation of Solve this by removing the requested_uA entry (we have no current users of this feature anyway) and ignoring errors creating the symlink to the consumer. We should do something nicer than this as this causes sysfs to spew enormous warnings but it allows users to run for now. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* | | regulator: core: Check for failed voltage sets before checking for delayMark Brown2012-06-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | There is no need to consider waiting for the voltage to ramp if we didn't manage to set it and looking at the return value is going to be cheaper than is_enabled(). Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | | regulator: Fix double free in devm_regulator_put()Mark Brown2012-06-181-3/+1
| | | | | | | | | | | | Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | | regulator: core.c Only delay when setting voltage requires thisPhilip Rakity2012-06-171-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | minor optimization: move delay code to where delay is set and thus where it is used vs in the main line path. Signed-off-by: Philip Rakity <prakity@marvell.com> Acked-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | | regulator: core.c Pass voltage to notifier when setting voltagePhilip Rakity2012-06-171-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The voltage being set should be passed to the call in handler requesting the callback. Currently this is not done. The calling handler cannot call regulator_get_voltage() to get the information since the mutex is held by the regulator and deadlock occurs. Without this change the receiver of the call in cannot know what action to take. This is used, for example, to set PAD voltages when doing SD vccq voltage changes. [Review and spelling fix in the commit log from Pankaj Jangra] Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | | regulator: core: Actually use the data in _notifier_call_chain()Mark Brown2012-06-171-1/+1
| | | | | | | | | | | | | | | Reported-by: Pankaj Jangra <jangra.pankaj9@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | | regulator: core: Use map_voltage_linear() if list_voltage_linear() is in use ↵Axel Lin2012-06-041-4/+10
| |/ |/| | | | | | | | | | | and nothing is set Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | regulator: core: Use dev_get_regmap() to find the regmapMark Brown2012-06-031-1/+4
| | | | | | | | | | | | | | | | | | If no regmap is explicitly specified then use dev_get_regmap() to obtain one. The driver must explicitly enable any actual usage of the regmap so there's no concern with unwanted usage. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* | regulator: Use newly added devres_release() rather than open codingMark Brown2012-06-031-1/+1
| | | | | | | | | | | | | | | | devres_release() will call the destructor for the resource as well as freeing the devres data. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* | regulator: core: Call set_voltage_time_sel() only when the regulator is onAxel Lin2012-06-031-2/+3
| | | | | | | | | | | | | | | | | | If the regulator is not on, it won't take time setting new voltage. So only call set_voltage_time_sel() to get the necessary delay when the regulator is on. Signed-off-by: Axel Lin <axel.lin@gmail.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/+25
|/ | | | | | | | | | 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>
* Merge tag 'regulator-3.5' of ↵Linus Torvalds2012-05-211-115/+341
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator updates from Mark Brown: "The major thing here is the addition of some helpers to factor code out of drivers, making a fair proportion of regulators much more just data rather than code which is nice. - Helpers in the core for regulators using regmap, providing generic implementations of the enable and voltage selection operations which just need data to describe them in the drivers. - Split out voltage mapping and voltage setting, allowing many more drivers to take advantage of the infrastructure for selectors. - Loads and loads of cleanups from Axel Lin once again, including many changes to take advantage of the above new framework features - New drivers for Ricoh RC5T583, TI TPS62362, TI TPS62363, TI TPS65913, TI TWL6035 and TI TWL6037. Some of the registration changes to support the core refactoring caused so many conflicts that eventually topic branches were abandoned for this release." * tag 'regulator-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (227 commits) regulator: tps65910: use of_node of matched regulator being register regulator: tps65910: dt: support when "regulators" node found regulator: tps65910: add error message in case of failure regulator: tps62360: dt: initialize of_node param for regulator register. regulator: tps65910: use devm_* for memory allocation regulator: tps65910: use small letter for regulator names mfd: tpx6586x: Depend on regulator regulator: regulator for Palmas Kconfig regulator: regulator driver for Palmas series chips regulator: Enable Device Tree for the db8500-prcmu regulator driver regulator: db8500-prcmu: Separate regulator registration from probe regulator: ab3100: Use regulator_map_voltage_iterate() regulator: tps65217: Convert to set_voltage_sel and map_voltage regulator: Enable the ab8500 for Device Tree regulator: ab8500: Split up probe() into manageable pieces regulator: max8925: Remove check_range function and max_uV from struct rc5t583_regulator_info regulator: max8649: Remove unused check_range() function regulator: rc5t583: Remove max_uV from struct rc5t583_regulator_info regulator: da9052: Convert to set_voltage_sel and map_voltage regulator: max8952: Use devm_kzalloc ...
| * regulator: core: Don't open code _regulator_is_enabled()Mark Brown2012-05-141-3/+2
| | | | | | | | | | Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
| * regulator: core: Release regulator-regulator supplies on errorMark Brown2012-05-141-0/+2
| | | | | | | | | | | | | | | | | | If we fail while registering a regulator make sure we release the supply for the regulator if there is one. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Cc: stable@vger.kernel.org
| * regulator: core: Ensure simple linear voltage mappings falls within the ↵Axel Lin2012-05-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | specified range Integer division may truncate the result. Use DIV_ROUND_UP to ensure simple linear voltage mappings falls within the specified range. Signed-off-by: Axel Lin <axel.lin@gmail.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-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-27/+55
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| *-. Merge remote-tracking branches 'regulator/topic/core', ↵Mark Brown2012-05-121-92/+236
| |\ \ | | | | | | | | | | | | 'regulator/topic/regmap' and 'regulator/topic/register' into regulator-next
| | | * regulator: core: Warn on missing struct deviceMark Brown2012-05-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The core really wants a struct device to be supplied for regulators and there's no reason this should be impossible so provide one so complain if we didn't get one. 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/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
OpenPOWER on IntegriCloud