Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1359156imm; Tue, 3 Jul 2018 09:45:05 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfzZR7j89OdHVtspSSXqFuqUb8RFrJrMdLBu8YNxxSs9Xiq0uGBDDuT1ZbPJfWPWISI30gc X-Received: by 2002:a63:b02:: with SMTP id 2-v6mr7821961pgl.301.1530636305917; Tue, 03 Jul 2018 09:45:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530636305; cv=none; d=google.com; s=arc-20160816; b=RJHGTta6ZK1qwrvwIJGzBAByXyTzgBypfUJffeaNB5DT7i/7mjtC/2DP0VbBiVmzAh MFFggtI2NDXJDjvvSpuJsj616/B0Hrr6Mo+XMPToELe5b46+TUrsmFyM32zHRAioNQ3d 9uluP0flxJPs3iZsxuZ4joXL+6tJptN9kr1bJgea+obYoDFbHCvahCdOI2n95vYV6XtP MYP/0ad5ouj4pMjSTJCCKgIghOCkXGqEmXFYcafviMtYaV1PwgD1udC5I2kGIDDQwl6I j7hkr9TNx52SsKnxsm2A5DSap6ygufJg8aiNpU73+A/lpTZzHywTrMcF88SFvvC1lOdC 54Rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=1wNCcbZuS/uxRdodOlI2/DPyHSzehxwgeuoGmB3mH30=; b=IhriZW1PvvtRbcX9IPQvwktnkJhhnZcPpfzp17oINm292s7axGIqFRQDWBRzHlvpt7 v2IYRjHs1HcBLJwanKaz5W+gTNNAWUI+hiI72Ocm8W83+3Nm9kQNMf3n7CDiCfgBZ/f8 iElGyBmiU2vrHv/JCI3VlSE/MhLLBcLjYdVP7Qi8IpGM15H0O1PEeAnVdFM9mLSuI8bV /VDkvxevKBkvoN1uOYnupl5c9+AiGclB1U0ACoXT6+BJdkwi7QUJ7gJmk8SSEmHnbUOS M1+NZynj40S0XtFIMQO8vflr2ByQpu1h+I/shmaf0bAAlv0phDXdv/BechOnd0PiRQmZ l9Sg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="cSinXxf/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b17-v6si1376576pls.467.2018.07.03.09.44.49; Tue, 03 Jul 2018 09:45:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="cSinXxf/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933961AbeGCQoJ (ORCPT + 99 others); Tue, 3 Jul 2018 12:44:09 -0400 Received: from mail-qk0-f194.google.com ([209.85.220.194]:46189 "EHLO mail-qk0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932520AbeGCQoI (ORCPT ); Tue, 3 Jul 2018 12:44:08 -0400 Received: by mail-qk0-f194.google.com with SMTP id o2-v6so1335458qkc.13; Tue, 03 Jul 2018 09:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=1wNCcbZuS/uxRdodOlI2/DPyHSzehxwgeuoGmB3mH30=; b=cSinXxf/QThPy/w/0NIKz8YwGSd2wx8ZQrOxeMp6GbqdrO0kZd8XIM9fPRFe6BxrvO Ztqp5QmIx1z7SseMAlDr+K4dcseu/+Dg6iXHrwJHxIms+6JZaIpbgeMwHPL9PJkF2T7T X3AgMSrhictuTkq/y03Mf9mptVlIWSaD9IPwDLEqc7KrXNZYLc8ODDiDLCBNIkELhWAE Qu5vn0imxf61ZErObkFkmuvXNNcp92cSA/MmjDZZai4iMsunP92YRqZK0rmKDgNTh7oE JyZyl/DWelGmBuaV3Yt/uEaMvNBCnZWvjlYpMDdyZN0aUAx0i2PArnrMitjNLLwNkW/z 5UAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=1wNCcbZuS/uxRdodOlI2/DPyHSzehxwgeuoGmB3mH30=; b=ogdLPfzNRCP+1wxOTk+iCCzjJ93WMwEbKESKzVxUvr7wpwX1hhUNWyneIJRTikIvel p08rZhajNvWqX5Nhibqw6AiwjEXvHAqLQKvwWxFSA5g2BGlxF0LePCpE+jpbwBMnkHoi +qBr47mzqqtJxu+mOiojJPam4i01dX+Oo4mrq+cYnmo4Yrol1tJE/EFhPuZmC1EKKJWi YpMbcDtZ9WD+mik7vT4m4Q2ipZ1QJWobVtb5nBOPoo2EPwDNqg5ZLCEe8VVIgSPMUuIn 2+ljDCG/pv+eujCqDkkOeyHNtwwRzsDxJqLeEoLzNIbhKLWYwfsLciimT+LQMGypsQqV OuJw== X-Gm-Message-State: APt69E2ccF4lKbFiXdXXFMo3F7+9aCLywZoleH2OLo7jfVA9hVp6tbFF Ff53z8QAAMiNx4MU0tVoXoU= X-Received: by 2002:a37:b12:: with SMTP id 18-v6mr26017635qkl.217.1530636247288; Tue, 03 Jul 2018 09:44:07 -0700 (PDT) Received: from localhost ([144.121.20.162]) by smtp.gmail.com with ESMTPSA id f64-v6sm1406848qkf.2.2018.07.03.09.44.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 03 Jul 2018 09:44:06 -0700 (PDT) From: Rob Clark To: dri-devel@lists.freedesktop.org Cc: Rob Clark , David Airlie , Archit Taneja , Sean Paul , linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH] drm/msm/mdp5: fix missing CTL flush Date: Tue, 3 Jul 2018 12:43:50 -0400 Message-Id: <20180703164403.23877-1-robdclark@gmail.com> X-Mailer: git-send-email 2.17.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org f9cb8d8d836e fixed various race conditions with CTL flush, in particular flushing and sending the START signal before encoder state was updated. But it did this a little too well in some cases that don't trigger encoder->enable(), and CTL[n].FLUSH would never be set. When page flips happen it would paper over the bug, since the first plag flip would flush out the state to the hardware. The issue could be reproduced with, for example, modetest (without the '-v' argument). Fixes: f9cb8d8d836e drm/msm/mdp5: rework CTL START signal handling Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c index 9af94e35f678..fcd44d1d1068 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c @@ -319,7 +319,17 @@ static int mdp5_encoder_atomic_check(struct drm_encoder *encoder, mdp5_cstate->ctl = ctl; mdp5_cstate->pipeline.intf = intf; - mdp5_cstate->defer_start = true; + + /* + * This is a bit awkward, but we want to flush the CTL and hit the + * START bit at most once for an atomic update. In the non-full- + * modeset case, this is done from crtc->atomic_flush(), but that + * is too early in the case of full modeset, in which case we + * defer to encoder->enable(). But we need to *know* whether + * encoder->enable() will be called to do this: + */ + if (drm_atomic_crtc_needs_modeset(crtc_state)) + mdp5_cstate->defer_start = true; return 0; } -- 2.17.1