From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750995AbeAOUob convert rfc822-to-8bit (ORCPT + 1 other); Mon, 15 Jan 2018 15:44:31 -0500 Received: from mx07-00178001.pphosted.com ([62.209.51.94]:40650 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750737AbeAOUo3 (ORCPT ); Mon, 15 Jan 2018 15:44:29 -0500 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 v2 12/16] remoteproc: look-up memory-device for vring allocation Thread-Topic: [PATCH v2 12/16] remoteproc: look-up memory-device for vring allocation Thread-Index: AQHTafrjxOv3m00YQ0iFF428pAA9h6NCFVWAgDOXmkA= Date: Mon, 15 Jan 2018 20:44:26 +0000 Message-ID: <638aed21e2cd4b1d9144a75e92a88f36@SFHDAG7NODE2.st.com> References: <1512060411-729-1-git-send-email-loic.pallardy@st.com> <1512060411-729-13-git-send-email-loic.pallardy@st.com> <20171214014407.GM17344@builder> In-Reply-To: <20171214014407.GM17344@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.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-15_09:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: > -----Original Message----- > From: Bjorn Andersson [mailto:bjorn.andersson@linaro.org] > Sent: Thursday, December 14, 2017 2:44 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 v2 12/16] remoteproc: look-up memory-device for vring > allocation > > On Thu 30 Nov 08:46 PST 2017, Loic Pallardy wrote: > > } else { > > + /* Find any carveout matching vring */ > > + /* Try dedicated vdev j vring i pool. */ > > + snprintf(name, sizeof(name), "vdev%dvring%d", rvdev- > >index, i); > > + carveout = rproc_find_carveout_by_name(rproc, name); > > This might match a carveout representing remapped device memory, which > wouldn't have a memdev so the logic below would silently allocate from > the parent dma_mem instead. > > I don't think this is user friendly and would be better to just use the > information in the already mapped carveout. Yes best will be to have a "real" device. If over memory config, dma allocation will rely on dedicated memory pool, else on generic one. > > > + > > + if (!carveout) { > > + /* Try dedicated vdev j vrings pool. */ > > + snprintf(name, sizeof(name), "vdev%dvring", rvdev- > >index); > > + carveout = rproc_find_carveout_by_name(rproc, > name); > > + } > > + > > + if (carveout && carveout->memdev) > > + memdev = &carveout->memdev->dev; > > + > > + rvring->dev = memdev; > > + > > /* > > * Allocate non-cacheable memory for the vring. In the future > > * this call will also configure the IOMMU for us > > */ > > - va = dma_alloc_coherent(dev->parent, size, &dma, > GFP_KERNEL); > > + va = dma_alloc_coherent(memdev, size, &dma, > GFP_KERNEL); > > It's possible that you have fulfilled a resource_table carveout request > with this memory, making the dynamic allocation likely to cause issues. > Yes if memory carveout is not dedicated to vring, indeed some other allocations could have been done before... In that case it means the region is not well sized and firmware and associated resources can't be supported /Loic > > if (!va) { > > dev_err(dev->parent, "dma_alloc_coherent > failed\n"); > > return -EINVAL; > > Regards, > Bjorn