Fix the support for 1/2/8 bytes wide register address checking.
Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Since regmap core and mmio have already support for 1/2/8 bytes wide values,
so adds support for 1/2/8 bytes wide registers address.
Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

In the regcache_default_sync, if a register isn't writeable, then
_regmap_write will return an error and the rest of the sync will be
aborted.  Avoid this by checking if a register is writeable before
trying to sync it.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

The default sync operation was still assuming a stride of one, fix it
to respect the reg_stride set in the map.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

regmap deploys the spinlock for the protection when set up in fast_io
mode.  This may lead to sleep-in-atomic by memory allocation with
GFP_KERNEL in regmap_bulk_write().  This patch fixes it by moving the
allocation out of the lock.

[Fix excessively large locked region -- broonie]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

With fast_io we use mutexes to lock the I/O operations so we would need
to do GFP_ATOMIC allocations if we wanted to do allocations inside the
lock as we do currently. Since it is unlikely that we will want to register
a patch outside of init where concurrency shouldn't be an issue move the
allocation of the patch data outside the lock.
Reported-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

After setting the 'data' pointer (wchich is returned to the caller for
freeing later) the regmap_add_irq_chip() could still fail for various
reasons (ENOMEM, regmap_read or regmap_write failure). In such case the
memory under 'data' was freed in error path and error value was returned
but the 'data' variable was not changed.

This could lead to errors if the caller passed such 'data' to
regmap_del_irq_chip().

The 'data' pointer should be changed atomically from the caller
perspective - set it only on regmap_add_irq_chip() success.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Signed-off-by: NGeert Uytterhoeven <geert+renesas@linux-m68k.org>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This is the implementation of regmap_multi_reg_write()

There is a new capability 'can_multi_write' that device drivers
must set in order to use this multi reg write mode.

This replaces the first definition, which just defined the API.
Signed-off-by: NAnthony Olech <anthony.olech.opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

This patch adds cpufreq suspend/resume calls to dpm_{suspend|resume}()
for handling suspend/resume of cpufreq governors.

Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found an issue where the
tunables configuration for clusters/sockets with non-boot CPUs was
lost after system suspend/resume, as we were notifying governors with
CPUFREQ_GOV_POLICY_EXIT on removal of the last CPU for that policy
which caused the tunables memory to be freed.

This is fixed by preventing any governor operations from being
carried out between the device suspend and device resume stages of
system suspend and resume, respectively.

We could have added these callbacks at dpm_{suspend|resume}_noirq()
level, but there is an additional problem that the majority of I/O
devices is already suspended at that point and if cpufreq drivers
want to change the frequency before suspending, then that not be
possible on some platforms (which depend on peripherals like i2c,
regulators, etc).
Reported-and-tested-by: NLan Tianyu <tianyu.lan@intel.com>
Reported-by: NJinhyuk Choi <jinchoi@broadcom.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
[rjw: Changelog]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

    In some cases, we need regmap's format parse_val function
to do be/le translation according to the bus configuration.
For example, snd_soc_bytes_put() uses regmap to write/read values,
and use cpu_to_be() directly to covert MASK into big endian. This
is a defect, and should use regmap's format function to do it according
to bus configuration.
Signed-off-by: NNenghua Cao <nhcao@marvell.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

This patch provides two new runtime PM helper functions which intend to
be used from system suspend/resume callbacks, to make sure devices are
put into low power state during system suspend and brought back to full
power at system resume.

The prerequisite is to have all levels of a device's runtime PM
callbacks to be defined through the SET_PM_RUNTIME_PM_OPS macro, which
means these are available for CONFIG_PM.

By using the new runtime PM helper functions especially the two
scenarios below will be addressed.

1) The PM core prevents .runtime_suspend callbacks from being invoked
during system suspend. That means even for a runtime PM centric
subsystem and driver, the device needs to be put into low power state
from a system suspend callback. Otherwise it may very well be left in
full power state (runtime resumed) while the system is suspended. By
using the new helper functions, we make sure to walk the hierarchy of
a device's power domain, subsystem and driver.

2) Subsystems and drivers need to cope with all the combinations of
CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME. The two new helper functions
smothly addresses this.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

While fetching the proper runtime PM callback, we walk the hierarchy of
device's power domains, subsystems and drivers.

This is common for rpm_suspend(), rpm_idle() and rpm_resume(). Let's
clean up the code by using a macro that handles this.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

If devices don't provide latency data, this warning can be quite noisy until
the pm domain was enabled and disabled a few times. Turn this warning into
a debug message.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

During restore, pm_notifier chain are called with
PM_RESTORE_PREPARE.  The firmware_class driver handler
fw_pm_notify does not have a handler for this.  As a result,
it keeps a reader on the kmod.c umhelper_sem.  During
freeze_processes, the call to __usermodehelper_disable tries to
take a write lock on this semaphore and hangs waiting.
Signed-off-by: NSebastian Capella <sebastian.capella@linaro.org>
Acked-by: NMing Lei <ming.lei@canonical.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Since we now have an internal version of regmap_multi_reg_write use this
to apply the register patch.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Devices with more complex boot proceedures may occasionally apply the
register patch manual. regmap_multi_reg_write is a logical way to do so,
however the patch must be applied with cache bypass on, such that it
doesn't override any user settings. This patch adds a
regmap_multi_reg_write_bypassed function that applies a set of writes
with the bypass enabled.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

There should be no need for the writes supplied to this function to be
edited by it so mark them as const.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

   /drivers/base/regmap/regmap.c:717:6-33: WARNING:
Comparison to bool.

   More information about semantic patching is available at
http://coccinelle.lip6.fr/Signed-off-by: NNenghua Cao <nhcao@marvell.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Currently, we check the registers in the patch are aligned to the
register stride everytime we sync the cache and the first time the patch
is written out is unchecked.

This patch checks the register patch when we first register it so the
first writes are no longer unchecked and then doesn't check on
subsequent syncs as the patch will be unchanged.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Since sometimes the 'config' parameter has no use, it should be NULL.
And make the code simplifier.
Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

In analogy with commits 5af84b82 and 97df8c12, using
asynchronous threads can improve the overall suspend_late
time significantly.

This patch is for suspend_late phase.
Signed-off-by: NChuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

In analogy with commits 5af84b82 and 97df8c12, using
asynchronous threads can improve the overall suspend_noirq
time significantly.

This patch is for suspend_noirq phase.
Signed-off-by: NChuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

In analogy with commits 5af84b82 and 97df8c12, using
asynchronous threads can improve the overall resume_early
time significantly.

This patch is for resume_early phase.
Signed-off-by: NChuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

In analogy with commits 5af84b82 and 97df8c12, using
asynchronous threads can improve the overall resume_noirq time
significantly.

One typical case is:
In resume_noirq phase and for the PCI devices, the function
pci_pm_resume_noirq() will be called, and there is one d3_delay
(10ms) at least.

With the way of asynchronous threads, we just need wait d3_delay
time once in parallel for each calling, which saves much time to
resume quickly.
Signed-off-by: NChuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The patch is a helper adding two new flags for implementing
async threads for suspend_noirq and suspend_late.
Signed-off-by: NChuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Create special function regmap_attach_dev
which can be called separately out of regmap_init.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Russell King observed 'wierd' looking output from debugfs, and also suggested
better ways of getting device names (use KBUILD_MODNAME, dev_name())

This patch addresses these issues to make the debugfs output correct and better
looking.

While at it, replace seq_printf with seq_puts to remove the checkpatch.pl
warnings.
Reported-by: NRussell King - ARM Linux <linux@arm.linux.org.uk>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>

Check if regs are readable.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Rework dev_pm_qos_add_ancestor_request() so that device PM QoS type
is passed to it as the third argument and make it support the
DEV_PM_QOS_LATENCY_TOLERANCE device PM QoS type (in addition to
DEV_PM_QOS_RESUME_LATENCY).

That will allow the drivers of devices without latency tolerance
hardware support to use their ancestors having it as proxies for
their latency tolerance requirements.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add a new latency tolerance device PM QoS type to be use for
specifying active state (RPM_ACTIVE) memory access (DMA) latency
tolerance requirements for devices.  It may be used to prevent
hardware from choosing overly aggressive energy-saving operation
modes (causing too much latency to appear) for the whole platform.

This feature reqiures hardware support, so it only will be
available for devices having a new .set_latency_tolerance()
callback in struct dev_pm_info populated, in which case the
routine pointed to by it should implement whatever is necessary
to transfer the effective requirement value to the hardware.

Whenever the effective latency tolerance changes for the device,
its .set_latency_tolerance() callback will be executed and the
effective value will be passed to it.  If that value is negative,
which means that the list of latency tolerance requirements for
the device is empty, the callback is expected to switch the
underlying hardware latency tolerance control mechanism to an
autonomous mode if available.  If that value is PM_QOS_LATENCY_ANY,
in turn, and the hardware supports a special "no requirement"
setting, the callback is expected to use it.  That allows software
to prevent the hardware from automatically updating the device's
latency tolerance in response to its power state changes (e.g. during
transitions from D3cold to D0), which generally may be done in the
autonomous latency tolerance control mode.

If .set_latency_tolerance() is present for the device, a new
pm_qos_latency_tolerance_us attribute will be present in the
devivce's power directory in sysfs.  Then, user space can use
that attribute to specify its latency tolerance requirement for
the device, if any.  Writing "any" to it means "no requirement, but
do not let the hardware control latency tolerance" and writing
"auto" to it allows the hardware to be switched to the autonomous
mode if there are no other requirements from the kernel side in the
device's list.

This changeset includes a fix from Mika Westerberg.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add a new field, no_constraints_value, to struct pm_qos_constraints
representing a list of PM QoS constraint requests to be returned by
pm_qos_get_value() when that list of requests is empty.

That field will be equal to default_value for all of the existing
global PM QoS classes and for the resume latency device PM QoS type,
but it will be different from default_value for the new latency
tolerance device PM QoS type introduced by the next changeset.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Rename symbols, variables, functions and structure fields related do
the resume latency device PM QoS type so that it is clear where they
belong (in particular, to avoid confusion with the latency tolerance
device PM QoS type introduced by a subsequent changeset).

Update the PM QoS documentation to better reflect its current state.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We weren't handling the devres issues for the master device failing a
bind, or being unbound properly.  Add a devres group to contain these,
and release the resources at the appropriate points.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

irqdomain now supports removal of domains on exit so we can properly clean
up on deletion of a regmap irqchip.
Signed-off-by: NMark Brown <broonie@linaro.org>

When a map covers a single register, max_register is equal
to 0, so the "registers" & "access" files were not created.
Now they will be, as register 0 must be readable for such
map to make sense.
Signed-off-by: NPawel Moll <pawel.moll@arm.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

regcache_sync_block_raw_flush takes the address of the base register
and the address of one past the last register to write to.  "count" is
the number of registers in the range, not the number of bytes, it
should be (end addr - start addr) / stride. Without accounting for
strides greater than one, registers past the end might be synced or
the writeable_reg callback at the beginning of _regmap_raw_write will
fail and nothing will be written.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

Fix a problem that, the platform bus supports the OF style modalias
in .uevent() call, but not in its device 'modalias' sysfs attribute.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI enumerated devices has ACPI style _HID and _CID strings,
all of these strings can be used for both driver loading and matching.

Currently, in Platform, I2C and SPI bus, the ACPI style driver matching
is supported by invoking acpi_driver_match_device() in bus .match() callback.
But, the module autoloading is still broken.

For example, there is any ACPI device with _HID "INTABCD" that is
enumerated to platform bus, and we have a driver that can probe it.

The driver exports its module_alias as "acpi:INTABCD" use the following code
static const struct acpi_device_id xxx_acpi_match[] = {
        { "INTABCD", 0 },
        { }
};
MODULE_DEVICE_TABLE(acpi, xxx_acpi_match);

But, unfortunately, the device' modalias is shown as "platform:INTABCD:00",
please refer to modalias_show() and platform_uevent() in
drivers/base/platform.c.
This results in that the driver will not be loaded automatically when the
device node is created, because their modalias do not match.

This also applies to I2C and SPI bus.

With this patch, the device' modalias will be shown as "acpi:INTABCD" as well.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NMark Brown <broonie@linaro.org>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>