Date   

[PATCH 7/7] gpio: rcar: Add Runtime PM handling for interrupts

Fabrizio Castro <fabrizio.castro@...>
 

From: Geert Uytterhoeven <geert+renesas@...>

The R-Car GPIO driver handles Runtime PM for requested GPIOs only.

When using a GPIO purely as an interrupt source, no Runtime PM handling
is done, and the GPIO module's clock may not be enabled.

To fix this:
- Add .irq_request_resources() and .irq_release_resources() callbacks
to handle Runtime PM when an interrupt is requested,
- Add irq_bus_lock() and sync_unlock() callbacks to handle Runtime PM
when e.g. disabling/enabling an interrupt, or configuring the
interrupt type.

Fixes: d5c3d84657db57bd "net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS"
Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Linus Walleij <linus.walleij@...>
(cherry picked from commit b26a719bdba9aa926ceaadecc66e07623d2b8a53)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
---
drivers/gpio/gpio-rcar.c | 42 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)

diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
index 75b2f2c..e38d97d 100644
--- a/drivers/gpio/gpio-rcar.c
+++ b/drivers/gpio/gpio-rcar.c
@@ -196,6 +196,44 @@ static int gpio_rcar_irq_set_wake(struct irq_data *d, unsigned int on)
return 0;
}

+static void gpio_rcar_irq_bus_lock(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct gpio_rcar_priv *p = gpiochip_get_data(gc);
+
+ pm_runtime_get_sync(&p->pdev->dev);
+}
+
+static void gpio_rcar_irq_bus_sync_unlock(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct gpio_rcar_priv *p = gpiochip_get_data(gc);
+
+ pm_runtime_put(&p->pdev->dev);
+}
+
+
+static int gpio_rcar_irq_request_resources(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct gpio_rcar_priv *p = gpiochip_get_data(gc);
+ int error;
+
+ error = pm_runtime_get_sync(&p->pdev->dev);
+ if (error < 0)
+ return error;
+
+ return 0;
+}
+
+static void gpio_rcar_irq_release_resources(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct gpio_rcar_priv *p = gpiochip_get_data(gc);
+
+ pm_runtime_put(&p->pdev->dev);
+}
+
static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id)
{
struct gpio_rcar_priv *p = dev_id;
@@ -455,6 +493,10 @@ static int gpio_rcar_probe(struct platform_device *pdev)
irq_chip->irq_unmask = gpio_rcar_irq_enable;
irq_chip->irq_set_type = gpio_rcar_irq_set_type;
irq_chip->irq_set_wake = gpio_rcar_irq_set_wake;
+ irq_chip->irq_bus_lock = gpio_rcar_irq_bus_lock;
+ irq_chip->irq_bus_sync_unlock = gpio_rcar_irq_bus_sync_unlock;
+ irq_chip->irq_request_resources = gpio_rcar_irq_request_resources;
+ irq_chip->irq_release_resources = gpio_rcar_irq_release_resources;
irq_chip->flags = IRQCHIP_SET_TYPE_MASKED | IRQCHIP_MASK_ON_SUSPEND;

ret = gpiochip_add_data(gpio_chip, p);
--
2.7.4


[PATCH 6/7] gpio: rcar: use gpiochip data pointer

Fabrizio Castro <fabrizio.castro@...>
 

From: Linus Walleij <linus.walleij@...>

This makes the driver use the data pointer added to the gpio_chip
to store a pointer to the state container instead of relying on
container_of().

Cc: Ulrich Hecht <ulrich.hecht+renesas@...>
Cc: Geert Uytterhoeven <geert+renesas@...>
Cc: Hisashi Nakamura <hisashi.nakamura.ak@...>
Signed-off-by: Linus Walleij <linus.walleij@...>
(cherry picked from commit c7b6f457cb53bceece484f4c528d1c149995e6c7)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
---
drivers/gpio/gpio-rcar.c | 33 ++++++++++++---------------------
1 file changed, 12 insertions(+), 21 deletions(-)

diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
index 22c8517..75b2f2c 100644
--- a/drivers/gpio/gpio-rcar.c
+++ b/drivers/gpio/gpio-rcar.c
@@ -84,8 +84,7 @@ static void gpio_rcar_modify_bit(struct gpio_rcar_priv *p, int offs,
static void gpio_rcar_irq_disable(struct irq_data *d)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
- struct gpio_rcar_priv *p = container_of(gc, struct gpio_rcar_priv,
- gpio_chip);
+ struct gpio_rcar_priv *p = gpiochip_get_data(gc);

gpio_rcar_write(p, INTMSK, ~BIT(irqd_to_hwirq(d)));
}
@@ -93,8 +92,7 @@ static void gpio_rcar_irq_disable(struct irq_data *d)
static void gpio_rcar_irq_enable(struct irq_data *d)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
- struct gpio_rcar_priv *p = container_of(gc, struct gpio_rcar_priv,
- gpio_chip);
+ struct gpio_rcar_priv *p = gpiochip_get_data(gc);

gpio_rcar_write(p, MSKCLR, BIT(irqd_to_hwirq(d)));
}
@@ -137,8 +135,7 @@ static void gpio_rcar_config_interrupt_input_mode(struct gpio_rcar_priv *p,
static int gpio_rcar_irq_set_type(struct irq_data *d, unsigned int type)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
- struct gpio_rcar_priv *p = container_of(gc, struct gpio_rcar_priv,
- gpio_chip);
+ struct gpio_rcar_priv *p = gpiochip_get_data(gc);
unsigned int hwirq = irqd_to_hwirq(d);

dev_dbg(&p->pdev->dev, "sense irq = %d, type = %d\n", hwirq, type);
@@ -175,8 +172,7 @@ static int gpio_rcar_irq_set_type(struct irq_data *d, unsigned int type)
static int gpio_rcar_irq_set_wake(struct irq_data *d, unsigned int on)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
- struct gpio_rcar_priv *p = container_of(gc, struct gpio_rcar_priv,
- gpio_chip);
+ struct gpio_rcar_priv *p = gpiochip_get_data(gc);
int error;

if (p->irq_parent) {
@@ -218,16 +214,11 @@ static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id)
return irqs_handled ? IRQ_HANDLED : IRQ_NONE;
}

-static inline struct gpio_rcar_priv *gpio_to_priv(struct gpio_chip *chip)
-{
- return container_of(chip, struct gpio_rcar_priv, gpio_chip);
-}
-
static void gpio_rcar_config_general_input_output_mode(struct gpio_chip *chip,
unsigned int gpio,
bool output)
{
- struct gpio_rcar_priv *p = gpio_to_priv(chip);
+ struct gpio_rcar_priv *p = gpiochip_get_data(chip);
unsigned long flags;

/* follow steps in the GPIO documentation for
@@ -251,7 +242,7 @@ static void gpio_rcar_config_general_input_output_mode(struct gpio_chip *chip,

static int gpio_rcar_request(struct gpio_chip *chip, unsigned offset)
{
- struct gpio_rcar_priv *p = gpio_to_priv(chip);
+ struct gpio_rcar_priv *p = gpiochip_get_data(chip);
int error;

error = pm_runtime_get_sync(&p->pdev->dev);
@@ -267,7 +258,7 @@ static int gpio_rcar_request(struct gpio_chip *chip, unsigned offset)

static void gpio_rcar_free(struct gpio_chip *chip, unsigned offset)
{
- struct gpio_rcar_priv *p = gpio_to_priv(chip);
+ struct gpio_rcar_priv *p = gpiochip_get_data(chip);

pinctrl_free_gpio(chip->base + offset);

@@ -291,15 +282,15 @@ static int gpio_rcar_get(struct gpio_chip *chip, unsigned offset)

/* testing on r8a7790 shows that INDT does not show correct pin state
* when configured as output, so use OUTDT in case of output pins */
- if (gpio_rcar_read(gpio_to_priv(chip), INOUTSEL) & bit)
- return !!(gpio_rcar_read(gpio_to_priv(chip), OUTDT) & bit);
+ if (gpio_rcar_read(gpiochip_get_data(chip), INOUTSEL) & bit)
+ return !!(gpio_rcar_read(gpiochip_get_data(chip), OUTDT) & bit);
else
- return !!(gpio_rcar_read(gpio_to_priv(chip), INDT) & bit);
+ return !!(gpio_rcar_read(gpiochip_get_data(chip), INDT) & bit);
}

static void gpio_rcar_set(struct gpio_chip *chip, unsigned offset, int value)
{
- struct gpio_rcar_priv *p = gpio_to_priv(chip);
+ struct gpio_rcar_priv *p = gpiochip_get_data(chip);
unsigned long flags;

spin_lock_irqsave(&p->lock, flags);
@@ -466,7 +457,7 @@ static int gpio_rcar_probe(struct platform_device *pdev)
irq_chip->irq_set_wake = gpio_rcar_irq_set_wake;
irq_chip->flags = IRQCHIP_SET_TYPE_MASKED | IRQCHIP_MASK_ON_SUSPEND;

- ret = gpiochip_add(gpio_chip);
+ ret = gpiochip_add_data(gpio_chip, p);
if (ret) {
dev_err(dev, "failed to add GPIO controller\n");
goto err0;
--
2.7.4


[PATCH 5/7] ARM: shmobile: defconfig: Enable CMA for DMA

Fabrizio Castro <fabrizio.castro@...>
 

From: Niklas Söderlund <niklas.soderlund+renesas@...>

To be able to use VIN with larger frame sizes CMA memory are needed for
DMA. If this is not enabled trying to capture large frames can result in
errors such as:

rcar-vin e6ef0000.video: dma_alloc_coherent of size 8388608 failed

A CMA area of 64MB are needed for v4l2-compliance to pass on all formats
on the largest possible frame size of 2048x2048.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 77af670a7698bbc4dc9fd8bbd553b33bfb16b68a)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
---
arch/arm/configs/shmobile_defconfig | 3 +++
1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 30a3424..733b4f2 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -35,6 +35,7 @@ CONFIG_HAVE_ARM_ARCH_TIMER=y
CONFIG_NR_CPUS=8
CONFIG_AEABI=y
CONFIG_HIGHMEM=y
+CONFIG_CMA=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
@@ -58,6 +59,8 @@ CONFIG_IP_PNP_DHCP=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_DMA_CMA=y
+CONFIG_CMA_SIZE_MBYTES=64
CONFIG_SIMPLE_PM_BUS=y
CONFIG_MTD=y
CONFIG_MTD_BLOCK=y
--
2.7.4


[PATCH 4/7] ARM: dts: iwg20d-q7-dbcm-ca: Add HDMI video output

Fabrizio Castro <fabrizio.castro@...>
 

Although there is a HDMI connector on the q7 carrier board it is not
connected to the RZ/G1M SoC. One must use the HDMI connector on the
camera daughter board.

This patch adds support for this connector.

Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
Reviewed-by: Laurent Pinchart <laurent.pinchart@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 55cce0a07678e5fe21c7f81cc437653b485a712c)
(taken out interrupt support)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
---
arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 73 ++++++++++++++++++++++++++++++++
1 file changed, 73 insertions(+)

diff --git a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
index 31fab5f..b9c377e 100644
--- a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
@@ -13,6 +13,37 @@
serial1 = &scif1;
serial4 = &hscif1;
};
+
+ cec_clock: cec-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <12000000>;
+ };
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_out: endpoint {
+ remote-endpoint = <&adv7511_out>;
+ };
+ };
+ };
+};
+
+&du {
+ pinctrl-0 = <&du_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ ports {
+ port@0 {
+ endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+ };
+ };
};

&hscif1 {
@@ -23,7 +54,49 @@
status = "okay";
};

+&i2c5 {
+ status = "okay";
+ clock-frequency = <400000>;
+
+ hdmi@39 {
+ compatible = "adi,adv7511w";
+ reg = <0x39>;
+ clocks = <&cec_clock>;
+ clock-names = "cec";
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <&du_out_rgb>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_con_out>;
+ };
+ };
+ };
+ };
+};
+
&pfc {
+ du_pins: du {
+ groups = "du_rgb888", "du_sync", "du_oddf", "du_clk_out_0";
+ function = "du";
+ };
+
hscif1_pins: hscif1 {
groups = "hscif1_data_c", "hscif1_ctrl_c";
function = "hscif1";
--
2.7.4


[PATCH 3/7] ARM: dts: r8a7743: Add DU support

Fabrizio Castro <fabrizio.castro@...>
 

Add du node to r8a7743 SoC DT. Boards that want to enable the DU
need to specify the output topology.

Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
Reviewed-by: Laurent Pinchart <laurent.pinchart@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 0d975e29a51011c244d41e16a59a26fddf6ea281)
(changed clocks property)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
---
arch/arm/boot/dts/r8a7743.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index eb3cdc8..173eae5 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -1330,6 +1330,36 @@
};
};

+ du: display@feb00000 {
+ compatible = "renesas,du-r8a7743";
+ reg = <0 0xfeb00000 0 0x40000>,
+ <0 0xfeb90000 0 0x1c>;
+ reg-names = "du", "lvds.0";
+ interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_DU0>,
+ <&mstp7_clks R8A7743_CLK_DU1>,
+ <&mstp7_clks R8A7743_CLK_LVDS0>;
+ clock-names = "du.0", "du.1", "lvds.0";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ du_out_rgb: endpoint {
+ };
+ };
+ port@1 {
+ reg = <1>;
+ du_out_lvds0: endpoint {
+ };
+ };
+ };
+ };
+
pci0: pci@ee090000 {
compatible = "renesas,pci-r8a7743",
"renesas,pci-rcar-gen2";
--
2.7.4


[PATCH 2/7] drm: rcar-du: Add R8A7743 support

Fabrizio Castro <fabrizio.castro@...>
 

Add support for the R8A7743 DU (which is very similar to the R8A7791 DU);
it has 1 DPAD (RGB) output and 1 LVDS output.

Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
Reviewed-by: Laurent Pinchart <laurent.pinchart@...>
(cherry picked from commit 36a46da90212ddeeb78c2f902caaca264d8496a9)
(removed .gen/added .encoder_type from/to rzg1_du_r8a7743_info)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index bb9cd35..eee90f5 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -35,6 +35,28 @@
* Device Information
*/

+static const struct rcar_du_device_info rzg1_du_r8a7743_info = {
+ .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
+ | RCAR_DU_FEATURE_EXT_CTRL_REGS,
+ .num_crtcs = 2,
+ .routes = {
+ /*
+ * R8A7743 has one RGB output and one LVDS output
+ */
+ [RCAR_DU_OUTPUT_DPAD0] = {
+ .possible_crtcs = BIT(1) | BIT(0),
+ .encoder_type = DRM_MODE_ENCODER_NONE,
+ .port = 0,
+ },
+ [RCAR_DU_OUTPUT_LVDS0] = {
+ .possible_crtcs = BIT(0),
+ .encoder_type = DRM_MODE_ENCODER_LVDS,
+ .port = 1,
+ },
+ },
+ .num_lvds = 1,
+};
+
static const struct rcar_du_device_info rcar_du_r8a7779_info = {
.features = 0,
.num_crtcs = 2,
@@ -130,6 +152,7 @@ static const struct rcar_du_device_info rcar_du_r8a7794_info = {
};

static const struct of_device_id rcar_du_of_table[] = {
+ { .compatible = "renesas,du-r8a7743", .data = &rzg1_du_r8a7743_info },
{ .compatible = "renesas,du-r8a7779", .data = &rcar_du_r8a7779_info },
{ .compatible = "renesas,du-r8a7790", .data = &rcar_du_r8a7790_info },
{ .compatible = "renesas,du-r8a7791", .data = &rcar_du_r8a7791_info },
--
2.7.4


[PATCH 1/7] dt-bindings: display: rcar-du: Document R8A774[35] DU

Fabrizio Castro <fabrizio.castro@...>
 

Add device tree bindings for r8a7743 and r8a7745 DUs.
r8a7743 DU is similar to the one from r8a7791, r8a7745 DU is similar
to the one from r8a7794.

Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
Reviewed-by: Laurent Pinchart <laurent.pinchart@...>
[Don't reference R8A779[0123456] and R8A774[35] explicitly]
[Number all DPAD, HDMI and LVDS ports]
Signed-off-by: Laurent Pinchart <laurent.pinchart@...>
(cherry picked from commit faf4a3ff36137aaa8de1a8da99a92f6e712903f1)
(removed R-Car gen3 SoCs)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
---
.../devicetree/bindings/display/renesas,du.txt | 24 +++++++++++++---------
1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt b/Documentation/devicetree/bindings/display/renesas,du.txt
index eccd4f4..2cc5fdd 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -3,6 +3,8 @@
Required Properties:

- compatible: must be one of the following.
+ - "renesas,du-r8a7743" for R8A7743 (RZ/G1M) compatible DU
+ - "renesas,du-r8a7745" for R8A7745 (RZ/G1E) compatible DU
- "renesas,du-r8a7779" for R8A7779 (R-Car H1) compatible DU
- "renesas,du-r8a7790" for R8A7790 (R-Car H2) compatible DU
- "renesas,du-r8a7791" for R8A7791 (R-Car M2-W) compatible DU
@@ -24,10 +26,10 @@ Required Properties:
- clock-names: Name of the clocks. This property is model-dependent.
- R8A7779 uses a single functional clock. The clock doesn't need to be
named.
- - R8A779[0134] use one functional clock per channel and one clock per LVDS
- encoder (if available). The functional clocks must be named "du.x" with
- "x" being the channel numerical index. The LVDS clocks must be named
- "lvds.x" with "x" being the LVDS encoder numerical index.
+ - All other DU instances use one functional clock per channel and one
+ clock per LVDS encoder (if available). The functional clocks must be
+ named "du.x" with "x" being the channel numerical index. The LVDS clocks
+ must be named "lvds.x" with "x" being the LVDS encoder numerical index.
- In addition to the functional and encoder clocks, all DU versions also
support externally supplied pixel clocks. Those clocks are optional.
When supplied they must be named "dclkin.x" with "x" being the input
@@ -41,13 +43,15 @@ bindings specified in Documentation/devicetree/bindings/graph.txt.
The following table lists for each supported model the port number
corresponding to each DU output.

- Port 0 Port1 Port2
+ Port 0 Port1 Port2
-----------------------------------------------------------------------------
- R8A7779 (H1) DPAD 0 DPAD 1 -
- R8A7790 (H2) DPAD LVDS 0 LVDS 1
- R8A7791 (M2-W) DPAD LVDS 0 -
- R8A7793 (M2-N) DPAD LVDS 0 -
- R8A7794 (E2) DPAD 0 DPAD 1 -
+ R8A7743 (RZ/G1M) DPAD 0 LVDS 0 -
+ R8A7745 (RZ/G1E) DPAD 0 DPAD 1 -
+ R8A7779 (R-Car H1) DPAD 0 DPAD 1 -
+ R8A7790 (R-Car H2) DPAD 0 LVDS 0 LVDS 1
+ R8A7791 (R-Car M2-W) DPAD 0 LVDS 0 -
+ R8A7793 (R-Car M2-N) DPAD 0 LVDS 0 -
+ R8A7794 (R-Car E2) DPAD 0 DPAD 1 -


Example: R8A7790 (R-Car H2) DU
--
2.7.4


[PATCH 0/7] Add HDMI support to iwg20d

Fabrizio Castro <fabrizio.castro@...>
 

Dear Ben,

this series adds HDMI video output to iWave's iwg20d board.

I had to take out interrupt (hotplug) support from the hdmi DT node as
it looks like commit 9183e45db7774716d056319c237a4185baba19c7 introduced
"connector" data field with struct adv7511, but drm_connector_init was
left behind, and as such connector.dev is NULL, and that causes issues
to function adv7511_hpd_work, preventing HDMI hotplug from working
properly.

While investigating HDMI hotplugging, I have found out that when using
a GPIO purely as an interrupt source the corresponding GPIO module
clock is not enabled, therefore this series backports the fix for this.
I yet have to check if this fix is any good to 4.4 LTS, I'll send it to
stable@... in case it works for 4.4 LTS too.

This series applies on top of tag v4.4.126-cip22.

Thanks,
Fab

Fabrizio Castro (4):
dt-bindings: display: rcar-du: Document R8A774[35] DU
drm: rcar-du: Add R8A7743 support
ARM: dts: r8a7743: Add DU support
ARM: dts: iwg20d-q7-dbcm-ca: Add HDMI video output

Geert Uytterhoeven (1):
gpio: rcar: Add Runtime PM handling for interrupts

Linus Walleij (1):
gpio: rcar: use gpiochip data pointer

Niklas Söderlund (1):
ARM: shmobile: defconfig: Enable CMA for DMA

.../devicetree/bindings/display/renesas,du.txt | 24 ++++---
arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 73 +++++++++++++++++++++
arch/arm/boot/dts/r8a7743.dtsi | 30 +++++++++
arch/arm/configs/shmobile_defconfig | 3 +
drivers/gpio/gpio-rcar.c | 75 ++++++++++++++++------
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 23 +++++++
6 files changed, 197 insertions(+), 31 deletions(-)

--
2.7.4


Re: [PATCH 57/62] thermal: rcar: enable to use thermal-zone on DT

Fabrizio Castro <fabrizio.castro@...>
 

Hello Ben,

-----Original Message-----
From: Ben Hutchings [mailto:ben.hutchings@...]
Sent: 11 May 2018 20:12
To: Biju Das <biju.das@...>
Cc: Chris Paterson <Chris.Paterson2@...>; Fabrizio Castro <fabrizio.castro@...>; cip-dev@...
Subject: Re: [PATCH 57/62] thermal: rcar: enable to use thermal-zone on DT

On Thu, 2018-05-10 at 16:08 +0100, Biju Das wrote:
From: Kuninori Morimoto <kuninori.morimoto.gx@...>

This patch enables to use thermal-zone on DT if it was calles as
"renesas,rcar-thermal-gen2".
Previous style (= non thermal-zone) is still supported by
"renesas,rcar-thermal" to keep compatibility for "git bisect".

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@...>
Signed-off-by: Eduardo Valentin <edubezval@...>
(cherry picked from commit 8b477ea56383dc8b838f1f8b506e4571c14ceb30)
Signed-off-by: Biju Das <biju.das@...>
Reviewed-by: Fabrizio Castro <fabrizio.castro@...>
[...]
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
[...]
@@ -463,7 +492,13 @@ static int rcar_thermal_probe(struct platform_device *pdev)
if (ret < 0)
goto error_unregister;

-priv->zone = thermal_zone_device_register("rcar_thermal",
+if (of_data == USE_OF_THERMAL)
+priv->zone = thermal_zone_of_sensor_register(
+dev, i, priv,
+&rcar_thermal_zone_of_ops);
Doesn't this require a corresponding change to use
thermal_zone_of_sensor_unregister()?
That's a good catch!


It looks like this was fixed upstream by commits 5e325868aa59
("thermal: convert rcar_thermal to use
devm_thermal_zone_of_sensor_register") and d4b23c5c434a ("thermal:
rcar_thermal: don't call thermal_zone_device_unregister when
USE_OF_THERMAL").
Thank you for the pointers, we will into them and we will send a v2.

Thank you for your help!

Cheers,
Fab


Ben.

+else
+priv->zone = thermal_zone_device_register(
+"rcar_thermal",
1, 0, priv,
&rcar_thermal_zone_ops, NULL, 0,
idle);
--
Ben Hutchings
Software Developer, Codethink Ltd.



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.


Re: Reviewing 4.4 stable updates

Daniel Wagner <daniel.wagner@...>
 

Hi Daniel,

Dhinakar Kalyanasundaram mentioned that this bug was fixed in kernel 4.14,
and Tim Bird updated the Fuego LTP documentation suggesting that
backporting the patch "fanotify: Release SRCU lock when waiting for
userspace response" should fix the hang.
https://patchwork.kernel.org/patch/9659809/

Shall I backport it and test?
It would be of a great help.

Can you send these reports to cip-testing-results ?
Just out of curiosity, do you also test the cip-rt kernel with fuego? I
got a report that a x86 box has problems to boot with the recent cip-rt
kernel. In the early device bring up a NULL pointer is dereferenced
(late_resume_init). So far I was not able to reproduce it on my machine.

Hence if you test the cip-rt kernel I would be interested to get
feedback as well :)

Thanks,
Daniel


Re: Reviewing 4.4 stable updates

Agustín Benito Bethencourt <agustin.benito@...>
 

Hi Daniel,

On Tuesday, 15 May 2018 08:44:19 CEST Daniel Sangorrin wrote:
It seems that backporting "fanotify: Release SRCU lock when waiting for
userspace response" was too complicated:
https://lists.debian.org/debian-kernel/2017/06/msg00170.html

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Daniel
Sangorrin Sent: Tuesday, May 15, 2018 1:07 PM
To: 'Ben Hutchings' <ben.hutchings@...>;
cip-dev@...
Subject: Re: [cip-dev] Reviewing 4.4 stable updates

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Daniel
Sangorrin Sent: Thursday, April 26, 2018 8:53 AM
To: 'Ben Hutchings' <ben.hutchings@...>;
cip-dev@...
Subject: Re: [cip-dev] Reviewing 4.4 stable updates
...

I saw there is already a 4.4.129 on the linux-stable-rc.git linux-4.4.y.
Test results so far show no regressions (altough i see failures that
might need investigation?):
Pixel: https://lkml.org/lkml/2018/4/22/732
Linaro: https://lkml.org/lkml/2018/4/23/116
Kerneltests: https://lkml.org/lkml/2018/4/23/823
dmseg: https://lkml.org/lkml/2018/4/23/1028

I will run some tests with Fuego.
Sorry for the late response. I tested LTS 4.4.129 with Fuego and most
tests worked correctly.
There were a few errors on some of the LTP tests (see the file attached).

fcntl35.c:98: FAIL: an unprivileged user init the capacity of a pipe to
65536 unexpectedly, expected 4096
getxattr04.c:72: FAIL: getxattr() failed to get an existing attribute
inotify07.c:157: FAIL: didn't get event: mask=40000004
inotify08.c:150: FAIL: didn't get event: mask=4
[Note] These 4 errors could be related with some configuration, so I need
to investigate them further.

For fanotify07 and fanotify08 I got some timeout errors:
tst_test.c:1015: INFO: Timeout per run is 0h 05m 00s
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Cannot kill test processes!
Congratulation, likely test hit a kernel bug.
Exitting uncleanly...

Dhinakar Kalyanasundaram mentioned that this bug was fixed in kernel 4.14,
and Tim Bird updated the Fuego LTP documentation suggesting that
backporting the patch "fanotify: Release SRCU lock when waiting for
userspace response" should fix the hang.
https://patchwork.kernel.org/patch/9659809/

Shall I backport it and test?
It would be of a great help.

Can you send these reports to cip-testing-results ?

Best Regards


--
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd


Re: Reviewing 4.4 stable updates

Daniel Sangorrin <daniel.sangorrin@...>
 

It seems that backporting "fanotify: Release SRCU lock when waiting for userspace response" was too complicated:
https://lists.debian.org/debian-kernel/2017/06/msg00170.html

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Daniel Sangorrin
Sent: Tuesday, May 15, 2018 1:07 PM
To: 'Ben Hutchings' <ben.hutchings@...>;
cip-dev@...
Subject: Re: [cip-dev] Reviewing 4.4 stable updates

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Daniel Sangorrin
Sent: Thursday, April 26, 2018 8:53 AM
To: 'Ben Hutchings' <ben.hutchings@...>;
cip-dev@...
Subject: Re: [cip-dev] Reviewing 4.4 stable updates
...
I saw there is already a 4.4.129 on the linux-stable-rc.git linux-4.4.y.
Test results so far show no regressions (altough i see failures that might need
investigation?):
Pixel: https://lkml.org/lkml/2018/4/22/732
Linaro: https://lkml.org/lkml/2018/4/23/116
Kerneltests: https://lkml.org/lkml/2018/4/23/823
dmseg: https://lkml.org/lkml/2018/4/23/1028

I will run some tests with Fuego.
Sorry for the late response. I tested LTS 4.4.129 with Fuego and most tests worked
correctly.
There were a few errors on some of the LTP tests (see the file attached).

fcntl35.c:98: FAIL: an unprivileged user init the capacity of a pipe to 65536
unexpectedly, expected 4096
getxattr04.c:72: FAIL: getxattr() failed to get an existing attribute
inotify07.c:157: FAIL: didn't get event: mask=40000004
inotify08.c:150: FAIL: didn't get event: mask=4
[Note] These 4 errors could be related with some configuration, so I need to
investigate them further.

For fanotify07 and fanotify08 I got some timeout errors:
tst_test.c:1015: INFO: Timeout per run is 0h 05m 00s
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Cannot kill test processes!
Congratulation, likely test hit a kernel bug.
Exitting uncleanly...

Dhinakar Kalyanasundaram mentioned that this bug was fixed in kernel 4.14, and
Tim Bird updated the Fuego LTP documentation suggesting that backporting the
patch "fanotify: Release SRCU lock when waiting for userspace response" should fix
the hang.
https://patchwork.kernel.org/patch/9659809/

Shall I backport it and test?

Thanks,
Daniel


Re: Reviewing 4.4 stable updates

Daniel Sangorrin <daniel.sangorrin@...>
 

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Daniel Sangorrin
Sent: Thursday, April 26, 2018 8:53 AM
To: 'Ben Hutchings' <ben.hutchings@...>;
cip-dev@...
Subject: Re: [cip-dev] Reviewing 4.4 stable updates
...
I saw there is already a 4.4.129 on the linux-stable-rc.git linux-4.4.y.
Test results so far show no regressions (altough i see failures that might need
investigation?):
Pixel: https://lkml.org/lkml/2018/4/22/732
Linaro: https://lkml.org/lkml/2018/4/23/116
Kerneltests: https://lkml.org/lkml/2018/4/23/823
dmseg: https://lkml.org/lkml/2018/4/23/1028

I will run some tests with Fuego.
Sorry for the late response. I tested LTS 4.4.129 with Fuego and most tests worked correctly.
There were a few errors on some of the LTP tests (see the file attached).

fcntl35.c:98: FAIL: an unprivileged user init the capacity of a pipe to 65536 unexpectedly, expected 4096
getxattr04.c:72: FAIL: getxattr() failed to get an existing attribute
inotify07.c:157: FAIL: didn't get event: mask=40000004
inotify08.c:150: FAIL: didn't get event: mask=4
[Note] These 4 errors could be related with some configuration, so I need to investigate them further.

For fanotify07 and fanotify08 I got some timeout errors:
tst_test.c:1015: INFO: Timeout per run is 0h 05m 00s
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Test timeouted, sending SIGKILL!
Cannot kill test processes!
Congratulation, likely test hit a kernel bug.
Exitting uncleanly...

Dhinakar Kalyanasundaram mentioned that this bug was fixed in kernel 4.14, and Tim Bird updated the Fuego LTP documentation suggesting that backporting the patch "fanotify: Release SRCU lock when waiting for userspace response" should fix the hang.
https://patchwork.kernel.org/patch/9659809/

Shall I backport it and test?

Thanks,
Daniel


Re: Kaufvertrag Und Zahlungsdokumente

VP Verband Pflegehilfe GmbH <sales@...>
 

Sehr geehrte Damen und Herrn,
 
wie telefonisch besprochen von deinem Büro, anbei der Unterzeichnete Kaufvertrag zum ELW Und Zahlungsbeleg.

Mit freundlichen Grüßen

Winkler Unternehmensgruppe
Zentralverwaltung

 

 

Buchhaltung
Verband Pflegehilfe
t: 06131.83 821 63
f: 06131. 83 821 68
w: Pflegehilfe.org  e: buchhaltung@...

VP Verband Pflegehilfe GmbH | Parcusstraße 8 | 55116 Mainz
Geschäftsführer: Johannes R. Haas, Michael Haas
Sitz der Gesellschaft: Mainz, Rheinland Pfalz
Registergericht: Amtsgericht Frankfurt am Main
Registernummer: HRB 109505
Umsatzsteuer-Identifikationsnummer gemäß § 27 a Umsatzsteuergesetz: DE296724731


Codethink report: weeks 18 - 19

Agustín Benito Bethencourt <agustin.benito@...>
 

Hi,

## Kernel maintenance

* Patch series from Fabrizio Castro to fix i2c-rcar driver reviewed.
* Reviewed patch series from Biju Das for Renesas R8A7743 support
* General 4.4-stable patch review (upstream).

## Testing

* Introducing changes to control when we want to apply LAVA updates: #184
** Link: https://gitlab.com/cip-project/cip-testing/testing/issues/184

* LAVA upgrade 2018.04
** Documentation update: test cases.
*** Link: https://wiki.linuxfoundation.org/civilinfrastructureplatform/
ciptestingreferencetestcases
** Problems with backports detected and fixed.

* Failures after testing the iwg20m kernel with U-Boot directly.
** Under investigation.

## Other topics

* Participation at cip-de IRC weekly meetings.

* Sudip, a Codethink kernel engineer, will join Agustin at the OSSJ event.
Both of us will help on the booth too.
** Registered.

* CIP kernel talk at OSSJ: https://events.linuxfoundation.org/events/open-source-summit-japan-2018/program/schedule/

Best Regards
--
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd


Re: [PATCH 57/62] thermal: rcar: enable to use thermal-zone on DT

Ben Hutchings <ben.hutchings@...>
 

On Thu, 2018-05-10 at 16:08 +0100, Biju Das wrote:
From: Kuninori Morimoto <kuninori.morimoto.gx@...>

This patch enables to use thermal-zone on DT if it was calles as
"renesas,rcar-thermal-gen2".
Previous style (= non thermal-zone) is still supported by
"renesas,rcar-thermal" to keep compatibility for "git bisect".

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@...>
Signed-off-by: Eduardo Valentin <edubezval@...>
(cherry picked from commit 8b477ea56383dc8b838f1f8b506e4571c14ceb30)
Signed-off-by: Biju Das <biju.das@...>
Reviewed-by: Fabrizio Castro <fabrizio.castro@...>
[...]
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
[...]
@@ -463,7 +492,13 @@ static int rcar_thermal_probe(struct platform_device *pdev)
  if (ret < 0)
  goto error_unregister;
 
- priv->zone = thermal_zone_device_register("rcar_thermal",
+ if (of_data == USE_OF_THERMAL)
+ priv->zone = thermal_zone_of_sensor_register(
+ dev, i, priv,
+ &rcar_thermal_zone_of_ops);
Doesn't this require a corresponding change to use
thermal_zone_of_sensor_unregister()?

It looks like this was fixed upstream by commits 5e325868aa59
("thermal: convert rcar_thermal to use
devm_thermal_zone_of_sensor_register") and d4b23c5c434a ("thermal:
rcar_thermal: don't call thermal_zone_device_unregister when
USE_OF_THERMAL").

Ben.

+ else
+ priv->zone = thermal_zone_device_register(
+ "rcar_thermal",
  1, 0, priv,
  &rcar_thermal_zone_ops, NULL, 0,
  idle);
--
Ben Hutchings
Software Developer, Codethink Ltd.


[Git][cip-project/cip-testing/board-at-desk-single-dev][master] 2 commits: Change necessary now that LAVA has moved to python 3 #184

Agustin Benito Bethencourt
 

Robert Marshall pushed to branch master at cip-project / cip-testing / board-at-desk-single-dev

Commits:

  • 304b6d65
    by Robert Marshall at 2018-05-09T12:46:03Z
    Change necessary now that LAVA has moved to python 3 #184
    
    The change to the shutdown message does not appear to be necessary.
    
  • 42e332d7
    by Robert Marshall at 2018-05-11T16:36:04Z
    Merge branch 'lava2018.4change' into 'master'
    
    Change necessary now that LAVA has moved to python 3 #184
    
    See merge request cip-project/cip-testing/board-at-desk-single-dev!59

1 changed file:

Changes:

  • integration-scripts/configure_lava.sh
    ... ... @@ -62,9 +62,4 @@ cp -v /vagrant/device-dictionary/myiwg20m.jinja2 ~/myrenesas.dat
    62 62
     sudo DEBIAN_FRONTEND=noninteractive chown lavaserver.lavaserver /etc/lava-server/dispatcher-config/devices/*
    
    63 63
     sudo DEBIAN_FRONTEND=noninteractive chown lavaserver.lavaserver /etc/lava-server/dispatcher-config/device-types/*
    
    64 64
     
    
    65
    -# Change the default shutdown message for kernel v4.4 - comment these lines out if using older kernel with a Shutdown message of "The system is going down for reboot NOW"
    
    66
    -cd /usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/utils/
    
    67
    -sudo DEBIAN_FRONTEND=noninteractive sed -ie "/SHUTDOWN_MESSAGE/s/The system is going down for reboot NOW/Restarting system/" constants.py
    
    68
    -cd ~
    
    69
    -
    
    70 65
     echo "END: configure_lava.sh"


  • Re: linux-cip-rt mirror on gitlab.com?

    Agustín Benito Bethencourt <agustin.benito@...>
     

    Hi,

    On Friday, 11 May 2018 09:34:24 CEST Daniel Wagner wrote:
    Hi Augstin,

    I just received an private message asking where the linux-cip-rt kernel
    is hosted. I wonder if it would be possible to mirror the linux-cip-rt
    as well in the cip-project group on gitlab.com. The wiki points only to
    the gitlab.com side.
    Of course, yes.


    My linux-cip-rt tree is here:

    https://git.kernel.org/pub/scm/linux/kernel/git/wagi/linux-cip-rt.git
    I will mirror repo and provide you master rights of it so you manage it.

    Best Regards

    --
    Agustín Benito Bethencourt
    Principal Consultant
    Codethink Ltd


    linux-cip-rt mirror on gitlab.com?

    Daniel Wagner <daniel.wagner@...>
     

    Hi Augstin,

    I just received an private message asking where the linux-cip-rt kernel
    is hosted. I wonder if it would be possible to mirror the linux-cip-rt
    as well in the cip-project group on gitlab.com. The wiki points only to
    the gitlab.com side.

    My linux-cip-rt tree is here:

    https://git.kernel.org/pub/scm/linux/kernel/git/wagi/linux-cip-rt.git

    Thanks,
    Daniel


    [PATCH 62/62] ARM: dts: r8a7743: Add thermal device to DT

    Biju Das <biju.das@...>
     

    This patch instantiates the thermal sensor module with thermal-zone
    support.

    This patch is based on the commit cac68a56e34b
    ("ARM: dts: r8a7791: enable to use thermal-zone") by Kuninori Morimoto.

    Signed-off-by: Biju Das <biju.das@...>
    Reviewed-by: Fabrizio Castro <fabrizio.castro@...>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
    Signed-off-by: Simon Horman <horms+renesas@...>
    (cherry picked from commit 6c76b4f7d89e89f0ae405dfc7a64c6d2b5d02813)
    (updated clocks and power-domains property.removed resets property)
    Signed-off-by: Biju Das <biju.das@...>
    Reviewed-by: Fabrizio Castro <fabrizio.castro@...>
    ---
    arch/arm/boot/dts/r8a7743.dtsi | 31 +++++++++++++++++++++++++++++++
    1 file changed, 31 insertions(+)

    diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
    index 17be22c..1d9adcc 100644
    --- a/arch/arm/boot/dts/r8a7743.dtsi
    +++ b/arch/arm/boot/dts/r8a7743.dtsi
    @@ -237,6 +237,37 @@
    power-domains = <&cpg_clocks>;
    };

    + thermal: thermal@e61f0000 {
    + compatible = "renesas,thermal-r8a7743",
    + "renesas,rcar-gen2-thermal",
    + "renesas,rcar-thermal";
    + reg = <0 0xe61f0000 0 0x10>, <0 0xe61f0100 0 0x38>;
    + interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
    + clocks = <&mstp5_clks R8A7743_CLK_THERMAL>;
    + power-domains = <&cpg_clocks>;
    + #thermal-sensor-cells = <0>;
    + };
    +
    + thermal-zones {
    + cpu_thermal: cpu-thermal {
    + polling-delay-passive = <0>;
    + polling-delay = <0>;
    +
    + thermal-sensors = <&thermal>;
    +
    + trips {
    + cpu-crit {
    + temperature = <95000>;
    + hysteresis = <0>;
    + type = "critical";
    + };
    + };
    +
    + cooling-maps {
    + };
    + };
    + };
    +
    timer {
    compatible = "arm,armv7-timer";
    interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
    --
    2.7.4

    8381 - 8400 of 9573