Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1454486ybk; Thu, 14 May 2020 09:21:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxeQc7+O62x9n2xB1IY0uKcMu4m6aiAdlUZTLnNZGAwD+ARnw3xdQM3vd92LzAX/rNup7UW X-Received: by 2002:a17:906:f90d:: with SMTP id lc13mr4295738ejb.367.1589473306851; Thu, 14 May 2020 09:21:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589473306; cv=none; d=google.com; s=arc-20160816; b=AsJb0Nd1rF8uz5iZU/vExbwe7CAlHL5UDdbhKJebzI/oho/0Fv85YkirwBc1S+WOi9 FaCIlOWrwYZXAQdVc/jju4xAMjIVbT6lhyZJRxnSGCGZ9IbH4kgIBHFsZZFNqXLOZ4ug tq3/OMRRDVHykp0azmCUPZMTKPmaRE+bWkvhQ75RFFoZGkkPxC0RxXiThIsV4epCRzDi QkOHYWsh1gUQ8htMqu+MxhYkRXr2Bzn4+eyF5CCAKX62d8mc0OOZp+R2lDt+1rfUigC4 qAlUXQqfuVgtDZeeKqhAtMy+J7l7/R45DI9O1Po5ifP7pHyRqC9XmUiu5MBzigW2H8Iw aSaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=OqjZEsENiuJ7Z2+zCW9pzRm/SY0vcINZf6TSPb9wFL8=; b=the8GImFAiXBVDNdE7gdrm+EltKgDsh8/41OEGbFSxgNKaigFFS/fHUywiJ9AW8ap6 gvPGUeZTyQ6cfNEWG17w/CGDflwez9aVgsG2Gr8E/LBUZ7unnyvdGaTR6RA4h3+S1Jvx oaRuCeYyRejX/MbfQCuAoggqC2LntgaAlcxq61/HNq/MJiaAZOQf58TQcUxpB9cI6NeZ cYpTDrhvqHUQzrewPAhdHi4mTvPKc8l08cFY3NhJUZw3ilshzrDSUIFwuocNkmyOsxuH kKDqDYDawYUWCeEb8RTRljLTXhCfOJg6SehxB5VUYJZBtNGzhjDKF5wZz2+D1Re4TcZ9 em2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=T5HS0B1f; 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 h10si2174089edn.261.2020.05.14.09.21.23; Thu, 14 May 2020 09:21:46 -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=T5HS0B1f; 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 S1726137AbgENQRb (ORCPT + 99 others); Thu, 14 May 2020 12:17:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726125AbgENQRa (ORCPT ); Thu, 14 May 2020 12:17:30 -0400 Received: from mail-ua1-x943.google.com (mail-ua1-x943.google.com [IPv6:2607:f8b0:4864:20::943]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 92A3CC061A0E for ; Thu, 14 May 2020 09:17:30 -0700 (PDT) Received: by mail-ua1-x943.google.com with SMTP id b6so1342381uak.6 for ; Thu, 14 May 2020 09:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OqjZEsENiuJ7Z2+zCW9pzRm/SY0vcINZf6TSPb9wFL8=; b=T5HS0B1fvJofutv3NJqUrbAvHVxEP8Z/4pbg8rWnyUbriguTHHrLowQ8XSkvu1D4nb CKxxadhSnrOhka8fhDtg4GRuLt/M9djey/HD7gL8AniRdx98Ev//amZicIk25BLCfDDp gSMyC2uil/ZYl+myPhupP0IWuS1OqIEI9X8ZY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OqjZEsENiuJ7Z2+zCW9pzRm/SY0vcINZf6TSPb9wFL8=; b=Q0x1sVbkF1oFWmrm0cdGouNK+XA9uZcG0YM48aVv162kUqPaoXw55iWCAv5N6nwh48 V+/HQHh5dBhqnav42T2LTSAn09l8ipvVrWJjX4WaMVxxBVdgpvss2+aeevL+KyFOHXX5 DrXR3O11+P89VPlUSjWRHY50oy8l8RA0I62z+1u4R8FVzkcWcfCsocR0X+yZMwALm4EY 0ZZ6vItDOrLqLRzUMhcFtVzVWvFaWI5YKk6DCLE3yxjMyFFUeraFeQFgq0MY0lSrmefW fQ8rR+V8R5MNgEyen5hf0r8PEsHekZCltTqhygnKaAQTHSh+pBGmUB2Flsseof6DtrJi V39w== X-Gm-Message-State: AOAM531OWdMCDeb5HE49rSTnHEzEB9qonMdVU92u0uVWEDSiIOOJv+cQ 6w/laFaWuaB6UIGITLAyahFIrHHUg8Q= X-Received: by 2002:ab0:5642:: with SMTP id z2mr4858228uaa.6.1589473049330; Thu, 14 May 2020 09:17:29 -0700 (PDT) Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com. [209.85.221.181]) by smtp.gmail.com with ESMTPSA id e27sm826153vkn.14.2020.05.14.09.17.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 May 2020 09:17:27 -0700 (PDT) Received: by mail-vk1-f181.google.com with SMTP id s85so908830vks.11 for ; Thu, 14 May 2020 09:17:27 -0700 (PDT) X-Received: by 2002:a1f:9605:: with SMTP id y5mr4360665vkd.75.1589473046623; Thu, 14 May 2020 09:17:26 -0700 (PDT) MIME-Version: 1.0 References: <1588339863-1322-1-git-send-email-kalyan_t@codeaurora.org> In-Reply-To: <1588339863-1322-1-git-send-email-kalyan_t@codeaurora.org> From: Doug Anderson Date: Thu, 14 May 2020 09:17:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep To: Kalyan Thota Cc: dri-devel , linux-arm-msm , freedreno , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , LKML , Rob Clark , Sean Paul , "Kristian H. Kristensen" , Jeykumar Sankaran , mkrishn@codeaurora.org, travitej@codeaurora.org, nganji@codeaurora.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Fri, May 1, 2020 at 6:31 AM Kalyan Thota wrote: > > "The PM core always increments the runtime usage counter > before calling the ->suspend() callback and decrements it > after calling the ->resume() callback" > > DPU and DSI are managed as runtime devices. When > suspend is triggered, PM core adds a refcount on all the > devices and calls device suspend, since usage count is > already incremented, runtime suspend was not getting called > and it kept the clocks on which resulted in target not > entering into XO shutdown. > > Add changes to force suspend on runtime devices during pm sleep. > > Changes in v1: > - Remove unnecessary checks in the function > _dpu_kms_disable_dpu (Rob Clark). > > Changes in v2: > - Avoid using suspend_late to reset the usagecount > as suspend_late might not be called during suspend > call failures (Doug). > > Changes in v3: > - Use force suspend instead of managing device usage_count > via runtime put and get API's to trigger callbacks (Doug). > > Changes in v4: > - Check the return values of pm_runtime_force_suspend and > pm_runtime_force_resume API's and pass appropriately (Doug). > > Changes in v5: Can you please put the version number properly in your subject? It's really hard to tell one version of your patch from another. > - With v4 patch, test cycle has uncovered issues in device resume. > > On bubs: cmd tx failures were seen as SW is sending panel off > commands when the dsi resources are turned off. > > Upon suspend, DRM driver will issue a NULL composition to the > dpu, followed by turning off all the HW blocks. > > v5 changes will serialize the NULL commit and resource unwinding > by handling them under PM prepare and PM complete phases there by > ensuring that clks are on when panel off commands are being > processed. I'm still most definitely not an expert in how all the DRM pieces all hook up together, but the solution you have in this patch seems wrong to me. As far as I can tell the "prepare" state isn't supposed to be actually doing the suspend work and here that's exactly what you're doing. I think you should find a different solution to ensure ordering is correct. -Doug