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 6357639EF24 for ; Tue, 8 Sep 2026 07:45:46 +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=1788853548; cv=none; b=ccx0mTme/J+hIKRFZKLMNyOAw09fOGa/n8KLrjcPNfoIkN6qg0w/I95E+5DFHl1VtrhdyqKIK3/YYSZhky40X+U4tniRZ+Lid0tuSlYLiteWQNuTix6qw59KGykZPcZJ7Te+IfDaG5cBqND5jUiVYta+CXgjcsB4ZYtFJPLdaZk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788853548; c=relaxed/simple; bh=MYJ8QuS9dJHlh3zGd4Jjmjuv7oAWC7r/tOj6ovNMei0=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=LwxekN6n14EDvZ8Gak998jmvP2jfiAGyZFe5x7z7GfZZpKmQ64XWPcoFj0JfQsPOheOEHTFiQFjO8t5vvCr8KYF1FhK9R7IDUBM5whFZHAgvsUhgDGeOxf6o2KS+hR+Axu8P2gn4TBO6Yu2rmsvHGts53xCyF052AFn0Ybw/HyI= 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=meyDObDd; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=YEHGqRBc; 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="meyDObDd"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="YEHGqRBc" Received: from pps.filterd (m0279868.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 6886M2Uh2072723 for ; Tue, 8 Sep 2026 07:45:45 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= vjCdleB62PQ5+3oSfJm6THWjJHXQHO2Cei/sEBlVgJo=; b=meyDObDdxg1onozh BTIfrgJw9Bf20bmpFLWeHyZoqdWL8TX8jZKczZ2pE6krABotoKHevESc6wzTBOzl OAwYrON/e3Pl7RsZxRn/C14fZyu4VRBSt3xnJLQHdwXsh88S9DC5l9GiZmPVa8hA eT3Vm7Xv/6RxHAs66hv7XBakFwk2uRVloSq8Bl9hzR6PEnOgqphhTOHN2EUHNvJq MqXXrISTRFOLQnXj5HCjf2dsYwA1yuMoVHaaoTwJGFlGxGn9AsLUQL4zxmYGCj/X DkfS9JacTTbaF9b8B28tcXEN5zSj37ztLWzdNQWA+CbGZVik/3TZUBGHipETto+C bV2gbQ== Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4ghsfymdmb-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 08 Sep 2026 07:45:44 +0000 (GMT) Received: by mail-pj1-f72.google.com with SMTP id 98e67ed59e1d1-39b90cc0d5cso999572a91.0 for ; Tue, 08 Sep 2026 00:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1788853543; x=1789458343; darn=vger.kernel.org; h=content-transfer-encoding:content-type: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:content-type; bh=vjCdleB62PQ5+3oSfJm6THWjJHXQHO2Cei/sEBlVgJo=; b=YEHGqRBcBcdowYeghmqS0KR/PddShzQCfUrDW9T8rNvAOVSypnoSj6A83LxedMtrYh YKIs4i6/TBkEJE26KrW4Odj3JpXn40cHjHqr9V7SfhLIEOrDwyMGYhMdIn2naMqlFpDe +pLjsN4rnGs+4L818Ng6FkuCQhwRGZ86WkYk1EBFMM0zV422XwqUDOIkNaLHzwMNb3Lf WRtgMfc4slq+oMi6YALGCIAVJEnxbJJ6FvWjML/lUMCELSi7zg1FrML/doltA1N8VO19 fSHk9ULQhm7tRk4xcqbf4Xs8RE1aaWRXQrAKgc4LGfNRyuKtlrj5HWsAJTh6kALWv+QP ujXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788853543; x=1789458343; h=content-transfer-encoding:content-type: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:content-type; bh=vjCdleB62PQ5+3oSfJm6THWjJHXQHO2Cei/sEBlVgJo=; b=lk+xLHQjuciv/n8lEHFHP9oxtjAVAbL8MeMVuX/PDoCFOpwH7pfq92dhVLgzahuH6Z ooAeicW2pXlkTO4Bs1pF7pUhbLrw8jeYlsB7ge1vuO5AJ/skr8eF81E4X5V3ttKSMcQr CXqDmsZY5tTBYPV8OsOrJHfi9y8uSS93RAh3Ges9ts2ytjAatdRbgEtYIW9rsgwGOtrd yWJygjb/22KpsMgpycRiiHnaCjrDRDJsrI1VA7ufjW6VxBY7J9ZZgQhK39+DmmCzpCzQ nB/2bz1pFE5u7IDT24CBvwPcs2p8ChYemY0YZo6DfQNvixmBRggfIXbaHKy0GSakmaT+ KUsQ== X-Forwarded-Encrypted: i=1; AKwUvBxZUz/KMkjF8+ISB0fGBo/j5oboWiJlYs66vh8b4WHueCU0PyeM0vXcCZJF+z0lNETgaaLbzWJy1hrOIA==@vger.kernel.org X-Gm-Message-State: AFuF++mLDKHcAskq1c8O01XposQmQdR9nBcfdac1ix2NFluJh6/pVMkL O9LfwF+mWwNZQGx+YeD7TsnP+xbmudHfdqgfieY31Eu49NBtAsDinqC8GLKw0Jy8QN1S4EL90YO +cBp1kjOZOkPO5vXmhARctzSZydimOEWydHsYTi8mvY/qJDDzrXHk6k/NXb96dYRpZA== X-Gm-Gg: AYBFou3cXIraofiW1zR8zFIZ7T4FFzlcDTItlfi40Cu5QxCPyGJJ+/k6PhuAyuPkWUP IlMrzyt7tv15Z7ISQSgNbylUK9kZPDQqZhDPmpoSXoMxm6E4OI1xXYyRlbNxJdAwtalmcCUGeYE 6ojcpaB27cqwkYdsZbPRTF4hYWQ4kHvYlkLl7Q0pkWAP8gmTLmB6cHDejL4UciL/d797hlXj0z3 9jabXJNV/uUjkyzwelY+Jjnj1z6zeyGA7OYvbhK/zztocPtISxpp45IyOv7rCMu/uzOVTj55g+G vidWa0+/BWGpQ28j9ZY+J/7HJiW1BnMMp5vGkuQPo2iCPnYikDEBzPQkZSvYAhbkaoStKqiDS3T OBmdxvl8s1kCr7T/JH2zXS8rBBerVRg== X-Received: by 2002:a17:90b:1e03:b0:398:b17b:3bd2 with SMTP id 98e67ed59e1d1-39b260dda6emr38832013a91.4.1788853543400; Tue, 08 Sep 2026 00:45:43 -0700 (PDT) X-Received: by 2002:a17:90b:1e03:b0:398:b17b:3bd2 with SMTP id 98e67ed59e1d1-39b260dda6emr38831975a91.4.1788853542891; Tue, 08 Sep 2026 00:45:42 -0700 (PDT) Received: from [10.219.57.226] ([202.46.23.19]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-336c2571039sm14719241eec.25.2026.09.08.00.45.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 00:45:42 -0700 (PDT) Message-ID: Date: Tue, 8 Sep 2026 13:15:32 +0530 Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/15] accel/qda: Add initial QDA DRM accelerator driver From: Ekansh Gupta To: Krzysztof Kozlowski , Dmitry Baryshkov Cc: Oded Gabbay , Jonathan Corbet , Shuah Khan , Randy Dunlap , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , "Joerg Roedel (AMD)" , Will Deacon , Robin Murphy , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Sumit Semwal , =?UTF-8?Q?Christian_K=C3=B6nig?= , Bharath Kumar , Chenna Kesava Raju , srinivas.kandagatla@oss.qualcomm.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org, linux-arm-msm@vger.kernel.org, llvm@lists.linux.dev, iommu@lists.linux.dev, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org References: <20260817-qda-v2-v2-0-69a02e9090d4@oss.qualcomm.com> <20260817-qda-v2-v2-3-69a02e9090d4@oss.qualcomm.com> <81708487-89ce-4cd5-b39a-2989bdce6088@kernel.org> <3476b5c3-7983-4994-a901-3d7d8bd75255@oss.qualcomm.com> <4ef74e14-8433-4619-ac97-62868c8799d1@kernel.org> <4xcyqqrqbvgxojfcmnpwbi2uqk5tvhts52l6sxetltcgb7mo75@lfsgfoq4npz3> <59aa182d-1b4c-4bdc-a1d5-e76cc9c88ed9@kernel.org> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-ORIG-GUID: NIqdIkGsa6fB8mDUBIbTYE3Nu5VMyGZx X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTA4MDA3OCBTYWx0ZWRfXwK+TrEflK99D g9tkqm/LJX4yxDfBw27yB3a7LgLQd3V3ag4kLzE7UqrVjlhWBzPFC6wFZUnrtPDh4YrLSLG0BW3 gQSsmbjtIlnp+AFPgxtpcv9aZwQBnGdOI5NJRhMuCGyNs4LSst/faW1J6I/uWdwzyTh//9oCCVv 6qURo2xGwi/5ql2pOmqpSS1ZWGjAftw7J3aHm98Oruj/dldGIzhBt4cglHNAC8LN+OUcbalV0Lh k95bXqDTVbW35JFvFowCmE++UgZ6OUZQJ29fG970P5IKfitdTAVpP3RrjdKOEAxvqWpDmrWUbwS 9DcqujnUWcOyDxBknkt+134JqsPDfr74DgkJcEB30TOZQG00rdnQZkMfksjPe4tG0PujbypzWlb rn0DjrG6aSqwBRF8hxWaNfS8M4F82T0x+7rL1ZrtUX27j9bIbLYRBsHjYc34vyEplzs+3UPerYW 9UxdYFZMdU7clmcy0bA== X-Proofpoint-GUID: NIqdIkGsa6fB8mDUBIbTYE3Nu5VMyGZx X-Proofpoint-Spam-Info: AW1haW4tMjYwOTA4MDA3OCBTYWx0ZWRfXypC1BbkU2EQw vvmj5wA9odJu3ccqhCuCZVv33YCX30n8TFi8+ByDToYPedB2pvc1rwp/ytDrG8OV/1I/TN88ppr 0Cb+sUuSgODT7opYevo1CVmer3rEyHc= X-Authority-Analysis: v=2.4 cv=AduB2XXG c=1 sm=1 tr=0 ts=6a9fbd28 cx=c_pps a=RP+M6JBNLl+fLTcSJhASfg==:117 a=j4ogTh8yFefVWWEFDRgCtg==:17 a=IkcTkHD0fZMA:10 a=VdqzKS8jKosA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=ZpdpYltYx_vBUK5n70dp:22 a=wP88gyHQT0P6k6tIFBAA:9 a=QEXdDO2ut3YA:10 a=iS9zxrgQBfv6-_F4QbHw:22 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-09-08_01,2026-09-07_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 lowpriorityscore=0 spamscore=0 bulkscore=0 adultscore=0 phishscore=0 clxscore=1015 suspectscore=0 priorityscore=1501 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2609080078 On 31-08-2026 20:28, Ekansh Gupta wrote: > On 20-08-2026 19:01, Krzysztof Kozlowski wrote: >> On 20/08/2026 12:07, Dmitry Baryshkov wrote: >>> On Thu, Aug 20, 2026 at 11:07:45AM +0200, Krzysztof Kozlowski wrote: >>>>>>>> >>>>>>>> Device node with this compatible is already populated, so this looks >>>>>>>> simply wrong or you are adding a duplicated driver. >>>>>>>> >>>>>>>> That's a no-go, you are supposed to work with existing drivers and grow >>>>>>>> them. >>>>>>> I'll bring the discussion again here, there was a discussion to move the >>>>>>> driver to accel subsystem if we want to support new features/uAPI >>>>>>> changes. Please read [1],[2] threads. The intention is to replace >>>>>>> fastrpc driver with QDA eventually. >>>>>> >>>>>> None of them address the problem. You want to grow fastrpc into user of >>>>>> dmabuf? So you move it from misc to here. >>>>> >>>>> It's not as easy and nice, so I think in this case it's better to repeat >>>> >>>> I disagree. The existing fastrpc driver is not that complicated. It's >>>> actually moderate amount of code, much less than Venus was (~7 times less). >>>> >>>> It easily can grow to support two interfaces and the only difficulty is >>>> how to manage these two interfaces simultaneously or exclusively, e.g. >>>> opening first one disables the second. >>> >>> I see the point here. >>> >>> Would it be acceptable if we add QDA support only on the new platforms >>> (e.g. via the SoC-specific compat), provide QDA for those platforms, >>> and, once it reaches complete API and feature parity, we remove the old >>> fastrpc driver, migrati old platforms. >> >> The problem with this approach is that we have no guarantees that it >> will reach feature parity in respect of old interface, thus old driver >> might stay forever. If we agree for duplicated driver, contributors have >> no incentives to support old approach. > That's a fair concern. Let me lay out the sequence we have in mind and > then the concrete reasons parity is not optional for us. > > The plan is staged. QDA is enabled first on new platforms, where there > is no existing userspace to migrate and the new UAPI can be exercised > properly. In parallel we close the remaining feature gaps against > fastrpc. Once parity is reached we migrate the older platforms onto QDA > and remove drivers/misc/fastrpc.c. The end state is one driver, not two. > > On why parity will actually happen: the DSP firmware is not changing. > Both drivers implement the same base protocol against the same firmware > image, so the feature set is defined by that firmware interface, not by > what we feel like implementing. For QDA to support a feature at all it > has to implement the same protocol operations fastrpc already does. > Parity is a property of the interface rather than of contributor enthusiasm. > > Other than the base protocol, there are some features(daemons, > capability, session sharing) that exist in fastrpc for performance etc. > but are not yet part of QDA. We want to implement them properly rather > than port them across as they stand. > > The remaining question is how fastrpc can actually be removed once > parity exists, without breaking existing userspace. That needs a > compatibility path, and it is a deliverable we are committed to rather > than an afterthought. For that, we need to settle is whether that path > is a userspace shim in the library, an in-kernel translation layer > exposing the legacy device nodes, or a hybrid. We evaluated an in-kernel > shim during v1 and hit constraints around constructing per-client > drm_file contexts from outside the DRM core, so the approach is still > open. I'll come back with a concrete proposal, and it will land before > fastrpc is removed rather than after. > >> >> Much better is to refine the old driver, gradually adding new features >> while maintaining old stuff. This is the only way we can force >> contributors to actively work on minimizing duplicate parts. >> > I believe you are suggesting we bring the new features we are developing > with DRM core utilities into the fastrpc driver. I don't think the two > interfaces can share one driver, though, and it isn't a question of code > size. > > fastrpc is a miscdevice: it accepts raw DMA-BUF fds as arguments and > tracks buffers in its own per-file lists, with the fd itself being the > buffer identity visible to the DSP. QDA is a drm_driver whose buffers > are GEM objects in a per-drm_file handle namespace, with PRIME used for > import and the GEM handle being the identity. These are two different > buffer ownership models, and neither can be expressed on the other's > file type. > > Supporting both from one driver therefore means carrying both models > simultaneously: two IOCTL surfaces, two buffer lifetimes, two teardown > paths, and a memory manager that has to serve both. That is two drivers > sharing a directory rather than one driver with two interfaces, and I > think it would be harder to review, and harder to eventually untangle, > than a separate driver with a stated removal plan. > > There is also a positive reason for being in the accel subsystem rather > than misc. We can build on existing DRM infrastructure instead of > reimplementing it: GEM for buffer management, the device and file > lifecycle, and the debug infrastructure. It also positions us for work > we have planned around scheduling, drm_gpuvm, etc. Over time this should > mean less driver-specific code, not more. > > I'll restructure the cover letter so the staged rollout, the > compatibility path and the eventual removal of drivers/misc/fastrpc.c > are stated properly. > > If after this you still want to add or change anything, please let me know. > > Thanks, > Ekansh> Best regards, Gentle ping on this thread. Wanted to check if there's any update on the compatible string and coexistence question above, since it's currently blocking respin. Thanks, Ekansh >> Krzysztof >