Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp549144pxy; Fri, 30 Apr 2021 10:46:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwOx993Hz9M88nCQpa1yUv9b/SmsIRraig4BI/KKOI7g5AKhl6iSnqRI/3LO8z72Pv6Sm3M X-Received: by 2002:a17:907:9720:: with SMTP id jg32mr5883493ejc.548.1619804783405; Fri, 30 Apr 2021 10:46:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619804783; cv=none; d=google.com; s=arc-20160816; b=uXVtO/vamABgaiFvdbIv/4TnNOnOJuGf0aJEGfRxnR73Uh5Ox/xzJ2LTfjrl8PrtYJ Uu2DXpHqKylM0n1SVPPls3z2M2v0DNSnnP6ZMwJ8PyibBxK3/Wz3z0NHNPfP1jRC0QI9 Ou89l/aXdRYQ77jvewf4qi4dKmQmx198bE8U64NifNLfKhSNPQP63lLyami/n6azh7Wm pkDcelwvxzXtoDtgOqRfvKucoDQwPqivtk1zqaLRM4M7fKTOIYwio9zot1opGNvZcTmH P4c5ROd398ujzN2DZCcmJ2QSk5y5oEZ9ekP8mWfaTzt5TqmL+hf4TQ2uIj5bWsQP7oiL jcDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:user-agent:from :references:in-reply-to:mime-version:dkim-signature; bh=6g0Wub32949zlUmpDO6orwMigbfoDepmWih+zxo6Gik=; b=s+9OZAmL3GxrRS/ckr4A5laWHrM7ic+DgaaNqidHEzAoiF77/+lnfRdWJkDkxFio91 kESU76/Xk7CtTm9U0yVfPcGXy2m7SmLH8uK9GDbft65yEokgF8xEozofzMBSHhR3dxCY ZJKA5nsCRg2yWDIBO2nmh7wApE8NsCMWJdcTu8F5pzwcSc7isKyDgBefw8pkuDKZeaA+ e27q8r+vejm32tv50RwAPbiUp3KXJHmp5irwr55GgQN8TrIrh5/xPrdHeKtFHHhyTi6F HpxLFaeCeMF/w4HlTZXb+l40598IIaoUsF8U3Agmf+Fs9QXRkdcIs6XDCZ8qkd2dpqUM q36g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Hwdg91N2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m8si2325115edv.506.2021.04.30.10.45.59; Fri, 30 Apr 2021 10:46:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Hwdg91N2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229750AbhD3Rpo (ORCPT + 99 others); Fri, 30 Apr 2021 13:45:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34294 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229954AbhD3Rpn (ORCPT ); Fri, 30 Apr 2021 13:45:43 -0400 Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 231B2C06138B for ; Fri, 30 Apr 2021 10:44:55 -0700 (PDT) Received: by mail-oo1-xc2c.google.com with SMTP id i20-20020a4a8d940000b02901bc71746525so15693413ook.2 for ; Fri, 30 Apr 2021 10:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:user-agent:date:message-id :subject:to:cc; bh=6g0Wub32949zlUmpDO6orwMigbfoDepmWih+zxo6Gik=; b=Hwdg91N23Pzm+MhntYiriTtK3LzxwTdtud93fhi+6PsD2MGghl+QzB5fD/KE4E/UOH rA+vVIVjaVzTOFbRvMMXkHYiDCWmryuId1VhGqaeOkuCUsxD1zdaAp83XrllM50f554B YII/rfNuz5fJX4CecLZUPgYKNcAoSrTUw9Yg0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from :user-agent:date:message-id:subject:to:cc; bh=6g0Wub32949zlUmpDO6orwMigbfoDepmWih+zxo6Gik=; b=n/ECBRwvsDftJJlC/4wctFpelGGOpi4GRAX+a/rY2aoiFu2cLGxNPYmfkz7oDEsAif KkP7K1qe3qLC6wu9AAYN/pqHPZDENrD5Wgz/NsqkhBBIF27GxmeYofmKowHoCoeXxxsm NApynDvrEsDtzatqq8uFD3jal8+i6CrwMJb/RMBnw4k4+9md2UptfLNBfpmhKr2oNk7E K1veG3FB0O6sZ3TdoBNfbuh8STaqPkCGieA/FmkNA7USy6BYW9czk5k+satFuVmwdTDZ wHOj71R692VWCpujGsVp6oB6CdN0DfancyFtiPffz5wDXchXb9tKli0Y7HHGoMtofWsk tH+A== X-Gm-Message-State: AOAM533VMyBlr1MQqmsZEIpjfn+MXX5+L7AuecuwYBLHrl6LBZOUhRsI IDdwC/7/ZFcWUAdmwuEUASxnVvlI7bBhL8Yg9GUqOw== X-Received: by 2002:a05:6820:381:: with SMTP id r1mr5451224ooj.79.1619804694545; Fri, 30 Apr 2021 10:44:54 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 30 Apr 2021 10:44:54 -0700 MIME-Version: 1.0 In-Reply-To: <20210430171744.1721408-1-robdclark@gmail.com> References: <20210430171744.1721408-1-robdclark@gmail.com> From: Stephen Boyd User-Agent: alot/0.9.1 Date: Fri, 30 Apr 2021 10:44:53 -0700 Message-ID: Subject: Re: [PATCH] drm/msm/dpu: Delete bonkers code To: Rob Clark , dri-devel@lists.freedesktop.org Cc: Maxime Ripard , Rob Clark , John Stultz , Sean Paul , David Airlie , Daniel Vetter , Abhinav Kumar , Thomas Zimmermann , Stephen Boyd , Kalyan Thota , Hongbo Yao , Qinglang Miao , Laurent Pinchart , Lee Jones , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Rob Clark (2021-04-30 10:17:39) > From: Rob Clark > > dpu_crtc_atomic_flush() was directly poking it's attached planes in a > code path that ended up in dpu_plane_atomic_update(), even if the plane > was not involved in the current atomic update. While a bit dubious, > this worked before because plane->state would always point to something > valid. But now using drm_atomic_get_new_plane_state() we could get a > NULL state pointer instead, leading to: > > [ 20.873273] Call trace: > [ 20.875740] dpu_plane_atomic_update+0x5c/0xed0 > [ 20.880311] dpu_plane_restore+0x40/0x88 > [ 20.884266] dpu_crtc_atomic_flush+0xf4/0x208 > [ 20.888660] drm_atomic_helper_commit_planes+0x150/0x238 > [ 20.894014] msm_atomic_commit_tail+0x1d4/0x7a0 > [ 20.898579] commit_tail+0xa4/0x168 > [ 20.902102] drm_atomic_helper_commit+0x164/0x178 > [ 20.906841] drm_atomic_commit+0x54/0x60 > [ 20.910798] drm_atomic_connector_commit_dpms+0x10c/0x118 > [ 20.916236] drm_mode_obj_set_property_ioctl+0x1e4/0x440 > [ 20.921588] drm_connector_property_set_ioctl+0x60/0x88 > [ 20.926852] drm_ioctl_kernel+0xd0/0x120 > [ 20.930807] drm_ioctl+0x21c/0x478 > [ 20.934235] __arm64_sys_ioctl+0xa8/0xe0 > [ 20.938193] invoke_syscall+0x64/0x130 > [ 20.941977] el0_svc_common.constprop.3+0x5c/0xe0 > [ 20.946716] do_el0_svc+0x80/0xa0 > [ 20.950058] el0_svc+0x20/0x30 > [ 20.953145] el0_sync_handler+0x88/0xb0 > [ 20.957014] el0_sync+0x13c/0x140 > > The reason for the codepath seems dubious, the atomic suspend/resume > heplers should handle the power-collapse case. If not, the CRTC's > atomic_check() should be adding the planes to the atomic update. > > Reported-by: Stephen Boyd Maybe better to use swboyd@chromium.org for this one. > Reported-by: John Stultz > Fixes: 37418bf14c13 drm: Use state helper instead of the plane state pointer Should be Fixes: 37418bf14c13 ("drm: Use state helper instead of the plane state pointer") to match the preferred format. > Signed-off-by: Rob Clark Otherwise looks good, thanks.