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

From: Jeffrey Hugo
Date: Tue May 19 2020 - 14:26:16 EST

On 5/19/2020 12:12 PM, Greg Kroah-Hartman wrote:
On Tue, May 19, 2020 at 12:07:03PM -0600, Jeffrey Hugo wrote:
On 5/19/2020 11:41 AM, 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.

Fair enough. I hope that your position may have made things easier for me.

I hope this doesn't widen the rift as it were, but what is the "bar" for
this userspace?

Is a simple test application that adds two numbers on the hardware
acceptable?

Make it the real library that you use for your applications that anyone
can then also use as well if they have the hardware. Why would you want
something "crippled"?

It makes it easier to dance around real or perceived IP issues, and thus I can likely more successfully "push upward" as you put it.


What is the bar "working"? I intend to satisfy this request in good faith,
but I wonder, if no one has the hardware besides our customers, and possibly
KernelCI, can you really say that I've provided a working userspace?

How do you know who your customers really are, or who they sell the
chips to? I could end up with one of these... :)

At this time, I don't think that is going to happen, but I would like to see it regardless.

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 :)

Those are the kind of conversations I try to avoid :)

Sounds like you are going to now have to have them, have fun!

Honestly, I fail to see where you think there is a derivative work, so, I'm not really sure what discussions I need to revisit with our lawyers.

--
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.