From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.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 1B7DA3EDE64 for ; Fri, 17 Jul 2026 10:44:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784285102; cv=none; b=BUyDVTuS3TVcJ3zHfnn/wmgMM3Yui5ifsZllQcyJ5OPUdrlXnE3aj/PUki15yAaaeLkd9DlGJNrhudrm8oiRhcPkuFOjDJUJvX7waXyHwtpolmYcfYUUZf5ZM3wLhQ8uW5HrnUvH1xDPoFzWJ6iV7JKYq/Y3CMwbIZdaEkI+Chw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784285102; c=relaxed/simple; bh=2pEd2PoX7gxj2uadPnEorYAgEq8J/PjNx7zkix44hD8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bqXPwzUj5wFcdAPlaKut5UPMU4bY80v4a+SRjPwydKV5lbuvvBMI6/I1CGbaA2DD3QFPLtvfqT6HbI7YrMDSj2ZXlfauKkidnUua5uloRp0mhhY6GCFea+xr6s/kf9gcN/AbYBWuXJttFeVDBTptpYEtKtpkx5fqsKFfYQTmGyU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ducQ3wXX; arc=none smtp.client-ip=209.85.218.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ducQ3wXX" Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-c15d3cd51b2so899057966b.3 for ; Fri, 17 Jul 2026 03:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784285098; x=1784889898; 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=GHMjre5IwjmjoZwiytENVYpWI2A7IWIyRw+/ii0+cJ8=; b=ducQ3wXXnM0/C16tx2bW4w73XQrvGY4nKM0b1cv6zI5EMAbtR1n7oJOgB7kGezYoTv fxwmR/zA/AKiNlfaRiuM0GUqqa/p2WM3gegjD5Pf2+IqLS6c4HN7/0OpHVqoPY5zVRke ftS/YdlP+sPW1Isn1uu8xwr+bgfpHjUpZFOniKxF7n1zP0huz2nb0oxg7DkaMZ+SRZQ5 YBH64t/nr72UYJuTqXpQQnoJ6QXnq/y9/x+XBAyxZyZSaw3H7g5YlXajZbqqge8EE7vL BTiifURUn/859051xj9FFksz6zRNxDy+J6CnVbUan3XQ5KNgiYNTUkXUPKNW3xCQxmPk 4c+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784285098; x=1784889898; 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=GHMjre5IwjmjoZwiytENVYpWI2A7IWIyRw+/ii0+cJ8=; b=UJzSFPFkqLciNT8OITWpQBgdENJPrKdf/jChPJO5k+hmlphmDAlfmawFMZ8epKoNDY PtE4befXRa/PsYxphV2Gsn8UzUZPegnuShBLjj8/Y8fKEOp+SJlHUxs5eBqFh79YFubw jkOw+gkWnhJnUZk4BZloMwr6iDcsWn4fA8VudaVV9zbY+oND5WhQYcARXBIcQjmxzNO8 8+HKC6KiSki3uJZ7MQhNJL7NpKy6v4PlV8BSYqyqsA4LUoM8svDSiat6BnvISbS2FDpr MvxgH+c15U/jJdjcz4Ii/vry7eOWr8PMKEqIcH9Mljvmxo1sxeGB7roTAIJj40HsNrhk T0Nw== X-Forwarded-Encrypted: i=1; AHgh+RpGRWYKjxJE2/vXlGr2n/1CT+V3lNT/IYhlfKgsqFdTMtd4e1klWUEF4VgiWTds5NisTiDeUl140xmwbz0=@vger.kernel.org X-Gm-Message-State: AOJu0Yzbkq/xkiq8KL5mxQyqb/O62sd87CqE0RstMd5ZDB3YDCxV8Dkz Hozhowfm5EdvoWMqTnNmXQJ/V/K5NfGjbiDZSom41LfFRg1lnFXVcOGj X-Gm-Gg: AfdE7ckSXnqWfM0zYclfmjyfJ5DETyeHKaOU/vvhBTjMpKfki7AoJBHORk+cbMbcMeo oIXmvVEjsNVErvavioXBH+q3KOmtRe9bNe/kM4gVNG2JgXa0earEZ9dOmp+V8VNn9/m5fpzUT/G m3wOsOq1xNXc4m786q3ul7Sk9CcgRN0fcBpx+ETDYpKsBwSG1ZJLLPSI+U3k2pKWvIjmR9s5DbM dXEYVt93FbC+MRBNkCuplZaIK7SnWH/CVeXmimtmplP4iuru6u44yY/45UsfZwORsn4b0Zl0H0I S3xSvSwIzxn9wYwZ821piWCic8Xtd15b8vt8SdyUhy3XhINwHPYnlI+JuC70TnmcDndqCQhSFhW y8VSZn1qBfM8FRkfp8X/x1pD2NGq17pRTE1V3OqIP2okrYUAju2+k47Ztbos6gTXKEEtVccKClE wFUjQPaDH/zb7i9g== X-Received: by 2002:a17:907:841:b0:c16:66dc:3abe with SMTP id a640c23a62f3a-c16b46fe83dmr88156066b.28.1784285097922; Fri, 17 Jul 2026 03:44:57 -0700 (PDT) Received: from [192.168.120.193] ([178.235.128.140]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c1740bf91bdsm52739366b.63.2026.07.17.03.44.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jul 2026 03:44:57 -0700 (PDT) Message-ID: Date: Fri, 17 Jul 2026 12:44:54 +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] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices To: Jason Gunthorpe , Krzysztof Kozlowski Cc: Vishnu Reddy , Rob Herring , Krzysztof Kozlowski , Conor Dooley , devicetree@vger.kernel.org, Vikash Garodia , Robin Murphy , joro@8bytes.org, will@kernel.org, m.szyprowski@samsung.com, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, dikshita.agarwal@oss.qualcomm.com, Bjorn Andersson , Dmitry Baryshkov , Robin Clark , Akhil P Oommen , Srinivas Kandagatla , Ekansh Gupta , Loic Poulain References: <20260119054936.3350128-1-busanna.reddy@oss.qualcomm.com> <20260612172649.GM1066031@ziepe.ca> <20260615125257.GS1066031@ziepe.ca> <20260617194038.GC231643@ziepe.ca> <20260618151745.GD231643@ziepe.ca> Content-Language: en-US From: Konrad Dybcio In-Reply-To: <20260618151745.GD231643@ziepe.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 6/18/26 5:17 PM, Jason Gunthorpe wrote: > On Thu, Jun 18, 2026 at 01:57:40PM +0200, Krzysztof Kozlowski wrote: [...] > So, if we are going to do a hack in DT to accomodate Linux, I argue to > choose explicit child devices so VPU does not need to create a special > bus, call of_dma_configue, or hack in new DMA API things that only it > will ever use. Bit late to the party, but I'll chime in with some more "amazing news".. All of the multimedia HW on QC platforms (camera, display, GPU, video and their specialized variations) has at least part of the same problems: * Multiple SID groups that need to be accommodated for different purposes (normal vs secure buffers provided by the same device, different "logical functions" generally speaking) apply to all of them * Different IOVA limitations per SID group seems to also concern at least the camera uC ("ICP") (but not all of camera hw) * Remoteprocs (and therefore also the audio stack) expose a number of subfunctions, some of which we currently model as subnodes (although many arguably only exist as such because someone decided it was convenient to express them this way). This, for example led to the representation of each SID group associated with the remoteproc (fastrpc/"run compute on rproc") as a separate node: -- qcom/hamoa.dtsi remoteproc_adsp: remoteproc@6800000 { [...] // no iommus OR iommus used for another purpose (fw loading) fastrpc { // no iommus compute-cb@3 { compatible = "qcom,fastrpc-compute-cb"; reg = <3>; iommus = <&apps_smmu 0x1003 0x80>, <&apps_smmu 0x1063 0x0>; dma-coherent; }; compute-cb@4 { compatible = "qcom,fastrpc-compute-cb"; reg = <4>; iommus = <&apps_smmu 0x1004 0x80>, <&apps_smmu 0x1064 0x0>; dma-coherent; }; [...] (there's a lot of them) }; }; There may be more hiding in plain sight, but those are the ones I'm aware of. I was kinda hoping there would be more buy-in to follow what PCIe does, but to my understanding you're opposed to it because "vpu_bus" is not dynamically discoverable. PCIe generally obviously is, but we already have prior art regarding hardwired/onboard devices - many qcom DTs carry per-board iommu-map overrides to please the allocator with known-in-advance BDF values (because the HW has only so many SIDs): -- qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso iommu-map = <0x0 &apps_smmu 0x1c00 0x1>, <0x100 &apps_smmu 0x1c01 0x1>, <0x208 &apps_smmu 0x1c04 0x1>, <0x210 &apps_smmu 0x1c05 0x1>, <0x218 &apps_smmu 0x1c06 0x1>, <0x300 &apps_smmu 0x1c07 0x1>, <0x400 &apps_smmu 0x1c08 0x1>, <0x500 &apps_smmu 0x1c09 0x1>, <0x501 &apps_smmu 0x1c10 0x1>; Although it seems to me that it's more of a hack than anything else.. With that in mind, do you still prefer that this is handled through separate nodes, presumably for all of the aforementioned cases? Konrad