On Sat, Feb 22, 2020 at 09:02:44AM +0100, Arnd Bergmann wrote: > On Fri, Feb 21, 2020 at 7:19 PM Scott Branden > <scott.branden@xxxxxxxxxxxx> wrote: > > On 2020-02-19 11:47 p.m., Greg Kroah-Hartman wrote: > > > > Have you worked with the V4L developers to tie this into the proper > > > in-kernel apis for this type of functionality? > > We looked at the V4L model doesn't have any support for anything we are > > 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. > > I see. Have you looked at the "uacce" driver submission? It seems > theirs is similar enough that there might be some way to share interfaces. > > > > Using a tty driver seems like the totally incorrect way to do this, what > > > am I missing? > > tty driver is used to provide console access to the processors running > > 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. > > In turn here, it sounds like you'd want to look at what drivers/misc/mic/ > 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. This is also similar to what the drivers/pci/endpoint > (from the other end) as the drivers/ntb (pci host on both ends) frameworks > and of course the rpmsg/remoteproc framework do. > > In the long run, I would want much more consolidation between the > 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. I agree, please do not override the generic tty api with something so hardware-specific like this as it really is not a serial device here. thanks, greg k-h
