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 69ED9C433EF for ; Tue, 8 Mar 2022 19:44:17 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7E5A410E495; Tue, 8 Mar 2022 19:44:11 +0000 (UTC) Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com [199.106.114.39]) by gabe.freedesktop.org (Postfix) with ESMTPS id AEDC58989C; Tue, 8 Mar 2022 19:44:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1646768649; x=1678304649; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=iNCOz7hZgjBQm4NquAnXW7pfqyYcChlO/XfWwJieS1A=; b=JnjRycK/u5ueeevlZq1hU3o2xuzW4p4SPzU4kClRVMfTiGODJMBHlGai P61k4LtPcU7dxMdvihTSv9qs+Fzf71mlIYYIvVjhR6gvAfDgwO5RIexiN W92JxaZHmmKTfhsszjfaYVcoeycqT3Ltmb5LcY4ubxxMFrLQMn8ouFxLL s=; Received: from unknown (HELO ironmsg-SD-alpha.qualcomm.com) ([10.53.140.30]) by alexa-out-sd-02.qualcomm.com with ESMTP; 08 Mar 2022 11:44:09 -0800 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg-SD-alpha.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Mar 2022 11:44:08 -0800 Received: from nalasex01a.na.qualcomm.com (10.47.209.196) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.15; Tue, 8 Mar 2022 11:44:08 -0800 Received: from [10.110.69.174] (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.15; Tue, 8 Mar 2022 11:44:07 -0800 Message-ID: <4daece94-c438-29dd-ef9d-e4c4c06187c4@quicinc.com> Date: Tue, 8 Mar 2022 11:44:07 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-US To: "Kandpal, Suraj" , Dmitry Baryshkov References: <87v8xxs2hz.fsf@intel.com> <871qzn6vmc.fsf@intel.com> <4d8daabe-10d9-a3cf-d305-68414cffe4ed@quicinc.com> <0cfd36a2-26e4-309d-d8e9-e3bf8a5d2417@quicinc.com> <9ae6ae27-b8fb-712a-64ec-c5e069059689@quicinc.com> From: Abhinav Kumar In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01a.na.qualcomm.com (10.47.209.196) Subject: Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Carsten Haitzler , "Nikula, Jani" , Daniel Vetter , Intel Graphics Development , dri-devel , David Airlie , Laurent Pinchart Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Hi Suraj On 3/8/2022 6:30 AM, Kandpal, Suraj wrote: > Hi Abhinav, >>> Hi, >>>>> Hi, >>>>>>> Hi Abhinav, >>>>>>>> Hi Laurent >>>>>>>> >>>>>>>> Ok sure, I can take this up but I need to understand the proposal >>>>>>>> a little bit more before proceeding on this. So we will discuss >>>>>>>> this in another email where we specifically talk about the >>>> connector changes. >>>>>>>> >>>>>>>> Also, I am willing to take this up once the encoder part is done >>>>>>>> and merged so that atleast we keep moving on that as MSM WB >>>>>>>> implementation can proceed with that first. >>>>>>>> >>>>>>>> Hi Jani and Suraj >>>>>>>> >>>>>>>> Any concerns with splitting up the series into encoder and >>>>>>>> connector OR re- arranging them? >>>>>>>> >>>>>>>> Let me know if you can do this OR I can also split this up >>>>>>>> keeping Suraj's name in the Co-developed by tag. >>>>>>> I was actually thinking of floating a new patch series with both >>>>>>> encoder and connector pointer changes but with a change in >>>>>>> initialization functions wherein we allocate a connector and >>>>>>> encoder incase the driver doesn’t have its own this should >>>>>>> minimize the effect on other drivers already using current drm >>>>>>> writeback framework and also >>>>>> allow i915 to create its own connector. >>>>>> >> >> I was proposing to split up the encoder and connector because the >> comments from Laurent meant we were in agreement about the encoder >> but not about the connector. >> >> I am afraid another attempt with the similar idea is only going to stall the >> series again and hence i gave this option. > > Seems like this patch series currently won't be able to move forward with the > connector pointer change so I guess you can split the series to encoder pointer > change where we optionally create encoder if required ,keeping my name in > co-developed tag so that msm can move forward with its implementation and > then we can work to see how the connector issue can be bypassed. > > Best Regards, > Suraj Kandpal Thanks, let me re-spin this and will keep your name as co-developer. Should be able to get it on the list in a week. Thanks Abhinav >> Eventually its upto Laurent and the other maintainers to guide us forward on >> this as this series has been stalled for weeks now. >> >>>>>> I thought that Laurent was quite strict about the connector. So I'd >>>>>> suggest targeting drm_writeback_connector with an optionally >>>>>> created encoder and the builtin connector >>>>> In that case even if we target that i915 will not be able to move >>>>> forward with its implementation of writeback as builtin connector >>>>> does not work for us right now as explained earlier, optionally >>>>> creating encoder and connector will help everyone move forward and >>>>> once done >>>> we >>>>> can actually sit and work on how to side step this issue using >>>>> Laurent's suggestion >>>> >>>> This is up to Laurent & other DRM maintainers to decide whether this >>>> approach would be accepted or not. >>>> So far unfortunately I have mostly seen the pushback and a strong >>>> suggestion to stop treating each drm_connector as i915_connector. >>>> I haven't checked the exact details, but IMO adding a branch if the >>>> connector's type is DRM_CONNECTOR_VIRTUAL should be doable. >>> Bringing in the change where we don’t treat each drm_connector as an >>> intel_connector or even adding a branch which checks if drm_connector >>> is DRM_CONNECTOR_VIRTUAL and conditionally cast it to intel_connector >>> is quite a lot of work for i915. >>> That's why I was suggesting if for now we could move forward with >>> optionally creating both encoder and connector minimizing affects on >>> other drivers as well as allowing us to move forward. >>> What do you think, Launrent? >>> >>>> >>>>>> >>>>>>> We can work on Laurent's suggestion but that would first require >>>>>>> the initial RFC patches and then a rework from both of our drivers >>>>>>> side to see if they gel well with our current code which will take >>>>>>> a considerable amount of time. We can for now however float the >>>>>>> patch series up which minimally affects the current drivers and >>>>>>> also allows >>>>>>> i915 and msm to move forward with its writeback implementation off >>>>>>> course with a proper documentation stating new drivers shouldn't >>>>>>> try to >>>>>> make their own connectors and encoders and that drm_writeback will >>>>>> do that for them. >>>>>>> Once that's done and merged we can work with Laurent on his >>>>>>> proposal to improve the drm writeback framework so that this issue >>>>>>> can be side >>>>>> stepped entirely in future. >>>>>>> For now I would like to keep the encoder and connector pointer >>>>>>> changes >>>>>> together. >>>>> >>>>