Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp510619pxp; Fri, 11 Mar 2022 08:39:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJxKoSnSG6IpCYTWFZtCi50dP2j+YNd+rDY+kvmtuIlmA7MeQgq1VmQxgnnptFEYHkjOMf9P X-Received: by 2002:aa7:8882:0:b0:4df:7b9e:1ccb with SMTP id z2-20020aa78882000000b004df7b9e1ccbmr10783121pfe.41.1647016775538; Fri, 11 Mar 2022 08:39:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1647016775; cv=none; d=google.com; s=arc-20160816; b=HboRrsYRibK7SdHUjbiJ30kVWmoWxlD6YqQWPYZCVGjS1bTnZcGGKBF+YdaACr9xlV vvLXeC9zEg7NctaFfICfLHS2okirklLSspeW6lJCuMVc/yQ2VrtAVyZleslgQUyOAMec X6kBWOzGWwaM1djdRB6/w49kt1y8V2j75zP+OdzHQ3An7R6/vhSyzoR2artl24LIRsuf gpkSkWTKv11854J9w3WMz2vcPxC6YR3w+FrYldgaNuOKvf5Gy5OTJ2yX7RB0pL5XircQ JHGQAfesvjtvowb90OAGeMvxOiV1+VwZLZ8gumsDFepuBdiSsRtZ1WcwBAPeT1lBGIbN q7Kw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=jjiwqlYyclbx2DJUqm+w4fp1F5GsZcEFn5+cReHV+A8=; b=rUZRWEal66q3s5WQKJBgxI0zpI1gPbifnh82IZh7j5ZFYwJFzGrw8yYTBOPEsSARAU /ZHSgWXcQWLWG9jk40oXLiKUDlGjQTfvrSYbJsu3oikMeAhLVrxnIgjlv07UfF8/VBvp H+BWMXAFbwLA74rNT9NyXUgPGwMARDvif+NNCwfFnh2Q+KSVS7Oh5/PI2hb+KFddCr/L oL1FvZUpvbB8+e8zJikriqgvpuTcoQVf/9FqDXB3Qy4fmZpjsIjwN4UhVCFe9ZLSLMgt YA2ECEqFLUlJPtWv06/qznpyvQ1IskXv/OhKzmIsCUBijUmPqjDdufInXmdLMzjJM7VW xLeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jOQkeXei; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id oo4-20020a17090b1c8400b001bd6b5b192csi6671147pjb.22.2022.03.11.08.39.18; Fri, 11 Mar 2022 08:39:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jOQkeXei; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245727AbiCJTGG (ORCPT + 99 others); Thu, 10 Mar 2022 14:06:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34130 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239330AbiCJTGE (ORCPT ); Thu, 10 Mar 2022 14:06:04 -0500 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C915E141E3E for ; Thu, 10 Mar 2022 11:05:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646939102; x=1678475102; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=WnFGNKbJzycKyV82fMk3LWMbBnyeS+s9105OQY/fMpc=; b=jOQkeXeihZRAUZnmZfqgK1V1WJurN4yFWBixmEuw0+rTbe1LMZlp0ET1 P5qJNNihAAoDh5joEuiyi3Ks/Hagd/Zwtdp/rq+3En/Cv6vv2X3xSTqcH ptrr73D5X/OiPeD+qtj2HDCGjkcO8+LyFLC/cjMdJilAWAtLApeYlL7Ce Op2nPBAO80VezYpeBAk3hBXV2EYMUdldaFXMDzgfJ5iaG+eHh5IxQYfjK fmWcvAnFRBXVTdsXXZ85lpKXPRdezRM8FR5+FY/cBCiuXDbmiNqQ3e/ur rpa6eDobrcDHtDX0O8dysgH8wRusmB+sreBeSBEfuyo2opxM9UFM9Opy2 Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10282"; a="255081932" X-IronPort-AV: E=Sophos;i="5.90,171,1643702400"; d="scan'208";a="255081932" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Mar 2022 11:03:49 -0800 X-IronPort-AV: E=Sophos;i="5.90,171,1643702400"; d="scan'208";a="554794723" Received: from jdubrow-mobl.amr.corp.intel.com (HELO intel.com) ([10.255.39.9]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Mar 2022 11:03:46 -0800 Date: Thu, 10 Mar 2022 14:03:45 -0500 From: Rodrigo Vivi To: Alexander Usyskin Cc: Greg Kroah-Hartman , Jani Nikula , Joonas Lahtinen , David Airlie , Daniel Vetter , Tvrtko Ursulin , linux-kernel@vger.kernel.org, Tomas Winkler , Vitaly Lubart , intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH v10 4/5] mei: gsc: add runtime pm handlers Message-ID: References: <20220308163654.942820-1-alexander.usyskin@intel.com> <20220308163654.942820-5-alexander.usyskin@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220308163654.942820-5-alexander.usyskin@intel.com> X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 08, 2022 at 06:36:53PM +0200, Alexander Usyskin wrote: > From: Tomas Winkler > > Implement runtime handlers for mei-gsc, to track > idle state of the device properly. > > CC: Rodrigo Vivi > Signed-off-by: Tomas Winkler > Signed-off-by: Alexander Usyskin > --- > drivers/misc/mei/gsc-me.c | 67 ++++++++++++++++++++++++++++++++++++++- > 1 file changed, 66 insertions(+), 1 deletion(-) > > diff --git a/drivers/misc/mei/gsc-me.c b/drivers/misc/mei/gsc-me.c > index cf427f6fdec9..dac482ddab51 100644 > --- a/drivers/misc/mei/gsc-me.c > +++ b/drivers/misc/mei/gsc-me.c > @@ -152,7 +152,72 @@ static int __maybe_unused mei_gsc_pm_resume(struct device *device) > return 0; > } > > -static SIMPLE_DEV_PM_OPS(mei_gsc_pm_ops, mei_gsc_pm_suspend, mei_gsc_pm_resume); > +static int __maybe_unused mei_gsc_pm_runtime_idle(struct device *device) > +{ > + struct mei_device *dev = dev_get_drvdata(device); > + > + if (!dev) > + return -ENODEV; > + if (mei_write_is_idle(dev)) > + pm_runtime_autosuspend(device); This is not needed. The _idle() callback is called right before the autosuspend. so you just need to return -EBUSY if not idle. But also I'm missing the call to enable the autosuspend and set the delay. Is this flow really working and you are getting device suspended when not in use? (Maybe it is just my ignorance on other flow types here) > + > + return -EBUSY; > +} > + > +static int __maybe_unused mei_gsc_pm_runtime_suspend(struct device *device) > +{ > + struct mei_device *dev = dev_get_drvdata(device); > + struct mei_me_hw *hw; > + int ret; > + > + if (!dev) > + return -ENODEV; > + > + mutex_lock(&dev->device_lock); > + > + if (mei_write_is_idle(dev)) { > + hw = to_me_hw(dev); > + hw->pg_state = MEI_PG_ON; > + ret = 0; > + } else { > + ret = -EAGAIN; > + } probably not needed this here... but it would be good if you use the runtime_pm{get,put} to protect your write operations as well... > + > + mutex_unlock(&dev->device_lock); > + > + return ret; > +} > + > +static int __maybe_unused mei_gsc_pm_runtime_resume(struct device *device) > +{ > + struct mei_device *dev = dev_get_drvdata(device); > + struct mei_me_hw *hw; > + irqreturn_t irq_ret; > + > + if (!dev) > + return -ENODEV; > + > + mutex_lock(&dev->device_lock); > + > + hw = to_me_hw(dev); > + hw->pg_state = MEI_PG_OFF; > + > + mutex_unlock(&dev->device_lock); > + > + irq_ret = mei_me_irq_thread_handler(1, dev); > + if (irq_ret != IRQ_HANDLED) > + dev_err(dev->dev, "thread handler fail %d\n", irq_ret); > + > + return 0; > +} > + > +static const struct dev_pm_ops mei_gsc_pm_ops = { > + SET_SYSTEM_SLEEP_PM_OPS(mei_gsc_pm_suspend, > + mei_gsc_pm_resume) > + SET_RUNTIME_PM_OPS(mei_gsc_pm_runtime_suspend, > + mei_gsc_pm_runtime_resume, > + mei_gsc_pm_runtime_idle) > +}; > > static const struct auxiliary_device_id mei_gsc_id_table[] = { > { > -- > 2.32.0 >