linux-stable.git/arch/arm/boot, branch v5.2.20 Linux kernel stable tree ARM: dts: am3517-evm: Fix missing video 2019-10-05T11:14:02+00:00 Adam Ford aford173@gmail.com 2019-08-28T18:33:51+00:00 d567e81a20c053d111ba383f1825f358293490e8 commit 24cf23276a54dd2825d3e3965c1b1b453e2a113d upstream. A previous commit removed the panel-dpi driver, which made the video on the AM3517-evm stop working because it relied on the dpi driver for setting video timings. Now that the simple-panel driver is available in omap2plus, this patch migrates the am3517-evm to use a similar panel and remove the manual timing requirements. Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver") Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 24cf23276a54dd2825d3e3965c1b1b453e2a113d upstream.

A previous commit removed the panel-dpi driver, which made the
video on the AM3517-evm stop working because it relied on the dpi
driver for setting video timings.  Now that the simple-panel driver
is available in omap2plus, this patch migrates the am3517-evm
to use a similar panel and remove the manual timing requirements.

Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")

Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: dts: logicpd-torpedo-baseboard: Fix missing video 2019-10-05T11:14:00+00:00 Adam Ford aford173@gmail.com 2019-08-28T18:33:50+00:00 3d226661238eddc23704b73a9b91adcb2d72ce32 commit f9f5518a38684e031d913f40482721ff553f5ba2 upstream. A previous commit removed the panel-dpi driver, which made the Torpedo video stop working because it relied on the dpi driver for setting video timings. Now that the simple-panel driver is available in omap2plus, this patch migrates the Torpedo dev kits to use a similar panel and remove the manual timing requirements. Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver") Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f9f5518a38684e031d913f40482721ff553f5ba2 upstream.

A previous commit removed the panel-dpi driver, which made the
Torpedo video stop working because it relied on the dpi driver
for setting video timings.  Now that the simple-panel driver is
available in omap2plus, this patch migrates the Torpedo dev kits
to use a similar panel and remove the manual timing requirements.

Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")

Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: dts: exynos: Mark LDO10 as always-on on Peach Pit/Pi Chromebooks 2019-10-05T11:13:52+00:00 Marek Szyprowski m.szyprowski@samsung.com 2019-08-30T12:52:42+00:00 91180767bba94344fc449c04bff2e042126c4fed [ Upstream commit 5b0eeeaa37615df37a9a30929b73e9defe61ca84 ] Commit aff138bf8e37 ("ARM: dts: exynos: Add TMU nodes regulator supply for Peach boards") assigned LDO10 to Exynos Thermal Measurement Unit, but it turned out that it supplies also some other critical parts and board freezes/crashes when it is turned off. The mentioned commit made Exynos TMU a consumer of that regulator and in typical case Exynos TMU driver keeps it enabled from early boot. However there are such configurations (example is multi_v7_defconfig), in which some of the regulators are compiled as modules and are not available from early boot. In such case it may happen that LDO10 is turned off by regulator core, because it has no consumers yet (in this case consumer drivers cannot get it, because the supply regulators for it are not yet available). This in turn causes the board to crash. This patch restores 'always-on' property for the LDO10 regulator. Fixes: aff138bf8e37 ("ARM: dts: exynos: Add TMU nodes regulator supply for Peach boards") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 5b0eeeaa37615df37a9a30929b73e9defe61ca84 ]

Commit aff138bf8e37 ("ARM: dts: exynos: Add TMU nodes regulator supply
for Peach boards") assigned LDO10 to Exynos Thermal Measurement Unit,
but it turned out that it supplies also some other critical parts and
board freezes/crashes when it is turned off.

The mentioned commit made Exynos TMU a consumer of that regulator and in
typical case Exynos TMU driver keeps it enabled from early boot. However
there are such configurations (example is multi_v7_defconfig), in which
some of the regulators are compiled as modules and are not available
from early boot. In such case it may happen that LDO10 is turned off by
regulator core, because it has no consumers yet (in this case consumer
drivers cannot get it, because the supply regulators for it are not yet
available). This in turn causes the board to crash. This patch restores
'always-on' property for the LDO10 regulator.

Fixes: aff138bf8e37 ("ARM: dts: exynos: Add TMU nodes regulator supply for Peach boards")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ARM: dts: imx7-colibri: disable HS400 2019-10-05T11:13:41+00:00 Stefan Agner stefan.agner@toradex.com 2019-08-12T14:21:17+00:00 5ac00c9194aea0b4b0811edbd4f3ad7c85ea33c0 [ Upstream commit a95fbda08ee20cd063ce5826e0df95a2c22ea8c5 ] Force HS200 by masking bit 63 of the SDHCI capability register. The i.MX ESDHC driver uses SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400. With that the stack checks bit 63 to descide whether HS400 is available. Using sdhci-caps-mask allows to mask bit 63. The stack then selects HS200 as operating mode. This prevents rare communication errors with minimal effect on performance: sdhci-esdhc-imx 30b60000.usdhc: warning! HS400 strobe DLL status REF not lock! Signed-off-by: Stefan Agner <stefan.agner@toradex.com> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Reviewed-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit a95fbda08ee20cd063ce5826e0df95a2c22ea8c5 ]

Force HS200 by masking bit 63 of the SDHCI capability register.
The i.MX ESDHC driver uses SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400. With
that the stack checks bit 63 to descide whether HS400 is available.
Using sdhci-caps-mask allows to mask bit 63. The stack then selects
HS200 as operating mode.

This prevents rare communication errors with minimal effect on
performance:
	sdhci-esdhc-imx 30b60000.usdhc: warning! HS400 strobe DLL
		status REF not lock!

Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Reviewed-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ARM: dts: imx7d: cl-som-imx7: make ethernet work again 2019-10-05T11:13:41+00:00 André Draszik git@andred.net 2019-08-09T03:12:27+00:00 d89e114b2f42b47a480ed0ad766163afda97aa9b [ Upstream commit 9846a4524ac90b63496580b7ad50674b40d92a8f ] Recent changes to the atheros at803x driver caused ethernet to stop working on this board. In particular commit 6d4cd041f0af ("net: phy: at803x: disable delay only for RGMII mode") and commit cd28d1d6e52e ("net: phy: at803x: Disable phy delay for RGMII mode") fix the AR8031 driver to configure the phy's (RX/TX) delays as per the 'phy-mode' in the device tree. This now prevents ethernet from working on this board. It used to work before those commits, because the AR8031 comes out of reset with RX delay enabled, and the at803x driver didn't touch the delay configuration at all when "rgmii" mode was selected, and because arch/arm/mach-imx/mach-imx7d.c:ar8031_phy_fixup() unconditionally enables TX delay. Since above commits ar8031_phy_fixup() also has no effect anymore, and the end-result is that all delays are disabled in the phy, no ethernet. Update the device tree to restore functionality. Signed-off-by: André Draszik <git@andred.net> CC: Ilya Ledvich <ilya@compulab.co.il> CC: Igor Grinberg <grinberg@compulab.co.il> CC: Rob Herring <robh+dt@kernel.org> CC: Mark Rutland <mark.rutland@arm.com> CC: Shawn Guo <shawnguo@kernel.org> CC: Sascha Hauer <s.hauer@pengutronix.de> CC: Pengutronix Kernel Team <kernel@pengutronix.de> CC: Fabio Estevam <festevam@gmail.com> CC: NXP Linux Team <linux-imx@nxp.com> CC: devicetree@vger.kernel.org CC: linux-arm-kernel@lists.infradead.org Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 9846a4524ac90b63496580b7ad50674b40d92a8f ]

Recent changes to the atheros at803x driver caused
ethernet to stop working on this board.
In particular commit 6d4cd041f0af
("net: phy: at803x: disable delay only for RGMII mode")
and commit cd28d1d6e52e
("net: phy: at803x: Disable phy delay for RGMII mode")
fix the AR8031 driver to configure the phy's (RX/TX)
delays as per the 'phy-mode' in the device tree.

This now prevents ethernet from working on this board.

It used to work before those commits, because the
AR8031 comes out of reset with RX delay enabled, and
the at803x driver didn't touch the delay configuration
at all when "rgmii" mode was selected, and because
arch/arm/mach-imx/mach-imx7d.c:ar8031_phy_fixup()
unconditionally enables TX delay.

Since above commits ar8031_phy_fixup() also has no
effect anymore, and the end-result is that all delays
are disabled in the phy, no ethernet.

Update the device tree to restore functionality.

Signed-off-by: André Draszik <git@andred.net>
CC: Ilya Ledvich <ilya@compulab.co.il>
CC: Igor Grinberg <grinberg@compulab.co.il>
CC: Rob Herring <robh+dt@kernel.org>
CC: Mark Rutland <mark.rutland@arm.com>
CC: Shawn Guo <shawnguo@kernel.org>
CC: Sascha Hauer <s.hauer@pengutronix.de>
CC: Pengutronix Kernel Team <kernel@pengutronix.de>
CC: Fabio Estevam <festevam@gmail.com>
CC: NXP Linux Team <linux-imx@nxp.com>
CC: devicetree@vger.kernel.org
CC: linux-arm-kernel@lists.infradead.org
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ARM: dts: Fix incomplete dts data for am3 and am4 mmc 2019-09-21T05:18:27+00:00 Tony Lindgren tony@atomide.com 2019-07-23T07:29:23+00:00 62c3bfff7d9e9ae9e0f56e0cd2fc5b13e3a41f7f [ Upstream commit 5b63fb90adb95a178ad403e1703f59bf1ff2c16b ] Commit 4e27f752ab8c ("ARM: OMAP2+: Drop mmc platform data for am330x and am43xx") dropped legacy mmc platform data for am3 and am4, but missed the fact that we never updated the dts files for mmc3 that is directly on l3 interconnect instead of l4 interconnect. This leads to a situation with no legacy platform data and incomplete dts data. Let's update the mmc instances on l3 interconnect to probe properly with ti-sysc interconnect target module driver to make mmc3 work again. Let's still keep legacy "ti,hwmods" property around for v5.2 kernel and only drop it later on. Note that there is no need to use property status = "disabled" for mmc3. The default for dts is enabled, and runtime PM will idle unused instances just fine. Fixes: 4e27f752ab8c ("ARM: OMAP2+: Drop mmc platform data for am330x and am43xx") Reported-by: David Lechner <david@lechnology.com> Tested-by: David Lechner <david@lechnology.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 5b63fb90adb95a178ad403e1703f59bf1ff2c16b ]

Commit 4e27f752ab8c ("ARM: OMAP2+: Drop mmc platform data for am330x and
am43xx") dropped legacy mmc platform data for am3 and am4, but missed the
fact that we never updated the dts files for mmc3 that is directly on l3
interconnect instead of l4 interconnect. This leads to a situation with
no legacy platform data and incomplete dts data.

Let's update the mmc instances on l3 interconnect to probe properly with
ti-sysc interconnect target module driver to make mmc3 work again. Let's
still keep legacy "ti,hwmods" property around for v5.2 kernel and only
drop it later on.

Note that there is no need to use property status = "disabled" for mmc3.
The default for dts is enabled, and runtime PM will idle unused instances
just fine.

Fixes: 4e27f752ab8c ("ARM: OMAP2+: Drop mmc platform data for am330x and am43xx")
Reported-by: David Lechner <david@lechnology.com>
Tested-by: David Lechner <david@lechnology.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ARM: dts: dra74x: Fix iodelay configuration for mmc3 2019-09-21T05:18:26+00:00 Faiz Abbas faiz_abbas@ti.com 2019-08-07T10:52:38+00:00 3d8729676adb9963e1d787390ec05d14bd894ab1 [ Upstream commit 07f9a8be66a9bd86f9eaedf8f8aeb416195adab8 ] According to the latest am572x[1] and dra74x[2] data manuals, mmc3 default, hs, sdr12 and sdr25 modes use iodelay values given in MMC3_MANUAL1. Set the MODE_SELECT bit for these so that manual mode is selected and correct iodelay values can be configured. [1] http://www.ti.com/lit/ds/symlink/am5728.pdf [2] http://www.ti.com/lit/ds/symlink/dra746.pdf Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 07f9a8be66a9bd86f9eaedf8f8aeb416195adab8 ]

According to the latest am572x[1] and dra74x[2] data manuals, mmc3
default, hs, sdr12 and sdr25 modes use iodelay values given in
MMC3_MANUAL1. Set the MODE_SELECT bit for these so that manual mode is
selected and correct iodelay values can be configured.

[1] http://www.ti.com/lit/ds/symlink/am5728.pdf
[2] http://www.ti.com/lit/ds/symlink/dra746.pdf

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ARM: dts: am335x: Fix UARTs length 2019-09-21T05:18:26+00:00 Emmanuel Vadot manu@freebsd.org 2019-07-24T12:23:29+00:00 70af7f6d9e6a7e1db12a8e3045580f83eb9cfacf [ Upstream commit 8613e2ca4fff764f23785eadfa54a08631ee682a ] As seen on the AM335x TRM all the UARTs controller only are 0x1000 in size. Fix this in the DTS. Signed-off-by: Emmanuel Vadot <manu@freebsd.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 8613e2ca4fff764f23785eadfa54a08631ee682a ]

As seen on the AM335x TRM all the UARTs controller only are 0x1000 in size.
Fix this in the DTS.

Signed-off-by: Emmanuel Vadot <manu@freebsd.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ARM: dts: Fix incorrect dcan register mapping for am3, am4 and dra7 2019-09-21T05:18:25+00:00 Tony Lindgren tony@atomide.com 2019-07-22T10:44:42+00:00 3d3879d57e3b6d6f6fb8a5059d4622c190ffbc51 [ Upstream commit 89bbc6f1eb90809b1538b3a9c54030c558180e3b ] We are currently using a wrong register for dcan revision. Although this is currently only used for detecting the dcan module, let's fix it to avoid confusion. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 89bbc6f1eb90809b1538b3a9c54030c558180e3b ]

We are currently using a wrong register for dcan revision. Although
this is currently only used for detecting the dcan module, let's
fix it to avoid confusion.

Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ARM: dts: Fix flags for gpio7 2019-09-21T05:18:24+00:00 Tony Lindgren tony@atomide.com 2019-07-22T10:44:47+00:00 6d326307187b37026706ba225b4b307cb962ed9a [ Upstream commit 2e8647bbe1c8233a20c32fd2648258f2c05c7335 ] The ti,no-idle-on-init and ti,no-reset-on-init flags need to be at the interconnect target module level for the modules that have it defined. Otherwise we get the following warnings: dts flag should be at module level for ti,no-idle-on-init dts flag should be at module level for ti,no-reset-on-init Reviewed-by: Suman Anna <s-anna@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 2e8647bbe1c8233a20c32fd2648258f2c05c7335 ]

The ti,no-idle-on-init and ti,no-reset-on-init flags need to be at
the interconnect target module level for the modules that have it
defined. Otherwise we get the following warnings:

dts flag should be at module level for ti,no-idle-on-init
dts flag should be at module level for ti,no-reset-on-init

Reviewed-by: Suman Anna <s-anna@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>