From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 8FC653624B1 for ; Fri, 6 Feb 2026 09:58:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770371937; cv=none; b=F+bY296F/CPbm8NuxkxhuYzcynODB2Lc9IkJZOkulQimn9hQfF6XmlD+7SzmBVjn9mOAXfUUXq1yJ5Wllt3lOBrJQSbR6N9NOFxOtYaaCuwWTN7N7iYCvoSVCjKiFH8HG5Mqfjg6qNDKoq4YYkHyd/sSpDbUjO7L8Arieim9KXY= 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.50 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-f50.google.com with SMTP id 5b1f17b1804b1-48327b8350dso1725515e9.1 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=K+YfeCoJn21qKhIaU8/jWwQO0Ez9TbnfXHIIrqqa/jOqW6wQFk03syXOr+2Pdk6xxE mo/wui+FIVKKqvHkNBM+fNrBIItssfwIPxD7MShICVa8JjOoSwK6MRzTZNIAL/Cs+2vV TKOXhRt8ThRI5DoEqIIfLZN7k+Uili+eIhlDrgMp73SShvbXeryUwzysOw62uwdBtag/ dN65bYbsJFpD+7Sp9N+XpfmWGUsQiNxLo5vqpU7Y0ijdXiYgdt2x4mC40XjXCTBqWwMI NlGLFA3tJizkEFLaX6mfGdzXYX0SyTDbtvKXf9cFy3IwnB2+H0rnyOuh+EGldMLhyuUK wzIg== X-Forwarded-Encrypted: i=1; AJvYcCXcdmx42wt+zMwfyhPPwmNIbY/nkO9E7xVhSvnIv7yExMG++JhB8ryDXIM2CB1S9q7OTEyDKSxi4aUhQg==@vger.kernel.org X-Gm-Message-State: AOJu0YwtYKMdbuBukcmL6xm4hA5A2kc9dnLVN0kzm18uB8QUKSK/85RO Blewp15cW/ncQdtfZdkreHU7lqi70c+MMo+1oXmQMNOazrmwvsbfv4VUwgQCaRA3vZA= X-Gm-Gg: AZuq6aJfOAc7DVvCQ4aSqjO/SLoW+dtgwmRboI3G9jBBwbN7geQZb4xQBTLmlURmsR3 CcXsoZOLT82jYyMOmoumb/+aUC9pu/7wwxuluRpFHtiRyZO4orEYDC+MF7abgQ2uXtL17jiQWg6 fXxE4W7tgVqcFad3GCIfanY9R+wcPniNVuFJKbHmOfq819tLuYfd+3SrsnlCYVbzBRZHJMZImPl O0sorPWl9fco8ZOIPaJfr5QCXxSuifU5OiQ5yQYAdnUeZHb1tQ98zClgXx8NFvnzEVuDB4FzUf6 63l1cgTooxFi/5w5+wMnNq2w6BxI15BlFl9abmkJ0rif3FvNopyvCVu9een8HgQryL8aWOecqZS 8JG6yfkIHVNNzoFia34ygUuLclI968Uuo+UbLNXwhtcNvimVwRdknOCquKiW3IcmBkzQsYiL4Kd qQeDRSOC69TkVKx4cghL8= 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-sound@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