[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d7e5e360-0a0e-344e-0c96-8209403aad88@collabora.com>
Date: Fri, 26 Nov 2021 11:23:00 +0100
From: AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>
To: Guillaume Ranquet <granquet@...libre.com>,
Chun-Kuang Hu <chunkuang.hu@...nel.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
Matthias Brugger <matthias.bgg@...il.com>
Cc: Markus Schneider-Pargmann <msp@...libre.com>,
dri-devel@...ts.freedesktop.org,
linux-mediatek@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 5/7] drm/mediatek: dpi: Add dpintf support
Il 10/11/21 14:06, Guillaume Ranquet ha scritto:
> From: Markus Schneider-Pargmann <msp@...libre.com>
>
> dpintf is the displayport interface hardware unit. This unit is similar
> to dpi and can reuse most of the code.
>
> This patch adds support for mt8195-dpintf to this dpi driver. Main
> differences are:
> - Some features/functional components are not available for dpintf
> which are now excluded from code execution once is_dpintf is set
> - dpintf can and needs to choose between different clockdividers based
> on the clockspeed. This is done by choosing a different clock parent.
> - There are two additional clocks that need to be managed. These are
> only set for dpintf and will be set to NULL if not supplied. The
> clk_* calls handle these as normal clocks then.
> - Some register contents differ slightly between the two components. To
> work around this I added register bits/masks with a DPINTF_ prefix
> and use them where different.
>
> Based on a separate driver for dpintf created by
> Jason-JH.Lin <jason-jh.lin@...iatek.com>.
>
> Signed-off-by: Markus Schneider-Pargmann <msp@...libre.com>
> Signed-off-by: Guillaume Ranquet <granquet@...libre.com>
Hello Guillaume, Markus
Strictly speaking about functionality, the entire series is totally fine,
however, I cannot give you a R-b on patches 6 and 7, since this code should
*really* make use of phy_get(), like suggested by Vinod.
In any case, for this patch:
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
Powered by blists - more mailing lists