From patchwork Fri Mar 5 22:21:33 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lyude Paul X-Patchwork-Id: 12119507 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=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 E57D4C433E0 for ; Fri, 5 Mar 2021 22:22:11 +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 7757A65068 for ; Fri, 5 Mar 2021 22:22:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7757A65068 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.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 E66656EC7E; Fri, 5 Mar 2021 22:22:09 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 860696EC7F for ; Fri, 5 Mar 2021 22:22:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614982927; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=aPyMsdHMnfaSpLLwitdtmkV1UTfjg0RUBiyEq1fqjlk=; b=AmptPShX6ktuNf4CsW4G1sq28MTMh7GG5sjbd5cSQsixiFh8LU4n3k9DfEE5eU2Nmkl6vh Rj2pYivTEs8W9wu+9Zj/st1LK93zI2ncuPZ9ubqiCd/bihdSbQKAP8BTlhT7ofZ+K5Ox3L 3IVqv8wdiPYcgTGowaZNxZNTZiFSGpY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-177-PeNlqFzlPsSfWOOkoEvYJg-1; Fri, 05 Mar 2021 17:22:04 -0500 X-MC-Unique: PeNlqFzlPsSfWOOkoEvYJg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 238B3801814; Fri, 5 Mar 2021 22:22:02 +0000 (UTC) Received: from Whitewolf.lyude.net (ovpn-117-70.rdu2.redhat.com [10.10.117.70]) by smtp.corp.redhat.com (Postfix) with ESMTP id E58B31A353; Fri, 5 Mar 2021 22:21:59 +0000 (UTC) From: Lyude Paul To: nouveau@lists.freedesktop.org Subject: [PATCH v2] drm/nouveau/kms/nve4-nv108: Don't advertise 256x256 cursor support yet Date: Fri, 5 Mar 2021 17:21:33 -0500 Message-Id: <20210305222135.1269175-1-lyude@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 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: "open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS" , David Airlie , Pankaj Bharadiya , James Jones , open list , stable@vger.kernel.org, Ben Skeggs , Dave Airlie Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" While Kepler does technically support 256x256 cursors, it turns out that in order for us to use these correctly we need to make sure that the cursor plane uses a ctxdma that is set to use small (4K)/large (128K) pages - whichever is applicable to the given cursor surface. Right now however, we share the main kmsVramCtxDma that is used for all but the ovly plane which defaults to small pages - resulting in artifacts when we use 256x256 cursor surfaces. So until we teach nouveau to use a separate ctxdma for the cursor, let's just stop advertising 256x256 cursors by default - which should fix the issues that users were seeing. Coincidentally - this is also why small ovlys don't work on Kepler: the ctxdma we use for ovlys is set to large pages. Changes since v2: * Fix comments and patch description Signed-off-by: Lyude Paul Fixes: d3b2f0f7921c ("drm/nouveau/kms/nv50-: Report max cursor size to userspace") Cc: # v5.11+ --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index 196612addfd6..d92cf9e17ac3 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -2693,9 +2693,19 @@ nv50_display_create(struct drm_device *dev) else nouveau_display(dev)->format_modifiers = disp50xx_modifiers; - if (disp->disp->object.oclass >= GK104_DISP) { + /* FIXME: 256x256 cursors are supported on Kepler, however unlike Maxwell and later + * generations Kepler requires that we specify the page type, small (4K) or large (128K), + * correctly for the ctxdma being used on curs/ovly. We currently share a ctxdma across all + * display planes (except ovly) that defaults to small pages, which results in artifacting + * on 256x256 cursors. Until we teach nouveau to create an appropriate ctxdma for the cursor + * fb in use, simply avoid advertising support for 256x256 cursors. + */ + if (disp->disp->object.oclass >= GM107_DISP) { dev->mode_config.cursor_width = 256; dev->mode_config.cursor_height = 256; + } else if (disp->disp->object.oclass >= GK104_DISP) { + dev->mode_config.cursor_width = 128; + dev->mode_config.cursor_height = 128; } else { dev->mode_config.cursor_width = 64; dev->mode_config.cursor_height = 64;