Message ID | 20240102-j7200-pcie-s2r-v1-1-84e55da52400@bootlin.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-26235-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2614:b0:101:6a76:bbe3 with SMTP id mm20csp1801884dyc; Mon, 15 Jan 2024 08:17:57 -0800 (PST) X-Google-Smtp-Source: AGHT+IHtHLF5nf65r+F4kMroc9trjEJ4lhxfMotbgHhMKzVQeMju87mO9+5aGDjoRxJVcBg8tGeI X-Received: by 2002:a17:90a:e614:b0:28c:91a6:8b81 with SMTP id j20-20020a17090ae61400b0028c91a68b81mr3041482pjy.58.1705335477446; Mon, 15 Jan 2024 08:17:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705335477; cv=none; d=google.com; s=arc-20160816; b=LOrkkayr2owtN+SYCM3NEss6LzpsYYfBZbCftfxZPgjVOEBfVz+G3ULLcNBqUlG5kA BfAvmRcAMzRw6oCI4vvuG9rNaq+s+S13bKJ6Sq7oTCLoUXdGPqgqnwktKJs/pX15TjJk Z6rgdmj6TrvA9bodONTIfVYW+wW/6sKLIJFPoECl9Nmx6nf25Zc/IJ6JoBPEBggUBTEg Jh3PL6WfrcT/LJ7M15NLtGe0obDvu4xav6n3A6UEmxKmRsXQHS1tX26sOZ5lkdIY+m2n qzoH3qcbvGIsQnDTFQHsAkGO9mlX2kDlYmGYMOLce/ZbVS4TEcMIxq5O21bhNOL5kepX OkTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :subject:date:from:dkim-signature; bh=QdylFGoGNBM+6WQopCODNAlZIa2ZGhmHad5v6oJ+DkE=; fh=ihwxVJW8DyodhmdJo1IfhLUDNDWeXh+49SpWXYbpL2Y=; b=IKibiDmTw7jSJVa3aTvNtqNXtLvlNS5uweouL1uloe1gFxbH1wAVQNlSES/a387YAr PS6X320+zwRCe9gngVTq6xXRVETTslrJ3FiK++MX76HjPV1ZDRA6Ku0HTaRecPGszqoN p7Rq9v/WOT6HncUySZxQ6ZxXysByrxAgPOgMuKHNwHR53SD8endfnUxc9bLhzzj4kAoq IiCiFEj6chegJtp+BxEgVdWSaE0aMNDXMwcNXkM8uk18Ew+ctoKSYNPLhOY/loht2LAP xnWHnUKabKnO9fHgMoc62L4P5tywWGcjuuLRZNG+5N1f8xU+HCCR03OyPX+0Y6RiXZer EVgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=Xrrtb3P8; spf=pass (google.com: domain of linux-kernel+bounces-26235-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-26235-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id y6-20020a17090a644600b0028cfb02353asi11638411pjm.169.2024.01.15.08.17.57 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jan 2024 08:17:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-26235-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=Xrrtb3P8; spf=pass (google.com: domain of linux-kernel+bounces-26235-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-26235-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id EDEAC282B1E for <ouuuleilei@gmail.com>; Mon, 15 Jan 2024 16:17:56 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id ADB9C1865C; Mon, 15 Jan 2024 16:16:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="Xrrtb3P8" Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9FA54179B8; Mon, 15 Jan 2024 16:16:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Received: by mail.gandi.net (Postfix) with ESMTPSA id 24575C0006; Mon, 15 Jan 2024 16:16:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1705335376; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QdylFGoGNBM+6WQopCODNAlZIa2ZGhmHad5v6oJ+DkE=; b=Xrrtb3P8fSAlvWg0HrBGIRn0z/2b89JwWbXUPzMJkJN376Hsr93U/+D2nW34Ye9VuZmmGf ycr1Bs2cezuq7DwAcszuCKv6OZ0GZNOWD/GG6kwlbfJohqEKpI8kO4aiLcMOBIwjnWGgeT dZ88pTG+vgf55p7hXOdqN+xAn5lJ/syE1dhWn0U79r171RVUSF7FhhvGRCr0UND8VnVdvY Zh4df2PphsovC0oH0o5a931aYsS2riTeyWAP9CjYPcxurcj/zVsmaBSPU3mXQFj8xr2Lef 3jEwsT2hqPazGPMtOqt7fxwVUsYNS9roCJRNlXsXPatwGcNvGXAWys3x2NpB8g== From: Thomas Richard <thomas.richard@bootlin.com> Date: Mon, 15 Jan 2024 17:14:42 +0100 Subject: [PATCH 01/14] gpio: pca953x: move suspend/resume to suspend_noirq/resume_noirq Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20240102-j7200-pcie-s2r-v1-1-84e55da52400@bootlin.com> References: <20240102-j7200-pcie-s2r-v1-0-84e55da52400@bootlin.com> In-Reply-To: <20240102-j7200-pcie-s2r-v1-0-84e55da52400@bootlin.com> To: Linus Walleij <linus.walleij@linaro.org>, Bartosz Golaszewski <brgl@bgdev.pl>, Andy Shevchenko <andy@kernel.org>, Tony Lindgren <tony@atomide.com>, Haojian Zhuang <haojian.zhuang@linaro.org>, Vignesh R <vigneshr@ti.com>, Aaro Koskinen <aaro.koskinen@iki.fi>, Janusz Krzysztofik <jmkrzyszt@gmail.com>, Andi Shyti <andi.shyti@kernel.org>, Peter Rosin <peda@axentia.se>, Vinod Koul <vkoul@kernel.org>, Kishon Vijay Abraham I <kishon@kernel.org>, Philipp Zabel <p.zabel@pengutronix.de>, Tom Joseph <tjoseph@cadence.com>, Lorenzo Pieralisi <lpieralisi@kernel.org>, =?utf-8?q?Krzysztof_Wilczy=C5=84?= =?utf-8?q?ski?= <kw@linux.com>, Rob Herring <robh@kernel.org>, Bjorn Helgaas <bhelgaas@google.com> Cc: linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org, linux-i2c@vger.kernel.org, linux-phy@lists.infradead.org, linux-pci@vger.kernel.org, gregory.clement@bootlin.com, theo.lebrun@bootlin.com, thomas.petazzoni@bootlin.com, u-kumar1@ti.com, Thomas Richard <thomas.richard@bootlin.com> X-Mailer: b4 0.12.0 X-GND-Sasl: thomas.richard@bootlin.com X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788173853585580182 X-GMAIL-MSGID: 1788173853585580182 |
Series |
Add suspend to ram support for PCIe on J7200
|
|
Commit Message
Thomas Richard
Jan. 15, 2024, 4:14 p.m. UTC
Some IOs can be needed during suspend_noirq/resume_noirq.
So move suspend/resume callbacks to noirq.
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
---
drivers/gpio/gpio-pca953x.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
Comments
On 1/15/24 20:56, Andy Shevchenko wrote: > On Mon, Jan 15, 2024 at 6:16 PM Thomas Richard > <thomas.richard@bootlin.com> wrote: >> >> Some IOs can be needed during suspend_noirq/resume_noirq. > > ->suspend_noirq() / ->resume_noirq() > >> So move suspend/resume callbacks to noirq. > > ... > >> -static DEFINE_SIMPLE_DEV_PM_OPS(pca953x_pm_ops, pca953x_suspend, pca953x_resume); >> +static const struct dev_pm_ops pca953x_pm_ops = { >> + SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(pca953x_suspend_noirq, pca953x_resume_noirq) >> +}; > > Please, use correct / modern macro. > Hello Andy, Thanks for the reviews. I applied your comments for the next iteration. Regards,
Hello Tony, On 1/16/24 08:43, Tony Lindgren wrote: > * Thomas Richard <thomas.richard@bootlin.com> [240115 16:16]: >> Some IOs can be needed during suspend_noirq/resume_noirq. >> So move suspend/resume callbacks to noirq. > > So have you checked that the pca953x_save_context() and restore works > this way? There's i2c traffic and regulators may sleep.. I wonder if > you instead just need to leave gpio-pca953x enabled in some cases > instead? > Yes I tested it, and it works (with my setup). But this patch may have an impact for other people. How could I leave it enabled in some cases ? Regards,
On Fri, Jan 19, 2024 at 6:01 PM Thomas Richard <thomas.richard@bootlin.com> wrote: > On 1/16/24 08:43, Tony Lindgren wrote: > > * Thomas Richard <thomas.richard@bootlin.com> [240115 16:16]: > >> Some IOs can be needed during suspend_noirq/resume_noirq. > >> So move suspend/resume callbacks to noirq. > > > > So have you checked that the pca953x_save_context() and restore works > > this way? There's i2c traffic and regulators may sleep.. I wonder if > > you instead just need to leave gpio-pca953x enabled in some cases > > instead? > > > > Yes I tested it, and it works (with my setup). > But this patch may have an impact for other people. > How could I leave it enabled in some cases ? I guess you could define both pca953x_suspend() and pca953x_suspend_noirq() and selectively bail out on one path on some systems? Worst case using if (of_machine_is_compatible("my,machine"))... Yours, Linus Walleij
On 1/28/24 01:12, Linus Walleij wrote: > On Fri, Jan 19, 2024 at 6:01 PM Thomas Richard > <thomas.richard@bootlin.com> wrote: >> On 1/16/24 08:43, Tony Lindgren wrote: >>> * Thomas Richard <thomas.richard@bootlin.com> [240115 16:16]: >>>> Some IOs can be needed during suspend_noirq/resume_noirq. >>>> So move suspend/resume callbacks to noirq. >>> >>> So have you checked that the pca953x_save_context() and restore works >>> this way? There's i2c traffic and regulators may sleep.. I wonder if >>> you instead just need to leave gpio-pca953x enabled in some cases >>> instead? >>> >> >> Yes I tested it, and it works (with my setup). >> But this patch may have an impact for other people. >> How could I leave it enabled in some cases ? > > I guess you could define both pca953x_suspend() and > pca953x_suspend_noirq() and selectively bail out on one > path on some systems? Yes. What do you think if I use a property like for example "ti,pm-noirq" to select the right path ? Is a property relevant for this use case ? Regards, > > Worst case using if (of_machine_is_compatible("my,machine"))... > > Yours, > Linus Walleij
On Thu, Feb 8, 2024 at 5:19 PM Thomas Richard <thomas.richard@bootlin.com> wrote: > On 1/28/24 01:12, Linus Walleij wrote: > > I guess you could define both pca953x_suspend() and > > pca953x_suspend_noirq() and selectively bail out on one > > path on some systems? > > Yes. > > What do you think if I use a property like for example "ti,pm-noirq" to > select the right path ? > Is a property relevant for this use case ? That's a Linux-specific property and that's useless for other operating systems and not normally allowed. PM noirq is just some Linux thing. *FIRST* we should check if putting the callbacks to noirq is fine with other systems too, and I don't see why not. Perhaps we need to even merge it if we don't get any test results. If it doesn't work we can think of other options. Yours, Linus Walleij
On 2/8/24 22:29, Linus Walleij wrote: > On Thu, Feb 8, 2024 at 5:19 PM Thomas Richard > <thomas.richard@bootlin.com> wrote: >> On 1/28/24 01:12, Linus Walleij wrote: > >>> I guess you could define both pca953x_suspend() and >>> pca953x_suspend_noirq() and selectively bail out on one >>> path on some systems? >> >> Yes. >> >> What do you think if I use a property like for example "ti,pm-noirq" to >> select the right path ? >> Is a property relevant for this use case ? > > That's a Linux-specific property and that's useless for other operating > systems and not normally allowed. PM noirq is just some Linux thing. > > *FIRST* we should check if putting the callbacks to noirq is fine with > other systems too, and I don't see why not. Perhaps we need to even > merge it if we don't get any test results. > > If it doesn't work we can think of other options. I think all systems using a i2c controller which uses autosuspend should be impacted. I guess a patch (like I did in this series for i2c-omap [1]) should be applied for all i2c controller which use autosuspend. [1] https://lore.kernel.org/all/hqnxyffdsiqz5t43bexcqrwmynpjubxbzjchjaagxecso75dc7@y7lznovxg3go/ Regards,
On Fri, Feb 9, 2024 at 8:44 AM Thomas Richard <thomas.richard@bootlin.com> wrote: > > *FIRST* we should check if putting the callbacks to noirq is fine with > > other systems too, and I don't see why not. Perhaps we need to even > > merge it if we don't get any test results. > > > > If it doesn't work we can think of other options. > > I think all systems using a i2c controller which uses autosuspend should > be impacted. > I guess a patch (like I did in this series for i2c-omap [1]) should be > applied for all i2c controller which use autosuspend. > > [1] > https://lore.kernel.org/all/hqnxyffdsiqz5t43bexcqrwmynpjubxbzjchjaagxecso75dc7@y7lznovxg3go/ I think this is the right thing to do. Maybe we should just go over all of them? (Also SPI controllers?) We will soon merge a patch to move the pinctrl-single PM to noirq, and that actually affects more than just OMAP, it also has effect on e.g. HiSilicon so we can expect a bit of shakeout unless we take a global approach to this. Yours, Linus Walleij
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c index 00ffa168e405..83da5d213c55 100644 --- a/drivers/gpio/gpio-pca953x.c +++ b/drivers/gpio/gpio-pca953x.c @@ -1234,7 +1234,7 @@ static void pca953x_save_context(struct pca953x_chip *chip) regcache_cache_only(chip->regmap, true); } -static int pca953x_suspend(struct device *dev) +static int pca953x_suspend_noirq(struct device *dev) { struct pca953x_chip *chip = dev_get_drvdata(dev); @@ -1248,7 +1248,7 @@ static int pca953x_suspend(struct device *dev) return 0; } -static int pca953x_resume(struct device *dev) +static int pca953x_resume_noirq(struct device *dev) { struct pca953x_chip *chip = dev_get_drvdata(dev); int ret; @@ -1268,7 +1268,9 @@ static int pca953x_resume(struct device *dev) return ret; } -static DEFINE_SIMPLE_DEV_PM_OPS(pca953x_pm_ops, pca953x_suspend, pca953x_resume); +static const struct dev_pm_ops pca953x_pm_ops = { + SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(pca953x_suspend_noirq, pca953x_resume_noirq) +}; /* convenience to stop overlong match-table lines */ #define OF_653X(__nrgpio, __int) ((void *)(__nrgpio | PCAL653X_TYPE | __int))