Message ID | 20230511141146.30465-2-me@dylanvanassche.be |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6358:3046:b0:115:7a1d:dabb with SMTP id p6csp4469674rwl; Thu, 11 May 2023 07:15:43 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4i0X70ZJIcpefWY/T4wZ8Z8mmvgnMxwBldoUBDU0Rh0U+oQn8SWu14sGVKmSRsQiCWu4fT X-Received: by 2002:a17:902:efc5:b0:19c:f096:bbef with SMTP id ja5-20020a170902efc500b0019cf096bbefmr19717473plb.49.1683814543388; Thu, 11 May 2023 07:15:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683814543; cv=none; d=google.com; s=arc-20160816; b=SLvBSxyLjt6PEhYZSEa4UwE642ODtRL+r7OMCYvKB5qtuIMeQQtwa1XrRYCATE9ZXR tpSX12GifOr/ckSs2WLEiOLZNv8wqDoTWoWu1990D27X8ySIcBBYuNDssTjB/SvqajdS q1PRts+76YahiP546KSSdj4aZtbkL7HCRRuHI6hpbg5RM7OTV9LOwTdI88czMUH7FOEs xa4DtASTLxkro5QDlYk8xLDqlA4naXoKTBNWQODWkQo95HHKZD11h6fwdhYT2uUpDa9F EVswGtOu4DdWpnVORyMUA5Q/7iHa38oa+590sl72yMVbwd9kwYcMZOF2dnL+fdUI08Ub yBAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=l2otcDdUshgA/c9L7n2sngTXTgjQKeWeYo6cxQJutfE=; b=FQRNq4bC2rwqbReeX1ufqAaXLyOhOCb8B8wXJabw5i6TCHoBRhgpJC7dN+3hB/+bgQ iXRmsp796LrggW3HByRlgDYVkVo/N6bjtMUXa00LigEjVKeXhZwNjN0x/GP4kChFaIje OueZrFe9Yp3t+klvqBDjvF5cF6pQzXDSWm9lxDE43yy35zuAg5DhAJPp/m9g4QNDQHma hyViF1JW1XE/+9HMtsc9CKH0FAc5cSHoqZIOqEb+dd3ODsqHwjEMYnezalK7UFuC1E32 s94OBbq/0W6ZLtsVnXu2goXFQzoa2Eh+8Z8YJRmTZhQTsfi4VhLcnxNeo2HVHF9/ofiY Wi1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dylanvanassche.be header.s=MBO0001 header.b=VO9CwJzG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=dylanvanassche.be Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e7-20020a17090301c700b001aaf08eae06si7546538plh.591.2023.05.11.07.15.27; Thu, 11 May 2023 07:15:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@dylanvanassche.be header.s=MBO0001 header.b=VO9CwJzG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=dylanvanassche.be Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237798AbjEKONc (ORCPT <rfc822;peekingduck44@gmail.com> + 99 others); Thu, 11 May 2023 10:13:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58298 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237997AbjEKON1 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 11 May 2023 10:13:27 -0400 Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 227E7A240; Thu, 11 May 2023 07:12:41 -0700 (PDT) Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4QHDNb6kB2z9sZD; Thu, 11 May 2023 16:11:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dylanvanassche.be; s=MBO0001; t=1683814319; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=l2otcDdUshgA/c9L7n2sngTXTgjQKeWeYo6cxQJutfE=; b=VO9CwJzGrBO1Spq63OV3oM5pIeShIfHHKAr8IWzkHKJUP+gGR6ZYeI53x9m7Q5+h8ByFJf v7mvRcPkmBztyE6xxsXnDtU9vHJ9pdfezDSNUA9VBdcYd/w4HBSlxPUyY9euIHJbLW1io8 8tm8vau+bxg+/c05UYrtklYN28EHOTkASLv9UZTpNfGkS4tsh/MtPCHJB85QdB88c7RBbn +2mtkrky87rJn6x4I3Db+AzL++HyqDm/3zA98XsfHLFZzFHNWoSwBmKuxx7va5VWwkhhIB 29gOMPhPm8Ah01gjkGyLqetyiZDd28nXHS0E2GQDyYYKXJpx7We5PjtNrr79Eg== From: Dylan Van Assche <me@dylanvanassche.be> To: srinivas.kandagatla@linaro.org, amahesh@qti.qualcomm.com, arnd@arndb.de, gregkh@linuxfoundation.org Cc: linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, ~postmarketos/upstreaming@lists.sr.ht, phone-devel@vger.kernel.org, dan.carpenter@linaro.org, Dylan Van Assche <me@dylanvanassche.be>, Caleb Connolly <caleb.connolly@linaro.org> Subject: [PATCH v4 1/2] misc: fastrpc: support complete DMA pool access to the DSP Date: Thu, 11 May 2023 16:11:45 +0200 Message-Id: <20230511141146.30465-2-me@dylanvanassche.be> In-Reply-To: <20230511141146.30465-1-me@dylanvanassche.be> References: <20230511141146.30465-1-me@dylanvanassche.be> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765607518888082271?= X-GMAIL-MSGID: =?utf-8?q?1765607518888082271?= |
Series |
misc: fastrpc: FastRPC reserved memory assignment for SDM845 SLPI
|
|
Commit Message
Dylan Van Assche
May 11, 2023, 2:11 p.m. UTC
To support FastRPC Context Banks which aren't mapped via the SMMU, make the whole reserved memory region available to the DSP to allow access to coherent buffers. This is performed by assigning the memory to the DSP via a hypervisor call to set the correct permissions for the Virtual Machines on the DSP. This is only necessary when a memory region is provided for SLPI DSPs so guard this with a domain ID check. Signed-off-by: Dylan Van Assche <me@dylanvanassche.be> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> --- drivers/misc/fastrpc.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
Comments
On 11/05/2023 15:11, Dylan Van Assche wrote: > To support FastRPC Context Banks which aren't mapped via the SMMU, > make the whole reserved memory region available to the DSP to allow > access to coherent buffers. Mapping the whole region sounds very inefficient, and also possibly making the cma region not usable by others. > AFAIU SDM845 does not have any context banks for SDSP. All new SoCs after 865 have moved to having a context bank. For such cases (w/o cb) we can make fastrpc_session_alloc use channel context device instead of session ctx device. As this is going to be an issue when we try to allocate buffers dynamically for that cb. In the newer platforms (from 865) there is support for iommu and context banks on SDSP, so the existing code flow is identical for both ADSP and SDSP. We should be careful not to break newer platfroms while adding support to this. Both myself and Ekansh thought about this and see that the better way to add support to this is by 1. extend fastrpc_session_alloc() to support zero context banks. 2. add flags to mark this and allocate meta data using secure allocation when its required based on this flag. 3. buffer allocation can either go with 2 or with a new flag coming from userspace. > This is performed by assigning the memory to the DSP via a hypervisor > call to set the correct permissions for the Virtual Machines on the DSP. > This is only necessary when a memory region is provided for SLPI DSPs > so guard this with a domain ID check. > > Signed-off-by: Dylan Van Assche <me@dylanvanassche.be> > Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> > --- > drivers/misc/fastrpc.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c > index f48466960f1b..1ced553ae959 100644 > --- a/drivers/misc/fastrpc.c > +++ b/drivers/misc/fastrpc.c > @@ -2231,6 +2231,8 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev) > int i, err, domain_id = -1, vmcount; > const char *domain; > bool secure_dsp; > + struct device_node *rmem_node; > + struct reserved_mem *rmem; > unsigned int vmids[FASTRPC_MAX_VMIDS]; > > err = of_property_read_string(rdev->of_node, "label", &domain); > @@ -2274,6 +2276,19 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev) > } > } > > + rmem_node = of_parse_phandle(rdev->of_node, "memory-region", 0); > + if (domain_id == SDSP_DOMAIN_ID && rmem_node) { > + rmem = of_reserved_mem_lookup(rmem_node); > + if (!rmem) { > + err = -EINVAL; > + goto fdev_error; > + } > + > + qcom_scm_assign_mem(rmem->base, rmem->size, &data->perms, > + data->vmperms, data->vmcount); vmperms need to be a bit field. > + > + } > + > secure_dsp = !(of_property_read_bool(rdev->of_node, "qcom,non-secure-domain")); > data->secure = secure_dsp; > --srini
On 30/05/2023 11:52, Srinivas Kandagatla wrote: > On 11/05/2023 15:11, Dylan Van Assche wrote: >> To support FastRPC Context Banks which aren't mapped via the SMMU, >> make the whole reserved memory region available to the DSP to allow >> access to coherent buffers. > > Mapping the whole region sounds very inefficient, and also possibly > making the cma region not usable by others. Probably I'm missing something obvious here... The downstream driver maps the whole region, what are the advantages to doing it on a per-allocation basis? What are the other users? > >> > > AFAIU SDM845 does not have any context banks for SDSP. All new SoCs > after 865 have moved to having a context bank. > > For such cases (w/o cb) we can make fastrpc_session_alloc use channel > context device instead of session ctx device. As this is going to be an > issue when we try to allocate buffers dynamically for that cb. Right.. This is what patch 2 does, but presumably the ALLOC_DMA_BUF, MMAP, etc ioctls won't work with the current iteration? > > In the newer platforms (from 865) there is support for iommu and context > banks on SDSP, so the existing code flow is identical for both ADSP and > SDSP. > > > We should be careful not to break newer platfroms while adding support > to this. > > Both myself and Ekansh thought about this and see that the better way to > add support to this is by > > 1. extend fastrpc_session_alloc() to support zero context banks. > > 2. add flags to mark this and allocate meta data using secure allocation > when its required based on this flag. > > 3. buffer allocation can either go with 2 or with a new flag coming > from userspace. This sounds pretty good to me! > > > >> This is performed by assigning the memory to the DSP via a hypervisor >> call to set the correct permissions for the Virtual Machines on the DSP. >> This is only necessary when a memory region is provided for SLPI DSPs >> so guard this with a domain ID check. >> >> Signed-off-by: Dylan Van Assche <me@dylanvanassche.be> >> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> >> --- >> drivers/misc/fastrpc.c | 15 +++++++++++++++ >> 1 file changed, 15 insertions(+) >> >> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c >> index f48466960f1b..1ced553ae959 100644 >> --- a/drivers/misc/fastrpc.c >> +++ b/drivers/misc/fastrpc.c >> @@ -2231,6 +2231,8 @@ static int fastrpc_rpmsg_probe(struct >> rpmsg_device *rpdev) >> int i, err, domain_id = -1, vmcount; >> const char *domain; >> bool secure_dsp; >> + struct device_node *rmem_node; >> + struct reserved_mem *rmem; >> unsigned int vmids[FASTRPC_MAX_VMIDS]; >> err = of_property_read_string(rdev->of_node, "label", &domain); >> @@ -2274,6 +2276,19 @@ static int fastrpc_rpmsg_probe(struct >> rpmsg_device *rpdev) >> } >> } >> + rmem_node = of_parse_phandle(rdev->of_node, "memory-region", 0); >> + if (domain_id == SDSP_DOMAIN_ID && rmem_node) { >> + rmem = of_reserved_mem_lookup(rmem_node); >> + if (!rmem) { >> + err = -EINVAL; >> + goto fdev_error; >> + } >> + >> + qcom_scm_assign_mem(rmem->base, rmem->size, &data->perms, >> + data->vmperms, data->vmcount); > > vmperms need to be a bit field. > >> + >> + } >> + >> secure_dsp = !(of_property_read_bool(rdev->of_node, >> "qcom,non-secure-domain")); >> data->secure = secure_dsp; >> > > --srini
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c index f48466960f1b..1ced553ae959 100644 --- a/drivers/misc/fastrpc.c +++ b/drivers/misc/fastrpc.c @@ -2231,6 +2231,8 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev) int i, err, domain_id = -1, vmcount; const char *domain; bool secure_dsp; + struct device_node *rmem_node; + struct reserved_mem *rmem; unsigned int vmids[FASTRPC_MAX_VMIDS]; err = of_property_read_string(rdev->of_node, "label", &domain); @@ -2274,6 +2276,19 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev) } } + rmem_node = of_parse_phandle(rdev->of_node, "memory-region", 0); + if (domain_id == SDSP_DOMAIN_ID && rmem_node) { + rmem = of_reserved_mem_lookup(rmem_node); + if (!rmem) { + err = -EINVAL; + goto fdev_error; + } + + qcom_scm_assign_mem(rmem->base, rmem->size, &data->perms, + data->vmperms, data->vmcount); + + } + secure_dsp = !(of_property_read_bool(rdev->of_node, "qcom,non-secure-domain")); data->secure = secure_dsp;