UPSTREAM: pwm: Introduce the pwm_args concept

Currently the PWM core mixes the current PWM state with the per-platform
reference config (specified through the PWM lookup table, DT definition
or directly hardcoded in PWM drivers).

Create a struct pwm_args to store this reference configuration, so that
PWM users can differentiate between the current and reference
configurations.

Patch all places where pwm->args should be initialized. We keep the
pwm_set_polarity/period() calls until all PWM users are patched to use
pwm_args instead of pwm_get_period/polarity().

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
[thierry.reding@gmail.com: reword kerneldoc comments]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit e39c0df1be5a97e0910b09af1530bdf3de057a06)

Change-Id: Id9ec0898d92d7049813c32acbd909103e949c846
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: Add early supply resolution for regulators

The call to set_machine_constraints() in regulator_register(), will
attempt to get the voltage for the regulator. If a regulator is in
bypass will fail to get the voltage (ie. it's bypass voltage) and
hence register the regulator, because the supply for the regulator has
not been resolved yet.

To fix this, add a call to regulator_resolve_supply() before we call
set_machine_constraints(). If the call to regulator_resolve_supply()
fails, rather than returning an error at this point, allow the
registration of the regulator to continue because for some regulators
resolving the supply at this point may not be necessary and it will be
resolved later as more regulators are added. Furthermore, if the supply
is still not resolved for a bypassed regulator, this will be detected
when we attempt to get the voltage for the regulator and an error will
be propagated at this point.

If a bypassed regulator does not have a supply when we attempt to get
the voltage, rather than returing -EINVAL, return -EPROBE_DEFER instead
to allow the registration of the regulator to be deferred and tried
again later.

Please note that regulator_resolve_supply() will call
regulator_dev_lookup() which may acquire the regulator_list_mutex. To
avoid any deadlocks we cannot hold the regulator_list_mutex when calling
regulator_resolve_supply(). Therefore, rather than holding the lock
around a large portion of the registration code, just hold the lock when
aquiring any GPIOs and setting up supplies because these sections may
add entries to the regulator_map_list and regulator_ena_gpio_list,
respectively.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 45389c47526d1eca70f96872c172aea0941e8520)

Change-Id: I9a0fa34c92b3326b9563672b74b5651cfd3a96f8
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: refactor valid_ops_mask checking code

To make the code more compat and centralized, this patch add a
unified function - regulator_ops_is_valid. So we can add
some extra checking code easily later.

Signed-off-by: WEN Pingbo <pingbo.wen@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 8a34e979f684aa13e6c4bf23b394cca9dfabf4a9)

Change-Id: Ib3ffc949004c71abe3b75b4e0ffaf2e303f00d22
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: helpers: Ensure bypass register field matches ON value

When checking bypass state for a regulator, we check to see if any bits
in the bypass mask are set. For most cases this is fine because there is
typically, only a single bit used to determine if the regulator is in
bypass. However, for some regulators, such as LDO6 on AS3722, the bypass
state is indicate by a value rather than a single bit. Therefore, when
checking the bypass state, check that the bypass field matches the ON
value.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit dd1a571daee7cdd6504a5771721e34f9b118f17a)

Change-Id: Ic9f9ee919969cc744be7e7c94729ee7ab9e0e7a1
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: Move registration of regulator device

The public functions to acquire a regulator, such as regulator_get(),
internally look-up the regulator from the list of regulators that have
been registered with the regulator device class. The registration of
a new regulator with the regulator device class happens before the
regulator has been completely setup. Therefore, it is possible that
the regulator could be acquired before it has been setup successfully.
To avoid this move the device registration of the regulator to the end
of the regulator setup and update the error exit path accordingly.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit c438b9d017362b65f6b1a9e54f7f35e7f873dc7c)

Change-Id: I9b33820c1ea748fdf5ccfb8949775b753af4a848
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: Clear the supply pointer if enabling fails

During the resolution of a regulator's supply, we may attempt to enable
the supply if the regulator itself is already enabled. If enabling the
supply fails, then we will call _regulator_put() for the supply.
However, the pointer to the supply has not been cleared for the
regulator and this will cause a crash if we then unregister the
regulator and attempt to call regulator_put() a second time for the
supply. Fix this by clearing the supply pointer if enabling the supply
after fails when resolving the supply for a regulator.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 8e5356a73604f53da6a1e0756727cb8f9f7bba17)

Change-Id: I3e83852db8c624fdd5b6c0bcab42c07289501a58
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: Don't terminate supply resolution early

The function regulator_register_resolve_supply() is called from the
context of class_for_each_dev() (during the regulator registration) to
resolve any supplies added. regulator_register_resolve_supply() will
return an error if a regulator's supply cannot be resolved and this will
terminate the loop in class_for_each_dev(). This means that we will not
attempt to resolve any other supplies after one has failed. Hence, this
may delay the resolution of other regulator supplies until the failing
one itself can be resolved.

Rather than terminating the loop early, don't return an error code and
keep attempting to resolve any other supplies for regulators that have
been registered.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 7ddede6a58a0bd26efcfd2a5055611195411f514)

Change-Id: I92644a3c2006476440f0eeca2e4a9717743b13b9
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: Add debugfs to show constraint flags

There are debugfs entries for voltage and current, but not for
the constraint flags. It's useful for debugging to be able to
see what these flags are so this patch adds a new debugfs file.
We can't use debugfs_create_bool for this because the flags are
bitfields, so as this needs a special read callback they have been
collected into a single file that lists all the flags.

Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 2d80a91b2f2a96f38877bc328dac135d69564911)

Change-Id: Ia3e78960204e34e004340e28b3a7f933aa457371
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: Fix locking of GPIO list on free

When we acquire a shareable enable GPIO on probe we do so with the
regulator_list_mutex held.  However when we release the GPIOs we do this
immediately after dropping the mutex meaning that the list could become
corrupted.  Move the release into the locked region to avoid this.

Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 2c0a303a128cbef54a7b58dc2e413b874d760097)

Change-Id: I27a96e1b5ff3034fa068bda5436a479e01e5a61b
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: reorder initialization steps in regulator_register()

device_register() is calling ->get_voltage() as part of it's sysfs attribute
initialization process, and this functions might need to know the regulator
constraints to return a valid value.
This is at least true for the pwm regulator driver (when operating in
continuous mode) which needs to know the minimum and maximum voltage values
to calculate the current voltage:

min_uV + (((max_uV - min_uV) * dutycycle) / 100);

Move device_register() after set_machine_constraints() to make sure those
constraints are correctly initialized when ->get_voltage() is called.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: Stephen Barber <smbarber@chromium.org>
Tested-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 469b640e4f4a28bdd50f0ac1d2b310907afb464c)

Change-Id: I83c95e5baef0501876d19f1e2e7a7e3af8631b1f
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: Use parent voltage from the supply when bypassed

When a regulator is in bypass mode it is functioning as a switch
returning the voltage set in the regulator will not give the voltage
being output by the regulator as it's just passing through its supply.
This means that when we are getting the voltage from a regulator we
should check to see if it is in bypass mode and if it is we should
report the voltage from the supply rather than that which is set on the
regulator.

Reported-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
[treding@nvidia.com: return early for bypass mode]
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit fef95019016ac10e250d2c67a3c97af5797e3938)

Change-Id: I889789bce3018bec24ba9a0476217c0573ce9a27
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: pwm: Try to avoid voltage error in duty cycle calculation

In continuous mode of the PWM regulators, the requested voltage
PWM duty cycle is calculated in terms of 100% scale where entire
range denotes 100%. The calculation for PWM pulse ON time(duty_pulse)
is done as:

duty_cycle = ((requested - minimum) * 100) / voltage_range.

then duty pulse is calculated as
duty_pulse = (pwm_period/100) * duty_cycle

This leads to the calculation error if we have the requested voltage
where accurate pulse time is possible.
For example: Consider following case
voltage range is 800000uV to 1350000uV.
pwm-period = 1550ns (1ns time is 1mV).

Requested 900000uV.

duty_cycle = ((900000uV - 800000uV) * 100)/ 1550000
   = 6.45 but we will get 6.

duty_pulse = (1550/100) * 6 = 90 pulse time.

90 pulse time is equivalent to 90mV and this gives us pulse time equivalent
to 890000uV instead of 900000uV.

Proposing the solution in which if requested voltage makes the accurate
duty pulse then there will not be any error. On this case, if
(req_uV - min_uV) * pwm_period is perfect dividable by voltage_range
then get the duty pulse time directly.

duty_pulse = ((900000uV - 800000uV) * 1550)/1550000)
   = 100

and this is equivalent to 100mV and so final voltage is
(800000 + 100000) = 900000uV which is same as requested,

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit fd786fb0276a22155058018f76eb4c665d37f170)

Change-Id: I08b54da55b29be7f8cbf4c837bc2e2d993ebf9a0
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: Fix deadlock during regulator registration

Commit 5e3ca2b349b1 ("regulator: Try to resolve regulators supplies on
registration") added a call to regulator_resolve_supply() within
regulator_register() where the regulator_list_mutex is held. This causes
a deadlock to occur on the Tegra114 Dalmore board when the palmas PMIC
is registered because regulator_register_resolve_supply() calls
regulator_dev_lookup() which may try to acquire the regulator_list_mutex
again.

Fix this by releasing the mutex before calling
regulator_register_resolve_supply() and update the error exit path to
ensure the mutex is released on an error.

[Made commit message more legible -- broonie]

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit a2151374230820a3a6e654f2998b2a44dbfae4e1)

Change-Id: I65ac4aeac254d2ef3f161c422b92defd5badbbc4
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: of: Don't flag voltage change as possible for exact voltages

Flagging voltage changes as possible for exactly specified voltages
appears to be triggering bugs in the SDHCI code (it should be able to
handle the case where only one voltage it wants is in the range it is
allowed to set) so make sure we only set the flag in cases where there's
genuine variability.

Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 45fa2038cf7820ecfcca8793b81e656ca3caaf0f)

Change-Id: I68c5c8fd3ca2da2ddb07af125f57158441040af3
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: Log when we bring constraints into range

This aids in debugging problems triggered by the regulator core applying
its constraints, we could potentially crash immediately after updating
the voltage if the constraints are buggy.

Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 45a91e8f767afbbffff46bf7251f81d15d121136)

Change-Id: I8c3e4a856f05c13e6ce3db8a6d46686557109962
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: Try to resolve regulators supplies on registration

Commit 6261b06de565 ("regulator: Defer lookup of supply to regulator_get")
moved the regulator supplies lookup logic from the regulators registration
to the regulators get time.

Unfortunately, that changed the behavior of the regulator core since now a
parent supply with a child regulator marked as always-on, won't be enabled
unless a client driver attempts to get the child regulator during boot.

This patch tries to resolve the parent supply for the already registered
regulators each time that a new regulator is registered. So the regulators
that have child regulators marked as always on will be enabled regardless
if a driver gets the child regulator or not.

That was the behavior before the mentioned commit, since parent supplies
were looked up at regulator registration time instead of during child get.

Since regulator_resolve_supply() checks for rdev->supply, most of the times
it will be a no-op. Errors aren't checked to keep the possible out of order
dependencies which was the motivation for the mentioned commit.

Also, the supply being available will be enforced on regulator get anyways
in case the resolve fails on regulators registration.

Fixes: 6261b06de565 ("regulator: Defer lookup of supply to regulator_get")
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org> # 4.1+
(cherry picked from commit 5e3ca2b349b1e2c80b060b51bbf2af37448fad85)

Change-Id: I0e1530a985002c915d7a8e04f56b7f2e1acb60c7
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: Ensure we are at least in bounds for our constraints

Currently we only attempt to set the voltage during constraints
application if an exact voltage is specified.  Extend this so that if
the currently set voltage for the regulator is outside the bounds set in
constraints we will move the voltage to the nearest constraint, raising
to the minimum or lowering to the maximum as needed.  This ensures that
drivers can probe without the hardware being driven out of spec.

Reported-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Tested-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit fa93fd4ecc9c58475abac6db93a797bff893bc16)

Change-Id: I3e3e60f2f93e971364a74f9735c362acaa59f512
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: Remove duplicate copy of active-discharge parsing

Apparently due to a wrongly resolved merge conflict between two
branches, which contained the same commit, the commit contents
partially was added two times in a row.

This change reverts the latter wrong inclusion of commit 909f7ee0b5f3
("regulator: core: Add support for active-discharge configuration").

The first applied commit 670666b9e0af ("regulator: core: Add support
for active-discharge configuration") is not touched.

Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit e437b90026ac754a0f8b4fe44b844d12ce6162d1)

Change-Id: Iaa7a0c0bb6b7cad7c33e02ac9d90c8e098ad8c18
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: Always flag voltage constraints as appliable

Allow the core to always use the voltage constraints to set the voltage
on startup.  A forthcoming change in that code will ensure that we bring
out of constraints voltages into spec with this setting.

Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 895fe2321efaf62023fdd8239d1846394df68570)

Change-Id: I62f44ce1d8a2649a855ef93d9ec551b78ee4b40b
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: Remove unneded check for regulator supply

The regulator_resolve_supply() function checks if a supply has been
associated with a regulator to avoid enabling it if that is not the
case.

But the supply was already looked up with regulator_resolve_supply()
and set with set_supply() before the check and both return on error.

So the fact that this statement has been reached means that neither
of them failed and a supply must be associated with the regulator.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 95a293c7ba17253b8cffcacbdd716ebfbfe42587)

Change-Id: Ib4738ae3f733256a2ba794543430ffde2c434352
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: pwm: Prints error number along with detail

Prints the error number along with error message when any
error occurs. This help on getting the reason of failure
quickly from log without any code instrument.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 5bf59bd5e9a5b262110df8c1ea5ad8820d7d524a)

Change-Id: If370a4b4b44064ef978bd3b0b6d172e0259a5843
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: pwm: Add support to have multiple instance of pwm regulator

Some of platforms like Nvidia's Tegra210 Jetson-TX1 platform has
multiple PMW based regulators. Add support to have multiple instances
of the driver by not changing any global data of pwm regulator and
if required, making instance specific copy and then making changes.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit f907a0a9498db29fb7c91b798d7af70add7dd86e)

Change-Id: Iafd9b033cd67a76a430024840f70e275a6d22e0d
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: pwm: Fix calculation of voltage-to-duty cycle

With following equation for calculating
voltage_to_duty_cycle_percentage
100 - (((req_uV * 100) - (min_uV * 100)) / diff);

we get 0% for max_uV and 100% for min_uV.

Correcting this to
((req_uV * 100) - (min_uV * 100)) / diff;
 to get proper duty cycle.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 1aaab34878ac14efede3f0e737b99447745699d1)

Change-Id: I61d88577ece2d7bec3e9ea6c863c101c65892271
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: of: Use of_property_read_u32() for reading min/max

OF interface provides to read the u32 value via standard interface
of_property_read_u32(). Use this API to read "regulator-min-microvolts"
and "regulator-max-microvolt".

This will make consistent with other property value reads.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit a34785f10d33f70680941da284d7ec3a612aad1a)

Change-Id: I12da714ca47197932e693567e34927a7ddd26f01
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: Add support for active-discharge configuration

Add support to enable/disable active discharge of regulator via
machine constraints. This configuration is done when setting
machine constraint during regulator register and if regulator
driver implemented the callback ops.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 909f7ee0b5f30f735e16864a7ed18d2e6123e6d9)

Change-Id: I9b989b8b88e9d8e765a6cefb1a189c86e7c87dbe
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: helper: Add helper to configure active-discharge using regmap

Add helper function to set the state of active-discharge of
regulator using regmap. The HW regulator driver can directly
use this by providing the necessary information in the regulator
descriptor.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 354794dacc213da7596cefea4dbcd8c094368807)

Change-Id: I195290ac6ddfbadc7876a28b6df5149530954484
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: Add support for active-discharge configuration

Add support to enable/disable active discharge of regulator via
machine constraints. This configuration is done when setting
machine constraint during regulator register and if regulator
driver implemented the callback ops.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 670666b9e0aff40c65d8061a2f53e79eee238685)

Change-Id: I5e22602d9a44b88482922ae0a726fd0d8f374e0a
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: fix crash in error path of regulator_register

This problem was introduced by:
commit daad134d6649 ("regulator: core: Request GPIO before creating
sysfs entries")

The error path was not updated correctly after moving GPIO registration
code and in case regulator_ena_gpio_free failed, device_unregister() was
called even though device_register() was not yet called.

This problem breaks the boot at least on all Tegra 32-bit devices. It
will also crash each device that specifices GPIO that is unavaiable at
regulator_register call. Here's error log I've got when forced GPIO to
be invalid:

[    1.116612] usb-otg-vbus-reg: Failed to request enable GPIO10: -22
[    1.122794] Unable to handle kernel NULL pointer dereference at
virtual address 00000044
[    1.130894] pgd = c0004000
[    1.133598] [00000044] *pgd=00000000
[    1.137205] Internal error: Oops: 5 [#1] SMP ARM

and here's backtrace from KDB:

Exception stack(0xef11fbd0 to 0xef11fc18)
fbc0:                                     00000000 c0738a14 00000000 00000000
fbe0: c0b2a0b0 00000000 00000000 c0738a14 c0b5fdf8 00000001 ef7f6074 ef11fc4c
fc00: ef11fc50 ef11fc20 c02a8344 c02a7f1c 60000013 ffffffff
[<c010cee0>] (__dabt_svc) from [<c02a7f1c>] (kernfs_find_ns+0x18/0xf8)
[<c02a7f1c>] (kernfs_find_ns) from [<c02a8344>] (kernfs_find_and_get_ns+0x40/0x58)
[<c02a8344>] (kernfs_find_and_get_ns) from [<c02ac4a4>] (sysfs_unmerge_group+0x28/0x68)
[<c02ac4a4>] (sysfs_unmerge_group) from [<c044389c>] (dpm_sysfs_remove+0x30/0x5c)
[<c044389c>] (dpm_sysfs_remove) from [<c0436ba8>] (device_del+0x48/0x1f4)
[<c0436ba8>] (device_del) from [<c0436d84>] (device_unregister+0x30/0x6c)
[<c0436d84>] (device_unregister) from [<c0403910>] (regulator_register+0x6d0/0xdac)
[<c0403910>] (regulator_register) from [<c04052d4>] (devm_regulator_register+0x50/0x84)
[<c04052d4>] (devm_regulator_register) from [<c0406298>] (reg_fixed_voltage_probe+0x25c/0x3c0)
[<c0406298>] (reg_fixed_voltage_probe) from [<c043d21c>] (platform_drv_probe+0x60/0xb0)
[<c043d21c>] (platform_drv_probe) from [<c043b078>] (driver_probe_device+0x24c/0x440)
[<c043b078>] (driver_probe_device) from [<c043b5e8>] (__device_attach_driver+0xc0/0x120)
[<c043b5e8>] (__device_attach_driver) from [<c043901c>] (bus_for_each_drv+0x6c/0x98)
[<c043901c>] (bus_for_each_drv) from [<c043ad20>] (__device_attach+0xac/0x138)
[<c043ad20>] (__device_attach) from [<c043b664>] (device_initial_probe+0x1c/0x20)
[<c043b664>] (device_initial_probe) from [<c043a074>] (bus_probe_device+0x94/0x9c)
[<c043a074>] (bus_probe_device) from [<c043a610>] (deferred_probe_work_func+0x80/0xcc)
[<c043a610>] (deferred_probe_work_func) from [<c01381d0>] (process_one_work+0x158/0x454)
[<c01381d0>] (process_one_work) from [<c013854c>] (worker_thread+0x38/0x510)
[<c013854c>] (worker_thread) from [<c013e154>] (kthread+0xe8/0x104)
[<c013e154>] (kthread) from [<c0108638>] (ret_from_fork+0x14/0x3c)

Signed-off-by: Krzysztof Adamski <krzysztof.adamski@tieto.com>
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 32165230eb6e629d7f88e66e0bd90a201549de53)

Change-Id: I08cf9670f329d917478f86f38ac343d6c55f3827
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: Request GPIO before creating sysfs entries

regulator_attr_is_visible (which is a .is_visible callback of
regulator_dev_group attribute_grpup) checks rdev->ena_pin to decide if
"status" file should be present in sysfs. This field is set at the end
of regulator_ena_gpio_request so it has to be called before
device_register() otherwise this test will always fail, causing "status"
file to not be visible.

Since regulator_attr_is_visible also tests for is_enabled() op, this
problem is only visible for regulators that does not define this
callback, like regulator-fixed.c.

Signed-off-by: Krzysztof Adamski <krzysztof.adamski@tieto.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit daad134d66492a9f641163c94510549770b39657)

Change-Id: I4c80adfd790bfec41b4817430c3af7c54a7b446e
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: Rely on regulator_dev_release to free constraints

As we now free the constraints in regulator_dev_release we will still
call free on the constraints pointer even if we went down an error
path in regulator_register, because it is only allocated after the
device_register. As such we no longer need to free rdev->constraints
on the error paths, so this patch removes said frees.

Fixes: 29f5f4860a8e ("regulator: core: Move more deallocation into class unregister")
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 6333ef46bbe514a8ece6c432aab6bcf8637b2d7c)

Change-Id: I731b81e175ef9fb519e2090590f5e7c081f748a2
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: remove some dead code

Originally queue_delayed_work() used to negative error codes or 0 and 1
on success depending if the work was queued or not.  It caused a lot of
bugs where people treated all non-zero returns as failures so we changed
it to return bool instead in d4283e937861 ('workqueue: make queueing
functions return bool').  Now it never returns failure.

Checking for negative values causes a static checker warning since it is
impossible based on the bool type.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 70dc6daff090afaab588e800fca3db59bfac694e)

Change-Id: I173125414dbb933e36692286e2f95541d396edc5
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: core: use dev_to_rdev

Use dev_to_rdev() instead of open-coding it.

Signed-off-by: Geliang Tang <geliangtang@163.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 83080a140874b6860b5191b375cfdad267eaa107)

Change-Id: I63e284044a4681bdaa053191e8f77017430135de
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: regulator: Make bulk API support optional supplies

Make it possible to use the bulk API with optional supplies, by allowing
the consumer to marking supplies as optional in the regulator_bulk_data.

Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 3ff3f518a135fa4592fe2817e9ac2cce1fa23dc2)

Change-Id: I1bf21d36ca181932bf7c626d45fef49b50931ac9
Signed-off-by: David Wu <david.wu@rock-chips.com>

drm: bridge/dw_hdmi: fix avi colorspace and scan_mode

According to the dw-hdmi spec, colorspace in bits 0,1,7,
scan_mode in bits 4,5.

Change-Id: I45233316ea7d5ce75d3844c183654f161cbf505e
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

Revert "drm/edid: Add 3840x2160@60hz modes"

This reverts commit 6976f8c987983642ac229bceaa185a87ae45f4fa.

Change-Id: Ib14873c3f7535c7932caf8caf629055bac3e9b5e
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

UPSTREAM: mmc: dw_mmc: The "clock-freq-min-max" property was deprecated

The "clock-freq-min-max" property was deprecated.
There is "max-frequency" property in drivers/mmc/core/host.c
"max-frequency" can be replaced with "clock-freq-min-max".
Minimum clock value might be set to 100K by default.
Then MMC core should try to find the correct value from 400K to 100K.
So it just needs to set Maximum clock value.

Change-Id: I1c72a891c8afd221b0c395c32c7adf8696cc46f1
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit b023030f10573de738bbe8df63d43acab64c9f7b)

UPSTREAM: mmc: dw_mmc: change the DW_MCI_FREQ_MIN from 400K to 100K

If there is no property "clock-freq-min-max", mmc->f_min should be set
to 400K by default. But Some SoC can be used 100K.
When 100K is used, MMC core will try to check from 400K to 100K.

Change-Id: I059c994f1654c212bcff9b85dbffd9697d800eaf
Reported-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 72e83577bc5bc02a92c7fd47d108de11c04dcbf0)

FROMLIST: drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

HDMI 2.0 introduces a new sampling mode called YCbCr 4:2:0.
According to the spec the EDID may contain two blocks that
signal this sampling mode:
- YCbCr 4:2:0 Video Data Block
- YCbCr 4:2:0 Video Capability Map Data Block

The video data block contains the list of vic's were
only YCbCr 4:2:0 sampling mode shall be used while the
video capability map data block contains a mask were
YCbCr 4:2:0 sampling mode may be used.

This RFC patch adds support for parsing these two new blocks
and introduces new flags to signal the drivers if the
mode is 4:2:0'only or 4:2:0'able.

The reason this is still a RFC is because there is no
reference in kernel for this new sampling mode (specially in
AVI infoframe part), so, I was hoping to hear some feedback
first.

Tested in a HDMI 2.0 compliance scenario.

Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Cc: Carlos Palminha <palminha@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
(am from https://patchwork.kernel.org/patch/9495175)
Change-Id: I7c9e331b5bf5f1fbcefd4368bc4b82ff180eb91e
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

FROMLIST: drm/edid: Complete CEA modedb(VIC 1-107)

CEA-861-F specs defines new 4k video modes to be used with
HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
way till VIC=107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse 4k modes using the existing techniques, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
V2: Addressed review comments from Jose:
- fix the timings for VIC 83, 90 and 91
- fix formatting for VIC 93-107

V3: Rebase on drm-tip

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
(am from https://patchwork.kernel.org/patch/9543865/)
Change-Id: I3708db9a06a1d57c4714aed67fb7ef3711ea0d1e
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

UPSTREAM: video: Add new aspect ratios for HDMI 2.0

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.

V2: rebase
V3: rebase
V4: Added r-b from Jose, Ack by Tomi

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1476705880-15600-4-git-send-email-shashank.sharma@intel.com
Change-Id: Ia0f63835c5ab44482baaf08c6f498d30997814d5
(cherry picked from commit a6e78b3e1406575323b30b65890ee3c29930fb27)
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

UPSTREAM: drm/edid: index CEA/HDMI mode tables using the VIC

Add a dummy entry to CEA/HDMI mode tables so they can be indexed
directly using the VIC, avoiding a +1/-1 dance here and there. This adds
clarity to the error checking for various functions that return the VIC
on success and zero on failure; we can now explicitly check for 0
instead of just subtracting one from an unsigned type.

Also add drm_valid_cea_vic() and drm_valid_hdmi_vic() helpers for
checking valid VICs.

v2: add drm_valid_cea_vic and drm_valid_hdmi_vic helpers (Ville)
    use { } instead of { 0 } for initializing the dummy modes

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452252111-6439-1-git-send-email-jani.nikula@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Change-Id: Id47deb7a806b896c047317ca8924ef73abb01095
(cherry picked from commit d9278b4c2c31603474eec19d9ea1dea6b3a81087)
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

UPSTREAM: drm/edid: Make the detailed timing CEA/HDMI mode fixup accept up to 5kHz clock difference

Rather than using drm_match_cea_mode() to see if the EDID detailed
timings are supposed to represent one of the CEA/HDMI modes, add a
special version of that function that takes in an explicit clock
tolerance value (in kHz). When looking at the detailed timings specify
the tolerance as 5kHz due to the 10kHz clock resolution limit inherent
in detailed timings.

drm_match_cea_mode() uses the normal KHZ2PICOS() matching of clocks,
which only allows smaller errors for lower clocks (eg. for 25200 it
won't allow any error) and a bigger error for higher clocks (eg. for
297000 it actually matches 296913-297000). So it doesn't really match
what we want for the fixup. Using the explicit +-5kHz is much better
for this use case.

Not sure if we should change the normal mode matching to also use
something else besides KHZ2PICOS() since it allows a different
proportion of error depending on the clock. I believe VESA CVT
allows a maximum deviation of .5%, so using that for normal mode
matching might be a good idea?

Change-Id: I824ec50368ddf152c9daa747ba92aaba1ef50f4b
Cc: Adam Jackson <ajax@redhat.com>
Tested-by: nathan.d.ciobanu@linux.intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92217
Fixes: fa3a7340eaa1 ("drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 4c6bcf44549907cb50b67f98eb13717a4adc6b33)
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

arm64: dts: rk3399: use hdmi-ddc for hdmi ddc bus in android

Change-Id: I8d90207d8899c09ed424d939a4a80d7f46b63163
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

arm64: dts: rockchip: move more common nodes to rk3368-android

Also fix io_domains and pmu_io_domains on rk3368-tb.dtsi

Change-Id: I90867a839079f67c68b8588304e06f7566749a3d
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

regulator: rk818: fix of_regulator_match table boost id missing

Change-Id: I9703deb0cef7b6e721fb7e5f68ffbea5803bdc5a
Signed-off-by: chenjh <chenjh@rock-chips.com>

ARM: dts: rockchip: use hdmi-ddc for ddc bus in miniarm

Using the builtin I2C controller in dw_hdmi is better than using the
normal RK3288 I2C controller(I2C5).

TEST: work normally when switch mode between 4K@60hz|4K@30hz|1080P..
Change-Id: Ic7287f9a87f0d701a10cbb94f6ae9f11f981739c
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>

drm: bridge/dw_hdmi: Add scdc operations for HDMI2.0

This patch do the following operation with scdc:

1、TMDS Configuration
   set TMDS_Bit_Clock_Ratio bit when supports TMDS Bit Rates
   above 3.4 Gbps
   (details see HDMI2.0 Specification Section 6.1.3.2)

2、Scrambling Control
   set Scrambling_Enable bit when it needs.
   (details see HDMI2.0 Specification Section 6.1.3.1)

Change-Id: Ibd4428bdf752d767caf9dd4e03f3c8d240f18f6b
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>

FROMLIST: mmc: core: Fix access to HS400-ES devices

HS400-ES devices fail to initialize with the following error messages.

mmc1: power class selection to bus width 8 ddr 0 failed
mmc1: error -110 whilst initialising MMC card

This was seen on Samsung Chromebook Plus. Code analysis points to
commit 3d4ef329757c ("mmc: core: fix multi-bit bus width without
high-speed mode"), which attempts to set the bus width for all but
HS200 devices unconditionally. However, for HS400-ES, the bus width
is already selected.

Change-Id: I877b225a2ab9da623061288b2f908e956754107a
Cc: Anssi Hannula <anssi.hannula@bitwise.fi>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>
Fixes: 3d4ef329757c ("mmc: core: fix multi-bit bus width ...")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chip.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>

arm64: rockchip_defconfig: update by savedefconfig

Change-Id: I09275a9a494d9c7c13f800ddf0b5b30eb3c2e761
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

Merge branch 'linux-linaro-lsk-v4.4-android' of git://git.linaro.org/kernel/linux-linaro-stable.git

* linux-linaro-lsk-v4.4-android: (434 commits)
  Linux 4.4.52
  kvm: vmx: ensure VMCS is current while enabling PML
  Revert "usb: chipidea: imx: enable CI_HDRC_SET_NON_ZERO_TTHA"
  rtlwifi: rtl_usb: Fix for URB leaking when doing ifconfig up/down
  block: fix double-free in the failure path of cgwb_bdi_init()
  goldfish: Sanitize the broken interrupt handler
  x86/platform/goldfish: Prevent unconditional loading
  USB: serial: ark3116: fix register-accessor error handling
  USB: serial: opticon: fix CTS retrieval at open
  USB: serial: spcp8x5: fix modem-status handling
  USB: serial: ftdi_sio: fix line-status over-reporting
  USB: serial: ftdi_sio: fix extreme low-latency setting
  USB: serial: ftdi_sio: fix modem-status error handling
  USB: serial: cp210x: add new IDs for GE Bx50v3 boards
  USB: serial: mos7840: fix another NULL-deref at open
  tty: serial: msm: Fix module autoload
  net: socket: fix recvmmsg not returning error from sock_error
  ip: fix IP_CHECKSUM handling
  irda: Fix lockdep annotations in hashbin_delete().
  dccp: fix freeing skb too early for IPV6_RECVPKTINFO
  ...

Conflicts:
drivers/mmc/core/mmc.c
drivers/usb/dwc3/ep0.c
drivers/usb/host/xhci.h

Change-Id: Icf331a68162ab686d01996a3f43fa2e97543f62e

UPSTREAM: PCI: rockchip: Set vendor ID from local core config space

The TRM says the vendor ID in the RC's configure space can be rewritten
and the value must be the same as the value read from the local core
configure space.  But we misread that and didn't notice it before.  Actually
we should only able to rewrite it from the local core configure space.

Fix that issue to make lspci show the correct IP vendor infomation.

Change-Id: Ia33bc0c10970649cc86bd02136f0ee997f18246d
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from 5800790a925b0aefb621ae3da86668c3a2867750)

phy: rockchip-emmc: enable internal pull-down for strobe line

We enable it by default as we could see the usage of PCB layout
will not stuff this registor. For currently boards which soldered
it already, there should be no harmful.

Change-Id: I913d6412d9e4589ded5ca012e46fe3e93075cc0d
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: xiaoyao <xiaoyao@rock-chips.com>

arm64: dts: rockchip: add rk3368-android.dtsi

Move some Android only nodes to rk3368-android.dtsi

Change-Id: I6fe283d4c247479945fbc3396cc65392268a2731
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

drm: scdc: correct Makefile mistake

Change-Id: Ibf4e1de4c5f398366c991b6bea0cafdbdaf8ab48
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>

arm64: dts: rockchip: reorder pinctrl of pwm nodes for rk3368

keep order as upstream.

Change-Id: I069ec407292922a72900c34b32c3d67f5cdf0a3b
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

UPSTREAM: arm64: dts: rockchip: add rk3368-r88 iodomains

Add the supply-links according to the R88 schematics.

Change-Id: Ia5119019d9d8b3d2d1990119f0947eaa0b901586
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 39e5f7bb98c979f563e08e8e4cd70989e5369da3)

UPSTREAM: arm64: dts: rockchip: add rk3368 io-domain core nodes

Add the core io-domain nodes to grf and pmugrf which individual
boards than just have to enable and add the necessary supplies to.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit d1ab05aba954ec02f087f6908d4e060655bde92c)

Change-Id: Ib70f0195544466b089866ac31eb9ea6fe73c5d59
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

UPSTREAM: arm64: dts: rockchip: make rk3368 grf syscons simple-mfds

The general register files do contain a lot of separate functions and
while some really are only registers with a lot of different 1-bit
settings, there are also a lot of them containing some bigger function
blocks. To be able to define these as sub-devices, make them simple-mfds.

Change-Id: I666e4fe9e6239a91ccaa70154883128be34f17c6
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: David Wu <david.wu@rock-chips.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 4cca3d9448bcc18b607dce2f962a614a415ddaae)

UPSTREAM: arm64: dts: rockchip: move the rk3368 thermal data into rk3368.dtsi

In order to be standard to manage for rockchip SoCs,  move the thermal
data into rk3368 dtsi, we needn't to add a new file for thermal.

Change-Id: I4cadb8742fb103f5642a8d122ebb5970eb140d30
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit 6ddf93e05e67f81b6a95840c35e1aa6e042196a8)

UPSTREAM: Documentation: devicetree: rockchip: Document rk3368-GeekBox

Use "geekbuying,geekbox" compatible string.

Signed-off-by: Andreas Färber <afaerber@suse.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit 40ac568d0ef07b60ba8cc0f2e88ccdd4dd0e176a)

Change-Id: Ib73b858a68753f77fe60cf4afea51151590e4585
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

UPSTREAM: arm64: dts: rockchip: Add rk3368 GeekBox dts

The GeekBox contains an MXM3 module with a Rockchip RK3368 SoC.
Some connectors are available directly on the module.

This adds initial support, namely serial, USB, GMAC, eMMC, IR and TSADC.

Change-Id: Ic9956b3b935467e3492bdab274579d4cd038d4e6
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit fd7b980c9e1e52d41589c41ae166b0cfae32b210)

UPSTREAM: arm64: dts: rockchip: Add rk3368 mailbox device nodes

This adds mailbox device nodes in dts.

Mailbox is used by the Rockchip CPU cores to communicate
requests to MCU processor.

Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit 6e7f9f5ad552327fcc1151e2dca141075f3e160a)

Change-Id: I9b93b2b3c28ca686c297d839077df5d725436f2f

UPSTREAM: arm64: dts: rockchip: fix the incorrect otp-out pin on rk3368

This patch fixes the incorrect Over-temperature protection pin.
since the rk3368 io list said the otp pin is gpio0a3.

Anyway, that should be fixed in here.

Change-Id: I0b868b6a2e1aac3eea21d6de4787b169a53ade5e
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit 04317584ff1ad6977ba37acf38d2c6b841ce20a4)

UPSTREAM: arm64: dts: rockchip: add rk3368 tuning clk for emmc and sdmmc

Add tuning clk for emmc and sdmmc, otherwise I get
the following failure while enabling mmc-hs200-1_8v.

dwmmc_rockchip ff0f0000.dwmmc: Tuning clock (sample_clk) not defined.
mmc0: tuning execution failed
mmc0: error -5 whilst initialising MMC card

With it
dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to 170
mmc0: new HS200 MMC card at address 0001
mmcblk0: mmc0:0001 M8G1GC 7.28 GiB

Change-Id: I14534f43249edecbb8239f4a86c808ebb7f0a959
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit 90191625ec0d075ac0748181ae1b947b0b30297e)

UPSTREAM: dt-bindings: rockchip-dw-mshc: add RK3368 dw-mshc description

rk3368 dtsi file add dw-mshc compatible "rockchip,rk3368-dw-mshc"
but didn't add it into rockchip-dw-mshc.txt.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit b662f6d03aeeb20c0f795f469341778f4577a6bf)

Change-Id: I2e97ad3a8701ab2391e421248595092b9a22569d

UPSTREAM: arm64: dts: rockchip: Add the broadcast-timer for RK3368 SoC

There is a need of a broadcast timer in this case to ensure proper
wakeup when the cpus are in sleep mode and a timer expires.

Change-Id: I8ab0e5506420e2650acc1dac4d5667f40c0d3b4f
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit b8084e5b34e83875846053bf9cd951b7640e40fe)

UPSTREAM: arm64: dts: rockchip: Fix typo in rk3368 sdmmc card detect pin name

The card detect pin is currently called sdmcc-cd.
This patch fixes the typo and renames the pin to sdmmc-cd.

Change-Id: I47ac2767ea442764bf71411ebd66de56e9c1e934
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 8fc5abd40efadf57ca43189c9c14c4de3db6300e)

UPSTREAM: arm64: dts: rockchip: correct voltage range for rk3368-evb-act8846 board

In general, the logic voltage is affected by ddr frequency factors.
We should fix the correct voltage range since assuemd that we have the
ddr frequency driver in mainline.

AFAIK, the 1.8v voltage is used by the SD3.0 card.

Change-Id: Id0ae87c7ec6d3d757fdde0b85caf1f535d200222
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit 87ac9de3b44fd6dc8d95a59e67b086c3e57285f8)

UPSTREAM: arm64: dts: rockchip: add rk3368 evaluation board

This board is similar with the rk3288 evb board but the rk3368 top
board. There exist the act8846 as the pmic.

Moment, add the balight/thermal/emmc/usb.. stuff,
Let the board can happy work.

Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit 5378e28c9776fbab6065cfb54417acff3ea5f1fd)

Change-Id: I78f39fa080d221e06849285b6a0c52bc04d5d1a9

UPSTREAM: arm64: dts: rockchip: Add main thermal info to rk3368.dtsi

This patch add the thermal needed info on RK3368.
Meanwhile, support the trips to throttle for thermal.

Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Acked-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit f990238f859e95841ecd151da258ea999555f609)

Change-Id: I76ba5230b1a334562ce7607aa02fec445612070c

UPSTREAM: arm64: dts: rockchip: Setup rk3368 ethernet0 alias for u-boot

Add an ethernet0 alias for the RK3368 mac interface so
that u-boot can find the device-node and fill in the mac address on
boards that support a wired network interface.

Change-Id: I2f82939290a0807ed84a3e93f6b0eef879cce076
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit ff08868ef0154cef01d3a50ae1f19dc968fc95f3)

drm: export drm_get_connector_name to fix compile problem

Fix compile error:
ERROR: "drm_get_connector_name" [drivers/gpu/drm/rockchip/rockchipdrm.ko] undefined!

Change-Id: If1ad322319bf4c20fa6b56be62024472a8272431
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

UPSTREAM: regulator: rk808: Use rdev_get_id() to access id of regulator

RK808_ID_DCDC1 is 0, no need to do subtract RK808_ID_DCDC1.

Change-Id: I395c30866aeb5c4c285dd083109a70bfef24bfca
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit bf8e27621effb49da525fb92a1f192db685d39bd)
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

UPSTREAM: regulator: rk808: Add regulator driver for RK818

Add support for the rk818 regulator. The regulator module consists
of 4 DCDCs, 9 LDOs, 1 switch and 1 BOOST converter which is used to
power OTG and HDMI5V.

The output voltages are configurable and are meant to supply power
to the main processor and other components.

Change-Id: I129a1f22c65684615e9ae792efaa880555f0235e
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
(cherry picked from commit 11375293530bb8434946c8c043f1adf5ffb6be10)
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

UPSTREAM: regulator: rk808: Delete owner assignment

The field "owner" is set by core. Thus delete an extra initialisation.

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
Change-Id: I7a2e347e07943c7eb5b2c9cae4eae2358a613e0e
(cherry picked from commit 556ae220ac64b6564be8d76d855e26b65fcf75bf)
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

UPSTREAM: regulator: rk808: Migrate to regulator core's simplified DT parsing code

A common simplified DT parsing code for regulators was introduced in
commit a0c7b164ad11 ("regulator: of: Provide simplified DT parsing
method")

While at it also added RK8XX_DESC and RK8XX_DESC_SWITCH macros for the
regulator_desc struct initialization. This just makes the driver more compact.

Change-Id: I5c1211decf37d27a68167be9b6354834532cc87b
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 9e9daa0a67d59df432664cdca1cf4659057fd00c)
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

UPSTREAM: regulator: rk808: Add rk808_reg_ops_ranges for LDO3

LDO_REG3 descriptor is using linear_ranges.
Add and use proper ops for LDO_REG3.

Change-Id: Iad515fd23e7b3bca6248739a54335a71eed01238
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 129d7cf98f5c739014ae5aa0311e48f6a64b0758)
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

UPSTREAM: regulator: rk808: remove unused rk808_reg_ops_ranges

After removing all uses of the range operations in a recent patch,
we get a warning about the symbol not being referenced anywhere:

drivers/regulator/rk808-regulator.c:306:29: 'rk808_reg_ops_ranges' defined but not used

This removes the now-unused structure along with the
rk808_set_suspend_voltage_range function that is only referenced from
rk808_reg_ops_ranges.

Fixes: afcd666d9db0 ("regulator: rk808: remove linear range definitions with a single range")
Change-Id: I565c91186ab5d7457a62b3bc4b4896a08f39dd2e
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 4a5ed8c1adc39f86a2887183c71b007bc962fdce)
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

UPSTREAM: regulator: rk808: remove linear range definitions with a single range

The driver was using only linear ranges. Now we remove linear range
definitions with a single range. So we have to add an ops struct for
ranges and adjust all other ops functions accordingly.

Change-Id: I6b2dd5e035832f9460ec8a24b5214204f7a930b7
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit afcd666d9db0ebfbf2751cce1e07b548547ca82e)
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

arm64: dts: rockchip: add dts file for rk3399-evb-rev3-android

Change-Id: I63306691f6b99243bec6289acda7abe303c70266
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

arm64: dts: rockchip: cleanup rk3399-android.dtsi

default enable rkvdec and vpu.
rga is default on, remove duplicate configuration.

Change-Id: I8375b2202a81977238e8120e1c2d60f2130844b5
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

drm/rockchip: dw_hdmi: add default 594Mhz clk for 4K@60hz

add 594Mhz configuration parameters in rockchip_phy_config

Change-Id: Iaa335cdd90059817fd9892877e574f8b84f2b5dc
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>

drm/edid: Add 3840x2160@60hz modes

Add 3840x2160@60hz modes in edid_4k_modes[] array.

Change-Id: I6d14cecebb68ccfaf4e92109a44bde0eb132f73b
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>

FROMLIST: drm: edid: HDMI 2.0 HF-VSDB block parsing

Adds parsing for HDMI 2.0 'HDMI Forum Vendor
Specific Data Block'. This block is present in
some HDMI 2.0 EDID's and gives information about
scrambling support, SCDC, 3D Views, and others.

Parsed parameters are stored in drm_connector
structure.
(am from: https://patchwork.kernel.org/patch/9273645)

Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Change-Id: I5a1485b79a407fd27ac4754827de318175bb8f6a
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>

FROMLIST: drm: Add SCDC helpers

SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.

This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.

(am from: https://patchwork.kernel.org/patch/7258251/)

Change-Id: I378bc2b465a720ccfede35a93bce0d9371e78f78
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>

dt-bindings: rockchip: add missing vop document

Change-Id: Idd86084787216bc835d9e3e8cf4e9d04975da68c
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

ARM64: dts: rk3328: add vop display node

Change-Id: I60322993b782a6d04ca7e46fdc114a0fbc43778a
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

drm/rockchip: support rk3328 vop

Change-Id: Ic8c1073a22b62fc9a1b2e758429298538727c20e
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

drm/rockchip: vop: get rid of max_output_fb

max_output_fb is similar to max_display_output

Change-Id: I2045dd1ca5f7c99d723122d1b6c9dbf600db9c61
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

drm/rockchip: vop: improve and add more info to vop sysfs

cat /sys/kernel/debug/dri/0/summary:

VOP [ff900000.vop]: ACTIVE
    Connector: DSI
        bus_format[0] output_mode[0]
    Display mode: 1200x1920p60
        clk[159390] real_clk[159390] type[8] flag[a]
        H: 1200 1280 1281 1341
        V: 1920 1955 1956 1981
    win0-0: DISABLED
    win1-0: DISABLED
    win2-0: ACTIVE
        format: XB24 little-endian (0x34324258)
        zpos: 0
        src: pos[0x0] rect[1200x1920]
        dst: pos[0x0] rect[1200x1920]
        buf[0]: addr: 0x0000000002d3a000 pitch: 4800 offset: 0
    win2-0: DISABLED
    win2-1: DISABLED
    win2-2: DISABLED
    win3-0: DISABLED
    win3-0: DISABLED
    win3-1: DISABLED
    win3-2: DISABLED
VOP [ff8f0000.vop]: DISABLED

Change-Id: I7811b2411bd9d2d52059d15645de399b0de5a49b
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

drm: support drm_get_connector_name

Change-Id: I075d948afc2baa47fb147f9a967844a872171397
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

arm64: dts: rockchip: add cpu's power coefficient for rk3328

Change-Id: I33112b21b8f92482ba8e337d622e51948ec923a0
Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com>

arm64: dts: rockchip: add tsadc and thermal basic config for rk3328

Change-Id: Ic0d417093c54fea5948fd79cab276ebe7aea0f2e
Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com>

thermal: rockchip: add rk3328 support

Change-Id: I31f87741a874657fb7caf494ebafd53b6c0ef3b1
Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com>

arm64: dts: rockchip: complete cpufreq config data for rk3328

Change-Id: I422ec388ab6d66e1ba669028d7b88525569e88d5
Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com>

Merge branch 'linux-linaro-lsk-v4.4' into linux-linaro-lsk-v4.4-android

 Merge tag 'v4.4.52' into linux-linaro-lsk-v4.4

 This is the 4.4.52 stable release

Linux 4.4.52

kvm: vmx: ensure VMCS is current while enabling PML

commit 4e59516a12a6ef6dcb660cb3a3f70c64bd60cfec upstream.

Between loading the new VMCS and enabling PML, the CPU was unpinned.
If the vCPU thread were migrated to another CPU in the interim (e.g.,
due to preemption or sleeping alloc_page), then the VMWRITEs to enable
PML would target the wrong VMCS -- or no VMCS at all:

  [ 2087.266950] vmwrite error: reg 200e value 3fe1d52000 (err -506126336)
  [ 2087.267062] vmwrite error: reg 812 value 1ff (err 511)
  [ 2087.267125] vmwrite error: reg 401e value 12229c00 (err 304258048)

This patch ensures that the VMCS remains current while enabling PML by
doing the VMWRITEs while the CPU is pinned. Allocation of the PML buffer
is hoisted out of the critical section.

Signed-off-by: Peter Feiner <pfeiner@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Herongguang (Stephen)" <herongguang.he@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "usb: chipidea: imx: enable CI_HDRC_SET_NON_ZERO_TTHA"

commit 1bc7da87c7410c6990c3251589e3854e64c55af2 upstream.

This reverts commit e765bfb73ff7.

In the most of cases, we only use one transaction per frame and the
frame rate may be high, If the platforms want to support multiple
transactions but less frame rate cases like [1] and [2], it can set
"non-zero-ttctrl-ttha" at dts.

[1] http://www.spinics.net/lists/linux-usb/msg123125.html
[2] http://www.spinics.net/lists/linux-usb/msg118679.html

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Cc: Martin Fuzzey <mfuzzey@parkeon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>