On Wed, Feb 19, 2020 at 04:48:24PM -0800, Scott Branden wrote:
Add Broadcom VK driver offload engine. This driver interfaces to the VK PCIe offload engine to perform should offload functions as video transcoding on multiple streams in parallel. VK device is booted from files loaded using request_firmware_into_buf mechanism. After booted card status is updated and messages can then be sent to the card. Such messages contain scatter gather list of addresses to pull data from the host to perform operations on.
Why is this a tty driver?
Have you worked with the V4L developers to tie this into the proper in-kernel apis for this type of functionality?
Using a tty driver seems like the totally incorrect way to do this, what am I missing?
Also, do not make up random error values, you return "-1" a lot here, that is not ok. Please fix up to return the correct -Ewhatever values instead.
thanks,
greg k-h
On 2020-02-19 11:47 p.m., Greg Kroah-Hartman wrote:
On Wed, Feb 19, 2020 at 04:48:24PM -0800, Scott Branden wrote:
Add Broadcom VK driver offload engine. This driver interfaces to the VK PCIe offload engine to perform should offload functions as video transcoding on multiple streams in parallel. VK device is booted from files loaded using request_firmware_into_buf mechanism. After booted card status is updated and messages can then be sent to the card. Such messages contain scatter gather list of addresses to pull data from the host to perform operations on.
Why is this a tty driver?
We have a tty driver here as there are (multiple) console interfaces to the card. The only viable interface to the card is through the PCIe bus. We can't hook up cables to the card to get at the consoles. As such we implemented a tty driver to access the console via a circular buffer in PCIe BAR space.
It is extremely useful. You get console access to virtual serial ports connected to each processor inside the VK SoC. Future enhancement is to connect the tty driver to use an MSIX interrupt rather than polling. Once that is done lrz/sz transfers will be much quicker. I'd also look at if I could use ser2net to get network access for the processors on the VK SoC over this interface as well.
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.
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.
Also, do not make up random error values, you return "-1" a lot here, that is not ok. Please fix up to return the correct -Ewhatever values instead.
OK.
thanks,
greg k-h
On Fri, Feb 21, 2020 at 7:19 PM Scott Branden scott.branden@broadcom.com 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.
Arnd
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@broadcom.com 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
On Sat, Feb 22, 2020 at 12:03 AM Arnd Bergmann arnd@arndb.de wrote:
On Fri, Feb 21, 2020 at 7:19 PM Scott Branden scott.branden@broadcom.com 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.
Uacce isn't a driver (or wasn't last time I looked at it, when it had 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.
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 has more value on the device than on the host, as far as I've 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/endpoint (from the other end) as the drivers/ntb (pci host on both ends) frameworks and of course the rpmsg/remoteproc framework do.
remoteproc is more about booting a tightly integrated device on an embedded system. Also not a match here IMHO.
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.
For a simple naive console/character stream, doing something on top of 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
Hi Olof/All,
I'm trying to digest all the feedback of what needs to be done. I will be fixing up all the valuable comments about general issues but would like to know what needs to be done about the tty interface.
The VK devices are configured to write serial data to circular buffers in memory or out a UART. When we configure a system using the UART we connect a cable to the host and open a tty device. When we don't connect a UART cable to the host we open the tty device in our driver instead. In this case the memory is exposed to the host via PCI BAR memory space. The bcm-vk host driver then accesses PCI space and presents a tty interface to the host. We implemented a tty device to present the tty interface. Host doesn't change anything other than opening a different devnode in UART vs. PCI case.
Based on all the comments: what interface should we be providing in driver instead?
On 2020-02-23 3:55 p.m., Olof Johansson wrote:
On Sat, Feb 22, 2020 at 12:03 AM Arnd Bergmann arnd@arndb.de wrote:
On Fri, Feb 21, 2020 at 7:19 PM Scott Branden scott.branden@broadcom.com 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.
Uacce isn't a driver (or wasn't last time I looked at it, when it had 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.
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 has more value on the device than on the host, as far as I've 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/endpoint (from the other end) as the drivers/ntb (pci host on both ends) frameworks and of course the rpmsg/remoteproc framework do.
remoteproc is more about booting a tightly integrated device on an embedded system. Also not a match here IMHO.
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.
For a simple naive console/character stream, doing something on top of 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
linux-kselftest-mirror@lists.linaro.org
-
Arnd Bergmann -
Greg Kroah-Hartman -
Olof Johansson -
Scott Branden