- 12 Aug, 2015 10 commits
-
-
Geert Uytterhoeven authored
Add an appropriate "#power-domain-cells" property to the cpg_clocks device node, to create the CPG/MSTP Clock Domain. Add "power-domains" properties to all device nodes for devices that are part of the CPG/MSTP Clock Domain and can be power-managed through an MSTP clock. This applies to most on-SoC devices, which have a one-to-one mapping from SoC device to DT device node. Notable exceptions are the "display" and "sound" nodes, which represent multiple SoC devices, each having their own MSTP clocks. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au>
-
Geert Uytterhoeven authored
Add an appropriate "#power-domain-cells" property to the cpg_clocks device node, to create the CPG/MSTP Clock Domain. Add "power-domains" properties to all device nodes for devices that are part of the CPG/MSTP Clock Domain and can be power-managed through an MSTP clock. This applies to most on-SoC devices, which have a one-to-one mapping from SoC device to DT device node. Signed-off-by:
-
Geert Uytterhoeven authored
Add an appropriate "#power-domain-cells" property to the cpg_clocks device node, to create the CPG/MSTP Clock Domain. Add "power-domains" properties to all device nodes for devices that are part of the CPG/MSTP Clock Domain and can be power-managed through an MSTP clock. This applies to most on-SoC devices, which have a one-to-one mapping from SoC device to DT device node. A notable exception is the "sound" node, which represents multiple SoC devices, each having their own MSTP clocks. Signed-off-by:
-
Geert Uytterhoeven authored
Add an appropriate "#power-domain-cells" property to the cpg_clocks device node, to create the CPG/MSTP Clock Domain. Add "power-domains" properties to all device nodes for devices that are part of the CPG/MSTP Clock Domain and can be power-managed through an MSTP clock. This applies to most on-SoC devices, which have a one-to-one mapping from SoC device to DT device node. Signed-off-by:
-
Simon Horman authored
-
Geert Uytterhoeven authored
Add Clock Domain support to the RZ Clock Pulse Generator (CPG) driver using the generic PM Domain. This allows to power-manage the module clocks of SoC devices that are part of the CPG/MSTP Clock Domain using Runtime PM, or for system suspend/resume. SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed through an MSTP clock should be tagged in DT with a proper "power-domains" property. Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Reviewed-by:
-
Geert Uytterhoeven authored
Add Clock Domain support to the R-Car Gen2 Clock Pulse Generator (CPG) driver using the generic PM Domain. This allows to power-manage the module clocks of SoC devices that are part of the CPG/MSTP Clock Domain using Runtime PM, or for system suspend/resume. SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed through an MSTP clock should be tagged in DT with a proper "power-domains" property. Signed-off-by:
-
Geert Uytterhoeven authored
Add Clock Domain support to the R-Car H1 Clock Pulse Generator (CPG) driver using the generic PM Domain. This allows to power-manage the module clocks of SoC devices that are part of the CPG/MSTP Clock Domain using Runtime PM, or for system suspend/resume. SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed through an MSTP clock should be tagged in DT with a proper "power-domains" property. Also update the reg property in the DT binding doc example to match the actual dtsi, which uses #address-cells and #size-cells == 1, not 2. Signed-off-by:
-
Geert Uytterhoeven authored
Add Clock Domain support to the R-Car M1A Clock Pulse Generator (CPG) driver using the generic PM Domain. This allows to power-manage the module clocks of SoC devices that are part of the CPG/MSTP Clock Domain using Runtime PM, or for system suspend/resume. SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed through an MSTP clock should be tagged in DT with a proper "power-domains" property. Signed-off-by:
-
Geert Uytterhoeven authored
Add Clock Domain support to the Clock Pulse Generator (CPG) Module Stop (MSTP) Clocks driver using the generic PM Domain. This allows to power-manage the module clocks of SoC devices that are part of the CPG/MSTP Clock Domain using Runtime PM, or for system suspend/resume. SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed through an MSTP clock should be tagged in DT with a proper "power-domains" property. The CPG/MSTP Clock Domain code will scan such devices for clocks that are suitable for power-managing the device, by looking for a clock that is compatible with "renesas,cpg-mstp-clocks". Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Kevin Hilman <khilman@linaro.org> Signed-off-by:
-
- 04 Aug, 2015 3 commits
-
-
Geert Uytterhoeven authored
If a GPIO driver uses gpiochip_add_pin_range() (which is usually the case for GPIO/PFC combos), the GPIO hogging mechanism configured from DT doesn't work: requesting hog GPIO led1-high (chip sh73a0_pfc, offset 20) failed The actual error code is -517 == -EPROBE_DEFER. The problem is that PFC+GPIO registration is handled in multiple steps: 1. pinctrl_register(), 2. gpiochip_add(), 3. gpiochip_add_pin_range(). Configuration of the hogs is handled in gpiochip_add(): gpiochip_add of_gpiochip_add of_gpiochip_scan_hogs gpiod_hog gpiochip_request_own_desc __gpiod_request chip->request pinctrl_request_gpio pinctrl_get_device_gpio_range However, at this point the GPIO controller hasn't been added to pinctrldev_list yet, so the range can't be found, and the operation fails with -EPROBE_DEFER. To fix this, add a "gpio-ranges" property to the gpio device node, so the ranges are added by of_gpiochip_add_pin_range(), which is called by of_gpiochip_add() before the call to of_gpiochip_scan_hogs(). Signed-off-by:Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Geert Uytterhoeven authored
If a GPIO driver uses gpiochip_add_pin_range() (which is usually the case for GPIO/PFC combos), the GPIO hogging mechanism configured from DT doesn't work: requesting hog GPIO lcd0 (chip r8a7740_pfc, offset 176) failed The actual error code is -517 == -EPROBE_DEFER. The problem is that PFC+GPIO registration is handled in multiple steps: 1. pinctrl_register(), 2. gpiochip_add(), 3. gpiochip_add_pin_range(). Configuration of the hogs is handled in gpiochip_add(): gpiochip_add of_gpiochip_add of_gpiochip_scan_hogs gpiod_hog gpiochip_request_own_desc __gpiod_request chip->request pinctrl_request_gpio pinctrl_get_device_gpio_range However, at this point the GPIO controller hasn't been added to pinctrldev_list yet, so the range can't be found, and the operation fails with -EPROBE_DEFER. To fix this, add a "gpio-ranges" property to the gpio device node, so the range is added by of_gpiochip_add_pin_range(), which is called by of_gpiochip_add() before the call to of_gpiochip_scan_hogs(). Signed-off-by: -
Geert Uytterhoeven authored
If a GPIO driver uses gpiochip_add_pin_range() (which is usually the case for GPIO/PFC combos), the GPIO hogging mechanism configured from DT doesn't work: requesting hog GPIO led1-high (chip r8a73a4_pfc, offset 28) failed The actual error code is -517 == -EPROBE_DEFER. The problem is that PFC+GPIO registration is handled in multiple steps: 1. pinctrl_register(), 2. gpiochip_add(), 3. gpiochip_add_pin_range(). Configuration of the hogs is handled in gpiochip_add(): gpiochip_add of_gpiochip_add of_gpiochip_scan_hogs gpiod_hog gpiochip_request_own_desc __gpiod_request chip->request pinctrl_request_gpio pinctrl_get_device_gpio_range However, at this point the GPIO controller hasn't been added to pinctrldev_list yet, so the range can't be found, and the operation fails with -EPROBE_DEFER. To fix this, add a "gpio-ranges" property to the gpio device node, so the ranges are added by of_gpiochip_add_pin_range(), which is called by of_gpiochip_add() before the call to of_gpiochip_scan_hogs(). Signed-off-by:
-
- 03 Aug, 2015 2 commits
-
-
Sergei Shtylyov authored
Define the SILK board dependent part of the MMCIF device node (the board has eMMC chip) along with the necessary voltage regulator (note that the Vcc/Vccq regulator is dummy -- it's required by the MMCIF driver but doesn't actually exist on the board). Based on the original patch by Vladimir Barinov <vladimir.barinov@cogentembedded.com>. Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
Sergei Shtylyov authored
Define the generic R8A7794 part of the MMCIF0 device node. Based on the orginal patch by Shinobu Uehara <shinobu.uehara.xc@renesas.com>. Signed-off-by:
-
- 30 Jul, 2015 2 commits
-
-
Sergei Shtylyov authored
Define the SILK board dependent part of the Ether device node. Enable DHCP and NFS root for the kernel booting. Based on the original patch by Vladimir Barinov <vladimir.barinov@cogentembedded.com>. Signed-off-by:
-
Sergei Shtylyov authored
Add the initial device tree for the R8A7794 SoC based SILK low cost board. SCIF2 serial port support is included, so that the serial console can work. Based on the original patch by Vladimir Barinov <vladimir.barinov@cogentembedded.com>. Signed-off-by:
-
- 28 Jul, 2015 3 commits
-
-
Sergei Shtylyov authored
Define the generic R8A7794 part of the PFC device node. Based on original patch by Hisashi Nakamura <hisashi.nakamura.ak@renesas.com>. Signed-off-by:
-
Mikhail Ulyanov authored
This patch contains device tree node definition for JPEG codec peripheral found in the Renesas R-Car r8a7791 SoC. Signed-off-by:
Mikhail Ulyanov <mikhail.ulyanov@cogentembedded.com> Signed-off-by:
-
Mikhail Ulyanov authored
This patch contains device tree node definition for JPEG codec peripheral found in the Renesas R-Car r8a7790 SoC. Signed-off-by:
-
- 22 Jul, 2015 5 commits
-
-
Kuninori Morimoto authored
Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
-
Kuninori Morimoto authored
Signed-off-by:
-
Kuninori Morimoto authored
Signed-off-by:
Keita Kobayashi <keita.kobayashi.ym@renesas.com> Signed-off-by:
-
Kuninori Morimoto authored
Signed-off-by:
-
Laurent Pinchart authored
The adv7511 IRQ is low level triggered, not falling edge triggered. The wrong sense configuration results in no interrupt being triggered at all, breaking hotplug detection. Fix it. Reported-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by:
-
- 15 Jul, 2015 4 commits
-
-
Kuninori Morimoto authored
It is easy to modify settings for Test or other purpose if sound has label Signed-off-by:
-
Kuninori Morimoto authored
It is easy to modify settings for Test or other purpose if sound has label Signed-off-by:
-
Wolfram Sang authored
Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
-
Wolfram Sang authored
Signed-off-by:
-
- 06 Jul, 2015 11 commits
-
-
Magnus Damm authored
Adjust the r8a7779 SoC DTS and the Marzen Reference C board code to use DTS only for INTC-IRQPIN IRLM setup. Signed-off-by:
Magnus Damm <damm+renesas@opensource.se> Acked-by:
-
Geert Uytterhoeven authored
Replace the "arm,cortex-a15-gic" compatible value for the GIC by "arm,gic-400", as the R-Car Gen2 GIC is assumed to be a GIC-400. This has been confirmed by reading the GICD_IIDR register (on r8a7791), which reports 0x0200043b (GIC-400 = 0x02, ARM = 0x43b). This has no effect on runtime behavior, as currently the GIC driver treats both compatible values the same. Signed-off-by:
-
Geert Uytterhoeven authored
Replace the "arm,cortex-a15-gic" compatible value for the GIC by "arm,gic-400", as the R-Car Gen2 GIC is assumed to be a GIC-400. This has been confirmed by reading the GICD_IIDR register (on r8a7791), which reports 0x0200043b (GIC-400 = 0x02, ARM = 0x43b). This has no effect on runtime behavior, as currently the GIC driver treats both compatible values the same. Signed-off-by:
-
Geert Uytterhoeven authored
Replace the "arm,cortex-a15-gic" compatible value for the GIC by "arm,gic-400", as the R-Car Gen2 GIC is assumed to be a GIC-400. This has been confirmed by reading the GICD_IIDR register, which reports 0x0200043b (GIC-400 = 0x02, ARM = 0x43b). This has no effect on runtime behavior, as currently the GIC driver treats both compatible values the same. Signed-off-by:
-
Geert Uytterhoeven authored
Replace the "arm,cortex-a15-gic" compatible value for the GIC by "arm,gic-400", as the R-Car Gen2 GIC is assumed to be a GIC-400. This has been confirmed by reading the GICD_IIDR register (on r8a7791), which reports 0x0200043b (GIC-400 = 0x02, ARM = 0x43b). This has no effect on runtime behavior, as currently the GIC driver treats both compatible values the same. Signed-off-by:
-
Geert Uytterhoeven authored
Replace the "arm,cortex-a15-gic" compatible value for the GIC by "arm,gic-400", as the documentation states it's a GIC-400. This has been confirmed by reading the GICD_IIDR register, which reports 0x0200043b (GIC-400 = 0x02, ARM = 0x43b). This has no effect on runtime behavior, as currently the GIC driver treats both compatible values the same. Signed-off-by:
-
Geert Uytterhoeven authored
Configure pinctrl and a GPIO-controller board mux for LCD use. This allows the armadillo800eva board staging code to enable lcdc0. Signed-off-by:
-
Sergei Shtylyov authored
Define the generic R8A7790 part of the EtherAVB device node. Based on original patch by Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>. Signed-off-by:
-
Sergei Shtylyov authored
Add the EtherAVB clock to the R8A7790 device tree. Based on original patch by Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>. Signed-off-by:
-
Ulrich Hecht authored
Minimal DT description and Makefile entry for the Gose eval board. Support for console, timer, and Ethernet. Signed-off-by:
Ulrich Hecht <ulrich.hecht+renesas@gmail.com> Acked-by:
-
Ulrich Hecht authored
Minimal r8a7793 device tree including one CPU core, interrupt controllers, timers, two serial ports, and the Ethernet controller, plus the required clock descriptions. Signed-off-by:
-
