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 C3F4E3876A1 for ; Thu, 2 Apr 2026 08:36:11 +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=1775118973; cv=none; b=GFVG2DRe2crXHaLxcmRJ+13FI62/yQ2nrzFPaUmscHieCWo0AkIpVHJPOZKWAGrnFiGM1zaAs9JGJC+F1Z0ouk4xo00UYwJSybY0wQDkkU5RdjRbBd6DcWiB3WOTCAIqi59oDXna657fXgEt2eq/g27Qj0u/l1ryKUwBgh/Mbe4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775118973; c=relaxed/simple; bh=efq6KExaXloGlu4W+o6XXI3jit5Ma9jZElLXNdRwpoM=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=KBxRG1Lub4x3UCFRWV9QsHmP72EsspTvNDQyeqZSqsTkbsHO6FOEIUxC9QWRyqMjcmOrJbmghjpZy4kcmgTQ8sUfz9ez33BwnlwivahbqZ87mrW1bGMuJohPHqZwiQXCueb14bCQYfdcLfhoNlzih5/uL5eSY5LSmYgOT03gj4o= 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=RHma4SsO; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=j0agQ9jh; 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="RHma4SsO"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="j0agQ9jh" Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 6326tIhn2798869 for ; Thu, 2 Apr 2026 08:36:11 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= nZz3msypn/iPTQp7pBZHHsP/2F3PYJPj/B+Z6Rd1qmE=; b=RHma4SsOd/81yQFQ xAx6QCQAEfsXUYd1eiP/9KcSKt05B/8+nzzL65Ik3f6iUQz9+9v40os1eMNUM4Om IS9+3uV9M7/lJ0a6VZGq6psD7b30MCA+yw5iTekmwvuLomU4AkZYSi58G9jG5Mpa iOp2Y8QzPE972/fofH+xbDT6h1kVAjUtirRtXOJD/iBWVX/JGnpdt+p1fi87apVD 1BHkr0w3slGvST99Bky9/WwAq3wJu5E2rRTGZuY1HvKgHB9TediDxYiK2oU1nnOM VB+ogu469E8DK5gDXnhY4WdZGMdplI6U/29ywBKz1Vr1nrk+2NFbY0oyylNTCK// s0HIyQ== Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4d96hk368f-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 02 Apr 2026 08:36:10 +0000 (GMT) Received: by mail-pl1-f200.google.com with SMTP id d9443c01a7336-2b2497cc190so12595055ad.0 for ; Thu, 02 Apr 2026 01:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1775118970; x=1775723770; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=nZz3msypn/iPTQp7pBZHHsP/2F3PYJPj/B+Z6Rd1qmE=; b=j0agQ9jhpGOlLpuYokhwwOgFcvdrH+A8TotNKbbz77s0c7uoAGzwy1JHIP9u1qcFHm zWkBbPsOF5yz8vgoD5EfArOkunccFyaHrL4X40vudnPbqS99fDYbwH4LvDPVRf23C36R BR1z5LrhsTmjzSBOW09YOCOov3MR6s+bfQLh+NIJhU2M0kUjx9MVHBbkbFZ3QS3QAQBx peltmcVVy7LIWI8cUIpNaM1hmIxR+5izrZhR8K4PLxd6UKqVBF9O4OFk+U4i+tC7XSoP l1JZuXkVxz2Bmw5ePUePxAFlv1MbnpvT2fPW6X1FIg2y6mmdRLlata4cenJh60fCWN9t hO4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775118970; x=1775723770; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from: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=nZz3msypn/iPTQp7pBZHHsP/2F3PYJPj/B+Z6Rd1qmE=; b=kmyX1ehb3LE5e4J4PRZzkdzlYqtMlytXOPoHQ+KoNas31EGo9CrrOyE6zRPXIZURbP IMm+9jXd2BYyEHLEJHrG2nW4qU95kTesdmhQrtXGLTRG/9cP8W61mYziokc5tZGlyqwJ w5DHX+cf55CLzXyJqkFc7Ik2Q6jSuNFDkSMdD431MmHJLLL0mk5jZSGQTYjei+amCVCJ zddX7jconYpoyHH9gqKqEmjlfFg5OFRsUgET0ZLfzm9HeQ2tiKkycJ0Gsthdgd4i57sk VccJqRC9mgq8e6wikW/NeFQqQvb1NvHvjj3W7/KiggRl4c2wsRQrahpb7Sjj4P2y/wjN If8w== X-Forwarded-Encrypted: i=1; AJvYcCW9W1kvbWCEqD2gFxIn3tzJDIRe8nQ4tIDRVE/6Q7IOoSX5XWc18FkwJKMaUFr5ZIKDnxzj+IPKq9Vapco=@vger.kernel.org X-Gm-Message-State: AOJu0Yxlpi4SAtMrFVQnK82yfLBqo8p1UI5ReVrwx3ZvCwRD8iPyeFmv V6QXpInxJ5gfrdyiiIRBljwBFfW76GxNektE36f5eUKnPfC3ybZK0HcqnV+0gmKjEbqPcs69jgy eIrSPLJC+m0EJjRgkaGtW3l9DAYmoqxaBVG4/pQBJn+rniILNLiBGlAKuaubByenpITY= X-Gm-Gg: AeBDieucuEc1UdeJ8Gi6X1GzjhGo6ut81uwjAFLUswNHVh+lXoiEoGVq/PS79uXfXl1 0J0LtS5igf+Kq6YKc6ow6bg4dXZ/DE+07XmWh53aykx19GGq/Ooa1fqXM7B33g+TjW5MXRPl7A0 HnA3pMStRszRXJXAQLK5OY5ReK6ZuPa6TIH1UB1ojrt+15FhXDW9zyZly832sT+qRzavomLh1WL gfjw6R3CKBKvo7p1OXusPLPa2scLvHuOeibgv66UMgsr6yPmPOUV5aV+ascpdyaQiPZL5gUgkG7 uab5tSfN0o95/axNxtKtw1iJ+bLDxoFEBI3flrbTv+rruehlMt+FakSvo2ZT/DHj9fIDUod2JfM HmObS1aIjfCFu4FXPx9ZBpL4eA6S0pBc3RIE+F5h+vOHftluZTsGh X-Received: by 2002:a17:902:db12:b0:2b2:4c30:e6e2 with SMTP id d9443c01a7336-2b277e256c0mr15094595ad.16.1775118969710; Thu, 02 Apr 2026 01:36:09 -0700 (PDT) X-Received: by 2002:a17:902:db12:b0:2b2:4c30:e6e2 with SMTP id d9443c01a7336-2b277e256c0mr15094325ad.16.1775118969177; Thu, 02 Apr 2026 01:36:09 -0700 (PDT) Received: from [192.168.1.14] ([110.225.167.58]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b2749e2e97sm27595375ad.82.2026.04.02.01.36.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Apr 2026 01:36:08 -0700 (PDT) Message-ID: <998ce121-e027-441d-a3f4-2f3e41e10830@oss.qualcomm.com> Date: Thu, 2 Apr 2026 14:06:00 +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 From: Ekansh Gupta 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> <29f9bb45-5c3f-4847-a629-21cef540f38b@oss.qualcomm.com> Content-Language: en-US In-Reply-To: <29f9bb45-5c3f-4847-a629-21cef540f38b@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNDAyMDA3NiBTYWx0ZWRfX2ANlveBXTHQB Ah2Mj1hFp12eWXqu8TY9QZGHIczPCRPppjD72x+SQDbyl23iOuqkk4jbA4evBbLMQBkneEaSV04 +j4QAydBHoWftA3VLpMPdNqhLMElbtnjX3KGhmtW96NX84ycnfV7k9fNYtJX4+azByforPiKKCZ AXDYmatPIJ2LDtav/d7+Ee8tAnjKXpTRPcKBwXeaUnc3m8JYKKbvX0xGKmxyIUX+S1kopbCGOIW C0ILhoLMYRdDUaHa3ZdVTfO4WnYKOe2rp7FZovJJmHJVgGhDw9WY2Ay9xK+x1okFFeO2cAtDcEX t4sgZmD5IckUEaWcByUhmkpdZ+LHTFu6ZnJY30GXGfK+qNvtqCT+6Dn8V6nhRfK4mpQMltLk4Vg MPvY+6L2o86nxmMQihJIUUVV/Xa6PFSUDXfJB/rCNSizsq3SxU9wiA01aV3Ho9CYgX7N2NYcEyg zU9T0BcVXlE5ZIPWe7A== X-Proofpoint-GUID: VsqzO4BUmvrcKN0Moz_Hzw8bCg1yBnsf X-Proofpoint-ORIG-GUID: VsqzO4BUmvrcKN0Moz_Hzw8bCg1yBnsf X-Authority-Analysis: v=2.4 cv=e9ULiKp/ c=1 sm=1 tr=0 ts=69ce2a7a cx=c_pps a=IZJwPbhc+fLeJZngyXXI0A==:117 a=GstQyB7T1i92F5dDEt+vJw==:17 a=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=rJkE3RaqiGZ5pbrm-msn:22 a=_EeEMxcBAAAA:8 a=VwQbUJbxAAAA:8 a=EUspDBNiAAAA:8 a=yv3-IXtlHroiPP0bXpQA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=czjwGCTIUPoA:10 a=uG9DUKGECoFWVXl0Dc02:22 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-04-02_01,2026-04-02_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 priorityscore=1501 phishscore=0 bulkscore=0 malwarescore=0 clxscore=1015 suspectscore=0 adultscore=0 spamscore=0 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2604020076 On 3/9/2026 12:29 PM, Ekansh Gupta wrote: > > 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 Hi Christian, Do you have any suggestions for the shared requirements? I'm reworking on the next version and currently I don't see any other way to handle dma_buf_attach* cases. //Ekansh >>> 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.