Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1423513 > unrolled thread

Re: [PATCH 4/5] remoteproc: core: Supply framework to request, declare and fetch shared memory

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 4/5] remoteproc: core: Supply framework to request,  declare and fetch shared memory Bjorn Andersson <bjorn.andersson@linaro.org> - 2016-06-16 00:10 +0200
    Re: [STLinux Kernel] [PATCH 4/5] remoteproc: core: Supply framework  to request, declare and fetch shared memory loic pallardy <loic.pallardy@st.com> - 2016-06-21 09:40 +0200
      Re: [STLinux Kernel] [PATCH 4/5] remoteproc: core: Supply framework  to request, declare and fetch shared memory Bjorn Andersson <bjorn.andersson@linaro.org> - 2016-06-22 18:30 +0200

#1423513 — Re: [PATCH 4/5] remoteproc: core: Supply framework to request, declare and fetch shared memory

On Thu 05 May 06:29 PDT 2016, Lee Jones wrote:

> Normally used for management of; carveout, devmem and trace memory.
> 
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  drivers/remoteproc/remoteproc_core.c | 174 +++++++++++++++++++++++++++++++++--
>  1 file changed, 167 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
[..]
> @@ -222,7 +223,8 @@ int rproc_alloc_vring(struct rproc_vdev *rvdev, int i)
[..]
> -	va = dma_alloc_coherent(dev->parent, size, &dma, GFP_KERNEL);
> +	dma_dev = rproc_subdev_lookup(rproc, "vring");
> +	va = dma_alloc_coherent(dma_dev, size, &dma, GFP_KERNEL);
[..]
> @@ -594,7 +599,8 @@ static int rproc_handle_carveout(struct rproc *rproc,
[..]
> -	va = dma_alloc_coherent(dev->parent, rsc->len, &dma, GFP_KERNEL);
> +	dma_dev = rproc_subdev_lookup(rproc, "carveout");
> +	va = dma_alloc_coherent(dma_dev, rsc->len, &dma, GFP_KERNEL);
[..]
> +static int rproc_subdev_match(struct device *dev, void *data)
> +{
> +	char *sub_name;
> +
> +	if (!dev_name(dev))
> +		return 0;
> +
> +	sub_name = strpbrk(dev_name(dev), "#");
> +	if (!sub_name)
> +		return 0;
> +
> +	return !strcmp(++sub_name, (char *)data);
> +}
> +
[..]
> +struct rproc_subdev *rproc_subdev_add(struct rproc *rproc, struct resource *res)
> +{
[..]
> +	dev_set_name(&sub->dev, "%s#%s", dev_name(sub->dev.parent), res->name);
> +	dev_set_drvdata(&sub->dev, sub);
> +
> +	ret = device_register(&sub->dev);
[..]
> +}
> +EXPORT_SYMBOL(rproc_subdev_add);

I worked up a prototype that allows remoteproc drivers to
programmatically specify carveout resources, which then are matched and
merged with entires from the resource table. I've given these
programmatically allocated carveouts a device so that the associated
allocation comes out of the specified region - or the rproc region if no
match is found.


This solves my use case of carving out memory from two disjoint memory
regions for one of my remoteprocs, but differs from your approach in
that you specify one large carveout (and vrings) region and any
carveouts (or vrings) will chip away from this.

Would this approach work for you, or do you depend on having 1:N
relationship between your memory region and your resources?

Regards,
Bjorn

[toc] | [next] | [standalone]

#1427408 — Re: [STLinux Kernel] [PATCH 4/5] remoteproc: core: Supply framework to request, declare and fetch shared memory

On 06/16/2016 12:06 AM, Bjorn Andersson wrote:
> On Thu 05 May 06:29 PDT 2016, Lee Jones wrote:
>
>> Normally used for management of; carveout, devmem and trace memory.
>>
>> Signed-off-by: Lee Jones <lee.jones@linaro.org>
>> ---
>>   drivers/remoteproc/remoteproc_core.c | 174 +++++++++++++++++++++++++++++++++--
>>   1 file changed, 167 insertions(+), 7 deletions(-)
>>
[..]
>> +}
>> +EXPORT_SYMBOL(rproc_subdev_add);
>
Hi Bjorn,

> I worked up a prototype that allows remoteproc drivers to
> programmatically specify carveout resources, which then are matched and
> merged with entires from the resource table. I've given these
> programmatically allocated carveouts a device so that the associated
> allocation comes out of the specified region - or the rproc region if no
> match is found.
>
No sure to catch your exact use case, but let me try to explain what we 
have today.
There are different rproc in ST. Some request a large chunk of memory 
for code and data, some have several dedicated memories like IRAM and DRAM.
In that case carevout memories are defined as subdev (like vrings).
Association is done thanks to carevout name in firmware resource table 
(in rproc_handle_carveout).

Moreover, as our coprocessors have no iommu, we add some check on 
allocated buffer to verify it fit with resource table declaration (pa).
This allows to guarantee complete alignment between resources needed by 
firmware and ones allocated by Linux kernel.
>
> This solves my use case of carving out memory from two disjoint memory
> regions for one of my remoteprocs, but differs from your approach in
> that you specify one large carveout (and vrings) region and any
> carveouts (or vrings) will chip away from this.
>
> Would this approach work for you, or do you depend on having 1:N
> relationship between your memory region and your resources?
>

Is this approach covering your needs?

Regards,
Loic

> Regards,
> Bjorn
>
> _______________________________________________
> Kernel mailing list
> Kernel@stlinux.com
> http://www.stlinux.com/mailman/listinfo/kernel
>

[toc] | [prev] | [next] | [standalone]

#1428961 — Re: [STLinux Kernel] [PATCH 4/5] remoteproc: core: Supply framework to request, declare and fetch shared memory

On Tue 21 Jun 00:33 PDT 2016, loic pallardy wrote:

> 
> 
> On 06/16/2016 12:06 AM, Bjorn Andersson wrote:
> >On Thu 05 May 06:29 PDT 2016, Lee Jones wrote:
> >
> >>Normally used for management of; carveout, devmem and trace memory.
> >>
> >>Signed-off-by: Lee Jones <lee.jones@linaro.org>
> >>---
> >>  drivers/remoteproc/remoteproc_core.c | 174 +++++++++++++++++++++++++++++++++--
> >>  1 file changed, 167 insertions(+), 7 deletions(-)
> >>
> [..]
> >>+}
> >>+EXPORT_SYMBOL(rproc_subdev_add);
> >
> Hi Bjorn,
> 

Hi Loic, thanks for your answer.

> >I worked up a prototype that allows remoteproc drivers to
> >programmatically specify carveout resources, which then are matched and
> >merged with entires from the resource table. I've given these
> >programmatically allocated carveouts a device so that the associated
> >allocation comes out of the specified region - or the rproc region if no
> >match is found.
> >
> No sure to catch your exact use case, but let me try to explain what we have
> today.
> There are different rproc in ST. Some request a large chunk of memory for
> code and data, some have several dedicated memories like IRAM and DRAM.
> In that case carevout memories are defined as subdev (like vrings).
> Association is done thanks to carevout name in firmware resource table (in
> rproc_handle_carveout).
> 

With the proposed solution you will only be able to have a single subdev
defining the "carveout" segment. I have a similar setup where I have two
disjoint memory regions that I would like to carve out memory from.

Further more, I don't have a resource table in my firmware, so I would
like to be able to register these carveout regions programmatically.

> Moreover, as our coprocessors have no iommu, we add some check on allocated
> buffer to verify it fit with resource table declaration (pa).
> This allows to guarantee complete alignment between resources needed by
> firmware and ones allocated by Linux kernel.

I have memory-regions defined in devicetree representing where my
carveouts should be, so the subdev proposal gives me a way to control
the physical placing of the carveout.


So, based on these "requirements" I had in working a patchset that
allows me to register carveout sections programatically and during the
load of the resource table I can merge carveouts (and the other
resources) to form the complete picture.


But this would imply a 1-to-1 relationship between programmatically
defined carveouts and carveouts from the resource table. Would you be
able to handle this? Or do you depend on being able to have your subdev
define the span and then a set of resources fill this up?

Regards,
Bjorn

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web