Dne sobota, 22. februar 2025 ob 03:48:01 Srednjeevropski standardni čas je Ryan Walklin napisal(a): > On Sat, 22 Feb 2025, at 7:57 AM, Jernej Škrabec wrote: > > Hi Ryan, > > > > sorry for very late review, but here we go... > > No problem, thanks for the review! > > > This patchset actually introduces 3 disticnt features, which should IMO > > be separated > > and thus making reviewing patches easier. > > > > 1. native 10-bit YUV420 output (without YUV->RGB->YUV conversions) - > > this is used on > > HDMI for proper 10-bit 4K@60 HDR output > > 2. Display Engine 3.3 (DE33) support > > 3. AFBC modifier/format support (used for more efficient GPU or VPU > > output rendering) > > > > If I'm not mistaken, your goal is only DE33 support. > > This is my initial goal, but I would still like good HDMI and video support (including HW decode). > > It took some refactoring and resequencing of (your) existing driver work to get to this series, and I have left out the HDMI and separated the TCON code for the same reason, that initially I am intending to just support RGB operation to an LCD. I do intend however to use the HDMI code either in or out of tree but think that will be a much bigger/more complex change to mainline given the current HDMI code is more invasive to the generic driver. > > The YUV and AFBC changes seemed more self-contained and seemed reasonable approaches given that they were both features of the DE3 and up. I am happy either to split these into either 4 or 5 separate patches ie: > > 1a. refactor CSC code to prepare for YUV > 1b. add YUV for DE3 > 2. refactor mixer enumeration and regmaps to support DE3+ > 3. add DE33 > 4. Add AFBC > > My only reluctance is that that adds more work to manage multiple patches which are logically grouped and in terms of ease of review, all these 4 steps are in the current set in that order (apart from AFBC which is completely standalone), and I don't think submitting them separately reduces complexity. It however will reduce reviewer burden as you suggest, but this has been a slow process already. Sorry, completely forgot. YUV420 HDMI code relies on my previous work, with which Maxime wasn't happy with: https://lore.kernel.org/linux-sunxi/20230924192604.3262187-1-jernej.skrabec@xxxxxxxxx/ So unless switching HDMI to bridge ops is implemented, which also brings format, YUV formatter and some other patches just add unused code, which isn't ideal, especially if we decide to rework driver before that code can be put in acceptable state for all involved.
