[RESEND 1/2] remoteproc: replace bool from struct rproc by u8
Post [1] and checkpatch tool indicate that usage of bool type
in structure is now no more allowed/advised.
This patch replaces bool by unsigned char (u8) and reorders
struct rproc fields to avoid padding.
[1] https://lkml.org/lkml/2017/11/21/384
Signed-off-by: Loic Pallardy
---
include/linux/remoteproc.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 16ad66683ad0..8cd22fecea61 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -472,15 +472,15 @@ struct rproc_dump_segment {
* @index: index of this rproc device
* @crash_handler: workqueue for handling a crash
* @crash_cnt: crash counter
- * @recovery_disabled: flag that state if recovery was disabled
* @max_notifyid: largest allocated notify id.
* @table_ptr: pointer to the resource table in effect
* @cached_table: copy of the resource table
* @table_sz: size of @cached_table
- * @has_iommu: flag to indicate if remote processor is behind an MMU
- * @auto_boot: flag to indicate if remote processor should be auto-started
* @dump_segments: list of segments in the firmware
* @nb_vdev: number of vdev currently handled by rproc
+ * @recovery_disabled: flag that state if recovery was disabled
+ * @has_iommu: flag to indicate if remote processor is behind an MMU
+ * @auto_boot: flag to indicate if remote processor should be auto-started
*/
struct rproc {
struct list_head node;
@@ -505,15 +505,15 @@ struct rproc {
int index;
struct work_struct crash_handler;
unsigned int crash_cnt;
- bool recovery_disabled;
int max_notifyid;
struct resource_table *table_ptr;
struct resource_table *cached_table;
size_t table_sz;
- bool has_iommu;
- bool auto_boot;
struct list_head dump_segments;
int nb_vdev;
+ u8 recovery_disabled;
+ u8 has_iommu;
+ u8 auto_boot;
};
/**
--
2.7.4
[RESEND 0/2] remoteproc: add support for preloaded firmware
This patch series introduces a new flag in remoteproc core to add support of remote processor having their firmware loading by another way than standard remoteproc core sequence. Firmware could be ROMed, loaded by security or bootloader before kernel boot or loaded by a special rproc platform driver interface. When "preloaded" flag is set by rproc platform driver, remoteproc core doesn't request firmware and execute rproc_start sequence as usual allocating associated rproc resources. It is rproc platform driver responsibility to implement the right firmware load operations according to HW specificities like resource table location or firmware definition if needed. Regards, Loic Loic Pallardy (2): remoteproc: replace bool from struct rproc by u8 remoteproc: add support for co-processor booted before kernel drivers/remoteproc/remoteproc_core.c | 37 +++- include/linux/remoteproc.h | 14 -- 2 files changed, 36 insertions(+), 15 deletions(-) -- 2.7.4
[RESEND 2/2] remoteproc: add support for co-processor booted before kernel
Remote processor could boot independently or be started before Linux
kernel by bootloader or any firmware.
This patch introduces a new property in rproc core, named preloaded,
to be able to allocate resources and sub-devices like vdev and to
synchronize with current state without loading firmware from file system.
It is platform driver responsibility to implement the right firmware
load ops according to HW specificities.
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 37 +++-
include/linux/remoteproc.h | 2 ++
2 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 3c5fbbbfb0f1..7eaf0f949afa 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1372,7 +1372,11 @@ static int rproc_fw_boot(struct rproc *rproc, const
struct firmware *fw)
if (ret)
return ret;
- dev_info(dev, "Booting fw image %s, size %zd\n", name, fw->size);
+ if (fw)
+ dev_info(dev, "Booting fw image %s, size %zd\n", name,
+fw->size);
+ else
+ dev_info(dev, "Synchronizing with preloaded co-processor\n");
/*
* if enabling an IOMMU isn't relevant for this rproc, this is
@@ -1728,7 +1732,7 @@ static void rproc_crash_handler_work(struct work_struct
*work)
*/
int rproc_boot(struct rproc *rproc)
{
- const struct firmware *firmware_p;
+ const struct firmware *firmware_p = NULL;
struct device *dev;
int ret;
@@ -1759,11 +1763,17 @@ int rproc_boot(struct rproc *rproc)
dev_info(dev, "powering up %s\n", rproc->name);
- /* load firmware */
- ret = request_firmware(_p, rproc->firmware, dev);
- if (ret < 0) {
- dev_err(dev, "request_firmware failed: %d\n", ret);
- goto downref_rproc;
+ if (!rproc->preloaded) {
+ /* load firmware */
+ ret = request_firmware(_p, rproc->firmware, dev);
+ if (ret < 0) {
+ dev_err(dev, "request_firmware failed: %d\n", ret);
+ goto downref_rproc;
+ }
+ } else {
+ /* set firmware name to null as unknown */
+ kfree(rproc->firmware);
+ rproc->firmware = NULL;
}
ret = rproc_fw_boot(rproc, firmware_p);
@@ -1917,8 +1927,17 @@ int rproc_add(struct rproc *rproc)
/* create debugfs entries */
rproc_create_debug_dir(rproc);
- /* if rproc is marked always-on, request it to boot */
- if (rproc->auto_boot) {
+ if (rproc->preloaded) {
+ /*
+* If rproc is marked already booted, no need to wait
+* for firmware.
+* Just handle associated resources and start sub devices
+*/
+ ret = rproc_boot(rproc);
+ if (ret < 0)
+ return ret;
+ } else if (rproc->auto_boot) {
+ /* if rproc is marked always-on, request it to boot */
ret = rproc_trigger_auto_boot(rproc);
if (ret < 0)
return ret;
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 8cd22fecea61..27f0dfdd3837 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -481,6 +481,7 @@ struct rproc_dump_segment {
* @recovery_disabled: flag that state if recovery was disabled
* @has_iommu: flag to indicate if remote processor is behind an MMU
* @auto_boot: flag to indicate if remote processor should be auto-started
+ * @preloaded: remote processor has been preloaded before start sequence
*/
struct rproc {
struct list_head node;
@@ -514,6 +515,7 @@ struct rproc {
u8 recovery_disabled;
u8 has_iommu;
u8 auto_boot;
+ u8 preloaded;
};
/**
--
2.7.4
RE: [PATCH v2] remoteproc: copy parent dma_pfn_offset for vdev
> -Original Message- > From: Christoph Hellwig > Sent: vendredi 19 juillet 2019 08:33 > To: Loic PALLARDY > Cc: Christoph Hellwig ; Clement Leger > ; Ohad Ben-Cohen ; Bjorn > Andersson ; linux- > remotep...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v2] remoteproc: copy parent dma_pfn_offset for vdev > > On Mon, Jul 08, 2019 at 11:45:46AM -0700, Christoph Hellwig wrote: > > > But that's breaking legacy as all platforms will have to add a virtio > > > device > node in > > > their DT file... > > > > > > Is it aligned with your view ? > > > > Yes, that is how I'd assume it works. But given that until recently > > you did now have these subdevices for dma coherent purposes we can't > > really break anything older than that, so I might still be missing > > something. > > Any chance we could expedite this? remoteproc is the only driver > inheriting dma ops to subdevices, and the only one using > dma_declare_coherent_memory. I'd really like to clean this mess up > rather sooner than later. Ongoing... Two topics to clean up: - Sub device creation and DMA ops inheritance --> need to use platform_device or device tree - dma_declare_coherent_memory use --> it has been introduced to support internal memories declared via reg field. I propose to migrate existing drivers on reserved memory usage and so remove dma_declare_coherent call from remoteproc core.
RE: [PATCH v2] remoteproc: copy parent dma_pfn_offset for vdev
Hi Christoph, > -Original Message- > From: Christoph Hellwig > Sent: mardi 2 juillet 2019 15:22 > To: Clement Leger > Cc: Ohad Ben-Cohen ; Bjorn Andersson > ; linux-remotep...@vger.kernel.org; linux- > ker...@vger.kernel.org; Loic PALLARDY > Subject: Re: [PATCH v2] remoteproc: copy parent dma_pfn_offset for vdev > > This is just increasing the mess remoteproc has created with the vdev. > It is poking its nose way to deep into the DMA layer internals, and > creating massive problems that way. Can we go back to the table > and figure out what the root problem even was? To me it seems if you > clearly need separate devices they should be declared as such in the > device tree. Agree there is definitively an issue with the way virtio device are defined. Today definition is based on rproc firmware ressource table and rproc framework is in charge of vdev creation. Device tree definition was discarded as vdev is not HW but SW definition. One solution would be to associate both resource table (which provides Firmware capabilities) and some virtio device tree nodes (declared as sub nodes of remote processor with associated resources like memory carveout). When we have a match between resource table and rproc DT sub node, we can register virtio device via of_platform_populate. Then need to adapt virtio_rpmsg or to create a virtio_rproc to be DT probe compliant like virtio_mmio is. But that's breaking legacy as all platforms will have to add a virtio device node in their DT file... Is it aligned with your view ? Regards, Loic
RE: linux-next: build failure after merge of the rpmsg tree
Hi, Changes in remoteproc have been introduced to associate dedicated dma coherent memory pool to each virtio device. It is needed when we have several virtio devices for which buffers can't be allocated from the same memory region. Patch introduces support in both ways: - memory region declared thanks to reserved memory and associated thanks to of_reserved_mem_device_init_by_idx(): mainly used for regions located in DDR. - memory region specified in rproc driver itself and defined as dma coherent thanks to dma_declare_coherent_memory(): These regions are generally located in coprocessor/SoC internal memories and declared in different ways by the different rproc drivers (regs in DT, hard coded values in drivers...). For me, dma_declare_coherent_memory based solution is there to allow a smooth transition from current rproc drivers implementations to a cleaner and unified one based on reserved memory declaration. Regards, Loic > -Original Message- > From: Christoph Hellwig > Sent: vendredi 22 février 2019 13:51 > To: Stephen Rothwell > Cc: Bjorn Andersson ; Christoph Hellwig > ; Linux Next Mailing List ; Linux > Kernel Mailing List ; Loic PALLARDY > > Subject: Re: linux-next: build failure after merge of the rpmsg tree > > FYI, can I please get an explanation for the remoteproc changes? > > We really should avoid adding new callers of > dma_declare_coherent_memory, > which is a rather badly designed interface.
RE: [PATCH v2 0/7] remoteproc: Fixes for memoy carveout management
Hi Bjorn, > -Original Message- > From: Loic PALLARDY > Sent: jeudi 10 janvier 2019 14:49 > To: bjorn.anders...@linaro.org; o...@wizery.com > Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; > Arnaud POULIQUEN ; > benjamin.gaign...@linaro.org; s-a...@ti.com; Loic PALLARDY > > Subject: [PATCH v2 0/7] remoteproc: Fixes for memoy carveout > management > > These patches fix the comments sent on remoteproc mailing > list after acceptation of memory carveout patch series [1]. > > In few words, series corrects: > - memory carveout allocation for rproc without iommu > - rproc_da_to_va and trace buffer access to take into account > late carveout allocation > - resource table cast by adding warning messages Could you please merge this series for next pull request as it contains only fixes of patches merged in kernel 4.20. Regards, Loic > > Regards, > Loic > > [1] https://lkml.org/lkml/2018/7/27/612 > > --- > Changes from v1: > - Modify way to notify resource table cast issue > - Complete trace buffer patch > > > Loic Pallardy (7): > remoteproc: correct rproc_mem_entry_init() comments > remoteproc: fix rproc_da_to_va in case of unallocated carveout > remoteproc: fix rproc_alloc_carveout() bad variable cast > remoteproc: add warning on resource table cast > remoteproc: fix rproc_alloc_carveout() for rproc with iommu domain > remoteproc: fix trace buffer va initialization > remoteproc: fix rproc_check_carveout_da() returned error and comments > > drivers/remoteproc/remoteproc_core.c | 108 ++- > > drivers/remoteproc/remoteproc_debugfs.c | 21 -- > drivers/remoteproc/remoteproc_internal.h | 9 ++- > 3 files changed, 89 insertions(+), 49 deletions(-) > > -- > 2.7.4
RE: [PATCH -next] remoteproc: make rproc_check_carveout_da static
Hi Yue,
> -Original Message-
> From: linux-remoteproc-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of YueHaibing
> Sent: vendredi 1 février 2019 04:13
> To: o...@wizery.com; bjorn.anders...@linaro.org
> Cc: linux-kernel@vger.kernel.org; linux-remotep...@vger.kernel.org;
> YueHaibing
> Subject: [PATCH -next] remoteproc: make rproc_check_carveout_da static
>
> Fixes the following sparse warnings:
>
> drivers/remoteproc/remoteproc_core.c:279:5: warning:
> symbol 'rproc_check_carveout_da' was not declared. Should it be static?
Correction already sent on ML few weeks ago. See [1]
Regards,
Loic
[1] https://patchwork.kernel.org/patch/10755763/
>
> Signed-off-by: YueHaibing
> ---
> drivers/remoteproc/remoteproc_core.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index 54ec38f..5d4954d 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -276,8 +276,9 @@ rproc_find_carveout_by_name(struct rproc *rproc,
> const char *name, ...)
> *
> * Return: 0 if carveout match request else -ENOMEM
> */
> -int rproc_check_carveout_da(struct rproc *rproc, struct rproc_mem_entry
> *mem,
> - u32 da, u32 len)
> +static int rproc_check_carveout_da(struct rproc *rproc,
> +struct rproc_mem_entry *mem,
> +u32 da, u32 len)
> {
> struct device *dev = >dev;
> int delta = 0;
> --
> 2.7.0
>
RE: [PATCH 1/1] remoteproc: fix recovery procedure
> -Original Message- > From: xiang xiao > Sent: lundi 21 janvier 2019 14:22 > To: Loic PALLARDY > Cc: Bjorn Andersson ; o...@wizery.com; > linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Arnaud > POULIQUEN ; benjamin.gaign...@linaro.org; s- > a...@ti.com > Subject: Re: [PATCH 1/1] remoteproc: fix recovery procedure > > On Fri, Jan 18, 2019 at 5:44 AM Loic PALLARDY wrote: > > > > > > > > > -Original Message- > > > From: linux-remoteproc-ow...@vger.kernel.org > > ow...@vger.kernel.org> On Behalf Of Loic PALLARDY > > > Sent: jeudi 17 janvier 2019 21:52 > > > To: Bjorn Andersson > > > Cc: xiang xiao ; o...@wizery.com; linux- > > > remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Arnaud > > > POULIQUEN ; > benjamin.gaign...@linaro.org; s- > > > a...@ti.com > > > Subject: RE: [PATCH 1/1] remoteproc: fix recovery procedure > > > > > > Hi Bjorn, > > > > > > > -Original Message- > > > > From: Bjorn Andersson > > > > Sent: jeudi 17 janvier 2019 19:00 > > > > To: Loic PALLARDY > > > > Cc: xiang xiao ; o...@wizery.com; linux- > > > > remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Arnaud > > > > POULIQUEN ; > benjamin.gaign...@linaro.org; > > > s- > > > > a...@ti.com > > > > Subject: Re: [PATCH 1/1] remoteproc: fix recovery procedure > > > > > > > > On Mon 14 Jan 12:23 PST 2019, Loic PALLARDY wrote: > > > > > > > > > Hi Xiang, > > > > > > > > > > > -Original Message- > > > > > > From: xiang xiao > > > > > > Sent: samedi 12 janvier 2019 19:29 > > > > > > To: Loic PALLARDY > > > > > > Cc: bjorn.anders...@linaro.org; o...@wizery.com; linux- > > > > > > remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; > Arnaud > > > > > > POULIQUEN ; > > > > benjamin.gaign...@linaro.org; s- > > > > > > a...@ti.com > > > > > > Subject: Re: [PATCH 1/1] remoteproc: fix recovery procedure > > > > > > > > > > > > > > Thanks Loic for picking this up again. > > > > > > > > > > Hi Loic, > > > > > > The change just hide the problem, I think. The big issue is: > > > > > > 1.virtio devices aren't destroyed by rpproc_stop > > > > > Virtio devices are destroyed by rproc_stop() as vdev is registered as > rproc > > > > sub device. > > > > > rproc_stop() is calling rproc_stop_subdevices() which is in charge of > > > > removing virtio device and associated children. > > > > > rproc_vdev_do_stop() --> rproc_remove_virtio_dev() --> > > > > unregister_virtio_device() > > > > > > > > > > > > > Xiang is right, unregister_virtio_device() ends up decrementing the > > > > refcount of device and might free it, but it's not guaranteed. > > > > > > But it that case calling rproc_shutdown() doesn't guarantee devices are > free, > > > it is the same. > > > The only difference will be that rproc_vdev will be released by rproc and > > > then reallocated. So virtio device allocation is restarting with a virgin > memory > > > buffer. But you will have some ghost devices and restart may failed too. > > > I post a fix [1] last summer to be sure virtio device won't be released > while > > > still registered or registering... So there is still potential issue. > > > > > > > > > > > So I think we need to decouple the rproc_vdev and virtio_device, to > > > > allow the latter to potentially outlive the prior. > > > > > > > I checked how to decouple at least the allocation because one issue here. > > > The main issue is that all references are done based on container_of(). > > > I look for a fix having the less impacts on the current code, but still > possible to > > > create cross pointer references between rproc_vdev and virtio device. > > > It will clean up the memory allocation procedure, but the problem is still > > > there if sub virtio devices not well release. > > > We need to not be able to restart remote processor if at least one sub > device > > > was not correctly release... > > > > > > > > Please find below trace of a recovery on my ST SOC. My 2 rpmsg tty > are > &g
RE: [PATCH 1/1] remoteproc: fix recovery procedure
> -Original Message- > From: xiang xiao > Sent: lundi 21 janvier 2019 13:45 > To: Loic PALLARDY > Cc: bjorn.anders...@linaro.org; o...@wizery.com; linux- > remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Arnaud > POULIQUEN ; benjamin.gaign...@linaro.org; s- > a...@ti.com > Subject: Re: [PATCH 1/1] remoteproc: fix recovery procedure > > On Fri, Jan 18, 2019 at 1:15 AM Loic PALLARDY wrote: > > > > Hi Xiang, > > > > > -Original Message- > > > From: linux-remoteproc-ow...@vger.kernel.org > > ow...@vger.kernel.org> On Behalf Of xiang xiao > > > Sent: mardi 15 janvier 2019 07:46 > > > To: Loic PALLARDY > > > Cc: bjorn.anders...@linaro.org; o...@wizery.com; linux- > > > remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Arnaud > > > POULIQUEN ; > benjamin.gaign...@linaro.org; s- > > > a...@ti.com > > > Subject: Re: [PATCH 1/1] remoteproc: fix recovery procedure > > > > > > Here is my output after apply your patch, the duplication device still > > > exist: > > > [ 48.012300] remoteproc remoteproc0: crash detected in > > > f921.toppwr:tl421-rproc: type watchdog > > > [ 48.023473] remoteproc remoteproc0: handling crash #1 in > > > f921.toppwr:tl421-rproc > > > [ 48.037504] remoteproc remoteproc0: recovering > f921.toppwr:tl421- > > > rproc > > > [ 48.048837] remoteproc remoteproc0: stopped remote processor > > > f921.toppwr:tl421-rproc > > > [ 48.061969] virtio_rpmsg_bus virtio2: rpmsg host is online > > > [ 48.061976] virtio_rpmsg_bus virtio2: creating channel rpmsg-ttyADSP > addr > > > 0x1 > > First rpmsg-ttyADSP announcement > > > > > [ 48.062956] virtio_rpmsg_bus virtio2: creating channel rpmsg-clk addr > 0x2 > > > [ 48.063489] virtio_rpmsg_bus virtio2: creating channel rpmsg-syslog > addr > > > 0x3 > > > [ 48.063815] virtio_rpmsg_bus virtio2: creating channel rpmsg-rtc addr > 0x4 > > > [ 48.064064] virtio_rpmsg_bus virtio2: creating channel rpmsg-ttyADSP > addr > > > 0x1 > > Second rpmsg-ttyADSP announcement > > > > > [ 48.064080] virtio_rpmsg_bus virtio2: channel > > > rpmsg-ttyADSP::1 already exist > > > [ 48.064087] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > > > [ 48.064102] virtio_rpmsg_bus virtio2: creating channel rpmsg-ttyADSP > addr > > > 0x1 > > > [ 48.064118] virtio_rpmsg_bus virtio2: channel > > > rpmsg-ttyADSP::1 already exist > > > [ 48.064127] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > > > [ 48.064139] virtio_rpmsg_bus virtio2: creating channel rpmsg-clk addr > 0x2 > > > [ 48.064153] virtio_rpmsg_bus virtio2: channel rpmsg-clk::2 > > > already exist > > > [ 48.064159] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > > > [ 48.064174] virtio_rpmsg_bus virtio2: creating channel rpmsg-syslog > addr > > > 0x3 > > > [ 48.064192] virtio_rpmsg_bus virtio2: channel > > > rpmsg-syslog::3 already exist > > > [ 48.064200] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > > > [ 48.064213] virtio_rpmsg_bus virtio2: creating channel rpmsg-rtc addr > 0x4 > > > [ 48.064229] virtio_rpmsg_bus virtio2: channel rpmsg-rtc::4 > > > already exist > > > [ 48.064235] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > > > [ 48.064286] virtio_rpmsg_bus virtio2: creating channel rpmsg-syslog > addr > > > 0x3 > > > [ 48.064302] virtio_rpmsg_bus virtio2: channel > > > rpmsg-syslog::3 already exist > > > [ 48.064306] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > > > [ 48.064318] virtio_rpmsg_bus virtio2: creating channel rpmsg-rtc addr > 0x4 > > > [ 48.064334] virtio_rpmsg_bus virtio2: channel rpmsg-rtc::4 > > > already exist > > > [ 48.064339] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > > > [ 48.064351] virtio_rpmsg_bus virtio2: creating channel rpmsg-hostfs > addr > > > 0x5 > > > [ 48.064773] virtio_rpmsg_bus virtio2: creating channel rpmsg-hostfs > addr > > > 0x5 > > > [ 48.064789] virtio_rpmsg_bus virtio2: channel > > > rpmsg-hostfs::5 already exist > > > [ 48.064797] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > > > [ 48.064930] virtio_rpmsg_bus virtio2: creating channel addr 0x5f7361 > > > [ 48.064945] virtio_rpmsg_bus virtio
[PATCH v2 1/1] remoteproc: fix recovery procedure
Commit 7e83cab824a87e83cab824a8 ("remoteproc: Modify recovery path
to use rproc_{start,stop}()") replaces rproc_{shutdown,boot}() with
rproc_{stop,start}(), which skips destroy the virtio device at stop
but re-initializes it again at start.
Issue is that struct virtio_dev is not correctly reinitialized like done
at initial allocation thanks to kzalloc() and kobject is considered as
already initialized by kernel. That is due to the fact struct virtio_dev
is allocated and released at vdev resource handling level managed and
virtio device is registered and unregistered at rproc subdevices level.
Moreover kernel documentation mentions that device struct must be
zero initialized before calling device_initialize().
This patch disentangles struct virtio_dev from struct rproc_vdev as
the two struct don't have the same life-cycle.
struct virtio_dev is now allocated on rproc_start() and released
on rproc_stop().
This patch applies on top of patch
remoteproc: create vdev subdevice with specific dma memory pool [1]
[1]: https://patchwork.kernel.org/patch/10755781/
Fixes: 7e83cab824a8 ("remoteproc: Modify recovery path to use
rproc_{start,stop}()")
Reported-by: Xiang Xiao
Signed-off-by: Loic Pallardy
---
Changes from V1:
- Remove memset of a specific part of vdev
- Disentangle struct virtio_dev from struc rproc_dev which have
different life-cycles
- Update commit header according to new implementation
---
drivers/remoteproc/remoteproc_core.c | 5 -
drivers/remoteproc/remoteproc_internal.h | 2 +-
drivers/remoteproc/remoteproc_virtio.c | 20
include/linux/remoteproc.h | 3 +--
4 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 821dbedef18e..454a601d63c9 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -421,8 +421,11 @@ static int rproc_vdev_do_start(struct rproc_subdev *subdev)
static void rproc_vdev_do_stop(struct rproc_subdev *subdev, bool crashed)
{
struct rproc_vdev *rvdev = container_of(subdev, struct rproc_vdev,
subdev);
+ int ret;
- rproc_remove_virtio_dev(rvdev);
+ ret = device_for_each_child(>dev, NULL, rproc_remove_virtio_dev);
+ if (ret)
+ dev_warn(>dev, "can't remove vdev child device: %d\n",
ret);
}
/**
diff --git a/drivers/remoteproc/remoteproc_internal.h
b/drivers/remoteproc/remoteproc_internal.h
index bfeacfd40947..2698775c5005 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -32,7 +32,7 @@ void rproc_vdev_release(struct kref *ref);
/* from remoteproc_virtio.c */
int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id);
-void rproc_remove_virtio_dev(struct rproc_vdev *rvdev);
+int rproc_remove_virtio_dev(struct device *dev, void *data);
/* from remoteproc_debugfs.c */
void rproc_remove_trace_file(struct dentry *tfile);
diff --git a/drivers/remoteproc/remoteproc_virtio.c
b/drivers/remoteproc/remoteproc_virtio.c
index d08b2cfd875b..b7a987d1b962 100644
--- a/drivers/remoteproc/remoteproc_virtio.c
+++ b/drivers/remoteproc/remoteproc_virtio.c
@@ -313,6 +313,8 @@ static void rproc_virtio_dev_release(struct device *dev)
struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
struct rproc *rproc = vdev_to_rproc(vdev);
+ kfree(vdev);
+
kref_put(>refcount, rproc_vdev_release);
put_device(>dev);
@@ -331,7 +333,7 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
{
struct rproc *rproc = rvdev->rproc;
struct device *dev = >dev;
- struct virtio_device *vdev = >vdev;
+ struct virtio_device *vdev;
struct rproc_mem_entry *mem;
int ret;
@@ -372,6 +374,12 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
}
}
+ /* Allocate virtio device */
+ vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
+ if (!vdev) {
+ ret = -ENOMEM;
+ goto out;
+ }
vdev->id.device = id,
vdev->config = _virtio_config_ops,
vdev->dev.parent = dev;
@@ -405,11 +413,15 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
/**
* rproc_remove_virtio_dev() - remove an rproc-induced virtio device
- * @rvdev: the remote vdev
+ * @dev: the virtio device
+ * @data: must be null
*
* This function unregisters an existing virtio device.
*/
-void rproc_remove_virtio_dev(struct rproc_vdev *rvdev)
+int rproc_remove_virtio_dev(struct device *dev, void *data)
{
- unregister_virtio_device(>vdev);
+ struct virtio_device *vdev = dev_to_virtio(dev);
+
+ unregister_virtio_device(vdev);
+ return 0;
}
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index beecd8cf2eb5..1ec66f7519f5 100644
--- a/include/linux/remoteproc.h
+++ b/i
RE: [PATCH 1/1] remoteproc: fix recovery procedure
> -Original Message- > From: linux-remoteproc-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Loic PALLARDY > Sent: jeudi 17 janvier 2019 21:52 > To: Bjorn Andersson > Cc: xiang xiao ; o...@wizery.com; linux- > remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Arnaud > POULIQUEN ; benjamin.gaign...@linaro.org; s- > a...@ti.com > Subject: RE: [PATCH 1/1] remoteproc: fix recovery procedure > > Hi Bjorn, > > > -Original Message- > > From: Bjorn Andersson > > Sent: jeudi 17 janvier 2019 19:00 > > To: Loic PALLARDY > > Cc: xiang xiao ; o...@wizery.com; linux- > > remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Arnaud > > POULIQUEN ; benjamin.gaign...@linaro.org; > s- > > a...@ti.com > > Subject: Re: [PATCH 1/1] remoteproc: fix recovery procedure > > > > On Mon 14 Jan 12:23 PST 2019, Loic PALLARDY wrote: > > > > > Hi Xiang, > > > > > > > -Original Message- > > > > From: xiang xiao > > > > Sent: samedi 12 janvier 2019 19:29 > > > > To: Loic PALLARDY > > > > Cc: bjorn.anders...@linaro.org; o...@wizery.com; linux- > > > > remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Arnaud > > > > POULIQUEN ; > > benjamin.gaign...@linaro.org; s- > > > > a...@ti.com > > > > Subject: Re: [PATCH 1/1] remoteproc: fix recovery procedure > > > > > > > > Thanks Loic for picking this up again. > > > > > > Hi Loic, > > > > The change just hide the problem, I think. The big issue is: > > > > 1.virtio devices aren't destroyed by rpproc_stop > > > Virtio devices are destroyed by rproc_stop() as vdev is registered as > > > rproc > > sub device. > > > rproc_stop() is calling rproc_stop_subdevices() which is in charge of > > removing virtio device and associated children. > > > rproc_vdev_do_stop() --> rproc_remove_virtio_dev() --> > > unregister_virtio_device() > > > > > > > Xiang is right, unregister_virtio_device() ends up decrementing the > > refcount of device and might free it, but it's not guaranteed. > > But it that case calling rproc_shutdown() doesn't guarantee devices are free, > it is the same. > The only difference will be that rproc_vdev will be released by rproc and > then reallocated. So virtio device allocation is restarting with a virgin > memory > buffer. But you will have some ghost devices and restart may failed too. > I post a fix [1] last summer to be sure virtio device won't be released while > still registered or registering... So there is still potential issue. > > > > > So I think we need to decouple the rproc_vdev and virtio_device, to > > allow the latter to potentially outlive the prior. > > > I checked how to decouple at least the allocation because one issue here. > The main issue is that all references are done based on container_of(). > I look for a fix having the less impacts on the current code, but still > possible to > create cross pointer references between rproc_vdev and virtio device. > It will clean up the memory allocation procedure, but the problem is still > there if sub virtio devices not well release. > We need to not be able to restart remote processor if at least one sub device > was not correctly release... > > > > Please find below trace of a recovery on my ST SOC. My 2 rpmsg tty are > > removed and re-inserted correctly > > > root@stm32mp1:~# ls /dev/ttyRPMSG* > > > /dev/ttyRPMSG0 /dev/ttyRPMSG1 > > > root@stm32mp1:~# [ 154.832523] remoteproc remoteproc0: crash > > detected in m4: type watchdog > > > [ 154.837725] remoteproc remoteproc0: handling crash #2 in m4 > > > [ 154.843319] remoteproc remoteproc0: recovering m4 > > > [ 154.849185] rpmsg_tty virtio0.rpmsg-tty-channel.-1.0: rpmsg tty device > 0 > > is removed > > > [ 154.857572] rpmsg_tty virtio0.rpmsg-tty-channel.-1.1: rpmsg tty device > 1 > > is removed > > > [ 155.382327] remoteproc remoteproc0: warning: remote FW shutdown > > without ack > > > [ 155.387857] remoteproc remoteproc0: stopped remote processor m4 > > > [ 155.398988] m4@0#vdev0buffer: assigned reserved memory node > > vdev0buffer@10044000 > > > [ 155.405910] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty- > channel > > addr 0x0 > > > [ 155.413422] rpmsg_tty virtio0.rpmsg-tty-channel.-1.0: new channel: > > 0x400 -> 0x0 : ttyRPMSG0 > > > [ 155.421038] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty- &g
RE: [PATCH 1/1] remoteproc: fix recovery procedure
Hi Bjorn, > -Original Message- > From: Bjorn Andersson > Sent: jeudi 17 janvier 2019 19:00 > To: Loic PALLARDY > Cc: xiang xiao ; o...@wizery.com; linux- > remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Arnaud > POULIQUEN ; benjamin.gaign...@linaro.org; s- > a...@ti.com > Subject: Re: [PATCH 1/1] remoteproc: fix recovery procedure > > On Mon 14 Jan 12:23 PST 2019, Loic PALLARDY wrote: > > > Hi Xiang, > > > > > -Original Message- > > > From: xiang xiao > > > Sent: samedi 12 janvier 2019 19:29 > > > To: Loic PALLARDY > > > Cc: bjorn.anders...@linaro.org; o...@wizery.com; linux- > > > remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Arnaud > > > POULIQUEN ; > benjamin.gaign...@linaro.org; s- > > > a...@ti.com > > > Subject: Re: [PATCH 1/1] remoteproc: fix recovery procedure > > > > > Thanks Loic for picking this up again. > > > > Hi Loic, > > > The change just hide the problem, I think. The big issue is: > > > 1.virtio devices aren't destroyed by rpproc_stop > > Virtio devices are destroyed by rproc_stop() as vdev is registered as rproc > sub device. > > rproc_stop() is calling rproc_stop_subdevices() which is in charge of > removing virtio device and associated children. > > rproc_vdev_do_stop() --> rproc_remove_virtio_dev() --> > unregister_virtio_device() > > > > Xiang is right, unregister_virtio_device() ends up decrementing the > refcount of device and might free it, but it's not guaranteed. But it that case calling rproc_shutdown() doesn't guarantee devices are free, it is the same. The only difference will be that rproc_vdev will be released by rproc and then reallocated. So virtio device allocation is restarting with a virgin memory buffer. But you will have some ghost devices and restart may failed too. I post a fix [1] last summer to be sure virtio device won't be released while still registered or registering... So there is still potential issue. > > So I think we need to decouple the rproc_vdev and virtio_device, to > allow the latter to potentially outlive the prior. > I checked how to decouple at least the allocation because one issue here. The main issue is that all references are done based on container_of(). I look for a fix having the less impacts on the current code, but still possible to create cross pointer references between rproc_vdev and virtio device. It will clean up the memory allocation procedure, but the problem is still there if sub virtio devices not well release. We need to not be able to restart remote processor if at least one sub device was not correctly release... > > Please find below trace of a recovery on my ST SOC. My 2 rpmsg tty are > removed and re-inserted correctly > > root@stm32mp1:~# ls /dev/ttyRPMSG* > > /dev/ttyRPMSG0 /dev/ttyRPMSG1 > > root@stm32mp1:~# [ 154.832523] remoteproc remoteproc0: crash > detected in m4: type watchdog > > [ 154.837725] remoteproc remoteproc0: handling crash #2 in m4 > > [ 154.843319] remoteproc remoteproc0: recovering m4 > > [ 154.849185] rpmsg_tty virtio0.rpmsg-tty-channel.-1.0: rpmsg tty device 0 > is removed > > [ 154.857572] rpmsg_tty virtio0.rpmsg-tty-channel.-1.1: rpmsg tty device 1 > is removed > > [ 155.382327] remoteproc remoteproc0: warning: remote FW shutdown > without ack > > [ 155.387857] remoteproc remoteproc0: stopped remote processor m4 > > [ 155.398988] m4@0#vdev0buffer: assigned reserved memory node > vdev0buffer@10044000 > > [ 155.405910] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty-channel > addr 0x0 > > [ 155.413422] rpmsg_tty virtio0.rpmsg-tty-channel.-1.0: new channel: > 0x400 -> 0x0 : ttyRPMSG0 > > [ 155.421038] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty-channel > addr 0x1 > > [ 155.429088] rpmsg_tty virtio0.rpmsg-tty-channel.-1.1: new channel: > 0x401 -> 0x1 : ttyRPMSG1 > > [ 155.437338] virtio_rpmsg_bus virtio0: rpmsg host is online > > [ 155.442401] m4@0#vdev0buffer: registered virtio0 (type 7) > > [ 155.461154] remoteproc remoteproc0: remote processor m4 is now up > > ls /dev/ttyRPMSG* > > /dev/ttyRPMSG0 /dev/ttyRPMSG1 > > root@stm32mp1:~# > > > > As vdev is including in a larger struct allocated by rproc, it is safe > > to set it to 0 before initializing virtio device while rproc subdevice > > sequence is respected. > > > > It's likely that this works in most use cases, but if for some reason > there's additional references held those will operate on the object past > your clearing of it. In fact, as the memory is free/kzalloc, virtio device fields are not all at 0
RE: [PATCH 1/1] remoteproc: fix recovery procedure
Hi Xiang, > -Original Message- > From: linux-remoteproc-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of xiang xiao > Sent: mardi 15 janvier 2019 07:46 > To: Loic PALLARDY > Cc: bjorn.anders...@linaro.org; o...@wizery.com; linux- > remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Arnaud > POULIQUEN ; benjamin.gaign...@linaro.org; s- > a...@ti.com > Subject: Re: [PATCH 1/1] remoteproc: fix recovery procedure > > Here is my output after apply your patch, the duplication device still exist: > [ 48.012300] remoteproc remoteproc0: crash detected in > f921.toppwr:tl421-rproc: type watchdog > [ 48.023473] remoteproc remoteproc0: handling crash #1 in > f921.toppwr:tl421-rproc > [ 48.037504] remoteproc remoteproc0: recovering f921.toppwr:tl421- > rproc > [ 48.048837] remoteproc remoteproc0: stopped remote processor > f921.toppwr:tl421-rproc > [ 48.061969] virtio_rpmsg_bus virtio2: rpmsg host is online > [ 48.061976] virtio_rpmsg_bus virtio2: creating channel rpmsg-ttyADSP addr > 0x1 First rpmsg-ttyADSP announcement > [ 48.062956] virtio_rpmsg_bus virtio2: creating channel rpmsg-clk addr 0x2 > [ 48.063489] virtio_rpmsg_bus virtio2: creating channel rpmsg-syslog addr > 0x3 > [ 48.063815] virtio_rpmsg_bus virtio2: creating channel rpmsg-rtc addr 0x4 > [ 48.064064] virtio_rpmsg_bus virtio2: creating channel rpmsg-ttyADSP addr > 0x1 Second rpmsg-ttyADSP announcement > [ 48.064080] virtio_rpmsg_bus virtio2: channel > rpmsg-ttyADSP::1 already exist > [ 48.064087] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > [ 48.064102] virtio_rpmsg_bus virtio2: creating channel rpmsg-ttyADSP addr > 0x1 > [ 48.064118] virtio_rpmsg_bus virtio2: channel > rpmsg-ttyADSP::1 already exist > [ 48.064127] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > [ 48.064139] virtio_rpmsg_bus virtio2: creating channel rpmsg-clk addr 0x2 > [ 48.064153] virtio_rpmsg_bus virtio2: channel rpmsg-clk::2 > already exist > [ 48.064159] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > [ 48.064174] virtio_rpmsg_bus virtio2: creating channel rpmsg-syslog addr > 0x3 > [ 48.064192] virtio_rpmsg_bus virtio2: channel > rpmsg-syslog::3 already exist > [ 48.064200] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > [ 48.064213] virtio_rpmsg_bus virtio2: creating channel rpmsg-rtc addr 0x4 > [ 48.064229] virtio_rpmsg_bus virtio2: channel rpmsg-rtc::4 > already exist > [ 48.064235] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > [ 48.064286] virtio_rpmsg_bus virtio2: creating channel rpmsg-syslog addr > 0x3 > [ 48.064302] virtio_rpmsg_bus virtio2: channel > rpmsg-syslog::3 already exist > [ 48.064306] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > [ 48.064318] virtio_rpmsg_bus virtio2: creating channel rpmsg-rtc addr 0x4 > [ 48.064334] virtio_rpmsg_bus virtio2: channel rpmsg-rtc::4 > already exist > [ 48.064339] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > [ 48.064351] virtio_rpmsg_bus virtio2: creating channel rpmsg-hostfs addr > 0x5 > [ 48.064773] virtio_rpmsg_bus virtio2: creating channel rpmsg-hostfs addr > 0x5 > [ 48.064789] virtio_rpmsg_bus virtio2: channel > rpmsg-hostfs::5 already exist > [ 48.064797] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > [ 48.064930] virtio_rpmsg_bus virtio2: creating channel addr 0x5f7361 > [ 48.064945] virtio_rpmsg_bus virtio2: rpmsg_find_device failed > [ 48.064957] virtio_rpmsg_bus virtio2: creating channel rpmsg-rtc addr 0x4 > [ 48.064973] virtio_rpmsg_bus virtio2: channel rpmsg-rtc::4 > already exist > [ 48.064979] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > [ 48.065015] virtio_rpmsg_bus virtio2: creating channel rpmsg-hostfs addr > 0x5 > [ 48.065030] virtio_rpmsg_bus virtio2: channel > rpmsg-hostfs::5 already exist > [ 48.065035] virtio_rpmsg_bus virtio2: rpmsg_create_channel failed > [ 48.352150] remoteproc remoteproc0: registered virtio2 (type 7) > [ 48.358813] remoteproc remoteproc0: remote processor > f921.toppwr:tl421-rproc is now up > do I still miss any additional patch? In your trace, I can see that your rpmsg device are announced twice and error is on the second announcement which is normal as endpoint ID is already used. virtio_rpmsg_bus virtio2: rpmsg_create_channel failed --> means you can't get the requested idr. In code you pointing in [1] I can see that you are using optimized version of rpmsg, having zero copy features and maybe others coming from rpmsg-lite. On my side I'm testing with official release from OpenAMP and I have no modification on Linux rpmsg (on the top of ke
RE: [PATCH 1/1] remoteproc: fix recovery procedure
Hi Xiang,
> -Original Message-
> From: xiang xiao
> Sent: samedi 12 janvier 2019 19:29
> To: Loic PALLARDY
> Cc: bjorn.anders...@linaro.org; o...@wizery.com; linux-
> remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Arnaud
> POULIQUEN ; benjamin.gaign...@linaro.org; s-
> a...@ti.com
> Subject: Re: [PATCH 1/1] remoteproc: fix recovery procedure
>
> Hi Loic,
> The change just hide the problem, I think. The big issue is:
> 1.virtio devices aren't destroyed by rpproc_stop
Virtio devices are destroyed by rproc_stop() as vdev is registered as rproc sub
device.
rproc_stop() is calling rproc_stop_subdevices() which is in charge of removing
virtio device and associated children.
rproc_vdev_do_stop() --> rproc_remove_virtio_dev() -->
unregister_virtio_device()
Please find below trace of a recovery on my ST SOC. My 2 rpmsg tty are removed
and re-inserted correctly
root@stm32mp1:~# ls /dev/ttyRPMSG*
/dev/ttyRPMSG0 /dev/ttyRPMSG1
root@stm32mp1:~# [ 154.832523] remoteproc remoteproc0: crash detected in m4:
type watchdog
[ 154.837725] remoteproc remoteproc0: handling crash #2 in m4
[ 154.843319] remoteproc remoteproc0: recovering m4
[ 154.849185] rpmsg_tty virtio0.rpmsg-tty-channel.-1.0: rpmsg tty device 0 is
removed
[ 154.857572] rpmsg_tty virtio0.rpmsg-tty-channel.-1.1: rpmsg tty device 1 is
removed
[ 155.382327] remoteproc remoteproc0: warning: remote FW shutdown without ack
[ 155.387857] remoteproc remoteproc0: stopped remote processor m4
[ 155.398988] m4@0#vdev0buffer: assigned reserved memory node
vdev0buffer@10044000
[ 155.405910] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty-channel
addr 0x0
[ 155.413422] rpmsg_tty virtio0.rpmsg-tty-channel.-1.0: new channel: 0x400 ->
0x0 : ttyRPMSG0
[ 155.421038] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty-channel
addr 0x1
[ 155.429088] rpmsg_tty virtio0.rpmsg-tty-channel.-1.1: new channel: 0x401 ->
0x1 : ttyRPMSG1
[ 155.437338] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 155.442401] m4@0#vdev0buffer: registered virtio0 (type 7)
[ 155.461154] remoteproc remoteproc0: remote processor m4 is now up
ls /dev/ttyRPMSG*
/dev/ttyRPMSG0 /dev/ttyRPMSG1
root@stm32mp1:~#
As vdev is including in a larger struct allocated by rproc, it is safe to set
it to 0 before initializing virtio device while rproc subdevice sequence is
respected.
> 2.and then rpmsg child devices aren't destroyed too
> Then, when the remote start and create rpmsg channel again, the
> duplicated channel will appear in kernel.
> To fix this problem, we need go through rpproc_shutdown/rproc_boot to
> destroy all devices(virtio and rpmsg) and create them again.
Rproc_shutdown/rproc_boot is solving the issue too, except if rproc_boot() was
called several times and so rproc->power atomic not equal to 1.
Using only rproc_stop() and rproc_start() allows to preserve rproc->power and
so to be silent from rproc user pov.
Regards,
Loic
>
> Thanks
> Xiang
>
> On Wed, Jan 9, 2019 at 6:56 PM Loic Pallardy wrote:
> >
> > Commit 7e83cab824a87e83cab824a8 ("remoteproc: Modify recovery path
> > to use rproc_{start,stop}()") replaces rproc_{shutdown,boot}() with
> > rproc_{stop,start}(), which skips destroy the virtio device at stop
> > but re-initializes it again at start.
> >
> > Issue is that struct virtio_dev is not correctly reinitialized like done
> > at initial allocation thanks to kzalloc() and kobject is considered as
> > already initialized by kernel. That is due to the fact struct virtio_dev
> > is allocated and released at vdev resource handling level managed and
> > virtio device is registered and unregistered at rproc subdevices level.
> >
> > This patch initializes struct virtio_dev to 0 before using it and
> > registering it.
> >
> > Fixes: 7e83cab824a8 ("remoteproc: Modify recovery path to use
> rproc_{start,stop}()")
> >
> > Reported-by: Xiang Xiao
> > Signed-off-by: Loic Pallardy
> > ---
> > drivers/remoteproc/remoteproc_virtio.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/remoteproc/remoteproc_virtio.c
> b/drivers/remoteproc/remoteproc_virtio.c
> > index 183fc42a510a..88eade99395c 100644
> > --- a/drivers/remoteproc/remoteproc_virtio.c
> > +++ b/drivers/remoteproc/remoteproc_virtio.c
> > @@ -332,6 +332,8 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev,
> int id)
> > struct virtio_device *vdev = >vdev;
> > int ret;
> >
> > + /* Reset vdev struct as you don't know how it has been previously
> used */
> > + memset(vdev, 0, sizeof(struct virtio_device));
> > vdev->id.device = id,
> > vdev->config = _virtio_config_ops,
> > vdev->dev.parent = dev;
> > --
> > 2.7.4
> >
[PATCH v2 1/1] irqchip: stm32-exti: add domain translate function
Domain translate function is needed to recover irq
configuration parameters from DT node
Fixes: 927abfc4461e ("irqchip/stm32: Add stm32mp1 support with hierarchy
domain")
Signed-off-by: Loic Pallardy
---
Changes from v2:
- Use irq_domain_xlate_twocell helper
- Add Fixes: tag in commit message
---
drivers/irqchip/irq-stm32-exti.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/irqchip/irq-stm32-exti.c b/drivers/irqchip/irq-stm32-exti.c
index 6edfd4bfa169..a93296b9b45d 100644
--- a/drivers/irqchip/irq-stm32-exti.c
+++ b/drivers/irqchip/irq-stm32-exti.c
@@ -822,6 +822,7 @@ static int __init stm32_exti_init(const struct
stm32_exti_drv_data *drv_data,
static const struct irq_domain_ops stm32_exti_h_domain_ops = {
.alloc = stm32_exti_h_domain_alloc,
.free = irq_domain_free_irqs_common,
+ .xlate = irq_domain_xlate_twocell,
};
static int
--
2.7.4
RE: [PATCH 1/1] irqchip: stm32-exti: add domain translate function
Hi Marc,
Thanks for the review
> -Original Message-
> From: Marc Zyngier
> Sent: vendredi 11 janvier 2019 16:52
> To: Loic PALLARDY ; t...@linutronix.de;
> ja...@lakedaemon.net; mcoquelin.st...@gmail.com; Alexandre TORGUE
>
> Cc: linux-kernel@vger.kernel.org; linux-stm32@st-md-
> mailman.stormreply.com; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 1/1] irqchip: stm32-exti: add domain translate function
>
> On 11/01/2019 13:58, Loic Pallardy wrote:
> > Domain translate function is needed to recover irq
> > configuration parameters from DT node
> >
> > Signed-off-by: Loic Pallardy
>
> Surely this fixes something, right? Can you please add a Fixes: tag?
Yes I will add tag of patch introducing hierarchical domain
>
> > ---
> > drivers/irqchip/irq-stm32-exti.c | 18 ++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/irqchip/irq-stm32-exti.c b/drivers/irqchip/irq-stm32-
> exti.c
> > index 6edfd4bfa169..717879028cc4 100644
> > --- a/drivers/irqchip/irq-stm32-exti.c
> > +++ b/drivers/irqchip/irq-stm32-exti.c
> > @@ -819,9 +819,27 @@ static int __init stm32_exti_init(const struct
> stm32_exti_drv_data *drv_data,
> > return ret;
> > }
> >
> > +static int stm32_exti_h_translate(struct irq_domain *d,
> > + struct irq_fwspec *fwspec,
> > + unsigned long *out_hwirq,
> > + unsigned int *out_type)
> > +{
> > + if (is_of_node(fwspec->fwnode)) {
>
> Is there any case where this wouldn't be true? i.e. an stm32 ACPI system?
You're right, no ACPI so check useless
>
> > + if (fwspec->param_count != 2)
> > + return -EINVAL;
> > +
> > + *out_hwirq = fwspec->param[0];
> > + *out_type = fwspec->param[1] & IRQ_TYPE_SENSE_MASK;
> > + return 0;
> > + }
> > +
> > + return -EINVAL;
> > +}
>
> Because otherwise, this is exactly what irq_domain_xlate_twocell() does.
Thanks for pointing me this helper. Indeed no need to duplicate code
I'll send a v2
Regards,
Loic
>
> > +
> > static const struct irq_domain_ops stm32_exti_h_domain_ops = {
> > .alloc = stm32_exti_h_domain_alloc,
> > .free = irq_domain_free_irqs_common,
> > + .translate = stm32_exti_h_translate,
> > };
> >
> > static int
> >
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
[PATCH 1/1] irqchip: stm32-exti: add domain translate function
Domain translate function is needed to recover irq
configuration parameters from DT node
Signed-off-by: Loic Pallardy
---
drivers/irqchip/irq-stm32-exti.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/irqchip/irq-stm32-exti.c b/drivers/irqchip/irq-stm32-exti.c
index 6edfd4bfa169..717879028cc4 100644
--- a/drivers/irqchip/irq-stm32-exti.c
+++ b/drivers/irqchip/irq-stm32-exti.c
@@ -819,9 +819,27 @@ static int __init stm32_exti_init(const struct
stm32_exti_drv_data *drv_data,
return ret;
}
+static int stm32_exti_h_translate(struct irq_domain *d,
+ struct irq_fwspec *fwspec,
+ unsigned long *out_hwirq,
+ unsigned int *out_type)
+{
+ if (is_of_node(fwspec->fwnode)) {
+ if (fwspec->param_count != 2)
+ return -EINVAL;
+
+ *out_hwirq = fwspec->param[0];
+ *out_type = fwspec->param[1] & IRQ_TYPE_SENSE_MASK;
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
static const struct irq_domain_ops stm32_exti_h_domain_ops = {
.alloc = stm32_exti_h_domain_alloc,
.free = irq_domain_free_irqs_common,
+ .translate = stm32_exti_h_translate,
};
static int
--
2.7.4
[PATCH 1/1] rpmsg: virtio: change header file sort style
Make header files alphabetical order. Signed-off-by: Loic Pallardy --- drivers/rpmsg/virtio_rpmsg_bus.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c index 664f957012cd..e1d563fbfe65 100644 --- a/drivers/rpmsg/virtio_rpmsg_bus.c +++ b/drivers/rpmsg/virtio_rpmsg_bus.c @@ -11,21 +11,21 @@ #define pr_fmt(fmt) "%s: " fmt, __func__ +#include +#include +#include #include #include -#include -#include -#include +#include +#include +#include #include -#include #include -#include -#include #include +#include +#include +#include #include -#include -#include -#include #include "rpmsg_internal.h" -- 2.7.4
[PATCH v2 3/3] rpmsg: virtio: allocate buffer from parent
Remoteproc is now capable to create one specific sub-device per
virtio link to associate a dedicated memory pool.
This implies to change device used by virtio_rpmsg for
buffer allocation from grand-parent to parent.
Signed-off-by: Loic Pallardy
Reviewed-by: Anup Patel
Tested-by: Anup Patel
---
drivers/rpmsg/virtio_rpmsg_bus.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 664f957012cd..5c892019ce89 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -912,7 +912,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
total_buf_space = vrp->num_bufs * vrp->buf_size;
/* allocate coherent memory for the buffers */
- bufs_va = dma_alloc_coherent(vdev->dev.parent->parent,
+ bufs_va = dma_alloc_coherent(vdev->dev.parent,
total_buf_space, >bufs_dma,
GFP_KERNEL);
if (!bufs_va) {
@@ -980,7 +980,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
return 0;
free_coherent:
- dma_free_coherent(vdev->dev.parent->parent, total_buf_space,
+ dma_free_coherent(vdev->dev.parent, total_buf_space,
bufs_va, vrp->bufs_dma);
vqs_del:
vdev->config->del_vqs(vrp->vdev);
@@ -1015,7 +1015,7 @@ static void rpmsg_remove(struct virtio_device *vdev)
vdev->config->del_vqs(vrp->vdev);
- dma_free_coherent(vdev->dev.parent->parent, total_buf_space,
+ dma_free_coherent(vdev->dev.parent, total_buf_space,
vrp->rbufs, vrp->bufs_dma);
kfree(vrp);
--
2.7.4
[PATCH v2 2/3] remoteproc: st: add reserved memory support
ST remote processor needs some specified memory regions for
firmware and IPC.
Memory regions are defined as reserved memory and should
be registered in remoteproc core thanks to rproc_add_carveout
function before rproc_start. For this, st rproc driver implements
prepare ops.
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/st_remoteproc.c | 91 +-
1 file changed, 80 insertions(+), 11 deletions(-)
diff --git a/drivers/remoteproc/st_remoteproc.c
b/drivers/remoteproc/st_remoteproc.c
index aacef0ea3b90..51049d17b1e5 100644
--- a/drivers/remoteproc/st_remoteproc.c
+++ b/drivers/remoteproc/st_remoteproc.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -91,6 +92,77 @@ static void st_rproc_kick(struct rproc *rproc, int vqid)
dev_err(dev, "failed to send message via mbox: %d\n", ret);
}
+static int st_rproc_mem_alloc(struct rproc *rproc,
+ struct rproc_mem_entry *mem)
+{
+ struct device *dev = rproc->dev.parent;
+ void *va;
+
+ va = ioremap_wc(mem->dma, mem->len);
+ if (!va) {
+ dev_err(dev, "Unable to map memory region: %pa+%zx\n",
+ >dma, mem->len);
+ return -ENOMEM;
+ }
+
+ /* Update memory entry va */
+ mem->va = va;
+
+ return 0;
+}
+
+static int st_rproc_mem_release(struct rproc *rproc,
+ struct rproc_mem_entry *mem)
+{
+ iounmap(mem->va);
+
+ return 0;
+}
+
+static int st_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
+{
+ struct device *dev = rproc->dev.parent;
+ struct device_node *np = dev->of_node;
+ struct rproc_mem_entry *mem;
+ struct reserved_mem *rmem;
+ struct of_phandle_iterator it;
+ int index = 0;
+
+ of_phandle_iterator_init(, np, "memory-region", NULL, 0);
+ while (of_phandle_iterator_next() == 0) {
+ rmem = of_reserved_mem_lookup(it.node);
+ if (!rmem) {
+ dev_err(dev, "unable to acquire memory-region\n");
+ return -EINVAL;
+ }
+
+ /* No need to map vdev buffer */
+ if (strcmp(it.node->name, "vdev0buffer")) {
+ /* Register memory region */
+ mem = rproc_mem_entry_init(dev, NULL,
+ (dma_addr_t)rmem->base,
+ rmem->size, rmem->base,
+ st_rproc_mem_alloc,
+ st_rproc_mem_release,
+ it.node->name);
+ } else {
+ /* Register reserved memory for vdev buffer allocation
*/
+ mem = rproc_of_resm_mem_entry_init(dev, index,
+ rmem->size,
+ rmem->base,
+ it.node->name);
+ }
+
+ if (!mem)
+ return -ENOMEM;
+
+ rproc_add_carveout(rproc, mem);
+ index++;
+ }
+
+ return rproc_elf_load_rsc_table(rproc, fw);
+}
+
static int st_rproc_start(struct rproc *rproc)
{
struct st_rproc *ddata = rproc->priv;
@@ -158,9 +230,14 @@ static int st_rproc_stop(struct rproc *rproc)
}
static const struct rproc_ops st_rproc_ops = {
- .kick = st_rproc_kick,
- .start = st_rproc_start,
- .stop = st_rproc_stop,
+ .kick = st_rproc_kick,
+ .start = st_rproc_start,
+ .stop = st_rproc_stop,
+ .parse_fw = st_rproc_parse_fw,
+ .load = rproc_elf_load_segments,
+ .find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
+ .sanity_check = rproc_elf_sanity_check,
+ .get_boot_addr = rproc_elf_get_boot_addr,
};
/*
@@ -254,12 +331,6 @@ static int st_rproc_parse_dt(struct platform_device *pdev)
return -EINVAL;
}
- err = of_reserved_mem_device_init(dev);
- if (err) {
- dev_err(dev, "Failed to obtain shared memory\n");
- return err;
- }
-
err = clk_prepare(ddata->clk);
if (err)
dev_err(dev, "failed to get clock\n");
@@ -387,8 +458,6 @@ static int st_rproc_remove(struct platform_device *pdev)
clk_disable_unprepare(ddata->clk);
- of_reserved_mem_device_release(>dev);
-
for (i = 0; i < ST_RPROC_MAX_VRING * MBOX_MAX; i++)
mbox_free_channel(ddata->mbox_chan[i]);
--
2.7.4
[PATCH v2 1/3] remoteproc: create vdev subdevice with specific dma memory pool
This patch creates a dedicated vdev subdevice for each vdev declared
in firmware resource table and associates carveout named "vdev%dbuffer"
(with %d vdev index in resource table) if any as dma coherent memory pool.
Then vdev subdevice is used as parent for virtio device.
Signed-off-by: Loic Pallardy
---
Changes from v1:
- rebase on v5.0-rc1 (dma_declare_coherent_memory() API change)
- call put_device() in case of error returned by device_register()
---
drivers/remoteproc/remoteproc_core.c | 47 ++--
drivers/remoteproc/remoteproc_internal.h | 1 +
drivers/remoteproc/remoteproc_virtio.c | 42 +++-
include/linux/remoteproc.h | 1 +
4 files changed, 87 insertions(+), 4 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 54ec38fc5dca..821dbedef18e 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -39,9 +39,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include "remoteproc_internal.h"
@@ -145,7 +147,7 @@ static void rproc_disable_iommu(struct rproc *rproc)
iommu_domain_free(domain);
}
-static phys_addr_t rproc_va_to_pa(void *cpu_addr)
+phys_addr_t rproc_va_to_pa(void *cpu_addr)
{
/*
* Return physical address according to virtual address location
@@ -160,6 +162,7 @@ static phys_addr_t rproc_va_to_pa(void *cpu_addr)
WARN_ON(!virt_addr_valid(cpu_addr));
return virt_to_phys(cpu_addr);
}
+EXPORT_SYMBOL(rproc_va_to_pa);
/**
* rproc_da_to_va() - lookup the kernel virtual address for a remoteproc
address
@@ -423,6 +426,20 @@ static void rproc_vdev_do_stop(struct rproc_subdev
*subdev, bool crashed)
}
/**
+ * rproc_rvdev_release() - release the existence of a rvdev
+ *
+ * @dev: the subdevice's dev
+ */
+static void rproc_rvdev_release(struct device *dev)
+{
+ struct rproc_vdev *rvdev = container_of(dev, struct rproc_vdev, dev);
+
+ of_reserved_mem_device_release(dev);
+
+ kfree(rvdev);
+}
+
+/**
* rproc_handle_vdev() - handle a vdev fw resource
* @rproc: the remote processor
* @rsc: the vring resource descriptor
@@ -455,6 +472,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct
fw_rsc_vdev *rsc,
struct device *dev = >dev;
struct rproc_vdev *rvdev;
int i, ret;
+ char name[16];
/* make sure resource isn't truncated */
if (sizeof(*rsc) + rsc->num_of_vrings * sizeof(struct fw_rsc_vdev_vring)
@@ -488,6 +506,29 @@ static int rproc_handle_vdev(struct rproc *rproc, struct
fw_rsc_vdev *rsc,
rvdev->rproc = rproc;
rvdev->index = rproc->nb_vdev++;
+ /* Initialise vdev subdevice */
+ snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
+ rvdev->dev.parent = rproc->dev.parent;
+ rvdev->dev.release = rproc_rvdev_release;
+ dev_set_name(>dev, "%s#%s", dev_name(rvdev->dev.parent), name);
+ dev_set_drvdata(>dev, rvdev);
+
+ ret = device_register(>dev);
+ if (ret) {
+ put_device(>dev);
+ return ret;
+ }
+ /* Make device dma capable by inheriting from parent's capabilities */
+ set_dma_ops(>dev, get_dma_ops(rproc->dev.parent));
+
+ ret = dma_coerce_mask_and_coherent(>dev,
+ dma_get_mask(rproc->dev.parent));
+ if (ret) {
+ dev_warn(dev,
+"Failed to set DMA mask %llx. Trying to continue...
%x\n",
+dma_get_mask(rproc->dev.parent), ret);
+ }
+
/* parse the vrings */
for (i = 0; i < rsc->num_of_vrings; i++) {
ret = rproc_parse_vring(rvdev, rsc, i);
@@ -518,7 +559,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct
fw_rsc_vdev *rsc,
for (i--; i >= 0; i--)
rproc_free_vring(>vring[i]);
free_rvdev:
- kfree(rvdev);
+ device_unregister(>dev);
return ret;
}
@@ -536,7 +577,7 @@ void rproc_vdev_release(struct kref *ref)
rproc_remove_subdev(rproc, >subdev);
list_del(>node);
- kfree(rvdev);
+ device_unregister(>dev);
}
/**
diff --git a/drivers/remoteproc/remoteproc_internal.h
b/drivers/remoteproc/remoteproc_internal.h
index f6cad243d7ca..bfeacfd40947 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -52,6 +52,7 @@ void rproc_free_vring(struct rproc_vring *rvring);
int rproc_alloc_vring(struct rproc_vdev *rvdev, int i);
void *rproc_da_to_va(struct rproc *rproc, u64 da, int len);
+phys_addr_t rproc_va_to_pa(void *cpu_addr);
int rproc_trigger_recovery(struct rproc *rproc);
int rproc_elf_sanity_check(struct rproc *rproc, const str
[PATCH v2 0/3] remoteproc: complete fixed memory region support
This new series corresponds to the remaining patches from [1] addressing fixed memory region support for remote processor. The three remaining patches allow to: - assign a specific memory region to vdev sub device. As all virtio based services are using virtio device parent for memory allocation, I propose to keep a dedicated vdev device per virtio link for memory allocation. A second step will be to used virtio device itself. - migrate ST driver on new memory carveout management - allocate virtio rpmsg buffer from parent device Regards, Loic [1] https://lkml.org/lkml/2018/7/27/612 --- Changes from V1: - rebase on kernel v5.0-rc0 - correct error management for device registering Loic Pallardy (3): remoteproc: create vdev subdevice with specific dma memory pool remoteproc: st: add reserved memory support rpmsg: virtio: allocate buffer from parent drivers/remoteproc/remoteproc_core.c | 47 +++-- drivers/remoteproc/remoteproc_internal.h | 1 + drivers/remoteproc/remoteproc_virtio.c | 42 ++- drivers/remoteproc/st_remoteproc.c | 91 drivers/rpmsg/virtio_rpmsg_bus.c | 6 +-- include/linux/remoteproc.h | 1 + 6 files changed, 170 insertions(+), 18 deletions(-) -- 2.7.4
[PATCH v2 3/7] remoteproc: fix rproc_alloc_carveout() bad variable cast
As dma member of struct rproc_mem_entry is dma_addr_t, no
need to cast in u32.
Fixes: d7c51706d095 ("remoteproc: add alloc ops in rproc_mem_entry struct")
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 28df71cb3fef..18a1bbf820c9 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -775,7 +775,7 @@ static int rproc_alloc_carveout(struct rproc *rproc,
mem->da = (u32)dma;
}
- mem->dma = (u32)dma;
+ mem->dma = dma;
mem->va = va;
return 0;
--
2.7.4
[PATCH v2 7/7] remoteproc: fix rproc_check_carveout_da() returned error and comments
Fix typo in comments.
Change returned error from ENOMEM to EINVAL as
not dealing with memory allocation.
Remove carveout forced da update and return an error
when no configuration match
Fixes: c874bf59add0 ("remoteproc: add helper function to check carveout device
address")
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 45d97871ca69..fc9bf99cd96f 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -278,25 +278,27 @@ rproc_find_carveout_by_name(struct rproc *rproc, const
char *name, ...)
* @len: associated area size
*
* This function is a helper function to verify requested device area (couple
- * da, len) is part of specified carevout.
+ * da, len) is part of specified carveout.
+ * If da is not set (defined as FW_RSC_ADDR_ANY), only requested length is
+ * checked.
*
- * Return: 0 if carveout match request else -ENOMEM
+ * Return: 0 if carveout matches request else error
*/
-int rproc_check_carveout_da(struct rproc *rproc, struct rproc_mem_entry *mem,
- u32 da, u32 len)
+static int rproc_check_carveout_da(struct rproc *rproc,
+ struct rproc_mem_entry *mem, u32 da, u32 len)
{
struct device *dev = >dev;
- int delta = 0;
+ int delta;
/* Check requested resource length */
if (len > mem->len) {
dev_err(dev, "Registered carveout doesn't fit len request\n");
- return -ENOMEM;
+ return -EINVAL;
}
if (da != FW_RSC_ADDR_ANY && mem->da == FW_RSC_ADDR_ANY) {
- /* Update existing carveout da */
- mem->da = da;
+ /* Address doesn't match registered carveout configuration */
+ return -EINVAL;
} else if (da != FW_RSC_ADDR_ANY && mem->da != FW_RSC_ADDR_ANY) {
delta = da - mem->da;
@@ -304,13 +306,13 @@ int rproc_check_carveout_da(struct rproc *rproc, struct
rproc_mem_entry *mem,
if (delta < 0) {
dev_err(dev,
"Registered carveout doesn't fit da request\n");
- return -ENOMEM;
+ return -EINVAL;
}
if (delta + len > mem->len) {
dev_err(dev,
"Registered carveout doesn't fit len
request\n");
- return -ENOMEM;
+ return -EINVAL;
}
}
--
2.7.4
[PATCH v2 4/7] remoteproc: add warning on resource table cast
Today resource table supports only 32bit address fields.
This is not compliant with 64bit platform for which addresses
are cast in 32bit.
This patch adds warn messages when address cast is done.
Signed-off-by: Loic Pallardy
---
Changes from v1:
- modify implementation to display warning message only when
data are modified by cast operation
---
drivers/remoteproc/remoteproc_core.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 18a1bbf820c9..0ecd37993f41 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -45,6 +45,8 @@
#include "remoteproc_internal.h"
+#define HIGH_BITS_MASK 0xULL
+
static DEFINE_MUTEX(rproc_list_mutex);
static LIST_HEAD(rproc_list);
@@ -772,6 +774,10 @@ static int rproc_alloc_carveout(struct rproc *rproc,
dev_dbg(dev, "carveout mapped 0x%x to %pad\n",
mem->da, );
} else {
+ /* Update device address as undefined by requester */
+ if ((u64)dma & HIGH_BITS_MASK)
+ dev_warn(dev, "DMA address cast in 32bit to fit
resource table format\n");
+
mem->da = (u32)dma;
}
@@ -1115,6 +1121,7 @@ static int rproc_alloc_registered_carveouts(struct rproc
*rproc)
struct rproc_mem_entry *entry, *tmp;
struct fw_rsc_carveout *rsc;
struct device *dev = >dev;
+ u64 pa;
int ret;
list_for_each_entry_safe(entry, tmp, >carveouts, node) {
@@ -1151,10 +1158,15 @@ static int rproc_alloc_registered_carveouts(struct
rproc *rproc)
/* Use va if defined else dma to generate pa */
if (entry->va)
- rsc->pa = (u32)rproc_va_to_pa(entry->va);
+ pa = (u64)rproc_va_to_pa(entry->va);
else
- rsc->pa = (u32)entry->dma;
+ pa = (u64)entry->dma;
+
+ if (((u64)pa) & HIGH_BITS_MASK)
+ dev_warn(dev,
+"Physical address cast in 32bit to fit
resource table format\n");
+ rsc->pa = (u32)pa;
rsc->da = entry->da;
rsc->len = entry->len;
}
--
2.7.4
[PATCH v2 6/7] remoteproc: fix trace buffer va initialization
With rproc_alloc_registered_carveouts() introduction, carveouts are
allocated after resource table parsing.
rproc_da_to_va() may return NULL at trace resource registering.
This patch modifies trace debufs registering to provide device address
(da) instead of va.
da to va translation is done at each trace buffer access
through debugfs interface.
Fixes: d7c51706d095 ("remoteproc: add alloc ops in rproc_mem_entry struct")
Signed-off-by: Loic Pallardy
---
Changes from v1:
- Add missing implementation in rproc_resources_cleanup()
---
drivers/remoteproc/remoteproc_core.c | 35 ++--
drivers/remoteproc/remoteproc_debugfs.c | 21 +++
drivers/remoteproc/remoteproc_internal.h | 9 +++-
3 files changed, 40 insertions(+), 25 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index e85722ee156b..45d97871ca69 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -564,9 +564,8 @@ void rproc_vdev_release(struct kref *ref)
static int rproc_handle_trace(struct rproc *rproc, struct fw_rsc_trace *rsc,
int offset, int avail)
{
- struct rproc_mem_entry *trace;
+ struct rproc_debug_trace *trace;
struct device *dev = >dev;
- void *ptr;
char name[15];
if (sizeof(*rsc) > avail) {
@@ -580,28 +579,23 @@ static int rproc_handle_trace(struct rproc *rproc, struct
fw_rsc_trace *rsc,
return -EINVAL;
}
- /* what's the kernel address of this resource ? */
- ptr = rproc_da_to_va(rproc, rsc->da, rsc->len);
- if (!ptr) {
- dev_err(dev, "erroneous trace resource entry\n");
- return -EINVAL;
- }
-
trace = kzalloc(sizeof(*trace), GFP_KERNEL);
if (!trace)
return -ENOMEM;
/* set the trace buffer dma properties */
- trace->len = rsc->len;
- trace->va = ptr;
+ trace->trace_mem.len = rsc->len;
+ trace->trace_mem.da = rsc->da;
+
+ /* set pointer on rproc device */
+ trace->rproc = rproc;
/* make sure snprintf always null terminates, even if truncating */
snprintf(name, sizeof(name), "trace%d", rproc->num_traces);
/* create the debugfs entry */
- trace->priv = rproc_create_trace_file(name, rproc, trace);
- if (!trace->priv) {
- trace->va = NULL;
+ trace->tfile = rproc_create_trace_file(name, rproc, trace);
+ if (!trace->tfile) {
kfree(trace);
return -EINVAL;
}
@@ -610,8 +604,8 @@ static int rproc_handle_trace(struct rproc *rproc, struct
fw_rsc_trace *rsc,
rproc->num_traces++;
- dev_dbg(dev, "%s added: va %pK, da 0x%x, len 0x%x\n",
- name, ptr, rsc->da, rsc->len);
+ dev_dbg(dev, "%s added: da 0x%x, len 0x%x\n",
+ name, rsc->da, rsc->len);
return 0;
}
@@ -1205,15 +1199,16 @@ static void rproc_coredump_cleanup(struct rproc *rproc)
static void rproc_resource_cleanup(struct rproc *rproc)
{
struct rproc_mem_entry *entry, *tmp;
+ struct rproc_debug_trace *trace, *ttmp;
struct rproc_vdev *rvdev, *rvtmp;
struct device *dev = >dev;
/* clean up debugfs trace entries */
- list_for_each_entry_safe(entry, tmp, >traces, node) {
- rproc_remove_trace_file(entry->priv);
+ list_for_each_entry_safe(trace, ttmp, >traces, node) {
+ rproc_remove_trace_file(trace->tfile);
rproc->num_traces--;
- list_del(>node);
- kfree(entry);
+ list_del(>node);
+ kfree(trace);
}
/* clean up iommu mapping entries */
diff --git a/drivers/remoteproc/remoteproc_debugfs.c
b/drivers/remoteproc/remoteproc_debugfs.c
index e90135c64af0..11240b4d0a91 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -47,10 +47,23 @@ static struct dentry *rproc_dbg;
static ssize_t rproc_trace_read(struct file *filp, char __user *userbuf,
size_t count, loff_t *ppos)
{
- struct rproc_mem_entry *trace = filp->private_data;
- int len = strnlen(trace->va, trace->len);
+ struct rproc_debug_trace *data = filp->private_data;
+ struct rproc_mem_entry *trace = >trace_mem;
+ void *va;
+ char buf[100];
+ int len;
+
+ va = rproc_da_to_va(data->rproc, trace->da, trace->len);
+
+ if (!va) {
+ len = scnprintf(buf, sizeof(buf), "Trace %s not available\n",
+ trace->name);
+ va = buf;
+ } else {
+ len = strnlen(va, trace->le
[PATCH v2 5/7] remoteproc: fix rproc_alloc_carveout() for rproc with iommu domain
Correct remoteproc core behavior when memory carveout device
address is fixed in resource table and rproc device doesn't have
associated IOMMU.
Current returned error is breaking legacy on TI platforms.
This patch restores previous behavior. It adds a warn message when
allocation doesn't fit carveout request, but doesn't stop rproc_start()
sequence anymore.
Fixes: 3bc8140b157c ("remoteproc: configure IOMMU only if device address
requested")
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 0ecd37993f41..e85722ee156b 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -721,6 +721,18 @@ static int rproc_alloc_carveout(struct rproc *rproc,
dev_dbg(dev, "carveout va %pK, dma %pad, len 0x%x\n",
va, , mem->len);
+ if (mem->da != FW_RSC_ADDR_ANY && !rproc->domain) {
+ /*
+* Check requested da is equal to dma address
+* and print a warn message in case of missalignment.
+* Don't stop rproc_start sequence as coprocessor may
+* build pa to da translation on its side.
+*/
+ if (mem->da != (u32)dma)
+ dev_warn(dev->parent,
+"Allocated carveout doesn't fit device address
request\n");
+ }
+
/*
* Ok, this is non-standard.
*
@@ -738,15 +750,7 @@ static int rproc_alloc_carveout(struct rproc *rproc,
* to use the iommu-based DMA API: we expect 'dma' to contain the
* physical address in this case.
*/
-
- if (mem->da != FW_RSC_ADDR_ANY) {
- if (!rproc->domain) {
- dev_err(dev->parent,
- "Bad carveout rsc configuration\n");
- ret = -ENOMEM;
- goto dma_free;
- }
-
+ if (mem->da != FW_RSC_ADDR_ANY && rproc->domain) {
mapping = kzalloc(sizeof(*mapping), GFP_KERNEL);
if (!mapping) {
ret = -ENOMEM;
@@ -773,7 +777,9 @@ static int rproc_alloc_carveout(struct rproc *rproc,
dev_dbg(dev, "carveout mapped 0x%x to %pad\n",
mem->da, );
- } else {
+ }
+
+ if (mem->da == FW_RSC_ADDR_ANY) {
/* Update device address as undefined by requester */
if ((u64)dma & HIGH_BITS_MASK)
dev_warn(dev, "DMA address cast in 32bit to fit
resource table format\n");
--
2.7.4
[PATCH v2 2/7] remoteproc: fix rproc_da_to_va in case of unallocated carveout
With introduction of rproc_alloc_registered_carveouts() which
delays carveout allocation just before the start of the remote
processor, rproc_da_to_va() could be called before all carveouts
are allocated.
This patch adds a check in rproc_da_to_va() to return NULL if
carveout is not allocated.
Fixes: d7c51706d095 ("remoteproc: add alloc ops in rproc_mem_entry struct")
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index c1a66e25b173..28df71cb3fef 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -204,6 +204,10 @@ void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
list_for_each_entry(carveout, >carveouts, node) {
int offset = da - carveout->da;
+ /* Verify that carveout is allocated */
+ if (!carveout->va)
+ continue;
+
/* try next carveout if da is too small */
if (offset < 0)
continue;
--
2.7.4
[PATCH v2 1/7] remoteproc: correct rproc_mem_entry_init() comments
Add alloc parameter description and correct comment about release one. Signed-off-by: Loic Pallardy --- drivers/remoteproc/remoteproc_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index 54ec38fc5dca..c1a66e25b173 100644 --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -900,7 +900,8 @@ EXPORT_SYMBOL(rproc_add_carveout); * @dma: dma address * @len: memory carveout length * @da: device address - * @release: memory carveout function + * @alloc: memory carveout allocation function + * @release: memory carveout release function * @name: carveout name * * This function allocates a rproc_mem_entry struct and fill it with parameters -- 2.7.4
[PATCH v2 0/7] remoteproc: Fixes for memoy carveout management
These patches fix the comments sent on remoteproc mailing list after acceptation of memory carveout patch series [1]. In few words, series corrects: - memory carveout allocation for rproc without iommu - rproc_da_to_va and trace buffer access to take into account late carveout allocation - resource table cast by adding warning messages Regards, Loic [1] https://lkml.org/lkml/2018/7/27/612 --- Changes from v1: - Modify way to notify resource table cast issue - Complete trace buffer patch Loic Pallardy (7): remoteproc: correct rproc_mem_entry_init() comments remoteproc: fix rproc_da_to_va in case of unallocated carveout remoteproc: fix rproc_alloc_carveout() bad variable cast remoteproc: add warning on resource table cast remoteproc: fix rproc_alloc_carveout() for rproc with iommu domain remoteproc: fix trace buffer va initialization remoteproc: fix rproc_check_carveout_da() returned error and comments drivers/remoteproc/remoteproc_core.c | 108 ++- drivers/remoteproc/remoteproc_debugfs.c | 21 -- drivers/remoteproc/remoteproc_internal.h | 9 ++- 3 files changed, 89 insertions(+), 49 deletions(-) -- 2.7.4
[PATCH 1/1] remoteproc: fix recovery procedure
Commit 7e83cab824a87e83cab824a8 ("remoteproc: Modify recovery path
to use rproc_{start,stop}()") replaces rproc_{shutdown,boot}() with
rproc_{stop,start}(), which skips destroy the virtio device at stop
but re-initializes it again at start.
Issue is that struct virtio_dev is not correctly reinitialized like done
at initial allocation thanks to kzalloc() and kobject is considered as
already initialized by kernel. That is due to the fact struct virtio_dev
is allocated and released at vdev resource handling level managed and
virtio device is registered and unregistered at rproc subdevices level.
This patch initializes struct virtio_dev to 0 before using it and
registering it.
Fixes: 7e83cab824a8 ("remoteproc: Modify recovery path to use
rproc_{start,stop}()")
Reported-by: Xiang Xiao
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_virtio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_virtio.c
b/drivers/remoteproc/remoteproc_virtio.c
index 183fc42a510a..88eade99395c 100644
--- a/drivers/remoteproc/remoteproc_virtio.c
+++ b/drivers/remoteproc/remoteproc_virtio.c
@@ -332,6 +332,8 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
struct virtio_device *vdev = >vdev;
int ret;
+ /* Reset vdev struct as you don't know how it has been previously used
*/
+ memset(vdev, 0, sizeof(struct virtio_device));
vdev->id.device = id,
vdev->config = _virtio_config_ops,
vdev->dev.parent = dev;
--
2.7.4
RE: [PATCH 6/7] remoteproc: fix trace buffer va initialization
> -Original Message-
> From: Loic PALLARDY
> Sent: jeudi 29 novembre 2018 22:29
> To: bjorn.anders...@linaro.org; o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org; s-a...@ti.com; Loic PALLARDY
>
> Subject: [PATCH 6/7] remoteproc: fix trace buffer va initialization
>
> With rproc_alloc_registered_carveouts() introduction, carveouts are
> allocated after resource table parsing.
> rproc_da_to_va() may return NULL at trace resource registering.
> This patch modifies trace debufs registering to provide device address
> (da) instead of va.
> da to va translation is done at each trace buffer access
> through debugfs interface.
>
> Fixes: d7c51706d095 ("remoteproc: add alloc ops in rproc_mem_entry
> struct")
>
> Signed-off-by: Loic Pallardy
> ---
> drivers/remoteproc/remoteproc_core.c | 26 ++
> drivers/remoteproc/remoteproc_debugfs.c | 21 +
> drivers/remoteproc/remoteproc_internal.h | 9 -
> 3 files changed, 35 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index f19bc6961e40..9dbcc16f8782 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -562,9 +562,8 @@ void rproc_vdev_release(struct kref *ref)
> static int rproc_handle_trace(struct rproc *rproc, struct fw_rsc_trace *rsc,
> int offset, int avail)
> {
> - struct rproc_mem_entry *trace;
> + struct rproc_debug_trace *trace;
> struct device *dev = >dev;
> - void *ptr;
> char name[15];
>
> if (sizeof(*rsc) > avail) {
> @@ -578,28 +577,23 @@ static int rproc_handle_trace(struct rproc *rproc,
> struct fw_rsc_trace *rsc,
> return -EINVAL;
> }
>
> - /* what's the kernel address of this resource ? */
> - ptr = rproc_da_to_va(rproc, rsc->da, rsc->len);
> - if (!ptr) {
> - dev_err(dev, "erroneous trace resource entry\n");
> - return -EINVAL;
> - }
> -
> trace = kzalloc(sizeof(*trace), GFP_KERNEL);
> if (!trace)
> return -ENOMEM;
>
> /* set the trace buffer dma properties */
> - trace->len = rsc->len;
> - trace->va = ptr;
> + trace->trace_mem.len = rsc->len;
> + trace->trace_mem.da = rsc->da;
> +
> + /* set pointer on rproc device */
> + trace->rproc = rproc;
>
> /* make sure snprintf always null terminates, even if truncating */
> snprintf(name, sizeof(name), "trace%d", rproc->num_traces);
>
> /* create the debugfs entry */
> - trace->priv = rproc_create_trace_file(name, rproc, trace);
> - if (!trace->priv) {
> - trace->va = NULL;
> + trace->tfile = rproc_create_trace_file(name, rproc, trace);
> + if (!trace->tfile) {
> kfree(trace);
> return -EINVAL;
> }
> @@ -608,8 +602,8 @@ static int rproc_handle_trace(struct rproc *rproc,
> struct fw_rsc_trace *rsc,
>
> rproc->num_traces++;
>
> - dev_dbg(dev, "%s added: va %pK, da 0x%x, len 0x%x\n",
> - name, ptr, rsc->da, rsc->len);
> + dev_dbg(dev, "%s added: da 0x%x, len 0x%x\n",
> + name, rsc->da, rsc->len);
>
> return 0;
> }
rproc_resource_cleanup() modification not included in this patch. (lost during
rebase)
I'll post a v2.
Regards,
Loic
> diff --git a/drivers/remoteproc/remoteproc_debugfs.c
> b/drivers/remoteproc/remoteproc_debugfs.c
> index e90135c64af0..11240b4d0a91 100644
> --- a/drivers/remoteproc/remoteproc_debugfs.c
> +++ b/drivers/remoteproc/remoteproc_debugfs.c
> @@ -47,10 +47,23 @@ static struct dentry *rproc_dbg;
> static ssize_t rproc_trace_read(struct file *filp, char __user *userbuf,
> size_t count, loff_t *ppos)
> {
> - struct rproc_mem_entry *trace = filp->private_data;
> - int len = strnlen(trace->va, trace->len);
> + struct rproc_debug_trace *data = filp->private_data;
> + struct rproc_mem_entry *trace = >trace_mem;
> + void *va;
> + char buf[100];
> + int len;
> +
> + va = rproc_da_to_va(data->rproc, trace->da, trace->len);
> +
> + if (!va) {
> + len = scnprintf(buf, sizeof(buf), "Trace %s not available\n",
> + trace->name);
> + va = buf;
> + } else {
>
RE: [PATCH 6/7] remoteproc: fix trace buffer va initialization
> -Original Message-
> From: Loic PALLARDY
> Sent: jeudi 29 novembre 2018 22:29
> To: bjorn.anders...@linaro.org; o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org; s-a...@ti.com; Loic PALLARDY
>
> Subject: [PATCH 6/7] remoteproc: fix trace buffer va initialization
>
> With rproc_alloc_registered_carveouts() introduction, carveouts are
> allocated after resource table parsing.
> rproc_da_to_va() may return NULL at trace resource registering.
> This patch modifies trace debufs registering to provide device address
> (da) instead of va.
> da to va translation is done at each trace buffer access
> through debugfs interface.
>
> Fixes: d7c51706d095 ("remoteproc: add alloc ops in rproc_mem_entry
> struct")
>
> Signed-off-by: Loic Pallardy
> ---
> drivers/remoteproc/remoteproc_core.c | 26 ++
> drivers/remoteproc/remoteproc_debugfs.c | 21 +
> drivers/remoteproc/remoteproc_internal.h | 9 -
> 3 files changed, 35 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index f19bc6961e40..9dbcc16f8782 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -562,9 +562,8 @@ void rproc_vdev_release(struct kref *ref)
> static int rproc_handle_trace(struct rproc *rproc, struct fw_rsc_trace *rsc,
> int offset, int avail)
> {
> - struct rproc_mem_entry *trace;
> + struct rproc_debug_trace *trace;
> struct device *dev = >dev;
> - void *ptr;
> char name[15];
>
> if (sizeof(*rsc) > avail) {
> @@ -578,28 +577,23 @@ static int rproc_handle_trace(struct rproc *rproc,
> struct fw_rsc_trace *rsc,
> return -EINVAL;
> }
>
> - /* what's the kernel address of this resource ? */
> - ptr = rproc_da_to_va(rproc, rsc->da, rsc->len);
> - if (!ptr) {
> - dev_err(dev, "erroneous trace resource entry\n");
> - return -EINVAL;
> - }
> -
> trace = kzalloc(sizeof(*trace), GFP_KERNEL);
> if (!trace)
> return -ENOMEM;
>
> /* set the trace buffer dma properties */
> - trace->len = rsc->len;
> - trace->va = ptr;
> + trace->trace_mem.len = rsc->len;
> + trace->trace_mem.da = rsc->da;
> +
> + /* set pointer on rproc device */
> + trace->rproc = rproc;
>
> /* make sure snprintf always null terminates, even if truncating */
> snprintf(name, sizeof(name), "trace%d", rproc->num_traces);
>
> /* create the debugfs entry */
> - trace->priv = rproc_create_trace_file(name, rproc, trace);
> - if (!trace->priv) {
> - trace->va = NULL;
> + trace->tfile = rproc_create_trace_file(name, rproc, trace);
> + if (!trace->tfile) {
> kfree(trace);
> return -EINVAL;
> }
> @@ -608,8 +602,8 @@ static int rproc_handle_trace(struct rproc *rproc,
> struct fw_rsc_trace *rsc,
>
> rproc->num_traces++;
>
> - dev_dbg(dev, "%s added: va %pK, da 0x%x, len 0x%x\n",
> - name, ptr, rsc->da, rsc->len);
> + dev_dbg(dev, "%s added: da 0x%x, len 0x%x\n",
> + name, rsc->da, rsc->len);
>
> return 0;
> }
rproc_resource_cleanup() modification not included in this patch. (lost during
rebase)
I'll post a v2.
Regards,
Loic
> diff --git a/drivers/remoteproc/remoteproc_debugfs.c
> b/drivers/remoteproc/remoteproc_debugfs.c
> index e90135c64af0..11240b4d0a91 100644
> --- a/drivers/remoteproc/remoteproc_debugfs.c
> +++ b/drivers/remoteproc/remoteproc_debugfs.c
> @@ -47,10 +47,23 @@ static struct dentry *rproc_dbg;
> static ssize_t rproc_trace_read(struct file *filp, char __user *userbuf,
> size_t count, loff_t *ppos)
> {
> - struct rproc_mem_entry *trace = filp->private_data;
> - int len = strnlen(trace->va, trace->len);
> + struct rproc_debug_trace *data = filp->private_data;
> + struct rproc_mem_entry *trace = >trace_mem;
> + void *va;
> + char buf[100];
> + int len;
> +
> + va = rproc_da_to_va(data->rproc, trace->da, trace->len);
> +
> + if (!va) {
> + len = scnprintf(buf, sizeof(buf), "Trace %s not available\n",
> + trace->name);
> + va = buf;
> + } else {
>
RE: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on centralized carveout allocator
> -Original Message- > From: Wendy Liang > Sent: mardi 4 décembre 2018 19:58 > To: Loic PALLARDY > Cc: Suman Anna ; Bjorn Andersson > ; Ohad Ben-Cohen ; > linux-remotep...@vger.kernel.org; Linux Kernel Mailing List ker...@vger.kernel.org>; Arnaud POULIQUEN ; > Benjamin Gaignard > Subject: Re: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on > centralized carveout allocator > > On Tue, Dec 4, 2018 at 10:04 AM Loic PALLARDY > wrote: > > > > > > > > > -Original Message- > > > From: Wendy Liang > > > Sent: mardi 4 décembre 2018 18:57 > > > To: Suman Anna > > > Cc: Loic PALLARDY ; Bjorn Andersson > > > ; Ohad Ben-Cohen ; > > > linux-remotep...@vger.kernel.org; Linux Kernel Mailing List > > ker...@vger.kernel.org>; Arnaud POULIQUEN > ; > > > Benjamin Gaignard > > > Subject: Re: [PATCH v4 12/17] remoteproc: modify vring allocation to rely > on > > > centralized carveout allocator > > > > > > On Mon, Oct 29, 2018 at 1:19 PM Suman Anna wrote: > > > > > > > > Hi Loic, > > > > > > > > On 10/24/18 10:14 AM, Loic PALLARDY wrote: > > > > > Hi Suman, > > > > > > > > > >> -Original Message- > > > > >> From: Suman Anna > > > > >> Sent: mercredi 24 octobre 2018 02:14 > > > > >> To: Loic PALLARDY ; > bjorn.anders...@linaro.org; > > > > >> o...@wizery.com > > > > >> Cc: linux-remotep...@vger.kernel.org; linux- > ker...@vger.kernel.org; > > > > >> Arnaud POULIQUEN ; > > > > >> benjamin.gaign...@linaro.org > > > > >> Subject: Re: [PATCH v4 12/17] remoteproc: modify vring allocation to > > > rely on > > > > >> centralized carveout allocator > > > > >> > > > > >> On 7/27/18 8:14 AM, Loic Pallardy wrote: > > > > >>> Current version of rproc_alloc_vring function supports only > dynamic > > > vring > > > > >>> allocation. > > > > >>> > > > > >>> This patch allows to allocate vrings based on memory region > > > declatation. > > > > >>> Vrings are now manage like memory carveouts, to communize > > > memory > > > > >> management > > > > >>> code in rproc_alloc_registered_carveouts(). > > > > >>> > > > > >>> Allocated buffer is retrieved in rp_find_vq() thanks to > > > > >>> rproc_find_carveout_by_name() functions for. > > > > >>> > > > > >>> This patch sets vrings names to vdev"x"vring"y" with x vdev index > in > > > > >>> resource table and y vring index in vdev. This will be updated when > > > > >>> name will be associated to vdev in firmware resource table. > > > > >>> > > > > >>> Signed-off-by: Loic Pallardy > > > > >>> --- > > > > >>> drivers/remoteproc/remoteproc_core.c | 61 > +- > > > - > > > > >> - > > > > >>> drivers/remoteproc/remoteproc_internal.h | 2 ++ > > > > >>> drivers/remoteproc/remoteproc_virtio.c | 14 +++- > > > > >>> include/linux/remoteproc.h | 6 ++-- > > > > >>> 4 files changed, 51 insertions(+), 32 deletions(-) > > > > >>> > > > > >>> diff --git a/drivers/remoteproc/remoteproc_core.c > > > > >> b/drivers/remoteproc/remoteproc_core.c > > > > >>> index c543d04..4edc6f0 100644 > > > > >>> --- a/drivers/remoteproc/remoteproc_core.c > > > > >>> +++ b/drivers/remoteproc/remoteproc_core.c > > > > >>> @@ -53,6 +53,11 @@ typedef int > (*rproc_handle_resources_t)(struct > > > > >> rproc *rproc, > > > > >>> typedef int (*rproc_handle_resource_t)(struct rproc *rproc, > > > > >>> void *, int offset, int avail); > > > > >>> > > > > >>> +static int rproc_alloc_carveout(struct rproc *rproc, > > > > >>> + struct rproc_mem_entry *mem); > > > > >>> +static int rproc_release_carveout(struct rproc *rproc, > > > > >>> +
RE: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on centralized carveout allocator
> -Original Message- > From: Wendy Liang > Sent: mardi 4 décembre 2018 19:58 > To: Loic PALLARDY > Cc: Suman Anna ; Bjorn Andersson > ; Ohad Ben-Cohen ; > linux-remotep...@vger.kernel.org; Linux Kernel Mailing List ker...@vger.kernel.org>; Arnaud POULIQUEN ; > Benjamin Gaignard > Subject: Re: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on > centralized carveout allocator > > On Tue, Dec 4, 2018 at 10:04 AM Loic PALLARDY > wrote: > > > > > > > > > -Original Message- > > > From: Wendy Liang > > > Sent: mardi 4 décembre 2018 18:57 > > > To: Suman Anna > > > Cc: Loic PALLARDY ; Bjorn Andersson > > > ; Ohad Ben-Cohen ; > > > linux-remotep...@vger.kernel.org; Linux Kernel Mailing List > > ker...@vger.kernel.org>; Arnaud POULIQUEN > ; > > > Benjamin Gaignard > > > Subject: Re: [PATCH v4 12/17] remoteproc: modify vring allocation to rely > on > > > centralized carveout allocator > > > > > > On Mon, Oct 29, 2018 at 1:19 PM Suman Anna wrote: > > > > > > > > Hi Loic, > > > > > > > > On 10/24/18 10:14 AM, Loic PALLARDY wrote: > > > > > Hi Suman, > > > > > > > > > >> -Original Message- > > > > >> From: Suman Anna > > > > >> Sent: mercredi 24 octobre 2018 02:14 > > > > >> To: Loic PALLARDY ; > bjorn.anders...@linaro.org; > > > > >> o...@wizery.com > > > > >> Cc: linux-remotep...@vger.kernel.org; linux- > ker...@vger.kernel.org; > > > > >> Arnaud POULIQUEN ; > > > > >> benjamin.gaign...@linaro.org > > > > >> Subject: Re: [PATCH v4 12/17] remoteproc: modify vring allocation to > > > rely on > > > > >> centralized carveout allocator > > > > >> > > > > >> On 7/27/18 8:14 AM, Loic Pallardy wrote: > > > > >>> Current version of rproc_alloc_vring function supports only > dynamic > > > vring > > > > >>> allocation. > > > > >>> > > > > >>> This patch allows to allocate vrings based on memory region > > > declatation. > > > > >>> Vrings are now manage like memory carveouts, to communize > > > memory > > > > >> management > > > > >>> code in rproc_alloc_registered_carveouts(). > > > > >>> > > > > >>> Allocated buffer is retrieved in rp_find_vq() thanks to > > > > >>> rproc_find_carveout_by_name() functions for. > > > > >>> > > > > >>> This patch sets vrings names to vdev"x"vring"y" with x vdev index > in > > > > >>> resource table and y vring index in vdev. This will be updated when > > > > >>> name will be associated to vdev in firmware resource table. > > > > >>> > > > > >>> Signed-off-by: Loic Pallardy > > > > >>> --- > > > > >>> drivers/remoteproc/remoteproc_core.c | 61 > +- > > > - > > > > >> - > > > > >>> drivers/remoteproc/remoteproc_internal.h | 2 ++ > > > > >>> drivers/remoteproc/remoteproc_virtio.c | 14 +++- > > > > >>> include/linux/remoteproc.h | 6 ++-- > > > > >>> 4 files changed, 51 insertions(+), 32 deletions(-) > > > > >>> > > > > >>> diff --git a/drivers/remoteproc/remoteproc_core.c > > > > >> b/drivers/remoteproc/remoteproc_core.c > > > > >>> index c543d04..4edc6f0 100644 > > > > >>> --- a/drivers/remoteproc/remoteproc_core.c > > > > >>> +++ b/drivers/remoteproc/remoteproc_core.c > > > > >>> @@ -53,6 +53,11 @@ typedef int > (*rproc_handle_resources_t)(struct > > > > >> rproc *rproc, > > > > >>> typedef int (*rproc_handle_resource_t)(struct rproc *rproc, > > > > >>> void *, int offset, int avail); > > > > >>> > > > > >>> +static int rproc_alloc_carveout(struct rproc *rproc, > > > > >>> + struct rproc_mem_entry *mem); > > > > >>> +static int rproc_release_carveout(struct rproc *rproc, > > > > >>> +
RE: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on centralized carveout allocator
> -Original Message-
> From: Wendy Liang
> Sent: mardi 4 décembre 2018 18:57
> To: Suman Anna
> Cc: Loic PALLARDY ; Bjorn Andersson
> ; Ohad Ben-Cohen ;
> linux-remotep...@vger.kernel.org; Linux Kernel Mailing List ker...@vger.kernel.org>; Arnaud POULIQUEN ;
> Benjamin Gaignard
> Subject: Re: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on
> centralized carveout allocator
>
> On Mon, Oct 29, 2018 at 1:19 PM Suman Anna wrote:
> >
> > Hi Loic,
> >
> > On 10/24/18 10:14 AM, Loic PALLARDY wrote:
> > > Hi Suman,
> > >
> > >> -Original Message-
> > >> From: Suman Anna
> > >> Sent: mercredi 24 octobre 2018 02:14
> > >> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> > >> o...@wizery.com
> > >> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > >> Arnaud POULIQUEN ;
> > >> benjamin.gaign...@linaro.org
> > >> Subject: Re: [PATCH v4 12/17] remoteproc: modify vring allocation to
> rely on
> > >> centralized carveout allocator
> > >>
> > >> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > >>> Current version of rproc_alloc_vring function supports only dynamic
> vring
> > >>> allocation.
> > >>>
> > >>> This patch allows to allocate vrings based on memory region
> declatation.
> > >>> Vrings are now manage like memory carveouts, to communize
> memory
> > >> management
> > >>> code in rproc_alloc_registered_carveouts().
> > >>>
> > >>> Allocated buffer is retrieved in rp_find_vq() thanks to
> > >>> rproc_find_carveout_by_name() functions for.
> > >>>
> > >>> This patch sets vrings names to vdev"x"vring"y" with x vdev index in
> > >>> resource table and y vring index in vdev. This will be updated when
> > >>> name will be associated to vdev in firmware resource table.
> > >>>
> > >>> Signed-off-by: Loic Pallardy
> > >>> ---
> > >>> drivers/remoteproc/remoteproc_core.c | 61 +-
> -
> > >> -
> > >>> drivers/remoteproc/remoteproc_internal.h | 2 ++
> > >>> drivers/remoteproc/remoteproc_virtio.c | 14 +++-
> > >>> include/linux/remoteproc.h | 6 ++--
> > >>> 4 files changed, 51 insertions(+), 32 deletions(-)
> > >>>
> > >>> diff --git a/drivers/remoteproc/remoteproc_core.c
> > >> b/drivers/remoteproc/remoteproc_core.c
> > >>> index c543d04..4edc6f0 100644
> > >>> --- a/drivers/remoteproc/remoteproc_core.c
> > >>> +++ b/drivers/remoteproc/remoteproc_core.c
> > >>> @@ -53,6 +53,11 @@ typedef int (*rproc_handle_resources_t)(struct
> > >> rproc *rproc,
> > >>> typedef int (*rproc_handle_resource_t)(struct rproc *rproc,
> > >>> void *, int offset, int avail);
> > >>>
> > >>> +static int rproc_alloc_carveout(struct rproc *rproc,
> > >>> + struct rproc_mem_entry *mem);
> > >>> +static int rproc_release_carveout(struct rproc *rproc,
> > >>> + struct rproc_mem_entry *mem);
> > >>> +
> > >>> /* Unique indices for remoteproc devices */
> > >>> static DEFINE_IDA(rproc_dev_index);
> > >>>
> > >>> @@ -312,21 +317,33 @@ int rproc_alloc_vring(struct rproc_vdev
> *rvdev,
> > >> int i)
> > >>> struct device *dev = >dev;
> > >>> struct rproc_vring *rvring = >vring[i];
> > >>> struct fw_rsc_vdev *rsc;
> > >>> - dma_addr_t dma;
> > >>> - void *va;
> > >>> int ret, size, notifyid;
> > >>> + struct rproc_mem_entry *mem;
> > >>>
> > >>> /* actual size of vring (in bytes) */
> > >>> size = PAGE_ALIGN(vring_size(rvring->len, rvring->align));
> > >>>
> > >>> - /*
> > >>> -* Allocate non-cacheable memory for the vring. In the future
> > >>> -* this call will also configure the IOMMU for us
> > >>> -*/
> > >>> - va = dma_alloc_coherent(dev->parent, size, , GFP_KERNEL);
> > >>> - if (!va) {
> > >>> - dev_err
RE: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on centralized carveout allocator
> -Original Message-
> From: Wendy Liang
> Sent: mardi 4 décembre 2018 18:57
> To: Suman Anna
> Cc: Loic PALLARDY ; Bjorn Andersson
> ; Ohad Ben-Cohen ;
> linux-remotep...@vger.kernel.org; Linux Kernel Mailing List ker...@vger.kernel.org>; Arnaud POULIQUEN ;
> Benjamin Gaignard
> Subject: Re: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on
> centralized carveout allocator
>
> On Mon, Oct 29, 2018 at 1:19 PM Suman Anna wrote:
> >
> > Hi Loic,
> >
> > On 10/24/18 10:14 AM, Loic PALLARDY wrote:
> > > Hi Suman,
> > >
> > >> -Original Message-
> > >> From: Suman Anna
> > >> Sent: mercredi 24 octobre 2018 02:14
> > >> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> > >> o...@wizery.com
> > >> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > >> Arnaud POULIQUEN ;
> > >> benjamin.gaign...@linaro.org
> > >> Subject: Re: [PATCH v4 12/17] remoteproc: modify vring allocation to
> rely on
> > >> centralized carveout allocator
> > >>
> > >> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > >>> Current version of rproc_alloc_vring function supports only dynamic
> vring
> > >>> allocation.
> > >>>
> > >>> This patch allows to allocate vrings based on memory region
> declatation.
> > >>> Vrings are now manage like memory carveouts, to communize
> memory
> > >> management
> > >>> code in rproc_alloc_registered_carveouts().
> > >>>
> > >>> Allocated buffer is retrieved in rp_find_vq() thanks to
> > >>> rproc_find_carveout_by_name() functions for.
> > >>>
> > >>> This patch sets vrings names to vdev"x"vring"y" with x vdev index in
> > >>> resource table and y vring index in vdev. This will be updated when
> > >>> name will be associated to vdev in firmware resource table.
> > >>>
> > >>> Signed-off-by: Loic Pallardy
> > >>> ---
> > >>> drivers/remoteproc/remoteproc_core.c | 61 +-
> -
> > >> -
> > >>> drivers/remoteproc/remoteproc_internal.h | 2 ++
> > >>> drivers/remoteproc/remoteproc_virtio.c | 14 +++-
> > >>> include/linux/remoteproc.h | 6 ++--
> > >>> 4 files changed, 51 insertions(+), 32 deletions(-)
> > >>>
> > >>> diff --git a/drivers/remoteproc/remoteproc_core.c
> > >> b/drivers/remoteproc/remoteproc_core.c
> > >>> index c543d04..4edc6f0 100644
> > >>> --- a/drivers/remoteproc/remoteproc_core.c
> > >>> +++ b/drivers/remoteproc/remoteproc_core.c
> > >>> @@ -53,6 +53,11 @@ typedef int (*rproc_handle_resources_t)(struct
> > >> rproc *rproc,
> > >>> typedef int (*rproc_handle_resource_t)(struct rproc *rproc,
> > >>> void *, int offset, int avail);
> > >>>
> > >>> +static int rproc_alloc_carveout(struct rproc *rproc,
> > >>> + struct rproc_mem_entry *mem);
> > >>> +static int rproc_release_carveout(struct rproc *rproc,
> > >>> + struct rproc_mem_entry *mem);
> > >>> +
> > >>> /* Unique indices for remoteproc devices */
> > >>> static DEFINE_IDA(rproc_dev_index);
> > >>>
> > >>> @@ -312,21 +317,33 @@ int rproc_alloc_vring(struct rproc_vdev
> *rvdev,
> > >> int i)
> > >>> struct device *dev = >dev;
> > >>> struct rproc_vring *rvring = >vring[i];
> > >>> struct fw_rsc_vdev *rsc;
> > >>> - dma_addr_t dma;
> > >>> - void *va;
> > >>> int ret, size, notifyid;
> > >>> + struct rproc_mem_entry *mem;
> > >>>
> > >>> /* actual size of vring (in bytes) */
> > >>> size = PAGE_ALIGN(vring_size(rvring->len, rvring->align));
> > >>>
> > >>> - /*
> > >>> -* Allocate non-cacheable memory for the vring. In the future
> > >>> -* this call will also configure the IOMMU for us
> > >>> -*/
> > >>> - va = dma_alloc_coherent(dev->parent, size, , GFP_KERNEL);
> > >>> - if (!va) {
> > >>> - dev_err
RE: [PATCH 4/7] remoteproc: add warning on resource table cast
> -Original Message-
> From: Arnd Bergmann
> Sent: vendredi 30 novembre 2018 15:33
> To: Loic PALLARDY
> Cc: Bjorn Andersson ; Ohad Ben-Cohen
> ; linux-remotep...@vger.kernel.org; Linux Kernel
> Mailing List ; Arnaud POULIQUEN
> ; Benjamin Gaignard
> ; Suman Anna
> Subject: Re: [PATCH 4/7] remoteproc: add warning on resource table cast
>
> On Thu, Nov 29, 2018 at 10:31 PM Loic Pallardy wrote:
> >
> > Today resource table supports only 32bit address fields.
> > This is not compliant with 64bit platform for which addresses
> > are cast in 32bit.
> > This patch adds warn messages when address cast is done.
> >
> > Signed-off-by: Loic Pallardy
> > ---
> > drivers/remoteproc/remoteproc_core.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> > index 18a1bbf820c9..61c954bd695e 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -772,6 +772,10 @@ static int rproc_alloc_carveout(struct rproc *rproc,
> > dev_dbg(dev, "carveout mapped 0x%x to %pad\n",
> > mem->da, );
> > } else {
> > + /* Update device address as undefined by requester */
> > + if (sizeof(dma_addr_t) > sizeof(u32))
> > + dev_warn(dev, "DMA address cast in 32bit to fit
> > resource table
> format\n");
> > +
> > mem->da = (u32)dma;
> > }
>
> I think this patch is wrong: sizeof(dma_addr_t) is defined to be large enough
> to support any machine that the kernel can run on. If you build a kernel that
> happens to work on an ARM32 platform with LPAE enabled, then this will
> warn every time, even if you are running on a machine that only has a 32-bit
> address space.
I suppose if LPAE is enabled, address space is larger than 32bit.
But I agree it is possible to display a warn only when some information will be
lost
due to cast.
I'll propose a new version testing dma address itself and displaying warn only
if above 4GB.
Regards,
Loic
>
> Arnd
RE: [PATCH 4/7] remoteproc: add warning on resource table cast
> -Original Message-
> From: Arnd Bergmann
> Sent: vendredi 30 novembre 2018 15:33
> To: Loic PALLARDY
> Cc: Bjorn Andersson ; Ohad Ben-Cohen
> ; linux-remotep...@vger.kernel.org; Linux Kernel
> Mailing List ; Arnaud POULIQUEN
> ; Benjamin Gaignard
> ; Suman Anna
> Subject: Re: [PATCH 4/7] remoteproc: add warning on resource table cast
>
> On Thu, Nov 29, 2018 at 10:31 PM Loic Pallardy wrote:
> >
> > Today resource table supports only 32bit address fields.
> > This is not compliant with 64bit platform for which addresses
> > are cast in 32bit.
> > This patch adds warn messages when address cast is done.
> >
> > Signed-off-by: Loic Pallardy
> > ---
> > drivers/remoteproc/remoteproc_core.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> > index 18a1bbf820c9..61c954bd695e 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -772,6 +772,10 @@ static int rproc_alloc_carveout(struct rproc *rproc,
> > dev_dbg(dev, "carveout mapped 0x%x to %pad\n",
> > mem->da, );
> > } else {
> > + /* Update device address as undefined by requester */
> > + if (sizeof(dma_addr_t) > sizeof(u32))
> > + dev_warn(dev, "DMA address cast in 32bit to fit
> > resource table
> format\n");
> > +
> > mem->da = (u32)dma;
> > }
>
> I think this patch is wrong: sizeof(dma_addr_t) is defined to be large enough
> to support any machine that the kernel can run on. If you build a kernel that
> happens to work on an ARM32 platform with LPAE enabled, then this will
> warn every time, even if you are running on a machine that only has a 32-bit
> address space.
I suppose if LPAE is enabled, address space is larger than 32bit.
But I agree it is possible to display a warn only when some information will be
lost
due to cast.
I'll propose a new version testing dma address itself and displaying warn only
if above 4GB.
Regards,
Loic
>
> Arnd
[PATCH 2/3] remoteproc: st: add reserved memory support
ST remote processor needs some specified memory regions for
firmware and IPC.
Memory regions are defined as reserved memory and should
be registered in remoteproc core thanks to rproc_add_carveout
function before rproc_start. For this, st rproc driver implements
prepare ops.
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/st_remoteproc.c | 91 +-
1 file changed, 80 insertions(+), 11 deletions(-)
diff --git a/drivers/remoteproc/st_remoteproc.c
b/drivers/remoteproc/st_remoteproc.c
index aacef0ea3b90..51049d17b1e5 100644
--- a/drivers/remoteproc/st_remoteproc.c
+++ b/drivers/remoteproc/st_remoteproc.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -91,6 +92,77 @@ static void st_rproc_kick(struct rproc *rproc, int vqid)
dev_err(dev, "failed to send message via mbox: %d\n", ret);
}
+static int st_rproc_mem_alloc(struct rproc *rproc,
+ struct rproc_mem_entry *mem)
+{
+ struct device *dev = rproc->dev.parent;
+ void *va;
+
+ va = ioremap_wc(mem->dma, mem->len);
+ if (!va) {
+ dev_err(dev, "Unable to map memory region: %pa+%zx\n",
+ >dma, mem->len);
+ return -ENOMEM;
+ }
+
+ /* Update memory entry va */
+ mem->va = va;
+
+ return 0;
+}
+
+static int st_rproc_mem_release(struct rproc *rproc,
+ struct rproc_mem_entry *mem)
+{
+ iounmap(mem->va);
+
+ return 0;
+}
+
+static int st_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
+{
+ struct device *dev = rproc->dev.parent;
+ struct device_node *np = dev->of_node;
+ struct rproc_mem_entry *mem;
+ struct reserved_mem *rmem;
+ struct of_phandle_iterator it;
+ int index = 0;
+
+ of_phandle_iterator_init(, np, "memory-region", NULL, 0);
+ while (of_phandle_iterator_next() == 0) {
+ rmem = of_reserved_mem_lookup(it.node);
+ if (!rmem) {
+ dev_err(dev, "unable to acquire memory-region\n");
+ return -EINVAL;
+ }
+
+ /* No need to map vdev buffer */
+ if (strcmp(it.node->name, "vdev0buffer")) {
+ /* Register memory region */
+ mem = rproc_mem_entry_init(dev, NULL,
+ (dma_addr_t)rmem->base,
+ rmem->size, rmem->base,
+ st_rproc_mem_alloc,
+ st_rproc_mem_release,
+ it.node->name);
+ } else {
+ /* Register reserved memory for vdev buffer allocation
*/
+ mem = rproc_of_resm_mem_entry_init(dev, index,
+ rmem->size,
+ rmem->base,
+ it.node->name);
+ }
+
+ if (!mem)
+ return -ENOMEM;
+
+ rproc_add_carveout(rproc, mem);
+ index++;
+ }
+
+ return rproc_elf_load_rsc_table(rproc, fw);
+}
+
static int st_rproc_start(struct rproc *rproc)
{
struct st_rproc *ddata = rproc->priv;
@@ -158,9 +230,14 @@ static int st_rproc_stop(struct rproc *rproc)
}
static const struct rproc_ops st_rproc_ops = {
- .kick = st_rproc_kick,
- .start = st_rproc_start,
- .stop = st_rproc_stop,
+ .kick = st_rproc_kick,
+ .start = st_rproc_start,
+ .stop = st_rproc_stop,
+ .parse_fw = st_rproc_parse_fw,
+ .load = rproc_elf_load_segments,
+ .find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
+ .sanity_check = rproc_elf_sanity_check,
+ .get_boot_addr = rproc_elf_get_boot_addr,
};
/*
@@ -254,12 +331,6 @@ static int st_rproc_parse_dt(struct platform_device *pdev)
return -EINVAL;
}
- err = of_reserved_mem_device_init(dev);
- if (err) {
- dev_err(dev, "Failed to obtain shared memory\n");
- return err;
- }
-
err = clk_prepare(ddata->clk);
if (err)
dev_err(dev, "failed to get clock\n");
@@ -387,8 +458,6 @@ static int st_rproc_remove(struct platform_device *pdev)
clk_disable_unprepare(ddata->clk);
- of_reserved_mem_device_release(>dev);
-
for (i = 0; i < ST_RPROC_MAX_VRING * MBOX_MAX; i++)
mbox_free_channel(ddata->mbox_chan[i]);
--
2.7.4
[PATCH 3/3] rpmsg: virtio: allocate buffer from parent
Remoteproc is now capable to create one specific sub-device per
virtio link to associate a dedicated memory pool.
This implies to change device used by virtio_rpmsg for
buffer allocation from grand-parent to parent.
Signed-off-by: Loic Pallardy
Reviewed-by: Anup Patel
Tested-by: Anup Patel
---
drivers/rpmsg/virtio_rpmsg_bus.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 664f957012cd..5c892019ce89 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -912,7 +912,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
total_buf_space = vrp->num_bufs * vrp->buf_size;
/* allocate coherent memory for the buffers */
- bufs_va = dma_alloc_coherent(vdev->dev.parent->parent,
+ bufs_va = dma_alloc_coherent(vdev->dev.parent,
total_buf_space, >bufs_dma,
GFP_KERNEL);
if (!bufs_va) {
@@ -980,7 +980,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
return 0;
free_coherent:
- dma_free_coherent(vdev->dev.parent->parent, total_buf_space,
+ dma_free_coherent(vdev->dev.parent, total_buf_space,
bufs_va, vrp->bufs_dma);
vqs_del:
vdev->config->del_vqs(vrp->vdev);
@@ -1015,7 +1015,7 @@ static void rpmsg_remove(struct virtio_device *vdev)
vdev->config->del_vqs(vrp->vdev);
- dma_free_coherent(vdev->dev.parent->parent, total_buf_space,
+ dma_free_coherent(vdev->dev.parent, total_buf_space,
vrp->rbufs, vrp->bufs_dma);
kfree(vrp);
--
2.7.4
[PATCH 2/3] remoteproc: st: add reserved memory support
ST remote processor needs some specified memory regions for
firmware and IPC.
Memory regions are defined as reserved memory and should
be registered in remoteproc core thanks to rproc_add_carveout
function before rproc_start. For this, st rproc driver implements
prepare ops.
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/st_remoteproc.c | 91 +-
1 file changed, 80 insertions(+), 11 deletions(-)
diff --git a/drivers/remoteproc/st_remoteproc.c
b/drivers/remoteproc/st_remoteproc.c
index aacef0ea3b90..51049d17b1e5 100644
--- a/drivers/remoteproc/st_remoteproc.c
+++ b/drivers/remoteproc/st_remoteproc.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -91,6 +92,77 @@ static void st_rproc_kick(struct rproc *rproc, int vqid)
dev_err(dev, "failed to send message via mbox: %d\n", ret);
}
+static int st_rproc_mem_alloc(struct rproc *rproc,
+ struct rproc_mem_entry *mem)
+{
+ struct device *dev = rproc->dev.parent;
+ void *va;
+
+ va = ioremap_wc(mem->dma, mem->len);
+ if (!va) {
+ dev_err(dev, "Unable to map memory region: %pa+%zx\n",
+ >dma, mem->len);
+ return -ENOMEM;
+ }
+
+ /* Update memory entry va */
+ mem->va = va;
+
+ return 0;
+}
+
+static int st_rproc_mem_release(struct rproc *rproc,
+ struct rproc_mem_entry *mem)
+{
+ iounmap(mem->va);
+
+ return 0;
+}
+
+static int st_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
+{
+ struct device *dev = rproc->dev.parent;
+ struct device_node *np = dev->of_node;
+ struct rproc_mem_entry *mem;
+ struct reserved_mem *rmem;
+ struct of_phandle_iterator it;
+ int index = 0;
+
+ of_phandle_iterator_init(, np, "memory-region", NULL, 0);
+ while (of_phandle_iterator_next() == 0) {
+ rmem = of_reserved_mem_lookup(it.node);
+ if (!rmem) {
+ dev_err(dev, "unable to acquire memory-region\n");
+ return -EINVAL;
+ }
+
+ /* No need to map vdev buffer */
+ if (strcmp(it.node->name, "vdev0buffer")) {
+ /* Register memory region */
+ mem = rproc_mem_entry_init(dev, NULL,
+ (dma_addr_t)rmem->base,
+ rmem->size, rmem->base,
+ st_rproc_mem_alloc,
+ st_rproc_mem_release,
+ it.node->name);
+ } else {
+ /* Register reserved memory for vdev buffer allocation
*/
+ mem = rproc_of_resm_mem_entry_init(dev, index,
+ rmem->size,
+ rmem->base,
+ it.node->name);
+ }
+
+ if (!mem)
+ return -ENOMEM;
+
+ rproc_add_carveout(rproc, mem);
+ index++;
+ }
+
+ return rproc_elf_load_rsc_table(rproc, fw);
+}
+
static int st_rproc_start(struct rproc *rproc)
{
struct st_rproc *ddata = rproc->priv;
@@ -158,9 +230,14 @@ static int st_rproc_stop(struct rproc *rproc)
}
static const struct rproc_ops st_rproc_ops = {
- .kick = st_rproc_kick,
- .start = st_rproc_start,
- .stop = st_rproc_stop,
+ .kick = st_rproc_kick,
+ .start = st_rproc_start,
+ .stop = st_rproc_stop,
+ .parse_fw = st_rproc_parse_fw,
+ .load = rproc_elf_load_segments,
+ .find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
+ .sanity_check = rproc_elf_sanity_check,
+ .get_boot_addr = rproc_elf_get_boot_addr,
};
/*
@@ -254,12 +331,6 @@ static int st_rproc_parse_dt(struct platform_device *pdev)
return -EINVAL;
}
- err = of_reserved_mem_device_init(dev);
- if (err) {
- dev_err(dev, "Failed to obtain shared memory\n");
- return err;
- }
-
err = clk_prepare(ddata->clk);
if (err)
dev_err(dev, "failed to get clock\n");
@@ -387,8 +458,6 @@ static int st_rproc_remove(struct platform_device *pdev)
clk_disable_unprepare(ddata->clk);
- of_reserved_mem_device_release(>dev);
-
for (i = 0; i < ST_RPROC_MAX_VRING * MBOX_MAX; i++)
mbox_free_channel(ddata->mbox_chan[i]);
--
2.7.4
[PATCH 3/3] rpmsg: virtio: allocate buffer from parent
Remoteproc is now capable to create one specific sub-device per
virtio link to associate a dedicated memory pool.
This implies to change device used by virtio_rpmsg for
buffer allocation from grand-parent to parent.
Signed-off-by: Loic Pallardy
Reviewed-by: Anup Patel
Tested-by: Anup Patel
---
drivers/rpmsg/virtio_rpmsg_bus.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 664f957012cd..5c892019ce89 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -912,7 +912,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
total_buf_space = vrp->num_bufs * vrp->buf_size;
/* allocate coherent memory for the buffers */
- bufs_va = dma_alloc_coherent(vdev->dev.parent->parent,
+ bufs_va = dma_alloc_coherent(vdev->dev.parent,
total_buf_space, >bufs_dma,
GFP_KERNEL);
if (!bufs_va) {
@@ -980,7 +980,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
return 0;
free_coherent:
- dma_free_coherent(vdev->dev.parent->parent, total_buf_space,
+ dma_free_coherent(vdev->dev.parent, total_buf_space,
bufs_va, vrp->bufs_dma);
vqs_del:
vdev->config->del_vqs(vrp->vdev);
@@ -1015,7 +1015,7 @@ static void rpmsg_remove(struct virtio_device *vdev)
vdev->config->del_vqs(vrp->vdev);
- dma_free_coherent(vdev->dev.parent->parent, total_buf_space,
+ dma_free_coherent(vdev->dev.parent, total_buf_space,
vrp->rbufs, vrp->bufs_dma);
kfree(vrp);
--
2.7.4
[PATCH 1/3] remoteproc: create vdev subdevice with specific dma memory pool
This patch creates a dedicated vdev subdevice for each vdev declared
in firmware resource table and associates carveout named "vdev%dbuffer"
(with %d vdev index in resource table) if any as dma coherent memory pool.
Then vdev subdevice is used as parent for virtio device.
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 46 +---
drivers/remoteproc/remoteproc_internal.h | 1 +
drivers/remoteproc/remoteproc_virtio.c | 42 -
include/linux/remoteproc.h | 1 +
4 files changed, 86 insertions(+), 4 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 54ec38fc5dca..49272da6edd7 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -39,9 +39,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include "remoteproc_internal.h"
@@ -145,7 +147,7 @@ static void rproc_disable_iommu(struct rproc *rproc)
iommu_domain_free(domain);
}
-static phys_addr_t rproc_va_to_pa(void *cpu_addr)
+phys_addr_t rproc_va_to_pa(void *cpu_addr)
{
/*
* Return physical address according to virtual address location
@@ -160,6 +162,7 @@ static phys_addr_t rproc_va_to_pa(void *cpu_addr)
WARN_ON(!virt_addr_valid(cpu_addr));
return virt_to_phys(cpu_addr);
}
+EXPORT_SYMBOL(rproc_va_to_pa);
/**
* rproc_da_to_va() - lookup the kernel virtual address for a remoteproc
address
@@ -423,6 +426,20 @@ static void rproc_vdev_do_stop(struct rproc_subdev
*subdev, bool crashed)
}
/**
+ * rproc_rvdev_release() - release the existence of a rvdev
+ *
+ * @dev: the subdevice's dev
+ */
+static void rproc_rvdev_release(struct device *dev)
+{
+ struct rproc_vdev *rvdev = container_of(dev, struct rproc_vdev, dev);
+
+ of_reserved_mem_device_release(dev);
+
+ kfree(rvdev);
+}
+
+/**
* rproc_handle_vdev() - handle a vdev fw resource
* @rproc: the remote processor
* @rsc: the vring resource descriptor
@@ -455,6 +472,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct
fw_rsc_vdev *rsc,
struct device *dev = >dev;
struct rproc_vdev *rvdev;
int i, ret;
+ char name[16];
/* make sure resource isn't truncated */
if (sizeof(*rsc) + rsc->num_of_vrings * sizeof(struct fw_rsc_vdev_vring)
@@ -488,6 +506,28 @@ static int rproc_handle_vdev(struct rproc *rproc, struct
fw_rsc_vdev *rsc,
rvdev->rproc = rproc;
rvdev->index = rproc->nb_vdev++;
+ /* Initialise vdev subdevice */
+ snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
+ rvdev->dev.parent = rproc->dev.parent;
+ rvdev->dev.release = rproc_rvdev_release;
+ dev_set_name(>dev, "%s#%s", dev_name(rvdev->dev.parent), name);
+ dev_set_drvdata(>dev, rvdev);
+
+ ret = device_register(>dev);
+ if (ret)
+ goto free_rvdev;
+
+ /* Make device dma capable by inheriting from parent's capabilities */
+ set_dma_ops(>dev, get_dma_ops(rproc->dev.parent));
+
+ ret = dma_coerce_mask_and_coherent(>dev,
+ dma_get_mask(rproc->dev.parent));
+ if (ret) {
+ dev_warn(dev,
+"Failed to set DMA mask %llx. Trying to continue...
%x\n",
+dma_get_mask(rproc->dev.parent), ret);
+ }
+
/* parse the vrings */
for (i = 0; i < rsc->num_of_vrings; i++) {
ret = rproc_parse_vring(rvdev, rsc, i);
@@ -518,7 +558,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct
fw_rsc_vdev *rsc,
for (i--; i >= 0; i--)
rproc_free_vring(>vring[i]);
free_rvdev:
- kfree(rvdev);
+ device_unregister(>dev);
return ret;
}
@@ -536,7 +576,7 @@ void rproc_vdev_release(struct kref *ref)
rproc_remove_subdev(rproc, >subdev);
list_del(>node);
- kfree(rvdev);
+ device_unregister(>dev);
}
/**
diff --git a/drivers/remoteproc/remoteproc_internal.h
b/drivers/remoteproc/remoteproc_internal.h
index f6cad243d7ca..bfeacfd40947 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -52,6 +52,7 @@ void rproc_free_vring(struct rproc_vring *rvring);
int rproc_alloc_vring(struct rproc_vdev *rvdev, int i);
void *rproc_da_to_va(struct rproc *rproc, u64 da, int len);
+phys_addr_t rproc_va_to_pa(void *cpu_addr);
int rproc_trigger_recovery(struct rproc *rproc);
int rproc_elf_sanity_check(struct rproc *rproc, const struct firmware *fw);
diff --git a/drivers/remoteproc/remoteproc_virtio.c
b/drivers/remoteproc/remoteproc_virtio.c
index de21f620b882..9ee63c0dfbc3 100644
--- a/drivers/remoteproc/remoteproc_virtio.c
[PATCH 1/3] remoteproc: create vdev subdevice with specific dma memory pool
This patch creates a dedicated vdev subdevice for each vdev declared
in firmware resource table and associates carveout named "vdev%dbuffer"
(with %d vdev index in resource table) if any as dma coherent memory pool.
Then vdev subdevice is used as parent for virtio device.
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 46 +---
drivers/remoteproc/remoteproc_internal.h | 1 +
drivers/remoteproc/remoteproc_virtio.c | 42 -
include/linux/remoteproc.h | 1 +
4 files changed, 86 insertions(+), 4 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 54ec38fc5dca..49272da6edd7 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -39,9 +39,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include "remoteproc_internal.h"
@@ -145,7 +147,7 @@ static void rproc_disable_iommu(struct rproc *rproc)
iommu_domain_free(domain);
}
-static phys_addr_t rproc_va_to_pa(void *cpu_addr)
+phys_addr_t rproc_va_to_pa(void *cpu_addr)
{
/*
* Return physical address according to virtual address location
@@ -160,6 +162,7 @@ static phys_addr_t rproc_va_to_pa(void *cpu_addr)
WARN_ON(!virt_addr_valid(cpu_addr));
return virt_to_phys(cpu_addr);
}
+EXPORT_SYMBOL(rproc_va_to_pa);
/**
* rproc_da_to_va() - lookup the kernel virtual address for a remoteproc
address
@@ -423,6 +426,20 @@ static void rproc_vdev_do_stop(struct rproc_subdev
*subdev, bool crashed)
}
/**
+ * rproc_rvdev_release() - release the existence of a rvdev
+ *
+ * @dev: the subdevice's dev
+ */
+static void rproc_rvdev_release(struct device *dev)
+{
+ struct rproc_vdev *rvdev = container_of(dev, struct rproc_vdev, dev);
+
+ of_reserved_mem_device_release(dev);
+
+ kfree(rvdev);
+}
+
+/**
* rproc_handle_vdev() - handle a vdev fw resource
* @rproc: the remote processor
* @rsc: the vring resource descriptor
@@ -455,6 +472,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct
fw_rsc_vdev *rsc,
struct device *dev = >dev;
struct rproc_vdev *rvdev;
int i, ret;
+ char name[16];
/* make sure resource isn't truncated */
if (sizeof(*rsc) + rsc->num_of_vrings * sizeof(struct fw_rsc_vdev_vring)
@@ -488,6 +506,28 @@ static int rproc_handle_vdev(struct rproc *rproc, struct
fw_rsc_vdev *rsc,
rvdev->rproc = rproc;
rvdev->index = rproc->nb_vdev++;
+ /* Initialise vdev subdevice */
+ snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
+ rvdev->dev.parent = rproc->dev.parent;
+ rvdev->dev.release = rproc_rvdev_release;
+ dev_set_name(>dev, "%s#%s", dev_name(rvdev->dev.parent), name);
+ dev_set_drvdata(>dev, rvdev);
+
+ ret = device_register(>dev);
+ if (ret)
+ goto free_rvdev;
+
+ /* Make device dma capable by inheriting from parent's capabilities */
+ set_dma_ops(>dev, get_dma_ops(rproc->dev.parent));
+
+ ret = dma_coerce_mask_and_coherent(>dev,
+ dma_get_mask(rproc->dev.parent));
+ if (ret) {
+ dev_warn(dev,
+"Failed to set DMA mask %llx. Trying to continue...
%x\n",
+dma_get_mask(rproc->dev.parent), ret);
+ }
+
/* parse the vrings */
for (i = 0; i < rsc->num_of_vrings; i++) {
ret = rproc_parse_vring(rvdev, rsc, i);
@@ -518,7 +558,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct
fw_rsc_vdev *rsc,
for (i--; i >= 0; i--)
rproc_free_vring(>vring[i]);
free_rvdev:
- kfree(rvdev);
+ device_unregister(>dev);
return ret;
}
@@ -536,7 +576,7 @@ void rproc_vdev_release(struct kref *ref)
rproc_remove_subdev(rproc, >subdev);
list_del(>node);
- kfree(rvdev);
+ device_unregister(>dev);
}
/**
diff --git a/drivers/remoteproc/remoteproc_internal.h
b/drivers/remoteproc/remoteproc_internal.h
index f6cad243d7ca..bfeacfd40947 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -52,6 +52,7 @@ void rproc_free_vring(struct rproc_vring *rvring);
int rproc_alloc_vring(struct rproc_vdev *rvdev, int i);
void *rproc_da_to_va(struct rproc *rproc, u64 da, int len);
+phys_addr_t rproc_va_to_pa(void *cpu_addr);
int rproc_trigger_recovery(struct rproc *rproc);
int rproc_elf_sanity_check(struct rproc *rproc, const struct firmware *fw);
diff --git a/drivers/remoteproc/remoteproc_virtio.c
b/drivers/remoteproc/remoteproc_virtio.c
index de21f620b882..9ee63c0dfbc3 100644
--- a/drivers/remoteproc/remoteproc_virtio.c
[PATCH 0/3] remoteproc: complete fixed memory region support
This new series corresponds to the remaining patches from [1] addressing fixed memory region support for remote processor. The three remaining patches allow to: - assign a specific memory region to vdev sub device. As all virtio based services are using virtio device parent for memory allocation, I propose to keep a dedicated vdev device per virtio link for memory allocation. A second step will be to used virtio device itself. - migrate ST driver on new memory carveout management - allocate virtio rpmsg buffer from parent device Regards, Loic [1] https://lkml.org/lkml/2018/7/27/612 Loic Pallardy (3): remoteproc: create vdev subdevice with specific dma memory pool remoteproc: st: add reserved memory support rpmsg: virtio: allocate buffer from parent drivers/remoteproc/remoteproc_core.c | 46 ++-- drivers/remoteproc/remoteproc_internal.h | 1 + drivers/remoteproc/remoteproc_virtio.c | 42 ++- drivers/remoteproc/st_remoteproc.c | 91 drivers/rpmsg/virtio_rpmsg_bus.c | 6 +-- include/linux/remoteproc.h | 1 + 6 files changed, 169 insertions(+), 18 deletions(-) -- 2.7.4
[PATCH 0/3] remoteproc: complete fixed memory region support
This new series corresponds to the remaining patches from [1] addressing fixed memory region support for remote processor. The three remaining patches allow to: - assign a specific memory region to vdev sub device. As all virtio based services are using virtio device parent for memory allocation, I propose to keep a dedicated vdev device per virtio link for memory allocation. A second step will be to used virtio device itself. - migrate ST driver on new memory carveout management - allocate virtio rpmsg buffer from parent device Regards, Loic [1] https://lkml.org/lkml/2018/7/27/612 Loic Pallardy (3): remoteproc: create vdev subdevice with specific dma memory pool remoteproc: st: add reserved memory support rpmsg: virtio: allocate buffer from parent drivers/remoteproc/remoteproc_core.c | 46 ++-- drivers/remoteproc/remoteproc_internal.h | 1 + drivers/remoteproc/remoteproc_virtio.c | 42 ++- drivers/remoteproc/st_remoteproc.c | 91 drivers/rpmsg/virtio_rpmsg_bus.c | 6 +-- include/linux/remoteproc.h | 1 + 6 files changed, 169 insertions(+), 18 deletions(-) -- 2.7.4
[PATCH 4/7] remoteproc: add warning on resource table cast
Today resource table supports only 32bit address fields.
This is not compliant with 64bit platform for which addresses
are cast in 32bit.
This patch adds warn messages when address cast is done.
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 18a1bbf820c9..61c954bd695e 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -772,6 +772,10 @@ static int rproc_alloc_carveout(struct rproc *rproc,
dev_dbg(dev, "carveout mapped 0x%x to %pad\n",
mem->da, );
} else {
+ /* Update device address as undefined by requester */
+ if (sizeof(dma_addr_t) > sizeof(u32))
+ dev_warn(dev, "DMA address cast in 32bit to fit
resource table format\n");
+
mem->da = (u32)dma;
}
@@ -1150,6 +1154,10 @@ static int rproc_alloc_registered_carveouts(struct rproc
*rproc)
*/
/* Use va if defined else dma to generate pa */
+ if (sizeof(dma_addr_t) > sizeof(u32) ||
+ sizeof(phys_addr_t) > sizeof(u32))
+ dev_warn(dev, "Physical address cast in 32bit
to fit resource table format\n");
+
if (entry->va)
rsc->pa = (u32)rproc_va_to_pa(entry->va);
else
--
2.7.4
[PATCH 5/7] remoteproc: fix rproc_alloc_carveout() for rproc with iommu domain
Correct remoteproc core behavior when memory carveout device
address is fixed in resource table and rproc device doesn't have
associated IOMMU.
Current returned error is breaking legacy on TI platforms.
This patch restores previous behavior. It adds a warn message when
allocation doesn't fit carveout request, but doesn't stop rproc_start()
sequence anymore.
Fixes: 3bc8140b157c ("remoteproc: configure IOMMU only if device address
requested")
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 61c954bd695e..f19bc6961e40 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -719,6 +719,18 @@ static int rproc_alloc_carveout(struct rproc *rproc,
dev_dbg(dev, "carveout va %pK, dma %pad, len 0x%x\n",
va, , mem->len);
+ if (mem->da != FW_RSC_ADDR_ANY && !rproc->domain) {
+ /*
+* Check requested da is equal to dma address
+* and print a warn message in case of missalignment.
+* Don't stop rproc_start sequence as coprocessor may
+* build pa to da translation on its side.
+*/
+ if (mem->da != (u32)dma)
+ dev_warn(dev->parent,
+"Allocated carveout doesn't fit device address
request\n");
+ }
+
/*
* Ok, this is non-standard.
*
@@ -736,15 +748,7 @@ static int rproc_alloc_carveout(struct rproc *rproc,
* to use the iommu-based DMA API: we expect 'dma' to contain the
* physical address in this case.
*/
-
- if (mem->da != FW_RSC_ADDR_ANY) {
- if (!rproc->domain) {
- dev_err(dev->parent,
- "Bad carveout rsc configuration\n");
- ret = -ENOMEM;
- goto dma_free;
- }
-
+ if (mem->da != FW_RSC_ADDR_ANY && rproc->domain) {
mapping = kzalloc(sizeof(*mapping), GFP_KERNEL);
if (!mapping) {
ret = -ENOMEM;
@@ -771,7 +775,9 @@ static int rproc_alloc_carveout(struct rproc *rproc,
dev_dbg(dev, "carveout mapped 0x%x to %pad\n",
mem->da, );
- } else {
+ }
+
+ if (mem->da == FW_RSC_ADDR_ANY) {
/* Update device address as undefined by requester */
if (sizeof(dma_addr_t) > sizeof(u32))
dev_warn(dev, "DMA address cast in 32bit to fit
resource table format\n");
--
2.7.4
[PATCH 7/7] remoteproc: fix rproc_check_carveout_da() returned error and comments
Fix typo in comments.
Change returned error from ENOMEM to EINVAL as
not dealing with memory allocation.
Remove carveout forced da update and return an error
when no configuration match
Fixes: c874bf59add0 ("remoteproc: add helper function to check carveout device
address")
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 9dbcc16f8782..b69ce5bff732 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -276,25 +276,27 @@ rproc_find_carveout_by_name(struct rproc *rproc, const
char *name, ...)
* @len: associated area size
*
* This function is a helper function to verify requested device area (couple
- * da, len) is part of specified carevout.
+ * da, len) is part of specified carveout.
+ * If da is not set (defined as FW_RSC_ADDR_ANY), only requested length is
+ * checked.
*
- * Return: 0 if carveout match request else -ENOMEM
+ * Return: 0 if carveout matches request else error
*/
-int rproc_check_carveout_da(struct rproc *rproc, struct rproc_mem_entry *mem,
- u32 da, u32 len)
+static int rproc_check_carveout_da(struct rproc *rproc,
+ struct rproc_mem_entry *mem, u32 da, u32 len)
{
struct device *dev = >dev;
- int delta = 0;
+ int delta;
/* Check requested resource length */
if (len > mem->len) {
dev_err(dev, "Registered carveout doesn't fit len request\n");
- return -ENOMEM;
+ return -EINVAL;
}
if (da != FW_RSC_ADDR_ANY && mem->da == FW_RSC_ADDR_ANY) {
- /* Update existing carveout da */
- mem->da = da;
+ /* Address doesn't match registered carveout configuration */
+ return -EINVAL;
} else if (da != FW_RSC_ADDR_ANY && mem->da != FW_RSC_ADDR_ANY) {
delta = da - mem->da;
@@ -302,13 +304,13 @@ int rproc_check_carveout_da(struct rproc *rproc, struct
rproc_mem_entry *mem,
if (delta < 0) {
dev_err(dev,
"Registered carveout doesn't fit da request\n");
- return -ENOMEM;
+ return -EINVAL;
}
if (delta + len > mem->len) {
dev_err(dev,
"Registered carveout doesn't fit len
request\n");
- return -ENOMEM;
+ return -EINVAL;
}
}
--
2.7.4
[PATCH 4/7] remoteproc: add warning on resource table cast
Today resource table supports only 32bit address fields.
This is not compliant with 64bit platform for which addresses
are cast in 32bit.
This patch adds warn messages when address cast is done.
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 18a1bbf820c9..61c954bd695e 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -772,6 +772,10 @@ static int rproc_alloc_carveout(struct rproc *rproc,
dev_dbg(dev, "carveout mapped 0x%x to %pad\n",
mem->da, );
} else {
+ /* Update device address as undefined by requester */
+ if (sizeof(dma_addr_t) > sizeof(u32))
+ dev_warn(dev, "DMA address cast in 32bit to fit
resource table format\n");
+
mem->da = (u32)dma;
}
@@ -1150,6 +1154,10 @@ static int rproc_alloc_registered_carveouts(struct rproc
*rproc)
*/
/* Use va if defined else dma to generate pa */
+ if (sizeof(dma_addr_t) > sizeof(u32) ||
+ sizeof(phys_addr_t) > sizeof(u32))
+ dev_warn(dev, "Physical address cast in 32bit
to fit resource table format\n");
+
if (entry->va)
rsc->pa = (u32)rproc_va_to_pa(entry->va);
else
--
2.7.4
[PATCH 5/7] remoteproc: fix rproc_alloc_carveout() for rproc with iommu domain
Correct remoteproc core behavior when memory carveout device
address is fixed in resource table and rproc device doesn't have
associated IOMMU.
Current returned error is breaking legacy on TI platforms.
This patch restores previous behavior. It adds a warn message when
allocation doesn't fit carveout request, but doesn't stop rproc_start()
sequence anymore.
Fixes: 3bc8140b157c ("remoteproc: configure IOMMU only if device address
requested")
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 61c954bd695e..f19bc6961e40 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -719,6 +719,18 @@ static int rproc_alloc_carveout(struct rproc *rproc,
dev_dbg(dev, "carveout va %pK, dma %pad, len 0x%x\n",
va, , mem->len);
+ if (mem->da != FW_RSC_ADDR_ANY && !rproc->domain) {
+ /*
+* Check requested da is equal to dma address
+* and print a warn message in case of missalignment.
+* Don't stop rproc_start sequence as coprocessor may
+* build pa to da translation on its side.
+*/
+ if (mem->da != (u32)dma)
+ dev_warn(dev->parent,
+"Allocated carveout doesn't fit device address
request\n");
+ }
+
/*
* Ok, this is non-standard.
*
@@ -736,15 +748,7 @@ static int rproc_alloc_carveout(struct rproc *rproc,
* to use the iommu-based DMA API: we expect 'dma' to contain the
* physical address in this case.
*/
-
- if (mem->da != FW_RSC_ADDR_ANY) {
- if (!rproc->domain) {
- dev_err(dev->parent,
- "Bad carveout rsc configuration\n");
- ret = -ENOMEM;
- goto dma_free;
- }
-
+ if (mem->da != FW_RSC_ADDR_ANY && rproc->domain) {
mapping = kzalloc(sizeof(*mapping), GFP_KERNEL);
if (!mapping) {
ret = -ENOMEM;
@@ -771,7 +775,9 @@ static int rproc_alloc_carveout(struct rproc *rproc,
dev_dbg(dev, "carveout mapped 0x%x to %pad\n",
mem->da, );
- } else {
+ }
+
+ if (mem->da == FW_RSC_ADDR_ANY) {
/* Update device address as undefined by requester */
if (sizeof(dma_addr_t) > sizeof(u32))
dev_warn(dev, "DMA address cast in 32bit to fit
resource table format\n");
--
2.7.4
[PATCH 7/7] remoteproc: fix rproc_check_carveout_da() returned error and comments
Fix typo in comments.
Change returned error from ENOMEM to EINVAL as
not dealing with memory allocation.
Remove carveout forced da update and return an error
when no configuration match
Fixes: c874bf59add0 ("remoteproc: add helper function to check carveout device
address")
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 9dbcc16f8782..b69ce5bff732 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -276,25 +276,27 @@ rproc_find_carveout_by_name(struct rproc *rproc, const
char *name, ...)
* @len: associated area size
*
* This function is a helper function to verify requested device area (couple
- * da, len) is part of specified carevout.
+ * da, len) is part of specified carveout.
+ * If da is not set (defined as FW_RSC_ADDR_ANY), only requested length is
+ * checked.
*
- * Return: 0 if carveout match request else -ENOMEM
+ * Return: 0 if carveout matches request else error
*/
-int rproc_check_carveout_da(struct rproc *rproc, struct rproc_mem_entry *mem,
- u32 da, u32 len)
+static int rproc_check_carveout_da(struct rproc *rproc,
+ struct rproc_mem_entry *mem, u32 da, u32 len)
{
struct device *dev = >dev;
- int delta = 0;
+ int delta;
/* Check requested resource length */
if (len > mem->len) {
dev_err(dev, "Registered carveout doesn't fit len request\n");
- return -ENOMEM;
+ return -EINVAL;
}
if (da != FW_RSC_ADDR_ANY && mem->da == FW_RSC_ADDR_ANY) {
- /* Update existing carveout da */
- mem->da = da;
+ /* Address doesn't match registered carveout configuration */
+ return -EINVAL;
} else if (da != FW_RSC_ADDR_ANY && mem->da != FW_RSC_ADDR_ANY) {
delta = da - mem->da;
@@ -302,13 +304,13 @@ int rproc_check_carveout_da(struct rproc *rproc, struct
rproc_mem_entry *mem,
if (delta < 0) {
dev_err(dev,
"Registered carveout doesn't fit da request\n");
- return -ENOMEM;
+ return -EINVAL;
}
if (delta + len > mem->len) {
dev_err(dev,
"Registered carveout doesn't fit len
request\n");
- return -ENOMEM;
+ return -EINVAL;
}
}
--
2.7.4
[PATCH 0/7] remoteproc: Fixes for memoy carveout management
These patches fix the comments sent on remoteproc mailing list after acceptation of memory carveout patch series [1]. In few words, series corrects: - memory carveout allocation for rproc without iommu - rproc_da_to_va and trace buffer access to take into account late carveout allocation - resource table cast by adding warning messages Regards, Loic [1] https://lkml.org/lkml/2018/7/27/612 Loic Pallardy (7): remoteproc: correct rproc_mem_entry_init() comments remoteproc: fix rproc_da_to_va in case of unallocated carveout remoteproc: fix rproc_alloc_carveout() bad variable cast remoteproc: add warning on resource table cast remoteproc: fix rproc_alloc_carveout() for rproc with iommu domain remoteproc: fix trace buffer va initialization remoteproc: fix rproc_check_carveout_da() returned error and comments drivers/remoteproc/remoteproc_core.c | 91 +++- drivers/remoteproc/remoteproc_debugfs.c | 21 ++-- drivers/remoteproc/remoteproc_internal.h | 9 +++- 3 files changed, 78 insertions(+), 43 deletions(-) -- 2.7.4
[PATCH 6/7] remoteproc: fix trace buffer va initialization
With rproc_alloc_registered_carveouts() introduction, carveouts are
allocated after resource table parsing.
rproc_da_to_va() may return NULL at trace resource registering.
This patch modifies trace debufs registering to provide device address
(da) instead of va.
da to va translation is done at each trace buffer access
through debugfs interface.
Fixes: d7c51706d095 ("remoteproc: add alloc ops in rproc_mem_entry struct")
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 26 ++
drivers/remoteproc/remoteproc_debugfs.c | 21 +
drivers/remoteproc/remoteproc_internal.h | 9 -
3 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index f19bc6961e40..9dbcc16f8782 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -562,9 +562,8 @@ void rproc_vdev_release(struct kref *ref)
static int rproc_handle_trace(struct rproc *rproc, struct fw_rsc_trace *rsc,
int offset, int avail)
{
- struct rproc_mem_entry *trace;
+ struct rproc_debug_trace *trace;
struct device *dev = >dev;
- void *ptr;
char name[15];
if (sizeof(*rsc) > avail) {
@@ -578,28 +577,23 @@ static int rproc_handle_trace(struct rproc *rproc, struct
fw_rsc_trace *rsc,
return -EINVAL;
}
- /* what's the kernel address of this resource ? */
- ptr = rproc_da_to_va(rproc, rsc->da, rsc->len);
- if (!ptr) {
- dev_err(dev, "erroneous trace resource entry\n");
- return -EINVAL;
- }
-
trace = kzalloc(sizeof(*trace), GFP_KERNEL);
if (!trace)
return -ENOMEM;
/* set the trace buffer dma properties */
- trace->len = rsc->len;
- trace->va = ptr;
+ trace->trace_mem.len = rsc->len;
+ trace->trace_mem.da = rsc->da;
+
+ /* set pointer on rproc device */
+ trace->rproc = rproc;
/* make sure snprintf always null terminates, even if truncating */
snprintf(name, sizeof(name), "trace%d", rproc->num_traces);
/* create the debugfs entry */
- trace->priv = rproc_create_trace_file(name, rproc, trace);
- if (!trace->priv) {
- trace->va = NULL;
+ trace->tfile = rproc_create_trace_file(name, rproc, trace);
+ if (!trace->tfile) {
kfree(trace);
return -EINVAL;
}
@@ -608,8 +602,8 @@ static int rproc_handle_trace(struct rproc *rproc, struct
fw_rsc_trace *rsc,
rproc->num_traces++;
- dev_dbg(dev, "%s added: va %pK, da 0x%x, len 0x%x\n",
- name, ptr, rsc->da, rsc->len);
+ dev_dbg(dev, "%s added: da 0x%x, len 0x%x\n",
+ name, rsc->da, rsc->len);
return 0;
}
diff --git a/drivers/remoteproc/remoteproc_debugfs.c
b/drivers/remoteproc/remoteproc_debugfs.c
index e90135c64af0..11240b4d0a91 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -47,10 +47,23 @@ static struct dentry *rproc_dbg;
static ssize_t rproc_trace_read(struct file *filp, char __user *userbuf,
size_t count, loff_t *ppos)
{
- struct rproc_mem_entry *trace = filp->private_data;
- int len = strnlen(trace->va, trace->len);
+ struct rproc_debug_trace *data = filp->private_data;
+ struct rproc_mem_entry *trace = >trace_mem;
+ void *va;
+ char buf[100];
+ int len;
+
+ va = rproc_da_to_va(data->rproc, trace->da, trace->len);
+
+ if (!va) {
+ len = scnprintf(buf, sizeof(buf), "Trace %s not available\n",
+ trace->name);
+ va = buf;
+ } else {
+ len = strnlen(va, trace->len);
+ }
- return simple_read_from_buffer(userbuf, count, ppos, trace->va, len);
+ return simple_read_from_buffer(userbuf, count, ppos, va, len);
}
static const struct file_operations trace_rproc_ops = {
@@ -288,7 +301,7 @@ void rproc_remove_trace_file(struct dentry *tfile)
}
struct dentry *rproc_create_trace_file(const char *name, struct rproc *rproc,
- struct rproc_mem_entry *trace)
+ struct rproc_debug_trace *trace)
{
struct dentry *tfile;
diff --git a/drivers/remoteproc/remoteproc_internal.h
b/drivers/remoteproc/remoteproc_internal.h
index f6cad243d7ca..7d8936688164 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -25,6 +25,13 @@
struct rproc;
+struct rproc_debug_trace {
+ struct rproc *rproc;
+ struct dentry *tfile;
[PATCH 0/7] remoteproc: Fixes for memoy carveout management
These patches fix the comments sent on remoteproc mailing list after acceptation of memory carveout patch series [1]. In few words, series corrects: - memory carveout allocation for rproc without iommu - rproc_da_to_va and trace buffer access to take into account late carveout allocation - resource table cast by adding warning messages Regards, Loic [1] https://lkml.org/lkml/2018/7/27/612 Loic Pallardy (7): remoteproc: correct rproc_mem_entry_init() comments remoteproc: fix rproc_da_to_va in case of unallocated carveout remoteproc: fix rproc_alloc_carveout() bad variable cast remoteproc: add warning on resource table cast remoteproc: fix rproc_alloc_carveout() for rproc with iommu domain remoteproc: fix trace buffer va initialization remoteproc: fix rproc_check_carveout_da() returned error and comments drivers/remoteproc/remoteproc_core.c | 91 +++- drivers/remoteproc/remoteproc_debugfs.c | 21 ++-- drivers/remoteproc/remoteproc_internal.h | 9 +++- 3 files changed, 78 insertions(+), 43 deletions(-) -- 2.7.4
[PATCH 6/7] remoteproc: fix trace buffer va initialization
With rproc_alloc_registered_carveouts() introduction, carveouts are
allocated after resource table parsing.
rproc_da_to_va() may return NULL at trace resource registering.
This patch modifies trace debufs registering to provide device address
(da) instead of va.
da to va translation is done at each trace buffer access
through debugfs interface.
Fixes: d7c51706d095 ("remoteproc: add alloc ops in rproc_mem_entry struct")
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 26 ++
drivers/remoteproc/remoteproc_debugfs.c | 21 +
drivers/remoteproc/remoteproc_internal.h | 9 -
3 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index f19bc6961e40..9dbcc16f8782 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -562,9 +562,8 @@ void rproc_vdev_release(struct kref *ref)
static int rproc_handle_trace(struct rproc *rproc, struct fw_rsc_trace *rsc,
int offset, int avail)
{
- struct rproc_mem_entry *trace;
+ struct rproc_debug_trace *trace;
struct device *dev = >dev;
- void *ptr;
char name[15];
if (sizeof(*rsc) > avail) {
@@ -578,28 +577,23 @@ static int rproc_handle_trace(struct rproc *rproc, struct
fw_rsc_trace *rsc,
return -EINVAL;
}
- /* what's the kernel address of this resource ? */
- ptr = rproc_da_to_va(rproc, rsc->da, rsc->len);
- if (!ptr) {
- dev_err(dev, "erroneous trace resource entry\n");
- return -EINVAL;
- }
-
trace = kzalloc(sizeof(*trace), GFP_KERNEL);
if (!trace)
return -ENOMEM;
/* set the trace buffer dma properties */
- trace->len = rsc->len;
- trace->va = ptr;
+ trace->trace_mem.len = rsc->len;
+ trace->trace_mem.da = rsc->da;
+
+ /* set pointer on rproc device */
+ trace->rproc = rproc;
/* make sure snprintf always null terminates, even if truncating */
snprintf(name, sizeof(name), "trace%d", rproc->num_traces);
/* create the debugfs entry */
- trace->priv = rproc_create_trace_file(name, rproc, trace);
- if (!trace->priv) {
- trace->va = NULL;
+ trace->tfile = rproc_create_trace_file(name, rproc, trace);
+ if (!trace->tfile) {
kfree(trace);
return -EINVAL;
}
@@ -608,8 +602,8 @@ static int rproc_handle_trace(struct rproc *rproc, struct
fw_rsc_trace *rsc,
rproc->num_traces++;
- dev_dbg(dev, "%s added: va %pK, da 0x%x, len 0x%x\n",
- name, ptr, rsc->da, rsc->len);
+ dev_dbg(dev, "%s added: da 0x%x, len 0x%x\n",
+ name, rsc->da, rsc->len);
return 0;
}
diff --git a/drivers/remoteproc/remoteproc_debugfs.c
b/drivers/remoteproc/remoteproc_debugfs.c
index e90135c64af0..11240b4d0a91 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -47,10 +47,23 @@ static struct dentry *rproc_dbg;
static ssize_t rproc_trace_read(struct file *filp, char __user *userbuf,
size_t count, loff_t *ppos)
{
- struct rproc_mem_entry *trace = filp->private_data;
- int len = strnlen(trace->va, trace->len);
+ struct rproc_debug_trace *data = filp->private_data;
+ struct rproc_mem_entry *trace = >trace_mem;
+ void *va;
+ char buf[100];
+ int len;
+
+ va = rproc_da_to_va(data->rproc, trace->da, trace->len);
+
+ if (!va) {
+ len = scnprintf(buf, sizeof(buf), "Trace %s not available\n",
+ trace->name);
+ va = buf;
+ } else {
+ len = strnlen(va, trace->len);
+ }
- return simple_read_from_buffer(userbuf, count, ppos, trace->va, len);
+ return simple_read_from_buffer(userbuf, count, ppos, va, len);
}
static const struct file_operations trace_rproc_ops = {
@@ -288,7 +301,7 @@ void rproc_remove_trace_file(struct dentry *tfile)
}
struct dentry *rproc_create_trace_file(const char *name, struct rproc *rproc,
- struct rproc_mem_entry *trace)
+ struct rproc_debug_trace *trace)
{
struct dentry *tfile;
diff --git a/drivers/remoteproc/remoteproc_internal.h
b/drivers/remoteproc/remoteproc_internal.h
index f6cad243d7ca..7d8936688164 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -25,6 +25,13 @@
struct rproc;
+struct rproc_debug_trace {
+ struct rproc *rproc;
+ struct dentry *tfile;
[PATCH 1/7] remoteproc: correct rproc_mem_entry_init() comments
Add alloc parameter description and correct comment about release one. Signed-off-by: Loic Pallardy --- drivers/remoteproc/remoteproc_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index 54ec38fc5dca..c1a66e25b173 100644 --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -900,7 +900,8 @@ EXPORT_SYMBOL(rproc_add_carveout); * @dma: dma address * @len: memory carveout length * @da: device address - * @release: memory carveout function + * @alloc: memory carveout allocation function + * @release: memory carveout release function * @name: carveout name * * This function allocates a rproc_mem_entry struct and fill it with parameters -- 2.7.4
[PATCH 3/7] remoteproc: fix rproc_alloc_carveout() bad variable cast
As dma member of struct rproc_mem_entry is dma_addr_t, no
need to cast in u32.
Fixes: d7c51706d095 ("remoteproc: add alloc ops in rproc_mem_entry struct")
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 28df71cb3fef..18a1bbf820c9 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -775,7 +775,7 @@ static int rproc_alloc_carveout(struct rproc *rproc,
mem->da = (u32)dma;
}
- mem->dma = (u32)dma;
+ mem->dma = dma;
mem->va = va;
return 0;
--
2.7.4
[PATCH 2/7] remoteproc: fix rproc_da_to_va in case of unallocated carveout
With introduction of rproc_alloc_registered_carveouts() which
delays carveout allocation just before the start of the remote
processor, rproc_da_to_va() could be called before all carveouts
are allocated.
This patch adds a check in rproc_da_to_va() to return NULL if
carveout is not allocated.
Fixes: d7c51706d095 ("remoteproc: add alloc ops in rproc_mem_entry struct")
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index c1a66e25b173..28df71cb3fef 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -204,6 +204,10 @@ void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
list_for_each_entry(carveout, >carveouts, node) {
int offset = da - carveout->da;
+ /* Verify that carveout is allocated */
+ if (!carveout->va)
+ continue;
+
/* try next carveout if da is too small */
if (offset < 0)
continue;
--
2.7.4
[PATCH 1/7] remoteproc: correct rproc_mem_entry_init() comments
Add alloc parameter description and correct comment about release one. Signed-off-by: Loic Pallardy --- drivers/remoteproc/remoteproc_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index 54ec38fc5dca..c1a66e25b173 100644 --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -900,7 +900,8 @@ EXPORT_SYMBOL(rproc_add_carveout); * @dma: dma address * @len: memory carveout length * @da: device address - * @release: memory carveout function + * @alloc: memory carveout allocation function + * @release: memory carveout release function * @name: carveout name * * This function allocates a rproc_mem_entry struct and fill it with parameters -- 2.7.4
[PATCH 3/7] remoteproc: fix rproc_alloc_carveout() bad variable cast
As dma member of struct rproc_mem_entry is dma_addr_t, no
need to cast in u32.
Fixes: d7c51706d095 ("remoteproc: add alloc ops in rproc_mem_entry struct")
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 28df71cb3fef..18a1bbf820c9 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -775,7 +775,7 @@ static int rproc_alloc_carveout(struct rproc *rproc,
mem->da = (u32)dma;
}
- mem->dma = (u32)dma;
+ mem->dma = dma;
mem->va = va;
return 0;
--
2.7.4
[PATCH 2/7] remoteproc: fix rproc_da_to_va in case of unallocated carveout
With introduction of rproc_alloc_registered_carveouts() which
delays carveout allocation just before the start of the remote
processor, rproc_da_to_va() could be called before all carveouts
are allocated.
This patch adds a check in rproc_da_to_va() to return NULL if
carveout is not allocated.
Fixes: d7c51706d095 ("remoteproc: add alloc ops in rproc_mem_entry struct")
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index c1a66e25b173..28df71cb3fef 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -204,6 +204,10 @@ void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
list_for_each_entry(carveout, >carveouts, node) {
int offset = da - carveout->da;
+ /* Verify that carveout is allocated */
+ if (!carveout->va)
+ continue;
+
/* try next carveout if da is too small */
if (offset < 0)
continue;
--
2.7.4
[PATCH 0/2] remoteproc: add support for preloaded firmware
This patch series introduces a new flag in remoteproc core to add support of remote processor having their firmware loading by another way than standard remoteproc core sequence. Firmware could be ROMed, loaded by security or bootloader before kernel boot or loaded by a special rproc platform driver interface. When "preloaded" flag is set by rproc platform driver, remoteproc core doesn't request firmware and execute rproc_start sequence as usual allocating associated rproc resources. It is rproc platform driver responsibility to implement the right firmware load operations according to HW specificities like resource table location or firmware definition if needed. Regards, Loic Loic Pallardy (2): remoteproc: replace bool from struct rproc by u8 remoteproc: add support for co-processor booted before kernel drivers/remoteproc/remoteproc_core.c | 37 +++- include/linux/remoteproc.h | 14 -- 2 files changed, 36 insertions(+), 15 deletions(-) -- 2.7.4
[PATCH 2/2] remoteproc: add support for co-processor booted before kernel
Remote processor could boot independently or be started before Linux
kernel by bootloader or any firmware.
This patch introduces a new property in rproc core, named preloaded,
to be able to allocate resources and sub-devices like vdev and to
synchronize with current state without loading firmware from file system.
It is platform driver responsibility to implement the right firmware
load ops according to HW specificities.
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 37 +++-
include/linux/remoteproc.h | 2 ++
2 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 54ec38fc5dca..8fc9a1bbb2a4 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1301,7 +1301,11 @@ static int rproc_fw_boot(struct rproc *rproc, const
struct firmware *fw)
if (ret)
return ret;
- dev_info(dev, "Booting fw image %s, size %zd\n", name, fw->size);
+ if (fw)
+ dev_info(dev, "Booting fw image %s, size %zd\n", name,
+fw->size);
+ else
+ dev_info(dev, "Synchronizing with preloaded co-processor\n");
/*
* if enabling an IOMMU isn't relevant for this rproc, this is
@@ -1657,7 +1661,7 @@ static void rproc_crash_handler_work(struct work_struct
*work)
*/
int rproc_boot(struct rproc *rproc)
{
- const struct firmware *firmware_p;
+ const struct firmware *firmware_p = NULL;
struct device *dev;
int ret;
@@ -1688,11 +1692,17 @@ int rproc_boot(struct rproc *rproc)
dev_info(dev, "powering up %s\n", rproc->name);
- /* load firmware */
- ret = request_firmware(_p, rproc->firmware, dev);
- if (ret < 0) {
- dev_err(dev, "request_firmware failed: %d\n", ret);
- goto downref_rproc;
+ if (!rproc->preloaded) {
+ /* load firmware */
+ ret = request_firmware(_p, rproc->firmware, dev);
+ if (ret < 0) {
+ dev_err(dev, "request_firmware failed: %d\n", ret);
+ goto downref_rproc;
+ }
+ } else {
+ /* set firmware name to null as unknown */
+ kfree(rproc->firmware);
+ rproc->firmware = NULL;
}
ret = rproc_fw_boot(rproc, firmware_p);
@@ -1846,8 +1856,17 @@ int rproc_add(struct rproc *rproc)
/* create debugfs entries */
rproc_create_debug_dir(rproc);
- /* if rproc is marked always-on, request it to boot */
- if (rproc->auto_boot) {
+ if (rproc->preloaded) {
+ /*
+* If rproc is marked already booted, no need to wait
+* for firmware.
+* Just handle associated resources and start sub devices
+*/
+ ret = rproc_boot(rproc);
+ if (ret < 0)
+ return ret;
+ } else if (rproc->auto_boot) {
+ /* if rproc is marked always-on, request it to boot */
ret = rproc_trigger_auto_boot(rproc);
if (ret < 0)
return ret;
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index b6660088949f..996404833a29 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -461,6 +461,7 @@ struct rproc_dump_segment {
* @recovery_disabled: flag that state if recovery was disabled
* @has_iommu: flag to indicate if remote processor is behind an MMU
* @auto_boot: flag to indicate if remote processor should be auto-started
+ * @preloaded: remote processor has been preloaded before start sequence
*/
struct rproc {
struct list_head node;
@@ -494,6 +495,7 @@ struct rproc {
u8 recovery_disabled;
u8 has_iommu;
u8 auto_boot;
+ u8 preloaded;
};
/**
--
2.7.4
[PATCH 0/2] remoteproc: add support for preloaded firmware
This patch series introduces a new flag in remoteproc core to add support of remote processor having their firmware loading by another way than standard remoteproc core sequence. Firmware could be ROMed, loaded by security or bootloader before kernel boot or loaded by a special rproc platform driver interface. When "preloaded" flag is set by rproc platform driver, remoteproc core doesn't request firmware and execute rproc_start sequence as usual allocating associated rproc resources. It is rproc platform driver responsibility to implement the right firmware load operations according to HW specificities like resource table location or firmware definition if needed. Regards, Loic Loic Pallardy (2): remoteproc: replace bool from struct rproc by u8 remoteproc: add support for co-processor booted before kernel drivers/remoteproc/remoteproc_core.c | 37 +++- include/linux/remoteproc.h | 14 -- 2 files changed, 36 insertions(+), 15 deletions(-) -- 2.7.4
[PATCH 2/2] remoteproc: add support for co-processor booted before kernel
Remote processor could boot independently or be started before Linux
kernel by bootloader or any firmware.
This patch introduces a new property in rproc core, named preloaded,
to be able to allocate resources and sub-devices like vdev and to
synchronize with current state without loading firmware from file system.
It is platform driver responsibility to implement the right firmware
load ops according to HW specificities.
Signed-off-by: Loic Pallardy
---
drivers/remoteproc/remoteproc_core.c | 37 +++-
include/linux/remoteproc.h | 2 ++
2 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 54ec38fc5dca..8fc9a1bbb2a4 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1301,7 +1301,11 @@ static int rproc_fw_boot(struct rproc *rproc, const
struct firmware *fw)
if (ret)
return ret;
- dev_info(dev, "Booting fw image %s, size %zd\n", name, fw->size);
+ if (fw)
+ dev_info(dev, "Booting fw image %s, size %zd\n", name,
+fw->size);
+ else
+ dev_info(dev, "Synchronizing with preloaded co-processor\n");
/*
* if enabling an IOMMU isn't relevant for this rproc, this is
@@ -1657,7 +1661,7 @@ static void rproc_crash_handler_work(struct work_struct
*work)
*/
int rproc_boot(struct rproc *rproc)
{
- const struct firmware *firmware_p;
+ const struct firmware *firmware_p = NULL;
struct device *dev;
int ret;
@@ -1688,11 +1692,17 @@ int rproc_boot(struct rproc *rproc)
dev_info(dev, "powering up %s\n", rproc->name);
- /* load firmware */
- ret = request_firmware(_p, rproc->firmware, dev);
- if (ret < 0) {
- dev_err(dev, "request_firmware failed: %d\n", ret);
- goto downref_rproc;
+ if (!rproc->preloaded) {
+ /* load firmware */
+ ret = request_firmware(_p, rproc->firmware, dev);
+ if (ret < 0) {
+ dev_err(dev, "request_firmware failed: %d\n", ret);
+ goto downref_rproc;
+ }
+ } else {
+ /* set firmware name to null as unknown */
+ kfree(rproc->firmware);
+ rproc->firmware = NULL;
}
ret = rproc_fw_boot(rproc, firmware_p);
@@ -1846,8 +1856,17 @@ int rproc_add(struct rproc *rproc)
/* create debugfs entries */
rproc_create_debug_dir(rproc);
- /* if rproc is marked always-on, request it to boot */
- if (rproc->auto_boot) {
+ if (rproc->preloaded) {
+ /*
+* If rproc is marked already booted, no need to wait
+* for firmware.
+* Just handle associated resources and start sub devices
+*/
+ ret = rproc_boot(rproc);
+ if (ret < 0)
+ return ret;
+ } else if (rproc->auto_boot) {
+ /* if rproc is marked always-on, request it to boot */
ret = rproc_trigger_auto_boot(rproc);
if (ret < 0)
return ret;
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index b6660088949f..996404833a29 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -461,6 +461,7 @@ struct rproc_dump_segment {
* @recovery_disabled: flag that state if recovery was disabled
* @has_iommu: flag to indicate if remote processor is behind an MMU
* @auto_boot: flag to indicate if remote processor should be auto-started
+ * @preloaded: remote processor has been preloaded before start sequence
*/
struct rproc {
struct list_head node;
@@ -494,6 +495,7 @@ struct rproc {
u8 recovery_disabled;
u8 has_iommu;
u8 auto_boot;
+ u8 preloaded;
};
/**
--
2.7.4
[PATCH 1/2] remoteproc: replace bool from struct rproc by u8
Post [1] and checkpatch tool indicate that usage of bool type
in structure is now no more allowed/advised.
This patch replaces bool by unsigned char (u8) and reorders
struct rproc fields to avoid padding.
[1] https://lkml.org/lkml/2017/11/21/384
Signed-off-by: Loic Pallardy
---
include/linux/remoteproc.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 507a2b524208..b6660088949f 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -452,15 +452,15 @@ struct rproc_dump_segment {
* @index: index of this rproc device
* @crash_handler: workqueue for handling a crash
* @crash_cnt: crash counter
- * @recovery_disabled: flag that state if recovery was disabled
* @max_notifyid: largest allocated notify id.
* @table_ptr: pointer to the resource table in effect
* @cached_table: copy of the resource table
* @table_sz: size of @cached_table
- * @has_iommu: flag to indicate if remote processor is behind an MMU
- * @auto_boot: flag to indicate if remote processor should be auto-started
* @dump_segments: list of segments in the firmware
* @nb_vdev: number of vdev currently handled by rproc
+ * @recovery_disabled: flag that state if recovery was disabled
+ * @has_iommu: flag to indicate if remote processor is behind an MMU
+ * @auto_boot: flag to indicate if remote processor should be auto-started
*/
struct rproc {
struct list_head node;
@@ -485,15 +485,15 @@ struct rproc {
int index;
struct work_struct crash_handler;
unsigned int crash_cnt;
- bool recovery_disabled;
int max_notifyid;
struct resource_table *table_ptr;
struct resource_table *cached_table;
size_t table_sz;
- bool has_iommu;
- bool auto_boot;
struct list_head dump_segments;
int nb_vdev;
+ u8 recovery_disabled;
+ u8 has_iommu;
+ u8 auto_boot;
};
/**
--
2.7.4
[PATCH 1/2] remoteproc: replace bool from struct rproc by u8
Post [1] and checkpatch tool indicate that usage of bool type
in structure is now no more allowed/advised.
This patch replaces bool by unsigned char (u8) and reorders
struct rproc fields to avoid padding.
[1] https://lkml.org/lkml/2017/11/21/384
Signed-off-by: Loic Pallardy
---
include/linux/remoteproc.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 507a2b524208..b6660088949f 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -452,15 +452,15 @@ struct rproc_dump_segment {
* @index: index of this rproc device
* @crash_handler: workqueue for handling a crash
* @crash_cnt: crash counter
- * @recovery_disabled: flag that state if recovery was disabled
* @max_notifyid: largest allocated notify id.
* @table_ptr: pointer to the resource table in effect
* @cached_table: copy of the resource table
* @table_sz: size of @cached_table
- * @has_iommu: flag to indicate if remote processor is behind an MMU
- * @auto_boot: flag to indicate if remote processor should be auto-started
* @dump_segments: list of segments in the firmware
* @nb_vdev: number of vdev currently handled by rproc
+ * @recovery_disabled: flag that state if recovery was disabled
+ * @has_iommu: flag to indicate if remote processor is behind an MMU
+ * @auto_boot: flag to indicate if remote processor should be auto-started
*/
struct rproc {
struct list_head node;
@@ -485,15 +485,15 @@ struct rproc {
int index;
struct work_struct crash_handler;
unsigned int crash_cnt;
- bool recovery_disabled;
int max_notifyid;
struct resource_table *table_ptr;
struct resource_table *cached_table;
size_t table_sz;
- bool has_iommu;
- bool auto_boot;
struct list_head dump_segments;
int nb_vdev;
+ u8 recovery_disabled;
+ u8 has_iommu;
+ u8 auto_boot;
};
/**
--
2.7.4
RE: [PATCH v4 08/17] remoteproc: add alloc ops in rproc_mem_entry struct
> -Original Message-
> From: Suman Anna
> Sent: mardi 23 octobre 2018 23:20
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 08/17] remoteproc: add alloc ops in
> rproc_mem_entry struct
>
> Hi Loic,
>
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > Memory entry could be allocated in different ways (ioremap,
> > dma_alloc_coherent, internal RAM allocator...).
> > This patch introduces an alloc ops in rproc_mem_entry structure
> > to associate dedicated allocation mechanism to each memory entry
> > descriptor in order to do remote core agnostic from memory allocators.
> >
> > The introduction of this ops allows to perform allocation of all registered
> > carveout at the same time, just before calling rproc_start().
> > It simplifies and makes uniform carveout management whatever origin.
>
> This patch is causing a kernel crash with trace entries. Please see
> further below for the cause.
>
> >
> > Signed-off-by: Loic Pallardy
> > ---
> > drivers/remoteproc/remoteproc_core.c | 261
> ++-
> > include/linux/remoteproc.h | 7 +
> > 2 files changed, 175 insertions(+), 93 deletions(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> > index 77b39ba..2c51549 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -642,74 +642,31 @@ static int rproc_handle_devmem(struct rproc
> *rproc, struct fw_rsc_devmem *rsc,
> > }
> >
> > /**
> > - * rproc_release_carveout() - release acquired carveout
> > + * rproc_alloc_carveout() - allocated specified carveout
> > * @rproc: rproc handle
> > - * @mem: the memory entry to release
> > - *
> > - * This function releases specified memory entry @mem allocated via
> > - * dma_alloc_coherent() function by @rproc.
> > - */
> > -static int rproc_release_carveout(struct rproc *rproc,
> > - struct rproc_mem_entry *mem)
> > -{
> > - struct device *dev = >dev;
> > -
> > - /* clean up carveout allocations */
> > - dma_free_coherent(dev->parent, mem->len, mem->va, mem-
> >dma);
> > - return 0;
> > -}
> > -
> > -/**
> > - * rproc_handle_carveout() - handle phys contig memory allocation
> requests
> > - * @rproc: rproc handle
> > - * @rsc: the resource entry
> > - * @avail: size of available data (for image validation)
> > - *
> > - * This function will handle firmware requests for allocation of physically
> > - * contiguous memory regions.
> > - *
> > - * These request entries should come first in the firmware's resource
> table,
> > - * as other firmware entries might request placing other data objects
> inside
> > - * these memory regions (e.g. data/code segments, trace resource
> entries, ...).
> > + * @mem: the memory entry to allocate
> > *
> > - * Allocating memory this way helps utilizing the reserved physical memory
> > - * (e.g. CMA) more efficiently, and also minimizes the number of TLB
> entries
> > - * needed to map it (in case @rproc is using an IOMMU). Reducing the TLB
> > - * pressure is important; it may have a substantial impact on performance.
> > + * This function allocate specified memory entry @mem using
> > + * dma_alloc_coherent() as default allocator
> > */
> > -static int rproc_handle_carveout(struct rproc *rproc,
> > -struct fw_rsc_carveout *rsc,
> > -int offset, int avail)
> > +static int rproc_alloc_carveout(struct rproc *rproc,
> > + struct rproc_mem_entry *mem)
> > {
> > - struct rproc_mem_entry *carveout, *mapping = NULL;
> > + struct rproc_mem_entry *mapping = NULL;
> > struct device *dev = >dev;
> > dma_addr_t dma;
> > void *va;
> > int ret;
> >
> > - if (sizeof(*rsc) > avail) {
> > - dev_err(dev, "carveout rsc is truncated\n");
> > - return -EINVAL;
> > - }
> > -
> > - /* make sure reserved bytes are zeroes */
> > - if (rsc->reserved) {
> > - dev_err(dev, "carveout rsc has non zero reserved bytes\n");
> > - return -EINVAL;
> > - }
> > -
> > - dev_dbg(dev, "carveout rsc: name: %s
RE: [PATCH v4 08/17] remoteproc: add alloc ops in rproc_mem_entry struct
> -Original Message-
> From: Suman Anna
> Sent: mardi 23 octobre 2018 23:20
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 08/17] remoteproc: add alloc ops in
> rproc_mem_entry struct
>
> Hi Loic,
>
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > Memory entry could be allocated in different ways (ioremap,
> > dma_alloc_coherent, internal RAM allocator...).
> > This patch introduces an alloc ops in rproc_mem_entry structure
> > to associate dedicated allocation mechanism to each memory entry
> > descriptor in order to do remote core agnostic from memory allocators.
> >
> > The introduction of this ops allows to perform allocation of all registered
> > carveout at the same time, just before calling rproc_start().
> > It simplifies and makes uniform carveout management whatever origin.
>
> This patch is causing a kernel crash with trace entries. Please see
> further below for the cause.
>
> >
> > Signed-off-by: Loic Pallardy
> > ---
> > drivers/remoteproc/remoteproc_core.c | 261
> ++-
> > include/linux/remoteproc.h | 7 +
> > 2 files changed, 175 insertions(+), 93 deletions(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> > index 77b39ba..2c51549 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -642,74 +642,31 @@ static int rproc_handle_devmem(struct rproc
> *rproc, struct fw_rsc_devmem *rsc,
> > }
> >
> > /**
> > - * rproc_release_carveout() - release acquired carveout
> > + * rproc_alloc_carveout() - allocated specified carveout
> > * @rproc: rproc handle
> > - * @mem: the memory entry to release
> > - *
> > - * This function releases specified memory entry @mem allocated via
> > - * dma_alloc_coherent() function by @rproc.
> > - */
> > -static int rproc_release_carveout(struct rproc *rproc,
> > - struct rproc_mem_entry *mem)
> > -{
> > - struct device *dev = >dev;
> > -
> > - /* clean up carveout allocations */
> > - dma_free_coherent(dev->parent, mem->len, mem->va, mem-
> >dma);
> > - return 0;
> > -}
> > -
> > -/**
> > - * rproc_handle_carveout() - handle phys contig memory allocation
> requests
> > - * @rproc: rproc handle
> > - * @rsc: the resource entry
> > - * @avail: size of available data (for image validation)
> > - *
> > - * This function will handle firmware requests for allocation of physically
> > - * contiguous memory regions.
> > - *
> > - * These request entries should come first in the firmware's resource
> table,
> > - * as other firmware entries might request placing other data objects
> inside
> > - * these memory regions (e.g. data/code segments, trace resource
> entries, ...).
> > + * @mem: the memory entry to allocate
> > *
> > - * Allocating memory this way helps utilizing the reserved physical memory
> > - * (e.g. CMA) more efficiently, and also minimizes the number of TLB
> entries
> > - * needed to map it (in case @rproc is using an IOMMU). Reducing the TLB
> > - * pressure is important; it may have a substantial impact on performance.
> > + * This function allocate specified memory entry @mem using
> > + * dma_alloc_coherent() as default allocator
> > */
> > -static int rproc_handle_carveout(struct rproc *rproc,
> > -struct fw_rsc_carveout *rsc,
> > -int offset, int avail)
> > +static int rproc_alloc_carveout(struct rproc *rproc,
> > + struct rproc_mem_entry *mem)
> > {
> > - struct rproc_mem_entry *carveout, *mapping = NULL;
> > + struct rproc_mem_entry *mapping = NULL;
> > struct device *dev = >dev;
> > dma_addr_t dma;
> > void *va;
> > int ret;
> >
> > - if (sizeof(*rsc) > avail) {
> > - dev_err(dev, "carveout rsc is truncated\n");
> > - return -EINVAL;
> > - }
> > -
> > - /* make sure reserved bytes are zeroes */
> > - if (rsc->reserved) {
> > - dev_err(dev, "carveout rsc has non zero reserved bytes\n");
> > - return -EINVAL;
> > - }
> > -
> > - dev_dbg(dev, "carveout rsc: name: %s
RE: [PATCH v4 10/17] remoteproc: add helper function to check carveout device address
Hi Suman,
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 00:14
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 10/17] remoteproc: add helper function to check
> carveout device address
>
> Hi Loic,
>
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > This patch introduces a function to verify that a specified carveout
> > is fitting request device address and associated length
> >
> > Signed-off-by: Loic Pallardy
> > ---
> > drivers/remoteproc/remoteproc_core.c | 47
>
> > 1 file changed, 47 insertions(+)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> > index 1e0fe3e..5dd5edf 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -259,6 +259,53 @@ struct rproc_mem_entry *
> > return mem;
> > }
> >
> > +/**
> > + * rproc_check_carveout_da() - Check specified carveout da configuration
> > + * @rproc: handle of a remote processor
> > + * @mem: pointer on carveout to check
> > + * @da: area device address
> > + * @len: associated area size
> > + *
> > + * This function is a helper function to verify requested device area
> (couple
> > + * da, len) is part of specified carevout.
>
> %s/carevout/carveout/
OK
>
> > + *
> > + * Return: 0 if carveout matchs request else -ENOMEM
>
> %s/matchs/matches/
OK
>
> > + */
> > +int rproc_check_carveout_da(struct rproc *rproc, struct
> rproc_mem_entry *mem,
>
> static int since this seems to be only a local function.
OK
>
> > + u32 da, u32 len)
> > +{
> > + struct device *dev = >dev;
> > + int delta = 0;
> > +
> > + /* Check requested resource length */
> > + if (len > mem->len) {
> > + dev_err(dev, "Registered carveout doesn't fit len
> request\n");
> > + return -ENOMEM;
>
> ENOMEM not typically used for these kind of errors, you were probably
> inclined to used this since it is dealing with memory.
-EINVAL will be better
>
> > + }
> > +
>
> Both the below codepaths are exercised only when da is not
> FW_RSC_ADDR_ANY, and you are returning 0 otherwise (which is the case of
> matches as per your description above). Is that what you really want -
> should it be an error
Yes when da is equal to FW_RSC_ADDR_ANY we should check the length too
>
> > + if (da != FW_RSC_ADDR_ANY && mem->da == FW_RSC_ADDR_ANY)
> {
> > + /* Update existing carveout da */
> > + mem->da = da;
>
> Where would you need to update this?
In that case, we have 2 carveouts with the same name.
One has some fixed requests. The other one has none.
The goal here is to align both on the one which has the strongest requirements.
I think length is missing.
Regards,
Loic
>
> regards
> Suman
>
> > + } else if (da != FW_RSC_ADDR_ANY && mem->da !=
> FW_RSC_ADDR_ANY) {
> > + delta = da - mem->da;
> > +
> > + /* Check requested resource belongs to registered carveout
> */
> > + if (delta < 0) {
> > + dev_err(dev,
> > + "Registered carveout doesn't fit da
> request\n");
> > + return -ENOMEM;
> > + }
> > +
> > + if (delta + len > mem->len) {
> > + dev_err(dev,
> > + "Registered carveout doesn't fit len
> request\n");
> > + return -ENOMEM;
> > + }
> > + }
> > +
> > + return 0;
>
>
> > +}
> > +
> > int rproc_alloc_vring(struct rproc_vdev *rvdev, int i)
> > {
> > struct rproc *rproc = rvdev->rproc;
> >
RE: [PATCH v4 10/17] remoteproc: add helper function to check carveout device address
Hi Suman,
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 00:14
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 10/17] remoteproc: add helper function to check
> carveout device address
>
> Hi Loic,
>
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > This patch introduces a function to verify that a specified carveout
> > is fitting request device address and associated length
> >
> > Signed-off-by: Loic Pallardy
> > ---
> > drivers/remoteproc/remoteproc_core.c | 47
>
> > 1 file changed, 47 insertions(+)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> > index 1e0fe3e..5dd5edf 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -259,6 +259,53 @@ struct rproc_mem_entry *
> > return mem;
> > }
> >
> > +/**
> > + * rproc_check_carveout_da() - Check specified carveout da configuration
> > + * @rproc: handle of a remote processor
> > + * @mem: pointer on carveout to check
> > + * @da: area device address
> > + * @len: associated area size
> > + *
> > + * This function is a helper function to verify requested device area
> (couple
> > + * da, len) is part of specified carevout.
>
> %s/carevout/carveout/
OK
>
> > + *
> > + * Return: 0 if carveout matchs request else -ENOMEM
>
> %s/matchs/matches/
OK
>
> > + */
> > +int rproc_check_carveout_da(struct rproc *rproc, struct
> rproc_mem_entry *mem,
>
> static int since this seems to be only a local function.
OK
>
> > + u32 da, u32 len)
> > +{
> > + struct device *dev = >dev;
> > + int delta = 0;
> > +
> > + /* Check requested resource length */
> > + if (len > mem->len) {
> > + dev_err(dev, "Registered carveout doesn't fit len
> request\n");
> > + return -ENOMEM;
>
> ENOMEM not typically used for these kind of errors, you were probably
> inclined to used this since it is dealing with memory.
-EINVAL will be better
>
> > + }
> > +
>
> Both the below codepaths are exercised only when da is not
> FW_RSC_ADDR_ANY, and you are returning 0 otherwise (which is the case of
> matches as per your description above). Is that what you really want -
> should it be an error
Yes when da is equal to FW_RSC_ADDR_ANY we should check the length too
>
> > + if (da != FW_RSC_ADDR_ANY && mem->da == FW_RSC_ADDR_ANY)
> {
> > + /* Update existing carveout da */
> > + mem->da = da;
>
> Where would you need to update this?
In that case, we have 2 carveouts with the same name.
One has some fixed requests. The other one has none.
The goal here is to align both on the one which has the strongest requirements.
I think length is missing.
Regards,
Loic
>
> regards
> Suman
>
> > + } else if (da != FW_RSC_ADDR_ANY && mem->da !=
> FW_RSC_ADDR_ANY) {
> > + delta = da - mem->da;
> > +
> > + /* Check requested resource belongs to registered carveout
> */
> > + if (delta < 0) {
> > + dev_err(dev,
> > + "Registered carveout doesn't fit da
> request\n");
> > + return -ENOMEM;
> > + }
> > +
> > + if (delta + len > mem->len) {
> > + dev_err(dev,
> > + "Registered carveout doesn't fit len
> request\n");
> > + return -ENOMEM;
> > + }
> > + }
> > +
> > + return 0;
>
>
> > +}
> > +
> > int rproc_alloc_vring(struct rproc_vdev *rvdev, int i)
> > {
> > struct rproc *rproc = rvdev->rproc;
> >
RE: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on centralized carveout allocator
Hi Suman,
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 02:14
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on
> centralized carveout allocator
>
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > Current version of rproc_alloc_vring function supports only dynamic vring
> > allocation.
> >
> > This patch allows to allocate vrings based on memory region declatation.
> > Vrings are now manage like memory carveouts, to communize memory
> management
> > code in rproc_alloc_registered_carveouts().
> >
> > Allocated buffer is retrieved in rp_find_vq() thanks to
> > rproc_find_carveout_by_name() functions for.
> >
> > This patch sets vrings names to vdev"x"vring"y" with x vdev index in
> > resource table and y vring index in vdev. This will be updated when
> > name will be associated to vdev in firmware resource table.
> >
> > Signed-off-by: Loic Pallardy
> > ---
> > drivers/remoteproc/remoteproc_core.c | 61 +--
> -
> > drivers/remoteproc/remoteproc_internal.h | 2 ++
> > drivers/remoteproc/remoteproc_virtio.c | 14 +++-
> > include/linux/remoteproc.h | 6 ++--
> > 4 files changed, 51 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> > index c543d04..4edc6f0 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -53,6 +53,11 @@ typedef int (*rproc_handle_resources_t)(struct
> rproc *rproc,
> > typedef int (*rproc_handle_resource_t)(struct rproc *rproc,
> > void *, int offset, int avail);
> >
> > +static int rproc_alloc_carveout(struct rproc *rproc,
> > + struct rproc_mem_entry *mem);
> > +static int rproc_release_carveout(struct rproc *rproc,
> > + struct rproc_mem_entry *mem);
> > +
> > /* Unique indices for remoteproc devices */
> > static DEFINE_IDA(rproc_dev_index);
> >
> > @@ -312,21 +317,33 @@ int rproc_alloc_vring(struct rproc_vdev *rvdev,
> int i)
> > struct device *dev = >dev;
> > struct rproc_vring *rvring = >vring[i];
> > struct fw_rsc_vdev *rsc;
> > - dma_addr_t dma;
> > - void *va;
> > int ret, size, notifyid;
> > + struct rproc_mem_entry *mem;
> >
> > /* actual size of vring (in bytes) */
> > size = PAGE_ALIGN(vring_size(rvring->len, rvring->align));
> >
> > - /*
> > -* Allocate non-cacheable memory for the vring. In the future
> > -* this call will also configure the IOMMU for us
> > -*/
> > - va = dma_alloc_coherent(dev->parent, size, , GFP_KERNEL);
> > - if (!va) {
> > - dev_err(dev->parent, "dma_alloc_coherent failed\n");
> > - return -EINVAL;
> > + rsc = (void *)rproc->table_ptr + rvdev->rsc_offset;
> > +
> > + /* Search for pre-registered carveout */
> > + mem = rproc_find_carveout_by_name(rproc, "vdev%dvring%d",
> rvdev->index,
> > + i);
> > + if (mem) {
> > + if (rproc_check_carveout_da(rproc, mem, rsc->vring[i].da,
> size))
> > + return -ENOMEM;
> > + } else {
> > + /* Register carveout in in list */
> > + mem = rproc_mem_entry_init(dev, 0, 0, size, rsc-
> >vring[i].da,
> > + rproc_alloc_carveout,
> > + rproc_release_carveout,
> > + "vdev%dvring%d",
> > + rvdev->index, i);
> > + if (!mem) {
> > + dev_err(dev, "Can't allocate memory entry
> structure\n");
> > + return -ENOMEM;
> > + }
> > +
> > + rproc_add_carveout(rproc, mem);
> > }
> >
> > /*
> > @@ -337,7 +354,6 @@ int rproc_alloc_vring(struct rproc_vdev *rvdev, int i)
> > ret = idr_alloc(>notifyids, rvring, 0, 0, GFP_KERNEL);
> > if (ret < 0) {
> > dev_err(dev, "idr_alloc failed: %d\n", ret);
> > - dma_free
RE: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on centralized carveout allocator
Hi Suman,
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 02:14
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on
> centralized carveout allocator
>
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > Current version of rproc_alloc_vring function supports only dynamic vring
> > allocation.
> >
> > This patch allows to allocate vrings based on memory region declatation.
> > Vrings are now manage like memory carveouts, to communize memory
> management
> > code in rproc_alloc_registered_carveouts().
> >
> > Allocated buffer is retrieved in rp_find_vq() thanks to
> > rproc_find_carveout_by_name() functions for.
> >
> > This patch sets vrings names to vdev"x"vring"y" with x vdev index in
> > resource table and y vring index in vdev. This will be updated when
> > name will be associated to vdev in firmware resource table.
> >
> > Signed-off-by: Loic Pallardy
> > ---
> > drivers/remoteproc/remoteproc_core.c | 61 +--
> -
> > drivers/remoteproc/remoteproc_internal.h | 2 ++
> > drivers/remoteproc/remoteproc_virtio.c | 14 +++-
> > include/linux/remoteproc.h | 6 ++--
> > 4 files changed, 51 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> > index c543d04..4edc6f0 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -53,6 +53,11 @@ typedef int (*rproc_handle_resources_t)(struct
> rproc *rproc,
> > typedef int (*rproc_handle_resource_t)(struct rproc *rproc,
> > void *, int offset, int avail);
> >
> > +static int rproc_alloc_carveout(struct rproc *rproc,
> > + struct rproc_mem_entry *mem);
> > +static int rproc_release_carveout(struct rproc *rproc,
> > + struct rproc_mem_entry *mem);
> > +
> > /* Unique indices for remoteproc devices */
> > static DEFINE_IDA(rproc_dev_index);
> >
> > @@ -312,21 +317,33 @@ int rproc_alloc_vring(struct rproc_vdev *rvdev,
> int i)
> > struct device *dev = >dev;
> > struct rproc_vring *rvring = >vring[i];
> > struct fw_rsc_vdev *rsc;
> > - dma_addr_t dma;
> > - void *va;
> > int ret, size, notifyid;
> > + struct rproc_mem_entry *mem;
> >
> > /* actual size of vring (in bytes) */
> > size = PAGE_ALIGN(vring_size(rvring->len, rvring->align));
> >
> > - /*
> > -* Allocate non-cacheable memory for the vring. In the future
> > -* this call will also configure the IOMMU for us
> > -*/
> > - va = dma_alloc_coherent(dev->parent, size, , GFP_KERNEL);
> > - if (!va) {
> > - dev_err(dev->parent, "dma_alloc_coherent failed\n");
> > - return -EINVAL;
> > + rsc = (void *)rproc->table_ptr + rvdev->rsc_offset;
> > +
> > + /* Search for pre-registered carveout */
> > + mem = rproc_find_carveout_by_name(rproc, "vdev%dvring%d",
> rvdev->index,
> > + i);
> > + if (mem) {
> > + if (rproc_check_carveout_da(rproc, mem, rsc->vring[i].da,
> size))
> > + return -ENOMEM;
> > + } else {
> > + /* Register carveout in in list */
> > + mem = rproc_mem_entry_init(dev, 0, 0, size, rsc-
> >vring[i].da,
> > + rproc_alloc_carveout,
> > + rproc_release_carveout,
> > + "vdev%dvring%d",
> > + rvdev->index, i);
> > + if (!mem) {
> > + dev_err(dev, "Can't allocate memory entry
> structure\n");
> > + return -ENOMEM;
> > + }
> > +
> > + rproc_add_carveout(rproc, mem);
> > }
> >
> > /*
> > @@ -337,7 +354,6 @@ int rproc_alloc_vring(struct rproc_vdev *rvdev, int i)
> > ret = idr_alloc(>notifyids, rvring, 0, 0, GFP_KERNEL);
> > if (ret < 0) {
> > dev_err(dev, "idr_alloc failed: %d\n", ret);
> > - dma_free
RE: [PATCH v4 15/17] remoteproc: da8xx: declare reserved memory region for vdev device
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 04:58
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 15/17] remoteproc: da8xx: declare reserved memory
> region for vdev device
>
> Hi Loic,
>
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > This patch introduces da8xx_rproc_parse_fw() to declare a
> > carveout region based on reserved memory for vdev buffer
> > allocation.
> >
> > Signed-off-by: Loic Pallardy
> > ---
> > drivers/remoteproc/da8xx_remoteproc.c | 38
> +++
> > 1 file changed, 38 insertions(+)
> >
> > diff --git a/drivers/remoteproc/da8xx_remoteproc.c
> b/drivers/remoteproc/da8xx_remoteproc.c
> > index b668e32..679a076 100644
> > --- a/drivers/remoteproc/da8xx_remoteproc.c
> > +++ b/drivers/remoteproc/da8xx_remoteproc.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -179,10 +180,47 @@ static void da8xx_rproc_kick(struct rproc *rproc,
> int vqid)
> > writel(SYSCFG_CHIPSIG2, drproc->chipsig);
> > }
> >
> > +static int da8xx_rproc_parse_fw(struct rproc *rproc, const struct firmware
> *fw)
> > +{
> > + struct device *dev = rproc->dev.parent;
> > + struct rproc_mem_entry *mem;
> > + struct device_node *node;
> > + struct resource res;
> > + int err;
> > +
> > + node = of_parse_phandle(dev->of_node, "memory-region", 0);
> > + if (!node) {
> > + dev_err(dev, "No memory-region specified\n");
> > + return -EINVAL;
> > + }
> > +
> > + err = of_address_to_resource(node, 0, );
> > + if (err) {
> > + dev_err(dev, "Bad memory-region definition\n");
> > + return err;
> > + }
> > +
> > + /* Register memory region for vdev buffer allocation */
> > + mem = rproc_of_resm_mem_entry_init(dev, 0,
> resource_size(),
> > + res.start, "vdev0buffer");> +
> > + if (!mem)
> > + return -ENOMEM;
> > +
> > + rproc_add_carveout(rproc, mem);
> > +
> > + return rproc_elf_load_rsc_table(rproc, fw);
> > +}
>
> Thanks for the patch, but this creates a kernel crash for me due to
> overlaps with manually created carveouts. I currently have a single
> memory-region and all allocations come from the same DMA pool, but the
> rproc_of_resm_mem_entry_init() creates an overall mem entry without the
> va being set (no alloc function plumbed in). In general, it is permitted
> to use the same reserved-memory node with multiple devices, so the index
> usage should have allowed it to do DMA allocations with vdev devices,
> but the loading is performed even before the vdev allocations and the
> da_to_va matches the first entry with no va set causing the crash.
Hummm, I didn't fall in this case, but clearly da_to_va should not crashed.
Not allocated carveout should be bypassed in the loop. Thanks for pointing
this. I need to fix it.
The rproc_of_resm_mem_entry_init() is simply registering the reserved memory to
be attached to vdev device.
So that normal it won't be allocated by rproc core (there is no alloc/free
function specificied in this helper).
Regards,
Loic
>
> Here's my debugfs output of the carveout_memories for reference,
>
> Carveout memory entry:
> Name: vdev0buffer
> Virtual address:
> DMA address: 0x
> Device address: 0xc300
> Length: 0x100 Bytes
>
> Carveout memory entry:
> Name: vdev0vring0
> Virtual address: c300
> DMA address: 0xc300
> Device address: 0xc300
> Length: 0x3000 Bytes
>
> Carveout memory entry:
> Name: vdev0vring1
> Virtual address: c3004000
> DMA address: 0xc3004000
> Device address: 0xc3004000
> Length: 0x3000 Bytes
>
> Carveout memory entry:
> Name: DSP_MEM_DATA
> Virtual address: c310
> DMA address: 0xc310
> Device address: 0xc310
> Length: 0xf0 Bytes
>
> You can drop both this patch and the keystone_remoteproc patch from the
> series. I did not run into any issues there since I did not have any
> RSC_CARVEOUT entries there. Also, see my comments on the next patch
> (the
> chang
RE: [PATCH v4 15/17] remoteproc: da8xx: declare reserved memory region for vdev device
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 04:58
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 15/17] remoteproc: da8xx: declare reserved memory
> region for vdev device
>
> Hi Loic,
>
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > This patch introduces da8xx_rproc_parse_fw() to declare a
> > carveout region based on reserved memory for vdev buffer
> > allocation.
> >
> > Signed-off-by: Loic Pallardy
> > ---
> > drivers/remoteproc/da8xx_remoteproc.c | 38
> +++
> > 1 file changed, 38 insertions(+)
> >
> > diff --git a/drivers/remoteproc/da8xx_remoteproc.c
> b/drivers/remoteproc/da8xx_remoteproc.c
> > index b668e32..679a076 100644
> > --- a/drivers/remoteproc/da8xx_remoteproc.c
> > +++ b/drivers/remoteproc/da8xx_remoteproc.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -179,10 +180,47 @@ static void da8xx_rproc_kick(struct rproc *rproc,
> int vqid)
> > writel(SYSCFG_CHIPSIG2, drproc->chipsig);
> > }
> >
> > +static int da8xx_rproc_parse_fw(struct rproc *rproc, const struct firmware
> *fw)
> > +{
> > + struct device *dev = rproc->dev.parent;
> > + struct rproc_mem_entry *mem;
> > + struct device_node *node;
> > + struct resource res;
> > + int err;
> > +
> > + node = of_parse_phandle(dev->of_node, "memory-region", 0);
> > + if (!node) {
> > + dev_err(dev, "No memory-region specified\n");
> > + return -EINVAL;
> > + }
> > +
> > + err = of_address_to_resource(node, 0, );
> > + if (err) {
> > + dev_err(dev, "Bad memory-region definition\n");
> > + return err;
> > + }
> > +
> > + /* Register memory region for vdev buffer allocation */
> > + mem = rproc_of_resm_mem_entry_init(dev, 0,
> resource_size(),
> > + res.start, "vdev0buffer");> +
> > + if (!mem)
> > + return -ENOMEM;
> > +
> > + rproc_add_carveout(rproc, mem);
> > +
> > + return rproc_elf_load_rsc_table(rproc, fw);
> > +}
>
> Thanks for the patch, but this creates a kernel crash for me due to
> overlaps with manually created carveouts. I currently have a single
> memory-region and all allocations come from the same DMA pool, but the
> rproc_of_resm_mem_entry_init() creates an overall mem entry without the
> va being set (no alloc function plumbed in). In general, it is permitted
> to use the same reserved-memory node with multiple devices, so the index
> usage should have allowed it to do DMA allocations with vdev devices,
> but the loading is performed even before the vdev allocations and the
> da_to_va matches the first entry with no va set causing the crash.
Hummm, I didn't fall in this case, but clearly da_to_va should not crashed.
Not allocated carveout should be bypassed in the loop. Thanks for pointing
this. I need to fix it.
The rproc_of_resm_mem_entry_init() is simply registering the reserved memory to
be attached to vdev device.
So that normal it won't be allocated by rproc core (there is no alloc/free
function specificied in this helper).
Regards,
Loic
>
> Here's my debugfs output of the carveout_memories for reference,
>
> Carveout memory entry:
> Name: vdev0buffer
> Virtual address:
> DMA address: 0x
> Device address: 0xc300
> Length: 0x100 Bytes
>
> Carveout memory entry:
> Name: vdev0vring0
> Virtual address: c300
> DMA address: 0xc300
> Device address: 0xc300
> Length: 0x3000 Bytes
>
> Carveout memory entry:
> Name: vdev0vring1
> Virtual address: c3004000
> DMA address: 0xc3004000
> Device address: 0xc3004000
> Length: 0x3000 Bytes
>
> Carveout memory entry:
> Name: DSP_MEM_DATA
> Virtual address: c310
> DMA address: 0xc310
> Device address: 0xc310
> Length: 0xf0 Bytes
>
> You can drop both this patch and the keystone_remoteproc patch from the
> series. I did not run into any issues there since I did not have any
> RSC_CARVEOUT entries there. Also, see my comments on the next patch
> (the
> chang
RE: [PATCH v4 02/17] remoteproc: add rproc_va_to_pa function
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 05:19
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 02/17] remoteproc: add rproc_va_to_pa function
>
> On 10/23/18 2:51 PM, Loic PALLARDY wrote:
> > Hi Suman,
> >
> >> -Original Message-
> >> From: Suman Anna
> >> Sent: mardi 23 octobre 2018 18:51
> >> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> >> o...@wizery.com
> >> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> Arnaud POULIQUEN ;
> >> benjamin.gaign...@linaro.org
> >> Subject: Re: [PATCH v4 02/17] remoteproc: add rproc_va_to_pa function
> >>
> >> Hi Loic, Bjorn,
> >>
> >> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> >>> This new function translates CPU virtual address in
> >>> CPU physical one according to virtual address location.
> >>>
> >>> Signed-off-by: Loic Pallardy
> >>> Acked-by: Bjorn Andersson
> >>> ---
> >>> drivers/remoteproc/remoteproc_core.c | 18 +-
> >>> 1 file changed, 17 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/remoteproc/remoteproc_core.c
> >> b/drivers/remoteproc/remoteproc_core.c
> >>> index 437fabf..8e5fe1e 100644
> >>> --- a/drivers/remoteproc/remoteproc_core.c
> >>> +++ b/drivers/remoteproc/remoteproc_core.c
> >>> @@ -140,6 +140,22 @@ static void rproc_disable_iommu(struct rproc
> >> *rproc)
> >>> iommu_domain_free(domain);
> >>> }
> >>>
> >>> +static phys_addr_t rproc_va_to_pa(void *cpu_addr)
> >>> +{
> >>> + /*
> >>> + * Return physical address according to virtual address location
> >>> + * - in vmalloc: if region ioremapped or defined as
> >> dma_alloc_coherent
> >>> + * - in kernel: if region allocated in generic dma memory pool
> >>> + */
> >>> + if (is_vmalloc_addr(cpu_addr)) {
> >>> + return page_to_phys(vmalloc_to_page(cpu_addr)) +
> >>> + offset_in_page(cpu_addr);
> >>> + }
> >>> +
> >>> + WARN_ON(!virt_addr_valid(cpu_addr));
> >>> + return virt_to_phys(cpu_addr);
> >>> +}
> >>> +
> >>> /**
> >>> * rproc_da_to_va() - lookup the kernel virtual address for a remoteproc
> >> address
> >>> * @rproc: handle of a remote processor
> >>> @@ -711,7 +727,7 @@ static int rproc_handle_carveout(struct rproc
> >> *rproc,
> >>>* In this case, the device address and the physical address
> >>>* are the same.
> >>>*/
> >>> - rsc->pa = dma;
> >>> + rsc->pa = (u32)rproc_va_to_pa(va);
> >>
> >> While I agree with the direction here, we ought to add a check here
> >> warning users if some address bits are getting lost as a result of the
> >> typecast. Granted the issue may have been present previously with
> >> dma_addr_t as well, but most platforms were using 32-bit dma addresses,
> >> so this was kinda masked. There are ARMv7 platforms with LPAE enabled
> >> allowing physical addresses > 32-bits.
> >>
> >> In anycase, we definitely have a need for a v2 for the fw_rsc_carveout
> >> structure to deal with 64-bit addresses.
> >>
> >
> > Agree with you.
> > Assumption for this series was to keep resource table as it is. Resource
> table improvement is planned in a second step.
>
> Perhaps, we should add a WARN_ON for the time being until we enhance
> the
> resource table for 64-bit platforms/addresses.
OK I will propose a patch to add WARN_ON on cast applied on resource table field
Regards,
Loic
>
> regards
> Suman
>
> > Regards,
> > Loic
> >
> >> regards
> >> Suman
> >>
> >>>
> >>> carveout->va = va;
> >>> carveout->len = rsc->len;
> >>>
> >
RE: [PATCH v4 02/17] remoteproc: add rproc_va_to_pa function
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 05:19
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 02/17] remoteproc: add rproc_va_to_pa function
>
> On 10/23/18 2:51 PM, Loic PALLARDY wrote:
> > Hi Suman,
> >
> >> -Original Message-
> >> From: Suman Anna
> >> Sent: mardi 23 octobre 2018 18:51
> >> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> >> o...@wizery.com
> >> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> Arnaud POULIQUEN ;
> >> benjamin.gaign...@linaro.org
> >> Subject: Re: [PATCH v4 02/17] remoteproc: add rproc_va_to_pa function
> >>
> >> Hi Loic, Bjorn,
> >>
> >> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> >>> This new function translates CPU virtual address in
> >>> CPU physical one according to virtual address location.
> >>>
> >>> Signed-off-by: Loic Pallardy
> >>> Acked-by: Bjorn Andersson
> >>> ---
> >>> drivers/remoteproc/remoteproc_core.c | 18 +-
> >>> 1 file changed, 17 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/remoteproc/remoteproc_core.c
> >> b/drivers/remoteproc/remoteproc_core.c
> >>> index 437fabf..8e5fe1e 100644
> >>> --- a/drivers/remoteproc/remoteproc_core.c
> >>> +++ b/drivers/remoteproc/remoteproc_core.c
> >>> @@ -140,6 +140,22 @@ static void rproc_disable_iommu(struct rproc
> >> *rproc)
> >>> iommu_domain_free(domain);
> >>> }
> >>>
> >>> +static phys_addr_t rproc_va_to_pa(void *cpu_addr)
> >>> +{
> >>> + /*
> >>> + * Return physical address according to virtual address location
> >>> + * - in vmalloc: if region ioremapped or defined as
> >> dma_alloc_coherent
> >>> + * - in kernel: if region allocated in generic dma memory pool
> >>> + */
> >>> + if (is_vmalloc_addr(cpu_addr)) {
> >>> + return page_to_phys(vmalloc_to_page(cpu_addr)) +
> >>> + offset_in_page(cpu_addr);
> >>> + }
> >>> +
> >>> + WARN_ON(!virt_addr_valid(cpu_addr));
> >>> + return virt_to_phys(cpu_addr);
> >>> +}
> >>> +
> >>> /**
> >>> * rproc_da_to_va() - lookup the kernel virtual address for a remoteproc
> >> address
> >>> * @rproc: handle of a remote processor
> >>> @@ -711,7 +727,7 @@ static int rproc_handle_carveout(struct rproc
> >> *rproc,
> >>>* In this case, the device address and the physical address
> >>>* are the same.
> >>>*/
> >>> - rsc->pa = dma;
> >>> + rsc->pa = (u32)rproc_va_to_pa(va);
> >>
> >> While I agree with the direction here, we ought to add a check here
> >> warning users if some address bits are getting lost as a result of the
> >> typecast. Granted the issue may have been present previously with
> >> dma_addr_t as well, but most platforms were using 32-bit dma addresses,
> >> so this was kinda masked. There are ARMv7 platforms with LPAE enabled
> >> allowing physical addresses > 32-bits.
> >>
> >> In anycase, we definitely have a need for a v2 for the fw_rsc_carveout
> >> structure to deal with 64-bit addresses.
> >>
> >
> > Agree with you.
> > Assumption for this series was to keep resource table as it is. Resource
> table improvement is planned in a second step.
>
> Perhaps, we should add a WARN_ON for the time being until we enhance
> the
> resource table for 64-bit platforms/addresses.
OK I will propose a patch to add WARN_ON on cast applied on resource table field
Regards,
Loic
>
> regards
> Suman
>
> > Regards,
> > Loic
> >
> >> regards
> >> Suman
> >>
> >>>
> >>> carveout->va = va;
> >>> carveout->len = rsc->len;
> >>>
> >
RE: [PATCH v4 01/17] remoteproc: configure IOMMU only if device address requested
> -Original Message- > From: Suman Anna > Sent: mercredi 24 octobre 2018 05:47 > To: Loic PALLARDY ; bjorn.anders...@linaro.org; > o...@wizery.com > Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; > Arnaud POULIQUEN ; > benjamin.gaign...@linaro.org > Subject: Re: [PATCH v4 01/17] remoteproc: configure IOMMU only if device > address requested > > On 10/23/18 2:40 PM, Loic PALLARDY wrote: > > Hi Suman, > > > >> -Original Message- > >> From: Suman Anna > >> Sent: mardi 23 octobre 2018 19:26 > >> To: Loic PALLARDY ; bjorn.anders...@linaro.org; > >> o...@wizery.com > >> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; > >> Arnaud POULIQUEN ; > >> benjamin.gaign...@linaro.org > >> Subject: Re: [PATCH v4 01/17] remoteproc: configure IOMMU only if > device > >> address requested > >> > >> Hi Loic, > >> > >> On 7/27/18 8:14 AM, Loic Pallardy wrote: > >>> If there is no IOMMU associate to remote processor device, > >>> remoteproc_core won't be able to satisfy device address requested > >>> in firmware resource table. > >>> Return an error as configuration won't be coherent. > >>> > >>> Signed-off-by: Loic Pallardy > >> > >> This patch is breaking my Davinci platforms. It is not really required > >> that you _should_ have IOMMUs when a valid DA is mentioned. Please > see > >> the existing description (paras 4 and 5) on the fw_rsc_carveout > >> kerneldoc in remoteproc.h file. > > > > Thanks for pointing this comment. Indeed sMMU is not mandatory, and at > first sight I agree we should remove the restriction introduced by the patch. > > Driver porting on the series should be done before adding this. > >> > >> We do have platforms where we have some internal sub-modules within > the > >> remote processor sub-system that provides some linear > >> address-translation (most common case with 32-bit processors supporting > >> 64-bit addresses). Also, we have some upcoming SoCs where we have an > >> MMU > >> but is not programmable by Linux. > >> > >> There is one comment there, but I don't think this is actually handled > >> in the current remoteproc core. > >> "If @da is set to > >> * FW_RSC_ADDR_ANY, then the host will dynamically allocate it, and > then > >> * overwrite @da with the dynamically allocated address." > >> > > I don't remember it was implemented like described. > > Yes, it was missing, and one of your patches seem to add this behavior > now. That said, I really don't think the remoteproc core can dictate the > da. Even if the individual remoteproc driver were to furnish this, how > would you get such data without forcing a fixed behavior for all > possible firmwares (not desirable). We should get rid of this comment, > and any code that seems to do this. Agree that if some rules are fixed by firmware, rproc core can't overwrite them. It was the goal of the patch as without sMMU if you don't have a match between rproc core carveout allocation and firmware rsc request, rproc core can't answer the request. In the rest of the series, da in rsc table is updated only in some specific cases (i.e. da is equal to FW_RSC_ADDR_ANY). If there is a force update I agree we should not allow it. > > > > > I have remarks about the comment: > > "* We will always use @da to negotiate the device addresses, even if it > > * isn't using an iommu. In that case, though, it will obviously contain > > * physical addresses." > > > > When there is no sMMU, we can't consider that da contains a physical > address because coprocessor can have its own memory map just because it > is a 32bit processor accessing only a part of the memory and the main is 64bit > one. The 2 processors won't see the internal memory at the same base > address for example. > > Agreed, believe it was valid when it was written (32-bit platforms > supporting 32-bit addresses). I think this is akin to an IPA > (Intermediate Physical Address). > > > So what should we do when carveout allocated by host is not fitting with > resource table request? > > - put a warning and overwrite da address in the resource table? > > Hmm, why da? This goes to my earlier comment about how you are able to > decide the da. Atleast your current ST driver seems to be assigning the > same value as the physical bus address for da, which would prompt why > you would still need a carveout entry in the resource table if it is
RE: [PATCH v4 01/17] remoteproc: configure IOMMU only if device address requested
> -Original Message- > From: Suman Anna > Sent: mercredi 24 octobre 2018 05:47 > To: Loic PALLARDY ; bjorn.anders...@linaro.org; > o...@wizery.com > Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; > Arnaud POULIQUEN ; > benjamin.gaign...@linaro.org > Subject: Re: [PATCH v4 01/17] remoteproc: configure IOMMU only if device > address requested > > On 10/23/18 2:40 PM, Loic PALLARDY wrote: > > Hi Suman, > > > >> -Original Message- > >> From: Suman Anna > >> Sent: mardi 23 octobre 2018 19:26 > >> To: Loic PALLARDY ; bjorn.anders...@linaro.org; > >> o...@wizery.com > >> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; > >> Arnaud POULIQUEN ; > >> benjamin.gaign...@linaro.org > >> Subject: Re: [PATCH v4 01/17] remoteproc: configure IOMMU only if > device > >> address requested > >> > >> Hi Loic, > >> > >> On 7/27/18 8:14 AM, Loic Pallardy wrote: > >>> If there is no IOMMU associate to remote processor device, > >>> remoteproc_core won't be able to satisfy device address requested > >>> in firmware resource table. > >>> Return an error as configuration won't be coherent. > >>> > >>> Signed-off-by: Loic Pallardy > >> > >> This patch is breaking my Davinci platforms. It is not really required > >> that you _should_ have IOMMUs when a valid DA is mentioned. Please > see > >> the existing description (paras 4 and 5) on the fw_rsc_carveout > >> kerneldoc in remoteproc.h file. > > > > Thanks for pointing this comment. Indeed sMMU is not mandatory, and at > first sight I agree we should remove the restriction introduced by the patch. > > Driver porting on the series should be done before adding this. > >> > >> We do have platforms where we have some internal sub-modules within > the > >> remote processor sub-system that provides some linear > >> address-translation (most common case with 32-bit processors supporting > >> 64-bit addresses). Also, we have some upcoming SoCs where we have an > >> MMU > >> but is not programmable by Linux. > >> > >> There is one comment there, but I don't think this is actually handled > >> in the current remoteproc core. > >> "If @da is set to > >> * FW_RSC_ADDR_ANY, then the host will dynamically allocate it, and > then > >> * overwrite @da with the dynamically allocated address." > >> > > I don't remember it was implemented like described. > > Yes, it was missing, and one of your patches seem to add this behavior > now. That said, I really don't think the remoteproc core can dictate the > da. Even if the individual remoteproc driver were to furnish this, how > would you get such data without forcing a fixed behavior for all > possible firmwares (not desirable). We should get rid of this comment, > and any code that seems to do this. Agree that if some rules are fixed by firmware, rproc core can't overwrite them. It was the goal of the patch as without sMMU if you don't have a match between rproc core carveout allocation and firmware rsc request, rproc core can't answer the request. In the rest of the series, da in rsc table is updated only in some specific cases (i.e. da is equal to FW_RSC_ADDR_ANY). If there is a force update I agree we should not allow it. > > > > > I have remarks about the comment: > > "* We will always use @da to negotiate the device addresses, even if it > > * isn't using an iommu. In that case, though, it will obviously contain > > * physical addresses." > > > > When there is no sMMU, we can't consider that da contains a physical > address because coprocessor can have its own memory map just because it > is a 32bit processor accessing only a part of the memory and the main is 64bit > one. The 2 processors won't see the internal memory at the same base > address for example. > > Agreed, believe it was valid when it was written (32-bit platforms > supporting 32-bit addresses). I think this is akin to an IPA > (Intermediate Physical Address). > > > So what should we do when carveout allocated by host is not fitting with > resource table request? > > - put a warning and overwrite da address in the resource table? > > Hmm, why da? This goes to my earlier comment about how you are able to > decide the da. Atleast your current ST driver seems to be assigning the > same value as the physical bus address for da, which would prompt why > you would still need a carveout entry in the resource table if it is
RE: [PATCH v4 13/17] remoteproc: create vdev subdevice with specific dma memory pool
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 03:49
> To: Wendy Liang ; Loic PALLARDY
>
> Cc: Bjorn Andersson ; Ohad Ben-Cohen
> ; linux-remotep...@vger.kernel.org; Linux Kernel
> Mailing List ; Arnaud POULIQUEN
> ; benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 13/17] remoteproc: create vdev subdevice with
> specific dma memory pool
>
> On 10/23/18 8:22 PM, Suman Anna wrote:
> > On 9/27/18 3:18 PM, Wendy Liang wrote:
> >> Hi Loic,
> >>
> >>
> >> On Thu, Sep 27, 2018 at 12:22 PM Loic PALLARDY
> wrote:
> >>>
> >>> Hi Wendy
> >>>
> >>>> -Original Message-
> >>>> From: Wendy Liang
> >>>> Sent: Thursday, September 27, 2018 7:17 PM
> >>>> To: Loic PALLARDY
> >>>> Cc: Bjorn Andersson ; Ohad Ben-Cohen
> >>>> ; linux-remotep...@vger.kernel.org; Linux Kernel
> >>>> Mailing List ; Arnaud POULIQUEN
> >>>> ; benjamin.gaign...@linaro.org; Suman
> Anna
> >>>>
> >>>> Subject: Re: [PATCH v4 13/17] remoteproc: create vdev subdevice with
> >>>> specific dma memory pool
> >>>>
> >>>> On Fri, Jul 27, 2018 at 6:16 AM Loic Pallardy
> wrote:
> >>>>>
> >>>>> This patch creates a dedicated vdev subdevice for each vdev declared
> >>>>> in firmware resource table and associates carveout named
> "vdev%dbuffer"
> >>>>> (with %d vdev index in resource table) if any as dma coherent
> memory
> >>>> pool.
> >>>>>
> >>>>> Then vdev subdevice is used as parent for virtio device.
> >>>>>
> >>>>> Signed-off-by: Loic Pallardy
> >>>>> ---
> >>>>> drivers/remoteproc/remoteproc_core.c | 35
> >>>> +++---
> >>>>> drivers/remoteproc/remoteproc_internal.h | 1 +
> >>>>> drivers/remoteproc/remoteproc_virtio.c | 42
> >>>> +++-
> >>>>> include/linux/remoteproc.h | 1 +
> >>>>> 4 files changed, 75 insertions(+), 4 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/remoteproc/remoteproc_core.c
> >>>> b/drivers/remoteproc/remoteproc_core.c
> >>>>> index 4edc6f0..adcc66e 100644
> >>>>> --- a/drivers/remoteproc/remoteproc_core.c
> >>>>> +++ b/drivers/remoteproc/remoteproc_core.c
> >>>>> @@ -39,6 +39,7 @@
> >>>>> #include
> >>>>> #include
> >>>>> #include
> >>>>> +#include
> >>>>> #include
> >>>>> #include
> >>>>> #include
> >>>>> @@ -145,7 +146,7 @@ static void rproc_disable_iommu(struct rproc
> >>>> *rproc)
> >>>>> iommu_domain_free(domain);
> >>>>> }
> >>>>>
> >>>>> -static phys_addr_t rproc_va_to_pa(void *cpu_addr)
> >>>>> +phys_addr_t rproc_va_to_pa(void *cpu_addr)
> >>>>> {
> >>>>> /*
> >>>>> * Return physical address according to virtual address location
> >>>>> @@ -160,6 +161,7 @@ static phys_addr_t rproc_va_to_pa(void
> >>>> *cpu_addr)
> >>>>> WARN_ON(!virt_addr_valid(cpu_addr));
> >>>>> return virt_to_phys(cpu_addr);
> >>>>> }
> >>>>> +EXPORT_SYMBOL(rproc_va_to_pa);
> >>>>>
> >>>>> /**
> >>>>> * rproc_da_to_va() - lookup the kernel virtual address for a
> remoteproc
> >>>> address
> >>>>> @@ -423,6 +425,20 @@ static void rproc_vdev_do_stop(struct
> >>>> rproc_subdev *subdev, bool crashed)
> >>>>> }
> >>>>>
> >>>>> /**
> >>>>> + * rproc_rvdev_release() - release the existence of a rvdev
> >>>>> + *
> >>>>> + * @dev: the subdevice's dev
> >>>>> + */
> >>>>> +static void rproc_rvdev_release(struct device *dev)
> >>>>> +{
> >>>>> + struct rproc_vdev *rvdev = container_of(dev, struct rproc_vdev,
> dev);
> >>>>> +
> >>>>> + of_reserved_mem_device_release(dev);
> >>>&
RE: [PATCH v4 13/17] remoteproc: create vdev subdevice with specific dma memory pool
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 03:49
> To: Wendy Liang ; Loic PALLARDY
>
> Cc: Bjorn Andersson ; Ohad Ben-Cohen
> ; linux-remotep...@vger.kernel.org; Linux Kernel
> Mailing List ; Arnaud POULIQUEN
> ; benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 13/17] remoteproc: create vdev subdevice with
> specific dma memory pool
>
> On 10/23/18 8:22 PM, Suman Anna wrote:
> > On 9/27/18 3:18 PM, Wendy Liang wrote:
> >> Hi Loic,
> >>
> >>
> >> On Thu, Sep 27, 2018 at 12:22 PM Loic PALLARDY
> wrote:
> >>>
> >>> Hi Wendy
> >>>
> >>>> -Original Message-
> >>>> From: Wendy Liang
> >>>> Sent: Thursday, September 27, 2018 7:17 PM
> >>>> To: Loic PALLARDY
> >>>> Cc: Bjorn Andersson ; Ohad Ben-Cohen
> >>>> ; linux-remotep...@vger.kernel.org; Linux Kernel
> >>>> Mailing List ; Arnaud POULIQUEN
> >>>> ; benjamin.gaign...@linaro.org; Suman
> Anna
> >>>>
> >>>> Subject: Re: [PATCH v4 13/17] remoteproc: create vdev subdevice with
> >>>> specific dma memory pool
> >>>>
> >>>> On Fri, Jul 27, 2018 at 6:16 AM Loic Pallardy
> wrote:
> >>>>>
> >>>>> This patch creates a dedicated vdev subdevice for each vdev declared
> >>>>> in firmware resource table and associates carveout named
> "vdev%dbuffer"
> >>>>> (with %d vdev index in resource table) if any as dma coherent
> memory
> >>>> pool.
> >>>>>
> >>>>> Then vdev subdevice is used as parent for virtio device.
> >>>>>
> >>>>> Signed-off-by: Loic Pallardy
> >>>>> ---
> >>>>> drivers/remoteproc/remoteproc_core.c | 35
> >>>> +++---
> >>>>> drivers/remoteproc/remoteproc_internal.h | 1 +
> >>>>> drivers/remoteproc/remoteproc_virtio.c | 42
> >>>> +++-
> >>>>> include/linux/remoteproc.h | 1 +
> >>>>> 4 files changed, 75 insertions(+), 4 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/remoteproc/remoteproc_core.c
> >>>> b/drivers/remoteproc/remoteproc_core.c
> >>>>> index 4edc6f0..adcc66e 100644
> >>>>> --- a/drivers/remoteproc/remoteproc_core.c
> >>>>> +++ b/drivers/remoteproc/remoteproc_core.c
> >>>>> @@ -39,6 +39,7 @@
> >>>>> #include
> >>>>> #include
> >>>>> #include
> >>>>> +#include
> >>>>> #include
> >>>>> #include
> >>>>> #include
> >>>>> @@ -145,7 +146,7 @@ static void rproc_disable_iommu(struct rproc
> >>>> *rproc)
> >>>>> iommu_domain_free(domain);
> >>>>> }
> >>>>>
> >>>>> -static phys_addr_t rproc_va_to_pa(void *cpu_addr)
> >>>>> +phys_addr_t rproc_va_to_pa(void *cpu_addr)
> >>>>> {
> >>>>> /*
> >>>>> * Return physical address according to virtual address location
> >>>>> @@ -160,6 +161,7 @@ static phys_addr_t rproc_va_to_pa(void
> >>>> *cpu_addr)
> >>>>> WARN_ON(!virt_addr_valid(cpu_addr));
> >>>>> return virt_to_phys(cpu_addr);
> >>>>> }
> >>>>> +EXPORT_SYMBOL(rproc_va_to_pa);
> >>>>>
> >>>>> /**
> >>>>> * rproc_da_to_va() - lookup the kernel virtual address for a
> remoteproc
> >>>> address
> >>>>> @@ -423,6 +425,20 @@ static void rproc_vdev_do_stop(struct
> >>>> rproc_subdev *subdev, bool crashed)
> >>>>> }
> >>>>>
> >>>>> /**
> >>>>> + * rproc_rvdev_release() - release the existence of a rvdev
> >>>>> + *
> >>>>> + * @dev: the subdevice's dev
> >>>>> + */
> >>>>> +static void rproc_rvdev_release(struct device *dev)
> >>>>> +{
> >>>>> + struct rproc_vdev *rvdev = container_of(dev, struct rproc_vdev,
> dev);
> >>>>> +
> >>>>> + of_reserved_mem_device_release(dev);
> >>>&
RE: [PATCH v4 13/17] remoteproc: create vdev subdevice with specific dma memory pool
Hi Suman,
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 03:22
> To: Wendy Liang ; Loic PALLARDY
>
> Cc: Bjorn Andersson ; Ohad Ben-Cohen
> ; linux-remotep...@vger.kernel.org; Linux Kernel
> Mailing List ; Arnaud POULIQUEN
> ; benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 13/17] remoteproc: create vdev subdevice with
> specific dma memory pool
>
> On 9/27/18 3:18 PM, Wendy Liang wrote:
> > Hi Loic,
> >
> >
> > On Thu, Sep 27, 2018 at 12:22 PM Loic PALLARDY
> wrote:
> >>
> >> Hi Wendy
> >>
> >>> -Original Message-
> >>> From: Wendy Liang
> >>> Sent: Thursday, September 27, 2018 7:17 PM
> >>> To: Loic PALLARDY
> >>> Cc: Bjorn Andersson ; Ohad Ben-Cohen
> >>> ; linux-remotep...@vger.kernel.org; Linux Kernel
> >>> Mailing List ; Arnaud POULIQUEN
> >>> ; benjamin.gaign...@linaro.org; Suman
> Anna
> >>>
> >>> Subject: Re: [PATCH v4 13/17] remoteproc: create vdev subdevice with
> >>> specific dma memory pool
> >>>
> >>> On Fri, Jul 27, 2018 at 6:16 AM Loic Pallardy
> wrote:
> >>>>
> >>>> This patch creates a dedicated vdev subdevice for each vdev declared
> >>>> in firmware resource table and associates carveout named
> "vdev%dbuffer"
> >>>> (with %d vdev index in resource table) if any as dma coherent memory
> >>> pool.
> >>>>
> >>>> Then vdev subdevice is used as parent for virtio device.
> >>>>
> >>>> Signed-off-by: Loic Pallardy
> >>>> ---
> >>>> drivers/remoteproc/remoteproc_core.c | 35
> >>> +++---
> >>>> drivers/remoteproc/remoteproc_internal.h | 1 +
> >>>> drivers/remoteproc/remoteproc_virtio.c | 42
> >>> +++-
> >>>> include/linux/remoteproc.h | 1 +
> >>>> 4 files changed, 75 insertions(+), 4 deletions(-)
> >>>>
> >>>> diff --git a/drivers/remoteproc/remoteproc_core.c
> >>> b/drivers/remoteproc/remoteproc_core.c
> >>>> index 4edc6f0..adcc66e 100644
> >>>> --- a/drivers/remoteproc/remoteproc_core.c
> >>>> +++ b/drivers/remoteproc/remoteproc_core.c
> >>>> @@ -39,6 +39,7 @@
> >>>> #include
> >>>> #include
> >>>> #include
> >>>> +#include
> >>>> #include
> >>>> #include
> >>>> #include
> >>>> @@ -145,7 +146,7 @@ static void rproc_disable_iommu(struct rproc
> >>> *rproc)
> >>>> iommu_domain_free(domain);
> >>>> }
> >>>>
> >>>> -static phys_addr_t rproc_va_to_pa(void *cpu_addr)
> >>>> +phys_addr_t rproc_va_to_pa(void *cpu_addr)
> >>>> {
> >>>> /*
> >>>> * Return physical address according to virtual address location
> >>>> @@ -160,6 +161,7 @@ static phys_addr_t rproc_va_to_pa(void
> >>> *cpu_addr)
> >>>> WARN_ON(!virt_addr_valid(cpu_addr));
> >>>> return virt_to_phys(cpu_addr);
> >>>> }
> >>>> +EXPORT_SYMBOL(rproc_va_to_pa);
> >>>>
> >>>> /**
> >>>> * rproc_da_to_va() - lookup the kernel virtual address for a
> remoteproc
> >>> address
> >>>> @@ -423,6 +425,20 @@ static void rproc_vdev_do_stop(struct
> >>> rproc_subdev *subdev, bool crashed)
> >>>> }
> >>>>
> >>>> /**
> >>>> + * rproc_rvdev_release() - release the existence of a rvdev
> >>>> + *
> >>>> + * @dev: the subdevice's dev
> >>>> + */
> >>>> +static void rproc_rvdev_release(struct device *dev)
> >>>> +{
> >>>> + struct rproc_vdev *rvdev = container_of(dev, struct rproc_vdev,
> dev);
> >>>> +
> >>>> + of_reserved_mem_device_release(dev);
> >>>> +
> >>>> + kfree(rvdev);
> >>>> +}
> >>>> +
> >>>> +/**
> >>>> * rproc_handle_vdev() - handle a vdev fw resource
> >>>> * @rproc: the remote processor
> >>>> * @rsc: the vring resource descriptor
> >>>> @@ -455,6 +471,7 @@ static int rproc_handle_vdev(struct rpr
RE: [PATCH v4 13/17] remoteproc: create vdev subdevice with specific dma memory pool
Hi Suman,
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 03:22
> To: Wendy Liang ; Loic PALLARDY
>
> Cc: Bjorn Andersson ; Ohad Ben-Cohen
> ; linux-remotep...@vger.kernel.org; Linux Kernel
> Mailing List ; Arnaud POULIQUEN
> ; benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 13/17] remoteproc: create vdev subdevice with
> specific dma memory pool
>
> On 9/27/18 3:18 PM, Wendy Liang wrote:
> > Hi Loic,
> >
> >
> > On Thu, Sep 27, 2018 at 12:22 PM Loic PALLARDY
> wrote:
> >>
> >> Hi Wendy
> >>
> >>> -Original Message-
> >>> From: Wendy Liang
> >>> Sent: Thursday, September 27, 2018 7:17 PM
> >>> To: Loic PALLARDY
> >>> Cc: Bjorn Andersson ; Ohad Ben-Cohen
> >>> ; linux-remotep...@vger.kernel.org; Linux Kernel
> >>> Mailing List ; Arnaud POULIQUEN
> >>> ; benjamin.gaign...@linaro.org; Suman
> Anna
> >>>
> >>> Subject: Re: [PATCH v4 13/17] remoteproc: create vdev subdevice with
> >>> specific dma memory pool
> >>>
> >>> On Fri, Jul 27, 2018 at 6:16 AM Loic Pallardy
> wrote:
> >>>>
> >>>> This patch creates a dedicated vdev subdevice for each vdev declared
> >>>> in firmware resource table and associates carveout named
> "vdev%dbuffer"
> >>>> (with %d vdev index in resource table) if any as dma coherent memory
> >>> pool.
> >>>>
> >>>> Then vdev subdevice is used as parent for virtio device.
> >>>>
> >>>> Signed-off-by: Loic Pallardy
> >>>> ---
> >>>> drivers/remoteproc/remoteproc_core.c | 35
> >>> +++---
> >>>> drivers/remoteproc/remoteproc_internal.h | 1 +
> >>>> drivers/remoteproc/remoteproc_virtio.c | 42
> >>> +++-
> >>>> include/linux/remoteproc.h | 1 +
> >>>> 4 files changed, 75 insertions(+), 4 deletions(-)
> >>>>
> >>>> diff --git a/drivers/remoteproc/remoteproc_core.c
> >>> b/drivers/remoteproc/remoteproc_core.c
> >>>> index 4edc6f0..adcc66e 100644
> >>>> --- a/drivers/remoteproc/remoteproc_core.c
> >>>> +++ b/drivers/remoteproc/remoteproc_core.c
> >>>> @@ -39,6 +39,7 @@
> >>>> #include
> >>>> #include
> >>>> #include
> >>>> +#include
> >>>> #include
> >>>> #include
> >>>> #include
> >>>> @@ -145,7 +146,7 @@ static void rproc_disable_iommu(struct rproc
> >>> *rproc)
> >>>> iommu_domain_free(domain);
> >>>> }
> >>>>
> >>>> -static phys_addr_t rproc_va_to_pa(void *cpu_addr)
> >>>> +phys_addr_t rproc_va_to_pa(void *cpu_addr)
> >>>> {
> >>>> /*
> >>>> * Return physical address according to virtual address location
> >>>> @@ -160,6 +161,7 @@ static phys_addr_t rproc_va_to_pa(void
> >>> *cpu_addr)
> >>>> WARN_ON(!virt_addr_valid(cpu_addr));
> >>>> return virt_to_phys(cpu_addr);
> >>>> }
> >>>> +EXPORT_SYMBOL(rproc_va_to_pa);
> >>>>
> >>>> /**
> >>>> * rproc_da_to_va() - lookup the kernel virtual address for a
> remoteproc
> >>> address
> >>>> @@ -423,6 +425,20 @@ static void rproc_vdev_do_stop(struct
> >>> rproc_subdev *subdev, bool crashed)
> >>>> }
> >>>>
> >>>> /**
> >>>> + * rproc_rvdev_release() - release the existence of a rvdev
> >>>> + *
> >>>> + * @dev: the subdevice's dev
> >>>> + */
> >>>> +static void rproc_rvdev_release(struct device *dev)
> >>>> +{
> >>>> + struct rproc_vdev *rvdev = container_of(dev, struct rproc_vdev,
> dev);
> >>>> +
> >>>> + of_reserved_mem_device_release(dev);
> >>>> +
> >>>> + kfree(rvdev);
> >>>> +}
> >>>> +
> >>>> +/**
> >>>> * rproc_handle_vdev() - handle a vdev fw resource
> >>>> * @rproc: the remote processor
> >>>> * @rsc: the vring resource descriptor
> >>>> @@ -455,6 +471,7 @@ static int rproc_handle_vdev(struct rpr
RE: [PATCH v4 16/17] remoteproc: st: add reserved memory support
Hi Suman,
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 05:02
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 16/17] remoteproc: st: add reserved memory support
>
> Hi Loic,
>
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > ST remote processor needs some specified memory regions for
> > firmware and IPC.
> > Memory regions are defined as reserved memory and should
> > be registered in remoteproc core thanks to rproc_add_carveout
> > function before rproc_start. For this, st rproc driver implements
> > prepare ops.
> >
> > Signed-off-by: Loic Pallardy
> > ---
> > drivers/remoteproc/st_remoteproc.c | 96
> +-
> > 1 file changed, 85 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/remoteproc/st_remoteproc.c
> b/drivers/remoteproc/st_remoteproc.c
> > index aacef0e..45958d5 100644
> > --- a/drivers/remoteproc/st_remoteproc.c
> > +++ b/drivers/remoteproc/st_remoteproc.c
> > @@ -19,6 +19,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -91,6 +92,82 @@ static void st_rproc_kick(struct rproc *rproc, int vqid)
> > dev_err(dev, "failed to send message via mbox: %d\n", ret);
> > }
> >
> > +static int st_rproc_mem_alloc(struct rproc *rproc,
> > + struct rproc_mem_entry *mem)
> > +{
> > + struct device *dev = rproc->dev.parent;
> > + void *va;
> > +
> > + va = ioremap_wc(mem->dma, mem->len);
> > + if (!va) {
> > + dev_err(dev, "Unable to map memory region: %pa+%zx\n",
> > + >dma, mem->len);
> > + return -ENOMEM;
> > + }
> > +
> > + /* Update memory entry va */
> > + mem->va = va;
> > +
> > + return 0;
> > +}
> > +
> > +static int st_rproc_mem_release(struct rproc *rproc,
> > + struct rproc_mem_entry *mem)
> > +{
> > + iounmap(mem->va);
> > +
> > + return 0;
> > +}
> > +
> > +static int st_rproc_parse_fw(struct rproc *rproc, const struct firmware
> *fw)
> > +{
> > + struct device *dev = rproc->dev.parent;
> > + struct device_node *np = dev->of_node;
> > + struct rproc_mem_entry *mem;
> > + void *va;
> > + struct reserved_mem *rmem;
> > + struct of_phandle_iterator it;
> > + int err, index = 0;
> > +
> > + of_phandle_iterator_init(, np, "memory-region", NULL, 0);
> > + while ((err = of_phandle_iterator_next()) == 0) {
> > + va = NULL;
> > + rmem = of_reserved_mem_lookup(it.node);
> > +
> > + /* No need to map vdev buffer */
> > + if (strcmp(it.node->name, "vdev0buffer")) {
> > + va = devm_ioremap_wc(dev, rmem->base, rmem-
> >size);
> > + if (!va) {
> > + dev_err(dev, "Unable to map memory
> region: %pa+%zx\n",
> > + >base, rmem->size);
> > + return -ENOMEM;
> > + }
> > +
> > + /* Register memory region */
> > + mem = rproc_mem_entry_init(dev, va,
> > + (dma_addr_t)rmem->base,
> > + rmem->size, rmem->base,
> > + st_rproc_mem_alloc,
> > + st_rproc_mem_release,
>
> You seem to be double-mapping, first just above to supply the va to
> mem_entry_init and then through the alloc function.
>
> This is DT parsing and is fixed irrespective of firmware and only needs
> to be done once really in the platform driver probe. I think this whole
> logic is unnecessarily complicated in the name of letting the remoteproc
> core handle the alloc and free for fixed memory carveouts during every
> boot and shutdown, and having to redo the mapping everytime during the
> firmware parse. I am not a big fan of overloading the parse_fw to do
> this runtime remapping everytime for something that should have been
> done once. I think you have done this in your v2, and somewhere along in
> v3 got modified into t
RE: [PATCH v4 16/17] remoteproc: st: add reserved memory support
Hi Suman,
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 05:02
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 16/17] remoteproc: st: add reserved memory support
>
> Hi Loic,
>
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > ST remote processor needs some specified memory regions for
> > firmware and IPC.
> > Memory regions are defined as reserved memory and should
> > be registered in remoteproc core thanks to rproc_add_carveout
> > function before rproc_start. For this, st rproc driver implements
> > prepare ops.
> >
> > Signed-off-by: Loic Pallardy
> > ---
> > drivers/remoteproc/st_remoteproc.c | 96
> +-
> > 1 file changed, 85 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/remoteproc/st_remoteproc.c
> b/drivers/remoteproc/st_remoteproc.c
> > index aacef0e..45958d5 100644
> > --- a/drivers/remoteproc/st_remoteproc.c
> > +++ b/drivers/remoteproc/st_remoteproc.c
> > @@ -19,6 +19,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -91,6 +92,82 @@ static void st_rproc_kick(struct rproc *rproc, int vqid)
> > dev_err(dev, "failed to send message via mbox: %d\n", ret);
> > }
> >
> > +static int st_rproc_mem_alloc(struct rproc *rproc,
> > + struct rproc_mem_entry *mem)
> > +{
> > + struct device *dev = rproc->dev.parent;
> > + void *va;
> > +
> > + va = ioremap_wc(mem->dma, mem->len);
> > + if (!va) {
> > + dev_err(dev, "Unable to map memory region: %pa+%zx\n",
> > + >dma, mem->len);
> > + return -ENOMEM;
> > + }
> > +
> > + /* Update memory entry va */
> > + mem->va = va;
> > +
> > + return 0;
> > +}
> > +
> > +static int st_rproc_mem_release(struct rproc *rproc,
> > + struct rproc_mem_entry *mem)
> > +{
> > + iounmap(mem->va);
> > +
> > + return 0;
> > +}
> > +
> > +static int st_rproc_parse_fw(struct rproc *rproc, const struct firmware
> *fw)
> > +{
> > + struct device *dev = rproc->dev.parent;
> > + struct device_node *np = dev->of_node;
> > + struct rproc_mem_entry *mem;
> > + void *va;
> > + struct reserved_mem *rmem;
> > + struct of_phandle_iterator it;
> > + int err, index = 0;
> > +
> > + of_phandle_iterator_init(, np, "memory-region", NULL, 0);
> > + while ((err = of_phandle_iterator_next()) == 0) {
> > + va = NULL;
> > + rmem = of_reserved_mem_lookup(it.node);
> > +
> > + /* No need to map vdev buffer */
> > + if (strcmp(it.node->name, "vdev0buffer")) {
> > + va = devm_ioremap_wc(dev, rmem->base, rmem-
> >size);
> > + if (!va) {
> > + dev_err(dev, "Unable to map memory
> region: %pa+%zx\n",
> > + >base, rmem->size);
> > + return -ENOMEM;
> > + }
> > +
> > + /* Register memory region */
> > + mem = rproc_mem_entry_init(dev, va,
> > + (dma_addr_t)rmem->base,
> > + rmem->size, rmem->base,
> > + st_rproc_mem_alloc,
> > + st_rproc_mem_release,
>
> You seem to be double-mapping, first just above to supply the va to
> mem_entry_init and then through the alloc function.
>
> This is DT parsing and is fixed irrespective of firmware and only needs
> to be done once really in the platform driver probe. I think this whole
> logic is unnecessarily complicated in the name of letting the remoteproc
> core handle the alloc and free for fixed memory carveouts during every
> boot and shutdown, and having to redo the mapping everytime during the
> firmware parse. I am not a big fan of overloading the parse_fw to do
> this runtime remapping everytime for something that should have been
> done once. I think you have done this in your v2, and somewhere along in
> v3 got modified into t
RE: [PATCH v4 02/17] remoteproc: add rproc_va_to_pa function
Hi Suman,
> -Original Message-
> From: Suman Anna
> Sent: mardi 23 octobre 2018 18:51
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 02/17] remoteproc: add rproc_va_to_pa function
>
> Hi Loic, Bjorn,
>
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > This new function translates CPU virtual address in
> > CPU physical one according to virtual address location.
> >
> > Signed-off-by: Loic Pallardy
> > Acked-by: Bjorn Andersson
> > ---
> > drivers/remoteproc/remoteproc_core.c | 18 +-
> > 1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> > index 437fabf..8e5fe1e 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -140,6 +140,22 @@ static void rproc_disable_iommu(struct rproc
> *rproc)
> > iommu_domain_free(domain);
> > }
> >
> > +static phys_addr_t rproc_va_to_pa(void *cpu_addr)
> > +{
> > + /*
> > +* Return physical address according to virtual address location
> > +* - in vmalloc: if region ioremapped or defined as
> dma_alloc_coherent
> > +* - in kernel: if region allocated in generic dma memory pool
> > +*/
> > + if (is_vmalloc_addr(cpu_addr)) {
> > + return page_to_phys(vmalloc_to_page(cpu_addr)) +
> > + offset_in_page(cpu_addr);
> > + }
> > +
> > + WARN_ON(!virt_addr_valid(cpu_addr));
> > + return virt_to_phys(cpu_addr);
> > +}
> > +
> > /**
> > * rproc_da_to_va() - lookup the kernel virtual address for a remoteproc
> address
> > * @rproc: handle of a remote processor
> > @@ -711,7 +727,7 @@ static int rproc_handle_carveout(struct rproc
> *rproc,
> > * In this case, the device address and the physical address
> > * are the same.
> > */
> > - rsc->pa = dma;
> > + rsc->pa = (u32)rproc_va_to_pa(va);
>
> While I agree with the direction here, we ought to add a check here
> warning users if some address bits are getting lost as a result of the
> typecast. Granted the issue may have been present previously with
> dma_addr_t as well, but most platforms were using 32-bit dma addresses,
> so this was kinda masked. There are ARMv7 platforms with LPAE enabled
> allowing physical addresses > 32-bits.
>
> In anycase, we definitely have a need for a v2 for the fw_rsc_carveout
> structure to deal with 64-bit addresses.
>
Agree with you.
Assumption for this series was to keep resource table as it is. Resource table
improvement is planned in a second step.
Regards,
Loic
> regards
> Suman
>
> >
> > carveout->va = va;
> > carveout->len = rsc->len;
> >
RE: [PATCH v4 02/17] remoteproc: add rproc_va_to_pa function
Hi Suman,
> -Original Message-
> From: Suman Anna
> Sent: mardi 23 octobre 2018 18:51
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 02/17] remoteproc: add rproc_va_to_pa function
>
> Hi Loic, Bjorn,
>
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > This new function translates CPU virtual address in
> > CPU physical one according to virtual address location.
> >
> > Signed-off-by: Loic Pallardy
> > Acked-by: Bjorn Andersson
> > ---
> > drivers/remoteproc/remoteproc_core.c | 18 +-
> > 1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> > index 437fabf..8e5fe1e 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -140,6 +140,22 @@ static void rproc_disable_iommu(struct rproc
> *rproc)
> > iommu_domain_free(domain);
> > }
> >
> > +static phys_addr_t rproc_va_to_pa(void *cpu_addr)
> > +{
> > + /*
> > +* Return physical address according to virtual address location
> > +* - in vmalloc: if region ioremapped or defined as
> dma_alloc_coherent
> > +* - in kernel: if region allocated in generic dma memory pool
> > +*/
> > + if (is_vmalloc_addr(cpu_addr)) {
> > + return page_to_phys(vmalloc_to_page(cpu_addr)) +
> > + offset_in_page(cpu_addr);
> > + }
> > +
> > + WARN_ON(!virt_addr_valid(cpu_addr));
> > + return virt_to_phys(cpu_addr);
> > +}
> > +
> > /**
> > * rproc_da_to_va() - lookup the kernel virtual address for a remoteproc
> address
> > * @rproc: handle of a remote processor
> > @@ -711,7 +727,7 @@ static int rproc_handle_carveout(struct rproc
> *rproc,
> > * In this case, the device address and the physical address
> > * are the same.
> > */
> > - rsc->pa = dma;
> > + rsc->pa = (u32)rproc_va_to_pa(va);
>
> While I agree with the direction here, we ought to add a check here
> warning users if some address bits are getting lost as a result of the
> typecast. Granted the issue may have been present previously with
> dma_addr_t as well, but most platforms were using 32-bit dma addresses,
> so this was kinda masked. There are ARMv7 platforms with LPAE enabled
> allowing physical addresses > 32-bits.
>
> In anycase, we definitely have a need for a v2 for the fw_rsc_carveout
> structure to deal with 64-bit addresses.
>
Agree with you.
Assumption for this series was to keep resource table as it is. Resource table
improvement is planned in a second step.
Regards,
Loic
> regards
> Suman
>
> >
> > carveout->va = va;
> > carveout->len = rsc->len;
> >
RE: [PATCH v4 06/17] remoteproc: introduce rproc_add_carveout function
> -Original Message-
> From: Suman Anna
> Sent: mardi 23 octobre 2018 19:05
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 06/17] remoteproc: introduce rproc_add_carveout
> function
>
> Hi Bjorn, Loic,
>
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > This patch introduces a new API to allow platform driver to register
> > platform specific carveout regions.
> >
> > Signed-off-by: Loic Pallardy
> > Acked-by: Bjorn Andersson
>
> Hmm, I do not prefer that this function be exported. It adds no value,
> and this adds an asymmetric API for remoteproc drivers to add a mem
> entry to the internal remoteproc lists, while relying on the remoteproc
> core to remove them. The carveout list maintenance is a remoteproc
> internal scheme, and so should be maintained that way. Further more, on
> the current series, all the existing calls are immediately after a
> rproc_of_resm_mem_entry_init() or a rproc_mem_entry_init() function,
> which means this could very well be folded into those individual functions.
>
I think it has been introduced in first series. Look that rproc_add_carveout()
call could be integrated in helper functions now.
I can propose a patch to correct this.
Regards,
Loic
> regards
> Suman
>
> > ---
> > drivers/remoteproc/remoteproc_core.c | 16 +++-
> > include/linux/remoteproc.h | 2 ++
> > 2 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> > index b76760e..fe6c4e4 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -747,7 +747,7 @@ static int rproc_handle_carveout(struct rproc
> *rproc,
> > if (!carveout)
> > goto free_carv;
> >
> > - list_add_tail(>node, >carveouts);
> > + rproc_add_carveout(rproc, carveout);
> >
> > return 0;
> >
> > @@ -761,6 +761,20 @@ static int rproc_handle_carveout(struct rproc
> *rproc,
> > }
> >
> > /**
> > + * rproc_add_carveout() - register an allocated carveout region
> > + * @rproc: rproc handle
> > + * @mem: memory entry to register
> > + *
> > + * This function registers specified memory entry in @rproc carveouts list.
> > + * Specified carveout should have been allocated before registering.
> > + */
> > +void rproc_add_carveout(struct rproc *rproc, struct rproc_mem_entry
> *mem)
> > +{
> > + list_add_tail(>node, >carveouts);
> > +}
> > +EXPORT_SYMBOL(rproc_add_carveout);
> > +
> > +/**
> > * rproc_mem_entry_init() - allocate and initialize rproc_mem_entry struct
> > * @dev: pointer on device struct
> > * @va: virtual address
> > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> > index 4bc961f..55f30fc 100644
> > --- a/include/linux/remoteproc.h
> > +++ b/include/linux/remoteproc.h
> > @@ -558,6 +558,8 @@ struct rproc *rproc_alloc(struct device *dev, const
> char *name,
> > int rproc_del(struct rproc *rproc);
> > void rproc_free(struct rproc *rproc);
> >
> > +void rproc_add_carveout(struct rproc *rproc, struct rproc_mem_entry
> *mem);
> > +
> > struct rproc_mem_entry *
> > rproc_mem_entry_init(struct device *dev,
> > void *va, dma_addr_t dma, int len, u32 da,
> >
RE: [PATCH v4 06/17] remoteproc: introduce rproc_add_carveout function
> -Original Message-
> From: Suman Anna
> Sent: mardi 23 octobre 2018 19:05
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 06/17] remoteproc: introduce rproc_add_carveout
> function
>
> Hi Bjorn, Loic,
>
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > This patch introduces a new API to allow platform driver to register
> > platform specific carveout regions.
> >
> > Signed-off-by: Loic Pallardy
> > Acked-by: Bjorn Andersson
>
> Hmm, I do not prefer that this function be exported. It adds no value,
> and this adds an asymmetric API for remoteproc drivers to add a mem
> entry to the internal remoteproc lists, while relying on the remoteproc
> core to remove them. The carveout list maintenance is a remoteproc
> internal scheme, and so should be maintained that way. Further more, on
> the current series, all the existing calls are immediately after a
> rproc_of_resm_mem_entry_init() or a rproc_mem_entry_init() function,
> which means this could very well be folded into those individual functions.
>
I think it has been introduced in first series. Look that rproc_add_carveout()
call could be integrated in helper functions now.
I can propose a patch to correct this.
Regards,
Loic
> regards
> Suman
>
> > ---
> > drivers/remoteproc/remoteproc_core.c | 16 +++-
> > include/linux/remoteproc.h | 2 ++
> > 2 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> > index b76760e..fe6c4e4 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -747,7 +747,7 @@ static int rproc_handle_carveout(struct rproc
> *rproc,
> > if (!carveout)
> > goto free_carv;
> >
> > - list_add_tail(>node, >carveouts);
> > + rproc_add_carveout(rproc, carveout);
> >
> > return 0;
> >
> > @@ -761,6 +761,20 @@ static int rproc_handle_carveout(struct rproc
> *rproc,
> > }
> >
> > /**
> > + * rproc_add_carveout() - register an allocated carveout region
> > + * @rproc: rproc handle
> > + * @mem: memory entry to register
> > + *
> > + * This function registers specified memory entry in @rproc carveouts list.
> > + * Specified carveout should have been allocated before registering.
> > + */
> > +void rproc_add_carveout(struct rproc *rproc, struct rproc_mem_entry
> *mem)
> > +{
> > + list_add_tail(>node, >carveouts);
> > +}
> > +EXPORT_SYMBOL(rproc_add_carveout);
> > +
> > +/**
> > * rproc_mem_entry_init() - allocate and initialize rproc_mem_entry struct
> > * @dev: pointer on device struct
> > * @va: virtual address
> > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> > index 4bc961f..55f30fc 100644
> > --- a/include/linux/remoteproc.h
> > +++ b/include/linux/remoteproc.h
> > @@ -558,6 +558,8 @@ struct rproc *rproc_alloc(struct device *dev, const
> char *name,
> > int rproc_del(struct rproc *rproc);
> > void rproc_free(struct rproc *rproc);
> >
> > +void rproc_add_carveout(struct rproc *rproc, struct rproc_mem_entry
> *mem);
> > +
> > struct rproc_mem_entry *
> > rproc_mem_entry_init(struct device *dev,
> > void *va, dma_addr_t dma, int len, u32 da,
> >
RE: [PATCH v4 01/17] remoteproc: configure IOMMU only if device address requested
Hi Suman,
> -Original Message-
> From: Suman Anna
> Sent: mardi 23 octobre 2018 19:26
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 01/17] remoteproc: configure IOMMU only if device
> address requested
>
> Hi Loic,
>
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > If there is no IOMMU associate to remote processor device,
> > remoteproc_core won't be able to satisfy device address requested
> > in firmware resource table.
> > Return an error as configuration won't be coherent.
> >
> > Signed-off-by: Loic Pallardy
>
> This patch is breaking my Davinci platforms. It is not really required
> that you _should_ have IOMMUs when a valid DA is mentioned. Please see
> the existing description (paras 4 and 5) on the fw_rsc_carveout
> kerneldoc in remoteproc.h file.
Thanks for pointing this comment. Indeed sMMU is not mandatory, and at first
sight I agree we should remove the restriction introduced by the patch.
Driver porting on the series should be done before adding this.
>
> We do have platforms where we have some internal sub-modules within the
> remote processor sub-system that provides some linear
> address-translation (most common case with 32-bit processors supporting
> 64-bit addresses). Also, we have some upcoming SoCs where we have an
> MMU
> but is not programmable by Linux.
>
> There is one comment there, but I don't think this is actually handled
> in the current remoteproc core.
> "If @da is set to
> * FW_RSC_ADDR_ANY, then the host will dynamically allocate it, and then
> * overwrite @da with the dynamically allocated address."
>
I don't remember it was implemented like described.
I have remarks about the comment:
"* We will always use @da to negotiate the device addresses, even if it
* isn't using an iommu. In that case, though, it will obviously contain
* physical addresses."
When there is no sMMU, we can't consider that da contains a physical address
because coprocessor can have its own memory map just because it is a 32bit
processor accessing only a part of the memory and the main is 64bit one. The 2
processors won't see the internal memory at the same base address for example.
So what should we do when carveout allocated by host is not fitting with
resource table request?
- put a warning and overwrite da address in the resource table?
- stop rproc probe as no match detected?
Later in the series, carveout allocation is changed. Resource table carveout
are either linked with an existing carveout registered by driver or added to
carveout list for allocations.
In the case you described, TI driver should first register the specific
carveout regions thank to the helper.
Regards,
Loic
> regards
> Suman
>
> > ---
> > drivers/remoteproc/remoteproc_core.c | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> > index 4cd1a8e..437fabf 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -657,7 +657,15 @@ static int rproc_handle_carveout(struct rproc
> *rproc,
> > * to use the iommu-based DMA API: we expect 'dma' to contain the
> > * physical address in this case.
> > */
> > - if (rproc->domain) {
> > +
> > + if (rsc->da != FW_RSC_ADDR_ANY && !rproc->domain) {
> > + dev_err(dev->parent,
> > + "Bad carveout rsc configuration\n");
> > + ret = -ENOMEM;
> > + goto dma_free;
> > + }
> > +
> > + if (rsc->da != FW_RSC_ADDR_ANY && rproc->domain) {
> > mapping = kzalloc(sizeof(*mapping), GFP_KERNEL);
> > if (!mapping) {
> > ret = -ENOMEM;
> >
RE: [PATCH v4 01/17] remoteproc: configure IOMMU only if device address requested
Hi Suman,
> -Original Message-
> From: Suman Anna
> Sent: mardi 23 octobre 2018 19:26
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v4 01/17] remoteproc: configure IOMMU only if device
> address requested
>
> Hi Loic,
>
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
> > If there is no IOMMU associate to remote processor device,
> > remoteproc_core won't be able to satisfy device address requested
> > in firmware resource table.
> > Return an error as configuration won't be coherent.
> >
> > Signed-off-by: Loic Pallardy
>
> This patch is breaking my Davinci platforms. It is not really required
> that you _should_ have IOMMUs when a valid DA is mentioned. Please see
> the existing description (paras 4 and 5) on the fw_rsc_carveout
> kerneldoc in remoteproc.h file.
Thanks for pointing this comment. Indeed sMMU is not mandatory, and at first
sight I agree we should remove the restriction introduced by the patch.
Driver porting on the series should be done before adding this.
>
> We do have platforms where we have some internal sub-modules within the
> remote processor sub-system that provides some linear
> address-translation (most common case with 32-bit processors supporting
> 64-bit addresses). Also, we have some upcoming SoCs where we have an
> MMU
> but is not programmable by Linux.
>
> There is one comment there, but I don't think this is actually handled
> in the current remoteproc core.
> "If @da is set to
> * FW_RSC_ADDR_ANY, then the host will dynamically allocate it, and then
> * overwrite @da with the dynamically allocated address."
>
I don't remember it was implemented like described.
I have remarks about the comment:
"* We will always use @da to negotiate the device addresses, even if it
* isn't using an iommu. In that case, though, it will obviously contain
* physical addresses."
When there is no sMMU, we can't consider that da contains a physical address
because coprocessor can have its own memory map just because it is a 32bit
processor accessing only a part of the memory and the main is 64bit one. The 2
processors won't see the internal memory at the same base address for example.
So what should we do when carveout allocated by host is not fitting with
resource table request?
- put a warning and overwrite da address in the resource table?
- stop rproc probe as no match detected?
Later in the series, carveout allocation is changed. Resource table carveout
are either linked with an existing carveout registered by driver or added to
carveout list for allocations.
In the case you described, TI driver should first register the specific
carveout regions thank to the helper.
Regards,
Loic
> regards
> Suman
>
> > ---
> > drivers/remoteproc/remoteproc_core.c | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> > index 4cd1a8e..437fabf 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -657,7 +657,15 @@ static int rproc_handle_carveout(struct rproc
> *rproc,
> > * to use the iommu-based DMA API: we expect 'dma' to contain the
> > * physical address in this case.
> > */
> > - if (rproc->domain) {
> > +
> > + if (rsc->da != FW_RSC_ADDR_ANY && !rproc->domain) {
> > + dev_err(dev->parent,
> > + "Bad carveout rsc configuration\n");
> > + ret = -ENOMEM;
> > + goto dma_free;
> > + }
> > +
> > + if (rsc->da != FW_RSC_ADDR_ANY && rproc->domain) {
> > mapping = kzalloc(sizeof(*mapping), GFP_KERNEL);
> > if (!mapping) {
> > ret = -ENOMEM;
> >
RE: [PATCH v2 05/16] remoteproc: modify rproc_handle_carveout to support preallocated region
> -Original Message-
> From: Suman Anna
> Sent: mardi 23 octobre 2018 19:40
> To: Loic PALLARDY ; Bjorn Andersson
>
> Cc: o...@wizery.com; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v2 05/16] remoteproc: modify rproc_handle_carveout to
> support preallocated region
>
> >>
> >> On Thu 30 Nov 08:46 PST 2017, Loic Pallardy wrote:
> >>
> >>> In current version rproc_handle_carveout function support only dynamic
> >>> region allocation.
> >>> This patch extends rproc_handle_carveout function to support different
> >> carveout
> >>> configurations:
> >>> - fixed DA and fixed PA: check if already part of pre-registered carveouts
> >>> (platform driver). If no, return error.
> >>> - fixed DA and any PA: check if already part of pre-allocated carveouts
> >>> (platform driver). If not found and rproc supports iommu, continue with
> >>> dynamic allocation (DA will be used for iommu programming), else
> return
> >>> error as no way to force DA.
> >>> - any DA and any PA: use original dynamic allocation
> >>>
> >>> Signed-off-by: Loic Pallardy
> >>> ---
> >>> drivers/remoteproc/remoteproc_core.c | 40
> >>
> >>> 1 file changed, 40 insertions(+)
> >>>
> >>> diff --git a/drivers/remoteproc/remoteproc_core.c
> >> b/drivers/remoteproc/remoteproc_core.c
> >>> index 78525d1..515a17a 100644
> >>> --- a/drivers/remoteproc/remoteproc_core.c
> >>> +++ b/drivers/remoteproc/remoteproc_core.c
> >>> @@ -184,6 +184,10 @@ void *rproc_da_to_va(struct rproc *rproc, u64
> da,
> >> int len)
> >>> struct rproc_mem_entry *carveout;
> >>> void *ptr = NULL;
> >>>
> >>> + /*
> >>> + * da_to_va platform driver is deprecated. Driver should register
> >>> + * carveout thanks to rproc_add_carveout function
> >>> + */
> >>
> >> I think this comment is unrelated to the rest of this patch. I also
> >> think that at the end of the carveout-rework we should have a patch
> >> removing this ops.
> >
> > I'll remove this comment and add a da_to_va clean-up patch at the end of
> the series
>
> da_to_va platform ops is actually used to provide the remoteproc
> internal memory translations for the most part, not restricted just to
> fixed carveouts. Also, typically these do have multiple address-views -
> one the regular bus-address view, and another a remote processor address
> view.
da_to_va op sis still there. I was proposing to remove this ops as we were
discussing to register all carveouts accessed by coprocessor in rproc core
carveout list.
This will allow to centralize all carveout definitions and to see all memory
resources viewed by coprocessor (va, pa and da) via debugfs...
Regards,
Loic
>
> regards
> Suman
>
> >
> >>
> >>> if (rproc->ops->da_to_va) {
> >>> ptr = rproc->ops->da_to_va(rproc, da, len);
> >>> if (ptr)
> >>> @@ -677,6 +681,7 @@ static int rproc_handle_carveout(struct rproc
> >> *rproc,
> >>> struct rproc_mem_entry *carveout, *mapping;
> >>> struct device *dev = >dev;
> >>> dma_addr_t dma;
> >>> + phys_addr_t pa;
> >>> void *va;
> >>> int ret;
> >>>
> >>> @@ -698,6 +703,41 @@ static int rproc_handle_carveout(struct rproc
> >> *rproc,
> >>> if (!carveout)
> >>> return -ENOMEM;
> >>>
> >>> + /* Check carveout rsc already part of a registered carveout */
> >>> + if (rsc->da != FW_RSC_ADDR_ANY) {
> >>
> >> As mentioned before, I consider it perfectly viable for rsc->da to be
> >> ANY and the driver providing a fixed carveout.
> >
> > Yes I'll change sequence to lookup by name first and then verify exact
> parameters matching , not only da definition.
> >
> >>
> >>> + va = rproc_find_carveout_by_da(rproc, rsc->da, rsc->len);
> >>> +
> >>> + if (va) {
> >>
> >> In a system with an iommu it's possible that rsc->len is larger than
> >> some carveout->len and va is NULL here so we fall through, allocate some
> >> memory and remap a segment of the carveout. (Or hopefully fails
> >> att
RE: [PATCH v2 05/16] remoteproc: modify rproc_handle_carveout to support preallocated region
> -Original Message-
> From: Suman Anna
> Sent: mardi 23 octobre 2018 19:40
> To: Loic PALLARDY ; Bjorn Andersson
>
> Cc: o...@wizery.com; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re: [PATCH v2 05/16] remoteproc: modify rproc_handle_carveout to
> support preallocated region
>
> >>
> >> On Thu 30 Nov 08:46 PST 2017, Loic Pallardy wrote:
> >>
> >>> In current version rproc_handle_carveout function support only dynamic
> >>> region allocation.
> >>> This patch extends rproc_handle_carveout function to support different
> >> carveout
> >>> configurations:
> >>> - fixed DA and fixed PA: check if already part of pre-registered carveouts
> >>> (platform driver). If no, return error.
> >>> - fixed DA and any PA: check if already part of pre-allocated carveouts
> >>> (platform driver). If not found and rproc supports iommu, continue with
> >>> dynamic allocation (DA will be used for iommu programming), else
> return
> >>> error as no way to force DA.
> >>> - any DA and any PA: use original dynamic allocation
> >>>
> >>> Signed-off-by: Loic Pallardy
> >>> ---
> >>> drivers/remoteproc/remoteproc_core.c | 40
> >>
> >>> 1 file changed, 40 insertions(+)
> >>>
> >>> diff --git a/drivers/remoteproc/remoteproc_core.c
> >> b/drivers/remoteproc/remoteproc_core.c
> >>> index 78525d1..515a17a 100644
> >>> --- a/drivers/remoteproc/remoteproc_core.c
> >>> +++ b/drivers/remoteproc/remoteproc_core.c
> >>> @@ -184,6 +184,10 @@ void *rproc_da_to_va(struct rproc *rproc, u64
> da,
> >> int len)
> >>> struct rproc_mem_entry *carveout;
> >>> void *ptr = NULL;
> >>>
> >>> + /*
> >>> + * da_to_va platform driver is deprecated. Driver should register
> >>> + * carveout thanks to rproc_add_carveout function
> >>> + */
> >>
> >> I think this comment is unrelated to the rest of this patch. I also
> >> think that at the end of the carveout-rework we should have a patch
> >> removing this ops.
> >
> > I'll remove this comment and add a da_to_va clean-up patch at the end of
> the series
>
> da_to_va platform ops is actually used to provide the remoteproc
> internal memory translations for the most part, not restricted just to
> fixed carveouts. Also, typically these do have multiple address-views -
> one the regular bus-address view, and another a remote processor address
> view.
da_to_va op sis still there. I was proposing to remove this ops as we were
discussing to register all carveouts accessed by coprocessor in rproc core
carveout list.
This will allow to centralize all carveout definitions and to see all memory
resources viewed by coprocessor (va, pa and da) via debugfs...
Regards,
Loic
>
> regards
> Suman
>
> >
> >>
> >>> if (rproc->ops->da_to_va) {
> >>> ptr = rproc->ops->da_to_va(rproc, da, len);
> >>> if (ptr)
> >>> @@ -677,6 +681,7 @@ static int rproc_handle_carveout(struct rproc
> >> *rproc,
> >>> struct rproc_mem_entry *carveout, *mapping;
> >>> struct device *dev = >dev;
> >>> dma_addr_t dma;
> >>> + phys_addr_t pa;
> >>> void *va;
> >>> int ret;
> >>>
> >>> @@ -698,6 +703,41 @@ static int rproc_handle_carveout(struct rproc
> >> *rproc,
> >>> if (!carveout)
> >>> return -ENOMEM;
> >>>
> >>> + /* Check carveout rsc already part of a registered carveout */
> >>> + if (rsc->da != FW_RSC_ADDR_ANY) {
> >>
> >> As mentioned before, I consider it perfectly viable for rsc->da to be
> >> ANY and the driver providing a fixed carveout.
> >
> > Yes I'll change sequence to lookup by name first and then verify exact
> parameters matching , not only da definition.
> >
> >>
> >>> + va = rproc_find_carveout_by_da(rproc, rsc->da, rsc->len);
> >>> +
> >>> + if (va) {
> >>
> >> In a system with an iommu it's possible that rsc->len is larger than
> >> some carveout->len and va is NULL here so we fall through, allocate some
> >> memory and remap a segment of the carveout. (Or hopefully fails
> >> att
RE: [PATCH v4 13/17] remoteproc: create vdev subdevice with specific dma memory pool
> -Original Message-
> From: Bjorn Andersson [mailto:bjorn.anders...@linaro.org]
> Sent: mercredi 10 octobre 2018 07:58
> To: Loic PALLARDY
> Cc: o...@wizery.com; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org; s-a...@ti.com
> Subject: Re: [PATCH v4 13/17] remoteproc: create vdev subdevice with
> specific dma memory pool
>
> On Fri 27 Jul 06:14 PDT 2018, Loic Pallardy wrote:
>
> > This patch creates a dedicated vdev subdevice for each vdev declared
> > in firmware resource table and associates carveout named "vdev%dbuffer"
> > (with %d vdev index in resource table) if any as dma coherent memory
> pool.
> >
> > Then vdev subdevice is used as parent for virtio device.
> >
> > Signed-off-by: Loic Pallardy
> > ---
> > drivers/remoteproc/remoteproc_core.c | 35
> +++---
> > drivers/remoteproc/remoteproc_internal.h | 1 +
> > drivers/remoteproc/remoteproc_virtio.c | 42
> +++-
> > include/linux/remoteproc.h | 1 +
> > 4 files changed, 75 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> > index 4edc6f0..adcc66e 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -39,6 +39,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -145,7 +146,7 @@ static void rproc_disable_iommu(struct rproc
> *rproc)
> > iommu_domain_free(domain);
> > }
> >
> > -static phys_addr_t rproc_va_to_pa(void *cpu_addr)
> > +phys_addr_t rproc_va_to_pa(void *cpu_addr)
> > {
> > /*
> > * Return physical address according to virtual address location
> > @@ -160,6 +161,7 @@ static phys_addr_t rproc_va_to_pa(void
> *cpu_addr)
> > WARN_ON(!virt_addr_valid(cpu_addr));
> > return virt_to_phys(cpu_addr);
> > }
> > +EXPORT_SYMBOL(rproc_va_to_pa);
> >
> > /**
> > * rproc_da_to_va() - lookup the kernel virtual address for a remoteproc
> address
> > @@ -423,6 +425,20 @@ static void rproc_vdev_do_stop(struct
> rproc_subdev *subdev, bool crashed)
> > }
> >
> > /**
> > + * rproc_rvdev_release() - release the existence of a rvdev
> > + *
> > + * @dev: the subdevice's dev
> > + */
> > +static void rproc_rvdev_release(struct device *dev)
> > +{
> > + struct rproc_vdev *rvdev = container_of(dev, struct rproc_vdev,
> dev);
> > +
> > + of_reserved_mem_device_release(dev);
> > +
> > + kfree(rvdev);
> > +}
> > +
> > +/**
> > * rproc_handle_vdev() - handle a vdev fw resource
> > * @rproc: the remote processor
> > * @rsc: the vring resource descriptor
> > @@ -455,6 +471,7 @@ static int rproc_handle_vdev(struct rproc *rproc,
> struct fw_rsc_vdev *rsc,
> > struct device *dev = >dev;
> > struct rproc_vdev *rvdev;
> > int i, ret;
> > + char name[16];
> >
> > /* make sure resource isn't truncated */
> > if (sizeof(*rsc) + rsc->num_of_vrings * sizeof(struct
> fw_rsc_vdev_vring)
> > @@ -488,6 +505,18 @@ static int rproc_handle_vdev(struct rproc *rproc,
> struct fw_rsc_vdev *rsc,
> > rvdev->rproc = rproc;
> > rvdev->index = rproc->nb_vdev++;
> >
> > + /* Initialise vdev subdevice */
> > + snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
> > + rvdev->dev.parent = rproc->dev.parent;
> > + rvdev->dev.release = rproc_rvdev_release;
> > + dev_set_name(>dev, "%s#%s", dev_name(rvdev-
> >dev.parent), name);
> > + dev_set_drvdata(>dev, rvdev);
> > + dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
> > +
> > + ret = device_register(>dev);
> > + if (ret)
> > + goto free_rvdev;
> > +
> > /* parse the vrings */
> > for (i = 0; i < rsc->num_of_vrings; i++) {
> > ret = rproc_parse_vring(rvdev, rsc, i);
> > @@ -518,7 +547,7 @@ static int rproc_handle_vdev(struct rproc *rproc,
> struct fw_rsc_vdev *rsc,
> > for (i--; i >= 0; i--)
> > rproc_free_vring(>vring[i]);
> > free_rvdev:
> > - kfree(rvdev);
> > + device_unregister(>dev);
> > return ret;
> > }
> >
> > @@ -536,7 +565,7 @@ void rproc_vdev_release(struct kref *ref)
> >
>
RE: [PATCH v4 13/17] remoteproc: create vdev subdevice with specific dma memory pool
> -Original Message-
> From: Bjorn Andersson [mailto:bjorn.anders...@linaro.org]
> Sent: mercredi 10 octobre 2018 07:58
> To: Loic PALLARDY
> Cc: o...@wizery.com; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org; s-a...@ti.com
> Subject: Re: [PATCH v4 13/17] remoteproc: create vdev subdevice with
> specific dma memory pool
>
> On Fri 27 Jul 06:14 PDT 2018, Loic Pallardy wrote:
>
> > This patch creates a dedicated vdev subdevice for each vdev declared
> > in firmware resource table and associates carveout named "vdev%dbuffer"
> > (with %d vdev index in resource table) if any as dma coherent memory
> pool.
> >
> > Then vdev subdevice is used as parent for virtio device.
> >
> > Signed-off-by: Loic Pallardy
> > ---
> > drivers/remoteproc/remoteproc_core.c | 35
> +++---
> > drivers/remoteproc/remoteproc_internal.h | 1 +
> > drivers/remoteproc/remoteproc_virtio.c | 42
> +++-
> > include/linux/remoteproc.h | 1 +
> > 4 files changed, 75 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> > index 4edc6f0..adcc66e 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -39,6 +39,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -145,7 +146,7 @@ static void rproc_disable_iommu(struct rproc
> *rproc)
> > iommu_domain_free(domain);
> > }
> >
> > -static phys_addr_t rproc_va_to_pa(void *cpu_addr)
> > +phys_addr_t rproc_va_to_pa(void *cpu_addr)
> > {
> > /*
> > * Return physical address according to virtual address location
> > @@ -160,6 +161,7 @@ static phys_addr_t rproc_va_to_pa(void
> *cpu_addr)
> > WARN_ON(!virt_addr_valid(cpu_addr));
> > return virt_to_phys(cpu_addr);
> > }
> > +EXPORT_SYMBOL(rproc_va_to_pa);
> >
> > /**
> > * rproc_da_to_va() - lookup the kernel virtual address for a remoteproc
> address
> > @@ -423,6 +425,20 @@ static void rproc_vdev_do_stop(struct
> rproc_subdev *subdev, bool crashed)
> > }
> >
> > /**
> > + * rproc_rvdev_release() - release the existence of a rvdev
> > + *
> > + * @dev: the subdevice's dev
> > + */
> > +static void rproc_rvdev_release(struct device *dev)
> > +{
> > + struct rproc_vdev *rvdev = container_of(dev, struct rproc_vdev,
> dev);
> > +
> > + of_reserved_mem_device_release(dev);
> > +
> > + kfree(rvdev);
> > +}
> > +
> > +/**
> > * rproc_handle_vdev() - handle a vdev fw resource
> > * @rproc: the remote processor
> > * @rsc: the vring resource descriptor
> > @@ -455,6 +471,7 @@ static int rproc_handle_vdev(struct rproc *rproc,
> struct fw_rsc_vdev *rsc,
> > struct device *dev = >dev;
> > struct rproc_vdev *rvdev;
> > int i, ret;
> > + char name[16];
> >
> > /* make sure resource isn't truncated */
> > if (sizeof(*rsc) + rsc->num_of_vrings * sizeof(struct
> fw_rsc_vdev_vring)
> > @@ -488,6 +505,18 @@ static int rproc_handle_vdev(struct rproc *rproc,
> struct fw_rsc_vdev *rsc,
> > rvdev->rproc = rproc;
> > rvdev->index = rproc->nb_vdev++;
> >
> > + /* Initialise vdev subdevice */
> > + snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
> > + rvdev->dev.parent = rproc->dev.parent;
> > + rvdev->dev.release = rproc_rvdev_release;
> > + dev_set_name(>dev, "%s#%s", dev_name(rvdev-
> >dev.parent), name);
> > + dev_set_drvdata(>dev, rvdev);
> > + dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
> > +
> > + ret = device_register(>dev);
> > + if (ret)
> > + goto free_rvdev;
> > +
> > /* parse the vrings */
> > for (i = 0; i < rsc->num_of_vrings; i++) {
> > ret = rproc_parse_vring(rvdev, rsc, i);
> > @@ -518,7 +547,7 @@ static int rproc_handle_vdev(struct rproc *rproc,
> struct fw_rsc_vdev *rsc,
> > for (i--; i >= 0; i--)
> > rproc_free_vring(>vring[i]);
> > free_rvdev:
> > - kfree(rvdev);
> > + device_unregister(>dev);
> > return ret;
> > }
> >
> > @@ -536,7 +565,7 @@ void rproc_vdev_release(struct kref *ref)
> >
>
RE: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on centralized carveout allocator
> -Original Message- > From: Bjorn Andersson [mailto:bjorn.anders...@linaro.org] > Sent: mercredi 10 octobre 2018 07:32 > To: Loic PALLARDY > Cc: o...@wizery.com; linux-remotep...@vger.kernel.org; linux- > ker...@vger.kernel.org; Arnaud POULIQUEN ; > benjamin.gaign...@linaro.org; s-a...@ti.com > Subject: Re: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on > centralized carveout allocator > > On Fri 27 Jul 06:14 PDT 2018, Loic Pallardy wrote: > > int rproc_fw_sanity_check(struct rproc *rproc, const struct firmware *fw) > > diff --git a/drivers/remoteproc/remoteproc_virtio.c > b/drivers/remoteproc/remoteproc_virtio.c > [..] > > @@ -114,6 +122,10 @@ static struct virtqueue *rp_find_vq(struct > virtio_device *vdev, > > rvring->vq = vq; > > vq->priv = rvring; > > > > + /* Update vring in resource table */ > > + rsc = (void *)rproc->table_ptr + rvdev->rsc_offset; > > + rsc->vring[id].da = mem->da; > > + > > This would now happen after we've started the remoteproc. Don't we need > to do this in-between allocating the carveouts and booting the > remoteproc? Yes da is updated after coprocessor boot, but before vdev status in resource table is set to DRIVER_OK and kick. Coprocessor should not parse this resource before as vrings not initialized yet. If coprocessor needs to get some information about vring carveout at boot time, carveout resources named vdev"x"vring"y" should be added to firmware resource table. In that case information will be filled before coprocessor boot. Regards, Loic > > Regards, > Bjorn
RE: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on centralized carveout allocator
> -Original Message- > From: Bjorn Andersson [mailto:bjorn.anders...@linaro.org] > Sent: mercredi 10 octobre 2018 07:32 > To: Loic PALLARDY > Cc: o...@wizery.com; linux-remotep...@vger.kernel.org; linux- > ker...@vger.kernel.org; Arnaud POULIQUEN ; > benjamin.gaign...@linaro.org; s-a...@ti.com > Subject: Re: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on > centralized carveout allocator > > On Fri 27 Jul 06:14 PDT 2018, Loic Pallardy wrote: > > int rproc_fw_sanity_check(struct rproc *rproc, const struct firmware *fw) > > diff --git a/drivers/remoteproc/remoteproc_virtio.c > b/drivers/remoteproc/remoteproc_virtio.c > [..] > > @@ -114,6 +122,10 @@ static struct virtqueue *rp_find_vq(struct > virtio_device *vdev, > > rvring->vq = vq; > > vq->priv = rvring; > > > > + /* Update vring in resource table */ > > + rsc = (void *)rproc->table_ptr + rvdev->rsc_offset; > > + rsc->vring[id].da = mem->da; > > + > > This would now happen after we've started the remoteproc. Don't we need > to do this in-between allocating the carveouts and booting the > remoteproc? Yes da is updated after coprocessor boot, but before vdev status in resource table is set to DRIVER_OK and kick. Coprocessor should not parse this resource before as vrings not initialized yet. If coprocessor needs to get some information about vring carveout at boot time, carveout resources named vdev"x"vring"y" should be added to firmware resource table. In that case information will be filled before coprocessor boot. Regards, Loic > > Regards, > Bjorn
