Date:   Tue, 29 Sep 2020 18:16:11 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Scott Branden <scott.branden@...adcom.com>
Cc:     Arnd Bergmann <arnd@...db.de>, Kees Cook <keescook@...omium.org>,
        linux-kernel@...r.kernel.org,
        bcm-kernel-feedback-list@...adcom.com,
        Desmond Yan <desmond.yan@...adcom.com>,
        James Hu <james.hu@...adcom.com>
Subject: Re: [PATCH v3 2/3] misc: bcm-vk: add Broadcom VK driver

On Fri, Sep 25, 2020 at 09:50:15AM -0700, Scott Branden wrote:
> Hi Greg,
> 
> On 2020-09-24 10:10 p.m., Greg Kroah-Hartman wrote:
> > On Thu, Sep 24, 2020 at 02:40:08PM -0700, Scott Branden wrote:
> >>> Ugh, yes, it is uncommon because those are two different things.  Why do
> >>> you need/want a misc driver to control a tty device?  Why do you need a
> >>> tty device?  What really is this beast?
> >> The beast consists of a PCI card.  The PCI card communicates to the host via shared memory in BAR space and MSIX interrupts.
> >> The host communicates through shared memory in BAR space and generates mailbox interrupts.
> > That describes any PCI card :)
> >
> >> In addition the PCI card has DMA access to host memory to access data for processing.
> >> The misc driver handles these operations.  Multiple user space processes are accessing the misc device at the same time
> >> to perform simultaenous offload operations.  Each process opens the device and sends multiple commands with write operations
> >> and receives solicited and unsolicited responses read read operations.  In addition there are sysfs entries to collect statistics and errors.
> >> Ioctl operations are present for loading new firmware images to the card and reset operations.
> >>
> >> In addition, the card has multiple physical UART connections to access consoles on multi processors on the card.
> >> But, in a real system there is no serial cable connected from the card to the server.  And, there could be 16 PCIe cards
> >> plugged into a server so that would make it even more unrealistic to access these consoles via a UART.
> >>
> >> Fortunately the data sent out to each physical UART exists in a circular buffer.  These circular buffer can be access via the host in BAR space.
> >> So we added tty device nodes per UART (2 per PCIe).  These are not the misc device node, these are seperate tty device nodes that are opened
> >> and behave like tty devices.
> >>
> >> We are not using the misc driver to control tty.
> >>   1) The PCI driver is the foundaton of it which provides the physical interface to the card, 2) misc driver is a presentation to user space to do its regular message - this allows user to treat it as a char-device, so its like fopen/read/write/close etc. and 3) tty is an additional debug channel which could be on or off.
> >>
> >> Please suggest how we can access the misc device and tty device nodes other than how we have implemented it in a single driver?
> > You haven't described what the card actually is for.  You describe how
> > you have tried to hook it up to userspace, but what is the use-case
> > here?
> The driver is used for real-time high performance, high throughput, low latency offload compute engine operations.
> These operations are used to offload tasks that take up far too much of a CPU to be run on a host which would only be able to run a few of these tasks.
> It is used for such tasks as: video and image processing and crypto.
> The card is capable of performing many of these task in parallel.  And, many of these cards can be plugged into the same system (say 16 cards).
> So instead of a host taking all its time running a single one of these tasks, 100's of these tasks can be performed instead.
> Of course, future cards will be able to perform even more operations, host memory bandwidth becoming a bottleneck.

So for off-load engines, as I mentioned in my patch review, we want to
also see the userspace library/applications/whatever as well, so that we
can properly review this type of thing.  Otherwise it's a mess...

> The main operation of the card is to receive commands from various user space operations to offload processing of data.
> This usually involves a sequence of offload operations.  The card will DMA the data from host memory and act upon it, signalling appropriate
> events back to the host.  At some point the card will typically write the data back to host memory via DMA.  Various statistics and events can also
> be queried via sysfs entries.  Crash and real time logs can also be retrieved.  User space processes need to be killed when the card resets or crashes so those tasks do not hang.  Console access to the card's processors is also required.

What do you mean by a "console access"?  Is Linux running in there too?

Anyway, if you want a TTY device to talk to the cpu/whatever, then
disconnect the tty device logic from your misc device logic, as you
can't keep the two bound together for obvious lifetime reasons.  I
mention that in the patch review as well.

thanks,

greg k-h

Powered by blists - more mailing lists