Messages in this thread | | | From | Ohad Ben-Cohen <> | Date | Wed, 28 Mar 2012 17:55:25 +0200 | Subject | Re: Using remoteproc with ST-Ericsson modem. |
| |
Hi Sjur,
On Wed, Mar 28, 2012 at 11:33 AM, Sjur BRENDELAND <sjur.brandeland@stericsson.com> wrote: > 1) Resource descriptors and parameters such as size of vring, > size of the "carved-out" shared memory
We have that already today - the firmware controls these kind of parameters (and more).
> as well as proprietary (CAIF specific) parameters
Not sure what exactly do you mean here - can you pls elaborate ?
> should be supported. These parameters > must be available to the Virtio device-drivers
Virtio configuration is done via the virtio config space, which we should already be supporting (untested though, because we didn't need this yet).
> (CAIF interface), > and to the modem. The resource/parameter configuration has to be > stored in shared memory before booting the modem.
Yeah, this is what we do today with the resource table.
> 2a) The resource descriptors and configuration parameters are pre- > formatted in the proprietary binary format.
What does mandate this proprietary binary format ? Can you just directly use remoteproc's resource table format instead (i.e. an extensible collection of type-value pairs) ?
> Remoteproc (or it's plugin) > must then be able to parse this proprietary format, extract > configuration parameters, and load the binary image into shared memory. > OR > 2b) Configuration parameters and firmware can be provided separately. > The remoteproc (or it's plugin) must be able to format the provided > configuration parameters in a proprietary format understood by the > modem boot-loader and store the firmware and configuration in > shared memory. A user-space API for configuration (e.g. netlink) > must be supported. > OR > 2c) As in 2a, the image in proprietary format containing both firmware > and parameters could be provided. In addition configuration parameters > could be provided to remoteproc separately. The binary-image and > configuration parameters will in this case hold identical configuration > information. A user-space API for configuration (e.g. netlink) > must be supported. > > In my case, the best solution seems to be 2a). I.e to parse parameters > from the provided firmware, and avoid any extra configuration parameters > provided from user-space. It seems to me we could do this by adding a > callback function to remoteproc that parses the firmware and returns > a resource table.
You have suggested several possible solutions, but I'd really prefer to understand the problem first please :)
Can you please explain how do things work for you today ? binary formats, image/configuration, how things boot/load/get-configured, etc..
If I'll understand your requirements (hardware, relevant firmware code which can't be changed and may impose the design, etc..) it will help me find with you a suitable solution.
> However there might be new requirements we have in common such as: > buffer pools with different fixed sized buffers, zero-copy handling of > SKBs (TX), and DMA for (RX). Even if I end up not using rpmsg we should > definitely look for opportunities for common code. I think we will be > trying to solve the same type of problems.
The main thing that rpmsg provides over virtio is the multiplexing of several channels/drivers over the same set of vrings and a simple API for doing TX/RX.
If you think you will have to implement similar plumbing, then please consider using rpmsg - it will save you time and effort (any other gap that rpmsg does not yet provide can be easily solved - I wouldn't worry about it).
OTOH, if you don't need that aforementioned plumbing, then directly using virtio does have its merit of course.
Thanks, Ohad.
| |