Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 03 Aug 2020 20:02:38 +0200
User-Agent: K-9 Mail for Android
In-Reply-To: <CAAOTY_-H3L=uJNJRF1VedbwXNwY2N-q4F6A-NsdNwbQswG0D-Q@mail.gmail.com>
References: <20200728111800.77641-1-frank-w@public-files.de> <20200728111800.77641-2-frank-w@public-files.de> <CAAOTY_8nm0KDHFzOX9+qTTHOUd0Vik063J+rScu_y-hTBTkrCQ@mail.gmail.com> <trinity-2bdb3521-256a-4d4d-928a-be9b8c179d4c-1596355539029@3c-app-gmx-bs58> <CAAOTY__TsqrfRX-z+DE0+X_UzxBqChJ+VdyQG6z9N6Qr4bn2Kg@mail.gmail.com> <trinity-b0ca2ee2-259a-4a1e-86ee-63b093202060-1596451368067@3c-app-gmx-bap36> <CAAOTY_-H3L=uJNJRF1VedbwXNwY2N-q4F6A-NsdNwbQswG0D-Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: Re: Re: [PATCH v2 1/5] drm/mediatek: config component output by device node port
Reply-to: frank-w@public-files.de
To:     linux-mediatek@lists.infradead.org,
        Chun-Kuang Hu <chunkuang.hu@kernel.org>, ryder.lee@mediatek.com
CC:     Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        DRI Development <dri-devel@lists.freedesktop.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@lists.infradead.org>,
        Philipp Zabel <p.zabel@pengutronix.de>,
        Matthias Brugger <matthias.bgg@gmail.com>,
        Bibby Hsieh <bibby.hsieh@mediatek.com>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>
From:   Frank Wunderlich <frank-w@public-files.de>
Message-ID: <D0A969BC-1BB3-4EBB-8D03-DAA610E62EBE@public-files.de>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


Am 3=2E August 2020 18:27:02 MESZ schrieb Chun-Kuang Hu <chunkuang=2Ehu@ke=
rnel=2Eorg>:

>But now I have a solution that you need not to modify binding document=2E
>Because now mt7623 has a different routing than mt2701, and this
>patch's approach is to use different port setting in each device tree=2E
>My solution is that these two SoC has different compatible string:
>"mediatek,mt7623-mmsys" and "mediatek,mt2701-mmsys"=2E For now,
>"mediatek,mt2701-mmsys" has its data as
>
>static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data =3D {
>=2Emain_path =3D mt2701_mtk_ddp_main,
>=2Emain_len =3D ARRAY_SIZE(mt2701_mtk_ddp_main),
>=2Eext_path =3D mt2701_mtk_ddp_ext,
>=2Eext_len =3D ARRAY_SIZE(mt2701_mtk_ddp_ext),
>=2Eshadow_register =3D true,
>};
>
>I think you could create a data for "mediatek,mt7623-mmsys" which has
>a different routing=2E

The paths are defined as this:

static enum mtk_ddp_comp_id mt2701_mtk_ddp_main[] =3D {	DDP_COMPONENT_OVL0=
,	DDP_COMPONENT_RDMA0,	DDP_COMPONENT_COLOR0,	DDP_COMPONENT_BLS,	DDP_COMPONE=
NT_DSI0,};

static enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] =3D {	DDP_COMPONENT_RDMA1=
,	DDP_COMPONENT_DPI0,};

First thing i notice is that main=3Ddsi and ext=3Ddpi (hdmi)=2E I guess dp=
i should be main,right? And bls is actually routed to dpi=2E=2E=2Ehow about=
 the other components?

The 2 loops are not really clear to me (except 1st overwrites mt2701 main-=
path and second ext_path based on ports/endpoints) but this only applies fr=
om bls-dpi-hdmi-connector,not xdma/color or similar=2E
Or should be main-path (or external) only bls and dpi? It looks like it on=
ly swappes dpi and dsi in my case=2E

@Ryder Lee can you explain it?
regards Frank