From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.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 3274A42E000 for ; Mon, 10 Aug 2026 16:57:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786381071; cv=none; b=DQFWuVp8UFn4Udat7KX/2tYCzOfKubhVSMKFc+uChO7VHQWGvJmHGqA/RqxBZOd29Li0y2a5E6/XNRaVe9+RWnSHt0xx5EIHKk9vMCdsc+Z+jfewvTN+rAMa8RfMR166ll8NGRdL+aO1+HSkLtrGnPTptwlGU4a8TVSUCjDtMqU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786381071; c=relaxed/simple; bh=ysfqfXPio134Qd8d8OvVqS8aWsQYJnFC+iPjlngYUsU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=VlM7T0A4IIoTjsUCj0e3Ku/zRnSBU0JrdyX012Pm8IzSO9eK1CRY2JBJ40o5PgCcyX+vX0DgdfLkOJcVKxrB0Dw790rHnf8TM9eDaeFhlQcOuglQmA9KlglpC98Csm5/Y+GE2OaVQgI5nyDZBk6yDwpawEzZQVN7daxA2ukB4yE= 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=M3KMeGL7; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=AkjA/TKb; arc=none smtp.client-ip=205.220.180.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="M3KMeGL7"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="AkjA/TKb" Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67AGstlU1936407 for ; Mon, 10 Aug 2026 16:57:49 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= QSdGRKjeM4r/MTfTpNKxuTG9yGYcCn3iH+71thLM5wQ=; b=M3KMeGL7JRfcGzyC YBsv9/wdmwMXNZDFVQEWvnLOzz+70kyIa4JgWuOzgZdm8F1IIttsHv7on5jZQAeA ZF+eTFY8DTRdqY6QpYfBYwA3EiE82puRfyAh8fCu2jr5DtfL6KfimpWSC6wuyv1u lS+TX6LwrvsamCqobC0O4UEjnJprnW+sObmzATvB6yL9z0jZBFG2juhGXkAuxsuY d9Qv06q8ws6c4JqoTStqzxT1OC3+rcEysk7+GDX5JsYt6DWBqkwV3V3Deo101uJr Xo4Md7Ka3nGyHg00QPUOTjbKISsQN+g1lEmlXXkX+CcOxIwqeu69icltusiUHY8O unIUFA== Received: from mail-pj1-f70.google.com (mail-pj1-f70.google.com [209.85.216.70]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fyjk600kj-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 10 Aug 2026 16:57:48 +0000 (GMT) Received: by mail-pj1-f70.google.com with SMTP id 98e67ed59e1d1-38dc085b0a7so3094273a91.2 for ; Mon, 10 Aug 2026 09:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1786381067; x=1786985867; darn=vger.kernel.org; h=content-transfer-encoding:content-type: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 :content-type; bh=QSdGRKjeM4r/MTfTpNKxuTG9yGYcCn3iH+71thLM5wQ=; b=AkjA/TKbp1NtSBE6+TEVAJRPJXb/p8yxXBS+ReBq5/ro7Fw6zUq1aH3rJDFqqGCYp2 bGY4NXXZE9/niQ8zHlQyZlXmA14gaJPGE2FM79f3uDeXXaPuvVYm3S2b8pctFLu7Fnks +zqwJsuSN54ALJUtgbxBYnX03gFxyhumgQiJFjsmPg9QrnxY7kMhHQ5+9KIeLZo+aeZF ZUozXq7ZNAgoJio6YnVKDQ6Ukil7EBLgR6niYCkvhaee04SjBbcnsrayks1/qKEgQN7Z qKNlUz8bBsDr3vi7oUTAhPnLx7fm1aYjbqh+ygl232DUdJt5yMFrNO90skznByTeD14Y GNgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786381067; x=1786985867; h=content-transfer-encoding:content-type: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:content-type; bh=QSdGRKjeM4r/MTfTpNKxuTG9yGYcCn3iH+71thLM5wQ=; b=e/fI6k5cFIjQ7N6th4mu5F9nl136e1O0t2/I1R2wtmY4/HO4A6T0yB8sFjBb1mWPXq bvAp+RsY2xZRoAjRV10QZNXsBPjccgG4JN2PNpVGJ7wdMhwOvZmqitjgADKDmCIdBllQ YTOX0q9l2X2sn+Qe5xcEEVbhCSj6akejkf3TkaRtuoVvYjjF7151q4VWwl3MNQSgis5C RxEufg1uDp9H7EkNYo9j8ii+KnRl0FItf5JE8BV8Boa8xJ29eCSzkeU9+9BzeAq35ONa rm1Lgp5B4fw6MMgdf3Dgq4WZJx2QBDP1U9ZEcdTuQQheS5tsAcXm4yGZyUS5omGRzdY4 zm/w== X-Forwarded-Encrypted: i=1; AHgh+RpDT61KHaJTMLRrqT9ZmJT5SQza48Fvfr0a95pxB6N8G8r1fxTsTgr1eMrxmBA3hxFPCcPUE0A8K/OVgrs=@vger.kernel.org X-Gm-Message-State: AOJu0Yy8NUkxkqx6GiH/7V6MUhPe8JaLZO8LTugaHN7SVkFqXKclAKny 3eQsBO0QvBOG3kHwQbrpEdHejBm24s3oltd01GDM6XIHmGpmmQhoci7Z8w867iVPlL0MZsssVUl uRARzZjpquWobmNbCs3lsuUc8YrUX79miK9IshTbVZKn+vbGC/tU7CI0qKXq8ltovOi4= X-Gm-Gg: AR+sD11tNxOizIH4vVFnyyvqEyOUx7+cocUeNt62XGT1dxkYguxW4VZeuHas+75oK0a xOd/90L55QeDjAF1O7P9+qMS8JSzG6b18lqWsylYXh8LbZak6PR8T3LUn5TC5hULMzGbj8772uh 6yv/FN16Kku9uzWdwGdP76EEL/ReEz4E3gPi9CMhVGC69JbLoftn1cJD7J3bfciDa4YWL8a92HH G70tXHqIpxCa34lcdNn3TYWbp3s0bKIbbtEBgo1N/KEREIVxJXM/DhIpzIcUM5Oq7mG+KfoXLQK JYBufYKBeSjapecEsEFm0Xx+ZAhY8OhzNT3SQS1vnQgC3VWGSOgQwz4t90ToywiSWH9qGxW/03q dr9Xz4+NdB3hqMQZPudMwq3MKlgeIVRbVQ/Q= X-Received: by 2002:a17:90b:3c0b:b0:381:3b5d:30f4 with SMTP id 98e67ed59e1d1-392cc8d0454mr3334177a91.1.1786381067396; Mon, 10 Aug 2026 09:57:47 -0700 (PDT) X-Received: by 2002:a17:90b:3c0b:b0:381:3b5d:30f4 with SMTP id 98e67ed59e1d1-392cc8d0454mr3334065a91.1.1786381066917; Mon, 10 Aug 2026 09:57:46 -0700 (PDT) Received: from [192.168.0.172] ([183.83.139.112]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-14101b7a772sm37165790c88.12.2026.08.10.09.57.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Aug 2026 09:57:46 -0700 (PDT) Message-ID: <7caa7fd4-6732-4c80-8b8e-a0ed99631ba2@oss.qualcomm.com> Date: Mon, 10 Aug 2026 22:27:31 +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 Subject: Re: [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris To: Dmitry Baryshkov Cc: Bryan O'Donoghue , Dikshita Agarwal , Mauro Carvalho Chehab , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Stanimir Varbanov , Sakari Ailus , Abhinav Kumar , Stephan Gerhold , Bjorn Andersson , Stanimir Varbanov , Konrad Dybcio , Johan Hovold , Neil Armstrong , Loic Poulain , Jorge Ramirez-Ortiz , Mansur Alisha Shaik , Andy Gross , Rob Clark , Stephen Boyd , Yassine Oudjana , Pierre-Hugues Husson , Marc Gonzalez , cros-qcom-dts-watchers@chromium.org, Matthias Kaehlcke , Douglas Anderson , AngeloGioacchino Del Regno , Aniket Masule , Malathi Gottam , Rajendra Nayak , Jonathan Marek , Dikshita Agarwal , Renjiang Han , Krzysztof Kozlowski , linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Bryan O'Donoghue , Mauro Carvalho Chehab , Konrad Dybcio , Krzysztof Kozlowski , Daniel J Blueman , stable@vger.kernel.org References: <20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com> <20260807-iris_iova_600mb_fix-v1-4-3996f67e33f9@oss.qualcomm.com> <27f0b033-e940-4369-aaa0-f08426aac73f@oss.qualcomm.com> <429d5d1d-92d5-4949-9991-b092cc7e9937@oss.qualcomm.com> <181b02e3-831e-4461-9327-ab5646380a10@kernel.org> <73b26356-8ccb-4a81-b626-a96de5b13173@oss.qualcomm.com> Content-Language: en-US From: Vikash Garodia In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authority-Analysis: v=2.4 cv=Nb3WEWD4 c=1 sm=1 tr=0 ts=6a7a030c cx=c_pps a=0uOsjrqzRL749jD1oC5vDA==:117 a=vZaankvBGbqXg3MvYcFdyQ==:17 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yx91gb_oNiZeI1HMLzn7:22 a=AauyIVVOzEBGxx0bfrQA:9 a=QEXdDO2ut3YA:10 a=mQ_c8vxmzFEMiUWkPHU9:22 X-Proofpoint-ORIG-GUID: lkZGXuotAXQ4zT_kAvnnF3GlYNVN2SXz X-Proofpoint-Spam-Info: AW1haW4tMjYwODEwMDE0NSBTYWx0ZWRfX32cVuUaHZUiE fk78OL043zZkpQThseNrmpHQdyy7QiA+397q1fRmDBZVOoxg4lT30QY4Js9qC2V3I1caPwe1oTP UwwspEiKwbIDevvI5N+fPYkG6YXUjGw= X-Proofpoint-GUID: lkZGXuotAXQ4zT_kAvnnF3GlYNVN2SXz X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODEwMDE0NSBTYWx0ZWRfX2KbiF3VAE0SS aiRy173Ls0lkyJ+1lqJ4PQwkwIW90KbKHdSrJ3sUoF+CCNQeRsiCITyHJKaozhyr1OIhyHcDqHy jJ2zYKCuaikWws2T2hIaWwHYZswtSuxGWlAVyrk+IJn7plTpYtwbwe2shfzZfpQCGGUHfi3W7SQ QrfqynB4HPdt//jEWyxPFPV8kK1Vs6GmSeGXJr6UpjlkLJcCsUklLR3yL0UZrC2e+PEnEprbsU2 1CW5tl+HQTeMPzrMha8/9ccwJPVc7EALDYYRV0wKEeWBBqqp2N4dPYZUWgdjVhT27NkdCUsgi0a e8EYJTuYDkbjmWt3PA/yM4DEaUG6OQjOzRIsGl2/FEXaAoXPJnhIS4SSpJWeiVxwu5X9qOca9+w jFWBJTtvLgP6v1PHsvdrlL0ywQ0kC2cqcBTcaudH0/x9Duqrev4X6M9YllOEs8DE70hfgLA1YPn Orloy+LasOV0p043Iuw== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-10_04,2026-08-10_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 priorityscore=1501 impostorscore=0 malwarescore=0 lowpriorityscore=0 spamscore=0 adultscore=0 suspectscore=0 phishscore=0 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608100145 On 8/10/2026 5:40 PM, Dmitry Baryshkov wrote: > On Sat, Aug 08, 2026 at 09:18:42PM +0530, Vikash Garodia wrote: >> >> >> On 8/7/2026 6:48 PM, Bryan O'Donoghue wrote: >>> On 07/08/2026 11:22, Vikash Garodia wrote: >>>>>>> I don't like the idea of this series, because it_again_ >>>>>>> doesn't tell us >>>>>>> the truth about the hardware. This typicall ends up with >>>>>>> bigger problems >>>>>> honestly...thats all the info i have about the vpu hardware that it >>>>>> restricts non pixel to DMA from the 0-600MB range. The same i have been >>>>>> trying for a year now >>>>> You are not honest here. You also know that there are secure streams, >>>>> which have to use their own IOMMU SIDs. And some of them, as far as I >>>>> remember, also have memory range restrictions. >>>> please read the commit description again, the answer is there. >>> >>> So I don't necessarily get all of the detail out of the commit log myself. >>> >>> Could you give some detail to address Dmitry's point. >>> >>> The question as I read it is - are all of the other potential SIDs >>> covered by this change ? >>> >> >> I get the query as "secure streams also have their dedicated reserve >> regions, so how does this approach helps" - This patch does not reserve any >> IOVA for secure streams, only the forward looking subnode can assign >> specific reserve for specific streams. >> The patch enforces a common IOVA across all streams, and is good enough to >> fix the problem we have w.r.t device reset. > > No, it's not good enough. It defines that both non-secure streams use > the provided memory range, it doesn't provide a natural way to later > _expand_ it to support secure subnodes, etc. > > We know that there is a problem. We already have been bitten by not > describing the hardware as is and using band-aids. Can we now learn the > lesson and write a proper hardware description? > >> >>>>> So, if we land these patches, how do extend it later to account for all >>>>> of that? >>>>> >>>> forward looking design would be subnode, which we can land ontop of this >>>> series. >>> >>> Yes it should be possible to branch to make subnodes work on-top of this >>> - accepting that once this lands it becomes ABI and support for this >>> method must be sustained, even after sub-nodes land. >>> >> >> Thats the plan. This goes as ABI with subnode to land on top of it. > > So, do you actually plan to support both ABIs? This would also mean > moving reserved regions to the subnode. How is that different from moving the reserve region when stream IDs would also need to move, so be it for the associated memory regions. > What prevents us from landing subnodes straight away? > You are well aware of them, but still asking the same. Reasons, 1. We have been attempting the subnodes for almost a year with multiple pushbacks from multiple maintainers. We are closer and working on it to post for iris, followed by venus, once review is acceptable for iris. 2. Current solution, in this series, is much easy to apply for all kernels and can land faster so that it can fix the reset issue we have for already enabled devices. Both from timewise and simplicity wise, this proposal is made to address the reset issue, while subnode can land ontop of this, without breaking ABI. Regards, Vikash