[PATCH v9 0/4] drm/atmel-hlcdc: bus-width override support

[PATCH v9 0/4] drm/atmel-hlcdc: bus-width override support

[Peter Rosin]

Hi!

The background for these patches is that our PCB interface between
the SAMA5D3 and the ds90c185 lvds encoder is only using 16 bits, and
this has to be described somewhere, or the atmel-hlcdc driver have no
chance of selecting the correct output mode. Since we have similar
problems with a tda19988 HDMI encoder I added patches to override
the atmel-hlcdc output format via DT properties compatible with the
media video-interface binding and things start to play together.

Cheers,
Peter

Changes since v8  https://lkml.org/lkml/2018/8/10/309
- go back to the solution in v7 (but the ep device_node leak fixed)
  for patch 4/4
- redo (part of) 3/4 w/o using the disliked of_graph_parse_endpoint

Changes since v7  https://lkml.org/lkml/2018/8/4/288
- The ep device_node was leaked in v7 patch 3/3, so add patch 3/4
  which simplifies fixing this in patch 4/4 (and adds flexibility)
  and adjust patch 4/4 to the changes done in the new 3/4.
- return -ENOMEM on allocation failure in patch 4/4

Changes since v6  https://lkml.org/lkml/2018/8/3/333
- zap bus-type from the binding in patch 2/3

Changes since (the shortened) v5  https://lkml.org/lkml/2018/8/3/182
- add reg properties (and #*-cells) to the example in patch 2/3
- prohibit bus-width 0 in the device-tree in patch 3/3
- added reviewed-by from Jacopo to patch 2/3 and 3/3

Peter Rosin (4):
  dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185
  dt-bindings: display: atmel: optional video-interface of endpoints
  drm/atmel-hlcdc: always iterate over the first 4 output endpoints
  drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes

 .../devicetree/bindings/display/atmel/hlcdc-dc.txt | 23 ++++++
 .../bindings/display/bridge/lvds-transmitter.txt   |  8 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c     | 70 +++++++++++-----
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h       |  1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c   | 92 +++++++++++++++++++---
 5 files changed, 163 insertions(+), 31 deletions(-)

-- 
2.11.0

[PATCH v9 1/4] dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185

[Peter Rosin]

Start list of actual chips compatible with "lvds-encoder".

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
 .../devicetree/bindings/display/bridge/lvds-transmitter.txt       | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
index fd39ad34c383..50220190c203 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -22,7 +22,13 @@ among others.
 
 Required properties:
 
-- compatible: Must be "lvds-encoder"
+- compatible: Must be one or more of the following
+  - "ti,ds90c185" for the TI DS90C185 FPD-Link Serializer
+  - "lvds-encoder" for a generic LVDS encoder device
+
+  When compatible with the generic version, nodes must list the
+  device-specific version corresponding to the device first
+  followed by the generic version.
 
 Required nodes:
 
-- 
2.11.0

[PATCH v9 2/4] dt-bindings: display: atmel: optional video-interface of endpoints

[Peter Rosin]

With bus-type/bus-width properties in the endpoint nodes, the video-
interface of the connection can be specified for cases where the
heuristic fails to select the correct output mode. This can happen
e.g. if not all RGB pins are routed on the PCB; the driver has no
way of knowing this, and needs to be told explicitly.

This is critical for the devices that have the "conflicting output
formats" issue (SAM9N12, SAM9X5, SAMA5D3), since the most significant
RGB bits move around depending on the selected output mode. For
devices that do not have the "conflicting output formats" issue
(SAMA5D2, SAMA5D4), this is completely irrelevant.

Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
 .../devicetree/bindings/display/atmel/hlcdc-dc.txt | 23 ++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
index 82f2acb3d374..0398aec488ac 100644
--- a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
+++ b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
@@ -15,6 +15,13 @@ Required children nodes:
  to external devices using the OF graph reprensentation (see ../graph.txt).
  At least one port node is required.
 
+Optional properties in grandchild nodes:
+ Any endpoint grandchild node may specify a desired video interface
+ according to ../../media/video-interfaces.txt, specifically
+ - bus-width: recognized values are <12>, <16>, <18> and <24>, and
+   override any output mode selection heuristic, forcing "rgb444",
+   "rgb565", "rgb666" and "rgb888" respectively.
+
 Example:
 
 	hlcdc: hlcdc@f0030000 {
@@ -50,3 +57,19 @@ Example:
 			#pwm-cells = <3>;
 		};
 	};
+
+Example 2: With a video interface override to force rgb565; as above
+but with these changes/additions:
+
+	&hlcdc {
+		hlcdc-display-controller {
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb565>;
+
+			port@0 {
+				hlcdc_panel_output: endpoint@0 {
+					bus-width = <16>;
+				};
+			};
+		};
+	};
-- 
2.11.0

[PATCH v9 3/4] drm/atmel-hlcdc: always iterate over the first 4 output endpoints

[Peter Rosin]

This enables more flexible devicetrees. You can e.g. have two output
nodes where one is not enabled, without the ordering affecting things.

Prior to this patch the active nodes had to have endpoint id zero and
upwards consecutively.

Signed-off-by: Peter Rosin <peda@axentia.se>
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 8db51fb131db..c05c2b744981 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -78,12 +78,23 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device *dev, int endpoint)
 int atmel_hlcdc_create_outputs(struct drm_device *dev)
 {
 	int endpoint, ret = 0;
+	int attached = 0;
 
-	for (endpoint = 0; !ret; endpoint++)
+	/*
+	 * Always scan the first few endpoints even if we get -ENODEV,
+	 * but keep going after that as long as we keep getting hits.
+	 */
+	for (endpoint = 0; !ret || endpoint < 4; endpoint++) {
 		ret = atmel_hlcdc_attach_endpoint(dev, endpoint);
+		if (ret == -ENODEV)
+			continue;
+		if (ret)
+			break;
+		attached++;
+	}
 
 	/* At least one device was successfully attached.*/
-	if (ret == -ENODEV && endpoint)
+	if (ret == -ENODEV && attached)
 		return 0;
 
 	return ret;
-- 
2.11.0

[PATCH v9 4/4] drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes

[Peter Rosin]

This beats the heuristic that the connector is involved in what format
should be output for cases where this fails.

E.g. if there is a bridge that changes format between the encoder and the
connector, or if some of the RGB pins between the lcd controller and the
encoder are not routed on the PCB.

This is critical for the devices that have the "conflicting output
formats" issue (SAM9N12, SAM9X5, SAMA5D3), since the most significant
RGB bits move around depending on the selected output mode. For
devices that do not have the "conflicting output formats" issue
(SAMA5D2, SAMA5D4), this is completely irrelevant.

Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 70 +++++++++++++++------
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h     |  1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 77 +++++++++++++++++++++---
 3 files changed, 120 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index d73281095fac..c38a479ada98 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -226,6 +226,55 @@ static void atmel_hlcdc_crtc_atomic_enable(struct drm_crtc *c,
 #define ATMEL_HLCDC_RGB888_OUTPUT	BIT(3)
 #define ATMEL_HLCDC_OUTPUT_MODE_MASK	GENMASK(3, 0)
 
+static int atmel_hlcdc_connector_output_mode(struct drm_connector_state *state)
+{
+	struct drm_connector *connector = state->connector;
+	struct drm_display_info *info = &connector->display_info;
+	struct drm_encoder *encoder;
+	unsigned int supported_fmts = 0;
+	int j;
+
+	encoder = state->best_encoder;
+	if (!encoder)
+		encoder = connector->encoder;
+
+	switch (atmel_hlcdc_encoder_get_bus_fmt(encoder)) {
+	case 0:
+		break;
+	case MEDIA_BUS_FMT_RGB444_1X12:
+		return ATMEL_HLCDC_RGB444_OUTPUT;
+	case MEDIA_BUS_FMT_RGB565_1X16:
+		return ATMEL_HLCDC_RGB565_OUTPUT;
+	case MEDIA_BUS_FMT_RGB666_1X18:
+		return ATMEL_HLCDC_RGB666_OUTPUT;
+	case MEDIA_BUS_FMT_RGB888_1X24:
+		return ATMEL_HLCDC_RGB888_OUTPUT;
+	default:
+		return -EINVAL;
+	}
+
+	for (j = 0; j < info->num_bus_formats; j++) {
+		switch (info->bus_formats[j]) {
+		case MEDIA_BUS_FMT_RGB444_1X12:
+			supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
+			break;
+		case MEDIA_BUS_FMT_RGB565_1X16:
+			supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
+			break;
+		case MEDIA_BUS_FMT_RGB666_1X18:
+			supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
+			break;
+		case MEDIA_BUS_FMT_RGB888_1X24:
+			supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT;
+			break;
+		default:
+			break;
+		}
+	}
+
+	return supported_fmts;
+}
+
 static int atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state)
 {
 	unsigned int output_fmts = ATMEL_HLCDC_OUTPUT_MODE_MASK;
@@ -238,31 +287,12 @@ static int atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state)
 	crtc = drm_crtc_to_atmel_hlcdc_crtc(state->crtc);
 
 	for_each_new_connector_in_state(state->state, connector, cstate, i) {
-		struct drm_display_info *info = &connector->display_info;
 		unsigned int supported_fmts = 0;
-		int j;
 
 		if (!cstate->crtc)
 			continue;
 
-		for (j = 0; j < info->num_bus_formats; j++) {
-			switch (info->bus_formats[j]) {
-			case MEDIA_BUS_FMT_RGB444_1X12:
-				supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
-				break;
-			case MEDIA_BUS_FMT_RGB565_1X16:
-				supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
-				break;
-			case MEDIA_BUS_FMT_RGB666_1X18:
-				supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
-				break;
-			case MEDIA_BUS_FMT_RGB888_1X24:
-				supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT;
-				break;
-			default:
-				break;
-			}
-		}
+		supported_fmts = atmel_hlcdc_connector_output_mode(cstate);
 
 		if (crtc->dc->desc->conflicting_output_formats)
 			output_fmts &= supported_fmts;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index 60c937f42114..4cc1e03f0aee 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -441,5 +441,6 @@ void atmel_hlcdc_crtc_irq(struct drm_crtc *c);
 int atmel_hlcdc_crtc_create(struct drm_device *dev);
 
 int atmel_hlcdc_create_outputs(struct drm_device *dev);
+int atmel_hlcdc_encoder_get_bus_fmt(struct drm_encoder *encoder);
 
 #endif /* DRM_ATMEL_HLCDC_H */
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index c05c2b744981..f73d8a92274e 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -27,33 +27,94 @@
 
 #include "atmel_hlcdc_dc.h"
 
+struct atmel_hlcdc_rgb_output {
+	struct drm_encoder encoder;
+	int bus_fmt;
+};
+
 static const struct drm_encoder_funcs atmel_hlcdc_panel_encoder_funcs = {
 	.destroy = drm_encoder_cleanup,
 };
 
+static struct atmel_hlcdc_rgb_output *
+atmel_hlcdc_encoder_to_rgb_output(struct drm_encoder *encoder)
+{
+	return container_of(encoder, struct atmel_hlcdc_rgb_output, encoder);
+}
+
+int atmel_hlcdc_encoder_get_bus_fmt(struct drm_encoder *encoder)
+{
+	struct atmel_hlcdc_rgb_output *output;
+
+	output = atmel_hlcdc_encoder_to_rgb_output(encoder);
+
+	return output->bus_fmt;
+}
+
+static int atmel_hlcdc_of_bus_fmt(const struct device_node *ep)
+{
+	u32 bus_width;
+	int ret;
+
+	ret = of_property_read_u32(ep, "bus-width", &bus_width);
+	if (ret == -EINVAL)
+		return 0;
+	if (ret)
+		return ret;
+
+	switch (bus_width) {
+	case 12:
+		return MEDIA_BUS_FMT_RGB444_1X12;
+	case 16:
+		return MEDIA_BUS_FMT_RGB565_1X16;
+	case 18:
+		return MEDIA_BUS_FMT_RGB666_1X18;
+	case 24:
+		return MEDIA_BUS_FMT_RGB888_1X24;
+	default:
+		return -EINVAL;
+	}
+}
+
 static int atmel_hlcdc_attach_endpoint(struct drm_device *dev, int endpoint)
 {
-	struct drm_encoder *encoder;
+	struct atmel_hlcdc_rgb_output *output;
+	struct device_node *ep;
 	struct drm_panel *panel;
 	struct drm_bridge *bridge;
 	int ret;
 
+	ep = of_graph_get_endpoint_by_regs(dev->dev->of_node, 0, endpoint);
+	if (!ep)
+		return -ENODEV;
+
 	ret = drm_of_find_panel_or_bridge(dev->dev->of_node, 0, endpoint,
 					  &panel, &bridge);
-	if (ret)
+	if (ret) {
+		of_node_put(ep);
 		return ret;
+	}
 
-	encoder = devm_kzalloc(dev->dev, sizeof(*encoder), GFP_KERNEL);
-	if (!encoder)
+	output = devm_kzalloc(dev->dev, sizeof(*output), GFP_KERNEL);
+	if (!output) {
+		of_node_put(ep);
+		return -ENOMEM;
+	}
+
+	output->bus_fmt = atmel_hlcdc_of_bus_fmt(ep);
+	of_node_put(ep);
+	if (output->bus_fmt < 0) {
+		dev_err(dev->dev, "endpoint %d: invalid bus width\n", endpoint);
 		return -EINVAL;
+	}
 
-	ret = drm_encoder_init(dev, encoder,
+	ret = drm_encoder_init(dev, &output->encoder,
 			       &atmel_hlcdc_panel_encoder_funcs,
 			       DRM_MODE_ENCODER_NONE, NULL);
 	if (ret)
 		return ret;
 
-	encoder->possible_crtcs = 0x1;
+	output->encoder.possible_crtcs = 0x1;
 
 	if (panel) {
 		bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_Unknown);
@@ -62,7 +123,7 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device *dev, int endpoint)
 	}
 
 	if (bridge) {
-		ret = drm_bridge_attach(encoder, bridge, NULL);
+		ret = drm_bridge_attach(&output->encoder, bridge, NULL);
 		if (!ret)
 			return 0;
 
@@ -70,7 +131,7 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device *dev, int endpoint)
 			drm_panel_bridge_remove(bridge);
 	}
 
-	drm_encoder_cleanup(encoder);
+	drm_encoder_cleanup(&output->encoder);
 
 	return ret;
 }
-- 
2.11.0

Re: [PATCH v9 0/4] drm/atmel-hlcdc: bus-width override support

[Boris Brezillon]

On Sat, 25 Aug 2018 10:56:16 +0200
Peter Rosin <peda@axentia.se> wrote:

> Hi!
> 
> The background for these patches is that our PCB interface between
> the SAMA5D3 and the ds90c185 lvds encoder is only using 16 bits, and
> this has to be described somewhere, or the atmel-hlcdc driver have no
> chance of selecting the correct output mode. Since we have similar
> problems with a tda19988 HDMI encoder I added patches to override
> the atmel-hlcdc output format via DT properties compatible with the
> media video-interface binding and things start to play together.

Queued to drm-misc-next.

Thanks,

Boris

> 
> Cheers,
> Peter
> 
> Changes since v8  https://lkml.org/lkml/2018/8/10/309
> - go back to the solution in v7 (but the ep device_node leak fixed)
>   for patch 4/4
> - redo (part of) 3/4 w/o using the disliked of_graph_parse_endpoint
> 
> Changes since v7  https://lkml.org/lkml/2018/8/4/288
> - The ep device_node was leaked in v7 patch 3/3, so add patch 3/4
>   which simplifies fixing this in patch 4/4 (and adds flexibility)
>   and adjust patch 4/4 to the changes done in the new 3/4.
> - return -ENOMEM on allocation failure in patch 4/4
> 
> Changes since v6  https://lkml.org/lkml/2018/8/3/333
> - zap bus-type from the binding in patch 2/3
> 
> Changes since (the shortened) v5  https://lkml.org/lkml/2018/8/3/182
> - add reg properties (and #*-cells) to the example in patch 2/3
> - prohibit bus-width 0 in the device-tree in patch 3/3
> - added reviewed-by from Jacopo to patch 2/3 and 3/3
> 
> Peter Rosin (4):
>   dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185
>   dt-bindings: display: atmel: optional video-interface of endpoints
>   drm/atmel-hlcdc: always iterate over the first 4 output endpoints
>   drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes
> 
>  .../devicetree/bindings/display/atmel/hlcdc-dc.txt | 23 ++++++
>  .../bindings/display/bridge/lvds-transmitter.txt   |  8 +-
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c     | 70 +++++++++++-----
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h       |  1 +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c   | 92 +++++++++++++++++++---
>  5 files changed, 163 insertions(+), 31 deletions(-)
> 

Re: [PATCH v9 0/4] drm/atmel-hlcdc: bus-width override support

[Peter Rosin]

On 2018-08-27 21:24, Boris Brezillon wrote:
> On Sat, 25 Aug 2018 10:56:16 +0200
> Peter Rosin <peda@axentia.se> wrote:
> 
>> Hi!
>>
>> The background for these patches is that our PCB interface between
>> the SAMA5D3 and the ds90c185 lvds encoder is only using 16 bits, and
>> this has to be described somewhere, or the atmel-hlcdc driver have no
>> chance of selecting the correct output mode. Since we have similar
>> problems with a tda19988 HDMI encoder I added patches to override
>> the atmel-hlcdc output format via DT properties compatible with the
>> media video-interface binding and things start to play together.
> 
> Queued to drm-misc-next.

Thanks!

Minute issue, you seem to have some spell-check going on or something,
because the subject of patch 1/4 has been "corrected" from
"...add ti,ds90c185" to "...add ti, ds90c185"

You might want to evaluate if that auto-correction "feature" should be
disabled/tweaked/whatever...

Cheers,
Peter

> Thanks,
> 
> Boris
> 
>>
>> Cheers,
>> Peter
>>
>> Changes since v8  https://lkml.org/lkml/2018/8/10/309
>> - go back to the solution in v7 (but the ep device_node leak fixed)
>>   for patch 4/4
>> - redo (part of) 3/4 w/o using the disliked of_graph_parse_endpoint
>>
>> Changes since v7  https://lkml.org/lkml/2018/8/4/288
>> - The ep device_node was leaked in v7 patch 3/3, so add patch 3/4
>>   which simplifies fixing this in patch 4/4 (and adds flexibility)
>>   and adjust patch 4/4 to the changes done in the new 3/4.
>> - return -ENOMEM on allocation failure in patch 4/4
>>
>> Changes since v6  https://lkml.org/lkml/2018/8/3/333
>> - zap bus-type from the binding in patch 2/3
>>
>> Changes since (the shortened) v5  https://lkml.org/lkml/2018/8/3/182
>> - add reg properties (and #*-cells) to the example in patch 2/3
>> - prohibit bus-width 0 in the device-tree in patch 3/3
>> - added reviewed-by from Jacopo to patch 2/3 and 3/3
>>
>> Peter Rosin (4):
>>   dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185
>>   dt-bindings: display: atmel: optional video-interface of endpoints
>>   drm/atmel-hlcdc: always iterate over the first 4 output endpoints
>>   drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes
>>
>>  .../devicetree/bindings/display/atmel/hlcdc-dc.txt | 23 ++++++
>>  .../bindings/display/bridge/lvds-transmitter.txt   |  8 +-
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c     | 70 +++++++++++-----
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h       |  1 +
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c   | 92 +++++++++++++++++++---
>>  5 files changed, 163 insertions(+), 31 deletions(-)
>>
> 

Re: [PATCH v9 0/4] drm/atmel-hlcdc: bus-width override support

[Boris Brezillon]

On Mon, 27 Aug 2018 22:31:22 +0200
Peter Rosin <peda@axentia.se> wrote:

> On 2018-08-27 21:24, Boris Brezillon wrote:
> > On Sat, 25 Aug 2018 10:56:16 +0200
> > Peter Rosin <peda@axentia.se> wrote:
> >   
> >> Hi!
> >>
> >> The background for these patches is that our PCB interface between
> >> the SAMA5D3 and the ds90c185 lvds encoder is only using 16 bits, and
> >> this has to be described somewhere, or the atmel-hlcdc driver have no
> >> chance of selecting the correct output mode. Since we have similar
> >> problems with a tda19988 HDMI encoder I added patches to override
> >> the atmel-hlcdc output format via DT properties compatible with the
> >> media video-interface binding and things start to play together.  
> > 
> > Queued to drm-misc-next.  
> 
> Thanks!
> 
> Minute issue, you seem to have some spell-check going on or something,
> because the subject of patch 1/4 has been "corrected" from
> "...add ti,ds90c185" to "...add ti, ds90c185"
> 
> You might want to evaluate if that auto-correction "feature" should be
> disabled/tweaked/whatever...

Hm, weird. I just downloaded the mbox from dri-devel's patchwork and
passed it to dim apply. dim tends to do a lot of things behind the
scene, so maybe it's also trying to fix typos :-).

Re: [PATCH v9 0/4] drm/atmel-hlcdc: bus-width override support

[Boris Brezillon]

On Mon, 27 Aug 2018 22:35:05 +0200
Boris Brezillon <boris.brezillon@bootlin.com> wrote:

> On Mon, 27 Aug 2018 22:31:22 +0200
> Peter Rosin <peda@axentia.se> wrote:
> 
> > On 2018-08-27 21:24, Boris Brezillon wrote:  
> > > On Sat, 25 Aug 2018 10:56:16 +0200
> > > Peter Rosin <peda@axentia.se> wrote:
> > >     
> > >> Hi!
> > >>
> > >> The background for these patches is that our PCB interface between
> > >> the SAMA5D3 and the ds90c185 lvds encoder is only using 16 bits, and
> > >> this has to be described somewhere, or the atmel-hlcdc driver have no
> > >> chance of selecting the correct output mode. Since we have similar
> > >> problems with a tda19988 HDMI encoder I added patches to override
> > >> the atmel-hlcdc output format via DT properties compatible with the
> > >> media video-interface binding and things start to play together.    
> > > 
> > > Queued to drm-misc-next.    
> > 
> > Thanks!
> > 
> > Minute issue, you seem to have some spell-check going on or something,
> > because the subject of patch 1/4 has been "corrected" from
> > "...add ti,ds90c185" to "...add ti, ds90c185"
> > 
> > You might want to evaluate if that auto-correction "feature" should be
> > disabled/tweaked/whatever...  
> 
> Hm, weird. I just downloaded the mbox from dri-devel's patchwork and
> passed it to dim apply. dim tends to do a lot of things behind the
> scene, so maybe it's also trying to fix typos :-).

Nope, looks like it was already wrong on patchwork [1], don't know what
happened, because the version I have in my mailbox is correct.

[1]https://patchwork.freedesktop.org/patch/246039/

Re: [PATCH v9 0/4] drm/atmel-hlcdc: bus-width override support

[Peter Rosin]

On 2018-08-27 22:40, Boris Brezillon wrote:
> On Mon, 27 Aug 2018 22:35:05 +0200
> Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> 
>> On Mon, 27 Aug 2018 22:31:22 +0200
>> Peter Rosin <peda@axentia.se> wrote:
>>
>>> On 2018-08-27 21:24, Boris Brezillon wrote:  
>>>> On Sat, 25 Aug 2018 10:56:16 +0200
>>>> Peter Rosin <peda@axentia.se> wrote:
>>>>     
>>>>> Hi!
>>>>>
>>>>> The background for these patches is that our PCB interface between
>>>>> the SAMA5D3 and the ds90c185 lvds encoder is only using 16 bits, and
>>>>> this has to be described somewhere, or the atmel-hlcdc driver have no
>>>>> chance of selecting the correct output mode. Since we have similar
>>>>> problems with a tda19988 HDMI encoder I added patches to override
>>>>> the atmel-hlcdc output format via DT properties compatible with the
>>>>> media video-interface binding and things start to play together.    
>>>>
>>>> Queued to drm-misc-next.    
>>>
>>> Thanks!
>>>
>>> Minute issue, you seem to have some spell-check going on or something,
>>> because the subject of patch 1/4 has been "corrected" from
>>> "...add ti,ds90c185" to "...add ti, ds90c185"
>>>
>>> You might want to evaluate if that auto-correction "feature" should be
>>> disabled/tweaked/whatever...  
>>
>> Hm, weird. I just downloaded the mbox from dri-devel's patchwork and
>> passed it to dim apply. dim tends to do a lot of things behind the
>> scene, so maybe it's also trying to fix typos :-).
> 
> Nope, looks like it was already wrong on patchwork [1], don't know what
> happened, because the version I have in my mailbox is correct.
> 
> [1]https://patchwork.freedesktop.org/patch/246039/

Apparently a known issue: https://github.com/getpatchwork/patchwork/issues/197

Cheers,
Peter