Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp536321imb; Fri, 1 Mar 2019 07:18:41 -0800 (PST) X-Google-Smtp-Source: APXvYqxitGs2+r88io7u5SSg0GD/Jn/TbAgLKLo1iwHWMZLIh450OihdaPdcG9utTgBfPPdyyKx2 X-Received: by 2002:a17:902:968b:: with SMTP id n11mr1868816plp.316.1551453521395; Fri, 01 Mar 2019 07:18:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551453521; cv=none; d=google.com; s=arc-20160816; b=QNcZcPFTikTPUktUzGY1CAgghsIH07Z5uDAjKo2sOTus9WN9BVFjO8v8caIW73mcs8 yRyts7EKhFK/SfTCQC/G12rXKwDkBqjHqGaFz8ZyfLaCb0VDQG+dEq9UYOk07PW/O0iK IQdmrfvcc71SUIYpto7W2QZA8ZneyxIwQKcR8DMx0ugBi3F4jK52AIn3ceIJC7rd3vVw 8yLfCAJKxQQUnFagbbb9cU7QnGn/N1n1YEaybBd3UgwvuGvhFSzYj8F2CjBn6f+2zVwN Ra8HVDDz1wvjX3lyj+fhDtONNONOOdf+vO8jUfLZr7WClo990j4Fb2o01V5UyvjiWR1n Tq7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=2hACK6tHDerSoCju9E8kfmgSvcVV1aCUWy9gSVXWFy0=; b=uTq41uWeQDriZHyqUOzMeZ4FwGeNzSUh13N80WK91yy/JxlKx4gY2Ip++pTXWGMmAd aTSOHAa8ba9NB2Vpn99LZ6hptqq2dU7WL01PmyUhrx2W34U/4yviRi8u3nsCWjU9Ttrq znrKw4LYldUw1/bh5kdTlwXusSAsLGdAg6c4r5NfI4McJrN1GMga5Hg7I7mTK5rh//bW Lq+dY8dspsEyG/KlYOgEI/8XGsmFcjd/Z9o6IrAaYEbtJPnE4/SxeP3eBMs+uNzVsVWN U7xBJnv+3/L+b445JlhSGlvHQPDNK/GWbOplR6f8EFcsLnivDLJzgDlZ4r3m0fr51o/0 o1eQ== 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 c16si20740986plo.412.2019.03.01.07.18.26; Fri, 01 Mar 2019 07:18:41 -0800 (PST) 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 S2388521AbfCAO0K (ORCPT + 99 others); Fri, 1 Mar 2019 09:26:10 -0500 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:39927 "EHLO relay4-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387536AbfCAO0J (ORCPT ); Fri, 1 Mar 2019 09:26:09 -0500 X-Originating-IP: 90.88.147.150 Received: from localhost (aaubervilliers-681-1-27-150.w90-88.abo.wanadoo.fr [90.88.147.150]) (Authenticated sender: antoine.tenart@bootlin.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id A823FE000D; Fri, 1 Mar 2019 14:26:02 +0000 (UTC) Date: Fri, 1 Mar 2019 15:26:02 +0100 From: Antoine Tenart To: Christoph Hellwig Cc: Brian Brooks , David Miller , antoine.tenart@bootlin.com, maxime.chevallier@bootlin.com, ymarkman@marvell.com, stefanc@marvell.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bjorn.topel@intel.com, brian.brooks@arm.com Subject: Re: [PATCH] net: mvpp2: avoid bouncing buffers Message-ID: <20190301142602.GC3554@kwain> References: <20180820024730.9147-1-brian.brooks@linaro.org> <20180819.195505.1988137313680465320.davem@davemloft.net> <20180820062326.GA22222@infradead.org> <20180827135524.fv4mxkwjn5bv7p5e@di3> <20180827154843.GA25821@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180827154843.GA25821@infradead.org> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Christoph, I saw you sent this patch as part of another series back in August, but it seems it was never applied and I can't find it even in -next. We made some tests and this patch is helping a lot the PPv2 engine driver in improving its performances. Do you plan on re-sending it, or reworking it? Are there current issues with it that prevent it from being merged upstream? Can we help in any way? Thanks! Antoine On Mon, Aug 27, 2018 at 08:48:43AM -0700, Christoph Hellwig wrote: > WE should basically never have dev->dma_mask = &dev->coherent_dma_mask, > so until that is the case you are doctoring around the symptoms and > not the problem. > > Does the patch below help your case? > > ---- > From 6294e0e330851ee06e66ab85b348f1d92d375d7a Mon Sep 17 00:00:00 2001 > From: Christoph Hellwig > Date: Mon, 27 Aug 2018 17:23:24 +0200 > Subject: driver core: initialize a default DMA mask for platform device > > We still treat devices without a DMA mask as defaulting to 32-bits for > both mask, but a few releases ago we've started warning about such > cases, as they require special cases to work around this sloppyness. > Add a dma_mask field to struct platform_object so that we can initialize > the dma_mask pointer in struct device and initialize both masks to > 32-bits by default. Architectures can still override this in > arch_setup_pdev_archdata if needed. > > Note that the code looks a little odd with the various conditionals > because we have to support platform_device structures that are > statically allocated. > > Signed-off-by: Christoph Hellwig > --- > drivers/base/platform.c | 15 +++++++++++++-- > include/linux/platform_device.h | 1 + > 2 files changed, 14 insertions(+), 2 deletions(-) > > diff --git a/drivers/base/platform.c b/drivers/base/platform.c > index dff82a3c2caa..baf4b06cf2d9 100644 > --- a/drivers/base/platform.c > +++ b/drivers/base/platform.c > @@ -225,6 +225,17 @@ struct platform_object { > char name[]; > }; > > +static void setup_pdev_archdata(struct platform_device *pdev) > +{ > + if (!pdev->dev.coherent_dma_mask) > + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); > + if (!pdev->dma_mask) > + pdev->dma_mask = DMA_BIT_MASK(32); > + if (!pdev->dev.dma_mask) > + pdev->dev.dma_mask = &pdev->dma_mask; > + arch_setup_pdev_archdata(pdev); > +}; > + > /** > * platform_device_put - destroy a platform device > * @pdev: platform device to free > @@ -271,7 +282,7 @@ struct platform_device *platform_device_alloc(const char *name, int id) > pa->pdev.id = id; > device_initialize(&pa->pdev.dev); > pa->pdev.dev.release = platform_device_release; > - arch_setup_pdev_archdata(&pa->pdev); > + setup_pdev_archdata(&pa->pdev); > } > > return pa ? &pa->pdev : NULL; > @@ -472,7 +483,7 @@ EXPORT_SYMBOL_GPL(platform_device_del); > int platform_device_register(struct platform_device *pdev) > { > device_initialize(&pdev->dev); > - arch_setup_pdev_archdata(pdev); > + setup_pdev_archdata(pdev); > return platform_device_add(pdev); > } > EXPORT_SYMBOL_GPL(platform_device_register); > diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h > index 1a9f38f27f65..d84ec1de6022 100644 > --- a/include/linux/platform_device.h > +++ b/include/linux/platform_device.h > @@ -25,6 +25,7 @@ struct platform_device { > int id; > bool id_auto; > struct device dev; > + dma_addr_t dma_mask; > u32 num_resources; > struct resource *resource; > > -- > 2.18.0 > -- Antoine T?nart, Bootlin Embedded Linux and Kernel engineering https://bootlin.com