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 15519274B39 for ; Mon, 9 Mar 2026 06:59:39 +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=1773039581; cv=none; b=TdJDHE3bM0zmy30mar01tigCLkTMj6IMe17ZFHHHDgtiRpYtWE3J8wkohnsE+AGg8aflKclN7Gf1Mxb8e2thCQhv8KCUG0Dllzv43jUTu0qTD0jzSuQVG/ZUFGYaQ6cDbp8r1k7inSsTsX6xmqIXgdQJqm/6Q12WFHwRlZPe8qU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773039581; c=relaxed/simple; bh=FvVlZ/Lcen9SEsi9VK8j2x4eoHrMDtIyP/b5GXbxpaU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=QOl4DmdlHFOf3Z1f2CcgZGXhGeZ2P61/yUA7sxu7cTxHThg2o5p6DVl+SbFi1f+WyZ80Kdri/00DnpK1mfZx96nVO28aEPxNrTScXf4HIKbExzfpASbZ0D3W7XipfI6FuOOKuwwUXJMGxhHqPkHaDWkVeTQ0lo+gEcOJblUfr7s= 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=i5QfXdgA; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=Jq9lh9yR; 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="i5QfXdgA"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="Jq9lh9yR" Received: from pps.filterd (m0279865.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 628LZp9K3540564 for ; Mon, 9 Mar 2026 06:59:39 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= G+rVK2qEYMP73XgPEKoeHzVEXgyXmbiGfinl4OV1AfY=; b=i5QfXdgAcg/AgJni irNAv/e8dbLAEbvQsR2oIvr8dzvfhC4LlOP5b0CUTzKKvbHMVURDzdsbElcrqk37 leb3d0XeO+wsZvb4WSyXwVHqYmgLUGuVSXsvUTqfbQsQxrYL5qOoI96G9Sd/6BFb 1d4IM7k4Cfc0ikPSe8fnxEOzpXFI03B8f3fSK43H3iiPAKvy4sACg/wvTt55A7pt 3u4Q3kGPEbgcz57stZVWCbucXmDT9odK4Bnl2AN2bzeNenaT0oCZyvSZ9ylxkB+z FvwsrcIZS9B9tZgDXowO674ls3TgjKtQRQ7IwMCSo/bnwHIlVK8Ay+idNqfBPxnM xRMw6g== Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4crayrmch9-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 09 Mar 2026 06:59:39 +0000 (GMT) Received: by mail-pl1-f198.google.com with SMTP id d9443c01a7336-2ae405e95f5so89162715ad.2 for ; Sun, 08 Mar 2026 23:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1773039578; x=1773644378; 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=G+rVK2qEYMP73XgPEKoeHzVEXgyXmbiGfinl4OV1AfY=; b=Jq9lh9yRemESfvXKxWWFUEpDQSyTjzbvSe6DiCoT+37aI7+RW4RHgXJ12Yyf5czfPI R16qDwGnD7Cfk+6FbNwLZQt6WwwrJqv6IBoXJwME5BKO3dCbx8dXCkas8Yr3qzPgUHZ+ Uqfc9FMHpIxEOZ4t/riHqHxuxLMakzIChi81da5+ZDHo5WQzH0Ge4QTxwmJtbckgJ2gI rv4Al/4F1NvpUhkNDC90LRwtrnsA2LD96g+ky8nK/M0n4zCjnuTunc8NRga7JauAKyGr zZ1QtEJ02o6f/Wugmg2B1OGSDGQ0atQ/r1jaSv5Mt0ZgluUK1grh8eSwrs+mBA4fOuuL FttQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773039578; x=1773644378; 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=G+rVK2qEYMP73XgPEKoeHzVEXgyXmbiGfinl4OV1AfY=; b=WZMfRGx90kidNwOZaSdXuGyQkJcZXEPZwyIS0CIHM5QUwx5dhhwiJWZx6T7iwIocwJ +ZtASRxR9vzE1BGzeO8zEchZGloVfmk269Y3JCT4atE41uXv8Bt7izAVZ+oNyiKvOb/o XdqrUN6Xa2ab08tzOqtn3pPKNBZ7tINY8XJyeXb4/hHCtSy0pHgeyPVBH3mHVen+ckTv 6lzK7GPUYdJVs1nhPFqZ5eb15LPFcAm5zhabdooZ8qEn5bJ7UJRnCBv3c9gjXSaaQl6n btT/JH7yJ+2aKcqO3Q5hC7oFiItVCPlf3S3I641pPWtIepIWyZ79lg7qXzYzuABLPRs1 RrHQ== X-Forwarded-Encrypted: i=1; AJvYcCUdvpEH6u/iXiSyHMXCfZJxyL2wx+3VOzKhUJy5d594+AhH7x3A4QD3+yvUUKynUM/MscYWF6564oh2+uI=@vger.kernel.org X-Gm-Message-State: AOJu0Yy2tQthwAZ0LONU6J5IZzC7keJodoA0j/sag1yZJJ5/4llHsKuZ MwMez5A0gXGpoBv6StV4ThhhiIlKDzSC7NVpJJdOs6pP4RPgefGiMiO1rOqf51IPRbzrXmlhqD+ AsEyavRxqAyvMr52tStR/pluoDsZUjtMQ3+Sm8Ugd7wWp52KUGgP7Nb2ZBHJuVmgoA6Y= X-Gm-Gg: ATEYQzyz2mgEDymDq79XPDhRxTglRP/D4892quWZEOfEwgasHyYZSAQF9XW+MKdCP+E qgBi0a6f4eV83Nh6kaoxruqdRhPWE78g0+xjijxilB+4z/Wf99spILRVvqHj8wXIxJ9jvRAM1Bf OXH3kpTcKuaJQu8Drqw0wUiPSoRV9bPNuRhLCJSBptvayH5uYwb9YsjpPLl4Tk2su+gj33yE//p 1cFWOkrCAW3SJ3tuOZW5qpIyPcwm2rOPWXSvagCjNwYVWL1gy99bUTYZusUJboVgmdkb5pzAgGc LZDHESMvK6vk87/Ff9UKc2kVq5ivWSyKpVowDSLGn01RqSPfiR0v3g8MqZfTDAJMfFZKJYzpJKW mTeGlQwfUJwsz6vS5FabJCkCXf68IRTl4mqJ9hatfov0KTZYShg== X-Received: by 2002:a17:902:f651:b0:2ae:61bb:4255 with SMTP id d9443c01a7336-2ae82418927mr109317785ad.11.1773039578328; Sun, 08 Mar 2026 23:59:38 -0700 (PDT) X-Received: by 2002:a17:902:f651:b0:2ae:61bb:4255 with SMTP id d9443c01a7336-2ae82418927mr109317495ad.11.1773039577848; Sun, 08 Mar 2026 23:59:37 -0700 (PDT) Received: from [10.206.99.28] ([202.46.23.25]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ae83e5c167sm99741945ad.1.2026.03.08.23.59.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Mar 2026 23:59:37 -0700 (PDT) Message-ID: <29f9bb45-5c3f-4847-a629-21cef540f38b@oss.qualcomm.com> Date: Mon, 9 Mar 2026 12:29:29 +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 RFC 12/18] accel/qda: Add PRIME dma-buf import support To: =?UTF-8?Q?Christian_K=C3=B6nig?= , Oded Gabbay , Jonathan Corbet , Shuah Khan , Joerg Roedel , Will Deacon , Robin Murphy , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Sumit Semwal Cc: dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, iommu@lists.linux.dev, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, Srinivas Kandagatla , Dmitry Baryshkov , Bharath Kumar , Chenna Kesava Raju References: <20260224-qda-firstpost-v1-0-fe46a9c1a046@oss.qualcomm.com> <20260224-qda-firstpost-v1-12-fe46a9c1a046@oss.qualcomm.com> Content-Language: en-US From: Ekansh Gupta In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Authority-Analysis: v=2.4 cv=U5qfzOru c=1 sm=1 tr=0 ts=69ae6fdb cx=c_pps a=MTSHoo12Qbhz2p7MsH1ifg==:117 a=ZePRamnt/+rB5gQjfz0u9A==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=Um2Pa8k9VHT-vaBCBUpS:22 a=_EeEMxcBAAAA:8 a=VwQbUJbxAAAA:8 a=EUspDBNiAAAA:8 a=YM0dgK5nqTTLF_VjvEgA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=czjwGCTIUPoA:10 a=GvdueXVYPmCkWapjIL-Q:22 X-Proofpoint-ORIG-GUID: HskWzw6da2g6oCBs9rBDzzP-D44B0inS X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzA5MDA2MyBTYWx0ZWRfX+eqRKOQckyFH ErAYzO8OLkVtvHwah2H3DKHNCoBgIq3OCqCgyl6j2gU4GWPc8Lk93KOlBp0La0VNLtAc4BbrySg TYeT19ckEZT8Ba5soYLws3TrsvOsUvN7I47RqsXg6N538z/ir3lIejbN0UAY0fnYW/DyziEsIaS BM/OWg1+Bd6E27jKFv0kqa9B7wY8oPQV2drVmrk1pr0Dby/WVPXr+uu7qc0QuvouAo2OyE1V+Vc IVtaS9qJXc4x1/s2I5fvmXdQR3Y5Ayl5l2AkrVAOIH2RxbzKnT8x94PM+4j01rL48eNAe4qjY5G I6W6NaiUY76XRQSfMakcjomEVHFDiBJJhpM2knviSf6CNWPL/a2HRIFO7ARfD/kjlsVx950KE/H Wne61VemWKGXj4oghCpu5CL3NzLF3YnNmqxZ/O7QVT61bLfU7oXfiy3pnM45k6dpigwxv0n6BrU 0fcMS+vk3NteWq5aUVw== X-Proofpoint-GUID: HskWzw6da2g6oCBs9rBDzzP-D44B0inS X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-09_02,2026-03-06_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 adultscore=0 impostorscore=0 lowpriorityscore=0 phishscore=0 bulkscore=0 malwarescore=0 priorityscore=1501 spamscore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603090063 On 2/24/2026 2:42 PM, Christian König wrote: > On 2/23/26 20:09, Ekansh Gupta wrote: >> [Sie erhalten nicht häufig E-Mails von ekansh.gupta@oss.qualcomm.com. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ] >> >> Add PRIME dma-buf import support for QDA GEM buffer objects and integrate >> it with the existing per-process memory manager and IOMMU device model. >> >> The implementation extends qda_gem_obj to represent imported dma-bufs, >> including dma_buf references, attachment state, scatter-gather tables >> and an imported DMA address used for DSP-facing book-keeping. The >> qda_gem_prime_import() path handles reimports of buffers originally >> exported by QDA as well as imports of external dma-bufs, attaching them >> to the assigned IOMMU device > That is usually an absolutely clear NO-GO for DMA-bufs. Where exactly in the code is that? dma_buf_attach* to comute-cb iommu devices are critical for DSPs to access the buffer. This is needed if the buffer is exported by anyone other than QDA(say system heap). If this is not the correct way, what should be the right way here? On the current fastrpc driver also, the DMABUF is getting attached with iommu device[1] due to the same requirement. [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n779 > >> and mapping them through the memory manager >> for DSP access. The GEM free path is updated to unmap and detach >> imported buffers while preserving the existing behaviour for locally >> allocated memory. >> >> The PRIME fd-to-handle path is implemented in qda_prime_fd_to_handle(), >> which records the calling drm_file in a driver-private import context >> before invoking the core DRM helpers. The GEM import callback retrieves >> this context to ensure that an IOMMU device is assigned to the process >> and that imported buffers follow the same per-process IOMMU selection >> rules as natively allocated GEM objects. >> >> This patch prepares the driver for interoperable buffer sharing between >> QDA and other dma-buf capable subsystems while keeping IOMMU mapping and >> lifetime handling consistent with the existing GEM allocation flow. >> >> Signed-off-by: Ekansh Gupta > ... > >> @@ -15,23 +16,29 @@ static int validate_gem_obj_for_mmap(struct qda_gem_obj *qda_gem_obj) >> qda_err(NULL, "Invalid GEM object size\n"); >> return -EINVAL; >> } >> - if (!qda_gem_obj->iommu_dev || !qda_gem_obj->iommu_dev->dev) { >> - qda_err(NULL, "Allocated buffer missing IOMMU device\n"); >> - return -EINVAL; >> - } >> - if (!qda_gem_obj->iommu_dev->dev) { >> - qda_err(NULL, "Allocated buffer missing IOMMU device\n"); >> - return -EINVAL; >> - } >> - if (!qda_gem_obj->virt) { >> - qda_err(NULL, "Allocated buffer missing virtual address\n"); >> - return -EINVAL; >> - } >> - if (qda_gem_obj->dma_addr == 0) { >> - qda_err(NULL, "Allocated buffer missing DMA address\n"); >> - return -EINVAL; >> + if (qda_gem_obj->is_imported) { > Absolutely clear NAK to that. Imported buffers *can't* be mmaped through the importer! > > Userspace needs to mmap() them through the exporter. > > If you absolutely have to map them through the importer for uAPI backward compatibility then there is dma_buf_mmap() for that, but this is clearly not the case here. > > ... Okay, the requirement is slightly different here. Any buffer which is not allocated using the QDA GEM interface needs to be attached to the iommu device for that particular process to enable DSP for the access. I should not call it `mmap` instead it should be called importing the buffer to a particular iommu context bank. With this definition, is it fine to keep it this way? Or should the dma_buf_attach* calls be moved to some other place? >> +static int qda_memory_manager_map_imported(struct qda_memory_manager *mem_mgr, >> + struct qda_gem_obj *gem_obj, >> + struct qda_iommu_device *iommu_dev) >> +{ >> + struct scatterlist *sg; >> + dma_addr_t dma_addr; >> + int ret = 0; >> + >> + if (!gem_obj->is_imported || !gem_obj->sgt || !iommu_dev) { >> + qda_err(NULL, "Invalid parameters for imported buffer mapping\n"); >> + return -EINVAL; >> + } >> + >> + gem_obj->iommu_dev = iommu_dev; >> + >> + sg = gem_obj->sgt->sgl; >> + if (sg) { >> + dma_addr = sg_dma_address(sg); >> + dma_addr += ((u64)iommu_dev->sid << 32); >> + >> + gem_obj->imported_dma_addr = dma_addr; > Well that looks like you are only using the first DMA address from the imported sgt. What about the others? I might have a proper appach for this now, will update in the next spin. > > Regards, > Christian.