Describe the dynamic power coefficient of A53 CPUs.

Based on work by Gaku Inami <gaku.inami.xw@bp.renesas.com> and others.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Setup a thermal zone driven by SoC temperature sensor.
Create passive trip points and bind them to CPUFreq cooling
device that supports power extension.

In R-Car Gen3, IPA is supported for only one channel
Reason:
  Currently, IPA controls base on only CPU temperature.
  And only one thermal channel is assembled closest
  CPU cores is selected as target of IPA.
  If other channels are used, IPA controlling is not properly.

A single cooling device is described for all A53 CPUs as this
reflects that physically there is only one cooling device present.

This patch improves on an earlier version by:

* Omitting cooling-max-level and cooling-min-level properties which
  are no longer present in mainline as of v4.17
* Removing an unused trip-point0 node sub-property from the trips
  property.
* Defers adding dynamic-power-coefficient properties to a separate patch as
  these are properties of the CPU.

The long signed-off by chain below reflects many revisions, mainly
internal, that this patch has been through.
Signed-off-by: NDien Pham <dien.pham.ry@renesas.com>
Signed-off-by: NTakeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: NYoshihiro Kaneko <ykaneko0929@gmail.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Describe the dynamic power coefficient of A57 and A53 CPUs.

Based on work by Gaku Inami <gaku.inami.xw@bp.renesas.com> and others.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Setup a thermal zone driven by SoC temperature sensor.
Create passive trip points and bind them to CPUFreq cooling
device that supports power extension.

In R-Car Gen3, IPA is supported for only one channel
(on H3/M3/M3N SoCs, it is channel THS3). Reason:
  Currently, IPA controls base on only CPU temperature.
  And only one thermal channel is assembled closest
  CPU cores is selected as target of IPA.
  If other channels are used, IPA controlling is not properly.

The A57 cooling device supports 5 cooling states which can be categorised
as follows:

0 & 1) boost (clocking up)
2)     default
3 & 4) cooling (clocking down)

Currently the thermal framework assumes that the default is the minimum,
or in other words there is no provision for handling boost states.
So this patch only describes the upper 3 states, default and cooling.

A single cooling device is described for all A57 CPUs and a separate
cooling device is described for all A53 CPUs. This reflects that physically
there is only one cooling device present for each type of CPU.

This patch improves on an earlier version by:

* Omitting cooling-max-level and cooling-min-level properties which
  are no longer present in mainline as of v4.17
* Removing an unused trip-point0 node sub-property from the trips
  property.
* Using cooling-device indexes such that maximum refers to maximum cooling
  rather than the inverse.
* Defers adding dynamic-power-coefficient properties to a separate patch as
  these are properties of the CPU.

The long signed-off by chain below reflects many revisions, mainly
internal, that this patch has been through.
Signed-off-by: NDien Pham <dien.pham.ry@renesas.com>
Signed-off-by: NAn Huynh <an.huynh.uj@rvc.renesas.com>
Signed-off-by: NTakeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: NYoshihiro Kaneko <ykaneko0929@gmail.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Describe the dynamic power coefficient of A57 and A53 CPUs.

Based on work by Gaku Inami <gaku.inami.xw@bp.renesas.com> and others.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Setup a thermal zone driven by SoC temperature sensor.
Create passive trip points and bind them to CPUFreq cooling
device that supports power extension.

In R-Car Gen3, IPA is supported for only one channel
 (on H3/M3/M3N SoCs, it is channel THS3). Reason:
  Currently, IPA controls base on only CPU temperature.
  And only one thermal channel is assembled closest
  CPU cores is selected as target of IPA.
  If other channels are used, IPA controlling is not properly.

The A57 cooling device supports 5 cooling states which can be categorised
as follows:

0 & 1) boost (clocking up)
2)     default
3 & 4) cooling (clocking down)

Currently the thermal framework assumes that the default is the minimum,
or in other words there is no provision for handling boost states.
So this patch only describes the upper 3 states, default and cooling.

A single cooling device is described for all A57 CPUs and a separate
cooling device is described for all A53 CPUs. This reflects that physically
there is only one cooling device present for each type of CPU.

This patch improves on an earlier version by:

* Omitting cooling-max-level and cooling-min-level properties which
  are no longer present in mainline as of v4.17
* Removing an unused trip-point0 node sub-property from the trips
  property.
* Using cooling-device indexes such that maximum refers to maximum cooling
  rather than the inverse.
* Defers adding dynamic-power-coefficient properties to a separate patch as
  these are properties of the CPU.

The long signed-off by chain below reflects many revisions, mainly
internal, that this patch has been through.
Signed-off-by: NDien Pham <dien.pham.ry@renesas.com>
Signed-off-by: NHien Dang <hien.dang.eb@rvc.renesas.com>
Signed-off-by: NAn Huynh <an.huynh.uj@rvc.renesas.com>
Signed-off-by: NTakeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: NYoshihiro Kaneko <ykaneko0929@gmail.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Describe the dynamic power coefficient of A57 and A53 CPUs.

Based on work by Gaku Inami <gaku.inami.xw@bp.renesas.com> and others.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Setup a thermal zone driven by SoC temperature sensor.
Create passive trip points and bind them to CPUFreq cooling
device that supports power extension.

In R-Car Gen3, IPA is supported for only one channel
(on H3/M3/M3N SoCs, it is channel THS3). Reason:
  Currently, IPA controls base on only CPU temperature.
  And only one thermal channel is assembled closest
  CPU cores is selected as target of IPA.
  If other channels are used, IPA controlling is not properly.

The A5 cooling device supports 5 cooling states which can be categorised as
follows:

0 & 1) boost (clocking up)
2)     default
3 & 4) cooling (clocking down)

Currently the thermal framework assumes that the default is the minimum,
or in other words there is no provision for handling boost states.
So this patch only describes the upper 3 states, default and cooling.

A single cooling device is described for all A57 CPUs and a separate
cooling device is described for all A53 CPUs. This reflects that physically
there is only one cooling device present for each type of CPU.

This patch improves on an earlier version by:

* Omitting cooling-max-level and cooling-min-level properties which
  are no longer present in mainline as of v4.17
* Removing an unused trip-point0 node sub-property from the trips
  property.
* Using cooling-device indexes such that maximum refers to maximum cooling
  rather than the inverse.
* Defers adding dynamic-power-coefficient properties to a separate patch as
  these are properties of the CPU.

The long signed-off by chain below reflects many revisions, mainly
internal, that this patch has been through.
Signed-off-by: NDien Pham <dien.pham.ry@renesas.com>
Signed-off-by: NKeita Kobayashi <keita.kobayashi.ym@renesas.com>
Signed-off-by: NGaku Inami <gaku.inami.xw@bp.renesas.com>
Signed-off-by: NHien Dang <hien.dang.eb@rvc.renesas.com>
Signed-off-by: NAn Huynh <an.huynh.uj@rvc.renesas.com>
Signed-off-by: NTakeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: NYoshihiro Kaneko <ykaneko0929@gmail.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Since the commit 233da2c9 ("dt-bindings: phy: rcar-gen3-phy-usb2:
Revise #phy-cells property") revised the #phy-cells, this patch follows
the updated document for R-Car Gen3 and RZ/A2 SoCs.
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

It is incorrect to specify the no-ether-link property for the AVB device on
the Ebisu board. This is because the property should only be used when a
board does not provide a proper AVB_LINK signal. However, the Ebisu board
does provide this signal.

As per 87c059e9 ("arm64: dts: renesas: salvator-x: Remove renesas,
no-ether-link property") this fixes a bug:

    Steps to reproduce:
    - start AVB TX stream (Using aplay via MSE),
    - disconnect+reconnect the eth cable,
    - after a reconnection the eth connection goes iteratively up/down
      without user interaction,
    - this may heal after some seconds or even stay for minutes.

    As the documentation specifies, the "renesas,no-ether-link" option
    should be used when a board does not provide a proper AVB_LINK signal.
    There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
    and ULCB starter kits since the AVB_LINK is correctly handled by HW.

    Choosing to keep or remove the "renesas,no-ether-link" option will have
    impact on the code flow in the following ways:
    - keeping this option enabled may lead to unexpected behavior since the
      RX & TX are enabled/disabled directly from adjust_link function
      without any HW interrogation,
    - removing this option, the RX & TX will only be enabled/disabled after
      HW interrogation. The HW check is made through the LMON pin in PSR
      register which specifies AVB_LINK signal value (0 - at low level;
      1 - at high level).

    In conclusion, the present change is also a safety improvement because
    it removes the "renesas,no-ether-link" option leading to a proper way
    of detecting the link state based on HW interrogation and not on
    software heuristic.

Fixes: 8441ef64 ("arm64: dts: renesas: r8a77990: ebisu: Enable EthernetAVB")
Signed-off-by: NTakeshi Kihara <takeshi.kihara.df@renesas.com>
[simon: updated changelog]
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Apparently this DTS crossed over with commit 31af04cd ("arm64: dts:
Remove inconsistent use of 'arm,armv8' compatible string") and missed
out on the cleanup, so put it right.
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Convert bootargs from ip=dhcp to ip=on
Signed-off-by: NMagnus Damm <damm+renesas@opensource.se>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

This patch enables BT support for the CAT874 board.
Signed-off-by: NBiju Das <biju.das@bp.renesas.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

This patch enables WLAN support for the CAT874 board.
Signed-off-by: NBiju Das <biju.das@bp.renesas.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Add tpu device node to dtsi for TPU support on r8a7795 SoC.
Signed-off-by: NCao Van Dong <cv-dong@jinso.co.jp>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Add tpu device node to dtsi for TPU support on r8a77965 SoC.
Signed-off-by: NCao Van Dong <cv-dong@jinso.co.jp>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Add tpu device node to dtsi for TPU support on r8a7796 SoC.
Signed-off-by: NCao Van Dong <cv-dong@jinso.co.jp>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

This patch adds description of TI WL1837 and links interfaces
to communicate with the IC, namely the SDIO interface to WLAN.
Signed-off-by: NSpyridon Papageorgiou <spapageorgiou@de.adit-jv.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

The ports node of vin4 only has one sub-node and thus does
not need #address-cells/#size-cells and the sub-node does
not need an exit.

This addresses the following warning:

 # make dtbs W=1
 ...
 arch/arm64/boot/dts/renesas/r8a77995-draak.dts:492.8-503.4: Warning (graph_child_address): /soc/video@e6ef4000/ports: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary

Fixes: 6a0942c2 ("arm64: dts: renesas: draak: Describe CVBS input")
Cc: Jacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>

The CAT874 board pushes sound via I2S over SSI0 into the
TDA19988BET chip.
This commit wires things up so that we can get sound out of
the HDMI interface.
Signed-off-by: NFabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

The CAT874 board comes with a HDMI connector, managed by
a TDA19988BET chip, connected to the RZ/G2E SoC via DPAD.
This patch adds the necessary support to the board DT.
Signed-off-by: NFabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Add IPMMU-DS0 to the Ethernet-AVB device node.

Based on work by Magnus Damm for the r8a7795.
Signed-off-by: NBiju Das <biju.das@bp.renesas.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Hook up r8a774a1 Audio-DMAC nodes to the IPMMU-MP.

Based on work for the r8a7795 by Magnus Damm.
Signed-off-by: NBiju Das <biju.das@bp.renesas.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Hook up r8a774a1 DMAC nodes to the IPMMUs. In particular SYS-DMAC0
gets tied to IPMMU-DS0, and SYS-DMAC1 and SYS-DMAC2 get tied to IPMMU-DS1.

Based on work for the r8a7796 by Magnus Damm.
Signed-off-by: NBiju Das <biju.das@bp.renesas.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

The r8a774a1 has a single FDP1 instance similar to r8a7796.
Signed-off-by: NBiju Das <biju.das@bp.renesas.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Add the DU device to r8a774a1.dtsi in a disabled state.
Signed-off-by: NBiju Das <biju.das@bp.renesas.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

The r8a774a1 soc has 5 VSP instances similar to r8a7796.
Signed-off-by: NBiju Das <biju.das@bp.renesas.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

We've introduced power management logics for the Spreadtrum serial
controller by commit 062ec2774c8a ("serial: sprd: Add power management
for the Spreadtrum serial controller"), thus add related clock properties
to support this feature.
Signed-off-by: NBaolin Wang <baolin.wang@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The recently introduced XUSB support for Jetson TX2 is causing boot, CPU
hotplug and suspend/resume failures according to several reports.

Temporarily work around this by disabling the XUSB controller and XUSB
pad controller nodes in device tree, while we figure out what's causing
this.
Reported-by: NBitan Biswas <bbiswas@nvidia.com>
Reported-by: NJonathan Hunter <jonathanh@nvidia.com>
Tested-by: NBitan Biswas <bbiswas@nvidia.com>
Tested-by: NJon Hunter <jonathanh@nvidia.com>
Acked-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Commit 954a03be ("iommu/arm-smmu: Break insecure users by disabling
bypass by default") intentionally breaks all devices using the SMMU in
bypass mode. This breaks, among other things, PCI support on Tegra186.
Fix this by populating the iommus property and friends for the PCIe
controller.

Fixes: 954a03be ("iommu/arm-smmu: Break insecure users by disabling bypass by default")
Signed-off-by: NThierry Reding <treding@nvidia.com>

Commit 954a03be ("iommu/arm-smmu: Break insecure users by disabling
bypass by default") intentionally breaks all devices using the SMMU in
bypass mode. This is breaking various devices on Tegra186 which include
the ethernet, BPMP and HDA device. Fix this by populating the iommus
property for these devices with their stream ID.

Fixes: 954a03be ("iommu/arm-smmu: Break insecure users by disabling bypass by default")
Signed-off-by: NJonathan Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Add pinctrl support for UARTs exposed on the Sophon Edge board.
Signed-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>

Add pinctrl support for Bitmain BM1880 SoC. This SoC only supports
pinmuxing and the pinctrl registers are part of the sctrl block.
Signed-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>

Add GPIO line names for Sophon Edge board based on BM1880 SoC from
Bitmain. Line names are based on the board schematics as well as the
96Boards Consumer Edition specification v1.0.
Signed-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

Add GPIO support for Bitmain BM1880 SoC based on Designware APB GPIO
controller IP. IP exposes 3 GPIO controllers with a total of 72 pins.
Signed-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

The old "cooling-{min,max}-state" properties for thermal bindings were
ratified to "cooling-{min,max}-level" by commit eb168b70 ("of:
thermal: Fix inconsitency between cooling-*-state and cooling-*-level"),
which were later removed entirely by commit e04907db ("dt-bindings:
thermal: Remove "cooling-{min|max}-level" properties").

The pwm-fan binding, however, was apparently in-flight in parallel with
that ratification, and so managed to introduce an example of the old
properties which escaped the scope of the later cleanup and has thus
continued to be dutifully copied for new boards despite being useless.
Clean up these remaining undocumented anachronisms to minimise any
further confusion.
Acked-by: NGuenter Roeck <linux@roeck-us.net>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Acked-by: NThierry Reding <treding@nvidia.com>
Acked-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NShawn Guo <shawnguo@kernel.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The thermal core restricts names of thermal zones to under 20
characters. Fix the names for a couple of msm8998 thermal zones.
Signed-off-by: NAmit Kucheria <amit.kucheria@linaro.org>
Tested-by: NMarc Gonzalez <marc.w.gonzalez@free.fr>
Signed-off-by: NAndy Gross <agross@kernel.org>

msm8998 has 22 sensors connected in total, 14 on the 1st controller, 8
on the 2nd controller. Increase the number to allow sensors with ID 12
and 13 to be registered.
Signed-off-by: NAmit Kucheria <amit.kucheria@linaro.org>
Tested-by: NMarc Gonzalez <marc.w.gonzalez@free.fr>
Signed-off-by: NAndy Gross <agross@kernel.org>

The msm8998-mtp doesn't have TSENS-based sensors wired up for skin and
battery thermal zones. TSENS sensors should be common across all boards
using the SoC and shouldn't be board-specific as these entries.

They also show the following error when trying to read the temperature

   cat: read error: Invalid argument

Remove these board-specific erroneous thermal zones.

Fixes: 4449b6f2 ("arm64: dts: qcom: msm8998: Add tsens and thermal-zones")
Signed-off-by: NAmit Kucheria <amit.kucheria@linaro.org>
Tested-by: NMarc Gonzalez <marc.w.gonzalez@free.fr>
Signed-off-by: NAndy Gross <agross@kernel.org>

The XXTI fixed-clock is the input to the SoC therefore it should not be
inside the soc node.  This also fixes DTC W=1 warning:

    arch/arm64/boot/dts/exynos/exynos7.dtsi:90.17-94.5:
        Warning (simple_bus_reg): /soc/xxti: missing or empty reg/ranges property

While moving, change the name of the xxti node to match the generic type
of device (following DeviceTree specification).
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>