With 'unevaluatedProperties' support implemented, there are a number of
warnings when running dtbs_check:
arch/arm64/boot/dts/renesas/r8a774b1-hihope-rzg2n-rev2-ex-idk-1110wr.dtb: spi@ee200000: Unevaluated properties are not allowed ('clock-names' was unexpected)
From schema: Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml
The main problem is that the DT bindings do not allow clock-names.
So just drop the clock-names properties from the SoC DTSI files.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20220829215128.5983-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Some EtherAVB variants support internal clock delay configuration, which
can add larger delays than the delays that are typically supported by
the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps"
properties).
Historically, the EtherAVB driver configured these delays based on the
"rgmii-*id" PHY mode. This was wrong, as these are meant solely for the
PHY, not for the MAC. Hence properties were introduced for explicit
configuration of these delays.
Convert the R-Car Gen3 DTS files from the old to the new scheme:
- Add default "rx-internal-delay-ps" and "tx-internal-delay-ps"
properties to the SoC .dtsi files, to be overridden by board files
where needed,
- Convert board files from "rgmii-*id" PHY modes to "rgmii", adding
the appropriate "rx-internal-delay-ps" and/or "tx-internal-delay-ps"
overrides.
Notes:
- R-Car E3 and D3 do not support TX internal delay handling,
- On R-Car D3, TX internal delay handling must always be enabled,
hence this fixes a bug on Draak,
- On R-Car V3H, RX internal delay handling must always be enabled.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200819134344.27813-7-geert+renesas@glider.be
Pull ARM devicetree updates from Arnd Bergmann:
"This is the set of device tree changes, mostly covering new hardware
support, with 577 patches touching a little over 500 files.
There are five new Arm SoCs supported in this release, all of them for
existing SoC families:
- Realtek RTD1195, RTD1395 and RTD1619 -- three SoCs used in both NAS
devices and Android Set-top-box designs, along with the
"Horseradish", "Lion Skin" and "Mjolnir" reference platforms; the
Mele X1000 and Xnano X5 set-top-boxes and the Banana Pi BPi-M4
single-board computer.
- Renesas RZ/G1H (r8a7742) -- a high-end 32-bit industrial SoC and
the iW-RainboW-G21D-Qseven-RZG1H board/SoM
- Rockchips RK3326 -- low-end 64-bit SoC along with the Odroid-GO
Advance game console
Newly added machines on already supported SoCs are:
- AMLogic S905D based Smartlabs SML-5442TW TV box
- AMLogic S905X3 based ODROID-C4 SBC
- AMLogic S922XH based Beelink GT-King Pro TV box
- Allwinner A20 based Olimex A20-OLinuXino-LIME-eMMC SBC
- Aspeed ast2500 based BMCs in Facebook x86 "Yosemite V2" and YADRO
OpenPower P9 "Nicole"
- Marvell Kirkwood based Check Point L-50 router
- Mediatek MT8173 based Elm/Hana Chromebook laptops
- Microchip SAMA5D2 "Industrial Connectivity Platform" reference
board
- NXP i.MX8m based Beacon i.MX8m-Mini SoM development kit
- Octavo OSDMP15x based Linux Automation MC-1 development board
- Qualcomm SDM630 based Xiaomi Redmi Note 7 phone
- Realtek RTD1295 based Xnano X5 TV Box
- STMicroelectronics STM32MP1 based Stinger96 single-board computer
and IoT Box
- Samsung Exynos4210 based based Samsung Galaxy S2 phone
- Socionext Uniphier based Akebi96 SBC
- TI Keystone based K2G Evaluation board
- TI am5729 based Beaglebone-AI development board
Include device descriptions for additional hardware support in
existing SoCs and machines based on all major SoC platforms:
- AMlogic Meson
- Allwinner sunxi
- Arm Juno/VFP/Vexpress/Integrator
- Broadcom bcm283x/bcm2711
- Hisilicon hi6220
- Marvell EBU
- Mediatek MT27xx, MT76xx, MT81xx and MT67xx
- Microchip SAMA5D2
- NXP i.MX6/i.MX7/i.MX8 and Layerscape
- Nvidia Tegra
- Qualcomm Snapdragon
- Renesas r8a77961, r8a7791
- Rockchips RK32xx/RK33xx
- ST-Ericsson ux500
- STMicroelectronics SMT32
- Samsung Exynos and S5PV210
- Socionext Uniphier
- TI OMAP5/DRA7 and Keystone"
* tag 'arm-dt-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (564 commits)
ARM: dts: keystone: Rename "msmram" node to "sram"
arm: dts: mt2712: add uart APDMA to device tree
arm64: dts: mt8183: add mmc node
arm64: dts: mt2712: add ethernet device node
arm64: tegra: Make the RTC a wakeup source on Jetson Nano and TX1
ARM: dts: mmp3: Add the fifth SD HCI
ARM: dts: berlin*: Fix up the SDHCI node names
ARM: dts: mmp3: Fix USB & USB PHY node names
ARM: dts: mmp3: Fix L2 cache controller node name
ARM: dts: mmp*: Fix up encoding of the /rtc interrupts property
ARM: dts: pxa*: Fix up encoding of the /rtc interrupts property
ARM: dts: pxa910: Fix the gpio interrupt cell number
ARM: dts: pxa3xx: Fix up encoding of the /gpio interrupts property
ARM: dts: pxa168: Fix the gpio interrupt cell number
ARM: dts: pxa168: Add missing address/size cells to i2c nodes
ARM: dts: dove: Fix interrupt controller node name
ARM: dts: kirkwood: Fix interrupt controller node name
arm64: dts: Add SC9863A emmc and sd card nodes
arm64: dts: Add SC9863A clock nodes
arm64: dts: mt6358: add PMIC MT6358 related nodes
...
Add reset control properties to the device nodes for the Display Units
on all supported R-Car Gen3 SoCs. Note that on these SoCs, there is
only a single reset for each pair of DU channels.
The display nodes on R-Car V3M and V3H already had "resets" properties,
but lacked the corresponding "reset-names" properties.
Join the clocks lines while at it, to increase uniformity.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/20200218133019.22299-4-geert+renesas@glider.be
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.
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-7-geert+renesas@glider.be
Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
According to the Renesas R-Car DU bindings documentation, the 'vsps'
property should be composed of a phandle to the VSP instance and the
index of the LIF channel assigned to the DU channel. Some SoC device
tree source files do not specify any LIF channel index, relying on the
driver defaulting to 0 if not specified.
Align all device tree files by specifying the LIF channel indices as
prescribed by the bindings documentation.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Link: https://lore.kernel.org/r/20190825140135.12150-2-jacopo+renesas@jmondi.org/
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
According to the R-Car Gen3 Hardware Manual Errata for Rev 1.50 of Feb
12, 2019, the base address of the IPMMU-VC0 block on R-Car V3H is
0xfe990000.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
Hook up the R-Car V3H AVB device to IPMMU-DS1 33 as described in
the data sheet.
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Describe MSIOF in the R8A779{7|8}0 device trees.
The DMA props are omitted for R8A77980 as the RT-DMAC isn't supported
(yet?)...
Based on the original (and large) patches by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
For R-Car V3H hook up SYS-DMAC1 and SYS-DMAC2 to IPMMU-DS1 to match
information in the R-Car Gen3 Rev.1.00 (April 2018) datasheet.
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The IPMMU nodes should follow the GEther node, not the CAN-FD node,
according to the <unit-address> part of the startng IPMMU-DS1 node.
While moving the nodes, also do sort them by label alphanumerically...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Browsing the DTS for all the R-Car SoCs with similar part numbers
makes my head hurt, so to improve the user friendliness of the
DTS code base include R-Car product name in each DTSI file.
Product names are derived from
Documentation/devicetree/bindings/arm/shmobile.txt
Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Add IPMMU device nodes for the R-Car M3-N (r8a77965),
V3H (r8a77980) and E3 (r8a77990) SoCs.
* The r8a77965 IPMMU is quite similar to r8a7796 however VP0
has been added and PV1 has been removed. Also the IMSSTR
bit assignment has been reworked.
* The r8a77980 IPMMU is quite similar to r8a77970 however VC0
has been added. The IMSSTR bit assignment has also been
reworked. Power domains are also quite different however the
the documentation is rather unclear about this topic.
Until we know better VC0 gets assigned to R8A77980_PD_ALWAYS_ON.
* The r8a77990 IPMMU is similar to r8a77995. Power domains are
however different and the public documentation is still unclear.
Based on preliminary information from the hardware team the R-Car E3
SoC comes with an IPMMU-VP0 device in an Always-on power domain and
the IPMMU-VC0 is placed as expected in the A3VC power domain.
Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
