From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (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 98BE33624BF for ; Fri, 6 Feb 2026 09:58:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770371937; cv=none; b=iKSomcSvrp63l+AgCNUnd8MmAwsB3XvQ4uGVAOvN+XatEO8pmdbitPTuLXiS3jimeAjct0vNqVGiGFhApA6EAp4WIAZLOXhqdPP1Hu5JlIltjiq5XT39uDnY0H/sVC7Pzv1u1iBfI6o+Ixb9gY/BcYJ2A+Ds0iTPgPY3EdrHpzc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770371937; c=relaxed/simple; bh=jEHVM2uAFpnYm9PtPyvn7k9l3RglrtAY0EfiLY0es90=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=pVMe3qWufPz9UlGg/0h/MagCGiATqAFPO2gO7+5wiivlv8UuIWjEC3F8etgulIwnAyY/Lb9XvVjoX8e1Lmy71ZZF8EXKvSBskiqx67AXq9Q1NjjSE9g/3KRJm4o967oUdlJJZbVvRok4AR0vdRKodT9mbaSsJ7LbCZmhg2q2J5Q= 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=ftapXC+n; arc=none smtp.client-ip=209.85.128.48 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="ftapXC+n" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4801d7c72a5so4505885e9.0 for ; Fri, 06 Feb 2026 01:58:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxon.dev; s=google; t=1770371935; x=1770976735; 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=QFozp/2BFyrawQi8Bi3WGk4TGqqtNng52TReapzy6oA=; b=ftapXC+njD6iuyDVMsjMkryPKO2duqrT+B6YKm8HS8w99MlkEtN9NyOWxN+d+qRc7v wxNZ9xXOpsjCKQ4celJ85HAqf0FG2N3QyF74MMY+Oeu4/txiK4Uv+XgJ4bdNLdH8YAX2 tVQYydeLypiNdS9TTVZ1x8lzZtxD14MIx6jWw+2d0pIWnAAktSrcauSvTeQnm5SXSZbO y1C7y0/68C1A+FjvzNwnsEKuiB5h+FRjNURq+CnCW7xEhEQVvayHjHiPW1AO38V/oKqp ArkzJENwcveQIx4hJYGtBcSpgQWMO0xQgul6o8aknfs2rWwPECaEv7izA/pjSW4qq24P MPNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770371935; x=1770976735; 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=QFozp/2BFyrawQi8Bi3WGk4TGqqtNng52TReapzy6oA=; b=MmFcLibFYCtI6KaN1lCqbZgxiY5VBHT5l1DuitAupvQAzZFtEqNXUJpHvvkNDHw7aG NeJWqod6MUljuiPL3q5PvB4rql0eqRss/AEXxz775zDQBcac5Tr4YgcErlxymx7mXPW0 RNwJ7h8SgX59qpvulNXFzWzFW6RGc3BThpDVY7EC8dTPZNHbG+ZvRpfccIdSRjgtOHe9 XK91Y4hfajfS+Ow0+SQHmkyGU9aEXIWL4sEZyqiOR1+Y6tQogRoqfBk66bSA+eZEs2Sl YIvIhCeLqnnbII0KOTAx+85/8ZXt1Fm88wh5pVgvzzjSGn2jULnk6Chq3XZsdZKKeRP2 Z8Lw== X-Forwarded-Encrypted: i=1; AJvYcCU0XxKD8esjrEC+d+oqJG1M7YZNQKpsjKzK9hiuwOSGDH1LYBeuQT9WfqnRY4Qae0X4GIeRuJaizduYCLo=@vger.kernel.org X-Gm-Message-State: AOJu0YxMVjeDOekWb4CuOhmRWWJ0+eRkcAn9I5Qe15dHgunqFAi5yLT1 8/0j2KUaSNfd9fd9XSTfaSjq84QIaD6RFWj6x4qzZTx7mS9X3QmoIem6qZg9TdBq8nA= X-Gm-Gg: AZuq6aKoRdnk6634zE4VmnQd8maq9C/MFpDlBwTqDlxI4hkWzjsiD7L7YJ5lyb8ObxT Pp2CAQWR0M0V5v8n1WQee3lJYi+ekBA4NahbwYgxnQLYwPh3x+nPGufhSRzC0cjRK8IHS6y3CIc muAqs6Y0M0sPCqBEAQRKdG9GPES9IrDw7M3EVRDfj+4qfBbq2hB82tYyEpN6GxY9Z9MOXRUorwT GC86ik/9EdUTBykTpD0h4nrSaKThdfkv5Db+5oBA3uv/dLlIljqJyiza+S95oSjgnTyNt6QuGbb AZ0WC9YXjKAmOb8Uw+9mqEQvgPQrSdPAZj9PYBravNCp3uZq1Bt8kE9Wo9ZQnFl5ngo5H4NyEt/ oBzpxD+Rf5QMva0CLK36yPZtcTLBE2Hbty8sCQIhrwp5ex+xtAlVXm/xV/OV5XOPsupp70W7f2F 4XWjdW2DipBI/DYzkPDGQ= X-Received: by 2002:a05:600c:470c:b0:477:7ae0:cd6e with SMTP id 5b1f17b1804b1-483201daa3amr29029995e9.5.1770371934663; Fri, 06 Feb 2026 01:58:54 -0800 (PST) Received: from [192.168.50.4] ([82.78.167.215]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-436296c0f2esm4622854f8f.19.2026.02.06.01.58.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Feb 2026 01:58:54 -0800 (PST) Message-ID: <4dd522fe-8143-4423-b428-2774a185ad73@tuxon.dev> Date: Fri, 6 Feb 2026 11:58:52 +0200 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 5/7] dmaengine: sh: rz-dmac: Add suspend to RAM support To: Biju Das , geert Cc: "vkoul@kernel.org" , Prabhakar Mahadev Lad , "lgirdwood@gmail.com" , "broonie@kernel.org" , "perex@perex.cz" , "tiwai@suse.com" , "p.zabel@pengutronix.de" , "geert+renesas@glider.be" , Fabrizio Castro , "dmaengine@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-sound@vger.kernel.org" , "linux-renesas-soc@vger.kernel.org" , Claudiu Beznea References: <20260126103155.2644586-1-claudiu.beznea.uj@bp.renesas.com> <16a6f14a-93e6-472c-8718-d46972f0ac5e@tuxon.dev> <5438ccc8-ed5a-4dd6-8995-e8e9926883a5@tuxon.dev> <7f0305f6-ae2d-4069-b53a-d2a81e75d164@tuxon.dev> <32ea84f2-621a-47d9-a661-9acd62d50662@tuxon.dev> Content-Language: en-US From: Claudiu Beznea In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Biju, On 2/5/26 19:41, Biju Das wrote: > Hi Claudiu, > >> -----Original Message----- >> From: Claudiu Beznea >> Sent: 05 February 2026 17:21 >> Subject: Re: [PATCH 5/7] dmaengine: sh: rz-dmac: Add suspend to RAM support >> >> Hi, Biju, >> >> On 2/5/26 16:06, Biju Das wrote: >>> Hi Geert, >>> >>>> -----Original Message----- >>>> From: Geert Uytterhoeven >>>> Sent: 05 February 2026 13:34 >>>> Subject: Re: [PATCH 5/7] dmaengine: sh: rz-dmac: Add suspend to RAM >>>> support >>>> >>>> Hi Biju, >>>> >>>> On Thu, 5 Feb 2026 at 14:30, Biju Das wrote: >>>>>> From: Claudiu Beznea On 1/26/26 17:28, >>>>>> Biju Das wrote: >>>>>>>> For s2idle issue on RZ/G3L is DMA device is in asserted state, >>>>>>>> not forwarding any IRQ to cpu for wakeup. >>>>>>>> >>>>>>>> For S2RAM issue on RZ/G3L is during suspend hardware turns >>>>>>>> DMAACLK off/ Asserted state. Clock framwork is not turning On DMAACLK as it critical clk. >>>>>>>> >>>>>>>> Can you please check your TF-A for the second case? First case, >>>>>>>> RZ/G3S may ok for reset assert state, it can forward IRQs to CPU. >>>>>>> >>>>>>> Just to summarize, currently there are 2 differences identified between RZ/G3S and RZ/G3L: >>>>>>> >>>>>>> SoC differences for s2idle: >>>>>>> >>>>>>> RZ/G3S: Can wake the system if the DMA device is in the assert >>>>>>> state >>>>>>> >>>>>>> RZ/G3L: Cannot wake the system if the DMA device is in the assert state. >>>>>>> >>>>>>> >>>>>>> TF-A differences for s2ram: >>>>>>> >>>>>>> RZ/G3S: TF_A turns on DMA_ACLK during boot/resume. >>>>>>> >>>>>>> RZ/G3L: TF_A does not handle DMA_ACLK during boot/resume. >>>>>> >>>>>> I'm seeing at [1] you are addressing these differences in the >>>>>> clock/reset drivers. With that, are you still considering this patch is breaking your system? >>>>> >>>>> Still, thinking whether to add critical reset or go with SoC quirk in DMA driver. >>>>> Some SoCs need DMA should be deasserted like critical clock that can >>>>> be handled either >>>>> >>>>> 1) Add a simple SoC quirk in DMA driver >>>>> >>>>> Or >>>>> >>>>> 2) Implement critical reset in SoC specific clock driver and check for all resets. >>>>> >>>>> Is simple SoC quirk in DMA driver, something can be done for RZ/G2L family SoCs? >>>> >>>> What if the DMA driver is not enabled? >>> >>> The below use cases will work (patch[1] - removing the code for >>> deassert in cpg_resume) as there is no DMA driver to assert the reset. >>> >>> 1) system will boot without DMA driver >>> 2) s2idle will work as there is no DMA driver to assert the reset. >>> 3) s2ram will work without DMA driver. >>> >>> If DMA driver is enabled, then there is an issue with s2idle as DMA >>> driver assert the reset and we cannot use serial console as wakeup >>> source >> >> I think we're taking here about both DMA clocks and resets. >> >> What if the DMA clocks are declared critical in Linux and clocks and resets are not handled by >> bootloader in probe or resume? Who will restore critical clocks? > > Patch [1] will restore critical clocks. >> >>> >>> One solution is SoC quirk will prevent assert/deassert of the DMA >>> reset during >>> suspend/resume() for affected SoCs. >> >> This can't work w/o taking care of the DMA clocks in the clock driver resume function (in case DMA >> clocks are critical). If so, why handling DMA clocks and resets differently? > > > What will you prefer > > a single check in suspend/resume of DMA driver? > > Or > > Around 100 checks in suspend/resume in clock driver for checking critical resets for skipping DMA reset? I see no conditions in your code. Just raw writes for DMA clocks and resets. I suspect the intention for v2 is to loop over all the resets in the resume path to find the critical one. While reviewing it I asked to avoid asserting the DMA resets on reset assert API. That could be handled either by adding the concept of critical assert in the reset driver (or framework) of by just checking directly the reset ID to match the DMA reset ID (as this is the only critical reset identified at the moment). To answer you, my personal taste would be: - to handle the setup of the critical clocks and resets in a single driver, for probe and suspend/resume as well - to handle it in a SoC specific code as this is micro-architecture specific issue; this problem is only for some of the SoCs, if I'm not wrong; the manuals for some of the SoCs using this DMA driver states the following (RZ/G3S HW manual, Rev.1.20., chapter 8.8.1): In addition, need following register settings *even if DMA controller is not used*. ● Set CPG_CLKON_DMAC_REG register to supply a clock for DMA Controller. Refer to Section 7.2.4, Clock Control Register DMAC_REG for register detail. ● Set CPG_RST_DMAC register to release a reset for DMA Controller. Refer to Section 7.2.4, Reset Control Register DMAC for register detail. Geert, Vinod: could you please let us know how would you like us to handle this? Thank you, Claudiu