Re: [EXT] Re: [PATCH V5 0/2] Change vring space from nomal memory to dma coherent memory

[Greg KH]

On Wed, Oct 28, 2020 at 03:11:15PM +0000, Andy Duan wrote:
> From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> Sent: Wednesday, October 28, 2020 7:14 PM
> > On Wed, Oct 28, 2020 at 10:17:39AM +0000, Andy Duan wrote:
> > > From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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&amp;data=04%7C01%7Csherry.sun%
> > > > > >
> > > >
> > 40nxp.com%7Cc19c987667434969847e08d87b0685e8%7C686ea1d3bc2b4c6f
> > > > > >
> > > >
> > a92cd99c5c301635%7C0%7C0%7C637394615238940323%7CUnknown%7CTW
> > > > > >
> > > >
> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > > > > >
> > > >
> > VCI6Mn0%3D%7C1000&amp;sdata=Zq%2FtHWTq%2BuIVBYXFGoeBmq0JJzYd
> > > > > > 9zDyv4NVN4TpC%2FU%3D&amp;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