From: Suman Anna <s-anna@ti.com>
To: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Dave Gerlach <d-gerlach@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>,
Robert Tivy <rtivy@ti.com>
Subject: Re: [PATCH 2/2] remoteproc: add support to handle internal memories
Date: Tue, 23 Sep 2014 11:42:45 -0500 [thread overview]
Message-ID: <5421A305.1050509@ti.com> (raw)
In-Reply-To: <CAK=WgbZanJYN7-vXW=wo0H40piauHGQHYPPppcCpc+6VapXmeg@mail.gmail.com>
Hi Ohad,
On 09/23/2014 09:16 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
>
> On Mon, Sep 15, 2014 at 10:39 PM, Suman Anna <s-anna@ti.com> wrote:
>> These processors need to use their internal RAM for loading, which is
>> not for generic usage by the kernel, so defining a CMA block for this
>> memory doesn't make sense.
>
> Ok - so just to make sure I understand, this is physical memory you
> want to use, which belongs to the remote processor, and which isn't
> mapped normally by the kernel?
Yes, this is not the regular DDR that is mapped into kernel normally,
but is a RAM internal to the remote processor subsystem. The MPU can
access it through a bus address/
>
>> Will it suffice to replace the memcpy() with memcpy_toio()?
>
> Yes, memcpy_toio should be fine (and then you don't need to cast the
> cookie returned by ioremap).
I have posted v2, and have not modified for this. The memcpy portion is
actually present in the remoteproc_elf_loader.c, and looks like I need
to export some flags from rproc_va_to_da if I were to differentiate
this. Is that ok with you?
regards
Suman
WARNING: multiple messages have this Message-ID (diff)
From: s-anna@ti.com (Suman Anna)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] remoteproc: add support to handle internal memories
Date: Tue, 23 Sep 2014 11:42:45 -0500 [thread overview]
Message-ID: <5421A305.1050509@ti.com> (raw)
In-Reply-To: <CAK=WgbZanJYN7-vXW=wo0H40piauHGQHYPPppcCpc+6VapXmeg@mail.gmail.com>
Hi Ohad,
On 09/23/2014 09:16 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
>
> On Mon, Sep 15, 2014 at 10:39 PM, Suman Anna <s-anna@ti.com> wrote:
>> These processors need to use their internal RAM for loading, which is
>> not for generic usage by the kernel, so defining a CMA block for this
>> memory doesn't make sense.
>
> Ok - so just to make sure I understand, this is physical memory you
> want to use, which belongs to the remote processor, and which isn't
> mapped normally by the kernel?
Yes, this is not the regular DDR that is mapped into kernel normally,
but is a RAM internal to the remote processor subsystem. The MPU can
access it through a bus address/
>
>> Will it suffice to replace the memcpy() with memcpy_toio()?
>
> Yes, memcpy_toio should be fine (and then you don't need to cast the
> cookie returned by ioremap).
I have posted v2, and have not modified for this. The memcpy portion is
actually present in the remoteproc_elf_loader.c, and looks like I need
to export some flags from rproc_va_to_da if I were to differentiate
this. Is that ok with you?
regards
Suman
next prev parent reply other threads:[~2014-09-23 16:42 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-08 16:21 [PATCH 0/2] couple of generic remoteproc enhancements Suman Anna
2014-07-08 16:21 ` Suman Anna
2014-07-08 16:22 ` [PATCH 1/2] remoteproc: use a flag to detect the presence of IOMMU Suman Anna
2014-07-08 16:22 ` Suman Anna
2014-07-29 10:57 ` Ohad Ben-Cohen
2014-07-29 10:57 ` Ohad Ben-Cohen
2014-07-29 16:10 ` Suman Anna
2014-07-29 16:10 ` Suman Anna
2014-08-04 11:50 ` Ohad Ben-Cohen
2014-08-04 11:50 ` Ohad Ben-Cohen
2014-08-04 15:48 ` Suman Anna
2014-08-04 15:48 ` Suman Anna
2014-08-05 7:05 ` Ohad Ben-Cohen
2014-08-05 7:05 ` Ohad Ben-Cohen
2014-07-08 16:22 ` [PATCH 2/2] remoteproc: add support to handle internal memories Suman Anna
2014-07-08 16:22 ` Suman Anna
2014-07-29 11:00 ` Ohad Ben-Cohen
2014-07-29 11:00 ` Ohad Ben-Cohen
2014-07-29 19:33 ` Suman Anna
2014-07-29 19:33 ` Suman Anna
2014-08-19 9:10 ` Ohad Ben-Cohen
2014-08-19 9:10 ` Ohad Ben-Cohen
2014-09-15 19:39 ` Suman Anna
2014-09-15 19:39 ` Suman Anna
2014-09-23 14:16 ` Ohad Ben-Cohen
2014-09-23 14:16 ` Ohad Ben-Cohen
2014-09-23 16:42 ` Suman Anna [this message]
2014-09-23 16:42 ` Suman Anna
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=5421A305.1050509@ti.com \
--to=s-anna@ti.com \
--cc=d-gerlach@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=ohad@wizery.com \
--cc=rtivy@ti.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: link
Be 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.