Re: [RFC PATCH 0/8] Qualcomm Cloud AI 100 driver

[Daniel Vetter]

On Tue, May 19, 2020 at 07:41:20PM +0200, Greg Kroah-Hartman wrote:
> On Tue, May 19, 2020 at 08:57:38AM -0600, Jeffrey Hugo wrote:
> > On 5/18/2020 11:08 PM, Dave Airlie wrote:
> > > On Fri, 15 May 2020 at 00:12, Jeffrey Hugo <jhugo@xxxxxxxxxxxxxx> wrote:
> > > >
> > > > Introduction:
> > > > Qualcomm Cloud AI 100 is a PCIe adapter card which contains a dedicated
> > > > SoC ASIC for the purpose of efficently running Deep Learning inference
> > > > workloads in a data center environment.
> > > >
> > > > The offical press release can be found at -
> > > > https://www.qualcomm.com/news/releases/2019/04/09/qualcomm-brings-power-efficient-artificial-intelligence-inference
> > > >
> > > > The offical product website is -
> > > > https://www.qualcomm.com/products/datacenter-artificial-intelligence
> > > >
> > > > At the time of the offical press release, numerious technology news sites
> > > > also covered the product.  Doing a search of your favorite site is likely
> > > > to find their coverage of it.
> > > >
> > > > It is our goal to have the kernel driver for the product fully upstream.
> > > > The purpose of this RFC is to start that process.  We are still doing
> > > > development (see below), and thus not quite looking to gain acceptance quite
> > > > yet, but now that we have a working driver we beleive we are at the stage
> > > > where meaningful conversation with the community can occur.
> > >
> > >
> > > Hi Jeffery,
> > >
> > > Just wondering what the userspace/testing plans for this driver.
> > >
> > > This introduces a new user facing API for a device without pointers to
> > > users or tests for that API.
> >
> > We have daily internal testing, although I don't expect you to take my word
> > for that.
> >
> > I would like to get one of these devices into the hands of Linaro, so that
> > it can be put into KernelCI.  Similar to other Qualcomm products. I'm trying
> > to convince the powers that be to make this happen.
> >
> > Regarding what the community could do on its own, everything but the Linux
> > driver is considered proprietary - that includes the on device firmware and
> > the entire userspace stack.  This is a decision above my pay grade.
>
> Ok, that's a decision you are going to have to push upward on, as we
> really can't take this without a working, open, userspace.

Uh wut.

So the merge criteria for drivers/accel (atm still drivers/misc but I
thought that was interim until more drivers showed up) isn't actually
"totally-not-a-gpu accel driver without open source userspace".

Instead it's "totally-not-a-gpu accel driver without open source
userspace" _and_ you have to be best buddies with Greg. Or at least
not be on the naughty company list. Since for habanalabs all you
wanted is a few test cases to exercise the ioctls. Not the entire
userspace.

The most bonkers part here is that drivers/gpu actually does have a bunch
of active contributors from codeaurora ...

> Especially given the copyright owner of this code, that would be just
> crazy and foolish to not have open userspace code as well.  Firmware
> would also be wonderful as well, go poke your lawyers about derivative
> work issues and the like for fun conversations :)
>
> So without that changed, I'm not going to take this, and push to object
> that anyone else take this.
>
> I'm not going to be able to review any of this code anymore until that
> changes, sorry.

So you couldn't review the habanalabs driver either?

Get some consistency into your decision making as maintainer. And don't
tell me or anyone else that this is complicated, gpu and rdma driver folks
very much told you and Olof last year that this is what you're getting
yourself into.

Cheers, Daniel

PS: I guess congrats for figuring out you can't write a totally-not-a-gpu
accel driver without making kernel and userspace parts derivatives works
of each another. We told you that last year.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch