Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2855060ybk; Mon, 18 May 2020 09:31:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJybxe/NO89uPQ3H4dSlh5UZMteaB4GvqG8QUrpm631UIJMovokqf0DD+qflm1NgamXNIPIL X-Received: by 2002:a17:906:37d9:: with SMTP id o25mr16186260ejc.15.1589819466331; Mon, 18 May 2020 09:31:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589819466; cv=none; d=google.com; s=arc-20160816; b=OZgKxp0GXSv+SHLnAmvSSwEI6KKAigP9pl7UINIqHuTeOFmOPkPUb6/65l8loWmvOZ tdhBnstNOiMXtT1EsOP5XAAsLhHGfwIjfsNYOoyuEQA9VgR50uFT0gz0W5YBGjY510UN HfS7hMUvdcNudNJLJVHChma0ncz+lNFk8icsACFn3AfegGJGWQ3edxwH9UqYZp6KauIW 5jP0B/CUjqYMLPGeKnQOTsQAI8+79c+mbJRGyr4DvM0xNKefrk1iLfUrwDUclelHJ8q1 Ye48LL45eqMw6lidvV0mxG8XpkPuVNM69mFBAWCokNvhgTC7ShdWzADMWMmQMc9TpIxR CWHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=wsQWTsWX2nHX19luhaDiip7r8CGCfrYXEJqyS+xYi/4=; b=vgWCjheq+dbimd/TDTPIaM8C1tTTDN2EZ45/83NYH/Ch/K/+RPXGdD/mdpXzSW7RRs cxipuOK4ESYl+i4m01k8zKvcut1nux/weq9ojgtW1Vkdlpm3RCrVQECBDE/VutZ8840N b+JeHGYpr8rxB6qB2jzLjsY95zplXQOF+2f/rRGfO/fYg+mfYiJ5IyYokIS/NzVKPs08 KvJ4eaqVMxG5RBnf3YAMcAqTZJjsU4J2zC2D6Jk52I0g+7t7j6/dWdftr3bqLHqXP4Z5 shoQ0RVczRhRoj9uHUDvTNYxv+vcg7mzg/A7/3zMXWb1JdL3TkQUUr5IjV3NkOrRIMek Vy2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="bSPZNJ/+"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 94si4716421edl.161.2020.05.18.09.30.41; Mon, 18 May 2020 09:31:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="bSPZNJ/+"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728176AbgERQ3R (ORCPT + 99 others); Mon, 18 May 2020 12:29:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48360 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728045AbgERQ3Q (ORCPT ); Mon, 18 May 2020 12:29:16 -0400 Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 86EF3C05BD09 for ; Mon, 18 May 2020 09:29:15 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id s10so11245253iog.7 for ; Mon, 18 May 2020 09:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wsQWTsWX2nHX19luhaDiip7r8CGCfrYXEJqyS+xYi/4=; b=bSPZNJ/+RFq4gD7fvba2WfPjrN7uJ1zq1w02BSYWZKYEPt/dPqB4b+WVzCZJrIi4nk zF1iLf6Y30e9ZEjEoza+2119f0YSs3e7TccHKRPO+w95GXhahxL2m7k7eAx+jgFrHePp zSWxnBkWAPtAWHQ4W6AnAXC4JdK1paRaYXaTRqUKzE8PZS+UXgo1B/CVjmCs0fYb6ZvI 1MvnuXwousaFRSF0P4r/Wut/FQ3OsKp7KuHJeGko4uaTqBhhAUBDapIQ+hicvzLuYnZr wyDqQrhO+jWo4AWF23p9rxYcrwBwU3tx9d9tjkhvqeIHgz0mhNcW+kNFWRsqgC7JVJRR U+dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wsQWTsWX2nHX19luhaDiip7r8CGCfrYXEJqyS+xYi/4=; b=bcmvq0RggP0Nu4z0sBkq9Eqo919KpYBGRvn3A8v8mvADwmu+ltKwnPJ8tjicxHhNTb EivtUZSYBwxqTnC09maKtvr3WxC9cvlaeny1J67uNPQFRxd44wwf+KG/nCvi1M8DqSrp w8ECmO/BwOu9RWFMJ/fldiQL9svfJtGB6EB/k7YH6K62Y4Kf6V6SXKCyHK77afuVOdAl mZb9L8jz9W2njtqhcT3E24xiXiL3x2BUhzv1V2UVXqq5UgKH8RpgNJpJzyDzXDFeN7CP 1l+n5APLZCoxPxtXtmf01JmfKabN7nj1bfby9dv4MGUovrl9zJ/q8g714Ulw+ZwsEe67 IzNg== X-Gm-Message-State: AOAM533XQ2LDRKdnKZdefzCP9NJqrGlFUpqTPJcGq+HodJyuC5PvMZeO G+3PFdF79p1+CM5HBtWJAkYc5mzTKEHZKkDvRc2ovw== X-Received: by 2002:a5d:8257:: with SMTP id n23mr14198274ioo.165.1589819354158; Mon, 18 May 2020 09:29:14 -0700 (PDT) MIME-Version: 1.0 References: <20200424200135.28825-1-mathieu.poirier@linaro.org> In-Reply-To: From: Mathieu Poirier Date: Mon, 18 May 2020 10:29:03 -0600 Message-ID: Subject: Re: [PATCH v3 00/14] remoteproc: Add support for synchronisaton with rproc To: Peng Fan Cc: "bjorn.andersson@linaro.org" , "ohad@wizery.com" , "loic.pallardy@st.com" , "arnaud.pouliquen@st.com" , "s-anna@ti.com" , "linux-remoteproc@vger.kernel.org" , "corbet@lwn.net" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 18 May 2020 at 07:28, Peng Fan wrote: > > > Subject: [PATCH v3 00/14] remoteproc: Add support for synchronisaton with > > rproc > > What's the status of this thread? Will this be applied or requires a new v4? It will not be applied as more work needs to be done. As one of the people this feature will benefit, it would be really nice if you could take the time to comment on the solution that is brought forward. > > Thanks, > Peng. > > > > > This is the third revision of this series that tries to address the problem of > > synchronising with a remote processor with as much flexibility as possible. > > > > Two things to pay attention to: > > > > 1) Function rproc_actuate() has been abandoned to avoid creating another > > way to start a remote processor from a kernel driver. Arnaud expressed > > the opinion that it is semantically questionnable to synchronise with a > > remote processor when calling rproc_boot(). We could rename > > rproc_boot() to rproc_actuate() but I'll wait to see what other people > > think before doing so. > > > > 2) The allocation of the synchronisation states has been split from the > > remote processor allocation. A new function rproc_set_state_machine() > > does all the work now. Proceeding this way has made the patchset a > > lot more simple. > > > > Other than the above I have tried to address all the comments made on the > > second revision. If a comment was not addressed it simply fell through the > > cracks rather than ignored. In such a case please reiterate your point > > of view and I'll be sure to address it. > > > > Applies cleanly on rproc-next (305ac5a766b1). > > > > Best regards, > > Mathieu > > > > Mathieu Poirier (14): > > remoteproc: Make core operations optional > > remoteproc: Introduce function rproc_alloc_internals() > > remoteproc: Add new operation and flags for synchronistation > > remoteproc: Refactor function rproc_boot() > > remoteproc: Refactor function rproc_fw_boot() > > remoteproc: Refactor function rproc_trigger_auto_boot() > > remoteproc: Introducting new start and stop functions > > remoteproc: Call core functions based on synchronisation flag > > remoteproc: Deal with synchronisation when crashing > > remoteproc: Deal with synchronisation when shutting down > > remoteproc: Deal with synchronisation when changing FW image > > remoteproc: Introducing function rproc_set_state_machine() > > remoteproc: Document function rproc_set_state_machine() > > remoteproc: Expose synchronisation flags via debugfs > > > > Documentation/remoteproc.txt | 17 ++ > > drivers/remoteproc/remoteproc_core.c | 197 > > +++++++++++++++++++---- > > drivers/remoteproc/remoteproc_debugfs.c | 21 +++ > > drivers/remoteproc/remoteproc_internal.h | 123 +++++++++++++- > > drivers/remoteproc/remoteproc_sysfs.c | 24 ++- > > include/linux/remoteproc.h | 27 ++++ > > 6 files changed, 372 insertions(+), 37 deletions(-) > > > > -- > > 2.20.1 >