Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp572032ybz; Wed, 29 Apr 2020 05:37:22 -0700 (PDT) X-Google-Smtp-Source: APiQypIyCtxl5VegPNt02/91FElR5WAKh+yigij8X/N+Fa2SOBAju4rbn4DQ4kPLImlJ4s/w3kG2 X-Received: by 2002:a17:906:9482:: with SMTP id t2mr2282018ejx.241.1588163841877; Wed, 29 Apr 2020 05:37:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588163841; cv=none; d=google.com; s=arc-20160816; b=tACRN2xLCHMnt91csrTkPMGiumBFY6MeJLy66hrKz2fktjwsmDYxHB1Byn6nEZMZ2h TlntL7c19Up6063GJB4jxf1kBH29z3KcYjLM4ZvgNj6KPLjbxpcFoPEzOR8/EfKeNPSo MIAvwNY6Qpc67vPHD+DTiEJeVtHYnvxtn6nrPUBPXKFfHpCcjPmD8PrYTUmiq6Zxc3PJ YEgAoJ5hVi6GML1zlsLnBonjKQ9ux9AGr1FY/VGquNXjY8j3LxUymw/KHkSXGOApBDPr SYN1GLT+C7nk0uJ7ylXEeSHp2/FM6D0Sw91/Vz4PpIjpAxtOW3a2pDqt3irn07g0lBmO cOhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=NUoe38klOCQtxasI+t9o8qMGW2IzeduoGzN0/atKrts=; b=YU3PtfAf4jAAueeGdaej15MtNFLmATLa0fVRWuUQ3UQG49ckstbnoIbpOP/fs/M7Vu z41omqv1EPp81+8lMOkhEbgxjvqRQs+ZM8020JMHN8dIxL9oiuNcjmfGng6LU3S7JwP3 hoQRZCDXo1K938FJOE3ABdRGUB2zXvDLm/2vXYAJ0SHrDY0TKKQZ3wPa7A5twqSmL4vv 72xQCwVoLEr/5gsd7vBuaEN2l2PNxfi5/eczRZiwBVSwcAKwZiawNISTNc7WbGtVxKfa 4T+Ck87jNDbLfZlgKuGrlpl4A6lrP/edwaSgzRbYX/+Jv3cAStvuth0MT9rUV6vh/t1T xbsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MRiAm3TF; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g20si3278135edm.43.2020.04.29.05.36.58; Wed, 29 Apr 2020 05:37:21 -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=@gmail.com header.s=20161025 header.b=MRiAm3TF; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726884AbgD2Mfa (ORCPT + 99 others); Wed, 29 Apr 2020 08:35:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43356 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726426AbgD2Mfa (ORCPT ); Wed, 29 Apr 2020 08:35:30 -0400 Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C63E1C03C1AD; Wed, 29 Apr 2020 05:35:29 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id f11so2445742ljp.1; Wed, 29 Apr 2020 05:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NUoe38klOCQtxasI+t9o8qMGW2IzeduoGzN0/atKrts=; b=MRiAm3TFoo3RKDwRuwyjSpfg0hBAboJFu4Rg82H4SpneSimPkxNpnFDp4x0JH/adU3 ULl1pjCoQXNHiox1BNXexlIyVXL10N9pJKSBmqe1TnKZCce24DbwlAmyL63O5x+949Bl m4EH3xn7pki+DkNj6lpzgURhqw1xD77/1wDLPOm/PiY3qHHd88hRM+fy4T1k8o6polkT tX+zpbdFCxHrJ33BGkYSHqqgojH8XgOwwKrbZ1053jD1oVgNMwjDJyi/9kMuVoLAotMw 80BOgbaBS8y39odMfidpUpClcBcAIPS+XTgGI1MdidQcto0jv6GVyJRpTbc2HtQWv4xO x1Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NUoe38klOCQtxasI+t9o8qMGW2IzeduoGzN0/atKrts=; b=NOWcLswioiGn7BY9QmlLKNCqadibVyQjO61ttkd00WGsqnedWjBdaf/R8j0hfEN6AU gRGET9qtF66GCMduZ5JYiwhM8x26oErg7QFnQ1MppHbCCSVUjtg4PodqPMzxhJF84otK rlBficTje2pBP+jTX4BLCSk8jYP3+4ouIXpv5qP9kVkY93get0mBueBniurO5GGibvXD qm5p+LXLdt5/U0QfSJWR5SrZ21Ga4d6woNwQuPteV9b6oVhhx6ec1Fti32sCtx1M+Jaj Rb8RtYd+yAomSqVAhi8eUG4NllQL2jgJwPdib5R1MNs3C/am4V35vXZ36DX3r7E2txWs ZlFA== X-Gm-Message-State: AGi0Pua8oVpHy0mfJ/WRLr74opjGzkPh/9fPpqxqBHTEwaKrCeDdgkMx 4KFkvz8ijEGgmDzjcHm1kbg8MEmN X-Received: by 2002:a2e:700b:: with SMTP id l11mr17063691ljc.255.1588163727943; Wed, 29 Apr 2020 05:35:27 -0700 (PDT) Received: from [192.168.2.145] (ppp91-78-208-152.pppoe.mtu-net.ru. [91.78.208.152]) by smtp.googlemail.com with ESMTPSA id k18sm3007442lfg.81.2020.04.29.05.35.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Apr 2020 05:35:27 -0700 (PDT) Subject: Re: [PATCH v2 1/2] i2c: tegra: Better handle case where CPU0 is busy for a long time To: Thierry Reding Cc: Jon Hunter , Wolfram Sang , Laxman Dewangan , Manikanta Maddireddy , Vidya Sagar , linux-i2c@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org References: <79f6560e-dbb5-0ae1-49f8-cf1cd95396ec@nvidia.com> <20200427074837.GC3451400@ulmo> <20200427110033.GC3464906@ulmo> <3a06811c-02dc-ce72-ebef-78c3fc3f4f7c@gmail.com> <20200427151234.GE3464906@ulmo> <1ab276cf-c2b0-e085-49d8-b8ce3dba8fbe@gmail.com> <20200429081448.GA2345465@ulmo> <20200429085502.GB2345465@ulmo> From: Dmitry Osipenko Message-ID: <9e36c4ec-ca02-bd15-d765-15635f09db4b@gmail.com> Date: Wed, 29 Apr 2020 15:35:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200429085502.GB2345465@ulmo> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 29.04.2020 11:55, Thierry Reding пишет: ... >>> It's not "papering over an issue". The bug can't be fixed properly >>> without introducing I2C atomic transfers support for a late suspend >>> phase, I don't see any other solutions for now. Stable kernels do not >>> support atomic transfers at all, that proper solution won't be backportable. >> >> Hm... on a hunch I tried something and, lo and behold, it worked. I can >> get Cardhu to properly suspend/resume on top of v5.7-rc3 with the >> following sequence: >> >> revert 9f42de8d4ec2 i2c: tegra: Fix suspending in active runtime PM state >> apply http://patchwork.ozlabs.org/project/linux-tegra/patch/20191213134417.222720-1-thierry.reding@gmail.com/ >> >> I also ran that through our test farm and I don't see any other issues. >> At the time I was already skeptical about pm_runtime_force_suspend() and >> pm_runtime_force_resume() and while I'm not fully certain why exactly it >> doesn't work, the above on top of v5.7-rc3 seems like a good option. >> >> I'll try to do some digging if I can find out why exactly force suspend >> and resume doesn't work. > > Ah... so it looks like pm_runtime_force_resume() never actually does > anything in this case and then disable_depth remains at 1 and the first > tegra_i2c_xfer() will then fail to runtime resume the controller. That's the exactly expected behaviour of the RPM force suspend/resume. The only unexpected part for me is that the tegra_i2c_xfer() runtime resume then fails in the NOIRQ phase. Anyways, again, today it's wrong to use I2C in the NOIRQ phase becasue I2C interrupt is disabled. It's the PCIe driver that should be fixed.