From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 911613A1D1B for ; Mon, 20 Apr 2026 14:15:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776694533; cv=none; b=F0OCEPdE2l2nKu8GMYJ82gKMyxSIYLpI3NLsBMT8FwDIb0HoBURx4LSuN5dRM6gedviVLw42AOAqgwm8dpqnFTwrPYV0YVMqL2RH0jNWShbKU8PH+Nrh1GSlvBn+Q+cCTZKdpw/9URV3JP824fSRtF58Z7Ks66fPF5jZQQn4Gxc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776694533; c=relaxed/simple; bh=ppsjy5cDgZ57Fyuoqm+hMsyL1FzmZJz4ryCWUG3qf58=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=X20JyykZJLxhGbGsVXk5I05j29oTsuLms0KUXH3o7y4iqP/MlRgjDHFriGeJNEj35wWXKPa3l7AYyoP2VjUmzswjfr6M5rPM2erLva8yRGM6vRP4Ubxny9nF+64sgXu4N89lrFp3w8OseegYQL3y5qPP9wvmxGf5QiDu0Po6Agw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tuxon.dev; spf=pass smtp.mailfrom=tuxon.dev; dkim=pass (2048-bit key) header.d=tuxon.dev header.i=@tuxon.dev header.b=Mt6szZCq; arc=none smtp.client-ip=209.85.128.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tuxon.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=tuxon.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=tuxon.dev header.i=@tuxon.dev header.b="Mt6szZCq" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-48a3e9862f0so4115185e9.1 for ; Mon, 20 Apr 2026 07:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxon.dev; s=google; t=1776694530; x=1777299330; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=t1bUvFpr3NIXY40lz2U87H/IH5ItVZVdVUddh0JtzjI=; b=Mt6szZCqaIMKyCOHFVNTJN3cvaGHM6/ZUXjXZeA7ru/cnIwI8HL4M79vTKch9fbIIt g20pVkGMmv3p2Nk+SVjcnvXbu3Iue7lVTRrPGsBSJogI3mTwRYGP+Cg1KoHQ4bHLixyU Mjo8jGNuM4bbUn1IZUmhXTtA2l4cJ61n2snD4pkJULN2OV/jDvE2hQ99wBx8tqKoFbNl IfzLfy/LhaIOg0NwlgjSH3J+fll9yBFfd9q/+tDu0ew4aJ4vWgnj9Xeo8CLbEs22AYXm 3CDF8OFsQLiAg1dYzUFGH8tJHvTieOv7EAcdGNYDKAiGP+mHTz5wlXIVW3If/yjbUZM3 d4UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776694530; x=1777299330; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=t1bUvFpr3NIXY40lz2U87H/IH5ItVZVdVUddh0JtzjI=; b=mGOIWM4fC2enqNGakWKiACctj+Ducf27nOhNvLNLPNUs9PqCd3hFbd0PPG9u7YPyuz b0cZ5WCHqdh4TLuVzucOwp2u6War8QsH5DZvVN4nOuyFItLJvvGOvv1ZI89qIH9TXjH6 kZ8JHQDUYOTuYLEQp/PfrTRERrIO0QGEs/QiRsMm7uSObbSTCaEYvGMHxj0V1DedLvcE LV7uVk16QyaR8/CoRweq1aOewvgQkgwKZmGc9uSdANX8lxyhtyHjUqbZDDrOZyVJRgRb q+zNQqsgRcS5DZr/M3F9ifORTXavMUErDofF3lbvEOH6G3H0+AzR9jTgHeDBRgcCsCsV Sn4A== X-Forwarded-Encrypted: i=1; AFNElJ/iOcSTlpJLkWrOlGQPN1PEcq2B2h/oC4ToHE9Qxe5aiHQZT253H0XvYBJrKrL9tKJTQUdp9oYhZ4i9Sl0=@vger.kernel.org X-Gm-Message-State: AOJu0Yz0Qt97G68bokHO8aoabXFORF3wn5+2jOKd1likTiNctt+mwVlT N+d1VANh+fveGFXhWj2KXrpD5fsMIE5n+jHUomS+C0XclTMi+j/Tl5XkcMTnVTqbuZ8= X-Gm-Gg: AeBDiev20oHafLyVLzBadVfmMlmD3iZA34x9hTP9jX4e8pvbY4eMx03iW03iMsKrjyF Ezz4yH/q1EIQX8nPHFjuCtNCJ8rDxagQ3jGFCuRvUhZDSj0Bobfq7yUdzD18fL3CL+pvZtjB11r XMoom+5UtgEur/fq4chmvKi87vWLPVFs+N26+cF6a6BCOYByxo8eqJOpFMDaMJ38YCqTJ3TrtkD jGUXCIAFOSyuzIYp0l8qL7bkUZywGKIXHN3i9MaB8c63fE3bz5aynuGCCH1PPDALfnHqO9kNHxH NvMQb8gK9XWDgXVdwB/P0FQeCqd7GL6LI98b0ftz37AOcUtWWJS+lrBiKSbdj6/00FfXKmwhas5 AQppTfcXp/TfuVl26hguwOM6vWr6RTDU3lwzxwQ99FF3lok2voRhZUU2E2dEVyMQMiX1L1o2CfK AS+R5t9Amouc5JgxnW3HJiFv6CLzYxrPk//5T/amss+8l/NBFQjfdD X-Received: by 2002:a05:600c:570f:b0:488:a502:8955 with SMTP id 5b1f17b1804b1-488fb882f13mr152359325e9.4.1776694529960; Mon, 20 Apr 2026 07:15:29 -0700 (PDT) Received: from [192.168.50.4] ([82.78.167.123]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43fe4e46471sm28832892f8f.28.2026.04.20.07.15.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Apr 2026 07:15:29 -0700 (PDT) Message-ID: <36468f41-7808-4fe3-b4bf-94eb128276fc@tuxon.dev> Date: Mon, 20 Apr 2026 17:15:27 +0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 14/17] dmaengine: sh: rz-dmac: Add suspend to RAM support To: Biju Das , "vkoul@kernel.org" , "Frank.Li@kernel.org" , "lgirdwood@gmail.com" , "broonie@kernel.org" , "perex@perex.cz" , "tiwai@suse.com" , Prabhakar Mahadev Lad , "p.zabel@pengutronix.de" , "geert+renesas@glider.be" , Fabrizio Castro , Long Luu Cc: "dmaengine@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-sound@vger.kernel.org" , "linux-renesas-soc@vger.kernel.org" , Claudiu Beznea References: <20260411114303.2814115-1-claudiu.beznea.uj@bp.renesas.com> <20260411114303.2814115-15-claudiu.beznea.uj@bp.renesas.com> Content-Language: en-US From: Claudiu Beznea In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/20/26 10:42, Biju Das wrote: >> +static int rz_dmac_suspend(struct device *dev) { >> + struct rz_dmac *dmac = dev_get_drvdata(dev); >> + int ret; >> + >> + for (unsigned int i = 0; i < dmac->n_channels; i++) { >> + struct rz_dmac_chan *channel = &dmac->channels[i]; >> + >> + guard(spinlock_irqsave)(&channel->vc.lock); >> + >> + if (!(channel->status & BIT(RZ_DMAC_CHAN_STATUS_CYCLIC))) >> + continue; >> + >> + ret = rz_dmac_device_pause_internal(channel); >> + if (ret) { >> + dev_err(dev, "Failed to suspend channel %s\n", >> + dma_chan_name(&channel->vc.chan)); >> + break; >> + } >> + >> + channel->pm_state.nxla = rz_dmac_ch_readl(channel, NXLA, 1); >> + } >> + >> + if (ret) { >> + rz_dmac_suspend_recover(dmac); >> + return ret; >> + } >> + >> + pm_runtime_put_sync(dmac->dev); >> + >> + ret = reset_control_assert(dmac->rstc); >> + if (ret) { >> + pm_runtime_resume_and_get(dmac->dev); >> + rz_dmac_suspend_recover(dmac); >> + } >> + >> + return ret; >> +} >> + >> +static int rz_dmac_resume(struct device *dev) { >> + struct rz_dmac *dmac = dev_get_drvdata(dev); >> + int errors = 0, ret; >> + >> + ret = reset_control_deassert(dmac->rstc); >> + if (ret) >> + return ret; >> + >> + ret = pm_runtime_resume_and_get(dmac->dev); > > If this fails for any reason, the next suspend still be called and it will decrement the counter, potentially undeflowing it. > Consider switching to pm_runtime_get_sync(), which suits better here I think runtime PM usage counter underflow will be the less significant problem in case runtime PM fails. Anyhow, could you please provide the code pattern you consider would be better for both suspend and resume? Thank you, Claudiu