From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5C4EC218592 for ; Thu, 14 Aug 2025 16:14:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755188044; cv=none; b=WMiMWeS4yNE9uSX85iWz0+SO4y3JWZr+gLP5dYgF0SA+jb/h2/eFEAUXY2lH+ou+0gBLF5G7MuzSvf7w4kDaERW/D9oe9F0aZuDrRT/KNLKJvvC0xgO8FpoC/5MHUqrQ5UEI8IGpvfYC0TOglHLAmV0Pbw8AD3yzDuVMQx317h8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755188044; c=relaxed/simple; bh=Fr6xTqn+YFAKntbls3pZMJ3VQKpDZwrzY1H8n1hFwDk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=N2RPnxPubdoE31I4nougMMoZnptHjjpSiPllXVajQcqXnTnUUz/XGfUlETkM23Hynre1Fo0eP5U5vUY3daBjpmdjLcfyEFK5Cr5nJpjNftgLZZ7e7w0iTX+cSBCeuQZ1w912MqoumOHJ2SDpHAy0+JcRUfXwJXHFPEvJY2qY6Ec= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 82C8E1691 for ; Thu, 14 Aug 2025 09:13:53 -0700 (PDT) Received: from e110455-lin.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 720CA3F738 for ; Thu, 14 Aug 2025 09:14:01 -0700 (PDT) Date: Thu, 14 Aug 2025 17:13:54 +0100 From: "liviu.dudau@arm.com" To: "Kandpal, Suraj" Cc: Dmitry Baryshkov , Laurent Pinchart , "kernel-list@raspberrypi.com" , "amd-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "linux-renesas-soc@vger.kernel.org" , "linux-arm-msm@vger.kernel.org" , "freedreno@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" , "intel-xe@lists.freedesktop.org" , "intel-gfx@lists.freedesktop.org" , "Nautiyal, Ankit K" , "Murthy, Arun R" , "Shankar, Uma" , "Nikula, Jani" , "harry.wentland@amd.com" , "siqueira@igalia.com" , "alexander.deucher@amd.com" , "christian.koenig@amd.com" , "airlied@gmail.com" , "simona@ffwll.ch" , "maarten.lankhorst@linux.intel.com" , "mripard@kernel.org" , "robin.clark@oss.qualcomm.com" , "abhinav.kumar@linux.dev" , "tzimmermann@suse.de" , "jessica.zhang@oss.qualcomm.com" , "sean@poorly.run" , "marijn.suijten@somainline.org" , "mcanal@igalia.com" , "dave.stevenson@raspberrypi.com" , "tomi.valkeinen+renesas@ideasonboard.com" , "kieran.bingham+renesas@ideasonboard.com" , "louis.chauvet@bootlin.com" Subject: Re: [RFC PATCH 1/8] drm: writeback: Refactor drm_writeback_connector structure Message-ID: References: <20250811092707.3986802-1-suraj.kandpal@intel.com> <20250811092707.3986802-2-suraj.kandpal@intel.com> <20250811094429.GE21313@pendragon.ideasonboard.com> <20250811111546.GA30760@pendragon.ideasonboard.com> <2ah3pau7p7brgw7huoxznvej3djct76vgfwtc72n6uub7sjojd@zzaebjdcpdwf> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hi, On Wed, Aug 13, 2025 at 10:04:22AM +0000, Kandpal, Suraj wrote: > > > > }; > > > > > > I still don't like that. This really doesn't belong here. If anything, > > > the drm_connector for writeback belongs to drm_crtc. > > > > Why? We already have generic HDMI field inside drm_connector. I am really > > hoping to be able to land DP parts next to it. In theory we can have a DVI- > > specific entry there (e.g. with the subconnector type). > > The idea is not to limit how the drivers subclass those structures. > > > > I don't see a good case why WB should deviate from that design. > > > > > If the issue is that some drivers need a custom drm_connector > > > subclass, then I'd rather turn the connector field of > > > drm_writeback_connector into a pointer. > > > > Having a pointer requires additional ops in order to get drm_connector from > > WB code and vice versa. Having drm_connector_wb inside drm_connector > > saves us from those ops (which don't manifest for any other kind of structure). > > Nor will it take any more space since union will reuse space already taken up by > > HDMI part. > > > > > > > Seems like this thread has died. We need to get a conclusion on the design. > Laurent do you have any issue with the design given Dmitry's explanation as to why this > Design is good for drm_writeback_connector. I'm with Laurent here. The idea for drm_connector (and a lot of drm structures) are to be used as base "classes" for extended structures. I don't know why HDMI connector ended up inside drm_connector as not all connectors have HDMI functionality, but that's a cleanup for another day. drm_writeback_connector uses the 'base' drm_connector only for a few things, mostly in __drm_writeback_connector_init() and prepare_job()/cleanup_job(). In _init() we just setup the properties and the encoder after we disable interlacing. prepare_job()/cleanup_job() is another workaround to be to some custom ops some drivers might want for signalling. So we should be able to convert the 'base' drm_connector to a pointer relatively easy. We shouldn't need to get to the drm_connector from a drm_writeback_connector() outside drm_writeback.c. Then it looks like what we need is a __drm_writeback_connector_init_with_connector() where we can pass a base pointer and remember it. Maybe an extra parameter to existing init functions, or a new one that skips the encoder initialisation entirely. Best regards, Liviu > > Regards, > Suraj Kandpal > > > > > I plan to add drm_connector_dp in a similar way, covering DP needs > > > > (currently WIP). > > > > -- > > With best wishes > > Dmitry -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯