From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10D10C388F7 for ; Thu, 29 Oct 2020 01:22:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C575320757 for ; Thu, 29 Oct 2020 01:22:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603934557; bh=zOJDHvxAOzkt5Os8SlOZ13QHa0aFK9IK3J1D0wsqnHA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=T7nsrHqDXCQkEzam6jL8bPtt7QzQhXoHI4U9PWAXsHex+6oKoyrsNYTOG6p665CVO z5yXW9Vig+vdsRYr3ViItU2o2qw+Lgo8u9oNC4+QzUdqzLy5r0dVFqZL3yl7NteZ8C HjZ0KiE5ZzMmOnUp1ZEIaQz674hmGSGUvGAguHZM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729506AbgJ1WEw (ORCPT ); Wed, 28 Oct 2020 18:04:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:50718 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728553AbgJ1WCY (ORCPT ); Wed, 28 Oct 2020 18:02:24 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 72958247CA; Wed, 28 Oct 2020 15:41:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603899668; bh=zOJDHvxAOzkt5Os8SlOZ13QHa0aFK9IK3J1D0wsqnHA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=k/r+56tdl0xlwkYmlH+MWBq5lmWTQT7/pxd8Vwsb35WO0flZzuFApTEDboQM0KncS B1SJbO0SnpL7IVwCeF/2eY30sxIitNa1+02swnmeBxVfQDpp7jSsOpCBss4dmdFMhG cI/SQ1fIaZ5Ul3yxgIJp1E2SSusvDQFphdCmCpx8= Date: Wed, 28 Oct 2020 16:42:00 +0100 From: Greg KH To: Andy Duan Cc: Sherry Sun , "hch@infradead.org" , "vincent.whitchurch@axis.com" , "sudeep.dutt@intel.com" , "ashutosh.dixit@intel.com" , "arnd@arndb.de" , "kishon@ti.com" , "lorenzo.pieralisi@arm.com" , "linux-kernel@vger.kernel.org" , "linux-pci@vger.kernel.org" , dl-linux-imx Subject: Re: [EXT] Re: [PATCH V5 0/2] Change vring space from nomal memory to dma coherent memory Message-ID: <20201028154200.GB2780014@kroah.com> References: <20201028020305.10593-1-sherry.sun@nxp.com> <20201028055836.GA244690@kroah.com> <20201028070712.GA1649838@kroah.com> <20201028111351.GA1964851@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Wed, Oct 28, 2020 at 03:11:15PM +0000, Andy Duan wrote: > From: Greg KH Sent: Wednesday, October 28, 2020 7:14 PM > > On Wed, Oct 28, 2020 at 10:17:39AM +0000, Andy Duan wrote: > > > From: Greg KH Sent: Wednesday, October > > > 28, 2020 3:07 PM > > > > On Wed, Oct 28, 2020 at 06:05:28AM +0000, Sherry Sun wrote: > > > > > Hi Greg, > > > > > > > > > > > Subject: Re: [PATCH V5 0/2] Change vring space from nomal memory > > > > > > to dma coherent memory > > > > > > > > > > > > On Wed, Oct 28, 2020 at 10:03:03AM +0800, Sherry Sun wrote: > > > > > > > Changes in V5: > > > > > > > 1. Reorganize the vop_mmap function code in patch 1, which is > > > > > > > done by > > > > > > Christoph. > > > > > > > 2. Completely remove the unnecessary code related to reassign > > > > > > > the used ring for card in patch 2. > > > > > > > > > > > > > > The original vop driver only supports dma coherent device, as > > > > > > > it allocates and maps vring by _get_free_pages and > > > > > > > dma_map_single, but not use dma_sync_single_for_cpu/device to > > > > > > > sync the updates of device_page/vring between EP and RC, which > > > > > > > will cause memory synchronization problem for device don't support > > hardware dma coherent. > > > > > > > > > > > > > > And allocate vrings use dma_alloc_coherent is a common way in > > > > > > > kernel, as the memory interacted between two systems should > > > > > > > use consistent memory to avoid caching effects. So here add > > > > > > > noncoherent platform > > > > > > support for vop driver. > > > > > > > Also add some related dma changes to make sure noncoherent > > > > > > > platform works well. > > > > > > > > > > > > > > Sherry Sun (2): > > > > > > > misc: vop: change the way of allocating vrings and device page > > > > > > > misc: vop: do not allocate and reassign the used ring > > > > > > > > > > > > > > drivers/misc/mic/bus/vop_bus.h | 2 + > > > > > > > drivers/misc/mic/host/mic_boot.c | 9 ++ > > > > > > > drivers/misc/mic/host/mic_main.c | 43 ++------ > > > > > > > drivers/misc/mic/vop/vop_debugfs.c | 4 - > > > > > > > drivers/misc/mic/vop/vop_main.c | 70 +----------- > > > > > > > drivers/misc/mic/vop/vop_vringh.c | 166 ++++++++++------------------- > > > > > > > include/uapi/linux/mic_common.h | 9 +- > > > > > > > 7 files changed, 85 insertions(+), 218 deletions(-) > > > > > > > > > > > > Have you all seen: > > > > > > > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F% > > > > > > 25 > > > > > > > > > > > > 2Flore.kernel.org%2Fr%2F8c1443136563de34699d2c084df478181c205db4.16 > > > > > > > > > > > > 03854416.git.sudeep.dutt%40intel.com&data=04%7C01%7Csherry.sun% > > > > > > > > > > > > 40nxp.com%7Cc19c987667434969847e08d87b0685e8%7C686ea1d3bc2b4c6f > > > > > > > > > > > > a92cd99c5c301635%7C0%7C0%7C637394615238940323%7CUnknown%7CTW > > > > > > > > > > > > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX > > > > > > > > > > > > VCI6Mn0%3D%7C1000&sdata=Zq%2FtHWTq%2BuIVBYXFGoeBmq0JJzYd > > > > > > 9zDyv4NVN4TpC%2FU%3D&reserved=0 > > > > > > > > > > > > Looks like this code is asking to just be deleted, is that ok with you? > > > > > > > > > > Yes, I saw that patch. I'm ok with it. > > > > > > > > Great, can you please provide a "Reviewed-by:" or "Acked-by:" for it? > > > > > > > > thanks, > > > > > > > > greg k-h > > > > > > Sherry took much effort on the features support on i.MX series like > > i.MX8QM/i.MX8QXP/i.MX8MM. > > > > > > Now it is a pity to delete the vop code. > > > > > > One question, > > > can we resubmit vop code by clean up, now only for i.MX series as Dutt's > > suggestion ? > > > Or we have to drop the design and switch to select other solutions ? > > > > Okay, we plan to switch to NTB solution. What is a "NTB solution" exactly? > > > If this whole subsystem is being deleted because it is not used and never shipped, > > yes, please use a different solution. > > > > I don't understand why you were trying to piggy-back on this codebase if the > > hardware was totally different, for some reason I thought this was the same > > hardware. What exactly is this? > > Not the whole codebase, just the vop framework. That didn't answer the question at all, what are you all trying to do here, with what hardware, that the VOP code seemed like a good fit? thanks, greg k-h