RK3288 SoC VOPs have optional support Gamma LUT setting,
which requires specifying the Gamma LUT address in the devicetree.
Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20191010194351.17940-4-ezequiel@collabora.comSigned-off-by: NHeiko Stuebner <heiko@sntech.de>

This just adds in another field of what's stored in the e-fuse on
rk3288.  Though I can't personally promise that every rk3288 out there
has the CPU ID stored in the eFuse at this location, there is some
evidence that it is correct:
- This matches what was in the Chrome OS 3.14 branch (see
  EFUSE_CHIP_UID_OFFSET and EFUSE_CHIP_UID_LEN) for rk3288.
- The upstream rk3399 dts file has this same data at the same offset
  and with the same length, indiciating that this is likely common for
  several modern Rockchip SoCs.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20190919142611.1.I309434f00a2a9be71e4437991fe08abc12f06e2e@changeidSigned-off-by: NHeiko Stuebner <heiko@sntech.de>

This adds the "unwedge" pinctrl entries introduced by a recent dw_hdmi
change that can unwedge the dw_hdmi i2c bus in some cases.  It's
expected that any boards using this would add:

  pinctrl-names = "default", "unwedge";
  pinctrl-0 = <&hdmi_ddc>;
  pinctrl-1 = <&hdmi_ddc_unwedge>;

Note that this isn't added by default because some boards may choose
to mux i2c5 for their DDC bus (if that is more tested for them).
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NSean Paul <sean@poorly.run>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

This is the same as the other PWMs on this SoC and uses 3 cells.
Signed-off-by: NJohn Keeping <john@metanate.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

The NPLL is the only safe way to generate 500 MHz for the GPU. The
downstream Chrome OS 3.14 kernel ('official' kernel for veyron
devices) re-purposes NPLL to HDMI and hence disables the OPP for
the GPU (see https://crrev.com/c/1574579). Disable it here as well
to keep in sync and avoid problems in case someone decides to
re-purpose NPLL.
Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
[moved from veyron to general rk3288, as tying up the NPLL for a
 not-that-helpful opp (not really fast but will still generate
 quite a bit of heat) doesn't make so much sense when it will
 keep us from supporting other display modes  in the future]
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Currently the CPUs are used as cooling devices of the rk3288 GPU
thermal zone. The CPUs are also configured as cooling devices in the
CPU thermal zone, which indirectly helps with cooling the GPU thermal
zone, since the CPU and GPU temperatures are correlated on the rk3288.

Configure the ARM Mali Midgard GPU as cooling device for the GPU
thermal zone instead of the CPUs.
Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

The Mali GPU of the rk3288 can be used as cooling device, add
a #cooling-cells entry for it.
Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

This is similar to commit e6186820 ("arm64: dts: rockchip: Arch
counter doesn't tick in system suspend").  Specifically on the rk3288
it can be seen that the timer stops ticking in suspend if we end up
running through the "osc_disable" path in rk3288_slp_mode_set().  In
that path the 24 MHz clock will turn off and the timer stops.

To test this, I ran this on a Chrome OS filesystem:
  before=$(date); \
  suspend_stress_test -c1 --suspend_min=30 --suspend_max=31; \
  echo ${before}; date

...and I found that unless I plug in a device that requests USB wakeup
to be active that the two calls to "date" would show that fewer than
30 seconds passed.

NOTE: deep suspend (where the 24 MHz clock gets disabled) isn't
supported yet on upstream Linux so this was tested on a downstream
kernel.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

We use the new PWM IP on RK3288, but the PWM's clock indeed incorrect.
Signed-off-by: NCaesar Wang <caesar.wang@rock-chips.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

The "host" USB port on rk3288 has a hardware errata where we've got to
assert a PHY reset whenever we see a remote wakeup.  Add that quirk
property to the device tree.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Let's hook up the resets to the three USB PHYs on rk3288 as per the
bindings.  This is in preparation for a future patch that will set the
"snps,reset-phy-on-wake" on the host port.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The value was determined with the following method:

- take CPUs 1-3 offline
- for each OPP
  - set cpufreq min and max freq to OPP freq
  - start dhrystone benchmark
  - measure CPU power consumption during 10s
  - calculate Cx for OPPx
    - Cx = (Px - P1) / (Vx²fx - V1²f1)          [1]
      using the following units: mW / Ghz / V   [2]
- C = avg(C2, ..., Cn)

[1] see commit 4daa001a ("arm64: dts: juno: Add cpu
     dynamic-power-coefficient information")
[2] https://patchwork.kernel.org/patch/10493615/#22158551

FTR, these are the values for the different OPPs:

freq (kHz)   	mV		Px (mW)		Cx

126000		900		39
216000		900		66		370
312000		900		95		372
408000		900		122		363
600000		900		177		359
696000		950		230		363
816000		1000		297		361
1008000		1050		404		362
1200000		1100		528		362
1416000		1200		770		377
1512000		1300		984		385
1608000		1350		1156		394
Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Rockchip SoCs use 2 different numbering schemes. Where the gpio-
controllers just count 0-31 for their 32 gpios, the underlying
iomux controller splits these into 4 separate entities A-D.

Device-schematics always use these iomux-values to identify pins,
so to make mapping schematics to devicetree easier Andy Yan introduced
named constants for the pins but so far we only used them on new
additions.

Using a sed-script created by Emil Renner Berthing bulk-convert
the remaining raw gpio numbers into their descriptive counterparts
and also gets rid of the unhelpful RK_FUNC_x -> x and RK_GPIOx -> x
mappings:

/rockchip,pins *=/bcheck
b # to end of script
:append-next-line
N
:check
/^[^;]*$/bappend-next-line
s/<RK_GPIO\([0-9]\) /<\1 /g
s/<\([^ ][^ ]*  *\)0 /<\1RK_PA0 /g
s/<\([^ ][^ ]*  *\)1 /<\1RK_PA1 /g
s/<\([^ ][^ ]*  *\)2 /<\1RK_PA2 /g
s/<\([^ ][^ ]*  *\)3 /<\1RK_PA3 /g
s/<\([^ ][^ ]*  *\)4 /<\1RK_PA4 /g
s/<\([^ ][^ ]*  *\)5 /<\1RK_PA5 /g
s/<\([^ ][^ ]*  *\)6 /<\1RK_PA6 /g
s/<\([^ ][^ ]*  *\)7 /<\1RK_PA7 /g
s/<\([^ ][^ ]*  *\)8 /<\1RK_PB0 /g
s/<\([^ ][^ ]*  *\)9 /<\1RK_PB1 /g
s/<\([^ ][^ ]*  *\)10 /<\1RK_PB2 /g
s/<\([^ ][^ ]*  *\)11 /<\1RK_PB3 /g
s/<\([^ ][^ ]*  *\)12 /<\1RK_PB4 /g
s/<\([^ ][^ ]*  *\)13 /<\1RK_PB5 /g
s/<\([^ ][^ ]*  *\)14 /<\1RK_PB6 /g
s/<\([^ ][^ ]*  *\)15 /<\1RK_PB7 /g
s/<\([^ ][^ ]*  *\)16 /<\1RK_PC0 /g
s/<\([^ ][^ ]*  *\)17 /<\1RK_PC1 /g
s/<\([^ ][^ ]*  *\)18 /<\1RK_PC2 /g
s/<\([^ ][^ ]*  *\)19 /<\1RK_PC3 /g
s/<\([^ ][^ ]*  *\)20 /<\1RK_PC4 /g
s/<\([^ ][^ ]*  *\)21 /<\1RK_PC5 /g
s/<\([^ ][^ ]*  *\)22 /<\1RK_PC6 /g
s/<\([^ ][^ ]*  *\)23 /<\1RK_PC7 /g
s/<\([^ ][^ ]*  *\)24 /<\1RK_PD0 /g
s/<\([^ ][^ ]*  *\)25 /<\1RK_PD1 /g
s/<\([^ ][^ ]*  *\)26 /<\1RK_PD2 /g
s/<\([^ ][^ ]*  *\)27 /<\1RK_PD3 /g
s/<\([^ ][^ ]*  *\)28 /<\1RK_PD4 /g
s/<\([^ ][^ ]*  *\)29 /<\1RK_PD5 /g
s/<\([^ ][^ ]*  *\)30 /<\1RK_PD6 /g
s/<\([^ ][^ ]*  *\)31 /<\1RK_PD7 /g
s/<\([^ ][^ ]*  *[^ ][^ ]*  *\)0 /<\1RK_FUNC_GPIO /g
s/<\([^ ][^ ]*  *[^ ][^ ]*  *\)RK_FUNC_\([1-9]\) /<\1\2 /g
Suggested-by: NEmil Renner Berthing <esmil@mailme.dk>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

They are pointless.  As dtc points out:
  Warning (avoid_unnecessary_addr_size):
  /mipi@ff960000:
  unnecessary #address-cells/#size-cells without "ranges" or child "reg" property

Let's remove them.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

The device tree compiler yells like this:
  Warning (unit_address_vs_reg):
  /gpu-opp-table/opp@100000000:
  node has a unit name, but no reg property

Let's match the cpu opp node names and use a dash.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

It can be seen that 0xffb40000 < 0xffc01000, thus efuse comes first.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

The following message can be seen during boot:

  rockchip-thermal ff280000.tsadc: Missing rockchip,grf property

Fix this by adding rockchip,grf property to tsadc node.

The warning itself is not relevant on rk3288 right now, as the
tsadc doesn't need to set GRF-values at this point and only newer
variants do.
Signed-off-by: NJonas Karlman <jonas@kwiboo.se>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

The following error can be seen during boot:

  of: /cpus/cpu@501: Couldn't find opp node

Change cpu nodes to use operating-points-v2 in order to fix this.

Fixes: ce76de98 ("ARM: dts: rockchip: convert rk3288 to operating-points-v2")
Cc: stable@vger.kernel.org
Signed-off-by: NJonas Karlman <jonas@kwiboo.se>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Add the Video Processing Unit node for RK3288 SoC.

Fix the VPU IOMMU node, which was disabled and lacking
its power domain property.
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Each CPU can (and does) participate in cooling down the system but the
DT only captures a handful of them, normally CPU0, in the cooling maps.
Things work by chance currently as under normal circumstances its the
first CPU of each cluster which is used by the operating systems to
probe the cooling devices. But as soon as this CPU ordering changes and
any other CPU is used to bring up the cooling device, we will start
seeing failures.

Also the DT is rather incomplete when we list only one CPU in the
cooling maps, as the hardware doesn't have any such limitations.

Update cooling maps to include all devices affected by individual trip
points.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.

Add such missing properties.

Fix other missing properties (clocks, OPP, clock latency) as well to
make it all work.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
[follow conversion to operating-points-v2]
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Operating points need to be present in each cpu core using it, not only
the first one. With operating-points-v1 this would require duplicating
this table into each cpu node.

With opp-v2 we can share the same table on all nodes.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>

Update all 32bit rockchip devicetree files to use SPDX-License-Identifiers.

All files except rk3288-veyron-analog-audio.dtsi (which is GPL 2.0 only)
claim to be GPL and X11 while the actual license text is MIT. Use the
MIT SPDX tag for them.
Signed-off-by: NKlaus Goger <klaus.goger@theobroma-systems.com>
Acked-by: NBrian Norris <briannorris@chromium.org>
Acked-by: NMatthias Brugger <mbrugger@suse.com>
Acked-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Add clocks in iommu nodes, since we are going to control clocks in
rockchip iommu driver.
Signed-off-by: NJeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

According to TRM, uart4 tx/rx should be 14/15
Signed-off-by: NJacob Chen <jacob-chen@iotwrt.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

dtc now gives the following warning:

arch/arm/boot/dts/rk3288-tinker.dtb: Warning (sound_dai_property): /sound/simple-audio-card,codec: Missing property '#sound-dai-cells' in node /hdmi@ff980000 or bad phandle (referred from sound-dai[0])

Add the missing #sound-dai-cells property.

Cc: Heiko Stuebner <heiko@sntech.de>
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: NRob Herring <robh@kernel.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

The interrupts property in the iep-IOMMU node for the rk3288 dts file has a
spurious extra cell causing a dtc warning:

Warning (interrupts_property): interrupts size is (16), expected multiple of 12 in /iommu@ff900800

Remove the extra cell.
Signed-off-by: NRob Herring <robh@kernel.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

The CEC line can be routed to two possible pins. Define those pins.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

The dw-hdmi block needs the cec clk for the rk3288. Add it.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

This patch add the RGA dt config of rk3288 SoC.
Signed-off-by: NJacob Chen <jacob-chen@iotwrt.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Add LVDS info in rk3288.dtsi for LVDS driver
Signed-off-by: NSandy Huang <hjc@rock-chips.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Add IEP/ISP/VPU/HEVC iommu nodes
Signed-off-by: NSimon Xue <xxm@rock-chips.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

In order to be able to use more than 4GB of RAM when the LPAE is
activated, the dts must be converted in 64 bits.
Signed-off-by: NTao Huang <huangtao@rock-chips.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

The binding specifies the actual implementations only (mali-t760
for example) but not the arm,mali-midgard used in some vendor kernels.
So drop that compatible property from the rk3288 where it had slipped in.

Also fix the node name which should be a generic gpu@...
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Add Mali GPU device tree node for the rk3288 SoC, with devfreq
opp table.
Signed-off-by: NGuillaume Tucker <guillaume.tucker@collabora.com>
Tested-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

dw-mmc got its reset-properties specified, so add the softresets
for it in rk3288.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Reviwed-by: NShawn Lin <shawn.lin@rock-chips.com>

Since everybody copied my own mistake from the DT binding example,
let's address all the offenders in one swift go.

Most of them got the CPU interface size wrong (4kB, while it should
be 8kB), except for both keystone platforms which got the control
interface wrong (4kB instead of 8kB).

In a few cases where I knew for sure what implementation was used,
I've added the "arm,gic-400" compatible string. I'm 99% sure that
this is what everyone is using, but short of having the TRM for
all the other SoCs, I've left them alone.
Acked-by: NShawn Guo <shawnguo@kernel.org>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Acked-by: NKrzysztof Kozlowski <krzk@kernel.org>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NAntoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NMatthias Brugger <matthias.bgg@gmail.com>
Acked-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

when pd power on/off, the qos regs need to save and restore.
Signed-off-by: NElaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

This is not needed as the gadget now fully supports DMA and it can
autodetect it. This was initially added because gadget DMA mode was only
partially implemented so could not be automatically enabled.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

In drivers/mmc/core/host.c, there is "max-frequency" property.
It should be same behavior. So use the "max-frequency" instead of
"clock-freq-min-max".
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>