This is the first generation Amazon Echo from 2016.
Audio support is not yet implemented.
Signed-off-by: André Hentschel <nerv@dawncrow.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
DM3730 is considered as omap36xx.dtsi, while the rest has:
DM3730 | DM3725 | AM3715 | AM3703
IVA X | X | |
SGX X | | X |
Where X is "supported"
Signed-off-by: André Hentschel <nerv@dawncrow.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
During suspend CPU context may be lost in both non-secure and secure CPU
states. The kernel can handle saving and restoring the non-secure context
but must call into the secure side to allow it to save any context it may
lose. Add these calls here.
Note that on systems with OP-TEE available the suspend call is issued to
OP-TEE using the ARM SMCCC, but the resume call is always issued to the
ROM. This is because on waking from suspend the ROM is restored as the
secure monitor. It is this resume call that instructs the ROM to restore
OP-TEE, all subsequent calls will be handled by OP-TEE and should use the
ARM SMCCC.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Dave Gerlach <d-gerlach@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
On High-Security(HS) OMAP2+ class devices a couple actions must be
performed from the ARM TrustZone during boot. These traditionally can be
performed by calling into the secure ROM code resident in this secure
world using legacy SMC calls. Optionally OP-TEE can replace this secure
world functionality by replacing the ROM after boot. ARM recommends a
standard calling convention is used for this interaction (SMC Calling
Convention). We check for the presence of OP-TEE and use this type of
call to perform the needed actions, falling back to the legacy OMAP ROM
call if OP-TEE is not available.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This check and associated flag can be used to signal the presence
of OP-TEE on the platform. This can be used to determine which
SMC calls to make to perform secure operations.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This can be used for detecting secure features or making early device
init sequence changes based on device security type.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
BeagleBone Black series is equipped with 512MB RAM
whereas only 256MB is included from am335x-bone-common.dtsi
This leads to an issue with unusual setups when devicetree
is loaded by GRUB2 directly.
Signed-off-by: Matwey V. Kornilov <matwey@sai.msu.ru>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The codec driver needs correct regulators in order to probe.
Both VCC_3.3V and VCC_1.8V is always on fixed regulators on the board.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
The codec driver needs correct regulators in order to probe.
Both VCC_3V3 and VCC_1V8 is always on fixed regulators on the board.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
An experimental test with the command below gives this error:
rk3188-bqedison2qc.dt.yaml: dwmmc@10218000: wifi@1:
'reg' is a required property
So fix this by adding a reg property to the brcmf sub node.
Also add #address-cells and #size-cells to prevent more warnings.
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200110134420.11280-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
All platforms have now been switched to the new clocksource driver.
Remove the old code and various no longer needed bits and pieces.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: David Lechner <david@lechnology.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
We now have a proper clocksource driver for davinci. Switch the dm365
platform to using it.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: David Lechner <david@lechnology.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
In order to probe this ethernet interface from the device tree
all physical MMIO regions must be passed as resources. Begin
this rewrite by first passing the port base address as a
resource for all platforms using this driver, remap it in
the driver and avoid using any reference of the statically
mapped virtual address in the driver.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The platform data is needed to compile the driver as standalone,
so move it to a global location along with similar files.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ixp46x ptp driver has a somewhat unusual setup, where the ptp
driver and the ethernet driver are in different directories but
access the same registers that are defined a platform specific
header file.
Moving everything into drivers/net/ makes it look more like most
other ptp drivers and allows compile-testing this driver on
other targets.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ixp4xx_hss driver needs the platform data definition and the
system clock rate to be compiled. Move both into a new platform_data
header file.
This is a prerequisite for compile testing, but turning on compile
testing requires further patches to isolate the SoC headers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The Gateworks GW5907 is an IMX6 SoC based single board computer with:
- IMX6Q or IMX6DL
- 32bit DDR3 DRAM
- FEC GbE Phy
- bi-color front-panel LED
- 256MB NAND boot device
- Gateworks System Controller (hwmon, pushbutton controller, EEPROM)
- Digital IO expander (pca9555)
- Joystick 12bit adc (ads1015)
Signed-off-by: Robert Jones <rjones@gateworks.com>
Reviewed-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Samsung DTS ARM changes for v5.6
1. Couple ARM and wcore bus regulators on Exynos542x so higher
frequencies could be used with dynamic voltage and frequency scaling.
Enable this higher frequencies.
2. Correct the polarity of USB3503 hub GPIOs.
3. Adjust the bus frequencies (scaled with devfreq framework) on
Exynos5422 Odroid boards to match values possible to obtain from root
PLLs.
4. Add display to Tiny4412 board.
5. Cleanups and minor improvements.
* tag 'samsung-dt-5.6' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
ARM: dts: exynos: Enable FIMD node and add proper panel node to Tiny4412
ARM: dts: samsung: Rename Samsung and Exynos to lowercase
ARM: dts: exynos: Adjust bus related OPPs to the values correct for Exynos5422 Odroids
ARM: dts: exynos: Move Exynos5420 bus related OPPs to the Odroid boards DTS
ARM: dts: exynos: Correct USB3503 GPIOs polarity
ARM: dts: exynos: Add missing CPU frequencies for Exynos5422/5800
ARM: dts: exynos: Add initial data for coupled regulators for Exynos5422/5800
ARM: dts: exynos: Remove syscon compatible from chipid node on Exynos5
Link: https://lore.kernel.org/r/20200110172334.4767-3-krzk@kernel.org
Signed-off-by: Olof Johansson <olof@lixom.net>
Cleanups (Samsung and Exynos names, Kconfig help text correction).
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAl4YsHAQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD1wKGD/9IdB5FLNEAoJ0hqn+JifCP77fAXpjuJu8A
XK/ruLhqJAFsmpynLmN8Mbno+48mewlQq9hRgl0vx9UN8wSzQh5vWqyTQl0PjqwV
4DdEJhxSueOxm7oxaBKV3k+QZX498sJxucdgCG53gRkxwvQj6TQn7PXDBwZYlOo8
6b40qwZ2lY/T/T8kUuKrMZs1SPoRa55y5Yc3Sj2B0S343grR6fdZ73AcSr44LN5v
GBCajYM8jyNXrfDcNaM54eeCDT/ExaF2QoqOS77C2dBb+pii41/Fz1w4jmj36X1E
izzqSbMlcZR0nMzywdy34l7XyWDgz2l7siUnhVCzbVcb9WtceEwnwLbASSzgQj6Z
XAZKBk1X618Oq8aFznzGIPx8CTxsUpjw/9vgpCsgx+v69L/xr6/pPTQveXiGVySo
0uevBI/6zbhr7kmarn3+0S2ly2DsVh2rTHC/T8P4wmD1rJSszjCXlXloUGnc7sNH
9z3I7zIzT9KmHFtN7wSb7olJYgnlWu32WWmvD8WsXkWGIDkX08J1qv7UIO00OL3H
rzG0hKJ3P2fA0EI/sLAbXLkrDwm/lOIINQpSdeqoBNRPKlPJ4njnRqHZtH5r29pu
Qsy+fCh+lj3M1RHLecnlq1DwWqJgSflFmd7j9zWoSw57XHTdW+zm+mZo1VY4brdr
UvaQruhzhw==
=NDK3
-----END PGP SIGNATURE-----
Merge tag 'samsung-soc-5.6' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/soc
Samsung mach/soc changes for v5.6
Cleanups (Samsung and Exynos names, Kconfig help text correction).
* tag 'samsung-soc-5.6' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
ARM: samsung: Rename Samsung and Exynos to lowercase
ARM: exynos: Correct the help text for platform Kconfig option
Link: https://lore.kernel.org/r/20200110172334.4767-4-krzk@kernel.org
Signed-off-by: Olof Johansson <olof@lixom.net>
carrier board, separate versions for the two rockpro64 hardware revisions
which switched a pin between revisions. The rockpro64 also got
bluetooth support now.
The px30 got a lot of attention with dsi, gpu and thermal support.
Similarly the rk3399-roc-pc board also got attention with mtd flash,
sdr104 mode, hdmi sound, gpu and a lot of other smaller improvements.
Other than that there is a new gpu-cooling device for rk3399 a cpu
idle-state for rk3328 and more small improvements across a number
of boards.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAl4Xm7MQHGhlaWtvQHNu
dGVjaC5kZQAKCRDzpnnJnNEdgXPbB/4/iuGhWfydiiB6Mrmeifzlt+Ch7Hm5IJBA
03f8FiHbGkW1Tlh1buw6t9BDKI0XKNqD94MU0pya4yDB7baFaH1GEk8S4/mbEAuE
OZnWM0jzQ40b/1JmwRCw0PL2NTFHwlE+SSHnBJ4EW/OnOsCYUSz8+Aq33fMwdsPA
Dm9gxAeeHsBJTxk26cxLrGePB5vYXltGwazklkKkU5scV75sfJu1xcRKcnVp71sH
4j33aWi19GWo2YkW6RGXzTgiXoFPR+PgzfU337KTqq6A5oSIybH9g2WUnYyAxi8R
tJKxiOBSBeGIrIRxMWtw8g9VxohJwzHfi9y4XO1VwzLpl/SQf3mb
=iCh7
-----END PGP SIGNATURE-----
Merge tag 'v5.6-rockchip-dts64-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/dt
New boards are the Radxa Rock Pi N10 using the VMARC SOM and Dalang
carrier board, separate versions for the two rockpro64 hardware revisions
which switched a pin between revisions. The rockpro64 also got
bluetooth support now.
The px30 got a lot of attention with dsi, gpu and thermal support.
Similarly the rk3399-roc-pc board also got attention with mtd flash,
sdr104 mode, hdmi sound, gpu and a lot of other smaller improvements.
Other than that there is a new gpu-cooling device for rk3399 a cpu
idle-state for rk3328 and more small improvements across a number
of boards.
* tag 'v5.6-rockchip-dts64-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: (37 commits)
arm64: dts: rockchip: Enable mp8859 regulator on rk3399-roc-pc
arm64: dts: rockchip: rk3399-hugsun-x99: remove supports-sd and supports-emmc options
arm64: dts: rockchip: rk3399-firefly: remove num-slots from &sdio0 node
arm64: dts: rockchip: Add PX30 LVDS
arm64: dts: rockchip: add dsi controller for px30
arm64: dts: rockchip: Add PX30 DSI DPHY
arm64: dts: rockchip: Add RK3328 idle state
arm64: dts: rockchip: remove identical &uart0 node from rk3368-lion-haikou
arm64: dts: rockchip: Add Radxa Rock Pi N10 initial support
ARM: dts: rockchip: Add Radxa Dalang Carrier board
arm64: dts: rockchip: Add VMARC RK3399Pro SOM initial support
dt-bindings: arm: rockchip: Add Rock Pi N10 binding
arm64: dts: rockchip: hook up bluetooth at uart0 on rockpro64
arm64: dts: rockchip: enable wifi module at sdio0 on rockpro64
arm64: dts: rockchip: split rk3399-rockpro64 for v2 and v2.1 boards
arm64: dts: rockchip: enable the gpu on px30-evb
arm64: dts: rockchip: add the gpu for px30
dt-bindings: gpu: mali-bifrost: Add Rockchip PX30
arm64: dts: rockchip: Add GPU cooling device for RK3399
arm64: dts: rockchip: Add regulators for PCIe for Radxa Rock Pi 4 board
...
Link: https://lore.kernel.org/r/5115625.yBEeHQkg2z@phil
Signed-off-by: Olof Johansson <olof@lixom.net>
additional operating points for rk3288-tinker.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAl4Xk/0QHGhlaWtvQHNu
dGVjaC5kZQAKCRDzpnnJnNEdgbR8B/9fX3OlIkdu19InRObH9COCjhgZNZQDTkcj
BDR2acJuVJlw409bxNJmWNp7/EvkNVv9y/8F5evqNTDx0qCWT7k05GaveXzwlVoE
FFoIlY1+6uuw/2zqCCI+PXDLSo7NKaNewUgmsdWMFfLPITK/Jh9QQgtq0Jw8xYjk
mpvv/BKWvwczj1Ms7Qx/jh9bKSxE8TyeLrLoEyUEYkqMvW+xf/5D4ahEPxwSWy9y
YumDskVBM+669aTLVSdCVKRZntZY8PdgGgo/l0uBTvIsS/GBvP0bdX8WZrwlvQeZ
02Mt/ef7xrA0QHjovypwkI7zZuBwTRSzUqbpTLnFy2HI4bKDiEh+
=+FbZ
-----END PGP SIGNATURE-----
Merge tag 'v5.6-rockchip-dts32-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/dt
Pin-name corrections for Veyron-Fievel, bluetooth for a number of veyron boards and
additional operating points for rk3288-tinker.
* tag 'v5.6-rockchip-dts32-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
ARM: dts: rockchip: Use ABI name for recovery mode pin on veyron fievel/tiger
ARM: dts: rockchip: Use ABI name for write protect pin on veyron fievel/tiger
ARM: dts: rockchip: Add missing cpu operating points for rk3288-tinker
ARM: dts: rockchip: Add brcm bluetooth for rk3288-veyron
Link: https://lore.kernel.org/r/8215452.dU6eVM2tAM@phil
Signed-off-by: Olof Johansson <olof@lixom.net>
This enables the driver for STM32 PWR regulators found on stm32mp1.
Link: https://lore.kernel.org/r/20200109125531.13610-1-alexandre.torgue@st.com
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Highlights:
----------
MPU part:
-Add PWM support on DK2 board.
-Add counter support to STM32 timers.
-Add support of SDMMC 2&3 instances based on "arm,pl18x". SDMMC2 is
connected to eMMC on ED1 board. SDMMC3 is connected to the GPIO
extension connector on EV1 & DKx boards.
-Add ADC support on ED1 board.
-Update devicetree files split to better fit to STM32MP15 SOC & boards
diversity.
-Fix issues seen during YAML validation.
-Enable Ethernet (MAC) TX clock gating during low-power mode.
-Enable USB OTG HS support on DKx boards.
-Enable USB Host EHCI on DKx boards.
MCU part:
-Fix issues seen during YAML validation.
-----BEGIN PGP SIGNATURE-----
iQJMBAABCgA2FiEEctl9+nxzUSUqdELdf5rJavIecIUFAl4XFegYHGFsZXhhbmRy
ZS50b3JndWVAc3QuY29tAAoJEH+ayWryHnCFlvQP/RtwRkAPRWd5HHJraAzEj4gJ
vx5Hcm8TW4Fsu1oQnOPGHBNUJcoj5QvaCKhyqBP/gaffDnzJz4GZsaAGZ0FyQJd7
7IWqWOp2Ek2d5bklpLwmn4KU/5ZAqWTKOL1hYoEAvkXHdmxzcQi7pZOrvCG75GGs
lsqabxtx0S3NCCmVHy/CsmK2qkAxbASUG2oAn3pMIncUxdUyq2u97qhJB0zjM4TL
wE8nXNDPZk4P2ePi675PNo/nVP1WTbFHReHd+SCtjuKgQGFKIpnp3pNSP4jIrN+e
e2Wcb+5zQ10ZGntDDAwN+Ig+Nv7hOMLdbBB29kmRYoD4szFcYvjt+kdnXms/MWw8
vwBW6h6YLQ56zzhmcvD8vIwo5jI3l8jO7Gxk4OlK2tsyR+4HXpntkYuq2jOuVqoF
UuTrL4hMSoXrUOX+lfaGFC6x0NmblE+NWqbXEWfQ+mqb42z69O1d6Ws2vcl3CgWc
yUpCMOPkzb6ZIzc77+884COneZKqxRtpjNE7vaIUBEzVdxF6IIyaABBhBNbM3SE2
R/ibKOVh1OWpaYIi2qK7jhUMb5WjVt1jTCDVQmB1sYXzfbA2bzzc3iRVAwd1Oioc
W/wn7G3kh4PcwM8QHlbtuJwa5j/BBF4CNAk+pTXuVKX0eBgfgxGOE+PLTUowH1HA
iYXi2dMogCnXHxDvIBtX
=ch11
-----END PGP SIGNATURE-----
Merge tag 'stm32-dt-for-v5.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into arm/dt
STM32 DT updates for v5.6, round 1
Highlights:
----------
MPU part:
-Add PWM support on DK2 board.
-Add counter support to STM32 timers.
-Add support of SDMMC 2&3 instances based on "arm,pl18x". SDMMC2 is
connected to eMMC on ED1 board. SDMMC3 is connected to the GPIO
extension connector on EV1 & DKx boards.
-Add ADC support on ED1 board.
-Update devicetree files split to better fit to STM32MP15 SOC & boards
diversity.
-Fix issues seen during YAML validation.
-Enable Ethernet (MAC) TX clock gating during low-power mode.
-Enable USB OTG HS support on DKx boards.
-Enable USB Host EHCI on DKx boards.
MCU part:
-Fix issues seen during YAML validation.
* tag 'stm32-dt-for-v5.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32: (37 commits)
ARM: dts: stm32: Add power-supply for RGB panel on stm32429i-eval
ARM: dts: stm32: Add power-supply for DSI panel on stm32f469-disco
ARM: dts: stm32: change nvmem node name on stm32mp1
ARM: dts: stm32: change nvmem node name on stm32f429
ARM: dts: stm32: update mlahb node according to the bindings on stm32mp15
ARM: dts: stm32: fix dma controller node name on stm32mp157c
ARM: dts: stm32: fix dma controller node name on stm32f743
ARM: dts: stm32: fix dma controller node name on stm32f746
ARM: dts: stm32: add phy-names to usbotg_hs on stm32mp157c-ev1
ARM: dts: stm32: enable USB OTG HS on stm32mp15 DKx boards
ARM: dts: stm32: enable USB Host (USBH) EHCI controller on stm32mp15 DKx
ARM: dts: stm32: enable USBPHYC on stm32mp15 DKx boards
ARM: dts: stm32: remove useless clock-names from RTC node on stm32f746
ARM: dts: stm32: remove useless clock-names from RTC node on stm32f429
ARM: dts: stm32: Enable MAC TX clock gating during TX low-power mode on stm32mp15
ARM: dts: stm32: adjust slew rate for Ethernet on stm32mp15
ARM: dts: stm32: remove syscfg clock on stm32mp15 ethernet
ARM: dts: stm32: remove "@" and "_" from stm32f7 pinmux groups
ARM: dts: stm32: remove "@" and "_" from stm32f4 pinmux groups
ARM: dts: stm32: Adapt STM32MP157C ED1 board to STM32 DT diversity
...
Link: https://lore.kernel.org/r/39df1dee-3c9f-cd35-bc55-a71223e07100@st.com
Signed-off-by: Olof Johansson <olof@lixom.net>
changes for 5.6, please pull the following:
- Justin adds an entry for BCM7216's debug UART to support DEBUG_LL
- Florian adds a select ARM_AMBA to support the ARM PL011 UART/console
which is required on BCM7211
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAl4WKG8ACgkQh9CWnEQH
BwTZug/8CDl9acI49fAWuKRNfd2InZQnwtvmdb5+kwYAtedkY/hmUodyDPoTqr9C
vQ/uzjXPRqKsr9TysK+ubZQomeqBdb4madmGoxqPE9Fl2yZwjnon9PE5Evqvk1b9
DxCBvrnP3/YMEFlGxebL5MORf8TPq+IKzA8Klzcs0ED3E6F2c8xG4ODFjXK7GSzf
Oz9+MropwWw7+bTN/VlOjL2x90b5fZM7chztC9zwBJGym85oqZnY5HvwLOZuysYp
5AsENirqgMuisM7EIy4DXwJFC15W4YIDTK/B+iKyapgyeYcrJmpQmsGePYY2Rtrs
tFd91RX5Wsg5RqCmFKgb2qa8QwtVOqARFoSfAOBU4Gx+ezIyg0hchgfhT9Mk2jF8
luM9ts99sxyUrS1yXv1MunXBmuXl+rMho3Su3vuAJNcYTW0b3ebE+UTxUM+oBu20
vPVVwLzUglS4siSi/Q09ar+GB4U8pn2y0k0reZuFUo8VBxjFIyFEIF9PUqgaXgtn
RKJto4YpDcTByhODYnDkLdzlPMC3vyMG+efgEj3YpWrfXxIx3L3kRT8dAEtU6zs+
8pD+OBxdgGfgwGCHU4AtpaANriaLXlGx+kMZiqXQYidHGOUtDS3rKkVkcVrhoJCs
GB7RHFABQrUFq+F72TxprxaXJ1a7EYmIeK8SYm6DvBXBYee63u4=
=yt4p
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-5.6/soc' of https://github.com/Broadcom/stblinux into arm/soc
This pull request contains Broadcom ARM-based SoCs Kconfig/machine
changes for 5.6, please pull the following:
- Justin adds an entry for BCM7216's debug UART to support DEBUG_LL
- Florian adds a select ARM_AMBA to support the ARM PL011 UART/console
which is required on BCM7211
* tag 'arm-soc/for-5.6/soc' of https://github.com/Broadcom/stblinux:
ARM: bcm: Select ARM_AMBA for ARCH_BRCMSTB
ARM: brcmstb: Add debug UART entry for 7216
Link: https://lore.kernel.org/r/20200108191114.15987-3-f.fainelli@gmail.com
Signed-off-by: Olof Johansson <olof@lixom.net>
for 5.6, please pull the following:
- Stephan adds support for the HWRNG on 2711 (Raspberry Pi 4) which is
different than the previous Pi chips
- Florian switches the BCM956265HR board to use the hardware I2C
controllers for interfacing with the SFPs
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAl4WKTUACgkQh9CWnEQH
BwQ/8Q//dU5IKccRirODFKEZwgjFd70a7tnf5GelqeBA8WqmN3sqGbPHtlJ8ycca
C0ueafIas6zeTheHvbbraRYyHetLOQys++eOBVzp3m9BtyemQPcb1wgbGe2lnwPe
F3eJSq/EvWavauOul/POzv4wJpvoX3D1mI5fIAfg7n4sIYe2UWtVvVIO2V6XaBFG
LCcIxPSxSLC5tVAVFNdvCoBLUv2QrrUQs5OHybZNTRmOabscPZW+wptsIu3Cyzw7
Z4DaBpPTJzhLZu0b88Y5hca7+el3hZ+aCJ3AzjXxrzJjG7gUgNEQXOg2ygXPWETO
vGjc3IrptriHGtHzby/+JWLW4GlGBPvP0+YBD6R+dR74ZFWZp9kPkJjbIzCd0/Tq
ajootPE+P6JlS2fKEWhBZcMpsBsBurBdlhP56DzwCgKkrzQn4CxW9BDcjHJTVE6x
FG8S5pil+PdMTVEm20ZV+ZjkAtdsQ/YakXeuT9l44C9L3jgWw6bz4lB4kgB4acOP
bi6xJpJ1XNxdjsqotLeg7DD5I56c7ZMvAdxo18zEBPxXmvitoUjEQPCYLomvWPhd
l6PGAeNNZAPKKWLP25qRFLTbihlMfBXujE489JbraNLsrSvgwzzxXGykV6cSNUf2
jqeLRghxtZTXnG+BRXXo+aPAfPUK3hHol8Bs1aRyUHV5fZAjly4=
=EguA
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-5.6/devicetree' of https://github.com/Broadcom/stblinux into arm/dt
This pull request contains Broadcom ARM-based SoCs Device Tree changes
for 5.6, please pull the following:
- Stephan adds support for the HWRNG on 2711 (Raspberry Pi 4) which is
different than the previous Pi chips
- Florian switches the BCM956265HR board to use the hardware I2C
controllers for interfacing with the SFPs
* tag 'arm-soc/for-5.6/devicetree' of https://github.com/Broadcom/stblinux:
ARM: dts: bcm2711: Enable HWRNG support
ARM: dts: bcm2835: Move rng definition to common location
ARM: dts: NSP: Use hardware I2C for BCM958625HR
Link: https://lore.kernel.org/r/20200108191114.15987-1-f.fainelli@gmail.com
Signed-off-by: Olof Johansson <olof@lixom.net>
- Fix i.MX8MM SDMA1 AHB clock setting to remove a "Timeout waiting for CH0"
error seen with UART1.
- Correct compatible of RV3029 RTC device on imx6q-dhcom board.
- Correct interrupt trigger type for magnetometer on board
imx8mq-librem5-devkit.
- A series from Anson Huang to fix vdd3p0 power supplier for a few NXP
development board.
- Fix imx6q-icore-mipi board to use 1.5 version of i.Core MX6DL, so
that Ethernet interface on the board works properly.
- Fix Toradex Colibri board to get NAND flash support back.
- Fix SGTL5000 VDDIO regulator connection for imx6q-dhcom, which
is connected to PMIC SW2 output rather than a fixed 3V3 rail.
- Fix 'reg' of CPU node on imx7ulp to get rid of a warning given by
kernel.
- Fix endian setting for DCFG on LS1028A SoC, so that register access
of DCFG becomes correct.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAl4Xz5gUHHNoYXduZ3Vv
QGtlcm5lbC5vcmcACgkQUFdYWoewfM44xgf+J/WZaUY9S9tvl9w9kMdmmB71WSVY
qCgWTS6FUvw7AiJ+4mUzXXTP+Wwb0c1wBtvI4FRk6MhkHEc1nSkhJ5I9++bDD7BV
2ktAIJmC2uSHdazq/wjDMi4T6LGnmRv1xKkEvib2/CBVzET9PoGJY2stS8R0r2xf
WwCvMb0Lc7Twp0/nlY+h8ItHL50ZZuBSqW83P26zQdImHKMwRiAdlFa7eiZu82nV
sPadYbtf07yUfeLpUfYXo/nFZ+Q2c+tJGUNxm0hXGvc+FaWS4MM44luBTN2fpaVl
vAg2LKvdaWGbDZk0Q6WQdMsleDaHs3JdbaNrqBePbYyTnMll8N31ek3PWg==
=Hv2B
-----END PGP SIGNATURE-----
Merge tag 'imx-fixes-5.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes
i.MX fixes for 5.5, round 2:
- Fix i.MX8MM SDMA1 AHB clock setting to remove a "Timeout waiting for CH0"
error seen with UART1.
- Correct compatible of RV3029 RTC device on imx6q-dhcom board.
- Correct interrupt trigger type for magnetometer on board
imx8mq-librem5-devkit.
- A series from Anson Huang to fix vdd3p0 power supplier for a few NXP
development board.
- Fix imx6q-icore-mipi board to use 1.5 version of i.Core MX6DL, so
that Ethernet interface on the board works properly.
- Fix Toradex Colibri board to get NAND flash support back.
- Fix SGTL5000 VDDIO regulator connection for imx6q-dhcom, which
is connected to PMIC SW2 output rather than a fixed 3V3 rail.
- Fix 'reg' of CPU node on imx7ulp to get rid of a warning given by
kernel.
- Fix endian setting for DCFG on LS1028A SoC, so that register access
of DCFG becomes correct.
* tag 'imx-fixes-5.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: dts: imx7: Fix Toradex Colibri iMX7S 256MB NAND flash support
ARM: dts: imx6sll-evk: Remove incorrect power supply assignment
ARM: dts: imx6sl-evk: Remove incorrect power supply assignment
ARM: dts: imx6sx-sdb: Remove incorrect power supply assignment
ARM: dts: imx6qdl-sabresd: Remove incorrect power supply assignment
ARM: dts: imx6q-icore-mipi: Use 1.5 version of i.Core MX6DL
arm64: dts: imx8mq-librem5-devkit: use correct interrupt for the magnetometer
ARM: dts: imx6q-dhcom: Fix SGTL5000 VDDIO regulator connection
ARM: dts: imx7ulp: fix reg of cpu node
arm64: dts: imx8mm: Change SDMA1 ahb clock for imx8mm
arm64: dts: ls1028a: fix endian setting for dcfg
ARM: dts: imx6q-dhcom: fix rtc compatible
Link: https://lore.kernel.org/r/20200110011836.GW4456@T480
Signed-off-by: Olof Johansson <olof@lixom.net>
Use of_device_id array to find the proper shdwc compatibile node.
SAM9X60's shdwc changes were not integrated when
commit eaedc0d379 ("ARM: at91: pm: add ULP1 support for SAM9X60")
was integrated.
Fixes: eaedc0d379 ("ARM: at91: pm: add ULP1 support for SAM9X60")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/1576062248-18514-3-git-send-email-claudiu.beznea@microchip.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
SAM9X60 PMC's has a different PMC. It was not integrated at the moment
commit 01c7031cfa ("ARM: at91: pm: initial PM support for SAM9X60")
was published.
Fixes: 01c7031cfa ("ARM: at91: pm: initial PM support for SAM9X60")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/1576062248-18514-2-git-send-email-claudiu.beznea@microchip.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Currently the maximum rate for peripheral clock is calculated based on a
typical 133MHz MCK. The maximum frequency is defined in the datasheet as a
ratio to MCK. Some sama5d3 platforms are using a 166MHz MCK. Update the
device trees to match the maximum rate based on 166MHz.
Reported-by: Karl Rudbæk Olsen <karl@micro-technic.com>
Fixes: d2e8190b79 ("ARM: at91/dt: define sama5d3 clocks")
Link: https://lore.kernel.org/r/20200110172007.1253659-1-alexandre.belloni@bootlin.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
PAZ00 board has two variants of DDR2 SDRAM devices for External Memory:
one is Hynix HY5PS1G831CLFP-Y5 and the other is Micron MT47H128M8CF-25:H.
The Micron variant doesn't have official timings in the wild, hence only
timings for the Hynix are added. The memory frequency-scaling was tested
using the Tegra20 devfreq driver.
Tested-by: Marc Dietrich <marvin24@gmx.de>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The EMC hardware block needs access to the EMC clock in order to scale
the external memory frequency. Add the clocks property so that drivers
for the EMC can acquire a reference to the EMC clock.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add a fixed regulator and use it as power supply for RBG panel.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Add a fixed regulator and use it as power supply for DSI panel.
Fixes: 18c8866266 ("ARM: dts: stm32: Add display support on stm32f469-disco")
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Change non volatile node name from nvmem to efuse to be compliant
with yaml schema.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Change non volatile node name from nvmem to efuse to be compliant
with yaml schema.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Update of the mlahb node according to to DT bindings using json-schema
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Modify dma controller nodes name to fit with the standard naming.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Modify dma controller nodes name to fit with the standard naming.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Modify dma controller nodes name to fit with the standard naming.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
phy-names is required by usbotg_hs driver to get the phy, otherwise, it
considers that there is no phys property.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
This patch enables USB OTG HS on stm32mp15 dkx in Peripheral mode.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
This patch enables USB Host (USBH) EHCI controller on stm32mp15 dk boards.
As a hub is used between USBH and USB connectors, no need to enable
USBH OHCI controller: all low- and full-speed traffic is managed by the
hub.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
This patch enables USBPHYC (USB PHY Controller on stm32mp15 DKx boards.
This enables the two usbphyc usb2 ports, which require 3 supplies:
3v3, 1v1 and 1v8.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
i.MX7D is supported for either the v7-A or the v7-M cores,
but the latter causes a warning:
WARNING: unmet direct dependencies detected for ARM_ERRATA_814220
Depends on [n]: CPU_V7 [=n]
Selected by [y]:
- SOC_IMX7D [=y] && ARCH_MXC [=y] && (ARCH_MULTI_V7 [=n] || ARM_SINGLE_ARMV7M [=y])
Make the select statement conditional.
Fixes: 4562fa4c86 ("ARM: imx: Enable ARM_ERRATA_814220 for i.MX6UL and i.MX7D")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
imx6ul-14x14-evk does not have a GPIO dedicated for reading the card
detect pin on the eSDHC2 micro-SD port.
Pass the "broken-cd" property to describe the absence of the card detect
GPIO so that polling must be used.
According to Documentation/devicetree/bindings/mmc/mmc-controller.yaml:
broken-cd:
$ref: /schemas/types.yaml#/definitions/flag
description:
There is no card detection available; polling must be used.
Even though no error is oberved in the kernel, the lack of the
'broken-cd' property caused the micro-SD to not be detected in U-Boot,
so let's improve the device tree description to make it more accurate.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The vdd3p0 LDO's input should be from external USB VBUS directly, NOT
PMIC's power supply, the vdd3p0 LDO's target output voltage can be
controlled by SW, and it requires input voltage to be high enough, with
incorrect power supply assigned, if the power supply's voltage is lower
than the LDO target output voltage, it will return fail and skip the LDO
voltage adjustment, so remove the power supply assignment for vdd3p0 to
avoid such scenario.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The vdd3p0 LDO's input should be from external USB VBUS directly, NOT
PMIC's power supply, the vdd3p0 LDO's target output voltage can be
controlled by SW, and it requires input voltage to be high enough, with
incorrect power supply assigned, if the power supply's voltage is lower
than the LDO target output voltage, it will return fail and skip the LDO
voltage adjustment, so remove the power supply assignment for vdd3p0 to
avoid such scenario.
Fixes: 96a9169cf6 ("ARM: dts: imx6sll-evk: Assign corresponding power supply for vdd3p0")
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The vdd3p0 LDO's input should be from external USB VBUS directly, NOT
PMIC's power supply, the vdd3p0 LDO's target output voltage can be
controlled by SW, and it requires input voltage to be high enough, with
incorrect power supply assigned, if the power supply's voltage is lower
than the LDO target output voltage, it will return fail and skip the LDO
voltage adjustment, so remove the power supply assignment for vdd3p0 to
avoid such scenario.
Fixes: 3feea8805d ("ARM: dts: imx6sl-evk: Assign corresponding power supply for LDOs")
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The vdd3p0 LDO's input should be from external USB VBUS directly, NOT
PMIC's power supply, the vdd3p0 LDO's target output voltage can be
controlled by SW, and it requires input voltage to be high enough, with
incorrect power supply assigned, if the power supply's voltage is lower
than the LDO target output voltage, it will return fail and skip the LDO
voltage adjustment, so remove the power supply assignment for vdd3p0 to
avoid such scenario.
Fixes: 37a4bdead1 ("ARM: dts: imx6sx-sdb: Assign corresponding power supply for LDOs")
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The vdd3p0 LDO's input should be from external USB VBUS directly, NOT
PMIC's power supply, the vdd3p0 LDO's target output voltage can be
controlled by SW, and it requires input voltage to be high enough, with
incorrect power supply assigned, if the power supply's voltage is lower
than the LDO target output voltage, it will return fail and skip the LDO
voltage adjustment, so remove the power supply assignment for vdd3p0 to
avoid such scenario.
Fixes: 93385546ba ("ARM: dts: imx6qdl-sabresd: Assign corresponding power supply for LDOs")
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Add support for the VXT VL050-8048NT-C01 panel connected through
the 24 bit parallel LCDIF interface.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Joris Offouga <offougajoris@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The EDIMM STARTER KIT i.Core 1.5 MIPI Evaluation is based on
the 1.5 version of the i.Core MX6 cpu module. The 1.5 version
differs from the original one for a few details, including the
ethernet PHY interface clock provider.
With this commit, the ethernet interface works properly:
SMSC LAN8710/LAN8720 2188000.ethernet-1:00: attached PHY driver
While before using the 1.5 version, ethernet failed to startup
do to un-clocked PHY interface:
fec 2188000.ethernet eth0: could not attach to PHY
Similar fix has merged for i.Core MX6Q but missed to update for DL.
Fixes: a8039f2dd0 ("ARM: dts: imx6dl: Add Engicam i.CoreM6 1.5 Quad/Dual MIPI starter kit support")
Cc: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
LAN8720 needs a reset of every clock enable. The reset needs
to be done at device level, due the flag PHY_RST_AFTER_CLK_EN.
So, add phy-handle by creating mdio child node inside fec.
This will eventually move the phy-reset-gpio which is defined
in fec node.
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Engicam i.CoreM6 1.5 Quad/Dual MIPI dtsi is reusing fec node
from Engicam i.CoreM6 dtsi but have sampe copy of phy-reset-gpio
and phy-mode properties.
So, drop this phy reset methods from imx6qdl-icore-1.5 dsti file.
Cc: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The following warning is seen when building with W=1:
arch/arm/boot/dts/imx7s.dtsi:551.39-553.7: Warning (unique_unit_address): /soc/aips-bus@30000000/ocotp-ctrl@30350000/temp-grade@10: duplicate unit-address (also used in node /soc/aips-bus@30000000/ocotp-ctrl@30350000/speed-grade@10)
Since temp-grade and speed-grade point to the same node, replace them by
a single one to avoid the duplicate unit-address warning.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Without the onkey device it isn't possible to power off the system using
the X_PMIC_nONKEY signal which is routed to the SoM pin header.
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The CRYPTO_TFM_RES_* flags were apparently meant as a way to make the
->setkey() functions provide more information about errors. But these
flags weren't actually being used or tested, and in many cases they
weren't being set correctly anyway. So they've now been removed.
Also, if someone ever actually needs to start better distinguishing
->setkey() errors (which is somewhat unlikely, as this has been unneeded
for a long time), we'd be much better off just defining different return
values, like -EINVAL if the key is invalid for the algorithm vs.
-EKEYREJECTED if the key was rejected by a policy like "no weak keys".
That would be much simpler, less error-prone, and easier to test.
So just remove CRYPTO_TFM_RES_MASK and all the unneeded logic that
propagates these flags around.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The CRYPTO_TFM_RES_BAD_KEY_LEN flag was apparently meant as a way to
make the ->setkey() functions provide more information about errors.
However, no one actually checks for this flag, which makes it pointless.
Also, many algorithms fail to set this flag when given a bad length key.
Reviewing just the generic implementations, this is the case for
aes-fixed-time, cbcmac, echainiv, nhpoly1305, pcrypt, rfc3686, rfc4309,
rfc7539, rfc7539esp, salsa20, seqiv, and xcbc. But there are probably
many more in arch/*/crypto/ and drivers/crypto/.
Some algorithms can even set this flag when the key is the correct
length. For example, authenc and authencesn set it when the key payload
is malformed in any way (not just a bad length), the atmel-sha and ccree
drivers can set it if a memory allocation fails, and the chelsio driver
sets it for bad auth tag lengths, not just bad key lengths.
So even if someone actually wanted to start checking this flag (which
seems unlikely, since it's been unused for a long time), there would be
a lot of work needed to get it working correctly. But it would probably
be much better to go back to the drawing board and just define different
return values, like -EINVAL if the key is invalid for the algorithm vs.
-EKEYREJECTED if the key was rejected by a policy like "no weak keys".
That would be much simpler, less error-prone, and easier to test.
So just remove this flag.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The recovery mode pin is currently named 'REC_MODE_L', which is
how the signal is called in the schematics. The Chrome OS ABI
requires the pin to be named 'RECOVERY_SW_L', which is also how
it is called on all other veyron devices. Rename the pin to match
the ABI.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200108092908.1.I3afd3535b65460e79f3976e9ebfa392a0dd75e01@changeid
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Enable fimd device node which is a display controller, and add panel
node required by it.
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
The clock setup on Meson8 cannot achieve a Mali frequency of exactly
182.15MHz. The vendor driver uses "FCLK_DIV7 / 1" for this frequency,
which translates to 2550MHz / 7 / 1 = 364285714Hz.
Update the GPU operating point to that specific frequency to not confuse
myself when comparing the frequency from the .dts with the actual clock
rate on the system.
Fixes: c3ea80b613 ("ARM: dts: meson8b: add the Mali-450 MP2 GPU")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
The clock setup on Meson8 cannot achieve a Mali frequency of exactly
182.15MHz. The vendor driver uses "FCLK_DIV7 / 2" for this frequency,
which translates to 2550MHz / 7 / 2 = 182142857Hz.
Update the GPU operating point to that specific frequency to not confuse
myself when comparing the frequency from the .dts with the actual clock
rate on the system.
Fixes: 7d3f6b536e ("ARM: dts: meson8: add the Mali-450 MP6 GPU")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
The Meson8b clock controller is an evolution of the Meson8 clock
controller. The clock controller on Meson8b contains two identical mali
clock trees for glitch-free rate switching.
Use the correct compatible string to make use of the glitch free mux.
Fixes: b6db3936f2 ("ARM: dts: meson: switch the clock controller to the HHI register area")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Fixes for some badly applied patches that went in to 5.5. There is also
a fix for an incorrect i2c address.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+nHMAt9PCBDH63wBa3ZZB4FHcJ4FAl4VPf8ACgkQa3ZZB4FH
cJ6TfhAApRoZpDJ+8R+8F7e88Gw7sDJY4KpPVMUodwizX4ReCGKkAl5R8R0NC5Z3
EYWl4iXrOdcbQZjAaJnnIXSA6X7aeryLfwvw2h1hqXvIQ1mkwciaoXH1UUgPATK6
GXPJabI4ickvvfFomu6YoB6LRasoDPrkPjOQOpSvg5ySBaxUWUNnNgy5UZBJLLmL
ucujAPccKYCvXoMm6prqvBLFbODhsyBSslNOhCOXtYlXxv5KrzcglKah7sEizKRa
WFC7pgMM8k9u49BJd994I36/IQ4H3e/28CpkDUTQppShPQHhDk6ufNATcCDogkXD
95MKIFLKlMgZauthwgbQ49IVf1xU8kKiAo6SYfalu7RYAaspFQwzHuDRTDItu7NX
2tNHsJ7jUJXWo0hxN6FKre/IWoRyKdotCpGF8/W+W9RB8W78Xd9x3J6wTF0+ZyxE
Dv8KSvTkkikTxoje+oHGbzQSGCeVkt8w1whXGpys3/dNRcz8saEU0yMRvvEw3zse
VMe0ehipHLZapy3vUTm3bODky0taesV39wRZcaV0O4sOR89tkPnLdLiWkJ3BoRJZ
86p8rQoNmRhrYowqgab+HMlcU1kgk/aoPrsnSIQWzRndn1N9t8t/38yz+PGBoJJr
YBAdw/a8hmD57KSGjl23RD9TZrYDh2Hv4c3Ru+RYLXFFE+IHc04=
=JQMa
-----END PGP SIGNATURE-----
Merge tag 'aspeed-5.5-devicetree-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed into arm/fixes
ASPEED device tree fixes for 5.5
Fixes for some badly applied patches that went in to 5.5. There is also
a fix for an incorrect i2c address.
* tag 'aspeed-5.5-devicetree-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed:
ARM: dts: aspeed: rainier: Fix fan fault and presence
ARM: dts: aspeed: rainier: Remove duplicate i2c busses
ARM: dts: aspeed: tacoma: Remove duplicate flash nodes
ARM: dts: aspeed: tacoma: Remove duplicate i2c busses
ARM: dts: aspeed: tacoma: Fix fsi master node
ARM: dts: aspeed-g6: Fix FSI master location
Link: https://lore.kernel.org/r/CACPK8XcjazgORXNZBU1ECMukXG4HA8D9VeDxiSPifDk_iB7_dw@mail.gmail.com
Signed-off-by: Olof Johansson <olof@lixom.net>
With the new omap_prm driver added unconditionally, omap2 builds
fail when the reset controller subsystem is disabled:
drivers/soc/ti/omap_prm.o: In function `omap_prm_probe':
omap_prm.c:(.text+0x2d4): undefined reference to `devm_reset_controller_register'
Link: https://lore.kernel.org/r/20191216132132.3330811-1-arnd@arndb.de
Fixes: 3e99cb214f ("soc: ti: add initial PRM driver with reset control support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Selecting RESET_CONTROLLER is actually required, otherwise we
can get a link failure in the clock driver:
drivers/clk/davinci/psc.o: In function `__davinci_psc_register_clocks':
psc.c:(.text+0x9a0): undefined reference to `devm_reset_controller_register'
drivers/clk/davinci/psc-da850.o: In function `da850_psc0_init':
psc-da850.c:(.text+0x24): undefined reference to `reset_controller_add_lookup'
Link: https://lore.kernel.org/r/20191210195202.622734-1-arnd@arndb.de
Fixes: f962396ce2 ("ARM: davinci: support multiplatform build for ARM v5")
Cc: <stable@vger.kernel.org> # v5.4
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
When kernel booting, it will create a cpuid map between the logical cpus
and physical cpus. In a normal boot, the cpuid map is as below:
Physical Logical
0 ==> 0
1 ==> 1
But in kdump, there is a condition that the crash happens at the
physical cpu1, and the crash kernel will run at the physical cpu1 too,
so the cpuid map in crash kernel is as below:
Physical Logical
1 ==> 0
0 ==> 1
The functions zynq_slcr_cpu_stop/start is to stop/start the physical
cpus, the parameter cpu should be the physical cpuid. So use
cpu_logical_map to translate the logical cpuid to physical cpuid.
Or else the logical cpu0(physical cpu1) will stop itself and
the processor will hang.
Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
Tested-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Configure the clock controller to set an alternate clock for the CPU
when it receives an IRQ during LP1 (system suspend). Specifically, use
clk_m (the crystal) rather than clk_s (a 32KHz clock). Such an IRQ will
be the LP1 wake event. This reduces the amount of time taken to resume
from LP1.
NVIDIA's downstream kernel executes this code on both Tegra30 and
Tegra124, so it appears OK to make this change unconditionally.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The reshift hardware module implements the RAM re-repair process. This
module uses PLLP as an input clock during LP1 resume. The input divider
for this clock is typically set for PLLP's normal rate. During LP1
resume, PLLP is bypassed and so runs at the crystal rate, which is much
slower. Consequently, decrease the divider so that the reshift module
runs at a reasonable rate during LP1 resume.
NVIDIA's downstream kernel code only does this if not compiled for
Tegra30, so the added code is made conditional upon the chip ID.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
For a little over a year, U-Boot has configured the flow controller to
perform automatic RAM re-repair on off->on power transitions of the CPU
rail[1]. This is mandatory for correct operation of Tegra124. However,
RAM re-repair relies on certain clocks, which the kernel must enable and
leave running. PLLP is one of those clocks. This clock is shut down
during LP1 in order to save power. Enable bypass (which I believe routes
osc_div_clk, essentially the crystal clock, to the PLL output) so that
this clock signal toggles even though the PLL is not active. This is
required so that LP1 power mode (system suspend) operates correctly.
The bypass configuration must then be undone when resuming from LP1, so
that all peripheral clocks run at the expected rate. Without this, many
peripherals won't work correctly; for example, the UART baud rate would
be incorrect.
NVIDIA's downstream kernel code only does this if not compiled for
Tegra30, so the added code is made conditional upon the chip ID.
NVIDIA's downstream code makes this change conditional upon the active
CPU cluster. The upstream kernel currently doesn't support cluster
switching, so this patch doesn't test the active CPU cluster ID.
[1] 3cc7942a4ae5 ARM: tegra: implement RAM repair
Reported-by: Jonathan Hunter <jonathanh@nvidia.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
SolidRun Clearfog Pro rev 2.1 and Clearfog Base rev 1.3 added EEPROM.
Add DT node for EEPROM description in the .dtsi shared by Clearfog Pro
and Base.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Move the i2c0 controller properties to the SOM .dtsi. This is
preparation for adding an i2c device at the SOM level.
Cc: Dennis Gilmore <dennis@ausil.us>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
SolidRun Clearfog GTR L8 and S4 SBCs are based on Armada 385. They
features 8 (L8) or 4 (S4) switched Ethernet ports, 1 1Gb Ethernet port,
1 directly connected SFP port, 1 SFP port behind the switch (not
currently described in DT), 3 mini-PCIe slots, eMMC, SPI flash, USB3
port.
https://developer.solid-run.com/products/clearfog-gtr-a385/
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
The PCA9552 used for fan fault and presence information is at address
61h, not 60h.
Fixes: 2efc118ce3 ("ARM: dts: aspeed: rainier: Add i2c devices")
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>
Reviewed-by: Eddie James <eajames@linux.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
This is a revert of "ARM: dts: aspeed: rainier: Add i2c devices", which
was already applied to the tree.
Fixes: 9c44db7096 ("ARM: dts: aspeed: rainier: Add i2c devices")
Reviewed-by: Jim Wright <wrightj@linux.vnet.ibm.com>
Tested-by: Jim Wright <wrightj@linux.vnet.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
This is a revert of "ARM: dts: aspeed: tacoma: Enable FMC and SPI
devices" which was already applied as part of "ARM: dts: aspeed: Add
Tacoma machine".
Fixes: 8737481e38 ("ARM: dts: aspeed: tacoma: Enable FMC and SPI devices")
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
This is a revert of "ARM: dts: aspeed: tacoma: Enable I2C busses", which
was already applied as part of "ARM: dts: aspeed: Add Tacoma machine".
Fixes: 606bcdde67 ("ARM: dts: aspeed: tacoma: Enable I2C busses")
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
The FIS nodes were placed incorrectly in the device tree.
Fixes: 0fe4e30478 ("ARM: dts: aspeed-g6: Describe FSI masters")
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
The flash write protect pin is currently named 'FW_WP_AP', which is
how the signal is called in the schematics. The Chrome OS ABI
requires the pin to be named 'AP_FLASH_WP_L', which is also how
it is called on all other veyron devices. Rename the pin to match
the ABI.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200106135142.1.I3f99ac8399a564c88ff48ae6290cc691b47c16ae@changeid
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Fix up inconsistent usage of upper and lowercase letters in "Samsung"
and "Exynos" names.
"SAMSUNG" and "EXYNOS" are not abbreviations but regular trademarked
names. Therefore they should be written with lowercase letters starting
with capital letter.
The lowercase "Exynos" name is promoted by its manufacturer Samsung
Electronics Co., Ltd., in advertisement materials and on website.
Although advertisement materials usually use uppercase "SAMSUNG", the
lowercase version is used in all legal aspects (e.g. on Wikipedia and in
privacy/legal statements on
https://www.samsung.com/semiconductor/privacy-global/).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Fix up inconsistent usage of upper and lowercase letters in "Samsung"
and "Exynos" names.
"SAMSUNG" and "EXYNOS" are not abbreviations but regular trademarked
names. Therefore they should be written with lowercase letters starting
with capital letter.
The lowercase "Exynos" name is promoted by its manufacturer Samsung
Electronics Co., Ltd., in advertisement materials and on website.
Although advertisement materials usually use uppercase "SAMSUNG", the
lowercase version is used in all legal aspects (e.g. on Wikipedia and in
privacy/legal statements on
https://www.samsung.com/semiconductor/privacy-global/).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
We can now probe devices with ti-sysc interconnect driver and dts
data, and can continue dropping the related platform data and custom
ti,hwmods dts property for various devices.
And related to that, we finally can remove the legacy sdma support in
favor of using the dmaengine driver only. I was planning to send the
sdma changes separately, but that would have produced a pile of
pointless merge conflicts, so I decided it's best to resolve it locally.
After all, the sdma series also ends up removing the related platform
data.
Note that this series is based on omap-for-v5.6/ti-sysc-dt-signed branch
as it depends for dts data being in place.
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEkgNvrZJU/QSQYIcQG9Q+yVyrpXMFAl4UxYsRHHRvbnlAYXRv
bWlkZS5jb20ACgkQG9Q+yVyrpXM8VQ/+OThstHL8rfZYYz1Dl+FdqSYpCYTTFjIH
cZAgWdIo0ZaPkrQNnbdCm7fppToeCv7+/g4J9H7ZvGPH3bXBsE0IDwcAeFFOpx1H
ZXHdxQ15CT4rfFMirc1703hVTkcBjwNicp7GeytVeIlDA4VSHyspDeZaWAhFGOti
WQcXEOvQ5RSaYnmlsxHc5k2rUY9ajrKqEE9kq2uNkdoGUEPOOjgfSnR4uwuv6U8g
MpxjLrqx/cGGpi3EELrEkWf8V6xrLd089Q1SDwyJd54ScI1RVv5jeUpT0SezD4Va
sctAtEp80xEja//uEb3NOOqDsCHZCV4qjB/zAAFeUA98DWVbVXA+jgV/awUCIzxQ
0AjePBAiNTPrEcKB+SkGKzAYQeeyplNWjGIkIrFMtktscfVPt0TdwRebD6MM5y2f
nuSX6xT4oNUeylygwciEYfawuQFfOL9rgviVyLcQ+B2JvUogjSj83g2+RxOuEUFp
iqeleWe89nTn7W5tpSJOPIAOumJkLeV9sRhaHcbX2m7JPKktyfY107SWsueuR+MA
jeZ/gzphxHirNcZFPwfybmFxobjOEABbZazQWFyqFNDHnIbM7dQ+giATjheIeEJ6
dMfjlNGI92U0WIYP/vLoFKazwvJGcBe6lmyb+75iZ+3SsUNX+16kKmUOKZJrfyEb
twYBzP9sEUc=
=DAqN
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v5.6/ti-sysc-drop-pdata-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/dt
Drop more legacy platform data for omaps for v5.6 merge window
We can now probe devices with ti-sysc interconnect driver and dts
data, and can continue dropping the related platform data and custom
ti,hwmods dts property for various devices.
And related to that, we finally can remove the legacy sdma support in
favor of using the dmaengine driver only. I was planning to send the
sdma changes separately, but that would have produced a pile of
pointless merge conflicts, so I decided it's best to resolve it locally.
After all, the sdma series also ends up removing the related platform
data.
Note that this series is based on omap-for-v5.6/ti-sysc-dt-signed branch
as it depends for dts data being in place.
* tag 'omap-for-v5.6/ti-sysc-drop-pdata-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (56 commits)
ARM: OMAP2+: Drop legacy platform data for sdma
ARM: OMAP2+: Drop legacy init for sdma
dmaengine: ti: omap-dma: Use cpu notifier to block idle for omap2
dmaengine: ti: omap-dma: Allocate channels directly
dmaengine: ti: omap-dma: Pass sdma auxdata to driver and use it
dmaengine: ti: omap-dma: Configure global priority register directly
ARM: OMAP5: hwmod-data: remove OMAP5 IOMMU hwmod data
ARM: OMAP4: hwmod-data: remove OMAP4 IOMMU hwmod data
ARM: OMAP2+: Drop legacy platform data for omap4 fdif
ARM: OMAP2+: Drop legacy platform data for omap4 slimbus
ARM: OMAP2+: Drop legacy platform data for omap5 kbd
ARM: OMAP2+: Drop legacy platform data for omap4 kbd
ARM: OMAP2+: Drop legacy platform data for dra7 smartreflex
ARM: OMAP2+: Drop legacy platform data for omap4 smartreflex
ARM: OMAP2+: Drop legacy platform data for omap4 hsi
ARM: OMAP2+: Drop legacy platform data for am4 vpfe
ARM: OMAP2+: Drop legacy platform data for dra7 ocp2scp
ARM: OMAP2+: Drop legacy platform data for omap5 ocp2scp
ARM: OMAP2+: Drop legacy platform data for omap4 ocp2scp
ARM: OMAP2+: Drop legacy platform data for am4 ocp2scp
...
Link: https://lore.kernel.org/r/pull-1578420398-290837@atomide.com-4
Signed-off-by: Olof Johansson <olof@lixom.net>
Devicetree changes for omaps for v5.6 to configure more
devices and update boards to use generic lcd panels:
- Configure HDMI for dra76-evm and am57xx-idk
- Correct node name for am3517 mdio
- Convert am335x-evm, am335x-evmsk, and am335x-icev2 to use generic
panels
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEkgNvrZJU/QSQYIcQG9Q+yVyrpXMFAl4Uxy0RHHRvbnlAYXRv
bWlkZS5jb20ACgkQG9Q+yVyrpXMXzQ//f8Vk6+MmdsDoZMsxyv/B+wYpfkZedAJH
xY3W78xEdY4z3jXyUBNiIyCScdRoDOJ6VoZ2ZdrE0adlzlUXLMoZxxoWCKs741go
3L/QACfViEjF/0auxCY/ThHhmS2bkVtvqnypKewc3IGyNBuLkyjO5EaFNl50375t
N3ojIGbkSvv3EcgUy7K43P/MRARods2ysYMrCxY06jEZZDXDtLWnW2/Md3/vfDI9
bnKAGjWBUxfmSHSqx8cM3JDrLqoLp1G/FyNadFaTDbc/INCvS8OrJzeErYqRc/NE
Y0ZK1XSc/W4BSptCsZSBuBKFv3E9sx0rH8LVr97fNjk8DB2umnQFKliFs6/aNtXm
uqGr7goaext2bsrGC+Tf4pYSTpF+YfOr2Kheuts+FG0pRorYy9zYlmSIjYSGwJfo
a6++vvWuol9IUg+CfNYv95TV2tg8OYO0GVjKt59P96JA8qcUpI1/y2BUl6m10sDo
BnNS6VpTIVjLaJsvCUtVqHsfi4Csu1pN4xEkn+8X/qr6OhO/cZmkA4Qf71FlfUWv
fqFySm1ZKQHbENnoaCxuY3KohQLxtAFGdjE7eClk+g9yIqFbd5PQcsaLIsWNzhnw
CGHIbBTXR0TVllU1VIDnAPWI/LbsDOjgq3V2Ab1XsB1Xsyx+6GQy3lRJMl1xoVaf
BOZj8j8lSbo=
=Aprz
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v5.6/dt-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/dt
Devicetree changes for omaps for v5.6 merge window
Devicetree changes for omaps for v5.6 to configure more
devices and update boards to use generic lcd panels:
- Configure HDMI for dra76-evm and am57xx-idk
- Correct node name for am3517 mdio
- Convert am335x-evm, am335x-evmsk, and am335x-icev2 to use generic
panels
* tag 'omap-for-v5.6/dt-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: am335x-icev2: Add support for OSD9616P0899-10 at i2c0
ARM: dts: am335x-evmsk: Use drm simple-panel instead of tilcdc-panel
ARM: dts: am335x-evm: Use drm simple-panel instead of tilcdc-panel
ARM: dts: omap3: name mdio node properly
ARM: dts: am57xx-idk-common: add HDMI to the common dtsi
ARM: dts: dra76-evm: add HDMI output
Link: https://lore.kernel.org/r/pull-1578420398-290837@atomide.com-2
Signed-off-by: Olof Johansson <olof@lixom.net>
SoC related changes for omaps that mostly relate to making iommus
to start probing with ti-sysc interconnect target module driver:
- Add missing lcdc clockdomain for am43xx
- Pass auxdata for reset control driver
- Remove old pdata quirks for iommus
- Add workaround for dra7 dsp mstandby errata
- Convert iommu platform code to probe with ti-sysc
- Use sperate iommu auxdata for ipu1
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEkgNvrZJU/QSQYIcQG9Q+yVyrpXMFAl4Uwa8RHHRvbnlAYXRv
bWlkZS5jb20ACgkQG9Q+yVyrpXNafBAApp7l7dV4WFw0zGb8G7RcX7mDLpEtHRzX
EmoMHeAoJZm46r4FyXF8RoCC2cpiH/HAFMYO/Ev61VJycmgJKGYSuzQ4+7LRSwxP
3U0n5/xsrswFnWnEN2jsarKSi+UKD7AVe4hNiMSXQizXxuuCZBzCjh9RQN8IBt99
uaM2prmAzCQ+x4ukX1NyXSFfxF257IpU6BB/oDLpHjPdQUq7nJr94hdzuqwG3J8j
fOwO1emMyciQf5dTC/fBffyBEsrWYkfQXmrf10DsG1TkICN13vRUIHTO62iHgwAV
MBYVbqWS7vcfLXQV+Ai7nrsA1csE/677BKD/X+DJDt3+B0huviFt0fw8ZcCNftqx
LbfklzzNnwbgTeRSuw5i/z0l33jBtGiyjhAx5mAqxax2g8hCX2ef2zuW6rJXpjoD
JHzLxtBUWI7Ef5J5mteaISa+uTaJTqRtFLzR5b1xOkshYmt/k90HkWOlguzpW7RV
SfH4lG7mWHuZVR1c7vnhxQAuHoK4zM+F15AqHuF3W/hgYbXKvhLTSYRIzS0aNNIH
EXCo8oG/fjAcNkqfJSz9W1E+Wow6/zwz86XiRdczYSq104X3CNOC2DFT8wG2qSNO
vyNvGu/KHaMA6lVZHZNgE+54BH4VkHXeWE8wgokEj7TQFj0NGyVQ9aNxKDG9Ces0
YKssMka7HHc=
=DT9F
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v5.6/soc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/soc
SoC changes for omaps for v5.6 merge window
SoC related changes for omaps that mostly relate to making iommus
to start probing with ti-sysc interconnect target module driver:
- Add missing lcdc clockdomain for am43xx
- Pass auxdata for reset control driver
- Remove old pdata quirks for iommus
- Add workaround for dra7 dsp mstandby errata
- Convert iommu platform code to probe with ti-sysc
- Use sperate iommu auxdata for ipu1
* tag 'omap-for-v5.6/soc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
ARM: OMAP2+: omap-iommu.c conversion to ti-sysc
ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
ARM: OMAP4+: remove pdata quirks for omap4+ iommus
ARM: OMAP2+: pdata-quirks: add PRM data for reset support
ARM: OMAP2+: am43xx: Add lcdc clockdomain
Link: https://lore.kernel.org/r/pull-1578420398-290837@atomide.com
Signed-off-by: Olof Johansson <olof@lixom.net>
Here are few fixes for v5.5-rc cycle:
- Two corner case fixes related to ti-sysc driver clock issues
- Fixes for am57xx dts for pcie gpios
- Beagle-x15 regulator dts fix
- Fix for wkup_m3_ipc driver race
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEkgNvrZJU/QSQYIcQG9Q+yVyrpXMFAl4UvwkRHHRvbnlAYXRv
bWlkZS5jb20ACgkQG9Q+yVyrpXPvjRAAquZEO7h7pat9W0kyGxxI9qkhbDTLtWbA
JRDXYUDsbji1Bz64Ea9rVYSOZlQi+dtOh3WXwQ5PNhEW5tCGV3WttScC5T2IyQBN
+Ab3a6Cr9eRN9wchsYifKntOnBKQDA62Eb1FsWXf/QYrAyI4SJpaNzJSh35xASAR
Z8hErABqSws/cIQ6x3hneArzwrvA1G8FMHryGFbPxvzbwxgEsW9J8nITG3S/itwM
WMPvBCx5YM1vI6weuXRsm1k0vPuHt1UYkg9J3AsINKpScbbwf3nz6r+vVMG0Zs93
9xlbsW68COObBvujTLrCb7/B6Mbqw/1vcWVf86vJr3xLzbVpRU+doDZAlV3FqMoP
srrcVPpR+s8HIICxCiFF4aWPOrwkkKTkZN0jIPGOTrObNVqIj3Im7gHoRuhD2bAj
/5X8h5or9Mpv+4zegNFxnfR/f9qf3f1Li3rsURTI75CNJnsNAqaNKTwikA+8SsIJ
EOGaTe5vFc5k4k9TmHT/OeJCTbuIHXs3E0OjnUBmQ9degOVxo8nNBbQKXioAmWy+
uFSQwJ4fVx54PIKlwJ0agnprOfkuM1IFbT+HxwZO1WAt6zUD4Vg1Z1Dv7si+XX02
joCzgy85nq1W9ljqew7mVu2sAQpzZB0dML4iuuPZ7IXHor9mXwQXD7Tfjg87rVn8
hYm/ZKHjGQQ=
=kjYS
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v5.5/fixes-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes
Fixes for omaps for v5.5-rc cycle
Here are few fixes for v5.5-rc cycle:
- Two corner case fixes related to ti-sysc driver clock issues
- Fixes for am57xx dts for pcie gpios
- Beagle-x15 regulator dts fix
- Fix for wkup_m3_ipc driver race
* tag 'omap-for-v5.5/fixes-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
soc: ti: wkup_m3_ipc: Fix race condition with rproc_boot
ARM: dts: beagle-x15-common: Model 5V0 regulator
ARM: dts: am571x-idk: Fix gpios property to have the correct gpio number
ARM: dts: am57xx-beagle-x15/am57xx-idk: Remove "gpios" for endpoint dt nodes
bus: ti-sysc: Fix iterating over clocks
ARM: OMAP2+: Fix ti_sysc_find_one_clockdomain to check for to_clk_hw_omap
Link: https://lore.kernel.org/r/pull-1578418121-413328@atomide.com
Signed-off-by: Olof Johansson <olof@lixom.net>
This enables hardware random number generator support for the BCM2711
on the Raspberry Pi 4 board.
Signed-off-by: Stephen Brennan <stephen@brennan.io>
Acked-by: Stefan Wahren <wahrenst@gmx.net>
[nsaenzjulienne@suse.de: remove unnecessary status="okay"]
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
BCM2711 inherits from BCM283X, but has an incompatible HWRNG. Move this
node to bcm2835-common.dtsi, so that BCM2711 can define its own.
Signed-off-by: Stephen Brennan <stephen@brennan.io>
Acked-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
A few clocks from the CCU were exported later, and references to them in
the device tree were using raw numbers.
Now that the DT binding header changes are in as well, switch to the
macros for more clarity.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The Allwinner R40 SoC contains four SPI controllers, using the newer
sun6i design (but at the legacy addresses).
The controller seems to be fully compatible to the A64 one, so no driver
changes are necessary.
The first three controllers can be used on two sets of pins, but SPI3 is
only routed to one set on Port A.
Only the pin groups for SPI0 on PortC and SPI1 on PortI are added here,
because those seem to be the only one exposed on the Bananapi boards.
Tested by connecting a SPI flash to a Bananapi M2 Berry SPI0 and SPI1
header pins.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
There's a SMSC USB2640 (USB hub & SD controller) connected to it, but
the SD card slot footprint is unpopulated. Also connected to the hub is
a SMSC LAN7500 gigabit ethernet adapter.
Link: https://lore.kernel.org/r/20191220065314.237624-6-lkundrak@v3.sk
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Olof Johansson <olof@lixom.net>
There are two on MMP3, along with the PHYs. The PHYs are made compatible
with the NOP transceiver, since there's no driver for the time being and
they're likely configured by the firmware.
Link: https://lore.kernel.org/r/20191220065314.237624-5-lkundrak@v3.sk
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
- Touch screen support for the iwg20d board,
- ARM global timer support on Cortex-A9 MPCore SoCs,
- Miscellaneous fixes for issues detected by "make dtbs_check".
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCXhMEjgAKCRCKwlD9ZEnx
cBi2AP9TSGAgkm94K9MGLInjz1jX7gJuaXBThOSsZK6cbLTanAEAoLG/Fbe/vkya
DiOgp89ukA7libFJEPIvPK0Nn8PJFgQ=
=clXj
-----END PGP SIGNATURE-----
Merge tag 'renesas-arm-dt-for-v5.6-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/dt
Renesas ARM DT updates for v5.6
- Touch screen support for the iwg20d board,
- ARM global timer support on Cortex-A9 MPCore SoCs,
- Miscellaneous fixes for issues detected by "make dtbs_check".
* tag 'renesas-arm-dt-for-v5.6-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
ARM: dts: sh73a0: Add missing clock-frequency for fixed clocks
ARM: dts: r8a7778: Add missing clock-frequency for fixed clocks
ARM: dts: rcar-gen2: Add missing mmio-sram bus properties
ARM: dts: rcar-gen2: Fix PCI high address in interrupt-map-mask
ARM: dts: renesas: Group tuples in pci ranges and dma-ranges properties
ARM: dts: renesas: Group tuples in interrupt properties
ARM: dts: renesas: Group tuples in regulator-gpio states properties
ARM: dts: r8a7779: Add device node for ARM global timer
ARM: dts: sh73a0: Add device node for ARM global timer
ARM: dts: sh73a0: Rename twd clock to periph clock
ARM: dts: iwg20d-q7-common: Add LCD support
Link: https://lore.kernel.org/r/20200106104857.8361-3-geert+renesas@glider.be
Signed-off-by: Olof Johansson <olof@lixom.net>
- Enable support for the display panel on the iwg20d board.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCXhMDegAKCRCKwlD9ZEnx
cIIvAQCfEELGg/5vz7r3iemrUfIHxWq8YkfWsg5UnnMQ0f11QgD9HMfJSO4XebkY
JLsr3JV3XzkrIAGgssxpRwO2EV0BNAo=
=xQC4
-----END PGP SIGNATURE-----
Merge tag 'renesas-arm-defconfig-for-v5.6-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/defconfig
Renesas ARM defconfig updates for v5.6
- Enable support for the display panel on the iwg20d board.
* tag 'renesas-arm-defconfig-for-v5.6-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
ARM: shmobile: defconfig: Enable support for panels from EDT
ARM: shmobile: defconfig: Restore debugfs support
Link: https://lore.kernel.org/r/20200106104857.8361-2-geert+renesas@glider.be
Signed-off-by: Olof Johansson <olof@lixom.net>
This updates the gemini defconfig with Kconfig shuffling and
some of the features activated in new upstream drivers and newly
supported devices:
- Move some symbols around due to Kconfig alterations,
this affects CONFIG_PREEMPT, CONFIG_PCI, CONFIG_CMA,
CONFIG_BINFMT_MISC, CONFIG_PARTITION_ADVANCED.
- Add RedBoot partition parsing, as all the Gemini
devices use some RedBoot derivative and store their
flash partition tables in this format.
- Enable bridge and VLAN filtering: a majority of the
Gemini devices have some kind of DSA chip for ethernet
bridging/routing.
- Enable CONFIG_NET_DSA_REALTEK_SMI as this DSA router
chip is found in the Gemini-based products. This makes
explicit selection of CONFIG_REALTEK_PHY unnecessary
so that goes away.
- Enable CONFIG_TUN since Gemini userspace often make
use of the TUN interface for network services.
- Enable MARVELL_PHY as Marvell PHY connectors are often
found in Gemini systems.
- Enable basic 802.11 libraries as many Gemini systems
have wireless PCI cards.
Link: https://lore.kernel.org/r/20200101143520.14218-1-linus.walleij@linaro.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
- Proper include file for the AB8505 PMIC variant.
- Add a DTS file for the GT-I8190/Golden
- Extend the IMU, touch screen, WiFi and Bluetooth
as separate patches.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAl4D7ooACgkQQRCzN7AZ
XXPwMA//TRcj1QGi/LxF1VhZYsDH1PGbnmYdRtJ8hWQkXB52I2ss2W/tGPgfwaeL
WmpjENMpFUknNGECgHQz3DX1ZI8dfA4Ni0b3JX0/cHfW+CIlbJE8ZF0nGyXM/0iT
egw7P3GP5Bana03ovt/n5Fuzr3gBqeWAxAqEu9ANk8qHr+LKCyIO1ODTSN2qIDe3
Z1M8PfOgbH6VyiIFtOY53GGaWQDxjmvxNUzd6RrzYL/PMyz2GFmzub7lksMN/ZhK
KtoOFzzf8sSZzENSotin9CkZTJRJcrvkehMmwjZhvcsOhuc3fkGCIbv7bj9RtFHd
0KENBltod2ol3h/I3aICSo0QeS8x+lurwpP4MEUdB0i4S4IpEVx1t2xn2yp7JNZt
VGhfqgZfmS7lJS1qSK4zP+tqrvvKzycsMKa691Ws3BD2tMQKz0eOeVsU3rLHQaUt
Lfm7gTbxvIOuL5f8/n/2XJz3w8ZvcwchE+LD1UTqlrRZ8wVuLIserizsY6oAEqkR
4DycpWywJYEFpcDpkZ6a/d9wF8EZzuFHzP1EIU5zaNo+fS9ddQSu6ye8gQw2DW6m
MUas/bYRNXs2B38o8s7RNxZiM5+l+dF84BaEI9eUZQArshzFaPeEEJY8S8zP1hTm
mHSP4VS1iZxtCbLN+3yMvPz+i1WMzHnoOkuWBxpr+WOT7HhMrPs=
=h5MX
-----END PGP SIGNATURE-----
Merge tag 'ux500-armsoc-v5.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson into arm/dt
Support the Samsung GT-I8190/Golden phone:
- Proper include file for the AB8505 PMIC variant.
- Add a DTS file for the GT-I8190/Golden
- Extend the IMU, touch screen, WiFi and Bluetooth
as separate patches.
* tag 'ux500-armsoc-v5.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson:
ARM: dts: ux500: samsung-golden: Add Bluetooth
ARM: dts: ux500: samsung-golden: Add WiFi
ARM: dts: ux500: samsung-golden: Add touch screen
ARM: dts: ux500: samsung-golden: Add IMU (accelerometer + gyroscope)
ARM: dts: ux500: Add device tree for Samsung Galaxy S III mini (GT-I8190)
dt-bindings: arm: ux500: Document samsung,golden compatible
ARM: dts: ux500: Add device tree include for AB8505
ARM: dts: ux500: Remove unused ste-href-ab8505.dtsi
Link: https://lore.kernel.org/r/CACRpkdaN2Lv_rBEYNiyAarA81yea6Eky8w_htqZqdRng8S-DcA@mail.gmail.com
Signed-off-by: Olof Johansson <olof@lixom.net>
The register blocks don't occupy 4K. In fact, some blocks are packed
close to others and assuming they're 4K causes overlaps:
pxa2xx-i2c d4033800.i2c: can't request region for resource
[mem 0xd4033800-0xd40347ff]
Link: https://lore.kernel.org/r/20191220071443.247183-1-lkundrak@v3.sk
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Olof Johansson <olof@lixom.net>
This was done because the clock driver returned the wrong rate, which is
fixed in "clk: mmp2: Fix the order of timer mux parents" patch.
Link: https://lore.kernel.org/r/20191218190454.420358-2-lkundrak@v3.sk
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Olof Johansson <olof@lixom.net>
The CSI0 and CSI1 blocks are the same as found on the A20. However only
CSI0 is supported upstream right now.
Add a device node for CSI0 using the A20 compatible as a fallback, and
the standard pinctrl options. Also add the MBUS interconnect.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The CSI controller driver now supports the second CSI controller, CSI1.
Add a device node for it. Pinmuxing options for the MCLK output, the
standard 8-bit interface, and a secondary 24-bit interface are included.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The CSI controller driver now supports the second CSI controller, CSI1.
Add a device node for it. Pinmuxing options for the MCLK output, the
standard 8-bit interface, and a secondary 24-bit interface are included.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
ioremap has provided non-cached semantics by default since the Linux 2.6
days, so remove the additional ioremap_nocache interface.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Some old SoCs, while supporting LVDS, don't list the LVDS clocks and reset
lines. Let's add them when relevant.
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
tcon_tv0, tcon_tv1 nodes have a clock names of tcon-ch0,
tcon-ch1 which are referring tcon_top clocks via index
numbers like 0, 1 with CLK_TCON_TV0 and CLK_TCON_TV1
respectively.
Use the macro in place of index numbers, for more code
readability.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The ARM Cortex-A7 cores used in the Allwinner R40 SoC have their usual
Performance Monitoring Unit (PMU), which allows perf to use hardware
events.
The SoC integrator just needs to connect each per-core interrupt line
to the GIC. The R40 manual does not really mention those IRQ lines, but
experimentation in U-Boot shows that interrupts 152-155 are connected to
the four cores (similar to the A20).
Tested on a Bananapi M2 Berry, with perf and taskset to confirm the
association between cores and interrupts.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The GIC used in the R40 SoC is an ARM GIC-400 with virtualization support,
so let's advertise the full 8K region of the GICC MMIO frame to enable
KVM's usage of the GIC (as we do already for all other SoCs).
Tested by running KVM on a Bananapi M2 Berry.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
"clock-frequency" is a required property for devices nodes compatible
with "fixed-clock", leading to warnings when running
$ make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/clock/fixed-clock.yaml
arch/arm/boot/dts/sh73a0-kzm9g.dt.yaml: extcki: 'clock-frequency' is a required property
Fix this by adding the missing "clock-frequency" properties to the various
clocks, to be overridden by the board DTS files when populated.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191213162736.2160-1-geert+renesas@glider.be
"clock-frequency" is a required property for devices nodes compatible
with "fixed-clock", leading to warnings when running
$ make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/clock/fixed-clock.yaml
arch/arm/boot/dts/r8a7778-bockw.dt.yaml: audio_clk_a: 'clock-frequency' is a required property
arch/arm/boot/dts/r8a7778-bockw.dt.yaml: audio_clk_b: 'clock-frequency' is a required property
arch/arm/boot/dts/r8a7778-bockw.dt.yaml: audio_clk_c: 'clock-frequency' is a required property
Fix this by adding the missing "clock-frequency" properties to the audio
clocks, to be overridden by board DTS files when populated.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191213162712.2056-1-geert+renesas@glider.be
"#address-cells", "#size-cells", and "ranges" are required properties
for devices nodes compatible with "mmio-sram", leading to warnings when
running "make dtbs_check":
$ make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/sram/sram.yaml
arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: sram@e63a0000: '#address-cells' is a required property
arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: sram@e63a0000: '#size-cells' is a required property
arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: sram@e63a0000: 'ranges' is a required property
...
Fix this by adding the missing properties to the mmio-sram device nodes
in the DTS files for all affected R-Car Gen2 and RZ/G1 SoCs.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191213162604.1890-1-geert+renesas@glider.be
"make dtbs_check" emits warnings like:
pci@ee090000: interrupt-map-mask:0:0: 65280 is greater than the maximum of 63488
pci@ee0b0000: interrupt-map-mask:0:0: 65280 is greater than the maximum of 63488
pci@ee0d0000: interrupt-map-mask:0:0: 65280 is greater than the maximum of 63488
According to dt-schemas/schemas/pci/pci-bus.yaml, the PCI high address
cell value in the "interrupt-map-mask" property must lie in the range
0..0xf800.
Fix this by correcting the values from 0xff00 to 0xf800 in all affected
R-Car Gen2 and RZ/G1 DTS files.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191213162459.1731-1-geert+renesas@glider.be
Current USB3503 driver ignores GPIO polarity and always operates as if the
GPIO lines were flagged as ACTIVE_HIGH. Fix the polarity for the existing
USB3503 chip applications to match the chip specification and common
convention for naming the pins. The only pin, which has to be ACTIVE_LOW
is the reset pin. The remaining are ACTIVE_HIGH. This change allows later
to fix the USB3503 driver to properly use generic GPIO bindings and read
polarity from DT.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20191211145208.24976-1-m.szyprowski@samsung.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Vinod Koul <vkoul@kernel.org>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now drop legacy init for sdma as we pass the quirks in auxdata to
the dmaengine driver.
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Vinod Koul <vkoul@kernel.org>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
For omap2, we need to block idle if SDMA is busy. Let's do this with a
cpu notifier and remove the custom call.
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Vinod Koul <vkoul@kernel.org>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now start passing sdma auxdata to the dmaengine driver to start
removing the platform based sdma init.
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Vinod Koul <vkoul@kernel.org>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can move the global priority register configuration to the dmaengine
driver and configure it based on the of_device_id match data.
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Vinod Koul <vkoul@kernel.org>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Currently only the drivers/pinctrl/devicetree.c code allows registering
pinctrl-mappings which may later be unregistered, all other mappings
are assumed to be permanent.
Non-dt platforms may also want to register pinctrl mappings from code which
is build as a module, which requires being able to unregister the mapping
when the module is unloaded to avoid dangling pointers.
To allow unregistering the mappings the devicetree code uses 2 internal
functions: pinctrl_register_map and pinctrl_unregister_map.
pinctrl_register_map allows the devicetree code to tell the core to
not memdup the mappings as it retains ownership of them and
pinctrl_unregister_map does the unregistering, note this only works
when the mappings where not memdupped.
The only code relying on the memdup/shallow-copy done by
pinctrl_register_mappings is arch/arm/mach-u300/core.c this commit
replaces the __initdata with const, so that the shallow-copy is no
longer necessary.
After that we can get rid of the internal pinctrl_unregister_map function
and just use pinctrl_register_mappings directly everywhere.
This commit also renames pinctrl_unregister_map to
pinctrl_unregister_mappings so that its naming matches its
pinctrl_register_mappings counter-part and exports it.
Together these 2 changes will allow non-dt platform code to
register pinctrl-mappings from modules without breaking things on
module unload (as they can now unregister the mapping on unload).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20191216205122.1850923-2-hdegoede@redhat.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch removes all instances of IRQ_TYPE_NONE, which fixes warning
messages during boot. It also changes interrupt types to their
corresponding macros, as defined in arm-gic.h.
Signed-off by: Victhor Foster <victhor.foster@ufpe.br>
Link: https://lore.kernel.org/r/1238987932.9511963.1577060836760.JavaMail.zimbra@ufpe.br
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
This patch changes the tsens peripheral definition to the new style,
which fixes a kernel panic caused by a change in the tsens driver,
introduced by commit 37624b5854. There
was a patch submitted recently to this list that should fix this problem
with old device trees and the new driver, so it may be redundant at this
point, in terms of fixing the kernel panic, but this should align the
APQ8084 device tree with the others.
Signed-off by: Victhor Foster <victhor.foster@ufpe.br>
Link: https://lore.kernel.org/r/108381142.9510389.1577057823350.JavaMail.zimbra@ufpe.br
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Daniel Borkmann says:
====================
pull-request: bpf-next 2019-12-27
The following pull-request contains BPF updates for your *net-next* tree.
We've added 127 non-merge commits during the last 17 day(s) which contain
a total of 110 files changed, 6901 insertions(+), 2721 deletions(-).
There are three merge conflicts. Conflicts and resolution looks as follows:
1) Merge conflict in net/bpf/test_run.c:
There was a tree-wide cleanup c593642c8b ("treewide: Use sizeof_field() macro")
which gets in the way with b590cb5f80 ("bpf: Switch to offsetofend in
BPF_PROG_TEST_RUN"):
<<<<<<< HEAD
if (!range_is_zero(__skb, offsetof(struct __sk_buff, priority) +
sizeof_field(struct __sk_buff, priority),
=======
if (!range_is_zero(__skb, offsetofend(struct __sk_buff, priority),
>>>>>>> 7c8dce4b16
There are a few occasions that look similar to this. Always take the chunk with
offsetofend(). Note that there is one where the fields differ in here:
<<<<<<< HEAD
if (!range_is_zero(__skb, offsetof(struct __sk_buff, tstamp) +
sizeof_field(struct __sk_buff, tstamp),
=======
if (!range_is_zero(__skb, offsetofend(struct __sk_buff, gso_segs),
>>>>>>> 7c8dce4b16
Just take the one with offsetofend() /and/ gso_segs. Latter is correct due to
850a88cc40 ("bpf: Expose __sk_buff wire_len/gso_segs to BPF_PROG_TEST_RUN").
2) Merge conflict in arch/riscv/net/bpf_jit_comp.c:
(I'm keeping Bjorn in Cc here for a double-check in case I got it wrong.)
<<<<<<< HEAD
if (is_13b_check(off, insn))
return -1;
emit(rv_blt(tcc, RV_REG_ZERO, off >> 1), ctx);
=======
emit_branch(BPF_JSLT, RV_REG_T1, RV_REG_ZERO, off, ctx);
>>>>>>> 7c8dce4b16
Result should look like:
emit_branch(BPF_JSLT, tcc, RV_REG_ZERO, off, ctx);
3) Merge conflict in arch/riscv/include/asm/pgtable.h:
<<<<<<< HEAD
=======
#define VMALLOC_SIZE (KERN_VIRT_SIZE >> 1)
#define VMALLOC_END (PAGE_OFFSET - 1)
#define VMALLOC_START (PAGE_OFFSET - VMALLOC_SIZE)
#define BPF_JIT_REGION_SIZE (SZ_128M)
#define BPF_JIT_REGION_START (PAGE_OFFSET - BPF_JIT_REGION_SIZE)
#define BPF_JIT_REGION_END (VMALLOC_END)
/*
* Roughly size the vmemmap space to be large enough to fit enough
* struct pages to map half the virtual address space. Then
* position vmemmap directly below the VMALLOC region.
*/
#define VMEMMAP_SHIFT \
(CONFIG_VA_BITS - PAGE_SHIFT - 1 + STRUCT_PAGE_MAX_SHIFT)
#define VMEMMAP_SIZE BIT(VMEMMAP_SHIFT)
#define VMEMMAP_END (VMALLOC_START - 1)
#define VMEMMAP_START (VMALLOC_START - VMEMMAP_SIZE)
#define vmemmap ((struct page *)VMEMMAP_START)
>>>>>>> 7c8dce4b16
Only take the BPF_* defines from there and move them higher up in the
same file. Remove the rest from the chunk. The VMALLOC_* etc defines
got moved via 01f52e16b8 ("riscv: define vmemmap before pfn_to_page
calls"). Result:
[...]
#define __S101 PAGE_READ_EXEC
#define __S110 PAGE_SHARED_EXEC
#define __S111 PAGE_SHARED_EXEC
#define VMALLOC_SIZE (KERN_VIRT_SIZE >> 1)
#define VMALLOC_END (PAGE_OFFSET - 1)
#define VMALLOC_START (PAGE_OFFSET - VMALLOC_SIZE)
#define BPF_JIT_REGION_SIZE (SZ_128M)
#define BPF_JIT_REGION_START (PAGE_OFFSET - BPF_JIT_REGION_SIZE)
#define BPF_JIT_REGION_END (VMALLOC_END)
/*
* Roughly size the vmemmap space to be large enough to fit enough
* struct pages to map half the virtual address space. Then
* position vmemmap directly below the VMALLOC region.
*/
#define VMEMMAP_SHIFT \
(CONFIG_VA_BITS - PAGE_SHIFT - 1 + STRUCT_PAGE_MAX_SHIFT)
#define VMEMMAP_SIZE BIT(VMEMMAP_SHIFT)
#define VMEMMAP_END (VMALLOC_START - 1)
#define VMEMMAP_START (VMALLOC_START - VMEMMAP_SIZE)
[...]
Let me know if there are any other issues.
Anyway, the main changes are:
1) Extend bpftool to produce a struct (aka "skeleton") tailored and specific
to a provided BPF object file. This provides an alternative, simplified API
compared to standard libbpf interaction. Also, add libbpf extern variable
resolution for .kconfig section to import Kconfig data, from Andrii Nakryiko.
2) Add BPF dispatcher for XDP which is a mechanism to avoid indirect calls by
generating a branch funnel as discussed back in bpfconf'19 at LSF/MM. Also,
add various BPF riscv JIT improvements, from Björn Töpel.
3) Extend bpftool to allow matching BPF programs and maps by name,
from Paul Chaignon.
4) Support for replacing cgroup BPF programs attached with BPF_F_ALLOW_MULTI
flag for allowing updates without service interruption, from Andrey Ignatov.
5) Cleanup and simplification of ring access functions for AF_XDP with a
bonus of 0-5% performance improvement, from Magnus Karlsson.
6) Enable BPF JITs for x86-64 and arm64 by default. Also, final version of
audit support for BPF, from Daniel Borkmann and latter with Jiri Olsa.
7) Move and extend test_select_reuseport into BPF program tests under
BPF selftests, from Jakub Sitnicki.
8) Various BPF sample improvements for xdpsock for customizing parameters
to set up and benchmark AF_XDP, from Jay Jayatheerthan.
9) Improve libbpf to provide a ulimit hint on permission denied errors.
Also change XDP sample programs to attach in driver mode by default,
from Toke Høiland-Jørgensen.
10) Extend BPF test infrastructure to allow changing skb mark from tc BPF
programs, from Nikita V. Shirokov.
11) Optimize prologue code sequence in BPF arm32 JIT, from Russell King.
12) Fix xdp_redirect_cpu BPF sample to manually attach to tracepoints after
libbpf conversion, from Jesper Dangaard Brouer.
13) Minor misc improvements from various others.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
BCM7211 uses a PL011 UART and is supported using ARCH_BRCMSTB, make sure
that we can enable that driver by selecting ARM_AMBA.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
The Libre Computer ALL-H3-IT board is a small single board computer that
is roughly the same size as the Raspberry Pi Zero, or around 20% smaller
than a credit card.
The board features:
- H2, H3, or H5 SoC from Allwinner
- 2 DDR3 DRAM chips
- Realtek RTL8821CU based WiFi module
- 128 Mbit SPI-NOR flash
- micro-SD card slot
- micro HDMI video output
- FPC connector for camera sensor module
- generic Raspberri-Pi style 40 pin GPIO header
- additional pin headers for extra USB host ports, ananlog audio and
IR receiver
Only H5 variant test samples were made available, but the vendor does
have plans to include at least an H3 variant. Thus the device tree is
split much like the ALL-H3-CC, with a common dtsi file for the board
design, and separate dts files including the common board file and the
SoC dtsi file. The other variants will be added as they are made
available.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
There is just one sensor for the CPU.
Signed-off-by: Ondrej Jirman <megous@megous.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
There are three sensors, two for each CPU cluster, one for GPU.
Signed-off-by: Ondrej Jirman <megous@megous.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
samsung-golden uses a BCM4334 WiFi+BT combo chip.
The BT part is connected via UART and supported by the hci_bcm
driver in mainline.
Add the necessary device tree changes to make it load correctly.
It requires (seemingly) device-specific firmware that can be
extracted from the stock Android system used on samsung-golden:
- /system/bin/bcm4334.hcd -> /lib/firmware/brcm/BCM4334B0.hcd
On my device, scanning for other Bluetooth devices works just fine,
but for some reason it keeps disconnecting immediately
when attempting to connect to an other device.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20191219202052.19039-9-stephan@gerhold.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
samsung-golden uses a BCM4334 WiFi+BT combo chip, connected to SDIO.
It is supported by the brcmfmac driver in mainline,
so we only need to set up the device tree to make it work correctly.
Note: brcmfmac requires (proprietary) firmware + a device-specific
NVRAM file. Both can be extracted from the stock Android system
used on samsung-golden:
- /system/etc/wifi/bcmdhd_sta.bin_b2 -> /lib/firmware/brcm/brcmfmac4334-sdio.bin
- /system/etc/wifi/nvram_net.txt_GPIO4 -> /lib/firmware/brcm/brcmfmac4334-sdio.samsung,golden.txt
brcmfmac4334-sdio.bin from linux-firmware also seems to work,
but results in occasional errors for some reason.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20191219202052.19039-8-stephan@gerhold.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
samsung-golden has an Atmel mXT224S touch controller connected to I2C.
It is supported by the existing driver for atmel,maxtouch, so all we
need to do to make it work is to define the necessary device tree nodes.
The atmel_mxt_ts driver does not support controlling regulators yet,
so add regulator-always-on for now to turn on the necessary regulators.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20191219202052.19039-7-stephan@gerhold.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
samsung-golden has a InvenSense MPU-6051M IMU that provides an
accelerometer and gyroscope. It seems to be functionally compatible
with MPU-6050 so we can easily enable it by adding the necessary
device tree nodes.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20191219202052.19039-6-stephan@gerhold.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Samsung Galaxy S III mini (GT-I8190) is a smartphone with Ux500 SoC
released in 2012. Thanks to the great mainline support for Ux500,
it can actually run mainline Linux quite well.
Add a new device tree for it with support for:
- Internal Storage (eMMC)
- External Storage (Micro SD card)
- UART
- GPIO Buttons
- Vibrator
Note that the device tree cannot be booted directly with
the original (Samsung) bootloader. It keeps the L2 cache turned on,
which causes the kernel to hang shortly after decompression.
As a workaround I have created a port of (mainline) U-Boot,
which locks the L2 cache before booting Linux. At the moment it does not
replace the Samsung bootloader, instead we let the original bootloader
load U-Boot as an another (intermediate) bootloader.
Another advantage of this is that U-Boot has proper device tree support,
so we do not need to hardcode the kernel command line in the device tree.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20191219202052.19039-5-stephan@gerhold.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
AB8505 is a slightly newer version of AB8500.
Overall it is quite similar, but there are some differences like
the number of GPIOs and regulators. Therefore we need a separate
device tree definition for devices making use of AB8505.
The AB8500-specific nodes were moved out of ste-dbx5x0.dtsi in
commit a46f7c6762 ("ARM: dts: ux500: Move ab8500 nodes to ste-ab8500.dtsi").
Add a new "ste-ab8505.dtsi" device tree include in a similar way.
Keep the battery/charging related sub-devices disabled by default
since they require additional configuration to work correctly.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20191219202052.19039-3-stephan@gerhold.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The pin configuration for HREF boards with AB8505 was added in
commit 77ad9dfc2c ("ARM: ux500: move last AB8505 set-up to DT").
As the commit message notes, it was unused back then and it has
remained so even today, especially considering AB8505 did not have
proper device tree support until recently.
We are now preparing to add support for some Samsung smartphones
that are using AB8505. However, they use different pin configs
because using ste-href-ab8505.dtsi is known to break UART.
There were not many HREFs with AB8505, so at this point it seems
unlikely that we will ever make use of this include. Remove it.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20191219202052.19039-2-stephan@gerhold.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The macros efi_call_early and efi_call_runtime are used to call EFI
boot services and runtime services, respectively. However, the naming
is confusing, given that the early vs runtime distinction may suggest
that these are used for calling the same set of services either early
or late (== at runtime), while in reality, the sets of services they
can be used with are completely disjoint, and efi_call_runtime is also
only usable in 'early' code.
So do a global sweep to replace all occurrences with efi_bs_call or
efi_rt_call, respectively, where BS and RT match the idiom used by
the UEFI spec to refer to boot time or runtime services.
While at it, use 'func' as the macro parameter name for the function
pointers, which is less likely to collide and cause weird build errors.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Borislav Petkov <bp@alien8.de>
Cc: James Morse <james.morse@arm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191224151025.32482-24-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
None of the definitions of the efi_table_attr() still refer to
their 'table' argument so let's get rid of it entirely.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Borislav Petkov <bp@alien8.de>
Cc: James Morse <james.morse@arm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191224151025.32482-23-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
After refactoring the mixed mode support code, efi_call_proto()
no longer uses its protocol argument in any of its implementation,
so let's remove it altogether.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Borislav Petkov <bp@alien8.de>
Cc: James Morse <james.morse@arm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191224151025.32482-22-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
We have a helper efi_system_table() that gives us the address of the
EFI system table in memory, so there is no longer point in passing
it around from each function to the next.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Borislav Petkov <bp@alien8.de>
Cc: James Morse <james.morse@arm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191224151025.32482-20-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The efi_call macros on ARM have a dependency on a variable 'sys_table_arg'
existing in the scope of the macro instantiation. Since this variable
always points to the same data structure, let's create a global getter
for it and use that instead.
Note that the use of a global variable with external linkage is avoided,
given the problems we had in the past with early processing of the GOT
tables.
While at it, drop the redundant casts in the efi_table_attr and
efi_call_proto macros.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Borislav Petkov <bp@alien8.de>
Cc: James Morse <james.morse@arm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191224151025.32482-16-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Currently, we support mixed mode by casting all boot time firmware
calls to 64-bit explicitly on native 64-bit systems, and to 32-bit
on 32-bit systems or 64-bit systems running with 32-bit firmware.
Due to this explicit awareness of the bitness in the code, we do a
lot of casting even on generic code that is shared with other
architectures, where mixed mode does not even exist. This casting
leads to loss of coverage of type checking by the compiler, which
we should try to avoid.
So instead of distinguishing between 32-bit vs 64-bit, distinguish
between native vs mixed, and limit all the nasty casting and
pointer mangling to the code that actually deals with mixed mode.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Borislav Petkov <bp@alien8.de>
Cc: James Morse <james.morse@arm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191224151025.32482-10-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The macro __efi_call_early() is defined by various architectures but
never used. Let's get rid of it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Borislav Petkov <bp@alien8.de>
Cc: James Morse <james.morse@arm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191224151025.32482-6-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The SGTL5000 VDDIO is connected to the PMIC SW2 output, not to
a fixed 3V3 rail. Describe this correctly in the DT.
Fixes: 52c7a088ba ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM and PDK2")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Ludwig Zenz <lzenz@dh-electronics.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
To: linux-arm-kernel@lists.infradead.org
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
According to arm cpus binding doc,
"
On 32-bit ARM v7 or later systems this property is
required and matches the CPU MPIDR[23:0] register
bits.
Bits [23:0] in the reg cell must be set to
bits [23:0] in MPIDR.
All other bits in the reg cell must be set to 0.
"
In i.MX7ULP, the MPIDR[23:0] is 0xf00, not 0, so fix it.
Otherwise there will be warning:
"DT missing boot CPU MPIDR[23:0], fall back to default cpu_logical_map"
Fixes: 20434dc92c ("ARM: dts: imx: add common imx7ulp dtsi support")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Some boards like imx51-babbage, imx53-cx9020 and imx6q-utilite-pro
have a TFP410 DVI bridge chip.
Select its driver by default.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
imx51-babbage has a TFP410 chip that receives 24-bit RGB parallel
input and convert it to DVI.
Fix the device tree description to reflect the real hardware.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Mux the HDMI CEC pin to make HDMI CEC working. With this change HDMI CEC
seems to work fine on a Apalis iMX6 on Ixora using cec-ctl.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The only correct and documented compatible string for the rv3029 is
microcrystal,rv3029. Fix it up.
Fixes: 52c7a088ba ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM and PDK2")
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Enable NFS_V4_1 and NFS_V4_2 to support NFS servers providing that
protocol.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
While the EPDC is optional, both consumer and industrial editions
have the PXP module, so adding it to the corresponding .dtsi
Information taken from freescale kernel, compared with the
reference manual and tested by a separate program.
Since it does not depend on external wiring, the
status = "disabled" is left out here.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Carrier board often referred as baseboard. For making
complete SBC or any other industrial boards, these
carrier boards will be used with associated SOMs.
Radxa has Dalang carrier board which supports on-board
peripherals, ports like USB-2.0, USB-3.0, HDMI, MIPI DSI/CSI,
eDP, Ethernet, WiFi, PCIe, USB-C, 40-Pin GPIO header and etc.
Right now Dalang carrier board is used with two SBC-variants:
Rock Pi N10 => VMARC RK3399Por SOM + Dalang carrier board
Rock Pi N8 => VMARC RK3288 SOM + Dalang carrier board(+codec)
So add this carrier board dtsi as a separate file in
ARM directory, so-that the same can reuse it in both
rk3288, rk3399pro variants of Rockchip SOMs.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Link: https://lore.kernel.org/r/20191216174711.17856-4-jagan@amarulasolutions.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
7216 has the same memory map as 7278 and the same physical address for
the UART, alias the definition accordingly.
Signed-off-by: Justin Chen <justinpopo6@gmail.com>
[florian: expand commit message]
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Split the existing Kizbox Mini boards into three board configuration,
the base board, the mother board and the RailDIN board.
Add a new dts file for the SmartKiz board support.
Signed-off-by: Kévin RAYMOND <k.raymond@overkiz.com>
Signed-off-by: Mickael GARDET <m.gardet@overkiz.com>
Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
Link: https://lore.kernel.org/r/20191220103835.160154-2-kamel.bouhara@bootlin.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
To improve human readability and enable automatic validation, the tuples
in the "ranges" and "dma-ranges" properties of PCI devices nodes should
be grouped. Not doing so causes "make dtbs_check" to emit warnings
like:
pcie@fe000000: dma-ranges: [[1107296256, 0, 1073741824, 0, 1073741824, 0, 2147483648, 1124073472, 2, 0, 2, 0, 1, 0]] is not valid under any of the given schemas (Possible causes of the failure):
pcie@fe000000: dma-ranges: [[1107296256, 0, 1073741824, 0, 1073741824, 0, 2147483648, 1124073472, 2, 0, 2, 0, 1, 0]] is not of type 'boolean'
pcie@fe000000: dma-ranges:0: [1107296256, 0, 1073741824, 0, 1073741824, 0, 2147483648, 1124073472, 2, 0, 2, 0, 1, 0] is too long
Fix this by grouping the tuples of the "ranges" and "dma-ranges"
properties using angle brackets.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191213164115.3697-5-geert+renesas@glider.be
Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
To improve human readability and enable automatic validation, the tuples
in the various properties containing interrupt specifiers should be
grouped. While "make dtbs_check" does not impose this yet for the
"interrupts" property, it does for the "interrupt-map" property, leading
to warnings like:
pci@ee090000: interrupt-map:0: [0, 0, 0, 1, 5, 0, 108, 4, 2048, 0, 0, 1, 5, 0, 108, 4, 4096, 0, 0, 2, 5, 0, 108, 4] is too long
pci@ee0d0000: interrupt-map:0: [0, 0, 0, 1, 5, 0, 113, 4, 2048, 0, 0, 1, 5, 0, 113, 4, 4096, 0, 0, 2, 5, 0, 113, 4] is too long
Fix this by grouping the tuples of the "interrupts" and "interrupt-map"
properties using angle brackets.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191213164115.3697-4-geert+renesas@glider.be
Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
To improve human readability and enable automatic validation, the tuples
in the "states" properties of device nodes compatible with
"regulator-gpio" should be grouped, as reported by "make dtbs_check":
$ make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/regulator/gpio-regulator.yaml
arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi0: states:0: Additional items are not allowed (1800000, 0 were unexpected)
arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi0: states:0: [3300000, 1, 1800000, 0] is too long
arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi1: states:0: Additional items are not allowed (1800000, 0 were unexpected)
arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi1: states:0: [3300000, 1, 1800000, 0] is too long
arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi2: states:0: Additional items are not allowed (1800000, 0 were unexpected)
arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi2: states:0: [3300000, 1, 1800000, 0] is too long
...
Fix this by grouping the tuples using angle brackets.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191213164115.3697-2-geert+renesas@glider.be
Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
Add a device node for the global timer, which is part of the Cortex-A9
MPCore.
The global timer can serve as an accurate (4 ns) clock source for
scheduling and delay loops.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191211135222.26770-4-geert+renesas@glider.be
Add a device node for the global timer, which is part of the Cortex-A9
MPCore.
The global timer can serve as an accurate (3 ns) clock source for
scheduling and delay loops.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191211135222.26770-3-geert+renesas@glider.be
The "TWD" clock is actually the Cortex-A9 MPCore "PERIPHCLK" clock,
which not only clocks the private timers and watchdogs (TWD), but also
the interrupt controller and global timer.
Hence rename it from "twd" to "periph".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191211135222.26770-2-geert+renesas@glider.be
The MMC configuration clock controller in the A80 definition has a
clock-names and reset-names property, even though the binding for that
controller doesn't declare it.
Remove it.
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Even though it translates to the same thing down to the binary level, we
should have an array of 2 number cells to describe each voltage state,
which in turns create a validation warning.
Let's fix this.
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The TCON binding mandates a dmas phandle to the DMAengine channel used for
that controller. However, since it's not used in the driver, some device
trees have been missing it. Let's add it.
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The V3s mixer node has an assigned clocks property, while the driver also
enforces it.
Since assigned-clocks is pretty fragile anyway, let's just remove it.
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
While this is functional, it's a best practice to always have the clocks
and reset lines in order, in case we ever need to have compatibility code.
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Hardkernel's Odroid XU3/XU4/HC1 boards use bootloader, which configures
top PLLs to the following values: MPLL: 532MHz, CPLL: 666MHz and DPLL:
600MHz.
Adjust all bus related OPPs to the values that are possible to derive
from the top PLL configured by the bootloader. Also add a comment for
each bus describing which PLL is used for it.
The most significant change is the highest rate for wcore bus. It has
been increased to 532MHz as this is the value configured initially by
the bootloader. Also the voltage for this OPP is changed to match the
value set by the bootloader.
This patch finally allows the buses to operate on the rates matching the
values set for each OPP and fixes the following warnings observed on
boot:
exynos-bus: new bus device registered: soc:bus_wcore ( 84000 KHz ~ 400000 KHz)
exynos-bus: new bus device registered: soc:bus_noc ( 67000 KHz ~ 100000 KHz)
exynos-bus: new bus device registered: soc:bus_fsys_apb (100000 KHz ~ 200000 KHz)
...
exynos-bus soc:bus_wcore: dev_pm_opp_set_rate: failed to find current OPP for freq 532000000 (-34)
exynos-bus soc:bus_noc: dev_pm_opp_set_rate: failed to find current OPP for freq 111000000 (-34)
exynos-bus soc:bus_fsys_apb: dev_pm_opp_set_rate: failed to find current OPP for freq 222000000 (-34)
The problem with setting incorrect (in some cases much lower) clock rate
for the defined OPP were there from the beginning, but went unnoticed
because the only way to observe it was to manually check the rate of the
respective clocks. The commit 4294a779bd ("PM / devfreq: exynos-bus:
Convert to use dev_pm_opp_set_rate()") finally revealed it, because it
enabled use of the generic code from the OPP framework, which issues the
above mentioned warnings.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Currently the only Exynos5422-based boards that support bus frequency
scaling are Hardkernel's Odroid XU3/XU4/HC1. Move the bus related OPPs
to the boards DTS, because those OPPs heavily depend on the clock
topology and top PLL rates, which are being configured by the board's
bootloader.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
This patch is to build the coresight topology structure of zynq-7000
series according to the docs of coresight and userguide of zynq-7000.
Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com>
Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
On am57xx-beagle-x15, 5V0 is connected to P16, P17, P18 and P19
connectors. On am57xx-evm, 5V0 regulator is used to get 3V6 regulator
which is connected to the COMQ port. Model 5V0 regulator here in order
for it to be used in am57xx-evm to model 3V6 regulator.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This activates the device tree-based cpufreq driver that
Ux500 is using and enables the schedutil and ondemand
governors with schedutil as default. This works fine in
the setups I have tested.
Link: https://lore.kernel.org/r/20191217202648.23206-1-linus.walleij@linaro.org
Cc: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
commit d23f3839fe ("ARM: dts: DRA7: Add pcie1 dt node for
EP mode") while adding the dt node for EP mode for DRA7 platform,
added rc node for am571x-idk and populated gpios property with
"gpio3 23". However the GPIO_PCIE_SWRST line is actually connected
to "gpio5 18". Fix it here. (The patch adding "gpio3 23" was tested
with another am57x board in EP mode which doesn't rely on reset from
host).
Cc: stable <stable@vger.kernel.org> # 4.14+
Fixes: d23f3839fe ("ARM: dts: DRA7: Add pcie1 dt node for EP mode")
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
PERST# line in the PCIE connector is driven by the host mode and not
EP mode. The gpios property here is used for driving the PERST# line.
Remove gpios property from all endpoint device tree nodes.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The IPU1 MMU has been using common IOMMU pdata quirks defined and
used by all IPU IOMMU devices on OMAP4 and beyond. Separate out the
pdata for IPU1 MMU with the additional .set_pwrdm_constraint ops
plugged in, so that the IPU1 power domain can be restricted to ON
state during the boot and active period of the IPU1 remote processor.
This eliminates the pre-conditions for the IPU1 boot issue as
described in commit afe518400bdb ("iommu/omap: fix boot issue on
remoteprocs with AMMU/Unicache").
NOTE:
1. RET is not a valid target power domain state on DRA7 platforms,
and IPU power domain is normally programmed for OFF. The IPU1
still fails to boot though, and an unclearable l3_noc error is
thrown currently on 4.14 kernel without this fix. This behavior
is slightly different from previous 4.9 LTS kernel.
2. The fix is currently applied only to IPU1 on DRA7xx SoC, as the
other affected processors on OMAP4/OMAP5/DRA7 are in domains
that are not entering RET. IPU2 on DRA7 is in CORE power domain
which is only programmed for ON power state. The fix can be easily
scaled if these domains do hit RET in the future.
3. The issue was not seen on current DRA7 platforms if any of the
DSP remote processors were booted and using one of the GPTimers
5, 6, 7 or 8 on previous 4.9 LTS kernel. This was due to the
errata fix for i874 implemented in commit 1cbabcb980 ("ARM:
DRA7: clockdomain: Implement timer workaround for errata i874")
which keeps the IPU1 power domain from entering RET when the
timers are active. But the timer workaround did not make any
difference on 4.14 kernel, and an l3_noc error was seen still
without this fix.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Convert omap2 iommu platform code to use ti-sysc instead of legacy
omap-device / hwmod interfaces.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Errata Title:
i879: DSP MStandby requires CD_EMU in SW_WKUP
Description:
The DSP requires the internal emulation clock to be actively toggling
in order to successfully enter a low power mode via execution of the
IDLE instruction and PRCM MStandby/Idle handshake. This assumes that
other prerequisites and software sequence are followed.
Workaround:
The emulation clock to the DSP is free-running anytime CCS is connected
via JTAG debugger to the DSP subsystem or when the CD_EMU clock domain
is set in SW_WKUP mode. The CD_EMU domain can be set in SW_WKUP mode
via the CM_EMU_CLKSTCTRL [1:0]CLKTRCTRL field.
Implementation:
This patch implements this workaround by denying the HW_AUTO mode
for the EMU clockdomain during the power-up of any DSP processor
and re-enabling the HW_AUTO mode during the shutdown of the last
DSP processor (actually done during the enabling and disabling of
the respective DSP MDMA MMUs). Reference counting has to be used to
manage the independent sequencing between the multiple DSP processors.
This switching is done at runtime rather than a static clockdomain
flags value to meet the target power domain state for the EMU power
domain during suspend.
Note that the DSP MStandby behavior is not consistent across all
boards prior to this fix. Please see commit 45f871eec6c0 ("ARM:
OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs") for
details.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
IOMMU driver will be using ti-sysc bus driver for power management control
going forward, and the pdata quirks are not needed for anything anymore.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The parent clockdomain for reset must be in force wakeup mode, otherwise
the reset may never complete. Add pdata quirks for this purpose for PRM
driver.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
IOMMUs are now supported via ti-sysc, so the legacy hwmod data can be
removed.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
IOMMUs are now supported via ti-sysc, so the legacy hwmod data can be
removed.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Convert omap5 IOMMUs to use ti-sysc instead of legacy omap-hwmod based
implementation. Enable the IOMMUs also while doing this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Convert omap4 IOMMUs to use ti-sysc instead of legacy omap-hwmod based
implementation. Enable the IOMMUs also while doing this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Convert dra74x IOMMUs to use ti-sysc instead of legacy omap-hwmod based
implementation. Enable the IOMMUs also while doing this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Convert dra7 IOMMUs to use ti-sysc instead of legacy omap-hwmod based
implementation. Enable the IOMMUs also while doing this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Sebastian Reichel <sre@kernel.org>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Benoit Parrot <bparrot@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Bin Liu <b-liu@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Jyri Sarha <jsarha@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Franklin S Cooper Jr <fcooper@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Franklin S Cooper Jr <fcooper@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Franklin S Cooper Jr <fcooper@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Andrew F. Davis <afd@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Vignesh R <vigneshr@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Andrew F. Davis <afd@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Vignesh R <vigneshr@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Vignesh R <vigneshr@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Suman Anna <s-anna@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Suman Anna <s-anna@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Suman Anna <s-anna@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Suman Anna <s-anna@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Franklin S Cooper Jr <fcooper@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Vignesh R <vigneshr@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Franklin S Cooper Jr <fcooper@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Vignesh R <vigneshr@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
André Hentschel