From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (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 33FF33DDAFF for ; Fri, 17 Jul 2026 11:40:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784288419; cv=none; b=KocRSrcoZz3cA1ulzrsKqmv0Mo8Qpeo32rYo84wS5Uq0HXK7ydL8vBfExv4PbrKvLI6NIwA8uiTQMD13bR7OYKxIfXlYhjGyZwAO+z7EqJmejC+Vwg/3HfpzmozvNAkAqavMm6DPytuA3M1nPci+z02kgTXbIrLP++HoNn0qH/o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784288419; c=relaxed/simple; bh=0M54LK+e+ZsqutDKWxmQf1vKliGbRxbhOcJFvzG1A0g=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=DMX2n7Xeli91t8iTJFvrjoh56Rhs3jYriAM8mahQvZgfYo2beUzg3iqaC5ySUNBFy7e9VYq98Kr64/owguTxAIC4oWo7QUjziz1zcHwAOmpD4K6mjiyeodMtXSigkVM6oXbhb9WBsdQNkvYnyexvBRd/T73OlHtRSu8iHWey88M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=a2v8hqQK; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=DxRtHT6a; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="a2v8hqQK"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="DxRtHT6a" Received: from pps.filterd (m0279864.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66HASaFc1191092 for ; Fri, 17 Jul 2026 11:40:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= KXuugUouKlB/CUW4LY6w9L6J1o6zPDA0wz2TTB2Kat4=; b=a2v8hqQK+5NFF89D 97D6u2gu1GhLs3KiOzhJ9ucraCDlBeBTtrCFilTzkcsuq9OcGN9kl9X0Up4NKBW0 k8plGKaONU2Bzc6E1gTHBP91QyRnTHCCKPUs7Eocnr7Lw/AYnrWS8mWgabM3brTf zNzQfLgUss/CGIKIpFSeoxa5zrxGstJ0SuHwOhNKlxP+dS73z/EQae0t3glkeB9f 2yO4euksQGEzVf/SST7/9nJAgB6TdMC6y1iWmS/hunc/ene9xhV9+RTFBFHUlYqd cLZIT408D4tIFli89y1czok8b1kU2nzfSKyDjgwSyDMlN1joZXxW9XCuCDxt+qvJ rrlsCw== Received: from mail-pf1-f199.google.com (mail-pf1-f199.google.com [209.85.210.199]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4ffj78rawc-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 17 Jul 2026 11:40:16 +0000 (GMT) Received: by mail-pf1-f199.google.com with SMTP id d2e1a72fcca58-848662cd2a1so4988125b3a.2 for ; Fri, 17 Jul 2026 04:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1784288415; x=1784893215; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=KXuugUouKlB/CUW4LY6w9L6J1o6zPDA0wz2TTB2Kat4=; b=DxRtHT6aTCKz8ZLtUkQd470zukEParciOXAQOy7oyXSPFiinUs5pfoTizpWBiEYW66 RDNAPr2oXOcwOa510KS0kRx5gseHmWDNpv0KkqZDgD0k8vygHB/VoBaJQSoUovNvW3Qg ybNRsabTLijuEfGWSDsEwsHHMlQepaXdPcbDxBSAyZUUGxiOjzpXxtKWxHw9/YXC7P3z CcWYcQqkG+mdlepMZdPOSS0zox9tBNzKkWF1z6+MqU1MGwFpa0q7fL6ZiXSSi3G65ywY 6FYasyAlm4OpSEt3ZjIpZY9+oZxm3bSbir//WYabpWkMCyEwzLUOVfT5q+dAsKXDnwuU JlMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784288415; x=1784893215; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=KXuugUouKlB/CUW4LY6w9L6J1o6zPDA0wz2TTB2Kat4=; b=Up9ifaN2082JYFN0YBU0L1NWO3eq2MZFqLCnbAY7+EpSlQ7JGEeV+Ygb0BzwyvEOAG pKXlbdaAqFj4Cpp/1NG4yjJ2Hs5oa6EmxwM0Poyrvy1Yw0gRk1gOdXjB0/oH4Iu0o4Js zQPsIVNgDxqjO9E8T9WEWu9myPKcIZaWfpHRVPD9v97c7Y7zs0TKxbGdFJO7s761z25I jYSjPpqqOFEO0OWqQ6X2hdWdaoObOabdHO6iSxciAxe76inncP5jVcBeuhb2XcbIYjm/ S+pBTsRZaOyP+nJT39ts4sS8lhueu6BMYr7aGlUis95pa3qIyDQKBT38EiUaEaaFTm+C V+9Q== X-Forwarded-Encrypted: i=1; AHgh+RrimwxsBKgLuRK+hITbjgecCZiap11n23wUSWcYnBpC8dW9M9pvDYwjqYwr6aAzXiNUtnXfDOHkgopX99A=@vger.kernel.org X-Gm-Message-State: AOJu0YyK9fZYce5VBYWCrC2Ji662V8D9pniMI5d3PHBdzRlCg9NVCG4D gP/Pdr6MhrOgssSn06brITDYB6A+oY7d/vCKqUbqRT5+EdfrW0szkcqVEq0T7hf2SlcZIxB3qEJ jfNJC33DMVReVWV7VUmWZhoecg1f/U49T8d/62nQiUnSNvEZf7mojrP3EjpCE2KSRJjk= X-Gm-Gg: AfdE7cl3d+5oswb0UTtfFPN5FeDzDsRlUIlmEoAonCrDSbfAjKPdNCrittjxvstsLxH Kzlt07olwRMgjzNlK2xRYCNoi7jQ1mbkSWjXGkya4bID1/sU02sjjpI5i46HMmVKv1XeKQFEhgi ee0i55SlSwwXCBF91yVhnmPRfZsHwZwPrXg5vX2huBKLTs1hltYfEPsR+RmG4pTs/Di2FTwfwuf L7FoafC3hifkCgZsu8nL0GgbCkMyo2qeAdvzVgrzVDYYbuQOehR8shl7s4WeM4OKWUTte7Ji+Sx j0VBYe+PhizTeS03j3KjoM0a7qGKrtYyJDkwKFey3XwZGZWBTtzbCPBQEtCpTDbFi4F9aOLYbTd L93JoDnQcy2UVgDC4Kdv7zLSjOQhS X-Received: by 2002:a05:6a00:80a:b0:847:97a4:d6b3 with SMTP id d2e1a72fcca58-84c2922630cmr2362993b3a.16.1784288415360; Fri, 17 Jul 2026 04:40:15 -0700 (PDT) X-Received: by 2002:a05:6a00:80a:b0:847:97a4:d6b3 with SMTP id d2e1a72fcca58-84c2922630cmr2362945b3a.16.1784288414707; Fri, 17 Jul 2026 04:40:14 -0700 (PDT) Received: from [10.218.33.224] ([202.46.22.19]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84c2af317c8sm859795b3a.30.2026.07.17.04.40.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jul 2026 04:40:14 -0700 (PDT) Message-ID: <2c21041d-f84c-4fa7-a977-555f9203d8b5@oss.qualcomm.com> Date: Fri, 17 Jul 2026 17:10:08 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Bibek Kumar Patro Subject: Re: [PATCH v3 3/6] arm64: dts: qcom: kodiak: Add GEM_NOC interconnect for adreno SMMU To: Bjorn Andersson Cc: Dmitry Baryshkov , Will Deacon , Robin Murphy , Joerg Roedel , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Konrad Dybcio , Rob Clark , linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org References: <20260706-smmu_interconnect_addition-v3-0-afdca0125a65@oss.qualcomm.com> <20260706-smmu_interconnect_addition-v3-3-afdca0125a65@oss.qualcomm.com> <807f145d-88d3-460a-9862-b63fe2a52cf7@oss.qualcomm.com> <4e5a3d82-b946-4490-885a-ea7061939c32@oss.qualcomm.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzE3MDExOCBTYWx0ZWRfX5D8RBjB0nLuz nALYD7uVcUKFHW75gUNXrUS6V3ar8aEKsYF68OTJwF23k+i/4YV9isVVaTJvQbSt3j1W228siEb 0bcK+XrdoymTPCrkm32+W1PNCT6UCGvoXN9Q4NWcEGchd8bPm5ybkisTDrcG65GSNNX/PZ6pu/Z uAKuxunaZAUUZzrYwbM5EVhr3/GXwJNo4nK+33ACTXgtV/IsPv12BlfYvr3qhAtBByO/Q4i5xUF 0c3f0C/7Z6E96J9GkabXP758a0wULyaZeMibjpO/yxj/qQ9I8XeSg4oYi9eTyxE5wnjTwm7u5+Q zNThKaVa6k8f+cncIXmI6h0M5tFhyJLRo3vI8jGWPEb8CtlhpZMxynEA4sH6pn/eSEgUe5jNRPO wMMdULXmRmhv0omdawIfig4CrvnYtSCbnCNrrAJyMokcF+tkupmibjvb/5mAxOxMXc9xEYYO+bv WdSem+3/RiOEZNI8F2g== X-Proofpoint-ORIG-GUID: I7mgPK9t850wzjTDusqwgBbTuCGsfHBU X-Authority-Analysis: v=2.4 cv=U9Ciy+ru c=1 sm=1 tr=0 ts=6a5a14a0 cx=c_pps a=WW5sKcV1LcKqjgzy2JUPuA==:117 a=fChuTYTh2wq5r3m49p7fHw==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=DJpcGTmdVt4CTyJn9g5Z:22 a=VwQbUJbxAAAA:8 a=EUspDBNiAAAA:8 a=qc56rwwszmrP7wb0vM8A:9 a=QEXdDO2ut3YA:10 a=OpyuDcXvxspvyRM73sMx:22 X-Proofpoint-GUID: I7mgPK9t850wzjTDusqwgBbTuCGsfHBU X-Proofpoint-Spam-Info: AW1haW4tMjYwNzE3MDExOCBTYWx0ZWRfX5hck0T5reo9c ChhWo+9D8qN+wRI3FOjSPHxurLK9i4O9PaT/AaeyAfUq8eTOrLPVgo461LKVxxRz1nBh6kNPjGT 9tOMGMI0g53Z6kuOiFSgdxX1xx7VumM= X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-07-17_03,2026-07-15_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 suspectscore=0 phishscore=0 spamscore=0 lowpriorityscore=0 clxscore=1015 priorityscore=1501 malwarescore=0 impostorscore=0 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607170118 On 7/8/2026 8:56 PM, Bjorn Andersson wrote: > On Wed, Jul 08, 2026 at 03:31:07PM +0530, Bibek Kumar Patro wrote: >> >> >> On 7/7/2026 10:14 PM, Dmitry Baryshkov wrote: >>> On Tue, Jul 07, 2026 at 06:37:24PM +0530, Bibek Kumar Patro wrote: >>>> >>>> >>>> On 7/6/2026 11:12 PM, Dmitry Baryshkov wrote: >>>>> On Mon, Jul 06, 2026 at 10:26:36PM +0530, Bibek Kumar Patro wrote: >>>>>> On Kodiak platforms, the Adreno SMMU requires a bandwidth vote on >>>>>> the GEM_NOC path (MASTER_GPU_TCU -> SLAVE_EBI1) before its registers >>>>>> are accessible. Without this vote, the SMMU may become unreachable, >>>>>> leading to intermittent probe failures and runtime issues. >>>>>> >>>>>> Add the required interconnect to ensure reliable register access. >>>>>> >>>>>> Signed-off-by: Bibek Kumar Patro >>>>>> --- >>>>>> arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 ++ >>>>>> 1 file changed, 2 insertions(+) >>>>>> >>>>>> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi >>>>>> index 90e50c245c0c..721526f023dd 100644 >>>>>> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi >>>>>> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi >>>>>> @@ -3389,6 +3389,8 @@ adreno_smmu: iommu@3da0000 { >>>>>> power-domains = <&gpucc GPU_CC_CX_GDSC>; >>>>>> dma-coherent; >>>>>> + interconnects = <&gem_noc MASTER_GPU_TCU QCOM_ICC_TAG_ALWAYS >>>>>> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>; >>>>> >>>>> Why is it ALWAYS? Would it be better to declare it as ACTIVE_ONLY and >>>> >>>> Added QCOM_ICC_TAG_ALWAYS, to hold the vote in SLEEP bucket as well >>>> preventing gem_noc going to sleep when icc_set_bw is being called. >>> >>> _why_? >>> >> >> Now when i think of where we implemented the hooks, ALWAYS is not needed. We >> should keep it ACTIVE_ONLY since we are already voting it >> back in resume pah. I'll fix it in next revision. >> > > The path is between the SMMU and DDR, so clearly it has to do with the > TCU's ability to fetch things from DDR. > Yes as you rightly mentioned, this series is helping to resolve the race in TCU DDR clink > ACTIVE_ONLY states that the vote should only be applied when the > application subsystem (CPUSS) is not in low-power mode (CPU is active). > > So, are you saying that in all cases that cpuidle might select such > low-power state the GPU TCU is "stopped", and does not need to perform > any memory transactions? > I rechecked the architectural block diagram, GPU TCU is independent of the CPUSS, unlike system TCU. This means CPUSS can be powered down while the GPU TCU remains voted up. While this series was intended to avoid a DDR voting race between the GPU TCU and its clients, using ACTIVE_ONLY could have possibly introduced a race between CPUSS and the GPU TCU itself. Thanks for catching this in my reply Bjorn. ACTIVE_ONLY would have been suitable for system TCU (apps_smmu) for which the interconnect field is anyways not needed, but unsuitable for GPU TCU. > > To me these two are orthogonal and TAG_ALWAYS is logically correct, but > perhaps there's some practical dependency that I'm missing? > We can ignore my acknowledgment [1] on previous response, Dmitry. ALWAYS TAG is correct here instead of ACTIVE_ONLY in the interconnect field for adreno SMMU. [1]: https://lore.kernel.org/all/4e5a3d82-b946-4490-885a-ea7061939c32@oss.qualcomm.com/#:~:text=Yes%2C%20I%20think%20we%20should%20go%20with%20the%20ACTIVE_ONLY%20flag Thanks & regards, Bibek > Regards, > Bjorn > >>>> >>>>> then drop the extra suspend/resume play? >>>> >>>> Not sure if I understood it correctly. >>>> Did you mean the extra suspend/resume play in arm_smmu_runtime_suspend >>>> or in arm_smmu_device_shutdown() path? >>> >>> runtime_suspend/resume. I might be incorrect here, but I think it is >>> exactly what you need. >>> >> >> Yes, I think we should go with the ACTIVE_ONLY flag and we would need >> this voting in suspend resume path (For the same reason mentioned in commit >> description and cover letter of the series). >> >> ALWAYS would avoid the need for this handling, it would keep the vote active >> unnecessarily, but still that would have been nondeterministic. >> >> Thanks & regards, >> Bibek >> >>>> >>>> Thanks & regards, >>>> Bibek >>>> >>>>> >>>>>> }; >>>>>> gfx_0_tbu: tbu@3dd9000 { >>>>>> >>>>>> -- >>>>>> 2.34.1 >>>>>> >>>>> >>>> >>> >>