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
