On Wed, Jan 23, 2019 at 5:03 PM Andrew Donnellan <andrew.donnellan@xxxxxxxxxxx> wrote: > > On 24/1/19 8:52 am, Olof Johansson wrote: > > But, I think the largest question I have (for a broader audience) is: > > > > I predict that we will see a handful of these kind of devices over the > > upcoming future -- definitely from ML accelerators but maybe also for > > other kinds of processing, where there's a command-based, buffer-based > > setup sending workloads to an offload engine and getting results back. > > While the first waves will all look different due to design trade-offs > > made in isolation, I think it makes sense to group them in one bucket > > instead of merging them through drivers/misc, if nothing else to > > encourage more cross-collaboration over time. First steps in figuring > > out long-term suitable frameworks is to get a survey of a few > > non-shared implementations. > > > > So, I'd like to propose a drivers/accel drivers subtree, and I'd be > > happy to bootstrap it with a small group (@Dave Airlie: I think your > > input from GPU land be very useful, want to join in?). Individual > > drivers maintained by existing maintainers, of course. > > > > I think it might make sense to move the CAPI/OpenCAPI drivers over as > > well -- not necessarily to change those drivers, but to group them > > with the rest as more show up. > > For cxl/ocxl, I have no objection to moving to this new subtree if > that's what we all agree to do. (what do people do about UAPI headers in > this situation? keep them where they are in misc/?) How about moving them but keeping a stub in misc that just includes the moved file? > If we do go ahead and set up this new subtree, perhaps we can use the > mailing list I set up at linux-accelerators@xxxxxxxxxxxxxxxx but we > haven't really started using... I've lost all lists.ozlabs.org muscle memory these days, but that seems reasonable to me. -Olof
