From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 026DBC07E9E for ; Tue, 6 Jul 2021 16:30:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D06AB600CC for ; Tue, 6 Jul 2021 16:29:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230154AbhGFQch (ORCPT ); Tue, 6 Jul 2021 12:32:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59384 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230149AbhGFQce (ORCPT ); Tue, 6 Jul 2021 12:32:34 -0400 Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3A72C06175F for ; Tue, 6 Jul 2021 09:29:55 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id z1so21408428ils.0 for ; Tue, 06 Jul 2021 09:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=etYc22i2Gl0Nevaba6RCpVnI4CJLkrAbQx/tp++WzW4=; b=QT4qJl6Njzuv/rc+EW47j005Go9tPi24idYG9F2hf6+7AESajcYJswCFXElQ8kFMby 3vxITIhL6oD5OvTn6ePN1zoUacBrQ5ffu1dB4JcTCI57bv9vthhfZgYhhhNqU+ePgyil 0oVjqkgbSnNJaSikDXvfN1uGA2r2rilepOECvDPAFz+i4YUySzo8ix4MsE7aC86tV60X iOE8CYqdzDybuCrmVxoL7WfhOPJx1E5WRlC0HlQ7DGrGnVNsT3Zk+Wbe3rSxO2v/33RX olRWd/DC6AGXPPFAvSitPnP8EShIrJOMYVTSz6I/9NOxcUk33s+sqTV1aJkNsz27Dc/v M/dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=etYc22i2Gl0Nevaba6RCpVnI4CJLkrAbQx/tp++WzW4=; b=VaBWuvVQaz45GMqVaUM3gd6jtiDJsii7ixx99f/d/0/HaHvAR3dCC4POtoavjt9aqU FFGRNi0kMrIipR0NBCxJ4sbXTSL3/6G1hyJg65k+TIXorItaDTqkfaou7tFR/HmHv2zl We0PSSIqe4tQAwLWG/XQ2IdZEdK5g4DiJft7pd7rgiuecpAS/7Ra0oqPuhKxQ/XNfz5u muXPVpi8rf3qPQKWvKaSelJ859YVSuMZdrvPJiUoJzp4zWJ2AHO7PhcNCZvCs8n5nZ9+ xXARqE0/jj7Pp9LmI0f+BC8kpYKmc18yfikgePMf0vf4SaFte6Qbq/arCKdfxNvFLGXO S96g== X-Gm-Message-State: AOAM531o+GG4qtHcYVq/T0Lox2Bws/xbdA1HkW4n9IXJ6Teaa4eh/B6p 9zNCk1Flt1gL+h509Tp1vdp97A== X-Google-Smtp-Source: ABdhPJz6bo5skYn6n6IU9DPSu+uSaHq70zWMOCxNpyUILydINIqb1PzqfwTHtoG8Ps83diFXVzV6Rw== X-Received: by 2002:a92:7f07:: with SMTP id a7mr14607133ild.202.1625588995298; Tue, 06 Jul 2021 09:29:55 -0700 (PDT) Received: from ziepe.ca ([206.223.160.26]) by smtp.gmail.com with ESMTPSA id r16sm8512490ilj.4.2021.07.06.09.29.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Jul 2021 09:29:54 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1m0nxJ-004TiJ-I6; Tue, 06 Jul 2021 13:29:53 -0300 Date: Tue, 6 Jul 2021 13:29:53 -0300 From: Jason Gunthorpe To: Daniel Vetter Cc: Oded Gabbay , Oded Gabbay , "Linux-Kernel@Vger. Kernel. Org" , Greg Kroah-Hartman , Sumit Semwal , Christian =?utf-8?B?S8O2bmln?= , Gal Pressman , sleybo@amazon.com, Maling list - DRI developers , linux-rdma , Linux Media Mailing List , Doug Ledford , Dave Airlie , Alex Deucher , Leon Romanovsky , Christoph Hellwig , amd-gfx list , "moderated list:DMA BUFFER SHARING FRAMEWORK" Subject: Re: [PATCH v4 0/2] Add p2p via dmabuf to habanalabs Message-ID: <20210706162953.GQ4604@ziepe.ca> References: <20210705130314.11519-1-ogabbay@kernel.org> <20210706142357.GN4604@ziepe.ca> <20210706152542.GP4604@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 06, 2021 at 05:49:01PM +0200, Daniel Vetter wrote: > The other thing to keep in mind is that one of these drivers supports > 25 years of product generations, and the other one doesn't. Sure, but that is the point, isn't it? To have an actually useful thing you need all of this mess > > My argument is that an in-tree open kernel driver is a big help to > > reverse engineering an open userspace. Having the vendors > > collaboration to build that monstrous thing can only help the end goal > > of an end to end open stack. > > Not sure where this got lost, but we're totally fine with vendors > using the upstream driver together with their closed stack. And most > of the drivers we do have in upstream are actually, at least in parts, > supported by the vendor. E.g. if you'd have looked the drm/arm driver > you picked is actually 100% written by ARM engineers. So kinda > unfitting example. So the argument with Habana really boils down to how much do they need to show in the open source space to get a kernel driver? You want to see the ISA or compiler at least? That at least doesn't seem "extreme" to me. > > For instance a vendor with an in-tree driver has a strong incentive to > > sort out their FW licensing issues so it can be redistributed. > > Nvidia has been claiming to try and sort out the FW problem for years. > They even managed to release a few things, but I think the last one is > 2-3 years late now. Partially the reason is that there don't have a > stable api between the firmware and driver, it's all internal from the > same source tree, and they don't really want to change that. Right, companies have no incentive to work in a sane way if they have their own parallel world. I think drawing them part by part into the standard open workflows and expectations is actually helpful to everyone. > > > I don't think the facts on the ground support your claim here, aside > > > from the practical problem that nvidia is unwilling to even create an > > > open driver to begin with. So there isn't anything to merge. > > > > The internet tells me there is nvgpu, it doesn't seem to have helped. > > Not sure which one you mean, but every once in a while they open up a > few headers, or a few programming specs, or a small driver somewhere > for a very specific thing, and then it dies again or gets obfuscated > for the next platform, or just never updated. I've never seen anything > that comes remotely to something complete, aside from tegra socs, > which are fully supported in upstream afaik. I understand nvgpu is the tegra driver that people actualy use. nouveau may have good tegra support but is it used in any actual commercial product? Jason