On 05/20, Dmitry Baryshkov wrote: > On Tue, May 19, 2026 at 09:59:00AM -0700, John Harrison wrote: > > On 5/16/26 08:25, Dmitry Baryshkov wrote: > > > On Tue, 05 May 2026 03:24:57 +0300, Dmitry Baryshkov wrote: > > > > Drivers using drm_writeback_connector_init() / _with_encoder() don't > > > > perform cleanup in a manner similar to drmm_writeback_connector_init() > > > > (see drm_writeback_connector_cleanup()). Migrate all existing drivers > > > > to use drmm_writeback_connector_init(), drop > > > > drm_writeback_connector_init() and drm_writeback_connector::encoder > > > > (it's unused afterwards). > > > > > > > > [...] > > > Applied to msm-fixes, thanks! > > > > > > [1/8] drm/msm/dpu: don't mix devm and drmm functions > > > https://gitlab.freedesktop.org/lumag/msm/-/commit/c0c70a11365c > > > > > > Best regards, > > That is only the first patch of the series, yes? > > Yes, correct. > > > > > What is happening with the rest? Can they all be merged to drm-next now? As > > I understand it, only the first patch was still being discussed, the others > > have all been reviewed some time ago. > > At least we need an ack from the AMD maintainers. I can pick up patches > 3-6 to drm-misc-next, but it doesn't really help because the rest of the > patches are blocked by the AMD change.
Hi Alex, Harry, Could we have your acked-by for this series? I tested it with a DCN 4.0.1 and the kms_writeback test; everything looks fine. This series should not cause regressions because the AMD modifications are restricted to the writeback functions; if you want to be sure and cover more hardware, it can be useful to run it through AMD CI (you just need to make a few minor adjustments when applying it to the amd-staging-drm-next). Anyway, this series was Tested-by: Rodrigo Siqueira <[email protected]> Thanks > > -- > With best wishes > Dmitry -- Rodrigo Siqueira
