RZ-G/RZG DeviceTree: Difference between revisions
(Rename "RZ Specific Files" to "RZ Evaluation Board Files") |
No edit summary |
||
(18 intermediate revisions by 2 users not shown) | |||
Line 314: | Line 314: | ||
</pre> | </pre> | ||
|} | |} | ||
<br> | |||
* If you to see a list of which peripheral nodes are set in each file, you can use this "dts_parser" tool below. For example, you want to find all the the .dtsi files that configure the i2c channels because you are looking for examples. | |||
** https://github.com/seebe/rzg_stuff/tree/master/dts_parser | |||
=Device Tree Syntax= | =Device Tree Syntax= | ||
Line 347: | Line 352: | ||
}; | }; | ||
</pre> | </pre> | ||
=Clocks and Resets (CPG)= | |||
* System clocks, PLL setup, Dividers, Individual Peripheral Reset etc... | |||
* CPG = Clock Pulse Generator | |||
'''Linux Drivers''' | |||
* RZ/G2H, G2M, G2N, G2E: | |||
* RZ/G2L, G2LC, G2UL, V2L: | |||
** drivers/clk/renesas/* | |||
** CONFIG_CLK_RENESAS=y | |||
** (drivers for individual devices are auto selected by Kconfig) | |||
'''Notes''' | |||
* You generally do not have to do anything with these nodes or drivers. They are just listed here for reference. | |||
=Pin Control (pin mux)= | =Pin Control (pin mux)= | ||
'''Linux Drivers''' | '''Linux Drivers''' | ||
* RZ/G2H, G2M, G2N, G2E: | * RZ/G2H, G2M, G2N, G2E: | ||
** drivers/pinctrl/renesas/ | ** drivers/pinctrl/renesas/core.c, pinctrl.c, pfc-xxxx.c, etc... (refer to the Makefile) | ||
** | ** CONFIG_PINCTRL_RENESAS=y | ||
** Documentation/devicetree/bindings/pinctrl/renesas,pcf.yaml | ** Documentation/devicetree/bindings/pinctrl/renesas,pcf.yaml | ||
* RZ/G2L, G2LC, G2UL, V2L: | * RZ/G2L, G2LC, G2UL, V2L: | ||
** drivers/pinctrl/renesas/ | ** drivers/pinctrl/renesas/pinctrl-rzg2l.c | ||
** CONFIG_PINCTRL_RZG2L=y | ** CONFIG_PINCTRL_RZG2L=y | ||
** Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml | ** Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml | ||
'''Notes''' | '''Notes''' | ||
* | * '''Helpful Debug Messages:''' Sometimes it is helpful to see how the pins are being configured on boot up. By putting '''#define DEBUG''' at the top of the driver file (pinctrl.c or pinctrl-rzg2.c) will make it print out how each pins is being configured. | ||
'''Device Tree Examples''' | '''Device Tree Examples''' | ||
* (see device tree for evaluation board) | * (see device tree for evaluation board) | ||
* Use any GPIO as wake-up source, e.g. P37.2: | |||
gpio_keys { | |||
compatible = "gpio-keys"; | |||
#address-cells = <1>; | |||
#size-cells = <0>; | |||
autorepeat; | |||
P37_2 { | |||
label = "GPIO Key WAKEUP"; | |||
linux,code = <143>; | |||
wakeup-source; | |||
interrupt-parent = <&pinctrl>; | |||
interrupts = <RZG2L_GPIO(37, 2) IRQ_TYPE_EDGE_FALLING>; | |||
debounce-interval = <50>; | |||
}; | |||
}; | |||
= IRQ0-7 = | = IRQ0-7 = | ||
Line 382: | Line 416: | ||
'''Device Tree Examples''' | '''Device Tree Examples''' | ||
* | *Use NMI as wake-up source: | ||
gpio_keys { | |||
compatible = "gpio-keys"; | |||
#address-cells = <1>; | |||
#size-cells = <0>; | |||
autorepeat; | |||
NMI { | |||
label = "NMI Key WAKEUP"; | |||
linux,code = <143>; | |||
wakeup-source; | |||
interrupt-parent = <&intc_ex>; | |||
interrupts = <8 IRQ_TYPE_EDGE_FALLING>; | |||
debounce-interval = <50>; | |||
}; | |||
}; | |||
&intc_ex { | |||
status = "okay"; | |||
}; | |||
IRQs can be used as well: | |||
gpio_keys { | |||
compatible = "gpio-keys"; | |||
#address-cells = <1>; | |||
#size-cells = <0>; | |||
autorepeat; | |||
pinctrl-0 = <&user_key_pin>; | |||
IRQ_7 { | |||
label = "IRQ_7 Key WAKEUP"; | |||
linux,code = <143>; | |||
wakeup-source; | |||
interrupt-parent = <&intc_ex>; | |||
interrupts = <7 IRQ_TYPE_EDGE_FALLING>; | |||
debounce-interval = <50>; | |||
}; | |||
}; | |||
&intc_ex { | |||
status = "okay"; | |||
}; | |||
&pinctrl{ | |||
user_key_pin: user_key { | |||
pinmux = <RZG2L_PORT_PINMUX(3, 1, 1)>; /* IRQ7 */ | |||
}; | |||
}; | |||
=Display= | =Display= | ||
Line 403: | Line 483: | ||
* '''MIPI DSI Overview:''' Here is a good article explaining the MIPI DSI interface, packets and commands. https://circuitcellar.com/resources/quickbits/mipi-display-serial-interface | * '''MIPI DSI Overview:''' Here is a good article explaining the MIPI DSI interface, packets and commands. https://circuitcellar.com/resources/quickbits/mipi-display-serial-interface | ||
* '''MIPI DCS Commands:''' Many (most) MIPI DSI Panels require setup command (DCS) to be set over MIPI DSI to configure the panel's controller before pixel data can be sent. This is why there is usually a separate driver for each LCD since these commands are specific to each LCD panel. | * '''MIPI DCS Commands:''' Many (most) MIPI DSI Panels require setup command (DCS) to be set over MIPI DSI to configure the panel's controller before pixel data can be sent. This is why there is usually a separate driver for each LCD since these commands are specific to each LCD panel. | ||
* '''Simple-Panel Driver:''' If | * '''Simple-Panel Driver:''' If your panel requires no special setup (no MIPI DSI DCS commands) or your system is configuring your LCD manually over I2C, or you are using a parallel RGB panel that typically requires no setup, you can use the kernel's "simple-panel" driver. The main reason is that you need to tell the kernel about the resolution and pixel timing is of your panel, but that information is not described in a Device Tree, it must come from a source code driver file. The panel-simple driver is there as a way to do that by simply adding in a new entry for your custom panel. Note that you will be required to edit the driver file (drivers/gpu/drm/panel/panel-simple.c) to add your specific panel resolution and timing that you want. See kernel documentation Documentation/devicetree/bindings/panel/simple-panel.txt. | ||
* '''Parallel RGB LCD:''' Since a parallel LCD does not need any special setup, you can use simple-panel driver in the kernel. | * '''Parallel RGB LCD:''' Since a parallel LCD does not need any special setup, you can use simple-panel driver in the kernel. | ||
* '''Check Display Settings:''' You can use the command '''modetest -M rcar-du -c''' to check the status of your display driver. It will also show you the supported resolutions of your display (in the case that you are using an HDMI interface where it will read what is supported by the HDMI panel). | * '''Check Display Settings:''' You can use the command '''modetest -M rcar-du -c''' to check the status of your display driver. It will also show you the supported resolutions of your display (in the case that you are using an HDMI interface where it will read what is supported by the HDMI panel). | ||
Line 468: | Line 548: | ||
{| class="mw-collapsible mw-collapsed wikitable" | {| class="mw-collapsible mw-collapsed wikitable" | ||
| Example of RGB Panel on RZ/G2L   | | Example of Parallel(RGB) Panel on RZ/G2L (5.10)   | ||
|- | |||
| | |||
* Please use kernel version 5.10.201-cip41+ | |||
* Configure pins | |||
<pre> | |||
&pinctrl { | |||
du_pins: du { | |||
data { | |||
pinmux = <RZG2L_PORT_PINMUX(7, 2, 1)>, | |||
<RZG2L_PORT_PINMUX(8, 0, 1)>, | |||
<RZG2L_PORT_PINMUX(8, 1, 1)>, | |||
<RZG2L_PORT_PINMUX(8, 2, 1)>, | |||
<RZG2L_PORT_PINMUX(9, 0, 1)>, | |||
<RZG2L_PORT_PINMUX(9, 1, 1)>, | |||
<RZG2L_PORT_PINMUX(10, 0, 1)>, | |||
<RZG2L_PORT_PINMUX(10, 1, 1)>, | |||
<RZG2L_PORT_PINMUX(11, 0, 1)>, | |||
<RZG2L_PORT_PINMUX(11, 1, 1)>, | |||
<RZG2L_PORT_PINMUX(12, 0, 1)>, | |||
<RZG2L_PORT_PINMUX(12, 1, 1)>, | |||
<RZG2L_PORT_PINMUX(13, 0, 1)>, | |||
<RZG2L_PORT_PINMUX(13, 1, 1)>, | |||
<RZG2L_PORT_PINMUX(13, 2, 1)>, | |||
<RZG2L_PORT_PINMUX(14, 0, 1)>, | |||
<RZG2L_PORT_PINMUX(14, 1, 1)>, | |||
<RZG2L_PORT_PINMUX(15, 0, 1)>, | |||
<RZG2L_PORT_PINMUX(15, 1, 1)>, | |||
<RZG2L_PORT_PINMUX(16, 0, 1)>, | |||
<RZG2L_PORT_PINMUX(16, 1, 1)>, | |||
<RZG2L_PORT_PINMUX(17, 0, 1)>, | |||
<RZG2L_PORT_PINMUX(17, 1, 1)>, | |||
<RZG2L_PORT_PINMUX(17, 2, 1)>; | |||
}; | |||
sync { | |||
pinmux = <RZG2L_PORT_PINMUX(6, 1, 1)>, /* HSYNC */ | |||
<RZG2L_PORT_PINMUX(7, 0, 1)>; /* VSYNC */ | |||
}; | |||
de { | |||
pinmux = <RZG2L_PORT_PINMUX(7, 1, 1)>; /* DE */ | |||
}; | |||
clk { | |||
pinmux = <RZG2L_PORT_PINMUX(6, 0, 1)>; /* CLK */ | |||
}; | |||
}; | |||
}; | |||
</pre> | |||
* We want to use simple panel driver and add the device node | |||
<pre> | |||
panel_rgb: panel-rgb { | |||
compatible = "arm,rtsm-display"; //<-- this property "arm,rtsm-display" is an example. | |||
// please fill in the correct information based on your panel spec. | |||
port { | |||
panel_in_rgb: endpoint { | |||
remote-endpoint = <&du_out_rgb>; | |||
}; | |||
}; | |||
}; | |||
</pre> | |||
* Add endpoint for DU RGB out: | |||
<pre> | |||
&du { | |||
pinctrl-0 = <&du_pins>; | |||
pinctrl-names = "default"; | |||
status = "okay"; | |||
ports { | |||
port@0 { | |||
du_out_rgb: endpoint { | |||
remote-endpoint = <&panel_in_rgb>; | |||
}; | |||
}; | |||
}; | |||
}; | |||
</pre> | |||
* We want the MIPI DSI driver disabled | |||
<pre> | |||
&dsi0 { | |||
status = "disabled"; | |||
}; | |||
</pre> | |||
|} | |||
{| class="mw-collapsible mw-collapsed wikitable" | |||
| Example of RGB Panel on RZ/G2L (4.19 kernel only)   | |||
|- | |- | ||
| | | | ||
Line 886: | Line 1,058: | ||
'''Linux Drivers''' | '''Linux Drivers''' | ||
* RZ/G2H, G2M, G2N, G2E: | * RZ/G2H, G2M, G2N, G2E: | ||
* RZ/G2L, G2LC, G2UL, V2L: | * RZ/G2L, G2LC, G2UL, V2L: | ||
** | '''Host''' | ||
** | * (uses standard EHCI and XHCI kernel drivers since H/W API is fixed) | ||
* drivers/usb/host/ehci-hcd.c | |||
* drivers/usb/host/ehci-platform.c | |||
* drivers/usb/host/xhci.c | |||
* drivers/usb/host/xhci-rcar.c | |||
** CONFIG_USB_EHCI_HCD=y | |||
** CONFIG_XHCI_PLATFORM=y | |||
** CONFIG_XHCI_RCAR=y | |||
'''Device''' | |||
* drivers/usb/renesas_usbhs/* | |||
** USB_RENESAS_USBHS=y | |||
'''PHY''' | |||
* The PHY is a separate H/W block. Also used to control host/device switching for OTG. | |||
* drivers/phy/renesas/* | |||
** CONFIG_PHY_RCAR_GEN3_USB2=y | |||
** CONFIG_PHY_RCAR_GEN3_USB3=y | |||
'''Notes''' | '''Notes''' | ||
* | * '''Disable OverCurrent Protection Interrupts:''' | ||
: If you did not connect the USB_OVCUR pin on your board, and it floats, you will get interrupt messages about over current. However, you can disable this interrupt by modifying the setting for the OHCI '''HcRhDescriptorA Register''' and setting bit '''NOCP''' to '1'. Search for "HcRhDescriptorA" in the hardware manual for more information. | |||
: In the '''kernel''', in file '''drivers/usb/host/ohci-hcd.c''', you want to '''comment out''' the line: | |||
:: <font face=Consolas>/* Configure for per-port over-current protection by default */</font> | |||
:: <font face=Consolas>val &= ~RH_A_NOCP;</font> | |||
: In u-boot, can see this is sometimes done for Renesas boards. See file '''board/renesas/rzg2l-dev/rzg2l-dev.c''' | |||
:: <font face=Consolas>(*(volatile u32 *)(USB1_BASE + HcRhDescriptorA)) |= (0x1u << 12); /* NOCP = 1 */</font> | |||
* '''Dynamic changing from Device and Host for OTG:''' | |||
: If you are using a device as OTG (On-the-Go) and want to change from device to you, you set a sysfs setting under the PHY driver (not the USB controller driver) | |||
:: <font face=Consolas>$ echo host > /sys/devices/platform/soc/ee080200.usb-phy/role</font> | |||
'''Device Tree Examples''' | '''Device Tree Examples''' | ||
Line 985: | Line 1,182: | ||
'''Device Tree Examples''' | '''Device Tree Examples''' | ||
* (see device tree for evaluation board) | * (see device tree for evaluation board) | ||
=DMA= | |||
'''Linux Drivers''' | |||
* RZ/G2H, G2M, G2N, G2E: | |||
** drivers/dma/sh/* | |||
** CONFIG_RCAR_DMAC=y | |||
* RZ/G2L, G2LC, G2UL, V2L: | |||
** drivers/dma/sh/rz-dma.c | |||
** CONFIG_RZ_DMAC=y | |||
'''Notes''' | |||
'''RZ/G2L, RZ/V2L, How to determine 'dmas' value''' | |||
* Given the Device Tree example below for SPI-1, you will need to determine the values for the "tx" and "rx" DMA triggers. | |||
<html><pre> | |||
&spi1 { | |||
pinctrl-0 = <&spi1_pins>; | |||
pinctrl-names = "default"; | |||
dmas = <&dmac <span><font color=red> 0x2e99 </font></span>>, <&dmac <span><font color=red> 0x2e9a </font></span>>; | |||
dma-names = "tx", "rx"; | |||
status = "okay"; | |||
}; | |||
</pre></html> | |||
* You can find some explanation in the kernel documentation: '''Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml''' | |||
<pre> | |||
'#dma-cells': | |||
const: 1 | |||
description: | |||
The cell specifies the encoded MID/RID values of the DMAC port | |||
connected to the DMA client and the slave channel configuration | |||
parameters. | |||
bits[0:9] - Specifies MID/RID value | |||
bit[10] - Specifies DMA request high enable (HIEN) | |||
bit[11] - Specifies DMA request detection type (LVL) | |||
bits[12:14] - Specifies DMAACK output mode (AM) | |||
bit[15] - Specifies Transfer Mode (TM) | |||
</pre> | |||
* These values are what get written directly to the DMA registers. Also, the values for these bits are fixed and shown in a table in the hardware manual. | |||
* If you look in the Direct Memory Access Control (DMA) chapter in the hardware manual, you will find the table "On-Chip Module Requests" | |||
'''Example: RZ/G2L RSPI ch1''' | |||
[[File:RZG2L DMA Request Table SPI.png]] | |||
'''SPIT1 (tranmit buffer empty)''' | |||
dma-names = "tx" | |||
<html><pre> | |||
MID[7:0] = 10100110'b | |||
RID[1:0] = 01'b | |||
HEIN = 1'b | |||
LVL = 1'b | |||
AM[2:0] = 010'b | |||
TM = 0'b | |||
AM HEIN RID | |||
| | | | |||
0 010 1 1 10100110 01 = 0010 1110 1001 1001 = <span><font color=red> 0x2e99 </font></span> | |||
| | | | |||
TM LVL MID | |||
</pre></html> | |||
'''SPIR1 (receive buffer full)''' | |||
dma-names = "rx" | |||
<html><pre> | |||
MID[7:0] = 10100110'b | |||
RID[1:0] = 10'b | |||
HEIN = 1'b | |||
LVL = 1'b | |||
AM[2:0] = 010'b | |||
TM = 0'b | |||
AM HEIN RID | |||
| | | | |||
0 010 1 1 10100110 10 = 0010 1110 1001 1010 = <span><font color=red> 0x2e9a </font></span> | |||
| | | | |||
TM LVL MID | |||
</pre></html> | |||
'''Device Tree Examples''' | |||
* (see device tree for evaluation board) | |||
=I2C= | =I2C= | ||
Line 1,011: | Line 1,292: | ||
'''Notes''' | '''Notes''' | ||
* | * '''spidev:''' | ||
** If you want a generic SPI device (/dev/spi-0), in the past you would allocate a <font color=navy>compatible = "spidev";</font> node. Unfortunately, that spidev name has been removed from Linux (since Linux-5.17). However, you can still create a spidev device by simply using another name that is already in the kernel. The compatible name will be different, but it will work the exact same way. | |||
** Below is the list of device that can be used with spidev from file '''drivers/spi/spidev.c''' | |||
: <html><pre> | |||
static const struct of_device_id spidev_dt_ids[] = { | |||
{ .compatible = "rohm,dh2228fv" }, | |||
{ .compatible = "lineartechnology,ltc2488" }, | |||
{ .compatible = "ge,achc" }, | |||
{ .compatible = "semtech,sx1301" }, | |||
{ .compatible = "lwn,bk4" }, | |||
{ .compatible = "dh,dhcom-board" }, | |||
{ .compatible = "menlo,m53cpld" }, | |||
{}, | |||
}; | |||
</pre></html> | |||
:* For example, if you just pick the first name in the list ("rohm,dh2228fv") this will work on any kernel version: | |||
: <html><pre> | |||
&spi1 { | |||
pinctrl-0 = <&spi1_pins>; | |||
pinctrl-names = "default"; | |||
status = "okay"; | |||
dmas = <&dmac 0x2e99>, | |||
<&dmac 0x2e9a>; | |||
dma-names = "tx", "rx"; | |||
spidev@0{ | |||
<b>compatible = "rohm,dh2228fv"; // (Using fake name to use spidev driver)</b> | |||
reg = <0>; | |||
spi-max-frequency = <1000000>; | |||
}; | |||
}; | |||
</pre></html> | |||
'''Device Tree Examples''' | '''Device Tree Examples''' | ||
* (see device tree for evaluation board) | * (see device tree for evaluation board) | ||
=QSPI Flash= | =QSPI Flash= | ||
Line 1,078: | Line 1,390: | ||
'''Linux Drivers''' | '''Linux Drivers''' | ||
* RZ/G2H, G2M, G2N, G2E: | * RZ/G2H, G2M, G2N, G2E: | ||
* RZ/G2L, G2LC, G2UL, V2L: | * RZ/G2L, G2LC, G2UL, V2L: | ||
** drivers/net/can/rcar/* | |||
** | ** | ||
** | ** CONFIG_CAN_RCAR=y | ||
** CONFIG_CAN_RCAR_FD=y | |||
'''Notes''' | '''Notes''' | ||
* | * CAN-FD is enabled by default. To switch to CAN protocol, a user can add property "renesas,no-can-fd" in the Device Tree | ||
* Example setup commands: | |||
** Classic CAN: <font face="consolas">$ ip link set can1 type can bitrate 125000</font> | |||
** CAN-FD: <font face="consolas">$ ip link set can1 type can bitrate 333333 dbitrate 666666 fd on </font> | |||
'''Device Tree Examples''' | '''Device Tree Examples''' | ||
* (see device tree for evaluation board) | * (see device tree for evaluation board) | ||
=ADC= | =ADC= |
Revision as of 07:36, 26 April 2024
← RZ-G
- This page contains helpful notes about Device Tree configurations
RZ Evaluation Board Files
- Device Tree files for Renesas SoC and evaluation boards are under the directory arch/arm64/boot/dts/renesas/
- Below is the list of Device Tree files used for the Renesas Evaluation boards.
- Because the evaluation kits share common boards, and have many different test/demo configurations, there are many include files (.dtsi) for any single device tree (.dts) build. For your custom board, you might only need your Device Tree for your board (my_board.dst) and that will only #include one other file which will be the base SoC file (RZ/G2H for example will #include "r8a774e1.dtsi").
- RZ board names that end in "-dev" are internal Renesas boards. While their Device Trees files appear in the BSP, they are not mainlined.
RZ/G2H HiHope | |
File | Description |
---|---|
r8a774e1.dtsi | RZ/G2H Device Tree containing all peripherals |
r8a774e1-hihope-rzg2h.dts | Main board only r8a774e1-hihope-rzg2h.dts ├─r8a774e1.dtsi └─hihope-rev4.dtsi └─hihope-common.dtsi |
r8a774e1-hihope-rzg2h-ex.dts | Main board + Sub board r8a774e1-hihope-rzg2h-ex.dts ├─r8a774e1-hihope-rzg2h.dts │ ├─r8a774e1.dtsi │ └─hihope-rev4.dtsi │ └─hihope-common.dtsi └─hihope-rzg2-ex.dtsi |
r8a774e1-hihope-rzg2h-ex-idk-1110wr.dts | Main board + Sub board + LVDS panel r8a774e1-hihope-rzg2h-ex-idk-1110wr.dts ├─r8a774e1-hihope-rzg2h-ex.dts │ ├─r8a774e1-hihope-rzg2h.dts │ │ ├─r8a774e1.dtsi │ │ └─hihope-rev4.dtsi │ │ └─hihope-common.dtsi │ └─hihope-rzg2-ex.dtsi ├─hihope-rzg2-ex-lvds.dtsi └─rzg2-advantech-idk-1110wr-panel.dtsi |
r8a774e1-hihope-rzg2h-ex-mipi-2.1.dts | Main board + Sub board + MIPI-CSI2 cameras r8a774e1-hihope-rzg2h-ex-mipi-2.1.dts ├─r8a774e1-hihope-rzg2h-ex.dts │ ├─r8a774e1-hihope-rzg2h.dts │ │ ├─r8a774e1.dtsi │ │ └─hihope-rev4.dtsi │ │ └─hihope-common.dtsi │ └─hihope-rzg2-ex.dtsi └─hihope-rzg2-ex-aistarvision-mipi-adapter-2.1.dtsi └─aistarvision-mipi-adapter-2.1.dtsi |
r8a774e1-hihope-rzg2h-ex-mipi-2.4.dts | Main board + Sub board + MIPI-CSI2 cameras r8a774e1-hihope-rzg2h-ex-mipi-2.4.dts ├─r8a774e1-hihope-rzg2h-ex.dts │ ├─r8a774e1-hihope-rzg2h.dts │ │ ├─r8a774e1.dtsi │ │ └─hihope-rev4.dtsi │ │ └─hihope-common.dtsi │ └─hihope-rzg2-ex.dtsi └─hihope-rzg2-ex-aistarvision-mipi-adapter-2.4.dtsi └─aistarvision-mipi-adapter-2.4.dtsi |
RZ/G2N HiHope | |
File | Description |
---|---|
r8a774b1.dtsi | RZ/G2N Device Tree containing all peripherals |
r8a774b1-hihope-rzg2n.dts | Main board only |
r8a774b1-hihope-rzg2n-ex.dts | Main board + Sub board |
r8a774b1-hihope-rzg2n-ex-idk-1110wr.dts | Main board + Sub board + LVDS panel |
r8a774b1-hihope-rzg2n-ex-mipi-2.1.dts | Main board + Sub board + MIPI/CSI2 cameras |
r8a774b1-hihope-rzg2n-ex-mipi-2.4.dts | Main board + Sub board + MIPI/CSI2 cameras |
r8a774b1-hihope-rzg2n-rev2.dts | |
r8a774b1-hihope-rzg2n-rev2-ex.dts | |
r8a774b1-hihope-rzg2n-rev2-ex-idk-1110wr.dts | |
rzg2-advantech-idk-1110wr-panel.dtsi | |
r8a774b1-hihope-rzg2n-rev2-ex-mipi-2.1.dts | Main board + Sub board + MIPI/CSI2 cameras |
r8a774b1-hihope-rzg2n-rev2-ex-mipi-2.4.dts | Main board + Sub board + MIPI/CSI2 cameras |
RZ/G2M HiHope | |
File | Description |
---|---|
r8a774a1.dtsi | RZ/G2M Device Tree containing all peripherals |
r8a774a1-hihope-rzg2m.dts | Main board only |
r8a774a1-hihope-rzg2m-ex.dts | Main board + Sub board |
r8a774a1-hihope-rzg2m-ex-idk-1110wr.dts | Main board + Sub board + LVDS panel |
rzg2-advantech-idk-1110wr-panel.dtsi | Main board + Sub board + LVDS panel |
r8a774a1-hihope-rzg2m-ex-mipi-2.1.dts | |
r8a774a1-hihope-rzg2m-ex-mipi-2.4.dts | |
r8a774a1-hihope-rzg2m-rev2.dts | |
r8a774a1-hihope-rzg2m-rev2-ex.dts | |
r8a774a1-hihope-rzg2m-rev2-ex-idk-1110wr.dts | |
r8a774a1-hihope-rzg2m-rev2-ex-mipi-2.1.dts | Main board + Sub board + MIPI/CSI2 cameras |
r8a774a1-hihope-rzg2m-rev2-ex-mipi-2.4.dts | Main board + Sub board + MIPI/CSI2 cameras |
r8a774a3.dtsi | |
r8a774a3-hihope-rzg2m.dts | |
r8a774a3-hihope-rzg2m-ex.dts | |
r8a774a3-hihope-rzg2m-ex-idk-1110wr.dts | |
rzg2-advantech-idk-1110wr-panel.dtsi | |
r8a774a3-hihope-rzg2m-ex-mipi-2.1.dts | Main board + Sub board + MIPI/CSI2 cameras |
r8a774a3-hihope-rzg2m-ex-mipi-2.4.dts | Main board + Sub board + MIPI/CSI2 cameras |
RZ/G2E EK874 | |
File | Description |
---|---|
r8a774c0.dtsi | RZ/G2E Device Tree containing all peripherals |
r8a774c0-cat874.dts | Main board only r8a774c0-cat874.dts ├─r8a774c0.dtsi └─cat874-common.dtsi |
r8a774c0-ek874.dts | Main board + Sub board r8a774c0-ek874.dts ├─r8a774c0-cat874.dts │ ├─r8a774c0.dtsi │ └─cat874-common.dtsi └─cat875.dtsi |
r8a774c0-ek874-idk-2121wr.dts | Main board + Sub board + LVDS panel |
r8a774c0-ek874-mipi-2.1.dts | Main board + Sub board + MIPI/CSI2 cameras |
r8a774c0-ek874-mipi-2.4.dts | Main board + Sub board + MIPI/CSI2 cameras |
r8a774c0-cat874-revc.dts | Main board only (older Rev C board) |
r8a774c0-ek874-revc.dts | Main board + Sub board (older Rev C board) |
r8a774c0-ek874-revc-idk-2121wr.dts | Main board + Sub board + LVDS panel (older Rev C board) |
r8a774c0-ek874-revc-mipi-2.1.dts | Main board + Sub board + MIPI/CSI2 cameras (older Rev C board) |
r8a774c0-ek874-revc-mipi-2.4.dts | Main board + Sub board + MIPI/CSI2 cameras (older Rev C board) |
r8a774c0-es10-cat874.dts | Main board only (older Rev 1.0 board) |
r8a774c0-es10-ek874.dts | Main board + Sub board (older Rev 1.0 board) |
r8a774c0-es10-ek874-idk-2121wr.dts | Main board + Sub board + LVDS panel (older Rev 1.0 board) |
r8a774c0-es10-ek874-mipi-2.1.dts | Main board + Sub board + MIPI/CSI2 cameras (older Rev 1.0 board) |
r8a774c0-es10-ek874-mipi-2.4.dts | Main board + Sub board + MIPI/CSI2 cameras (older Rev 1.0 board) |
RZ/G2L SMARC | |
File | Description |
---|---|
r9a07g044.dtsi | RZ/G2L family SoC common parts |
r9a07g044l.dtsi | Specific to RZ/G2L (R9A07G044L) SoC |
r9a07g044l1.dtsi | Specific to RZ/G2L (R9A07G044L single cortex A55) SoC |
r9a07g044l2.dtsi | Specific to RZ/G2L (R9A07G044L dual cortex A55) SoC |
r9a07g044l2-smarc.dts | Top level Device Tree Included files: r9a07g044l2-smarc.dts ├─r9a07g044l2.dtsi │ └─r9a07g044.dtsi ├─rzg2l-smarc-som.dtsi ├─rzg2l-smarc-pinfunction.dtsi ├─rz-smarc-common.dtsi └─rzg2l-smarc.dtsi |
RZ/G2LC SMARC | |
File | Description |
---|---|
r9a07g044c1.dtsi | RZ/G2LC Device Tree containing all peripherals |
r9a07g044c2.dtsi | RZ/G2LC Device Tree containing all peripherals |
r9a07g044c2-smarc.dts | Top level Device Tree Included files: r9a07g044c2-smarc.dts ├─r9a07g044c2.dtsi │ └─r9a07g044.dtsi └─rzg2lc-smarc.dtsi ├─rzg2lc-smarc-som.dtsi ├─rzg2lc-smarc-pinfunction.dtsi └─rz-smarc-common.dtsi |
RZ/G2UL SMARC | |
File | Description |
---|---|
r9a07g043.dtsi | RZ/G2UL Device Tree containing all peripherals |
r9a07g043u11-smarc.dts | Top level Device Tree
Included files: r9a07g043u11-smarc.dts ├─r9a07g043.dtsi └─rzg2ul-smarc.dtsi ├─rzg2ul-smarc-som.dtsi ├─rzg2ul-smarc-pinfunction.dtsi └─rz-smarc-common.dtsi |
RZ/V2L SMARC | |
File | Description |
---|---|
r9a07g054.dtsi | RZ/V2L Device Tree containing all peripherals. Use for your board. |
r9a07g054l1.dtsi | Sets the compatible strings. Use for your board. |
r9a07g054l2-smac.dts | Top level Device Tree Defines Memory areas including video Codec, DRP-AI, Simple ISP, V4L image buf r9a07g054l2-smarc.dts ├─r9a07g054l2.dtsi │ └─r9a07g054.dtsi ├─rzg2l-smarc-som.dtsi ├─rzg2l-smarc-pinfunction.dtsi ├─rz-smarc-common.dtsi └─rzg2l-smarc.dtsi |
- If you to see a list of which peripheral nodes are set in each file, you can use this "dts_parser" tool below. For example, you want to find all the the .dtsi files that configure the i2c channels because you are looking for examples.
Device Tree Syntax
Print a Compiled DTB Output File
- When compiling a .dts file into a binary .dtb file, many include files might be combined.
- Some include files might contain nodes overwrite other nodes.
- You might not know what the final Device Tree looks like after all the includes and nodes overwrites.
- You can install the device-tree-compiler package to show the contents of a .dtb file
$ sudo apt-get install device-tree-compiler
- Below is an example command to print a .dtb file
$ dtc -I dtb -O dts -o - r8a774a3-hihope-rzg2m-ex.dtb
Top Level (root node)
Compatible for the SoC
- The .dtsi file for each SoC will have a "compatible" string to specify that SoC it is. If you decide to make your own top level compatible, make sure you include the original SoC string. The reason is that some drivers (the VSP driver for example) look for that SoC string to know what SoC they are running on. If it is missing, it will not load or run correctly.
Here is a correct example of a .dts file for a RZ/G2L board. Notice how "renesas,r9a07g044" is at the end of the line.
/ { model = "My Really Cool RZ/G2L Board"; compatible = "my-rzg2l-board" , "renesas,r9a07g044"; chosen { bootargs = "ignore_loglevel rw root=/dev/mmc0blk1"; stdout-path = "serial0:115200n8"; }; };
Clocks and Resets (CPG)
- System clocks, PLL setup, Dividers, Individual Peripheral Reset etc...
- CPG = Clock Pulse Generator
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- RZ/G2L, G2LC, G2UL, V2L:
- drivers/clk/renesas/*
- CONFIG_CLK_RENESAS=y
- (drivers for individual devices are auto selected by Kconfig)
Notes
- You generally do not have to do anything with these nodes or drivers. They are just listed here for reference.
Pin Control (pin mux)
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- drivers/pinctrl/renesas/core.c, pinctrl.c, pfc-xxxx.c, etc... (refer to the Makefile)
- CONFIG_PINCTRL_RENESAS=y
- Documentation/devicetree/bindings/pinctrl/renesas,pcf.yaml
- RZ/G2L, G2LC, G2UL, V2L:
- drivers/pinctrl/renesas/pinctrl-rzg2l.c
- CONFIG_PINCTRL_RZG2L=y
- Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml
Notes
- Helpful Debug Messages: Sometimes it is helpful to see how the pins are being configured on boot up. By putting #define DEBUG at the top of the driver file (pinctrl.c or pinctrl-rzg2.c) will make it print out how each pins is being configured.
Device Tree Examples
- (see device tree for evaluation board)
- Use any GPIO as wake-up source, e.g. P37.2:
gpio_keys { compatible = "gpio-keys"; #address-cells = <1>; #size-cells = <0>; autorepeat; P37_2 { label = "GPIO Key WAKEUP"; linux,code = <143>; wakeup-source; interrupt-parent = <&pinctrl>; interrupts = <RZG2L_GPIO(37, 2) IRQ_TYPE_EDGE_FALLING>; debounce-interval = <50>; }; };
IRQ0-7
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- CONFIG_xxx=y
- RZ/G2L, G2LC, G2UL, V2L:
- drivers/irqchip/irq-renesas-rzg2l.c
- CONFIG_RENESAS_RZG2L_IRQC=y
- Added after 'rz-5.10-cip13'
Notes
Device Tree Examples
- Use NMI as wake-up source:
gpio_keys { compatible = "gpio-keys"; #address-cells = <1>; #size-cells = <0>; autorepeat; NMI { label = "NMI Key WAKEUP"; linux,code = <143>; wakeup-source; interrupt-parent = <&intc_ex>; interrupts = <8 IRQ_TYPE_EDGE_FALLING>; debounce-interval = <50>; }; }; &intc_ex { status = "okay"; };
IRQs can be used as well:
gpio_keys { compatible = "gpio-keys"; #address-cells = <1>; #size-cells = <0>; autorepeat; pinctrl-0 = <&user_key_pin>; IRQ_7 { label = "IRQ_7 Key WAKEUP"; linux,code = <143>; wakeup-source; interrupt-parent = <&intc_ex>; interrupts = <7 IRQ_TYPE_EDGE_FALLING>; debounce-interval = <50>; }; }; &intc_ex { status = "okay"; }; &pinctrl{ user_key_pin: user_key { pinmux = <RZG2L_PORT_PINMUX(3, 1, 1)>; /* IRQ7 */ }; };
Display
Linux Drivers
- Common:
- drivers/gpu/drm/rcar-du/*
- CONFIG_DRM_RCAR_DU=y
- drivers/media/platform/vsp1/*
- CONFIG_VIDEO_RENESAS_VSP1=y
- drivers/gpu/drm/rcar-du/*
- RZ/G2H, G2M, G2N, G2E:
- CONFIG_DRM_RCAR_LVDS=y
- RZ/G2L, G2LC, G2UL, V2L:
- drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.h
- drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
- drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h
Notes
- Ports Node When defining ports { }, you must set #address-cells = <1>; and #size-cells = <0>;. For more information, see the documentation in the kernel source: Documentation/devicetree/bindings/media/video-interfaces.txt
- Resolution and Clock Definitions: An LCD Panel will have it's own separate driver. That driver will define the clock rate and resolution. The Renesas LCD driver will then get that information in order to set up the LCD controller (DU) output.
- MIPI DSI Overview: Here is a good article explaining the MIPI DSI interface, packets and commands. https://circuitcellar.com/resources/quickbits/mipi-display-serial-interface
- MIPI DCS Commands: Many (most) MIPI DSI Panels require setup command (DCS) to be set over MIPI DSI to configure the panel's controller before pixel data can be sent. This is why there is usually a separate driver for each LCD since these commands are specific to each LCD panel.
- Simple-Panel Driver: If your panel requires no special setup (no MIPI DSI DCS commands) or your system is configuring your LCD manually over I2C, or you are using a parallel RGB panel that typically requires no setup, you can use the kernel's "simple-panel" driver. The main reason is that you need to tell the kernel about the resolution and pixel timing is of your panel, but that information is not described in a Device Tree, it must come from a source code driver file. The panel-simple driver is there as a way to do that by simply adding in a new entry for your custom panel. Note that you will be required to edit the driver file (drivers/gpu/drm/panel/panel-simple.c) to add your specific panel resolution and timing that you want. See kernel documentation Documentation/devicetree/bindings/panel/simple-panel.txt.
- Parallel RGB LCD: Since a parallel LCD does not need any special setup, you can use simple-panel driver in the kernel.
- Check Display Settings: You can use the command modetest -M rcar-du -c to check the status of your display driver. It will also show you the supported resolutions of your display (in the case that you are using an HDMI interface where it will read what is supported by the HDMI panel).
- Check VBLANK Timings: You can use the command vbltest -M rcar-du to check the VBLANK timings. If your result is always around 60Hz, your panel is set correctly.
Device Tree Examples:
- RZ/G2L: MIPI-CSI to HDMI Bridge: See device tree for evaluation board.
Example of MIPI DSI Panel on RZ/G2L |
&du { status = "okay"; }; &dsi0 { status = "okay"; #address-cells = <1>; #size-cells = <0>; ports { #address-cells = <1>; #size-cells = <0>; port@1 { dsi0_out: endpoint { remote-endpoint = <&panel_in>; data-lanes = <1 2>; }; }; }; panel@0 { compatible = "ilitek,ili9881c"; reg = <0>; dsi-lanes = <2>; enable-gpios = <&pinctrl RZG2L_GPIO(43, 0) GPIO_ACTIVE_HIGH>; backlight = <&backlight>; status = "okay"; port { panel_in: endpoint { remote-endpoint = <&dsi0_out>; }; }; }; }; |
Example of Parallel(RGB) Panel on RZ/G2L (5.10) |
&pinctrl { du_pins: du { data { pinmux = <RZG2L_PORT_PINMUX(7, 2, 1)>, <RZG2L_PORT_PINMUX(8, 0, 1)>, <RZG2L_PORT_PINMUX(8, 1, 1)>, <RZG2L_PORT_PINMUX(8, 2, 1)>, <RZG2L_PORT_PINMUX(9, 0, 1)>, <RZG2L_PORT_PINMUX(9, 1, 1)>, <RZG2L_PORT_PINMUX(10, 0, 1)>, <RZG2L_PORT_PINMUX(10, 1, 1)>, <RZG2L_PORT_PINMUX(11, 0, 1)>, <RZG2L_PORT_PINMUX(11, 1, 1)>, <RZG2L_PORT_PINMUX(12, 0, 1)>, <RZG2L_PORT_PINMUX(12, 1, 1)>, <RZG2L_PORT_PINMUX(13, 0, 1)>, <RZG2L_PORT_PINMUX(13, 1, 1)>, <RZG2L_PORT_PINMUX(13, 2, 1)>, <RZG2L_PORT_PINMUX(14, 0, 1)>, <RZG2L_PORT_PINMUX(14, 1, 1)>, <RZG2L_PORT_PINMUX(15, 0, 1)>, <RZG2L_PORT_PINMUX(15, 1, 1)>, <RZG2L_PORT_PINMUX(16, 0, 1)>, <RZG2L_PORT_PINMUX(16, 1, 1)>, <RZG2L_PORT_PINMUX(17, 0, 1)>, <RZG2L_PORT_PINMUX(17, 1, 1)>, <RZG2L_PORT_PINMUX(17, 2, 1)>; }; sync { pinmux = <RZG2L_PORT_PINMUX(6, 1, 1)>, /* HSYNC */ <RZG2L_PORT_PINMUX(7, 0, 1)>; /* VSYNC */ }; de { pinmux = <RZG2L_PORT_PINMUX(7, 1, 1)>; /* DE */ }; clk { pinmux = <RZG2L_PORT_PINMUX(6, 0, 1)>; /* CLK */ }; }; };
panel_rgb: panel-rgb { compatible = "arm,rtsm-display"; //<-- this property "arm,rtsm-display" is an example. // please fill in the correct information based on your panel spec. port { panel_in_rgb: endpoint { remote-endpoint = <&du_out_rgb>; }; }; };
&du { pinctrl-0 = <&du_pins>; pinctrl-names = "default"; status = "okay"; ports { port@0 { du_out_rgb: endpoint { remote-endpoint = <&panel_in_rgb>; }; }; }; };
&dsi0 { status = "disabled"; }; |
Example of RGB Panel on RZ/G2L (4.19 kernel only) |
&pinctrl { du_pins: du { data { pinmux = <RZG2L_PORT_PINMUX(7, 2, 1)>, <RZG2L_PORT_PINMUX(8, 0, 1)>, <RZG2L_PORT_PINMUX(8, 1, 1)>, <RZG2L_PORT_PINMUX(8, 2, 1)>, <RZG2L_PORT_PINMUX(9, 0, 1)>, <RZG2L_PORT_PINMUX(9, 1, 1)>, <RZG2L_PORT_PINMUX(10, 0, 1)>, <RZG2L_PORT_PINMUX(10, 1, 1)>, <RZG2L_PORT_PINMUX(11, 0, 1)>, <RZG2L_PORT_PINMUX(11, 1, 1)>, <RZG2L_PORT_PINMUX(12, 0, 1)>, <RZG2L_PORT_PINMUX(12, 1, 1)>, <RZG2L_PORT_PINMUX(13, 0, 1)>, <RZG2L_PORT_PINMUX(13, 1, 1)>, <RZG2L_PORT_PINMUX(13, 2, 1)>, <RZG2L_PORT_PINMUX(14, 0, 1)>, <RZG2L_PORT_PINMUX(14, 1, 1)>, <RZG2L_PORT_PINMUX(15, 0, 1)>, <RZG2L_PORT_PINMUX(15, 1, 1)>, <RZG2L_PORT_PINMUX(16, 0, 1)>, <RZG2L_PORT_PINMUX(16, 1, 1)>, <RZG2L_PORT_PINMUX(17, 0, 1)>, <RZG2L_PORT_PINMUX(17, 1, 1)>, <RZG2L_PORT_PINMUX(17, 2, 1)>; }; sync { pinmux = <RZG2L_PORT_PINMUX(6, 1, 1)>, /* HSYNC */ <RZG2L_PORT_PINMUX(7, 0, 1)>; /* VSYNC */ }; de { pinmux = <RZG2L_PORT_PINMUX(7, 1, 1)>; /* DE */ }; clk { pinmux = <RZG2L_PORT_PINMUX(6, 0, 1)>; /* CLK */ }; }; };
rgb-dummy { compatible = "renesas,rgb-dummy"; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; rgb_in: endpoint { remote-endpoint = <&du_out_rgb>; }; }; port@1 { reg = <1>; rgb_out: endpoint { remote-endpoint = <&panel_in>; }; }; }; };
panel { /* * Define code for panel here such as compatible, backlight, power,... * Can refer drivers/gpu/drm/panel/panel-simple.c */ port { panel_in: endpoint { remote-endpoint = <&rgb_out>; }; }; };
&dsi0 { status = "disabled"; };
&du { pinctrl-0 = <&du_pins>; pinctrl-names = "default"; ports { port@0 { du_out_rgb: endpoint { remote-endpoint = <&rgb_in>; }; }; }; }; |
Audio
Linux Drivers
- RZ/G2H, G2M, G2N, G2E: rz_linux-cip/sound/soc/sh/rcar/*.c
- RZ/G2L, G2LC, G2UL, V2L: rz_linux-cip/sound/soc/sh/rz-ssi.c
Device Tree Examples
Example of MAX9867 codec with MAX98390 Amplifier for RZ/G2L |
Here is an example of a MAX9867 on SSI channel 3, using I2C-3. MAX98390 Amplifier on I2C-2. This is for the Linux-5.10 kernel. For the older Linux-4.19 kernel, there are some differences. Pin Setup &pinctrl { /* MAX98390 Amplifier */ i2c2_pins: i2c2 { pinmux = <RZG2L_PORT_PINMUX(42, 3, 1)>, /* SDA */ <RZG2L_PORT_PINMUX(42, 4, 1)>; /* SCL */ }; /* MAX9867 Codec */ i2c3_pins: i2c3 { pinmux = <RZG2L_PORT_PINMUX(18, 0, 3)>, /* SDA */ <RZG2L_PORT_PINMUX(18, 1, 3)>; /* SCL */ }; ssi3_pins: ssi3 { pinmux = <RZG2L_PORT_PINMUX(31, 0, 5)>, /* BCK */ <RZG2L_PORT_PINMUX(31, 1, 5)>, /* RCK */ <RZG2L_PORT_PINMUX(32, 0, 5)>, /* TXD */ <RZG2L_PORT_PINMUX(32, 1, 5)>; /* RXD */ }; }; Enable SSI channel &ssi3 { pinctrl-0 = <&ssi3_pins>; pinctrl-names = "default"; #sound-dai-cells = <1>; status = "okay"; }; Create a node for the MAX9867 my_snd: sound { compatible = "simple-audio-card"; simple-audio-card,widgets = "Speaker", "Ext Spk"; simple-audio-card,routing = "Ext Spk", "BE_OUT"; "Ext Spk", "LOUT", "Ext Spk", "ROUT"; /* MAX98390 Amplifier */ simple-audio-card,dai-link@0{ format = "i2s"; bitclock-master = <&cpu_dai3>; frame-master = <&cpu_dai3>; mclk-fs = <256>; cpu_dai3: cpu { sound-dai = <&ssi3>; }; codec_dai3: codec { sound-dai = <&max98390>; clocks = <&mclk>; }; }; /* MAX9867 Codec */ simple-audio-card,dai-link@1{ format = "i2s"; bitclock-master = <&cpu_dai0>; frame-master = <&cpu_dai0>; mclk-fs = <256>; cpu_dai0: cpu { sound-dai = <&ssi0>; }; codec_dai0: codec { sound-dai = <&max9867>; clocks = <&mclk>; }; }; };
&i2c2 { pinctrl-0 = <&i2c2_pins>; pinctrl-names = "default"; status = "okay"; clock-frequency = <400000>; /* MAX98390 Amplifier */ max98390: codec@3d { status = "okay"; compatible = "maxim,max98390"; #sound-dai-cells = <0>; reg = <0x3d>; }; }; &i2c3 { pinctrl-0 = <&i2c3_pins>; pinctrl-names = "default"; status = "okay"; clock-frequency = <400000>; /* MAX9867 Codec */ max9867: codec@18 { status = "okay"; compatible = "maxim,max9867"; #sound-dai-cells = <0>; reg = <0x18>; }; };
|
Camera
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- CONFIG_xxx=y
- RZ/G2L, G2LC, G2UL, V2L:
- CONFIG_xxx=y
Notes
Device Tree Examples
- (see device tree for evaluation board)
Ethernet
Linux Drivers
- RZ/G2H, G2M, G2N, G2E, G2L, G2LC, G2UL, V2L:
- rz_linux-cip/drivers/net/ethernet/renesas/ (ravb_main.c, ravb_ptp.c)
- Documentation/devicetree/bindings/net/renesas,etheravb.yaml
- CONFIG_NET_VENDOR_RENESAS=y
- # CONFIG_SH_ETH is not set
- CONFIG_RAVB=y
Notes
- The Link Status input pin (LINKSTA) is not used. The driver instead relies on the PHY to inform it that the link is up by using in-band status messages on the RGMII lines.
- Do not forget to set the correct voltage levels for the pins (3.3v, 1.5v, etc..) in the device tree in the pinctrl node.
- You use the syntax "power-source = <3300>;" when you declare the pins for Ethernet.
- Refer to the pinctrl documentation in the kernel for more info.
- Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml
- Documentation/devicetree/bindings/pinctrl/renesas,pcf.yaml
- In the Device Tree, the MDIO address is set by @x and the "reg =<x>;" For example, MDIO address of 0:
phy0: ethernet-phy@0 { reg = <0>;
Device Tree Examples
Example of enabling MII mode for RZ/G2L |
Ethernet node for MII mode ð0 { pinctrl-0 = <ð0_mii_pins>; pinctrl-names = "default"; phy-handle = <&phy0>; phy-mode = "mii"; status = "okay"; phy0: ethernet-phy@7 { compatible = "ethernet-phy-id0022.1640", "ethernet-phy-ieee802.3-c22"; reg = <7>; rxc-skew-psec = <2400>; txc-skew-psec = <2400>; rxdv-skew-psec = <0>; txdv-skew-psec = <0>; rxd0-skew-psec = <0>; rxd1-skew-psec = <0>; rxd2-skew-psec = <0>; rxd3-skew-psec = <0>; txd0-skew-psec = <0>; txd1-skew-psec = <0>; txd2-skew-psec = <0>; txd3-skew-psec = <0>; interrupt-parent = <&pinctrl>; interrupts = <RZG2L_GPIO(1, 0) IRQ_TYPE_LEVEL_LOW>; }; }; ð1 { pinctrl-0 = <ð1_mii_pins>; pinctrl-names = "default"; phy-handle = <&phy1>; phy-mode = "mii"; status = "okay"; phy1: ethernet-phy@7 { compatible = "ethernet-phy-id0022.1640", "ethernet-phy-ieee802.3-c22"; reg = <7>; rxc-skew-psec = <2400>; txc-skew-psec = <2400>; rxdv-skew-psec = <0>; txdv-skew-psec = <0>; rxd0-skew-psec = <0>; rxd1-skew-psec = <0>; rxd2-skew-psec = <0>; rxd3-skew-psec = <0>; txd0-skew-psec = <0>; txd1-skew-psec = <0>; txd2-skew-psec = <0>; txd3-skew-psec = <0>; interrupt-parent = <&pinctrl>; interrupts = <RZG2L_GPIO(1, 1) IRQ_TYPE_LEVEL_LOW>; }; };
&pinctrl { eth0_mii_pins: eth0 { pinmux = <RZG2L_PORT_PINMUX(28, 1, 1)>, /* ET0_LINKSTA */ <RZG2L_PORT_PINMUX(27, 1, 1)>, /* ET0_MDC */ <RZG2L_PORT_PINMUX(28, 0, 1)>, /* ET0_MDIO */ <RZG2L_PORT_PINMUX(20, 0, 1)>, /* ET0_TXC */ <RZG2L_PORT_PINMUX(20, 1, 1)>, /* ET0_TX_CTL */ <RZG2L_PORT_PINMUX(20, 2, 1)>, /* ET0_TXD0 */ <RZG2L_PORT_PINMUX(21, 0, 1)>, /* ET0_TXD1 */ <RZG2L_PORT_PINMUX(21, 1, 1)>, /* ET0_TXD2 */ <RZG2L_PORT_PINMUX(22, 0, 1)>, /* ET0_TXD3 */ <RZG2L_PORT_PINMUX(22, 1, 1)>, /* ETH0_TX_ERR */ <RZG2L_PORT_PINMUX(23, 0, 1)>, /* ETH0_TX_COL */ <RZG2L_PORT_PINMUX(23, 1, 1)>, /* ETH0_TX_CRS */ <RZG2L_PORT_PINMUX(24, 0, 1)>, /* ET0_RXC */ <RZG2L_PORT_PINMUX(24, 1, 1)>, /* ET0_RX_CTL */ <RZG2L_PORT_PINMUX(25, 0, 1)>, /* ET0_RXD0 */ <RZG2L_PORT_PINMUX(25, 1, 1)>, /* ET0_RXD1 */ <RZG2L_PORT_PINMUX(26, 0, 1)>, /* ET0_RXD2 */ <RZG2L_PORT_PINMUX(26, 1, 1)>, /* ET0_RXD3 */ <RZG2L_PORT_PINMUX(27, 0, 1)>; /* ETH0_RX_ERR */ }; eth1_mii_pins: eth1 { pinmux = <RZG2L_PORT_PINMUX(37, 2, 1)>, /* ET1_LINKSTA */ <RZG2L_PORT_PINMUX(37, 0, 1)>, /* ET1_MDC */ <RZG2L_PORT_PINMUX(37, 1, 1)>, /* ET1_MDIO */ <RZG2L_PORT_PINMUX(29, 0, 1)>, /* ET1_TXC */ <RZG2L_PORT_PINMUX(29, 1, 1)>, /* ET1_TX_CTL */ <RZG2L_PORT_PINMUX(30, 0, 1)>, /* ET1_TXD0 */ <RZG2L_PORT_PINMUX(30, 1, 1)>, /* ET1_TXD1 */ <RZG2L_PORT_PINMUX(31, 0, 1)>, /* ET1_TXD2 */ <RZG2L_PORT_PINMUX(31, 1, 1)>, /* ET1_TXD3 */ <RZG2L_PORT_PINMUX(32, 0, 1)>, /* ETH1_TX_ERR */ <RZG2L_PORT_PINMUX(32, 1, 1)>, /* ETH1_TX_COL */ <RZG2L_PORT_PINMUX(33, 0, 1)>, /* ETH1_TX_CRS */ <RZG2L_PORT_PINMUX(33, 1, 1)>, /* ET1_RXC */ <RZG2L_PORT_PINMUX(34, 0, 1)>, /* ET1_RX_CTL */ <RZG2L_PORT_PINMUX(34, 1, 1)>, /* ET1_RXD0 */ <RZG2L_PORT_PINMUX(35, 0, 1)>, /* ET1_RXD1 */ <RZG2L_PORT_PINMUX(35, 1, 1)>, /* ET1_RXD2 */ <RZG2L_PORT_PINMUX(36, 0, 1)>, /* ET1_RXD3 */ <RZG2L_PORT_PINMUX(36, 1, 1)>; /* ETH1_RX_ERR */ }; }; |
USB
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- RZ/G2L, G2LC, G2UL, V2L:
Host
- (uses standard EHCI and XHCI kernel drivers since H/W API is fixed)
- drivers/usb/host/ehci-hcd.c
- drivers/usb/host/ehci-platform.c
- drivers/usb/host/xhci.c
- drivers/usb/host/xhci-rcar.c
- CONFIG_USB_EHCI_HCD=y
- CONFIG_XHCI_PLATFORM=y
- CONFIG_XHCI_RCAR=y
Device
- drivers/usb/renesas_usbhs/*
- USB_RENESAS_USBHS=y
PHY
- The PHY is a separate H/W block. Also used to control host/device switching for OTG.
- drivers/phy/renesas/*
- CONFIG_PHY_RCAR_GEN3_USB2=y
- CONFIG_PHY_RCAR_GEN3_USB3=y
Notes
- Disable OverCurrent Protection Interrupts:
- If you did not connect the USB_OVCUR pin on your board, and it floats, you will get interrupt messages about over current. However, you can disable this interrupt by modifying the setting for the OHCI HcRhDescriptorA Register and setting bit NOCP to '1'. Search for "HcRhDescriptorA" in the hardware manual for more information.
- In the kernel, in file drivers/usb/host/ohci-hcd.c, you want to comment out the line:
- /* Configure for per-port over-current protection by default */
- val &= ~RH_A_NOCP;
- In u-boot, can see this is sometimes done for Renesas boards. See file board/renesas/rzg2l-dev/rzg2l-dev.c
- (*(volatile u32 *)(USB1_BASE + HcRhDescriptorA)) |= (0x1u << 12); /* NOCP = 1 */
- Dynamic changing from Device and Host for OTG:
- If you are using a device as OTG (On-the-Go) and want to change from device to you, you set a sysfs setting under the PHY driver (not the USB controller driver)
- $ echo host > /sys/devices/platform/soc/ee080200.usb-phy/role
Device Tree Examples
- (see device tree for evaluation board)
SD Card
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- CONFIG_xxx=y
- RZ/G2L, G2LC, G2UL, V2L:
- CONFIG_xxx=y
Notes
- Same as eMMC: The drivers for SD Card and SDIO are the same as eMMC. Please the section on eMMC.
- 3.3v Only: If you only provide 3.3v (do not support dynamically switching to 1.8v for UHS), then you should add the no-1-8-v; flag to the sdhi node. This flag is used for both kernel and u-boot device trees.
- vmmc-supply: This is the voltage regulator connected to the SD card VDD pin. It could be a constant fixed 3.3v, or it be attached to a regulator that you can turn off to save power.
- vqmmc-supply: This is the voltage regulator that the pull-ups for the data lines go to. For high speed SD, they will change from 3.3v to 1.8v.
Device Tree Examples
- (see device tree for evaluation board)
RZ/G2L SMARC Device Tree Example |
/ { reg_3p3v: regulator1 { compatible = "regulator-fixed"; regulator-name = "fixed-3.3V"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; regulator-boot-on; regulator-always-on; }; vccq_sdhi1: regulator-vccq-sdhi1 { compatible = "regulator-gpio"; regulator-name = "SDHI1 VccQ"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <3300000>; gpios-states = <1>; states = <3300000 1>, <1800000 0>; }; }; &sdhi1 { pinctrl-0 = <&sdhi1_pins>; pinctrl-1 = <&sdhi1_pins_uhs>; pinctrl-names = "default", "state_uhs"; vmmc-supply = <®_3p3v>; vqmmc-supply = <&vccq_sdhi1>; bus-width = <4>; sd-uhs-sdr50; sd-uhs-sdr104; status = "okay"; }; |
eMMC
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- RZ/G2L, G2LC, G2UL, V2L:
- driver/mmc/host/renesas_sdhi.h
- driver/mmc/host/renesas_sdhi_core.c
- driver/mmc/host/renesas_sdhi_internal_dmac.c
- driver/mmc/host/tmio_mmc.h
- driver/mmc/host/tmio_mmc_core.c
- CONFIG_MMC_SDHI=y
- CONFIG_MMC_SDHI_INTERNAL_DMAC=y (selected automatically by MMC_SDHI)
- CONFIG_MMC_TMIO_CORE=y (selected automatically by MMC_SDHI)
Notes
- Combo driver for MMC + SDHI HW
- The core of the SDHI code is using the TMIO (Toshiba Mobile IO) driver because it is the same HW block and they have shared the same driver for many years.
- CONFIG_MMC_SDHI_SYS_DMAC=y is selected automatically by MMC_SDHI, but is only for RZ/G1 series devices.
- Note that if you are using more than one mmc/sdhi channel, you might run into the issue that you don't get the same device number (ie, /dev/mmcblk0) each time you boot. To fix this, simply add an 'alias' to the top of your Device Tree to make each channel a fixed number. As an example:
aliases { mmc0 = &sdhi3; // eMMC Flash for rootfs mmc1 = &sdhi0; // SD Card Socket mmc2 = &sdhi2; // SDIO for WiFi };
Device Tree Examples
- (see device tree for evaluation board)
DMA
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- drivers/dma/sh/*
- CONFIG_RCAR_DMAC=y
- RZ/G2L, G2LC, G2UL, V2L:
- drivers/dma/sh/rz-dma.c
- CONFIG_RZ_DMAC=y
Notes
RZ/G2L, RZ/V2L, How to determine 'dmas' value
- Given the Device Tree example below for SPI-1, you will need to determine the values for the "tx" and "rx" DMA triggers.
&spi1 { pinctrl-0 = <&spi1_pins>; pinctrl-names = "default"; dmas = <&dmac 0x2e99 >, <&dmac 0x2e9a >; dma-names = "tx", "rx"; status = "okay"; };
- You can find some explanation in the kernel documentation: Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
'#dma-cells': const: 1 description: The cell specifies the encoded MID/RID values of the DMAC port connected to the DMA client and the slave channel configuration parameters. bits[0:9] - Specifies MID/RID value bit[10] - Specifies DMA request high enable (HIEN) bit[11] - Specifies DMA request detection type (LVL) bits[12:14] - Specifies DMAACK output mode (AM) bit[15] - Specifies Transfer Mode (TM)
- These values are what get written directly to the DMA registers. Also, the values for these bits are fixed and shown in a table in the hardware manual.
- If you look in the Direct Memory Access Control (DMA) chapter in the hardware manual, you will find the table "On-Chip Module Requests"
Example: RZ/G2L RSPI ch1
SPIT1 (tranmit buffer empty) dma-names = "tx"
MID[7:0] = 10100110'b
RID[1:0] = 01'b
HEIN = 1'b
LVL = 1'b
AM[2:0] = 010'b
TM = 0'b
AM HEIN RID
| | |
0 010 1 1 10100110 01 = 0010 1110 1001 1001 = 0x2e99
| | |
TM LVL MID
SPIR1 (receive buffer full)
dma-names = "rx"
MID[7:0] = 10100110'b
RID[1:0] = 10'b
HEIN = 1'b
LVL = 1'b
AM[2:0] = 010'b
TM = 0'b
AM HEIN RID
| | |
0 010 1 1 10100110 10 = 0010 1110 1001 1010 = 0x2e9a
| | |
TM LVL MID
Device Tree Examples
- (see device tree for evaluation board)
I2C
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- CONFIG_xxx=y
- RZ/G2L, G2LC, G2UL, V2L:
- drivers/i2c/busses/ i2c-riic.c
- CONFIG_I2C_RIIC=y
Notes
Device Tree Examples
- (see device tree for evaluation board)
SPI
Linux Drivers
- MSIOF: RZ/G2H, G2M, G2N, G2E:
- CONFIG_xxx=y
- RSPI: RZ/G2L, G2LC, G2UL, V2L:
- drivers/spi/spi-rspi.c
- CONFIG_SPI_RSPI=y
Notes
- spidev:
- If you want a generic SPI device (/dev/spi-0), in the past you would allocate a compatible = "spidev"; node. Unfortunately, that spidev name has been removed from Linux (since Linux-5.17). However, you can still create a spidev device by simply using another name that is already in the kernel. The compatible name will be different, but it will work the exact same way.
- Below is the list of device that can be used with spidev from file drivers/spi/spidev.c
static const struct of_device_id spidev_dt_ids[] = { { .compatible = "rohm,dh2228fv" }, { .compatible = "lineartechnology,ltc2488" }, { .compatible = "ge,achc" }, { .compatible = "semtech,sx1301" }, { .compatible = "lwn,bk4" }, { .compatible = "dh,dhcom-board" }, { .compatible = "menlo,m53cpld" }, {}, };
- For example, if you just pick the first name in the list ("rohm,dh2228fv") this will work on any kernel version:
&spi1 { pinctrl-0 = <&spi1_pins>; pinctrl-names = "default"; status = "okay"; dmas = <&dmac 0x2e99>, <&dmac 0x2e9a>; dma-names = "tx", "rx"; spidev@0{ compatible = "rohm,dh2228fv"; // (Using fake name to use spidev driver) reg = <0>; spi-max-frequency = <1000000>; }; };
Device Tree Examples
- (see device tree for evaluation board)
QSPI Flash
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- drivers/spi/spi-rpc-if.c
- drivers/memory/renesas-rpc-if.c
- drivers/mtd/hyperbus/rpc-if.c
- CONFIG_SPI_RPCIF=y
- CONFIG_RENESAS_RPCIF=y
- CONFIG_RPCIF_HYPERBUS=y
- RZ/G2L, G2LC, G2UL, V2L:
- CONFIG_xxx=y
Notes
- unrecognized JEDEC id bytes: If when booting the kernel, you get a message like:
[ 2.328844] rpc-if-spi rpc-if-spi: registered master spi2 [ 2.328891] spi spi2.0: setup mode 0, 8 bits/w, 50000000 Hz max --> 0 [ 2.329230] spi-nor spi2.0: unrecognized JEDEC id bytes: 1f 87 01 1f 87 01
it means this nor flash is not supported in the Linux kernel. To support this flash, you should add this flash info in "static const struct flash_info atmel_parts[]" in drivers/mtd/spi-nor/atmel.c:
{ "at25sf321", INFO(0x1f8701, 0, 64 * 1024, 64, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
Device Tree Examples
- (see device tree for evaluation board)
UART (SCIF)
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- CONFIG_xxx=y
- RZ/G2L, G2LC, G2UL, V2L:
- CONFIG_xxx=y
Notes
Device Tree Examples
- (see device tree for evaluation board)
UART (SCI)
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- CONFIG_xxx=y
- RZ/G2L, G2LC, G2UL, V2L:
- CONFIG_xxx=y
Notes
Device Tree Examples
- (see device tree for evaluation board)
CAN
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- RZ/G2L, G2LC, G2UL, V2L:
- drivers/net/can/rcar/*
- CONFIG_CAN_RCAR=y
- CONFIG_CAN_RCAR_FD=y
Notes
- CAN-FD is enabled by default. To switch to CAN protocol, a user can add property "renesas,no-can-fd" in the Device Tree
- Example setup commands:
- Classic CAN: $ ip link set can1 type can bitrate 125000
- CAN-FD: $ ip link set can1 type can bitrate 333333 dbitrate 666666 fd on
Device Tree Examples
- (see device tree for evaluation board)
ADC
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- CONFIG_xxx=y
- RZ/G2L, G2LC, G2UL, V2L:
- CONFIG_xxx=y
Notes
Device Tree Examples
- (see device tree for evaluation board)
Watchdog Timer(WDT)
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- rz_linux-cip/drivers/watchdog/renesas_wdt.c
- CONFIG_RENESAS_WDT
- RZ/G2L, G2LC, G2UL, V2L:
- rz_linux-cip/drivers/watchdog/rzg2l_wdt.c
- CONFIG_RENESAS_RZG2LWDT
Notes
- When rebooting the system, the watchdog timer is used. Simply type the command line "reboot" in the console.
- To test a watch dog timeout/reboot, enter this command in the console "cat >> /dev/watchdog", then press ENTER again, then wait 1 minutes, and the board should reboot.
- RZ/G2L: Reset on a WDT Timeout: There is a register in the CPG (WDT Reset Selector Register - CPG_WDTRST_SEL) to control if the WDT will reset the system or not. To generate a system RESET, you need to set it to 0x00010001. You can do this in u-boot, or when the kernel boots (in the CPG driver, not the WDT driver).
# Add this code to u-boot #define CPG_WDTRST_SEL (CPG_BASE + 0xB14) *(volatile u32 *)(CPG_WDTRST_SEL) = 0x00010001; - or - # Add this code to the kernel CPG driver # FILE: drivers/clk/renesas/rzg2l-cpg.c # FUNCTION: rzg2l_cpg_probe() # LINE: Before the 'return 0;' at the end of the funtion writel(0x00010001, (priv->base + 0xB14));
- RZ/G2L: Toggle WDTOVF_PERROUT# Note that by default, the WDTOVF_PERROUT# pin will not toggle on a WDT reboot. You need to set the CPG_WDTRST_SEL register manually in u-boot since Linux never touches that register. For example:
#define CPG_WDTRST_SEL (CPG_BASE + 0xB14) *(volatile u32 *)(CPG_WDTRST_SEL) = 0x00100010;
Device Tree Examples
- (see device tree for evaluation board)
PWM
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- CONFIG_xxx=y
- RZ/G2L, G2LC, G2UL, V2L:
- CONFIG_xxx=y
Notes
Device Tree Examples
- (see device tree for evaluation board)
Timer
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- CONFIG_xxx=y
- RZ/G2L, G2LC, G2UL, V2L:
- CONFIG_xxx=y
Notes
Device Tree Examples
- (see device tree for evaluation board)
Thermal
Linux Drivers
- RZ/G2H, G2M, G2N, G2E:
- drivers/thermal/rcar_gen3__thermal.c
- CONFIG_RCAR_GEN3_THERMAL=y
- RZ/G2L, G2LC, G2UL, V2L:
- drivers/thermal/rzg2l_thermal.c
- CONFIG_RZG2L_THERMAL=y
Notes
- The Linux driver reads the registers and applies the formula in the hardware manual
- You can read the current value running the command:
- $ cat /sys/class/thermal/thermal_zone0/temp
- The output value is in millicelsius
Device Tree Examples
- (see device tree for evaluation board)
PMIC RAA215300
Linux Drivers
- drivers/mfd/raa215300.c
- CONFIG_PMIC_RAA215300=y
- Documentation/devicetree/bindings/mfd/raa215300.txt
Notes
- Only supports RTC function
- Added in VLP/G v3.0.1 release (branch rz-5.10-cip13)
Device Tree Examples
- (see device tree for evaluation board)