From mboxrd@z Thu Jan 1 00:00:00 1970 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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 4822CC54FD3 for ; Wed, 25 Mar 2020 15:40:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2055620774 for ; Wed, 25 Mar 2020 15:40:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iM7fQags" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728078AbgCYPkV (ORCPT ); Wed, 25 Mar 2020 11:40:21 -0400 Received: from mail-ed1-f68.google.com ([209.85.208.68]:46882 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727992AbgCYPkU (ORCPT ); Wed, 25 Mar 2020 11:40:20 -0400 Received: by mail-ed1-f68.google.com with SMTP id cf14so2875079edb.13; Wed, 25 Mar 2020 08:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vVQBr/UYJMdab8jRg2zR24QImGiBviKI+Lqx/RV8Icg=; b=iM7fQags/yNx8RR2ehfaaLuUBoI2eC3ngDb/4LT7lEsOSVAPorZvL9vvcfzaiS579r pgFp1e+/ArquN9GvkHX9wxU90+sCMiWWybFbWUe00yHiHTdHFsutf3sq5PHLUx0JEJWK ck4Q8LpTpZQ3xd2pJEdZYJ/scZaUMf0DXBjEpWdWahv71/3HKMfYwqyZE9x1CylE0FtA lYiAm5qYpDgvG+qJMuPHYWCmkNOZJTw3UpvcMiNXXj3LZwXsTF+Kbf9uaZhGHfi6cbNX P9kq1JZiizjkbHXEhwwS0MQPu0HMt7xJ4FiUjJ9oPLUEPDLaCtnfOmZAgg1olxUPPlug ieXQ== 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=vVQBr/UYJMdab8jRg2zR24QImGiBviKI+Lqx/RV8Icg=; b=XyGgMVFy3IxJi8KSCkRe+fm5iv/vf/Sjqgh39fM93cDdq+arGRZUpsXkdIulaWeDF4 8ghkrlNvrgkRB0/C8eHfVKygf+yhL3fIkbcKPRF5ELspSJAlXWGwudaALq45Hs9nomNV 2Wz6MPtkwajW9mZ8Nufji6Z/GyJ8zy4QOEuDuumCfkepvNWI51KYaD0/r0ifXrr0qah2 I9mmKDjZ0/02TfoQhqHaWMqE+IHJsNTLJJheSM4BID4EcFoa3X9gDEZ4VTAn3BBXhmdT lZJ/z/WFvn+mPY5zfAC1Yihc/HKxTfgVMERvLMENuRQ6dFopsXuivEoHfcleYw93QB7w fnMw== X-Gm-Message-State: ANhLgQ3zcoGpnn7rxqburlF3Tl0rHPAJlhfTO9HezwSjV9fzlom1Gl9W wRbZ3Mj9EH/SS37SQ7vtx2gQfgP0AfqcxjUBznw= X-Google-Smtp-Source: ADFU+vvti2A9QZho9Id7sZ6hCv38ZZx7DwFDLQbnZuOsJZY6bJU+aLt9MOUecd3kZZiKiatZ3p4eVZ3oEbpz1o8iDmo= X-Received: by 2002:a50:d712:: with SMTP id t18mr3467606edi.151.1585150817053; Wed, 25 Mar 2020 08:40:17 -0700 (PDT) MIME-Version: 1.0 References: <1584944027-1730-1-git-send-email-kalyan_t@codeaurora.org> In-Reply-To: From: Rob Clark Date: Wed, 25 Mar 2020 08:40:14 -0700 Message-ID: Subject: Re: [PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep To: Doug Anderson Cc: Kalyan Thota , dri-devel , linux-arm-msm , freedreno , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , LKML , 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-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Tue, Mar 24, 2020 at 7:35 AM Doug Anderson wrote: > > Hi, > > On Sun, Mar 22, 2020 at 11:14 PM 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 manage runtime devices during pm sleep. > > > > Changes in v1: > > - Remove unnecessary checks in the function > > _dpu_kms_disable_dpu (Rob Clark). > > I'm wondering what happened with my feedback on v1, AKA: > > https://lore.kernel.org/r/CAD=FV=VxzEV40g+ieuEN+7o=34+wM8MHO8o7T5zA1Yosx7SVWg@mail.gmail.com > > Maybe you didn't see it? ...or if you or Rob think I'm way off base > (always possible) then please tell me so. > At least w/ the current patch, disable_dpu should not be called for screen-off (although I'd hope if all the screens are off the device would suspend). But I won't claim to be a pm expert.. so not really sure if this is the best approach or not. I don't think our arrangement of sub-devices under a parent is completely abnormal, so it does feel like there should be a simpler solution.. BR, -R From mboxrd@z Thu Jan 1 00:00:00 1970 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=-0.5 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 B1DEAC1975A for ; Wed, 25 Mar 2020 15:40:20 +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 8BAC920789 for ; Wed, 25 Mar 2020 15:40:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iM7fQags" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8BAC920789 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.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 0094E6E87D; Wed, 25 Mar 2020 15:40:20 +0000 (UTC) Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) by gabe.freedesktop.org (Postfix) with ESMTPS id 858486E87D; Wed, 25 Mar 2020 15:40:18 +0000 (UTC) Received: by mail-ed1-x542.google.com with SMTP id bd14so2891617edb.10; Wed, 25 Mar 2020 08:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vVQBr/UYJMdab8jRg2zR24QImGiBviKI+Lqx/RV8Icg=; b=iM7fQags/yNx8RR2ehfaaLuUBoI2eC3ngDb/4LT7lEsOSVAPorZvL9vvcfzaiS579r pgFp1e+/ArquN9GvkHX9wxU90+sCMiWWybFbWUe00yHiHTdHFsutf3sq5PHLUx0JEJWK ck4Q8LpTpZQ3xd2pJEdZYJ/scZaUMf0DXBjEpWdWahv71/3HKMfYwqyZE9x1CylE0FtA lYiAm5qYpDgvG+qJMuPHYWCmkNOZJTw3UpvcMiNXXj3LZwXsTF+Kbf9uaZhGHfi6cbNX P9kq1JZiizjkbHXEhwwS0MQPu0HMt7xJ4FiUjJ9oPLUEPDLaCtnfOmZAgg1olxUPPlug ieXQ== 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=vVQBr/UYJMdab8jRg2zR24QImGiBviKI+Lqx/RV8Icg=; b=sGTH4EAQWx0kjfqPVHljqD5qbn9Lk/VT/0VkXj8xFdlKU1pv8PPr+CqDPwHCsRnGnm pCpsL7xFrymeD3VdPxYDNCAndeGNQXm0yTnyuMFKMQFL9KtLMpwQi54aYvEYHd/ILP1X 47VR3LZWwkLJEzTm/PriY0F84RBSidYwXGURxE9712hv8Kmu0kWq2ZugHZx2SPPzMo2j xkE4OoVXdmZUP3GoRnpL7T8bB1N9Jx+PrmSvGkeZ4zEjlq7Ab9VsHOXoK07/aOkKubP7 ihWEvdHpfbCeM4eCRFPc2omEH+68NLa6VMGBrsR44ixq8m8XcCwaqTEugZsmCnfue00I cGHg== X-Gm-Message-State: ANhLgQ270ERIvbHsmKX6Pcarx7UkDXnmtF8PXHicL87U2SUv38Pw2egP 90NmCZtTAQYH4Ye6Nu6n6K6+phZXIvNvGJu1bexZaei484M= X-Google-Smtp-Source: ADFU+vvti2A9QZho9Id7sZ6hCv38ZZx7DwFDLQbnZuOsJZY6bJU+aLt9MOUecd3kZZiKiatZ3p4eVZ3oEbpz1o8iDmo= X-Received: by 2002:a50:d712:: with SMTP id t18mr3467606edi.151.1585150817053; Wed, 25 Mar 2020 08:40:17 -0700 (PDT) MIME-Version: 1.0 References: <1584944027-1730-1-git-send-email-kalyan_t@codeaurora.org> In-Reply-To: From: Rob Clark Date: Wed, 25 Mar 2020 08:40:14 -0700 Message-ID: Subject: Re: [PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep To: Doug Anderson 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:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , mkrishn@codeaurora.org, linux-arm-msm , travitej@codeaurora.org, LKML , dri-devel , Sean Paul , Kalyan Thota , "Kristian H. Kristensen" , freedreno Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Mar 24, 2020 at 7:35 AM Doug Anderson wrote: > > Hi, > > On Sun, Mar 22, 2020 at 11:14 PM 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 manage runtime devices during pm sleep. > > > > Changes in v1: > > - Remove unnecessary checks in the function > > _dpu_kms_disable_dpu (Rob Clark). > > I'm wondering what happened with my feedback on v1, AKA: > > https://lore.kernel.org/r/CAD=FV=VxzEV40g+ieuEN+7o=34+wM8MHO8o7T5zA1Yosx7SVWg@mail.gmail.com > > Maybe you didn't see it? ...or if you or Rob think I'm way off base > (always possible) then please tell me so. > At least w/ the current patch, disable_dpu should not be called for screen-off (although I'd hope if all the screens are off the device would suspend). But I won't claim to be a pm expert.. so not really sure if this is the best approach or not. I don't think our arrangement of sub-devices under a parent is completely abnormal, so it does feel like there should be a simpler solution.. BR, -R _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel