mbox series

[v8,0/3] drm/mediatek: Add support for OF graphs

Message ID 20240618101726.110416-1-angelogioacchino.delregno@collabora.com (mailing list archive)
Headers show
Series drm/mediatek: Add support for OF graphs | expand

Message

AngeloGioacchino Del Regno June 18, 2024, 10:17 a.m. UTC
Changes in v8:
 - Rebased on next-20240617
 - Changed to allow probing a VDO with no available display outputs

Changes in v7:
 - Fix typo in patch 3/3

Changes in v6:
 - Added EPROBE_DEFER check to fix dsi/dpi false positive DT fallback case
 - Dropped refcount of ep_out in mtk_drm_of_get_ddp_ep_cid()
 - Fixed double refcount drop during path building
 - Removed failure upon finding a DT-disabled path as requested
 - Tested again on MT8195, MT8395 boards

Changes in v5:
 - Fixed commit [2/3], changed allOf -> anyOf to get the
   intended allowance in the binding

Changes in v4:
 - Fixed a typo that caused pure OF graphs pipelines multiple
   concurrent outputs to not get correctly parsed (port->id); 
 - Added OVL_ADAPTOR support for OF graph specified pipelines;
 - Now tested with fully OF Graph specified pipelines on MT8195
   Chromebooks and MT8395 boards;
 - Rebased on next-20240516

Changes in v3:
 - Rebased on next-20240502 because of renames in mediatek-drm

Changes in v2:
 - Fixed wrong `required` block indentation in commit [2/3]


The display IPs in MediaTek SoCs are *VERY* flexible and those support
being interconnected with different instances of DDP IPs (for example,
merge0 or merge1) and/or with different DDP IPs (for example, rdma can
be connected with either color, dpi, dsi, merge, etc), forming a full
Display Data Path that ends with an actual display.

This series was born because of an issue that I've found while enabling
support for MT8195/MT8395 boards with DSI output as main display: the
current mtk_drm_route variations would not work as currently, the driver
hardcodes a display path for Chromebooks, which have a DisplayPort panel
with DSC support, instead of a DSI panel without DSC support.

There are other reasons for which I wrote this series, and I find that
hardcoding those paths - when a HW path is clearly board-specific - is
highly suboptimal. Also, let's not forget about keeping this driver from
becoming a huge list of paths for each combination of SoC->board->disp
and... this and that.

For more information, please look at the commit description for each of
the commits included in this series.

This series is essential to enable support for the MT8195/MT8395 EVK,
Kontron i1200, Radxa NIO-12L and, mainly, for non-Chromebook boards
and Chromebooks to co-exist without conflicts.

Besides, this is also a valid option for MT8188 Chromebooks which might
have different DSI-or-eDP displays depending on the model (as far as I
can see from the mtk_drm_route attempt for this SoC that is already
present in this driver).

This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
NIO-12L with both hardcoded paths, OF graph support and partially
hardcoded paths, and pure OF graph support including pipelines that
require OVL_ADAPTOR support.

AngeloGioacchino Del Regno (3):
  dt-bindings: display: mediatek: Add OF graph support for board path
  dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
  drm/mediatek: Implement OF graphs support for display paths

 .../bindings/arm/mediatek/mediatek,mmsys.yaml |  28 ++
 .../display/mediatek/mediatek,aal.yaml        |  40 +++
 .../display/mediatek/mediatek,ccorr.yaml      |  21 ++
 .../display/mediatek/mediatek,color.yaml      |  22 ++
 .../display/mediatek/mediatek,dither.yaml     |  22 ++
 .../display/mediatek/mediatek,dpi.yaml        |  25 +-
 .../display/mediatek/mediatek,dsc.yaml        |  24 ++
 .../display/mediatek/mediatek,dsi.yaml        |  27 +-
 .../display/mediatek/mediatek,ethdr.yaml      |  22 ++
 .../display/mediatek/mediatek,gamma.yaml      |  19 ++
 .../display/mediatek/mediatek,merge.yaml      |  23 ++
 .../display/mediatek/mediatek,od.yaml         |  22 ++
 .../display/mediatek/mediatek,ovl-2l.yaml     |  22 ++
 .../display/mediatek/mediatek,ovl.yaml        |  22 ++
 .../display/mediatek/mediatek,postmask.yaml   |  21 ++
 .../display/mediatek/mediatek,rdma.yaml       |  22 ++
 .../display/mediatek/mediatek,ufoe.yaml       |  21 ++
 drivers/gpu/drm/mediatek/mtk_disp_drv.h       |   1 +
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   |  40 ++-
 drivers/gpu/drm/mediatek/mtk_dpi.c            |  21 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c        | 291 ++++++++++++++++--
 drivers/gpu/drm/mediatek/mtk_drm_drv.h        |   2 +-
 drivers/gpu/drm/mediatek/mtk_dsi.c            |  14 +-
 23 files changed, 731 insertions(+), 41 deletions(-)

Comments

Michael Walle June 18, 2024, 11:05 a.m. UTC | #1
On Tue Jun 18, 2024 at 12:17 PM CEST, AngeloGioacchino Del Regno wrote:
> The display IPs in MediaTek SoCs are *VERY* flexible and those support
> being interconnected with different instances of DDP IPs (for example,
> merge0 or merge1) and/or with different DDP IPs (for example, rdma can
> be connected with either color, dpi, dsi, merge, etc), forming a full
> Display Data Path that ends with an actual display.
>
> This series was born because of an issue that I've found while enabling
> support for MT8195/MT8395 boards with DSI output as main display: the
> current mtk_drm_route variations would not work as currently, the driver
> hardcodes a display path for Chromebooks, which have a DisplayPort panel
> with DSC support, instead of a DSI panel without DSC support.
>
> There are other reasons for which I wrote this series, and I find that
> hardcoding those paths - when a HW path is clearly board-specific - is
> highly suboptimal. Also, let's not forget about keeping this driver from
> becoming a huge list of paths for each combination of SoC->board->disp
> and... this and that.
>
> For more information, please look at the commit description for each of
> the commits included in this series.
>
> This series is essential to enable support for the MT8195/MT8395 EVK,
> Kontron i1200, Radxa NIO-12L and, mainly, for non-Chromebook boards
> and Chromebooks to co-exist without conflicts.
>
> Besides, this is also a valid option for MT8188 Chromebooks which might
> have different DSI-or-eDP displays depending on the model (as far as I
> can see from the mtk_drm_route attempt for this SoC that is already
> present in this driver).
>
> This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
> NIO-12L with both hardcoded paths, OF graph support and partially
> hardcoded paths, and pure OF graph support including pipelines that
> require OVL_ADAPTOR support.
>
> AngeloGioacchino Del Regno (3):
>   dt-bindings: display: mediatek: Add OF graph support for board path
>   dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
>   drm/mediatek: Implement OF graphs support for display paths

Thanks!

Tested-by: Michael Walle <mwalle@kernel.org> # on kontron-sbc-i1200

-michael
AngeloGioacchino Del Regno June 19, 2024, 10:56 a.m. UTC | #2
Il 18/06/24 12:17, AngeloGioacchino Del Regno ha scritto:
> Changes in v8:
>   - Rebased on next-20240617
>   - Changed to allow probing a VDO with no available display outputs
> 

Hello CK,

At the time of writing, this series was well reviewed and tested by multiple people
on multiple SoCs and boards.

We've got a bunch of series that are waiting for this to get upstreamed, including
the addition of support for MT8365-EVK (already on mailing lists), MT8395 Radxa
NIO 12L, MT8395 Kontron SBC i1200 (not on mailing lists yet, waiting for this to
get merged), other than some other conversion commits for other MediaTek DTs from
myself.

As for the MT8195/NIO12L commits, I'm planning to send them on the lists tomorrow,
along with some code to properly support devicetree overlays (DTBO) generation for
MediaTek boards.

Alexandre tested it on MT8365-EVK;
Michael tested on Kontron SBC-i1200;
I tested on Radxa NIO-12L, Cherry Tomato Chromebook, MT6795 Sony Xperia
M5 (dsi video panel) smartphone and MT8192 Asurada Chromebook.

So, is there anything else to address on this, or can we proceed?

Many thanks,
Angelo

> Changes in v7:
>   - Fix typo in patch 3/3
> 
> Changes in v6:
>   - Added EPROBE_DEFER check to fix dsi/dpi false positive DT fallback case
>   - Dropped refcount of ep_out in mtk_drm_of_get_ddp_ep_cid()
>   - Fixed double refcount drop during path building
>   - Removed failure upon finding a DT-disabled path as requested
>   - Tested again on MT8195, MT8395 boards
> 
> Changes in v5:
>   - Fixed commit [2/3], changed allOf -> anyOf to get the
>     intended allowance in the binding
> 
> Changes in v4:
>   - Fixed a typo that caused pure OF graphs pipelines multiple
>     concurrent outputs to not get correctly parsed (port->id);
>   - Added OVL_ADAPTOR support for OF graph specified pipelines;
>   - Now tested with fully OF Graph specified pipelines on MT8195
>     Chromebooks and MT8395 boards;
>   - Rebased on next-20240516
> 
> Changes in v3:
>   - Rebased on next-20240502 because of renames in mediatek-drm
> 
> Changes in v2:
>   - Fixed wrong `required` block indentation in commit [2/3]
> 
> 
> The display IPs in MediaTek SoCs are *VERY* flexible and those support
> being interconnected with different instances of DDP IPs (for example,
> merge0 or merge1) and/or with different DDP IPs (for example, rdma can
> be connected with either color, dpi, dsi, merge, etc), forming a full
> Display Data Path that ends with an actual display.
> 
> This series was born because of an issue that I've found while enabling
> support for MT8195/MT8395 boards with DSI output as main display: the
> current mtk_drm_route variations would not work as currently, the driver
> hardcodes a display path for Chromebooks, which have a DisplayPort panel
> with DSC support, instead of a DSI panel without DSC support.
> 
> There are other reasons for which I wrote this series, and I find that
> hardcoding those paths - when a HW path is clearly board-specific - is
> highly suboptimal. Also, let's not forget about keeping this driver from
> becoming a huge list of paths for each combination of SoC->board->disp
> and... this and that.
> 
> For more information, please look at the commit description for each of
> the commits included in this series.
> 
> This series is essential to enable support for the MT8195/MT8395 EVK,
> Kontron i1200, Radxa NIO-12L and, mainly, for non-Chromebook boards
> and Chromebooks to co-exist without conflicts.
> 
> Besides, this is also a valid option for MT8188 Chromebooks which might
> have different DSI-or-eDP displays depending on the model (as far as I
> can see from the mtk_drm_route attempt for this SoC that is already
> present in this driver).
> 
> This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
> NIO-12L with both hardcoded paths, OF graph support and partially
> hardcoded paths, and pure OF graph support including pipelines that
> require OVL_ADAPTOR support.
> 
> AngeloGioacchino Del Regno (3):
>    dt-bindings: display: mediatek: Add OF graph support for board path
>    dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
>    drm/mediatek: Implement OF graphs support for display paths
> 
>   .../bindings/arm/mediatek/mediatek,mmsys.yaml |  28 ++
>   .../display/mediatek/mediatek,aal.yaml        |  40 +++
>   .../display/mediatek/mediatek,ccorr.yaml      |  21 ++
>   .../display/mediatek/mediatek,color.yaml      |  22 ++
>   .../display/mediatek/mediatek,dither.yaml     |  22 ++
>   .../display/mediatek/mediatek,dpi.yaml        |  25 +-
>   .../display/mediatek/mediatek,dsc.yaml        |  24 ++
>   .../display/mediatek/mediatek,dsi.yaml        |  27 +-
>   .../display/mediatek/mediatek,ethdr.yaml      |  22 ++
>   .../display/mediatek/mediatek,gamma.yaml      |  19 ++
>   .../display/mediatek/mediatek,merge.yaml      |  23 ++
>   .../display/mediatek/mediatek,od.yaml         |  22 ++
>   .../display/mediatek/mediatek,ovl-2l.yaml     |  22 ++
>   .../display/mediatek/mediatek,ovl.yaml        |  22 ++
>   .../display/mediatek/mediatek,postmask.yaml   |  21 ++
>   .../display/mediatek/mediatek,rdma.yaml       |  22 ++
>   .../display/mediatek/mediatek,ufoe.yaml       |  21 ++
>   drivers/gpu/drm/mediatek/mtk_disp_drv.h       |   1 +
>   .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   |  40 ++-
>   drivers/gpu/drm/mediatek/mtk_dpi.c            |  21 +-
>   drivers/gpu/drm/mediatek/mtk_drm_drv.c        | 291 ++++++++++++++++--
>   drivers/gpu/drm/mediatek/mtk_drm_drv.h        |   2 +-
>   drivers/gpu/drm/mediatek/mtk_dsi.c            |  14 +-
>   23 files changed, 731 insertions(+), 41 deletions(-)
>
AngeloGioacchino Del Regno July 4, 2024, 8:29 a.m. UTC | #3
Il 19/06/24 12:56, AngeloGioacchino Del Regno ha scritto:
> Il 18/06/24 12:17, AngeloGioacchino Del Regno ha scritto:
>> Changes in v8:
>>   - Rebased on next-20240617
>>   - Changed to allow probing a VDO with no available display outputs
>>
> 
> Hello CK,
> 
> At the time of writing, this series was well reviewed and tested by multiple people
> on multiple SoCs and boards.
> 
> We've got a bunch of series that are waiting for this to get upstreamed, including
> the addition of support for MT8365-EVK (already on mailing lists), MT8395 Radxa
> NIO 12L, MT8395 Kontron SBC i1200 (not on mailing lists yet, waiting for this to
> get merged), other than some other conversion commits for other MediaTek DTs from
> myself.
> 
> As for the MT8195/NIO12L commits, I'm planning to send them on the lists tomorrow,
> along with some code to properly support devicetree overlays (DTBO) generation for
> MediaTek boards.
> 
> Alexandre tested it on MT8365-EVK;
> Michael tested on Kontron SBC-i1200;
> I tested on Radxa NIO-12L, Cherry Tomato Chromebook, MT6795 Sony Xperia
> M5 (dsi video panel) smartphone and MT8192 Asurada Chromebook.
> 
> So, is there anything else to address on this, or can we proceed?
> 

Gentle ping

Regards,
Angelo

> Many thanks,
> Angelo
> 
>> Changes in v7:
>>   - Fix typo in patch 3/3
>>
>> Changes in v6:
>>   - Added EPROBE_DEFER check to fix dsi/dpi false positive DT fallback case
>>   - Dropped refcount of ep_out in mtk_drm_of_get_ddp_ep_cid()
>>   - Fixed double refcount drop during path building
>>   - Removed failure upon finding a DT-disabled path as requested
>>   - Tested again on MT8195, MT8395 boards
>>
>> Changes in v5:
>>   - Fixed commit [2/3], changed allOf -> anyOf to get the
>>     intended allowance in the binding
>>
>> Changes in v4:
>>   - Fixed a typo that caused pure OF graphs pipelines multiple
>>     concurrent outputs to not get correctly parsed (port->id);
>>   - Added OVL_ADAPTOR support for OF graph specified pipelines;
>>   - Now tested with fully OF Graph specified pipelines on MT8195
>>     Chromebooks and MT8395 boards;
>>   - Rebased on next-20240516
>>
>> Changes in v3:
>>   - Rebased on next-20240502 because of renames in mediatek-drm
>>
>> Changes in v2:
>>   - Fixed wrong `required` block indentation in commit [2/3]
>>
>>
>> The display IPs in MediaTek SoCs are *VERY* flexible and those support
>> being interconnected with different instances of DDP IPs (for example,
>> merge0 or merge1) and/or with different DDP IPs (for example, rdma can
>> be connected with either color, dpi, dsi, merge, etc), forming a full
>> Display Data Path that ends with an actual display.
>>
>> This series was born because of an issue that I've found while enabling
>> support for MT8195/MT8395 boards with DSI output as main display: the
>> current mtk_drm_route variations would not work as currently, the driver
>> hardcodes a display path for Chromebooks, which have a DisplayPort panel
>> with DSC support, instead of a DSI panel without DSC support.
>>
>> There are other reasons for which I wrote this series, and I find that
>> hardcoding those paths - when a HW path is clearly board-specific - is
>> highly suboptimal. Also, let's not forget about keeping this driver from
>> becoming a huge list of paths for each combination of SoC->board->disp
>> and... this and that.
>>
>> For more information, please look at the commit description for each of
>> the commits included in this series.
>>
>> This series is essential to enable support for the MT8195/MT8395 EVK,
>> Kontron i1200, Radxa NIO-12L and, mainly, for non-Chromebook boards
>> and Chromebooks to co-exist without conflicts.
>>
>> Besides, this is also a valid option for MT8188 Chromebooks which might
>> have different DSI-or-eDP displays depending on the model (as far as I
>> can see from the mtk_drm_route attempt for this SoC that is already
>> present in this driver).
>>
>> This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
>> NIO-12L with both hardcoded paths, OF graph support and partially
>> hardcoded paths, and pure OF graph support including pipelines that
>> require OVL_ADAPTOR support.
>>
>> AngeloGioacchino Del Regno (3):
>>    dt-bindings: display: mediatek: Add OF graph support for board path
>>    dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
>>    drm/mediatek: Implement OF graphs support for display paths
>>
>>   .../bindings/arm/mediatek/mediatek,mmsys.yaml |  28 ++
>>   .../display/mediatek/mediatek,aal.yaml        |  40 +++
>>   .../display/mediatek/mediatek,ccorr.yaml      |  21 ++
>>   .../display/mediatek/mediatek,color.yaml      |  22 ++
>>   .../display/mediatek/mediatek,dither.yaml     |  22 ++
>>   .../display/mediatek/mediatek,dpi.yaml        |  25 +-
>>   .../display/mediatek/mediatek,dsc.yaml        |  24 ++
>>   .../display/mediatek/mediatek,dsi.yaml        |  27 +-
>>   .../display/mediatek/mediatek,ethdr.yaml      |  22 ++
>>   .../display/mediatek/mediatek,gamma.yaml      |  19 ++
>>   .../display/mediatek/mediatek,merge.yaml      |  23 ++
>>   .../display/mediatek/mediatek,od.yaml         |  22 ++
>>   .../display/mediatek/mediatek,ovl-2l.yaml     |  22 ++
>>   .../display/mediatek/mediatek,ovl.yaml        |  22 ++
>>   .../display/mediatek/mediatek,postmask.yaml   |  21 ++
>>   .../display/mediatek/mediatek,rdma.yaml       |  22 ++
>>   .../display/mediatek/mediatek,ufoe.yaml       |  21 ++
>>   drivers/gpu/drm/mediatek/mtk_disp_drv.h       |   1 +
>>   .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   |  40 ++-
>>   drivers/gpu/drm/mediatek/mtk_dpi.c            |  21 +-
>>   drivers/gpu/drm/mediatek/mtk_drm_drv.c        | 291 ++++++++++++++++--
>>   drivers/gpu/drm/mediatek/mtk_drm_drv.h        |   2 +-
>>   drivers/gpu/drm/mediatek/mtk_dsi.c            |  14 +-
>>   23 files changed, 731 insertions(+), 41 deletions(-)
>>
> 
>
Michael Walle July 11, 2024, 9:24 a.m. UTC | #4
Hi,

> > We've got a bunch of series that are waiting for this to get upstreamed, including
> > the addition of support for MT8365-EVK (already on mailing lists), MT8395 Radxa
> > NIO 12L, MT8395 Kontron SBC i1200 (not on mailing lists yet, waiting for this to
> > get merged), other than some other conversion commits for other MediaTek DTs from
> > myself.

Yes this is the missing piece to finally get DisplayPort output
working on our board.

-michael
Michael Walle Aug. 19, 2024, 7:43 a.m. UTC | #5
Hi,

On Thu Jul 4, 2024 at 10:29 AM CEST, AngeloGioacchino Del Regno wrote:
> Il 19/06/24 12:56, AngeloGioacchino Del Regno ha scritto:
> > Il 18/06/24 12:17, AngeloGioacchino Del Regno ha scritto:
> >> Changes in v8:
> >>   - Rebased on next-20240617
> >>   - Changed to allow probing a VDO with no available display outputs
> >>
> > 
> > Hello CK,
> > 
> > At the time of writing, this series was well reviewed and tested by multiple people
> > on multiple SoCs and boards.
> > 
> > We've got a bunch of series that are waiting for this to get upstreamed, including
> > the addition of support for MT8365-EVK (already on mailing lists), MT8395 Radxa
> > NIO 12L, MT8395 Kontron SBC i1200 (not on mailing lists yet, waiting for this to
> > get merged), other than some other conversion commits for other MediaTek DTs from
> > myself.
> > 
> > As for the MT8195/NIO12L commits, I'm planning to send them on the lists tomorrow,
> > along with some code to properly support devicetree overlays (DTBO) generation for
> > MediaTek boards.
> > 
> > Alexandre tested it on MT8365-EVK;
> > Michael tested on Kontron SBC-i1200;
> > I tested on Radxa NIO-12L, Cherry Tomato Chromebook, MT6795 Sony Xperia
> > M5 (dsi video panel) smartphone and MT8192 Asurada Chromebook.
> > 
> > So, is there anything else to address on this, or can we proceed?
> > 
>
> Gentle ping

Any news here? Angelo, maybe you can just resend the patches?
Because there is already a new kernel release, I'm not sure how this
is handled.

-michael