drm: bridge/dw_hdmi: support HDMI 2.0 YCbCr 4:2:0

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

ARM64: dts: rockchip: rk3368: add ramp-delay for syr82x dcdc

Change-Id: I61ef71b32aa708123909124b89f61e8a8f3a1bb7
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

mfd: rk818: use rk808-regulator

Change-Id: Ib7150f229a4682b6d0f4c5a6776a9ebc8565d221
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

drm: redefine YCbCr420 flag to bits 23:24

Since bits[19:22] have been used for picture aspect ratio
in upstream patch 876f43c073d79ad3f14a4cebd1aea1f39fc4daf5.
We define YCbCr420 flag to the subsequent bits.

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

UPSTREAM: drm: add picture aspect ratio flags

This patch adds drm flag bits for aspect ratio information

Currently drm flag bits don't have field for mode's picture
aspect ratio. This field will help the driver to pick mode with
right aspect ratio, and help in setting right VIC field in avi
infoframes.

V2: Addressed review comments from Sean
- Changed PAR-> PIC_AR
V3: Rebase
V3: Added r-b by Jose

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.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-2-git-send-email-shashank.sharma@intel.com
(cherry picked from commit 876f43c073d79ad3f14a4cebd1aea1f39fc4daf5)
Change-Id: I7dc4d82722d4824ba2b6c041080373175b8f6d18
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

drm/rockchip: gem: reorder pages if page chunk less than 8

Change-Id: I03a91d2f9c017086b3cb35edeaf6b7913b147b9b
Signed-off-by: Simon <xxm@rock-chips.com>

ARM64: dts: rk3399: Add pd/clk for iommu

Change-Id: I6da7372e82a031140fead601a0661260be75855b
Signed-off-by: Simon <xxm@rock-chips.com>

drm/rockchip: support YUV420 output mode

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

drm/rockchip: vop: fixup color space table

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

video: rockchip: vcodec: add reg_rlc inside dec_pp

dec_pp also need to remap input fd.

Change-Id: Ic19a14a5ccc002b5be36d90ec3114244d5e494aa
Signed-off-by: Jung Zhao <jung.zhao@rock-chips.com>

ARM64: dts: rockchip: rk3399: invert the pwm polarity

invert the pwm polarity for new pwm interface

Change-Id: I8dfde14fbc4fd4aa907722f260ce72fdb4d7d3bb
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

video: backlight: pwm_bl: Fix the bug of Splashing screen when boot

The pwm_apply_args() should be removed when switching to the atomic
PWM API. Oherwise, the screen would splashing as the backlight is
disabled once when boot.

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

pwm: rockchip: State of pwm clock should synchronize with pwm enabled state

If the pwm was not enabled at uboot loader, pwm could not work for clock
always disabled at pwm driver. The pwm clock is enabled at beginning of
pwm_apply(), but disabled at end of pwm_apply().

If the pwm was enabled at uboot loader, pwm clock is always enabled unless
closed by ATF. The pwm-backlight might turn off the power at early suspend,
should disable pwm clock for saving power consume.

It is important to provide opportunity to enable/disable clock at pwm driver,
the pwm consumer should ensure correct order to call pwm enable/disable, and
pwm driver ensure state of pwm clock synchronized with pwm enabled state.

Change-Id: I545db81eb638957567abacb93fd06fff9dd7181b
Fixes: 2bf1c98aa5a4 ("pwm: rockchip: Add support for atomic update")
Signed-off-by: David Wu <david.wu@rock-chips.com>

UPSTREAM: pwm: cros-ec: Add __packed to prevent padding

While the particular usage in question is likely safe (struct
cros_ec_command is 32-bit aligned, followed by <= 32-bit fields), it's
been suggested this is not a great pattern to follow for the general
case -- for example, if we follow a 'struct cros_ec_command' (which is
32-bit- but not 64-bit-aligned) with a struct that starts with a 64-bit
type (e.g., u64), the compiler may add padding.

Let's add __packed, to inform the compiler of our true intention -- to
have no padding between these struct elements -- and to future proof for
any refactorings that might occur.

Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 065cfbbb638cce3d388020c4b97813b4a904a7c3)

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

UPSTREAM: pwm: Add ChromeOS EC PWM driver

Use the new ChromeOS EC EC_CMD_PWM_{GET,SET}_DUTY commands to control
one or more PWMs attached to the Embedded Controller. Because the EC
allows us to modify the duty cycle (as a percentage, where U16_MAX is
100%) but not the period, we assign the period a fixed value of
EC_PWM_MAX_DUTY and reject all attempts to change it.

This driver supports only device tree at the moment, because that
provides a very flexible way of describing the relationship between PWMs
and their consumer devices (e.g., backlight). On a non-DT system, we'll
probably want to use the non-GENERIC addressing (i.e., we'll need to
make special device instances that will use EC_PWM_TYPE_KB_LIGHT or
EC_PWM_TYPE_DISPLAY_LIGHT), as well as the relatively inflexible
pwm_lookup infrastructure for matching devices. Defer that work for now.

Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 1f0d3bb02785f698dc273b9006a473194c32f874)

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

UPSTREAM: dt-bindings: pwm: Add binding for ChromeOS EC PWM

The ChromeOS Embedded Controller can support controlling its attached
PWMs via its host-command interface. The number of supported PWMs varies
on a per-board basis, but we can autodetect this by checking the error
codes, so we don't need an extra property for this. And because the EC
only allows specifying the duty cycle and not the period, we don't
specify the period via pwm-cells, and instead have only support for one
cell -- to specify the index.

Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 9e60f50b4a79ae2df791d89d08cf2b78ad7629bd)

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

UPSTREAM: regulator: pwm: Document pwm-dutycycle-unit and pwm-dutycycle-range

Document the pwm-dutycycle-unit and pwm-dutycycle-range properties.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 58fd822b2e344edae6b4dbc09b19bd0c4a2f8f60)

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

UPSTREAM: regulator: pwm: Support extra continuous mode cases

The continuous mode allows one to declare a PWM regulator without having
to declare the voltage <-> dutycycle association table. It works fine as
long as your voltage(dutycycle) function is linear, but also has the
following constraints:

- dutycycle for min_uV = 0%
- dutycycle for max_uV = 100%
- dutycycle for min_uV < dutycycle for max_uV

While the linearity constraint is acceptable for now, we sometimes need to
restrict of the PWM range (to limit the maximum/minimum voltage for
example) or have a min_uV_dutycycle > max_uV_dutycycle (this could be
tweaked with PWM polarity, but not all PWMs support inverted polarity).

Add the pwm-dutycycle-range and pwm-dutycycle-unit DT properties to define
such constraints. If those properties are not defined, the PWM regulator
use the default pwm-dutycycle-range = <0 100> and
pwm-dutycycle-unit = <100> values (existing behavior).

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit ea398e28739e25651ede7ddf5aeb57cbcbc8ca7d)

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

UPSTREAM: pwm: rockchip: Add support for atomic update

Implement the ->apply() function to add support for atomic update.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(commit 2bf1c98aa5a41651f5e6455117ff06f66ff3cc50)

Conflicts:
drivers/pwm/pwm-rockchip.c

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

UPSTREAM: pwm: rockchip: Avoid glitches on already running PWMs

The current logic will disable the PWM clk even if the PWM was left
enabled by the bootloader (because it's controlling a critical device
like a regulator for example).
Keep the PWM clk enabled if the PWM is enabled to avoid any glitches.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(commit 48cf973cae33488f84d7ab79a0f613383cff4de4)

Conflicts:
drivers/pwm/pwm-rockchip.c

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

UPSTREAM: pwm: rockchip: Add support for hardware readout

Implement the ->get_state() function to expose initial state.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 1ebb74cf3537135f157beddf1a4366070155edda)

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

UPSTREAM: pwm: rockchip: Fix period and duty cycle approximation

The current implementation always round down the duty and period values,
while it would be better to round them to the closest integer.

These changes are needed in preparation of atomic update support to
prevent a period/duty cycle drift when executing several times the
'pwm_get_state() / modify / pwm_apply_state()' sequence.

Say you have an expected period of 3.333 us and a clk rate of
112.666667 MHz -- the clock frequency doesn't divide evenly, so the
period (stashed in nanoseconds) shrinks when we convert to the register
value and back, as follows:

  pwm_apply_state(): register = period * 112666667 / 1000000000;
  pwm_get_state(): period = register * 1000000000 / 112666667;

or in other words:

  period = period * 112666667 / 1000000000 * 1000000000 / 112666667;

which yields a sequence like:

  3333 -> 3328
  3328 -> 3319
  3319 -> 3310
  3310 -> 3301
  3301 -> 3292
  3292 -> ... (etc) ...

With this patch, we'd see instead:

  period = div_round_closest(period * 112666667, 1000000000) *
                   1000000000 / 112666667;

which yields a stable sequence:

  3333 -> 3337
  3337 -> 3337
  3337 -> ... (etc) ...

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 12f9ce4a519845070d338253ab9528b5d7e2df34)

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

UPSTREAM: regulator: pwm: Retrieve correct voltage

The continuous PWM voltage regulator is caching the voltage value in
the ->volt_uV field. While most of the time this value should reflect the
real voltage, sometime it can be sightly different if the PWM device
rounded the set_duty_cycle request.
Moreover, this value is not valid until someone has modified the regulator
output.

Remove the ->volt_uV field and always rely on the PWM state to calculate
the regulator output.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit d9070fdbe40a04b61262bac0f7ff0c7c29a68015)

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

UPSTREAM: regulator: pwm: Properly initialize the ->state field

The ->state field is currently initialized to 0, thus referencing the
voltage selector at index 0, which might not reflect the current
voltage value.
If possible, retrieve the current voltage selector from the PWM state,
else return -EINVAL.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 87248991a1de28e73dc30057e82d831bc11cdd44)

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

UPSTREAM: regulator: pwm: Switch to the atomic PWM API

Use the atomic API wherever appropriate and get rid of pwm_apply_args()
call (the reference period and polarity are now explicitly set when
calling pwm_apply_state()).

We also make use of the pwm_set_relative_duty_cycle() helper to ease
relative to absolute duty_cycle conversion.

Note that changes introduced by commit fd786fb0276a ("regulator: pwm:
Try to avoid voltage error in duty cycle calculation") are no longer
needed because pwm_set_relative_duty_cycle() takes care of all rounding
approximation for us.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 3f4eb39be9b1402ea01a5c67441d0b0bcb74b4b2)

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

UPSTREAM: regulator: pwm: Adjust PWM config at probe time

The PWM attached to a PWM regulator device might have been previously
configured by the bootloader.
Make sure the bootloader and linux config are in sync, and adjust the PWM
config if that's not the case.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit fd4f99c4c3ce8ccd9b8ea751afc614a7624ecef2)

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

UPSTREAM: pwm: Remove gratuitous blank line

Commit 5ec803edcb70 ("pwm: Add core infrastructure to allow atomic
updates") introduced this double blank line by mistake.

Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 2b77487f2e8ff7e6496a7f5a08839de9bbb39ab3)

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

UPSTREAM: pwm: Add relative duty cycle manipulation helpers

The PWM framework expects PWM users to configure the duty cycle in nano-
seconds, but many users want to express the duty cycle relatively to the
period value (i.e. duty_cycle = 33% of the period).

Add the pwm_{get,set}_relative_duty_cycle() helpers to ease this kind of
conversion.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit f6f3bddf7b2b994a927808fcc5a3d07069c35956)

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

UPSTREAM: pwm: Add a helper to prepare a new PWM state

The pwm_init_state() helper prepares a new state object containing the
current PWM state except for the polarity and period fields which are
set to the reference values (those in struct pwm_args).

This is particularly useful for PWM users who want to apply a new duty-
cycle expressed relatively to the reference period without changing the
enable state.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit a6a0dbbcfa469cf3e5c4d9522106c0b7b9e9e373)

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

UPSTREAM: regulator: pwm: Fix regulator ramp delay for continuous mode

The original commit adding support for continuous voltage mode didn't
handle the regulator ramp delay properly.  It treated the delay as a
fixed delay in uS despite the property being defined as uV / uS.  Let's
adjust it.  Luckily there appear to be no users of this ramp delay for
PWM regulators (as per grepping through device trees in linuxnext).

Note also that the upper bound of usleep_range probably shouldn't be a
full 1 ms longer than the lower bound since I've seen plenty of hardware
with a ramp rate of ~5000 uS / uV and for small jumps the total delays
are in the tens of uS.  1000 is way too much.  We'll try to be dynamic
and use 10%.

NOTE: This commit doesn't add support for regulator-enable-ramp-delay.
That could be done in a future patch when someone has a user of that
featre.

Though this patch is shows as "fixing" a bug, there are no actual known
users of continuous mode PWM regulator w/ ramp delay in mainline and so
this likely won't have any effect on anyone unless they are working
out-of-tree with private patches.  For anyone in this state, it is
highly encouraged to also pick Boris Brezillon's WIP patches to get
yourself a reliable and glitch-free regulator.

Fixes: 4773be185a0f ("regulator: pwm-regulator: Add support for continuous-voltage")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit c2588393e6315ab68207323d37d2a73713d6bc81)

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

UPSTREAM: pwm: Fix pwm_apply_args()

Commit 5ec803edcb70 ("pwm: Add core infrastructure to allow atomic
updates"), implemented pwm_disable() as a wrapper around
pwm_apply_state(), and then, commit ef2bf4997f7d ("pwm: Improve args
checking in pwm_apply_state()") added missing checks on the ->period
value in pwm_apply_state() to ensure we were not passing inappropriate
values to the ->config() or ->apply() methods.

The conjunction of these 2 commits led to a case where pwm_disable()
was no longer succeeding, thus preventing the polarity setting done
in pwm_apply_args().

Set a valid period in pwm_apply_args() to ensure polarity setting
won't be rejected.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Suggested-by: Brian Norris <briannorris@chromium.org>
Fixes: 5ec803edcb70 ("pwm: Add core infrastructure to allow atomic updates")
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 33cdcee04be3b4482be97393167e7561b2584e1e)

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

UPSTREAM: regulator: pwm: Support for enable GPIO

Add an optional enable GPIO to the pwm-regulator driver.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 27bfa8893b15a3fa22a593c90a48c8bcb1f9c75b)

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

UPSTREAM: pwm: sysfs: Add PWM capture support

Allow a user to read PWM capture results from sysfs. To start a capture
and read the result, simply read the file:

  $ cat $PWMCHIP/capture

The output format is "<period> <duty cycle>".

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 1a366fe9153f445e950a7a344932b7419aa83094)

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

UPSTREAM: pwm: Add PWM capture support

Supply a PWM capture callback op in order to pass back information
obtained by running analysis on a PWM signal. This would normally (at
least during testing) be called from the sysfs routines with a view to
printing out PWM capture data which has been encoded into a string.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
[thierry.reding@gmail.com: make capture data unsigned int for symmetry]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 3a3d1a4e32ab47323d7b8c8b7631a8d36a3098b2)

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

UPSTREAM: pwm: sysfs: Get return value from pwm_apply_state()

This patch adds to check the return value from pwm_apply_state()
used in enable_store(). The error of enable_store() doesn't work
if the return value doesn't received.

Signed-off-by: Ryo Kodama <ryo.kodama.vz@renesas.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Fixes: 39100ceea79f ("pwm: Switch to the atomic API")
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit fe5aa34d6eb9c4d34071845f70f3714b41c8a77d)

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

UPSTREAM: pwm: Improve args checking in pwm_apply_state()

It seems like in the process of refactoring pwm_config() to utilize the
newly-introduced pwm_apply_state() API, some args/bounds checking was
dropped.

In particular, I noted that we are now allowing invalid period
selections, e.g.:

  # echo 1 > /sys/class/pwm/pwmchip0/export
  # cat /sys/class/pwm/pwmchip0/pwm1/period
  100
  # echo 101 > /sys/class/pwm/pwmchip0/pwm1/duty_cycle
  [... driver may or may not reject the value, or trigger some logic bug ...]

It's better to see:

  # echo 1 > /sys/class/pwm/pwmchip0/export
  # cat /sys/class/pwm/pwmchip0/pwm1/period
  100
  # echo 101 > /sys/class/pwm/pwmchip0/pwm1/duty_cycle
  -bash: echo: write error: Invalid argument

This patch reintroduces some bounds checks in both pwm_config() (for its
signed parameters; we don't want to convert negative values into large
unsigned values) and in pwm_apply_state() (which fix the above described
behavior, as well as other potential API misuses).

Fixes: 5ec803edcb70 ("pwm: Add core infrastructure to allow atomic updates")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit ef2bf4997f7da6efa8540d9cf726c44bf2b863af)

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

UPSTREAM: regulator: pwm: Drop unneeded pwm_enable() call

Now that the PWM regulator driver implements the ->enable/disable() hooks
we can remove the pwm_enable() call from pwm_regulator_set_voltage().

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 830583004e615a4637eacc77866b84908414d7a0)

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

UPSTREAM: pwm: Add information about polarity, duty cycle and period to debugfs

The PWM states make it possible to also output the polarity, duty cycle
and period information in the debugfs summary output. This simplifies
gathering information about PWMs without needing to walk through the
sysfs attributes of every PWM.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
[thierry.reding@gmail.com: use more spaces in debugfs output]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 23e3523f5d3a980edf7f189743cf4bb9490400a9)

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

UPSTREAM: pwm: Switch to the atomic API

Replace legacy pwm_get/set_xxx() and pwm_config/enable/disable() calls
by pwm_get/apply_state().

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 39100ceea79ff2efeb2fb094baf120c73d5ccf47)

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

UPSTREAM: pwm: Update documentation

Update the PWM subsystem documentation to reflect the atomic PWM
changes.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit a07136fdcf12281781142caf1f78c6696721accd)

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

UPSTREAM: pwm: Add core infrastructure to allow atomic updates

Add an ->apply() method to the pwm_ops struct to allow PWM drivers to
implement atomic updates. This method is preferred over the ->enable(),
->disable() and ->config() methods if available.

Add the pwm_apply_state() function to the PWM user API.

Note that the pwm_apply_state() does not guarantee the atomicity of the
update operation, it all depends on the availability and implementation
of the ->apply() method.

pwm_enable/disable/set_polarity/config() are now implemented as wrappers
around the pwm_apply_state() function.

pwm_adjust_config() is allowing smooth handover between the bootloader
and the kernel. This function tries to adapt the current PWM state to
the PWM arguments coming from a PWM lookup table or a DT definition
without changing the duty_cycle/period proportion.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
[thierry.reding@gmail.com: fix a couple of typos]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 5ec803edcb703fe379836f13560b79dfac79b01d)

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

UPSTREAM: pwm: Add hardware readout infrastructure

Add a ->get_state() function to the pwm_ops struct to let PWM drivers
initialize the PWM state attached to a PWM device.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 15fa8a43c147213a9563903c87b29671035eb6e8)

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

UPSTREAM: pwm: Move the enabled/disabled info into pwm_state

Prepare the transition to PWM atomic update by moving the enabled and
disabled state into the pwm_state struct. This way we can easily update
the whole PWM state by copying the new state in the ->state field.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 09a7e4a3d9fcb95ade2cb02167e85fbeb8315ce0)

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

UPSTREAM: pwm: Introduce the pwm_state concept

The PWM state, represented by its period, duty_cycle and polarity is
currently directly stored in the PWM device. Declare a pwm_state
structure embedding those field so that we can later use this struct
to atomically update all the PWM parameters at once.

All pwm_get_xxx() helpers are now implemented as wrappers around
pwm_get_state().

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 43a276b003ed2e03de9d94b02a1ba49c1849b931)

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

UPSTREAM: pwm: Keep PWM state in sync with hardware state

Before the introduction of pwm_args, the core was resetting the PWM
period and polarity states to the reference values (those provided
through the DT, a PWM lookup table or hardcoded in the driver).

Now that all PWM users are correctly using pwm_args to configure their
PWM device, we can safely remove the pwm_apply_args() call in pwm_get()
and of_pwm_get().

We can also get rid of the pwm_set_period() call in pwm_apply_args(),
because PWM users are now directly using pargs->period instead of
pwm_get_period(). By doing that we avoid messing with the current PWM
period.

The only remaining bit in pwm_apply_args() is the initial polarity
setting, and it should go away when all PWM users have been patched to
use the atomic API (with this API the polarity will be set along with
other PWM arguments when configuring the PWM).

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit a8c3862551e063344f80c3e05d595f9d8836f355)

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

UPSTREAM: backlight: pwm_bl: Use pwm_get_args() where appropriate

The PWM framework has clarified the concept of reference PWM config (the
platform dependent config retrieved from the DT or the PWM lookup table)
and real PWM state.

Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.

This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has just
been requested (before the user calls pwm_config/enable/disable()).

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 6cb9644db7364ff5d2980ccd365b8cb684145327)

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

UPSTREAM: regulator: pwm: Use pwm_get_args() where appropriate

The PWM framework has clarified the concept of reference PWM config (the
platform dependent config retrieved from the DT or the PWM lookup table)
and real PWM state.

Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.

This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has just
been requested (before the user calls pwm_config/enable/disable()).

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from 8c12ad8e916ee0477f7a0a0f00b0a87b9a21ebf7)

Conflicts:
drivers/regulator/pwm-regulator.c

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

UPSTREAM: pwm: Get rid of pwm->lock

PWM devices are not protected against concurrent accesses. The lock in
struct pwm_device might let PWM users think it is, but it's actually
only protecting the enabled state.

Removing this lock should be fine as long as all PWM users are aware
that accesses to the PWM device have to be serialized, which seems to be
the case for all of them except the sysfs interface. Patch the sysfs
code by adding a lock to the pwm_export struct and making sure it's
taken for all relevant accesses to the exported PWM device.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 459a25afe97cb3d7f978b90c881f4d7aac8fb755)

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

UPSTREAM: backlight: pwm_bl: Remove useless call to pwm_set_period()

The PWM period will be set when calling pwm_config. Remove this useless
call to pwm_set_period(), which might mess up the internal PWM state.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 7f044b09b68d36811518c55f736a20648e8ed6e2)

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

UPSTREAM: pwm: Fix pwm_apply_args() call sites

pwm_apply_args() is supposed to initialize a PWM device according to the
arguments provided by the DT or the PWM lookup, but this function was
called inside pwm_device_request(), which in turn was called before the
core had a chance to initialize the pwm->args fields.

Fix that by calling pwm_apply_args directly in pwm_get() and of_pwm_get()
after initializing pwm->args field.

This commit also fixes an invalid pointer dereference introduced by
commit e39c0df1be5a ("pwm: Introduce the pwm_args concept").

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: e39c0df1be5a ("pwm: Introduce the pwm_args concept")
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit fbd45a12988e75a48d392feb8b0e5feb5d612513)

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

UPSTREAM: video / backlight: remove the backlight_device_registered API

Since we will need the backlight_device_get_by_type API, we can use it
instead of the backlight_device_registered API whenever necessary so
remove the backlight_device_registered API.

Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 01c3664de62f89f6777e59173ad8e20b5a4c267f)

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

UPSTREAM: video / backlight: add two APIs for drivers to use

It is useful to get the backlight device's pointer and use it to set
backlight in some cases(the following patch will make use of it) so add
the two APIs and export them.

Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit f6a4790a5471d7cba406d87f6b41323f40bb93d2)

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

UPSTREAM: backlight: pwm_bl: Free PWM requested by legacy API on error path

If pwm is requested by legacy pwm_request() and if the following
backlight_device_register() call fails, add pwm_free() clean-up.

Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
(cherry picked from commit 60d613d6aef4ae49988eeb3ad38af948c561db1e)

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

UPSTREAM: backlight: pwm_bl: Fix broken PWM backlight for non-dt platforms

Commit ee65ad0e2a9e ("backlight: pwm_bl: Avoid backlight flicker when
probed from DT") tries to dereference the device of_node pointer
unconditionally, causing a NULL pointer dereference on non-dt platforms.
Fix it by replacing the phandle variable with a node variable and
by checking that for NULL before dereferencing it.

Reported-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
(cherry picked from commit 8777078015bb77f0561303b6dea23d40bd9f3053)

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

UPSTREAM: backlight: pwm_bl: Avoid backlight flicker when probed from DT

If the driver is probed from the device tree, and there is a phandle
property set on it, and the enable GPIO is already configured as output,
and the backlight is currently disabled, keep it disabled.
If all these conditions are met, assume there will be some other driver
that can enable the backlight at the appropriate time.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
(cherry picked from commit 3698d7e7d221a5c90d4b55e96d0c8f98a8b4d7df)

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

UPSTREAM: pwm: Use kcalloc() instead of kzalloc()

kcalloc() should be preferred for allocations of arrays over kzalloc()
with multiplication.

Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 2907f8abb7ec3aec85ceaaf03dfbc16cca0018dc)

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

UPSTREAM: pwm: Add missing newline

checkpatch requires that declarations be separated from code by a blank
line. Add one for readability and to silence the warning.

Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 83a98864ff62b23dfa93baeaaf340741e263c02b)

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

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>