diff mbox

[v3,2/4] remoteproc: add a rproc ops for performing address translation

Message ID 1427917039-43206-3-git-send-email-d-gerlach@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Dave Gerlach April 1, 2015, 7:37 p.m. UTC
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(-)

Comments

Ohad Ben Cohen May 9, 2015, 7:54 a.m. UTC | #1
Hi Dave,

On Wed, Apr 1, 2015 at 10:37 PM, Dave Gerlach <d-gerlach@ti.com> wrote:
> 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.

Can you please provide specific examples where this is needed and how
it is going to be used?

Thanks,
Ohad.
Suman Anna May 11, 2015, 2:55 p.m. UTC | #2
Hi Ohad,

On 05/09/2015 02:54 AM, Ohad Ben-Cohen wrote:
> Hi Dave,
> 
> On Wed, Apr 1, 2015 at 10:37 PM, Dave Gerlach <d-gerlach@ti.com> wrote:
>> 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.
> 
> Can you please provide specific examples where this is needed and how
> it is going to be used?

We will be using this for the WkupM3 remoteproc driver, and also using
it for a PRUSS remoteproc driver (on downstream kernel for now) on TI
AM335x/AM437x SoCs. The driver uses a firmware where all segments are
placed only in internal RAMs (nothing in DDR), and we use the remoteproc
core's ELF loader code to perform the loading. We need a way for the
remoteproc elf loader core to be able to translate these device
addresses into a kernel mapped addresses so that the loader code can
copy the firmware segments.

The previous attempt on this was to use a new resource type through the
resource table, whereby we are publishing and storing the internal
memory translations were stored in the remoteproc core [1].

regards
Suman

[1] https://patchwork.kernel.org/patch/5602981/
diff mbox

Patch

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);
 };
 
 /**