- 05 Apr, 2017 2 commits
-
-
Geert Uytterhoeven authored
The current practice is to not add _clk suffixes to clock node names in DT, as these names are used as the actual clock names. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au>
-
Jacopo Mondi authored
Enable the 32.768 kHz RTC_X1 clock by setting the frequency value to non-zero and enable the realtime clock. Signed-off-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by:
-
- 04 Apr, 2017 6 commits
-
-
Chris Brandt authored
Enable the realtime clock. Signed-off-by:
Chris Brandt <chris.brandt@renesas.com> Reviewed-by:
-
Chris Brandt authored
Enable the 32.768 kHz RTC_X1 clock by setting the frequency value to non-zero. Signed-off-by:
-
Chris Brandt authored
Add the realtime clock device node. Signed-off-by:
-
Chris Brandt authored
Add the RTC clocks to device tree. The frequencies must be fixed values according to the hardware manual. Signed-off-by:
-
Chris Brandt authored
Add the realtime clock functional clock source. Signed-off-by:
-
Geert Uytterhoeven authored
The X2 crystal oscillator on the Koelsch development board provides a 74.25 MHz clock, not a 148.5 MHz clock. Fixes: cd21cb46 ("ARM: shmobile: koelsch: Add DU external pixel clocks to DT") Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
-
- 03 Apr, 2017 6 commits
-
-
Geert Uytterhoeven authored
Add the Z2 clock (Cortex-A7 CPU core clock), which uses a fixed divider, and link the first CPU node to it. Signed-off-by:
-
Geert Uytterhoeven authored
Unlike other R-Car Gen2 SoCs with Cortex-A15 CPU cores, R-Car V2H does not have a programmable Z clock (Cortex-A15 CPU core clock), but uses a fixed divider. This is similar to the Z2 clock (Cortex-A7 CPU core clock) on R-Car E2. Hence: - Remove the Z clock output from the cpg_clocks node, as this implied a programmable clock, - Add the Z clock as a fixed factor clock, - Let the first CPU node point to the new Z clock, - Remove the Z clock index from the bindings (this definition was used by r8a7792.dtsi only, and was not a contract between DT and driver). Fixes: 7c4163aa ("ARM: dts: r8a7792: initial SoC device tree") Signed-off-by: -
Geert Uytterhoeven authored
The SSI-ALL gate clock is located in between the P clock and the individual SSI[0-9] clocks, hence the former should be listed as their parent. Fixes: 072d3265 ("ARM: dts: r8a7793: add MSTP10 clocks to device tree") Signed-off-by:
-
Geert Uytterhoeven authored
The SSI-ALL gate clock is located in between the P clock and the individual SSI[0-9] clocks, hence the former should be listed as their parent. Fixes: ee914152 ("ARM: shmobile: r8a7791: add MSTP10 support on DTSI") Signed-off-by:
-
Geert Uytterhoeven authored
The SSI-ALL gate clock is located in between the P clock and the individual SSI[0-9] clocks, hence the former should be listed as their parent. Fixes: bcde3722 ("ARM: shmobile: r8a7790: add MSTP10 support on DTSI") Signed-off-by:
-
Chris Brandt authored
Technically, the Ethernet block is run off the 133MHz Bus (B) clock, not the 33MHz Peripheral 0 (P0) clock. Fixes: 969244f9 ("ARM: dts: r7s72100: add ethernet clock to device tree") Signed-off-by:
-
- 28 Mar, 2017 4 commits
-
-
Geert Uytterhoeven authored
The second channel of the display unit uses a different module clock than the first channel. Fixes: 84e734f4 ("ARM: dts: silk: add DU DT support") Signed-off-by:
-
Geert Uytterhoeven authored
The second channel of the display unit uses a different module clock than the first channel. Fixes: 876e7fb9 ("ARM: shmobile: r8a7794: alt: Enable VGA port") Signed-off-by:
-
Geert Uytterhoeven authored
The second channel of the display unit uses a different module clock than the first channel. Fixes: 46c4f13d ("ARM: shmobile: r8a7794: Add DU node to device tree") Signed-off-by:
-
Geert Uytterhoeven authored
Add the missing module clock for the second channel of the display unit. Signed-off-by:
-
- 24 Mar, 2017 1 commit
-
-
Chris Brandt authored
Reported-by:
-
- 21 Mar, 2017 2 commits
-
-
Geert Uytterhoeven authored
Add properties to describe the reset topology for on-SoC devices: - Add the "#reset-cells" property to the CPG/MSSR device node, - Add resets and reset-names properties to the various device nodes. This allows to reset SoC devices using the Reset Controller API. Note that all resets added match the corresponding module clocks. Signed-off-by:
-
Geert Uytterhoeven authored
Add properties to describe the reset topology for on-SoC devices: - Add the "#reset-cells" property to the CPG/MSSR device node, - Add resets and reset-names properties to the various device nodes. This allows to reset SoC devices using the Reset Controller API. Note that all resets added match the corresponding module clocks. Signed-off-by:
-
- 13 Mar, 2017 10 commits
-
-
Geert Uytterhoeven authored
The scif_clk device node is already enabled in r8a7794.dtsi, so there is no need to update its status again. Signed-off-by:
-
Geert Uytterhoeven authored
The scif_clk device node is already enabled in r8a7794.dtsi, so there is no need to update its status again. Signed-off-by:
-
Geert Uytterhoeven authored
The scif_clk device node is already enabled in r8a7793.dtsi, so there is no need to update its status again. Signed-off-by:
-
Geert Uytterhoeven authored
The pcie_bus_clk device node is already enabled in r8a7791.dtsi, so there is no need to update its status again. Signed-off-by:
-
Geert Uytterhoeven authored
The scif_clk and pcie_bus_clk device nodes are already enabled in r8a7791.dtsi, so there is no need to update their statuses again. Signed-off-by:
-
Geert Uytterhoeven authored
The scif_clk device node is already enabled in r8a7790.dtsi, so there is no need to update its status again. Signed-off-by:
-
Geert Uytterhoeven authored
The scif_clk device node is already enabled in r8a7779.dtsi, so there is no need to update its status again. Signed-off-by:
-
Geert Uytterhoeven authored
The scif_clk device node is already enabled in r8a7778.dtsi, so there is no need to update its status again. Signed-off-by:
-
Geert Uytterhoeven authored
While status "ok" does work, the canonical form is "okay", so update the few places that used the former. Signed-off-by:
-
Geert Uytterhoeven authored
Link the ARM GIC to the INTC-SYS module clock, and add it to the "always on" PM Domain, so it can be power managed using that clock. Note that currently the GIC-400 driver doesn't support module clocks nor Runtime PM, so this must be handled as a critical clock. Signed-off-by:
-
- 10 Mar, 2017 8 commits
-
-
Kuninori Morimoto authored
Current Audio-DMAC is assigned "rx" as Audio-DMAC0, "tx" as Audio-DMAC1. Thus, DVC "tx" should be assigned as Audio-DMAC1, instead of Audio-DMAC0. Because of this, current platform board (using SRC/DVC/SSI) Playback/Capture both will use same Audio-DMAC0 (but it depends on audio data path). First note is that this "rx" and "tx" are from each IP point, it doesn't mean Playback/Capture. Second note is that Audio DMAC assigned on DT is only for Audio-DMAC, Audio-DMAC-peri-peri has no entry. => Audio-DMAC -> Audio-DMAC-peri-peri -- HW connection Playback case [Mem] => [SRC]--[DVC] -> [SSI]--[Codec] rx ~~~~~~~~~~~~ Capture [Mem] <= [DVC]--[SRC] <- [SSI]--[Codec] tx ~~~~~~~~~~~~ Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
-
Kuninori Morimoto authored
Current Audio-DMAC is assigned "rx" as Audio-DMAC0, "tx" as Audio-DMAC1. Thus, DVC "tx" should be assigned as Audio-DMAC1, instead of Audio-DMAC0. Because of this, current platform board (using SRC/DVC/SSI) Playback/Capture both will use same Audio-DMAC0 (but it depends on audio data path). First note is that this "rx" and "tx" are from each IP point, it doesn't mean Playback/Capture. Second note is that Audio DMAC assigned on DT is only for Audio-DMAC, Audio-DMAC-peri-peri has no entry. => Audio-DMAC -> Audio-DMAC-peri-peri -- HW connection Playback case [Mem] => [SRC]--[DVC] -> [SSI]--[Codec] rx ~~~~~~~~~~~~ Capture [Mem] <= [DVC]--[SRC] <- [SSI]--[Codec] tx ~~~~~~~~~~~~ Signed-off-by:
-
Geert Uytterhoeven authored
Link the ARM GIC to the INTC-SYS module clock, and add it to the "always on" PM Domain, so it can be power managed using that clock. Note that currently the GIC-400 driver doesn't support module clocks nor Runtime PM, so this must be handled as a critical clock. Signed-off-by:
-
Geert Uytterhoeven authored
Link the ARM GIC to the INTC-SYS module clock, and add it to the "always on" PM Domain, so it can be power managed using that clock. Note that currently the GIC-400 driver doesn't support module clocks nor Runtime PM, so this must be handled as a critical clock. Signed-off-by:
-
Geert Uytterhoeven authored
Link the ARM GIC to the INTC-SYS module clock, and add it to the "always on" PM Domain, so it can be power managed using that clock. Note that currently the GIC-400 driver doesn't support module clocks nor Runtime PM, so this must be handled as a critical clock. Signed-off-by:
-
Geert Uytterhoeven authored
Link the ARM GIC to the INTC-SYS module clock, and add it to the "always on" PM Domain, so it can be power managed using that clock. Note that currently the GIC-400 driver doesn't support module clocks nor Runtime PM, so this must be handled as a critical clock. Signed-off-by:
-
Geert Uytterhoeven authored
Link the ARM GIC to the INTC-SYS module clock and the C4 power domain, so it can be power managed using that clock in the future. Note that currently the GIC-400 driver doesn't support module clocks nor Runtime PM, so this must be handled as a critical clock. Signed-off-by:
-
Chris Brandt authored
Add watchdog timer support for RZ/A1. For the RZ/A1, the only way to do a reset is to overflow the WDT, so this is useful even if you don't need the watchdog functionality. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
- 07 Mar, 2017 1 commit
-
-
Kuninori Morimoto authored
Current Audio-DMAC is assigned "rx" as Audio-DMAC0, "tx" as Audio-DMAC1. Thus, DVC "tx" should be assigned as Audio-DMAC1, instead of Audio-DMAC0. Because of this, current platform board (using SRC/DVC/SSI) Playback/Capture both will use same Audio-DMAC0 (but it depends on data path). First note is that this "rx" and "tx" are from each IP point, it doesn't mean Playback/Capture. Second note is that Audio DMAC assigned on DT is only for Audio-DMAC, Audio-DMAC-peri-peri has no entry. => Audio-DMAC -> Audio-DMAC-peri-peri -- HW connection Playback case [Mem] => [SRC]--[DVC] -> [SSI]--[Codec] rx ~~~~~~~~~~~~ Capture [Mem] <= [DVC]--[SRC] <- [SSI]--[Codec] tx ~~~~~~~~~~~~ Signed-off-by:
-
