[PATCH] gpu/drm: mediatek: hdmi: check for valid modes on MT8167

[Neil Armstrong]

On MT8167, only CEA modes and anything using a clock below 148500 is
supported for HDMI. This change adds some checks to make sure the
video format is OK for MT8167.

Signed-off-by: Fabien Parent 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 8ee55f9e2954..991e2e935b93 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -148,6 +148,8 @@ struct hdmi_audio_param {
 
 struct mtk_hdmi_conf {
bool tz_disabled;
+   unsigned long max_mode_clock;
+   bool cea_modes_only;
 };
 
 struct mtk_hdmi {
@@ -1259,6 +1261,13 @@ static int mtk_hdmi_conn_mode_valid(struct drm_connector 
*conn,
return MODE_BAD;
}
 
+   if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
+   return MODE_BAD;
+
+   if (hdmi->conf->max_mode_clock &&
+   mode->clock > hdmi->conf->max_mode_clock)
+   return MODE_CLOCK_HIGH;
+
if (mode->clock < 27000)
return MODE_CLOCK_LOW;
if (mode->clock > 297000)
@@ -1810,10 +1819,18 @@ static const struct mtk_hdmi_conf mtk_hdmi_conf_mt2701 
= {
.tz_disabled = true,
 };
 
+static const struct mtk_hdmi_conf mtk_hdmi_conf_mt8167 = {
+   .max_mode_clock = 148500,
+   .cea_modes_only = true,
+};
+
 static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
{ .compatible = "mediatek,mt2701-hdmi",
  .data = &mtk_hdmi_conf_mt2701,
},
+   { .compatible = "mediatek,mt8167-hdmi",
+ .data = &mtk_hdmi_conf_mt8167,
+   },
{ .compatible = "mediatek,mt8173-hdmi",
},
{}
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/18] drm/vc4: hdmi: Add Support for the YUV output

[Neil Armstrong]

On 18/03/2021 19:16, Jernej Škrabec wrote:
> Hi!
> 
> Dne sreda, 17. marec 2021 ob 16:43:34 CET je Maxime Ripard napisal(a):
>> Hi,
>>
>> Here's an attempt at support the HDMI YUV output on the BCM2711 SoC found on
>> the RaspberryPi4.
>>
>> I took the same approach than what dw-hdmi did already, turning a bunch of
>> functions found in that driver into helpers since they were fairly generic.
>>
>> However, it feels a bit clunky overall and there's a few rough edges that
>> should be addressed in a generic manner:
>>
>>   - while the format negociation makes sense for a bridge, it feels a bit
>> over-engineered for a simple encoder where that setting could be a 
> simple
>> switch (and possibly a property?)
> 
> Property could work, but possible values should be then limited to cross 
> section of HW and connected display capabilities.
> 
>>
>>   - more importantly, whether we're choosing an YUV output or not is 
> completely
>> hidden away from the userspace even though it might have some effect on 
> the
>> visual quality output (thinking about YUV420 and YUV422 here mostly).
> 
> IMO driver should select highest achievable quality. So in case of YUV420 and 
> YUV422, later should be selected. This should be the case even if the 
> property 
> is implemented.
> 
> Best regards,
> Jernej
> 
>>
>>   - Similarly, the list we report is static and the userspace cannot change 
> or
>> force one mode over the other. We will always pick YUV444 over RGB444 if
>> both are available for example.
>>
>> While the first one might just be due to a lack of helpers, the second and
>> third ones are also feeling a bit inconsistent with how we're handling the
>> 10/12 bit output for example

Another points for YUV422 and YUV420 are:
- mandatory YUV420 for pre-HDMI2 displays to achieve 4k60 with HDMI1.4 max TDMS
- possibility to achieve factorial frequencies for 10/12bits, it's not the case 
for YUV422, it's the same TMDS character rate for 8, 19, 12 and 16bits
- selecting YUV422 instead of YUV444 for 10/12/16 for 4k60 in HDMI2.0

Today we do not take in account the SCDC feedback from the display, but at some 
point we should
monitor the Scrambling_Status and Character Error Detection to lower down from 
YUV444 to 422 and 420
for example.

Neil

>>
>> Let me know what you think,
>> Maxime
>>
>> Maxime Ripard (18):
>>   drm: Introduce new HDMI helpers
>>   drm/bridge: Add HDMI output fmt helper
>>   drm/bridge: dw-hdmi: Use helpers
>>   drm/vc4: txp: Properly set the possible_crtcs mask
>>   drm/vc4: crtc: Skip the TXP
>>   drm/vc4: Rework the encoder retrieval code
>>   drm/vc4: hdmi: Add full range RGB helper
>>   drm/vc4: hdmi: Use full range helper in csc functions
>>   drm/vc4: hdmi: Remove limited_rgb_range
>>   drm/vc4: hdmi: Convert to bridge
>>   drm/vc4: hdmi: Move XBAR setup to csc_setup
>>   drm/vc4: hdmi: Replace CSC_CTL hardcoded value by defines
>>   drm/vc4: hdmi: Define colorspace matrices
>>   drm/vc4: hdmi: Change CSC callback prototype
>>   drm/vc4: hdmi: Rework the infoframe prototype
>>   drm/vc4: hdmi: Support HDMI YUV output
>>   drm/vc4: hdmi: Move the pixel rate calculation to a helper
>>   drm/vc4: hdmi: Force YUV422 if the rate is too high
>>
>>  drivers/gpu/drm/Makefile  |   2 +-
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 268 ++-
>>  drivers/gpu/drm/drm_bridge.c  | 118 +++
>>  drivers/gpu/drm/drm_hdmi.c| 170 +
>>  drivers/gpu/drm/vc4/vc4_crtc.c|  59 +++-
>>  drivers/gpu/drm/vc4/vc4_drv.c |  41 +++
>>  drivers/gpu/drm/vc4/vc4_drv.h |  26 +-
>>  drivers/gpu/drm/vc4/vc4_hdmi.c| 399 +++---
>>  drivers/gpu/drm/vc4/vc4_hdmi.h|  13 +-
>>  drivers/gpu/drm/vc4/vc4_hdmi_regs.h   |   6 +
>>  drivers/gpu/drm/vc4/vc4_regs.h|  19 ++
>>  drivers/gpu/drm/vc4/vc4_txp.c |   2 +-
>>  include/drm/drm_bridge.h  |   6 +
>>  include/drm/drm_hdmi.h|  24 ++
>>  14 files changed, 770 insertions(+), 383 deletions(-)
>>  create mode 100644 drivers/gpu/drm/drm_hdmi.c
>>  create mode 100644 include/drm/drm_hdmi.h
>>
>> -- 
>> 2.30.2
>>
>>
> 
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu/drm: mediatek: hdmi: check for valid modes on MT8167

[Neil Armstrong]

On 10/04/2021 00:41, Chun-Kuang Hu wrote:
> Hi, Neil:
> 
> Neil Armstrong  於 2021年4月9日 週五 下午4:43寫道：
>>
>> On MT8167, only CEA modes and anything using a clock below 148500 is
>> supported for HDMI. This change adds some checks to make sure the
>> video format is OK for MT8167.
> 
> I think this patch should be separated to 3 patches. check CEA mode,
> check clock, add mt8167 hdmi support.

Ok

> 
>>
>> Signed-off-by: Fabien Parent 
>> Signed-off-by: Neil Armstrong 
>> ---
>>  drivers/gpu/drm/mediatek/mtk_hdmi.c | 17 +
>>  1 file changed, 17 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
>> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
>> index 8ee55f9e2954..991e2e935b93 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
>> @@ -148,6 +148,8 @@ struct hdmi_audio_param {
>>
>>  struct mtk_hdmi_conf {
>> bool tz_disabled;
>> +   unsigned long max_mode_clock;
>> +   bool cea_modes_only;
>>  };
>>
>>  struct mtk_hdmi {
>> @@ -1259,6 +1261,13 @@ static int mtk_hdmi_conn_mode_valid(struct 
>> drm_connector *conn,
>> return MODE_BAD;
>> }
>>
>> +   if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
>> +   return MODE_BAD;
>> +
>> +   if (hdmi->conf->max_mode_clock &&
>> +   mode->clock > hdmi->conf->max_mode_clock)
>> +   return MODE_CLOCK_HIGH;
>> +
>> if (mode->clock < 27000)
>> return MODE_CLOCK_LOW;
>> if (mode->clock > 297000)
>> @@ -1810,10 +1819,18 @@ static const struct mtk_hdmi_conf 
>> mtk_hdmi_conf_mt2701 = {
>> .tz_disabled = true,
>>  };
>>
>> +static const struct mtk_hdmi_conf mtk_hdmi_conf_mt8167 = {
>> +   .max_mode_clock = 148500,
>> +   .cea_modes_only = true,
>> +};
>> +
>>  static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
>> { .compatible = "mediatek,mt2701-hdmi",
>>   .data = &mtk_hdmi_conf_mt2701,
>> },
>> +   { .compatible = "mediatek,mt8167-hdmi",
> 
> "mediatek,mt8167-hdmi" does not exist in binding document, so add this
> to binding document first.
> In addition, could you also transfer mediatek,hdmi.txt to yaml format?

Sure

Thanks,
Neil

> 
> Regards,
> Chun-Kuang.
> 
>> + .data = &mtk_hdmi_conf_mt8167,
>> +   },
>> { .compatible = "mediatek,mt8173-hdmi",
>> },
>> {}
>> --
>> 2.25.1
>>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/5] mediatek: hdmi: add MT8167 configuration

[Neil Armstrong]

The MT8167 SoC have a hard limit on the maximal supported HDMI TMDS clock,
and is not validated and supported for HDMI modes out of HDMI CEA modes.

To achieve this:
- switch the mediatek HDMI bindings to YAML
- add the MT8167 compatible
- add a boolean to discard the non-CEA modes
- add a value to specify mac TMDS supported clock
- add a conf entry for the MT8167 compatible

Neil Armstrong (5):
  dt-bindings: display: mediatek,hdmi: Convert to use graph schema
  dt-bindings: mediatek: add mt8167 to hdmi, hdmi-ddc and cec bindings
  gpu/drm: mediatek: hdmi: add check for CEA modes only
  gpu/drm: mediatek: hdmi: add optional limit on maximal HDMI mode clock
  gpu/drm: mediatek: hdmi: add MT8167 configuration

 .../display/mediatek/mediatek,cec.yaml|  52 +++
 .../display/mediatek/mediatek,hdmi-ddc.yaml   |  58 
 .../display/mediatek/mediatek,hdmi.txt| 136 --
 .../display/mediatek/mediatek,hdmi.yaml   | 132 +
 drivers/gpu/drm/mediatek/mtk_hdmi.c   |  17 +++
 5 files changed, 259 insertions(+), 136 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
 delete mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml

-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 5/5] gpu/drm: mediatek: hdmi: add MT8167 configuration

[Neil Armstrong]

The MT8167 SoC have a hard limit on the maximal supported HDMI TMDS clock,
and is not validated and supported for HDMI modes out of HDMI CEA modes,
so add a configuration entry linked to the MT8167 compatible.

Signed-off-by: Fabien Parent 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index bc50d97f2553..c1651a83700d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1787,10 +1787,18 @@ static const struct mtk_hdmi_conf mtk_hdmi_conf_mt2701 
= {
.tz_disabled = true,
 };
 
+static const struct mtk_hdmi_conf mtk_hdmi_conf_mt8167 = {
+   .max_mode_clock = 148500,
+   .cea_modes_only = true,
+};
+
 static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
{ .compatible = "mediatek,mt2701-hdmi",
  .data = &mtk_hdmi_conf_mt2701,
},
+   { .compatible = "mediatek,mt8167-hdmi",
+ .data = &mtk_hdmi_conf_mt8167,
+   },
{ .compatible = "mediatek,mt8173-hdmi",
},
{}
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/5] dt-bindings: mediatek: add mt8167 to hdmi, hdmi-ddc and cec bindings

[Neil Armstrong]

Add mt8167 SoC compatible to Mediatek hdmi, hdmi-ddc and cec schema bindings.

Signed-off-by: Neil Armstrong 
---
 .../devicetree/bindings/display/mediatek/mediatek,cec.yaml   | 1 +
 .../devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml  | 1 +
 .../devicetree/bindings/display/mediatek/mediatek,hdmi.yaml  | 1 +
 3 files changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
index 408e7dfce409..23e21656ca55 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
@@ -17,6 +17,7 @@ properties:
   compatible:
 enum:
   - mediatek,mt7623-hdmi
+  - mediatek,mt8167-hdmi
   - mediatek,mt8173-hdmi
 
   reg:
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
index c15b3470d652..9d7148b1a7c3 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
@@ -17,6 +17,7 @@ properties:
   compatible:
 enum:
   - mediatek,mt7623-hdmi
+  - mediatek,mt8167-hdmi
   - mediatek,mt8173-hdmi
 
   reg:
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
index 9c125d7c8934..01ab0e8e02bc 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
@@ -19,6 +19,7 @@ properties:
 enum:
   - mediatek,mt2701-hdmi
   - mediatek,mt7623-hdmi
+  - mediatek,mt8167-hdmi
   - mediatek,mt8173-hdmi
 
   reg:
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/5] dt-bindings: display: mediatek, hdmi: Convert to use graph schema

[Neil Armstrong]

Update the mediatek,dpi binding to use the graph schema.

Signed-off-by: Neil Armstrong 
---
 .../display/mediatek/mediatek,cec.yaml|  51 +++
 .../display/mediatek/mediatek,hdmi-ddc.yaml   |  57 
 .../display/mediatek/mediatek,hdmi.txt| 136 --
 .../display/mediatek/mediatek,hdmi.yaml   | 131 +
 4 files changed, 239 insertions(+), 136 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
 delete mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
new file mode 100644
index ..408e7dfce409
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,cec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek HDMI CEC Controller Device Tree Bindings
+
+maintainers:
+  - CK Hu 
+  - Jitao shi 
+
+description: |
+  The HDMI CEC controller handles hotplug detection and CEC communication.
+
+properties:
+  compatible:
+enum:
+  - mediatek,mt7623-hdmi
+  - mediatek,mt8173-hdmi
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+cec: cec@10013000 {
+compatible = "mediatek,mt8173-cec";
+reg = <0x10013000 0xbc>;
+interrupts = ;
+clocks = <&infracfg CLK_INFRA_CEC>;
+};
+
+...
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
new file mode 100644
index ..c15b3470d652
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,hdmi-ddc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek HDMI DDC Device Tree Bindings
+
+maintainers:
+  - CK Hu 
+  - Jitao shi 
+
+description: |
+  The HDMI DDC i2c controller is used to interface with the HDMI DDC pins.
+
+properties:
+  compatible:
+enum:
+  - mediatek,mt7623-hdmi
+  - mediatek,mt8173-hdmi
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+items:
+  - const: ddc-i2c
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+hdmi_ddc0: i2c@11012000 {
+compatible = "mediatek,mt8173-hdmi-ddc";
+reg = <0x11012000 0x1c>;
+interrupts = ;
+clocks = <&pericfg CLK_PERI_I2C5>;
+clock-names = "ddc-i2c";
+};
+
+...
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
deleted file mode 100644
index b284ca51b913..
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
+++ /dev/null
@@ -1,136 +0,0 @@
-Mediatek HDMI Encoder
-=
-
-The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from
-its parallel input.
-
-Required properties:
-- compatible: Should be "mediatek,-hdmi".
-- the supported chips are mt2701, mt7623 and mt8173
-- reg: Physical base address and length of the controller's registers
-- interrupts: The interrupt signal from the function block.
-- clocks: device clocks
-  See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
-- clock-names: must contain "pixel", "pll", "bclk", and "spdif".
-- phys: phandle link to the HDMI PHY node.
-  See Documentation/devicetree/bindings/phy/phy-bindings.txt for details.
-- phy-names: must contain "hdmi"
-- mediatek,syscon-hdmi: phandle link and register offset to the system
-  configuration registers. For mt8173 this must be offset 0x900 into the
-  MMSYS_CONFIG region: <&mmsys 0x900>.
-- ports: A node containing input and output port nodes with endpoint
-  definitions as documented in Documentation/devicetree/bindings/graph.txt.
-- port@0: The input port in the ports node should be connecte

[PATCH v2 3/5] gpu/drm: mediatek: hdmi: add check for CEA modes only

[Neil Armstrong]

Some SoCs like the MT8167 are not validated and supported for HDMI modes
out of HDMI CEA modes, so add a configuration boolean to filter out
non-CEA modes.

Signed-off-by: Fabien Parent 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index dea46d66e712..0539262e69d3 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -148,6 +148,7 @@ struct hdmi_audio_param {
 
 struct mtk_hdmi_conf {
bool tz_disabled;
+   bool cea_modes_only;
 };
 
 struct mtk_hdmi {
@@ -1222,6 +1223,9 @@ static int mtk_hdmi_bridge_mode_valid(struct drm_bridge 
*bridge,
return MODE_BAD;
}
 
+   if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
+   return MODE_BAD;
+
if (mode->clock < 27000)
return MODE_CLOCK_LOW;
if (mode->clock > 297000)
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 4/5] gpu/drm: mediatek: hdmi: add optional limit on maximal HDMI mode clock

[Neil Armstrong]

Some SoCs like the MT8167 have a hard limit on the maximal supported HDMI TMDS
clock, so add a configuration value to filter out those modes.

Signed-off-by: Fabien Parent 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 0539262e69d3..bc50d97f2553 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -149,6 +149,7 @@ struct hdmi_audio_param {
 struct mtk_hdmi_conf {
bool tz_disabled;
bool cea_modes_only;
+   unsigned long max_mode_clock;
 };
 
 struct mtk_hdmi {
@@ -1226,6 +1227,10 @@ static int mtk_hdmi_bridge_mode_valid(struct drm_bridge 
*bridge,
if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
return MODE_BAD;
 
+   if (hdmi->conf->max_mode_clock &&
+   mode->clock > hdmi->conf->max_mode_clock)
+   return MODE_CLOCK_HIGH;
+
if (mode->clock < 27000)
return MODE_CLOCK_LOW;
if (mode->clock > 297000)
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 2/3] drm: bridge: add it66121 driver

[Neil Armstrong]

From: Phong LE 

This commit is a simple driver for bridge HMDI it66121.
The input format is RBG and there is no color conversion.
Audio, HDCP and CEC are not supported yet.

Signed-off-by: Phong LE 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/Kconfig   |8 +
 drivers/gpu/drm/bridge/Makefile  |1 +
 drivers/gpu/drm/bridge/ite-it66121.c | 1081 ++
 3 files changed, 1090 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index e4110d6ca7b3..6915c38fa459 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -74,6 +74,14 @@ config DRM_LONTIUM_LT9611UXC
  HDMI signals
  Please say Y if you have such hardware.
 
+config DRM_ITE_IT66121
+   tristate "ITE IT66121 HDMI bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select REGMAP_I2C
+   help
+ Support for ITE IT66121 HDMI bridge.
+
 config DRM_LVDS_CODEC
tristate "Transparent LVDS encoders and decoders support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 86e7acc76f8d..4f725753117c 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
 obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
 obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
 obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
+obj-$(CONFIG_DRM_ITE_IT66121) += ite-it66121.o
 
 obj-y += analogix/
 obj-y += cadence/
diff --git a/drivers/gpu/drm/bridge/ite-it66121.c 
b/drivers/gpu/drm/bridge/ite-it66121.c
new file mode 100644
index ..73af49b29dfa
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ite-it66121.c
@@ -0,0 +1,1081 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 BayLibre, SAS
+ * Author: Phong LE 
+ * Copyright (C) 2018-2019, Artem Mygaiev
+ * Copyright (C) 2017, Fresco Logic, Incorporated.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IT66121_VENDOR_ID0_REG 0x00
+#define IT66121_VENDOR_ID1_REG 0x01
+#define IT66121_DEVICE_ID0_REG 0x02
+#define IT66121_DEVICE_ID1_REG 0x03
+
+#define IT66121_VENDOR_ID0 0x54
+#define IT66121_VENDOR_ID1 0x49
+#define IT66121_DEVICE_ID0 0x12
+#define IT66121_DEVICE_ID1 0x06
+#define IT66121_REVISION_MASK  GENMASK(7, 4)
+#define IT66121_DEVICE_ID1_MASKGENMASK(3, 0)
+
+#define IT66121_MASTER_SEL_REG 0x10
+#define IT66121_MASTER_SEL_HOSTBIT(0)
+
+#define IT66121_AFE_DRV_REG0x61
+#define IT66121_AFE_DRV_RSTBIT(4)
+#define IT66121_AFE_DRV_PWDBIT(5)
+
+#define IT66121_INPUT_MODE_REG 0x70
+#define IT66121_INPUT_MODE_RGB (0 << 6)
+#define IT66121_INPUT_MODE_YUV422  BIT(6)
+#define IT66121_INPUT_MODE_YUV444  (2 << 6)
+#define IT66121_INPUT_MODE_CCIR656 BIT(4)
+#define IT66121_INPUT_MODE_SYNCEMB BIT(3)
+#define IT66121_INPUT_MODE_DDR BIT(2)
+
+#define IT66121_INPUT_CSC_REG  0x72
+#define IT66121_INPUT_CSC_ENDITHER BIT(7)
+#define IT66121_INPUT_CSC_ENUDFILTER   BIT(6)
+#define IT66121_INPUT_CSC_DNFREE_GOBIT(5)
+#define IT66121_INPUT_CSC_RGB_TO_YUV   0x02
+#define IT66121_INPUT_CSC_YUV_TO_RGB   0x03
+#define IT66121_INPUT_CSC_NO_CONV  0x00
+
+#define IT66121_AFE_XP_REG 0x62
+#define IT66121_AFE_XP_GAINBIT BIT(7)
+#define IT66121_AFE_XP_PWDPLL  BIT(6)
+#define IT66121_AFE_XP_ENI BIT(5)
+#define IT66121_AFE_XP_ENO BIT(4)
+#define IT66121_AFE_XP_RESETB  BIT(3)
+#define IT66121_AFE_XP_PWDIBIT(2)
+
+#define IT66121_AFE_IP_REG 0x64
+#define IT66121_AFE_IP_GAINBIT BIT(7)
+#define IT66121_AFE_IP_PWDPLL  BIT(6)
+#define IT66121_AFE_IP_CKSEL_05(0 << 4)
+#define IT66121_AFE_IP_CKSEL_1 BIT(4)
+#define IT66121_AFE_IP_CKSEL_2 (2 << 4)
+#define IT66121_AFE_IP_CKSEL_2OR4  (3 << 4)
+#define IT66121_AFE_IP_ER0 BIT(3)
+#define IT66121_AFE_IP_RESETB  BIT(2)
+#define IT66121_AFE_IP_ENC BIT(1)
+#define IT66121_AFE_IP_EC1 BIT(0)
+
+#define IT66121_AFE_XP_EC1_REG 0x68
+#define IT66121_AFE_XP_EC1_LOWCLK

[PATCH v3 1/3] dt-bindings: display: bridge: add it66121 bindings

[Neil Armstrong]

From: Phong LE 

Add the ITE bridge HDMI it66121 bindings.

Signed-off-by: Phong LE 
Signed-off-by: Neil Armstrong 
---
 .../bindings/display/bridge/ite,it66121.yaml  | 123 ++
 1 file changed, 123 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml

diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml 
b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
new file mode 100644
index ..61ed6dc7740b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ite,it66121.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ITE it66121 HDMI bridge Device Tree Bindings
+
+maintainers:
+  - Phong LE 
+  - Neil Armstrong 
+
+description: |
+  The IT66121 is a high-performance and low-power single channel HDMI
+  transmitter, fully compliant with HDMI 1.3a, HDCP 1.2 and backward compatible
+  to DVI 1.0 specifications.
+
+properties:
+  compatible:
+const: ite,it66121
+
+  reg:
+maxItems: 1
+description: base I2C address of the device
+
+  reset-gpios:
+maxItems: 1
+description: GPIO connected to active low reset
+
+  vrf12-supply:
+description: Regulator for 1.2V analog core power.
+
+  vcn33-supply:
+description: Regulator for 3.3V digital core power.
+
+  vcn18-supply:
+description: Regulator for 1.8V IO core power.
+
+  interrupts:
+maxItems: 1
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/$defs/port-base
+unevaluatedProperties: false
+description: DPI input port.
+
+properties:
+  endpoint:
+$ref: /schemas/graph.yaml#/$defs/endpoint-base
+unevaluatedProperties: false
+
+properties:
+  bus-width:
+description:
+  Endpoint bus width.
+enum:
+  - 12  # 12 data lines connected and dual-edge mode
+  - 24  # 24 data lines connected and single-edge mode
+default: 24
+
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: HDMI Connector port.
+
+required:
+  - port@0
+  - port@1
+
+required:
+  - compatible
+  - reg
+  - reset-gpios
+  - vrf12-supply
+  - vcn33-supply
+  - vcn18-supply
+  - interrupts
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+i2c {
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  it66121hdmitx: it66121hdmitx@4c {
+compatible = "ite,it66121";
+pinctrl-names = "default";
+pinctrl-0 = <&ite_pins_default>;
+vcn33-supply = <&mt6358_vcn33_wifi_reg>;
+vcn18-supply = <&mt6358_vcn18_reg>;
+vrf12-supply = <&mt6358_vrf12_reg>;
+reset-gpios = <&pio 160 1 /* GPIO_ACTIVE_LOW */>;
+interrupt-parent = <&pio>;
+interrupts = <4 8 /* IRQ_TYPE_LEVEL_LOW */>;
+reg = <0x4c>;
+
+ports {
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  port@0 {
+reg = <0>;
+it66121_in: endpoint {
+  bus-width = <12>;
+  remote-endpoint = <&display_out>;
+};
+  };
+
+  port@1 {
+reg = <1>;
+hdmi_conn_out: endpoint {
+  remote-endpoint = <&hdmi_conn_in>;
+};
+  };
+};
+  };
+};
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 3/3] MAINTAINERS: add it66121 HDMI bridge driver entry

[Neil Armstrong]

From: Phong LE 

Add Neil Armstrong and myself as maintainers

Signed-off-by: Phong LE 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9ae8444c96b4..ff6450c83049 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9515,6 +9515,14 @@ Q:   
http://patchwork.linuxtv.org/project/linux-media/list/
 T: git git://linuxtv.org/anttip/media_tree.git
 F: drivers/media/tuners/it913x*
 
+ITE IT66121 HDMI BRIDGE DRIVER
+M: Phong LE 
+M: Neil Armstrong 
+S: Maintained
+F: drivers/gpu/drm/bridge/ite-it66121.c
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
+
 IVTV VIDEO4LINUX DRIVER
 M: Andy Walls 
 L: linux-me...@vger.kernel.org
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 0/3] drm/bridge: Add it66121 driver

[Neil Armstrong]

The IT66121 is a high-performance and low-power single channel HDMI
transmitter, fully compliant with HDMI 1.3a, HDCP 1.2 and backward
compatible to DVI 1.0 specifications.
It supports pixel rates from 25MHz to 165MHz.

This series contains document bindings, add vendor prefix, Kconfig to
enable or not.
For now, the driver handles only RGB without color conversion.
Audio, CEC and HDCP are not implemented yet.

Changes since v2 at [1]:
- fixed DT bindings by:
  - adding bus-width property to input port
  - correctly defining ports
  - other minor fixes
- fixed bridge driver by:
  - general cleanup following Andy's comments
  - implemented support for NO_CONNECTOR
  - makes basic usage of the bus width property
  - add support for bus format negociation
  - other minor fixes
- fixed order of MAINTAINERS entries

[1] https://lore.kernel.org/r/20200311125135.30832-1-...@baylibre.com

Phong LE (3):
  dt-bindings: display: bridge: add it66121 bindings
  drm: bridge: add it66121 driver
  MAINTAINERS: add it66121 HDMI bridge driver entry

 .../bindings/display/bridge/ite,it66121.yaml  |  123 ++
 MAINTAINERS   |8 +
 drivers/gpu/drm/bridge/Kconfig|8 +
 drivers/gpu/drm/bridge/Makefile   |1 +
 drivers/gpu/drm/bridge/ite-it66121.c  | 1081 +
 5 files changed, 1221 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
 create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c

-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/3] MAINTAINERS: add it66121 HDMI bridge driver entry

[Neil Armstrong]

On 12/04/2021 17:46, Neil Armstrong wrote:
> From: Phong LE 
> 
> Add Neil Armstrong and myself as maintainers
> 
> Signed-off-by: Phong LE 

Obviously:
Signed-off-by: Neil Armstrong 

> ---
>  MAINTAINERS | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9ae8444c96b4..ff6450c83049 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9515,6 +9515,14 @@ Q: 
> http://patchwork.linuxtv.org/project/linux-media/list/
>  T:   git git://linuxtv.org/anttip/media_tree.git
>  F:   drivers/media/tuners/it913x*
>  
> +ITE IT66121 HDMI BRIDGE DRIVER
> +M:   Phong LE 
> +M:   Neil Armstrong 
> +S:   Maintained
> +F:   drivers/gpu/drm/bridge/ite-it66121.c
> +T:   git git://anongit.freedesktop.org/drm/drm-misc
> +F:   Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
> +
>  IVTV VIDEO4LINUX DRIVER
>  M:   Andy Walls 
>  L:   linux-me...@vger.kernel.org
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/5] dt-bindings: display: mediatek,hdmi: Convert to use graph schema

[Neil Armstrong]

On 12/04/2021 11:39, Neil Armstrong wrote:
> Update the mediatek,dpi binding to use the graph schema.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  .../display/mediatek/mediatek,cec.yaml|  51 +++
>  .../display/mediatek/mediatek,hdmi-ddc.yaml   |  57 
>  .../display/mediatek/mediatek,hdmi.txt| 136 --
>  .../display/mediatek/mediatek,hdmi.yaml   | 131 +
>  4 files changed, 239 insertions(+), 136 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
> new file mode 100644
> index ..408e7dfce409
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/mediatek/mediatek,cec.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek HDMI CEC Controller Device Tree Bindings
> +
> +maintainers:
> +  - CK Hu 
> +  - Jitao shi 
> +
> +description: |
> +  The HDMI CEC controller handles hotplug detection and CEC communication.
> +
> +properties:
> +  compatible:
> +enum:
> +  - mediatek,mt7623-hdmi

=> mediatek,mt7623-cec

> +  - mediatek,mt8173-hdmi

=> mediatek,mt8173-cec

> +
> +  reg:
> +maxItems: 1
> +
> +  interrupts:
> +maxItems: 1
> +
> +  clocks:
> +maxItems: 1

[..]

> diff --git 
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
> new file mode 100644
> index ..c15b3470d652
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
> @@ -0,0 +1,57 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/mediatek/mediatek,hdmi-ddc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek HDMI DDC Device Tree Bindings
> +
> +maintainers:
> +  - CK Hu 
> +  - Jitao shi 
> +
> +description: |
> +  The HDMI DDC i2c controller is used to interface with the HDMI DDC pins.
> +
> +properties:
> +  compatible:
> +enum:
> +  - mediatek,mt7623-hdmi

=> mediatek,mt7623-hdmi-ddc

> +  - mediatek,mt8173-hdmi

=> mediatek,mt8173-hdmi-ddc

> +
> +  reg:
> +maxItems: 1


[..]
will repost with these fixes in  a few days,

Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/3] drm: bridge: add it66121 driver

[Neil Armstrong]

Hi Rob,

Le 13/04/2021 à 22:21, Robert Foss a écrit :
> Hey Neil & Phong,
> 
> Thanks for submitting this series!
> 
>> +
>> +static const struct drm_bridge_funcs it66121_bridge_funcs = {
>> +   .attach = it66121_bridge_attach,
>> +   .enable = it66121_bridge_enable,
>> +   .disable = it66121_bridge_disable,
>> +   .mode_set = it66121_bridge_mode_set,
>> +   .mode_valid = it66121_bridge_mode_valid,
>> +   .detect = it66121_bridge_detect,
>> +   .get_edid = it66121_bridge_get_edid,
>> +   .atomic_get_output_bus_fmts = 
>> it66121_bridge_atomic_get_output_bus_fmts,
>> +   .atomic_get_input_bus_fmts = 
>> it66121_bridge_atomic_get_input_bus_fmts,
>> +};
> 
> I would like to see an implementation of HPD, since it is supported by
> the hardware[1] (and required by the documentation). IRQ status bit 0
> seems to be the responsible for notifying us about hot plug detection
> events.

It's implemented in the IRQ handler with the IT66121_INT_STATUS1_HPD_STATUS 
event.

Neil

> 
> [1] https://rockchip.fr/radxa/IT66121_Programming_Guide.v1.05.pdf
> 
> 
> Rob.
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/3] drm: bridge: add it66121 driver

[Neil Armstrong]

Hi,

Le 13/04/2021 à 22:56, Paul Cercueil a écrit :
> Hi Neil,
> 
> I get build failures locally:
> 
> drivers/gpu/drm/bridge/ite-it66121.c: In function ‘it66121_hw_reset’:
> drivers/gpu/drm/bridge/ite-it66121.c:242:2: error: implicit declaration of 
> function ‘gpiod_set_value’ [-Werror=implicit-function-declaration]
> 242 | gpiod_set_value(ctx->gpio_reset, 1);
>     | ^~~
> drivers/gpu/drm/bridge/ite-it66121.c: In function ‘it66121_probe’:
> drivers/gpu/drm/bridge/ite-it66121.c:1016:16: error: implicit declaration of 
> function ‘FIELD_GET’; did you mean ‘FOLL_GET’? 
> [-Werror=implicit-function-declaration]
> 1016 | revision_id = FIELD_GET(IT66121_REVISION_MASK, device_ids[1]);
>     | ^
>     | FOLL_GET
> 
> Nothing difficult to fix, but the includes should be added nonetheless.

Exact, I got the CI build failures, I'll fix these for v4.

Were you able to test on your setup ?
The v2 always forced DDR mode, with this v3, I also switch to normal 24input 
mode, but totally untested.

Thanks,
Neil

> 
> Cheers,
> -Paul
> 
> 
> Le lun. 12 avril 2021 à 17:46, Neil Armstrong  a 
> écrit :
>> From: Phong LE 
>>
>> This commit is a simple driver for bridge HMDI it66121.
>> The input format is RBG and there is no color conversion.
>> Audio, HDCP and CEC are not supported yet.
>>
>> Signed-off-by: Phong LE 
>> Signed-off-by: Neil Armstrong 
>> ---
>>  drivers/gpu/drm/bridge/Kconfig   |    8 +
>>  drivers/gpu/drm/bridge/Makefile  |    1 +
>>  drivers/gpu/drm/bridge/ite-it66121.c | 1081 ++
>>  3 files changed, 1090 insertions(+)
>>  create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index e4110d6ca7b3..6915c38fa459 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -74,6 +74,14 @@ config DRM_LONTIUM_LT9611UXC
>>    HDMI signals
>>    Please say Y if you have such hardware.
>>
>> +config DRM_ITE_IT66121
>> +    tristate "ITE IT66121 HDMI bridge"
>> +    depends on OF
>> +    select DRM_KMS_HELPER
>> +    select REGMAP_I2C
>> +    help
>> +  Support for ITE IT66121 HDMI bridge.
>> +
>>  config DRM_LVDS_CODEC
>>  tristate "Transparent LVDS encoders and decoders support"
>>  depends on OF
>> diff --git a/drivers/gpu/drm/bridge/Makefile 
>> b/drivers/gpu/drm/bridge/Makefile
>> index 86e7acc76f8d..4f725753117c 100644
>> --- a/drivers/gpu/drm/bridge/Makefile
>> +++ b/drivers/gpu/drm/bridge/Makefile
>> @@ -24,6 +24,7 @@ obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
>>  obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
>>  obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
>>  obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
>> +obj-$(CONFIG_DRM_ITE_IT66121) += ite-it66121.o
>>
>>  obj-y += analogix/
>>  obj-y += cadence/
>> diff --git a/drivers/gpu/drm/bridge/ite-it66121.c 
>> b/drivers/gpu/drm/bridge/ite-it66121.c
>> new file mode 100644
>> index ..73af49b29dfa
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/ite-it66121.c
>> @@ -0,0 +1,1081 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) 2020 BayLibre, SAS
>> + * Author: Phong LE 
>> + * Copyright (C) 2018-2019, Artem Mygaiev
>> + * Copyright (C) 2017, Fresco Logic, Incorporated.
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define IT66121_VENDOR_ID0_REG    0x00
>> +#define IT66121_VENDOR_ID1_REG    0x01
>> +#define IT66121_DEVICE_ID0_REG    0x02
>> +#define IT66121_DEVICE_ID1_REG    0x03
>> +
>> +#define IT66121_VENDOR_ID0    0x54
>> +#define IT66121_VENDOR_ID1    0x49
>> +#define IT66121_DEVICE_ID0    0x12
>> +#define IT66121_DEVICE_ID1    0x06
>> +#define IT66121_REVISION_MASK    GENMASK(7, 4)
>> +#define IT66121_DEVICE_ID1_MASK    GENMASK(3, 0)
>> +
>> +#define IT66121_MASTER_SEL_REG    0x10
>> +#define IT66121_MASTER_SEL_HOST    BIT(0)
>> +
>> +#define IT66121_AFE_DRV_REG    0x61
>> +#define IT66121_AFE_DRV_RST    BIT(4)
>> +#defin

Re: [PATCH v3 2/3] drm: bridge: add it66121 driver

[Neil Armstrong]

On 14/04/2021 10:06, Robert Foss wrote:
> On Wed, 14 Apr 2021 at 08:13, Neil Armstrong  wrote:
>>
>> Hi Rob,
>>
>> Le 13/04/2021 à 22:21, Robert Foss a écrit :
>>> Hey Neil & Phong,
>>>
>>> Thanks for submitting this series!
>>>
>>>> +
>>>> +static const struct drm_bridge_funcs it66121_bridge_funcs = {
>>>> +   .attach = it66121_bridge_attach,
>>>> +   .enable = it66121_bridge_enable,
>>>> +   .disable = it66121_bridge_disable,
>>>> +   .mode_set = it66121_bridge_mode_set,
>>>> +   .mode_valid = it66121_bridge_mode_valid,
>>>> +   .detect = it66121_bridge_detect,
>>>> +   .get_edid = it66121_bridge_get_edid,
>>>> +   .atomic_get_output_bus_fmts = 
>>>> it66121_bridge_atomic_get_output_bus_fmts,
>>>> +   .atomic_get_input_bus_fmts = 
>>>> it66121_bridge_atomic_get_input_bus_fmts,
>>>> +};
>>>
>>> I would like to see an implementation of HPD, since it is supported by
>>> the hardware[1] (and required by the documentation). IRQ status bit 0
>>> seems to be the responsible for notifying us about hot plug detection
>>> events.
>>
>> It's implemented in the IRQ handler with the IT66121_INT_STATUS1_HPD_STATUS 
>> event.
>>
> 
> I didn't even get that far :)
> 
> Either way, the HPD support should be exposed in drm_bridge_funcs
> (.hpd_enable, .hpd_disable (and possibly .hpd_notify)) and
> drm_bridge.ops (DRM_BRIDGE_OP_HPD).
> 

Indeed I forgot these calls in the NO_CONNECTOR implementation...

Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/3] dt-bindings: display: bridge: add it66121 bindings

[Neil Armstrong]

On 13/04/2021 18:03, Laurent Pinchart wrote:
> Hi Neil,
> 
> Thank you for the patch.
> 
> On Mon, Apr 12, 2021 at 05:46:46PM +0200, Neil Armstrong wrote:
>> From: Phong LE 
>>
>> Add the ITE bridge HDMI it66121 bindings.
>>
>> Signed-off-by: Phong LE 
>> Signed-off-by: Neil Armstrong 
>> ---
>>  .../bindings/display/bridge/ite,it66121.yaml  | 123 ++
>>  1 file changed, 123 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml 
>> b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
>> new file mode 100644
>> index ..61ed6dc7740b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
>> @@ -0,0 +1,123 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/bridge/ite,it66121.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: ITE it66121 HDMI bridge Device Tree Bindings
>> +
>> +maintainers:
>> +  - Phong LE 
>> +  - Neil Armstrong 
>> +
>> +description: |
>> +  The IT66121 is a high-performance and low-power single channel HDMI
>> +  transmitter, fully compliant with HDMI 1.3a, HDCP 1.2 and backward 
>> compatible
>> +  to DVI 1.0 specifications.
>> +
>> +properties:
>> +  compatible:
>> +const: ite,it66121
>> +
>> +  reg:
>> +maxItems: 1
>> +description: base I2C address of the device
> 
> You can drop the description.

Done

> 
>> +
>> +  reset-gpios:
>> +maxItems: 1
>> +description: GPIO connected to active low reset
>> +
>> +  vrf12-supply:
>> +description: Regulator for 1.2V analog core power.
>> +
>> +  vcn33-supply:
>> +description: Regulator for 3.3V digital core power.
>> +
>> +  vcn18-supply:
>> +description: Regulator for 1.8V IO core power.
>> +
>> +  interrupts:
>> +maxItems: 1
>> +
>> +  ports:
>> +$ref: /schemas/graph.yaml#/properties/ports
>> +
>> +properties:
>> +  port@0:
>> +$ref: /schemas/graph.yaml#/$defs/port-base
>> +unevaluatedProperties: false
>> +description: DPI input port.
>> +
>> +properties:
>> +  endpoint:
>> +$ref: /schemas/graph.yaml#/$defs/endpoint-base
>> +unevaluatedProperties: false
>> +
>> +properties:
>> +  bus-width:
>> +description:
>> +  Endpoint bus width.
>> +enum:
>> +  - 12  # 12 data lines connected and dual-edge mode
>> +  - 24  # 24 data lines connected and single-edge mode
>> +default: 24
>> +
>> +  port@1:
>> +$ref: /schemas/graph.yaml#/properties/port
>> +description: HDMI Connector port.
>> +
>> +required:
>> +  - port@0
>> +  - port@1
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - reset-gpios
>> +  - vrf12-supply
>> +  - vcn33-supply
>> +  - vcn18-supply
>> +  - interrupts
>> +  - ports
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +i2c {
>> +  #address-cells = <1>;
>> +  #size-cells = <0>;
> 
> It's customary to indent DT examples with 4 spaces.

Done

> 
>> +
>> +  it66121hdmitx: it66121hdmitx@4c {
>> +compatible = "ite,it66121";
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&ite_pins_default>;
>> +vcn33-supply = <&mt6358_vcn33_wifi_reg>;
>> +vcn18-supply = <&mt6358_vcn18_reg>;
>> +vrf12-supply = <&mt6358_vrf12_reg>;
>> +reset-gpios = <&pio 160 1 /* GPIO_ACTIVE_LOW */>;
> 
> You can #include the necessary headers at the top of the example, and
> use GPIO_ACTIVE_LOW and IRQ_TYPE_LEVEL_LOW to replace the numerical
> values.

Done

> 
> Reviewed-by: Laurent Pinchart 

Thanks,
Neil

> 
>> +interrupt-parent = <&pio>;
>> +interrupts = <4 8 /* IRQ_TYPE_LEVEL_LOW */>;
>> +reg = <0x4c>;
>> +
>> +ports {
>> +  #address-cells = <1>;
>> +  #size-cells = <0>;
>> +
>> +  port@0 {
>> +reg = <0>;
>> +it66121_in: endpoint {
>> +  bus-width = <12>;
>> +  remote-endpoint = <&display_out>;
>> +};
>> +  };
>> +
>> +  port@1 {
>> +reg = <1>;
>> +hdmi_conn_out: endpoint {
>> +  remote-endpoint = <&hdmi_conn_in>;
>> +};
>> +  };
>> +};
>> +  };
>> +};
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/3] drm: bridge: add it66121 driver

[Neil Armstrong]

On 14/04/2021 10:16, Laurent Pinchart wrote:
> Hi Neil,
> 
> On Wed, Apr 14, 2021 at 10:08:46AM +0200, Neil Armstrong wrote:
>> On 14/04/2021 10:06, Robert Foss wrote:
>>> On Wed, 14 Apr 2021 at 08:13, Neil Armstrong  
>>> wrote:
>>>> Le 13/04/2021 à 22:21, Robert Foss a écrit :
>>>>> Hey Neil & Phong,
>>>>>
>>>>> Thanks for submitting this series!
>>>>>
>>>>>> +
>>>>>> +static const struct drm_bridge_funcs it66121_bridge_funcs = {
>>>>>> +   .attach = it66121_bridge_attach,
>>>>>> +   .enable = it66121_bridge_enable,
>>>>>> +   .disable = it66121_bridge_disable,
>>>>>> +   .mode_set = it66121_bridge_mode_set,
>>>>>> +   .mode_valid = it66121_bridge_mode_valid,
>>>>>> +   .detect = it66121_bridge_detect,
>>>>>> +   .get_edid = it66121_bridge_get_edid,
>>>>>> +   .atomic_get_output_bus_fmts = 
>>>>>> it66121_bridge_atomic_get_output_bus_fmts,
>>>>>> +   .atomic_get_input_bus_fmts = 
>>>>>> it66121_bridge_atomic_get_input_bus_fmts,
>>>>>> +};
>>>>>
>>>>> I would like to see an implementation of HPD, since it is supported by
>>>>> the hardware[1] (and required by the documentation). IRQ status bit 0
>>>>> seems to be the responsible for notifying us about hot plug detection
>>>>> events.
>>>>
>>>> It's implemented in the IRQ handler with the 
>>>> IT66121_INT_STATUS1_HPD_STATUS event.
>>>
>>> I didn't even get that far :)
>>>
>>> Either way, the HPD support should be exposed in drm_bridge_funcs
>>> (.hpd_enable, .hpd_disable (and possibly .hpd_notify)) and
>>> drm_bridge.ops (DRM_BRIDGE_OP_HPD).
>>
>> Indeed I forgot these calls in the NO_CONNECTOR implementation...
> 
> For new bridges, you should no implement connector creation, only the
> DRM_BRIDGE_ATTACH_NO_CONNECTOR case should be supported.
> 

Right, time to make a clean bridge-only implementation then !

Thanks for your feedbacks,

Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/3] drm: bridge: add it66121 driver

[Neil Armstrong]

On 14/04/2021 19:35, Paul Cercueil wrote:
> Hi Neil,
> 
> Le mer. 14 avril 2021 à 8:17, Neil Armstrong  a 
> écrit :
>> Hi,
>>
>> Le 13/04/2021 à 22:56, Paul Cercueil a écrit :
>>>  Hi Neil,
>>>
>>>  I get build failures locally:
>>>
>>>  drivers/gpu/drm/bridge/ite-it66121.c: In function ‘it66121_hw_reset’:
>>>  drivers/gpu/drm/bridge/ite-it66121.c:242:2: error: implicit declaration of 
>>> function ‘gpiod_set_value’ [-Werror=implicit-function-declaration]
>>>  242 | gpiod_set_value(ctx->gpio_reset, 1);
>>>  | ^~~
>>>  drivers/gpu/drm/bridge/ite-it66121.c: In function ‘it66121_probe’:
>>>  drivers/gpu/drm/bridge/ite-it66121.c:1016:16: error: implicit declaration 
>>> of function ‘FIELD_GET’; did you mean ‘FOLL_GET’? 
>>> [-Werror=implicit-function-declaration]
>>>  1016 | revision_id = FIELD_GET(IT66121_REVISION_MASK, device_ids[1]);
>>>  | ^
>>>  | FOLL_GET
>>>
>>>  Nothing difficult to fix, but the includes should be added nonetheless.
>>
>> Exact, I got the CI build failures, I'll fix these for v4.
>>
>> Were you able to test on your setup ?
>> The v2 always forced DDR mode, with this v3, I also switch to normal 24input 
>> mode, but totally untested.
> 
> It triggers a warning:
> 
> [  277.870247] WARNING: CPU: 0 PID: 310 at drivers/gpu/drm/drm_bridge.c:892 
> drm_atomic_bridge_chain_check+0x304/0x324
> [  277.870290] Modules linked in:
> [  277.870306] CPU: 0 PID: 310 Comm: modetest Tainted: G    W    
> 5.12.0-rc7-opendingux-00121-g828a3020b5d3 #371
> [  277.870322] Stack : 83f62580 80163b58  0004  b1f39d7e 
> 83581a9c 80ab42b0
> [  277.870367] 808a 808a 835c82f0 808a0dab 80ab42b0 0001 
> 83581a48 b1f39d7e
> [  277.870412]   807e9030  00b8 835818fc 
>  7875676e
> [  277.870456] 3130302d 80abaa43 80abaa9f 672d3132 808a 8000 
> 0009 037c
> [  277.870500]   82a2d0f8 83043b80  fffc 
> 2098 80ab
> [  277.870544] ...
> [  277.870556] Call Trace:
> [  277.870560] [<80109010>] show_stack+0x40/0x128
> [  277.870588] [<80123350>] __warn+0xe0/0x154
> [  277.870608] [<80123428>] warn_slowpath_fmt+0x64/0xb8
> [  277.870625] [<80504e70>] drm_atomic_bridge_chain_check+0x304/0x324
> [  277.870642] [<804e3244>] drm_atomic_helper_check_modeset+0x9f4/0xc58
> [  277.870667] [<804e4338>] drm_atomic_helper_check+0x20/0xa8
> [  277.870685] [<80503644>] drm_atomic_check_only+0x538/0x98c
> [  277.870700] [<80503ab4>] drm_atomic_commit+0x1c/0x70
> [  277.870716] [<8051c3e4>] drm_mode_atomic_ioctl+0x920/0xb44
> [  277.870736] [<804f033c>] drm_ioctl+0x20c/0x3d8
> [  277.870754] [<80283658>] sys_ioctl+0x358/0x860
> [  277.870772] [<801107ec>] syscall_common+0x34/0x58
> 
> [  277.870795] ---[ end trace e973f3b21c63aa1d ]---

Will fix this,

Neil

> 
> That causes my atomic commit to fail, so I can't test it further.
> 
> Cheers,
> -Paul
> 
>> Thanks,
>> Neil
>>
>>>
>>>  Cheers,
>>>  -Paul
>>>
>>>
>>>  Le lun. 12 avril 2021 à 17:46, Neil Armstrong  a 
>>> écrit :
>>>>  From: Phong LE 
>>>>
>>>>  This commit is a simple driver for bridge HMDI it66121.
>>>>  The input format is RBG and there is no color conversion.
>>>>  Audio, HDCP and CEC are not supported yet.
>>>>
>>>>  Signed-off-by: Phong LE 
>>>>  Signed-off-by: Neil Armstrong 
>>>>  ---
>>>>   drivers/gpu/drm/bridge/Kconfig   |    8 +
>>>>   drivers/gpu/drm/bridge/Makefile  |    1 +
>>>>   drivers/gpu/drm/bridge/ite-it66121.c | 1081 ++
>>>>   3 files changed, 1090 insertions(+)
>>>>   create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c
>>>>
>>>>  diff --git a/drivers/gpu/drm/bridge/Kconfig 
>>>> b/drivers/gpu/drm/bridge/Kconfig
>>>>  index e4110d6ca7b3..6915c38fa459 100644
>>>>  --- a/drivers/gpu/drm/bridge/Kconfig
>>>>  +++ b/drivers/gpu/drm/bridge/Kconfig
>>>>  @@ -74,6 +74,14 @@ config DRM_LONTIUM_LT9611UXC
>>>>     HDMI signals
>>>>     Please say Y if you have such hardware.
>>>>
>>>>  +config DRM_ITE_IT66121
>>>>  +    tristate "ITE IT66121 HDMI bridge"
>>>>  +    depends on OF
>>>> 

[PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver

[Neil Armstrong]

This adds DW-HDMI driver a glue option to disable loading of the CEC sub-driver.

On some SoCs, the CEC functionality is enabled in the IP config bits, but the
CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is set
but the DW-HDMI CEC signal is not connected to a physical pin, leading to some
confusion when the DW-HDMI CEC controller can't communicate on the bus.

Jernej Skrabec (1):
  drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC
driver

Neil Armstrong (1):
  drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver

 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
 drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 +
 include/drm/bridge/dw_hdmi.h  | 2 ++
 3 files changed, 4 insertions(+), 1 deletion(-)

-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC driver

[Neil Armstrong]

From: Jernej Skrabec 

This adds DW-HDMI driver a glue option to disable loading of the CEC sub-driver.

On some SoCs, the CEC functionality is enabled in the IP config bits, but the
CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is set
but the DW-HDMI CEC signal is not connected to a physical pin, leading to some
confusion when the DW-HDMI CEC controller can't communicate on the bus.

Reviewed-by: Neil Armstrong 
Signed-off-by: Jernej Skrabec 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
 include/drm/bridge/dw_hdmi.h  | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index dda4fa9a1a08..ae97513ef886 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3421,7 +3421,7 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device 
*pdev,
hdmi->audio = platform_device_register_full(&pdevinfo);
}
 
-   if (config0 & HDMI_CONFIG0_CEC) {
+   if (!plat_data->disable_cec && (config0 & HDMI_CONFIG0_CEC)) {
cec.hdmi = hdmi;
cec.ops = &dw_hdmi_cec_ops;
cec.irq = irq;
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index ea34ca146b82..6a5716655619 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -153,6 +153,8 @@ struct dw_hdmi_plat_data {
const struct dw_hdmi_phy_config *phy_config;
int (*configure_phy)(struct dw_hdmi *hdmi, void *data,
 unsigned long mpixelclock);
+
+   unsigned int disable_cec : 1;
 };
 
 struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver

[Neil Armstrong]

On the Amlogic SoCs, the DW-HDMI HW support is here but the DW-HDMI CEC signal
is not connected to a physical pin, leading to confusion when the dw-hdmi cec
controller can't communicate on the bus.

Disable it to avoid exposing a non-functinal bus.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index aad75a22dc33..2ed87cfdd735 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -1103,6 +1103,7 @@ static int meson_dw_hdmi_bind(struct device *dev, struct 
device *master,
dw_plat_data->phy_data = meson_dw_hdmi;
dw_plat_data->input_bus_encoding = V4L2_YCBCR_ENC_709;
dw_plat_data->ycbcr_420_allowed = true;
+   dw_plat_data->disable_cec = true;
 
if (dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-gxl-dw-hdmi") ||
dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-gxm-dw-hdmi") ||
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver

[Neil Armstrong]

On 16/04/2021 11:58, Laurent Pinchart wrote:
> Hi Neil,
> 
> On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
>> This adds DW-HDMI driver a glue option to disable loading of the CEC 
>> sub-driver.
>>
>> On some SoCs, the CEC functionality is enabled in the IP config bits, but the
>> CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is 
>> set
>> but the DW-HDMI CEC signal is not connected to a physical pin, leading to 
>> some
>> confusion when the DW-HDMI CEC controller can't communicate on the bus.
> 
> If we can't trust the CEC config bit, would it be better to not use it
> at all, and instead let each platform glue logic tell whether to enable
> CEC or not ?

Actually, the CEC config bit is right, the HW exists and should be functional, 
but
this bit doesn't tell if the CEC signal is connected to something.

This lies in the IP integration, like other bits under the 
"amlogic,meson-*-dw-hdmi"
umbrella.

The first attempt was by Hans using DT, but adding a property in DT for a vendor
specific compatible doesn't make sense. Another idea would be to describe the
CEC signal endpoint like we do for video signal, but I think this is out of 
scope and
this solution is much simpler and straightforward, and it's more an exception 
than
a general use case to solve.

Neil

> 
>> Jernej Skrabec (1):
>>   drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC
>> driver
>>
>> Neil Armstrong (1):
>>   drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver
>>
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
>>  drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 +
>>  include/drm/bridge/dw_hdmi.h  | 2 ++
>>  3 files changed, 4 insertions(+), 1 deletion(-)
>>
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 0/3] drm/bridge: Add it66121 driver

[Neil Armstrong]

The IT66121 is a high-performance and low-power single channel HDMI
transmitter, fully compliant with HDMI 1.3a, HDCP 1.2 and backward
compatible to DVI 1.0 specifications.
It supports pixel rates from 25MHz to 165MHz.

This series contains document bindings, add vendor prefix, Kconfig to
enable or not.
For now, the driver handles only RGB without color conversion.
Audio, CEC and HDCP are not implemented yet.

Changes since v3 at [2]:
- DT
 - removed i2c reg description
 - used 4 spaces indent in example
 - added review tags
- driver
 - added missing includes
 - added missing atomic bridge callbacks
 - dropped connector creation completely, only supports NO_CONNECTOR
 - moved single line helpers to inline
 - some more indentation cleanups
- MAINTAINER
 - fixed order
 - added review tags

Changes since v2 at [1]:
- fixed DT bindings by:
  - adding bus-width property to input port
  - correctly defining ports
  - other minor fixes
- fixed bridge driver by:
  - general cleanup following Andy's comments
  - implemented support for NO_CONNECTOR
  - makes basic usage of the bus width property
  - add support for bus format negociation
  - other minor fixes
- fixed order of MAINTAINERS entries

[1] https://lore.kernel.org/r/20200311125135.30832-1-...@baylibre.com
[2] https://lore.kernel.org/r/20210412154648.3719153-1-narmstr...@baylibre.com

Phong LE (3):
  dt-bindings: display: bridge: add it66121 bindings
  drm: bridge: add it66121 driver
  MAINTAINERS: add it66121 HDMI bridge driver entry

 .../bindings/display/bridge/ite,it66121.yaml  |  124 ++
 MAINTAINERS   |8 +
 drivers/gpu/drm/bridge/Kconfig|8 +
 drivers/gpu/drm/bridge/Makefile   |1 +
 drivers/gpu/drm/bridge/ite-it66121.c  | 1021 +
 5 files changed, 1162 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
 create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c

-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 1/3] dt-bindings: display: bridge: add it66121 bindings

[Neil Armstrong]

From: Phong LE 

Add the ITE bridge HDMI it66121 bindings.

Signed-off-by: Phong LE 
Signed-off-by: Neil Armstrong 
Reviewed-by: Rob Herring 
Reviewed-by: Laurent Pinchart 
---
 .../bindings/display/bridge/ite,it66121.yaml  | 124 ++
 1 file changed, 124 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml

diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml 
b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
new file mode 100644
index ..6ec1d5fbb8bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ite,it66121.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ITE it66121 HDMI bridge Device Tree Bindings
+
+maintainers:
+  - Phong LE 
+  - Neil Armstrong 
+
+description: |
+  The IT66121 is a high-performance and low-power single channel HDMI
+  transmitter, fully compliant with HDMI 1.3a, HDCP 1.2 and backward compatible
+  to DVI 1.0 specifications.
+
+properties:
+  compatible:
+const: ite,it66121
+
+  reg:
+maxItems: 1
+
+  reset-gpios:
+maxItems: 1
+description: GPIO connected to active low reset
+
+  vrf12-supply:
+description: Regulator for 1.2V analog core power.
+
+  vcn33-supply:
+description: Regulator for 3.3V digital core power.
+
+  vcn18-supply:
+description: Regulator for 1.8V IO core power.
+
+  interrupts:
+maxItems: 1
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/$defs/port-base
+unevaluatedProperties: false
+description: DPI input port.
+
+properties:
+  endpoint:
+$ref: /schemas/graph.yaml#/$defs/endpoint-base
+unevaluatedProperties: false
+
+properties:
+  bus-width:
+description:
+  Endpoint bus width.
+enum:
+  - 12  # 12 data lines connected and dual-edge mode
+  - 24  # 24 data lines connected and single-edge mode
+default: 24
+
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: HDMI Connector port.
+
+required:
+  - port@0
+  - port@1
+
+required:
+  - compatible
+  - reg
+  - reset-gpios
+  - vrf12-supply
+  - vcn33-supply
+  - vcn18-supply
+  - interrupts
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+it66121hdmitx: hdmitx@4c {
+compatible = "ite,it66121";
+pinctrl-names = "default";
+pinctrl-0 = <&ite_pins_default>;
+vcn33-supply = <&mt6358_vcn33_wifi_reg>;
+vcn18-supply = <&mt6358_vcn18_reg>;
+vrf12-supply = <&mt6358_vrf12_reg>;
+reset-gpios = <&pio 160 GPIO_ACTIVE_LOW>;
+interrupt-parent = <&pio>;
+interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+reg = <0x4c>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+it66121_in: endpoint {
+bus-width = <12>;
+remote-endpoint = <&display_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+hdmi_conn_out: endpoint {
+remote-endpoint = <&hdmi_conn_in>;
+};
+};
+};
+};
+};
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 2/3] drm: bridge: add it66121 driver

[Neil Armstrong]

From: Phong LE 

This commit is a simple driver for bridge HMDI it66121.
The input format is RBG and there is no color conversion.
Audio, HDCP and CEC are not supported yet.

Signed-off-by: Phong LE 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/Kconfig   |8 +
 drivers/gpu/drm/bridge/Makefile  |1 +
 drivers/gpu/drm/bridge/ite-it66121.c | 1021 ++
 3 files changed, 1030 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index e4110d6ca7b3..6915c38fa459 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -74,6 +74,14 @@ config DRM_LONTIUM_LT9611UXC
  HDMI signals
  Please say Y if you have such hardware.
 
+config DRM_ITE_IT66121
+   tristate "ITE IT66121 HDMI bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select REGMAP_I2C
+   help
+ Support for ITE IT66121 HDMI bridge.
+
 config DRM_LVDS_CODEC
tristate "Transparent LVDS encoders and decoders support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 86e7acc76f8d..4f725753117c 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
 obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
 obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
 obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
+obj-$(CONFIG_DRM_ITE_IT66121) += ite-it66121.o
 
 obj-y += analogix/
 obj-y += cadence/
diff --git a/drivers/gpu/drm/bridge/ite-it66121.c 
b/drivers/gpu/drm/bridge/ite-it66121.c
new file mode 100644
index ..d8a60691fd32
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ite-it66121.c
@@ -0,0 +1,1021 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 BayLibre, SAS
+ * Author: Phong LE 
+ * Copyright (C) 2018-2019, Artem Mygaiev
+ * Copyright (C) 2017, Fresco Logic, Incorporated.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IT66121_VENDOR_ID0_REG 0x00
+#define IT66121_VENDOR_ID1_REG 0x01
+#define IT66121_DEVICE_ID0_REG 0x02
+#define IT66121_DEVICE_ID1_REG 0x03
+
+#define IT66121_VENDOR_ID0 0x54
+#define IT66121_VENDOR_ID1 0x49
+#define IT66121_DEVICE_ID0 0x12
+#define IT66121_DEVICE_ID1 0x06
+#define IT66121_REVISION_MASK  GENMASK(7, 4)
+#define IT66121_DEVICE_ID1_MASKGENMASK(3, 0)
+
+#define IT66121_MASTER_SEL_REG 0x10
+#define IT66121_MASTER_SEL_HOSTBIT(0)
+
+#define IT66121_AFE_DRV_REG0x61
+#define IT66121_AFE_DRV_RSTBIT(4)
+#define IT66121_AFE_DRV_PWDBIT(5)
+
+#define IT66121_INPUT_MODE_REG 0x70
+#define IT66121_INPUT_MODE_RGB (0 << 6)
+#define IT66121_INPUT_MODE_YUV422  BIT(6)
+#define IT66121_INPUT_MODE_YUV444  (2 << 6)
+#define IT66121_INPUT_MODE_CCIR656 BIT(4)
+#define IT66121_INPUT_MODE_SYNCEMB BIT(3)
+#define IT66121_INPUT_MODE_DDR BIT(2)
+
+#define IT66121_INPUT_CSC_REG  0x72
+#define IT66121_INPUT_CSC_ENDITHER BIT(7)
+#define IT66121_INPUT_CSC_ENUDFILTER   BIT(6)
+#define IT66121_INPUT_CSC_DNFREE_GOBIT(5)
+#define IT66121_INPUT_CSC_RGB_TO_YUV   0x02
+#define IT66121_INPUT_CSC_YUV_TO_RGB   0x03
+#define IT66121_INPUT_CSC_NO_CONV  0x00
+
+#define IT66121_AFE_XP_REG 0x62
+#define IT66121_AFE_XP_GAINBIT BIT(7)
+#define IT66121_AFE_XP_PWDPLL  BIT(6)
+#define IT66121_AFE_XP_ENI BIT(5)
+#define IT66121_AFE_XP_ENO BIT(4)
+#define IT66121_AFE_XP_RESETB  BIT(3)
+#define IT66121_AFE_XP_PWDIBIT(2)
+
+#define IT66121_AFE_IP_REG 0x64
+#define IT66121_AFE_IP_GAINBIT BIT(7)
+#define IT66121_AFE_IP_PWDPLL  BIT(6)
+#define IT66121_AFE_IP_CKSEL_05(0 << 4)
+#define IT66121_AFE_IP_CKSEL_1 BIT(4)
+#define IT66121_AFE_IP_CKSEL_2 (2 << 4)
+#define IT66121_AFE_IP_CKSEL_2OR4  (3 << 4)
+#define IT66121_AFE_IP_ER0 BIT(3)
+#define IT66121_AFE_IP_RESETB  BIT(2)
+#define IT66121_AFE_IP_ENC BIT(1)
+#define IT66121_AFE_IP_EC1 BIT(0)
+
+#define IT66121_AFE_XP_EC1_REG 0x68
+#define IT6612

[PATCH v4 3/3] MAINTAINERS: add it66121 HDMI bridge driver entry

[Neil Armstrong]

From: Phong LE 

Add Neil Armstrong and myself as maintainers

Signed-off-by: Phong LE 
Signed-off-by: Neil Armstrong 
Reviewed-by: Robert Foss 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9ae8444c96b4..313b3374a51e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9515,6 +9515,14 @@ Q:   
http://patchwork.linuxtv.org/project/linux-media/list/
 T: git git://linuxtv.org/anttip/media_tree.git
 F: drivers/media/tuners/it913x*
 
+ITE IT66121 HDMI BRIDGE DRIVER
+M: Phong LE 
+M: Neil Armstrong 
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
+F: drivers/gpu/drm/bridge/ite-it66121.c
+
 IVTV VIDEO4LINUX DRIVER
 M: Andy Walls 
 L: linux-me...@vger.kernel.org
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 0/5] mediatek: hdmi: add MT8167 configuration

[Neil Armstrong]

The MT8167 SoC have a hard limit on the maximal supported HDMI TMDS clock,
and is not validated and supported for HDMI modes out of HDMI CEA modes.

To achieve this:
- switch the mediatek HDMI bindings to YAML
- add the MT8167 compatible
- add a boolean to discard the non-CEA modes
- add a value to specify mac TMDS supported clock
- add a conf entry for the MT8167 compatible

Changes since v4:
- fixed bindings

Neil Armstrong (5):
  dt-bindings: display: mediatek,hdmi: Convert to use graph schema
  dt-bindings: mediatek: add mt8167 to hdmi, hdmi-ddc and cec bindings
  gpu/drm: mediatek: hdmi: add check for CEA modes only
  gpu/drm: mediatek: hdmi: add optional limit on maximal HDMI mode clock
  gpu/drm: mediatek: hdmi: add MT8167 configuration

 .../display/mediatek/mediatek,cec.yaml|  52 +++
 .../display/mediatek/mediatek,hdmi-ddc.yaml   |  58 
 .../display/mediatek/mediatek,hdmi.txt| 136 --
 .../display/mediatek/mediatek,hdmi.yaml   | 133 +
 drivers/gpu/drm/mediatek/mtk_hdmi.c   |  17 +++
 5 files changed, 260 insertions(+), 136 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
 delete mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml

-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/5] dt-bindings: display: mediatek, hdmi: Convert to use graph schema

[Neil Armstrong]

Update the mediatek,dpi binding to use the graph schema.

Signed-off-by: Neil Armstrong 
---
 .../display/mediatek/mediatek,cec.yaml|  51 +++
 .../display/mediatek/mediatek,hdmi-ddc.yaml   |  57 
 .../display/mediatek/mediatek,hdmi.txt| 136 --
 .../display/mediatek/mediatek,hdmi.yaml   | 132 +
 4 files changed, 240 insertions(+), 136 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
 delete mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
new file mode 100644
index ..b38d8732d7e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,cec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek HDMI CEC Controller Device Tree Bindings
+
+maintainers:
+  - CK Hu 
+  - Jitao shi 
+
+description: |
+  The HDMI CEC controller handles hotplug detection and CEC communication.
+
+properties:
+  compatible:
+enum:
+  - mediatek,mt7623-cec
+  - mediatek,mt8173-cec
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+cec: cec@10013000 {
+compatible = "mediatek,mt8173-cec";
+reg = <0x10013000 0xbc>;
+interrupts = ;
+clocks = <&infracfg CLK_INFRA_CEC>;
+};
+
+...
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
new file mode 100644
index ..c8ba94d6908b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,hdmi-ddc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek HDMI DDC Device Tree Bindings
+
+maintainers:
+  - CK Hu 
+  - Jitao shi 
+
+description: |
+  The HDMI DDC i2c controller is used to interface with the HDMI DDC pins.
+
+properties:
+  compatible:
+enum:
+  - mediatek,mt7623-hdmi-ddc
+  - mediatek,mt8173-hdmi-ddc
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+items:
+  - const: ddc-i2c
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+hdmi_ddc0: i2c@11012000 {
+compatible = "mediatek,mt8173-hdmi-ddc";
+reg = <0x11012000 0x1c>;
+interrupts = ;
+clocks = <&pericfg CLK_PERI_I2C5>;
+clock-names = "ddc-i2c";
+};
+
+...
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
deleted file mode 100644
index b284ca51b913..
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
+++ /dev/null
@@ -1,136 +0,0 @@
-Mediatek HDMI Encoder
-=
-
-The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from
-its parallel input.
-
-Required properties:
-- compatible: Should be "mediatek,-hdmi".
-- the supported chips are mt2701, mt7623 and mt8173
-- reg: Physical base address and length of the controller's registers
-- interrupts: The interrupt signal from the function block.
-- clocks: device clocks
-  See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
-- clock-names: must contain "pixel", "pll", "bclk", and "spdif".
-- phys: phandle link to the HDMI PHY node.
-  See Documentation/devicetree/bindings/phy/phy-bindings.txt for details.
-- phy-names: must contain "hdmi"
-- mediatek,syscon-hdmi: phandle link and register offset to the system
-  configuration registers. For mt8173 this must be offset 0x900 into the
-  MMSYS_CONFIG region: <&mmsys 0x900>.
-- ports: A node containing input and output port nodes with endpoint
-  definitions as documented in Documentation/devicetree/bindings/graph.txt.
-- port@0: The input port in the ports node should be connecte

[PATCH v3 2/5] dt-bindings: mediatek: add mt8167 to hdmi, hdmi-ddc and cec bindings

[Neil Armstrong]

Add mt8167 SoC compatible to Mediatek hdmi, hdmi-ddc and cec schema bindings.

Signed-off-by: Neil Armstrong 
---
 .../devicetree/bindings/display/mediatek/mediatek,cec.yaml   | 1 +
 .../devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml  | 1 +
 .../devicetree/bindings/display/mediatek/mediatek,hdmi.yaml  | 1 +
 3 files changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
index b38d8732d7e0..66288b9f0aa6 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
@@ -17,6 +17,7 @@ properties:
   compatible:
 enum:
   - mediatek,mt7623-cec
+  - mediatek,mt8167-cec
   - mediatek,mt8173-cec
 
   reg:
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
index c8ba94d6908b..b6fcdfb99ab2 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
@@ -17,6 +17,7 @@ properties:
   compatible:
 enum:
   - mediatek,mt7623-hdmi-ddc
+  - mediatek,mt8167-hdmi-ddc
   - mediatek,mt8173-hdmi-ddc
 
   reg:
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
index 6a144faed682..111967efa999 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
@@ -19,6 +19,7 @@ properties:
 enum:
   - mediatek,mt2701-hdmi
   - mediatek,mt7623-hdmi
+  - mediatek,mt8167-hdmi
   - mediatek,mt8173-hdmi
 
   reg:
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 3/5] gpu/drm: mediatek: hdmi: add check for CEA modes only

[Neil Armstrong]

Some SoCs like the MT8167 are not validated and supported for HDMI modes
out of HDMI CEA modes, so add a configuration boolean to filter out
non-CEA modes.

Signed-off-by: Fabien Parent 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index dea46d66e712..0539262e69d3 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -148,6 +148,7 @@ struct hdmi_audio_param {
 
 struct mtk_hdmi_conf {
bool tz_disabled;
+   bool cea_modes_only;
 };
 
 struct mtk_hdmi {
@@ -1222,6 +1223,9 @@ static int mtk_hdmi_bridge_mode_valid(struct drm_bridge 
*bridge,
return MODE_BAD;
}
 
+   if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
+   return MODE_BAD;
+
if (mode->clock < 27000)
return MODE_CLOCK_LOW;
if (mode->clock > 297000)
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 4/5] gpu/drm: mediatek: hdmi: add optional limit on maximal HDMI mode clock

[Neil Armstrong]

Some SoCs like the MT8167 have a hard limit on the maximal supported HDMI TMDS
clock, so add a configuration value to filter out those modes.

Signed-off-by: Fabien Parent 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 0539262e69d3..bc50d97f2553 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -149,6 +149,7 @@ struct hdmi_audio_param {
 struct mtk_hdmi_conf {
bool tz_disabled;
bool cea_modes_only;
+   unsigned long max_mode_clock;
 };
 
 struct mtk_hdmi {
@@ -1226,6 +1227,10 @@ static int mtk_hdmi_bridge_mode_valid(struct drm_bridge 
*bridge,
if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
return MODE_BAD;
 
+   if (hdmi->conf->max_mode_clock &&
+   mode->clock > hdmi->conf->max_mode_clock)
+   return MODE_CLOCK_HIGH;
+
if (mode->clock < 27000)
return MODE_CLOCK_LOW;
if (mode->clock > 297000)
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 5/5] gpu/drm: mediatek: hdmi: add MT8167 configuration

[Neil Armstrong]

The MT8167 SoC have a hard limit on the maximal supported HDMI TMDS clock,
and is not validated and supported for HDMI modes out of HDMI CEA modes,
so add a configuration entry linked to the MT8167 compatible.

Signed-off-by: Fabien Parent 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index bc50d97f2553..c1651a83700d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1787,10 +1787,18 @@ static const struct mtk_hdmi_conf mtk_hdmi_conf_mt2701 
= {
.tz_disabled = true,
 };
 
+static const struct mtk_hdmi_conf mtk_hdmi_conf_mt8167 = {
+   .max_mode_clock = 148500,
+   .cea_modes_only = true,
+};
+
 static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
{ .compatible = "mediatek,mt2701-hdmi",
  .data = &mtk_hdmi_conf_mt2701,
},
+   { .compatible = "mediatek,mt8167-hdmi",
+ .data = &mtk_hdmi_conf_mt8167,
+   },
{ .compatible = "mediatek,mt8173-hdmi",
},
{}
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver

[Neil Armstrong]

On 20/04/2021 17:13, Hans Verkuil wrote:
> On 16/04/2021 13:38, Neil Armstrong wrote:
>> On 16/04/2021 11:58, Laurent Pinchart wrote:
>>> Hi Neil,
>>>
>>> On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
>>>> This adds DW-HDMI driver a glue option to disable loading of the CEC 
>>>> sub-driver.
>>>>
>>>> On some SoCs, the CEC functionality is enabled in the IP config bits, but 
>>>> the
>>>> CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit 
>>>> is set
>>>> but the DW-HDMI CEC signal is not connected to a physical pin, leading to 
>>>> some
>>>> confusion when the DW-HDMI CEC controller can't communicate on the bus.
>>>
>>> If we can't trust the CEC config bit, would it be better to not use it
>>> at all, and instead let each platform glue logic tell whether to enable
>>> CEC or not ?
>>
>> Actually, the CEC config bit is right, the HW exists and should be 
>> functional, but
>> this bit doesn't tell if the CEC signal is connected to something.
>>
>> This lies in the IP integration, like other bits under the 
>> "amlogic,meson-*-dw-hdmi"
>> umbrella.
>>
>> The first attempt was by Hans using DT, but adding a property in DT for a 
>> vendor
>> specific compatible doesn't make sense. Another idea would be to describe the
>> CEC signal endpoint like we do for video signal, but I think this is out of 
>> scope and
>> this solution is much simpler and straightforward, and it's more an 
>> exception than
>> a general use case to solve.
> 
> While a DT property might not make sense in this particular case, I still
> believe that it is a perfectly valid approach in general: whether or not
> the CEC pin is connected is at the hardware level decision, it is not
> something that software can detect. If the designer of the board didn't
> connect it, then the only place you can define that is in the device tree.

Agreed, we need to define a smart way to declare CEC bus relationship in DT, 
the side
effect would be to handle this particular case.

> 
> Anyway, for meson I am fine with this solution. At least it prevents creating
> a non-functioning cec device. So for this series:
> 
> Acked-by: Hans Verkuil 

Thanks,

Applying this serie to drm-misc-next

Neil

> 
> Regards,
> 
>   Hans
> 
>>
>> Neil
>>
>>>
>>>> Jernej Skrabec (1):
>>>>   drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC
>>>> driver
>>>>
>>>> Neil Armstrong (1):
>>>>   drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver
>>>>
>>>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
>>>>  drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 +
>>>>  include/drm/bridge/dw_hdmi.h  | 2 ++
>>>>  3 files changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/3] drm: bridge: add it66121 driver

[Neil Armstrong]

Hi Paul,

On 19/04/2021 09:12, Neil Armstrong wrote:
> From: Phong LE 
> 
> This commit is a simple driver for bridge HMDI it66121.
> The input format is RBG and there is no color conversion.
> Audio, HDCP and CEC are not supported yet.

Did you manage to get it working on your platform with all the needed bridge 
stuff ?

Neil

> 
> Signed-off-by: Phong LE 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/bridge/Kconfig   |8 +
>  drivers/gpu/drm/bridge/Makefile  |1 +
>  drivers/gpu/drm/bridge/ite-it66121.c | 1021 ++
>  3 files changed, 1030 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index e4110d6ca7b3..6915c38fa459 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -74,6 +74,14 @@ config DRM_LONTIUM_LT9611UXC
> HDMI signals
> Please say Y if you have such hardware.
>  
> +config DRM_ITE_IT66121
> + tristate "ITE IT66121 HDMI bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + help
> +   Support for ITE IT66121 HDMI bridge.
> +
>  config DRM_LVDS_CODEC
>   tristate "Transparent LVDS encoders and decoders support"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 86e7acc76f8d..4f725753117c 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
>  obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
>  obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
>  obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
> +obj-$(CONFIG_DRM_ITE_IT66121) += ite-it66121.o
>  
>  obj-y += analogix/
>  obj-y += cadence/
> diff --git a/drivers/gpu/drm/bridge/ite-it66121.c 
> b/drivers/gpu/drm/bridge/ite-it66121.c
> new file mode 100644
> index ..d8a60691fd32
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ite-it66121.c
> @@ -0,0 +1,1021 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2020 BayLibre, SAS
> + * Author: Phong LE 
> + * Copyright (C) 2018-2019, Artem Mygaiev
> + * Copyright (C) 2017, Fresco Logic, Incorporated.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define IT66121_VENDOR_ID0_REG   0x00
> +#define IT66121_VENDOR_ID1_REG   0x01
> +#define IT66121_DEVICE_ID0_REG   0x02
> +#define IT66121_DEVICE_ID1_REG   0x03
> +
> +#define IT66121_VENDOR_ID0   0x54
> +#define IT66121_VENDOR_ID1   0x49
> +#define IT66121_DEVICE_ID0   0x12
> +#define IT66121_DEVICE_ID1   0x06
> +#define IT66121_REVISION_MASKGENMASK(7, 4)
> +#define IT66121_DEVICE_ID1_MASK  GENMASK(3, 0)
> +
> +#define IT66121_MASTER_SEL_REG   0x10
> +#define IT66121_MASTER_SEL_HOST  BIT(0)
> +
> +#define IT66121_AFE_DRV_REG  0x61
> +#define IT66121_AFE_DRV_RST  BIT(4)
> +#define IT66121_AFE_DRV_PWD  BIT(5)
> +
> +#define IT66121_INPUT_MODE_REG   0x70
> +#define IT66121_INPUT_MODE_RGB   (0 << 6)
> +#define IT66121_INPUT_MODE_YUV422BIT(6)
> +#define IT66121_INPUT_MODE_YUV444(2 << 6)
> +#define IT66121_INPUT_MODE_CCIR656   BIT(4)
> +#define IT66121_INPUT_MODE_SYNCEMB   BIT(3)
> +#define IT66121_INPUT_MODE_DDR   BIT(2)
> +
> +#define IT66121_INPUT_CSC_REG0x72
> +#define IT66121_INPUT_CSC_ENDITHER   BIT(7)
> +#define IT66121_INPUT_CSC_ENUDFILTER BIT(6)
> +#define IT66121_INPUT_CSC_DNFREE_GO  BIT(5)
> +#define IT66121_INPUT_CSC_RGB_TO_YUV 0x02
> +#define IT66121_INPUT_CSC_YUV_TO_RGB 0x03
> +#define IT66121_INPUT_CSC_NO_CONV0x00
> +
> +#define IT66121_AFE_XP_REG   0x62
> +#define IT66121_AFE_XP_GAINBIT   BIT(7)
> +#define IT66121_AFE_XP_PWDPLLBIT(6)
> +#define IT66121_AFE_XP_ENI   BIT(5)
> +#define IT66121_AFE_XP_ENO   BIT(4)
> +#define IT66121_AFE_XP_RESETBBIT(3

Re: [PATCH v4 2/3] drm: bridge: add it66121 driver

[Neil Armstrong]

Hi,

On 21/04/2021 11:58, Paul Cercueil wrote:
> Hi Neil,
> 
> Le mer. 21 avril 2021 à 11:25, Neil Armstrong  a 
> écrit :
>> Hi Paul,
>>
>> On 19/04/2021 09:12, Neil Armstrong wrote:
>>>  From: Phong LE 
>>>
>>>  This commit is a simple driver for bridge HMDI it66121.
>>>  The input format is RBG and there is no color conversion.
>>>  Audio, HDCP and CEC are not supported yet.
>>
>> Did you manage to get it working on your platform with all the needed bridge 
>> stuff ?
>>
>> Neil
> 
> I think I will need a bit more time to update ingenic-drm to use the bridge 
> stuff. That's quite a big change.
> 
> So don't wait for me.

Sure, we have time for fixes until it goes into the next release anyway.

Neil

> 
> Cheers,
> -Paul
> 
>>>
>>>  Signed-off-by: Phong LE 
>>>  Signed-off-by: Neil Armstrong 
>>>  ---
>>>   drivers/gpu/drm/bridge/Kconfig   |    8 +
>>>   drivers/gpu/drm/bridge/Makefile  |    1 +
>>>   drivers/gpu/drm/bridge/ite-it66121.c | 1021 ++
>>>   3 files changed, 1030 insertions(+)
>>>   create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c
>>>
>>>  diff --git a/drivers/gpu/drm/bridge/Kconfig 
>>> b/drivers/gpu/drm/bridge/Kconfig
>>>  index e4110d6ca7b3..6915c38fa459 100644
>>>  --- a/drivers/gpu/drm/bridge/Kconfig
>>>  +++ b/drivers/gpu/drm/bridge/Kconfig
>>>  @@ -74,6 +74,14 @@ config DRM_LONTIUM_LT9611UXC
>>>     HDMI signals
>>>     Please say Y if you have such hardware.
>>>
>>>  +config DRM_ITE_IT66121
>>>  +    tristate "ITE IT66121 HDMI bridge"
>>>  +    depends on OF
>>>  +    select DRM_KMS_HELPER
>>>  +    select REGMAP_I2C
>>>  +    help
>>>  +  Support for ITE IT66121 HDMI bridge.
>>>  +
>>>   config DRM_LVDS_CODEC
>>>   tristate "Transparent LVDS encoders and decoders support"
>>>   depends on OF
>>>  diff --git a/drivers/gpu/drm/bridge/Makefile 
>>> b/drivers/gpu/drm/bridge/Makefile
>>>  index 86e7acc76f8d..4f725753117c 100644
>>>  --- a/drivers/gpu/drm/bridge/Makefile
>>>  +++ b/drivers/gpu/drm/bridge/Makefile
>>>  @@ -24,6 +24,7 @@ obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
>>>   obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
>>>   obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
>>>   obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
>>>  +obj-$(CONFIG_DRM_ITE_IT66121) += ite-it66121.o
>>>
>>>   obj-y += analogix/
>>>   obj-y += cadence/
>>>  diff --git a/drivers/gpu/drm/bridge/ite-it66121.c 
>>> b/drivers/gpu/drm/bridge/ite-it66121.c
>>>  new file mode 100644
>>>  index ..d8a60691fd32
>>>  --- /dev/null
>>>  +++ b/drivers/gpu/drm/bridge/ite-it66121.c
>>>  @@ -0,0 +1,1021 @@
>>>  +// SPDX-License-Identifier: GPL-2.0-only
>>>  +/*
>>>  + * Copyright (C) 2020 BayLibre, SAS
>>>  + * Author: Phong LE 
>>>  + * Copyright (C) 2018-2019, Artem Mygaiev
>>>  + * Copyright (C) 2017, Fresco Logic, Incorporated.
>>>  + *
>>>  + */
>>>  +
>>>  +#include 
>>>  +#include 
>>>  +#include 
>>>  +#include 
>>>  +#include 
>>>  +#include 
>>>  +#include 
>>>  +#include 
>>>  +#include 
>>>  +#include 
>>>  +#include 
>>>  +
>>>  +#include 
>>>  +#include 
>>>  +#include 
>>>  +#include 
>>>  +#include 
>>>  +#include 
>>>  +#include 
>>>  +
>>>  +#define IT66121_VENDOR_ID0_REG    0x00
>>>  +#define IT66121_VENDOR_ID1_REG    0x01
>>>  +#define IT66121_DEVICE_ID0_REG    0x02
>>>  +#define IT66121_DEVICE_ID1_REG    0x03
>>>  +
>>>  +#define IT66121_VENDOR_ID0    0x54
>>>  +#define IT66121_VENDOR_ID1    0x49
>>>  +#define IT66121_DEVICE_ID0    0x12
>>>  +#define IT66121_DEVICE_ID1    0x06
>>>  +#define IT66121_REVISION_MASK    GENMASK(7, 4)
>>>  +#define IT66121_DEVICE_ID1_MASK    GENMASK(3, 0)
>>>  +
>>>  +#define IT66121_MASTER_SEL_REG    0x10
>>>  +#define IT66121_MASTER_SEL_HOST    BIT(0)
>>>  +
>>>  +#define IT66121_AFE_DRV_REG    0x61
>>>  +#define IT66121_AFE_DRV_RST    BIT(4)
>>>  +#define IT66121_AFE_D

Re: [PATCH v4 0/3] drm/bridge: Add it66121 driver

[Neil Armstrong]

On 19/04/2021 09:12, Neil Armstrong wrote:
> The IT66121 is a high-performance and low-power single channel HDMI
> transmitter, fully compliant with HDMI 1.3a, HDCP 1.2 and backward
> compatible to DVI 1.0 specifications.
> It supports pixel rates from 25MHz to 165MHz.
> 
> This series contains document bindings, add vendor prefix, Kconfig to
> enable or not.
> For now, the driver handles only RGB without color conversion.
> Audio, CEC and HDCP are not implemented yet.
> 
> Changes since v3 at [2]:
> - DT
>  - removed i2c reg description
>  - used 4 spaces indent in example
>  - added review tags
> - driver
>  - added missing includes
>  - added missing atomic bridge callbacks
>  - dropped connector creation completely, only supports NO_CONNECTOR
>  - moved single line helpers to inline
>  - some more indentation cleanups
> - MAINTAINER
>  - fixed order
>  - added review tags
> 
> Changes since v2 at [1]:
> - fixed DT bindings by:
>   - adding bus-width property to input port
>   - correctly defining ports
>   - other minor fixes
> - fixed bridge driver by:
>   - general cleanup following Andy's comments
>   - implemented support for NO_CONNECTOR
>   - makes basic usage of the bus width property
>   - add support for bus format negociation
>   - other minor fixes
> - fixed order of MAINTAINERS entries
> 
> [1] https://lore.kernel.org/r/20200311125135.30832-1-...@baylibre.com
> [2] https://lore.kernel.org/r/20210412154648.3719153-1-narmstr...@baylibre.com
> 
> Phong LE (3):
>   dt-bindings: display: bridge: add it66121 bindings
>   drm: bridge: add it66121 driver
>   MAINTAINERS: add it66121 HDMI bridge driver entry
> 
>  .../bindings/display/bridge/ite,it66121.yaml  |  124 ++
>  MAINTAINERS   |8 +
>  drivers/gpu/drm/bridge/Kconfig|8 +
>  drivers/gpu/drm/bridge/Makefile   |1 +
>  drivers/gpu/drm/bridge/ite-it66121.c  | 1021 +
>  5 files changed, 1162 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
>  create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c
> 

Applied to drm-misc-next !
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 bindings

[Neil Armstrong]

On 22/04/2021 00:31, Marek Vasut wrote:
> Add DT binding document for TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge.
> 
> Signed-off-by: Marek Vasut 
> Cc: Douglas Anderson 
> Cc: Jagan Teki 
> Cc: Laurent Pinchart 
> Cc: Linus Walleij 
> Cc: Rob Herring 
> Cc: Sam Ravnborg 
> Cc: Stephen Boyd 
> Cc: devicet...@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
> ---
> V2: Add compatible string for SN65DSI84, since this is now tested on it
> ---
>  .../bindings/display/bridge/ti,sn65dsi83.yaml | 134 ++
>  1 file changed, 134 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml 
> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> new file mode 100644
> index ..42d11b46a1eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> @@ -0,0 +1,134 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi83.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: SN65DSI83 and SN65DSI84 DSI to LVDS bridge chip
> +
> +maintainers:
> +  - Marek Vasut 
> +
> +description: |
> +  Texas Instruments SN65DSI83 1x Single-link MIPI DSI
> +  to 1x Single-link LVDS
> +  https://www.ti.com/lit/gpn/sn65dsi83
> +  Texas Instruments SN65DSI84 1x Single-link MIPI DSI
> +  to 1x Dual-link or 2x Single-link LVDS
> +  https://www.ti.com/lit/gpn/sn65dsi84
> +
> +properties:
> +  compatible:
> +oneOf:
> +  - const: ti,sn65dsi83
> +  - const: ti,sn65dsi84
> +
> +  reg:
> +const: 0x2d
> +
> +  enable-gpios:
> +maxItems: 1
> +description: GPIO specifier for bridge_en pin (active high).
> +
> +  ports:
> +type: object
> +additionalProperties: false
> +
> +properties:
> +  "#address-cells":
> +const: 1
> +
> +  "#size-cells":
> +const: 0
> +
> +  port@0:
> +type: object
> +additionalProperties: false
> +
> +description:
> +  Video port for MIPI DSI input
> +
> +properties:
> +  reg:
> +const: 0
> +
> +  endpoint:
> +type: object
> +additionalProperties: false
> +properties:
> +  remote-endpoint: true
> +  data-lanes:
> +description: array of physical DSI data lane indexes.
> +
> +required:
> +  - reg
> +
> +  port@1:
> +type: object
> +additionalProperties: false
> +
> +description:
> +  Video port for LVDS output (panel or bridge).
> +
> +properties:
> +  reg:
> +const: 1
> +
> +  endpoint:
> +type: object
> +additionalProperties: false
> +properties:
> +  remote-endpoint: true

Similar to Jagan's serie, would be great to add bindings for the dual-link LVDS 
even if not supported
by the driver (the driver can fails with a verbose error).

Neil

> +
> +required:
> +  - reg
> +
> +required:
> +  - "#address-cells"
> +  - "#size-cells"
> +  - port@0
> +  - port@1
> +
> +required:
> +  - compatible
> +  - reg
> +  - enable-gpios
> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +
> +i2c {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  bridge@2d {
> +compatible = "ti,sn65dsi83";
> +reg = <0x2d>;
> +
> +enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
> +
> +ports {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  port@0 {
> +reg = <0>;
> +endpoint {
> +  remote-endpoint = <&dsi0_out>;
> +  data-lanes = <1 2 3 4>;
> +};
> +  };
> +
> +  port@1 {
> +reg = <1>;
> +endpoint {
> +  remote-endpoint = <&panel_in_lvds>;
> +};
> +  };
> +};
> +  };
> +};
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/bridge: nwl-dsi: Get MIPI DSI controller and PHY ready in ->mode_set()

[Neil Armstrong]

Hi,

On 22/04/2021 07:14, Liu Ying wrote:
> Some MIPI DSI panel drivers like 'raydium,rm68200' send
> MIPI_DCS_SET_DISPLAY_ON commands in panel_funcs->prepare(), which
> requires the MIPI DSI controller and PHY to be ready beforehand.
> Without this patch, the nwl-dsi driver gets the MIPI DSI controller
> and PHY ready in bridge_funcs->pre_enable(), which happens after
> the panel_funcs->prepare(). So, this patch shifts the bridge operation
> ealier from bridge_funcs->pre_enable() to bridge_funcs->mode_set().

This makes sense, this is how we do on the synopsys dw mipi dsi driver.

> This way, more MIPI DSI panels can connect to this nwl-dsi bridge.
> Care is taken to make sure bridge_funcs->mode_set()/atomic_disable()
> are called in pairs, which includes removing a check on unchanged HS
> clock rate and forcing a full modeset when only connector's DPMS is
> brought out of "Off" status.

I would split the changes in multiple patches to clarify the changes.

Neil

> 
> Cc: Andrzej Hajda 
> Cc: Neil Armstrong 
> Cc: Robert Foss 
> Cc: Laurent Pinchart 
> Cc: Jonas Karlman 
> Cc: Jernej Skrabec 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Guido Günther 
> Cc: Robert Chiras 
> Cc: NXP Linux Team 
> Signed-off-by: Liu Ying 
> ---
> v1->v2:
> * Fix commit message typo - s/unchange/unchanged/
> 
>  drivers/gpu/drm/bridge/nwl-dsi.c | 86 
> +---
>  1 file changed, 46 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c 
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index be6bfc5..229f0b1 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -661,7 +662,7 @@ static irqreturn_t nwl_dsi_irq_handler(int irq, void 
> *data)
>   return IRQ_HANDLED;
>  }
>  
> -static int nwl_dsi_enable(struct nwl_dsi *dsi)
> +static int nwl_dsi_mode_set(struct nwl_dsi *dsi)
>  {
>   struct device *dev = dsi->dev;
>   union phy_configure_opts *phy_cfg = &dsi->phy_cfg;
> @@ -748,7 +749,9 @@ static int nwl_dsi_disable(struct nwl_dsi *dsi)
>   return 0;
>  }
>  
> -static void nwl_dsi_bridge_disable(struct drm_bridge *bridge)
> +static void
> +nwl_dsi_bridge_atomic_disable(struct drm_bridge *bridge,
> +   struct drm_bridge_state *old_bridge_state)
>  {
>   struct nwl_dsi *dsi = bridge_to_dsi(bridge);
>   int ret;
> @@ -809,17 +812,6 @@ static int nwl_dsi_get_dphy_params(struct nwl_dsi *dsi,
>   return 0;
>  }
>  
> -static bool nwl_dsi_bridge_mode_fixup(struct drm_bridge *bridge,
> -   const struct drm_display_mode *mode,
> -   struct drm_display_mode *adjusted_mode)
> -{
> - /* At least LCDIF + NWL needs active high sync */
> - adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
> - adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
> -
> - return true;
> -}
> -
>  static enum drm_mode_status
>  nwl_dsi_bridge_mode_valid(struct drm_bridge *bridge,
> const struct drm_display_info *info,
> @@ -837,6 +829,29 @@ nwl_dsi_bridge_mode_valid(struct drm_bridge *bridge,
>   return MODE_OK;
>  }
>  
> +static int nwl_dsi_bridge_atomic_check(struct drm_bridge *bridge,
> +struct drm_bridge_state *bridge_state,
> +struct drm_crtc_state *crtc_state,
> +struct drm_connector_state *conn_state)
> +{
> + struct drm_display_mode *adjusted_mode = &crtc_state->adjusted_mode;
> +
> + /* At least LCDIF + NWL needs active high sync */
> + adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
> + adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
> +
> + /*
> +  * Do a full modeset if crtc_state->active is changed to be true.
> +  * This ensures our ->mode_set() is called to get the DSI controller
> +  * and the PHY ready to send DCS commands, when only the connector's
> +  * DPMS is brought out of "Off" status.
> +  */
> + if (crtc_state->active_changed && crtc_state->active)
> + crtc_state->mode_changed = true;
> +
> + return 0;
> +}
> +
>  static void
>  nwl_dsi_bridge_mode_set(struct drm_bridge *bridge,
>   const struct drm_display_mode *mode,
> @@ -852,13 +867,6 @@ nwl_dsi_bridge_mo

Re: [PATCH v2] drm/bridge: nwl-dsi: Get MIPI DSI controller and PHY ready in ->mode_set()

[Neil Armstrong]

Hi,

On 22/04/2021 11:31, Liu Ying wrote:
> Hi Neil,
> 
> On Thu, 2021-04-22 at 10:48 +0200, Neil Armstrong wrote:
>> Hi,
>>
>> On 22/04/2021 07:14, Liu Ying wrote:
>>> Some MIPI DSI panel drivers like 'raydium,rm68200' send
>>> MIPI_DCS_SET_DISPLAY_ON commands in panel_funcs->prepare(), which
>>> requires the MIPI DSI controller and PHY to be ready beforehand.
>>> Without this patch, the nwl-dsi driver gets the MIPI DSI controller
>>> and PHY ready in bridge_funcs->pre_enable(), which happens after
>>> the panel_funcs->prepare(). So, this patch shifts the bridge operation
>>> ealier from bridge_funcs->pre_enable() to bridge_funcs->mode_set().
>>
>> This makes sense, this is how we do on the synopsys dw mipi dsi driver.
>>
>>> This way, more MIPI DSI panels can connect to this nwl-dsi bridge.
>>> Care is taken to make sure bridge_funcs->mode_set()/atomic_disable()
>>> are called in pairs, which includes removing a check on unchanged HS
>>> clock rate and forcing a full modeset when only connector's DPMS is
>>> brought out of "Off" status.
>>
>> I would split the changes in multiple patches to clarify the changes.
> 
> Maybe, I can split this into the below 3 patches:
> 1) Remove a check on unchanged HS clock rate from ->mode_set().
> 2) Force a full modeset when only connector's DPMS is brought out of
> "Off" status. This will be done in ->atomic_check() together with the
> fixup for H/VSYNC polarities.
> 3) Shift the bridge operation as the last step.
> 
> I'll mention that 1) & 2) are needed by 3) in their commit message.

Sure, you can also put this split explanation in the cover letter.

> 
> Does this split-up sound reasonable?

Yes makes sense, thanks

Neil

> 
> Thanks,
> Liu Ying
> 
>>
>> Neil
>>
>>> Cc: Andrzej Hajda 
>>> Cc: Neil Armstrong 
>>> Cc: Robert Foss 
>>> Cc: Laurent Pinchart 
>>> Cc: Jonas Karlman 
>>> Cc: Jernej Skrabec 
>>> Cc: David Airlie 
>>> Cc: Daniel Vetter 
>>> Cc: Guido Günther 
>>> Cc: Robert Chiras 
>>> Cc: NXP Linux Team 
>>> Signed-off-by: Liu Ying 
>>> ---
>>> v1->v2:
>>> * Fix commit message typo - s/unchange/unchanged/
>>>
>>>  drivers/gpu/drm/bridge/nwl-dsi.c | 86 
>>> +---
>>>  1 file changed, 46 insertions(+), 40 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c 
>>> b/drivers/gpu/drm/bridge/nwl-dsi.c
>>> index be6bfc5..229f0b1 100644
>>> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
>>> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
>>> @@ -21,6 +21,7 @@
>>>  #include 
>>>  #include 
>>>  
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -661,7 +662,7 @@ static irqreturn_t nwl_dsi_irq_handler(int irq, void 
>>> *data)
>>> return IRQ_HANDLED;
>>>  }
>>>  
>>> -static int nwl_dsi_enable(struct nwl_dsi *dsi)
>>> +static int nwl_dsi_mode_set(struct nwl_dsi *dsi)
>>>  {
>>> struct device *dev = dsi->dev;
>>> union phy_configure_opts *phy_cfg = &dsi->phy_cfg;
>>> @@ -748,7 +749,9 @@ static int nwl_dsi_disable(struct nwl_dsi *dsi)
>>> return 0;
>>>  }
>>>  
>>> -static void nwl_dsi_bridge_disable(struct drm_bridge *bridge)
>>> +static void
>>> +nwl_dsi_bridge_atomic_disable(struct drm_bridge *bridge,
>>> + struct drm_bridge_state *old_bridge_state)
>>>  {
>>> struct nwl_dsi *dsi = bridge_to_dsi(bridge);
>>> int ret;
>>> @@ -809,17 +812,6 @@ static int nwl_dsi_get_dphy_params(struct nwl_dsi *dsi,
>>> return 0;
>>>  }
>>>  
>>> -static bool nwl_dsi_bridge_mode_fixup(struct drm_bridge *bridge,
>>> - const struct drm_display_mode *mode,
>>> - struct drm_display_mode *adjusted_mode)
>>> -{
>>> -   /* At least LCDIF + NWL needs active high sync */
>>> -   adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
>>> -   adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
>>> -
>>> -   return true;
>>> -}
>>> -
>>>  static enum drm_mode_status
>>>  nwl_dsi_bridge_mode_valid(struct drm_bridge *bridge,
>>>

Re: [PATCH] drm: bridge: add missing word in Analogix help text

[Neil Armstrong]

Le 24/04/2021 à 08:18, Randy Dunlap a écrit :
> Insert a missing word "power" in Kconfig help text.
> 
> Fixes: 6aa192698089 ("drm/bridge: Add Analogix anx6345 support")
> Signed-off-by: Randy Dunlap 
> Cc: Andrzej Hajda 
> Cc: Neil Armstrong 
> Cc: Robert Foss 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: Icenowy Zheng 
> Cc: Vasily Khoruzhick 
> Cc: Torsten Duwe 
> Cc: Maxime Ripard 
> ---
>  drivers/gpu/drm/bridge/analogix/Kconfig |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- linux-next-20210423.orig/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ linux-next-20210423/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -6,7 +6,7 @@ config DRM_ANALOGIX_ANX6345
>   select DRM_KMS_HELPER
>   select REGMAP_I2C
>   help
> -   ANX6345 is an ultra-low Full-HD DisplayPort/eDP
> +   ANX6345 is an ultra-low power Full-HD DisplayPort/eDP
> transmitter designed for portable devices. The
> ANX6345 transforms the LVTTL RGB output of an
> application processor to eDP or DisplayPort.
> 

Reviewed-by: Neil Armstrong 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/3] drm/bridge: nwl-dsi: Get MIPI DSI controller and PHY ready in ->mode_set()

[Neil Armstrong]

Hi,

On 23/04/2021 11:26, Liu Ying wrote:
> Hi,
> 
> This series aims to make the nwl-dsi bridge be able to connect with
> more MIPI DSI panels.  Some MIPI DSI panel drivers like 'raydium,rm68200'
> send MIPI_DCS_SET_DISPLAY_ON commands in panel_funcs->prepare(), which
> requires the MIPI DSI controller and PHY to be ready beforehand.
> However, the existing nwl-dsi driver gets the MIPI DSI controller and
> PHY ready in bridge_funcs->pre_enable(), which happens after the
> panel_funcs->prepare().  So, this series shifts the bridge operation
> ealier from bridge_funcs->pre_enable() to bridge_funcs->mode_set().
> 
> Patch 3/3 does the essential bridge operation shift.
> 
> Patch 1/3 and 2/3 are split from the original single patch in v2 and
> are needed by patch 3/3.  This split-up helps clarify changes better.
> The split-up is done in this way:
> 
> 1) Patch 1/3 forces a full modeset when crtc_state->active is changed to
>be true(which implies only connector's DPMS is brought out of "Off"
>status, though not necessarily).  This makes sure ->mode_set() and
>->atomic_disable() will be called in pairs.
> 2) Patch 2/3 removes a check on unchanged HS clock rate from ->mode_set(),
>to make sure MIPI DSI controller and PHY are brought up and taken down
>in pairs.
> 3) Patch 3/3 shifts the bridge operation as the last step.
> 
> 
> v2->v3:
> * Split the single patch in v2 into 3 patches. (Neil)
> 
> v1->v2:
> * Fix a typo in commit message - s/unchange/unchanged/
> 
> 
> Liu Ying (3):
>   drm/bridge: nwl-dsi: Force a full modeset when crtc_state->active is
> changed to be true
>   drm/bridge: nwl-dsi: Remove a check on unchanged HS clock rate from
> ->mode_set()
>   drm/bridge: nwl-dsi: Get MIPI DSI controller and PHY ready in
> ->mode_set()
> 
>  drivers/gpu/drm/bridge/nwl-dsi.c | 86 +---
>  1 file changed, 46 insertions(+), 40 deletions(-)
> 

The patchset looks fine, I'll leave a few days for Laurent or Rob to eventually 
comment.

Thanks,
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: bridge: add missing word in Analogix help text

[Neil Armstrong]

On 26/04/2021 09:42, Robert Foss wrote:
> 
> 
> On Mon, Apr 26, 2021, 09:15 Neil Armstrong  <mailto:narmstr...@baylibre.com>> wrote:
> 
> 
> 
> Le 24/04/2021 à 08:18, Randy Dunlap a écrit :
> > Insert a missing word "power" in Kconfig help text.
> >
> > Fixes: 6aa192698089 ("drm/bridge: Add Analogix anx6345 support")
> > Signed-off-by: Randy Dunlap  <mailto:rdun...@infradead.org>>
> > Cc: Andrzej Hajda mailto:a.ha...@samsung.com>>
> > Cc: Neil Armstrong  <mailto:narmstr...@baylibre.com>>
> > Cc: Robert Foss mailto:robert.f...@linaro.org>>
> > Cc: David Airlie mailto:airl...@linux.ie>>
> > Cc: Daniel Vetter mailto:dan...@ffwll.ch>>
> > Cc: dri-devel@lists.freedesktop.org 
> <mailto:dri-devel@lists.freedesktop.org>
> > Cc: Icenowy Zheng mailto:icen...@aosc.io>>
> > Cc: Vasily Khoruzhick mailto:anars...@gmail.com>>
> > Cc: Torsten Duwe mailto:d...@suse.de>>
> > Cc: Maxime Ripard 
> > ---
> >  drivers/gpu/drm/bridge/analogix/Kconfig |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --- linux-next-20210423.orig/drivers/gpu/drm/bridge/analogix/Kconfig
> > +++ linux-next-20210423/drivers/gpu/drm/bridge/analogix/Kconfig
> > @@ -6,7 +6,7 @@ config DRM_ANALOGIX_ANX6345
> >       select DRM_KMS_HELPER
> >       select REGMAP_I2C
> >       help
> > -       ANX6345 is an ultra-low Full-HD DisplayPort/eDP
> > +       ANX6345 is an ultra-low power Full-HD DisplayPort/eDP
> >         transmitter designed for portable devices. The
> >         ANX6345 transforms the LVTTL RGB output of an
> >         application processor to eDP or DisplayPort.
> >
> 
> Reviewed-by: Neil Armstrong  <mailto:narmstro...@baylibre.com>>
> 
> 
> I think a typo in the email snuck in ;)
> 

Ah ah indeed !

Reviewed-by: Neil Armstrong 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 0/4] drm/panfrost: Add support for mt8183 GPU

[Neil Armstrong]

Hi,

On 21/04/2021 07:28, Nicolas Boichat wrote:
> Hi!
> 
> This is just a rebase of the v11, untested (but it seems like
> Neil Armstrong recently tested it), with small changes in
> binding and dts. v11 cover follows:
> 
> Follow-up on the v5 [1], things have gotten significantly
> better in the last year, thanks to the efforts on Bifrost
> support by the Collabora team (and probably others I'm not
> aware of).
> 
> I've been testing this series on a MT8183/kukui device, with a
> chromeos-5.10 kernel [2], and got basic Chromium OS UI up with
> mesa 20.3.2 (lots of artifacts though).
> 
> devfreq is currently not supported, as we'll need:
>  - Clock core support for switching the GPU core clock (see 2/4).
>  - Platform-specific handling of the 2-regulator (see 3/4).
> 
> Since the latter is easy to detect, patch 3/4 just disables
> devfreq if the more than one regulator is specified in the
> compatible matching table.
> 
> [1] 
> https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.259332-1-drink...@chromium.org/
> [2] https://crrev.com/c/2608070
> 
> Changes in v13:
>  - devfreq: Fix conflict resolution mistake when rebasing, didn't
>even compile. Oops.
> 
> Changes in v12:
>  - binding: Fix min/maxItems logic (Rob Herring)
>  - Add gpu node to mt8183-pumpkin.dts as well (Neil Armstrong).
> 
> Changes in v11:
>  - binding: power-domain-names not power-domainS-names
>  - mt8183*.dts: remove incorrect supply-names
> 
> Changes in v10:
>  - Fix the binding to make sure sram-supply property can be provided.
> 
> Changes in v9:
>  - Explain why devfreq needs to be disabled for GPUs with >1
>regulators.
> 
> Changes in v8:
>  - Use DRM_DEV_INFO instead of ERROR
> 
> Changes in v7:
>  - Fix GPU ID in commit message
>  - Fix GPU ID in commit message
> 
> Changes in v6:
>  - Rebased, actually tested with recent mesa driver.
>  - Add gpu regulators to kukui dtsi as well.
>  - Power domains are now attached to spm, not scpsys
>  - Drop R-B.
>  - devfreq: New change
>  - Context conflicts, reflow the code.
>  - Use ARRAY_SIZE for power domains too.
> 
> Changes in v5:
>  - Rename "2d" power domain to "core2"
>  - Rename "2d" power domain to "core2" (keep R-B again).
>  - Change power domain name from 2d to core2.
> 
> Changes in v4:
>  - Add power-domain-names description
>(kept Alyssa's reviewed-by as the change is minor)
>  - Add power-domain-names to describe the 3 domains.
>(kept Alyssa's reviewed-by as the change is minor)
>  - Add power domain names.
> 
> Changes in v3:
>  - Match mt8183-mali instead of bifrost, as we require special
>handling for the 2 regulators and 3 power domains.
> 
> Changes in v2:
>  - Use sram instead of mali_sram as SRAM supply name.
>  - Rename mali@ to gpu@.
> 
> Nicolas Boichat (4):
>   dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
>   arm64: dts: mt8183: Add node for the Mali GPU
>   drm/panfrost: devfreq: Disable devfreq when num_supplies > 1
>   drm/panfrost: Add mt8183-mali compatible string
> 
>  .../bindings/gpu/arm,mali-bifrost.yaml|  30 -
>  arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   5 +
>  .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi |   5 +
>  .../boot/dts/mediatek/mt8183-pumpkin.dts  |   5 +
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi  | 105 ++
>  drivers/gpu/drm/panfrost/panfrost_devfreq.c   |   9 ++
>  drivers/gpu/drm/panfrost/panfrost_drv.c   |  10 ++
>  7 files changed, 168 insertions(+), 1 deletion(-)
> 

Seems this version is ready to be applied if we get a review on the DT ?

Mathias ? could you have a look ?

Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: bridge: add missing word in Analogix help text

[Neil Armstrong]

On 26/04/2021 10:59, Neil Armstrong wrote:
> On 26/04/2021 09:42, Robert Foss wrote:
>>
>>
>> On Mon, Apr 26, 2021, 09:15 Neil Armstrong > <mailto:narmstr...@baylibre.com>> wrote:
>>
>>
>>
>> Le 24/04/2021 à 08:18, Randy Dunlap a écrit :
>> > Insert a missing word "power" in Kconfig help text.
>> >
>> > Fixes: 6aa192698089 ("drm/bridge: Add Analogix anx6345 support")
>> > Signed-off-by: Randy Dunlap > <mailto:rdun...@infradead.org>>
>> > Cc: Andrzej Hajda mailto:a.ha...@samsung.com>>
>> > Cc: Neil Armstrong > <mailto:narmstr...@baylibre.com>>
>> > Cc: Robert Foss > <mailto:robert.f...@linaro.org>>
>> > Cc: David Airlie mailto:airl...@linux.ie>>
>> > Cc: Daniel Vetter mailto:dan...@ffwll.ch>>
>> > Cc: dri-devel@lists.freedesktop.org 
>> <mailto:dri-devel@lists.freedesktop.org>
>> > Cc: Icenowy Zheng mailto:icen...@aosc.io>>
>> > Cc: Vasily Khoruzhick mailto:anars...@gmail.com>>
>> > Cc: Torsten Duwe mailto:d...@suse.de>>
>> > Cc: Maxime Ripard 
>> > ---
>> >  drivers/gpu/drm/bridge/analogix/Kconfig |    2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > --- linux-next-20210423.orig/drivers/gpu/drm/bridge/analogix/Kconfig
>> > +++ linux-next-20210423/drivers/gpu/drm/bridge/analogix/Kconfig
>> > @@ -6,7 +6,7 @@ config DRM_ANALOGIX_ANX6345
>> >       select DRM_KMS_HELPER
>> >       select REGMAP_I2C
>> >       help
>> > -       ANX6345 is an ultra-low Full-HD DisplayPort/eDP
>> > +       ANX6345 is an ultra-low power Full-HD DisplayPort/eDP
>> >         transmitter designed for portable devices. The
>> >         ANX6345 transforms the LVTTL RGB output of an
>> >         application processor to eDP or DisplayPort.
>> >
>>
>> Reviewed-by: Neil Armstrong > <mailto:narmstro...@baylibre.com>>
>>
>>
>> I think a typo in the email snuck in ;)
>>
> 
> Ah ah indeed !
> 
> Reviewed-by: Neil Armstrong 
> 
Wow, twice the same error... Monday was a bead day for me

Reviewed-by: Neil Armstrong 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: anx7625: Fix power on delay

[Neil Armstrong]

On 27/04/2021 07:53, Hsin-Yi Wang wrote:
> From anx7625 spec, the delay between powering on power supplies and gpio
> should be larger than 10ms.
> 
> Fixes: 6c744983004e ("drm/bridge: anx7625: disable regulators when power off")
> Signed-off-by: Hsin-Yi Wang 
> ---
>  drivers/gpu/drm/bridge/analogix/anx7625.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index 23283ba0c4f9..0a8db745cfd5 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -893,7 +893,7 @@ static void anx7625_power_on(struct anx7625_data *ctx)
>   usleep_range(2000, 2100);
>   }
>  
> - usleep_range(4000, 4100);
> + usleep_range(1, 11000);
>  
>   /* Power on pin enable */
>   gpiod_set_value(ctx->pdata.gpio_p_on, 1);
> 

Reviewed-by: Neil Armstrong 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver

[Neil Armstrong]

On 28/04/2021 11:26, Loic Poulain wrote:
> On Wed, 28 Apr 2021 at 10:13, Frieder Schrempf
>  wrote:
>>
>> On 28.04.21 09:51, Frieder Schrempf wrote:
>>> On 22.04.21 00:31, Marek Vasut wrote:
 Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
 and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
 bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on,
 but easy to add.

 The driver operates the chip via I2C bus. Currently the LVDS clock are
 always derived from DSI clock lane, which is the usual mode of operation.
 Support for clock from external oscillator is not implemented, but it is
 easy to add if ever needed. Only RGB888 pixel format is implemented, the
 LVDS666 is not supported, but could be added if needed.

 Signed-off-by: Marek Vasut 
 Cc: Douglas Anderson 
 Cc: Jagan Teki 
 Cc: Laurent Pinchart 
 Cc: Linus Walleij 
 Cc: Philippe Schenker 
 Cc: Sam Ravnborg 
 Cc: Stephen Boyd 
 Cc: Valentin Raevsky 
 To: dri-devel@lists.freedesktop.org
 Tested-by: Loic Poulain 
 ---
 V2: - Use dev_err_probe()
  - Set REG_RC_RESET as volatile
  - Wait for PLL stabilization by polling REG_RC_LVDS_PLL
  - Use ctx->mode = *adj instead of *mode in sn65dsi83_mode_set
  - Add tested DSI84 support in dual-link mode
  - Correctly set VCOM
  - Fill in missing DSI CHB and LVDS CHB bits from DSI84 and DSI85
datasheets, with that all the reserved bits make far more sense
as the DSI83 and DSI84 seems to be reduced version of DSI85
 ---
   drivers/gpu/drm/bridge/Kconfig|  10 +
   drivers/gpu/drm/bridge/Makefile   |   1 +
   drivers/gpu/drm/bridge/ti-sn65dsi83.c | 617 ++
   3 files changed, 628 insertions(+)
   create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c

>>> [...]
 +static int sn65dsi83_probe(struct i2c_client *client,
 +   const struct i2c_device_id *id)
 +{
 +struct device *dev = &client->dev;
 +enum sn65dsi83_model model;
 +struct sn65dsi83 *ctx;
 +int ret;
 +
 +ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
 +if (!ctx)
 +return -ENOMEM;
 +
 +ctx->dev = dev;
 +
 +if (dev->of_node)
 +model = (enum sn65dsi83_model)of_device_get_match_data(dev);
 +else
 +model = id->driver_data;
 +
 +/* Default to dual-link LVDS on all but DSI83. */
 +if (model != MODEL_SN65DSI83)
 +ctx->lvds_dual_link = true;
>>>
>>> What if I use the DSI84 with a single link LVDS? I can't see any way to
>>> configure that right now.
> 
> I assume the simplest way would be to use the "ti,sn65dsi83"
> compatible string in your dts, since the way you wired it is
> 'compatible' with sn65dsi83, right?

No this isn't the right way to to, if sn65dsi84 is supported and the bindings 
only support single lvds link,
the driver must only support single link on sn65dsi84, or add the dual link 
lvds in the bindings only for sn65dsi84.

> 
>>
>> I just saw the note in the header of the driver that says that single
>> link mode is unsupported for the DSI84.
>>
>> I have hardware with a single link display and if I set
>> ctx->lvds_dual_link = false it works just fine.
>>
>> How is this supposed to be selected? Does it need an extra devicetree
>> property? And would you mind adding single-link support in the next
>> version or do you prefer adding it in a follow-up patch?
> 
> If this has to be supported I think the proper way would be to support
> two output ports in the dts (e.g. lvds0_out, lvds1_out), in the same
> way as supported by the 'advantech,idk-2121wr' panel.

Yes, this is why I asked to have the dual-link lvds in the bindings.

Neil

> 
> Regards,
> Loic
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/meson: fix shutdown crash when component not probed

[Neil Armstrong]

When main component is not probed, by example when the dw-hdmi module is
not loaded yet or in probe defer, the following crash appears on shutdown:

Unable to handle kernel NULL pointer dereference at virtual address 
0038
...
pc : meson_drv_shutdown+0x24/0x50
lr : platform_drv_shutdown+0x20/0x30
...
Call trace:
meson_drv_shutdown+0x24/0x50
platform_drv_shutdown+0x20/0x30
device_shutdown+0x158/0x360
kernel_restart_prepare+0x38/0x48
kernel_restart+0x18/0x68
__do_sys_reboot+0x224/0x250
__arm64_sys_reboot+0x24/0x30
...

Simply check if the priv struct has been allocated before using it.

Fixes: fa0c16caf3d7 ("drm: meson_drv add shutdown function")
Reported-by: Stefan Agner 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_drv.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_drv.c 
b/drivers/gpu/drm/meson/meson_drv.c
index 453d8b4c5763..07fcd12dca16 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -485,11 +485,12 @@ static int meson_probe_remote(struct platform_device 
*pdev,
 static void meson_drv_shutdown(struct platform_device *pdev)
 {
struct meson_drm *priv = dev_get_drvdata(&pdev->dev);
-   struct drm_device *drm = priv->drm;
 
-   DRM_DEBUG_DRIVER("\n");
-   drm_kms_helper_poll_fini(drm);
-   drm_atomic_helper_shutdown(drm);
+   if (!priv)
+   return;
+
+   drm_kms_helper_poll_fini(priv->drm);
+   drm_atomic_helper_shutdown(priv->drm);
 }
 
 static int meson_drv_probe(struct platform_device *pdev)
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver

[Neil Armstrong]

On 29/04/2021 18:27, Frieder Schrempf wrote:
> On 28.04.21 16:16, Marek Vasut wrote:
>> On 4/28/21 11:24 AM, Neil Armstrong wrote:
>> [...]
>>
>>>>>>> +static int sn65dsi83_probe(struct i2c_client *client,
>>>>>>> +   const struct i2c_device_id *id)
>>>>>>> +{
>>>>>>> +    struct device *dev = &client->dev;
>>>>>>> +    enum sn65dsi83_model model;
>>>>>>> +    struct sn65dsi83 *ctx;
>>>>>>> +    int ret;
>>>>>>> +
>>>>>>> +    ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
>>>>>>> +    if (!ctx)
>>>>>>> +    return -ENOMEM;
>>>>>>> +
>>>>>>> +    ctx->dev = dev;
>>>>>>> +
>>>>>>> +    if (dev->of_node)
>>>>>>> +    model = (enum sn65dsi83_model)of_device_get_match_data(dev);
>>>>>>> +    else
>>>>>>> +    model = id->driver_data;
>>>>>>> +
>>>>>>> +    /* Default to dual-link LVDS on all but DSI83. */
>>>>>>> +    if (model != MODEL_SN65DSI83)
>>>>>>> +    ctx->lvds_dual_link = true;
>>>>>>
>>>>>> What if I use the DSI84 with a single link LVDS? I can't see any way to
>>>>>> configure that right now.
>>>>
>>>> I assume the simplest way would be to use the "ti,sn65dsi83"
>>>> compatible string in your dts, since the way you wired it is
>>>> 'compatible' with sn65dsi83, right?
>>>
>>> No this isn't the right way to to, if sn65dsi84 is supported and the 
>>> bindings only support single lvds link,
>>> the driver must only support single link on sn65dsi84, or add the dual link 
>>> lvds in the bindings only for sn65dsi84.
>>
>> The driver has a comment about what is supported and tested, as Frieder 
>> already pointed out:
>>
>> Currently supported:
>> - SN65DSI83
>>    = 1x Single-link DSI ~ 1x Single-link LVDS
>>    - Supported
>>    - Single-link LVDS mode tested
>> - SN65DSI84
>>    = 1x Single-link DSI ~ 2x Single-link or 1x Dual-link LVDS
>>    - Supported
>>    - Dual-link LVDS mode tested
>>    - 2x Single-link LVDS mode unsupported
>>  (should be easy to add by someone who has the HW)
>> - SN65DSI85
>>    = 2x Single-link or 1x Dual-link DSI ~ 2x Single-link or 1x Dual-link LVDS
>>    - Unsupported
>>  (should be easy to add by someone who has the HW)
>>
>> So,
>> DSI83 is always single-link DSI, single-link LVDS.
>> DSI84 is always single-link DSI, and currently always dual-link LVDS.
>>
>> The DSI83 can do one thing on the LVDS end:
>> - 1x single link lVDS
>>
>> The DSI84 can do two things on the LVDS end:
>> - 1x single link lVDS
>> - 1x dual link LVDS
>>
>> There is also some sort of mention in the DSI84 datasheet about 2x single 
>> link LVDS, but I suspect that might be copied from DSI85 datasheet instead, 
>> which would make sense. The other option is that it behaves as a mirror 
>> (i.e. same pixels are scanned out of LVDS channel A and B). Either option 
>> can be added by either adding a DT property which would enable the mirror 
>> mode, or new port linking the LVDS endpoint to the same panel twice, and/or 
>> two new ports for DSI85, so there is no problem to extend the bindings 
>> without breaking them. So for now I would ignore this mode.
> 
> Agreed.
> 
>>
>> So ultimately, what we have to sort out is the 1x single / 1x dual link LVDS 
>> mode setting on DSI84. Frieder already pointed out how the driver can be 
>> tweaked to support the single-link mode on DSI84, so now we need to tie it 
>> into DT bindings.
>>
>> Currently, neither the LVDS panels in upstream in panel-simple nor lvds.yaml 
>> provide any indication that the panel is single-link or dual-link. Those 
>> dual-link LVDS panels seem to always set 2x pixel clock and let the bridge 
>> somehow sort it out.
>>
>> Maybe that isn't always the best approach, maybe we should add a new 
>> DRM_BUS_FLAG for those panels and handle the flag in the bridge driver ? 
>> Such a new flag could be added over time to panels where applicable, so old 
>> setups won't be broken by that either, they will just ignore the new flag 
>> and work as before.
> 
> I agree that the panel dr

Re: [PATCH v3 1/3] drm/bridge: nwl-dsi: Force a full modeset when crtc_state->active is changed to be true

[Neil Armstrong]

On 23/04/2021 11:26, Liu Ying wrote:
> This patch replaces ->mode_fixup() with ->atomic_check() so that
> a full modeset can be requested from there when crtc_state->active
> is changed to be true(which implies only connector's DPMS is brought
> out of "Off" status, though not necessarily).  Bridge functions are
> added or changed to accommodate the ->atomic_check() callback.  That
> full modeset is needed by the up-coming patch which gets MIPI DSI
> controller and PHY ready in ->mode_set(), because it makes sure
> ->mode_set() and ->atomic_disable() are called in pairs.
> 
> Cc: Andrzej Hajda 
> Cc: Neil Armstrong 
> Cc: Robert Foss 
> Cc: Laurent Pinchart 
> Cc: Jonas Karlman 
> Cc: Jernej Skrabec 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Guido Günther 
> Cc: Robert Chiras 
> Cc: NXP Linux Team 
> Signed-off-by: Liu Ying 
> ---
> v2->v3:
> * Split from the single patch in v2 to clarify changes. (Neil)
> 
>  drivers/gpu/drm/bridge/nwl-dsi.c | 61 
>  1 file changed, 39 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c 
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index 66b67402f1acd..c65ca860712d2 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -742,7 +743,9 @@ static int nwl_dsi_disable(struct nwl_dsi *dsi)
>   return 0;
>  }
>  
> -static void nwl_dsi_bridge_disable(struct drm_bridge *bridge)
> +static void
> +nwl_dsi_bridge_atomic_disable(struct drm_bridge *bridge,
> +   struct drm_bridge_state *old_bridge_state)
>  {
>   struct nwl_dsi *dsi = bridge_to_dsi(bridge);
>   int ret;
> @@ -803,17 +806,6 @@ static int nwl_dsi_get_dphy_params(struct nwl_dsi *dsi,
>   return 0;
>  }
>  
> -static bool nwl_dsi_bridge_mode_fixup(struct drm_bridge *bridge,
> -   const struct drm_display_mode *mode,
> -   struct drm_display_mode *adjusted_mode)
> -{
> - /* At least LCDIF + NWL needs active high sync */
> - adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
> - adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
> -
> - return true;
> -}
> -
>  static enum drm_mode_status
>  nwl_dsi_bridge_mode_valid(struct drm_bridge *bridge,
> const struct drm_display_info *info,
> @@ -831,6 +823,24 @@ nwl_dsi_bridge_mode_valid(struct drm_bridge *bridge,
>   return MODE_OK;
>  }
>  
> +static int nwl_dsi_bridge_atomic_check(struct drm_bridge *bridge,
> +struct drm_bridge_state *bridge_state,
> +struct drm_crtc_state *crtc_state,
> +struct drm_connector_state *conn_state)
> +{
> + struct drm_display_mode *adjusted_mode = &crtc_state->adjusted_mode;
> +
> + /* At least LCDIF + NWL needs active high sync */
> + adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
> + adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
> +
> + /* Do a full modeset if crtc_state->active is changed to be true. */
> + if (crtc_state->active_changed && crtc_state->active)
> + crtc_state->mode_changed = true;
> +
> + return 0;
> +}
> +
>  static void
>  nwl_dsi_bridge_mode_set(struct drm_bridge *bridge,
>   const struct drm_display_mode *mode,
> @@ -862,7 +872,9 @@ nwl_dsi_bridge_mode_set(struct drm_bridge *bridge,
>   drm_mode_debug_printmodeline(adjusted_mode);
>  }
>  
> -static void nwl_dsi_bridge_pre_enable(struct drm_bridge *bridge)
> +static void
> +nwl_dsi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
> +  struct drm_bridge_state *old_bridge_state)
>  {
>   struct nwl_dsi *dsi = bridge_to_dsi(bridge);
>   int ret;
> @@ -897,7 +909,9 @@ static void nwl_dsi_bridge_pre_enable(struct drm_bridge 
> *bridge)
>   }
>  }
>  
> -static void nwl_dsi_bridge_enable(struct drm_bridge *bridge)
> +static void
> +nwl_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
> +  struct drm_bridge_state *old_bridge_state)
>  {
>   struct nwl_dsi *dsi = bridge_to_dsi(bridge);
>   int ret;
> @@ -942,14 +956,17 @@ static void nwl_dsi_bridge_detach(struct drm_bridge 
> *bridge)
>  }
>  
>  static const struct drm_bridge_funcs nwl_dsi_bridge_func

Re: [PATCH v3 2/3] drm/bridge: nwl-dsi: Remove a check on unchanged HS clock rate from ->mode_set()

[Neil Armstrong]

On 23/04/2021 11:26, Liu Ying wrote:
> The check on unchanged HS clock rate in ->mode_set() improves
> the callback's performance a bit by early return.  However,
> the up-coming patch would get MIPI DSI controller and PHY ready
> in ->mode_set() after that check, thus likely skipped.
> So, this patch removes that check to make sure MIPI DSI controller
> and PHY will be brought up and taken down from ->mode_set() and
> ->atomic_disable() respectively in pairs.
> 
> Cc: Andrzej Hajda 
> Cc: Neil Armstrong 
> Cc: Robert Foss 
> Cc: Laurent Pinchart 
> Cc: Jonas Karlman 
> Cc: Jernej Skrabec 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Guido Günther 
> Cc: Robert Chiras 
> Cc: NXP Linux Team 
> Signed-off-by: Liu Ying 
> ---
> v2->v3:
> * Split from the single patch in v2 to clarify changes. (Neil)
> 
>  drivers/gpu/drm/bridge/nwl-dsi.c | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c 
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index c65ca860712d2..601ccc4a7cdc7 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -856,13 +856,6 @@ nwl_dsi_bridge_mode_set(struct drm_bridge *bridge,
>   if (ret < 0)
>   return;
>  
> - /*
> -  * If hs clock is unchanged, we're all good - all parameters are
> -  * derived from it atm.
> -  */
> - if (new_cfg.mipi_dphy.hs_clk_rate == dsi->phy_cfg.mipi_dphy.hs_clk_rate)
> - return;
> -
>   phy_ref_rate = clk_get_rate(dsi->phy_ref_clk);
>   DRM_DEV_DEBUG_DRIVER(dev, "PHY at ref rate: %lu\n", phy_ref_rate);
>   /* Save the new desired phy config */
> 

Reviewed-by: Neil Armstrong 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/3] drm/bridge: nwl-dsi: Get MIPI DSI controller and PHY ready in ->mode_set()

[Neil Armstrong]

On 23/04/2021 11:26, Liu Ying wrote:
> Some MIPI DSI panel drivers like 'raydium,rm68200' send
> MIPI_DCS_SET_DISPLAY_ON commands in panel_funcs->prepare(), which
> requires the MIPI DSI controller and PHY to be ready beforehand.
> Without this patch, the nwl-dsi driver gets the MIPI DSI controller
> and PHY ready in bridge_funcs->atomic_pre_enable(), which happens after
> the panel_funcs->prepare().  So, this patch shifts the bridge operation
> ealier from bridge_funcs->atomic_pre_enable() to bridge_funcs->mode_set().
> This way, more MIPI DSI panels can connect to this nwl-dsi bridge.
> 
> Cc: Andrzej Hajda 
> Cc: Neil Armstrong 
> Cc: Robert Foss 
> Cc: Laurent Pinchart 
> Cc: Jonas Karlman 
> Cc: Jernej Skrabec 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Guido Günther 
> Cc: Robert Chiras 
> Cc: NXP Linux Team 
> Signed-off-by: Liu Ying 
> ---
> v2->v3:
> * Split some changes to patch 1/3 and 2/3, to clarify changes. (Neil)
> 
> v1->v2:
> * Fix a typo in commit message - s/unchange/unchanged/
> 
>  drivers/gpu/drm/bridge/nwl-dsi.c | 28 
>  1 file changed, 12 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c 
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index 601ccc4a7cdc7..873995f0a7416 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -662,7 +662,7 @@ static irqreturn_t nwl_dsi_irq_handler(int irq, void 
> *data)
>   return IRQ_HANDLED;
>  }
>  
> -static int nwl_dsi_enable(struct nwl_dsi *dsi)
> +static int nwl_dsi_mode_set(struct nwl_dsi *dsi)
>  {
>   struct device *dev = dsi->dev;
>   union phy_configure_opts *phy_cfg = &dsi->phy_cfg;
> @@ -834,7 +834,12 @@ static int nwl_dsi_bridge_atomic_check(struct drm_bridge 
> *bridge,
>   adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
>   adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
>  
> - /* Do a full modeset if crtc_state->active is changed to be true. */
> + /*
> +  * Do a full modeset if crtc_state->active is changed to be true.
> +  * This ensures our ->mode_set() is called to get the DSI controller
> +  * and the PHY ready to send DCS commands, when only the connector's
> +  * DPMS is brought out of "Off" status.
> +  */
>   if (crtc_state->active_changed && crtc_state->active)
>   crtc_state->mode_changed = true;
>  
> @@ -863,16 +868,8 @@ nwl_dsi_bridge_mode_set(struct drm_bridge *bridge,
>  
>   memcpy(&dsi->mode, adjusted_mode, sizeof(dsi->mode));
>   drm_mode_debug_printmodeline(adjusted_mode);
> -}
> -
> -static void
> -nwl_dsi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
> -  struct drm_bridge_state *old_bridge_state)
> -{
> - struct nwl_dsi *dsi = bridge_to_dsi(bridge);
> - int ret;
>  
> - pm_runtime_get_sync(dsi->dev);
> + pm_runtime_get_sync(dev);
>  
>   if (clk_prepare_enable(dsi->lcdif_clk) < 0)
>   return;
> @@ -882,22 +879,22 @@ nwl_dsi_bridge_atomic_pre_enable(struct drm_bridge 
> *bridge,
>   /* Step 1 from DSI reset-out instructions */
>   ret = reset_control_deassert(dsi->rst_pclk);
>   if (ret < 0) {
> - DRM_DEV_ERROR(dsi->dev, "Failed to deassert PCLK: %d\n", ret);
> + DRM_DEV_ERROR(dev, "Failed to deassert PCLK: %d\n", ret);
>   return;
>   }
>  
>   /* Step 2 from DSI reset-out instructions */
> - nwl_dsi_enable(dsi);
> + nwl_dsi_mode_set(dsi);
>  
>   /* Step 3 from DSI reset-out instructions */
>   ret = reset_control_deassert(dsi->rst_esc);
>   if (ret < 0) {
> - DRM_DEV_ERROR(dsi->dev, "Failed to deassert ESC: %d\n", ret);
> + DRM_DEV_ERROR(dev, "Failed to deassert ESC: %d\n", ret);
>   return;
>   }
>   ret = reset_control_deassert(dsi->rst_byte);
>   if (ret < 0) {
> - DRM_DEV_ERROR(dsi->dev, "Failed to deassert BYTE: %d\n", ret);
> + DRM_DEV_ERROR(dev, "Failed to deassert BYTE: %d\n", ret);
>   return;
>   }
>  }
> @@ -953,7 +950,6 @@ static const struct drm_bridge_funcs nwl_dsi_bridge_funcs 
> = {
>   .atomic_destroy_state   = drm_atomic_helper_bridge_destroy_state,
>   .atomic_reset   = drm_atomic_helper_bridge_reset,
>   .atomic_check   = nwl_dsi_bridge_atomic_check,
> - .atomic_pre_enable  = nwl_dsi_bridge_atomic_pre_enable,
>   .atomic_enable  = nwl_dsi_bridge_atomic_enable,
>   .atomic_disable = nwl_dsi_bridge_atomic_disable,
>   .mode_set   = nwl_dsi_bridge_mode_set,
> 

Reviewed-by: Neil Armstrong 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/3] drm/bridge: nwl-dsi: Get MIPI DSI controller and PHY ready in ->mode_set()

[Neil Armstrong]

On 23/04/2021 11:26, Liu Ying wrote:
> Hi,
> 
> This series aims to make the nwl-dsi bridge be able to connect with
> more MIPI DSI panels.  Some MIPI DSI panel drivers like 'raydium,rm68200'
> send MIPI_DCS_SET_DISPLAY_ON commands in panel_funcs->prepare(), which
> requires the MIPI DSI controller and PHY to be ready beforehand.
> However, the existing nwl-dsi driver gets the MIPI DSI controller and
> PHY ready in bridge_funcs->pre_enable(), which happens after the
> panel_funcs->prepare().  So, this series shifts the bridge operation
> ealier from bridge_funcs->pre_enable() to bridge_funcs->mode_set().
> 
> Patch 3/3 does the essential bridge operation shift.
> 
> Patch 1/3 and 2/3 are split from the original single patch in v2 and
> are needed by patch 3/3.  This split-up helps clarify changes better.
> The split-up is done in this way:
> 
> 1) Patch 1/3 forces a full modeset when crtc_state->active is changed to
>be true(which implies only connector's DPMS is brought out of "Off"
>status, though not necessarily).  This makes sure ->mode_set() and
>->atomic_disable() will be called in pairs.
> 2) Patch 2/3 removes a check on unchanged HS clock rate from ->mode_set(),
>to make sure MIPI DSI controller and PHY are brought up and taken down
>in pairs.
> 3) Patch 3/3 shifts the bridge operation as the last step.
> 
> 
> v2->v3:
> * Split the single patch in v2 into 3 patches. (Neil)
> 
> v1->v2:
> * Fix a typo in commit message - s/unchange/unchanged/
> 
> 
> Liu Ying (3):
>   drm/bridge: nwl-dsi: Force a full modeset when crtc_state->active is
> changed to be true
>   drm/bridge: nwl-dsi: Remove a check on unchanged HS clock rate from
> ->mode_set()
>   drm/bridge: nwl-dsi: Get MIPI DSI controller and PHY ready in
> ->mode_set()
> 
>  drivers/gpu/drm/bridge/nwl-dsi.c | 86 +---
>  1 file changed, 46 insertions(+), 40 deletions(-)
> 

Applying to drm-misc-next

Thanks,
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/18] drm/bridge: Add HDMI output fmt helper

[Neil Armstrong]

On 17/03/2021 16:43, Maxime Ripard wrote:
> The atomic_get_output_bus_fmts bridge callback is there to list the
> available formats for output by decreasing order of preference.
> 
> On HDMI controllers, we have a fairly static list that will depend on
> what the HDMI sink is capable of and the BPC our controller can output.
> 
> The dw-hdmi driver already has that code done in a fairly generic
> manner, so let's turn that code into an helper for all the HDMI
> controllers to reuse.

This code was based on the capabilities of the DW-HDMI IP, copying it as-is
doesn't make much sense, we should be able to filter out formats the HDMI IP
doesn't support.

Neil

> 
> Signed-off-by: Maxime Ripard 
> ---

[...]
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/meson: Fix few typo

[Neil Armstrong]

On 18/03/2021 12:00, Bhaskar Chowdhury wrote:
> 
> s/initialy/initially/
> s/desined/designed/
> 
> Signed-off-by: Bhaskar Chowdhury 
> ---
>  drivers/gpu/drm/meson/meson_venc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_venc.c 
> b/drivers/gpu/drm/meson/meson_venc.c
> index 5e2236ec189f..3c55ed003359 100644
> --- a/drivers/gpu/drm/meson/meson_venc.c
> +++ b/drivers/gpu/drm/meson/meson_venc.c
> @@ -45,7 +45,7 @@
>   * The ENCI is designed for PAl or NTSC encoding and can go through the VDAC
>   * directly for CVBS encoding or through the ENCI_DVI encoder for HDMI.
>   * The ENCP is designed for Progressive encoding but can also generate
> - * 1080i interlaced pixels, and was initialy desined to encode pixels for
> + * 1080i interlaced pixels, and was initially designed to encode pixels for
>   * VDAC to output RGB ou YUV analog outputs.
>   * It's output is only used through the ENCP_DVI encoder for HDMI.
>   * The ENCL LVDS encoder is not implemented.
> --
> 2.26.2
> 

Thanks,
Applied to drm-misc-next

Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/18] drm/bridge: Add HDMI output fmt helper

[Neil Armstrong]

On 18/03/2021 19:31, Jernej Škrabec wrote:
> Dne sreda, 17. marec 2021 ob 17:08:07 CET je Neil Armstrong napisal(a):
>> On 17/03/2021 16:43, Maxime Ripard wrote:
>>> The atomic_get_output_bus_fmts bridge callback is there to list the
>>> available formats for output by decreasing order of preference.
>>>
>>> On HDMI controllers, we have a fairly static list that will depend on
>>> what the HDMI sink is capable of and the BPC our controller can output.
>>>
>>> The dw-hdmi driver already has that code done in a fairly generic
>>> manner, so let's turn that code into an helper for all the HDMI
>>> controllers to reuse.
>>
>> This code was based on the capabilities of the DW-HDMI IP, copying it as-is
>> doesn't make much sense, we should be able to filter out formats the HDMI IP
>> doesn't support.
> 
> HDMI standard has pretty strict requirements which formats should be 
> supported, so cores should have very similar capabilities.

Yes for output formats (we still may need to filter out 420, 422 for example),

No for input formats, since it depends entirely on the capability of the 
transceiver
in terms of format conversion.

Neil

> 
> Best regards,
> Jernej
> 
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1] MAINTAINERS: Update Maintainers of DRM Bridge Drivers

[Neil Armstrong]

Hi !

On 24/03/2021 11:20, Robert Foss wrote:
> Add myself as co-maintainer of DRM Bridge Drivers. Repository
> commit access has already been granted.
> 
> https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/338
> 
> Cc: Neil Armstrong 
> Cc: Laurent Pinchart 
> Cc: Jonas Karlman 
> Cc: Andrzej Hajda 
> Cc: Jernej Škrabec 
> Cc: Daniel Vetter 
> Signed-off-by: Robert Foss 

+ CC: dri-devel@lists.freedesktop.org

> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4b705ba51c54..16ace8f58649 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5902,6 +5902,7 @@ F:  drivers/gpu/drm/atmel-hlcdc/
>  DRM DRIVERS FOR BRIDGE CHIPS
>  M:   Andrzej Hajda 
>  M:   Neil Armstrong 
> +M:   Robert Foss 
>  R:   Laurent Pinchart 
>  R:   Jonas Karlman 
>  R:   Jernej Skrabec 
> 

Acked-by: Neil Armstrong 

Welcome to the team, help is needed !

Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD

[Neil Armstrong]

Hi,


On 10/01/2021 21:06, Oliver Graute wrote:
> On 10/01/21, Fabio Estevam wrote:
>> Hi Oliver,
>>
>> On Sun, Jan 10, 2021 at 12:35 PM Oliver Graute  
>> wrote:
>>
>>> the first two errors are gone. But I still get this:
>>>
>>> [   42.387107] mxsfb 21c8000.lcdif: Cannot connect bridge: -517
>>>
>>> The panel is still off perhaps I miss something else.
>>
>> Some suggestions:
>>
>> - Take a look at arch/arm/boot/dts/imx6ul-14x14-evk.dtsi as a
>> reference as it has display functional
>> - Use imx_v6_v7_defconfig to make sure all the required drivers are selected
> 
> ok I checked imx6ul-14x14-evk.dtsi and use imx_v6_v7_defconfig
> 
>> - If it still does not work, share the dts and schematics
> 
> here the schematics and my dts. The board is using a LVDS connector for
> the display.
> 
> https://www.variscite.de/wp-content/uploads/2017/12/VAR-6ULCustomboard-Schematics.pdf
> https://lore.kernel.org/linux-arm-kernel/1610144511-19018-3-git-send-email-oliver.gra...@gmail.com/

The DT6CustomBoard uses almost the same screen (sgd,gktw70sdae4se), it's 
supported and tested in kernelci, you can find the dt in 
arch/arm/boot/dts/imx6q-var-dt6customboard.dts

Neil

> 
> Thx for your help,
> 
> Best Regards,
> 
> Oliver
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] dt-bindings: display: Add "disable-hpd" binding

[Neil Armstrong]

Hi,

On 31/01/2021 10:57, Mykyta Poturai wrote:
> Add the "disable-hpd" binding, used to disable hotplug detected
> functionality in the driver. When it's enabled the driver assumes that
> the connector is always connected and disables the hotplug detect
> related IRQ.

DT describes the hardware, not the software behaviour.

So if the HPD is broken, then add a "snps,broken-hpd" instead, or if you want 
to force output, use the DRM mode forcing, which is handled by the dw-hdmi code:
https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes

Neil

> 
> Signed-off-by: Mykyta Poturai 
> ---
>  .../devicetree/bindings/display/bridge/renesas,dw-hdmi.txt   | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt 
> b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> index 3f6072651182..b2b899f46b86 100644
> --- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> @@ -39,6 +39,7 @@ Optional properties:
>  
>  - power-domains: Shall reference the power domain that contains the DWC HDMI,
>if any.
> +- disable-hpd: Disables the hotplug detect feature
>  
>  
>  Example:
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/bridge: dw-hdmi: Add DT binding to disable hotplug detect

[Neil Armstrong]

On 31/01/2021 10:55, Mykyta Poturai wrote:
> Add "disable-hpd" boolean binding for the device tree. When this option
> is turned on HPD-related IRQ is disabled and it is assumed that the HDMI
> connector is connected all the time. This may be useful in systems where
> it is impossible or undesirable to connect the HPD pin, or the
> connection is broken.

DRM mode forcing exists for this reason.

You can even force an EDID to have a fixed mode.

Neil

> 
> Signed-off-by: Mykyta Poturai 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 0c79a9ba48bb..4ca0ac130beb 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -194,6 +194,7 @@ struct dw_hdmi {
>   unsigned int audio_cts;
>   unsigned int audio_n;
>   bool audio_enable;
> + bool disable_hpd;
>  
>   unsigned int reg_shift;
>   struct regmap *regm;
> @@ -1559,7 +1560,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi, 
> void *data)
>  enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
>  void *data)
>  {
> - return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
> + return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD || 
> hdmi->disable_hpd ?
>   connector_status_connected : connector_status_disconnected;
>  }
>  EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
> @@ -1585,6 +1586,10 @@ void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void 
> *data)
>* Configure the PHY RX SENSE and HPD interrupts polarities and clear
>* any pending interrupt.
>*/
> +
> + if (hdmi->disable_hpd)
> + return;
> +
>   hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
>   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
>   HDMI_IH_PHY_STAT0);
> @@ -3212,6 +3217,10 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device 
> *pdev,
>   mutex_init(&hdmi->cec_notifier_mutex);
>   spin_lock_init(&hdmi->audio_lock);
>  
> + if (of_property_read_bool(np, "disable-hpd")) {
> + dev_info(hdmi->dev, "Disabling HPD\n");
> + hdmi->disable_hpd = true;
> + }
>   ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
>   if (ddc_node) {
>   hdmi->ddc = of_get_i2c_adapter_by_node(ddc_node);
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/2] dt-bindings: display: bridge: Add bindings for SN65DSI83/84/85

[Neil Armstrong]

Hi,

On 14/02/2021 18:44, Jagan Teki wrote:
> SN65DSI83/84/85 devices are MIPI DSI to LVDS based bridge
> controller IC's from Texas Instruments.
> 
> SN65DSI83 - Single Channel DSI to Single-link LVDS bridge
> SN65DSI84 - Single Channel DSI to Dual-link LVDS bridge
> SN65DSI85 - Dual Channel DSI to Dual-link LVDS bridge
> 
> Right now the bridge driver is supporting Channel A with single
> link, so dt-bindings documented according to it.

Shouldn't it describe Dual-link LVDS already for SN65DSI84/85 and Dual Channel 
DSI for SN65DSI85 even if not implemented in the driver ?

Neil

> 
> Cc: Marek Vasut 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v3:
> - fixed Rob comments
> - updated commit message and file name to support all chip variants 
> Changes for v2:
> - none
> 
>  .../bindings/display/bridge/ti,sn65dsi8x.yaml | 122 ++
>  1 file changed, 122 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/ti,sn65dsi8x.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi8x.yaml 
> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi8x.yaml
> new file mode 100644
> index ..7f9f8cd6e786
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi8x.yaml
> @@ -0,0 +1,122 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi8x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI SN65DSI83/84/85 MIPI DSI to LVDS bridge bindings
> +
> +maintainers:
> +  - Jagan Teki 
> +
> +description: |
> +  SN65DSI83/84/85 devices are MIPI DSI to LVDS based bridge controller
> +  IC's from Texas Instruments.
> +
> +  SN65DSI83 - Single Channel DSI to Single-link LVDS bridge
> +  SN65DSI84 - Single Channel DSI to Dual-link LVDS bridge
> +  SN65DSI85 - Dual Channel DSI to Dual-link LVDS bridge
> +
> +  Bridge decodes MIPI DSI 18bpp RGB666 and 240bpp RG888 packets and
> +  converts the formatted video data stream to a FlatLink compatible
> +  LVDS output operating at pixel clocks operating from 25 MHx to
> +  154 MHz.
> +
> +properties:
> +  compatible:
> +enum:
> +  - ti,sn65dsi83
> +  - ti,sn65dsi84
> +
> +  reg:
> +const: 0x2c
> +
> +  enable-gpios:
> +maxItems: 1
> +description: GPIO specifier for bridge enable pin (active high).
> +
> +  ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> +  port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: |
> +  DSI Input. The remote endpoint phandle should be a
> +  reference to a valid mipi_dsi_host device node.
> +
> +  port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: |
> +  Video port for LVDS output (panel or connector).
> +
> +required:
> +  - port@0
> +  - port@1
> +
> +required:
> +  - compatible
> +  - reg
> +  - enable-gpios
> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +
> +dsi {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   port@0 {
> +   reg = <0>;
> +   dsi_in: endpoint {
> +   remote-endpoint = <;
> +   };
> +   };
> +
> +   port@1 {
> +   reg = <1>;
> +   dsi_out: endpoint {
> +   remote-endpoint = <&bridge_in>;
> +   data-lanes = <0 1>;
> +   };
> +   };
> +   };
> +};
> +
> +i2c6 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   bridge@2c {
> +   compatible = "ti,sn65dsi84";
> +   reg = <0x2c>;
> +   enable-gpios = <&gpiof 15 GPIO_ACTIVE_HIGH>;
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   port@0 {
> +   reg = <0>;
> +   bridge_in: endpoint {
> +remote-endpoint = <&dsi_out>;
> +   };
> +   };
> +
> +   port@1 {
> +   reg = <1>;
> +   bridge_out: endpoint {
> +remote-endpoint = <&panel_in_lvds>;
> +   };
> +   };
> +   };
> +   };
> +};
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: ITE66121 HDMI driver

[Neil Armstrong]

Hi,

On 14/02/2021 00:54, Paul Cercueil wrote:
> Hi Phong and Neil,
> 
> I see you sent a patchset to support the ITE66121 HDMI transmitter, last 
> version being the V2 back in March 2020.
> 
> Do you still plan to mainline it?

Yes, we still plan to mainline it.

> 
> I do have a device with a ITE66121 chip, so I can help to clean the driver 
> and have it mainlined. But right now I cannot get the driver to work, while 
> the chip is properly detected and correct DDC data is read,, my PC monitor 
> does not detect any signal.

Having DDC read working is a good point...

Did you check the DPI data setup ? the chip supports dual data rate input, and 
the last version only supported it via a DT property.

Neil


> 
> Cheers,
> -Paul
> 
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] dt-bindings: Add YAML bindings for Host1x and NVDEC

[Neil Armstrong]

On 13/02/2021 11:15, Mikko Perttunen wrote:
> Convert the original Host1x bindings to YAML and add new bindings for
> NVDEC, now in a more appropriate location. The old text bindings
> for Host1x and engines are still kept at display/tegra/ since they
> encompass a lot more engines that haven't been converted over yet.
> 
> Signed-off-by: Mikko Perttunen 
> ---
>  .../gpu/host1x/nvidia,tegra20-host1x.yaml | 129 ++
>  .../gpu/host1x/nvidia,tegra210-nvdec.yaml |  90 
>  MAINTAINERS   |   1 +
>  3 files changed, 220 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml 
> b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml
> new file mode 100644
> index ..613c6601f0f1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml
> @@ -0,0 +1,129 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra20-host1x.yaml#";
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> +
> +title: Device tree binding for NVIDIA Host1x
> +
> +maintainers:
> +  - Thierry Reding 
> +  - Mikko Perttunen 
> +
> +properties:
> +  $nodename:
> +pattern: "^host1x@[0-9a-f]*$"
> +
> +  compatible:
> +oneOf:
> +  - const: nvidia,tegra20-host1x
> +  - const: nvidia,tegra30-host1x
> +  - const: nvidia,tegra114-host1x
> +  - const: nvidia,tegra124-host1x
> +  - items:
> +  - const: nvidia,tegra132-host1x
> +  - const: nvidia,tegra124-host1x
> +  - const: nvidia,tegra210-host1x
> +
> +  reg:
> +maxItems: 1
> +
> +  interrupts:
> +items:
> +  - description: Syncpoint threshold interrupt
> +  - description: General interrupt
> +
> +  interrupt-names:
> +items:
> +  - const: syncpt
> +  - const: host1x
> +
> +  clocks:
> +maxItems: 1
> +
> +  clock-names:
> +items:
> +  - const: host1x
> +
> +  resets:
> +maxItems: 1
> +
> +  reset-names:
> +items:
> +  - const: host1x
> +
> +  iommus:
> +maxItems: 1
> +
> +  interconnects:
> +maxItems: 1
> +
> +  interconnect-names:
> +items:
> +  - const: dma-mem
> +
> +  '#address-cells':
> +const: 1
> +
> +  '#size-cells':
> +const: 1
> +
> +  ranges: true
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - interrupt-names
> +  - clocks
> +  - clock-names
> +  - resets
> +  - reset-names
> +  - '#address-cells'
> +  - '#size-cells'
> +  - ranges
> +
> +additionalProperties:
> +  type: object
> +
> +if:
> +  properties:
> +compatible:
> +  contains:
> +anyOf:
> +  - const: nvidia,tegra186-host1x
> +  - const: nvidia,tegra194-host1x
> +then:
> +  properties:
> +reg:
> +  items:
> +- description: Hypervisor-accessible register area
> +- description: VM-accessible register area
> +reg-names:
> +  items:
> +- const: hypervisor
> +- const: vm
> +  required:
> +- reg-names
> +
> +examples:
> +  - |
> +#include 
> +#include 
> +
> +host1x@5000 {
> +compatible = "nvidia,tegra20-host1x";
> +reg = <0x5000 0x00024000>;
> +interrupts = , /* syncpt */
> +  ; /* general */
> +interrupt-names = "syncpt", "host1x";
> +clocks = <&tegra_car TEGRA20_CLK_HOST1X>;
> +clock-names = "host1x";
> +resets = <&tegra_car 28>;
> +reset-names = "host1x";
> +
> +#address-cells = <1>;
> +#size-cells = <1>;
> +
> +ranges = <0x5400 0x5400 0x0400>;
> +};
> diff --git 
> a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml 
> b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml
> new file mode 100644
> index ..9a6334d930c8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml
> @@ -0,0 +1,90 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvdec.yaml#";
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> +
> +title: Device tree binding for NVIDIA Tegra VIC

---/\ Should be NVDEC ?

Neil

> +
> +maintainers:
> +  - Thierry Reding 
> +  - Mikko Perttunen 
> +
> +properties:
> +  $nodename:
> +pattern: "^nvdec@[0-9a-f]*$"
> +
> +  compatible:
> +enum:
> +  - nvidia,tegra210-nvdec
> +  - nvidia,tegra186-nvdec
> +  - nvidia,tegra194-nvdec
> +
> +  reg:
> +maxItems: 1
> +
> +  clocks:
> +maxItems: 1
> +
> +  clock-names:
> +items:
> +  -

Re: [PATCH 0/3] NVIDIA Tegra NVDEC support

[Neil Armstrong]

Hi,

On 13/02/2021 11:15, Mikko Perttunen wrote:
> Hi all,
> 
> with the release of documentation headers for Tegra multimedia engines
> (NVDEC, NVENC, NVJPG) [1], I have started working on the corresponding
> implementations. Here's the first one, NVDEC.
> 
> The kernel driver is a simple Falcon boot driver based on the VIC
> driver. Some code sharing should be considered there in the future.
> The userspace driver to accompany this is a bit more complicated -
> I have expanded vaapi-tegra-driver[2] to support MPEG2 decoding.
> It should be noted that the implementation is still very clunky
> and has poor performance, but it's a start.

Funny how all this tries to avoid all the DRM, remoteproc, V4L2-M2M stateless & 
co
all the other vendors tries to make usage of...

Neil

> 
> This series is based on top of the "Host1x/TegraDRM UAPI" series.
> For testing, appropriate firmware should be obtained from a
> Linux for Tegra distribution for now; the GPU should also be
> enabled in the device tree.
> 
> Series was tested on Tegra186.
> 
> Thanks!
> 
> Mikko
> 
> [1] https://github.com/NVIDIA/open-gpu-doc/tree/master/classes/video
> [2] https://github.com/cyndis/vaapi-tegra-driver
> 
> Mikko Perttunen (3):
>   dt-bindings: Add YAML bindings for Host1x and NVDEC
>   arm64: tegra: Add NVDEC to Tegra186 device tree
>   drm/tegra: Add NVDEC driver
> 
>  .../gpu/host1x/nvidia,tegra20-host1x.yaml | 129 +
>  .../gpu/host1x/nvidia,tegra210-nvdec.yaml |  90 
>  MAINTAINERS   |   1 +
>  arch/arm64/boot/dts/nvidia/tegra186.dtsi  |  15 +
>  drivers/gpu/drm/tegra/Makefile|   3 +-
>  drivers/gpu/drm/tegra/drm.c   |   4 +
>  drivers/gpu/drm/tegra/drm.h   |   1 +
>  drivers/gpu/drm/tegra/nvdec.c | 497 ++
>  drivers/gpu/host1x/dev.c  |  12 +
>  include/linux/host1x.h|   1 +
>  10 files changed, 752 insertions(+), 1 deletion(-)
>  create mode 100644 
> Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml
>  create mode 100644 drivers/gpu/drm/tegra/nvdec.c
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] NVIDIA Tegra NVDEC support

[Neil Armstrong]

Hi Thierry,


On 15/02/2021 10:50, Thierry Reding wrote:
> On Mon, Feb 15, 2021 at 10:10:26AM +0100, Neil Armstrong wrote:
>> Hi,
>>
>> On 13/02/2021 11:15, Mikko Perttunen wrote:
>>> Hi all,
>>>
>>> with the release of documentation headers for Tegra multimedia engines
>>> (NVDEC, NVENC, NVJPG) [1], I have started working on the corresponding
>>> implementations. Here's the first one, NVDEC.
>>>
>>> The kernel driver is a simple Falcon boot driver based on the VIC
>>> driver. Some code sharing should be considered there in the future.
>>> The userspace driver to accompany this is a bit more complicated -
>>> I have expanded vaapi-tegra-driver[2] to support MPEG2 decoding.
>>> It should be noted that the implementation is still very clunky
>>> and has poor performance, but it's a start.
>>
>> Funny how all this tries to avoid all the DRM, remoteproc, V4L2-M2M 
>> stateless & co
>> all the other vendors tries to make usage of...
> 
> Care to elaborate why you think this is trying to avoid anything? Mikko
> pointed you at the documentation for these engines, provided a link to
> an open-source (albeit work in progress) userspace driver and posts an
> extension to an existing DRM driver to add the required kernel
> functionality. That's a standard approach for submitting this kind of
> driver.

Thanks for the reply, I didn't look extensively at all the documents & userspace
libraries, but I wonder why this couldn't fit in the V4L2-M2M approach and avoid
having userspace drivers and specific libraries to handle this.

Neil

> 
> Thierry
> 




signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: ITE66121 HDMI driver

[Neil Armstrong]

On 15/02/2021 13:01, Paul Cercueil wrote:
> 
> 
> Le lun. 15 févr. 2021 à 10:05, Neil Armstrong  a 
> écrit :
>> Hi,
>>
>> On 14/02/2021 00:54, Paul Cercueil wrote:
>>>  Hi Phong and Neil,
>>>
>>>  I see you sent a patchset to support the ITE66121 HDMI transmitter, last 
>>> version being the V2 back in March 2020.
>>>
>>>  Do you still plan to mainline it?
>>
>> Yes, we still plan to mainline it.
> 
> Ok, great!
> 
>>>
>>>  I do have a device with a ITE66121 chip, so I can help to clean the driver 
>>> and have it mainlined. But right now I cannot get the driver to work, while 
>>> the chip is properly detected and correct DDC data is read,, my PC monitor 
>>> does not detect any signal.
>>
>> Having DDC read working is a good point...
>>
>> Did you check the DPI data setup ? the chip supports dual data rate input, 
>> and the last version only supported it via a DT property.
> 
> If "dual data rate" means two pixels per pixclock tick, then my SoC does not 
> support it. I did try both modes though.
> 
> The other thing is that my SoC has no VDE/HDE pins, so (according to the 
> manual) I have to have the chip recreate these signals from videomode 
> information. Which I did, and I get the "video stable" status bit, but I 
> still cannot get anything on screen.

What is the mode you're trying to achieve ?

let me send a v3 with all the comments from v2 fixed and re-start a discussion 
from this patchset.

Neil

> 
> Cheers,
> -Paul
> 
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/2] dt-bindings: display: bridge: Add bindings for SN65DSI83/84/85

[Neil Armstrong]

Hi,

On 15/02/2021 12:25, Jagan Teki wrote:
> On Mon, Feb 15, 2021 at 2:32 PM Neil Armstrong  
> wrote:
>>
>> Hi,
>>
>> On 14/02/2021 18:44, Jagan Teki wrote:
>>> SN65DSI83/84/85 devices are MIPI DSI to LVDS based bridge
>>> controller IC's from Texas Instruments.
>>>
>>> SN65DSI83 - Single Channel DSI to Single-link LVDS bridge
>>> SN65DSI84 - Single Channel DSI to Dual-link LVDS bridge
>>> SN65DSI85 - Dual Channel DSI to Dual-link LVDS bridge
>>>
>>> Right now the bridge driver is supporting Channel A with single
>>> link, so dt-bindings documented according to it.
>>
>> Shouldn't it describe Dual-link LVDS already for SN65DSI84/85 and Dual 
>> Channel DSI for SN65DSI85 even if not implemented in the driver ?
> 
> Patch documented only Single link LVDS as it only supported by driver.
> Single link LVDS with Channel A configuration is common across all 3
> variant chips. I have SN65DSI84 with Single link LVDS which is routed
> in Channel A. Idea is to go with Single link and add double link later
> and document the same.

DT Bindings is unrelated to the software support, simply add the second LVDS 
channel endpoint
for SN65DSI84/85 and the second dsi endpoint for SN65DSI85.

Neil

> 
> Jagan.
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: meson_drv add shutdown function

[Neil Armstrong]

On 02/03/2021 05:22, Artem Lapkin wrote:
> Problem: random stucks on reboot stage about 1/20 stuck/reboots
> // debug kernel log
> [4.496660] reboot: kernel restart prepare CMD:(null)
> [4.498114] meson_ee_pwrc c883c000.system-controller:power-controller: 
> shutdown begin
> [4.503949] meson_ee_pwrc c883c000.system-controller:power-controller: 
> shutdown domain 0:VPU...
> ...STUCK...
> 
> Solution: add shutdown function to meson_drm driver 
> // debug kernel log
> [5.231896] reboot: kernel restart prepare CMD:(null)
> [5.246135] [drm:meson_drv_shutdown]
> ...
> [5.259271] meson_ee_pwrc c883c000.system-controller:power-controller: 
> shutdown begin
> [5.274688] meson_ee_pwrc c883c000.system-controller:power-controller: 
> shutdown domain 0:VPU...
> [5.338331] reboot: Restarting system
> [5.358293] psci: PSCI_0_2_FN_SYSTEM_RESET reboot_mode:0 cmd:(null)
> bl31 reboot reason: 0xd
> bl31 reboot reason: 0x0
> system cmd  1.
> ...REBOOT...
> 
> Tested: on VIM1 VIM2 VIM3 VIM3L khadas sbcs - 1000+ successful reboots
> and Odroid boards, WeTek Play2 (GXBB)
> 

Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")

> Tested-by: Christian Hewitt 
> Signed-off-by: Artem Lapkin 
> 
> ---
>  drivers/gpu/drm/meson/meson_drv.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
> b/drivers/gpu/drm/meson/meson_drv.c
> index 42c5d3246..693bb1293 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -482,6 +482,16 @@ static int meson_probe_remote(struct platform_device 
> *pdev,
>   return count;
>  }
>  
> +static void meson_drv_shutdown(struct platform_device *pdev)
> +{
> + struct meson_drm *priv = dev_get_drvdata(&pdev->dev);
> + struct drm_device *drm = priv->drm;
> +
> + DRM_DEBUG_DRIVER("\n");
> + drm_kms_helper_poll_fini(drm);
> + drm_atomic_helper_shutdown(drm);
> +}
> +
>  static int meson_drv_probe(struct platform_device *pdev)
>  {
>   struct component_match *match = NULL;
> @@ -553,6 +563,7 @@ static const struct dev_pm_ops meson_drv_pm_ops = {
>  
>  static struct platform_driver meson_drm_platform_driver = {
>   .probe  = meson_drv_probe,
> + .shutdown   = meson_drv_shutdown,
>   .driver = {
>   .name   = "meson-drm",
>   .of_match_table = dt_match,
> 

Acked-by: Neil Armstrong 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: meson_drv add shutdown function

[Neil Armstrong]

On 02/03/2021 05:22, Artem Lapkin wrote:
> Problem: random stucks on reboot stage about 1/20 stuck/reboots
> // debug kernel log
> [4.496660] reboot: kernel restart prepare CMD:(null)
> [4.498114] meson_ee_pwrc c883c000.system-controller:power-controller: 
> shutdown begin
> [4.503949] meson_ee_pwrc c883c000.system-controller:power-controller: 
> shutdown domain 0:VPU...
> ...STUCK...
> 
> Solution: add shutdown function to meson_drm driver 
> // debug kernel log
> [5.231896] reboot: kernel restart prepare CMD:(null)
> [5.246135] [drm:meson_drv_shutdown]
> ...
> [5.259271] meson_ee_pwrc c883c000.system-controller:power-controller: 
> shutdown begin
> [5.274688] meson_ee_pwrc c883c000.system-controller:power-controller: 
> shutdown domain 0:VPU...
> [5.338331] reboot: Restarting system
> [5.358293] psci: PSCI_0_2_FN_SYSTEM_RESET reboot_mode:0 cmd:(null)
> bl31 reboot reason: 0xd
> bl31 reboot reason: 0x0
> system cmd  1.
> ...REBOOT...
> 
> Tested: on VIM1 VIM2 VIM3 VIM3L khadas sbcs - 1000+ successful reboots
> and Odroid boards, WeTek Play2 (GXBB)
> 
> Tested-by: Christian Hewitt 
> Signed-off-by: Artem Lapkin 
> 
> ---
>  drivers/gpu/drm/meson/meson_drv.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
> b/drivers/gpu/drm/meson/meson_drv.c
> index 42c5d3246..693bb1293 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -482,6 +482,16 @@ static int meson_probe_remote(struct platform_device 
> *pdev,
>   return count;
>  }
>  
> +static void meson_drv_shutdown(struct platform_device *pdev)
> +{
> + struct meson_drm *priv = dev_get_drvdata(&pdev->dev);
> + struct drm_device *drm = priv->drm;
> +
> + DRM_DEBUG_DRIVER("\n");
> + drm_kms_helper_poll_fini(drm);
> + drm_atomic_helper_shutdown(drm);
> +}
> +
>  static int meson_drv_probe(struct platform_device *pdev)
>  {
>   struct component_match *match = NULL;
> @@ -553,6 +563,7 @@ static const struct dev_pm_ops meson_drv_pm_ops = {
>  
>  static struct platform_driver meson_drm_platform_driver = {
>   .probe  = meson_drv_probe,
> + .shutdown   = meson_drv_shutdown,
>   .driver = {
>   .name   = "meson-drm",
>   .of_match_table = dt_match,
> 

Applied to drm-misc-fixes,

Thanks !
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: meson_drv add shutdown function

[Neil Armstrong]

On 09/03/2021 18:13, Kevin Hilman wrote:
> Hi Neil,
> 
> Neil Armstrong  writes:
> 
>> On 02/03/2021 05:22, Artem Lapkin wrote:
>>> Problem: random stucks on reboot stage about 1/20 stuck/reboots
>>> // debug kernel log
>>> [4.496660] reboot: kernel restart prepare CMD:(null)
>>> [4.498114] meson_ee_pwrc c883c000.system-controller:power-controller: 
>>> shutdown begin
>>> [4.503949] meson_ee_pwrc c883c000.system-controller:power-controller: 
>>> shutdown domain 0:VPU...
>>> ...STUCK...
>>>
>>> Solution: add shutdown function to meson_drm driver 
>>> // debug kernel log
>>> [5.231896] reboot: kernel restart prepare CMD:(null)
>>> [5.246135] [drm:meson_drv_shutdown]
>>> ...
>>> [5.259271] meson_ee_pwrc c883c000.system-controller:power-controller: 
>>> shutdown begin
>>> [5.274688] meson_ee_pwrc c883c000.system-controller:power-controller: 
>>> shutdown domain 0:VPU...
>>> [5.338331] reboot: Restarting system
>>> [5.358293] psci: PSCI_0_2_FN_SYSTEM_RESET reboot_mode:0 cmd:(null)
>>> bl31 reboot reason: 0xd
>>> bl31 reboot reason: 0x0
>>> system cmd  1.
>>> ...REBOOT...
>>>
>>> Tested: on VIM1 VIM2 VIM3 VIM3L khadas sbcs - 1000+ successful reboots
>>> and Odroid boards, WeTek Play2 (GXBB)
>>>
>>> Tested-by: Christian Hewitt 
>>> Signed-off-by: Artem Lapkin 
>>>
>>> ---
>>>  drivers/gpu/drm/meson/meson_drv.c | 11 +++
>>>  1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
>>> b/drivers/gpu/drm/meson/meson_drv.c
>>> index 42c5d3246..693bb1293 100644
>>> --- a/drivers/gpu/drm/meson/meson_drv.c
>>> +++ b/drivers/gpu/drm/meson/meson_drv.c
>>> @@ -482,6 +482,16 @@ static int meson_probe_remote(struct platform_device 
>>> *pdev,
>>> return count;
>>>  }
>>>  
>>> +static void meson_drv_shutdown(struct platform_device *pdev)
>>> +{
>>> +   struct meson_drm *priv = dev_get_drvdata(&pdev->dev);
>>> +   struct drm_device *drm = priv->drm;
>>> +
>>> +   DRM_DEBUG_DRIVER("\n");
>>> +   drm_kms_helper_poll_fini(drm);
>>> +   drm_atomic_helper_shutdown(drm);
>>> +}
>>> +
>>>  static int meson_drv_probe(struct platform_device *pdev)
>>>  {
>>> struct component_match *match = NULL;
>>> @@ -553,6 +563,7 @@ static const struct dev_pm_ops meson_drv_pm_ops = {
>>>  
>>>  static struct platform_driver meson_drm_platform_driver = {
>>> .probe  = meson_drv_probe,
>>> +   .shutdown   = meson_drv_shutdown,
>>> .driver = {
>>> .name   = "meson-drm",
>>> .of_match_table = dt_match,
>>>
>>
>> Applied to drm-misc-fixes,
> 
> Could you submit this as a fix to stable (v5.10+) also?

It should be done automagically since I added the Fixes tag

neil

> 
> Thanks,
> 
> Kevin
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 0/4] drm/panfrost: Add support for mt8183 GPU

[Neil Armstrong]

On 13/05/2021 16:55, Ezequiel Garcia wrote:
> Hi Neil,
> 
> On Mon, 26 Apr 2021 at 06:59, Neil Armstrong  wrote:
>>
>> Hi,
>>
>> On 21/04/2021 07:28, Nicolas Boichat wrote:
>>> Hi!
>>>
>>> This is just a rebase of the v11, untested (but it seems like
>>> Neil Armstrong recently tested it), with small changes in
>>> binding and dts. v11 cover follows:
>>>
>>> Follow-up on the v5 [1], things have gotten significantly
>>> better in the last year, thanks to the efforts on Bifrost
>>> support by the Collabora team (and probably others I'm not
>>> aware of).
>>>
>>> I've been testing this series on a MT8183/kukui device, with a
>>> chromeos-5.10 kernel [2], and got basic Chromium OS UI up with
>>> mesa 20.3.2 (lots of artifacts though).
>>>
>>> devfreq is currently not supported, as we'll need:
>>>  - Clock core support for switching the GPU core clock (see 2/4).
>>>  - Platform-specific handling of the 2-regulator (see 3/4).
>>>
>>> Since the latter is easy to detect, patch 3/4 just disables
>>> devfreq if the more than one regulator is specified in the
>>> compatible matching table.
>>>
>>> [1] 
>>> https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.259332-1-drink...@chromium.org/
>>> [2] https://crrev.com/c/2608070
>>>
>>> Changes in v13:
>>>  - devfreq: Fix conflict resolution mistake when rebasing, didn't
>>>even compile. Oops.
>>>
>>> Changes in v12:
>>>  - binding: Fix min/maxItems logic (Rob Herring)
>>>  - Add gpu node to mt8183-pumpkin.dts as well (Neil Armstrong).
>>>
>>> Changes in v11:
>>>  - binding: power-domain-names not power-domainS-names
>>>  - mt8183*.dts: remove incorrect supply-names
>>>
>>> Changes in v10:
>>>  - Fix the binding to make sure sram-supply property can be provided.
>>>
>>> Changes in v9:
>>>  - Explain why devfreq needs to be disabled for GPUs with >1
>>>regulators.
>>>
>>> Changes in v8:
>>>  - Use DRM_DEV_INFO instead of ERROR
>>>
>>> Changes in v7:
>>>  - Fix GPU ID in commit message
>>>  - Fix GPU ID in commit message
>>>
>>> Changes in v6:
>>>  - Rebased, actually tested with recent mesa driver.
>>>  - Add gpu regulators to kukui dtsi as well.
>>>  - Power domains are now attached to spm, not scpsys
>>>  - Drop R-B.
>>>  - devfreq: New change
>>>  - Context conflicts, reflow the code.
>>>  - Use ARRAY_SIZE for power domains too.
>>>
>>> Changes in v5:
>>>  - Rename "2d" power domain to "core2"
>>>  - Rename "2d" power domain to "core2" (keep R-B again).
>>>  - Change power domain name from 2d to core2.
>>>
>>> Changes in v4:
>>>  - Add power-domain-names description
>>>(kept Alyssa's reviewed-by as the change is minor)
>>>  - Add power-domain-names to describe the 3 domains.
>>>(kept Alyssa's reviewed-by as the change is minor)
>>>  - Add power domain names.
>>>
>>> Changes in v3:
>>>  - Match mt8183-mali instead of bifrost, as we require special
>>>handling for the 2 regulators and 3 power domains.
>>>
>>> Changes in v2:
>>>  - Use sram instead of mali_sram as SRAM supply name.
>>>  - Rename mali@ to gpu@.
>>>
>>> Nicolas Boichat (4):
>>>   dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
>>>   arm64: dts: mt8183: Add node for the Mali GPU
>>>   drm/panfrost: devfreq: Disable devfreq when num_supplies > 1
>>>   drm/panfrost: Add mt8183-mali compatible string
>>>
>>>  .../bindings/gpu/arm,mali-bifrost.yaml|  30 -
>>>  arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   5 +
>>>  .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi |   5 +
>>>  .../boot/dts/mediatek/mt8183-pumpkin.dts  |   5 +
>>>  arch/arm64/boot/dts/mediatek/mt8183.dtsi  | 105 ++
>>>  drivers/gpu/drm/panfrost/panfrost_devfreq.c   |   9 ++
>>>  drivers/gpu/drm/panfrost/panfrost_drv.c   |  10 ++
>>>  7 files changed, 168 insertions(+), 1 deletion(-)
>>>
>>
>> Seems this version is ready to be applied if we get a review on the DT ?
>>
>> Mathias ? could you have a look ?
>>
> 
> Given Rob has Acked the DT bindings, I think it's OK to apply patches
> 1, 3 and 4 via drm-misc, letting Mediatek people sort out the DT changes.
> 
> My two unsolicited cents :-)

Yeah sure, is there a panfrost maintainer in the room ? I can apply them if you 
ack me.

Neil

> 
> Ezequiel
> 

Re: [PATCH 1/2] drm: bridge: it66121: fix an error code in it66121_probe()

[Neil Armstrong]

On 15/05/2021 11:50, Dan Carpenter wrote:
> This code is passing the wrong variable to PTR_ERR() so it doesn't
> return the correct error code.
> 
> Fixes: 988156dc2fc9 ("drm: bridge: add it66121 driver")
> Signed-off-by: Dan Carpenter 
> ---
>  drivers/gpu/drm/bridge/ite-it66121.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ite-it66121.c 
> b/drivers/gpu/drm/bridge/ite-it66121.c
> index d8a60691fd32..6980c9801d0d 100644
> --- a/drivers/gpu/drm/bridge/ite-it66121.c
> +++ b/drivers/gpu/drm/bridge/ite-it66121.c
> @@ -943,7 +943,7 @@ static int it66121_probe(struct i2c_client *client,
>   ctx->regmap = devm_regmap_init_i2c(client, &it66121_regmap_config);
>   if (IS_ERR(ctx->regmap)) {
>   ite66121_power_off(ctx);
> - return PTR_ERR(ctx);
> + return PTR_ERR(ctx->regmap);
>   }
>  
>   regmap_read(ctx->regmap, IT66121_VENDOR_ID0_REG, &vendor_ids[0]);
> 

Thanks !

Acked-by: Neil Armstrong 

Applying to drm-misc-fixes

Re: [PATCH 2/2] drm: bridge: it66121: fix a resource leak in probe

[Neil Armstrong]

On 15/05/2021 11:50, Dan Carpenter wrote:
> In the original code if the "ctx = devm_kzalloc()" allocation failed
> then we should have called of_node_put(ep); before returning.  It's
> actually a bit easier to do the allocation first before assigning
> ep = of_graph_get_endpoint_by_regs().
> 
> Fixes: 988156dc2fc9 ("drm: bridge: add it66121 driver")
> Signed-off-by: Dan Carpenter 
> ---
>  drivers/gpu/drm/bridge/ite-it66121.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ite-it66121.c 
> b/drivers/gpu/drm/bridge/ite-it66121.c
> index 6980c9801d0d..7149ed40af83 100644
> --- a/drivers/gpu/drm/bridge/ite-it66121.c
> +++ b/drivers/gpu/drm/bridge/ite-it66121.c
> @@ -898,14 +898,14 @@ static int it66121_probe(struct i2c_client *client,
>   return -ENXIO;
>   }
>  
> - ep = of_graph_get_endpoint_by_regs(dev->of_node, 0, 0);
> - if (!ep)
> - return -EINVAL;
> -
>   ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
>   if (!ctx)
>   return -ENOMEM;
>  
> + ep = of_graph_get_endpoint_by_regs(dev->of_node, 0, 0);
> + if (!ep)
> + return -EINVAL;
> +
>   ctx->dev = dev;
>   ctx->client = client;
>  
> 

Thanks !

Acked-by: Neil Armstrong 

Applying to drm-misc-fixes

Re: [PATCH v13 0/4] drm/panfrost: Add support for mt8183 GPU

[Neil Armstrong]

On 14/05/2021 17:27, Steven Price wrote:
> On 14/05/2021 15:48, Neil Armstrong wrote:
>> On 13/05/2021 16:55, Ezequiel Garcia wrote:
>>> Hi Neil,
>>>
>>> On Mon, 26 Apr 2021 at 06:59, Neil Armstrong  
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 21/04/2021 07:28, Nicolas Boichat wrote:
>>>>> Hi!
>>>>>
>>>>> This is just a rebase of the v11, untested (but it seems like
>>>>> Neil Armstrong recently tested it), with small changes in
>>>>> binding and dts. v11 cover follows:
>>>>>
>>>>> Follow-up on the v5 [1], things have gotten significantly
>>>>> better in the last year, thanks to the efforts on Bifrost
>>>>> support by the Collabora team (and probably others I'm not
>>>>> aware of).
>>>>>
>>>>> I've been testing this series on a MT8183/kukui device, with a
>>>>> chromeos-5.10 kernel [2], and got basic Chromium OS UI up with
>>>>> mesa 20.3.2 (lots of artifacts though).
>>>>>
>>>>> devfreq is currently not supported, as we'll need:
>>>>>  - Clock core support for switching the GPU core clock (see 2/4).
>>>>>  - Platform-specific handling of the 2-regulator (see 3/4).
>>>>>
>>>>> Since the latter is easy to detect, patch 3/4 just disables
>>>>> devfreq if the more than one regulator is specified in the
>>>>> compatible matching table.
>>>>>
>>>>> [1] 
>>>>> https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.259332-1-drink...@chromium.org/
>>>>> [2] https://crrev.com/c/2608070
>>>>>
>>>>> Changes in v13:
>>>>>  - devfreq: Fix conflict resolution mistake when rebasing, didn't
>>>>>even compile. Oops.
>>>>>
>>>>> Changes in v12:
>>>>>  - binding: Fix min/maxItems logic (Rob Herring)
>>>>>  - Add gpu node to mt8183-pumpkin.dts as well (Neil Armstrong).
>>>>>
>>>>> Changes in v11:
>>>>>  - binding: power-domain-names not power-domainS-names
>>>>>  - mt8183*.dts: remove incorrect supply-names
>>>>>
>>>>> Changes in v10:
>>>>>  - Fix the binding to make sure sram-supply property can be provided.
>>>>>
>>>>> Changes in v9:
>>>>>  - Explain why devfreq needs to be disabled for GPUs with >1
>>>>>regulators.
>>>>>
>>>>> Changes in v8:
>>>>>  - Use DRM_DEV_INFO instead of ERROR
>>>>>
>>>>> Changes in v7:
>>>>>  - Fix GPU ID in commit message
>>>>>  - Fix GPU ID in commit message
>>>>>
>>>>> Changes in v6:
>>>>>  - Rebased, actually tested with recent mesa driver.
>>>>>  - Add gpu regulators to kukui dtsi as well.
>>>>>  - Power domains are now attached to spm, not scpsys
>>>>>  - Drop R-B.
>>>>>  - devfreq: New change
>>>>>  - Context conflicts, reflow the code.
>>>>>  - Use ARRAY_SIZE for power domains too.
>>>>>
>>>>> Changes in v5:
>>>>>  - Rename "2d" power domain to "core2"
>>>>>  - Rename "2d" power domain to "core2" (keep R-B again).
>>>>>  - Change power domain name from 2d to core2.
>>>>>
>>>>> Changes in v4:
>>>>>  - Add power-domain-names description
>>>>>(kept Alyssa's reviewed-by as the change is minor)
>>>>>  - Add power-domain-names to describe the 3 domains.
>>>>>(kept Alyssa's reviewed-by as the change is minor)
>>>>>  - Add power domain names.
>>>>>
>>>>> Changes in v3:
>>>>>  - Match mt8183-mali instead of bifrost, as we require special
>>>>>handling for the 2 regulators and 3 power domains.
>>>>>
>>>>> Changes in v2:
>>>>>  - Use sram instead of mali_sram as SRAM supply name.
>>>>>  - Rename mali@ to gpu@.
>>>>>
>>>>> Nicolas Boichat (4):
>>>>>   dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
>>>>>   arm64: dts: mt8183: Add node for the Mali GPU
>>>>>   drm/panfrost: devfreq: Disable devfreq when num_supplies > 1
>>>>>   drm/panfrost: Add mt8183-mali compatible string
>>>>>
>>>>>  .../bindings/gpu/arm,mali-bifrost.yaml|  30 -
>>>>>  arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   5 +
>>>>>  .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi |   5 +
>>>>>  .../boot/dts/mediatek/mt8183-pumpkin.dts  |   5 +
>>>>>  arch/arm64/boot/dts/mediatek/mt8183.dtsi  | 105 ++
>>>>>  drivers/gpu/drm/panfrost/panfrost_devfreq.c   |   9 ++
>>>>>  drivers/gpu/drm/panfrost/panfrost_drv.c   |  10 ++
>>>>>  7 files changed, 168 insertions(+), 1 deletion(-)
>>>>>
>>>>
>>>> Seems this version is ready to be applied if we get a review on the DT ?
>>>>
>>>> Mathias ? could you have a look ?
>>>>
>>>
>>> Given Rob has Acked the DT bindings, I think it's OK to apply patches
>>> 1, 3 and 4 via drm-misc, letting Mediatek people sort out the DT changes.
>>>
>>> My two unsolicited cents :-)
> 
> You make a convincing point - and if everyone is happy for the DT
> changes to be handled separately I don't see a reason for the other
> patches to be held up.
> 
>> Yeah sure, is there a panfrost maintainer in the room ? I can apply them if 
>> you ack me.
> 
> I seem to be applying most Panfrost changes these days, so I'll save you
> the effort and push 1,3,4 to drm-misc-next.

Thanks !

Neil

> 
> Thanks,
> 
> Steve
> 

[PATCH 0/2] drm: panel: add support for the Khadas TS050 panel

[Neil Armstrong]

This add support & bindings for the Khadas TS050 1080x1920 5" LCD DSI panel 
designed
to work with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.
It provides a MIPI DSI interface to the host, a built-in LED backlight
and touch controller.

Neil Armstrong (2):
  dt-bindings: panel-simple-dsi: add Khadas TS050 panel bindings
  drm: panel: add Khadas TS050 panel driver

 .../display/panel/panel-simple-dsi.yaml   |   2 +
 drivers/gpu/drm/panel/Kconfig |  11 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-khadas-ts050.c| 876 ++
 4 files changed, 890 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-khadas-ts050.c

-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] dt-bindings: panel-simple-dsi: add Khadas TS050 panel bindings

[Neil Armstrong]

This add the bindings for the Khadas TS050 1080x1920 5" LCD DSI panel designed 
to work
with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.

Signed-off-by: Neil Armstrong 
---
 .../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
index 72e4b6d4d5e1..fbd71669248f 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
@@ -35,6 +35,8 @@ properties:
   - boe,tv080wum-nl0
 # Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
   - innolux,p079zca
+# Khadas TS050 5" 1080x1920 LCD panel
+  - khadas,ts050
 # Kingdisplay KD097D04 9.7" 1536x2048 TFT LCD panel
   - kingdisplay,kd097d04
 # LG ACX467AKM-7 4.95" 1080×1920 LCD Panel
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm: panel: add Khadas TS050 panel driver

[Neil Armstrong]

This add support for the Khadas TS050 1080x1920 5" LCD DSI panel designed to 
work
with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.
It provides a MIPI DSI interface to the host, a built-in LED backlight
and touch controller.

The init values was taken from the vendor source tree, comments were added to 
the
know values but most of the init table is undocumented.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/panel/Kconfig  |  11 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-khadas-ts050.c | 876 +
 3 files changed, 888 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-khadas-ts050.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index b4e021ea30f9..8fec45b2ce02 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -145,6 +145,17 @@ config DRM_PANEL_JDI_LT070ME05000
  The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
  24 bit per pixel.
 
+config DRM_PANEL_KHADAS_TS050
+   tristate "Khadas TS050 panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Khadas TS050 TFT-LCD
+ panel module. The panel has a 1080x1920 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host, a built-in LED backlight and touch controller.
+
 config DRM_PANEL_KINGDISPLAY_KD097D04
tristate "Kingdisplay kd097d04 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index ebbf488c7eac..03496695e03f 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += 
panel-ilitek-ili9322.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
 obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
+obj-$(CONFIG_DRM_PANEL_KHADAS_TS050) += panel-khadas-ts050.o
 obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
 obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += panel-leadtek-ltk050h3146w.o
 obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
diff --git a/drivers/gpu/drm/panel/panel-khadas-ts050.c 
b/drivers/gpu/drm/panel/panel-khadas-ts050.c
new file mode 100644
index ..856fcad69306
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-khadas-ts050.c
@@ -0,0 +1,876 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 BayLibre, SAS
+ * Author: Neil Armstrong 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct khadas_ts050_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *link;
+
+   struct regulator *supply;
+   struct gpio_desc *reset_gpio;
+   struct gpio_desc *enable_gpio;
+
+   bool prepared;
+   bool enabled;
+};
+
+struct khadas_ts050_panel_cmd {
+   u8 cmd;
+   u8 data;
+};
+
+/* Only the CMD1 User Command set is documented */
+static const struct khadas_ts050_panel_cmd init_code[] = {
+   /* Select Unknown CMD Page (Undocumented) */
+   {0xff, 0xee},
+   /* Reload CMD1: Don't reload default value to register */
+   {0xfb, 0x01},
+   {0x1f, 0x45},
+   {0x24, 0x4f},
+   {0x38, 0xc8},
+   {0x39, 0x27},
+   {0x1e, 0x77},
+   {0x1d, 0x0f},
+   {0x7e, 0x71},
+   {0x7c, 0x03},
+   {0xff, 0x00},
+   {0xfb, 0x01},
+   {0x35, 0x01},
+   /* Select CMD2 Page0 (Undocumented) */
+   {0xff, 0x01},
+   /* Reload CMD1: Don't reload default value to register */
+   {0xfb, 0x01},
+   {0x00, 0x01},
+   {0x01, 0x55},
+   {0x02, 0x40},
+   {0x05, 0x40},
+   {0x06, 0x4a},
+   {0x07, 0x24},
+   {0x08, 0x0c},
+   {0x0b, 0x7d},
+   {0x0c, 0x7d},
+   {0x0e, 0xb0},
+   {0x0f, 0xae},
+   {0x11, 0x10},
+   {0x12, 0x10},
+   {0x13, 0x03},
+   {0x14, 0x4a},
+   {0x15, 0x12},
+   {0x16, 0x12},
+   {0x18, 0x00},
+   {0x19, 0x77},
+   {0x1a, 0x55},
+   {0x1b, 0x13},
+   {0x1c, 0x00},
+   {0x1d, 0x00},
+   {0x1e, 0x13},
+   {0x1f, 0x00},
+   {0x23, 0x00},
+   {0x24, 0x00},
+   {0x25, 0x00},
+   {0x26, 0x00},
+   {0x27, 0x00},
+   {0x28, 0x00},
+   {0x35, 0x00},
+   {0x66, 0x00},
+   {0x58, 0x82},
+   {0x59, 0x02},
+   {0x5a, 0x02},
+   {0x5b, 0x02},
+   {0x5c, 0x82},
+   {0x5d, 0x82},
+   {0x5e, 0x02},
+   {0x5f, 0x02},
+   {0x72, 0x31},
+   /* Select CMD2 Page4 (Undocumented) */
+   {0xff, 0x05},
+   /* Reload CMD1: Don't reload default value to register */
+

Re: [PATCH 2/2] drm: panel: add Khadas TS050 panel driver

[Neil Armstrong]

Hi Sam,

On 23/11/2020 22:05, Sam Ravnborg wrote:
> Hi Neil.
> 
> Looks good but a few comments in the following that needs some attention.
> 
>   Sam
> 
> On Mon, Nov 23, 2020 at 03:33:54PM +0100, Neil Armstrong wrote:
>> This add support for the Khadas TS050 1080x1920 5" LCD DSI panel designed to 
>> work
>> with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.
>> It provides a MIPI DSI interface to the host, a built-in LED backlight
>> and touch controller.
>>
>> The init values was taken from the vendor source tree, comments were added 
>> to the
>> know values but most of the init table is undocumented.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  drivers/gpu/drm/panel/Kconfig  |  11 +
>>  drivers/gpu/drm/panel/Makefile |   1 +
>>  drivers/gpu/drm/panel/panel-khadas-ts050.c | 876 +
>>  3 files changed, 888 insertions(+)
>>  create mode 100644 drivers/gpu/drm/panel/panel-khadas-ts050.c
>>
>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>> index b4e021ea30f9..8fec45b2ce02 100644
>> --- a/drivers/gpu/drm/panel/Kconfig
>> +++ b/drivers/gpu/drm/panel/Kconfig
>> @@ -145,6 +145,17 @@ config DRM_PANEL_JDI_LT070ME05000
>>The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
>>24 bit per pixel.
>>  
>> +config DRM_PANEL_KHADAS_TS050
>> +tristate "Khadas TS050 panel"
>> +depends on OF
>> +depends on DRM_MIPI_DSI
>> +depends on BACKLIGHT_CLASS_DEVICE
>> +help
>> +  Say Y here if you want to enable support for Khadas TS050 TFT-LCD
>> +  panel module. The panel has a 1080x1920 resolution and uses
>> +  24 bit RGB per pixel. It provides a MIPI DSI interface to
>> +  the host, a built-in LED backlight and touch controller.
>> +
>>  config DRM_PANEL_KINGDISPLAY_KD097D04
>>  tristate "Kingdisplay kd097d04 panel"
>>  depends on OF
>> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
>> index ebbf488c7eac..03496695e03f 100644
>> --- a/drivers/gpu/drm/panel/Makefile
>> +++ b/drivers/gpu/drm/panel/Makefile
>> @@ -13,6 +13,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += 
>> panel-ilitek-ili9322.o
>>  obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
>>  obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
>>  obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
>> +obj-$(CONFIG_DRM_PANEL_KHADAS_TS050) += panel-khadas-ts050.o
>>  obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
>>  obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += panel-leadtek-ltk050h3146w.o
>>  obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
>> diff --git a/drivers/gpu/drm/panel/panel-khadas-ts050.c 
>> b/drivers/gpu/drm/panel/panel-khadas-ts050.c
>> new file mode 100644
>> index ..856fcad69306
>> --- /dev/null
>> +++ b/drivers/gpu/drm/panel/panel-khadas-ts050.c
>> @@ -0,0 +1,876 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2020 BayLibre, SAS
>> + * Author: Neil Armstrong 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
> Panels do not use DRM_ or drm_ for logging, so this include is not
> needed.

Ok forgot to remove this

> 
>> +
>> +struct khadas_ts050_panel {
>> +struct drm_panel base;
>> +struct mipi_dsi_device *link;
>> +
>> +struct regulator *supply;
>> +struct gpio_desc *reset_gpio;
>> +struct gpio_desc *enable_gpio;
>> +
>> +bool prepared;
>> +bool enabled;
>> +};
>> +
>> +struct khadas_ts050_panel_cmd {
>> +u8 cmd;
>> +u8 data;
>> +};
>> +
>> +/* Only the CMD1 User Command set is documented */
>> +static const struct khadas_ts050_panel_cmd init_code[] = {
>> +/* Select Unknown CMD Page (Undocumented) */
>> +{0xff, 0xee},
> ...
>> +{0xd4, 0x04}, /* RGBMIPICTRL: VSYNC front porch = 4 */
>> +};
>> +
>> +static inline
>> +struct khadas_ts050_panel *to_khadas_ts050_panel(struct drm_panel *panel)
>> +{
>> +return container_of(panel, struct khadas_ts050_panel, base);
>> +}
>> +
>> +static int khadas_ts050_panel_prepare(

[PATCH v2 0/2] drm: panel: add support for the Khadas TS050 panel

[Neil Armstrong]

This add support & bindings for the Khadas TS050 1080x1920 5" LCD DSI panel 
designed
to work with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.
It provides a MIPI DSI interface to the host, a built-in LED backlight
and touch controller.

Changes since v1:
- removed drm_print include
- added reset_gpio to 1 after prepare failure
- now ignore regulator_disable() on prepare failure
- mark prepared=false whatever the result of the unprepare function errors
- also reset_gpio to 1 on unprepare
- do not return on mipi_dsi_dcs_enter_sleep_mode error on unprepare
- mark enabled=true unconditionnally
- use dev_err_probe in probe()

Neil Armstrong (2):
  dt-bindings: panel-simple-dsi: add Khadas TS050 panel bindings
  drm: panel: add Khadas TS050 panel driver

 .../display/panel/panel-simple-dsi.yaml   |   2 +
 drivers/gpu/drm/panel/Kconfig |  11 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-khadas-ts050.c| 866 ++
 4 files changed, 880 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-khadas-ts050.c

-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/2] dt-bindings: panel-simple-dsi: add Khadas TS050 panel bindings

[Neil Armstrong]

This add the bindings for the Khadas TS050 1080x1920 5" LCD DSI panel designed 
to work
with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.

Signed-off-by: Neil Armstrong 
Reviewed-by: Sam Ravnborg 
---
 .../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
index 72e4b6d4d5e1..fbd71669248f 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
@@ -35,6 +35,8 @@ properties:
   - boe,tv080wum-nl0
 # Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
   - innolux,p079zca
+# Khadas TS050 5" 1080x1920 LCD panel
+  - khadas,ts050
 # Kingdisplay KD097D04 9.7" 1536x2048 TFT LCD panel
   - kingdisplay,kd097d04
 # LG ACX467AKM-7 4.95" 1080×1920 LCD Panel
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/2] drm: panel: add Khadas TS050 panel driver

[Neil Armstrong]

This add support for the Khadas TS050 1080x1920 5" LCD DSI panel designed to 
work
with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.
It provides a MIPI DSI interface to the host, a built-in LED backlight
and touch controller.

The init values was taken from the vendor source tree, comments were added to 
the
know values but most of the init table is undocumented.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/panel/Kconfig  |  11 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-khadas-ts050.c | 866 +
 3 files changed, 878 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-khadas-ts050.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index b4e021ea30f9..8fec45b2ce02 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -145,6 +145,17 @@ config DRM_PANEL_JDI_LT070ME05000
  The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
  24 bit per pixel.
 
+config DRM_PANEL_KHADAS_TS050
+   tristate "Khadas TS050 panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Khadas TS050 TFT-LCD
+ panel module. The panel has a 1080x1920 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host, a built-in LED backlight and touch controller.
+
 config DRM_PANEL_KINGDISPLAY_KD097D04
tristate "Kingdisplay kd097d04 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index ebbf488c7eac..03496695e03f 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += 
panel-ilitek-ili9322.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
 obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
+obj-$(CONFIG_DRM_PANEL_KHADAS_TS050) += panel-khadas-ts050.o
 obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
 obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += panel-leadtek-ltk050h3146w.o
 obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
diff --git a/drivers/gpu/drm/panel/panel-khadas-ts050.c 
b/drivers/gpu/drm/panel/panel-khadas-ts050.c
new file mode 100644
index ..ced48a96ffce
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-khadas-ts050.c
@@ -0,0 +1,866 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 BayLibre, SAS
+ * Author: Neil Armstrong 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct khadas_ts050_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *link;
+
+   struct regulator *supply;
+   struct gpio_desc *reset_gpio;
+   struct gpio_desc *enable_gpio;
+
+   bool prepared;
+   bool enabled;
+};
+
+struct khadas_ts050_panel_cmd {
+   u8 cmd;
+   u8 data;
+};
+
+/* Only the CMD1 User Command set is documented */
+static const struct khadas_ts050_panel_cmd init_code[] = {
+   /* Select Unknown CMD Page (Undocumented) */
+   {0xff, 0xee},
+   /* Reload CMD1: Don't reload default value to register */
+   {0xfb, 0x01},
+   {0x1f, 0x45},
+   {0x24, 0x4f},
+   {0x38, 0xc8},
+   {0x39, 0x27},
+   {0x1e, 0x77},
+   {0x1d, 0x0f},
+   {0x7e, 0x71},
+   {0x7c, 0x03},
+   {0xff, 0x00},
+   {0xfb, 0x01},
+   {0x35, 0x01},
+   /* Select CMD2 Page0 (Undocumented) */
+   {0xff, 0x01},
+   /* Reload CMD1: Don't reload default value to register */
+   {0xfb, 0x01},
+   {0x00, 0x01},
+   {0x01, 0x55},
+   {0x02, 0x40},
+   {0x05, 0x40},
+   {0x06, 0x4a},
+   {0x07, 0x24},
+   {0x08, 0x0c},
+   {0x0b, 0x7d},
+   {0x0c, 0x7d},
+   {0x0e, 0xb0},
+   {0x0f, 0xae},
+   {0x11, 0x10},
+   {0x12, 0x10},
+   {0x13, 0x03},
+   {0x14, 0x4a},
+   {0x15, 0x12},
+   {0x16, 0x12},
+   {0x18, 0x00},
+   {0x19, 0x77},
+   {0x1a, 0x55},
+   {0x1b, 0x13},
+   {0x1c, 0x00},
+   {0x1d, 0x00},
+   {0x1e, 0x13},
+   {0x1f, 0x00},
+   {0x23, 0x00},
+   {0x24, 0x00},
+   {0x25, 0x00},
+   {0x26, 0x00},
+   {0x27, 0x00},
+   {0x28, 0x00},
+   {0x35, 0x00},
+   {0x66, 0x00},
+   {0x58, 0x82},
+   {0x59, 0x02},
+   {0x5a, 0x02},
+   {0x5b, 0x02},
+   {0x5c, 0x82},
+   {0x5d, 0x82},
+   {0x5e, 0x02},
+   {0x5f, 0x02},
+   {0x72, 0x31},
+   /* Select CMD2 Page4 (Undocumented) */
+   {0xff, 0x05},
+   /* Reload CMD1: Don't reload default value to register */
+   {0xfb, 0x01},
+

Re: [PATCH v2 2/2] drm: panel: add Khadas TS050 panel driver

[Neil Armstrong]

Hi,

On 05/12/2020 20:15, Sam Ravnborg wrote:
> Hi Neil,
> 
>> +
>> +static int khadas_ts050_panel_probe(struct mipi_dsi_device *dsi)
>> +{
>> +struct khadas_ts050_panel *khadas_ts050;
>> +int err;
>> +
>> +dsi->lanes = 4;
>> +dsi->format = MIPI_DSI_FMT_RGB888;
>> +dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
>> +  MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_EOT_PACKET;
>> +
>> +khadas_ts050 = devm_kzalloc(&dsi->dev, sizeof(*khadas_ts050),
>> +GFP_KERNEL);
>> +if (!khadas_ts050)
>> +return -ENOMEM;
>> +
>> +mipi_dsi_set_drvdata(dsi, khadas_ts050);
>> +khadas_ts050->link = dsi;
>> +
>> +err = khadas_ts050_panel_add(khadas_ts050);
>> +if (err < 0)
>> +return err;
>> +
>> +return mipi_dsi_attach(dsi);
>> +}
> 
> If mipi_dsi_attach() failes then da a drm_panel_remove() like this:
> 
>   ret = mipi_dsi_attach(dsi);
>   if (ret)
>   drm_panel_remove(&khadas_ts050->base);
> 
>   return ret;
> 
> This is again something several panels gets wrong.
> 
> With this fixed:
> Reviewed-by: Sam Ravnborg 
> 
> I assume you will fix it while applying.

Sure, thanks !

Neil

> 
>   Sam
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/aperture: Pass DRM driver structure instead of driver name

[Neil Armstrong]

Hi,

On 29/06/2021 15:58, Thomas Zimmermann wrote:
> Print the name of the DRM driver when taking over fbdev devices. Makes
> the output to dmesg more consistent. Note that the driver name is only
> used for printing a string to the kernel log. No UAPI is affected by this
> change.
> 
> Signed-off-by: Thomas Zimmermann 
> ---

...

>  drivers/gpu/drm/meson/meson_drv.c |  2 +-

Acked-by: Neil Armstrong 

...

>  
> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
> b/drivers/gpu/drm/meson/meson_drv.c
> index a7388bf7c838..3d0ccc7eef1b 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -285,7 +285,7 @@ static int meson_drv_bind_master(struct device *dev, bool 
> has_components)
>* Remove early framebuffers (ie. simplefb). The framebuffer can be
>* located anywhere in RAM
>*/
> - ret = drm_aperture_remove_framebuffers(false, "meson-drm-fb");
> + ret = drm_aperture_remove_framebuffers(false, &meson_driver);
>   if (ret)
>   goto free_drm;
>  

...

Re: [PATCH] drm/meson: Convert to Linux IRQ interfaces

[Neil Armstrong]

Hi,

Le 06/07/2021 à 09:45, Thomas Zimmermann a écrit :
> Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
> IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
> don't benefit from using it.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/meson/meson_drv.c | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
> b/drivers/gpu/drm/meson/meson_drv.c
> index 3d0ccc7eef1b..bc0d60df04ae 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -21,7 +21,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -94,9 +93,6 @@ DEFINE_DRM_GEM_CMA_FOPS(fops);
>  static const struct drm_driver meson_driver = {
>   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
>  
> - /* IRQ */
> - .irq_handler= meson_irq,
> -
>   /* CMA Ops */
>   DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(meson_dumb_create),
>  
> @@ -335,7 +331,7 @@ static int meson_drv_bind_master(struct device *dev, bool 
> has_components)
>   if (ret)
>   goto free_drm;
>  
> - ret = drm_irq_install(drm, priv->vsync_irq);
> + ret = request_irq(priv->vsync_irq, meson_irq, 0, drm->driver->name, 
> drm);
>   if (ret)
>   goto free_drm;
>  
> @@ -354,7 +350,7 @@ static int meson_drv_bind_master(struct device *dev, bool 
> has_components)
>   return 0;
>  
>  uninstall_irq:
> - drm_irq_uninstall(drm);
> + free_irq(priv->vsync_irq, drm);
>  free_drm:
>   drm_dev_put(drm);
>  
> @@ -382,7 +378,7 @@ static void meson_drv_unbind(struct device *dev)
>   drm_kms_helper_poll_fini(drm);
>   drm_atomic_helper_shutdown(drm);
>   component_unbind_all(dev, drm);
> - drm_irq_uninstall(drm);
> + free_irq(priv->vsync_irq, drm);
>   drm_dev_put(drm);
>  
>   if (priv->afbcd.ops) {
> 

Looks good !

Reviewed-by: Neil Armstrong 

Thanks,
Neil

Re: [PATCH v10 1/6] dt-bindings: display: Add support for Intel KeemBay Display

[Neil Armstrong]

On 03/11/2020 03:02, Rob Herring wrote:
> On Mon, Nov 2, 2020 at 10:38 AM Neil Armstrong  
> wrote:
>>
>> On 02/11/2020 16:16, Rob Herring wrote:
>>> On Fri, Oct 30, 2020 at 4:15 PM Sam Ravnborg  wrote:
>>>>
>>>> Hi Neil.
>>>>
>>>> On Fri, Oct 30, 2020 at 09:31:36AM +0100, Neil Armstrong wrote:
>>>>> Hi,
>>>>>
>>>>> On 29/10/2020 23:20, Sam Ravnborg wrote:
>>>>>> Hi Anitha.
>>>>>>
>>>>>> On Thu, Oct 29, 2020 at 02:27:52PM -0700, Anitha Chrisanthus wrote:
>>>>>>> This patch adds bindings for Intel KeemBay Display
>>>>>>>
>>>>>>> v2: review changes from Rob Herring
>>>>>>> v3: review changes from Sam Ravnborg (removed mipi dsi entries, and
>>>>>>> encoder entry, connect port to dsi)
>>>>>>> MSSCAM is part of the display submodule and its used to reset LCD
>>>>>>> and MIPI DSI clocks, so its best to be on this device tree.
>>>>>>>
>>>>>>> Signed-off-by: Anitha Chrisanthus 
>>>>>>> Cc: Sam Ravnborg 
>>>>>>> Cc: Thomas Zimmermann 
>>>>>>> Cc: Daniel Vetter 
>>>>>>
>>>>>> Looks good - and the split betwwen the display and the mipi<->dsi parts
>>>>>> matches the understanding of the HW I have developed.
>>>>>>
>>>>>> Reviewed-by: Sam Ravnborg 
>>>>>>
>>>>>>> ---
>>>>>>>  .../bindings/display/intel,keembay-display.yaml| 75 
>>>>>>> ++
>>>>>>>  1 file changed, 75 insertions(+)
>>>>>>>  create mode 100644 
>>>>>>> Documentation/devicetree/bindings/display/intel,keembay-display.yaml
>>>>>>>
>>>>>>> diff --git 
>>>>>>> a/Documentation/devicetree/bindings/display/intel,keembay-display.yaml 
>>>>>>> b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
>>>>>>> new file mode 100644
>>>>>>> index 000..8a8effe
>>>>>>> --- /dev/null
>>>>>>> +++ 
>>>>>>> b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
>>>>>>> @@ -0,0 +1,75 @@
>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>>> +%YAML 1.2
>>>>>>> +---
>>>>>>> +$id: http://devicetree.org/schemas/display/intel,keembay-display.yaml#
>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>> +
>>>>>>> +title: Devicetree bindings for Intel Keem Bay display controller
>>>>>>> +
>>>>>>> +maintainers:
>>>>>>> +  - Anitha Chrisanthus 
>>>>>>> +  - Edmond J Dea 
>>>>>>> +
>>>>>>> +properties:
>>>>>>> +  compatible:
>>>>>>> +const: intel,keembay-display
>>>>>>> +
>>>>>>> +  reg:
>>>>>>> +items:
>>>>>>> +  - description: LCD registers range
>>>>>>> +  - description: Msscam registers range
>>>>>>> +
>>>>>
>>>>> Indeed the split is much better, but as you replied on 
>>>>> http://lore.kernel.org/r/by5pr11mb41827de07436dd0454e24e6e8c...@by5pr11mb4182.namprd11.prod.outlook.com
>>>>> the msscam seems to be shared with the camera subsystem block, if this is 
>>>>> the case it should be handled.
>>>>>
>>>>> If it's a shared register block, it could be defined as a "syscon" used 
>>>>> by both subsystems.
>>>>
>>>> I think I got it now.
>>>>
>>>> msscam is used to enable clocks both for the display driver and the
>>>> mipi-dsi part.
>>>
>>> If just clocks, then the msscam should be a clock provider possibly.
>>> If not, then the below looks right.
>>
>> I agree
>>
>>>
>>>>
>>>> So it should be pulled in to a dedicated node - for example like this:
>>>>
>>>> mssscam: msscam@2091 {
>>>> compatible = "intel,keembay-msscam", "syscon";
>>>> reg = <0x2091, 0x30>;
>>>> reg-io-width = <4>;
>>>> };
>>>>
>>>> And ofc we need a binding file for that.
>>>>
>>>>
>>>> And then we could have code like this in the display driver:
>>>> regmap *msscam = 
>>>> syscon_regmap_lookup_by_compatible("intel,keembay-msscam");
>>>> if (IS_ERR(msscam))
>>>> tell-and goto-out;
>>
>> It's better to use a phandle in the display node, instead of looking for 
>> compatible nodes.
> 
> No, you don't need it in DT unless there's more than one instance or
> other parameters needed like register offsets/masks. The above is
> actually faster too walking a list rather than a phandle look up
> (though the phandle cache now may make it faster).

A phandle makes the dependency explicit, anyway it's only an advice.

Neil

> 
> Rob
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v10 1/6] dt-bindings: display: Add support for Intel KeemBay Display

[Neil Armstrong]

On 02/11/2020 19:04, Sam Ravnborg wrote:
> Hi Neil.
> 
>>> ---
>>>  .../bindings/display/intel,keembay-display.yaml| 75 
>>> ++
>>>  1 file changed, 75 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/display/intel,keembay-display.yaml
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/display/intel,keembay-display.yaml 
>>> b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
>>> new file mode 100644
>>> index 000..8a8effe
>>> --- /dev/null
>>> +++ 
>>> b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
>>> @@ -0,0 +1,75 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/display/intel,keembay-display.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Devicetree bindings for Intel Keem Bay display controller
>>> +
>>> +maintainers:
>>> +  - Anitha Chrisanthus 
>>> +  - Edmond J Dea 
>>> +
>>> +properties:
>>> +  compatible:
>>> +const: intel,keembay-display
>>> +
>>> +  reg:
>>> +items:
>>> +  - description: LCD registers range
>>> +  - description: Msscam registers range
>>> +
>
> Indeed the split is much better, but as you replied on 
> http://lore.kernel.org/r/by5pr11mb41827de07436dd0454e24e6e8c...@by5pr11mb4182.namprd11.prod.outlook.com
> the msscam seems to be shared with the camera subsystem block, if this is 
> the case it should be handled.
>
> If it's a shared register block, it could be defined as a "syscon" used 
> by both subsystems.

 I think I got it now.

 msscam is used to enable clocks both for the display driver and the
 mipi-dsi part.
>>>
>>> If just clocks, then the msscam should be a clock provider possibly.
>>> If not, then the below looks right.
> 
> I am feeling a little clueless here - sorry.
> 
> Can you help with any example that does this?
> 
> Everything I looked up in bindings/clock/ had a "#clock-cells" which is
> not relevant for msscam - or so I think at least.

Looking at the code make it clear it's not relevant to implement it as clock 
controller.

The syscon is enough.

Neil

> 
> 
>   Sam
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 17/40] drm/meson/meson_vclk: Make two local functions static

[Neil Armstrong]

On 13/11/2020 14:49, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/meson/meson_vclk.c:134:6: warning: no previous prototype for 
> ‘meson_vid_pll_set’ [-Wmissing-prototypes]
>  drivers/gpu/drm/meson/meson_vclk.c:490:6: warning: no previous prototype for 
> ‘meson_hdmi_pll_set_params’ [-Wmissing-prototypes]
> 
> Cc: Neil Armstrong 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Kevin Hilman 
> Cc: Jerome Brunet 
> Cc: Martin Blumenstingl 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/meson/meson_vclk.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_vclk.c 
> b/drivers/gpu/drm/meson/meson_vclk.c
> index 0eb86943a3588..2a82119eb58ed 100644
> --- a/drivers/gpu/drm/meson/meson_vclk.c
> +++ b/drivers/gpu/drm/meson/meson_vclk.c
> @@ -131,7 +131,7 @@ enum {
>   VID_PLL_DIV_15,
>  };
>  
> -void meson_vid_pll_set(struct meson_drm *priv, unsigned int div)
> +static void meson_vid_pll_set(struct meson_drm *priv, unsigned int div)
>  {
>   unsigned int shift_val = 0;
>   unsigned int shift_sel = 0;
> @@ -487,9 +487,9 @@ static inline unsigned int pll_od_to_reg(unsigned int od)
>   return 0;
>  }
>  
> -void meson_hdmi_pll_set_params(struct meson_drm *priv, unsigned int m,
> -unsigned int frac, unsigned int od1,
> -unsigned int od2, unsigned int od3)
> +static void meson_hdmi_pll_set_params(struct meson_drm *priv, unsigned int m,
> +   unsigned int frac, unsigned int od1,
> +   unsigned int od2, unsigned int od3)
>  {
>   unsigned int val;
>  
> 

Reviewed-by: Neil Armstrong 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 14/40] drm/meson/meson_venc: Make local function 'meson_venc_hdmi_get_dmt_vmode' static

[Neil Armstrong]

On 13/11/2020 14:49, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/meson/meson_venc.c:893:6: warning: no previous prototype for 
> ‘meson_venc_hdmi_get_dmt_vmode’ [-Wmissing-prototypes]
> 
> Cc: Neil Armstrong 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Kevin Hilman 
> Cc: Jerome Brunet 
> Cc: Martin Blumenstingl 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/meson/meson_venc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_venc.c 
> b/drivers/gpu/drm/meson/meson_venc.c
> index f93c725b6f02d..5e2236ec189fa 100644
> --- a/drivers/gpu/drm/meson/meson_venc.c
> +++ b/drivers/gpu/drm/meson/meson_venc.c
> @@ -890,8 +890,8 @@ bool meson_venc_hdmi_supported_vic(int vic)
>  }
>  EXPORT_SYMBOL_GPL(meson_venc_hdmi_supported_vic);
>  
> -void meson_venc_hdmi_get_dmt_vmode(const struct drm_display_mode *mode,
> -union meson_hdmi_venc_mode *dmt_mode)
> +static void meson_venc_hdmi_get_dmt_vmode(const struct drm_display_mode 
> *mode,
> +   union meson_hdmi_venc_mode *dmt_mode)
>  {
>   memset(dmt_mode, 0, sizeof(*dmt_mode));
>  
> 

Reviewed-by: Neil Armstrong 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] drm/meson: Module removal fixes

[Neil Armstrong]

Hi Marc,

On 16/11/2020 21:07, Marc Zyngier wrote:
> Hi all,
> 
> Having recently moved over to a top-of-the-tree u-boot on one of my
> VIM3L systems in order to benefit from unrelated improvements
> (automatic PCIe detection, EFI...), I faced the issue that my kernel
> would hang like this:
> 
> [  OK  ] Finished Helper to synchronize boot up for ifupdown.
> [  OK  ] Started Rule-based Manager for Device Events and Files.
> [7.114516] VDDCPU: supplied by regulator-dummy
> [  OK  ] Found device /dev/ttyAML0.
> [7.146862] meson-drm ff90.vpu: Queued 2 outputs on vpu
> [7.169630] fb0: switching to meson-drm-fb from simple
> [7.169944] Console: switching to colour dummy device 80x25
> [7.179250] meson-drm ff90.vpu: CVBS Output connector not available
> 
> and that's it.
> 
> After some poking around, I figured out that it is in the
> meson-dw-hdmi module that the CPU was hanging...

I'll be interested in having your kernel config, I never had such report
since I enabled HDMI support in U-Boot a few years ago.

> 
> Reverting to the kernel DT instead of u-boot's papered over it
> somehow, but it turned out that removing the module (modprobe -r)
> resulted in a firework. And for every issue I was fixing, another
> followed. Much fun for a rainy Monday in the basement!
> 
> I ended up with the following 4 patches, which solve all my problems:
> I can now boot with the u-boot provided DT, and the hdmi and DRM
> drivers can be removed and re-inserted at will.
> 
> The first patch is a straightforward use-after-free, causing a NULL
> pointer dereference. Moving things around fixes it.
> 
> The second patch shows that I have no clue about the DRM subsystem
> whatsoever. I mimicked what my Rockchip systems are doing, and the two
> warnings disappeared. It can't completely be wrong (famous last
> words...).
> 
> The third patch fixes a *very* common issue with regulators (I've
> fixed at least 3 drivers with a similar issue). I guess the devm
> subsystem needs to grow a new helper at some point.
> 
> The last patch finally fixes the issue I was seeing: the HDMI driver
> hangs when accessing a register with clocks disabled, which they are
> on module removal. It also fixes my u-boot booting for similar
> reasons, I guess.

Anyway, thanks for fixing this !

> 
> I went as far as reaching out for a HDMI cable and verifying that I
> was getting a working display. Total dedication.

This is very appreciated :-)

> 
> Feedback much appreciated.
> 
>   M.
> 
> Marc Zyngier (4):
>   drm/meson: Free RDMA resources after tearing down DRM
>   drm/meson: Unbind all connectors on module removal
>   drm/meson: dw-hdmi: Register a callback to disable the regulator
>   drm/meson: dw-hdmi: Ensure that clocks are enabled before touching the
> TOP registers
> 
>  drivers/gpu/drm/meson/meson_drv.c | 12 +++-
>  drivers/gpu/drm/meson/meson_dw_hdmi.c | 13 +++--
>  2 files changed, 18 insertions(+), 7 deletions(-)
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/meson: Free RDMA resources after tearing down DRM

[Neil Armstrong]

On 16/11/2020 21:07, Marc Zyngier wrote:
> Removing the meson DRM module results in the following splat:
> 
> [ 2179.451346] Hardware name:  , BIOS 2021.01-rc2-00012-gde865f7ee1 11/16/2020
> [ 2179.458316] Workqueue: events drm_mode_rmfb_work_fn [drm]
> [ 2179.463597] pstate: 80c9 (Nzcv daif +PAN +UAO -TCO BTYPE=--)
> [ 2179.469558] pc : meson_rdma_writel_sync+0x44/0xb0 [meson_drm]
> [ 2179.475243] lr : meson_g12a_afbcd_reset+0x34/0x60 [meson_drm]
> [ 2179.480930] sp : ffc01212bb70
> [ 2179.484207] x29: ffc01212bb70 x28: ff8044f66f00
> [ 2179.489469] x27: ff8045b13800 x26: 0001
> [ 2179.494730] x25:  x24: 0001
> [ 2179.41] x23:  x22: 
> [ 2179.505252] x21: 0028 x20: 1a01
> [ 2179.510513] x19: ff8046029480 x18: 
> [ 2179.515775] x17:  x16: 
> [ 2179.521036] x15:  x14: 
> [ 2179.526297] x13: 00400326 x12: 0309030303260300
> [ 2179.531558] x11: 0300054004a0 x10: 0418054004000400
> [ 2179.536820] x9 : ffc008fe4914 x8 : ff8040a1adc0
> [ 2179.542081] x7 :  x6 : ff8042aa0080
> [ 2179.547342] x5 : ff8044f66f00 x4 : ffc008fe5bc8
> [ 2179.552603] x3 : 00010101 x2 : 0001
> [ 2179.557865] x1 :  x0 : 
> [ 2179.563127] Call trace:
> [ 2179.565548]  meson_rdma_writel_sync+0x44/0xb0 [meson_drm]
> [ 2179.570894]  meson_g12a_afbcd_reset+0x34/0x60 [meson_drm]
> [ 2179.576241]  meson_plane_atomic_disable+0x38/0xb0 [meson_drm]
> [ 2179.581966]  drm_atomic_helper_commit_planes+0x1e0/0x21c [drm_kms_helper]
> [ 2179.588684]  drm_atomic_helper_commit_tail_rpm+0x68/0xb0 [drm_kms_helper]
> [ 2179.595410]  commit_tail+0xac/0x190 [drm_kms_helper]
> [ 2179.600326]  drm_atomic_helper_commit+0x16c/0x390 [drm_kms_helper]
> [ 2179.606484]  drm_atomic_commit+0x58/0x70 [drm]
> [ 2179.610880]  drm_framebuffer_remove+0x398/0x434 [drm]
> [ 2179.615881]  drm_mode_rmfb_work_fn+0x68/0x8c [drm]
> [ 2179.620575]  process_one_work+0x1cc/0x49c
> [ 2179.624538]  worker_thread+0x200/0x444
> [ 2179.628246]  kthread+0x14c/0x160
> [ 2179.631439]  ret_from_fork+0x10/0x38
> 
> caused by the fact that the RDMA buffer has already been freed,
> resulting in meson_rdma_writel_sync() getting a NULL pointer.
> 
> Move the afbcd reset and meson_rdma_free calls after the DRM
> unregistration is complete so that the teardown can safely complete.
> 
> Signed-off-by: Marc Zyngier 

Fixes: d1b5e41e13a7 ("drm/meson: Add AFBCD module driver")

> ---
>  drivers/gpu/drm/meson/meson_drv.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
> b/drivers/gpu/drm/meson/meson_drv.c
> index 8b9c8dd788c4..324fa489f1c4 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -389,15 +389,15 @@ static void meson_drv_unbind(struct device *dev)
>   meson_canvas_free(priv->canvas, priv->canvas_id_vd1_2);
>   }
>  
> - if (priv->afbcd.ops) {
> - priv->afbcd.ops->reset(priv);
> - meson_rdma_free(priv);
> - }
> -
>   drm_dev_unregister(drm);
>   drm_irq_uninstall(drm);
>   drm_kms_helper_poll_fini(drm);
>   drm_dev_put(drm);
> +
> + if (priv->afbcd.ops) {
> + priv->afbcd.ops->reset(priv);
> + meson_rdma_free(priv);
> + }
>  }
>  
>  static const struct component_master_ops meson_drv_master_ops = {
> 

Acked-by: Neil Armstrong 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/4] drm/meson: Unbind all connectors on module removal

[Neil Armstrong]

On 16/11/2020 21:07, Marc Zyngier wrote:
> Removing the meson DRM module results in the following splats:
> 
> [   42.689228] WARNING: CPU: 0 PID: 572 at drivers/gpu/drm/drm_irq.c:192 
> drm_irq_uninstall+0x130/0x160 [drm]
> [...]
> [   42.812820] Hardware name:  , BIOS 2021.01-rc2-00012-gde865f7ee1 11/16/2020
> [   42.819723] pstate: 80400089 (Nzcv daIf +PAN -UAO -TCO BTYPE=--)
> [   42.825737] pc : drm_irq_uninstall+0x130/0x160 [drm]
> [   42.830647] lr : drm_irq_uninstall+0xc4/0x160 [drm]
> [...]
> [   42.917614] Call trace:
> [   42.920086]  drm_irq_uninstall+0x130/0x160 [drm]
> [   42.924612]  meson_drv_unbind+0x68/0xa4 [meson_drm]
> [   42.929436]  component_del+0xc0/0x180
> [   42.933058]  meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi]
> [   42.938576]  platform_drv_remove+0x38/0x60
> [   42.942628]  __device_release_driver+0x190/0x23c
> [   42.947198]  driver_detach+0xcc/0x160
> [   42.950822]  bus_remove_driver+0x68/0xe0
> [   42.954702]  driver_unregister+0x3c/0x6c
> [   42.958583]  platform_driver_unregister+0x20/0x2c
> [   42.963243]  meson_dw_hdmi_platform_driver_exit+0x18/0x4a8 [meson_dw_hdmi]
> [   42.970057]  __arm64_sys_delete_module+0x1bc/0x294
> [   42.974801]  el0_svc_common.constprop.0+0x80/0x240
> [   42.979542]  do_el0_svc+0x30/0xa0
> [   42.982821]  el0_svc+0x18/0x50
> [   42.985839]  el0_sync_handler+0x198/0x404
> [   42.989806]  el0_sync+0x158/0x180
> 
> immediatelly followed by
> 
> [   43.002296] WARNING: CPU: 0 PID: 572 at 
> drivers/gpu/drm/drm_mode_config.c:504 drm_mode_config_cleanup+0x2a8/0x304 
> [drm]
> [...]
> [   43.128150] Hardware name:  , BIOS 2021.01-rc2-00012-gde865f7ee1 11/16/2020
> [   43.135052] pstate: 8049 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
> [   43.141062] pc : drm_mode_config_cleanup+0x2a8/0x304 [drm]
> [   43.146492] lr : drm_mode_config_cleanup+0xac/0x304 [drm]
> [...]
> [   43.233979] Call trace:
> [   43.236451]  drm_mode_config_cleanup+0x2a8/0x304 [drm]
> [   43.241538]  drm_mode_config_init_release+0x1c/0x2c [drm]
> [   43.246886]  drm_managed_release+0xa8/0x120 [drm]
> [   43.251543]  drm_dev_put+0x94/0xc0 [drm]
> [   43.255380]  meson_drv_unbind+0x78/0xa4 [meson_drm]
> [   43.260204]  component_del+0xc0/0x180
> [   43.263829]  meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi]
> [   43.269344]  platform_drv_remove+0x38/0x60
> [   43.273398]  __device_release_driver+0x190/0x23c
> [   43.277967]  driver_detach+0xcc/0x160
> [   43.281590]  bus_remove_driver+0x68/0xe0
> [   43.285471]  driver_unregister+0x3c/0x6c
> [   43.289352]  platform_driver_unregister+0x20/0x2c
> [   43.294011]  meson_dw_hdmi_platform_driver_exit+0x18/0x4a8 [meson_dw_hdmi]
> [   43.300826]  __arm64_sys_delete_module+0x1bc/0x294
> [   43.305570]  el0_svc_common.constprop.0+0x80/0x240
> [   43.310312]  do_el0_svc+0x30/0xa0
> [   43.313590]  el0_svc+0x18/0x50
> [   43.316608]  el0_sync_handler+0x198/0x404
> [   43.320574]  el0_sync+0x158/0x180
> [   43.323852] ---[ end trace d796a3072dab01da ]---
> [   43.328561] [drm:drm_mode_config_cleanup [drm]] *ERROR* connector HDMI-A-1 
> leaked!
> 
> both triggered by the fact that the HDMI subsystem is still active,
> and the DRM removal doesn't result in the connectors being torn down.
> 
> Call drm_atomic_helper_shutdown() and component_unbind_all() to safely
> tear the module down.
> 
> Signed-off-by: Marc Zyngier 

Fixes: 2d8f92897ad8 ("drm/meson: Uninstall IRQ handler")

> ---
>  drivers/gpu/drm/meson/meson_drv.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
> b/drivers/gpu/drm/meson/meson_drv.c
> index 324fa489f1c4..3d1de9cbb1c8 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -390,8 +390,10 @@ static void meson_drv_unbind(struct device *dev)
>   }
>  
>   drm_dev_unregister(drm);
> - drm_irq_uninstall(drm);
>   drm_kms_helper_poll_fini(drm);
> + drm_atomic_helper_shutdown(drm);
> + component_unbind_all(dev, drm);
> + drm_irq_uninstall(drm);
>   drm_dev_put(drm);
>  
>   if (priv->afbcd.ops) {
> 

Acked-by: Neil Armstrong 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/4] drm/meson: dw-hdmi: Register a callback to disable the regulator

[Neil Armstrong]

On 16/11/2020 21:07, Marc Zyngier wrote:
> Removing the meson-dw-hdmi module results in the following splat:
> 
> i[   43.340509] WARNING: CPU: 0 PID: 572 at drivers/regulator/core.c:2125 
> _regulator_put.part.0+0x16c/0x174
> [...]
> [   43.454870] CPU: 0 PID: 572 Comm: modprobe Tainted: GW   E 
> 5.10.0-rc4-00049-gd274813a4de3-dirty #2147
> [   43.465042] Hardware name:  , BIOS 2021.01-rc2-00012-gde865f7ee1 11/16/2020
> [   43.471945] pstate: 8049 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
> [   43.477896] pc : _regulator_put.part.0+0x16c/0x174
> [   43.482638] lr : regulator_put+0x44/0x60
> [...]
> [   43.568715] Call trace:
> [   43.571132]  _regulator_put.part.0+0x16c/0x174
> [   43.575529]  regulator_put+0x44/0x60
> [   43.579067]  devm_regulator_release+0x20/0x2c
> [   43.583380]  release_nodes+0x1c8/0x2b4
> [   43.587087]  devres_release_all+0x44/0x6c
> [   43.591056]  __device_release_driver+0x1a0/0x23c
> [   43.595626]  driver_detach+0xcc/0x160
> [   43.599249]  bus_remove_driver+0x68/0xe0
> [   43.603130]  driver_unregister+0x3c/0x6c
> [   43.607011]  platform_driver_unregister+0x20/0x2c
> [   43.611678]  meson_dw_hdmi_platform_driver_exit+0x18/0x4a8 [meson_dw_hdmi]
> [   43.618485]  __arm64_sys_delete_module+0x1bc/0x294
> 
> as the HDMI regulator is still enabled on release.
> 
> In order to address this, register a callback that will deal with
> the disabling when the driver is unbound, solving the problem.
> 
> Signed-off-by: Marc Zyngier 

Fixes: 161a803fe32d ("drm/meson: dw_hdmi: Add support for an optional external 
5V regulator")

> ---
>  drivers/gpu/drm/meson/meson_dw_hdmi.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 29a8ff41595d..68826cf9993f 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -941,6 +941,11 @@ static void meson_dw_hdmi_init(struct meson_dw_hdmi 
> *meson_dw_hdmi)
>  
>  }
>  
> +static void meson_disable_regulator(void *data)
> +{
> + regulator_disable(data);
> +}
> +
>  static int meson_dw_hdmi_bind(struct device *dev, struct device *master,
>   void *data)
>  {
> @@ -989,6 +994,10 @@ static int meson_dw_hdmi_bind(struct device *dev, struct 
> device *master,
>   ret = regulator_enable(meson_dw_hdmi->hdmi_supply);
>   if (ret)
>   return ret;
> + ret = devm_add_action_or_reset(dev, meson_disable_regulator,
> +meson_dw_hdmi->hdmi_supply);
> + if (ret)
> + return ret;
>   }
>  
>   meson_dw_hdmi->hdmitx_apb = devm_reset_control_get_exclusive(dev,
> 

Acked-by: Neil Armstrong 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] drm/meson: dw-hdmi: Ensure that clocks are enabled before touching the TOP registers

[Neil Armstrong]

On 16/11/2020 21:07, Marc Zyngier wrote:
> Removing the meson-dw-hdmi module and re-inserting it results in a hang
> as the driver writes to HDMITX_TOP_SW_RESET. Similar effects can be seen
> when booting with mainline u-boot and using the u-boot provided DT (which
> is highly desirable).
> 
> The reason for the hang seem to be that the clocks are not always
> enabled by the time we enter meson_dw_hdmi_init(). Moving this call
> *after* dw_hdmi_probe() ensures that the clocks are enabled.
> 
> Signed-off-by: Marc Zyngier 

Fixes: 1374b8375c2e ("drm/meson: dw_hdmi: add resume/suspend hooks")

> ---
>  drivers/gpu/drm/meson/meson_dw_hdmi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 68826cf9993f..7f8eea494147 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -1073,8 +1073,6 @@ static int meson_dw_hdmi_bind(struct device *dev, 
> struct device *master,
>  
>   DRM_DEBUG_DRIVER("encoder initialized\n");
>  
> - meson_dw_hdmi_init(meson_dw_hdmi);
> -
>   /* Bridge / Connector */
>  
>   dw_plat_data->priv_data = meson_dw_hdmi;
> @@ -1097,6 +1095,8 @@ static int meson_dw_hdmi_bind(struct device *dev, 
> struct device *master,
>   if (IS_ERR(meson_dw_hdmi->hdmi))
>   return PTR_ERR(meson_dw_hdmi->hdmi);
>  
> + meson_dw_hdmi_init(meson_dw_hdmi);
> +
>   next_bridge = of_drm_find_bridge(pdev->dev.of_node);
>   if (next_bridge)
>   drm_bridge_attach(encoder, next_bridge,
> 

Acked-by: Neil Armstrong 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] drm/meson: Module removal fixes

[Neil Armstrong]

On 17/11/2020 10:19, Marc Zyngier wrote:
> Hi Neil,
> 
> On 2020-11-17 08:49, Neil Armstrong wrote:
>> Hi Marc,
>>
>> On 16/11/2020 21:07, Marc Zyngier wrote:
>>> Hi all,
>>>
>>> Having recently moved over to a top-of-the-tree u-boot on one of my
>>> VIM3L systems in order to benefit from unrelated improvements
>>> (automatic PCIe detection, EFI...), I faced the issue that my kernel
>>> would hang like this:
>>>
>>> [  OK  ] Finished Helper to synchronize boot up for ifupdown.
>>> [  OK  ] Started Rule-based Manager for Device Events and Files.
>>> [    7.114516] VDDCPU: supplied by regulator-dummy
>>> [  OK  ] Found device /dev/ttyAML0.
>>> [    7.146862] meson-drm ff90.vpu: Queued 2 outputs on vpu
>>> [    7.169630] fb0: switching to meson-drm-fb from simple
>>> [    7.169944] Console: switching to colour dummy device 80x25
>>> [    7.179250] meson-drm ff90.vpu: CVBS Output connector not available
>>>
>>> and that's it.
>>>
>>> After some poking around, I figured out that it is in the
>>> meson-dw-hdmi module that the CPU was hanging...
>>
>> I'll be interested in having your kernel config, I never had such report
>> since I enabled HDMI support in U-Boot a few years ago.
> 
> Yeah, I was pretty surprised too. I have a hunch that this is caused
> by u-boot DT exposing an extra MMIO region (dubbed "hhi") that gets
> picked up by the kernel driver. *Not* having the region in the DT
> (as in the kernel's version of the same DT) makes the driver work
> exactly once:

Yeah, we used this to simplify our u-boot driver, the bindings were missing this
memory space, it should be fixed at some point and stop relying on the
main drm driver to get this memory space.

> 
> Decompiled u-boot DT:
> 
>     hdmi-tx@0 {
>     compatible = "amlogic,meson-g12a-dw-hdmi";
>     reg = <0x00 0x00 0x00 0x1 0x00 0x3c000 0x00 0x1000>;
>     [...]
>     reg-names = "hdmitx\0hhi";
> 
> Decompiled kernel DT:
> 
>     hdmi-tx@0 {
>     compatible = "amlogic,meson-g12a-dw-hdmi";
>     reg = <0x00 0x00 0x00 0x1>;
> 
> There seem to be some complex interactions between the HDMI driver
> and the DRM driver, both using this MMIO region at any given time.
> But I admit not having tried very hard to follow the DRM maze of
> intricate callbacks. All I needed was this box to reliably boot with
> the firmware-provided DT.

Yes, the HDMI stuff has some dependencies on the DRM display subsystem.
I plan to reorganize stuff but I lack time...

Anyway, thanks.

Applying to drm-misc-next

Neil

> 
> You can find a reasonably recent version of my config at [1].
> 
>     M.
> 
> [1] http://www.loen.fr/tmp/Config.full-arm64

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: next/master bisection: baseline.dmesg.emerg on meson-gxbb-p200

[Neil Armstrong]

On 19/11/2020 11:20, Marc Zyngier wrote:
> On 2020-11-19 08:50, Guillaume Tucker wrote:
>> Please see the automated bisection report below about some kernel
>> errors on meson-gxbb-p200.
>>
>> Reports aren't automatically sent to the public while we're
>> trialing new bisection features on kernelci.org, however this one
>> looks valid.
>>
>> The bisection started with next-20201118 but the errors are still
>> present in next-20201119.  Details for this regression:
>>
>>   https://kernelci.org/test/case/id/5fb6196bfd0127fd68d8d902/
>>
>> The first error is:
>>
>>   [   14.757489] Internal error: synchronous external abort: 96000210
>> [#1] PREEMPT SMP
> 
> Looks like yet another clock ordering setup. I guess different Amlogic
> platforms have slightly different ordering requirements.
> 
> Neil, do you have any idea of which platform requires which ordering?
> The variability in DT and platforms is pretty difficult to follow (and
> I don't think I have such board around).

The requirements should be the same, here the init was done before calling
dw_hdmi_probe to be sure the clocks and internals resets were deasserted.
But since you boot from u-boot already enabling these, it's already active.

The solution would be to revert and do some check in meson_dw_hdmi_init() to
check if already enabled and do nothing.

Neil

> 
> Thanks,
> 
>     M.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: next/master bisection: baseline.dmesg.emerg on meson-gxbb-p200

[Neil Armstrong]

On 19/11/2020 19:35, Marc Zyngier wrote:
> On 2020-11-19 18:13, Jerome Brunet wrote:
>> On Thu 19 Nov 2020 at 19:04, Guillaume Tucker
>>  wrote:
>>
>>> Hi Marc,
>>>
>>> On 19/11/2020 11:58, Marc Zyngier wrote:
>>>> On 2020-11-19 10:26, Neil Armstrong wrote:
>>>>> On 19/11/2020 11:20, Marc Zyngier wrote:
>>>>>> On 2020-11-19 08:50, Guillaume Tucker wrote:
>>>>>>> Please see the automated bisection report below about some kernel
>>>>>>> errors on meson-gxbb-p200.
>>>>>>>
>>>>>>> Reports aren't automatically sent to the public while we're
>>>>>>> trialing new bisection features on kernelci.org, however this one
>>>>>>> looks valid.
>>>>>>>
>>>>>>> The bisection started with next-20201118 but the errors are still
>>>>>>> present in next-20201119.  Details for this regression:
>>>>>>>
>>>>>>>   https://kernelci.org/test/case/id/5fb6196bfd0127fd68d8d902/
>>>>>>>
>>>>>>> The first error is:
>>>>>>>
>>>>>>>   [   14.757489] Internal error: synchronous external abort: 96000210
>>>>>>> [#1] PREEMPT SMP
>>>>>>
>>>>>> Looks like yet another clock ordering setup. I guess different Amlogic
>>>>>> platforms have slightly different ordering requirements.
>>>>>>
>>>>>> Neil, do you have any idea of which platform requires which ordering?
>>>>>> The variability in DT and platforms is pretty difficult to follow (and
>>>>>> I don't think I have such board around).
>>>>>
>>>>> The requirements should be the same, here the init was done before calling
>>>>> dw_hdmi_probe to be sure the clocks and internals resets were deasserted.
>>>>> But since you boot from u-boot already enabling these, it's already 
>>>>> active.
>>>>>
>>>>> The solution would be to revert and do some check in meson_dw_hdmi_init() 
>>>>> to
>>>>> check if already enabled and do nothing.
>>>>
>>>> A better fix seems to be this, which makes it explicit that there is
>>>> a dependency between some of the registers accessed from 
>>>> meson_dw_hdmi_init()
>>>> and the iahb clock.
>>>>
>>>> Guillaume, can you give this a go on your failing box?
>>>
>>> I confirm it solves the problem.  Please add this to your fix
>>> patch if it's OK with you:
>>>
>>>   Reported-by: "kernelci.org bot" 
>>>   Tested-by: Guillaume Tucker 
>>>
>>>
>>> For the record, it passed all the tests when applied on top of
>>> the "bad" revision found by the bisection:
>>>
>>>   
>>> http://lava.baylibre.com:10080/scheduler/alljobs?search=v5.10-rc3-1021-gb8668a2e5ea1
>>>
>>> and the exact same test on the "bad" revision without the fix
>>> consistently showed the error:
>>>
>>>   http://lava.baylibre.com:10080/scheduler/job/374176
>>>
>>>
>>> Thanks,
>>> Guillaume
>>>
>>>
>>>> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
>>>> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
>>>> index 7f8eea494147..52af8ba94311 100644
>>>> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
>>>> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
>>>> @@ -146,6 +146,7 @@ struct meson_dw_hdmi {
>>>>  struct reset_control *hdmitx_ctrl;
>>>>  struct reset_control *hdmitx_phy;
>>>>  struct clk *hdmi_pclk;
>>>> +    struct clk *iahb_clk;
>>>>  struct clk *venci_clk;
>>>>  struct regulator *hdmi_supply;
>>>>  u32 irq_stat;
>>>> @@ -1033,6 +1034,13 @@ static int meson_dw_hdmi_bind(struct device *dev, 
>>>> struct device *master,
>>>>  }
>>>>  clk_prepare_enable(meson_dw_hdmi->hdmi_pclk);
>>>>
>>>> +    meson_dw_hdmi->iahb_clk = devm_clk_get(dev, "iahb");
>>>> +    if (IS_ERR(meson_dw_hdmi->iahb_clk)) {
>>>> +    dev_err(dev, "Unable to get iahb clk\n");
>>>> +    return PTR_ERR(meson_dw_hdmi->iahb_clk);
>>>> +    }
>>>> +    clk_prepare_enable(meson_dw_hdmi->iahb_clk);


On previous SoCs, iahb was directly the bus clock (clk81), and on recent socs
this clock is a gate.

The question is why is it disabled. Maybe a previous failed probe disabled it
in the dw-hdmi probe failure code and this clock is needed for 
meson_dw_hdmi_init(),
so yeah this is the right fix.

Thanks.

Could you send a revert of b33340e33acdfe5ca6a5aa1244709575ae1e0432 and then 
proper fix with clk_disable_unprepare added ?

>>
>> If you guys are going ahead with this fix, this call to
>> clk_prepare_enable() needs to be balanced with clk_disable_unprepare() 
>> somehow
> 
> Yup, good point.
> 
> Although this driver *never* disables any clock it enables, and leaves it
> to the main DW driver, which I guess makes it leak references.
> 
> So all 3 clocks need fixing.

Exact.

Thx Guillaume for testing,

Neil

> 
> Thanks,
> 
>     M.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/meson: dw-hdmi: Enable the iahb clock early enough

[Neil Armstrong]

On 20/11/2020 12:10, Marc Zyngier wrote:
> On 2020-11-20 10:54, Guillaume Tucker wrote:
>> On 20/11/2020 09:42, Marc Zyngier wrote:
>>> Instead of moving meson_dw_hdmi_init() around which breaks existing
>>> platform, let's enable the clock meson_dw_hdmi_init() depends on.
>>> This means we don't have to worry about this clock being enabled or
>>> not, depending on the boot-loader features.
>>>
>>> Fixes: b33340e33acd ("drm/meson: dw-hdmi: Ensure that clocks are enabled 
>>> before touching the TOP registers")
>>> Reported-by: Guillaume Tucker 
>>
>> Although I am triaging kernelci bisections, it was initially
>> found thanks to our friendly bot.  So if you're OK with this, it
>> would most definitely appreciate a mention:
>>
>>   Reported-by: "kernelci.org bot" 
> 
> Sure. Neil can add this when (and if) he applies these patches.

Yep applying to drm-misc-next and switching to `Reported-by: "kernelci.org bot" 
`

Thanks
Neil

> 
> Thanks,
> 
>     M.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/meson: dw-hdmi: Disable clocks on driver teardown

[Neil Armstrong]

On 20/11/2020 10:42, Marc Zyngier wrote:
> The HDMI driver request clocks early, but never disable them, leaving
> the clocks on even when the driver is removed.
> 
> Fix it by slightly refactoring the clock code, and register a devm
> action that will eventually disable/unprepare the enabled clocks.
> 
> Signed-off-by: Marc Zyngier 
> ---
>  drivers/gpu/drm/meson/meson_dw_hdmi.c | 43 ++-
>  1 file changed, 29 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 7f8eea494147..29623b309cb1 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -145,8 +145,6 @@ struct meson_dw_hdmi {
>   struct reset_control *hdmitx_apb;
>   struct reset_control *hdmitx_ctrl;
>   struct reset_control *hdmitx_phy;
> - struct clk *hdmi_pclk;
> - struct clk *venci_clk;
>   struct regulator *hdmi_supply;
>   u32 irq_stat;
>   struct dw_hdmi *hdmi;
> @@ -946,6 +944,29 @@ static void meson_disable_regulator(void *data)
>   regulator_disable(data);
>  }
>  
> +static void meson_disable_clk(void *data)
> +{
> + clk_disable_unprepare(data);
> +}
> +
> +static int meson_enable_clk(struct device *dev, char *name)
> +{
> + struct clk *clk;
> + int ret;
> +
> + clk = devm_clk_get(dev, name);
> + if (IS_ERR(clk)) {
> + dev_err(dev, "Unable to get %s pclk\n", name);
> + return PTR_ERR(clk);
> + }
> +
> + ret = clk_prepare_enable(clk);
> + if (!ret)
> + ret = devm_add_action_or_reset(dev, meson_disable_clk, clk);
> +
> + return ret;
> +}
> +
>  static int meson_dw_hdmi_bind(struct device *dev, struct device *master,
>   void *data)
>  {
> @@ -1026,19 +1047,13 @@ static int meson_dw_hdmi_bind(struct device *dev, 
> struct device *master,
>   if (IS_ERR(meson_dw_hdmi->hdmitx))
>   return PTR_ERR(meson_dw_hdmi->hdmitx);
>  
> - meson_dw_hdmi->hdmi_pclk = devm_clk_get(dev, "isfr");
> - if (IS_ERR(meson_dw_hdmi->hdmi_pclk)) {
> - dev_err(dev, "Unable to get HDMI pclk\n");
> - return PTR_ERR(meson_dw_hdmi->hdmi_pclk);
> - }
> - clk_prepare_enable(meson_dw_hdmi->hdmi_pclk);
> + ret = meson_enable_clk(dev, "isfr");
> + if (ret)
> + return ret;
>  
> - meson_dw_hdmi->venci_clk = devm_clk_get(dev, "venci");
> - if (IS_ERR(meson_dw_hdmi->venci_clk)) {
> - dev_err(dev, "Unable to get venci clk\n");
> - return PTR_ERR(meson_dw_hdmi->venci_clk);
> - }
> -     clk_prepare_enable(meson_dw_hdmi->venci_clk);
> + ret = meson_enable_clk(dev, "venci");
> + if (ret)
> + return ret;
>  
>   dw_plat_data->regm = devm_regmap_init(dev, NULL, meson_dw_hdmi,
> &meson_dw_hdmi_regmap_config);
> 

Reviewed-by: Neil Armstrong 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel