From: Greg KH <[email protected]> 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 ?
Thanks,
Andy
On Wed, Oct 28, 2020 at 10:17:39AM +0000, Andy Duan wrote:
> From: Greg KH <[email protected]> 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 ?
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?
thanks,
greg k-h