On Fri, Jan 20, 2012 at 1:58 AM, Linus Torvalds<torvalds@linux-foundation.org> wrote:> There are a couple of trees I haven't merged on purpose, and there may> be a few trees I overlooked by mistake. The "on purpose" ones were> things that looked unfamiliar and I felt I didn't have the bandwidth> to check. The "mistake" ones would just be things I missed due to> being busy.

I guess that the remoteproc/rpmsg tree belongs to the "on purpose" department :)

> So if you felt that your pull request was overlooked by mistake (or> intentionally, but really not so scary that you think I should have a> really easy time checking it), you have a couple of days to marshal> your arguments for why I should pull it after all.

I realize there's a slim chance to get it merged at this point, but Ido think that both remoteproc and rpmsg are not so scary:

* The code is completely self contained, and the only few externalplaces it changes amount to grabbing a new virtio id (which isAcked-by Rusty) and some OMAP init platform code (which is Acked-byTony). People who aren't explicitly using it won't notice it's there;even its Kconfig entries get selected automatically when relevant(i.e. only on OMAP4 at this point) and would never show up otherwise.

* Remoteproc is just a driver. It had to be generic, because there'svery little platform-specific parts in it, and lots of different SoCsneed something like it, but all in all it's a simple driver that loadsa firmware and power up a remote core.

* Rpmsg is, essentially, a simple send/receive API that allows driversto communicate with remote services. The real gory details (and wit!)are actually handled by virtio, which is used as the shared-memory"wire" protocol with the remote core. Thanks to virtio, rpmsg ended upvery simple and lightweight. It had to be generic, too, becausethere's nothing platform-specific in it, and drivers for remoteservices could easily end up being used on several differentplatforms.

* These frameworks have been discussed in embedded/ARM circles forquite some time, and numerous maintainers support it, including Arndand Grant.

It's a real need for many SoCs, and not a niche hardware support: thisdrives, e.g., the camera and video use cases of the Galaxy Nexusphone. At this point there are several teams, spanning severalvendors, which look into adding support for this (and furtherdeveloping it), so merging it will just make collaboration easier.