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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C756FC2BA19 for ; Mon, 6 Apr 2020 09:11:44 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id A696020781 for ; Mon, 6 Apr 2020 09:11:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A696020781 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A3B5F89DF7; Mon, 6 Apr 2020 09:11:41 +0000 (UTC) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id 73EF989BB2; Mon, 6 Apr 2020 09:11:40 +0000 (UTC) IronPort-SDR: m0rdf1h397I0SFc6KKq3iMu3DbrQ3Q2GzthhAPAlURfxXYDDQrqSXoFTF/CtWT7gJx50YihASL j6NG/duO812Q== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2020 02:11:39 -0700 IronPort-SDR: U/7yDPrLtYunTdbwKyXMOoY4ReiX8XnjIuq37cKWO9ZNo/NOrYfPnk8zA/9ubT3ezfozmivQ8/ +9xpwGaATDCQ== X-IronPort-AV: E=Sophos;i="5.72,350,1580803200"; d="scan'208";a="397440298" Received: from maytarsh-mobl1.ger.corp.intel.com (HELO localhost) ([10.249.38.121]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2020 02:11:35 -0700 From: Jani Nikula To: abhinavk@codeaurora.org, Ville Syrjala Subject: Re: [PATCH v2 16/17] drm: Nuke mode->private_flags In-Reply-To: <7cd8b081a383125732dbddd32116e46e@codeaurora.org> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20200403204008.14864-1-ville.syrjala@linux.intel.com> <20200403204008.14864-17-ville.syrjala@linux.intel.com> <7cd8b081a383125732dbddd32116e46e@codeaurora.org> Date: Mon, 06 Apr 2020 12:11:32 +0300 Message-ID: <87r1x1kmgr.fsf@intel.com> MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sam Ravnborg , jeykumar@quicinc.com, Daniel Vetter , intel-gfx@lists.freedesktop.org, Emil Velikov , dri-devel@lists.freedesktop.org, nganji@quicinc.com, pdhaval@quicinc.com, sean@poorly.run, aravindh@quicinc.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, 03 Apr 2020, abhinavk@codeaurora.org wrote: > Hi Ville > > Thanks for the patch. > > Our understanding of private_flags was that we can use it within our > drivers to handle vendor specific features. > Hence we do have several features in our downstream drivers as well as > some planned work based on this. > > This was the only method to pass around and consume the driver only > information which we have been using. > > In the current qualcomm upstream display drivers, the only usage of the > mode->private_flags is what you have removed in > https://patchwork.kernel.org/patch/11473497/. > > However, for other projects which do not use upstream drivers yet, we > have several features already which are using the mode->private_flags. > > We do have a plan to remove the usage of mode->private_flags for those > drivers as well but its not ready yet. > > These downstream drivers still use the upstream drm files for > compilation. > > So how it works is we use all the headers under include/drm and also the > files under drivers/gpu/drm as-it-is from upstream but maintain our > drivers on top of this. > > Removing this will result in compilation failures for us in the near > term. > > Can we keep this one as-it-is and when our changes are ready to post it > upstream we shall remove private_flags from the drm_modes.h If your driver were upstream, Ville would have fixed it in the process of removing private_flags. It would be part of this patch series. That is the only guarantee you get for kernel internal APIs, and you only get that guarantee for drivers in the upstream kernel. Otherwise, all bets are off. Taking all the upstream considerations into account is complicated enough. It is simply not reasonable to hold back internal kernel changes due to out-of-tree or downstream drivers. I know it is painful, but that's the cost of maintaining a driver out-of-tree. Sorry, but no. Further reading [1]. BR, Jani. [1] https://www.kernel.org/doc/html/latest/process/stable-api-nonsense.html -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel 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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7219AC2BA19 for ; Mon, 6 Apr 2020 09:11:42 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 4ED8720781 for ; Mon, 6 Apr 2020 09:11:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4ED8720781 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id AD30089E32; Mon, 6 Apr 2020 09:11:41 +0000 (UTC) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id 73EF989BB2; Mon, 6 Apr 2020 09:11:40 +0000 (UTC) IronPort-SDR: m0rdf1h397I0SFc6KKq3iMu3DbrQ3Q2GzthhAPAlURfxXYDDQrqSXoFTF/CtWT7gJx50YihASL j6NG/duO812Q== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2020 02:11:39 -0700 IronPort-SDR: U/7yDPrLtYunTdbwKyXMOoY4ReiX8XnjIuq37cKWO9ZNo/NOrYfPnk8zA/9ubT3ezfozmivQ8/ +9xpwGaATDCQ== X-IronPort-AV: E=Sophos;i="5.72,350,1580803200"; d="scan'208";a="397440298" Received: from maytarsh-mobl1.ger.corp.intel.com (HELO localhost) ([10.249.38.121]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2020 02:11:35 -0700 From: Jani Nikula To: abhinavk@codeaurora.org, Ville Syrjala In-Reply-To: <7cd8b081a383125732dbddd32116e46e@codeaurora.org> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20200403204008.14864-1-ville.syrjala@linux.intel.com> <20200403204008.14864-17-ville.syrjala@linux.intel.com> <7cd8b081a383125732dbddd32116e46e@codeaurora.org> Date: Mon, 06 Apr 2020 12:11:32 +0300 Message-ID: <87r1x1kmgr.fsf@intel.com> MIME-Version: 1.0 Subject: Re: [Intel-gfx] [PATCH v2 16/17] drm: Nuke mode->private_flags 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: Sam Ravnborg , jeykumar@quicinc.com, Daniel Vetter , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, nganji@quicinc.com, pdhaval@quicinc.com, aravindh@quicinc.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Fri, 03 Apr 2020, abhinavk@codeaurora.org wrote: > Hi Ville > > Thanks for the patch. > > Our understanding of private_flags was that we can use it within our > drivers to handle vendor specific features. > Hence we do have several features in our downstream drivers as well as > some planned work based on this. > > This was the only method to pass around and consume the driver only > information which we have been using. > > In the current qualcomm upstream display drivers, the only usage of the > mode->private_flags is what you have removed in > https://patchwork.kernel.org/patch/11473497/. > > However, for other projects which do not use upstream drivers yet, we > have several features already which are using the mode->private_flags. > > We do have a plan to remove the usage of mode->private_flags for those > drivers as well but its not ready yet. > > These downstream drivers still use the upstream drm files for > compilation. > > So how it works is we use all the headers under include/drm and also the > files under drivers/gpu/drm as-it-is from upstream but maintain our > drivers on top of this. > > Removing this will result in compilation failures for us in the near > term. > > Can we keep this one as-it-is and when our changes are ready to post it > upstream we shall remove private_flags from the drm_modes.h If your driver were upstream, Ville would have fixed it in the process of removing private_flags. It would be part of this patch series. That is the only guarantee you get for kernel internal APIs, and you only get that guarantee for drivers in the upstream kernel. Otherwise, all bets are off. Taking all the upstream considerations into account is complicated enough. It is simply not reasonable to hold back internal kernel changes due to out-of-tree or downstream drivers. I know it is painful, but that's the cost of maintaining a driver out-of-tree. Sorry, but no. Further reading [1]. BR, Jani. [1] https://www.kernel.org/doc/html/latest/process/stable-api-nonsense.html -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx