| Message ID | CAK=WgbaU6vpiBGSgogYPjQNmrF-U0wk1rSXMX83DdgQa9hw5Mw@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
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.
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.
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
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.
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
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
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.
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