From patchwork Fri Aug 14 06:57:22 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: You-Sheng Yang X-Patchwork-Id: 1344669 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4BSZ643xsWz9sPB; Fri, 14 Aug 2020 16:58:36 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1k6Tfb-0007yu-Pg; Fri, 14 Aug 2020 06:58:31 +0000 Received: from mail-pf1-f196.google.com ([209.85.210.196]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1k6TfW-0007oC-4J for kernel-team@lists.ubuntu.com; Fri, 14 Aug 2020 06:58:26 +0000 Received: by mail-pf1-f196.google.com with SMTP id m71so4115846pfd.1 for ; Thu, 13 Aug 2020 23:58:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=zOXj1ySO+G7qoe+9TvmN/BfGLyefW0e/eMWiK8pufMM=; b=JZ/foLKqhkK3FPjmyYRDOcLXB0EZ2GYnwRKAvlbM4gQOf/OGvzXLQJ66Ltcq2gxenf qcCdawvYoap/mgaRebHsimV9bErjNH37mPimrxrodL06y55en5TDcCVa6lBPyOJg4P8P YBMP1PGjcO/rKLfnLW2G2PvSTZIkYsnN8IdjHVg91sPi/+Hw4y61vgIdf0R2flhLn1EC sIajxBtwvfS8SFlotp4iwMCxwWT/i8TALYQ+C4SQRvL6Mmn+IgvUjubVHJ36qHKbQwia qywHVRq4p/2X4PNFx7ZmLud8p2PdKuevrSDPmh+dlLQXPn738KuKIa6FDVojhkNvEUsa OY4g== X-Gm-Message-State: AOAM532AeT6FNmyEksYlp8lb82OqTt+w/QVSYIrzXyFfACiGtz9z/Ceh i4doDt/x5Fm9adS/KDsJKXQW3oniUjS2VQ== X-Google-Smtp-Source: ABdhPJyLtqy4ifwuDJaYWryiC/DRON+f5hTY09wCFB1heQ5N/zba/qXrLFbA13WFqSQaAcH/8ECqoQ== X-Received: by 2002:a63:c252:: with SMTP id l18mr906830pgg.349.1597388298084; Thu, 13 Aug 2020 23:58:18 -0700 (PDT) Received: from localhost (61-220-137-37.HINET-IP.hinet.net. [61.220.137.37]) by smtp.gmail.com with ESMTPSA id i14sm7094974pjz.25.2020.08.13.23.58.17 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Aug 2020 23:58:17 -0700 (PDT) From: You-Sheng Yang To: kernel-team@lists.ubuntu.com Subject: [PATCH 13/31][SRU][OEM-5.6] drm/i915: Don't check uv_wm in skl_plane_wm_equals() Date: Fri, 14 Aug 2020 14:57:22 +0800 Message-Id: <20200814065740.276039-14-vicamo.yang@canonical.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200814065740.276039-1-vicamo.yang@canonical.com> References: <20200814065740.276039-1-vicamo.yang@canonical.com> MIME-Version: 1.0 Received-SPF: pass client-ip=209.85.210.196; envelope-from=vicamo@gmail.com; helo=mail-pf1-f196.google.com X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Ville Syrjälä BugLink: https://bugs.launchpad.net/bugs/1891451 The hardware never sees the uv_wm values (apart from uv_wm.min_ddb_alloc affecting the ddb allocation). Thus there is no point in comparing uv_wm to determine if we need to reprogram the watermark registers. So let's check only the rgb/y watermark in skl_plane_wm_equals(). But let's leave a comment behind so that the next person reading this doesn't get as confused as I did when I added this check. If the ddb allocation ends up changing due to uv_wm skl_ddb_add_affected_planes() takes care of adding the plane to the state. TODO: we should perhaps just eliminate uv_wm from the state and simply track the min_ddb_alloc for uv instead. Cc: Matt Roper Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20200228203552.30273-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza (cherry picked from commit e7f54e6c198159ff593f1d52707d40a82899cfc7) Signed-off-by: You-Sheng Yang --- drivers/gpu/drm/i915/intel_pm.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 5eba87c55d54..d25726666177 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5407,8 +5407,12 @@ static bool skl_plane_wm_equals(struct drm_i915_private *dev_priv, int level, max_level = ilk_wm_max_level(dev_priv); for (level = 0; level <= max_level; level++) { - if (!skl_wm_level_equals(&wm1->wm[level], &wm2->wm[level]) || - !skl_wm_level_equals(&wm1->uv_wm[level], &wm2->uv_wm[level])) + /* + * We don't check uv_wm as the hardware doesn't actually + * use it. It only gets used for calculating the required + * ddb allocation. + */ + if (!skl_wm_level_equals(&wm1->wm[level], &wm2->wm[level])) return false; }