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=-9.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable 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 7D484C433DF for ; Thu, 28 May 2020 07:46:29 +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 4AD50208E4 for ; Thu, 28 May 2020 07:46:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=cerno.tech header.i=@cerno.tech header.b="wD9Cp1Ay"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="Nh5U/pBB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4AD50208E4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cerno.tech 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 EA3EE6E43C; Thu, 28 May 2020 07:43:56 +0000 (UTC) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by gabe.freedesktop.org (Postfix) with ESMTPS id BF39B6E33D for ; Wed, 27 May 2020 15:49:45 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 34431582026; Wed, 27 May 2020 11:49:45 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 27 May 2020 11:49:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; s=fm2; bh=oSQosAw4Q7vGc L01pDAaCeuv0svJvci7XNfnDxhY4go=; b=wD9Cp1AyP9VKPrrwQzGwKUXpxp/l5 czNXVKIztc5CQZ6FJOuNMqm/QKv/RvS462MsxJl3tYhhGKGCcHJ0UsJAwWyGrdqX vYElxJafEcu1iTG3nDRkvMMdtzYYvlj1VFf3viC+aqybv5/sp/XD/IdMOrOl97e0 b6/Z1NhqKooplUd/W3GfRIMH4kJZDgjO/dSMtKDQZHlfrI2quuKa1PV8M6lZUgTq FXFCBdGFQ2kJSUCoc6kw4+U1yCKaYDNywv3pVItPURxFdnmsBsvlhFW3Oe4zfS8h 35rkOIx8snehUrBi2Gy2DnIGPFDva2RpDBFx5uV7difcuSgQPWYic8vhw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=oSQosAw4Q7vGcL01pDAaCeuv0svJvci7XNfnDxhY4go=; b=Nh5U/pBB R3zjrWJYZTF0l7hNzolnuMDFOO/hm4ZN36giX965khZbgejIMaYsJcS/o4sVZjRc RmI3PqOuBNQIpEowA5/Xm6lmvOfh3A5cZfHWMdxv202776iBjR4exEA/OilQjZiq 6jmdhNv+i11nz0ESshWdLUpUKV5/32kUfwZTW66PGoo4gCrMLpmGfyOmU2BPbAPj ibtGrNYS+EXRwRuOq97rxHxE8adv+ATY9gbnwQEZCv5GlCKC+lWmmqtMwg3Mgzva Wuf/hNMA/6U2PXjFYNTXEtdUF7IW26xs2r/VEnzS4UFcWf2K5IwPWnhvseE2jwk7 x9GldzGz/o8V1Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvgedgkeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepvdekleevfeffkeejhfffueelteelfeduieefheduudfggffhhfffheevveeh hedvnecukfhppeeltddrkeelrdeikedrjeeinecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhgrgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA id C663C3280064; Wed, 27 May 2020 11:49:44 -0400 (EDT) From: Maxime Ripard To: Nicolas Saenz Julienne , Eric Anholt Subject: [PATCH v3 018/105] drm/vc4: plane: Move additional planes creation to driver Date: Wed, 27 May 2020 17:47:48 +0200 Message-Id: <0b85a3fdb20bb4ff85fb62cabd082d5a65e2730b.1590594512.git-series.maxime@cerno.tech> X-Mailer: git-send-email 2.26.2 In-Reply-To: References: MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 28 May 2020 07:43:50 +0000 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: Tim Gover , Dave Stevenson , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, bcm-kernel-feedback-list@broadcom.com, linux-rpi-kernel@lists.infradead.org, Phil Elwell , linux-arm-kernel@lists.infradead.org, Maxime Ripard Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" So far the plane creation was done when each CRTC was bound, and those planes were only tied to the CRTC that was registering them. This causes two main issues: - The planes in the vc4 hardware are actually not tied to any CRTC, but can be used with every combination - More importantly, so far, we allocate 10 planes per CRTC, with 3 CRTCs. However, the next generation of hardware will have 5 CRTCs, putting us well above the maximum of 32 planes currently allowed by DRM. This patch is the first one in a series of patches that will take down both of these issues so that we can support the next generation of hardware while keeping a good amount of planes. We start by changing the way the planes are registered to first registering the primary planes for each CRTC in the CRTC bind function as we used to, but moving the overlay and cursor creation to the main driver bind function, after all the CRTCs have been bound. This will slightly change the ID order of the planes, since the primary planes of all CRTCs will be first, and then a pattern of 8 overlays, 1 cursor plane for each CRTC. This shouldn't cause any trouble since the ordering between the planes is preserved though. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_crtc.c | 4 ---- drivers/gpu/drm/vc4/vc4_drv.c | 7 +++++++ 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c index 29c72c322c6b..2131164779dd 100644 --- a/drivers/gpu/drm/vc4/vc4_crtc.c +++ b/drivers/gpu/drm/vc4/vc4_crtc.c @@ -1192,10 +1192,6 @@ static int vc4_crtc_bind(struct device *dev, struct device *master, void *data) */ drm_crtc_enable_color_mgmt(crtc, 0, true, crtc->gamma_size); - ret = vc4_plane_create_additional_planes(drm, crtc); - if (ret) - goto err_destroy_planes; - vc4_crtc_get_cob_allocation(vc4_crtc); CRTC_WRITE(PV_INTEN, 0); diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index d7f554a6f0ed..daf07a61a7b5 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -250,6 +250,7 @@ static int vc4_drm_bind(struct device *dev) { struct platform_device *pdev = to_platform_device(dev); struct drm_device *drm; + struct drm_crtc *crtc; struct vc4_dev *vc4; struct device_node *node; int ret = 0; @@ -288,6 +289,12 @@ static int vc4_drm_bind(struct device *dev) if (ret) goto gem_destroy; + drm_for_each_crtc(crtc, drm) { + ret = vc4_plane_create_additional_planes(drm, crtc); + if (ret) + continue; + } + drm_fb_helper_remove_conflicting_framebuffers(NULL, "vc4drmfb", false); ret = vc4_kms_load(drm); -- git-series 0.9.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel