On Sat, Feb 22, 2020 at 12:03 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
On Fri, Feb 21, 2020 at 7:19 PM Scott BrandenUacce isn't a driver (or wasn't last time I looked at it, when it had
<scott.branden@xxxxxxxxxxxx> wrote:
On 2020-02-19 11:47 p.m., Greg Kroah-Hartman wrote:I see. Have you looked at the "uacce" driver submission? It seems
Have you worked with the V4L developers to tie this into the properWe looked at the V4L model doesn't have any support for anything we are
in-kernel apis for this type of functionality?
doing in this driver.
We also want a driver that doesn't care about video. It could be
offloading crypto or other operations.
We talked with Olof about all of this previously and he said leave it as
a misc driver for now.
He was going to discuss at linux plumbers conference that we need some
sort of offload engine model that such devices could fit into.
theirs is similar enough that there might be some way to share interfaces.
a different name). It's more of a framework for standardized direct HW
access from userspace, and relies on I/O virtualization to keep DMA
secure/partitioned, etc. VK is more of a classic PCIe device, it'll
handle DMA to/from the host, etc.
This has more value on the device than on the host, as far as I'veIn turn here, it sounds like you'd want to look at what drivers/misc/mic/Using a tty driver seems like the totally incorrect way to do this, whattty driver is used to provide console access to the processors running
am I missing?
on vk.
Data is sent using the bcm_vk_msg interface by read/write operations
from user space.
VK then gets the messages and DMA's the data to/from host memory when
needed to process.
and the mellanox bluefield drivers are doing. As I understand, they have the
same requirements for console, but have a nicer approach of providing
abstract 'virtio' channels between the PCIe endpoint and the host, and
then run regular virtio based drivers (console, tty, block, filesystem,
network, ...) along with application specific ones to provide the custom
high-level protocols.
seen it used (if you want to boot Linux on it and have things
exposed).
virtio isn't necessarily a match if all you really want is a character
stream for a console and don't need (or have performance requirements
beyond what virtio offers) other types of communication.
This is also similar to what the drivers/pci/endpointremoteproc is more about booting a tightly integrated device on an
(from the other end) as the drivers/ntb (pci host on both ends) frameworks
and of course the rpmsg/remoteproc framework do.
embedded system. Also not a match here IMHO.
In the long run, I would want much more consolidation between theFor a simple naive console/character stream, doing something on top of
low-level parts of all these frameworks, but moving your high-level
protocols to the same virtio method would sound like a step in the
direction towards a generialized framework and easier sharing of
the abstractions.
hvc might be easier -- it already does polling for you, etc.
Of course, the intent is not to ever use it as a console for the host
here, so that aspect of hvc isn't useful. But it gives you a bunch of
other stuff for free with just getchar/putchar interfaces to
implement.
-Olof