* [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support
2020-04-20 16:05 [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support Suman Anna
@ 2020-04-20 16:05 ` Suman Anna
2020-04-20 16:05 ` [PATCH v3 1/2] remoteproc: Fall back to using parent memory pool if no dedicated available Suman Anna
` (3 subsequent siblings)
4 siblings, 0 replies; 13+ messages in thread
From: Suman Anna @ 2020-04-20 16:05 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Mathieu Poirier, Arnaud Pouliquen, Loic Pallardy, Tero Kristo,
linux-remoteproc, linux-kernel, Suman Anna
Hi Bjorn,
This is another minor revision of the fixes around fixed memory region
support [1] series. Patch 1 is revised to go back to the logic used in v1
after a long discussion on the v2 version [2]. The other suggestions can
be future improvments as they would require corresponding platform driver
changes. Please look through the discussion there and let us know your
preference. Patches are based on v5.7-rc1.
I really appreciate it if you can target the series for the current 5.7 -rc's.
The fixes would apply for all 5.1+ kernels.
Please see the v1 cover-letter [1] for the details on the issues.
regards
Suman
[1] https://patchwork.kernel.org/cover/11422723/
[2] https://patchwork.kernel.org/comment/23274389/
Suman Anna (1):
remoteproc: Fix and restore the parenting hierarchy for vdev
Tero Kristo (1):
remoteproc: Fall back to using parent memory pool if no dedicated
available
drivers/remoteproc/remoteproc_core.c | 2 +-
drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
2 files changed, 13 insertions(+), 1 deletion(-)
--
2.26.0
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH v3 1/2] remoteproc: Fall back to using parent memory pool if no dedicated available
2020-04-20 16:05 [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support Suman Anna
2020-04-20 16:05 ` Suman Anna
@ 2020-04-20 16:05 ` Suman Anna
2020-04-20 16:05 ` Suman Anna
` (2 more replies)
2020-04-20 16:06 ` [PATCH v3 2/2] remoteproc: Fix and restore the parenting hierarchy for vdev Suman Anna
` (2 subsequent siblings)
4 siblings, 3 replies; 13+ messages in thread
From: Suman Anna @ 2020-04-20 16:05 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Mathieu Poirier, Arnaud Pouliquen, Loic Pallardy, Tero Kristo,
linux-remoteproc, linux-kernel, Suman Anna
From: Tero Kristo <t-kristo@ti.com>
In some cases, like with OMAP remoteproc, we are not creating dedicated
memory pool for the virtio device. Instead, we use the same memory pool
for all shared memories. The current virtio memory pool handling forces
a split between these two, as a separate device is created for it,
causing memory to be allocated from bad location if the dedicated pool
is not available. Fix this by falling back to using the parent device
memory pool if dedicated is not available.
Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v3:
- Go back to v1 logic (removed the vdevbuf_mem_id variable added in v2)
- Revised the comment to remove references to vdevbuf_mem_id
- Capitalize the patch header
v2: https://patchwork.kernel.org/patch/11447651/
drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_virtio.c b/drivers/remoteproc/remoteproc_virtio.c
index e61d738d9b47..44187fe43677 100644
--- a/drivers/remoteproc/remoteproc_virtio.c
+++ b/drivers/remoteproc/remoteproc_virtio.c
@@ -376,6 +376,18 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
goto out;
}
}
+ } else {
+ struct device_node *np = rproc->dev.parent->of_node;
+
+ /*
+ * If we don't have dedicated buffer, just attempt to re-assign
+ * the reserved memory from our parent. A default memory-region
+ * at index 0 from the parent's memory-regions is assigned for
+ * the rvdev dev to allocate from. Failure is non-critical and
+ * the allocations will fall back to global pools, so don't
+ * check return value either.
+ */
+ of_reserved_mem_device_init_by_idx(dev, np, 0);
}
/* Allocate virtio device */
--
2.26.0
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v3 1/2] remoteproc: Fall back to using parent memory pool if no dedicated available
2020-04-20 16:05 ` [PATCH v3 1/2] remoteproc: Fall back to using parent memory pool if no dedicated available Suman Anna
@ 2020-04-20 16:05 ` Suman Anna
2020-05-07 15:52 ` Arnaud POULIQUEN
2020-05-08 22:27 ` Mathieu Poirier
2 siblings, 0 replies; 13+ messages in thread
From: Suman Anna @ 2020-04-20 16:05 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Mathieu Poirier, Arnaud Pouliquen, Loic Pallardy, Tero Kristo,
linux-remoteproc, linux-kernel, Suman Anna
From: Tero Kristo <t-kristo@ti.com>
In some cases, like with OMAP remoteproc, we are not creating dedicated
memory pool for the virtio device. Instead, we use the same memory pool
for all shared memories. The current virtio memory pool handling forces
a split between these two, as a separate device is created for it,
causing memory to be allocated from bad location if the dedicated pool
is not available. Fix this by falling back to using the parent device
memory pool if dedicated is not available.
Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v3:
- Go back to v1 logic (removed the vdevbuf_mem_id variable added in v2)
- Revised the comment to remove references to vdevbuf_mem_id
- Capitalize the patch header
v2: https://patchwork.kernel.org/patch/11447651/
drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_virtio.c b/drivers/remoteproc/remoteproc_virtio.c
index e61d738d9b47..44187fe43677 100644
--- a/drivers/remoteproc/remoteproc_virtio.c
+++ b/drivers/remoteproc/remoteproc_virtio.c
@@ -376,6 +376,18 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
goto out;
}
}
+ } else {
+ struct device_node *np = rproc->dev.parent->of_node;
+
+ /*
+ * If we don't have dedicated buffer, just attempt to re-assign
+ * the reserved memory from our parent. A default memory-region
+ * at index 0 from the parent's memory-regions is assigned for
+ * the rvdev dev to allocate from. Failure is non-critical and
+ * the allocations will fall back to global pools, so don't
+ * check return value either.
+ */
+ of_reserved_mem_device_init_by_idx(dev, np, 0);
}
/* Allocate virtio device */
--
2.26.0
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH v3 1/2] remoteproc: Fall back to using parent memory pool if no dedicated available
2020-04-20 16:05 ` [PATCH v3 1/2] remoteproc: Fall back to using parent memory pool if no dedicated available Suman Anna
2020-04-20 16:05 ` Suman Anna
@ 2020-05-07 15:52 ` Arnaud POULIQUEN
2020-05-08 22:27 ` Mathieu Poirier
2 siblings, 0 replies; 13+ messages in thread
From: Arnaud POULIQUEN @ 2020-05-07 15:52 UTC (permalink / raw)
To: Suman Anna, Bjorn Andersson
Cc: Mathieu Poirier, Loic Pallardy, Tero Kristo, linux-remoteproc,
linux-kernel
Hi Suman
On 4/20/20 6:05 PM, Suman Anna wrote:
> From: Tero Kristo <t-kristo@ti.com>
>
> In some cases, like with OMAP remoteproc, we are not creating dedicated
> memory pool for the virtio device. Instead, we use the same memory pool
> for all shared memories. The current virtio memory pool handling forces
> a split between these two, as a separate device is created for it,
> causing memory to be allocated from bad location if the dedicated pool
> is not available. Fix this by falling back to using the parent device
> memory pool if dedicated is not available.
As it fixes the implementation of the legacy, that seems reasonable to me.
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
>
> Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> v3:
> - Go back to v1 logic (removed the vdevbuf_mem_id variable added in v2)
> - Revised the comment to remove references to vdevbuf_mem_id
> - Capitalize the patch header
> v2: https://patchwork.kernel.org/patch/11447651/
>
> drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/remoteproc/remoteproc_virtio.c b/drivers/remoteproc/remoteproc_virtio.c
> index e61d738d9b47..44187fe43677 100644
> --- a/drivers/remoteproc/remoteproc_virtio.c
> +++ b/drivers/remoteproc/remoteproc_virtio.c
> @@ -376,6 +376,18 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
> goto out;
> }
> }
> + } else {
> + struct device_node *np = rproc->dev.parent->of_node;
> +
> + /*
> + * If we don't have dedicated buffer, just attempt to re-assign
> + * the reserved memory from our parent. A default memory-region
> + * at index 0 from the parent's memory-regions is assigned for
> + * the rvdev dev to allocate from. Failure is non-critical and
> + * the allocations will fall back to global pools, so don't
> + * check return value either.
> + */
> + of_reserved_mem_device_init_by_idx(dev, np, 0);
> }
>
> /* Allocate virtio device */
>
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH v3 1/2] remoteproc: Fall back to using parent memory pool if no dedicated available
2020-04-20 16:05 ` [PATCH v3 1/2] remoteproc: Fall back to using parent memory pool if no dedicated available Suman Anna
2020-04-20 16:05 ` Suman Anna
2020-05-07 15:52 ` Arnaud POULIQUEN
@ 2020-05-08 22:27 ` Mathieu Poirier
2 siblings, 0 replies; 13+ messages in thread
From: Mathieu Poirier @ 2020-05-08 22:27 UTC (permalink / raw)
To: Suman Anna
Cc: Bjorn Andersson, Arnaud Pouliquen, Loic Pallardy, Tero Kristo,
linux-remoteproc, Linux Kernel Mailing List
On Mon, 20 Apr 2020 at 10:07, Suman Anna <s-anna@ti.com> wrote:
>
> From: Tero Kristo <t-kristo@ti.com>
>
> In some cases, like with OMAP remoteproc, we are not creating dedicated
> memory pool for the virtio device. Instead, we use the same memory pool
> for all shared memories. The current virtio memory pool handling forces
> a split between these two, as a separate device is created for it,
> causing memory to be allocated from bad location if the dedicated pool
> is not available. Fix this by falling back to using the parent device
> memory pool if dedicated is not available.
>
> Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> ---
> v3:
> - Go back to v1 logic (removed the vdevbuf_mem_id variable added in v2)
> - Revised the comment to remove references to vdevbuf_mem_id
> - Capitalize the patch header
> v2: https://patchwork.kernel.org/patch/11447651/
>
> drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/remoteproc/remoteproc_virtio.c b/drivers/remoteproc/remoteproc_virtio.c
> index e61d738d9b47..44187fe43677 100644
> --- a/drivers/remoteproc/remoteproc_virtio.c
> +++ b/drivers/remoteproc/remoteproc_virtio.c
> @@ -376,6 +376,18 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
> goto out;
> }
> }
> + } else {
> + struct device_node *np = rproc->dev.parent->of_node;
> +
> + /*
> + * If we don't have dedicated buffer, just attempt to re-assign
> + * the reserved memory from our parent. A default memory-region
> + * at index 0 from the parent's memory-regions is assigned for
> + * the rvdev dev to allocate from. Failure is non-critical and
> + * the allocations will fall back to global pools, so don't
> + * check return value either.
> + */
> + of_reserved_mem_device_init_by_idx(dev, np, 0);
> }
>
> /* Allocate virtio device */
> --
> 2.26.0
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v3 2/2] remoteproc: Fix and restore the parenting hierarchy for vdev
2020-04-20 16:05 [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support Suman Anna
2020-04-20 16:05 ` Suman Anna
2020-04-20 16:05 ` [PATCH v3 1/2] remoteproc: Fall back to using parent memory pool if no dedicated available Suman Anna
@ 2020-04-20 16:06 ` Suman Anna
2020-04-20 16:06 ` Suman Anna
2020-05-02 18:29 ` [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support Suman Anna
2020-05-13 6:20 ` patchwork-bot+linux-remoteproc
4 siblings, 1 reply; 13+ messages in thread
From: Suman Anna @ 2020-04-20 16:06 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Mathieu Poirier, Arnaud Pouliquen, Loic Pallardy, Tero Kristo,
linux-remoteproc, linux-kernel, Suman Anna
The commit 086d08725d34 ("remoteproc: create vdev subdevice with specific
dma memory pool") has introduced a new vdev subdevice for each vdev
declared in the firmware resource table and made it as the parent for the
created virtio rpmsg devices instead of the previous remoteproc device.
This changed the overall parenting hierarchy for the rpmsg devices, which
were children of virtio devices, and does not allow the corresponding
rpmsg drivers to retrieve the parent rproc device through the
rproc_get_by_child() API.
Fix this by restoring the remoteproc device as the parent. The new vdev
subdevice can continue to inherit the DMA attributes from the remoteproc's
parent device (actual platform device).
Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
---
v3: No changes
v2: https://patchwork.kernel.org/patch/11447653/
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 e12a54e67588..be15aace9b3c 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -517,7 +517,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct fw_rsc_vdev *rsc,
/* Initialise vdev subdevice */
snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
- rvdev->dev.parent = rproc->dev.parent;
+ rvdev->dev.parent = &rproc->dev;
rvdev->dev.dma_pfn_offset = rproc->dev.parent->dma_pfn_offset;
rvdev->dev.release = rproc_rvdev_release;
dev_set_name(&rvdev->dev, "%s#%s", dev_name(rvdev->dev.parent), name);
--
2.26.0
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v3 2/2] remoteproc: Fix and restore the parenting hierarchy for vdev
2020-04-20 16:06 ` [PATCH v3 2/2] remoteproc: Fix and restore the parenting hierarchy for vdev Suman Anna
@ 2020-04-20 16:06 ` Suman Anna
0 siblings, 0 replies; 13+ messages in thread
From: Suman Anna @ 2020-04-20 16:06 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Mathieu Poirier, Arnaud Pouliquen, Loic Pallardy, Tero Kristo,
linux-remoteproc, linux-kernel, Suman Anna
The commit 086d08725d34 ("remoteproc: create vdev subdevice with specific
dma memory pool") has introduced a new vdev subdevice for each vdev
declared in the firmware resource table and made it as the parent for the
created virtio rpmsg devices instead of the previous remoteproc device.
This changed the overall parenting hierarchy for the rpmsg devices, which
were children of virtio devices, and does not allow the corresponding
rpmsg drivers to retrieve the parent rproc device through the
rproc_get_by_child() API.
Fix this by restoring the remoteproc device as the parent. The new vdev
subdevice can continue to inherit the DMA attributes from the remoteproc's
parent device (actual platform device).
Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
---
v3: No changes
v2: https://patchwork.kernel.org/patch/11447653/
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 e12a54e67588..be15aace9b3c 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -517,7 +517,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct fw_rsc_vdev *rsc,
/* Initialise vdev subdevice */
snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
- rvdev->dev.parent = rproc->dev.parent;
+ rvdev->dev.parent = &rproc->dev;
rvdev->dev.dma_pfn_offset = rproc->dev.parent->dma_pfn_offset;
rvdev->dev.release = rproc_rvdev_release;
dev_set_name(&rvdev->dev, "%s#%s", dev_name(rvdev->dev.parent), name);
--
2.26.0
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support
2020-04-20 16:05 [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support Suman Anna
` (2 preceding siblings ...)
2020-04-20 16:06 ` [PATCH v3 2/2] remoteproc: Fix and restore the parenting hierarchy for vdev Suman Anna
@ 2020-05-02 18:29 ` Suman Anna
2020-05-08 15:14 ` Suman Anna
2020-05-13 6:20 ` patchwork-bot+linux-remoteproc
4 siblings, 1 reply; 13+ messages in thread
From: Suman Anna @ 2020-05-02 18:29 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Mathieu Poirier, Arnaud Pouliquen, Loic Pallardy, Tero Kristo,
linux-remoteproc, linux-kernel
Hi Bjorn,
On 4/20/20 11:05 AM, Suman Anna wrote:
> Hi Bjorn,
>
> This is another minor revision of the fixes around fixed memory region
> support [1] series. Patch 1 is revised to go back to the logic used in v1
> after a long discussion on the v2 version [2]. The other suggestions can
> be future improvments as they would require corresponding platform driver
> changes. Please look through the discussion there and let us know your
> preference. Patches are based on v5.7-rc1.
>
> I really appreciate it if you can target the series for the current 5.7 -rc's.
> The fixes would apply for all 5.1+ kernels.
Ping on these.
regards
Suman
>
> Please see the v1 cover-letter [1] for the details on the issues.
>
> regards
> Suman
>
> [1] https://patchwork.kernel.org/cover/11422723/
> [2] https://patchwork.kernel.org/comment/23274389/
>
> Suman Anna (1):
> remoteproc: Fix and restore the parenting hierarchy for vdev
>
> Tero Kristo (1):
> remoteproc: Fall back to using parent memory pool if no dedicated
> available
>
> drivers/remoteproc/remoteproc_core.c | 2 +-
> drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support
2020-05-02 18:29 ` [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support Suman Anna
@ 2020-05-08 15:14 ` Suman Anna
2020-05-12 23:10 ` Bjorn Andersson
0 siblings, 1 reply; 13+ messages in thread
From: Suman Anna @ 2020-05-08 15:14 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Mathieu Poirier, Arnaud Pouliquen, Loic Pallardy, Tero Kristo,
linux-remoteproc, linux-kernel
Hi Bjorn,
On 5/2/20 1:29 PM, Suman Anna wrote:
> Hi Bjorn,
>
> On 4/20/20 11:05 AM, Suman Anna wrote:
>> Hi Bjorn,
>>
>> This is another minor revision of the fixes around fixed memory region
>> support [1] series. Patch 1 is revised to go back to the logic used in v1
>> after a long discussion on the v2 version [2]. The other suggestions can
>> be future improvments as they would require corresponding platform driver
>> changes. Please look through the discussion there and let us know your
>> preference. Patches are based on v5.7-rc1.
>>
>> I really appreciate it if you can target the series for the current
>> 5.7 -rc's.
>> The fixes would apply for all 5.1+ kernels.
>
> Ping on these.
The patches have been reviewed and/or acked by both Mathieu and Arnaud.
Can you please get these into the current -rc's?
Thanks,
Suman
>
> regards
> Suman
>
>>
>> Please see the v1 cover-letter [1] for the details on the issues.
>>
>> regards
>> Suman
>>
>> [1] https://patchwork.kernel.org/cover/11422723/
>> [2] https://patchwork.kernel.org/comment/23274389/
>>
>> Suman Anna (1):
>> remoteproc: Fix and restore the parenting hierarchy for vdev
>>
>> Tero Kristo (1):
>> remoteproc: Fall back to using parent memory pool if no dedicated
>> available
>>
>> drivers/remoteproc/remoteproc_core.c | 2 +-
>> drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
>> 2 files changed, 13 insertions(+), 1 deletion(-)
>>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support
2020-05-08 15:14 ` Suman Anna
@ 2020-05-12 23:10 ` Bjorn Andersson
2020-05-13 9:50 ` Tero Kristo
0 siblings, 1 reply; 13+ messages in thread
From: Bjorn Andersson @ 2020-05-12 23:10 UTC (permalink / raw)
To: Suman Anna
Cc: Mathieu Poirier, Arnaud Pouliquen, Loic Pallardy, Tero Kristo,
linux-remoteproc, linux-kernel
On Fri 08 May 08:14 PDT 2020, Suman Anna wrote:
> Hi Bjorn,
>
> On 5/2/20 1:29 PM, Suman Anna wrote:
> > Hi Bjorn,
> >
> > On 4/20/20 11:05 AM, Suman Anna wrote:
> > > Hi Bjorn,
> > >
> > > This is another minor revision of the fixes around fixed memory region
> > > support [1] series. Patch 1 is revised to go back to the logic used in v1
> > > after a long discussion on the v2 version [2]. The other suggestions can
> > > be future improvments as they would require corresponding platform driver
> > > changes. Please look through the discussion there and let us know your
> > > preference. Patches are based on v5.7-rc1.
> > >
> > > I really appreciate it if you can target the series for the current
> > > 5.7 -rc's.
> > > The fixes would apply for all 5.1+ kernels.
> >
> > Ping on these.
>
> The patches have been reviewed and/or acked by both Mathieu and Arnaud.
Thanks for the reviews!
> Can you please get these into the current -rc's?
>
The offending patch appeared in 5.1, so I have a hard time claiming that
this is a regression in 5.7-rc. I've added Cc: stable and picked the two
patches for 5.8.
Thanks,
Bjorn
> Thanks,
> Suman
>
> >
> > regards
> > Suman
> >
> > >
> > > Please see the v1 cover-letter [1] for the details on the issues.
> > >
> > > regards
> > > Suman
> > >
> > > [1] https://patchwork.kernel.org/cover/11422723/
> > > [2] https://patchwork.kernel.org/comment/23274389/
> > >
> > > Suman Anna (1):
> > > remoteproc: Fix and restore the parenting hierarchy for vdev
> > >
> > > Tero Kristo (1):
> > > remoteproc: Fall back to using parent memory pool if no dedicated
> > > available
> > >
> > > drivers/remoteproc/remoteproc_core.c | 2 +-
> > > drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
> > > 2 files changed, 13 insertions(+), 1 deletion(-)
> > >
> >
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support
2020-05-12 23:10 ` Bjorn Andersson
@ 2020-05-13 9:50 ` Tero Kristo
0 siblings, 0 replies; 13+ messages in thread
From: Tero Kristo @ 2020-05-13 9:50 UTC (permalink / raw)
To: Bjorn Andersson, Suman Anna
Cc: Mathieu Poirier, Arnaud Pouliquen, Loic Pallardy,
linux-remoteproc, linux-kernel
On 13/05/2020 02:10, Bjorn Andersson wrote:
> On Fri 08 May 08:14 PDT 2020, Suman Anna wrote:
>
>> Hi Bjorn,
>>
>> On 5/2/20 1:29 PM, Suman Anna wrote:
>>> Hi Bjorn,
>>>
>>> On 4/20/20 11:05 AM, Suman Anna wrote:
>>>> Hi Bjorn,
>>>>
>>>> This is another minor revision of the fixes around fixed memory region
>>>> support [1] series. Patch 1 is revised to go back to the logic used in v1
>>>> after a long discussion on the v2 version [2]. The other suggestions can
>>>> be future improvments as they would require corresponding platform driver
>>>> changes. Please look through the discussion there and let us know your
>>>> preference. Patches are based on v5.7-rc1.
>>>>
>>>> I really appreciate it if you can target the series for the current
>>>> 5.7 -rc's.
>>>> The fixes would apply for all 5.1+ kernels.
>>>
>>> Ping on these.
>>
>> The patches have been reviewed and/or acked by both Mathieu and Arnaud.
>
> Thanks for the reviews!
>
>> Can you please get these into the current -rc's?
>>
>
> The offending patch appeared in 5.1, so I have a hard time claiming that
> this is a regression in 5.7-rc. I've added Cc: stable and picked the two
> patches for 5.8.
Thanks Bjorn,
I believe 5.8 should be fine, we can backport this internally if needed.
-Tero
>
> Thanks,
> Bjorn
>
>> Thanks,
>> Suman
>>
>>>
>>> regards
>>> Suman
>>>
>>>>
>>>> Please see the v1 cover-letter [1] for the details on the issues.
>>>>
>>>> regards
>>>> Suman
>>>>
>>>> [1] https://patchwork.kernel.org/cover/11422723/
>>>> [2] https://patchwork.kernel.org/comment/23274389/
>>>>
>>>> Suman Anna (1):
>>>> remoteproc: Fix and restore the parenting hierarchy for vdev
>>>>
>>>> Tero Kristo (1):
>>>> remoteproc: Fall back to using parent memory pool if no dedicated
>>>> available
>>>>
>>>> drivers/remoteproc/remoteproc_core.c | 2 +-
>>>> drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
>>>> 2 files changed, 13 insertions(+), 1 deletion(-)
>>>>
>>>
>>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support
2020-04-20 16:05 [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support Suman Anna
` (3 preceding siblings ...)
2020-05-02 18:29 ` [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support Suman Anna
@ 2020-05-13 6:20 ` patchwork-bot+linux-remoteproc
4 siblings, 0 replies; 13+ messages in thread
From: patchwork-bot+linux-remoteproc @ 2020-05-13 6:20 UTC (permalink / raw)
To: Suman Anna; +Cc: linux-remoteproc
Hello:
This series was applied to andersson/remoteproc.git (refs/heads/for-next).
On Mon, 20 Apr 2020 11:05:58 -0500 you wrote:
> Hi Bjorn,
>
> This is another minor revision of the fixes around fixed memory region
> support [1] series. Patch 1 is revised to go back to the logic used in v1
> after a long discussion on the v2 version [2]. The other suggestions can
> be future improvments as they would require corresponding platform driver
> changes. Please look through the discussion there and let us know your
> preference. Patches are based on v5.7-rc1.
>
> [...]
Here is a summary with links:
- [v3,1/2] remoteproc: Fall back to using parent memory pool if no dedicated available
https://git.kernel.org/andersson/remoteproc/c/db9178a4f8c4e523f824892cb8bab00961b07385
- [v3,2/2] remoteproc: Fix and restore the parenting hierarchy for vdev
https://git.kernel.org/andersson/remoteproc/c/c774ad010873bb89dcc0cdcb1e96aef6664d8caf
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/pwbot
^ permalink raw reply [flat|nested] 13+ messages in thread