From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0E558CA0FE7 for ; Tue, 26 Aug 2025 16:08:28 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A953510E696; Tue, 26 Aug 2025 16:08:27 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=qualcomm.com header.i=@qualcomm.com header.b="JbswCT6s"; dkim-atps=neutral Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6166B10E0DA for ; Tue, 26 Aug 2025 16:08:26 +0000 (UTC) Received: from pps.filterd (m0279866.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 57QD6HBD014293 for ; Tue, 26 Aug 2025 16:08:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=qcppdkim1; bh=5Y6MH/IfjA1JcEnoDtSw8pJM 2X/EunOT5oKJPorXhUE=; b=JbswCT6sjJBwB/oXRot1KzTm7NFqJUos8kr5i1CQ MP1A0cQ0WBCm2vDiljFK0hOwi19o+0cJpUQVlWAONGs8nOm7/NEe7wEfUuvyhydc CmhkC/SkW6VCegD9VGihV7/3wCI+YqYEZI5A1/Fx3TizavTs3DR0NGFBGFUhhTxl SnU65YAmgvZinrJ1lwsb93+k8Klg1GXt/QBvWkL4nZ9pJmbQFJHCg5jMMZS1tKnE KWpQSqL6k5pfdetx2H7bjnQOy4oeSH6onMkGAxSU27uvyINNG6CJd8IgdNd1kXyE Z/lqRkYgZuw4nptDVgV7LXFFAaNJJzX1TbIWhbep88YBhA== Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 48q6x89jy4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 26 Aug 2025 16:08:25 +0000 (GMT) Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-4b10993f679so156559691cf.0 for ; Tue, 26 Aug 2025 09:08:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756224504; x=1756829304; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5Y6MH/IfjA1JcEnoDtSw8pJM2X/EunOT5oKJPorXhUE=; b=fM6AKuoe9AM65aFTuUo1pgJnNaMtT/VZguAIbuehfVYz0qHIllkyAkIDz8EWNKJipW ZoM2pqJmPlmsRV5jWVE68kXsXI52MtlpJKkuXU2ybFB2QtX/09goV0TI3JzYcuHJgKp3 cYDOlu8V1YhtBXdFj3eZWUqTfAVUQB/aAfYFn1Y0sOsAQRXCNeNa++LgoOu3tWImhyez 39Rc0TDqaYEUp9Xn8eotoQrSBsezFczV8V3fNpaxuhylFM/RCRbkqXoI/QfLQxm9gYZh k8DZqqpJMDcqQTCq9x1egjnSqoXAGRasA1uwqwtReiJHvBrIDMovZ+dedJTk4GLz080c T8Xw== X-Forwarded-Encrypted: i=1; AJvYcCVMoaR0OIZsOjFkCaSn7NgGSaAkLgBETqpvgTz1beda1PJGn7fA9OPGmn5VcKu5tm4yCa2FVLTp@lists.freedesktop.org X-Gm-Message-State: AOJu0YwA/VQoaGw3TLZGNKXm1waeghA/KcfG6Zs3cjev6kNN8p7HpX61 r1ZueqY2HGWmhyc7PYGQSs5NlxcrbNmcicPum3NfYIBwUiwyuin1DBcC5NuPGwxNvJauHVlV4lt FVqzajNpin5zAU1kpvpnlwqbxtkXDaPmzXedbZ/oZH1LtCIcf3hUlvR73msSS6WIOIbow X-Gm-Gg: ASbGncuLt6wNOZZw7pqTJhm8LjEG7iM2ksGth7r9xtgERdIG3hUEBhOc4mcLaZMuuYu EiO7aI3eNkPN8t3B7rHq0kiG0W7ClLWuNWumfmLKJloqIM74tHDfYbbsqLCqkaDA5v2K9/UnKuT IIUFQUy6BiSy0IB9pDUKOfIj67Ok55Tp0RmghwNZK0PrFyvyU+eIKnTknl4yl7syiVSzWaAA9Uc tKeskfcXkJCV43RJfiGb7UCs4gWVWbY1SfZNEecZ6ysKyR6gxSWk1MJrYONVBrHLi/PUw6zCMW7 Ys4JY3AvsjNOyKB9pA7FqCg6joZms2wljxUauSq5LReQvpma10yNmjR/WQ5xDpgo6UBuGxvreoK VxaqyB1WJLONhnH8zAfVSrg8zY4ew3tV9KnvxWP6HD4C5LS5dRLHN X-Received: by 2002:a05:622a:188e:b0:4b0:677d:d8e1 with SMTP id d75a77b69052e-4b2aaa055c4mr159229851cf.17.1756224504011; Tue, 26 Aug 2025 09:08:24 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGw4XVvhS8sJ4oPyO5LSxRLiQgorFOHBMUJBTT8et5S5EVGydVwVkXldGpoHbR11UxUC58e2w== X-Received: by 2002:a05:622a:188e:b0:4b0:677d:d8e1 with SMTP id d75a77b69052e-4b2aaa055c4mr159227761cf.17.1756224501655; Tue, 26 Aug 2025 09:08:21 -0700 (PDT) Received: from umbar.lan (2001-14ba-a0c3-3a00-264b-feff-fe8b-be8a.rev.dnainternet.fi. [2001:14ba:a0c3:3a00:264b:feff:fe8b:be8a]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-55f45a230ddsm1241131e87.59.2025.08.26.09.08.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Aug 2025 09:08:20 -0700 (PDT) Date: Tue, 26 Aug 2025 19:08:17 +0300 From: Dmitry Baryshkov To: "mripard@kernel.org" Cc: "Kandpal, Suraj" , "liviu.dudau@arm.com" , 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" , "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: <76cmo6pqa534cdnckfgsnspczenzt7kiwkpgg4olxysjn2can7@g5dxteqi5jjs> References: <20250811094429.GE21313@pendragon.ideasonboard.com> <20250811111546.GA30760@pendragon.ideasonboard.com> <2ah3pau7p7brgw7huoxznvej3djct76vgfwtc72n6uub7sjojd@zzaebjdcpdwf> <20250826-skinny-dancing-otter-de9be4@houat> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250826-skinny-dancing-otter-de9be4@houat> X-Proofpoint-ORIG-GUID: OrtQyzGylKmQdQNHFDXctcNDqVbzkKy0 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwODIzMDA0NCBTYWx0ZWRfX6SlgWFQXbHsl 4HijDwEscm3arU1jzjd9IEVMAxLgzx41Dh5xgurOLoVibu4DA3Nl+IV/mPCScm2hVdj/BKYRdpJ KwLR6iU7gSH1jgzP7hEnFH9ZjZ194upGWzahfVpMH/Xr4iKk6h+yEKgNPiT0u5GHT0Ad/j8SnSU J6dEZQD5jooS968qjYzcvHj60bdgiiYwAa5S4AUPPGnC2xqz8ZtFIHoxuMCLeH23bApbC4O6ymh yu8iLnURf0vtt+Upm6a9oeQ99iIZwA6xR1EA9I/SJxYe/1EoZ/CnhK7/MiwmEHMTtLbX9RmCl9w XNdtUxlT/EIQVx4E+yw+7qWSHk6cHC8E6FwJZ4YRwj/MsGOV+hnPjx8gmtJYoM1m3S3Kj7D7S34 MnMKz5xP X-Proofpoint-GUID: OrtQyzGylKmQdQNHFDXctcNDqVbzkKy0 X-Authority-Analysis: v=2.4 cv=Ep/SrTcA c=1 sm=1 tr=0 ts=68addbf9 cx=c_pps a=mPf7EqFMSY9/WdsSgAYMbA==:117 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=2OwXVqhp2XgA:10 a=VwQbUJbxAAAA:8 a=7CQSdrXTAAAA:8 a=cj-Nge-_NgV5cCdd3SwA:9 a=CjuIK1q_8ugA:10 a=dawVfQjAaf238kedN5IG:22 a=a-qgeE7W1pNrGK8U0ZQC:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.1.9,FMLib:17.12.80.40 definitions=2025-08-26_02,2025-08-26_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 spamscore=0 adultscore=0 bulkscore=0 suspectscore=0 phishscore=0 priorityscore=1501 malwarescore=0 impostorscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2507300000 definitions=main-2508230044 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On Tue, Aug 26, 2025 at 05:48:18PM +0200, mripard@kernel.org wrote: > On Mon, Aug 25, 2025 at 06:26:48AM +0000, Kandpal, Suraj wrote: > > > Subject: Re: [RFC PATCH 1/8] drm: writeback: Refactor > > > drm_writeback_connector structure > > > > > > Hi, > > > > > > On Sat, Aug 16, 2025 at 01:20:53AM +0300, Dmitry Baryshkov wrote: > > > > On Thu, Aug 14, 2025 at 05:13:54PM +0100, liviu.dudau@arm.com wrote: > > > > > 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. > > > > > > > > Maybe Maxime can better comment on it, but I think it was made exactly > > > > for the purpose of not limiting the driver's design. For example, a > > > > lot of drivers subclass drm_connector via drm_bridge_connector. If > > > > struct drm_connector_hdmi was a wrapper around struct drm_connector, > > > > then it would have been impossible to use HDMI helpers for bridge > > > > drivers, while current design freely allows any driver to utilize > > > > corresponding library code. > > > > > > That's exactly why we ended up like this. With that design, we wouldn't have > > > been able to "inherit" two connector "classes": bridge_connector is one, > > > intel_connector another one. > > > > > > See here for the rationale: > > > https://lore.kernel.org/dri-devel/ZOTDKHxn2bOg+Xmg@phenom.ffwll.local/ > > > > > > I don't think the "but we'll bloat drm_connector" makes sense either. > > > There's already a *lot* of things that aren't useful to every connector (fwnode, > > > display_info, edid in general, scaling, vrr, etc.) > > > > > > And it's not like we allocate more than a handful of them during a system's life. > > > > So Are we okay with the approach mentioned here with the changes that have been proposed here like > > Having drm_writeback_connector in union with drm_hdmi_connector > > I don't think we need a union here. It artificially creates the same > issue: we can't have two types for a connector if we do so. Well... What kind of connector would be both HDMI and WriteBack? I think they are mutually exclusive already. > > Also one more thing I would like to clarify here is how everyone would > > like the patches patches where each patch changes both the drm core > > and all related drivers (ensures buildability but then review is tough > > for each driver). Or patches where we have initial drm core changes > > and then each patch does the all changes in a driver in its own > > respective patch. > > The latter should be preferred, but if you can't maintain bisectability > that way, then it's the most important and you should fall back to the > former. I'd say, we should be trying our best in providing bisectability. It really a PITA if one can not use `git bisect run`. -- With best wishes Dmitry