From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 3B5683AE1B4 for ; Mon, 20 Apr 2026 14:37:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776695847; cv=none; b=cMR5XLVGkent36GMhDcwH5YSsGJ+aKEWYtP5FUvztUNfn4KKyiEuji8Hc48Dk88eGYwvf1MsGZLO4YYxpCJUksFHfkz29tV7IzKUx2idUKo33gWf9X9N+NNs54tMx9JpTALB3JNRFaFRCULGtIL2pR8zSlH8uZVbTSRxPy5mzhM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776695847; c=relaxed/simple; bh=G43em0UTQ2JQXzJA76cdqW6wsnO4G8o1Mo5P6nGZgPo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Ue3erPrxArT1X9cove2Ho9AiHNHQJtb8GEC+8+pOyzIJ2FAicS1MDaVwFg0RbYibkspcgTnrrn9qHqbhjcsIZPGBJoY8LKRK4PjjBxeVjoKeGRUXFQvP2JOKYPNgOQXTxfJFFJVZV1rQNleJCUz/0qlTUGZiizXLnWpufHMCKJk= 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=Z1ad9HW3; arc=none smtp.client-ip=209.85.128.43 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="Z1ad9HW3" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-488a9033b2cso35524075e9.2 for ; Mon, 20 Apr 2026 07:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxon.dev; s=google; t=1776695844; x=1777300644; 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=P2uTS1FpJvpBuQ/f8W19roBhKwBLhDMKvzjCC/g1ICM=; b=Z1ad9HW3b0ftwI665ozfA7pOvAv/MixGYv/maWoHIEqxhvnBU0SzMrxmu9s2QN+qln iyWsKOc7JhZ28n/TmoqfF81rocMwYRRWix0jHEyDkZ2QiMWfOXMsEOfmHZV4Sw0wLZbZ O67u2MVUmz1Ez2hsVTzOru86X6Pif0vlP8IjVzM0RRDDLoLUeCqemOQbNDaAMcbZwe1/ 2twhgk6HuVDE8Np5FcVpJfgMDvvd1AanT4gdLw4is9Y5fI/0zYajGEoEzgfSGEYrqTj4 Rd31hcC4oZ6JR9C+/zcE/3GwDq25NYH3ibyZ08JYqYAnSvd5T4IymwyMEpsbqYv5rWG+ 5KYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776695844; x=1777300644; 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=P2uTS1FpJvpBuQ/f8W19roBhKwBLhDMKvzjCC/g1ICM=; b=hL1Jhhfeffk2RDEbvyoMiJhzxdQip/VihTKcjByA+I7K5vVRRbmoWDKv3lP36szwJ4 DWnObcjgO5us+3GF+oKTRcHx4pQYL1xtwQ8QbGrkUSqQISM1ptd+zIULpzLltBAsm10R YwxHU/bqVK+WpJAFYzaCiqq5SBCT8D8ItFEbNXs6vmEccyH7D4Jfph3Mshsu6niYjzZl 3iEPOpSopErAaPRzRZ3OrEh0kwfmJ6AD/RAsQFI5vfoQv2St1CCpktyrj0tukZdT/t8T Lqlb5wBwhzTPsjn2DNxzv+H6jX28zl0Y5Moc44IWH6qvqAOM98A61tk3pJGwn7MRp2z8 psqg== X-Forwarded-Encrypted: i=1; AFNElJ/RNFtPPXtLP9fA+R8jDEfBsHWc+BpvsxkE8oNCX5M6Vs16dWPqp9QXjZ61816BvytKk9qpL4PZwrEGxME=@vger.kernel.org X-Gm-Message-State: AOJu0YwzM09JY3JPPEt+DcDze8PRJgmqdhGOp3sUF9A3bDHvLYduDNlR 3LJc2+WjnHl/HTE48RS9tFuzZtGPcKKk3AjBGDHpYuN4anTeGhXLLtqSdlE7977uwo8= X-Gm-Gg: AeBDies4NywimZZuYIpTvxsXhtDLsV3V+j917dESrfzWX4smsTIaVzyMwP3iaREh8v0 gXZfOM7LZ2gWpYyMTdP8yHRhwIzrCLxVWxkbLVo0QaR3dkurTI2/F7iw6nxSp8qrJWNgsWOS9NG H85jLVSF3p9xjpf6tHBBtf380Qr6BXQgNIk07kzcYSsm5o14S1uyFS8CPBWjR1Flq77WBJD9A0G TP3rYmofpnAgjHak5QlXkmnHnIm/wuzFqd6QZFujeVnu07AlNa2dcor11C50FGoYrXbUU1/y4A+ ZB/Cw8VpJGY77cQFnVtwxE+/STfilDdPPPsglDx0x6Gr+fBfcDGsTdFYfe7Kd5zE2+/u2PwPFZL xLDzYfUwMzieG12csfJsyBPtxb0tD/8fmDdA7PnM6o2hVemvoguSX9MEH5u7Tj1uUz6fcZgZJ3e LTsn6Wq9Lu4tETDooX9dtUENHNvsLNtUo6CoZdWg3ugw== X-Received: by 2002:a05:600c:1385:b0:485:4eaf:eb54 with SMTP id 5b1f17b1804b1-488fb78260bmr187342395e9.20.1776695843391; Mon, 20 Apr 2026 07:37:23 -0700 (PDT) Received: from [192.168.50.4] ([82.78.167.123]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488fc14a61asm271273795e9.15.2026.04.20.07.37.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Apr 2026 07:37:22 -0700 (PDT) Message-ID: <2d055792-c8ad-440e-8fe6-68b75832e30f@tuxon.dev> Date: Mon, 20 Apr 2026 17:37:21 +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> <36468f41-7808-4fe3-b4bf-94eb128276fc@tuxon.dev> 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 17:21, Biju Das wrote: > Hi Claudiu, > >> -----Original Message----- >> From: Claudiu Beznea >> Sent: 20 April 2026 15:15 >> Subject: Re: [PATCH v4 14/17] dmaengine: sh: rz-dmac: Add suspend to RAM support >> >> >> >> 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? > > > system_resume() > { > pm_runtime_resume_and_get() --> PM counter is not incremented in case of error > } > > system_suspend() > { > pm_runtime_put() --> counter is decremented and prints a noisy WARN message > } > > Just replace pm_runtime_resume_and_get()->pm_runtime_get_sync() > this will return the error to caller like previously and also increment the counter > which avoids warning on the subsequent suspend() This wouldn't solve anything. If the newly added pm_runtime_get_sync() fails the next dev_pm_ops::prepare() call, accesses DMA IP registers. That will sync abort (due to MSTOP) even before any warning (I guess underflow runtime PM usage counter) will be printed. If we add runtime PM resumes in the dev_pm_ops::prepare() to overcome part of the sync abort in the next dev_pm_ops::prepare() call and keep pm_runtime_get_sync() blindly, w/o dropping the usage counter on failure, that will still lead to sync aborts, because the runtime PM resumes in dev_pm_ops::prepare() should only increase the runtime PM ref counter and return success. Thank you, Claudiu