Message-ID: <8711522c-44e6-a923-1595-e82fcebf9df3@broadcom.com>
Date:   Tue, 29 Sep 2020 17:03:29 -0700
From:   Scott Branden <scott.branden@...adcom.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
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 2020-09-29 9:16 a.m., Greg Kroah-Hartman wrote:
> 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...
Replied in other email and published vkil:
https://github.com/Broadcom/vkil/
>
>> 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"?  
The card's processors have physical UARTs on the VK card as described in the other email.
Some of the processors' console programs can be accessed via "UART" emulated over PCIe interface.
> Is Linux running in there too?
One of the processors with a console does not run Linux.
Linux is currently running on one of the other processor complexes.  Before Linux boots low level boot code, ATF, etc can output to the same UART circular buffer.

>
> 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.
I described the lifetime dependencies of the tty device on the image loading and internal card resets.
It would take some time to figure out how to create the same dependency between multiple drivers.
If it helps, I can drop the tty patches from the current patch series and work on the tty afterwards.
>
> thanks,
>
> greg k-h


Download attachment "smime.p7s" of type "application/pkcs7-signature" (4169 bytes)

Powered by blists - more mailing lists