On Thu, Aug 28, 2025 at 03:56:21PM +0300, Dmitry Baryshkov wrote: > On Thu, Aug 28, 2025 at 10:05:28AM +0200, Maxime Ripard wrote: > > On Thu, Aug 28, 2025 at 09:50:34AM +0200, Thomas Zimmermann wrote: > > > Hi > > > > > > Am 28.08.25 um 00:24 schrieb Dmitry Baryshkov: > > > > On Fri, Aug 22, 2025 at 02:39:44PM +0800, Andy Yan wrote: > > > > > From: Andy Yan > > > > > > > > > > > > > > > There are two DW DPTX based DisplayPort Controller on rk3588 which > > > > > are compliant with the DisplayPort Specification Version 1.4 with > > > > > the following features: > > > > > > > > > > * DisplayPort 1.4a > > > > > * Main Link: 1/2/4 lanes > > > > > * Main Link Support 1.62Gbps, 2.7Gbps, 5.4Gbps and 8.1Gbps > > > > > * AUX channel 1Mbps > > > > > * Single Stream Transport(SST) > > > > > * Multistream Transport (MST) > > > > > * Type-C support (alternate mode) > > > > > * HDCP 2.2, HDCP 1.3 > > > > > * Supports up to 8/10 bits per color component > > > > > * Supports RBG, YCbCr4:4:4, YCbCr4:2:2, YCbCr4:2:0 > > > > > * Pixel clock up to 594MHz > > > > > * I2S, SPDIF audio interface > > > > > > > > > > The current version of this patch series only supports basic display outputs. > > > > > I conducted tests with DP0 in 1080p and 4K@60 YCbCr4:2:0 modes; the ALT/Type-C > > > > > mode was tested on Rock 5B, DP1 was tested on Rock 5 ITX by Stephen and Piotr. > > > > > HDCP and audio features remain unimplemented. > > > > > For RK3588, it's only support SST, while in the upcoming RK3576, it can support > > > > > MST output. > > > > > > > > > [skipped changelog] > > > > > > > > > Andy Yan (10): > > > > > dt-bindings: display: rockchip: Add schema for RK3588 DPTX Controller > > > > > drm/bridge: synopsys: Add DW DPTX Controller support library > > > > > drm/rockchip: Add RK3588 DPTX output support > > > > > MAINTAINERS: Add entry for DW DPTX Controller bridge > > > > I tried pushing patches 1-4, but got the following error: > > > > > > > > dim: ERROR: 5a68dcf5837a ("MAINTAINERS: Add entry for DW DPTX Controller bridge"): Mandatory Maintainer Acked-by missing., aborting > > > > > > > > I'm not sure how to handle MAINTAINERS changes (or whether it's fine for > > > > me or not), so I will probably push patches 1-3 in a few days, if nobody > > > > beats me (or unless somebody points out a correct process for > > > > MAINTAINERS changes). > > > > > > That warning has been added recently to make sure that patches do not get in > > > without sufficient review. It's overly pedantic, though. > > > > It's not "overly pedantic", it follows the contribution rules. I'd argue > > that, if anything, we've been overly tolerant with that kind of > > practices. > > > > We do have a bug with handling MAINTAINERS changes at the moment. But > > everything else shouldn't be ignored: either patch MAINTAINERS to > > reflect the actual contribution path, or get the maintainers Ack. > > For me that points out that MAINTAINERS changes should be integrated > into the corresponding driver patch rather than being a separate patch. Not really. It's really just a bug in dim, there's no hidden intent :) Maxime