On Fri, 9 Aug 2019 14:06:26 +0100 Jonathan Cameron <jonathan.cameron@xxxxxxxxxx> wrote: > On Thu, 8 Aug 2019 12:41:08 +0200 > Olof Johansson <olof@xxxxxxxxx> wrote: > > > On Thu, Aug 8, 2019 at 11:20 AM Zhangfei Gao <zhangfei.gao@xxxxxxxxxx> wrote: > > > > > > *WarpDrive* is a general accelerator framework for the user application to > > > access the hardware without going through the kernel in data path. > > > > > > WarpDrive is the name for the whole framework. The component in kernel > > > is called uacce, meaning "Unified/User-space-access-intended Accelerator > > > Framework". It makes use of the capability of IOMMU to maintain a > > > unified virtual address space between the hardware and the process. > > > > > > WarpDrive is intended to be used with Jean Philippe Brucker's SVA > > > patchset[1], which enables IO side page fault and PASID support. > > > We have keep verifying with Jean's sva/current [2] > > > We also keep verifying with Eric's SMMUv3 Nested Stage patch [3] > > > > > > This series and related zip & qm driver as well as dummy driver for qemu test: > > > https://github.com/Linaro/linux-kernel-warpdrive/tree/5.3-rc1-warpdrive-rc4 > > > > > > The library and user application: > > > https://github.com/Linaro/warpdrive/tree/wdprd-v1-current > > > > Hi, > > > > An overall comment: This isn't really an "accelerator framework" as > > much as a library for drivers to implement shared device/userspace > > memory regions where the hardware allows for it. In particular, it > > doesn't handle device-specific resource arbitration and > > (understandably) the other components needed for an actual driver. > > > > As such, it probably doesn't belong in drivers/misc per se, since it > > is more of a library to be used *by* drivers. It also doesn't fulfill > > the requirement of in-kernel interfaces having user when added, i.e. a > > real driver submitted that makes use of this library and implements > > the corresponding control path . > > The code is a bit hidden in that github branch above (not ideal!) > > drivers/crypto/hisilicon/zip/* I would imagine that was to > allow this side of the code to be proposed as an RFC whilst we > might potentially still have changes to the precursor patches. > > Given the kernel side of the zip driver was applied by Herbert > this morning, it would be good to rebase this tree on Herbert's > crypto tree and repost this series with that final patch included > so it is apparent how this actually fits with a crypto driver. > > Much easier to understand if everything is in front of us! > > Thanks > > Jonathan Ah my email filters went and hid zhangfei's similar response which provided more detail than I have here. Oops. Jonathan
