Possibly merge VCHIQ with MBOX?

[ghost]

I've been poking around VCHIQ for a bit and after I get past the part of VCHIQ needing some major TLC, I see a lot of potential in the component. It has a lot of ideas that appear to have been started, but never completed.

VCHIQ(aprox 10,000 lines of C code):

1. Canceling queuing a message.
2. Blocking vs. asynchronous I/O.
3. Multiple pending I/O transfers.
4. Multiple communication channels.
5. Based on shared memory.

MBOX on the other hand
MBOX(aprox 1,000 lines of C code):

1. Only one pending request/reply.
2. Also based on shared memory.

As I go through the source to the kernel, I'm seeing that their are not many things that actually use mbox and many of the cases that do could perhaps use some redesign. In fact, one of the main reasons for mbox seems to be to allocate a region of memory. Some examples of this are:

1. Video driver frame buffer allocation.
2. VCHIQ shared memory allocation.
3. RPI Touchscreen touch buffer allocation.
4. GPIO virtual buffer.

I'm thinking that all four of these mbox calls could be reduced or elimated by simply having the firmeware allocate the memory first and pass the address either through the device tree or through the command line options. This is already done today for the video frame buffer in case simplefb is going to be used. So why couldn't the same idea be used for the other 3 major cases?

In fact, in theory the only reason the video driver needs to use mbox at all is for changing the video mode(1024x768 vs 1920x1080). Today, the video mode isn't changed much because the number of pixels in the monitor is fixed and ideally the RPI should just use the native mode of the monitor. In fact, I couldn't get video mode switching to work at all in stock Raspbian. I'm only able to get mode switching to work at all with the vc4 driver.

Finally, my point is that perhaps mbox should be removed or possibly implemented on top of vchiq?

[ghost]

Ideally, it would be wise to keep VCHIQ optional and out of the bootup path. But I think reducing the dependency on mbox by having the firmware allocate buffers first would accomplish this.

[pelwell]

I can't see us abandoning the mbox interface. Mailbox drivers are a standard paradigm, and although they are limited they require no knowledge of the memory layout of the other side, and thus provide an obvious way to exchange configuration data at the start of day. You've noticed that mbox is used for memory allocation, but if those allocations were made static the ARM would still need to discover where they were allocated, and for that we would use mbox.

VCHIQ has a high throughput, but it also has protocol deficiencies that allow an errant process to halt all communications. Mbox is simple, uncontroversial and upstreamed, and performs a useful function. If other services need a way for the VPU and ARM to rendezvous it is the obvious candidate.

[ghost]

Yes, VCHIQ does need alot of TLC..

As for the allocations, they could be made a bootup time by the firmware and passed either though the device tree or command line. It's only when those allocations move would mbox be needed.

BTW, on a semi-related topic I was wondering what the plans are for a better system for managing allocations shared between the GPU and CPU. For example, if alot of 3D isn't in use the video driver doesn't need much shared memory. Open up that 3D video game, and the requirements spike. Close the game, and the memory should be returned to the CPU.

[pelwell]

There is a VCHIQ-based service for sharing memory via CMA (vccma), but we never got it to work reliably on very resource-constrained systems so it is not enabled by default.

All assets use by V3D need to be in the same 256M bank, and individual allocations must be contiguous - the V3D unit (like the rest of the VPU) has no MMU. We are working on improving the memory sharing by moving the driver to the ARM, so that it can benefit from flexible allocations without the need for round trips via the VPU.

[ghost]

Cool, that would reduce the need for mbox even more. The firmware powers up with a simple static based allocation, the kernel boots, and then when needed the vccma can be used to shuffle allocations around....

[6by9]

All assets use by V3D need to be in the same 256M bank

V3D hardware has the same restriction as the codec block then? I never knew that one.