lkml.org 
[lkml]   [2022]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v10 01/21] dt-bindings: mediatek,dpi: Add DPINTF compatible
From
Date
On Wed, 2022-05-25 at 13:55 +0200, AngeloGioacchino Del Regno wrote:
> Il 23/05/22 12:47, Guillaume Ranquet ha scritto:
> > From: Markus Schneider-Pargmann <msp@baylibre.com>
> >
> > DPINTF is similar to DPI but does not have the exact same feature
> > set
> > or register layouts.
> >
> > DPINTF is the sink of the display pipeline that is connected to the
> > DisplayPort controller and encoder unit. It takes the same clocks
> > as
> > DPI.
> >
> > Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> > Signed-off-by: Guillaume Ranquet <granquet@baylibre.com>
> > ---
> > .../bindings/display/mediatek/mediatek,dpi.yaml | 13
> > ++++++++-----
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.y
> > aml
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.y
> > aml
> > index dd2896a40ff0..6d9f6c11806e 100644
> > ---
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.y
> > aml
> > +++
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.y
> > aml
> > @@ -4,16 +4,16 @@
> > $id:
> > http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
> > $schema: http://devicetree.org/meta-schemas/core.yaml#
> >
> > -title: mediatek DPI Controller Device Tree Bindings
> > +title: mediatek DPI/DPINTF Controller
> >
> > maintainers:
> > - CK Hu <ck.hu@mediatek.com>
> > - Jitao shi <jitao.shi@mediatek.com>
> >
> > description: |
> > - The Mediatek DPI function block is a sink of the display
> > subsystem and
> > - provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a
> > parallel
> > - output bus.
> > + The Mediatek DPI and DPINTF function blocks are a sink of the
> > display
> > + subsystem and provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422
> > pixel data on a
> > + parallel output bus.
> >
> > properties:
> > compatible:
> > @@ -23,6 +23,7 @@ properties:
> > - mediatek,mt8173-dpi
> > - mediatek,mt8183-dpi
> > - mediatek,mt8192-dpi
> > + - mediatek,mt8195-dpintf
> >
> > reg:
> > maxItems: 1
> > @@ -35,12 +36,14 @@ properties:
> > - description: Pixel Clock
> > - description: Engine Clock
> > - description: DPI PLL
> > + - description: Optional CK CG Clock
> >
> > clock-names:
> > items:
> > - const: pixel
> > - const: engine
> > - const: pll
> > + - const: ck_cg
>
> This is my understanding on how the DisplayPort Interface clocks work
> on 8195:
>
> The "engine" clock is for the *VPP Engine's DisplayPort ip/block*,
> "pll" is for TVD PLL divider selection
> "pixel" is the gate for the pixel clock to the connected display.
>
> "ck_cg" is useless, as that's the parent of "pixel" (and will always
> be)... for
> example, on mt8195... check clk/mediatek/clk-mt8195-vdo0.c - the
> CLK_VDO0_DP_INTF0_DP_INTF clock already has CLK_TOP_EDP as its
> parent, hence
> enabling the first will enable the latter.
>
> That said... you can most probably avoid adding the ck_cg clock, as
> if you try
> to turn that off while it's in use by its children, you'll be only
> decrementing
> a refcount, but no "real action" will ever take place.
>
>
> Regards,
> Angelo

Hello Chunfeng and Angelo,

ck_cg is a clock gate, and I try to remove it from drivers but it's
failed to enable dp_intf.

the block diagram is:
1. 26M->CLK_APMIXED_TVDPLL1(pll)->CLK_TOP_EDP(pixel)-
>CLK_VDO0_DP_INTF0_DP_INTF(ck_cg)->dp_intf

2. VDOSYS clock->CLK_VDO0_DP_INTF0(engine)->dp_intf

"engine" and "ck_cg" are all clock gates which control the clock source
input to dp_intf.

Maybe we just need to rename it?
If so, what name do you think we should modify?

BRs,
Bo-Chen

>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

\
 
 \ /
  Last update: 2022-06-07 04:31    [W:0.102 / U:0.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site