Date   

[PATCH 4.19.y-cip 13/17] drm: rcar-du: lvds: Allow for even and odd pixels swap

Biju Das <biju.das.jz@...>
 

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

commit 59c1f061c97e70d81b046e90b259589b645bb87f upstream.

DT properties dual-lvds-even-pixels and dual-lvds-odd-pixels
can be used to work out if the driver needs to swap even
and odd pixels around.

This patch makes use of the return value from function
drm_of_lvds_get_dual_link_pixel_order to determine if we
need to swap odd and even pixels around for things to work
properly.

The dual_link boolean field from struct rcar_lvds is not
sufficient to describe the type of LVDS link anymore, since
we now have information related to pixel order, therefore
rename it to link_type and repurpose its usage to fit the
new requirements.

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 77 ++++++++++++++++++++++-------
1 file changed, 58 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 12d2bbbb02f0..e4d0bd043613 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -35,6 +35,12 @@ enum rcar_lvds_mode {
RCAR_LVDS_MODE_VESA = 4,
};

+enum rcar_lvds_link_type {
+ RCAR_LVDS_SINGLE_LINK = 0,
+ RCAR_LVDS_DUAL_LINK_EVEN_ODD_PIXELS = 1,
+ RCAR_LVDS_DUAL_LINK_ODD_EVEN_PIXELS = 2,
+};
+
#define RCAR_LVDS_QUIRK_LANES BIT(0) /* LVDS lanes 1 and 3 inverted */
#define RCAR_LVDS_QUIRK_GEN3_LVEN BIT(1) /* LVEN bit needs to be set on R8A77970/R8A7799x */
#define RCAR_LVDS_QUIRK_PWD BIT(2) /* PWD bit available (all of Gen3 but E3) */
@@ -65,7 +71,7 @@ struct rcar_lvds {
} clocks;

struct drm_bridge *companion;
- bool dual_link;
+ enum rcar_lvds_link_type link_type;
};

#define bridge_to_rcar_lvds(b) \
@@ -452,7 +458,7 @@ static void __rcar_lvds_atomic_enable(struct drm_bridge *bridge,
return;

/* Enable the companion LVDS encoder in dual-link mode. */
- if (lvds->dual_link && lvds->companion)
+ if (lvds->link_type != RCAR_LVDS_SINGLE_LINK && lvds->companion)
__rcar_lvds_atomic_enable(lvds->companion, state, crtc,
connector);

@@ -478,19 +484,38 @@ static void __rcar_lvds_atomic_enable(struct drm_bridge *bridge,
rcar_lvds_write(lvds, LVDCHCR, lvdhcr);

if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) {
- /*
- * Configure vertical stripe based on the mode of operation of
- * the connected device.
- */
- rcar_lvds_write(lvds, LVDSTRIPE,
- lvds->dual_link ? LVDSTRIPE_ST_ON : 0);
+ u32 lvdstripe = 0;
+
+ if (lvds->link_type != RCAR_LVDS_SINGLE_LINK) {
+ /*
+ * By default we generate even pixels from the primary
+ * encoder and odd pixels from the companion encoder.
+ * Swap pixels around if the sink requires odd pixels
+ * from the primary encoder and even pixels from the
+ * companion encoder.
+ */
+ bool swap_pixels = lvds->link_type ==
+ RCAR_LVDS_DUAL_LINK_ODD_EVEN_PIXELS;
+
+ /*
+ * Configure vertical stripe since we are dealing with
+ * an LVDS dual-link connection.
+ *
+ * ST_SWAP is reserved for the companion encoder, only
+ * set it in the primary encoder.
+ */
+ lvdstripe = LVDSTRIPE_ST_ON
+ | (lvds->companion && swap_pixels ?
+ LVDSTRIPE_ST_SWAP : 0);
+ }
+ rcar_lvds_write(lvds, LVDSTRIPE, lvdstripe);
}

/*
* PLL clock configuration on all instances but the companion in
* dual-link mode.
*/
- if (!lvds->dual_link || lvds->companion) {
+ if (lvds->link_type == RCAR_LVDS_SINGLE_LINK || lvds->companion) {
const struct drm_crtc_state *crtc_state =
drm_atomic_get_new_crtc_state(state, crtc);
const struct drm_display_mode *mode =
@@ -584,7 +609,7 @@ static void rcar_lvds_atomic_disable(struct drm_bridge *bridge,
rcar_lvds_write(lvds, LVDPLLCR, 0);

/* Disable the companion LVDS encoder in dual-link mode. */
- if (lvds->dual_link && lvds->companion)
+ if (lvds->link_type != RCAR_LVDS_SINGLE_LINK && lvds->companion)
lvds->companion->funcs->atomic_disable(lvds->companion, state);

clk_disable_unprepare(lvds->clocks.mod);
@@ -658,7 +683,7 @@ bool rcar_lvds_dual_link(struct drm_bridge *bridge)
{
struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);

- return lvds->dual_link;
+ return lvds->link_type != RCAR_LVDS_SINGLE_LINK;
}
EXPORT_SYMBOL_GPL(rcar_lvds_dual_link);

@@ -704,17 +729,28 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds *lvds)
of_node_put(port0);
of_node_put(port1);

- if (dual_link >= DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS)
- lvds->dual_link = true;
- else if (lvds->next_bridge && lvds->next_bridge->timings)
+ switch (dual_link) {
+ case DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS:
+ lvds->link_type = RCAR_LVDS_DUAL_LINK_ODD_EVEN_PIXELS;
+ break;
+ case DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS:
+ lvds->link_type = RCAR_LVDS_DUAL_LINK_EVEN_ODD_PIXELS;
+ break;
+ default:
/*
* Early dual-link bridge specific implementations populate the
- * timings field of drm_bridge, read the dual_link flag off the
- * bridge directly for backward compatibility.
+ * timings field of drm_bridge. If the flag is set, we assume
+ * that we are expected to generate even pixels from the primary
+ * encoder, and odd pixels from the companion encoder.
*/
- lvds->dual_link = lvds->next_bridge->timings->dual_link;
+ if (lvds->next_bridge && lvds->next_bridge->timings &&
+ lvds->next_bridge->timings->dual_link)
+ lvds->link_type = RCAR_LVDS_DUAL_LINK_EVEN_ODD_PIXELS;
+ else
+ lvds->link_type = RCAR_LVDS_SINGLE_LINK;
+ }

- if (!lvds->dual_link) {
+ if (lvds->link_type == RCAR_LVDS_SINGLE_LINK) {
dev_dbg(dev, "Single-link configuration detected\n");
goto done;
}
@@ -729,6 +765,9 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds *lvds)
"Dual-link configuration detected (companion encoder %pOF)\n",
companion);

+ if (lvds->link_type == RCAR_LVDS_DUAL_LINK_ODD_EVEN_PIXELS)
+ dev_dbg(dev, "Data swapping required\n");
+
/*
* FIXME: We should not be messing with the companion encoder private
* data from the primary encoder, we should rather let the companion
@@ -739,7 +778,7 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds *lvds)
* for the time being.
*/
companion_lvds = bridge_to_rcar_lvds(lvds->companion);
- companion_lvds->dual_link = true;
+ companion_lvds->link_type = lvds->link_type;

done:
of_node_put(companion);
--
2.17.1


[PATCH 4.19.y-cip 11/17] drm: of: Add drm_of_lvds_get_dual_link_pixel_order

Biju Das <biju.das.jz@...>
 

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

commit 6529007522ded00b8912c079250620fa7a732166 upstream.

An LVDS dual-link connection is made of two links, with even
pixels transitting on one link, and odd pixels on the other
link. The device tree can be used to fully describe dual-link
LVDS connections between encoders and bridges/panels.
The sink of an LVDS dual-link connection is made of two ports,
the corresponding OF graph port nodes can be marked
with either dual-lvds-even-pixels or dual-lvds-odd-pixels,
and that fully describes an LVDS dual-link connection,
including pixel order.

drm_of_lvds_get_dual_link_pixel_order is a new helper
added by this patch, given the source port nodes it
returns DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS if the source
port nodes belong to an LVDS dual-link connection, with even
pixels expected to be generated from the first port, and odd
pixels expected to be generated from the second port.
If the new helper returns DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS,
odd pixels are expected to be generated from the first port,
and even pixels from the other port.

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
drivers/gpu/drm/drm_of.c | 116 +++++++++++++++++++++++++++++++++++++++
include/drm/drm_of.h | 20 +++++++
2 files changed, 136 insertions(+)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 2763a5ec845b..4f0bc1363fbe 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -275,3 +275,119 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
return ret;
}
EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
+
+enum drm_of_lvds_pixels {
+ DRM_OF_LVDS_EVEN = BIT(0),
+ DRM_OF_LVDS_ODD = BIT(1),
+};
+
+static int drm_of_lvds_get_port_pixels_type(struct device_node *port_node)
+{
+ bool even_pixels =
+ of_property_read_bool(port_node, "dual-lvds-even-pixels");
+ bool odd_pixels =
+ of_property_read_bool(port_node, "dual-lvds-odd-pixels");
+
+ return (even_pixels ? DRM_OF_LVDS_EVEN : 0) |
+ (odd_pixels ? DRM_OF_LVDS_ODD : 0);
+}
+
+static int drm_of_lvds_get_remote_pixels_type(
+ const struct device_node *port_node)
+{
+ struct device_node *endpoint = NULL;
+ int pixels_type = -EPIPE;
+
+ for_each_child_of_node(port_node, endpoint) {
+ struct device_node *remote_port;
+ int current_pt;
+
+ if (!of_node_name_eq(endpoint, "endpoint"))
+ continue;
+
+ remote_port = of_graph_get_remote_port(endpoint);
+ if (!remote_port) {
+ of_node_put(remote_port);
+ return -EPIPE;
+ }
+
+ current_pt = drm_of_lvds_get_port_pixels_type(remote_port);
+ of_node_put(remote_port);
+ if (pixels_type < 0)
+ pixels_type = current_pt;
+
+ /*
+ * Sanity check, ensure that all remote endpoints have the same
+ * pixel type. We may lift this restriction later if we need to
+ * support multiple sinks with different dual-link
+ * configurations by passing the endpoints explicitly to
+ * drm_of_lvds_get_dual_link_pixel_order().
+ */
+ if (!current_pt || pixels_type != current_pt) {
+ of_node_put(remote_port);
+ return -EINVAL;
+ }
+ }
+
+ return pixels_type;
+}
+
+/**
+ * drm_of_lvds_get_dual_link_pixel_order - Get LVDS dual-link pixel order
+ * @port1: First DT port node of the Dual-link LVDS source
+ * @port2: Second DT port node of the Dual-link LVDS source
+ *
+ * An LVDS dual-link connection is made of two links, with even pixels
+ * transitting on one link, and odd pixels on the other link. This function
+ * returns, for two ports of an LVDS dual-link source, which port shall transmit
+ * the even and odd pixels, based on the requirements of the connected sink.
+ *
+ * The pixel order is determined from the dual-lvds-even-pixels and
+ * dual-lvds-odd-pixels properties in the sink's DT port nodes. If those
+ * properties are not present, or if their usage is not valid, this function
+ * returns -EINVAL.
+ *
+ * If either port is not connected, this function returns -EPIPE.
+ *
+ * @port1 and @port2 are typically DT sibling nodes, but may have different
+ * parents when, for instance, two separate LVDS encoders carry the even and odd
+ * pixels.
+ *
+ * Return:
+ * * DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS - @port1 carries even pixels and @port2
+ * carries odd pixels
+ * * DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS - @port1 carries odd pixels and @port2
+ * carries even pixels
+ * * -EINVAL - @port1 and @port2 are not connected to a dual-link LVDS sink, or
+ * the sink configuration is invalid
+ * * -EPIPE - when @port1 or @port2 are not connected
+ */
+int drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
+ const struct device_node *port2)
+{
+ int remote_p1_pt, remote_p2_pt;
+
+ if (!port1 || !port2)
+ return -EINVAL;
+
+ remote_p1_pt = drm_of_lvds_get_remote_pixels_type(port1);
+ if (remote_p1_pt < 0)
+ return remote_p1_pt;
+
+ remote_p2_pt = drm_of_lvds_get_remote_pixels_type(port2);
+ if (remote_p2_pt < 0)
+ return remote_p2_pt;
+
+ /*
+ * A valid dual-lVDS bus is found when one remote port is marked with
+ * "dual-lvds-even-pixels", and the other remote port is marked with
+ * "dual-lvds-odd-pixels", bail out if the markers are not right.
+ */
+ if (remote_p1_pt + remote_p2_pt != DRM_OF_LVDS_EVEN + DRM_OF_LVDS_ODD)
+ return -EINVAL;
+
+ return remote_p1_pt == DRM_OF_LVDS_EVEN ?
+ DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS :
+ DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS;
+}
+EXPORT_SYMBOL_GPL(drm_of_lvds_get_dual_link_pixel_order);
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index ead34ab5ca4e..8ec7ca6d2369 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -16,6 +16,18 @@ struct drm_panel;
struct drm_bridge;
struct device_node;

+/**
+ * enum drm_lvds_dual_link_pixels - Pixel order of an LVDS dual-link connection
+ * @DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS: Even pixels are expected to be generated
+ * from the first port, odd pixels from the second port
+ * @DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS: Odd pixels are expected to be generated
+ * from the first port, even pixels from the second port
+ */
+enum drm_lvds_dual_link_pixels {
+ DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS = 0,
+ DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS = 1,
+};
+
#ifdef CONFIG_OF
uint32_t drm_of_crtc_port_mask(struct drm_device *dev,
struct device_node *port);
@@ -35,6 +47,8 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
int port, int endpoint,
struct drm_panel **panel,
struct drm_bridge **bridge);
+int drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
+ const struct device_node *port2);
#else
static inline uint32_t drm_of_crtc_port_mask(struct drm_device *dev,
struct device_node *port)
@@ -77,6 +91,12 @@ static inline int drm_of_find_panel_or_bridge(const struct device_node *np,
{
return -EINVAL;
}
+
+int drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
+ const struct device_node *port2)
+{
+ return -EINVAL;
+}
#endif

/*
--
2.17.1


[PATCH 4.19.y-cip 05/17] drm: rcar-du: Skip LVDS1 output on Gen3 when using dual-link LVDS mode

Biju Das <biju.das.jz@...>
 

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

commit 8e8fddab0d0acdefb1ad76852d954b2bbaa3896d upstream.

In dual-link LVDS mode, the LVDS1 encoder is used as a companion for
LVDS0, and both encoders transmit data from DU0. The LVDS1 output of DU1
can't be used in that case, don't create an encoder and connector for
it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 12 ++++++++++++
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 5cca7f7aacd8..de8fe74c0362 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -21,6 +21,7 @@
#include "rcar_du_drv.h"
#include "rcar_du_encoder.h"
#include "rcar_du_kms.h"
+#include "rcar_lvds.h"

/* -----------------------------------------------------------------------------
* Encoder
@@ -60,6 +61,17 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
goto done;
}

+ /*
+ * On Gen3 skip the LVDS1 output if the LVDS1 encoder is used as a
+ * companion for LVDS0 in dual-link mode.
+ */
+ if (rcdu->info->gen >= 3 && output == RCAR_DU_OUTPUT_LVDS1) {
+ if (rcar_lvds_dual_link(bridge)) {
+ ret = -ENOLINK;
+ goto done;
+ }
+ }
+
ret = drm_encoder_init(rcdu->ddev, encoder, &encoder_funcs,
DRM_MODE_ENCODER_NONE, NULL);
if (ret < 0)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 3257aca39a65..5cf0331defd4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -380,7 +380,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device *rcdu,
}

ret = rcar_du_encoder_init(rcdu, output, entity);
- if (ret && ret != -EPROBE_DEFER)
+ if (ret && ret != -EPROBE_DEFER && ret != -ENOLINK)
dev_warn(rcdu->dev,
"failed to initialize encoder %pOF on output %u (%d), skipping\n",
entity, output, ret);
--
2.17.1


[PATCH 4.19.y-cip 14/17] arm64: dts: renesas: r8a774c0: Point LVDS0 to its companion LVDS1

Biju Das <biju.das.jz@...>
 

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

commit a2fe2cd26285061fd9ef2649bac529f1db33d50b upstream.

Add the new renesas,companion property to the LVDS0 node to point to the
companion LVDS encoder LVDS1.
Based on similar work from Laurent Pinchart for the r8a7799[05].

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 2 ++
1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
index cf25dbb1b4e1..75d4fbd2579e 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
@@ -1850,6 +1850,8 @@
resets = <&cpg 727>;
status = "disabled";

+ renesas,companion = <&lvds1>;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.17.1


[PATCH 4.19.y-cip 04/17] drm: rcar-du: lvds: Add support for dual-link mode

Biju Das <biju.das.jz@...>
 

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

commit fa440d870358fd01eeedd212a1ad918a3b2771d5 upstream.

In dual-link mode the LVDS0 encoder transmits even-numbered pixels, and
sends odd-numbered pixels to the LVDS1 encoder for transmission on a
separate link.

To implement support for this mode of operation, determine if the LVDS
connection operates in dual-link mode by querying the next device in the
pipeline, locate the companion encoder, and control it directly through
its bridge operations.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 107 ++++++++++++++++++++++++----
drivers/gpu/drm/rcar-du/rcar_lvds.h | 5 ++
2 files changed, 99 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 067017d25993..0774bd00dfac 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -65,6 +65,9 @@ struct rcar_lvds {

struct drm_display_mode display_mode;
enum rcar_lvds_mode mode;
+
+ struct drm_bridge *companion;
+ bool dual_link;
};

#define bridge_to_rcar_lvds(b) \
@@ -399,11 +402,6 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
{
struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
const struct drm_display_mode *mode = &lvds->display_mode;
- /*
- * FIXME: We should really retrieve the CRTC through the state, but how
- * do we get a state pointer?
- */
- struct drm_crtc *crtc = lvds->bridge.encoder->crtc;
u32 lvdhcr;
u32 lvdcr0;
int ret;
@@ -412,6 +410,10 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
if (ret < 0)
return;

+ /* Enable the companion LVDS encoder in dual-link mode. */
+ if (lvds->dual_link && lvds->companion)
+ lvds->companion->funcs->enable(lvds->companion);
+
/*
* Hardcode the channels and control signals routing for now.
*
@@ -434,17 +436,33 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
rcar_lvds_write(lvds, LVDCHCR, lvdhcr);

if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) {
- /* Disable dual-link mode. */
- rcar_lvds_write(lvds, LVDSTRIPE, 0);
+ /*
+ * Configure vertical stripe based on the mode of operation of
+ * the connected device.
+ */
+ rcar_lvds_write(lvds, LVDSTRIPE,
+ lvds->dual_link ? LVDSTRIPE_ST_ON : 0);
}

- /* PLL clock configuration. */
- lvds->info->pll_setup(lvds, mode->clock * 1000);
+ /*
+ * PLL clock configuration on all instances but the companion in
+ * dual-link mode.
+ */
+ if (!lvds->dual_link || lvds->companion)
+ lvds->info->pll_setup(lvds, mode->clock * 1000);

/* Set the LVDS mode and select the input. */
lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
- if (drm_crtc_index(crtc) == 2)
- lvdcr0 |= LVDCR0_DUSEL;
+
+ if (lvds->bridge.encoder) {
+ /*
+ * FIXME: We should really retrieve the CRTC through the state,
+ * but how do we get a state pointer?
+ */
+ if (drm_crtc_index(lvds->bridge.encoder->crtc) == 2)
+ lvdcr0 |= LVDCR0_DUSEL;
+ }
+
rcar_lvds_write(lvds, LVDCR0, lvdcr0);

/* Turn all the channels on. */
@@ -507,6 +525,10 @@ static void rcar_lvds_disable(struct drm_bridge *bridge)
rcar_lvds_write(lvds, LVDCR1, 0);
rcar_lvds_write(lvds, LVDPLLCR, 0);

+ /* Disable the companion LVDS encoder in dual-link mode. */
+ if (lvds->dual_link && lvds->companion)
+ lvds->companion->funcs->disable(lvds->companion);
+
clk_disable_unprepare(lvds->clocks.mod);
}

@@ -623,10 +645,57 @@ static const struct drm_bridge_funcs rcar_lvds_bridge_ops = {
.mode_set = rcar_lvds_mode_set,
};

+bool rcar_lvds_dual_link(struct drm_bridge *bridge)
+{
+ struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
+
+ return lvds->dual_link;
+}
+EXPORT_SYMBOL_GPL(rcar_lvds_dual_link);
+
/* -----------------------------------------------------------------------------
* Probe & Remove
*/

+static int rcar_lvds_parse_dt_companion(struct rcar_lvds *lvds)
+{
+ const struct of_device_id *match;
+ struct device_node *companion;
+ struct device *dev = lvds->dev;
+ int ret = 0;
+
+ /* Locate the companion LVDS encoder for dual-link operation, if any. */
+ companion = of_parse_phandle(dev->of_node, "renesas,companion", 0);
+ if (!companion) {
+ dev_err(dev, "Companion LVDS encoder not found\n");
+ return -ENXIO;
+ }
+
+ /*
+ * Sanity check: the companion encoder must have the same compatible
+ * string.
+ */
+ match = of_match_device(dev->driver->of_match_table, dev);
+ if (!of_device_is_compatible(companion, match->compatible)) {
+ dev_err(dev, "Companion LVDS encoder is invalid\n");
+ ret = -ENXIO;
+ goto done;
+ }
+
+ lvds->companion = of_drm_find_bridge(companion);
+ if (!lvds->companion) {
+ ret = -EPROBE_DEFER;
+ goto done;
+ }
+
+ dev_dbg(dev, "Found companion encoder %pOF\n", companion);
+
+done:
+ of_node_put(companion);
+
+ return ret;
+}
+
static int rcar_lvds_parse_dt(struct rcar_lvds *lvds)
{
struct device_node *local_output = NULL;
@@ -677,14 +746,26 @@ static int rcar_lvds_parse_dt(struct rcar_lvds *lvds)

if (is_bridge) {
lvds->next_bridge = of_drm_find_bridge(remote);
- if (!lvds->next_bridge)
+ if (!lvds->next_bridge) {
ret = -EPROBE_DEFER;
+ goto done;
+ }
+
+ if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK)
+ lvds->dual_link = lvds->next_bridge->timings
+ ? lvds->next_bridge->timings->dual_link
+ : false;
} else {
lvds->panel = of_drm_find_panel(remote);
- if (IS_ERR(lvds->panel))
+ if (IS_ERR(lvds->panel)) {
ret = PTR_ERR(lvds->panel);
+ goto done;
+ }
}

+ if (lvds->dual_link)
+ ret = rcar_lvds_parse_dt_companion(lvds);
+
done:
of_node_put(local_output);
of_node_put(remote_input);
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.h b/drivers/gpu/drm/rcar-du/rcar_lvds.h
index a709cae1bc32..222ec0e60785 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.h
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.h
@@ -15,6 +15,7 @@ struct drm_bridge;
#if IS_ENABLED(CONFIG_DRM_RCAR_LVDS)
int rcar_lvds_clk_enable(struct drm_bridge *bridge, unsigned long freq);
void rcar_lvds_clk_disable(struct drm_bridge *bridge);
+bool rcar_lvds_dual_link(struct drm_bridge *bridge);
#else
static inline int rcar_lvds_clk_enable(struct drm_bridge *bridge,
unsigned long freq)
@@ -22,6 +23,10 @@ static inline int rcar_lvds_clk_enable(struct drm_bridge *bridge,
return -ENOSYS;
}
static inline void rcar_lvds_clk_disable(struct drm_bridge *bridge) { }
+static inline bool rcar_lvds_dual_link(struct drm_bridge *bridge)
+{
+ return false;
+}
#endif /* CONFIG_DRM_RCAR_LVDS */

#endif /* __RCAR_LVDS_H__ */
--
2.17.1


[PATCH 4.19.y-cip 02/17] drm: bridge: Add dual_link field to the drm_bridge_timings structure

Biju Das <biju.das.jz@...>
 

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

commit b0a6b94027c85857f768a586cbcf1e96ee1d04ae upstreaam.

Extend the drm_bridge_timings structure with a new dual_link field to
indicate that the bridge's input bus carries data on two separate
physical links. The first use case is LVDS dual-link mode where even-
and odd-numbered pixels are transferred on separate LVDS links.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
include/drm/drm_bridge.h | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index bd850747ce54..d26eaa317fc2 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -266,6 +266,14 @@ struct drm_bridge_timings {
* input signal after the clock edge.
*/
u32 hold_time_ps;
+ /**
+ * @dual_link:
+ *
+ * True if the bus operates in dual-link mode. The exact meaning is
+ * dependent on the bus type. For LVDS buses, this indicates that even-
+ * and odd-numbered pixels are received on separate links.
+ */
+ bool dual_link;
};

/**
--
2.17.1


[PATCH 4.19.y-cip 01/17] drm: rcar-du: lvds: Remove LVDS double-enable checks

Biju Das <biju.das.jz@...>
 

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

commit 968328496b0fbee42abb6fae98ba0dc720bda977 upstream.

The DRM core and DU driver guarantee that the LVDS bridge will not be
double-enabled or double-disabled. Remove the corresponding unnecessary
checks.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 19 -------------------
1 file changed, 19 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 21fd248e5cbf..067017d25993 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -62,7 +62,6 @@ struct rcar_lvds {
struct clk *extal; /* External clock */
struct clk *dotclkin[2]; /* External DU clocks */
} clocks;
- bool enabled;

struct drm_display_mode display_mode;
enum rcar_lvds_mode mode;
@@ -367,15 +366,12 @@ int rcar_lvds_clk_enable(struct drm_bridge *bridge, unsigned long freq)

dev_dbg(lvds->dev, "enabling LVDS PLL, freq=%luHz\n", freq);

- WARN_ON(lvds->enabled);
-
ret = clk_prepare_enable(lvds->clocks.mod);
if (ret < 0)
return ret;

__rcar_lvds_pll_setup_d3_e3(lvds, freq, true);

- lvds->enabled = true;
return 0;
}
EXPORT_SYMBOL_GPL(rcar_lvds_clk_enable);
@@ -389,13 +385,9 @@ void rcar_lvds_clk_disable(struct drm_bridge *bridge)

dev_dbg(lvds->dev, "disabling LVDS PLL\n");

- WARN_ON(!lvds->enabled);
-
rcar_lvds_write(lvds, LVDPLLCR, 0);

clk_disable_unprepare(lvds->clocks.mod);
-
- lvds->enabled = false;
}
EXPORT_SYMBOL_GPL(rcar_lvds_clk_disable);

@@ -416,8 +408,6 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
u32 lvdcr0;
int ret;

- WARN_ON(lvds->enabled);
-
ret = clk_prepare_enable(lvds->clocks.mod);
if (ret < 0)
return;
@@ -502,16 +492,12 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
drm_panel_prepare(lvds->panel);
drm_panel_enable(lvds->panel);
}
-
- lvds->enabled = true;
}

static void rcar_lvds_disable(struct drm_bridge *bridge)
{
struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);

- WARN_ON(!lvds->enabled);
-
if (lvds->panel) {
drm_panel_disable(lvds->panel);
drm_panel_unprepare(lvds->panel);
@@ -522,8 +508,6 @@ static void rcar_lvds_disable(struct drm_bridge *bridge)
rcar_lvds_write(lvds, LVDPLLCR, 0);

clk_disable_unprepare(lvds->clocks.mod);
-
- lvds->enabled = false;
}

static bool rcar_lvds_mode_fixup(struct drm_bridge *bridge,
@@ -587,8 +571,6 @@ static void rcar_lvds_mode_set(struct drm_bridge *bridge,
{
struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);

- WARN_ON(lvds->enabled);
-
lvds->display_mode = *adjusted_mode;

rcar_lvds_get_lvds_mode(lvds);
@@ -788,7 +770,6 @@ static int rcar_lvds_probe(struct platform_device *pdev)

lvds->dev = &pdev->dev;
lvds->info = of_device_get_match_data(&pdev->dev);
- lvds->enabled = false;

ret = rcar_lvds_parse_dt(lvds);
if (ret < 0)
--
2.17.1


[PATCH 4.19.y-cip 08/17] drm: Add atomic variants for bridge enable/disable

Biju Das <biju.das.jz@...>
 

From: Sean Paul <seanpaul@chromium.org>

commit 5ade071ba13e3bb24e3a9d5f8d6a3cf145deeb18 upstream.

This patch adds atomic variants for all of
pre_enable/enable/disable/post_disable bridge functions. These will be
called from the appropriate atomic helper functions. If the bridge
driver doesn't implement the atomic version of the function, we will
fall back to the vanilla implementation.

Note that some drivers call drm_bridge_disable directly, and these cases
are not covered. It's up to the driver to decide whether to implement
both atomic_disable and disable, or if it's not necessary.

Changes in v3:
- Added to the patchset
Changes in v4:
- Fix up docbook references (Daniel)
Changes in v5:
- None

Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-4-sean@poorly.run
Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-4-sean@poorly.run

Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190611160844.257498-4-sean@poorly.run
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
drivers/gpu/drm/drm_atomic_helper.c | 8 +-
drivers/gpu/drm/drm_bridge.c | 110 ++++++++++++++++++++++++++++
include/drm/drm_bridge.h | 106 +++++++++++++++++++++++++++
3 files changed, 220 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index c22062cc9992..84bc8af8fc71 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -951,7 +951,7 @@ disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state)
* Each encoder has at most one connector (since we always steal
* it away), so we won't call disable hooks twice.
*/
- drm_bridge_disable(encoder->bridge);
+ drm_atomic_bridge_disable(encoder->bridge, old_state);

/* Right function depends upon target state. */
if (funcs) {
@@ -963,7 +963,7 @@ disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state)
funcs->dpms(encoder, DRM_MODE_DPMS_OFF);
}

- drm_bridge_post_disable(encoder->bridge);
+ drm_atomic_bridge_post_disable(encoder->bridge, old_state);
}

for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) {
@@ -1262,7 +1262,7 @@ void drm_atomic_helper_commit_modeset_enables(struct drm_device *dev,
* Each encoder has at most one connector (since we always steal
* it away), so we won't call enable hooks twice.
*/
- drm_bridge_pre_enable(encoder->bridge);
+ drm_atomic_bridge_pre_enable(encoder->bridge, old_state);

if (funcs) {
if (funcs->enable)
@@ -1271,7 +1271,7 @@ void drm_atomic_helper_commit_modeset_enables(struct drm_device *dev,
funcs->commit(encoder);
}

- drm_bridge_enable(encoder->bridge);
+ drm_atomic_bridge_enable(encoder->bridge, old_state);
}

drm_atomic_helper_commit_writebacks(dev, old_state);
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 1638bfe9627c..190f43380e29 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -348,6 +348,116 @@ void drm_bridge_enable(struct drm_bridge *bridge)
}
EXPORT_SYMBOL(drm_bridge_enable);

+/**
+ * drm_atomic_bridge_disable - disables all bridges in the encoder chain
+ * @bridge: bridge control structure
+ * @state: atomic state being committed
+ *
+ * Calls &drm_bridge_funcs.atomic_disable (falls back on
+ * &drm_bridge_funcs.disable) op for all the bridges in the encoder chain,
+ * starting from the last bridge to the first. These are called before calling
+ * &drm_encoder_helper_funcs.atomic_disable
+ *
+ * Note: the bridge passed should be the one closest to the encoder
+ */
+void drm_atomic_bridge_disable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state)
+{
+ if (!bridge)
+ return;
+
+ drm_atomic_bridge_disable(bridge->next, state);
+
+ if (bridge->funcs->atomic_disable)
+ bridge->funcs->atomic_disable(bridge, state);
+ else if (bridge->funcs->disable)
+ bridge->funcs->disable(bridge);
+}
+EXPORT_SYMBOL(drm_atomic_bridge_disable);
+
+/**
+ * drm_atomic_bridge_post_disable - cleans up after disabling all bridges in the
+ * encoder chain
+ * @bridge: bridge control structure
+ * @state: atomic state being committed
+ *
+ * Calls &drm_bridge_funcs.atomic_post_disable (falls back on
+ * &drm_bridge_funcs.post_disable) op for all the bridges in the encoder chain,
+ * starting from the first bridge to the last. These are called after completing
+ * &drm_encoder_helper_funcs.atomic_disable
+ *
+ * Note: the bridge passed should be the one closest to the encoder
+ */
+void drm_atomic_bridge_post_disable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state)
+{
+ if (!bridge)
+ return;
+
+ if (bridge->funcs->atomic_post_disable)
+ bridge->funcs->atomic_post_disable(bridge, state);
+ else if (bridge->funcs->post_disable)
+ bridge->funcs->post_disable(bridge);
+
+ drm_atomic_bridge_post_disable(bridge->next, state);
+}
+EXPORT_SYMBOL(drm_atomic_bridge_post_disable);
+
+/**
+ * drm_atomic_bridge_pre_enable - prepares for enabling all bridges in the
+ * encoder chain
+ * @bridge: bridge control structure
+ * @state: atomic state being committed
+ *
+ * Calls &drm_bridge_funcs.atomic_pre_enable (falls back on
+ * &drm_bridge_funcs.pre_enable) op for all the bridges in the encoder chain,
+ * starting from the last bridge to the first. These are called before calling
+ * &drm_encoder_helper_funcs.atomic_enable
+ *
+ * Note: the bridge passed should be the one closest to the encoder
+ */
+void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state)
+{
+ if (!bridge)
+ return;
+
+ drm_atomic_bridge_pre_enable(bridge->next, state);
+
+ if (bridge->funcs->atomic_pre_enable)
+ bridge->funcs->atomic_pre_enable(bridge, state);
+ else if (bridge->funcs->pre_enable)
+ bridge->funcs->pre_enable(bridge);
+}
+EXPORT_SYMBOL(drm_atomic_bridge_pre_enable);
+
+/**
+ * drm_atomic_bridge_enable - enables all bridges in the encoder chain
+ * @bridge: bridge control structure
+ * @state: atomic state being committed
+ *
+ * Calls &drm_bridge_funcs.atomic_enable (falls back on
+ * &drm_bridge_funcs.enable) op for all the bridges in the encoder chain,
+ * starting from the first bridge to the last. These are called after completing
+ * &drm_encoder_helper_funcs.atomic_enable
+ *
+ * Note: the bridge passed should be the one closest to the encoder
+ */
+void drm_atomic_bridge_enable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state)
+{
+ if (!bridge)
+ return;
+
+ if (bridge->funcs->atomic_enable)
+ bridge->funcs->atomic_enable(bridge, state);
+ else if (bridge->funcs->enable)
+ bridge->funcs->enable(bridge);
+
+ drm_atomic_bridge_enable(bridge->next, state);
+}
+EXPORT_SYMBOL(drm_atomic_bridge_enable);
+
#ifdef CONFIG_OF
/**
* of_drm_find_bridge - find the bridge corresponding to the device node in
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index d26eaa317fc2..97b17cb9cc51 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -237,6 +237,103 @@ struct drm_bridge_funcs {
* The enable callback is optional.
*/
void (*enable)(struct drm_bridge *bridge);
+
+ /**
+ * @atomic_pre_enable:
+ *
+ * This callback should enable the bridge. It is called right before
+ * the preceding element in the display pipe is enabled. If the
+ * preceding element is a bridge this means it's called before that
+ * bridge's @atomic_pre_enable or @pre_enable function. If the preceding
+ * element is a &drm_encoder it's called right before the encoder's
+ * &drm_encoder_helper_funcs.atomic_enable hook.
+ *
+ * The display pipe (i.e. clocks and timing signals) feeding this bridge
+ * will not yet be running when this callback is called. The bridge must
+ * not enable the display link feeding the next bridge in the chain (if
+ * there is one) when this callback is called.
+ *
+ * Note that this function will only be invoked in the context of an
+ * atomic commit. It will not be invoked from &drm_bridge_pre_enable. It
+ * would be prudent to also provide an implementation of @pre_enable if
+ * you are expecting driver calls into &drm_bridge_pre_enable.
+ *
+ * The @atomic_pre_enable callback is optional.
+ */
+ void (*atomic_pre_enable)(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
+
+ /**
+ * @atomic_enable:
+ *
+ * This callback should enable the bridge. It is called right after
+ * the preceding element in the display pipe is enabled. If the
+ * preceding element is a bridge this means it's called after that
+ * bridge's @atomic_enable or @enable function. If the preceding element
+ * is a &drm_encoder it's called right after the encoder's
+ * &drm_encoder_helper_funcs.atomic_enable hook.
+ *
+ * The bridge can assume that the display pipe (i.e. clocks and timing
+ * signals) feeding it is running when this callback is called. This
+ * callback must enable the display link feeding the next bridge in the
+ * chain if there is one.
+ *
+ * Note that this function will only be invoked in the context of an
+ * atomic commit. It will not be invoked from &drm_bridge_enable. It
+ * would be prudent to also provide an implementation of @enable if
+ * you are expecting driver calls into &drm_bridge_enable.
+ *
+ * The enable callback is optional.
+ */
+ void (*atomic_enable)(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
+ /**
+ * @atomic_disable:
+ *
+ * This callback should disable the bridge. It is called right before
+ * the preceding element in the display pipe is disabled. If the
+ * preceding element is a bridge this means it's called before that
+ * bridge's @atomic_disable or @disable vfunc. If the preceding element
+ * is a &drm_encoder it's called right before the
+ * &drm_encoder_helper_funcs.atomic_disable hook.
+ *
+ * The bridge can assume that the display pipe (i.e. clocks and timing
+ * signals) feeding it is still running when this callback is called.
+ *
+ * Note that this function will only be invoked in the context of an
+ * atomic commit. It will not be invoked from &drm_bridge_disable. It
+ * would be prudent to also provide an implementation of @disable if
+ * you are expecting driver calls into &drm_bridge_disable.
+ *
+ * The disable callback is optional.
+ */
+ void (*atomic_disable)(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
+
+ /**
+ * @atomic_post_disable:
+ *
+ * This callback should disable the bridge. It is called right after the
+ * preceding element in the display pipe is disabled. If the preceding
+ * element is a bridge this means it's called after that bridge's
+ * @atomic_post_disable or @post_disable function. If the preceding
+ * element is a &drm_encoder it's called right after the encoder's
+ * &drm_encoder_helper_funcs.atomic_disable hook.
+ *
+ * The bridge must assume that the display pipe (i.e. clocks and timing
+ * signals) feeding it is no longer running when this callback is
+ * called.
+ *
+ * Note that this function will only be invoked in the context of an
+ * atomic commit. It will not be invoked from &drm_bridge_post_disable.
+ * It would be prudent to also provide an implementation of
+ * @post_disable if you are expecting driver calls into
+ * &drm_bridge_post_disable.
+ *
+ * The post_disable callback is optional.
+ */
+ void (*atomic_post_disable)(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
};

/**
@@ -323,6 +420,15 @@ void drm_bridge_mode_set(struct drm_bridge *bridge,
void drm_bridge_pre_enable(struct drm_bridge *bridge);
void drm_bridge_enable(struct drm_bridge *bridge);

+void drm_atomic_bridge_disable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
+void drm_atomic_bridge_post_disable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
+void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
+void drm_atomic_bridge_enable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
+
#ifdef CONFIG_DRM_PANEL_BRIDGE
struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
u32 connector_type);
--
2.17.1


[PATCH 4.19.y-cip 00/17] Add RZ/G2E Dual LVDS display

Biju Das <biju.das.jz@...>
 

Add RZ/G2E Dual LVDS display support. All patches in this series are
cherry-picked from upstream kernel.

Fabrizio Castro (7):
drm: rcar-du: lvds: Improve identification of panels
drm: of: Add drm_of_lvds_get_dual_link_pixel_order
drm: rcar-du: lvds: Get dual link configuration from DT
drm: rcar-du: lvds: Allow for even and odd pixels swap
arm64: dts: renesas: r8a774c0: Point LVDS0 to its companion LVDS1
dt-bindings: display: Add idk-2121wr binding
arm64: dts: renesas: Add EK874 board with idk-2121wr display support

Geert Uytterhoeven (1):
arm64: dts: renesas: rzg2: Add reset control properties for display

Jacopo Mondi (1):
drm: rcar_lvds: Fix dual link mode operations

Laurent Pinchart (7):
drm: rcar-du: lvds: Remove LVDS double-enable checks
drm: bridge: Add dual_link field to the drm_bridge_timings structure
dt-bindings: display: renesas: lvds: Add renesas,companion property
drm: rcar-du: lvds: Add support for dual-link mode
drm: rcar-du: Skip LVDS1 output on Gen3 when using dual-link LVDS mode
drm: Add drm_atomic_get_(old|new)_connector_for_encoder() helpers
drm: rcar-du: lvds: Get mode from state

Sean Paul (1):
drm: Add atomic variants for bridge enable/disable

.../bindings/display/bridge/renesas,lvds.txt | 18 +-
.../display/panel/advantech,idk-2121wr.yaml | 122 ++++++
arch/arm64/boot/dts/renesas/Makefile | 3 +-
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 5 +-
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 5 +-
.../dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 116 ++++++
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 8 +-
drivers/gpu/drm/drm_atomic.c | 113 ++++++
drivers/gpu/drm/drm_atomic_helper.c | 8 +-
drivers/gpu/drm/drm_bridge.c | 110 ++++++
drivers/gpu/drm/drm_of.c | 116 ++++++
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 12 +
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_lvds.c | 348 +++++++++++-------
drivers/gpu/drm/rcar-du/rcar_lvds.h | 5 +
include/drm/drm_atomic.h | 7 +
include/drm/drm_bridge.h | 114 ++++++
include/drm/drm_connector.h | 9 +
include/drm/drm_of.h | 20 +
19 files changed, 996 insertions(+), 145 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts

--
2.17.1


Re: [isar-cip-core] tests: put all tests into a opt layer

Jan Kiszka
 

On 22.07.20 12:46, Daniel Sangorrin wrote:
Hi Jan

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Jan Kiszka
Sent: Wednesday, July 22, 2020 5:05 PM
To: sangorrin daniel(サンゴリン ダニエル □SWC◯ACT) <daniel.sangorrin@toshiba.co.jp>; cip-dev@lists.cip-project.org; iwamatsu
nobuhiro(岩松 信洋 □SWC◯ACT) <nobuhiro1.iwamatsu@toshiba.co.jp>
Subject: Re: [cip-dev] [isar-cip-core] tests: put all tests into a opt layer

On 22.07.20 09:25, daniel.sangorrin@toshiba.co.jp wrote:
________________________________________
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Wednesday, July 22, 2020 3:44 PM
To: cip-dev@lists.cip-project.org; sangorrin daniel(サンゴリン ダニエル
□SWC◯ACT); iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
Subject: Re: [cip-dev] [isar-cip-core] tests: put all tests into a opt
layer

On 21.07.20 14:42, Daniel Sangorrin wrote:
having an opt-tests layer makes it easier to see what tests are
installed, and allows creating images without them as well
JAN:
"Having ... as well."

Does this obsolete
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests
/7,
where I just commented on?

DANIEL: Maybe you can apply Iwamatsu-san merge request first, and I will prepare a new patch on top of that to avoid confusion.
That would confuse me now: What creating a separate test image first, just to remove it again?
Sorry for the confusion.
If you apply MR7, I will move the rt-tests and stress-ng packages from the customization "package" to the test image.
If you instead apply MR5, I will move them to opt-testtools.yml
Or is there any special reason for rt-tests and stress-ng to be in the customization package?
Nobuhiro, is something missing from your perspective in Daniels approach? If not, I'd like to have one patch that takes us to that level.

By now, I think an opt-testtools.yml is better (an "option", not a "layer") than a separate image. That allows to test the security image eventually as well.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: [isar-cip-core] tests: put all tests into a opt layer

Daniel Sangorrin
 

Hi Jan

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Jan Kiszka
Sent: Wednesday, July 22, 2020 5:05 PM
To: sangorrin daniel(サンゴリン ダニエル □SWC◯ACT) <daniel.sangorrin@toshiba.co.jp>; cip-dev@lists.cip-project.org; iwamatsu
nobuhiro(岩松 信洋 □SWC◯ACT) <nobuhiro1.iwamatsu@toshiba.co.jp>
Subject: Re: [cip-dev] [isar-cip-core] tests: put all tests into a opt layer

On 22.07.20 09:25, daniel.sangorrin@toshiba.co.jp wrote:
________________________________________
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Wednesday, July 22, 2020 3:44 PM
To: cip-dev@lists.cip-project.org; sangorrin daniel(サンゴリン ダニエル
□SWC◯ACT); iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
Subject: Re: [cip-dev] [isar-cip-core] tests: put all tests into a opt
layer

On 21.07.20 14:42, Daniel Sangorrin wrote:
having an opt-tests layer makes it easier to see what tests are
installed, and allows creating images without them as well
JAN:
"Having ... as well."

Does this obsolete
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests
/7,
where I just commented on?

DANIEL: Maybe you can apply Iwamatsu-san merge request first, and I will prepare a new patch on top of that to avoid confusion.
That would confuse me now: What creating a separate test image first, just to remove it again?
Sorry for the confusion.

If you apply MR7, I will move the rt-tests and stress-ng packages from the customization "package" to the test image.
If you instead apply MR5, I will move them to opt-testtools.yml

Or is there any special reason for rt-tests and stress-ng to be in the customization package?

Thanks,
Daniel


Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux


Re: [isar-cip-core] tests: put all tests into a opt layer

Jan Kiszka
 

On 22.07.20 09:25, daniel.sangorrin@toshiba.co.jp wrote:
________________________________________
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Wednesday, July 22, 2020 3:44 PM
To: cip-dev@lists.cip-project.org; sangorrin daniel(サンゴリン ダニエル □SWC◯ACT); iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
Subject: Re: [cip-dev] [isar-cip-core] tests: put all tests into a opt layer
On 21.07.20 14:42, Daniel Sangorrin wrote:
having an opt-tests layer makes it easier to see what
tests are installed, and allows creating images without
them as well
JAN:
"Having ... as well."
Does this obsolete
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests/7,
where I just commented on?
DANIEL: Maybe you can apply Iwamatsu-san merge request first, and I will prepare a new patch on top of that to avoid confusion.
That would confuse me now: What creating a separate test image first, just to remove it again?

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: [isar-cip-core] tests: put all tests into a opt layer

Daniel Sangorrin
 

________________________________________
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Wednesday, July 22, 2020 3:44 PM
To: cip-dev@lists.cip-project.org; sangorrin daniel(サンゴリン ダニエル □SWC◯ACT); iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
Subject: Re: [cip-dev] [isar-cip-core] tests: put all tests into a opt layer

On 21.07.20 14:42, Daniel Sangorrin wrote:
having an opt-tests layer makes it easier to see what
tests are installed, and allows creating images without
them as well
JAN:
"Having ... as well."

Does this obsolete
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests/7,
where I just commented on?

DANIEL: Maybe you can apply Iwamatsu-san merge request first, and I will prepare a new patch on top of that to avoid confusion.

Thanks,
Daniel


Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
---
.gitlab-ci.yml | 8 ++++----
README.md | 4 ++++
opt-tests.yml | 19 +++++++++++++++++++
recipes-core/customizations/customizations.bb | 5 ++---
recipes-core/images/cip-core-image.bb | 3 +--
5 files changed, 30 insertions(+), 9 deletions(-)
create mode 100644 opt-tests.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 6f1dc91..90eec1f 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -13,17 +13,17 @@ all:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY

- - kas build kas.yml:board-simatic-ipc227e.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-simatic-ipc227e.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster simatic-ipc227e

- sudo rm -rf build/tmp
- - kas build kas.yml:board-bbb.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-bbb.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster bbb am335x-boneblack.dtb

- sudo rm -rf build/tmp
- - kas build kas.yml:board-iwg20m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-iwg20m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster iwg20m r8a7743-iwg20d-q7-dbcm-ca.dtb

- sudo rm -rf build/tmp
- - kas build kas.yml:board-rzg2m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-rzg2m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster hihope-rzg2m renesas/r8a774a1-hihope-rzg2m-ex.dtb
diff --git a/README.md b/README.md
index bbad1a0..7339396 100644
--- a/README.md
+++ b/README.md
@@ -25,6 +25,10 @@ this:

This image can be run using `start-qemu.sh x86`.

+If you want to include the testing layer add ':opt-tests.yml' like this
Wording: It's not a testing layer, it's "test packages", no?

+
+ ./kas-docker --isar build kas.yml:board-qemu-amd64.yml:opt-tests.yml
+
The BeagleBone Black target is selected by `... kas.yml:board-bbb.yml`. In
order to build the image with the PREEMPT-RT kernel, append `:opt-rt.yml` to
the above. Append ':opt-4.4.yml' to use the kernel version 4.4 instead of 4.19.
diff --git a/opt-tests.yml b/opt-tests.yml
new file mode 100644
index 0000000..a1f431d
--- /dev/null
+++ b/opt-tests.yml
@@ -0,0 +1,19 @@
+#
+# CIP Core, generic profile
+#
+# Copyright (c) Toshiba corp., 2020
+#
+# Authors:
+# Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
+#
+# SPDX-License-Identifier: MIT
+#
+
+header:
+ version: 8
+
+local_conf_header:
+ tests: |
+ IMAGE_INSTALL += "ltp-full"
+ IMAGE_PREINSTALL += "rt-tests stress-ng"
This, in fact, has some benefit over a separate image in that it would
also allow to make the security image testable by appending the snippet

+
No extra line at EOF, please.

diff --git a/recipes-core/customizations/customizations.bb b/recipes-core/customizations/customizations.bb
index 38881fb..cbd6daf 100644
--- a/recipes-core/customizations/customizations.bb
+++ b/recipes-core/customizations/customizations.bb
@@ -11,7 +11,7 @@

inherit dpkg-raw

-DESCRIPTION = "CIP Core image demo & test customizations"
+DESCRIPTION = "CIP Core image demo customizations"
Maybe "reference customizations" - typically, you will replace this
package for a real product with a, well, product specific customization.


SRC_URI = " \
file://postinst \
@@ -21,8 +21,7 @@ SRC_URI = " \
DEPENDS += "sshd-regen-keys"

DEBIAN_DEPENDS = " \
- ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys, \
- rt-tests, stress-ng"
+ ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys"

do_install() {
install -v -d ${D}/etc/network/interfaces.d
diff --git a/recipes-core/images/cip-core-image.bb b/recipes-core/images/cip-core-image.bb
index 9ee4b25..188c714 100644
--- a/recipes-core/images/cip-core-image.bb
+++ b/recipes-core/images/cip-core-image.bb
@@ -15,5 +15,4 @@ ISAR_RELEASE_CMD = "git -C ${LAYERDIR_cip-core} describe --tags --dirty --always
DESCRIPTION = "CIP Core image"

IMAGE_INSTALL += "customizations"
-# for cip-testing
-IMAGE_INSTALL += "ltp-full"
+
No extra line at EOF, please.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: [isar-cip-core] tests: put all tests into a opt layer

Jan Kiszka
 

On 21.07.20 14:42, Daniel Sangorrin wrote:
having an opt-tests layer makes it easier to see what
tests are installed, and allows creating images without
them as well
"Having ... as well."

Does this obsolete https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests/7, where I just commented on?

Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
---
.gitlab-ci.yml | 8 ++++----
README.md | 4 ++++
opt-tests.yml | 19 +++++++++++++++++++
recipes-core/customizations/customizations.bb | 5 ++---
recipes-core/images/cip-core-image.bb | 3 +--
5 files changed, 30 insertions(+), 9 deletions(-)
create mode 100644 opt-tests.yml
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 6f1dc91..90eec1f 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -13,17 +13,17 @@ all:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- - kas build kas.yml:board-simatic-ipc227e.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-simatic-ipc227e.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster simatic-ipc227e
- sudo rm -rf build/tmp
- - kas build kas.yml:board-bbb.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-bbb.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster bbb am335x-boneblack.dtb
- sudo rm -rf build/tmp
- - kas build kas.yml:board-iwg20m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-iwg20m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster iwg20m r8a7743-iwg20d-q7-dbcm-ca.dtb
- sudo rm -rf build/tmp
- - kas build kas.yml:board-rzg2m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-rzg2m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster hihope-rzg2m renesas/r8a774a1-hihope-rzg2m-ex.dtb
diff --git a/README.md b/README.md
index bbad1a0..7339396 100644
--- a/README.md
+++ b/README.md
@@ -25,6 +25,10 @@ this:
This image can be run using `start-qemu.sh x86`.
+If you want to include the testing layer add ':opt-tests.yml' like this
Wording: It's not a testing layer, it's "test packages", no?

+
+ ./kas-docker --isar build kas.yml:board-qemu-amd64.yml:opt-tests.yml
+
The BeagleBone Black target is selected by `... kas.yml:board-bbb.yml`. In
order to build the image with the PREEMPT-RT kernel, append `:opt-rt.yml` to
the above. Append ':opt-4.4.yml' to use the kernel version 4.4 instead of 4.19.
diff --git a/opt-tests.yml b/opt-tests.yml
new file mode 100644
index 0000000..a1f431d
--- /dev/null
+++ b/opt-tests.yml
@@ -0,0 +1,19 @@
+#
+# CIP Core, generic profile
+#
+# Copyright (c) Toshiba corp., 2020
+#
+# Authors:
+# Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
+#
+# SPDX-License-Identifier: MIT
+#
+
+header:
+ version: 8
+
+local_conf_header:
+ tests: |
+ IMAGE_INSTALL += "ltp-full"
+ IMAGE_PREINSTALL += "rt-tests stress-ng"
This, in fact, has some benefit over a separate image in that it would also allow to make the security image testable by appending the snippet

+
No extra line at EOF, please.

diff --git a/recipes-core/customizations/customizations.bb b/recipes-core/customizations/customizations.bb
index 38881fb..cbd6daf 100644
--- a/recipes-core/customizations/customizations.bb
+++ b/recipes-core/customizations/customizations.bb
@@ -11,7 +11,7 @@
inherit dpkg-raw
-DESCRIPTION = "CIP Core image demo & test customizations"
+DESCRIPTION = "CIP Core image demo customizations"
Maybe "reference customizations" - typically, you will replace this package for a real product with a, well, product specific customization.

SRC_URI = " \
file://postinst \
@@ -21,8 +21,7 @@ SRC_URI = " \
DEPENDS += "sshd-regen-keys"
DEBIAN_DEPENDS = " \
- ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys, \
- rt-tests, stress-ng"
+ ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys"
do_install() {
install -v -d ${D}/etc/network/interfaces.d
diff --git a/recipes-core/images/cip-core-image.bb b/recipes-core/images/cip-core-image.bb
index 9ee4b25..188c714 100644
--- a/recipes-core/images/cip-core-image.bb
+++ b/recipes-core/images/cip-core-image.bb
@@ -15,5 +15,4 @@ ISAR_RELEASE_CMD = "git -C ${LAYERDIR_cip-core} describe --tags --dirty --always
DESCRIPTION = "CIP Core image"
IMAGE_INSTALL += "customizations"
-# for cip-testing
-IMAGE_INSTALL += "ltp-full"
+
No extra line at EOF, please.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: Kindly review for kernel config changes

Daniel Sangorrin
 

Hi Kent,

Let me check if we can use the cip-kernel-config version on ISAR and remove the one in isar-cip-core.

I will also add nftables as a fragment to isar-cip-core until you tell me that it needs long-term support. If it needs long-term support we will have to move it to cip-kernel-config.

Thanks,
Daniel

________________________________________
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> on behalf of Kento Yoshida <kento.yoshida.wz@renesas.com>
Sent: Tuesday, July 21, 2020 5:40 PM
To: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] Kindly review for kernel config changes

isar-cip-core and deby share cip-kernel-config configuration files.
*isar-cip-core still has the configuration files there but conf/machine files with
USE_CIP_KERNEL_CONFIG = "1" do not use them anymore.
I see. Thank you, Daniel.
But, I'm wondering why conf/machine/qemu-amd64.conf doesn't define USE_CIP_KERNEL_CONFIG = "1".

Do you have any information for this, Dinesh or Venkata?
I think we should reconfirm to add these configs to https://gitlab.com/cip-project/cip-kernel/cip-kernel-config/-/blob/master/4.19.y-cip/x86/cip_qemu_defconfig.
Or, have you already confirmed to build the image using this?

BR, Kent

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of
Daniel Sangorrin via lists.cip-project.org
Sent: Tuesday, July 21, 2020 4:57 PM
To: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] Kindly review for kernel config changes

Hi Kent,

The configuration should go to
https://gitlab.com/cip-project/cip-kernel/cip-kernel-config not isar-cip-core.

isar-cip-core and deby share cip-kernel-config configuration files.
*isar-cip-core still has the configuration files there but conf/machine files with
USE_CIP_KERNEL_CONFIG = "1" do not use them anymore.

Actually that is a nother AI.

Thanks,
Daniel

________________________________________
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> on behalf of
Kento Yoshida <kento.yoshida.wz@renesas.com>
Sent: Tuesday, July 21, 2020 4:12 PM
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] Kindly review for kernel config changes

Hi,

The security working group need to use "nftables", and it requires to add the
below kernel configs to work.
Before merging to the master branch of "isar-cip-core", would you kindly review to
add the below configs by this Friday, everyone?

--- a/recipes-kernel/linux/files/qemu-amd64_defconfig
+++ b/recipes-kernel/linux/files/qemu-amd64_defconfig
@@ -351,3 +351,34 @@ CONFIG_CRYPTO_DEV_CCP=y # CONFIG_XZ_DEC_ARM
is not set # CONFIG_XZ_DEC_ARMTHUMB is not set # CONFIG_XZ_DEC_SPARC is
not set
+CONFIG_NF_TABLES=y
+CONFIG_NF_TABLES_INET=y
+CONFIG_NF_TABLES_NETDEV=y
+CONFIG_NFT_EXTHDR=y
+CONFIG_NFT_META=y
+CONFIG_NFT_CT=y
+CONFIG_NFT_RBTREE=y
+CONFIG_NFT_HASH=y
+CONFIG_NFT_COUNTER=y
+CONFIG_NFT_LOG=y
+CONFIG_NFT_LIMIT=y
+CONFIG_NFT_MASQ=y
+CONFIG_NFT_REDIR=y
+CONFIG_NFT_NAT=y
+CONFIG_NFT_QUEUE=y
+CONFIG_NFT_REJECT=y
+CONFIG_NFT_REJECT_INET=y
+CONFIG_NFT_COMPAT=y
+CONFIG_NFT_CHAIN_ROUTE_IPV4=y
+CONFIG_NFT_REJECT_IPV4=y
+CONFIG_NFT_CHAIN_NAT_IPV4=y
+CONFIG_NFT_MASQ_IPV4=y
+# CONFIG_NFT_REDIR_IPV4 is not set
+CONFIG_NFT_CHAIN_ROUTE_IPV6=y
+CONFIG_NFT_REJECT_IPV6=y
+CONFIG_NFT_CHAIN_NAT_IPV6=y
+CONFIG_NFT_MASQ_IPV6=y
+# CONFIG_NFT_REDIR_IPV6 is not set
+CONFIG_NFT_BRIDGE_META=y
+CONFIG_NFT_BRIDGE_REJECT=y
+CONFIG_NF_LOG_BRIDGE=y

BR, Kent


Fw: [isar-cip-core] tests: put all tests into a opt layer

Daniel Sangorrin
 

Hi Jan,

Sorry, I failed to put you in the Cc when I sent this patch.
There are also 3 patches from Venkata-san on the cip-dev mailing list (sent yesterday)
Apart from that there are some merge requests on gitlab.

Thanks,
Daniel


________________________________________
From: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
Sent: Tuesday, July 21, 2020 7:59 PM
To: sangorrin daniel(サンゴリン ダニエル □SWC◯ACT)
Subject: [isar-cip-core] tests: put all tests into a opt layer

having an opt-tests layer makes it easier to see what
tests are installed, and allows creating images without
them as well

Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
---
.gitlab-ci.yml | 8 ++++----
README.md | 4 ++++
opt-tests.yml | 19 +++++++++++++++++++
recipes-core/customizations/customizations.bb | 5 ++---
recipes-core/images/cip-core-image.bb | 3 +--
5 files changed, 30 insertions(+), 9 deletions(-)
create mode 100644 opt-tests.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 6f1dc91..90eec1f 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -13,17 +13,17 @@ all:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY

- - kas build kas.yml:board-simatic-ipc227e.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-simatic-ipc227e.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster simatic-ipc227e

- sudo rm -rf build/tmp
- - kas build kas.yml:board-bbb.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-bbb.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster bbb am335x-boneblack.dtb

- sudo rm -rf build/tmp
- - kas build kas.yml:board-iwg20m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-iwg20m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster iwg20m r8a7743-iwg20d-q7-dbcm-ca.dtb

- sudo rm -rf build/tmp
- - kas build kas.yml:board-rzg2m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-rzg2m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster hihope-rzg2m renesas/r8a774a1-hihope-rzg2m-ex.dtb
diff --git a/README.md b/README.md
index bbad1a0..7339396 100644
--- a/README.md
+++ b/README.md
@@ -25,6 +25,10 @@ this:

This image can be run using `start-qemu.sh x86`.

+If you want to include the testing layer add ':opt-tests.yml' like this
+
+ ./kas-docker --isar build kas.yml:board-qemu-amd64.yml:opt-tests.yml
+
The BeagleBone Black target is selected by `... kas.yml:board-bbb.yml`. In
order to build the image with the PREEMPT-RT kernel, append `:opt-rt.yml` to
the above. Append ':opt-4.4.yml' to use the kernel version 4.4 instead of 4.19.
diff --git a/opt-tests.yml b/opt-tests.yml
new file mode 100644
index 0000000..a1f431d
--- /dev/null
+++ b/opt-tests.yml
@@ -0,0 +1,19 @@
+#
+# CIP Core, generic profile
+#
+# Copyright (c) Toshiba corp., 2020
+#
+# Authors:
+# Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
+#
+# SPDX-License-Identifier: MIT
+#
+
+header:
+ version: 8
+
+local_conf_header:
+ tests: |
+ IMAGE_INSTALL += "ltp-full"
+ IMAGE_PREINSTALL += "rt-tests stress-ng"
+
diff --git a/recipes-core/customizations/customizations.bb b/recipes-core/customizations/customizations.bb
index 38881fb..cbd6daf 100644
--- a/recipes-core/customizations/customizations.bb
+++ b/recipes-core/customizations/customizations.bb
@@ -11,7 +11,7 @@

inherit dpkg-raw

-DESCRIPTION = "CIP Core image demo & test customizations"
+DESCRIPTION = "CIP Core image demo customizations"

SRC_URI = " \
file://postinst \
@@ -21,8 +21,7 @@ SRC_URI = " \
DEPENDS += "sshd-regen-keys"

DEBIAN_DEPENDS = " \
- ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys, \
- rt-tests, stress-ng"
+ ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys"

do_install() {
install -v -d ${D}/etc/network/interfaces.d
diff --git a/recipes-core/images/cip-core-image.bb b/recipes-core/images/cip-core-image.bb
index 9ee4b25..188c714 100644
--- a/recipes-core/images/cip-core-image.bb
+++ b/recipes-core/images/cip-core-image.bb
@@ -15,5 +15,4 @@ ISAR_RELEASE_CMD = "git -C ${LAYERDIR_cip-core} describe --tags --dirty --always
DESCRIPTION = "CIP Core image"

IMAGE_INSTALL += "customizations"
-# for cip-testing
-IMAGE_INSTALL += "ltp-full"
+
--
2.25.1


Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional support for Renesas platforms

Biju Das <biju.das.jz@...>
 

Hi Pavel,

Thanks for the feedback.

Subject: Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional
support for Renesas platforms

Hi!

On Mon 2020-07-20 18:52:23, Biju Das wrote:
From: Geert Uytterhoeven <geert+renesas@glider.be>

commit bf9e333ec0d54f7428d9192ad403c3cb523584c7 upstream

Increase build and test coverage by enabling support for more
hardware present on Renesas SoCs and boards:
- R-Car CAN and CAN-FD controllers,
Ok, I can apply this if there are no comments.
Both patches seem to be okay to me.
I will push to repository if there is no problem in our test.
I see it is already pushed, thank you!

Biju, the first patch seems like a bugfix suitable for -stable. Can you send it to
Greg (etc) for inclusion?
Yes, Will do.

Regards,
Biju


Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647


Re: [PATCH 4.19.y-cip 2/2] arm64: defconfig: Enable additional support for Renesas platforms

Pavel Machek
 

Hi!

On Mon 2020-07-20 18:52:23, Biju Das wrote:
From: Geert Uytterhoeven <geert+renesas@glider.be>

commit bf9e333ec0d54f7428d9192ad403c3cb523584c7 upstream

Increase build and test coverage by enabling support for more hardware
present on Renesas SoCs and boards:
- R-Car CAN and CAN-FD controllers,
Ok, I can apply this if there are no comments.
Both patches seem to be okay to me.
I will push to repository if there is no problem in our test.
I see it is already pushed, thank you!

Biju, the first patch seems like a bugfix suitable for -stable. Can
you send it to Greg (etc) for inclusion?

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


[isar-cip-core] tests: put all tests into a opt layer

Daniel Sangorrin
 

having an opt-tests layer makes it easier to see what
tests are installed, and allows creating images without
them as well

Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
---
.gitlab-ci.yml | 8 ++++----
README.md | 4 ++++
opt-tests.yml | 19 +++++++++++++++++++
recipes-core/customizations/customizations.bb | 5 ++---
recipes-core/images/cip-core-image.bb | 3 +--
5 files changed, 30 insertions(+), 9 deletions(-)
create mode 100644 opt-tests.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 6f1dc91..90eec1f 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -13,17 +13,17 @@ all:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY

- - kas build kas.yml:board-simatic-ipc227e.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-simatic-ipc227e.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster simatic-ipc227e

- sudo rm -rf build/tmp
- - kas build kas.yml:board-bbb.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-bbb.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster bbb am335x-boneblack.dtb

- sudo rm -rf build/tmp
- - kas build kas.yml:board-iwg20m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-iwg20m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster iwg20m r8a7743-iwg20d-q7-dbcm-ca.dtb

- sudo rm -rf build/tmp
- - kas build kas.yml:board-rzg2m.yml:opt-rt.yml:opt-targz-img.yml
+ - kas build kas.yml:board-rzg2m.yml:opt-tests.yml:opt-rt.yml:opt-targz-img.yml
- scripts/deploy-cip-core.sh buster hihope-rzg2m renesas/r8a774a1-hihope-rzg2m-ex.dtb
diff --git a/README.md b/README.md
index bbad1a0..7339396 100644
--- a/README.md
+++ b/README.md
@@ -25,6 +25,10 @@ this:

This image can be run using `start-qemu.sh x86`.

+If you want to include the testing layer add ':opt-tests.yml' like this
+
+ ./kas-docker --isar build kas.yml:board-qemu-amd64.yml:opt-tests.yml
+
The BeagleBone Black target is selected by `... kas.yml:board-bbb.yml`. In
order to build the image with the PREEMPT-RT kernel, append `:opt-rt.yml` to
the above. Append ':opt-4.4.yml' to use the kernel version 4.4 instead of 4.19.
diff --git a/opt-tests.yml b/opt-tests.yml
new file mode 100644
index 0000000..a1f431d
--- /dev/null
+++ b/opt-tests.yml
@@ -0,0 +1,19 @@
+#
+# CIP Core, generic profile
+#
+# Copyright (c) Toshiba corp., 2020
+#
+# Authors:
+# Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
+#
+# SPDX-License-Identifier: MIT
+#
+
+header:
+ version: 8
+
+local_conf_header:
+ tests: |
+ IMAGE_INSTALL += "ltp-full"
+ IMAGE_PREINSTALL += "rt-tests stress-ng"
+
diff --git a/recipes-core/customizations/customizations.bb b/recipes-core/customizations/customizations.bb
index 38881fb..cbd6daf 100644
--- a/recipes-core/customizations/customizations.bb
+++ b/recipes-core/customizations/customizations.bb
@@ -11,7 +11,7 @@

inherit dpkg-raw

-DESCRIPTION = "CIP Core image demo & test customizations"
+DESCRIPTION = "CIP Core image demo customizations"

SRC_URI = " \
file://postinst \
@@ -21,8 +21,7 @@ SRC_URI = " \
DEPENDS += "sshd-regen-keys"

DEBIAN_DEPENDS = " \
- ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys, \
- rt-tests, stress-ng"
+ ifupdown, isc-dhcp-client, net-tools, iputils-ping, ssh, sshd-regen-keys"

do_install() {
install -v -d ${D}/etc/network/interfaces.d
diff --git a/recipes-core/images/cip-core-image.bb b/recipes-core/images/cip-core-image.bb
index 9ee4b25..188c714 100644
--- a/recipes-core/images/cip-core-image.bb
+++ b/recipes-core/images/cip-core-image.bb
@@ -15,5 +15,4 @@ ISAR_RELEASE_CMD = "git -C ${LAYERDIR_cip-core} describe --tags --dirty --always
DESCRIPTION = "CIP Core image"

IMAGE_INSTALL += "customizations"
-# for cip-testing
-IMAGE_INSTALL += "ltp-full"
+
--
2.25.1


Re: Kindly review for kernel config changes

Kento Yoshida
 

isar-cip-core and deby share cip-kernel-config configuration files.
*isar-cip-core still has the configuration files there but conf/machine files with
USE_CIP_KERNEL_CONFIG = "1" do not use them anymore.
I see. Thank you, Daniel.
But, I'm wondering why conf/machine/qemu-amd64.conf doesn't define USE_CIP_KERNEL_CONFIG = "1".

Do you have any information for this, Dinesh or Venkata?
I think we should reconfirm to add these configs to https://gitlab.com/cip-project/cip-kernel/cip-kernel-config/-/blob/master/4.19.y-cip/x86/cip_qemu_defconfig.
Or, have you already confirmed to build the image using this?

BR, Kent

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of
Daniel Sangorrin via lists.cip-project.org
Sent: Tuesday, July 21, 2020 4:57 PM
To: cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] Kindly review for kernel config changes

Hi Kent,

The configuration should go to
https://gitlab.com/cip-project/cip-kernel/cip-kernel-config not isar-cip-core.

isar-cip-core and deby share cip-kernel-config configuration files.
*isar-cip-core still has the configuration files there but conf/machine files with
USE_CIP_KERNEL_CONFIG = "1" do not use them anymore.

Actually that is a nother AI.

Thanks,
Daniel

________________________________________
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> on behalf of
Kento Yoshida <kento.yoshida.wz@renesas.com>
Sent: Tuesday, July 21, 2020 4:12 PM
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] Kindly review for kernel config changes

Hi,

The security working group need to use "nftables", and it requires to add the
below kernel configs to work.
Before merging to the master branch of "isar-cip-core", would you kindly review to
add the below configs by this Friday, everyone?

--- a/recipes-kernel/linux/files/qemu-amd64_defconfig
+++ b/recipes-kernel/linux/files/qemu-amd64_defconfig
@@ -351,3 +351,34 @@ CONFIG_CRYPTO_DEV_CCP=y # CONFIG_XZ_DEC_ARM
is not set # CONFIG_XZ_DEC_ARMTHUMB is not set # CONFIG_XZ_DEC_SPARC is
not set
+CONFIG_NF_TABLES=y
+CONFIG_NF_TABLES_INET=y
+CONFIG_NF_TABLES_NETDEV=y
+CONFIG_NFT_EXTHDR=y
+CONFIG_NFT_META=y
+CONFIG_NFT_CT=y
+CONFIG_NFT_RBTREE=y
+CONFIG_NFT_HASH=y
+CONFIG_NFT_COUNTER=y
+CONFIG_NFT_LOG=y
+CONFIG_NFT_LIMIT=y
+CONFIG_NFT_MASQ=y
+CONFIG_NFT_REDIR=y
+CONFIG_NFT_NAT=y
+CONFIG_NFT_QUEUE=y
+CONFIG_NFT_REJECT=y
+CONFIG_NFT_REJECT_INET=y
+CONFIG_NFT_COMPAT=y
+CONFIG_NFT_CHAIN_ROUTE_IPV4=y
+CONFIG_NFT_REJECT_IPV4=y
+CONFIG_NFT_CHAIN_NAT_IPV4=y
+CONFIG_NFT_MASQ_IPV4=y
+# CONFIG_NFT_REDIR_IPV4 is not set
+CONFIG_NFT_CHAIN_ROUTE_IPV6=y
+CONFIG_NFT_REJECT_IPV6=y
+CONFIG_NFT_CHAIN_NAT_IPV6=y
+CONFIG_NFT_MASQ_IPV6=y
+# CONFIG_NFT_REDIR_IPV6 is not set
+CONFIG_NFT_BRIDGE_META=y
+CONFIG_NFT_BRIDGE_REJECT=y
+CONFIG_NF_LOG_BRIDGE=y

BR, Kent

1861 - 1880 of 6828