From: Stephen Boyd <sboyd@codeaurora.org> To: Ohad Ben-Cohen <ohad@wizery.com> Cc: linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] remoteproc: block premature rproc booting Date: Tue, 05 Jun 2012 20:25:03 -0700 [thread overview] Message-ID: <4FCECD8F.8000600@codeaurora.org> (raw) In-Reply-To: <CAK=WgbZo-8GXY9bVYGk0XZvqKrdaJZWeNkK1FhRWnH5doGYLjA@mail.gmail.com> On 06/05/12 03:57, Ohad Ben-Cohen wrote: > What about using a separate file for the resource table ? > > That should be very easy to support, and may make life easier for you > in the long term. > > Resource tables tend to change in time, and hard coding it in the > kernel doesn't sound ideal (both in terms of development overhead, and > kernel-firmware backward and forward compatibility). Thanks. I'll look into that as that seems feasible. > Does the below work for you (sans the OMAP terminology ;) ? > > root@omap4430-panda:/sys/bus/platform/drivers/omap-rproc# echo > omap-rproc.1 > unbind > [ 471.376556] remoteproc remoteproc0: releasing ipu_c0 > root@omap4430-panda:/sys/bus/platform/drivers/omap-rproc# echo > omap-rproc.1 > bind > [ 478.219177] remoteproc remoteproc0: ipu_c0 is available > [ 478.224639] remoteproc remoteproc0: Note: remoteproc is still under > development and considered experimental. > [ 478.235015] remoteproc remoteproc0: THE BINARY FORMAT IS NOT YET > FINALIZED, and backward compatibility isn't yet guaranteed. > [ 478.325347] remoteproc remoteproc0: registered virtio0 (type 7) > [ 478.331848] remoteproc remoteproc0: registered virtio1 (type 3) > > This way user space can unbind a specific remote processor (which will > also trigger unbinding the entire device hierarchy below it, i.e. all > rpmsg/virtio devices). This is great! I finally see how bind/unbind is useful. What if I don't want to boot the device at kernel start-up? Do I have to make it a module then? -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] remoteproc: block premature rproc booting Date: Tue, 05 Jun 2012 20:25:03 -0700 [thread overview] Message-ID: <4FCECD8F.8000600@codeaurora.org> (raw) In-Reply-To: <CAK=WgbZo-8GXY9bVYGk0XZvqKrdaJZWeNkK1FhRWnH5doGYLjA@mail.gmail.com> On 06/05/12 03:57, Ohad Ben-Cohen wrote: > What about using a separate file for the resource table ? > > That should be very easy to support, and may make life easier for you > in the long term. > > Resource tables tend to change in time, and hard coding it in the > kernel doesn't sound ideal (both in terms of development overhead, and > kernel-firmware backward and forward compatibility). Thanks. I'll look into that as that seems feasible. > Does the below work for you (sans the OMAP terminology ;) ? > > root at omap4430-panda:/sys/bus/platform/drivers/omap-rproc# echo > omap-rproc.1 > unbind > [ 471.376556] remoteproc remoteproc0: releasing ipu_c0 > root at omap4430-panda:/sys/bus/platform/drivers/omap-rproc# echo > omap-rproc.1 > bind > [ 478.219177] remoteproc remoteproc0: ipu_c0 is available > [ 478.224639] remoteproc remoteproc0: Note: remoteproc is still under > development and considered experimental. > [ 478.235015] remoteproc remoteproc0: THE BINARY FORMAT IS NOT YET > FINALIZED, and backward compatibility isn't yet guaranteed. > [ 478.325347] remoteproc remoteproc0: registered virtio0 (type 7) > [ 478.331848] remoteproc remoteproc0: registered virtio1 (type 3) > > This way user space can unbind a specific remote processor (which will > also trigger unbinding the entire device hierarchy below it, i.e. all > rpmsg/virtio devices). This is great! I finally see how bind/unbind is useful. What if I don't want to boot the device at kernel start-up? Do I have to make it a module then? -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2012-06-06 3:25 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-05-22 11:51 [PATCH] remoteproc: block premature rproc booting Ohad Ben-Cohen 2012-05-22 11:51 ` Ohad Ben-Cohen 2012-05-22 11:51 ` Ohad Ben-Cohen 2012-05-24 9:15 ` Stephen Boyd 2012-05-24 9:15 ` Stephen Boyd 2012-05-24 20:11 ` Ohad Ben-Cohen 2012-05-24 20:11 ` Ohad Ben-Cohen 2012-06-04 21:23 ` Stephen Boyd 2012-06-04 21:23 ` Stephen Boyd 2012-06-05 10:57 ` Ohad Ben-Cohen 2012-06-05 10:57 ` Ohad Ben-Cohen 2012-06-06 3:25 ` Stephen Boyd [this message] 2012-06-06 3:25 ` Stephen Boyd 2012-06-06 5:44 ` Ohad Ben-Cohen 2012-06-06 5:44 ` Ohad Ben-Cohen 2012-06-06 5:44 ` Ohad Ben-Cohen 2012-07-02 12:25 ` Ohad Ben-Cohen 2012-07-02 12:25 ` Ohad Ben-Cohen 2012-07-02 15:15 ` Sjur BRENDELAND 2012-07-02 15:15 ` Sjur BRENDELAND 2012-07-02 15:15 ` Sjur BRENDELAND 2012-07-02 15:19 ` Ohad Ben-Cohen 2012-07-02 15:19 ` Ohad Ben-Cohen 2012-07-02 15:19 ` Ohad Ben-Cohen [not found] <81C3A93C17462B4BBD7E272753C10579232F86B623@EXDCVYMBSTM005.EQ1STM.local> 2012-06-29 14:56 ` Ohad Ben-Cohen 2012-07-02 6:08 ` Preetham-rao K 2012-07-02 21:10 ` Guzman Lugo, Fernando
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4FCECD8F.8000600@codeaurora.org \ --to=sboyd@codeaurora.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=ohad@wizery.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.