Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4606354imm; Mon, 14 May 2018 09:53:29 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqYYTs/9n5GKMhmrRh7824BvtQ9FIzKFNMiCwrvNkzrnAdLvByqSLtx5+sM4q5auOVQYmHL X-Received: by 2002:a17:902:14cb:: with SMTP id y11-v6mr10484346plg.229.1526316809741; Mon, 14 May 2018 09:53:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526316809; cv=none; d=google.com; s=arc-20160816; b=UgL80oWjLZTWGSXpDSS/Y8gU79L50IzA4LTc3Ke5d7X9F/roAlRZhZqyKJhUzSAJjj 1dsj1VQbPjJmzNJBni0VMI+PMkZVumt3lTsbVHIZ4PnnSiPM7M66LGNPDq8kxvJPnn/4 5jPq6VYtQuk1u1r/bUgdjAJD0RIEr9DGE5TbxAuQDEvd5PEykBirKEj/2YstX3KH8kp+ 5K1GmcYb3/LQNbRZoi4xv0OVOCZBY4JyzqowkoEEDZu5WvqkOnUzQluRIc06zQz2uTxd i4XSSGjUYPsKY5pKEb/xWFlvvJsUFIjJ9rppPJv+rLJsqWXeQ/ybvjIuHuXa5S7rHrkB bI8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:accept-language:in-reply-to:references:message-id :date:thread-index:thread-topic:subject:cc:to:from :arc-authentication-results; bh=dFd72QKFQ1fH44jBZ38iS51zwior1MZxcU5bLYPBg58=; b=JFhDreBtpLMbL8acp04TQCVdxWGhb5L8MJ5bKFgHqx+3mbnYVV77ZUe+tNmZ7RCrmi Iu0mZaHz/0iqQf/oHPJCPwUm+O/+4xz1LfWcjdp8TW5AN/74KJmO9HH4O6RwX1RxN2el aLoIl1OkWlXZGNUtZLlTZ9WJyow8e6BF82XrP1+BVQeXyfwTQ9rE0TGqsQQcdKVAxaEy C90gOccFEMoRbVKCxCmmJoeIrVwTvbpmUxskW7oljyObE8eSEFyWft6+vLJwmC0//kuc Zh9b0IofE+o/TwCnCK42X0BGpZrI5k1JfgYcmmjVLkxcS4Ft9dS6/sZiUt+GcLGGzF/Z vT5A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1-v6si8032698plr.483.2018.05.14.09.52.33; Mon, 14 May 2018 09:53:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753913AbeENOwh convert rfc822-to-8bit (ORCPT + 99 others); Mon, 14 May 2018 10:52:37 -0400 Received: from mx07-00178001.pphosted.com ([62.209.51.94]:15579 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752349AbeENOwf (ORCPT ); Mon, 14 May 2018 10:52:35 -0400 Received: from pps.filterd (m0046668.ppops.net [127.0.0.1]) by mx07-.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w4EEnY5F002399; Mon, 14 May 2018 16:52:33 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 2hwnqxavrh-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 May 2018 16:52:33 +0200 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 5BD5134; Mon, 14 May 2018 14:52:33 +0000 (GMT) Received: from Webmail-eu.st.com (sfhdag3node1.st.com [10.75.127.7]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 3DD41585F; Mon, 14 May 2018 14:52:33 +0000 (GMT) Received: from SFHDAG7NODE2.st.com (10.75.127.20) by SFHDAG3NODE1.st.com (10.75.127.7) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 14 May 2018 16:52:32 +0200 Received: from SFHDAG7NODE2.st.com ([fe80::d548:6a8f:2ca4:2090]) by SFHDAG7NODE2.st.com ([fe80::d548:6a8f:2ca4:2090%20]) with mapi id 15.00.1347.000; Mon, 14 May 2018 16:52:32 +0200 From: Loic PALLARDY To: Bjorn Andersson CC: "ohad@wizery.com" , "linux-remoteproc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Arnaud POULIQUEN , "benjamin.gaignard@linaro.org" Subject: RE: [PATCH v3 09/13] remoteproc: modify rproc_handle_carveout to support pre-registered region Thread-Topic: [PATCH v3 09/13] remoteproc: modify rproc_handle_carveout to support pre-registered region Thread-Index: AQHTsXm+pn7t5hJUkUCVCvRavBQVeqQoayMAgAdVZGA= Date: Mon, 14 May 2018 14:52:32 +0000 Message-ID: <35c35efde19e464285402786cba732ff@SFHDAG7NODE2.st.com> References: <1519921440-21356-1-git-send-email-loic.pallardy@st.com> <1519921440-21356-10-git-send-email-loic.pallardy@st.com> <20180510004244.GE29093@builder> In-Reply-To: <20180510004244.GE29093@builder> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.75.127.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-14_04:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----Original Message----- > From: Bjorn Andersson [mailto:bjorn.andersson@linaro.org] > Sent: Thursday, May 10, 2018 2:43 AM > To: Loic PALLARDY > Cc: ohad@wizery.com; linux-remoteproc@vger.kernel.org; linux- > kernel@vger.kernel.org; Arnaud POULIQUEN ; > benjamin.gaignard@linaro.org > Subject: Re: [PATCH v3 09/13] remoteproc: modify rproc_handle_carveout to > support pre-registered region > > On Thu 01 Mar 08:23 PST 2018, Loic Pallardy wrote: > > > In current version rproc_handle_carveout function support only dynamic > > region allocation. > > This patch extends rproc_handle_carveout function to support pre- > registered > > region. Match is done on region name, then requested device address and > > length are checked. > > If no name match found, original allocation is used. > > > > Signed-off-by: Loic Pallardy > > --- > > drivers/remoteproc/remoteproc_core.c | 49 > +++++++++++++++++++++++++++++++++++- > > 1 file changed, 48 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/remoteproc/remoteproc_core.c > b/drivers/remoteproc/remoteproc_core.c > > index 0ebbc4f..49b28a0 100644 > > --- a/drivers/remoteproc/remoteproc_core.c > > +++ b/drivers/remoteproc/remoteproc_core.c > > @@ -679,7 +679,7 @@ static int rproc_handle_carveout(struct rproc > *rproc, > > struct fw_rsc_carveout *rsc, > > int offset, int avail) > > { > > - struct rproc_mem_entry *carveout, *mapping = NULL; > > + struct rproc_mem_entry *carveout, *mapping = NULL, *mem; > > struct device *dev = &rproc->dev; > > dma_addr_t dma; > > void *va; > > @@ -699,6 +699,51 @@ static int rproc_handle_carveout(struct rproc > *rproc, > > dev_dbg(dev, "carveout rsc: name: %s, da 0x%x, pa 0x%x, len 0x%x, > flags 0x%x\n", > > rsc->name, rsc->da, rsc->pa, rsc->len, rsc->flags); > > > > + /* Check carveout rsc already part of a registered carveout */ > > + /* Search by name */ > > + mem = rproc_find_carveout_by_name(rproc, rsc->name); > > + if (mem) { > > I don't fancy the concept of "check if there is another registered > carveout and if so update this carveouts data based on that one and then > skip the bottom half of this function but keep them both on the > carveouts list". > > It's unfortunately not very easy to follow and it doesn't allow us to > reuse the carveout-handler for allocations in remoteprocs without a > resource table. > > How about splitting the handling of the resource table in two parts; one > that creates or updates a carveout on the carvouts list and a second > part that runs through all carveouts and "allocate" (similar to your > specific release function) them. > > > The first part of this function would then attempt to find a carveout > entry matching the one we're trying to "handle"; > > * if one is found we check if it's compatible (as you do here), update a > rsc_offset (as we do with vrings) and return. > > * if no match is found we create a new rproc_mem_entry, fill it out > based on the fw_rsc_carveout information and stash it at the end of > the carveouts list. > > We do the same in the other resource handlers (just allocate entries > onto the lists). > > > As that is done the second step is to loop over all carveouts, devmem, > trace and vdev resources and actually "allocate" the resources, by > calling a "alloc" function pointer next to your proposed release one. > > For memremap() memory this could be as simple as filling out the > resource table at the associated rsc_offset or simply doing the > memremap(). > > The default alloc (filled out in step 1, if not already specified) would > be what's today found in rproc_handle_carveout(). > > > This allows carveout resources not specified in the resource table to be > allocated as well. Which comes in handy for the handling of vdev > resources: > > In rproc_parse_vdev() we do a similar operation to the parser of a > fw_rsc_carveout and try to find an existing carveout by name and if not > create a new one on the list. > > As the actual allocation of carveouts is done before the "allocation" of > vrings there will be an allocated carveout ready when we hit > rproc_alloc_vring() - and we don't care if it came from > dma_alloc_coherent() or a driver defined region. > > > Does this sound reasonable? Yes, better to separate resource table parsing and memory carveout allocation. I'll update series in that way Regards, Loic > > Regards, > Bjorn