[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200910203848.GJ3354160@lunn.ch>
Date: Thu, 10 Sep 2020 22:38:48 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Oded Gabbay <oded.gabbay@...il.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
netdev@...r.kernel.org, SW_Drivers <SW_Drivers@...ana.ai>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH 00/15] Adding GAUDI NIC code to habanalabs driver
On Thu, Sep 10, 2020 at 11:30:33PM +0300, Oded Gabbay wrote:
> On Thu, Sep 10, 2020 at 11:25 PM Andrew Lunn <andrew@...n.ch> wrote:
> >
> > > Can you please elaborate on how to do this with a single driver that
> > > is already in misc ?
> > > As I mentioned in the cover letter, we are not developing a
> > > stand-alone NIC. We have a deep-learning accelerator with a NIC
> > > interface.
> >
> > This sounds like an MFD.
> >
> > Andrew
>
> Yes and no. There is only one functionality - training of deep
> learning (Accelerating compute operations) :)
> The rdma is just our method of scaling-out - our method of
> intra-connection between GAUDI devices (similar to NVlink or AMD
> crossfire).
> So the H/W exposes a single physical function at the PCI level. And
> thus Linux can call a single driver for it during the PCI probe.
Yes, it probes the MFD driver. The MFD driver then creates platform
drivers for the sub functions. i.e. it would create an Ethernet
platform driver. That then gets probed in the usual way. The child
device can get access to the parent device, if it needs to share
things, e.g. a device on a bus. This is typically I2C or SPI, but
there is no reason it cannot be a PCI device.
Go look in drivers/mfd.
Andrew
Powered by blists - more mailing lists