From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 A00F9288C81; Wed, 12 Aug 2026 05:03:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786511001; cv=none; b=C4hOmcW0hpQ37oPuzxpszEVNDmd7Zpw6JbcMe2D9c+hQf9w3aO3PEyI2ypmauBjn2mpaGCathLcLgJepQBTHZU4MjUZyaT5QalNOnLgVEd4vFituaUNM6vD9LI8/CVbjaiWnU52jIrpj8mhupFPRuMW4hOcBVsAXCcrWWDazTWQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786511001; c=relaxed/simple; bh=45c9Mw+RtUpfsCt03yp7BPZDMVxg9SOCXgQtlflD+eg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=I2nUgLztiI8V0PHPeT8qqhR4Ds/kg/xBCek6iOfwF0+Hbfc5mt3iv1nwP5EqxJd66Dr+Zqj2YdP1O+U7arwiizEtiyN+fSTSJUxkUww37xHEyjatn1Pxl+y3O4iI/RT4IQEW9k6PKJ5poo8OUsZ2KpPPxp/pKJ93l2j8AiG/ZQA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lSFJzf+q; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lSFJzf+q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CB3C81F000E9; Wed, 12 Aug 2026 05:03:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786511000; bh=AG9V5QM/LQXyVzTFmXGwnlr2XmuiKwvic52wSwqRFzQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=lSFJzf+q9hmSN5emquAz9I3IscJsmGq5T3KpusvnyFpGD4/i/WjIpPuCtjvTsHC2l pCvfKHl8O/ubf46hB7lvrncAx5enJIzKUPk/tRW6uzf3jOtrDMSqHFzpwZPtIvaFRA d1P9Hcx4AI3iNHwGW/UHpGB4tMZEK7mhUJN5BQG1UrITNQTRfUNg6NbxYGS3zkKfCR GaI9EJvJcgzDPNJso37s3yhasCE0zf9jHzRMEvO/PoWp39v6Vxb1gfozUSMc/vI3BL MxDMYr9lKRVO0GzfmqeAFgqGnCdXHRtbPQFiyD0Ddv+oNDug2n6T9ywj+KEjfKYqxf ajIVyQVqCeJIA== Message-ID: <6906ca3c-03b2-4d9a-a3b6-2d38345d8534@kernel.org> Date: Wed, 12 Aug 2026 06:02:58 +0100 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: Vikash Garodia , Dmitry Baryshkov Cc: 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> <7caa7fd4-6732-4c80-8b8e-a0ed99631ba2@oss.qualcomm.com> From: Bryan O'Donoghue Content-Language: en-US In-Reply-To: <7caa7fd4-6732-4c80-8b8e-a0ed99631ba2@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/08/2026 17:57, Vikash Garodia wrote: > > > 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 > There is another solution. Restrict multiple concurrent streams in both drivers. The failure mode is as I understand it only triggered by _concurrent_ streams so, restrict that case in the .c code. Nothing dictates DT as the means of addressing the problem. Clearly not many people run concurrent streams with the upstream stuff so formalise the restriction until sub-nodes permit reintroduction of the feature. --- bod