linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Gerlach <d-gerlach@ti.com>
To: <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <linux-omap@vger.kernel.org>,
	<devicetree@vger.kernel.org>
Cc: Ohad Ben-Cohen <ohad@wizery.com>, Suman Anna <s-anna@ti.com>,
	Kevin Hilman <khilman@linaro.org>,
	Tony Lindgren <tony@atomide.com>, Dave Gerlach <d-gerlach@ti.com>
Subject: [PATCH v3 2/4] remoteproc: add a rproc ops for performing address translation
Date: Wed, 1 Apr 2015 14:37:17 -0500	[thread overview]
Message-ID: <1427917039-43206-3-git-send-email-d-gerlach@ti.com> (raw)
In-Reply-To: <1427917039-43206-1-git-send-email-d-gerlach@ti.com>

From: Suman Anna <s-anna@ti.com>

The rproc_da_to_va API is currently used to perform any device to
kernel address translations to meet the different needs of the remoteproc
core/drivers (eg: loading). The functionality is achieved within the
remoteproc core, and is limited only for carveouts allocated within the
core.

A new rproc ops, da_to_va, is added to provide flexibility to platform
implementations to perform the address translation themselves when the
above conditions cannot be met by the implementations. The rproc_da_to_va()
API is extended to invoke this ops if present, and fallback to regular
processing if the platform implementation cannot provide the translation.
This will allow any remoteproc implementations to translate addresses for
dedicated memories like internal memories.

While at this, also update the rproc_da_to_va() documentation since it
is an exported function.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
 drivers/remoteproc/remoteproc_core.c | 31 +++++++++++++++++++++++++------
 include/linux/remoteproc.h           |  2 ++
 2 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 5a6c192..f1efe62 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -159,28 +159,46 @@ static void rproc_disable_iommu(struct rproc *rproc)
 	return;
 }
 
-/*
+/**
+ * rproc_da_to_va() - lookup the kernel virtual address for a remoteproc address
+ * @rproc: handle of a remote processor
+ * @da: remoteproc device address to translate
+ * @len: length of the memory region @da is pointing to
+ *
  * Some remote processors will ask us to allocate them physically contiguous
  * memory regions (which we call "carveouts"), and map them to specific
- * device addresses (which are hardcoded in the firmware).
+ * device addresses (which are hardcoded in the firmware). They may also have
+ * dedicated memory regions internal to the processors, and use them either
+ * exclusively or alongside carveouts.
  *
  * They may then ask us to copy objects into specific device addresses (e.g.
  * code/data sections) or expose us certain symbols in other device address
  * (e.g. their trace buffer).
  *
- * This function is an internal helper with which we can go over the allocated
- * carveouts and translate specific device address to kernel virtual addresses
- * so we can access the referenced memory.
+ * This function is a helper function with which we can go over the allocated
+ * carveouts and translate specific device addresses to kernel virtual addresses
+ * so we can access the referenced memory. This function also allows to perform
+ * translations on the internal remoteproc memory regions through a platform
+ * implementation specific da_to_va ops, if present.
+ *
+ * The function returns a valid kernel address on success or NULL on failure.
  *
  * Note: phys_to_virt(iommu_iova_to_phys(rproc->domain, da)) will work too,
  * but only on kernel direct mapped RAM memory. Instead, we're just using
- * here the output of the DMA API, which should be more correct.
+ * here the output of the DMA API for the carveouts, which should be more
+ * correct.
  */
 void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
 {
 	struct rproc_mem_entry *carveout;
 	void *ptr = NULL;
 
+	if (rproc->ops->da_to_va) {
+		ptr = rproc->ops->da_to_va(rproc, da, len);
+		if (ptr)
+			goto out;
+	}
+
 	list_for_each_entry(carveout, &rproc->carveouts, node) {
 		int offset = da - carveout->da;
 
@@ -197,6 +215,7 @@ void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
 		break;
 	}
 
+out:
 	return ptr;
 }
 EXPORT_SYMBOL(rproc_da_to_va);
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 0c7d403..81b224d 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -331,11 +331,13 @@ struct rproc;
  * @start:	power on the device and boot it
  * @stop:	power off the device
  * @kick:	kick a virtqueue (virtqueue id given as a parameter)
+ * @da_to_va:	optional platform hook to perform address translations
  */
 struct rproc_ops {
 	int (*start)(struct rproc *rproc);
 	int (*stop)(struct rproc *rproc);
 	void (*kick)(struct rproc *rproc, int vqid);
+	void * (*da_to_va)(struct rproc *rproc, u64 da, int len);
 };
 
 /**
-- 
2.3.0


  parent reply	other threads:[~2015-04-01 19:38 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-01 19:37 [PATCH v3 0/4] remoteproc: Introduce wkup_m3_rproc driver Dave Gerlach
2015-04-01 19:37 ` [PATCH v3 1/4] remoteproc: introduce rproc_get_by_phandle API Dave Gerlach
2015-05-09  7:39   ` Ohad Ben-Cohen
2015-05-11 15:09     ` Suman Anna
2015-05-16  7:18       ` Ohad Ben-Cohen
2015-05-18 14:33         ` Dave Gerlach
2015-04-01 19:37 ` Dave Gerlach [this message]
2015-05-09  7:54   ` [PATCH v3 2/4] remoteproc: add a rproc ops for performing address translation Ohad Ben-Cohen
2015-05-11 14:55     ` Suman Anna
2015-04-01 19:37 ` [PATCH v3 3/4] Documentation: dt: add bindings for TI Wakeup M3 processor Dave Gerlach
2015-05-11 17:28   ` Tony Lindgren
2015-04-01 19:37 ` [PATCH v3 4/4] remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3 Dave Gerlach
2015-05-09  8:42   ` Ohad Ben-Cohen
2015-05-11 15:01     ` Suman Anna
2015-05-16  8:43       ` Ohad Ben-Cohen
2015-04-29 16:05 ` [PATCH v3 0/4] remoteproc: Introduce wkup_m3_rproc driver Suman Anna
2015-05-02  8:45   ` 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=1427917039-43206-3-git-send-email-d-gerlach@ti.com \
    --to=d-gerlach@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=khilman@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=ohad@wizery.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).