Re: Linux 3.3-1 out - merge window closed

[Ohad Ben-Cohen]

Hi Linus,

On Fri, Jan 20, 2012 at 1:58 AM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> 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 I
do think that both remoteproc and rpmsg are not so scary:

* The code is completely self contained, and the only few external
places it changes amount to grabbing a new virtio id (which is
Acked-by Rusty) and some OMAP init platform code (which is Acked-by
Tony). 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's
very little platform-specific parts in it, and lots of different SoCs
need something like it, but all in all it's a simple driver that loads
a firmware and power up a remote core.

* Rpmsg is, essentially, a simple send/receive API that allows drivers
to 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 up
very simple and lightweight. It had to be generic, too, because
there's nothing platform-specific in it, and drivers for remote
services could easily end up being used on several different
platforms.

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

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

Hope this all makes sense (and sorry for the sales pitch :).

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/