From: Ohad Ben-Cohen <ohad@wizery.com> To: Suman Anna <s-anna@ti.com> Cc: Tony Lindgren <tony@atomide.com>, Kevin Hilman <khilman@linaro.org>, Dave Gerlach <d-gerlach@ti.com>, Robert Tivy <rtivy@ti.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>, linux-arm <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v3 2/2] remoteproc: add support to handle internal memories Date: Fri, 13 Feb 2015 07:20:16 +0200 [thread overview] Message-ID: <CAK=WgbaK+TNJR1UHm7orcFk7kaGTWMQsW0XhX_t7qvWwe+YJEg@mail.gmail.com> (raw) In-Reply-To: <54DD131F.8040704@ti.com> On Thu, Feb 12, 2015 at 10:54 PM, Suman Anna <s-anna@ti.com> wrote: > My original motivation was that it would only need to be added on > firmwares requiring support for loading into internal memories, > otherwise, these are something left to be managed by the software > running on the remote processor completely, and MPU will not even touch > them. Sure. But even if you guys will use this interface correctly, this patch essentially exposes ioremap to user space, which is something we generally want to avoid. > So, let me know if this is a NAK. If so, we have two options - one to go > the sram node model where each of them have to be defined separately, > and have a specific property in the rproc nodes to be able to get the > gen_pool handles. The other one is simply to define these as <reg> and > use devm_ioremap_resource() (so use DT for defining the regions instead > of a resource table entry). Any approach where these regions are defined explicitly really sounds better. If you could look into these two alternatives that would be great. Thanks, Ohad.
WARNING: multiple messages have this Message-ID (diff)
From: ohad@wizery.com (Ohad Ben-Cohen) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v3 2/2] remoteproc: add support to handle internal memories Date: Fri, 13 Feb 2015 07:20:16 +0200 [thread overview] Message-ID: <CAK=WgbaK+TNJR1UHm7orcFk7kaGTWMQsW0XhX_t7qvWwe+YJEg@mail.gmail.com> (raw) In-Reply-To: <54DD131F.8040704@ti.com> On Thu, Feb 12, 2015 at 10:54 PM, Suman Anna <s-anna@ti.com> wrote: > My original motivation was that it would only need to be added on > firmwares requiring support for loading into internal memories, > otherwise, these are something left to be managed by the software > running on the remote processor completely, and MPU will not even touch > them. Sure. But even if you guys will use this interface correctly, this patch essentially exposes ioremap to user space, which is something we generally want to avoid. > So, let me know if this is a NAK. If so, we have two options - one to go > the sram node model where each of them have to be defined separately, > and have a specific property in the rproc nodes to be able to get the > gen_pool handles. The other one is simply to define these as <reg> and > use devm_ioremap_resource() (so use DT for defining the regions instead > of a resource table entry). Any approach where these regions are defined explicitly really sounds better. If you could look into these two alternatives that would be great. Thanks, Ohad.
next prev parent reply other threads:[~2015-02-13 5:20 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-01-09 21:21 [PATCH v3 0/2] couple of generic remoteproc enhancements Suman Anna 2015-01-09 21:21 ` Suman Anna 2015-01-09 21:21 ` Suman Anna 2015-01-09 21:21 ` [PATCH v3 1/2] remoteproc: use a flag to detect the presence of IOMMU Suman Anna 2015-01-09 21:21 ` Suman Anna 2015-01-09 21:21 ` Suman Anna 2015-03-12 9:04 ` Ohad Ben-Cohen 2015-03-12 9:04 ` Ohad Ben-Cohen 2015-03-13 23:35 ` Suman Anna 2015-03-13 23:35 ` Suman Anna 2015-01-09 21:21 ` [PATCH v3 2/2] remoteproc: add support to handle internal memories Suman Anna 2015-01-09 21:21 ` Suman Anna 2015-01-09 21:21 ` Suman Anna 2015-02-10 10:10 ` Ohad Ben-Cohen 2015-02-10 10:10 ` Ohad Ben-Cohen 2015-02-11 20:57 ` Tony Lindgren 2015-02-11 20:57 ` Tony Lindgren 2015-02-11 20:57 ` Tony Lindgren 2015-02-11 22:28 ` Suman Anna 2015-02-11 22:28 ` Suman Anna 2015-02-11 22:48 ` Tony Lindgren 2015-02-11 22:48 ` Tony Lindgren 2015-02-12 0:01 ` Suman Anna 2015-02-12 0:01 ` Suman Anna 2015-02-12 0:18 ` Tony Lindgren 2015-02-12 0:18 ` Tony Lindgren 2015-02-12 1:07 ` Suman Anna 2015-02-12 1:07 ` Suman Anna 2015-02-12 9:09 ` Ohad Ben-Cohen 2015-02-12 9:09 ` Ohad Ben-Cohen 2015-02-12 20:54 ` Suman Anna 2015-02-12 20:54 ` Suman Anna 2015-02-13 5:20 ` Ohad Ben-Cohen [this message] 2015-02-13 5:20 ` Ohad Ben-Cohen 2015-02-13 16:13 ` Suman Anna 2015-02-13 16:13 ` Suman Anna 2015-02-13 18:35 ` Tony Lindgren 2015-02-13 18:35 ` Tony Lindgren 2015-01-22 21:52 ` [PATCH v3 0/2] couple of generic remoteproc enhancements Suman Anna 2015-01-22 21:52 ` Suman Anna 2015-01-22 21:52 ` Suman Anna 2015-02-03 20:55 ` Suman Anna 2015-02-03 20:55 ` Suman Anna 2015-02-03 20:55 ` Suman Anna 2015-02-05 15:11 ` Ohad Ben-Cohen 2015-02-05 15:11 ` Ohad Ben-Cohen
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='CAK=WgbaK+TNJR1UHm7orcFk7kaGTWMQsW0XhX_t7qvWwe+YJEg@mail.gmail.com' \ --to=ohad@wizery.com \ --cc=d-gerlach@ti.com \ --cc=khilman@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=rtivy@ti.com \ --cc=s-anna@ti.com \ --cc=tony@atomide.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.