Re: [git pull] habanalabs pull request for kernel 5.15
From: Daniel Vetter
Date: Fri Aug 20 2021 - 02:44:30 EST
On Thu, Aug 19, 2021 at 8:48 PM Dave Airlie <airlied@xxxxxxxxx> wrote:
> On Fri, 20 Aug 2021 at 03:07, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > On Thu, Aug 19, 2021 at 02:02:09PM +0300, Oded Gabbay wrote:
> > > Hi Greg,
> > >
> > > This is habanalabs pull request for the merge window of kernel 5.15.
> > > The commits divide roughly 50/50 between adding new features, such
> > > as peer-to-peer support with DMA-BUF or signaling from within a graph,
> > > and fixing various bugs, small improvements, etc.
> > Pulled and pushed out, thanks!
> NAK for adding dma-buf or p2p support to this driver in the upstream
> kernel. There needs to be a hard line between
> "I-can't-believe-its-not-a-drm-driver" drivers which bypass our
> userspace requirements, and I consider this the line.
> This driver was merged into misc on the grounds it wasn't really a
> drm/gpu driver and so didn't have to accept our userspace rules.
> Adding dma-buf/p2p support to this driver is showing it really fits
> the gpu driver model and should be under the drivers/gpu rules since
> what are most GPUs except accelerators.
> We are opening a major can of worms (some would say merging habanalabs
> driver opened it), but this places us in the situation that if a GPU
> vendor just claims their hw is a "vector" accelerator they can use
> Greg to bypass all the work that been done to ensure we have
> maintainability long term. I don't want drivers in the tree using
> dma-buf to interact with other drivers when we don't have access to a
> userspace project to validate the kernel driver assumptions.
I think everything that can be said has been said over the last few
years, here on m-l and at plumbers, so just for the record my +1.
There's no point in negotiation for years with accel companies in the
background if the guy next door just gleefully offers to get pulled
over the table, no questions asked.
Software Engineer, Intel Corporation