According to Documentation/devicetree/bindings/arm/cpus.yaml, the
"enable-method" property should be a property of the individual CPU
nodes, and not of the parent "cpus" container node.
However, on R-Car Gen2 and RZ/G1 SoCs, the property is tied to the
"cpus" node instead.
Secondary CPU bringup and CPU hot (un)plug work regardless, as
arm_dt_init_cpu_maps() falls back to looking in the "cpus" node.
The cpuidle code does not have such a fallback, so it does not detect
the enable-method. Note that cpuidle does not support the
"renesas,apmu" enable-method yet, so for now this does not make any
difference.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/35fcfedf9de9269185c48ca5a6dfcba7cdd3484b.1621427319.git.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
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>
Enable support for the ARM Performance Monitor Units in the Cortex-A7
CPU cores on RZ/G1C by adding a device node for the PMU.
New Linux output:
hw perfevents: enabled with armv7_cortex_a7 PMU driver, 5 counters available
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Define the r8a77470 generic part of the HSUSB0/1 device nodes.
Currently the renesas_usbhs driver doesn't handle multiple phys and we
don't have a proper hardware to validate such driver changes.
So for hsusb1 it is assumed that usbphy0 will be enabled by either
channel0 host or device.
In future, if any boards support hsusb1, we will need to add multiple phy
support in the renesas_usbhs driver and override the board dts to enable
the same.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Define the r8a77470 generic part of the USB2.0 Host Controller device
nodes (ehci[01]/ohci[01]).
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Add pwm{0|1|2|3|4|5|6} nodes to dtsi for PWM support on the
RZ/G1C (r8a77470) SoC.
Signed-off-by: Cao Van Dong <cv-dong@jinso.co.jp>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Add hscif{0|1|2} nodes to dtsi for HSCIF support on the
RZ/G1C (r8a77470) SoC.
Signed-off-by: Cao Van Dong <cv-dong@jinso.co.jp>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Althought interface SDHI1 found on the RZ/G1C SoC (a.k.a.
r8a77470) is compatible with the R-Car Gen3 ones, its OF
compatibility is restricted to the SoC specific compatible
string to avoid confusion, as from a more generic perspective
the RZ/G1C is sharing the most similarities with the R-Car
Gen2 family of SoCs, and there is a combination of R-Car
Gen2 compatible SDHI IPs and R-Car Gen3 compatible SDHI IP
on this specific chip.
This patch adds the SoC specific part of SDHI1 support, and
since SDHI1 comes with internal DMA, its DT node looks fairly
different from SDHI0 and SDHI2.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
RZ/G1C comes with two different types of IP for the SDHI
interfaces, SDHI0 and SDHI2 share the same IP type, and
such an IP is also compatible with the one found in R-Car
Gen2. SDHI1 IP on the other hand is compatible with R-Car
Gen3 with internal DMA.
This patch completes the SDHI support of the R-Car Gen2
compatible IPs, including fixing the max-frequency
definition of SDHI2, as it turns out there is a bug in
Section 1.3.9 of the RZ/G1C Hardware User's Manual (Rev.
1.00 Oct. 2017).
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
