Re: [PATCH] drm/tidss: Use dev_err_probe() over dev_dbg() when failing to probe the port

2024-02-28 Thread Enric Balletbo i Serra
Hello Andrew,

Many thanks for proposing this.

On Wed, Feb 28, 2024 at 11:02 PM Javier Martinez Canillas
 wrote:
>
> Andrew Halaney  writes:
>
> Hello Andrew,
>
> > This gets logged out to /sys/kernel/debug/devices_deferred in the
> > -EPROBE_DEFER case and as an error otherwise. The message here provides
> > useful information to the user when troubleshooting why their display is
> > not working in either case, so let's make it output appropriately.
> >
> > Signed-off-by: Andrew Halaney 
> > ---
> > There's definitely more spots in this driver that could be upgraded from
> > dev_dbg() to something more appropriate, but this one burned me today so
> > I thought I'd send a patch for it specifically before I forget.
> > ---
>
> Makes sense to me and I agree that's useful to have that information there.
>
> Reviewed-by: Javier Martinez Canillas 
>

Logging in  /sys/kernel/debug/devices_deferred was useful for me, so

Tested-by: Enric Balletbo i Serra 

Cheers,
  Enric

> --
> Best regards,
>
> Javier Martinez Canillas
> Core Platforms
> Red Hat
>



[PATCH v4 7/7] drm/mediatek: mtk_dsi: Reset the dsi0 hardware

2021-09-30 Thread Enric Balletbo i Serra
Reset dsi0 HW to default when power on. This prevents to have different
settingis between the bootloader and the kernel.

As not all Mediatek boards have the reset consumer configured in their
board description, also is not needed on all of them, the reset is optional,
so the change is compatible with all boards.

Cc: Jitao Shi 
Suggested-by: Chun-Kuang Hu 
Signed-off-by: Enric Balletbo i Serra 
Acked-by: Chun-Kuang Hu 
Reviewed-by: Matthias Brugger 
---

(no changes since v3)

Changes in v3:
- Fix typo in the commit description

 drivers/gpu/drm/mediatek/mtk_dsi.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 93b40c245f00..5d90d2eb0019 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -980,8 +981,10 @@ static int mtk_dsi_bind(struct device *dev, struct device 
*master, void *data)
struct mtk_dsi *dsi = dev_get_drvdata(dev);
 
ret = mtk_dsi_encoder_init(drm, dsi);
+   if (ret)
+   return ret;
 
-   return ret;
+   return device_reset_optional(dev);
 }
 
 static void mtk_dsi_unbind(struct device *dev, struct device *master,
-- 
2.30.2



[PATCH v4 3/7] dt-bindings: display: mediatek: add dsi reset optional property

2021-09-30 Thread Enric Balletbo i Serra
Update device tree binding documentation for the dsi to add the optional
property to reset the dsi controller.

Signed-off-by: Enric Balletbo i Serra 
Acked-by: Rob Herring 
---

(no changes since v2)

Changes in v2:
- Added a new patch to describe the dsi reset optional property.

 .../devicetree/bindings/display/mediatek/mediatek,dsi.txt   | 6 ++
 1 file changed, 6 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
index d30428b9fb33..36b01458f45c 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
@@ -19,6 +19,11 @@ Required properties:
   Documentation/devicetree/bindings/graph.txt. This port should be connected
   to the input port of an attached DSI panel or DSI-to-eDP encoder chip.
 
+Optional properties:
+- resets: list of phandle + reset specifier pair, as described in [1].
+
+[1] Documentation/devicetree/bindings/reset/reset.txt
+
 MIPI TX Configuration Module
 
 
@@ -45,6 +50,7 @@ dsi0: dsi@1401b000 {
clocks = < MM_DSI0_ENGINE>, < MM_DSI0_DIGITAL>,
 <_tx0>;
clock-names = "engine", "digital", "hs";
+   resets = < MT8173_MMSYS_SW0_RST_B_DISP_DSI0>;
phys = <_tx0>;
phy-names = "dphy";
 
-- 
2.30.2



[PATCH v4 0/7] Add support to the mmsys driver to be a reset controller

2021-09-30 Thread Enric Balletbo i Serra
Dear all,

The following patchset is a reimplementation of the patch sent by Jitao
Shi [1] some time ago. As suggested by Chun-Kuang Hu, this time the
reset is done using the reset API, where the mmsys driver is the reset
controller and the mtk_dsi driver is the reset consumer.

Note that the first patch is kind of unrelated change, it's just a
cleanup but is needed if you want to apply all the following patches
cleanly.

This patchset is important in order to have the DSI panel working on some
kukui MT8183 Chromebooks (i.e Lenovo IdeaPad Duet). Without it, you just
get a black screen.

Best regards,
  Enric

[1] 
https://lore.kernel.org/linux-arm-kernel/20210420132614.150242-4-jitao@mediatek.com/


Changes in v4:
- Remove unnused variable as pointed by Hsin-Yi

Changes in v3:
- Based on top of the patch that converts mmsys to schema
- Fix typo in the commit description

Changes in v2:
- Fix build test ERROR Reported-by: kernel test robot 
- Added a new patch to describe the dsi reset optional property.

Enric Balletbo i Serra (7):
  arm64: dts: mediatek: Move reset controller constants into common
location
  dt-bindings: mediatek: Add #reset-cells to mmsys system controller
  dt-bindings: display: mediatek: add dsi reset optional property
  arm64: dts: mt8173: Add the mmsys reset bit to reset the dsi0
  arm64: dts: mt8183: Add the mmsys reset bit to reset the dsi0
  soc: mediatek: mmsys: Add reset controller support
  drm/mediatek: mtk_dsi: Reset the dsi0 hardware

 .../bindings/arm/mediatek/mediatek,mmsys.yaml |  4 ++
 .../display/mediatek/mediatek,dsi.txt |  6 ++
 arch/arm64/boot/dts/mediatek/mt8173.dtsi  |  2 +
 arch/arm64/boot/dts/mediatek/mt8183.dtsi  |  5 +-
 drivers/gpu/drm/mediatek/mtk_dsi.c|  5 +-
 drivers/soc/mediatek/mtk-mmsys.c  | 68 +++
 drivers/soc/mediatek/mtk-mmsys.h  |  2 +
 drivers/watchdog/mtk_wdt.c|  6 +-
 .../mt2712-resets.h   |  0
 include/dt-bindings/reset/mt8173-resets.h |  2 +
 .../mt8183-resets.h   |  3 +
 .../mt8192-resets.h   |  0
 12 files changed, 97 insertions(+), 6 deletions(-)
 rename include/dt-bindings/{reset-controller => reset}/mt2712-resets.h (100%)
 rename include/dt-bindings/{reset-controller => reset}/mt8183-resets.h (98%)
 rename include/dt-bindings/{reset-controller => reset}/mt8192-resets.h (100%)

-- 
2.30.2



Re: [PATCH v10 01/17] dt-bindings: arm: mediatek: mmsys: add power and gce properties

2021-09-08 Thread Enric Balletbo i Serra
Hi Jason,

Thank you for your patch. One small comment below.

On 8/9/21 8:02, jason-jh.lin wrote:
> Power:
> 1. Add description for power-domains property.
> 
> GCE:
> 1. Add description for mboxes property.
> 2. Add description for mediatek,gce-client-reg property.
> 
> Signed-off-by: jason-jh.lin 
> ---
>  .../bindings/arm/mediatek/mediatek,mmsys.yaml | 30 ++-
>  1 file changed, 29 insertions(+), 1 deletion(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml 
> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> index 2d4ff0ce387b..a2e7bddfed03 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> @@ -39,6 +39,30 @@ properties:
>reg:
>  maxItems: 1
>  
> +  power-domains:
> +description:
> +  A phandle and PM domain specifier as defined by bindings
> +  of the power controller specified by phandle. See
> +  Documentation/devicetree/bindings/power/power-domain.yaml for details.
> +
> +  mboxes:
> +description:
> +  Using mailbox to communicate with GCE, it should have this
> +  property and list of phandle, mailbox specifiers. See
> +  Documentation/devicetree/bindings/mailbox/mtk-gce.txt for details.
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +
> +  mediatek,gce-client-reg:
> +description:
> +  The register of client driver can be configured by gce with 4 arguments
> +  defined in this property, such as phandle of gce, subsys id,
> +  register offset and size.
> +  Each subsys id is mapping to a base address of display function blocks
> +  register which is defined in the gce header
> +  include/dt-bindings/gce/-gce.h.
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +maxItems: 1
> +
>"#clock-cells":
>  const: 1
>  
> @@ -53,6 +77,10 @@ examples:
>- |
>  mmsys: syscon@1400 {
>  compatible = "mediatek,mt8173-mmsys", "syscon";
> -reg = <0x1400 0x1000>;
> +reg = <0 0x1400 0 0x1000>;

Why this change?

Thanks,
  Enric


> +power-domains = < MT8173_POWER_DOMAIN_MM>;
>  #clock-cells = <1>;
> +mboxes = < 0 CMDQ_THR_PRIO_HIGHEST>,
> + < 1 CMDQ_THR_PRIO_HIGHEST>;
> +mediatek,gce-client-reg = < SUBSYS_1400 0 0x1000>;
>  };
> 


[PATCH v3 3/7] dt-bindings: display: mediatek: add dsi reset optional property

2021-08-25 Thread Enric Balletbo i Serra
Update device tree binding documentation for the dsi to add the optional
property to reset the dsi controller.

Signed-off-by: Enric Balletbo i Serra 
Acked-by: Rob Herring 
---

(no changes since v2)

Changes in v2:
- Added a new patch to describe the dsi reset optional property.

 .../devicetree/bindings/display/mediatek/mediatek,dsi.txt   | 6 ++
 1 file changed, 6 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
index 8238a86686be..3209b700ded6 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
@@ -19,6 +19,11 @@ Required properties:
   Documentation/devicetree/bindings/graph.txt. This port should be connected
   to the input port of an attached DSI panel or DSI-to-eDP encoder chip.
 
+Optional properties:
+- resets: list of phandle + reset specifier pair, as described in [1].
+
+[1] Documentation/devicetree/bindings/reset/reset.txt
+
 MIPI TX Configuration Module
 
 
@@ -45,6 +50,7 @@ dsi0: dsi@1401b000 {
clocks = < MM_DSI0_ENGINE>, < MM_DSI0_DIGITAL>,
 <_tx0>;
clock-names = "engine", "digital", "hs";
+   resets = < MT8173_MMSYS_SW0_RST_B_DISP_DSI0>;
phys = <_tx0>;
phy-names = "dphy";
 
-- 
2.30.2



[PATCH v3 7/7] drm/mediatek: mtk_dsi: Reset the dsi0 hardware

2021-08-25 Thread Enric Balletbo i Serra
Reset dsi0 HW to default when power on. This prevents to have different
settingis between the bootloader and the kernel.

As not all Mediatek boards have the reset consumer configured in their
board description, also is not needed on all of them, the reset is optional,
so the change is compatible with all boards.

Cc: Jitao Shi 
Suggested-by: Chun-Kuang Hu 
Signed-off-by: Enric Balletbo i Serra 
Acked-by: Chun-Kuang Hu 
Reviewed-by: Matthias Brugger 
---

Changes in v3:
- Fix typo in the commit description

 drivers/gpu/drm/mediatek/mtk_dsi.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index ae403c67cbd9..d8b81e2ab841 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -980,8 +981,10 @@ static int mtk_dsi_bind(struct device *dev, struct device 
*master, void *data)
struct mtk_dsi *dsi = dev_get_drvdata(dev);
 
ret = mtk_dsi_encoder_init(drm, dsi);
+   if (ret)
+   return ret;
 
-   return ret;
+   return device_reset_optional(dev);
 }
 
 static void mtk_dsi_unbind(struct device *dev, struct device *master,
-- 
2.30.2



[PATCH v3 0/7] Add support to the mmsys driver to be a reset controller

2021-08-25 Thread Enric Balletbo i Serra
Dear all,

The following patchset is a reimplementation of the patch sent by Jitao
Shi [1] some time ago. As suggested by Chun-Kuang Hu, this time the
reset is done using the reset API, where the mmsys driver is the reset
controller and the mtk_dsi driver is the reset consumer.

Note that the first patch is kind of unrelated change, it's just a
cleanup but is needed if you want to apply all the following patches
cleanly.

This patchset is important in order to have the DSI panel working on some
kukui MT8183 Chromebooks (i.e Lenovo IdeaPad Duet). Without it, you just
get a black screen.

Best regards,
  Enric

[1] 
https://lore.kernel.org/linux-arm-kernel/20210420132614.150242-4-jitao@mediatek.com/


Changes in v3:
- Based on top of the patch that converts mmsys to schema
- Fix typo in the commit description

Changes in v2:
- Fix build test ERROR Reported-by: kernel test robot 
- Added a new patch to describe the dsi reset optional property.

Enric Balletbo i Serra (7):
  arm64: dts: mediatek: Move reset controller constants into common
location
  dt-bindings: mediatek: Add #reset-cells to mmsys system controller
  dt-bindings: display: mediatek: add dsi reset optional property
  arm64: dts: mt8173: Add the mmsys reset bit to reset the dsi0
  arm64: dts: mt8183: Add the mmsys reset bit to reset the dsi0
  soc: mediatek: mmsys: Add reset controller support
  drm/mediatek: mtk_dsi: Reset the dsi0 hardware

 .../bindings/arm/mediatek/mediatek,mmsys.yaml |  4 ++
 .../display/mediatek/mediatek,dsi.txt |  6 ++
 arch/arm64/boot/dts/mediatek/mt8173.dtsi  |  2 +
 arch/arm64/boot/dts/mediatek/mt8183.dtsi  |  5 +-
 drivers/gpu/drm/mediatek/mtk_dsi.c|  5 +-
 drivers/soc/mediatek/mtk-mmsys.c  | 69 +++
 drivers/soc/mediatek/mtk-mmsys.h  |  2 +
 drivers/watchdog/mtk_wdt.c|  6 +-
 .../mt2712-resets.h   |  0
 include/dt-bindings/reset/mt8173-resets.h |  2 +
 .../mt8183-resets.h   |  3 +
 .../mt8192-resets.h   |  0
 12 files changed, 98 insertions(+), 6 deletions(-)
 rename include/dt-bindings/{reset-controller => reset}/mt2712-resets.h (100%)
 rename include/dt-bindings/{reset-controller => reset}/mt8183-resets.h (98%)
 rename include/dt-bindings/{reset-controller => reset}/mt8192-resets.h (100%)

-- 
2.30.2



Re: [PATCH v5 0/6] Add Mediatek Soc DRM (vdosys0) support for mt8195

2021-07-30 Thread Enric Balletbo i Serra
Hi Jason,

Thank you for your patch.

On 29/7/21 19:07, jason-jh.lin wrote:
> The hardware path of vdosys0 with eDP panel output need to go through
> by several modules, such as, OVL, RDMA, COLOR, CCORR, AAL, GAMMA,
> DITHER, DSC and MERGE.
> 


You said in other discussions that vdosys0 has eDP panel output and vdosys1 has
DP output. Is it possible to switch the outputs? What I am wondering is if this
configuration is hardware specific or board specific, i.e it'll be possible to
have another board that has DP output on vdosys0 and eDP output for vdosys1?

Thanks,
  Enric


> Change in v5:
> - add power-domain property into vdosys0 and vdosys1 dts node.
> - add MT8195 prifix and remove unused VDO1 define in mt8195-mmsys.h
> 
> Change in v4:
> - extract dt-binding patches to another patch series
>   https://patchwork.kernel.org/project/linux-mediatek/list/?series=519597
> - squash DSC module into mtk_drm_ddp_comp.c
> - add coment and simplify MERGE config function
> 
> Change in v3:
> - change mmsys and display dt-bindings document from txt to yaml
> - add MERGE additional description in display dt-bindings document
> - fix mboxes-cells number of vdosys0 node in dts
> - drop mutex eof convert define
> - remove pm_runtime apis in DSC and MERGE
> - change DSC and MERGE enum to alphabetic order
> 
> Change in v2:
> - add DSC yaml file
> - add mt8195 drm driver porting parts in to one patch
> - remove useless define, variable, structure member and function
> - simplify DSC and MERGE file and switch threre order
> 
> jason-jh.lin (6):
>   arm64: dts: mt8195: add display node for vdosys0
>   soc: mediatek: add mtk-mmsys support for mt8195 vdosys0
>   soc: mediatek: add mtk-mutex support for mt8195 vdosys0
>   drm/mediatek: add mediatek-drm of vdosys0 support for mt8195
>   drm/mediatek: add DSC support for mt8195
>   drm/mediatek: add MERGE support for mt8195
> 
>  arch/arm64/boot/dts/mediatek/mt8195.dtsi| 112 
>  drivers/gpu/drm/mediatek/Makefile   |   1 +
>  drivers/gpu/drm/mediatek/mtk_disp_drv.h |   8 +
>  drivers/gpu/drm/mediatek/mtk_disp_merge.c   | 277 
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|   6 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  62 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   2 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  32 ++-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |   1 +
>  drivers/soc/mediatek/mt8195-mmsys.h |  96 +++
>  drivers/soc/mediatek/mtk-mmsys.c|  11 +
>  drivers/soc/mediatek/mtk-mutex.c|  93 ++-
>  include/linux/soc/mediatek/mtk-mmsys.h  |   9 +
>  13 files changed, 706 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_merge.c
>  create mode 100644 drivers/soc/mediatek/mt8195-mmsys.h
> 


Re: [PATCH v5 2/6] soc: mediatek: add mtk-mmsys support for mt8195 vdosys0

2021-07-30 Thread Enric Balletbo i Serra
Hi Jason,

Thank you for your patch.

On 29/7/21 19:07, jason-jh.lin wrote:
> Add mt8195 vdosys0 clock driver name and routing table to
> the driver data of mtk-mmsys.
> 

This patch is the one that is really introducing mt8195 mmsys support. It is a
bit confusing sent the binding on another patchset. Please include [1] in this
patchset so it's clear.

[1]
https://patchwork.kernel.org/project/linux-mediatek/patch/20210722092624.14401-2-jason-jh@mediatek.com/

> Signed-off-by: jason-jh.lin 
> ---
> This patch is base on [1]
> 
> [1]add mt8195 SoC DRM binding
> - https://patchwork.kernel.org/project/linux-mediatek/list/?series=519597
> ---
>  drivers/soc/mediatek/mt8195-mmsys.h| 96 ++
>  drivers/soc/mediatek/mtk-mmsys.c   | 11 +++
>  include/linux/soc/mediatek/mtk-mmsys.h |  9 +++
>  3 files changed, 116 insertions(+)
>  create mode 100644 drivers/soc/mediatek/mt8195-mmsys.h
> 
> diff --git a/drivers/soc/mediatek/mt8195-mmsys.h 
> b/drivers/soc/mediatek/mt8195-mmsys.h
> new file mode 100644
> index ..9339a786ec5d
> --- /dev/null
> +++ b/drivers/soc/mediatek/mt8195-mmsys.h
> @@ -0,0 +1,96 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef __SOC_MEDIATEK_MT8195_MMSYS_H
> +#define __SOC_MEDIATEK_MT8195_MMSYS_H
> +
> +#define MT8195_VDO0_OVL_MOUT_EN  0xf14
> +#define MT8195_MOUT_DISP_OVL0_TO_DISP_RDMA0  BIT(0)
> +#define MT8195_MOUT_DISP_OVL0_TO_DISP_WDMA0  BIT(1)
> +#define MT8195_MOUT_DISP_OVL0_TO_DISP_OVL1   BIT(2)
> +#define MT8195_MOUT_DISP_OVL1_TO_DISP_RDMA1  BIT(4)
> +#define MT8195_MOUT_DISP_OVL1_TO_DISP_WDMA1  BIT(5)
> +#define MT8195_MOUT_DISP_OVL1_TO_DISP_OVL0   BIT(6)
> +
> +#define MT8195_VDO0_SEL_IN   0xf34
> +#define MT8195_SEL_IN_VPP_MERGE_FROM_DSC_WRAP0_OUT   (0 << 0)
> +#define MT8195_SEL_IN_VPP_MERGE_FROM_DISP_DITHER1(1 << 0)
> +#define MT8195_SEL_IN_VPP_MERGE_FROM_VDO1_VIRTUAL0   (2 << 0)
> +#define MT8195_SEL_IN_DSC_WRAP0_IN_FROM_DISP_DITHER0 (0 << 4)
> +#define MT8195_SEL_IN_DSC_WRAP0_IN_FROM_VPP_MERGE(1 << 4)
> +#define MT8195_SEL_IN_DSC_WRAP1_IN_FROM_DISP_DITHER1 (0 << 5)
> +#define MT8195_SEL_IN_DSC_WRAP1_IN_FROM_VPP_MERGE(1 << 5)
> +#define MT8195_SEL_IN_SINA_VIRTUAL0_FROM_VPP_MERGE   (0 << 8)
> +#define MT8195_SEL_IN_SINA_VIRTUAL0_FROM_DSC_WRAP1_OUT   (1 << 8)
> +#define MT8195_SEL_IN_SINB_VIRTUAL0_FROM_DSC_WRAP0_OUT   (0 << 9)
> +#define MT8195_SEL_IN_DP_INTF0_FROM_DSC_WRAP1_OUT(0 << 12)
> +#define MT8195_SEL_IN_DP_INTF0_FROM_VPP_MERGE(1 << 
> 12)
> +#define MT8195_SEL_IN_DP_INTF0_FROM_VDO1_VIRTUAL0(2 << 12)
> +#define MT8195_SEL_IN_DSI0_FROM_DSC_WRAP0_OUT(0 << 
> 16)
> +#define MT8195_SEL_IN_DSI0_FROM_DISP_DITHER0 (1 << 16)
> +#define MT8195_SEL_IN_DSI1_FROM_DSC_WRAP1_OUT(0 << 
> 17)
> +#define MT8195_SEL_IN_DSI1_FROM_VPP_MERGE(1 << 17)
> +#define MT8195_SEL_IN_DISP_WDMA1_FROM_DISP_OVL1  (0 << 
> 20)
> +#define MT8195_SEL_IN_DISP_WDMA1_FROM_VPP_MERGE  (1 << 
> 20)
> +#define MT8195_SEL_IN_DSC_WRAP1_OUT_FROM_DSC_WRAP1_IN(0 << 
> 21)
> +#define MT8195_SEL_IN_DSC_WRAP1_OUT_FROM_DISP_DITHER1(1 << 
> 21)
> +#define MT8195_SEL_IN_DISP_WDMA0_FROM_DISP_OVL0  (0 << 
> 22)
> +#define MT8195_SEL_IN_DISP_WDMA0_FROM_VPP_MERGE  (1 << 
> 22)
> +
> +#define MT8195_VDO0_SEL_OUT  0xf38
> +#define MT8195_SOUT_DISP_DITHER0_TO_DSC_WRAP0_IN (0 << 0)
> +#define MT8195_SOUT_DISP_DITHER0_TO_DSI0 (1 << 0)
> +#define MT8195_SOUT_DISP_DITHER1_TO_DSC_WRAP1_IN (0 << 1)
> +#define MT8195_SOUT_DISP_DITHER1_TO_VPP_MERGE(1 << 1)
> +#define MT8195_SOUT_DISP_DITHER1_TO_DSC_WRAP1_OUT(2 << 1)
> +#define MT8195_SOUT_VDO1_VIRTUAL0_TO_VPP_MERGE   (0 << 4)
> +#define MT8195_SOUT_VDO1_VIRTUAL0_TO_DP_INTF0(1 << 4)
> +#define MT8195_SOUT_VPP_MERGE_TO_DSI1(0 << 8)
> +#define MT8195_SOUT_VPP_MERGE_TO_DP_INTF0(1 << 8)
> +#define MT8195_SOUT_VPP_MERGE_TO_SINA_VIRTUAL0   (2 << 8)
> +#define MT8195_SOUT_VPP_MERGE_TO_DISP_WDMA1  (3 << 8)
> +#define MT8195_SOUT_VPP_MERGE_TO_DSC_WRAP0_IN(4 << 8)
> +#define MT8195_SOUT_VPP_MERGE_TO_DSC_WRAP1_IN(0 << 
> 11)
> +#define MT8195_SOUT_VPP_MERGE_TO_DISP_WDMA0  (1 << 11)
> +#define MT8195_SOUT_DSC_WRAP0_OUT_TO_DSI0(0 << 12)
> +#define MT8195_SOUT_DSC_WRAP0_OUT_TO_SINB_VIRTUAL0   (1 << 12)
> +#define 

[PATCH v2 7/7] drm/mediatek: mtk_dsi: Reset the dsi0 hardware

2021-07-14 Thread Enric Balletbo i Serra
Reset dsi0 HW to default when power on. This prevents to have different
settingbetween the bootloader and the kernel.

As not all Mediatek boards have the reset consumer configured in their
board description, also is not needed on all of them, the reset is optional,
so the change is compatible with all boards.

Cc: Jitao Shi 
Suggested-by: Chun-Kuang Hu 
Signed-off-by: Enric Balletbo i Serra 
---

(no changes since v1)

 drivers/gpu/drm/mediatek/mtk_dsi.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index ae403c67cbd9..d8b81e2ab841 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -980,8 +981,10 @@ static int mtk_dsi_bind(struct device *dev, struct device 
*master, void *data)
struct mtk_dsi *dsi = dev_get_drvdata(dev);
 
ret = mtk_dsi_encoder_init(drm, dsi);
+   if (ret)
+   return ret;
 
-   return ret;
+   return device_reset_optional(dev);
 }
 
 static void mtk_dsi_unbind(struct device *dev, struct device *master,
-- 
2.30.2



[PATCH v2 3/7] dt-bindings: display: mediatek: add dsi reset optional property

2021-07-14 Thread Enric Balletbo i Serra
Update device tree binding documentation for the dsi to add the optional
property to reset the dsi controller.

Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2:
- Added a new patch to describe the dsi reset optional property.

 .../devicetree/bindings/display/mediatek/mediatek,dsi.txt   | 6 ++
 1 file changed, 6 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
index 8238a86686be..3209b700ded6 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
@@ -19,6 +19,11 @@ Required properties:
   Documentation/devicetree/bindings/graph.txt. This port should be connected
   to the input port of an attached DSI panel or DSI-to-eDP encoder chip.
 
+Optional properties:
+- resets: list of phandle + reset specifier pair, as described in [1].
+
+[1] Documentation/devicetree/bindings/reset/reset.txt
+
 MIPI TX Configuration Module
 
 
@@ -45,6 +50,7 @@ dsi0: dsi@1401b000 {
clocks = < MM_DSI0_ENGINE>, < MM_DSI0_DIGITAL>,
 <_tx0>;
clock-names = "engine", "digital", "hs";
+   resets = < MT8173_MMSYS_SW0_RST_B_DISP_DSI0>;
phys = <_tx0>;
phy-names = "dphy";
 
-- 
2.30.2



[PATCH v2 0/7] Add support to the mmsys driver to be a reset controller

2021-07-14 Thread Enric Balletbo i Serra
Dear all,

The following patchset is a reimplementation of the patch sent by Jitao
Shi [1] some time ago. As suggested by Chun-Kuang Hu, this time the
reset is done using the reset API, where the mmsys driver is the reset
controller and the mtk_dsi driver is the reset consumer.

Note that the first patch is kind of unrelated change, it's just a
cleanup but is needed if you want to apply all the following patches
cleanly.

This patchset is important in order to have the DSI panel working on some
kukui MT8183 Chromebooks (i.e Lenovo IdeaPad Duet). Without it, you just
get a black screen.

Best regards,
  Enric

[1] 
https://lore.kernel.org/linux-arm-kernel/20210420132614.150242-4-jitao@mediatek.com/


Changes in v2:
- Fix build test ERROR Reported-by: kernel test robot 
- Added a new patch to describe the dsi reset optional property.

Enric Balletbo i Serra (7):
  arm64: dts: mediatek: Move reset controller constants into common
location
  dt-bindings: mediatek: Add #reset-cells to mmsys system controller
  dt-bindings: display: mediatek: add dsi reset optional property
  arm64: dts: mt8173: Add the mmsys reset bit to reset the dsi0
  arm64: dts: mt8183: Add the mmsys reset bit to reset the dsi0
  soc: mediatek: mmsys: Add reset controller support
  drm/mediatek: mtk_dsi: Reset the dsi0 hardware

 .../bindings/arm/mediatek/mediatek,mmsys.txt  |  2 +
 .../display/mediatek/mediatek,dsi.txt |  6 ++
 arch/arm64/boot/dts/mediatek/mt8173.dtsi  |  2 +
 arch/arm64/boot/dts/mediatek/mt8183.dtsi  |  5 +-
 drivers/gpu/drm/mediatek/mtk_dsi.c|  5 +-
 drivers/soc/mediatek/mtk-mmsys.c  | 69 +++
 drivers/soc/mediatek/mtk-mmsys.h  |  2 +
 drivers/watchdog/mtk_wdt.c|  6 +-
 .../mt2712-resets.h   |  0
 include/dt-bindings/reset/mt8173-resets.h |  2 +
 .../mt8183-resets.h   |  3 +
 .../mt8192-resets.h   |  0
 12 files changed, 96 insertions(+), 6 deletions(-)
 rename include/dt-bindings/{reset-controller => reset}/mt2712-resets.h (100%)
 rename include/dt-bindings/{reset-controller => reset}/mt8183-resets.h (98%)
 rename include/dt-bindings/{reset-controller => reset}/mt8192-resets.h (100%)

-- 
2.30.2



[PATCH 6/6] drm/mediatek: mtk_dsi: Reset the dsi0 hardware

2021-06-30 Thread Enric Balletbo i Serra
Reset dsi0 HW to default when power on. This prevents to have different
settingbetween the bootloader and the kernel.

As not all Mediatek boards have the reset consumer configured in their
board description, also is not needed on all of them, the reset is optional,
so the change is compatible with all boards.

Cc: Jitao Shi 
Suggested-by: Chun-Kuang Hu 
Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/mediatek/mtk_dsi.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index ae403c67cbd9..d8b81e2ab841 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -980,8 +981,10 @@ static int mtk_dsi_bind(struct device *dev, struct device 
*master, void *data)
struct mtk_dsi *dsi = dev_get_drvdata(dev);
 
ret = mtk_dsi_encoder_init(drm, dsi);
+   if (ret)
+   return ret;
 
-   return ret;
+   return device_reset_optional(dev);
 }
 
 static void mtk_dsi_unbind(struct device *dev, struct device *master,
-- 
2.30.2



[PATCH 0/6] Add support to the mmsys driver to be a reset controller

2021-06-30 Thread Enric Balletbo i Serra
Dear all,

The following patchset is a reimplementation of the patch sent by Jitao
Shi [1] some time ago. As suggested by Chun-Kuang Hu, this time the
reset is done using the reset API, where the mmsys driver is the reset
controller and the mtk_dsi driver is the reset consumer.

Note that the first patch is kind of unrelated change, it's just a
cleanup but is needed if you want to apply all the following patches
cleanly.

This patchset is important in order to have the DSI panel working on some
kukui MT8183 Chromebooks (i.e Lenovo IdeaPad Duet). Without it, you just
get a black screen.

Best regards,
  Enric

[1] 
https://lore.kernel.org/linux-arm-kernel/20210420132614.150242-4-jitao@mediatek.com/

Enric Balletbo i Serra (6):
  arm64: dts: mediatek: Move reset controller constants into common
location
  dt-bindings: mediatek: Add #reset-cells to mmsys system controller
  arm64: dts: mt8173: Add the mmsys reset bit to reset the dsi0
  arm64: dts: mt8183: Add the mmsys reset bit to reset the dsi0
  soc: mediatek: mmsys: Add reset controller support
  drm/mediatek: mtk_dsi: Reset the dsi0 hardware

 .../bindings/arm/mediatek/mediatek,mmsys.txt  |  2 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi  |  2 +
 arch/arm64/boot/dts/mediatek/mt8183.dtsi  |  5 +-
 drivers/gpu/drm/mediatek/mtk_dsi.c|  5 +-
 drivers/soc/mediatek/mtk-mmsys.c  | 69 +++
 drivers/soc/mediatek/mtk-mmsys.h  |  2 +
 .../mt2712-resets.h   |  0
 include/dt-bindings/reset/mt8173-resets.h |  2 +
 .../mt8183-resets.h   |  3 +
 .../mt8192-resets.h   |  0
 10 files changed, 87 insertions(+), 3 deletions(-)
 rename include/dt-bindings/{reset-controller => reset}/mt2712-resets.h (100%)
 rename include/dt-bindings/{reset-controller => reset}/mt8183-resets.h (98%)
 rename include/dt-bindings/{reset-controller => reset}/mt8192-resets.h (100%)

-- 
2.30.2



Re: [PATCH] drm/bridge: DRM_CROS_EC_ANX7688 should depend on I2C_CROS_EC_TUNNEL

2021-05-27 Thread Enric Balletbo i Serra
Hi Geert,

Thank you for your patch.

On 26/5/21 9:50, Geert Uytterhoeven wrote:
> The ChromeOS EC ANX7688 bridge is connected to a ChromeOS Embedded
> Controller, and is accessed using I2C tunneling through the Embedded
> Controller.  Hence add a dependency on I2C_CROS_EC_TUNNEL, to prevent
> asking the user about this driver when configuring a kernel without
> support for the ChromeOS EC tunnel I2C bus.
> 
> Fixes: 44602b10d7f2a5f7 ("drm/bridge: Add ChromeOS EC ANX7688 bridge driver 
> support")
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Enric Balletbo i Serra 

> ---
>  drivers/gpu/drm/bridge/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 7e7f28eb954661e2..c96e4b38d1d34ee6 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -53,6 +53,7 @@ config DRM_CHRONTEL_CH7033
>  config DRM_CROS_EC_ANX7688
>   tristate "ChromeOS EC ANX7688 bridge"
>   depends on OF
> + depends on I2C_CROS_EC_TUNNEL || COMPILE_TEST
>   select DRM_KMS_HELPER
>   select REGMAP_I2C
>   help
> 


Re: [PATCH v5 1/2] dt-bindings: usb: add analogix,anx7688.yaml

2021-04-06 Thread Enric Balletbo i Serra
Hi Laurent and Dafna,

On 31/3/21 22:40, Laurent Pinchart wrote:
> On Tue, Mar 30, 2021 at 05:14:44PM +0200, Enric Balletbo i Serra wrote:
>> On 30/3/21 15:35, Dafna Hirschfeld wrote:
>>> On 05.03.21 16:19, Laurent Pinchart wrote:
>>>> On Fri, Mar 05, 2021 at 04:14:03PM +0100, Dafna Hirschfeld wrote:
>>>>> On 05.03.21 15:34, Laurent Pinchart wrote:
>>>>>> On Fri, Mar 05, 2021 at 01:43:50PM +0100, Dafna Hirschfeld wrote:
>>>>>>> ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 
>>>>>>> 2.0 to
>>>>>>> DisplayPort 1.3 Ultra-HDi (4096x2160p60).
>>>>>>> The integrated crosspoint switch (the MUX) supports USB 3.1 data 
>>>>>>> transfer
>>>>>>> along with the DisplayPort Alternate Mode signaling over USB Type-C.
>>>>>>> Additionally, an on-chip microcontroller (OCM) is available to manage 
>>>>>>> the
>>>>>>> signal switching, Channel Configuration (CC) detection, USB Power
>>>>>>> Delivery (USB-PD), Vendor Defined Message (VDM) protocol support and 
>>>>>>> other
>>>>>>> functions as defined in the USB TypeC and USB Power Delivery
>>>>>>> specifications.
>>>>>>>
>>>>>>> ANX7688 is found on Acer Chromebook R13 (elm) and on
>>>>>>> Pine64 PinePhone.
>>>>>>>
>>>>>>> Signed-off-by: Dafna Hirschfeld 
>>>>>>> ---
>>>>>>>    .../bindings/usb/analogix,anx7688.yaml    | 177 
>>>>>>> ++
>>>>>>>    1 file changed, 177 insertions(+)
>>>>>>>    create mode 100644
>>>>>>> Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
>>>>>>> b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
>>>>>>> new file mode 100644
>>>>>>> index ..6c4dd6b4b28b
>>>>>>> --- /dev/null
>>>>>>> +++ b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
>>>>>>> @@ -0,0 +1,177 @@
>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>>> +%YAML 1.2
>>>>>>> +---
>>>>>>> +$id: http://devicetree.org/schemas/usb/analogix,anx7688.yaml#
>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>> +
>>>>>>> +title: Analogix ANX7688 Type-C Port Controller with HDMI to DP 
>>>>>>> conversion
>>>>>>> +
>>>>>>> +maintainers:
>>>>>>> +  - Nicolas Boichat 
>>>>>>> +  - Enric Balletbo i Serra 
>>>>>>> +
>>>>>>> +description: |
>>>>>>> +  ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 
>>>>>>> 2.0 to
>>>>>>> +  DisplayPort 1.3 Ultra-HDi (4096x2160p60).
>>>>>>> +  The integrated crosspoint switch (the MUX) supports USB 3.1 data
>>>>>>> transfer along with
>>>>>>> +  the DisplayPort Alternate Mode signaling over USB Type-C. 
>>>>>>> Additionally,
>>>>>>> +  an on-chip microcontroller (OCM) is available to manage the signal
>>>>>>> switching,
>>>>>>> +  Channel Configuration (CC) detection, USB Power Delivery (USB-PD), 
>>>>>>> Vendor
>>>>>>> +  Defined Message (VDM) protocol support and other functions as 
>>>>>>> defined in
>>>>>>> the
>>>>>>> +  USB TypeC and USB Power Delivery specifications.
>>>>>>> +
>>>>>>> +
>>>>>>
>>>>>> Extra blank line ?
>>>>>>
>>>>>>> +properties:
>>>>>>> +  compatible:
>>>>>>> +    const: analogix,anx7688
>>>>>>> +
>>>>>>> +  reg:
>>>>>>> +    maxItems: 1
>>>>>>> +
>>>>>>> +  avdd33-supply:
>>>>>>> +    description: 3.3V Analog core supply voltage.
>>>>>>> +
>>>>>>> +  dvdd18-supply:
>&

Re: [PATCH v5 2/2] drm/bridge: anx7688: Add ANX7688 bridge driver support

2021-03-30 Thread Enric Balletbo i Serra
Hi Dafna,

Thank you for your patch and to work on this.

On 5/3/21 13:43, Dafna Hirschfeld wrote:
> From: Enric Balletbo i Serra 
> 
> This driver adds support for the ANX7688 HDMI to DP converter block of the
> ANX7688 device.
> 
> For our use case, the only reason the Linux kernel driver is necessary is
> to reject resolutions that require more bandwidth than what is available
> on the DP side. DP bandwidth and lane count are reported by the bridge via
> 2 registers and, as far as we know, only chips that have a firmware
> version greater than 0.85 support these two registers.
> 

Maybe we should mention that this driver can be extended to support the typec
controller part which is not implemented right now because due our hardware
configuration we can't test.


> Signed-off-by: Nicolas Boichat 
> Signed-off-by: Hsin-Yi Wang 
> [The driver is OF only so should depends on CONFIG_OF]
> Reported-by: kbuild test robot 
> Signed-off-by: Enric Balletbo i Serra 
> [convert the driver to be a i2c driver]
> Signed-off-by: Dafna Hirschfeld 
> ---
>  drivers/gpu/drm/bridge/analogix/Kconfig   |  11 ++
>  drivers/gpu/drm/bridge/analogix/Makefile  |   1 +
>  .../drm/bridge/analogix/analogix-anx7688.c| 186 ++

You put the binding in bindings/usb/analogix,anx7688.yaml, which I think is the
right place. So to be coherent that should go under usb/typec. But we only
implemented the HDMI to DP bridge part (port0) because is what we can really 
test.

But this chip is more a typec controller than a bridge, so maybe it should be
placed there.


>  3 files changed, 198 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig 
> b/drivers/gpu/drm/bridge/analogix/Kconfig
> index 024ea2a570e7..323327aabc38 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -11,6 +11,17 @@ config DRM_ANALOGIX_ANX6345
> ANX6345 transforms the LVTTL RGB output of an
> application processor to eDP or DisplayPort.
>  
> +config DRM_ANALOGIX_ANX7688
> + tristate "Analogix ANX7688 bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + help
> +   ANX7688 is an ultra-low power 4K Ultra-HD (4096x2160p60)
> +   mobile HD transmitter designed for portable
> +   devices. The ANX7688 converts HDMI 2.0 to
> +   DisplayPort 1.3 Ultra-HD.
> +
>  config DRM_ANALOGIX_ANX78XX
>   tristate "Analogix ANX78XX bridge"
>   select DRM_ANALOGIX_DP
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile 
> b/drivers/gpu/drm/bridge/analogix/Makefile
> index 44da392bb9f9..8f2272b8b732 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -2,5 +2,6 @@
>  analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
>  obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
>  obj-$(CONFIG_DRM_ANALOGIX_ANX7625) += anx7625.o
> +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
>  obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c 
> b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> new file mode 100644
> index ..85a4b1a23035
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> @@ -0,0 +1,186 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * ANX7688 HDMI->DP bridge driver
> + *
> + * Copyright 2020 Google LLC
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Register addresses */
> +#define ANX7688_VENDOR_ID_REG0x00
> +#define ANX7688_DEVICE_ID_REG0x02
> +
> +#define ANX7688_FW_VERSION_REG   0x80
> +
> +#define ANX7688_DP_BANDWIDTH_REG 0x85
> +#define ANX7688_DP_LANE_COUNT_REG0x86
> +
> +#define ANX7688_VENDOR_ID0x1f29
> +#define ANX7688_DEVICE_ID0x7688
> +
> +/* First supported firmware version (0.85) */
> +#define ANX7688_MINIMUM_FW_VERSION   0x0085
> +
> +static const struct regmap_config anx7688_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> +};
> +
> +struct anx7688 {
> + struct i2c_client *client;
> + struct regmap *regmap;
> + struct drm_bridge bridge;
> + bool filter;
> +};
> +
> +static inline struct anx7688 *
> +bridge_to_anx7688(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct anx7688, bridge);
> +}
> +
> +static b

Re: [PATCH v5 1/2] dt-bindings: usb: add analogix,anx7688.yaml

2021-03-30 Thread Enric Balletbo i Serra
Hi Dafna,

Many thanks to take this challenge and work on this.

On 30/3/21 15:35, Dafna Hirschfeld wrote:
> Hi,
> 
> On 05.03.21 16:19, Laurent Pinchart wrote:
>> Hi Dafna,
>>
>> On Fri, Mar 05, 2021 at 04:14:03PM +0100, Dafna Hirschfeld wrote:
>>> On 05.03.21 15:34, Laurent Pinchart wrote:
>>>> On Fri, Mar 05, 2021 at 01:43:50PM +0100, Dafna Hirschfeld wrote:
>>>>> ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 2.0 
>>>>> to
>>>>> DisplayPort 1.3 Ultra-HDi (4096x2160p60).
>>>>> The integrated crosspoint switch (the MUX) supports USB 3.1 data transfer
>>>>> along with the DisplayPort Alternate Mode signaling over USB Type-C.
>>>>> Additionally, an on-chip microcontroller (OCM) is available to manage the
>>>>> signal switching, Channel Configuration (CC) detection, USB Power
>>>>> Delivery (USB-PD), Vendor Defined Message (VDM) protocol support and other
>>>>> functions as defined in the USB TypeC and USB Power Delivery
>>>>> specifications.
>>>>>
>>>>> ANX7688 is found on Acer Chromebook R13 (elm) and on
>>>>> Pine64 PinePhone.
>>>>>
>>>>> Signed-off-by: Dafna Hirschfeld 
>>>>> ---
>>>>>    .../bindings/usb/analogix,anx7688.yaml    | 177 ++
>>>>>    1 file changed, 177 insertions(+)
>>>>>    create mode 100644
>>>>> Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
>>>>> b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
>>>>> new file mode 100644
>>>>> index ..6c4dd6b4b28b
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
>>>>> @@ -0,0 +1,177 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>> +%YAML 1.2
>>>>> +---
>>>>> +$id: http://devicetree.org/schemas/usb/analogix,anx7688.yaml#
>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: Analogix ANX7688 Type-C Port Controller with HDMI to DP conversion
>>>>> +
>>>>> +maintainers:
>>>>> +  - Nicolas Boichat 
>>>>> +  - Enric Balletbo i Serra 
>>>>> +
>>>>> +description: |
>>>>> +  ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 
>>>>> 2.0 to
>>>>> +  DisplayPort 1.3 Ultra-HDi (4096x2160p60).
>>>>> +  The integrated crosspoint switch (the MUX) supports USB 3.1 data
>>>>> transfer along with
>>>>> +  the DisplayPort Alternate Mode signaling over USB Type-C. Additionally,
>>>>> +  an on-chip microcontroller (OCM) is available to manage the signal
>>>>> switching,
>>>>> +  Channel Configuration (CC) detection, USB Power Delivery (USB-PD), 
>>>>> Vendor
>>>>> +  Defined Message (VDM) protocol support and other functions as defined 
>>>>> in
>>>>> the
>>>>> +  USB TypeC and USB Power Delivery specifications.
>>>>> +
>>>>> +
>>>>
>>>> Extra blank line ?
>>>>
>>>>> +properties:
>>>>> +  compatible:
>>>>> +    const: analogix,anx7688
>>>>> +
>>>>> +  reg:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  avdd33-supply:
>>>>> +    description: 3.3V Analog core supply voltage.
>>>>> +
>>>>> +  dvdd18-supply:
>>>>> +    description: 1.8V Digital I/O supply voltage.
>>>>> +
>>>>> +  avdd18-supply:
>>>>> +    description: 1.8V Analog core power supply voltage.
>>>>> +
>>>>> +  avdd10-supply:
>>>>> +    description: 1.0V Analog core power supply voltage.
>>>>> +
>>>>> +  dvdd10-supply:
>>>>> +    description: 1.0V Digital core supply voltage.
>>>>> +
>>>>
>>>> That's lots of supplies. If there's a reasonable chance that some of
>>>> them will always be driven by the same regulator (especially if the
>>>> ANX7688 documentation requires that), then they could be grouped. For
>>>> instance dvdd18-supply

Re: [PATCH] drm/mediatek: Add missing MODULE_DEVICE_TABLE()

2021-03-30 Thread Enric Balletbo i Serra
Hi,

On 3/2/21 12:07, Enric Balletbo i Serra wrote:
> From: Boris Brezillon 
> 
> This patch adds the missing MODULE_DEVICE_TABLE definitions on different
> Mediatek drivers which generates correct modalias for automatic loading
> when these drivers are compiled as an external module.
> 
> Signed-off-by: Boris Brezillon 
> Signed-off-by: Enric Balletbo i Serra 

A gentle ping for someone to review this patchset :-)

Thanks,
  Enric

> ---
> 
>  drivers/gpu/drm/mediatek/mtk_cec.c  | 2 ++
>  drivers/gpu/drm/mediatek/mtk_dpi.c  | 1 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 1 +
>  drivers/gpu/drm/mediatek/mtk_dsi.c  | 1 +
>  drivers/gpu/drm/mediatek/mtk_hdmi.c | 1 +
>  drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 1 +
>  6 files changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c 
> b/drivers/gpu/drm/mediatek/mtk_cec.c
> index cb29b649fcdb..3b86e626e459 100644
> --- a/drivers/gpu/drm/mediatek/mtk_cec.c
> +++ b/drivers/gpu/drm/mediatek/mtk_cec.c
> @@ -7,6 +7,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -247,6 +248,7 @@ static const struct of_device_id mtk_cec_of_ids[] = {
>   { .compatible = "mediatek,mt8173-cec", },
>   {}
>  };
> +MODULE_DEVICE_TABLE(of, mtk_cec_of_ids);
>  
>  struct platform_driver mtk_cec_driver = {
>   .probe = mtk_cec_probe,
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 52f11a63a330..2680370652fd 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -822,6 +822,7 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
>   },
>   { },
>  };
> +MODULE_DEVICE_TABLE(of, mtk_dpi_of_ids);
>  
>  struct platform_driver mtk_dpi_driver = {
>   .probe = mtk_dpi_probe,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 5f49a809689b..e4645c8ae1c0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -470,6 +470,7 @@ static const struct of_device_id mtk_drm_of_ids[] = {
> .data = _mmsys_driver_data},
>   { }
>  };
> +MODULE_DEVICE_TABLE(of, mtk_drm_of_ids);
>  
>  static int mtk_drm_probe(struct platform_device *pdev)
>  {
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 0527480c07be..c71ce62d1bec 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1193,6 +1193,7 @@ static const struct of_device_id mtk_dsi_of_match[] = {
> .data = _dsi_driver_data },
>   { },
>  };
> +MODULE_DEVICE_TABLE(of, mtk_dsi_of_match);
>  
>  struct platform_driver mtk_dsi_driver = {
>   .probe = mtk_dsi_probe,
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 8ee55f9e2954..b4696a9d73f7 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -1818,6 +1818,7 @@ static const struct of_device_id mtk_drm_hdmi_of_ids[] 
> = {
>   },
>   {}
>  };
> +MODULE_DEVICE_TABLE(of, mtk_drm_hdmi_of_ids);
>  
>  static struct platform_driver mtk_hdmi_driver = {
>   .probe = mtk_drm_hdmi_probe,
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c 
> b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
> index 62dbad5675bb..6207eac88550 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
> @@ -335,6 +335,7 @@ static const struct of_device_id mtk_hdmi_ddc_match[] = {
>   { .compatible = "mediatek,mt8173-hdmi-ddc", },
>   {},
>  };
> +MODULE_DEVICE_TABLE(of, mtk_hdmi_ddc_match);
>  
>  struct platform_driver mtk_hdmi_ddc_driver = {
>   .probe = mtk_hdmi_ddc_probe,
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] drm/mediatek: Switch the hdmi bridge ops to the atomic versions

2021-03-25 Thread Enric Balletbo i Serra
Hi Dafna,

Thank you for your patch. It'd be nice if you can cc the linux-mediatek ML for
next version, so Mediatek people is more aware of this change. IMHO cc'ing the
lkml is also a good practice.

On 24/3/21 20:12, Dafna Hirschfeld wrote:
> The bridge operation '.enable' and the audio cb '.get_eld'
> access hdmi->conn. In the future we will want to support
> the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR and then we will
> not have direct access to the connector.
> The atomic version '.atomic_enable' allows accessing the
> current connector from the state.
> This patch switches the bridge to the atomic version and
> saves the current connector in a new field 'curr_conn'.
> 
> Signed-off-by: Dafna Hirschfeld 
> ---
>  drivers/gpu/drm/mediatek/mtk_hdmi.c | 41 -
>  1 file changed, 29 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 8ee55f9e2954..9f415c508b33 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -154,6 +154,7 @@ struct mtk_hdmi {
>   struct drm_bridge bridge;
>   struct drm_bridge *next_bridge;
>   struct drm_connector conn;
> + struct drm_connector *curr_conn;

Adding a new drm_connector (curr_conn) is something that surprised me at the
beginning, then I saw that in the second patch you remove the first
drm_connector (conn). I didn't test it yet, but did you test this patch alone?
without the second one, maybe I'm missing something but looks to me that this
patch alone breaks more functionalities of the driver? (and I know that the
driver is broken right now)

Is really needed to create a new drm_connector to switch to the atomic versions?


>   struct device *dev;
>   const struct mtk_hdmi_conf *conf;
>   struct phy *phy;
> @@ -974,7 +975,7 @@ static int mtk_hdmi_setup_avi_infoframe(struct mtk_hdmi 
> *hdmi,
>   ssize_t err;
>  
>   err = drm_hdmi_avi_infoframe_from_display_mode(,
> ->conn, mode);
> +hdmi->curr_conn, mode);
>   if (err < 0) {
>   dev_err(hdmi->dev,
>   "Failed to get AVI infoframe from mode: %zd\n", err);
> @@ -1054,7 +1055,7 @@ static int 
> mtk_hdmi_setup_vendor_specific_infoframe(struct mtk_hdmi *hdmi,
>   ssize_t err;
>  
>   err = drm_hdmi_vendor_infoframe_from_display_mode(,
> -   >conn, mode);
> +   hdmi->curr_conn, 
> mode);
>   if (err) {
>   dev_err(hdmi->dev,
>   "Failed to get vendor infoframe from mode: %zd\n", err);
> @@ -1357,7 +1358,8 @@ static bool mtk_hdmi_bridge_mode_fixup(struct 
> drm_bridge *bridge,
>   return true;
>  }
>  
> -static void mtk_hdmi_bridge_disable(struct drm_bridge *bridge)
> +static void mtk_hdmi_bridge_atomic_disable(struct drm_bridge *bridge,
> +struct drm_bridge_state 
> *old_bridge_state)
>  {
>   struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
>  
> @@ -1368,10 +1370,13 @@ static void mtk_hdmi_bridge_disable(struct drm_bridge 
> *bridge)
>   clk_disable_unprepare(hdmi->clk[MTK_HDMI_CLK_HDMI_PIXEL]);
>   clk_disable_unprepare(hdmi->clk[MTK_HDMI_CLK_HDMI_PLL]);
>  
> + hdmi->curr_conn = NULL;
> +
>   hdmi->enabled = false;
>  }
>  
> -static void mtk_hdmi_bridge_post_disable(struct drm_bridge *bridge)
> +static void mtk_hdmi_bridge_atomic_post_disable(struct drm_bridge *bridge,
> + struct drm_bridge_state 
> *old_state)
>  {
>   struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
>  
> @@ -1406,7 +1411,8 @@ static void mtk_hdmi_bridge_mode_set(struct drm_bridge 
> *bridge,
>   drm_mode_copy(>mode, adjusted_mode);
>  }
>  
> -static void mtk_hdmi_bridge_pre_enable(struct drm_bridge *bridge)
> +static void mtk_hdmi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
> +   struct drm_bridge_state 
> *old_state)
>  {
>   struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
>  
> @@ -1426,10 +1432,16 @@ static void mtk_hdmi_send_infoframe(struct mtk_hdmi 
> *hdmi,
>   mtk_hdmi_setup_vendor_specific_infoframe(hdmi, mode);
>  }
>  
> -static void mtk_hdmi_bridge_enable(struct drm_bridge *bridge)
> +static void mtk_hdmi_bridge_atomic_enable(struct drm_bridge *bridge,
> +   struct drm_bridge_state *old_state)
>  {
> + struct drm_atomic_state *state = old_state->base.state;
>   struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
>  
> + /* Retrieve the connector through the atomic state. */
> + hdmi->curr_conn = drm_atomic_get_new_connector_for_encoder(state,
> +
> 

[PATCH] drm/mediatek: Add missing MODULE_DEVICE_TABLE()

2021-02-04 Thread Enric Balletbo i Serra
From: Boris Brezillon 

This patch adds the missing MODULE_DEVICE_TABLE definitions on different
Mediatek drivers which generates correct modalias for automatic loading
when these drivers are compiled as an external module.

Signed-off-by: Boris Brezillon 
Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/mediatek/mtk_cec.c  | 2 ++
 drivers/gpu/drm/mediatek/mtk_dpi.c  | 1 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 1 +
 drivers/gpu/drm/mediatek/mtk_dsi.c  | 1 +
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 1 +
 drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 1 +
 6 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c 
b/drivers/gpu/drm/mediatek/mtk_cec.c
index cb29b649fcdb..3b86e626e459 100644
--- a/drivers/gpu/drm/mediatek/mtk_cec.c
+++ b/drivers/gpu/drm/mediatek/mtk_cec.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -247,6 +248,7 @@ static const struct of_device_id mtk_cec_of_ids[] = {
{ .compatible = "mediatek,mt8173-cec", },
{}
 };
+MODULE_DEVICE_TABLE(of, mtk_cec_of_ids);
 
 struct platform_driver mtk_cec_driver = {
.probe = mtk_cec_probe,
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 52f11a63a330..2680370652fd 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -822,6 +822,7 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
},
{ },
 };
+MODULE_DEVICE_TABLE(of, mtk_dpi_of_ids);
 
 struct platform_driver mtk_dpi_driver = {
.probe = mtk_dpi_probe,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 5f49a809689b..e4645c8ae1c0 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -470,6 +470,7 @@ static const struct of_device_id mtk_drm_of_ids[] = {
  .data = _mmsys_driver_data},
{ }
 };
+MODULE_DEVICE_TABLE(of, mtk_drm_of_ids);
 
 static int mtk_drm_probe(struct platform_device *pdev)
 {
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 0527480c07be..c71ce62d1bec 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -1193,6 +1193,7 @@ static const struct of_device_id mtk_dsi_of_match[] = {
  .data = _dsi_driver_data },
{ },
 };
+MODULE_DEVICE_TABLE(of, mtk_dsi_of_match);
 
 struct platform_driver mtk_dsi_driver = {
.probe = mtk_dsi_probe,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 8ee55f9e2954..b4696a9d73f7 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1818,6 +1818,7 @@ static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
},
{}
 };
+MODULE_DEVICE_TABLE(of, mtk_drm_hdmi_of_ids);
 
 static struct platform_driver mtk_hdmi_driver = {
.probe = mtk_drm_hdmi_probe,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
index 62dbad5675bb..6207eac88550 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
@@ -335,6 +335,7 @@ static const struct of_device_id mtk_hdmi_ddc_match[] = {
{ .compatible = "mediatek,mt8173-hdmi-ddc", },
{},
 };
+MODULE_DEVICE_TABLE(of, mtk_hdmi_ddc_match);
 
 struct platform_driver mtk_hdmi_ddc_driver = {
.probe = mtk_hdmi_ddc_probe,
-- 
2.30.0

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


[PATCH] phy: mediatek: Add missing MODULE_DEVICE_TABLE()

2021-02-04 Thread Enric Balletbo i Serra
From: Boris Brezillon 

This patch adds the missing MODULE_DEVICE_TABLE definitions on different
Mediatek phy drivers which generates correct modalias for automatic loading
when these drivers are compiled as an external module.

Signed-off-by: Boris Brezillon 
Signed-off-by: Enric Balletbo i Serra 
---

 drivers/phy/mediatek/phy-mtk-hdmi.c | 1 +
 drivers/phy/mediatek/phy-mtk-mipi-dsi.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/phy/mediatek/phy-mtk-hdmi.c 
b/drivers/phy/mediatek/phy-mtk-hdmi.c
index 45be8aa724f3..8313bd517e4c 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi.c
@@ -201,6 +201,7 @@ static const struct of_device_id mtk_hdmi_phy_match[] = {
},
{},
 };
+MODULE_DEVICE_TABLE(of, mtk_hdmi_phy_match);
 
 static struct platform_driver mtk_hdmi_phy_driver = {
.probe = mtk_hdmi_phy_probe,
diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c 
b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
index 18c481251f04..9c7815bb9000 100644
--- a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
+++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
@@ -233,6 +233,7 @@ static const struct of_device_id mtk_mipi_tx_match[] = {
  .data = _mipitx_data },
{ },
 };
+MODULE_DEVICE_TABLE(of, mtk_mipi_tx_match);
 
 struct platform_driver mtk_mipi_tx_driver = {
.probe = mtk_mipi_tx_probe,
-- 
2.30.0

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


[PATCH] drm/mediatek: Use correct aliases name for ovl

2020-11-29 Thread Enric Balletbo i Serra
Aliases property name must include only lowercase and '-', so fix this
in the driver, so we're not tempted to do "ovl_2l0 = _2l0" in the
device-tree instead of the right one which is "ovl-2l0 = _2l0".

Fixes: dd8feb2262d9 ("drm/mediatek: add component OVL_2L1")
Fixes: b17bdd0d7a73 ("drm/mediatek: add component OVL_2L0")
Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 8eba44be3a8a..3064eac1a750 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -359,7 +359,7 @@ static const struct mtk_ddp_comp_funcs ddp_ufoe = {
 
 static const char * const mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] = {
[MTK_DISP_OVL] = "ovl",
-   [MTK_DISP_OVL_2L] = "ovl_2l",
+   [MTK_DISP_OVL_2L] = "ovl-2l",
[MTK_DISP_RDMA] = "rdma",
[MTK_DISP_WDMA] = "wdma",
[MTK_DISP_COLOR] = "color",
-- 
2.29.2

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


Re: [PATCH 0/4] soc: mediatek: Prepare MMSYS for DDP routing using tables

2020-11-04 Thread Enric Balletbo i Serra
Hi Matthias,

On 6/10/20 21:33, Enric Balletbo i Serra wrote:
> Dear all,
> 
> The following series are intended to prepare the mtk-mmsys driver to
> allow different DDP (Data Display Path) routing tables per SoC. Note
> that the series has been tested only on MT8173 platform and could break
> the display on MT2701 and MT2712 based devices. I kindly ask for someone
> having these devices to provide a tested routing table (unfortunately I
> didn't have enough documentation to figure out this myself).
> 
> For the other devices (MT8183, MT6779 and MT6797) DRM support is not in
> mainline yet so nothing will break.
> 
> Thanks,
>   Enric
> 
> 
> CK Hu (2):
>   soc: mediatek: mmsys: Create struct mtk_mmsys to store context data
>   soc: mediatek: mmsys: Use an array for setting the routing registers
> 
> Enric Balletbo i Serra (1):
>   soc: mediatek: mmsys: Use devm_platform_ioremap_resource()
> 
> Yongqiang Niu (1):
>   soc / drm: mediatek: Move DDP component defines into mtk-mmsys.h
> 
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  34 +-
>  drivers/soc/mediatek/mtk-mmsys.c| 429 +++-
>  include/linux/soc/mediatek/mtk-mmsys.h  |  33 ++
>  3 files changed, 263 insertions(+), 233 deletions(-)
> 

Although the patches 3 and 4 are controversial, and I'll work on it, I am
wondering if 1 and 2 are ready to be picked, as they are independent, so I can
send next version without these two patches.

Thanks,
  Enric


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


Re: [PATCH] drm/mediatek: mtk_dpi: Fix unused variable 'mtk_dpi_encoder_funcs'

2020-11-04 Thread Enric Balletbo i Serra
Hi

On 5/10/20 18:22, Enric Balletbo i Serra wrote:
> Commit f89c696e7f63 ("drm/mediatek: mtk_dpi: Convert to bridge driver")
> introduced the following build warning with W=1
> 
>  drivers/gpu/drm/mediatek/mtk_dpi.c:530:39: warning: unused variable 
> 'mtk_dpi_encoder_funcs' [-Wunused-const-variable]
>  static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
> 
> This struct is and the 'mtk_dpi_encoder_destroy()' are not needed
> anymore, so remove them.
> 
> Fixes: f89c696e7f63 ("drm/mediatek: mtk_dpi: Convert to bridge driver")
> Reported-by: kernel test robot 
> Signed-off-by: Enric Balletbo i Serra 
> ---

A gentle ping on this small fix. Thanks,

  Enric

> 
>  drivers/gpu/drm/mediatek/mtk_dpi.c | 9 -
>  1 file changed, 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 589ef33a1780..2609d917e3f9 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -522,15 +522,6 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
>   return 0;
>  }
>  
> -static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> -}
> -
> -static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
> - .destroy = mtk_dpi_encoder_destroy,
> -};
> -
>  static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
>enum drm_bridge_attach_flags flags)
>  {
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/4] soc / drm: mediatek: Move DDP component defines into mtk-mmsys.h

2020-10-07 Thread Enric Balletbo i Serra
From: Yongqiang Niu 

MMSYS is the driver which controls the routing of these DDP components,
so the definition of the mtk_ddp_comp_id enum should be placed in mtk-mmsys.h

Signed-off-by: Yongqiang Niu 
Reviewed-by: Chun-Kuang Hu 
Signed-off-by: Enric Balletbo i Serra 
---
This patch was previously part of another series, but has no
dependencies and can be applied independently. As the latest version
sent is from two months ago, I resent this patch because the next patches
of this series depends on it to apply cleanly.

[1] https://patchwork.kernel.org/patch/11706243

 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 34 +
 drivers/soc/mediatek/mtk-mmsys.c|  4 +--
 include/linux/soc/mediatek/mtk-mmsys.h  | 33 
 3 files changed, 35 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index debe36395fe7..161201fe5179 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -7,6 +7,7 @@
 #define MTK_DRM_DDP_COMP_H
 
 #include 
+#include 
 
 struct device;
 struct device_node;
@@ -35,39 +36,6 @@ enum mtk_ddp_comp_type {
MTK_DDP_COMP_TYPE_MAX,
 };
 
-enum mtk_ddp_comp_id {
-   DDP_COMPONENT_AAL0,
-   DDP_COMPONENT_AAL1,
-   DDP_COMPONENT_BLS,
-   DDP_COMPONENT_CCORR,
-   DDP_COMPONENT_COLOR0,
-   DDP_COMPONENT_COLOR1,
-   DDP_COMPONENT_DITHER,
-   DDP_COMPONENT_DPI0,
-   DDP_COMPONENT_DPI1,
-   DDP_COMPONENT_DSI0,
-   DDP_COMPONENT_DSI1,
-   DDP_COMPONENT_DSI2,
-   DDP_COMPONENT_DSI3,
-   DDP_COMPONENT_GAMMA,
-   DDP_COMPONENT_OD0,
-   DDP_COMPONENT_OD1,
-   DDP_COMPONENT_OVL0,
-   DDP_COMPONENT_OVL_2L0,
-   DDP_COMPONENT_OVL_2L1,
-   DDP_COMPONENT_OVL1,
-   DDP_COMPONENT_PWM0,
-   DDP_COMPONENT_PWM1,
-   DDP_COMPONENT_PWM2,
-   DDP_COMPONENT_RDMA0,
-   DDP_COMPONENT_RDMA1,
-   DDP_COMPONENT_RDMA2,
-   DDP_COMPONENT_UFOE,
-   DDP_COMPONENT_WDMA0,
-   DDP_COMPONENT_WDMA1,
-   DDP_COMPONENT_ID_MAX,
-};
-
 struct mtk_ddp_comp;
 struct cmdq_pkt;
 struct mtk_ddp_comp_funcs {
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index a55f25511173..36ad66bb221b 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -5,13 +5,11 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 
-#include "../../gpu/drm/mediatek/mtk_drm_ddp.h"
-#include "../../gpu/drm/mediatek/mtk_drm_ddp_comp.h"
-
 #define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN  0x040
 #define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN  0x044
 #define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048
diff --git a/include/linux/soc/mediatek/mtk-mmsys.h 
b/include/linux/soc/mediatek/mtk-mmsys.h
index 7bab5d9a3d31..2228bf6133da 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -9,6 +9,39 @@
 enum mtk_ddp_comp_id;
 struct device;
 
+enum mtk_ddp_comp_id {
+   DDP_COMPONENT_AAL0,
+   DDP_COMPONENT_AAL1,
+   DDP_COMPONENT_BLS,
+   DDP_COMPONENT_CCORR,
+   DDP_COMPONENT_COLOR0,
+   DDP_COMPONENT_COLOR1,
+   DDP_COMPONENT_DITHER,
+   DDP_COMPONENT_DPI0,
+   DDP_COMPONENT_DPI1,
+   DDP_COMPONENT_DSI0,
+   DDP_COMPONENT_DSI1,
+   DDP_COMPONENT_DSI2,
+   DDP_COMPONENT_DSI3,
+   DDP_COMPONENT_GAMMA,
+   DDP_COMPONENT_OD0,
+   DDP_COMPONENT_OD1,
+   DDP_COMPONENT_OVL0,
+   DDP_COMPONENT_OVL_2L0,
+   DDP_COMPONENT_OVL_2L1,
+   DDP_COMPONENT_OVL1,
+   DDP_COMPONENT_PWM0,
+   DDP_COMPONENT_PWM1,
+   DDP_COMPONENT_PWM2,
+   DDP_COMPONENT_RDMA0,
+   DDP_COMPONENT_RDMA1,
+   DDP_COMPONENT_RDMA2,
+   DDP_COMPONENT_UFOE,
+   DDP_COMPONENT_WDMA0,
+   DDP_COMPONENT_WDMA1,
+   DDP_COMPONENT_ID_MAX,
+};
+
 void mtk_mmsys_ddp_connect(struct device *dev,
   enum mtk_ddp_comp_id cur,
   enum mtk_ddp_comp_id next);
-- 
2.28.0

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


[PATCH 0/4] soc: mediatek: Prepare MMSYS for DDP routing using tables

2020-10-07 Thread Enric Balletbo i Serra
Dear all,

The following series are intended to prepare the mtk-mmsys driver to
allow different DDP (Data Display Path) routing tables per SoC. Note
that the series has been tested only on MT8173 platform and could break
the display on MT2701 and MT2712 based devices. I kindly ask for someone
having these devices to provide a tested routing table (unfortunately I
didn't have enough documentation to figure out this myself).

For the other devices (MT8183, MT6779 and MT6797) DRM support is not in
mainline yet so nothing will break.

Thanks,
  Enric


CK Hu (2):
  soc: mediatek: mmsys: Create struct mtk_mmsys to store context data
  soc: mediatek: mmsys: Use an array for setting the routing registers

Enric Balletbo i Serra (1):
  soc: mediatek: mmsys: Use devm_platform_ioremap_resource()

Yongqiang Niu (1):
  soc / drm: mediatek: Move DDP component defines into mtk-mmsys.h

 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  34 +-
 drivers/soc/mediatek/mtk-mmsys.c| 429 +++-
 include/linux/soc/mediatek/mtk-mmsys.h  |  33 ++
 3 files changed, 263 insertions(+), 233 deletions(-)

-- 
2.28.0

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


[PATCH] drm/mediatek: mtk_dpi: Fix unused variable 'mtk_dpi_encoder_funcs'

2020-10-06 Thread Enric Balletbo i Serra
Commit f89c696e7f63 ("drm/mediatek: mtk_dpi: Convert to bridge driver")
introduced the following build warning with W=1

 drivers/gpu/drm/mediatek/mtk_dpi.c:530:39: warning: unused variable 
'mtk_dpi_encoder_funcs' [-Wunused-const-variable]
 static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {

This struct is and the 'mtk_dpi_encoder_destroy()' are not needed
anymore, so remove them.

Fixes: f89c696e7f63 ("drm/mediatek: mtk_dpi: Convert to bridge driver")
Reported-by: kernel test robot 
Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/mediatek/mtk_dpi.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 589ef33a1780..2609d917e3f9 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -522,15 +522,6 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
return 0;
 }
 
-static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
-{
-   drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
-   .destroy = mtk_dpi_encoder_destroy,
-};
-
 static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
 enum drm_bridge_attach_flags flags)
 {
-- 
2.28.0

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


Re: [PATCH v1 2/2] drm/rockchip: fix warning from cdn_dp_resume

2020-09-29 Thread Enric Balletbo i Serra
Hi Sam,

Thank you for your patch.

On 25/9/20 23:55, Sam Ravnborg wrote:
> Commit 7c49abb4c2f8 ("drm/rockchip: cdn-dp-core: Make 
> cdn_dp_core_suspend/resume static")
> introduced the following warning in some builds:
> 
> cdn-dp-core.c:1124:12: warning: ‘cdn_dp_resume’ defined but not used
>  1124 | static int cdn_dp_resume(struct device *dev)
>   |^
> 
> Fix this by defining cdn_dp_resume __maybe_unused
> 
> Signed-off-by: Sam Ravnborg 
> Fixes: 7c49abb4c2f8 ("drm/rockchip: cdn-dp-core: Make 
> cdn_dp_core_suspend/resume static")
> Cc: Enric Balletbo i Serra 
> Cc: Heiko Stuebner 
> Cc: Sandy Huang 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-rockc...@lists.infradead.org
> Cc:  # v5.8+
> ---

Hopefully this time this change lands ;-) Similar patches [1], [2], [3], were
sent in the past by different authors but for some reason never reached 
upstream.

[1] https://lkml.org/lkml/2020/4/28/1703
[2] https://www.spinics.net/lists/dri-devel/msg268818.html
[3] https://lkml.org/lkml/2020/8/10/1412

>  drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index a4a45daf93f2..1162e321aaed 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -1121,7 +1121,7 @@ static int cdn_dp_suspend(struct device *dev)

Shouldn't cdn_dp_suspend also have a __maybe_unused?

With that,

Reviewed-by: Enric Balletbo i Serra 

>   return ret;
>  }
>  
> -static int cdn_dp_resume(struct device *dev)
> +static int __maybe_unused cdn_dp_resume(struct device *dev)
>  {
>   struct cdn_dp_device *dp = dev_get_drvdata(dev);
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 0/1] drm/bridge: ps8640: Make sure all needed is powered to get the EDID

2020-09-15 Thread Enric Balletbo i Serra
Hi Sam,

On 27/8/20 10:59, Enric Balletbo i Serra wrote:
> The first 4 patches of the series version 2:
>   - drm/bridge_connector: Set default status connected for eDP connectors
>   - drm/bridge: ps8640: Get the EDID from eDP control
>   - drm/bridge: ps8640: Return an error for incorrect attach flags
>   - drm/bridge: ps8640: Print an error if VDO control fails
> 
> Are already applied to drm-misc-next, so I removed from this series. The
> pending patch is part of the original series and is a rework of the power
> handling to get the EDID. Basically, we need to make sure all the
> needed is powered to be able to get the EDID. Before, we saw that getting
> the EDID failed as explained in the third patch.
> 
> [1] https://lkml.org/lkml/2020/6/15/1208
> 
> Changes in v3:
> - Make poweron/poweroff and pre_enable/post_disable reverse one to each other 
> (Sam Ravnborg)
> 
> Changes in v2:
> - Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg)
> 
> Enric Balletbo i Serra (1):
>   drm/bridge: ps8640: Rework power state handling
> 
>  drivers/gpu/drm/bridge/parade-ps8640.c | 68 ++
>  1 file changed, 58 insertions(+), 10 deletions(-)
> 

A gentle ping on this patch. Would be nice land this together with the already
accepted patches.

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


Re: [PATCH v3 1/1] drm/bridge: ps8640: Rework power state handling

2020-09-01 Thread Enric Balletbo i Serra
Hi Bilal,

On 31/8/20 11:32, Bilal Wasim wrote:
> 
> Hi Enric,
> 
> On Thu, 27 Aug 2020 10:59:11 +0200
> Enric Balletbo i Serra  wrote:
> 
>> The get_edid() callback can be triggered anytime by an ioctl, i.e
>>
>>   drm_mode_getconnector (ioctl)
>> -> drm_helper_probe_single_connector_modes
>>-> drm_bridge_connector_get_modes
>>   -> ps8640_bridge_get_edid  
>>
>> Actually if the bridge pre_enable() function was not called before
>> get_edid(), the driver will not be able to get the EDID properly and
>> display will not work until a second get_edid() call is issued and if
>> pre_enable() is called before. The side effect of this, for example,
>> is that you see anything when `Frecon` starts, neither the splash
>> screen, until the graphical session manager starts.
>>
>> To fix this we need to make sure that all we need is enabled before
>> reading the EDID. This means the following:
>>
>> 1. If get_edid() is called before having the device powered we need to
>>power on the device. In such case, the driver will power off again
>> the device.
>>
>> 2. If get_edid() is called after having the device powered, all should
>>just work. We added a powered flag in order to avoid recurrent
>> calls to ps8640_bridge_poweron() and unneeded delays.
>>
>> 3. This seems to be specific for this device, but we need to make sure
>>the panel is powered on before do a power on cycle on this device.
>>Otherwise the device fails to retrieve the EDID.
>>
>> Signed-off-by: Enric Balletbo i Serra 
>> ---
>>
>> Changes in v3:
>> - Make poweron/poweroff and pre_enable/post_disable reverse one to
>> each other (Sam Ravnborg)
>>
>> Changes in v2:
>> - Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam
>> Ravnborg)
>>
>>  drivers/gpu/drm/bridge/parade-ps8640.c | 68
>> ++ 1 file changed, 58 insertions(+), 10
>> deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
>> b/drivers/gpu/drm/bridge/parade-ps8640.c index
>> 9f7b7a9c53c5..7bd0affa057a 100644 ---
>> a/drivers/gpu/drm/bridge/parade-ps8640.c +++
>> b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -65,6 +65,7 @@ struct
>> ps8640 { struct regulator_bulk_data supplies[2];
>>  struct gpio_desc *gpio_reset;
>>  struct gpio_desc *gpio_powerdown;
>> +bool powered;
>>  };
>>  
>>  static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
>> @@ -91,13 +92,15 @@ static int ps8640_bridge_vdo_control(struct
>> ps8640 *ps_bridge, return 0;
>>  }
>>  
>> -static void ps8640_pre_enable(struct drm_bridge *bridge)
>> +static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
>>  {
>> -struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>>  struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
>>  unsigned long timeout;
>>  int ret, status;
>>  
>> +if (ps_bridge->powered)
>> +return;
>> +
>>  ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
>>  ps_bridge->supplies);
>>  if (ret < 0) {
>> @@ -152,10 +155,6 @@ static void ps8640_pre_enable(struct drm_bridge
>> *bridge) goto err_regulators_disable;
>>  }
>>  
>> -ret = ps8640_bridge_vdo_control(ps_bridge, ENABLE);
>> -if (ret)
>> -goto err_regulators_disable;
>> -
>>  /* Switch access edp panel's edid through i2c */
>>  ret = i2c_smbus_write_byte_data(client, PAGE2_I2C_BYPASS,
>>  I2C_BYPASS_EN);
>> @@ -164,6 +163,8 @@ static void ps8640_pre_enable(struct drm_bridge
>> *bridge) goto err_regulators_disable;
>>  }
>>  
>> +ps_bridge->powered = true;
>> +
>>  return;
>>  
>>  err_regulators_disable:
>> @@ -171,12 +172,12 @@ static void ps8640_pre_enable(struct drm_bridge
>> *bridge) ps_bridge->supplies);
>>  }
>>  
>> -static void ps8640_post_disable(struct drm_bridge *bridge)
>> +static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
>>  {
>> -struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>>  int ret;
>>  
>> -ps8640_bridge_vdo_control(ps_bridge, DISABLE);
>> +if (!ps_bridge->powered)
>> +return;
>>  
>>  gpiod_set_value(ps_bridge->gpio_reset, 1);
>>  gpiod_set_value(ps_bridge->gpio_powerdown, 1

[PATCH v3 0/1] drm/bridge: ps8640: Make sure all needed is powered to get the EDID

2020-08-28 Thread Enric Balletbo i Serra
The first 4 patches of the series version 2:
  - drm/bridge_connector: Set default status connected for eDP connectors
  - drm/bridge: ps8640: Get the EDID from eDP control
  - drm/bridge: ps8640: Return an error for incorrect attach flags
  - drm/bridge: ps8640: Print an error if VDO control fails

Are already applied to drm-misc-next, so I removed from this series. The
pending patch is part of the original series and is a rework of the power
handling to get the EDID. Basically, we need to make sure all the
needed is powered to be able to get the EDID. Before, we saw that getting
the EDID failed as explained in the third patch.

[1] https://lkml.org/lkml/2020/6/15/1208

Changes in v3:
- Make poweron/poweroff and pre_enable/post_disable reverse one to each other 
(Sam Ravnborg)

Changes in v2:
- Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg)

Enric Balletbo i Serra (1):
  drm/bridge: ps8640: Rework power state handling

 drivers/gpu/drm/bridge/parade-ps8640.c | 68 ++
 1 file changed, 58 insertions(+), 10 deletions(-)

-- 
2.28.0

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


[PATCH v3 1/1] drm/bridge: ps8640: Rework power state handling

2020-08-28 Thread Enric Balletbo i Serra
The get_edid() callback can be triggered anytime by an ioctl, i.e

  drm_mode_getconnector (ioctl)
-> drm_helper_probe_single_connector_modes
   -> drm_bridge_connector_get_modes
  -> ps8640_bridge_get_edid

Actually if the bridge pre_enable() function was not called before
get_edid(), the driver will not be able to get the EDID properly and
display will not work until a second get_edid() call is issued and if
pre_enable() is called before. The side effect of this, for example, is
that you see anything when `Frecon` starts, neither the splash screen,
until the graphical session manager starts.

To fix this we need to make sure that all we need is enabled before
reading the EDID. This means the following:

1. If get_edid() is called before having the device powered we need to
   power on the device. In such case, the driver will power off again the
   device.

2. If get_edid() is called after having the device powered, all should
   just work. We added a powered flag in order to avoid recurrent calls
   to ps8640_bridge_poweron() and unneeded delays.

3. This seems to be specific for this device, but we need to make sure
   the panel is powered on before do a power on cycle on this device.
   Otherwise the device fails to retrieve the EDID.

Signed-off-by: Enric Balletbo i Serra 
---

Changes in v3:
- Make poweron/poweroff and pre_enable/post_disable reverse one to each other 
(Sam Ravnborg)

Changes in v2:
- Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg)

 drivers/gpu/drm/bridge/parade-ps8640.c | 68 ++
 1 file changed, 58 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 9f7b7a9c53c5..7bd0affa057a 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -65,6 +65,7 @@ struct ps8640 {
struct regulator_bulk_data supplies[2];
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_powerdown;
+   bool powered;
 };
 
 static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
@@ -91,13 +92,15 @@ static int ps8640_bridge_vdo_control(struct ps8640 
*ps_bridge,
return 0;
 }
 
-static void ps8640_pre_enable(struct drm_bridge *bridge)
+static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
 {
-   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
unsigned long timeout;
int ret, status;
 
+   if (ps_bridge->powered)
+   return;
+
ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
ps_bridge->supplies);
if (ret < 0) {
@@ -152,10 +155,6 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
goto err_regulators_disable;
}
 
-   ret = ps8640_bridge_vdo_control(ps_bridge, ENABLE);
-   if (ret)
-   goto err_regulators_disable;
-
/* Switch access edp panel's edid through i2c */
ret = i2c_smbus_write_byte_data(client, PAGE2_I2C_BYPASS,
I2C_BYPASS_EN);
@@ -164,6 +163,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
goto err_regulators_disable;
}
 
+   ps_bridge->powered = true;
+
return;
 
 err_regulators_disable:
@@ -171,12 +172,12 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
   ps_bridge->supplies);
 }
 
-static void ps8640_post_disable(struct drm_bridge *bridge)
+static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
 {
-   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
int ret;
 
-   ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+   if (!ps_bridge->powered)
+   return;
 
gpiod_set_value(ps_bridge->gpio_reset, 1);
gpiod_set_value(ps_bridge->gpio_powerdown, 1);
@@ -184,6 +185,28 @@ static void ps8640_post_disable(struct drm_bridge *bridge)
 ps_bridge->supplies);
if (ret < 0)
DRM_ERROR("cannot disable regulators %d\n", ret);
+
+   ps_bridge->powered = false;
+}
+
+static void ps8640_pre_enable(struct drm_bridge *bridge)
+{
+   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+   int ret;
+
+   ps8640_bridge_poweron(ps_bridge);
+
+   ret = ps8640_bridge_vdo_control(ps_bridge, ENABLE);
+   if (ret < 0)
+   ps8640_bridge_poweroff(ps_bridge);
+}
+
+static void ps8640_post_disable(struct drm_bridge *bridge)
+{
+   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+   ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+   ps8640_bridge_poweroff(ps_bridge);
 }
 
 static int ps8640_bridge_attach(struct drm_bridge *bridge,
@@ -249,9 +272,34 @@ static struct edid *ps8640_bridge_get_edid(struct 
drm_brid

Re: [PATCH v2 5/5] drm/bridge: ps8640: Rework power state handling

2020-08-28 Thread Enric Balletbo i Serra
Hi Sam,

Thanks for your comments.

On 26/8/20 20:46, Sam Ravnborg wrote:
> Hi Enric.
> 
> On Wed, Aug 26, 2020 at 10:15:26AM +0200, Enric Balletbo i Serra wrote:
>> The get_edid() callback can be triggered anytime by an ioctl, i.e
>>
>>   drm_mode_getconnector (ioctl)
>> -> drm_helper_probe_single_connector_modes
>>-> drm_bridge_connector_get_modes
>>   -> ps8640_bridge_get_edid
>>
>> Actually if the bridge pre_enable() function was not called before
>> get_edid(), the driver will not be able to get the EDID properly and
>> display will not work until a second get_edid() call is issued and if
>> pre_enable() is called before. The side effect of this, for example, is
>> that you see anything when `Frecon` starts, neither the splash screen,
>> until the graphical session manager starts.
>>
>> To fix this we need to make sure that all we need is enabled before
>> reading the EDID. This means the following:
>>
>> 1. If get_edid() is called before having the device powered we need to
>>power on the device. In such case, the driver will power off again the
>>device.
>>
>> 2. If get_edid() is called after having the device powered, all should
>>just work. We added a powered flag in order to avoid recurrent calls
>>to ps8640_bridge_poweron() and unneeded delays.
>>
>> 3. This seems to be specific for this device, but we need to make sure
>>the panel is powered on before do a power on cycle on this device.
>>Otherwise the device fails to retrieve the EDID.
>>
>> Signed-off-by: Enric Balletbo i Serra 
>> ---
>>
>> Changes in v2:
>> - Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg)
>>
>>  drivers/gpu/drm/bridge/parade-ps8640.c | 64 +++---
>>  1 file changed, 58 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
>> b/drivers/gpu/drm/bridge/parade-ps8640.c
>> index 9f7b7a9c53c5..c5d76e209bda 100644
>> --- a/drivers/gpu/drm/bridge/parade-ps8640.c
>> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
>> @@ -65,6 +65,7 @@ struct ps8640 {
>>  struct regulator_bulk_data supplies[2];
>>  struct gpio_desc *gpio_reset;
>>  struct gpio_desc *gpio_powerdown;
>> +bool powered;
>>  };
>>  
>>  static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
>> @@ -91,13 +92,15 @@ static int ps8640_bridge_vdo_control(struct ps8640 
>> *ps_bridge,
>>  return 0;
>>  }
>>  
>> -static void ps8640_pre_enable(struct drm_bridge *bridge)
>> +static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
>>  {
>> -struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>>  struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
>>  unsigned long timeout;
>>  int ret, status;
>>  
>> +if (ps_bridge->powered)
>> +return;
>> +
>>  ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
>>  ps_bridge->supplies);
>>  if (ret < 0) {
>> @@ -164,6 +167,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
>>  goto err_regulators_disable;
>>  }
>>  
>> +ps_bridge->powered = true;
>> +
>>  return;
>>  
>>  err_regulators_disable:
>> @@ -171,12 +176,12 @@ static void ps8640_pre_enable(struct drm_bridge 
>> *bridge)
>> ps_bridge->supplies);
>>  }
>>  
>> -static void ps8640_post_disable(struct drm_bridge *bridge)
>> +static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
>>  {
>> -struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>>  int ret;
>>  
>> -ps8640_bridge_vdo_control(ps_bridge, DISABLE);
>> +if (!ps_bridge->powered)
>> +return;
>>  
>>  gpiod_set_value(ps_bridge->gpio_reset, 1);
>>  gpiod_set_value(ps_bridge->gpio_powerdown, 1);
>> @@ -184,6 +189,28 @@ static void ps8640_post_disable(struct drm_bridge 
>> *bridge)
>>   ps_bridge->supplies);
>>  if (ret < 0)
>>  DRM_ERROR("cannot disable regulators %d\n", ret);
>> +
>> +ps_bridge->powered = false;
>> +}
>> +
>> +static void ps8640_pre_enable(struct drm_bridge *bridge)
>> +{
>> +struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>> +int ret;
>> +
>> +ps8640_bridge_poweron(ps_bridge

[RESEND PATCH v2 0/2] Convert mtk-dpi to drm_bridge API

2020-08-27 Thread Enric Balletbo i Serra


The mtk-dpi driver still uses the drm_encoder API which is now somewhat
deprecated. We started to move all the Mediatek drivers to the drm_bridge API,
like we did for the mtk-dsi driver [1], this is another small step to be able to
fully convert the DRM Mediatek drivers to the drm_bridge API. A dummy
drm_encoder is maintained in the mtk-dpi driver but the end goal is move all the
dummy drm_encoder (mtk-dsi, mtk-dpi, etc) to the main mtk_drm_drv driver.

[1] https://lore.kernel.org/patchwork/project/lkml/list/?series=441559

Changes in v2:
- Maintain error message when attach to bridge fails. (Boris)

Enric Balletbo i Serra (2):
  drm/mediatek: mtk_dpi: Rename bridge to next_bridge
  drm/mediatek: mtk_dpi: Convert to bridge driver

 drivers/gpu/drm/mediatek/mtk_dpi.c | 77 +-
 1 file changed, 45 insertions(+), 32 deletions(-)

-- 
2.28.0

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


[PATCH v2 3/5] drm/bridge: ps8640: Return an error for incorrect attach flags

2020-08-27 Thread Enric Balletbo i Serra
Bridge drivers that implement the new model only shall return an error
from their attach() handler when the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag
is not set. So make sure we return an error because only the new
drm_bridge model is supported.

Reviewed-by: Sam Ravnborg 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2: None

 drivers/gpu/drm/bridge/parade-ps8640.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 13755d278db6..ce3e8b2da8c9 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -200,6 +200,10 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge,
   .channel = 0,
   .node = NULL,
 };
+
+   if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
+   return -EINVAL;
+
/* port@0 is ps8640 dsi input port */
in_ep = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1);
if (!in_ep)
-- 
2.28.0

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


[PATCH v2 2/5] drm/bridge: ps8640: Get the EDID from eDP control

2020-08-27 Thread Enric Balletbo i Serra
The PS8640 DSI-to-eDP bridge can retrieve the EDID, so implement the
.get_edid callback and set the flag to indicate the core to use it.

Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2:
- Included the patch `drm/bridge: ps8640: Get the EDID from eDP control`

 drivers/gpu/drm/bridge/parade-ps8640.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 4b099196afeb..13755d278db6 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -242,8 +242,18 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge,
return ret;
 }
 
+static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge,
+  struct drm_connector *connector)
+{
+   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+   return drm_get_edid(connector,
+   ps_bridge->page[PAGE0_DP_CNTL]->adapter);
+}
+
 static const struct drm_bridge_funcs ps8640_bridge_funcs = {
.attach = ps8640_bridge_attach,
+   .get_edid = ps8640_bridge_get_edid,
.post_disable = ps8640_post_disable,
.pre_enable = ps8640_pre_enable,
 };
@@ -294,6 +304,8 @@ static int ps8640_probe(struct i2c_client *client)
 
ps_bridge->bridge.funcs = _bridge_funcs;
ps_bridge->bridge.of_node = dev->of_node;
+   ps_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
+   ps_bridge->bridge.type = DRM_MODE_CONNECTOR_eDP;
 
ps_bridge->page[PAGE0_DP_CNTL] = client;
 
-- 
2.28.0

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


Re: [PATCH v4 0/7] Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge

2020-08-27 Thread Enric Balletbo i Serra
Hi Bilal,

On 24/8/20 21:01, Bilal Wasim wrote:
> Hi Chun-Kuan, Enric,
> 
> Is there any plan to merge the following commits in this series to the 
> mainline?
> 
>   drm/bridge: ps8640: Get the EDID from eDP control
>   drm/bridge_connector: Set default status connected for eDP connectors
> 

Just sent a new series including this patches:
https://lore.kernel.org/patchwork/project/lkml/list/?series=459760

Thanks,
 Enric

> I see that rest of the patchset is already merged and available in 5.9-RC2. 
> 
> Thanks,
> Bilal
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 0/5] drm/bridge: ps8640: Make sure all needed is powered to get the EDID

2020-08-27 Thread Enric Balletbo i Serra
The first patch was initially part of the series [1] but for some reason
was not picked when the series were merged, so I included in this series
because it is needed to make the others to work properly.

The same happened for the second patch, was part of series [1] but not
merged.

The third patch and next are part of the original series and are to rework
the power handling to get the EDID. Basically, we need to make sure all the
needed is powered to be able to get the EDID. Before, we saw that getting
the EDID failed as explained in the third patch.

[1] https://lkml.org/lkml/2020/6/15/1208

Changes in v2:
- Included the patch `drm/bridge_connector: Set default status connected for 
eDP connectors`
- Included the patch `drm/bridge: ps8640: Get the EDID from eDP control`
- Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg)

Enric Balletbo i Serra (5):
  drm/bridge_connector: Set default status connected for eDP connectors
  drm/bridge: ps8640: Get the EDID from eDP control
  drm/bridge: ps8640: Return an error for incorrect attach flags
  drm/bridge: ps8640: Print an error if VDO control fails
  drm/bridge: ps8640: Rework power state handling

 drivers/gpu/drm/bridge/parade-ps8640.c | 89 ++
 drivers/gpu/drm/drm_bridge_connector.c |  1 +
 2 files changed, 79 insertions(+), 11 deletions(-)

-- 
2.28.0

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


[PATCH v2 4/5] drm/bridge: ps8640: Print an error if VDO control fails

2020-08-27 Thread Enric Balletbo i Serra
Print an error message inside ps8640_bridge_vdo_control() function when
it fails so we can simplify a bit the callers, they will only need to
check the error code.

Reviewed-by: Sam Ravnborg 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2: None

 drivers/gpu/drm/bridge/parade-ps8640.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index ce3e8b2da8c9..9f7b7a9c53c5 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -82,8 +82,11 @@ static int ps8640_bridge_vdo_control(struct ps8640 
*ps_bridge,
ret = i2c_smbus_write_i2c_block_data(client, PAGE3_SET_ADD,
 sizeof(vdo_ctrl_buf),
 vdo_ctrl_buf);
-   if (ret < 0)
+   if (ret < 0) {
+   DRM_ERROR("failed to %sable VDO: %d\n",
+ ctrl == ENABLE ? "en" : "dis", ret);
return ret;
+   }
 
return 0;
 }
@@ -150,10 +153,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
}
 
ret = ps8640_bridge_vdo_control(ps_bridge, ENABLE);
-   if (ret) {
-   DRM_ERROR("failed to enable VDO: %d\n", ret);
+   if (ret)
goto err_regulators_disable;
-   }
 
/* Switch access edp panel's edid through i2c */
ret = i2c_smbus_write_byte_data(client, PAGE2_I2C_BYPASS,
@@ -175,9 +176,7 @@ static void ps8640_post_disable(struct drm_bridge *bridge)
struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
int ret;
 
-   ret = ps8640_bridge_vdo_control(ps_bridge, DISABLE);
-   if (ret < 0)
-   DRM_ERROR("failed to disable VDO: %d\n", ret);
+   ps8640_bridge_vdo_control(ps_bridge, DISABLE);
 
gpiod_set_value(ps_bridge->gpio_reset, 1);
gpiod_set_value(ps_bridge->gpio_powerdown, 1);
-- 
2.28.0

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


[RESEND PATCH v2 2/2] drm/mediatek: mtk_dpi: Convert to bridge driver

2020-08-27 Thread Enric Balletbo i Serra
Convert mtk_dpi to a bridge driver with built-in encoder support for
compatibility with existing component drivers.

Reviewed-by: Chun-Kuang Hu 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2:
- Maintain error message when attach to bridge fails. (Boris)

 drivers/gpu/drm/mediatek/mtk_dpi.c | 71 ++
 1 file changed, 42 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index f7372dbdac0e..589ef33a1780 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -64,6 +64,7 @@ enum mtk_dpi_out_color_format {
 struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
+   struct drm_bridge bridge;
struct drm_bridge *next_bridge;
void __iomem *regs;
struct device *dev;
@@ -83,9 +84,9 @@ struct mtk_dpi {
int refcount;
 };
 
-static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
+static inline struct mtk_dpi *bridge_to_dpi(struct drm_bridge *b)
 {
-   return container_of(e, struct mtk_dpi, encoder);
+   return container_of(b, struct mtk_dpi, bridge);
 }
 
 enum mtk_dpi_polarity {
@@ -521,50 +522,53 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
return 0;
 }
 
-static bool mtk_dpi_encoder_mode_fixup(struct drm_encoder *encoder,
-  const struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
+static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
 {
-   return true;
+   drm_encoder_cleanup(encoder);
 }
 
-static void mtk_dpi_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
+static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
+   .destroy = mtk_dpi_encoder_destroy,
+};
+
+static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+
+   return drm_bridge_attach(bridge->encoder, dpi->next_bridge,
+>bridge, flags);
+}
+
+static void mtk_dpi_bridge_mode_set(struct drm_bridge *bridge,
+   const struct drm_display_mode *mode,
+   const struct drm_display_mode *adjusted_mode)
+{
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
drm_mode_copy(>mode, adjusted_mode);
 }
 
-static void mtk_dpi_encoder_disable(struct drm_encoder *encoder)
+static void mtk_dpi_bridge_disable(struct drm_bridge *bridge)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
mtk_dpi_power_off(dpi);
 }
 
-static void mtk_dpi_encoder_enable(struct drm_encoder *encoder)
+static void mtk_dpi_bridge_enable(struct drm_bridge *bridge)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
mtk_dpi_power_on(dpi);
mtk_dpi_set_display_mode(dpi, >mode);
 }
 
-static int mtk_dpi_atomic_check(struct drm_encoder *encoder,
-   struct drm_crtc_state *crtc_state,
-   struct drm_connector_state *conn_state)
-{
-   return 0;
-}
-
-static const struct drm_encoder_helper_funcs mtk_dpi_encoder_helper_funcs = {
-   .mode_fixup = mtk_dpi_encoder_mode_fixup,
-   .mode_set = mtk_dpi_encoder_mode_set,
-   .disable = mtk_dpi_encoder_disable,
-   .enable = mtk_dpi_encoder_enable,
-   .atomic_check = mtk_dpi_atomic_check,
+static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
+   .attach = mtk_dpi_bridge_attach,
+   .mode_set = mtk_dpi_bridge_mode_set,
+   .disable = mtk_dpi_bridge_disable,
+   .enable = mtk_dpi_bridge_enable,
 };
 
 static void mtk_dpi_start(struct mtk_ddp_comp *comp)
@@ -605,12 +609,11 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
dev_err(dev, "Failed to initialize decoder: %d\n", ret);
goto err_unregister;
}
-   drm_encoder_helper_add(>encoder, _dpi_encoder_helper_funcs);
 
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
 
-   ret = drm_bridge_attach(>encoder, dpi->next_bridge, NULL, 0);
+   ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
if (ret) {
dev_err(dev, "Failed to attach bridge: %d\n", ret);
goto err_cleanup;
@@ -791,8 +794,15 @@ static int mtk_dpi_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, dpi);
 
+   dpi->bridge.func

[PATCH v2 5/5] drm/bridge: ps8640: Rework power state handling

2020-08-27 Thread Enric Balletbo i Serra
The get_edid() callback can be triggered anytime by an ioctl, i.e

  drm_mode_getconnector (ioctl)
-> drm_helper_probe_single_connector_modes
   -> drm_bridge_connector_get_modes
  -> ps8640_bridge_get_edid

Actually if the bridge pre_enable() function was not called before
get_edid(), the driver will not be able to get the EDID properly and
display will not work until a second get_edid() call is issued and if
pre_enable() is called before. The side effect of this, for example, is
that you see anything when `Frecon` starts, neither the splash screen,
until the graphical session manager starts.

To fix this we need to make sure that all we need is enabled before
reading the EDID. This means the following:

1. If get_edid() is called before having the device powered we need to
   power on the device. In such case, the driver will power off again the
   device.

2. If get_edid() is called after having the device powered, all should
   just work. We added a powered flag in order to avoid recurrent calls
   to ps8640_bridge_poweron() and unneeded delays.

3. This seems to be specific for this device, but we need to make sure
   the panel is powered on before do a power on cycle on this device.
   Otherwise the device fails to retrieve the EDID.

Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2:
- Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg)

 drivers/gpu/drm/bridge/parade-ps8640.c | 64 +++---
 1 file changed, 58 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 9f7b7a9c53c5..c5d76e209bda 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -65,6 +65,7 @@ struct ps8640 {
struct regulator_bulk_data supplies[2];
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_powerdown;
+   bool powered;
 };
 
 static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
@@ -91,13 +92,15 @@ static int ps8640_bridge_vdo_control(struct ps8640 
*ps_bridge,
return 0;
 }
 
-static void ps8640_pre_enable(struct drm_bridge *bridge)
+static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
 {
-   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
unsigned long timeout;
int ret, status;
 
+   if (ps_bridge->powered)
+   return;
+
ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
ps_bridge->supplies);
if (ret < 0) {
@@ -164,6 +167,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
goto err_regulators_disable;
}
 
+   ps_bridge->powered = true;
+
return;
 
 err_regulators_disable:
@@ -171,12 +176,12 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
   ps_bridge->supplies);
 }
 
-static void ps8640_post_disable(struct drm_bridge *bridge)
+static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
 {
-   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
int ret;
 
-   ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+   if (!ps_bridge->powered)
+   return;
 
gpiod_set_value(ps_bridge->gpio_reset, 1);
gpiod_set_value(ps_bridge->gpio_powerdown, 1);
@@ -184,6 +189,28 @@ static void ps8640_post_disable(struct drm_bridge *bridge)
 ps_bridge->supplies);
if (ret < 0)
DRM_ERROR("cannot disable regulators %d\n", ret);
+
+   ps_bridge->powered = false;
+}
+
+static void ps8640_pre_enable(struct drm_bridge *bridge)
+{
+   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+   int ret;
+
+   ps8640_bridge_poweron(ps_bridge);
+
+   ret = ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+   if (ret < 0)
+   ps8640_bridge_poweroff(ps_bridge);
+}
+
+static void ps8640_post_disable(struct drm_bridge *bridge)
+{
+   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+   ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+   ps8640_bridge_poweroff(ps_bridge);
 }
 
 static int ps8640_bridge_attach(struct drm_bridge *bridge,
@@ -249,9 +276,34 @@ static struct edid *ps8640_bridge_get_edid(struct 
drm_bridge *bridge,
   struct drm_connector *connector)
 {
struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+   bool poweroff = !ps_bridge->powered;
+   struct edid *edid;
+
+   /*
+* When we end calling get_edid() triggered by an ioctl, i.e
+*
+*   drm_mode_getconnector (ioctl)
+* -> drm_helper_probe_single_connector_modes
+*-> drm_bridge_connector_get_modes
+*   -> ps8640_bridge_get_edid
+*
+* We need

[RESEND PATCH v2 1/2] drm/mediatek: mtk_dpi: Rename bridge to next_bridge

2020-08-27 Thread Enric Balletbo i Serra
This is really a cosmetic change just to make a bit more readable the
code after convert the driver to drm_bridge. The bridge variable name
will be used by the encoder drm_bridge, and the chained bridge will be
named next_bridge.

Reviewed-by: Chun-Kuang Hu 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2: None

 drivers/gpu/drm/mediatek/mtk_dpi.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index d4f0fb7ad312..f7372dbdac0e 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -64,7 +64,7 @@ enum mtk_dpi_out_color_format {
 struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
-   struct drm_bridge *bridge;
+   struct drm_bridge *next_bridge;
void __iomem *regs;
struct device *dev;
struct clk *engine_clk;
@@ -610,7 +610,7 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
 
-   ret = drm_bridge_attach(>encoder, dpi->bridge, NULL, 0);
+   ret = drm_bridge_attach(>encoder, dpi->next_bridge, NULL, 0);
if (ret) {
dev_err(dev, "Failed to attach bridge: %d\n", ret);
goto err_cleanup;
@@ -770,11 +770,11 @@ static int mtk_dpi_probe(struct platform_device *pdev)
}
 
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
- NULL, >bridge);
+ NULL, >next_bridge);
if (ret)
return ret;
 
-   dev_info(dev, "Found bridge node: %pOF\n", dpi->bridge->of_node);
+   dev_info(dev, "Found bridge node: %pOF\n", dpi->next_bridge->of_node);
 
comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DPI);
if (comp_id < 0) {
-- 
2.28.0

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


[PATCH v2 1/5] drm/bridge_connector: Set default status connected for eDP connectors

2020-08-27 Thread Enric Balletbo i Serra
In an eDP application, HPD is not required and on most bridge chips
useless. If HPD is not used, we need to set initial status as connected,
otherwise the connector created by the drm_bridge_connector API remains
in an unknown state.

Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2:
- Included the patch `drm/bridge_connector: Set default status connected for 
eDP connectors`

 drivers/gpu/drm/drm_bridge_connector.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_bridge_connector.c 
b/drivers/gpu/drm/drm_bridge_connector.c
index c6994fe673f3..a58cbde59c34 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -187,6 +187,7 @@ drm_bridge_connector_detect(struct drm_connector 
*connector, bool force)
case DRM_MODE_CONNECTOR_DPI:
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_DSI:
+   case DRM_MODE_CONNECTOR_eDP:
status = connector_status_connected;
break;
default:
-- 
2.28.0

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


Re: [PATCH 3/3] drm/bridge: ps8640: Rework power state handling

2020-08-22 Thread Enric Balletbo i Serra
Dear drm_bridge maintainers,

It's been a while since I send these patches, and I'd like to find a proper
solution.

On 25/6/20 11:21, Enric Balletbo i Serra wrote:
> Hi Sam,
> 
> On 24/6/20 9:07, Sam Ravnborg wrote:
>> Hi Enric.
>>
>> On Tue, Jun 23, 2020 at 05:16:43PM +0200, Enric Balletbo i Serra wrote:
>>> Hi Sam,
>>>
>>> Many thanks for your feedback. See my answers below.
>>>
>>> On 20/6/20 23:42, Sam Ravnborg wrote:
>>>> Hi Enric.
>>>>
>>>> On Mon, Jun 15, 2020 at 10:53:20PM +0200, Enric Balletbo i Serra wrote:
>>>>> The get_edid() callback can be triggered anytime by an ioctl, i.e
>>>>>
>>>>>   drm_mode_getconnector (ioctl)
>>>>> -> drm_helper_probe_single_connector_modes
>>>>>-> drm_bridge_connector_get_modes
>>>>>   -> ps8640_bridge_get_edid
>>>>>
>>>>> Actually if the bridge pre_enable() function was not called before
>>>>> get_edid(), the driver will not be able to get the EDID properly and
>>>>> display will not work until a second get_edid() call is issued and if
>>>>> pre_enable() is called before.
>>>> Is it correct to fix this in the driver?
>>>> Why not just fail and tell user-sapce to try again later?
>>>> (Dunno what error-code to use - there must be one).
>>>>
>>>
>>> My undestanding, I might be wrong, is that userspace should don't know which
>>> bits, regulators, etc, are needed to get the EDID with an ioctl. Is the 
>>> kernel
>>> that should make sure that all is set properly (the required regulators, 
>>> etc)
>>> when userspace wants to read the EDID.
>>
>> The idea I suggest is that the kernel side should just error
>> out and let user-space retry later.
> 
> I see, I got it.
> 
>> So we avoid all the extra logic in the kernel because userspace wants
>> info before the HW is ready.
>> And userspace shall anyway deal with the ioctl that fails.
>>
> 
> My doubt here is, at which point the kernel driver should leave the hardware 
> in
> a state that getting the EDID should work? After the bridge pre_enable() or
> enable() calls? After has been proved? AFAIK the bridge pre_enable() and
> enable() calls are only about enable the stream out and in most cases you can
> get the EDID without having to call pre_enable() and enable() before.
> 

Let me reformulate the question for if it was not clear.

What I did is be able to read the EDID every time userspace asks for it (so
kernel enables all the required) and Sam is proposing to just fail if all is not
setup. I can obviously do this but my question is, at which point I should leave
all the logic enabled to be able to read the EDID (after probe?, after
pre_enable, after enable?) It is not clear for me from the API.

Thanks,
 Enric


> Thanks,
>  Enric
> 
> 
>>  Sam
>>
>>>
>>>> Then we avoid complicating drivers fro somethign we really should
>>>> fix in user-space.
>>>>
>>>>> The side effect of this, for example, is
>>>>> that you see anything when `Frecon` starts, neither the splash screen,
>>>> that you do not see ...
>>>>
>>>> (Otherwise I do not parse the above).
>>>>
>>>>> until the graphical session manager starts.
>>>>>
>>>>> To fix this we need to make sure that all we need is enabled before
>>>>> reading the EDID. This means the following:
>>>>>
>>>>> 1. If get_edid() is called before having the device powered we need to
>>>>>power on the device. In such case, the driver will power off again the
>>>>>device.
>>>>>
>>>>> 2. If get_edid() is called after having the device powered, all should
>>>>>just work. We added a powered flag in order to avoid recurrent calls
>>>>>to ps8640_bridge_poweron() and unneeded delays.
>>>>>
>>>>> 3. This seems to be specific for this device, but we need to make sure
>>>>>the panel is powered on before do a power on cycle on this device.
>>>>>Otherwise the device fails to retrieve the EDID.
>>>> Step 3. looks like an ugly hack too
>>>>
>>>
>>> It is, but I don't have enough hardware details to be able to answer why we 
>>> need
>>> to do this. What is well tested is that, if I don't power the panel before
>>> powering on the bridge,

[PATCH v2 1/2] drm/mediatek: mtk_dpi: Rename bridge to next_bridge

2020-07-10 Thread Enric Balletbo i Serra
This is really a cosmetic change just to make a bit more readable the
code after convert the driver to drm_bridge. The bridge variable name
will be used by the encoder drm_bridge, and the chained bridge will be
named next_bridge.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Chun-Kuang Hu 
---

Changes in v2: None

 drivers/gpu/drm/mediatek/mtk_dpi.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index d4f0fb7ad312..f7372dbdac0e 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -64,7 +64,7 @@ enum mtk_dpi_out_color_format {
 struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
-   struct drm_bridge *bridge;
+   struct drm_bridge *next_bridge;
void __iomem *regs;
struct device *dev;
struct clk *engine_clk;
@@ -610,7 +610,7 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
 
-   ret = drm_bridge_attach(>encoder, dpi->bridge, NULL, 0);
+   ret = drm_bridge_attach(>encoder, dpi->next_bridge, NULL, 0);
if (ret) {
dev_err(dev, "Failed to attach bridge: %d\n", ret);
goto err_cleanup;
@@ -770,11 +770,11 @@ static int mtk_dpi_probe(struct platform_device *pdev)
}
 
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
- NULL, >bridge);
+ NULL, >next_bridge);
if (ret)
return ret;
 
-   dev_info(dev, "Found bridge node: %pOF\n", dpi->bridge->of_node);
+   dev_info(dev, "Found bridge node: %pOF\n", dpi->next_bridge->of_node);
 
comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DPI);
if (comp_id < 0) {
-- 
2.27.0

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


[PATCH v2 2/2] drm/mediatek: mtk_dpi: Convert to bridge driver

2020-07-10 Thread Enric Balletbo i Serra
Convert mtk_dpi to a bridge driver with built-in encoder support for
compatibility with existing component drivers.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Chun-Kuang Hu 
---

Changes in v2:
- Maintain error message when attach to bridge fails. (Boris)

 drivers/gpu/drm/mediatek/mtk_dpi.c | 71 ++
 1 file changed, 42 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index f7372dbdac0e..589ef33a1780 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -64,6 +64,7 @@ enum mtk_dpi_out_color_format {
 struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
+   struct drm_bridge bridge;
struct drm_bridge *next_bridge;
void __iomem *regs;
struct device *dev;
@@ -83,9 +84,9 @@ struct mtk_dpi {
int refcount;
 };
 
-static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
+static inline struct mtk_dpi *bridge_to_dpi(struct drm_bridge *b)
 {
-   return container_of(e, struct mtk_dpi, encoder);
+   return container_of(b, struct mtk_dpi, bridge);
 }
 
 enum mtk_dpi_polarity {
@@ -521,50 +522,53 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
return 0;
 }
 
-static bool mtk_dpi_encoder_mode_fixup(struct drm_encoder *encoder,
-  const struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
+static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
 {
-   return true;
+   drm_encoder_cleanup(encoder);
 }
 
-static void mtk_dpi_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
+static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
+   .destroy = mtk_dpi_encoder_destroy,
+};
+
+static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+
+   return drm_bridge_attach(bridge->encoder, dpi->next_bridge,
+>bridge, flags);
+}
+
+static void mtk_dpi_bridge_mode_set(struct drm_bridge *bridge,
+   const struct drm_display_mode *mode,
+   const struct drm_display_mode *adjusted_mode)
+{
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
drm_mode_copy(>mode, adjusted_mode);
 }
 
-static void mtk_dpi_encoder_disable(struct drm_encoder *encoder)
+static void mtk_dpi_bridge_disable(struct drm_bridge *bridge)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
mtk_dpi_power_off(dpi);
 }
 
-static void mtk_dpi_encoder_enable(struct drm_encoder *encoder)
+static void mtk_dpi_bridge_enable(struct drm_bridge *bridge)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
mtk_dpi_power_on(dpi);
mtk_dpi_set_display_mode(dpi, >mode);
 }
 
-static int mtk_dpi_atomic_check(struct drm_encoder *encoder,
-   struct drm_crtc_state *crtc_state,
-   struct drm_connector_state *conn_state)
-{
-   return 0;
-}
-
-static const struct drm_encoder_helper_funcs mtk_dpi_encoder_helper_funcs = {
-   .mode_fixup = mtk_dpi_encoder_mode_fixup,
-   .mode_set = mtk_dpi_encoder_mode_set,
-   .disable = mtk_dpi_encoder_disable,
-   .enable = mtk_dpi_encoder_enable,
-   .atomic_check = mtk_dpi_atomic_check,
+static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
+   .attach = mtk_dpi_bridge_attach,
+   .mode_set = mtk_dpi_bridge_mode_set,
+   .disable = mtk_dpi_bridge_disable,
+   .enable = mtk_dpi_bridge_enable,
 };
 
 static void mtk_dpi_start(struct mtk_ddp_comp *comp)
@@ -605,12 +609,11 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
dev_err(dev, "Failed to initialize decoder: %d\n", ret);
goto err_unregister;
}
-   drm_encoder_helper_add(>encoder, _dpi_encoder_helper_funcs);
 
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
 
-   ret = drm_bridge_attach(>encoder, dpi->next_bridge, NULL, 0);
+   ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
if (ret) {
dev_err(dev, "Failed to attach bridge: %d\n", ret);
goto err_cleanup;
@@ -791,8 +794,15 @@ static int mtk_dpi_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, dpi);
 
+   dpi->bridge.func

Re: [RESEND PATCH 3/3] drm/mediatek: mtk_dpi: Use simple encoder

2020-07-10 Thread Enric Balletbo i Serra
Hi again,

On 8/7/20 17:12, Enric Balletbo i Serra wrote:
> Hi Boris,
> 
> Thank you to spend some time to review the patches.
> 
> On 1/7/20 13:41, Boris Brezillon wrote:
>> On Mon, 18 May 2020 19:39:09 +0200
>> Enric Balletbo i Serra  wrote:
>>
>>> The mtk_dpi driver uses an empty implementation for its encoder. Replace
>>> the code with the generic simple encoder.
>>>
>>> Signed-off-by: Enric Balletbo i Serra 
>>> Reviewed-by: Chun-Kuang Hu 
>>> ---
>>>
>>>  drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++---
>>>  1 file changed, 3 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
>>> b/drivers/gpu/drm/mediatek/mtk_dpi.c
>>> index baad198c69eb..80778b2aac2a 100644
>>> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
>>> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
>>> @@ -20,6 +20,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  
>>>  #include "mtk_dpi_regs.h"
>>>  #include "mtk_drm_ddp_comp.h"
>>> @@ -510,15 +511,6 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi 
>>> *dpi,
>>> return 0;
>>>  }
>>>  
>>> -static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
>>> -{
>>> -   drm_encoder_cleanup(encoder);
>>> -}
>>> -
>>> -static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
>>> -   .destroy = mtk_dpi_encoder_destroy,
>>> -};
>>> -
>>>  static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
>>>  enum drm_bridge_attach_flags flags)
>>>  {
>>> @@ -591,8 +583,8 @@ static int mtk_dpi_bind(struct device *dev, struct 
>>> device *master, void *data)
>>> return ret;
>>> }
>>>  
>>> -   ret = drm_encoder_init(drm_dev, >encoder, _dpi_encoder_funcs,
>>> -  DRM_MODE_ENCODER_TMDS, NULL);
>>> +   ret = drm_simple_encoder_init(drm_dev, >encoder,
>>> + DRM_MODE_ENCODER_TMDS);
>>
>> Not related to this change, but shouldn't we have DRM_MODE_ENCODER_DPI
>> here?
>>
> 

Thinking a bit more about this and this patchset in general, I think I'll drop
this patch from the series, at the end, all the encoder creation stuff should be
moved to mtk_drm_drv.


> Right, I'll add a patch to fix this.
> 
>>> if (ret) {
>>> dev_err(dev, "Failed to initialize decoder: %d\n", ret);
>>> goto err_unregister;
>>
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 0/2] Convert mtk-dpi to drm_bridge API

2020-07-10 Thread Enric Balletbo i Serra
The mtk-dpi driver still uses the drm_encoder API which is now somewhat
deprecated. We started to move all the Mediatek drivers to the drm_bridge API,
like we did for the mtk-dsi driver [1], this is another small step to be able to
fully convert the DRM Mediatek drivers to the drm_bridge API. A dummy
drm_encoder is maintained in the mtk-dpi driver but the end goal is move all the
dummy drm_encoder (mtk-dsi, mtk-dpi, etc) to the main mtk_drm_drv driver.

[1] https://lore.kernel.org/patchwork/project/lkml/list/?series=441559

Changes in v2:
- Maintain error message when attach to bridge fails. (Boris)
- Drop the third patch.

Enric Balletbo i Serra (2):
  drm/mediatek: mtk_dpi: Rename bridge to next_bridge
  drm/mediatek: mtk_dpi: Convert to bridge driver

 drivers/gpu/drm/mediatek/mtk_dpi.c | 77 +-
 1 file changed, 45 insertions(+), 32 deletions(-)

-- 
2.27.0

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


Re: [RESEND PATCH 3/3] drm/mediatek: mtk_dpi: Use simple encoder

2020-07-09 Thread Enric Balletbo i Serra
Hi Boris,

Thank you to spend some time to review the patches.

On 1/7/20 13:41, Boris Brezillon wrote:
> On Mon, 18 May 2020 19:39:09 +0200
> Enric Balletbo i Serra  wrote:
> 
>> The mtk_dpi driver uses an empty implementation for its encoder. Replace
>> the code with the generic simple encoder.
>>
>> Signed-off-by: Enric Balletbo i Serra 
>> Reviewed-by: Chun-Kuang Hu 
>> ---
>>
>>  drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++---
>>  1 file changed, 3 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
>> b/drivers/gpu/drm/mediatek/mtk_dpi.c
>> index baad198c69eb..80778b2aac2a 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
>> @@ -20,6 +20,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include "mtk_dpi_regs.h"
>>  #include "mtk_drm_ddp_comp.h"
>> @@ -510,15 +511,6 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
>>  return 0;
>>  }
>>  
>> -static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
>> -{
>> -drm_encoder_cleanup(encoder);
>> -}
>> -
>> -static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
>> -.destroy = mtk_dpi_encoder_destroy,
>> -};
>> -
>>  static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
>>   enum drm_bridge_attach_flags flags)
>>  {
>> @@ -591,8 +583,8 @@ static int mtk_dpi_bind(struct device *dev, struct 
>> device *master, void *data)
>>  return ret;
>>  }
>>  
>> -ret = drm_encoder_init(drm_dev, >encoder, _dpi_encoder_funcs,
>> -   DRM_MODE_ENCODER_TMDS, NULL);
>> +ret = drm_simple_encoder_init(drm_dev, >encoder,
>> +  DRM_MODE_ENCODER_TMDS);
> 
> Not related to this change, but shouldn't we have DRM_MODE_ENCODER_DPI
> here?
> 

Right, I'll add a patch to fix this.

>>  if (ret) {
>>  dev_err(dev, "Failed to initialize decoder: %d\n", ret);
>>  goto err_unregister;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RESEND PATCH 2/3] drm/mediatek: mtk_dpi: Convert to bridge driver

2020-07-09 Thread Enric Balletbo i Serra
Hi Boris,

Thank you for review the patch.

On 1/7/20 13:51, Boris Brezillon wrote:
> On Mon, 18 May 2020 19:39:08 +0200
> Enric Balletbo i Serra  wrote:
> 
>> Convert mtk_dpi to a bridge driver with built-in encoder support for
>> compatibility with existing component drivers.
>>
>> Signed-off-by: Enric Balletbo i Serra 
>> Reviewed-by: Chun-Kuang Hu 
>> ---
>>
>>  drivers/gpu/drm/mediatek/mtk_dpi.c | 66 +++---
>>  1 file changed, 34 insertions(+), 32 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
>> b/drivers/gpu/drm/mediatek/mtk_dpi.c
>> index 7112125dc3d1..baad198c69eb 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
>> @@ -61,6 +61,7 @@ enum mtk_dpi_out_color_format {
>>  struct mtk_dpi {
>>  struct mtk_ddp_comp ddp_comp;
>>  struct drm_encoder encoder;
>> +struct drm_bridge bridge;
>>  struct drm_bridge *next_bridge;
>>  void __iomem *regs;
>>  struct device *dev;
>> @@ -77,9 +78,9 @@ struct mtk_dpi {
>>  int refcount;
>>  };
>>  
>> -static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
>> +static inline struct mtk_dpi *bridge_to_dpi(struct drm_bridge *b)
>>  {
>> -return container_of(e, struct mtk_dpi, encoder);
>> +return container_of(b, struct mtk_dpi, bridge);
>>  }
>>  
>>  enum mtk_dpi_polarity {
>> @@ -518,50 +519,44 @@ static const struct drm_encoder_funcs 
>> mtk_dpi_encoder_funcs = {
>>  .destroy = mtk_dpi_encoder_destroy,
>>  };
>>  
>> -static bool mtk_dpi_encoder_mode_fixup(struct drm_encoder *encoder,
>> -   const struct drm_display_mode *mode,
>> -   struct drm_display_mode *adjusted_mode)
>> +static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
>> + enum drm_bridge_attach_flags flags)
>>  {
>> -return true;
>> +struct mtk_dpi *dpi = bridge_to_dpi(bridge);
>> +
>> +return drm_bridge_attach(bridge->encoder, dpi->next_bridge,
>> + >bridge, flags);
>>  }
>>  
>> -static void mtk_dpi_encoder_mode_set(struct drm_encoder *encoder,
>> - struct drm_display_mode *mode,
>> - struct drm_display_mode *adjusted_mode)
>> +static void mtk_dpi_bridge_mode_set(struct drm_bridge *bridge,
>> +const struct drm_display_mode *mode,
>> +const struct drm_display_mode *adjusted_mode)
>>  {
>> -struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
>> +struct mtk_dpi *dpi = bridge_to_dpi(bridge);
>>  
>>  drm_mode_copy(>mode, adjusted_mode);
>>  }
>>  
>> -static void mtk_dpi_encoder_disable(struct drm_encoder *encoder)
>> +static void mtk_dpi_bridge_disable(struct drm_bridge *bridge)
>>  {
>> -struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
>> +struct mtk_dpi *dpi = bridge_to_dpi(bridge);
>>  
>>  mtk_dpi_power_off(dpi);
>>  }
>>  
>> -static void mtk_dpi_encoder_enable(struct drm_encoder *encoder)
>> +static void mtk_dpi_bridge_enable(struct drm_bridge *bridge)
>>  {
>> -struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
>> +struct mtk_dpi *dpi = bridge_to_dpi(bridge);
>>  
>>  mtk_dpi_power_on(dpi);
>>  mtk_dpi_set_display_mode(dpi, >mode);
>>  }
>>  
>> -static int mtk_dpi_atomic_check(struct drm_encoder *encoder,
>> -struct drm_crtc_state *crtc_state,
>> -struct drm_connector_state *conn_state)
>> -{
>> -return 0;
>> -}
>> -
>> -static const struct drm_encoder_helper_funcs mtk_dpi_encoder_helper_funcs = 
>> {
>> -.mode_fixup = mtk_dpi_encoder_mode_fixup,
>> -.mode_set = mtk_dpi_encoder_mode_set,
>> -.disable = mtk_dpi_encoder_disable,
>> -.enable = mtk_dpi_encoder_enable,
>> -.atomic_check = mtk_dpi_atomic_check,
>> +static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
>> +.attach = mtk_dpi_bridge_attach,
>> +.mode_set = mtk_dpi_bridge_mode_set,
>> +.disable = mtk_dpi_bridge_disable,
>> +.enable = mtk_dpi_bridge_enable,
>>  };
>>  
>>  static void mtk_dpi_start(struct mtk_ddp_comp *comp)
>> @@ -602,16 +597,13 @@ static int mtk_dpi_bind(struct device *dev, struct 
>> device *master, voi

Re: [RESEND PATCH v4 0/7] Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge

2020-07-01 Thread Enric Balletbo i Serra
Hi Sam, Chun-Kuan,

On 20/6/20 23:33, Sam Ravnborg wrote:
> Hi Enric
> 
> On Mon, Jun 15, 2020 at 10:31:01PM +0200, Enric Balletbo i Serra wrote:
>> (This resend is to fix some trivial conflicts due the merge window)
>>
>> The PS8640 dsi-to-eDP bridge driver is using the panel bridge API,
>> however, not all the components in the chain have been ported to the
>> drm_bridge API. Actually, when a panel is attached the default panel's mode
>> is used, but in some cases we can't get display up if mode getting from
>> eDP control EDID is not chosen.
>>
>> This series address that problem, first implements the .get_edid()
>> callback in the PS8640 driver (which is not used until the conversion is
>> done) and then, converts the Mediatek DSI driver to use the drm_bridge
>> API.
>>
>> As far as I know, we're the only users of the mediatek dsi driver in
>> mainline, so should be safe to switch to the new chain of drm_bridge API
>> unconditionally.
>>
>> The patches has been tested on a Acer Chromebook R13 (Elm) running a
>> Chrome OS userspace and checking that the valid EDID mode reported by
>> the bridge is selected.
>>
>> Changes in v4:
>> - Remove double call to drm_encoder_init(). (Chun-Kuang Hu)
>> - Cleanup the encoder in mtk_dsi_unbind(). (Chun-Kuang Hu)
>>
>> Changes in v3:
>> - Replace s/bridge/next bridge/ for comment. (Laurent Pinchart)
>> - Add the bridge.type. (Laurent Pinchart)
>> - Use next_bridge field to store the panel bridge. (Laurent Pinchart)
>> - Add the bridge.type field. (Laurent Pinchart)
>> - This patch requires https://lkml.org/lkml/2020/4/16/2080 to work
>>   properly.
>> - Move the bridge.type line to the patch that adds drm_bridge support. 
>> (Laurent Pinchart)
>>
>> Changes in v2:
>> - Do not set connector_type for panel here. (Sam Ravnborg)
>>
>> Enric Balletbo i Serra (7):
>>   drm/bridge: ps8640: Get the EDID from eDP control
>>   drm/bridge_connector: Set default status connected for eDP connectors
>>   drm/mediatek: mtk_dsi: Rename bridge to next_bridge
>>   drm/mediatek: mtk_dsi: Convert to bridge driver
>>   drm/mediatek: mtk_dsi: Use simple encoder
>>   drm/mediatek: mtk_dsi: Use the drm_panel_bridge API
>>   drm/mediatek: mtk_dsi: Create connector for bridges
> 
> Patch seems ready to apply. Will they be applied to a mediatek tree
> or to drm-misc-next?
> Or shall we take the first two patches via drm-misc-next, and the
> remaning via a mediatek tree? (I hope not)
> 

I think the only concern is from Chun-Kuan regarding patch 7/7 "drm/mediatek:
mtk_dsi: Create connector for bridges" whether we should support the old API or
not, but the discussion stalled.

Thanks,
 Enric



>   Sam
> 
> 
>>
>>  drivers/gpu/drm/bridge/parade-ps8640.c |  12 ++
>>  drivers/gpu/drm/drm_bridge_connector.c |   1 +
>>  drivers/gpu/drm/mediatek/mtk_dsi.c | 269 -
>>  3 files changed, 97 insertions(+), 185 deletions(-)
>>
>> -- 
>> 2.27.0
>>
>> ___
>> 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: [RESEND PATCH v4 0/7] Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge

2020-07-01 Thread Enric Balletbo i Serra
Hi Chun-Kuang,

On 30/6/20 18:26, Chun-Kuang Hu wrote:
> Hi, Enric:
> 
> Enric Balletbo i Serra  於 2020年6月30日 週二 
> 下午10:34寫道:
>>
>> Hi Sam, Chun-Kuan,
>>
>> On 20/6/20 23:33, Sam Ravnborg wrote:
>>> Hi Enric
>>>
>>> On Mon, Jun 15, 2020 at 10:31:01PM +0200, Enric Balletbo i Serra wrote:
>>>> (This resend is to fix some trivial conflicts due the merge window)
>>>>
>>>> The PS8640 dsi-to-eDP bridge driver is using the panel bridge API,
>>>> however, not all the components in the chain have been ported to the
>>>> drm_bridge API. Actually, when a panel is attached the default panel's mode
>>>> is used, but in some cases we can't get display up if mode getting from
>>>> eDP control EDID is not chosen.
>>>>
>>>> This series address that problem, first implements the .get_edid()
>>>> callback in the PS8640 driver (which is not used until the conversion is
>>>> done) and then, converts the Mediatek DSI driver to use the drm_bridge
>>>> API.
>>>>
>>>> As far as I know, we're the only users of the mediatek dsi driver in
>>>> mainline, so should be safe to switch to the new chain of drm_bridge API
>>>> unconditionally.
>>>>
>>>> The patches has been tested on a Acer Chromebook R13 (Elm) running a
>>>> Chrome OS userspace and checking that the valid EDID mode reported by
>>>> the bridge is selected.
>>>>
>>>> Changes in v4:
>>>> - Remove double call to drm_encoder_init(). (Chun-Kuang Hu)
>>>> - Cleanup the encoder in mtk_dsi_unbind(). (Chun-Kuang Hu)
>>>>
>>>> Changes in v3:
>>>> - Replace s/bridge/next bridge/ for comment. (Laurent Pinchart)
>>>> - Add the bridge.type. (Laurent Pinchart)
>>>> - Use next_bridge field to store the panel bridge. (Laurent Pinchart)
>>>> - Add the bridge.type field. (Laurent Pinchart)
>>>> - This patch requires https://lkml.org/lkml/2020/4/16/2080 to work
>>>>   properly.
>>>> - Move the bridge.type line to the patch that adds drm_bridge support. 
>>>> (Laurent Pinchart)
>>>>
>>>> Changes in v2:
>>>> - Do not set connector_type for panel here. (Sam Ravnborg)
>>>>
>>>> Enric Balletbo i Serra (7):
>>>>   drm/bridge: ps8640: Get the EDID from eDP control
>>>>   drm/bridge_connector: Set default status connected for eDP connectors
>>>>   drm/mediatek: mtk_dsi: Rename bridge to next_bridge
>>>>   drm/mediatek: mtk_dsi: Convert to bridge driver
>>>>   drm/mediatek: mtk_dsi: Use simple encoder
>>>>   drm/mediatek: mtk_dsi: Use the drm_panel_bridge API
>>>>   drm/mediatek: mtk_dsi: Create connector for bridges
>>>
>>> Patch seems ready to apply. Will they be applied to a mediatek tree
>>> or to drm-misc-next?
>>> Or shall we take the first two patches via drm-misc-next, and the
>>> remaning via a mediatek tree? (I hope not)
>>>
>>
>> I think the only concern is from Chun-Kuan regarding patch 7/7 "drm/mediatek:
>> mtk_dsi: Create connector for bridges" whether we should support the old API 
>> or
>> not, but the discussion stalled.
>>
> 
> I get more clear now. In patch 7/7,
> 
> ret = drm_bridge_attach(>encoder, >bridge, NULL,
> DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> 
> this would call into mtk_dsi_bridge_attach() first, and then call into
> panel_bridge_attach() next. So panel_bridge_attach() would receive
> DRM_BRIDGE_ATTACH_NO_CONNECTOR and it return immediately so it does
> not call drm_panel_attach(). So where do you call drm_panel_attach()?
> 

Why I need to call drm_panel_attach?

I believe drm_panel_attach() was to attach a panel to a connector, but we don't
need to do this with the new API as the connector is already created and
attached to the "dummy" encoder.

Makes that sense to you? What do you think will not work if I don't call
drm_panel_attach?

[1]
https://elixir.bootlin.com/linux/v5.8-rc3/source/drivers/gpu/drm/drm_panel.c#L101

Regards,
 Enric


> Regards,
> Chun-Kuang.
> 
>> Thanks,
>>  Enric
>>
>>
>>
>>>   Sam
>>>
>>>
>>>>
>>>>  drivers/gpu/drm/bridge/parade-ps8640.c |  12 ++
>>>>  drivers/gpu/drm/drm_bridge_connector.c |   1 +
>>>>  drivers/gpu/drm/mediatek/mtk_dsi.c | 269 -
>>>>  3 files changed, 97 insertions(+), 185 deletions(-)
>>>>
>>>> --
>>>> 2.27.0
>>>>
>>>> ___
>>>> 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 3/3] drm/bridge: ps8640: Rework power state handling

2020-06-26 Thread Enric Balletbo i Serra
Hi Sam,

On 24/6/20 9:07, Sam Ravnborg wrote:
> Hi Enric.
> 
> On Tue, Jun 23, 2020 at 05:16:43PM +0200, Enric Balletbo i Serra wrote:
>> Hi Sam,
>>
>> Many thanks for your feedback. See my answers below.
>>
>> On 20/6/20 23:42, Sam Ravnborg wrote:
>>> Hi Enric.
>>>
>>> On Mon, Jun 15, 2020 at 10:53:20PM +0200, Enric Balletbo i Serra wrote:
>>>> The get_edid() callback can be triggered anytime by an ioctl, i.e
>>>>
>>>>   drm_mode_getconnector (ioctl)
>>>> -> drm_helper_probe_single_connector_modes
>>>>-> drm_bridge_connector_get_modes
>>>>   -> ps8640_bridge_get_edid
>>>>
>>>> Actually if the bridge pre_enable() function was not called before
>>>> get_edid(), the driver will not be able to get the EDID properly and
>>>> display will not work until a second get_edid() call is issued and if
>>>> pre_enable() is called before.
>>> Is it correct to fix this in the driver?
>>> Why not just fail and tell user-sapce to try again later?
>>> (Dunno what error-code to use - there must be one).
>>>
>>
>> My undestanding, I might be wrong, is that userspace should don't know which
>> bits, regulators, etc, are needed to get the EDID with an ioctl. Is the 
>> kernel
>> that should make sure that all is set properly (the required regulators, etc)
>> when userspace wants to read the EDID.
> 
> The idea I suggest is that the kernel side should just error
> out and let user-space retry later.

I see, I got it.

> So we avoid all the extra logic in the kernel because userspace wants
> info before the HW is ready.
> And userspace shall anyway deal with the ioctl that fails.
> 

My doubt here is, at which point the kernel driver should leave the hardware in
a state that getting the EDID should work? After the bridge pre_enable() or
enable() calls? After has been proved? AFAIK the bridge pre_enable() and
enable() calls are only about enable the stream out and in most cases you can
get the EDID without having to call pre_enable() and enable() before.

Thanks,
 Enric


>   Sam
> 
>>
>>> Then we avoid complicating drivers fro somethign we really should
>>> fix in user-space.
>>>
>>>> The side effect of this, for example, is
>>>> that you see anything when `Frecon` starts, neither the splash screen,
>>> that you do not see ...
>>>
>>> (Otherwise I do not parse the above).
>>>
>>>> until the graphical session manager starts.
>>>>
>>>> To fix this we need to make sure that all we need is enabled before
>>>> reading the EDID. This means the following:
>>>>
>>>> 1. If get_edid() is called before having the device powered we need to
>>>>power on the device. In such case, the driver will power off again the
>>>>device.
>>>>
>>>> 2. If get_edid() is called after having the device powered, all should
>>>>just work. We added a powered flag in order to avoid recurrent calls
>>>>to ps8640_bridge_poweron() and unneeded delays.
>>>>
>>>> 3. This seems to be specific for this device, but we need to make sure
>>>>the panel is powered on before do a power on cycle on this device.
>>>>Otherwise the device fails to retrieve the EDID.
>>> Step 3. looks like an ugly hack too
>>>
>>
>> It is, but I don't have enough hardware details to be able to answer why we 
>> need
>> to do this. What is well tested is that, if I don't power the panel before
>> powering on the bridge, it doesn't get a proper EDID. Seems that when the 
>> bridge
>> goes up, the firmware tries to read the EDID and caches somehow. Well not 
>> sure.
>>
>>>>
>>>> Signed-off-by: Enric Balletbo i Serra 
>>>> ---
>>>>
>>>>  drivers/gpu/drm/bridge/parade-ps8640.c | 79 --
>>>>  1 file changed, 73 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
>>>> b/drivers/gpu/drm/bridge/parade-ps8640.c
>>>> index 9f7b7a9c53c52..ca651480891df 100644
>>>> --- a/drivers/gpu/drm/bridge/parade-ps8640.c
>>>> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
>>>> @@ -65,6 +65,7 @@ struct ps8640 {
>>>>struct regulator_bulk_data supplies[2];
>>>>struct gpio_desc *gpio_reset;
>>>>struct gpio_desc *gpio_powerdown;
>>>> +  bool powe

Re: [PATCH 3/3] drm/bridge: ps8640: Rework power state handling

2020-06-24 Thread Enric Balletbo i Serra
Hi Sam,

Many thanks for your feedback. See my answers below.

On 20/6/20 23:42, Sam Ravnborg wrote:
> Hi Enric.
> 
> On Mon, Jun 15, 2020 at 10:53:20PM +0200, Enric Balletbo i Serra wrote:
>> The get_edid() callback can be triggered anytime by an ioctl, i.e
>>
>>   drm_mode_getconnector (ioctl)
>> -> drm_helper_probe_single_connector_modes
>>-> drm_bridge_connector_get_modes
>>   -> ps8640_bridge_get_edid
>>
>> Actually if the bridge pre_enable() function was not called before
>> get_edid(), the driver will not be able to get the EDID properly and
>> display will not work until a second get_edid() call is issued and if
>> pre_enable() is called before.
> Is it correct to fix this in the driver?
> Why not just fail and tell user-sapce to try again later?
> (Dunno what error-code to use - there must be one).
> 

My undestanding, I might be wrong, is that userspace should don't know which
bits, regulators, etc, are needed to get the EDID with an ioctl. Is the kernel
that should make sure that all is set properly (the required regulators, etc)
when userspace wants to read the EDID.

> Then we avoid complicating drivers fro somethign we really should
> fix in user-space.
> 
>> The side effect of this, for example, is
>> that you see anything when `Frecon` starts, neither the splash screen,
> that you do not see ...
> 
> (Otherwise I do not parse the above).
> 
>> until the graphical session manager starts.
>>
>> To fix this we need to make sure that all we need is enabled before
>> reading the EDID. This means the following:
>>
>> 1. If get_edid() is called before having the device powered we need to
>>power on the device. In such case, the driver will power off again the
>>device.
>>
>> 2. If get_edid() is called after having the device powered, all should
>>just work. We added a powered flag in order to avoid recurrent calls
>>to ps8640_bridge_poweron() and unneeded delays.
>>
>> 3. This seems to be specific for this device, but we need to make sure
>>the panel is powered on before do a power on cycle on this device.
>>Otherwise the device fails to retrieve the EDID.
> Step 3. looks like an ugly hack too
> 

It is, but I don't have enough hardware details to be able to answer why we need
to do this. What is well tested is that, if I don't power the panel before
powering on the bridge, it doesn't get a proper EDID. Seems that when the bridge
goes up, the firmware tries to read the EDID and caches somehow. Well not sure.

>>
>> Signed-off-by: Enric Balletbo i Serra 
>> ---
>>
>>  drivers/gpu/drm/bridge/parade-ps8640.c | 79 --
>>  1 file changed, 73 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
>> b/drivers/gpu/drm/bridge/parade-ps8640.c
>> index 9f7b7a9c53c52..ca651480891df 100644
>> --- a/drivers/gpu/drm/bridge/parade-ps8640.c
>> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
>> @@ -65,6 +65,7 @@ struct ps8640 {
>>  struct regulator_bulk_data supplies[2];
>>  struct gpio_desc *gpio_reset;
>>  struct gpio_desc *gpio_powerdown;
>> +bool powered;
>>  };
>>  
>>  static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
>> @@ -91,13 +92,25 @@ static int ps8640_bridge_vdo_control(struct ps8640 
>> *ps_bridge,
>>  return 0;
>>  }
>>  
>> -static void ps8640_pre_enable(struct drm_bridge *bridge)
>> +static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
>>  {
>> -struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>>  struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
>> +struct drm_bridge *panel;
>>  unsigned long timeout;
>>  int ret, status;
>>  
>> +if (ps_bridge->powered)
>> +return;
>> +
>> +/*
>> + * That seems to be specific to this chip, and a weird behaviour, but
>> + * we need to call drm_panel_prepare before issuing a poweron cycle. If
>> + * we don't do this, the chip is not able to read properly the EDID.
>> + */
>> +panel = ps_bridge->panel_bridge;
>> +if (panel->funcs && panel->funcs->pre_enable)
>> +panel->funcs->pre_enable(panel);
>> +
>>  ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
>>  ps_bridge->supplies);
>>  if (ret < 0) {
>> @@ -164,6 +177,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
>>  goto err

[PATCH 0/3] drm/bridge: ps8640: Make sure all needed is powered to get the EDID

2020-06-16 Thread Enric Balletbo i Serra
The first patch is not really related and can be picked alone. The
second and the third are to rework the power handling to get the EDID.
Basically, we need to make sure all the needed is powered to be able
to get the EDID. Before, we saw that getting the EDID failed as
explained in the third patch.

Note that this series depends on:

  https://lore.kernel.org/patchwork/project/lkml/list/?series=448525

to apply cleanly.


Enric Balletbo i Serra (3):
  drm/bridge: ps8640: Return an error for incorrect attach flags
  drm/bridge: ps8640: Print an error if VDO control fails
  drm/bridge: ps8640: Rework power state handling

 drivers/gpu/drm/bridge/parade-ps8640.c | 94 ++
 1 file changed, 82 insertions(+), 12 deletions(-)

-- 
2.27.0

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


[RESEND PATCH v4 2/7] drm/bridge_connector: Set default status connected for eDP connectors

2020-06-16 Thread Enric Balletbo i Serra
In an eDP application, HPD is not required and on most bridge chips
useless. If HPD is not used, we need to set initial status as connected,
otherwise the connector created by the drm_bridge_connector API remains
in an unknown state.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/drm_bridge_connector.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_bridge_connector.c 
b/drivers/gpu/drm/drm_bridge_connector.c
index c6994fe673f31..a58cbde59c34a 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -187,6 +187,7 @@ drm_bridge_connector_detect(struct drm_connector 
*connector, bool force)
case DRM_MODE_CONNECTOR_DPI:
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_DSI:
+   case DRM_MODE_CONNECTOR_eDP:
status = connector_status_connected;
break;
default:
-- 
2.27.0

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


[RESEND PATCH v4 3/7] drm/mediatek: mtk_dsi: Rename bridge to next_bridge

2020-06-16 Thread Enric Balletbo i Serra
This is really a cosmetic change just to make a bit more readable the
code after convert the driver to drm_bridge. The bridge variable name
will be used by the encoder drm_bridge, and the chained bridge will be
named next_bridge.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
Reviewed-by: Chun-Kuang Hu 
---

Changes in v4: None
Changes in v3:
- Replace s/bridge/next bridge/ for comment. (Laurent Pinchart)

Changes in v2: None

 drivers/gpu/drm/mediatek/mtk_dsi.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 270bf22c98feb..208f49bf14a01 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -183,7 +183,7 @@ struct mtk_dsi {
struct drm_encoder encoder;
struct drm_connector conn;
struct drm_panel *panel;
-   struct drm_bridge *bridge;
+   struct drm_bridge *next_bridge;
struct phy *phy;
 
void __iomem *regs;
@@ -894,9 +894,10 @@ static int mtk_dsi_create_conn_enc(struct drm_device *drm, 
struct mtk_dsi *dsi)
 */
dsi->encoder.possible_crtcs = 1;
 
-   /* If there's a bridge, attach to it and let it create the connector */
-   if (dsi->bridge) {
-   ret = drm_bridge_attach(>encoder, dsi->bridge, NULL, 0);
+   /* If there's a next bridge, attach to it and let it create the 
connector */
+   if (dsi->next_bridge) {
+   ret = drm_bridge_attach(>encoder, dsi->next_bridge, NULL,
+   0);
if (ret) {
DRM_ERROR("Failed to attach bridge to drm\n");
goto err_encoder_cleanup;
@@ -1177,7 +1178,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
}
 
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
- >panel, >bridge);
+ >panel, >next_bridge);
if (ret)
goto err_unregister_host;
 
-- 
2.27.0

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


[RESEND PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges

2020-06-16 Thread Enric Balletbo i Serra
Use the drm_bridge_connector helper to create a connector for pipelines
that use drm_bridge. This allows splitting connector operations across
multiple bridges when necessary, instead of having the last bridge in
the chain creating the connector and handling all connector operations
internally.

Signed-off-by: Enric Balletbo i Serra 
Acked-by: Sam Ravnborg 
---

Changes in v4: None
Changes in v3:
- Move the bridge.type line to the patch that adds drm_bridge support. (Laurent 
Pinchart)

Changes in v2: None

 drivers/gpu/drm/mediatek/mtk_dsi.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 4f3bd095c1eee..471fcafdf3488 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -183,6 +184,7 @@ struct mtk_dsi {
struct drm_encoder encoder;
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
+   struct drm_connector *connector;
struct phy *phy;
 
void __iomem *regs;
@@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, 
struct mtk_dsi *dsi)
 */
dsi->encoder.possible_crtcs = 1;
 
-   ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
+   ret = drm_bridge_attach(>encoder, >bridge, NULL,
+   DRM_BRIDGE_ATTACH_NO_CONNECTOR);
if (ret)
goto err_cleanup_encoder;
 
+   dsi->connector = drm_bridge_connector_init(drm, >encoder);
+   if (IS_ERR(dsi->connector)) {
+   DRM_ERROR("Unable to create bridge connector\n");
+   ret = PTR_ERR(dsi->connector);
+   goto err_cleanup_encoder;
+   }
+   drm_connector_attach_encoder(dsi->connector, >encoder);
+
return 0;
 
 err_cleanup_encoder:
-- 
2.27.0

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


[RESEND PATCH v4 0/7] Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge

2020-06-16 Thread Enric Balletbo i Serra
(This resend is to fix some trivial conflicts due the merge window)

The PS8640 dsi-to-eDP bridge driver is using the panel bridge API,
however, not all the components in the chain have been ported to the
drm_bridge API. Actually, when a panel is attached the default panel's mode
is used, but in some cases we can't get display up if mode getting from
eDP control EDID is not chosen.

This series address that problem, first implements the .get_edid()
callback in the PS8640 driver (which is not used until the conversion is
done) and then, converts the Mediatek DSI driver to use the drm_bridge
API.

As far as I know, we're the only users of the mediatek dsi driver in
mainline, so should be safe to switch to the new chain of drm_bridge API
unconditionally.

The patches has been tested on a Acer Chromebook R13 (Elm) running a
Chrome OS userspace and checking that the valid EDID mode reported by
the bridge is selected.

Changes in v4:
- Remove double call to drm_encoder_init(). (Chun-Kuang Hu)
- Cleanup the encoder in mtk_dsi_unbind(). (Chun-Kuang Hu)

Changes in v3:
- Replace s/bridge/next bridge/ for comment. (Laurent Pinchart)
- Add the bridge.type. (Laurent Pinchart)
- Use next_bridge field to store the panel bridge. (Laurent Pinchart)
- Add the bridge.type field. (Laurent Pinchart)
- This patch requires https://lkml.org/lkml/2020/4/16/2080 to work
  properly.
- Move the bridge.type line to the patch that adds drm_bridge support. (Laurent 
Pinchart)

Changes in v2:
- Do not set connector_type for panel here. (Sam Ravnborg)

Enric Balletbo i Serra (7):
  drm/bridge: ps8640: Get the EDID from eDP control
  drm/bridge_connector: Set default status connected for eDP connectors
  drm/mediatek: mtk_dsi: Rename bridge to next_bridge
  drm/mediatek: mtk_dsi: Convert to bridge driver
  drm/mediatek: mtk_dsi: Use simple encoder
  drm/mediatek: mtk_dsi: Use the drm_panel_bridge API
  drm/mediatek: mtk_dsi: Create connector for bridges

 drivers/gpu/drm/bridge/parade-ps8640.c |  12 ++
 drivers/gpu/drm/drm_bridge_connector.c |   1 +
 drivers/gpu/drm/mediatek/mtk_dsi.c | 269 -
 3 files changed, 97 insertions(+), 185 deletions(-)

-- 
2.27.0

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


[RESEND PATCH v4 1/7] drm/bridge: ps8640: Get the EDID from eDP control

2020-06-16 Thread Enric Balletbo i Serra
The PS8640 DSI-to-eDP bridge can retrieve the EDID, so implement the
.get_edid callback and set the flag to indicate the core to use it.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/parade-ps8640.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 4b099196afeba..13755d278db6d 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -242,8 +242,18 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge,
return ret;
 }
 
+static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge,
+  struct drm_connector *connector)
+{
+   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+   return drm_get_edid(connector,
+   ps_bridge->page[PAGE0_DP_CNTL]->adapter);
+}
+
 static const struct drm_bridge_funcs ps8640_bridge_funcs = {
.attach = ps8640_bridge_attach,
+   .get_edid = ps8640_bridge_get_edid,
.post_disable = ps8640_post_disable,
.pre_enable = ps8640_pre_enable,
 };
@@ -294,6 +304,8 @@ static int ps8640_probe(struct i2c_client *client)
 
ps_bridge->bridge.funcs = _bridge_funcs;
ps_bridge->bridge.of_node = dev->of_node;
+   ps_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
+   ps_bridge->bridge.type = DRM_MODE_CONNECTOR_eDP;
 
ps_bridge->page[PAGE0_DP_CNTL] = client;
 
-- 
2.27.0

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


[RESEND PATCH v4 6/7] drm/mediatek: mtk_dsi: Use the drm_panel_bridge API

2020-06-16 Thread Enric Balletbo i Serra
Replace the manual panel handling code by a drm_panel_bridge. This
simplifies the driver and allows all components in the display pipeline
to be treated as bridges, paving the way to generic connector handling.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
Reviewed-by: Chun-Kuang Hu 
---

Changes in v4: None
Changes in v3:
- Use next_bridge field to store the panel bridge. (Laurent Pinchart)
- Add the bridge.type field. (Laurent Pinchart)
- This patch requires https://lkml.org/lkml/2020/4/16/2080 to work
  properly.

Changes in v2:
- Do not set connector_type for panel here. (Sam Ravnborg)

 drivers/gpu/drm/mediatek/mtk_dsi.c | 173 +++--
 1 file changed, 14 insertions(+), 159 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index e02d16a086ac0..4f3bd095c1eee 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -182,8 +182,6 @@ struct mtk_dsi {
struct mipi_dsi_host host;
struct drm_encoder encoder;
struct drm_bridge bridge;
-   struct drm_connector conn;
-   struct drm_panel *panel;
struct drm_bridge *next_bridge;
struct phy *phy;
 
@@ -212,11 +210,6 @@ static inline struct mtk_dsi *bridge_to_dsi(struct 
drm_bridge *b)
return container_of(b, struct mtk_dsi, bridge);
 }
 
-static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
-{
-   return container_of(c, struct mtk_dsi, conn);
-}
-
 static inline struct mtk_dsi *host_to_dsi(struct mipi_dsi_host *h)
 {
return container_of(h, struct mtk_dsi, host);
@@ -682,16 +675,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
mtk_dsi_lane0_ulp_mode_leave(dsi);
mtk_dsi_clk_hs_mode(dsi, 0);
 
-   if (dsi->panel) {
-   if (drm_panel_prepare(dsi->panel)) {
-   DRM_ERROR("failed to prepare the panel\n");
-   goto err_disable_digital_clk;
-   }
-   }
-
return 0;
-err_disable_digital_clk:
-   clk_disable_unprepare(dsi->digital_clk);
 err_disable_engine_clk:
clk_disable_unprepare(dsi->engine_clk);
 err_phy_power_off:
@@ -718,15 +702,7 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
 */
mtk_dsi_stop(dsi);
 
-   if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
-   if (dsi->panel) {
-   if (drm_panel_unprepare(dsi->panel)) {
-   DRM_ERROR("failed to unprepare the panel\n");
-   return;
-   }
-   }
-   }
-
+   mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500);
mtk_dsi_reset_engine(dsi);
mtk_dsi_lane0_ulp_mode_enter(dsi);
mtk_dsi_clk_ulp_mode_enter(dsi);
@@ -757,19 +733,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
 
mtk_dsi_start(dsi);
 
-   if (dsi->panel) {
-   if (drm_panel_enable(dsi->panel)) {
-   DRM_ERROR("failed to enable the panel\n");
-   goto err_dsi_power_off;
-   }
-   }
-
dsi->enabled = true;
-
-   return;
-err_dsi_power_off:
-   mtk_dsi_stop(dsi);
-   mtk_dsi_poweroff(dsi);
 }
 
 static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
@@ -777,34 +741,19 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
if (!dsi->enabled)
return;
 
-   if (dsi->panel) {
-   if (drm_panel_disable(dsi->panel)) {
-   DRM_ERROR("failed to disable the panel\n");
-   return;
-   }
-   }
-
mtk_dsi_poweroff(dsi);
 
dsi->enabled = false;
 }
 
-static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi 
*dsi);
-static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
-
 static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
 enum drm_bridge_attach_flags flags)
 {
struct mtk_dsi *dsi = bridge_to_dsi(bridge);
 
-   return mtk_dsi_create_conn_enc(bridge->dev, dsi);
-}
-
-static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
-{
-   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
-
-   mtk_dsi_destroy_conn_enc(dsi);
+   /* Attach the panel or bridge to the dsi bridge */
+   return drm_bridge_attach(bridge->encoder, dsi->next_bridge,
+>bridge, flags);
 }
 
 static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
@@ -830,101 +779,13 @@ static void mtk_dsi_bridge_enable(struct drm_bridge 
*bridge)
mtk_output_dsi_enable(dsi);
 }
 
-static int mtk_dsi_connector_get_modes(struct drm_connector *connector)
-{
-   struct mtk_dsi *dsi = connector_to_dsi(connector);
-
-   return drm_panel_get_mo

[RESEND PATCH v4 5/7] drm/mediatek: mtk_dsi: Use simple encoder

2020-06-16 Thread Enric Balletbo i Serra
The mtk_dsi driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
Reviewed-by: Chun-Kuang Hu 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/mediatek/mtk_dsi.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 759a5b37fb4d2..e02d16a086ac0 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -789,15 +789,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
dsi->enabled = false;
 }
 
-static void mtk_dsi_encoder_destroy(struct drm_encoder *encoder)
-{
-   drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs mtk_dsi_encoder_funcs = {
-   .destroy = mtk_dsi_encoder_destroy,
-};
-
 static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi 
*dsi);
 static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
 
@@ -1127,8 +1118,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, 
struct mtk_dsi *dsi)
 {
int ret;
 
-   ret = drm_encoder_init(drm, >encoder, _dsi_encoder_funcs,
-  DRM_MODE_ENCODER_DSI, NULL);
+   ret = drm_simple_encoder_init(drm, >encoder,
+ DRM_MODE_ENCODER_DSI);
if (ret) {
DRM_ERROR("Failed to encoder init to drm\n");
return ret;
-- 
2.27.0

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


[PATCH 2/3] drm/bridge: ps8640: Print an error if VDO control fails

2020-06-16 Thread Enric Balletbo i Serra
Print an error message inside ps8640_bridge_vdo_control() function when
it fails so we can simplify a bit the callers, they will only need to
check the error code.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/bridge/parade-ps8640.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index ce3e8b2da8c9b..9f7b7a9c53c52 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -82,8 +82,11 @@ static int ps8640_bridge_vdo_control(struct ps8640 
*ps_bridge,
ret = i2c_smbus_write_i2c_block_data(client, PAGE3_SET_ADD,
 sizeof(vdo_ctrl_buf),
 vdo_ctrl_buf);
-   if (ret < 0)
+   if (ret < 0) {
+   DRM_ERROR("failed to %sable VDO: %d\n",
+ ctrl == ENABLE ? "en" : "dis", ret);
return ret;
+   }
 
return 0;
 }
@@ -150,10 +153,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
}
 
ret = ps8640_bridge_vdo_control(ps_bridge, ENABLE);
-   if (ret) {
-   DRM_ERROR("failed to enable VDO: %d\n", ret);
+   if (ret)
goto err_regulators_disable;
-   }
 
/* Switch access edp panel's edid through i2c */
ret = i2c_smbus_write_byte_data(client, PAGE2_I2C_BYPASS,
@@ -175,9 +176,7 @@ static void ps8640_post_disable(struct drm_bridge *bridge)
struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
int ret;
 
-   ret = ps8640_bridge_vdo_control(ps_bridge, DISABLE);
-   if (ret < 0)
-   DRM_ERROR("failed to disable VDO: %d\n", ret);
+   ps8640_bridge_vdo_control(ps_bridge, DISABLE);
 
gpiod_set_value(ps_bridge->gpio_reset, 1);
gpiod_set_value(ps_bridge->gpio_powerdown, 1);
-- 
2.27.0

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


[PATCH 1/3] drm/bridge: ps8640: Return an error for incorrect attach flags

2020-06-16 Thread Enric Balletbo i Serra
Bridge drivers that implement the new model only shall return an error
from their attach() handler when the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag
is not set. So make sure we return an error because only the new
drm_bridge model is supported.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/bridge/parade-ps8640.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 13755d278db6d..ce3e8b2da8c9b 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -200,6 +200,10 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge,
   .channel = 0,
   .node = NULL,
 };
+
+   if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
+   return -EINVAL;
+
/* port@0 is ps8640 dsi input port */
in_ep = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1);
if (!in_ep)
-- 
2.27.0

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


[PATCH 3/3] drm/bridge: ps8640: Rework power state handling

2020-06-16 Thread Enric Balletbo i Serra
The get_edid() callback can be triggered anytime by an ioctl, i.e

  drm_mode_getconnector (ioctl)
-> drm_helper_probe_single_connector_modes
   -> drm_bridge_connector_get_modes
  -> ps8640_bridge_get_edid

Actually if the bridge pre_enable() function was not called before
get_edid(), the driver will not be able to get the EDID properly and
display will not work until a second get_edid() call is issued and if
pre_enable() is called before. The side effect of this, for example, is
that you see anything when `Frecon` starts, neither the splash screen,
until the graphical session manager starts.

To fix this we need to make sure that all we need is enabled before
reading the EDID. This means the following:

1. If get_edid() is called before having the device powered we need to
   power on the device. In such case, the driver will power off again the
   device.

2. If get_edid() is called after having the device powered, all should
   just work. We added a powered flag in order to avoid recurrent calls
   to ps8640_bridge_poweron() and unneeded delays.

3. This seems to be specific for this device, but we need to make sure
   the panel is powered on before do a power on cycle on this device.
   Otherwise the device fails to retrieve the EDID.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/bridge/parade-ps8640.c | 79 --
 1 file changed, 73 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 9f7b7a9c53c52..ca651480891df 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -65,6 +65,7 @@ struct ps8640 {
struct regulator_bulk_data supplies[2];
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_powerdown;
+   bool powered;
 };
 
 static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
@@ -91,13 +92,25 @@ static int ps8640_bridge_vdo_control(struct ps8640 
*ps_bridge,
return 0;
 }
 
-static void ps8640_pre_enable(struct drm_bridge *bridge)
+static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
 {
-   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
+   struct drm_bridge *panel;
unsigned long timeout;
int ret, status;
 
+   if (ps_bridge->powered)
+   return;
+
+   /*
+* That seems to be specific to this chip, and a weird behaviour, but
+* we need to call drm_panel_prepare before issuing a poweron cycle. If
+* we don't do this, the chip is not able to read properly the EDID.
+*/
+   panel = ps_bridge->panel_bridge;
+   if (panel->funcs && panel->funcs->pre_enable)
+   panel->funcs->pre_enable(panel);
+
ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
ps_bridge->supplies);
if (ret < 0) {
@@ -164,6 +177,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
goto err_regulators_disable;
}
 
+   ps_bridge->powered = true;
+
return;
 
 err_regulators_disable:
@@ -171,12 +186,13 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
   ps_bridge->supplies);
 }
 
-static void ps8640_post_disable(struct drm_bridge *bridge)
+static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
 {
-   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+   struct drm_bridge *panel;
int ret;
 
-   ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+   if (!ps_bridge->powered)
+   return;
 
gpiod_set_value(ps_bridge->gpio_reset, 1);
gpiod_set_value(ps_bridge->gpio_powerdown, 1);
@@ -184,6 +200,32 @@ static void ps8640_post_disable(struct drm_bridge *bridge)
 ps_bridge->supplies);
if (ret < 0)
DRM_ERROR("cannot disable regulators %d\n", ret);
+
+   panel = ps_bridge->panel_bridge;
+   if (panel->funcs && panel->funcs->post_disable)
+   panel->funcs->post_disable(panel);
+
+   ps_bridge->powered = false;
+}
+
+static void ps8640_pre_enable(struct drm_bridge *bridge)
+{
+   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+   int ret;
+
+   ps8640_bridge_poweron(ps_bridge);
+
+   ret = ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+   if (ret < 0)
+   ps8640_bridge_poweroff(ps_bridge);
+}
+
+static void ps8640_post_disable(struct drm_bridge *bridge)
+{
+   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+   ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+   ps8640_bridge_poweroff(ps_bridge);
 }
 
 static int ps8640_bridge_attach(struct drm_bridge *bridge,
@@ -249,9 +291,34 @@ static struct edid *p

[RESEND PATCH v4 4/7] drm/mediatek: mtk_dsi: Convert to bridge driver

2020-06-16 Thread Enric Balletbo i Serra
Convert mtk_dsi to a bridge driver with built-in encoder support for
compatibility with existing component drivers.

Signed-off-by: Enric Balletbo i Serra 
Acked-by: Sam Ravnborg 
Reviewed-by: Chun-Kuang Hu 
---

Changes in v4:
- Remove double call to drm_encoder_init(). (Chun-Kuang Hu)
- Cleanup the encoder in mtk_dsi_unbind(). (Chun-Kuang Hu)

Changes in v3:
- Add the bridge.type. (Laurent Pinchart)

Changes in v2: None

 drivers/gpu/drm/mediatek/mtk_dsi.c | 117 +++--
 1 file changed, 79 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 208f49bf14a01..759a5b37fb4d2 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -181,6 +181,7 @@ struct mtk_dsi {
struct device *dev;
struct mipi_dsi_host host;
struct drm_encoder encoder;
+   struct drm_bridge bridge;
struct drm_connector conn;
struct drm_panel *panel;
struct drm_bridge *next_bridge;
@@ -206,9 +207,9 @@ struct mtk_dsi {
const struct mtk_dsi_driver_data *driver_data;
 };
 
-static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
+static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
 {
-   return container_of(e, struct mtk_dsi, encoder);
+   return container_of(b, struct mtk_dsi, bridge);
 }
 
 static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
@@ -788,32 +789,52 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
dsi->enabled = false;
 }
 
-static bool mtk_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
-  const struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
+static void mtk_dsi_encoder_destroy(struct drm_encoder *encoder)
 {
-   return true;
+   drm_encoder_cleanup(encoder);
 }
 
-static void mtk_dsi_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted)
+static const struct drm_encoder_funcs mtk_dsi_encoder_funcs = {
+   .destroy = mtk_dsi_encoder_destroy,
+};
+
+static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi 
*dsi);
+static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
+
+static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
+{
+   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
+
+   return mtk_dsi_create_conn_enc(bridge->dev, dsi);
+}
+
+static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
 {
-   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
+
+   mtk_dsi_destroy_conn_enc(dsi);
+}
+
+static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
+   const struct drm_display_mode *mode,
+   const struct drm_display_mode *adjusted)
+{
+   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
 
drm_display_mode_to_videomode(adjusted, >vm);
 }
 
-static void mtk_dsi_encoder_disable(struct drm_encoder *encoder)
+static void mtk_dsi_bridge_disable(struct drm_bridge *bridge)
 {
-   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
 
mtk_output_dsi_disable(dsi);
 }
 
-static void mtk_dsi_encoder_enable(struct drm_encoder *encoder)
+static void mtk_dsi_bridge_enable(struct drm_bridge *bridge)
 {
-   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
 
mtk_output_dsi_enable(dsi);
 }
@@ -825,11 +846,12 @@ static int mtk_dsi_connector_get_modes(struct 
drm_connector *connector)
return drm_panel_get_modes(dsi->panel, connector);
 }
 
-static const struct drm_encoder_helper_funcs mtk_dsi_encoder_helper_funcs = {
-   .mode_fixup = mtk_dsi_encoder_mode_fixup,
-   .mode_set = mtk_dsi_encoder_mode_set,
-   .disable = mtk_dsi_encoder_disable,
-   .enable = mtk_dsi_encoder_enable,
+static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
+   .attach = mtk_dsi_bridge_attach,
+   .detach = mtk_dsi_bridge_detach,
+   .disable = mtk_dsi_bridge_disable,
+   .enable = mtk_dsi_bridge_enable,
+   .mode_set = mtk_dsi_bridge_mode_set,
 };
 
 static const struct drm_connector_funcs mtk_dsi_connector_funcs = {
@@ -880,20 +902,6 @@ static int mtk_dsi_create_conn_enc(struct drm_device *drm, 
struct mtk_dsi *dsi)
 {
int ret;
 
-   ret = drm_simple_encoder_init(drm, >encoder,
- DRM_MODE_ENCODER_DSI);
-   if (ret) {
-   DRM_ERROR("Failed to encoder init to drm\n");
-   return ret;
-   }
-   drm_encoder_helper_add(>encoder, _dsi_encoder_helper_funcs);
-
-  

Re: [RESEND PATCH 0/3] Convert mtk-dpi to drm_bridge API

2020-06-13 Thread Enric Balletbo i Serra
Hi,

On 18/5/20 19:39, Enric Balletbo i Serra wrote:
> The reason for this resend is because I forget to add some bridge
> maintainers. So adding them and collect the actual tags.
> 
> The mtk-dpi driver still uses the drm_encoder API which is now somewhat
> deprecated. We started to move all the Mediatek drivers to the drm_bridge API,
> like we did for the mtk-dsi driver [1], this is another small step to be able 
> to
> fully convert the DRM Mediatek drivers to the drm_bridge API. A dummy
> drm_encoder is maintained in the mtk-dpi driver but the end goal is move all 
> the
> dummy drm_encoder (mtk-dsi, mtk-dpi, etc) to the main mtk_drm_drv driver.
> 
> [1] https://lore.kernel.org/patchwork/project/lkml/list/?series=441559
> 
> 
> Enric Balletbo i Serra (3):
>   drm/mediatek: mtk_dpi: Rename bridge to next_bridge
>   drm/mediatek: mtk_dpi: Convert to bridge driver
>   drm/mediatek: mtk_dpi: Use simple encoder
> 
>  drivers/gpu/drm/mediatek/mtk_dpi.c | 84 ++

A gentle ping, I think this patchset still is missing a reviewed tag from bridge
maintainers if is fine.

Thanks,
 Enric


>  1 file changed, 39 insertions(+), 45 deletions(-)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/mediatek: mtk_mt8173_hdmi_phy: Remove unnused const variables

2020-05-20 Thread Enric Balletbo i Serra
There are some `static const u8` variables that are not used, this
triggers a warning building with `make W=1`, it is safe to remove them,
so do it and make the compiler more happy.

Signed-off-by: Enric Balletbo i Serra 
---

 .../gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c| 48 ---
 1 file changed, 48 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index 1c3575372230..827b93786fac 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -107,54 +107,6 @@
 #define RGS_HDMITX_5T1_EDG (0xf << 4)
 #define RGS_HDMITX_PLUG_TSTBIT(0)
 
-static const u8 PREDIV[3][4] = {
-   {0x0, 0x0, 0x0, 0x0},   /* 27Mhz */
-   {0x1, 0x1, 0x1, 0x1},   /* 74Mhz */
-   {0x1, 0x1, 0x1, 0x1}/* 148Mhz */
-};
-
-static const u8 TXDIV[3][4] = {
-   {0x3, 0x3, 0x3, 0x2},   /* 27Mhz */
-   {0x2, 0x1, 0x1, 0x1},   /* 74Mhz */
-   {0x1, 0x0, 0x0, 0x0}/* 148Mhz */
-};
-
-static const u8 FBKSEL[3][4] = {
-   {0x1, 0x1, 0x1, 0x1},   /* 27Mhz */
-   {0x1, 0x0, 0x1, 0x1},   /* 74Mhz */
-   {0x1, 0x0, 0x1, 0x1}/* 148Mhz */
-};
-
-static const u8 FBKDIV[3][4] = {
-   {19, 24, 29, 19},   /* 27Mhz */
-   {19, 24, 14, 19},   /* 74Mhz */
-   {19, 24, 14, 19}/* 148Mhz */
-};
-
-static const u8 DIVEN[3][4] = {
-   {0x2, 0x1, 0x1, 0x2},   /* 27Mhz */
-   {0x2, 0x2, 0x2, 0x2},   /* 74Mhz */
-   {0x2, 0x2, 0x2, 0x2}/* 148Mhz */
-};
-
-static const u8 HTPLLBP[3][4] = {
-   {0xc, 0xc, 0x8, 0xc},   /* 27Mhz */
-   {0xc, 0xf, 0xf, 0xc},   /* 74Mhz */
-   {0xc, 0xf, 0xf, 0xc}/* 148Mhz */
-};
-
-static const u8 HTPLLBC[3][4] = {
-   {0x2, 0x3, 0x3, 0x2},   /* 27Mhz */
-   {0x2, 0x3, 0x3, 0x2},   /* 74Mhz */
-   {0x2, 0x3, 0x3, 0x2}/* 148Mhz */
-};
-
-static const u8 HTPLLBR[3][4] = {
-   {0x1, 0x1, 0x0, 0x1},   /* 27Mhz */
-   {0x1, 0x2, 0x2, 0x1},   /* 74Mhz */
-   {0x1, 0x2, 0x2, 0x1}/* 148Mhz */
-};
-
 static int mtk_hdmi_pll_prepare(struct clk_hw *hw)
 {
struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
-- 
2.26.2

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


[PATCH] drm/mediatek: mtk_hdmi: Remove debug messages for function calls

2020-05-20 Thread Enric Balletbo i Serra
Equivalent information can be nowadays obtained using function tracer

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/mediatek/mtk_hdmi.c| 12 +---
 drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c |  4 
 2 files changed, 1 insertion(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index b0555a7cb3b4..172d67294435 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1634,8 +1634,6 @@ static int mtk_hdmi_audio_startup(struct device *dev, 
void *data)
 {
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
 
-   dev_dbg(dev, "%s\n", __func__);
-
mtk_hdmi_audio_enable(hdmi);
 
return 0;
@@ -1645,8 +1643,6 @@ static void mtk_hdmi_audio_shutdown(struct device *dev, 
void *data)
 {
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
 
-   dev_dbg(dev, "%s\n", __func__);
-
mtk_hdmi_audio_disable(hdmi);
 }
 
@@ -1655,8 +1651,6 @@ mtk_hdmi_audio_digital_mute(struct device *dev, void 
*data, bool enable)
 {
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
 
-   dev_dbg(dev, "%s(%d)\n", __func__, enable);
-
if (enable)
mtk_hdmi_hw_aud_mute(hdmi);
else
@@ -1669,8 +1663,6 @@ static int mtk_hdmi_audio_get_eld(struct device *dev, 
void *data, uint8_t *buf,
 {
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
 
-   dev_dbg(dev, "%s\n", __func__);
-
memcpy(buf, hdmi->conn.eld, min(sizeof(hdmi->conn.eld), len));
 
return 0;
@@ -1770,7 +1762,6 @@ static int mtk_drm_hdmi_probe(struct platform_device 
*pdev)
goto err_bridge_remove;
}
 
-   dev_dbg(dev, "mediatek hdmi probe success\n");
return 0;
 
 err_bridge_remove:
@@ -1793,7 +1784,7 @@ static int mtk_hdmi_suspend(struct device *dev)
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
 
mtk_hdmi_clk_disable_audio(hdmi);
-   dev_dbg(dev, "hdmi suspend success!\n");
+
return 0;
 }
 
@@ -1808,7 +1799,6 @@ static int mtk_hdmi_resume(struct device *dev)
return ret;
}
 
-   dev_dbg(dev, "hdmi resume success!\n");
return 0;
 }
 #endif
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index b55f51675205..1c3575372230 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -159,8 +159,6 @@ static int mtk_hdmi_pll_prepare(struct clk_hw *hw)
 {
struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
 
-   dev_dbg(hdmi_phy->dev, "%s\n", __func__);
-
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON1, RG_HDMITX_PLL_AUTOK_EN);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_PLL_POSDIV);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3, RG_HDMITX_MHLCK_EN);
@@ -178,8 +176,6 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
 {
struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
 
-   dev_dbg(hdmi_phy->dev, "%s\n", __func__);
-
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON1, RG_HDMITX_PLL_TXDIV_EN);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON1, RG_HDMITX_PLL_BIAS_LPF_EN);
usleep_range(100, 150);
-- 
2.26.2

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


[RESEND PATCH 2/3] drm/mediatek: mtk_dpi: Convert to bridge driver

2020-05-19 Thread Enric Balletbo i Serra
Convert mtk_dpi to a bridge driver with built-in encoder support for
compatibility with existing component drivers.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Chun-Kuang Hu 
---

 drivers/gpu/drm/mediatek/mtk_dpi.c | 66 +++---
 1 file changed, 34 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 7112125dc3d1..baad198c69eb 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -61,6 +61,7 @@ enum mtk_dpi_out_color_format {
 struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
+   struct drm_bridge bridge;
struct drm_bridge *next_bridge;
void __iomem *regs;
struct device *dev;
@@ -77,9 +78,9 @@ struct mtk_dpi {
int refcount;
 };
 
-static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
+static inline struct mtk_dpi *bridge_to_dpi(struct drm_bridge *b)
 {
-   return container_of(e, struct mtk_dpi, encoder);
+   return container_of(b, struct mtk_dpi, bridge);
 }
 
 enum mtk_dpi_polarity {
@@ -518,50 +519,44 @@ static const struct drm_encoder_funcs 
mtk_dpi_encoder_funcs = {
.destroy = mtk_dpi_encoder_destroy,
 };
 
-static bool mtk_dpi_encoder_mode_fixup(struct drm_encoder *encoder,
-  const struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
+static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
 {
-   return true;
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+
+   return drm_bridge_attach(bridge->encoder, dpi->next_bridge,
+>bridge, flags);
 }
 
-static void mtk_dpi_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
+static void mtk_dpi_bridge_mode_set(struct drm_bridge *bridge,
+   const struct drm_display_mode *mode,
+   const struct drm_display_mode *adjusted_mode)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
drm_mode_copy(>mode, adjusted_mode);
 }
 
-static void mtk_dpi_encoder_disable(struct drm_encoder *encoder)
+static void mtk_dpi_bridge_disable(struct drm_bridge *bridge)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
mtk_dpi_power_off(dpi);
 }
 
-static void mtk_dpi_encoder_enable(struct drm_encoder *encoder)
+static void mtk_dpi_bridge_enable(struct drm_bridge *bridge)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
mtk_dpi_power_on(dpi);
mtk_dpi_set_display_mode(dpi, >mode);
 }
 
-static int mtk_dpi_atomic_check(struct drm_encoder *encoder,
-   struct drm_crtc_state *crtc_state,
-   struct drm_connector_state *conn_state)
-{
-   return 0;
-}
-
-static const struct drm_encoder_helper_funcs mtk_dpi_encoder_helper_funcs = {
-   .mode_fixup = mtk_dpi_encoder_mode_fixup,
-   .mode_set = mtk_dpi_encoder_mode_set,
-   .disable = mtk_dpi_encoder_disable,
-   .enable = mtk_dpi_encoder_enable,
-   .atomic_check = mtk_dpi_atomic_check,
+static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
+   .attach = mtk_dpi_bridge_attach,
+   .mode_set = mtk_dpi_bridge_mode_set,
+   .disable = mtk_dpi_bridge_disable,
+   .enable = mtk_dpi_bridge_enable,
 };
 
 static void mtk_dpi_start(struct mtk_ddp_comp *comp)
@@ -602,16 +597,13 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
dev_err(dev, "Failed to initialize decoder: %d\n", ret);
goto err_unregister;
}
-   drm_encoder_helper_add(>encoder, _dpi_encoder_helper_funcs);
 
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
 
-   ret = drm_bridge_attach(>encoder, dpi->next_bridge, NULL, 0);
-   if (ret) {
-   dev_err(dev, "Failed to attach bridge: %d\n", ret);
+   ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
+   if (ret)
goto err_cleanup;
-   }
 
dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
@@ -768,8 +760,15 @@ static int mtk_dpi_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, dpi);
 
+   dpi->bridge.funcs = _dpi_bridge_funcs;
+   dpi->bridge.of_node = dev->of_node;
+   dpi->bridge.type = DRM_MODE_CONNECTOR_DP

[RESEND PATCH 3/3] drm/mediatek: mtk_dpi: Use simple encoder

2020-05-19 Thread Enric Balletbo i Serra
The mtk_dpi driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Chun-Kuang Hu 
---

 drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index baad198c69eb..80778b2aac2a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mtk_dpi_regs.h"
 #include "mtk_drm_ddp_comp.h"
@@ -510,15 +511,6 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
return 0;
 }
 
-static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
-{
-   drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
-   .destroy = mtk_dpi_encoder_destroy,
-};
-
 static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
 enum drm_bridge_attach_flags flags)
 {
@@ -591,8 +583,8 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
return ret;
}
 
-   ret = drm_encoder_init(drm_dev, >encoder, _dpi_encoder_funcs,
-  DRM_MODE_ENCODER_TMDS, NULL);
+   ret = drm_simple_encoder_init(drm_dev, >encoder,
+ DRM_MODE_ENCODER_TMDS);
if (ret) {
dev_err(dev, "Failed to initialize decoder: %d\n", ret);
goto err_unregister;
-- 
2.26.2

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


[RESEND PATCH 1/3] drm/mediatek: mtk_dpi: Rename bridge to next_bridge

2020-05-19 Thread Enric Balletbo i Serra
This is really a cosmetic change just to make a bit more readable the
code after convert the driver to drm_bridge. The bridge variable name
will be used by the encoder drm_bridge, and the chained bridge will be
named next_bridge.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Chun-Kuang Hu 
---

 drivers/gpu/drm/mediatek/mtk_dpi.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 7fbfa95bab09..7112125dc3d1 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -61,7 +61,7 @@ enum mtk_dpi_out_color_format {
 struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
-   struct drm_bridge *bridge;
+   struct drm_bridge *next_bridge;
void __iomem *regs;
struct device *dev;
struct clk *engine_clk;
@@ -607,7 +607,7 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
 
-   ret = drm_bridge_attach(>encoder, dpi->bridge, NULL, 0);
+   ret = drm_bridge_attach(>encoder, dpi->next_bridge, NULL, 0);
if (ret) {
dev_err(dev, "Failed to attach bridge: %d\n", ret);
goto err_cleanup;
@@ -747,11 +747,11 @@ static int mtk_dpi_probe(struct platform_device *pdev)
}
 
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
- NULL, >bridge);
+ NULL, >next_bridge);
if (ret)
return ret;
 
-   dev_info(dev, "Found bridge node: %pOF\n", dpi->bridge->of_node);
+   dev_info(dev, "Found bridge node: %pOF\n", dpi->next_bridge->of_node);
 
comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DPI);
if (comp_id < 0) {
-- 
2.26.2

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


[RESEND PATCH 0/3] Convert mtk-dpi to drm_bridge API

2020-05-19 Thread Enric Balletbo i Serra
The reason for this resend is because I forget to add some bridge
maintainers. So adding them and collect the actual tags.

The mtk-dpi driver still uses the drm_encoder API which is now somewhat
deprecated. We started to move all the Mediatek drivers to the drm_bridge API,
like we did for the mtk-dsi driver [1], this is another small step to be able to
fully convert the DRM Mediatek drivers to the drm_bridge API. A dummy
drm_encoder is maintained in the mtk-dpi driver but the end goal is move all the
dummy drm_encoder (mtk-dsi, mtk-dpi, etc) to the main mtk_drm_drv driver.

[1] https://lore.kernel.org/patchwork/project/lkml/list/?series=441559


Enric Balletbo i Serra (3):
  drm/mediatek: mtk_dpi: Rename bridge to next_bridge
  drm/mediatek: mtk_dpi: Convert to bridge driver
  drm/mediatek: mtk_dpi: Use simple encoder

 drivers/gpu/drm/mediatek/mtk_dpi.c | 84 ++
 1 file changed, 39 insertions(+), 45 deletions(-)

-- 
2.26.2

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


Re: [PATCH] drm/mediatek: Delete not used of_device_get_match_data

2020-05-19 Thread Enric Balletbo i Serra
Hi Matthias,

On 18/5/20 13:22, matthias@kernel.org wrote:
> From: Matthias Brugger 
> 
> The driver will be loaded by via a platform device. So we
> will need to get the device_node from the parent device.
> Depending on this we will set the driver data.
> As all this is done later already, just delete the call to
> of_device_get_match_data.
> 
> Signed-off-by: Matthias Brugger 

Reviewed-by: Enric Balletbo i Serra 

> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index e2bb0d19ef99..63ec92ba0e92 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -447,7 +447,6 @@ static int mtk_drm_probe(struct platform_device *pdev)
>   if (!private)
>   return -ENOMEM;
>  
> - private->data = of_device_get_match_data(dev);
>   private->mmsys_dev = dev->parent;
>   if (!private->mmsys_dev) {
>   dev_err(dev, "Failed to get MMSYS device\n");
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges

2020-05-15 Thread Enric Balletbo i Serra
Hi again,

On 14/5/20 19:12, Enric Balletbo i Serra wrote:
> Hi Chun-Kuang,
> 
> On 14/5/20 18:44, Chun-Kuang Hu wrote:
>> Hi, Enric:
>>
>> Enric Balletbo i Serra  於 2020年5月14日 週四 
>> 下午11:42寫道:
>>>
>>> Hi Chun-Kuang,
>>>
>>> On 14/5/20 16:28, Chun-Kuang Hu wrote:
>>>> Hi, Enric:
>>>>
>>>> Enric Balletbo Serra  於 2020年5月14日 週四 上午12:41寫道:
>>>>>
>>>>> Hi Chun-Kuang,
>>>>>
>>>>> Missatge de Enric Balletbo i Serra  del
>>>>> dia dv., 1 de maig 2020 a les 17:25:
>>>>>>
>>>>>> Use the drm_bridge_connector helper to create a connector for pipelines
>>>>>> that use drm_bridge. This allows splitting connector operations across
>>>>>> multiple bridges when necessary, instead of having the last bridge in
>>>>>> the chain creating the connector and handling all connector operations
>>>>>> internally.
>>>>>>
>>>>>> Signed-off-by: Enric Balletbo i Serra 
>>>>>> Acked-by: Sam Ravnborg 
>>>>>
>>>>> A gentle ping on this, I think that this one is the only one that
>>>>> still needs a review in the series.
>>>>
>>>> This is what I reply in patch v3:
>>>>
>>>
>>> Sorry for missing this.
>>>
>>>> I think the panel is wrapped into next_bridge here,
>>>>
>>>
>>> Yes, you can have for example:
>>>
>>> 1. drm_bridge (mtk_dsi) -> drm_bridge (ps8640 - dsi-to-edp) -> 
>>> drm_panel_bridge
>>> (edp panel)
>>>
>>> or a
>>>
>>> 2. drm_bridge (mtk_dsi)-> drm_panel_bridge (dsi panel)
>>>
>>> The _first_ one is my use case
>>>
>>>> if (panel) {
>>>
>>> This handles the second case, where you attach a dsi panel.
>>>
>>>> dsi->next_bridge = devm_drm_panel_bridge_add(dev, panel);
>>>>
>>>> so the next_bridge is a panel_bridge, in its attach function
>>>> panel_bridge_attach(),
>>>> according to the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, if not exist,
>>>> it would create connector and attach connector to panel.
>>>>
>>>> I'm not sure this flag would exist or not, but for both case, it's strange.
>>>> If exist, you create connector in this patch but no where to attach
>>>> connector to panel.
>>>
>>> Yes, in fact, this is transitional patch needed, as once I converted 
>>> mtk_dpi,
>>> mtk_dsi and mtk_hdmi to the new drm_bridge API the 
>>> drm_bridge_connector_init()
>>> will be done in mtk_drm_drv. We will need to call drm_bridge_connector_init 
>>> for
>>> dpi and dsi pipes and remove that call from mtk_dsi and mtk_dpi drivers. The
>>> graphic controller driver should create connectors and CRTCs, as example 
>>> you can
>>> take a look at drivers/gpu/drm/omapdrm/omap_drv.c
>>>
>>
>> I have such question because I've reviewed omap's driver. In omap's
>> driver, after it call drm_bridge_connector_init(), it does this:
>>
>> if (pipe->output->panel) {
>> ret = drm_panel_attach(pipe->output->panel,
>>   pipe->connector);
>> if (ret < 0)
>> return ret;
>> }
>>
>> In this patch, you does not do this.
>>
> 
> I see, so yes, I am probably missing call drm_panel_attach in case there is a
> direct panel attached. Thanks for pointing it.
> 
> I'll send a new version adding the drm_panel_attach call.
> 

Wait, shouldn't panel be attached on the call of mtk_dsi_bridge_attach as
next_bridge points to a bridge or a panel?

static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
 enum drm_bridge_attach_flags flags)
{
struct mtk_dsi *dsi = bridge_to_dsi(bridge);

/* Attach the panel or bridge to the dsi bridge */
return drm_bridge_attach(bridge->encoder, dsi->next_bridge,
 >bridge, flags);
}

Or I am continuing misunderstanding all this?

>>>> If not exist, the next_brige would create one connector and this brige
>>>> would create another connector.
>>>>
>>>> I think in your case, mtk_dsi does not directly connect to a panel, so
>>>
>>> Exactly
>>>
>>>> I need a exact explain. Or someone could test this on a
>>>> directly-connect-panel platform.
>>>
>>> I don't thi

Re: [PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges

2020-05-15 Thread Enric Balletbo i Serra
Hi Chun-Kuang,

On 14/5/20 16:28, Chun-Kuang Hu wrote:
> Hi, Enric:
> 
> Enric Balletbo Serra  於 2020年5月14日 週四 上午12:41寫道:
>>
>> Hi Chun-Kuang,
>>
>> Missatge de Enric Balletbo i Serra  del
>> dia dv., 1 de maig 2020 a les 17:25:
>>>
>>> Use the drm_bridge_connector helper to create a connector for pipelines
>>> that use drm_bridge. This allows splitting connector operations across
>>> multiple bridges when necessary, instead of having the last bridge in
>>> the chain creating the connector and handling all connector operations
>>> internally.
>>>
>>> Signed-off-by: Enric Balletbo i Serra 
>>> Acked-by: Sam Ravnborg 
>>
>> A gentle ping on this, I think that this one is the only one that
>> still needs a review in the series.
> 
> This is what I reply in patch v3:
> 

Sorry for missing this.

> I think the panel is wrapped into next_bridge here,
> 

Yes, you can have for example:

1. drm_bridge (mtk_dsi) -> drm_bridge (ps8640 - dsi-to-edp) -> drm_panel_bridge
(edp panel)

or a

2. drm_bridge (mtk_dsi)-> drm_panel_bridge (dsi panel)

The _first_ one is my use case

> if (panel) {

This handles the second case, where you attach a dsi panel.

> dsi->next_bridge = devm_drm_panel_bridge_add(dev, panel);
> 
> so the next_bridge is a panel_bridge, in its attach function
> panel_bridge_attach(),
> according to the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, if not exist,
> it would create connector and attach connector to panel.
> 
> I'm not sure this flag would exist or not, but for both case, it's strange.
> If exist, you create connector in this patch but no where to attach
> connector to panel.

Yes, in fact, this is transitional patch needed, as once I converted mtk_dpi,
mtk_dsi and mtk_hdmi to the new drm_bridge API the drm_bridge_connector_init()
will be done in mtk_drm_drv. We will need to call drm_bridge_connector_init for
dpi and dsi pipes and remove that call from mtk_dsi and mtk_dpi drivers. The
graphic controller driver should create connectors and CRTCs, as example you can
take a look at drivers/gpu/drm/omapdrm/omap_drv.c

> If not exist, the next_brige would create one connector and this brige
> would create another connector.
> 
> I think in your case, mtk_dsi does not directly connect to a panel, so

Exactly

> I need a exact explain. Or someone could test this on a
> directly-connect-panel platform.

I don't think I am breaking this use case but AFAICS there is no users in
mainline that directly connect a panel using the mediatek driver. As I said my
use case is the other so I can't really test. Do you know anyone that can test 
this?

Thanks,
 Enric

> 
> Regards,
> Chun-Kuang.
> 
>>
>> Thanks,
>>  Enric
>>
>>> ---
>>>
>>> Changes in v4: None
>>> Changes in v3:
>>> - Move the bridge.type line to the patch that adds drm_bridge support. 
>>> (Laurent Pinchart)
>>>
>>> Changes in v2: None
>>>
>>>  drivers/gpu/drm/mediatek/mtk_dsi.c | 13 -
>>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
>>> b/drivers/gpu/drm/mediatek/mtk_dsi.c
>>> index 4f3bd095c1ee..471fcafdf348 100644
>>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
>>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
>>> @@ -17,6 +17,7 @@
>>>
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -183,6 +184,7 @@ struct mtk_dsi {
>>> struct drm_encoder encoder;
>>> struct drm_bridge bridge;
>>> struct drm_bridge *next_bridge;
>>> +   struct drm_connector *connector;
>>> struct phy *phy;
>>>
>>> void __iomem *regs;
>>> @@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device 
>>> *drm, struct mtk_dsi *dsi)
>>>  */
>>> dsi->encoder.possible_crtcs = 1;
>>>
>>> -   ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
>>> +   ret = drm_bridge_attach(>encoder, >bridge, NULL,
>>> +   DRM_BRIDGE_ATTACH_NO_CONNECTOR);
>>> if (ret)
>>> goto err_cleanup_encoder;
>>>
>>> +   dsi->connector = drm_bridge_connector_init(drm, >encoder);
>>> +   if (IS_ERR(dsi->connector)) {
>>> +   DRM_ERROR("Unable to create bridge connector\n");
>>> +   ret = PTR_ERR(dsi->connector);
>>> +   goto err_cleanup_encoder;
>>> +   }
>>> +   drm_connector_attach_encoder(dsi->connector, >encoder);
>>> +
>>> return 0;
>>>
>>>  err_cleanup_encoder:
>>> --
>>> 2.26.2
>>>
>>>
>>> ___
>>> Linux-mediatek mailing list
>>> linux-media...@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges

2020-05-15 Thread Enric Balletbo i Serra
Hi Chun-Kuang,

On 14/5/20 18:44, Chun-Kuang Hu wrote:
> Hi, Enric:
> 
> Enric Balletbo i Serra  於 2020年5月14日 週四 
> 下午11:42寫道:
>>
>> Hi Chun-Kuang,
>>
>> On 14/5/20 16:28, Chun-Kuang Hu wrote:
>>> Hi, Enric:
>>>
>>> Enric Balletbo Serra  於 2020年5月14日 週四 上午12:41寫道:
>>>>
>>>> Hi Chun-Kuang,
>>>>
>>>> Missatge de Enric Balletbo i Serra  del
>>>> dia dv., 1 de maig 2020 a les 17:25:
>>>>>
>>>>> Use the drm_bridge_connector helper to create a connector for pipelines
>>>>> that use drm_bridge. This allows splitting connector operations across
>>>>> multiple bridges when necessary, instead of having the last bridge in
>>>>> the chain creating the connector and handling all connector operations
>>>>> internally.
>>>>>
>>>>> Signed-off-by: Enric Balletbo i Serra 
>>>>> Acked-by: Sam Ravnborg 
>>>>
>>>> A gentle ping on this, I think that this one is the only one that
>>>> still needs a review in the series.
>>>
>>> This is what I reply in patch v3:
>>>
>>
>> Sorry for missing this.
>>
>>> I think the panel is wrapped into next_bridge here,
>>>
>>
>> Yes, you can have for example:
>>
>> 1. drm_bridge (mtk_dsi) -> drm_bridge (ps8640 - dsi-to-edp) -> 
>> drm_panel_bridge
>> (edp panel)
>>
>> or a
>>
>> 2. drm_bridge (mtk_dsi)-> drm_panel_bridge (dsi panel)
>>
>> The _first_ one is my use case
>>
>>> if (panel) {
>>
>> This handles the second case, where you attach a dsi panel.
>>
>>> dsi->next_bridge = devm_drm_panel_bridge_add(dev, panel);
>>>
>>> so the next_bridge is a panel_bridge, in its attach function
>>> panel_bridge_attach(),
>>> according to the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, if not exist,
>>> it would create connector and attach connector to panel.
>>>
>>> I'm not sure this flag would exist or not, but for both case, it's strange.
>>> If exist, you create connector in this patch but no where to attach
>>> connector to panel.
>>
>> Yes, in fact, this is transitional patch needed, as once I converted mtk_dpi,
>> mtk_dsi and mtk_hdmi to the new drm_bridge API the 
>> drm_bridge_connector_init()
>> will be done in mtk_drm_drv. We will need to call drm_bridge_connector_init 
>> for
>> dpi and dsi pipes and remove that call from mtk_dsi and mtk_dpi drivers. The
>> graphic controller driver should create connectors and CRTCs, as example you 
>> can
>> take a look at drivers/gpu/drm/omapdrm/omap_drv.c
>>
> 
> I have such question because I've reviewed omap's driver. In omap's
> driver, after it call drm_bridge_connector_init(), it does this:
> 
> if (pipe->output->panel) {
> ret = drm_panel_attach(pipe->output->panel,
>   pipe->connector);
> if (ret < 0)
> return ret;
> }
> 
> In this patch, you does not do this.
> 

I see, so yes, I am probably missing call drm_panel_attach in case there is a
direct panel attached. Thanks for pointing it.

I'll send a new version adding the drm_panel_attach call.

>>> If not exist, the next_brige would create one connector and this brige
>>> would create another connector.
>>>
>>> I think in your case, mtk_dsi does not directly connect to a panel, so
>>
>> Exactly
>>
>>> I need a exact explain. Or someone could test this on a
>>> directly-connect-panel platform.
>>
>> I don't think I am breaking this use case but AFAICS there is no users in
>> mainline that directly connect a panel using the mediatek driver. As I said 
>> my
>> use case is the other so I can't really test. Do you know anyone that can 
>> test this?
> 
> I'm not sure who can test this, but [1], which is sent by YT Shen in a
> series, is a patch to support dsi command mode so dsi could directly
> connect to panel.
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/mediatek?h=v5.7-rc5=21898816831fc60c92dd634ab4316a24da7eb4af
> 
> It's better that someone could test this case, but if no one would
> test this, I could also accept a good-look patch.
> 
> Regards,
> Chun-Kuang.
> 
>>
>> Thanks,
>>  Enric
>>
>>>
>>> Regards,
>>> Chun-Kuang.
>>>
>>>>
>>>> Thanks,
>>>>  Enric
>>>>
>>>>> ---
>>>&

[PATCH 0/3] Convert mtk-dpi to drm_bridge API

2020-05-05 Thread Enric Balletbo i Serra
The mtk-dpi driver still uses the drm_encoder API which is now somehow
deprecated. We started to move all the Mediatek drivers to the drm_bridge API,
like we did for the mtk-dsi driver [1], this is another small step to be able to
fully convert the DRM Mediatek drivers to the drm_bridge API. A dummy
drm_encoder is maintained in the mtk-dpi driver but the end goal is move all the
dummy drm_encoder (mtk-dsi, mtk-dpi, etc) to the main mtk_drm_drv driver.

Best regards,
 Enric

[1] https://lore.kernel.org/patchwork/project/lkml/list/?series=441559

Enric Balletbo i Serra (3):
  drm/mediatek: mtk_dpi: Rename bridge to next_bridge
  drm/mediatek: mtk_dpi: Convert to bridge driver
  drm/mediatek: mtk_dpi: Use simple encoder

 drivers/gpu/drm/mediatek/mtk_dpi.c | 84 ++
 1 file changed, 39 insertions(+), 45 deletions(-)

-- 
2.26.2

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


[PATCH 1/3] drm/mediatek: mtk_dpi: Rename bridge to next_bridge

2020-05-05 Thread Enric Balletbo i Serra
This is really a cosmetic change just to make a bit more readable the
code after convert the driver to drm_bridge. The bridge variable name
will be used by the encoder drm_bridge, and the chained bridge will be
named next_bridge.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/mediatek/mtk_dpi.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 7fbfa95bab09..7112125dc3d1 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -61,7 +61,7 @@ enum mtk_dpi_out_color_format {
 struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
-   struct drm_bridge *bridge;
+   struct drm_bridge *next_bridge;
void __iomem *regs;
struct device *dev;
struct clk *engine_clk;
@@ -607,7 +607,7 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
 
-   ret = drm_bridge_attach(>encoder, dpi->bridge, NULL, 0);
+   ret = drm_bridge_attach(>encoder, dpi->next_bridge, NULL, 0);
if (ret) {
dev_err(dev, "Failed to attach bridge: %d\n", ret);
goto err_cleanup;
@@ -747,11 +747,11 @@ static int mtk_dpi_probe(struct platform_device *pdev)
}
 
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
- NULL, >bridge);
+ NULL, >next_bridge);
if (ret)
return ret;
 
-   dev_info(dev, "Found bridge node: %pOF\n", dpi->bridge->of_node);
+   dev_info(dev, "Found bridge node: %pOF\n", dpi->next_bridge->of_node);
 
comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DPI);
if (comp_id < 0) {
-- 
2.26.2

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


[PATCH 2/3] drm/mediatek: mtk_dpi: Convert to bridge driver

2020-05-05 Thread Enric Balletbo i Serra
Convert mtk_dpi to a bridge driver with built-in encoder support for
compatibility with existing component drivers.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/mediatek/mtk_dpi.c | 66 +++---
 1 file changed, 34 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 7112125dc3d1..baad198c69eb 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -61,6 +61,7 @@ enum mtk_dpi_out_color_format {
 struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
+   struct drm_bridge bridge;
struct drm_bridge *next_bridge;
void __iomem *regs;
struct device *dev;
@@ -77,9 +78,9 @@ struct mtk_dpi {
int refcount;
 };
 
-static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
+static inline struct mtk_dpi *bridge_to_dpi(struct drm_bridge *b)
 {
-   return container_of(e, struct mtk_dpi, encoder);
+   return container_of(b, struct mtk_dpi, bridge);
 }
 
 enum mtk_dpi_polarity {
@@ -518,50 +519,44 @@ static const struct drm_encoder_funcs 
mtk_dpi_encoder_funcs = {
.destroy = mtk_dpi_encoder_destroy,
 };
 
-static bool mtk_dpi_encoder_mode_fixup(struct drm_encoder *encoder,
-  const struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
+static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
 {
-   return true;
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+
+   return drm_bridge_attach(bridge->encoder, dpi->next_bridge,
+>bridge, flags);
 }
 
-static void mtk_dpi_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
+static void mtk_dpi_bridge_mode_set(struct drm_bridge *bridge,
+   const struct drm_display_mode *mode,
+   const struct drm_display_mode *adjusted_mode)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
drm_mode_copy(>mode, adjusted_mode);
 }
 
-static void mtk_dpi_encoder_disable(struct drm_encoder *encoder)
+static void mtk_dpi_bridge_disable(struct drm_bridge *bridge)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
mtk_dpi_power_off(dpi);
 }
 
-static void mtk_dpi_encoder_enable(struct drm_encoder *encoder)
+static void mtk_dpi_bridge_enable(struct drm_bridge *bridge)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
mtk_dpi_power_on(dpi);
mtk_dpi_set_display_mode(dpi, >mode);
 }
 
-static int mtk_dpi_atomic_check(struct drm_encoder *encoder,
-   struct drm_crtc_state *crtc_state,
-   struct drm_connector_state *conn_state)
-{
-   return 0;
-}
-
-static const struct drm_encoder_helper_funcs mtk_dpi_encoder_helper_funcs = {
-   .mode_fixup = mtk_dpi_encoder_mode_fixup,
-   .mode_set = mtk_dpi_encoder_mode_set,
-   .disable = mtk_dpi_encoder_disable,
-   .enable = mtk_dpi_encoder_enable,
-   .atomic_check = mtk_dpi_atomic_check,
+static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
+   .attach = mtk_dpi_bridge_attach,
+   .mode_set = mtk_dpi_bridge_mode_set,
+   .disable = mtk_dpi_bridge_disable,
+   .enable = mtk_dpi_bridge_enable,
 };
 
 static void mtk_dpi_start(struct mtk_ddp_comp *comp)
@@ -602,16 +597,13 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
dev_err(dev, "Failed to initialize decoder: %d\n", ret);
goto err_unregister;
}
-   drm_encoder_helper_add(>encoder, _dpi_encoder_helper_funcs);
 
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
 
-   ret = drm_bridge_attach(>encoder, dpi->next_bridge, NULL, 0);
-   if (ret) {
-   dev_err(dev, "Failed to attach bridge: %d\n", ret);
+   ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
+   if (ret)
goto err_cleanup;
-   }
 
dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
@@ -768,8 +760,15 @@ static int mtk_dpi_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, dpi);
 
+   dpi->bridge.funcs = _dpi_bridge_funcs;
+   dpi->bridge.of_node = dev->of_node;
+   dpi->bridge.type = DRM_MODE_CONNECTOR_DPI;
+
+   drm_bri

[PATCH 3/3] drm/mediatek: mtk_dpi: Use simple encoder

2020-05-05 Thread Enric Balletbo i Serra
The mtk_dpi driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index baad198c69eb..80778b2aac2a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mtk_dpi_regs.h"
 #include "mtk_drm_ddp_comp.h"
@@ -510,15 +511,6 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
return 0;
 }
 
-static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
-{
-   drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
-   .destroy = mtk_dpi_encoder_destroy,
-};
-
 static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
 enum drm_bridge_attach_flags flags)
 {
@@ -591,8 +583,8 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
return ret;
}
 
-   ret = drm_encoder_init(drm_dev, >encoder, _dpi_encoder_funcs,
-  DRM_MODE_ENCODER_TMDS, NULL);
+   ret = drm_simple_encoder_init(drm_dev, >encoder,
+ DRM_MODE_ENCODER_TMDS);
if (ret) {
dev_err(dev, "Failed to initialize decoder: %d\n", ret);
goto err_unregister;
-- 
2.26.2

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


[PATCH v4 0/7] Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge

2020-05-02 Thread Enric Balletbo i Serra
The PS8640 dsi-to-eDP bridge driver is using the panel bridge API,
however, not all the components in the chain have been ported to the
drm_bridge API. Actually, when a panel is attached the default panel's mode
is used, but in some cases we can't get display up if mode getting from
eDP control EDID is not chosen.

This series address that problem, first implements the .get_edid()
callback in the PS8640 driver (which is not used until the conversion is
done) and then, converts the Mediatek DSI driver to use the drm_bridge
API.

As far as I know, we're the only users of the mediatek dsi driver in
mainline, so should be safe to switch to the new chain of drm_bridge API
unconditionally.

The patches has been tested on a Acer Chromebook R13 (Elm) running a
Chrome OS userspace and checking that the valid EDID mode reported by
the bridge is selected.

Enric Balletbo i Serra (7):
  drm/bridge: ps8640: Get the EDID from eDP control
  drm/bridge_connector: Set default status connected for eDP connectors
  drm/mediatek: mtk_dsi: Rename bridge to next_bridge
  drm/mediatek: mtk_dsi: Convert to bridge driver
  drm/mediatek: mtk_dsi: Use simple encoder
  drm/mediatek: mtk_dsi: Use the drm_panel_bridge API
  drm/mediatek: mtk_dsi: Create connector for bridges

 drivers/gpu/drm/bridge/parade-ps8640.c |  12 ++
 drivers/gpu/drm/drm_bridge_connector.c |   1 +
 drivers/gpu/drm/mediatek/mtk_dsi.c | 277 -
 3 files changed, 97 insertions(+), 193 deletions(-)

-- 
2.26.2

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


[PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges

2020-05-02 Thread Enric Balletbo i Serra
Use the drm_bridge_connector helper to create a connector for pipelines
that use drm_bridge. This allows splitting connector operations across
multiple bridges when necessary, instead of having the last bridge in
the chain creating the connector and handling all connector operations
internally.

Signed-off-by: Enric Balletbo i Serra 
Acked-by: Sam Ravnborg 
---

Changes in v4: None
Changes in v3:
- Move the bridge.type line to the patch that adds drm_bridge support. (Laurent 
Pinchart)

Changes in v2: None

 drivers/gpu/drm/mediatek/mtk_dsi.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 4f3bd095c1ee..471fcafdf348 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -183,6 +184,7 @@ struct mtk_dsi {
struct drm_encoder encoder;
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
+   struct drm_connector *connector;
struct phy *phy;
 
void __iomem *regs;
@@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, 
struct mtk_dsi *dsi)
 */
dsi->encoder.possible_crtcs = 1;
 
-   ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
+   ret = drm_bridge_attach(>encoder, >bridge, NULL,
+   DRM_BRIDGE_ATTACH_NO_CONNECTOR);
if (ret)
goto err_cleanup_encoder;
 
+   dsi->connector = drm_bridge_connector_init(drm, >encoder);
+   if (IS_ERR(dsi->connector)) {
+   DRM_ERROR("Unable to create bridge connector\n");
+   ret = PTR_ERR(dsi->connector);
+   goto err_cleanup_encoder;
+   }
+   drm_connector_attach_encoder(dsi->connector, >encoder);
+
return 0;
 
 err_cleanup_encoder:
-- 
2.26.2

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


[PATCH v4 3/7] drm/mediatek: mtk_dsi: Rename bridge to next_bridge

2020-05-02 Thread Enric Balletbo i Serra
This is really a cosmetic change just to make a bit more readable the
code after convert the driver to drm_bridge. The bridge variable name
will be used by the encoder drm_bridge, and the chained bridge will be
named next_bridge.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
---

Changes in v4: None
Changes in v3:
- Replace s/bridge/next bridge/ for comment. (Laurent Pinchart)

Changes in v2: None

 drivers/gpu/drm/mediatek/mtk_dsi.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index cfa45d6abd74..37b8d7ffd835 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -182,7 +182,7 @@ struct mtk_dsi {
struct drm_encoder encoder;
struct drm_connector conn;
struct drm_panel *panel;
-   struct drm_bridge *bridge;
+   struct drm_bridge *next_bridge;
struct phy *phy;
 
void __iomem *regs;
@@ -902,9 +902,10 @@ static int mtk_dsi_create_conn_enc(struct drm_device *drm, 
struct mtk_dsi *dsi)
 */
dsi->encoder.possible_crtcs = 1;
 
-   /* If there's a bridge, attach to it and let it create the connector */
-   if (dsi->bridge) {
-   ret = drm_bridge_attach(>encoder, dsi->bridge, NULL, 0);
+   /* If there's a next bridge, attach to it and let it create the 
connector */
+   if (dsi->next_bridge) {
+   ret = drm_bridge_attach(>encoder, dsi->next_bridge, NULL,
+   0);
if (ret) {
DRM_ERROR("Failed to attach bridge to drm\n");
goto err_encoder_cleanup;
@@ -1185,7 +1186,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
}
 
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
- >panel, >bridge);
+ >panel, >next_bridge);
if (ret)
goto err_unregister_host;
 
-- 
2.26.2

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


Re: [PATCH v3 7/7] drm/mediatek: mtk_dsi: Create connector for bridges

2020-05-02 Thread Enric Balletbo i Serra
Hi Chun-Kuang,

Thank you for your review.

On 1/5/20 16:26, Chun-Kuang Hu wrote:
> Hi, Enric:
> 
> Enric Balletbo i Serra  於 2020年4月17日 週五 
> 下午11:06寫道:
>>
>> Use the drm_bridge_connector helper to create a connector for pipelines
>> that use drm_bridge. This allows splitting connector operations across
>> multiple bridges when necessary, instead of having the last bridge in
>> the chain creating the connector and handling all connector operations
>> internally.
>>
>> Signed-off-by: Enric Balletbo i Serra 
>> ---
>>
>> Changes in v3:
>> - Move the bridge.type line to the patch that adds drm_bridge support. 
>> (Laurent Pinchart)
>>
>> Changes in v2: None
>>
>>  drivers/gpu/drm/mediatek/mtk_dsi.c | 13 -
>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
>> b/drivers/gpu/drm/mediatek/mtk_dsi.c
>> index 157097c63b23..85f76b01ae4d 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
>> @@ -17,6 +17,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -183,6 +184,7 @@ struct mtk_dsi {
>> struct drm_encoder encoder;
>> struct drm_bridge bridge;
>> struct drm_bridge *next_bridge;
>> +   struct drm_connector *connector;
>> struct phy *phy;
>>
>> void __iomem *regs;
>> @@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device 
>> *drm, struct mtk_dsi *dsi)
>>  */
>> dsi->encoder.possible_crtcs = 1;
>>
>> -   ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
>> +   ret = drm_bridge_attach(>encoder, >bridge, NULL,
>> +   DRM_BRIDGE_ATTACH_NO_CONNECTOR);
>> if (ret)
>> goto err_cleanup_encoder;
>>
>> +   dsi->connector = drm_bridge_connector_init(drm, >encoder);
>> +   if (IS_ERR(dsi->connector)) {
>> +   DRM_ERROR("Unable to create bridge connector\n");
>> +   ret = PTR_ERR(dsi->connector);
>> +   goto err_cleanup_encoder;
>> +   }
>> +   drm_connector_attach_encoder(dsi->connector, >encoder);
>> +
> 
> I'm not very clear about how brige-connector works, but why connector
> does not attach to panel?
> 

Laurent or other drm maintainers might have more details than me, but, AFAIK the
drm_bridge_connector_init initializes a connector for a chain of bridges that
starts at the @encoder. At this point you don't know which bridge is connected
to the panel physically but doesn't really matter as what you know is that will
be only one connector in the  chain.

Thanks,
 Enric

> Regards,
> Chun-Kuang.
> 
>> return 0;
>>
>>  err_cleanup_encoder:
>> --
>> 2.25.1
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 1/7] drm/bridge: ps8640: Get the EDID from eDP control

2020-05-02 Thread Enric Balletbo i Serra
The PS8640 DSI-to-eDP bridge can retrieve the EDID, so implement the
.get_edid callback and set the flag to indicate the core to use it.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/parade-ps8640.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 4b099196afeb..13755d278db6 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -242,8 +242,18 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge,
return ret;
 }
 
+static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge,
+  struct drm_connector *connector)
+{
+   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+   return drm_get_edid(connector,
+   ps_bridge->page[PAGE0_DP_CNTL]->adapter);
+}
+
 static const struct drm_bridge_funcs ps8640_bridge_funcs = {
.attach = ps8640_bridge_attach,
+   .get_edid = ps8640_bridge_get_edid,
.post_disable = ps8640_post_disable,
.pre_enable = ps8640_pre_enable,
 };
@@ -294,6 +304,8 @@ static int ps8640_probe(struct i2c_client *client)
 
ps_bridge->bridge.funcs = _bridge_funcs;
ps_bridge->bridge.of_node = dev->of_node;
+   ps_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
+   ps_bridge->bridge.type = DRM_MODE_CONNECTOR_eDP;
 
ps_bridge->page[PAGE0_DP_CNTL] = client;
 
-- 
2.26.2

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


[PATCH v4 6/7] drm/mediatek: mtk_dsi: Use the drm_panel_bridge API

2020-05-02 Thread Enric Balletbo i Serra
Replace the manual panel handling code by a drm_panel_bridge. This
simplifies the driver and allows all components in the display pipeline
to be treated as bridges, paving the way to generic connector handling.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
Reviewed-by: Chun-Kuang Hu 
---

Changes in v4: None
Changes in v3:
- Use next_bridge field to store the panel bridge. (Laurent Pinchart)
- Add the bridge.type field. (Laurent Pinchart)
- This patch requires https://lkml.org/lkml/2020/4/16/2080 to work
  properly.

Changes in v2:
- Do not set connector_type for panel here. (Sam Ravnborg)

 drivers/gpu/drm/mediatek/mtk_dsi.c | 173 +++--
 1 file changed, 14 insertions(+), 159 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index e02d16a086ac..4f3bd095c1ee 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -182,8 +182,6 @@ struct mtk_dsi {
struct mipi_dsi_host host;
struct drm_encoder encoder;
struct drm_bridge bridge;
-   struct drm_connector conn;
-   struct drm_panel *panel;
struct drm_bridge *next_bridge;
struct phy *phy;
 
@@ -212,11 +210,6 @@ static inline struct mtk_dsi *bridge_to_dsi(struct 
drm_bridge *b)
return container_of(b, struct mtk_dsi, bridge);
 }
 
-static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
-{
-   return container_of(c, struct mtk_dsi, conn);
-}
-
 static inline struct mtk_dsi *host_to_dsi(struct mipi_dsi_host *h)
 {
return container_of(h, struct mtk_dsi, host);
@@ -682,16 +675,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
mtk_dsi_lane0_ulp_mode_leave(dsi);
mtk_dsi_clk_hs_mode(dsi, 0);
 
-   if (dsi->panel) {
-   if (drm_panel_prepare(dsi->panel)) {
-   DRM_ERROR("failed to prepare the panel\n");
-   goto err_disable_digital_clk;
-   }
-   }
-
return 0;
-err_disable_digital_clk:
-   clk_disable_unprepare(dsi->digital_clk);
 err_disable_engine_clk:
clk_disable_unprepare(dsi->engine_clk);
 err_phy_power_off:
@@ -718,15 +702,7 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
 */
mtk_dsi_stop(dsi);
 
-   if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
-   if (dsi->panel) {
-   if (drm_panel_unprepare(dsi->panel)) {
-   DRM_ERROR("failed to unprepare the panel\n");
-   return;
-   }
-   }
-   }
-
+   mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500);
mtk_dsi_reset_engine(dsi);
mtk_dsi_lane0_ulp_mode_enter(dsi);
mtk_dsi_clk_ulp_mode_enter(dsi);
@@ -757,19 +733,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
 
mtk_dsi_start(dsi);
 
-   if (dsi->panel) {
-   if (drm_panel_enable(dsi->panel)) {
-   DRM_ERROR("failed to enable the panel\n");
-   goto err_dsi_power_off;
-   }
-   }
-
dsi->enabled = true;
-
-   return;
-err_dsi_power_off:
-   mtk_dsi_stop(dsi);
-   mtk_dsi_poweroff(dsi);
 }
 
 static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
@@ -777,34 +741,19 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
if (!dsi->enabled)
return;
 
-   if (dsi->panel) {
-   if (drm_panel_disable(dsi->panel)) {
-   DRM_ERROR("failed to disable the panel\n");
-   return;
-   }
-   }
-
mtk_dsi_poweroff(dsi);
 
dsi->enabled = false;
 }
 
-static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi 
*dsi);
-static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
-
 static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
 enum drm_bridge_attach_flags flags)
 {
struct mtk_dsi *dsi = bridge_to_dsi(bridge);
 
-   return mtk_dsi_create_conn_enc(bridge->dev, dsi);
-}
-
-static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
-{
-   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
-
-   mtk_dsi_destroy_conn_enc(dsi);
+   /* Attach the panel or bridge to the dsi bridge */
+   return drm_bridge_attach(bridge->encoder, dsi->next_bridge,
+>bridge, flags);
 }
 
 static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
@@ -830,101 +779,13 @@ static void mtk_dsi_bridge_enable(struct drm_bridge 
*bridge)
mtk_output_dsi_enable(dsi);
 }
 
-static int mtk_dsi_connector_get_modes(struct drm_connector *connector)
-{
-   struct mtk_dsi *dsi = connector_to_dsi(connector);
-
-   return drm_panel_get_mo

[PATCH v4 4/7] drm/mediatek: mtk_dsi: Convert to bridge driver

2020-05-02 Thread Enric Balletbo i Serra
Convert mtk_dsi to a bridge driver with built-in encoder support for
compatibility with existing component drivers.

Signed-off-by: Enric Balletbo i Serra 
Acked-by: Sam Ravnborg 
---

Changes in v4:
- Remove double call to drm_encoder_init(). (Chun-Kuang Hu)
- Cleanup the encoder in mtk_dsi_unbind(). (Chun-Kuang Hu)

Changes in v3:
- Add the bridge.type. (Laurent Pinchart)

Changes in v2: None

 drivers/gpu/drm/mediatek/mtk_dsi.c | 108 +++--
 1 file changed, 70 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 37b8d7ffd835..38cbdcb15fff 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -180,6 +180,7 @@ struct mtk_dsi {
struct device *dev;
struct mipi_dsi_host host;
struct drm_encoder encoder;
+   struct drm_bridge bridge;
struct drm_connector conn;
struct drm_panel *panel;
struct drm_bridge *next_bridge;
@@ -205,9 +206,9 @@ struct mtk_dsi {
const struct mtk_dsi_driver_data *driver_data;
 };
 
-static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
+static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
 {
-   return container_of(e, struct mtk_dsi, encoder);
+   return container_of(b, struct mtk_dsi, bridge);
 }
 
 static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
@@ -796,32 +797,43 @@ static const struct drm_encoder_funcs 
mtk_dsi_encoder_funcs = {
.destroy = mtk_dsi_encoder_destroy,
 };
 
-static bool mtk_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
-  const struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
+static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi 
*dsi);
+static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
+
+static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
 {
-   return true;
+   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
+
+   return mtk_dsi_create_conn_enc(bridge->dev, dsi);
+}
+
+static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
+{
+   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
+
+   mtk_dsi_destroy_conn_enc(dsi);
 }
 
-static void mtk_dsi_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted)
+static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
+   const struct drm_display_mode *mode,
+   const struct drm_display_mode *adjusted)
 {
-   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
 
drm_display_mode_to_videomode(adjusted, >vm);
 }
 
-static void mtk_dsi_encoder_disable(struct drm_encoder *encoder)
+static void mtk_dsi_bridge_disable(struct drm_bridge *bridge)
 {
-   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
 
mtk_output_dsi_disable(dsi);
 }
 
-static void mtk_dsi_encoder_enable(struct drm_encoder *encoder)
+static void mtk_dsi_bridge_enable(struct drm_bridge *bridge)
 {
-   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
 
mtk_output_dsi_enable(dsi);
 }
@@ -833,11 +845,12 @@ static int mtk_dsi_connector_get_modes(struct 
drm_connector *connector)
return drm_panel_get_modes(dsi->panel, connector);
 }
 
-static const struct drm_encoder_helper_funcs mtk_dsi_encoder_helper_funcs = {
-   .mode_fixup = mtk_dsi_encoder_mode_fixup,
-   .mode_set = mtk_dsi_encoder_mode_set,
-   .disable = mtk_dsi_encoder_disable,
-   .enable = mtk_dsi_encoder_enable,
+static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
+   .attach = mtk_dsi_bridge_attach,
+   .detach = mtk_dsi_bridge_detach,
+   .disable = mtk_dsi_bridge_disable,
+   .enable = mtk_dsi_bridge_enable,
+   .mode_set = mtk_dsi_bridge_mode_set,
 };
 
 static const struct drm_connector_funcs mtk_dsi_connector_funcs = {
@@ -888,20 +901,6 @@ static int mtk_dsi_create_conn_enc(struct drm_device *drm, 
struct mtk_dsi *dsi)
 {
int ret;
 
-   ret = drm_encoder_init(drm, >encoder, _dsi_encoder_funcs,
-  DRM_MODE_ENCODER_DSI, NULL);
-   if (ret) {
-   DRM_ERROR("Failed to encoder init to drm\n");
-   return ret;
-   }
-   drm_encoder_helper_add(>encoder, _dsi_encoder_helper_funcs);
-
-   /*
-* Currently display data paths are statically assigned to a crtc each.
-* crtc 0 is OVL0 -> COLOR0 -> AAL -> OD -> RDMA0 -> UFOE -> DSI0
-*/
-   dsi->encoder.poss

[PATCH v4 5/7] drm/mediatek: mtk_dsi: Use simple encoder

2020-05-02 Thread Enric Balletbo i Serra
The mtk_dsi driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
Reviewed-by: Chun-Kuang Hu 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 38cbdcb15fff..e02d16a086ac 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mtk_drm_ddp_comp.h"
 
@@ -788,15 +789,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
dsi->enabled = false;
 }
 
-static void mtk_dsi_encoder_destroy(struct drm_encoder *encoder)
-{
-   drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs mtk_dsi_encoder_funcs = {
-   .destroy = mtk_dsi_encoder_destroy,
-};
-
 static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi 
*dsi);
 static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
 
@@ -1126,8 +1118,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, 
struct mtk_dsi *dsi)
 {
int ret;
 
-   ret = drm_encoder_init(drm, >encoder, _dsi_encoder_funcs,
-  DRM_MODE_ENCODER_DSI, NULL);
+   ret = drm_simple_encoder_init(drm, >encoder,
+ DRM_MODE_ENCODER_DSI);
if (ret) {
DRM_ERROR("Failed to encoder init to drm\n");
return ret;
-- 
2.26.2

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


Re: [PATCH v3 4/7] drm/mediatek: mtk_dsi: Convert to bridge driver

2020-05-02 Thread Enric Balletbo i Serra
Hi Chun-Kuang,

Thank you for the review.

On 1/5/20 15:21, Chun-Kuang Hu wrote:
> Hi, Enric:
> 
> Enric Balletbo i Serra  於 2020年4月17日 週五 
> 下午11:06寫道:
>>
>> Convert mtk_dsi to a bridge driver with built-in encoder support for
>> compatibility with existing component drivers.
>>
>> Signed-off-by: Enric Balletbo i Serra 
>> ---
>>
>> Changes in v3:
>> - Add the bridge.type. (Laurent Pinchart)
>>
>> Changes in v2: None
>>
>>  drivers/gpu/drm/mediatek/mtk_dsi.c | 93 ++
>>  1 file changed, 69 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
>> b/drivers/gpu/drm/mediatek/mtk_dsi.c
>> index 37b8d7ffd835..869ae0a2e9f8 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
>> @@ -180,6 +180,7 @@ struct mtk_dsi {
>> struct device *dev;
>> struct mipi_dsi_host host;
>> struct drm_encoder encoder;
>> +   struct drm_bridge bridge;
>> struct drm_connector conn;
>> struct drm_panel *panel;
>> struct drm_bridge *next_bridge;
>> @@ -205,9 +206,9 @@ struct mtk_dsi {
>> const struct mtk_dsi_driver_data *driver_data;
>>  };
>>
>> -static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
>> +static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
>>  {
>> -   return container_of(e, struct mtk_dsi, encoder);
>> +   return container_of(b, struct mtk_dsi, bridge);
>>  }
>>
>>  static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
>> @@ -796,32 +797,43 @@ static const struct drm_encoder_funcs 
>> mtk_dsi_encoder_funcs = {
>> .destroy = mtk_dsi_encoder_destroy,
>>  };
>>
>> -static bool mtk_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
>> -  const struct drm_display_mode *mode,
>> -  struct drm_display_mode 
>> *adjusted_mode)
>> +static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi 
>> *dsi);
>> +static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
>> +
>> +static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
>> +enum drm_bridge_attach_flags flags)
>> +{
>> +   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>> +
>> +   return mtk_dsi_create_conn_enc(bridge->dev, dsi);
>> +}
>> +
>> +static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
>>  {
>> -   return true;
>> +   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>> +
>> +   mtk_dsi_destroy_conn_enc(dsi);
>>  }
>>
>> -static void mtk_dsi_encoder_mode_set(struct drm_encoder *encoder,
>> -struct drm_display_mode *mode,
>> -struct drm_display_mode *adjusted)
>> +static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
>> +   const struct drm_display_mode *mode,
>> +   const struct drm_display_mode *adjusted)
>>  {
>> -   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
>> +   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>>
>> drm_display_mode_to_videomode(adjusted, >vm);
>>  }
>>
>> -static void mtk_dsi_encoder_disable(struct drm_encoder *encoder)
>> +static void mtk_dsi_bridge_disable(struct drm_bridge *bridge)
>>  {
>> -   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
>> +   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>>
>> mtk_output_dsi_disable(dsi);
>>  }
>>
>> -static void mtk_dsi_encoder_enable(struct drm_encoder *encoder)
>> +static void mtk_dsi_bridge_enable(struct drm_bridge *bridge)
>>  {
>> -   struct mtk_dsi *dsi = encoder_to_dsi(encoder);
>> +   struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>>
>> mtk_output_dsi_enable(dsi);
>>  }
>> @@ -833,11 +845,12 @@ static int mtk_dsi_connector_get_modes(struct 
>> drm_connector *connector)
>> return drm_panel_get_modes(dsi->panel, connector);
>>  }
>>
>> -static const struct drm_encoder_helper_funcs mtk_dsi_encoder_helper_funcs = 
>> {
>> -   .mode_fixup = mtk_dsi_encoder_mode_fixup,
>> -   .mode_set = mtk_dsi_encoder_mode_set,
>> -   .disable = mtk_dsi_encoder_disable,
>> -   .enable = mtk_dsi_encoder_enable,
>>

[PATCH v4 2/7] drm/bridge_connector: Set default status connected for eDP connectors

2020-05-02 Thread Enric Balletbo i Serra
In an eDP application, HPD is not required and on most bridge chips
useless. If HPD is not used, we need to set initial status as connected,
otherwise the connector created by the drm_bridge_connector API remains
in an unknown state.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/drm_bridge_connector.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_bridge_connector.c 
b/drivers/gpu/drm/drm_bridge_connector.c
index c6994fe673f3..a58cbde59c34 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -187,6 +187,7 @@ drm_bridge_connector_detect(struct drm_connector 
*connector, bool force)
case DRM_MODE_CONNECTOR_DPI:
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_DSI:
+   case DRM_MODE_CONNECTOR_eDP:
status = connector_status_connected;
break;
default:
-- 
2.26.2

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


Re: [PATCH v3 -next] drm/mediatek: Fix Kconfig warning

2020-04-30 Thread Enric Balletbo i Serra
Hi YueHaibing,

Thank you for your patch.

On 29/4/20 9:13, YueHaibing wrote:
> WARNING: unmet direct dependencies detected for MTK_MMSYS
>   Depends on [n]: (ARCH_MEDIATEK [=y] || COMPILE_TEST [=n]) && 
> COMMON_CLK_MT8173_MMSYS [=n]
>   Selected by [y]:
>   - DRM_MEDIATEK [=y] && HAS_IOMEM [=y] && DRM [=y] && (ARCH_MEDIATEK [=y] || 
> ARM && COMPILE_TEST [=n]) && COMMON_CLK [=y] && HAVE_ARM_SMCCC [=y] && OF [=y]
> 
> Make DRM_MEDIATEK depend on MTK_MMSYS to fix this.
> 
> Fixes: 2c758e301ed9 ("soc / drm: mediatek: Move routing control to mmsys 
> device")
> Signed-off-by: YueHaibing 

Definitively we shouldn't select the MTK_MMSYS and we should depend on MTK_MMSYS
instead, so

Reviewed-by: Enric Balletbo i Serra 

> ---
> v3: make DRM_MEDIATEK depends on MTK_MMSYS
> v2: select COMMON_CLK_MT8173_MMSYS instead of adding DRM_MEDIATEK dependency  
> ---
>  drivers/gpu/drm/mediatek/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/Kconfig 
> b/drivers/gpu/drm/mediatek/Kconfig
> index c420f5a3d33b..aa74aac3cbcc 100644
> --- a/drivers/gpu/drm/mediatek/Kconfig
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> @@ -6,12 +6,12 @@ config DRM_MEDIATEK
>   depends on COMMON_CLK
>   depends on HAVE_ARM_SMCCC
>   depends on OF
> + depends on MTK_MMSYS
>   select DRM_GEM_CMA_HELPER
>   select DRM_KMS_HELPER
>   select DRM_MIPI_DSI
>   select DRM_PANEL
>   select MEMORY
> - select MTK_MMSYS
>   select MTK_SMI
>   select VIDEOMODE_HELPERS
>   help
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/rockchip: cdn-dp-core: Make cdn_dp_core_suspend/resume __maybe_unused

2020-04-29 Thread Enric Balletbo i Serra
Hi Arnd,

On 28/4/20 23:31, Arnd Bergmann wrote:
> With the new static annotation, the compiler warns when the functions
> are actually unused:
> 

Right, thank you for the patch.

> drivers/gpu/drm/rockchip/cdn-dp-core.c:1123:12: error: 'cdn_dp_resume' 
> defined but not used [-Werror=unused-function]
>  1123 | static int cdn_dp_resume(struct device *dev)
>   |^
> 
> Mark them __maybe_unused to suppress that warning as well.
> 
> Fixes: 7c49abb4c2f8 ("drm/rockchip: cdn-dp-core: Make 
> cdn_dp_core_suspend/resume static")
> Signed-off-by: Arnd Bergmann 

Reviewed-by: Enric Balletbo i Serra 

> ---
>  drivers/gpu/drm/rockchip/cdn-dp-core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index c634b95b50f7..1cde98c6b0e6 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -1106,7 +1106,7 @@ static const struct component_ops cdn_dp_component_ops 
> = {
>   .unbind = cdn_dp_unbind,
>  };
>  
> -static int cdn_dp_suspend(struct device *dev)
> +static __maybe_unused int cdn_dp_suspend(struct device *dev)
>  {
>   struct cdn_dp_device *dp = dev_get_drvdata(dev);
>   int ret = 0;
> @@ -1120,7 +1120,7 @@ static int cdn_dp_suspend(struct device *dev)
>   return ret;
>  }
>  
> -static int cdn_dp_resume(struct device *dev)
> +static __maybe_unused int cdn_dp_resume(struct device *dev)
>  {
>   struct cdn_dp_device *dp = dev_get_drvdata(dev);
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v8 05/10] drm: imx: Add i.MX 6 MIPI DSI host platform driver

2020-04-28 Thread Enric Balletbo i Serra
Hi Adrian

Thank you for your patch.

On 27/4/20 10:19, Adrian Ratiu wrote:
> This adds support for the Synopsis DesignWare MIPI DSI v1.01 host
> controller which is embedded in i.MX 6 SoCs.
> 
> Based on following patches, but updated/extended to work with existing
> support found in the kernel:
> 
> - drm: imx: Support Synopsys DesignWare MIPI DSI host controller
>   Signed-off-by: Liu Ying 
> 
> Cc: Fabio Estevam 
> Cc: Enric Balletbo Serra 
> Reviewed-by: Emil Velikov 
> Tested-by: Adrian Pop 
> Tested-by: Arnaud Ferraris 
> Signed-off-by: Sjoerd Simons 
> Signed-off-by: Martyn Welch 
> Signed-off-by: Adrian Ratiu 
> ---
> Changes since v7:
>   - Removed encoder helper ops and added drm_bridge (Laurent)
>   - Brought back drm_simple_encoder_init and dropped dependency on
>   external unify encoder creation patch (Laurent)
>   - Minor typo fixes
> 
> Changes since v6:
>   - Replaced custom noop encoder with the simple drm encoder (Enric)
>   - Added CONFIG_DRM_IMX6_MIPI_DSI depends on CONFIG_OF (Enric)
>   - Dropped imx_mipi_dsi_register() because now it only creates the
>   dummy encoder which can easily be done directly in imx_dsi_bind()
> 
> Changes since v5:
>   - Reword to remove unrelated device tree patch mention (Fabio)
>   - Move pllref_clk enable/disable to bind/unbind (Ezequiel)
>   - Fix freescale.com -> nxp.com email addresses (Fabio)
>   - Also added myself as module author (Fabio)
>   - Use DRM_DEV_* macros for consistency, print more error msg
> 
> Changes since v4:
>   - Split off driver-specific configuration of phy timings due
>   to new upstream API.
>   - Move regmap infrastructure logic to separate commit (Ezequiel)
>   - Move dsi v1.01 layout addition to a separate commit (Ezequiel)
>   - Minor warnings and driver name fixes
> 
> Changes since v3:
>   - Renamed platform driver to reflect it's i.MX6 only. (Fabio)
> 
> Changes since v2:
>   - Fixed commit tags. (Emil)
> 
> Changes since v1:
>   - Moved register definitions & regmap initialization into bridge
>   module. Platform drivers get the regmap via plat_data after
>   calling the bridge probe. (Emil)
> ---
>  drivers/gpu/drm/imx/Kconfig|   8 +
>  drivers/gpu/drm/imx/Makefile   |   1 +
>  drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c | 399 +
>  3 files changed, 408 insertions(+)
>  create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> 
> diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
> index 207bf7409dfba..0dffc72df7922 100644
> --- a/drivers/gpu/drm/imx/Kconfig
> +++ b/drivers/gpu/drm/imx/Kconfig
> @@ -39,3 +39,11 @@ config DRM_IMX_HDMI
>   depends on DRM_IMX
>   help
> Choose this if you want to use HDMI on i.MX6.
> +
> +config DRM_IMX6_MIPI_DSI
> + tristate "Freescale i.MX6 DRM MIPI DSI"
> + select DRM_DW_MIPI_DSI
> + depends on DRM_IMX
> + depends on OF
> + help
> +   Choose this if you want to use MIPI DSI on i.MX6.
> diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
> index 21cdcc2faabc8..9a7843c593478 100644
> --- a/drivers/gpu/drm/imx/Makefile
> +++ b/drivers/gpu/drm/imx/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
>  obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
>  
>  obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
> +obj-$(CONFIG_DRM_IMX6_MIPI_DSI) += dw_mipi_dsi-imx6.o
> diff --git a/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c 
> b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> new file mode 100644
> index 0..492decc418bc3
> --- /dev/null
> +++ b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> @@ -0,0 +1,399 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * i.MX6 drm driver - MIPI DSI Host Controller
> + *
> + * Copyright (C) 2011-2015 Freescale Semiconductor, Inc.
> + * Copyright (C) 2019-2020 Collabora, Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "imx-drm.h"
> +
> +#define DSI_PWR_UP   0x04
> +#define RESET0
> +#define POWERUP  BIT(0)
> +
> +#define DSI_PHY_IF_CTRL  0x5c
> +#define PHY_IF_CTRL_RESET0x0
> +
> +#define DSI_PHY_TST_CTRL00x64
> +#define PHY_TESTCLK  BIT(1)
> +#define PHY_UNTESTCLK0
> +#define PHY_TESTCLR  BIT(0)
> +#define PHY_UNTESTCLR0
> +
> +#define DSI_PHY_TST_CTRL10x68
> +#define PHY_TESTEN   BIT(16)
> +#define PHY_UNTESTEN 0
> +#define PHY_TESTDOUT(n)  (((n) & 0xff) << 8)
> +#define PHY_TESTDIN(n)   (((n) & 0xff) << 0)
> +
> +struct imx_mipi_dsi {
> + struct drm_encoder encoder;
> + struct drm_bridge bridge;
> + struct device *dev;
> + struct regmap *mux_sel;
> + struct 

Re: [PATCH v3] dt-bindings: display: anx7814.txt: convert to yaml

2020-04-28 Thread Enric Balletbo i Serra
Hi Ricardo,

Thank you for your patch.

On 27/4/20 12:09, Ricardo Cañuelo wrote:
> This converts the Analogix ANX7814 bridge DT binding to yaml. Port
> definitions and descriptions were expanded, apart from that it's a
> direct translation from the original binding.
> 
> Signed-off-by: Ricardo Cañuelo 
> Acked-by: Sam Ravnborg 
> ---
> Changes in v3 (suggested by Sam Ravnborg):
>   - Rename example node i2c0 to i2c.
> 
> Changes in v2 (suggested by Enric Balletbo):
>   - File name change: use full compatible string.
>   - Binding description removed.
>   - #address-cells and #size-cells properties removed from ports node.
>   - Example node renamed: anx7814 -> bridge.
> 
> Tested with:
> make dt_binding_check ARCH=arm64 DT_SCHEMA_FILES=<.../analogix,anx7814.yaml>
> make dtbs_check ARCH=arm64 DT_SCHEMA_FILES=<.../analogix,anx7814.yaml>
> 
>  .../display/bridge/analogix,anx7814.yaml  | 124 ++
>  .../bindings/display/bridge/anx7814.txt   |  42 --
>  2 files changed, 124 insertions(+), 42 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/display/bridge/anx7814.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml 
> b/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
> new file mode 100644
> index ..13f0b52edefd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
> @@ -0,0 +1,124 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/analogix,anx7814.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analogix ANX7814 SlimPort (Full-HD Transmitter)
> +
> +maintainers:
> +  - Enric Balletbo i Serra 
> +
> +properties:
> +  compatible:
> +enum:
> +  - analogix,anx7808
> +  - analogix,anx7812
> +  - analogix,anx7814
> +  - analogix,anx7818
> +
> +  reg:
> +maxItems: 1
> +description: I2C address of the device.
> +
> +  interrupts:
> +maxItems: 1
> +description: Should contain the INTP interrupt.
> +
> +  hpd-gpios:
> +maxItems: 1
> +description: Which GPIO to use for hpd.
> +
> +  pd-gpios:
> +maxItems: 1
> +description: Which GPIO to use for power down.
> +
> +  reset-gpios:
> +maxItems: 1
> +description: Which GPIO to use for reset.
> +
> +  dvdd10-supply:
> +maxItems: 1
> +description: Regulator for 1.0V digital core power.
> +
> +  ports:
> +type: object
> +description:
> +  A node containing input and output port nodes with endpoint
> +  definitions as documented in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt
> +  Documentation/devicetree/bindings/graph.txt
> +
> +properties:
> +  port@0:
> +type: object
> +description: Video port for HDMI input.
> +
> +properties:
> +  reg:
> +const: 0
> +
> +  port@1:
> +type: object
> +description:
> +  Video port for SlimPort, DisplayPort, eDP or MyDP output.
> +
> +properties:
> +  reg:
> +const: 1
> +
> +required:
> +  - port@0
> +  - port@1
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts

See below ...

> +  - hpd-gpios
> +  - pd-gpios
> +  - reset-gpios

I know that these gpio attributes were required in the old binding and the
driver handles these gpios as required, but assuming that we should really
describe the hardware _not_ the driver, strictly talking, none of these gpios
are really required. The same happens with the interrupt, you can left the pin
floating and poll the registers.

So I am wondering if you should remove interrupts, *-gpios from required. Maybe
Rob Herring can give us more light on this?

Other than that:

Reviewed-by: Enric Balletbo i Serra 

Thanks,
 Enric

> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +#include 
> +
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +anx7814: bridge@38 {
> +compatible = "analogix,anx7814";
> +reg = <0x38>;
> +interrupt-parent = <>;
> +interrupts = <99 IRQ_TYPE_LEVEL_LOW>;   /* INTP */
> +hpd-gpios = < 36 GPIO_ACTIVE_HIGH>;
> +pd-gpios = < 33 GPIO_ACTIVE_HIGH>;
> + 

Re: [PATCH v8 01/10] drm: bridge: dw_mipi_dsi: add initial regmap infrastructure

2020-04-28 Thread Enric Balletbo i Serra
Hi Adrian,

Thank you for your patch and to apply the changes I requested

On 27/4/20 10:19, Adrian Ratiu wrote:
> In order to support multiple versions of the Synopsis MIPI DSI host
> controller, which have different register layouts but almost identical
> HW protocols, we add a regmap infrastructure which can abstract away
> register accesses for platform drivers using the bridge.
> 
> The controller HW revision is detected during bridge probe which will
> be used in future commits to load the relevant register layout which
> the bridge will use transparently to the platform drivers.
> 
> Cc: Enric Balletbo Serra 
> Suggested-by: Ezequiel Garcia 
> Tested-by: Adrian Pop 
> Tested-by: Arnaud Ferraris 
> Signed-off-by: Adrian Ratiu 

Reviewed-by: Enric Balletbo i Serra 

> ---
> Chnages since v7:
>   - Minor checkpatch line fix
> 
> Changes since v6:
>   - Select REGMAP_MMIO in Kconfig (Enric)
>   - Drop unnecessary stack variable inits (Enric)
>   - Make bridge error ASAP after a bad revision read (Enric)
>   - Drop redundant read of hw_version in dphy_timing_config (Enric)
> 
> New in v5.
> ---
>  drivers/gpu/drm/bridge/synopsys/Kconfig   |   1 +
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 210 ++
>  2 files changed, 121 insertions(+), 90 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig 
> b/drivers/gpu/drm/bridge/synopsys/Kconfig
> index 21a1be3ced0f3..080146093b68e 100644
> --- a/drivers/gpu/drm/bridge/synopsys/Kconfig
> +++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
> @@ -39,3 +39,4 @@ config DRM_DW_MIPI_DSI
>   select DRM_KMS_HELPER
>   select DRM_MIPI_DSI
>   select DRM_PANEL_BRIDGE
> + select REGMAP_MMIO
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 5ef0f154aa7bd..34b8668ae24ea 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -227,6 +228,7 @@ struct dw_mipi_dsi {
>   struct drm_bridge *panel_bridge;
>   struct device *dev;
>   void __iomem *base;
> + struct regmap *regs;
>  
>   struct clk *pclk;
>  
> @@ -235,6 +237,7 @@ struct dw_mipi_dsi {
>   u32 lanes;
>   u32 format;
>   unsigned long mode_flags;
> + u32 hw_version;
>  
>  #ifdef CONFIG_DEBUG_FS
>   struct dentry *debugfs;
> @@ -249,6 +252,13 @@ struct dw_mipi_dsi {
>   const struct dw_mipi_dsi_plat_data *plat_data;
>  };
>  
> +static const struct regmap_config dw_mipi_dsi_regmap_cfg = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .name = "dw-mipi-dsi",
> +};
> +
>  /*
>   * Check if either a link to a master or slave is present
>   */
> @@ -280,16 +290,6 @@ static inline struct dw_mipi_dsi *bridge_to_dsi(struct 
> drm_bridge *bridge)
>   return container_of(bridge, struct dw_mipi_dsi, bridge);
>  }
>  
> -static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg, u32 val)
> -{
> - writel(val, dsi->base + reg);
> -}
> -
> -static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg)
> -{
> - return readl(dsi->base + reg);
> -}
> -
>  static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
>  struct mipi_dsi_device *device)
>  {
> @@ -366,8 +366,8 @@ static void dw_mipi_message_config(struct dw_mipi_dsi 
> *dsi,
>   if (lpm)
>   val |= CMD_MODE_ALL_LP;
>  
> - dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
> - dsi_write(dsi, DSI_CMD_MODE_CFG, val);
> + regmap_write(dsi->regs, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
> + regmap_write(dsi->regs, DSI_CMD_MODE_CFG, val);
>  }
>  
>  static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 
> hdr_val)
> @@ -375,20 +375,20 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct 
> dw_mipi_dsi *dsi, u32 hdr_val)
>   int ret;
>   u32 val, mask;
>  
> - ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
> -  val, !(val & GEN_CMD_FULL), 1000,
> -  CMD_PKT_STATUS_TIMEOUT_US);
> + ret = regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS,
> +val, !(val & GEN_CMD_FULL), 1000,
> +CMD_PKT_STATUS_TIMEOUT_US);
>   if (ret) {
>   dev_err(dsi->dev, "failed to get available command FIFO\n");
>   return

[PATCH] drm/rockchip: cdn-dp-core: Make cdn_dp_core_suspend/resume static

2020-04-27 Thread Enric Balletbo i Serra
This fixes the following warning detected when running make with W=1

drivers/gpu/drm/rockchip//cdn-dp-core.c:1112:5: warning: no previous
prototype for ‘cdn_dp_suspend’ [-Wmissing-prototypes]

drivers/gpu/drm/rockchip//cdn-dp-core.c:1126:5: warning: no previous
prototype for ‘cdn_dp_resume’ [-Wmissing-prototypes]

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/rockchip/cdn-dp-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index eed594bd38d3..4fa00af89cca 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1109,7 +1109,7 @@ static const struct component_ops cdn_dp_component_ops = {
.unbind = cdn_dp_unbind,
 };
 
-int cdn_dp_suspend(struct device *dev)
+static int cdn_dp_suspend(struct device *dev)
 {
struct cdn_dp_device *dp = dev_get_drvdata(dev);
int ret = 0;
@@ -1123,7 +1123,7 @@ int cdn_dp_suspend(struct device *dev)
return ret;
 }
 
-int cdn_dp_resume(struct device *dev)
+static int cdn_dp_resume(struct device *dev)
 {
struct cdn_dp_device *dp = dev_get_drvdata(dev);
 
-- 
2.26.2

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


Re: [PATCH] dt-bindings: display: anx7814.txt: convert to yaml

2020-04-24 Thread Enric Balletbo i Serra
Hi Ricardo,

Thank you for your patch.

On 24/4/20 8:53, Ricardo Cañuelo wrote:
> This converts the Analogix ANX7814 bridge DT binding to yaml. Port
> definitions and descriptions were expanded, apart from that it's a
> direct translation from the original binding.
> 
> Signed-off-by: Ricardo Cañuelo 
> ---
> Tested with:
> make dt_binding_check ARCH=arm64 DT_SCHEMA_FILES=<.../anx7814.yaml>
> make dtbs_check ARCH=arm64 DT_SCHEMA_FILES=<.../anx7814.yaml>
> 
>  .../bindings/display/bridge/anx7814.txt   |  42 --
>  .../bindings/display/bridge/anx7814.yaml  | 133 ++
>  2 files changed, 133 insertions(+), 42 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/bridge/anx7814.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/anx7814.yaml

Use the full compatible string: analogix,anx7814.yaml

> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/anx7814.txt 
> b/Documentation/devicetree/bindings/display/bridge/anx7814.txt
> deleted file mode 100644
> index 17258747fff6..
> --- a/Documentation/devicetree/bindings/display/bridge/anx7814.txt
> +++ /dev/null
> @@ -1,42 +0,0 @@
> -Analogix ANX7814 SlimPort (Full-HD Transmitter)
> 
> -
> -The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> -designed for portable devices.
> -
> -Required properties:
> -
> - - compatible: Must be one of:
> -   "analogix,anx7808"
> -   "analogix,anx7812"
> -   "analogix,anx7814"
> -   "analogix,anx7818"
> - - reg   : I2C address of the device
> - - interrupts: Should contain the INTP interrupt
> - - hpd-gpios : Which GPIO to use for hpd
> - - pd-gpios  : Which GPIO to use for power down
> - - reset-gpios   : Which GPIO to use for reset
> -
> -Optional properties:
> -
> - - dvdd10-supply : Regulator for 1.0V digital core power.
> - - Video port for HDMI input, using the DT bindings defined in [1].
> -
> -[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> -
> -Example:
> -
> - anx7814: anx7814@38 {
> - compatible = "analogix,anx7814";
> - reg = <0x38>;
> - interrupt-parent = <>;
> - interrupts = <99 IRQ_TYPE_LEVEL_LOW>;   /* INTP */
> - hpd-gpios = < 36 GPIO_ACTIVE_HIGH>;
> - pd-gpios = < 33 GPIO_ACTIVE_HIGH>;
> - reset-gpios = < 98 GPIO_ACTIVE_HIGH>;
> - port {
> - anx7814_in: endpoint {
> - remote-endpoint = <_out>;
> - };
> - };
> - };
> diff --git a/Documentation/devicetree/bindings/display/bridge/anx7814.yaml 
> b/Documentation/devicetree/bindings/display/bridge/anx7814.yaml
> new file mode 100644
> index ..53d3c778c893
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/anx7814.yaml
> @@ -0,0 +1,133 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/anx7814.yaml#

Don't forget to update this too.


> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analogix ANX7814 SlimPort (Full-HD Transmitter)
> +
> +maintainers:
> +  - Enric Balletbo i Serra 
> +
> +description: |
> +  The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> +  designed for portable devices.
> +
> +properties:
> +  compatible:
> +enum:
> +  - analogix,anx7808
> +  - analogix,anx7812
> +  - analogix,anx7814
> +  - analogix,anx7818
> +
> +  reg:
> +maxItems: 1
> +description: I2C address of the device.
> +

Can drop the description as there's nothing specific to this device.

> +  interrupts:
> +maxItems: 1
> +description: Should contain the INTP interrupt.
> +
> +  hpd-gpios:
> +maxItems: 1
> +description: Which GPIO to use for hpd.
> +
> +  pd-gpios:
> +maxItems: 1
> +description: Which GPIO to use for power down.
> +
> +  reset-gpios:
> +maxItems: 1
> +description: Which GPIO to use for reset.
> +
> +  dvdd10-supply:
> +maxItems: 1
> +description: Regulator for 1.0V digital core power.
> +
> +  ports:
> +type: object
> +description:
> +  A node containing input and output port nodes with endpoint
> +  def

  1   2   3   4   5   >