Move regulator_list_voltage_{linear,linear_range,table} helper functions to
helpers.c.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
While the majority of supplies on devices are mandatory and can't be
physically omitted for electrical reasons some devices do have optional
supplies and need to know if they are missing, MMC being the most common
of these.
Currently the core accurately reports all errors when regulators are
requested since it does not know if the supply is one that must be provided
even if by a regulator software does not know about or if it is one that
may genuinely be disconnected. In order to allow this behaviour to be
changed and stub regulators to be provided in the former case add a new
regulator request function regulator_get_optional() which provides a hint
to the core that the regulator may genuinely not be connected.
Currently the implementation is identical to the current behaviour, future
patches will add support in the core for returning stub regulators in the
case where normal regulator_get() fails and the board has requested it.
Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Chris Ball <cjb@laptop.org>
The dev_attrs field of struct class is going away soon, dev_groups
should be used instead. This converts the regulator class code to use
the correct field.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Current code does not allow fixed voltage range in multiple linear ranges.
If someone does set range->uV_step == 0 in one of the linear ranges, we hit
divided by zero bug. This patch fixes this issue.
For fixed voltage range, return any selector means the same voltage.
Thus just return 0.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
There is no need to use a normal per-CPU workqueue for delayed power downs
as they're not timing or performance critical and waking up a core for them
would defeat some of the point.
Signed-off-by: Mark Brown <broonie@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Liam Girdwood <liam.r.girdwood@intel.com>
In function _regulator_do_set_voltage(), old_selector gets intialised only
if (_regulator_is_enabled(rdev) && rdev->desc->ops->set_voltage_time_sel &&
rdev->desc->ops->get_voltage_sel)) is true.
Before calling set_voltage_time_sel() we checks if (old_selector >= 0) and it
will true if it got intialised properly. so we don't need to check again
_regulator_is_enabled(rdev) && rdev->desc->ops->set_voltage_time_sel before
calling set_voltage_time_sel().
Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Some hardwares support disabling ramp delay, so adding ramp_disable flag to
constraints. It will be used to figure out whether ramp_delay in constraints
is explicitly set to zero or its unintialized (zero by default).
And we don't need to call set_voltage_time_sel() for regulators for whom ramp
delay is disabled in constraints.
Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
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>
Add regulator_get_linear_step(), which returns the voltage step size
between VSEL values for linear regulators. This is intended for use
by regulator consumers which build their own voltage-to-VSEL tables.
Signed-off-by: Paul Walmsley <pwalmsley@nvidia.com>
Reviewed-by: Andrew Chew <achew@nvidia.com>
Cc: Matthew Longnecker <mlongnecker@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Add a couple kernel-doc lines to get rid of kernel-doc generation
warnings, no functional change.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
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>
commit 6d191a5fc7
(regulator: core: Don't defer probe if there's no DT binding for a supply)
Attempted to differentiate between regulator_get() with an actual
DT binding for the supply and when there is none to avoid unnecessary
deferal.
However, ret value supplied by regulator_dev_lookup() is being
ignored by regulator_get(). So, exit with the appropriate return value.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Regulator drivers may specify regulator_desc->supply_name which
regulator_register() will use to find the supply node for a regulator.
If no supply was specified in the device tree or the supply has yet
to be registered regulator_register() will fail, deferring the probe
of the regulator. In the case where no supply node was specified in the
device tree, there is no supply and it is pointless to try and find one
later, so go ahead and add the regulator without the supply.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
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>
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>
To support shared enable GPIO pin, replace GPIO code with new static functions
Reference count: 'enable_count'
Balance the reference count of each GPIO and actual pin control.
The count is incremented with enabling GPIO.
On the other hand, it is decremented on disabling GPIO.
Actual GPIO pin is enabled at the initial use.(enable_count = 0)
The pin is disabled if it is not used(shared) any more. (enable_count <=1)
Regardless of the enable count, update GPIO state of the regulator.
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>
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>
Unwinding code disables all successfully enabled regulators.
Error is logged for every failed regulator.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
commit f59c8f9f (regulator: core: Support bypass mode)
has a short documentation error around the regulator_allow_bypass
parameter 'enable' which is documented as 'allow'.
This generates kernel-doc warning as follows:
./scripts/kernel-doc drivers/regulator/core.c >/dev/null
Warning(drivers/regulator/core.c:2841): No description found for parameter 'enable'
Warning(drivers/regulator/core.c:2841): Excess function parameter 'allow' description in 'regulator_allow_bypass'
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>
commit dd8004af: 'regulator: core: Log when a device causes a voltage
constraint fail', tried to print out some information about the
check consumer min/max uV fixup, however, it uses a garbage pointer
left over from list_for_each_entry leading to boot messages in the
form:
'[ 2.079890] <RANDOM ASCII>: Restricting voltage, 3735899821-4294967295uV'
Because it references regulator->dev, it could potentially read memory from
anywhere causing a panic.
This patch instead uses rdev and the updated min/max uV values.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Optimize _regulator_do_set_voltage() for the case selector is equal to
old_selector. Since the voltage does not change, we don't need to call
set_voltage_sel() and set_voltage_time_sel() in this case.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
regulator_register() does not return 0 on success, fix the comment.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
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>
Regulator drivers with continuous_voltage_range flag set allows not setting
n_voltages. Thus if continuous_voltage_range is set, check the constraint range
instead.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Tested-by: Robert Nelson <robertcnelson@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Having a linear_min_sel setting means the first linear_min_sel selectors are
invalid. We need to subtract linear_min_sel when use n_voltages to determinate
if regulator can change voltage.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Introduce a regulator_can_change_voltage() function for the subsytems or
drivers which might check if applying voltage change is possible and use
special workaround code when the driver is used with fixed regulators or
regulators with disabled ability to change the voltage.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
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_is_supported_voltage() should return true only if the voltage
of fixed/constant regulator is between min_uV and max_uV.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
When regulator_register fails and exits through the scrub path the
regulator_put function was called whilst holding the
regulator_list_mutex, causing deadlock.
This patch adds a private version of the regulator_put function which
can be safely called whilst holding the mutex, replacing the
aforementioned call.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If the gpio_request_one() fails, or returns EPROBE_DEFER, the
regulator must be device_unregister()ed. When this is not done,
there are WARNING: from sysfs:
WARNING: at fs/sysfs/file.c:343 sysfs_open_file+0x238/0x268()
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
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>
Pull workqueue changes from Tejun Heo:
"This is workqueue updates for v3.7-rc1. A lot of activities this
round including considerable API and behavior cleanups.
* delayed_work combines a timer and a work item. The handling of the
timer part has always been a bit clunky leading to confusing
cancelation API with weird corner-case behaviors. delayed_work is
updated to use new IRQ safe timer and cancelation now works as
expected.
* Another deficiency of delayed_work was lack of the counterpart of
mod_timer() which led to cancel+queue combinations or open-coded
timer+work usages. mod_delayed_work[_on]() are added.
These two delayed_work changes make delayed_work provide interface
and behave like timer which is executed with process context.
* A work item could be executed concurrently on multiple CPUs, which
is rather unintuitive and made flush_work() behavior confusing and
half-broken under certain circumstances. This problem doesn't
exist for non-reentrant workqueues. While non-reentrancy check
isn't free, the overhead is incurred only when a work item bounces
across different CPUs and even in simulated pathological scenario
the overhead isn't too high.
All workqueues are made non-reentrant. This removes the
distinction between flush_[delayed_]work() and
flush_[delayed_]_work_sync(). The former is now as strong as the
latter and the specified work item is guaranteed to have finished
execution of any previous queueing on return.
* In addition to the various bug fixes, Lai redid and simplified CPU
hotplug handling significantly.
* Joonsoo introduced system_highpri_wq and used it during CPU
hotplug.
There are two merge commits - one to pull in IRQ safe timer from
tip/timers/core and the other to pull in CPU hotplug fixes from
wq/for-3.6-fixes as Lai's hotplug restructuring depended on them."
Fixed a number of trivial conflicts, but the more interesting conflicts
were silent ones where the deprecated interfaces had been used by new
code in the merge window, and thus didn't cause any real data conflicts.
Tejun pointed out a few of them, I fixed a couple more.
* 'for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: (46 commits)
workqueue: remove spurious WARN_ON_ONCE(in_irq()) from try_to_grab_pending()
workqueue: use cwq_set_max_active() helper for workqueue_set_max_active()
workqueue: introduce cwq_set_max_active() helper for thaw_workqueues()
workqueue: remove @delayed from cwq_dec_nr_in_flight()
workqueue: fix possible stall on try_to_grab_pending() of a delayed work item
workqueue: use hotcpu_notifier() for workqueue_cpu_down_callback()
workqueue: use __cpuinit instead of __devinit for cpu callbacks
workqueue: rename manager_mutex to assoc_mutex
workqueue: WORKER_REBIND is no longer necessary for idle rebinding
workqueue: WORKER_REBIND is no longer necessary for busy rebinding
workqueue: reimplement idle worker rebinding
workqueue: deprecate __cancel_delayed_work()
workqueue: reimplement cancel_delayed_work() using try_to_grab_pending()
workqueue: use mod_delayed_work() instead of __cancel + queue
workqueue: use irqsafe timer for delayed_work
workqueue: clean up delayed_work initializers and add missing one
workqueue: make deferrable delayed_work initializer names consistent
workqueue: cosmetic whitespace updates for macro definitions
workqueue: deprecate system_nrt[_freezable]_wq
workqueue: deprecate flush[_delayed]_work_sync()
...
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>
If the device doesn't have a regmap specified by the driver and we can't
find one on the device itself try its parent, providing a useful defualt
for many MFDs.
[Rewrite commit message -- broonie]
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Users (especially framework code) may end up passing in a zero deferral
time depending on runtime conditions or configuration. If they do then
just call regulator_disable() directly to save scheduling.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
If a regulator only supports a single voltage list_voltage() can be used
to report what that voltage is so add this as one of the criteria for
creating the microvolts file in sysfs.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Fix regulator kernel-doc warnings:
Warning(drivers/regulator/core.c:2308): No description found for parameter 'rdev'
Warning(drivers/regulator/core.c:2308): Excess function parameter 'regulator' description in 'regulator_set_voltage_time_sel'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
flush[_delayed]_work_sync() are now spurious. Mark them deprecated
and convert all users to flush[_delayed]_work().
If you're cc'd and wondering what's going on: Now all workqueues are
non-reentrant and the regular flushes guarantee that the work item is
not pending or running on any CPU on return, so there's no reason to
use the sync flushes at all and they're going away.
This patch doesn't make any functional difference.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Mattia Dongili <malattia@linux.it>
Cc: Kent Yoder <key@linux.vnet.ibm.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Bryan Wu <bryan.wu@canonical.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Alasdair Kergon <agk@redhat.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: Anton Vorontsov <cbou@mail.ru>
Cc: Sangbeom Kim <sbkim73@samsung.com>
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Petr Vandrovec <petr@vandrovec.name>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Avi Kivity <avi@redhat.com>
Fix regulator kernel-doc warnings:
Warning(drivers/regulator/core.c:2308): No description found for parameter 'rdev'
Warning(drivers/regulator/core.c:2308): Excess function parameter 'regulator' description in 'regulator_set_voltage_time_sel'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Commit 65f735082d ("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>
If the regulator doesn't supply a way of reading back the voltage but does
provide a list_voltage() operation then use that with a selector of zero
to read the voltage. Regulators doing this means that we have the list
operation there for consumers that want to configure themselves.
Reported-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
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>
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>
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>
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>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQEcBAABAgAGBQJQDjDCAAoJEDeqqVYsXL0M/sMH/jVgBfF1mjR+DQuTscKyD21w
0BQLn5OmvDZDqo44iqQzNRObw7CxkBkUtHoozsknLijw+KggER653ZOAtUdIHfI/
/uo7iJQ3J3D/Ezm99HYSpZiF2juZwsBRtFBoKkGqOpMlzFUx5o4hUbH5OcINxnHR
VmvJU5K1kg8D77Q6zK+Atl14/Rfibc2IoufFmbYdplUAM/tV0BpBSSHJAJvqua76
NGMl4KJcPZnXe/4LXcxZia5A2efdFFEzaQ2mM9rUVEAgHDAxc0Zg9IoDhGd08FX4
G55NK+6+bKb9s7bgyva0T/iy817TRCzjteeYNFrb8nBRe7aQbAivaBHQFXIyvdQ=
=y2sh
-----END PGP SIGNATURE-----
Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
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
...
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQEcBAABAgAGBQJP53AxAAoJEHm+PkMAQRiGs2QH/RaqkXz96fwjhDcyiKpDqA3c
kGuS5mz5cOhnqKSmR88HFm6pwuhLux/qSJzeAmoQy1MC8a0ACx7AnANW0lfN3/qe
/HGYz8h60yCL/fhn8/bUYtdt9xsoDqoDcq/ooFl9mcsJGWbC6WeMSZU5dAUYqviE
qFrp5zjY07FG53CRGT0hFpezQNwNL+VLH30CF9LD+fJLPVEYum2zBNGXWM42rcw5
fxzGL/6SO8YqA/Upic1ht6HAd6s5LOrlST7qvnyXUMvRXN5z/Y92ueYJZefkS1Om
ohuLIKM2bv9/dJS67H8N2baSKGCzBdfSe5/5WaHdLYW9MiVju0wRl6HPJtAMrkk=
=H8t8
-----END PGP SIGNATURE-----
Merge tag 'v3.5-rc4' into regulator-drivers
Linux 3.5-rc4 contains patches which conflict with some of the
development work.
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>
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>
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>
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>
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>
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>
Axel Lin