On Mon, Jun 03, 2024 at 03:03:12PM GMT, Heiko Stuebner wrote: > Am Montag, 3. Juni 2024, 14:14:17 CEST schrieb Andy Yan: > > Hi Neil: > > > > On 6/3/24 16:55, Neil Armstrong wrote: > > > Hi Christian, > > > > > > On 01/06/2024 15:12, Cristian Ciocaltea wrote: > > >> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the > > >> Synopsys DesignWare HDMI TX controller used in the previous SoCs. > > >> > > >> It is HDMI 2.1 compliant and supports the following features, among > > >> others: > > >> > > > . > > > > > > .. > > > > > >> * SCDC I2C DDC access > > >> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4 > > >> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds > > >> * Multi-stream audio > > >> * Enhanced Audio Return Channel (EARC) > > > -> Those features were already supported by the HDMI 2.0a compliant HW, just > > > list the _new_ features for HDMI 2.1 > > > > > > I did a quick review of your patchset and I don't understand why you need > > > to add a separate dw-hdmi-qp.c since you only need simple variants of the I2C > > > bus, infoframe and bridge setup. > > > > > > Can you elaborate further ? isn't this Quad-Pixel (QP) TX controller version > > > detectable at runtime ? > > > > > > I would prefer to keep a single dw-hdmi driver if possible. > > > > The QP HDMI controller is a completely different variant with totally different > > registers layout, see PATCH 13/14. > > I think make it a separate driver will be easier for development and maintenance. > > I'm with Andy here. Trying to navigate a driver for two IP blocks really > sounds taxing especially when both are so different. If it's a completely new controller, I agree that it needs a new driver, but then why do we need to share code between the two? Maxime
Attachment:
signature.asc
Description: PGP signature
