Adding remoteproc/rpmsg to linux-next

Adding remoteproc/rpmsg to linux-next

[Ohad Ben-Cohen]

Hi Stephen,

Can you please add the following remoteproc tree to linux-next ?

git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git for-next

This branch includes the basic remoteproc/rpmsg functionality as
posted in the mailing lists, with a few minor changes that were
requested (namely, changes against virtio-spec.txt were removed and
"amp" is no longer used).

The motivation for having this in linux-next is twofold:
1. Getting prepared for a 3.3 merger (knock on wood)
2. Starting a linear development scheme, in order to make it easier
for people to collaborate (and to reduce the review load of
incremental changes)

I suspect that once this basic functionality will be merged upstream,
the development of remoteproc and rpmsg will become completely
orthogonal, and it would then make sense to start queueing patches
separately. At that point I'll send you the details for the rpmsg.git
tree.

Last note: the "ARM: OMAP: add remoteproc devices for OMAP4" patch is
omitted from this branch, since it depends on CMA (which isn't merged
yet). As soon as CMA will be added (at least to linux-next) that patch
will be queued up too.

Thanks,
Ohad.

The following changes since commit 5611cc4572e889b62a7b4c72a413536bf6a9c416:

  Linux 3.2-rc4 (2011-12-01 14:56:01 -0800)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git for-next

Ohad Ben-Cohen (6):
      remoteproc: add framework for controlling remote processors
      remoteproc: add debugfs entries
      remoteproc: create rpmsg virtio device
      remoteproc/omap: add a remoteproc driver for OMAP4
      rpmsg: add virtio-based remote processor messaging bus
      samples/rpmsg: add an rpmsg driver sample

 Documentation/ABI/testing/sysfs-bus-rpmsg    |   75 ++
 Documentation/remoteproc.txt                 |  324 ++++++
 Documentation/rpmsg.txt                      |  293 ++++++
 MAINTAINERS                                  |    7 +
 arch/arm/plat-omap/include/plat/remoteproc.h |   57 +
 drivers/Kconfig                              |    4 +
 drivers/Makefile                             |    2 +
 drivers/remoteproc/Kconfig                   |   24 +
 drivers/remoteproc/Makefile                  |    9 +
 drivers/remoteproc/omap_remoteproc.c         |  249 +++++
 drivers/remoteproc/omap_remoteproc.h         |   69 ++
 drivers/remoteproc/remoteproc_core.c         | 1410 ++++++++++++++++++++++++++
 drivers/remoteproc/remoteproc_debugfs.c      |  179 ++++
 drivers/remoteproc/remoteproc_internal.h     |   44 +
 drivers/remoteproc/remoteproc_rpmsg.c        |  295 ++++++
 drivers/rpmsg/Kconfig                        |    5 +
 drivers/rpmsg/Makefile                       |    1 +
 drivers/rpmsg/virtio_rpmsg_bus.c             | 1026 +++++++++++++++++++
 include/linux/mod_devicetable.h              |    9 +
 include/linux/remoteproc.h                   |  265 +++++
 include/linux/rpmsg.h                        |  326 ++++++
 include/linux/virtio_ids.h                   |    1 +
 samples/Kconfig                              |    8 +
 samples/Makefile                             |    2 +-
 samples/rpmsg/Makefile                       |    1 +
 samples/rpmsg/rpmsg_client_sample.c          |  100 ++
 26 files changed, 4784 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-rpmsg
 create mode 100644 Documentation/remoteproc.txt
 create mode 100644 Documentation/rpmsg.txt
 create mode 100644 arch/arm/plat-omap/include/plat/remoteproc.h
 create mode 100644 drivers/remoteproc/Kconfig
 create mode 100644 drivers/remoteproc/Makefile
 create mode 100644 drivers/remoteproc/omap_remoteproc.c
 create mode 100644 drivers/remoteproc/omap_remoteproc.h
 create mode 100644 drivers/remoteproc/remoteproc_core.c
 create mode 100644 drivers/remoteproc/remoteproc_debugfs.c
 create mode 100644 drivers/remoteproc/remoteproc_internal.h
 create mode 100644 drivers/remoteproc/remoteproc_rpmsg.c
 create mode 100644 drivers/rpmsg/Kconfig
 create mode 100644 drivers/rpmsg/Makefile
 create mode 100644 drivers/rpmsg/virtio_rpmsg_bus.c
 create mode 100644 include/linux/remoteproc.h
 create mode 100644 include/linux/rpmsg.h
 create mode 100644 samples/rpmsg/Makefile
 create mode 100644 samples/rpmsg/rpmsg_client_sample.c

Re: Adding remoteproc/rpmsg to linux-next

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]

Hi Ohad,

On Fri, 9 Dec 2011 16:55:27 +0200 Ohad Ben-Cohen <ohad@wizery.com> wrote:
>
> Can you please add the following remoteproc tree to linux-next ?
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git for-next

I have added that from today.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
	Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
sfr@canb.auug.org.au

Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees.  You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next.  These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc.  The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc.  If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: Adding remoteproc/rpmsg to linux-next

[Ohad Ben-Cohen]

Hi Arnd,

On Mon, Dec 12, 2011 at 1:33 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Fri, 9 Dec 2011 16:55:27 +0200 Ohad Ben-Cohen <ohad@wizery.com> wrote:
>>
>> Can you please add the following remoteproc tree to linux-next ?
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git for-next
>
> I have added that from today.

Would you like rpmsg/remoteproc to go through arm-soc or do you prefer
me to send a pull request directly to Linus ?

If you prefer the former (IIRC you told me you might consider it in a
random ELCE hallway conversation :) then I'll send you a pull request.

I'm happy either way.

Thanks!
Ohad.

Re: Adding remoteproc/rpmsg to linux-next

[Arnd Bergmann]

On Wednesday 21 December 2011, Ohad Ben-Cohen wrote:
> Hi Arnd,
> 
> On Mon, Dec 12, 2011 at 1:33 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > On Fri, 9 Dec 2011 16:55:27 +0200 Ohad Ben-Cohen <ohad@wizery.com> wrote:
> >>
> >> Can you please add the following remoteproc tree to linux-next ?
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git for-next
> >
> > I have added that from today.
> 
> Would you like rpmsg/remoteproc to go through arm-soc or do you prefer
> me to send a pull request directly to Linus ?
> 
> If you prefer the former (IIRC you told me you might consider it in a
> random ELCE hallway conversation :) then I'll send you a pull request.
> 
> I'm happy either way.

Either way works for me, too. Right now, I would tend to let you send it
to Linus directly because I haven't looked at the latest versions of the
code for some time. While I generally trust you to do the right thing
there, I'm not 100% comfortable to vouch for it in the way that an Ack
or pull would imply without doing a more detailed review of the latest
code.

I know that I promised you that review, but haven't gotten to it, sorry.
I've done a 5 minute review now and it absolutely looks good to go in
as far as I can tell, so I certainly don't object to you sending it
to Linus for 3.3. If you think you need more Acks or if there are other
reasons to have it go through arm-soc, please tell me and I'll try harder
to find the time for a proper review.

	Arnd

Re: Adding remoteproc/rpmsg to linux-next

[Ohad Ben-Cohen]

On Thu, Dec 22, 2011 at 5:22 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> Either way works for me, too. Right now, I would tend to let you send it
> to Linus directly because I haven't looked at the latest versions of the
> code for some time.

Directly to Linus it is then.

> While I generally trust you to do the right thing
> there, I'm not 100% comfortable to vouch for it in the way that an Ack
> or pull would imply without doing a more detailed review of the latest
> code.

Sure, I fully understand.

> I know that I promised you that review, but haven't gotten to it, sorry.
> I've done a 5 minute review now and it absolutely looks good to go in
> as far as I can tell, so I certainly don't object to you sending it
> to Linus for 3.3.

Thanks.

> If you think you need more Acks or if there are other
> reasons to have it go through arm-soc, please tell me and I'll try harder
> to find the time for a proper review.

I do have explicit Acks on the changes to other sub-systems, though
ideally I'd be happy to have some explicit Acks on the generic code
too.

But I hope this should be fine. Let's try to proceed this way and see
how it goes (maybe I should just tell Linus that despite the lack of
explicit Acks to some of the patches, people do think this is
good-to-go).

Thanks!
Ohad.

Re: Adding remoteproc/rpmsg to linux-next

[Ohad Ben-Cohen]

Hi Arnd,

On Thu, Dec 22, 2011 at 5:22 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> If you think you need more Acks or if there are other
> reasons to have it go through arm-soc, please tell me and I'll try harder
> to find the time for a proper review.

Any chance you could carve out some time for reviewing remoteproc and
rpmsg [1] ?

I hope we could either get your Acks on the patches or even have it go
through arm-soc for 3.4.

Thanks!
Ohad.

[1] git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
rpmsg-for-3.3

Re: Adding remoteproc/rpmsg to linux-next

[Arnd Bergmann]

On Wednesday 01 February 2012, Ohad Ben-Cohen wrote:
> On Thu, Dec 22, 2011 at 5:22 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > If you think you need more Acks or if there are other
> > reasons to have it go through arm-soc, please tell me and I'll try harder
> > to find the time for a proper review.
> 
> Any chance you could carve out some time for reviewing remoteproc and
> rpmsg [1] ?

I will.
 
> I hope we could either get your Acks on the patches or even have it go
> through arm-soc for 3.4.

Yes, I think it's best to have it merged through arm-soc, in case Linus
is more likely to take it from there than pull from your tree.

	Arnd

Re: Adding remoteproc/rpmsg to linux-next

[Ohad Ben-Cohen]

On Wed, Feb 1, 2012 at 6:57 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> I will.

Thanks.

> Yes, I think it's best to have it merged through arm-soc, in case Linus
> is more likely to take it from there than pull from your tree.

Great, thanks.

Ohad.