Hi Arnd, >> However for the long term perspective: we expect this interface to evolve >> for future products, so suggestions and input for improvements is welcome. >> rpmsg or at least the use of virtio-ring combined with a true end-to-end >> zero copy is something we definitely are interested to look into for the >> future. > > Is the rpmsg support something that can be done with the current low-level > protocol? It would be really nice if you could at least share some code > for the general infrastructure, even if both the underlying transport > and the high-level protocols are different. I have already been challenged in this area by Linux Walleij :-), but I'm afraid I don't see how this could be done in a sensible way. The modem doesn't understand the virtual-ring format, and implements a different "protocol" - so the virtual-ring format cannot be used to talk to the modem. And using virtqueue as a packet elevator between Kernel internal modules doesn't seem like the right thing either. If the virtqueue_ops structure hadn't been removed, we could have used this as an abstraction. But this structure was killed off. I might be missing something here, but currently I don't see how I could reuse any of the virtio architecture for the current implementation. However it is definitely something we want to look into for the future. >> As mentioned above, the modem is in different run modes, stream device >> is only used when modem runs in OS-less mode, during boot or crash-dump. >> Except for boot and crash-dump the CAIF stack is used. >> A similar approach is used for HSI, where we use a bare >> HSI channel in OS-less mode, and CAIF over HSI otherwise. > > My feeling is that a character device is not the ideal implementation here, > but I'm not sure what is. One option I can see is to declare the stream > interface part of the configuration logic and do everything through netlink, > packetizing the stream data in netlink frames. Alternatively, a tty port > device might be more appropriate than a plain chardev. Both of these > are likely a bit slower than what you have today, but my impression is that > performance is not the main design goal for the stream interface. If it is, > the best option would probably be to allow user space to mmap the buffer and > do the implementation in an application outside of the kernel. The M7400 modem implements other physical interfaces such as HSI and USB. We have a daemon in user space controlling the run modes and "life-cycle" of the modem (boot, shutdown, upgrade, etc) and we are trying to keep the interface to the different physical interfaces aligned. So for both HSI and USB we're using a stream interface (tty or char device) for the flash-less boot protocol. Due to this I'd prefer to stick to a plain char/tty interface and not use netlink or mmap interfaces. The overall modem boot time is certainly important. But I don't have performance figures of how much of the overall boot time is used for transferring the flash- less boot image in front of me. So it's hard to make a judgment of exactly how performance critical this is. With the current implementation there is *one* copy from user-space to the shared memory area so it should be reasonably efficient. Regards, Sjur {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I