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


Groups > linux.kernel > #1484445 > unrolled thread

Re: [PATCH v2 07/19] remoteproc: Add new resource type for resource table spare bytes

Started byBjorn Andersson <bjorn.andersson@linaro.org>
First post2016-09-15 20:00 +0200
Last post2016-09-19 10:00 +0200
Articles 4 — 2 participants

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 v2 07/19] remoteproc: Add new resource type for resource  table spare bytes Bjorn Andersson <bjorn.andersson@linaro.org> - 2016-09-15 20:00 +0200
    Re: [PATCH v2 07/19] remoteproc: Add new resource type for resource  table spare bytes loic pallardy <loic.pallardy@st.com> - 2016-09-16 11:10 +0200
      Re: [PATCH v2 07/19] remoteproc: Add new resource type for resource  table spare bytes Bjorn Andersson <bjorn.andersson@linaro.org> - 2016-09-16 19:20 +0200
        Re: [PATCH v2 07/19] remoteproc: Add new resource type for resource  table spare bytes loic pallardy <loic.pallardy@st.com> - 2016-09-19 10:00 +0200

#1484445 — Re: [PATCH v2 07/19] remoteproc: Add new resource type for resource table spare bytes

FromBjorn Andersson <bjorn.andersson@linaro.org>
Date2016-09-15 20:00 +0200
SubjectRe: [PATCH v2 07/19] remoteproc: Add new resource type for resource table spare bytes
Message-ID<shJ74-1GD-27@gated-at.bofh.it>
On Wed 31 Aug 13:50 PDT 2016, Loic Pallardy wrote:

> To allow resource appending to an existing resource table,
> remoteproc framework should get information about resource
> table spare area. With current resource table construction,
> remoteproc is not able to identify by itself any free location.
> This patch introduces a new resource type named RSC_SPARE which
> allows firmware to define room for resource table extension.
> Defined spare area will be used by remtoreproc to extend resource
> table.
> 

We don't need a dummy type for keeping track of the available room in
the resource table in the loaded firmware. All we need to do is to look
at the sh_size of the .resource_table section, which actually is what's
returned in tablesz.

So the spare size is the difference between tablesz and the end of the
last resource and if you need you can pad this when composing the
firmware.

Regards,
Bjorn

[toc] | [next] | [standalone]


#1484824

Fromloic pallardy <loic.pallardy@st.com>
Date2016-09-16 11:10 +0200
Message-ID<shXjI-2Fs-5@gated-at.bofh.it>
In reply to#1484445

On 09/15/2016 07:54 PM, Bjorn Andersson wrote:
> On Wed 31 Aug 13:50 PDT 2016, Loic Pallardy wrote:
>
>> To allow resource appending to an existing resource table,
>> remoteproc framework should get information about resource
>> table spare area. With current resource table construction,
>> remoteproc is not able to identify by itself any free location.
>> This patch introduces a new resource type named RSC_SPARE which
>> allows firmware to define room for resource table extension.
>> Defined spare area will be used by remtoreproc to extend resource
>> table.
>>
>
> We don't need a dummy type for keeping track of the available room in
> the resource table in the loaded firmware. All we need to do is to look
> at the sh_size of the .resource_table section, which actually is what's
> returned in tablesz.
>
This is the size of the .resource_table section. Doesn't means that only 
resource table is stored in. Today this is the assumption and we force 
firmware to respect this.

> So the spare size is the difference between tablesz and the end of the
> last resource and if you need you can pad this when composing the
> firmware.
>
Proposal was to clearly identify the area for extension (whatever 
.resource_table section is done). But if you agree on the fact 
.resource_tabel section constains only resource table and eventualy room 
for extension, I can indeed simply room detection.

Regards,
Loic

> Regards,
> Bjorn
>

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


#1485186

FromBjorn Andersson <bjorn.andersson@linaro.org>
Date2016-09-16 19:20 +0200
Message-ID<si4XU-7Hc-11@gated-at.bofh.it>
In reply to#1484824
On Fri 16 Sep 02:02 PDT 2016, loic pallardy wrote:

> 
> 
> On 09/15/2016 07:54 PM, Bjorn Andersson wrote:
> >On Wed 31 Aug 13:50 PDT 2016, Loic Pallardy wrote:
> >
> >>To allow resource appending to an existing resource table,
> >>remoteproc framework should get information about resource
> >>table spare area. With current resource table construction,
> >>remoteproc is not able to identify by itself any free location.
> >>This patch introduces a new resource type named RSC_SPARE which
> >>allows firmware to define room for resource table extension.
> >>Defined spare area will be used by remtoreproc to extend resource
> >>table.
> >>
> >
> >We don't need a dummy type for keeping track of the available room in
> >the resource table in the loaded firmware. All we need to do is to look
> >at the sh_size of the .resource_table section, which actually is what's
> >returned in tablesz.
> >
> This is the size of the .resource_table section. Doesn't means that only
> resource table is stored in.

I'm not sure I'm getting the details of what you're saying here. Do you
mean that there could be other things in the resource_table section or
just the fact that it being a section doesn't give any information about
how much space this thing will have in loaded form.

> Today this is the assumption and we force firmware to respect this.
> 

I find it unfortunate that this was put in section and that we just have
to make assumptions on how this projects onto the loaded form.

> >So the spare size is the difference between tablesz and the end of the
> >last resource and if you need you can pad this when composing the
> >firmware.
> >
> Proposal was to clearly identify the area for extension (whatever
> .resource_table section is done). But if you agree on the fact
> .resource_tabel section constains only resource table and eventualy room for
> extension, I can indeed simply room detection.
> 

Could you describe your use case for programmatically generate a
resource table for a firmware without a .resource_table? I would like to
understand the contract between the driver and the firmware when it
comes to what should go into the resource table.

Regards,
Bjorn

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


#1486226

Fromloic pallardy <loic.pallardy@st.com>
Date2016-09-19 10:00 +0200
Message-ID<sj1EC-2Bu-9@gated-at.bofh.it>
In reply to#1485186

On 09/16/2016 07:12 PM, Bjorn Andersson wrote:
> On Fri 16 Sep 02:02 PDT 2016, loic pallardy wrote:
>
>>
>>
>> On 09/15/2016 07:54 PM, Bjorn Andersson wrote:
>>> On Wed 31 Aug 13:50 PDT 2016, Loic Pallardy wrote:
>>>
>>>> To allow resource appending to an existing resource table,
>>>> remoteproc framework should get information about resource
>>>> table spare area. With current resource table construction,
>>>> remoteproc is not able to identify by itself any free location.
>>>> This patch introduces a new resource type named RSC_SPARE which
>>>> allows firmware to define room for resource table extension.
>>>> Defined spare area will be used by remtoreproc to extend resource
>>>> table.
>>>>
>>>
>>> We don't need a dummy type for keeping track of the available room in
>>> the resource table in the loaded firmware. All we need to do is to look
>>> at the sh_size of the .resource_table section, which actually is what's
>>> returned in tablesz.
>>>
>> This is the size of the .resource_table section. Doesn't means that only
>> resource table is stored in.
>
> I'm not sure I'm getting the details of what you're saying here. Do you
> mean that there could be other things in the resource_table section or
> just the fact that it being a section doesn't give any information about
> how much space this thing will have in loaded form.
>
>> Today this is the assumption and we force firmware to respect this.
>>
>
> I find it unfortunate that this was put in section and that we just have
> to make assumptions on how this projects onto the loaded form.
>
>>> So the spare size is the difference between tablesz and the end of the
>>> last resource and if you need you can pad this when composing the
>>> firmware.
>>>
>> Proposal was to clearly identify the area for extension (whatever
>> .resource_table section is done). But if you agree on the fact
>> .resource_tabel section constains only resource table and eventualy room for
>> extension, I can indeed simply room detection.
>>
>
> Could you describe your use case for programmatically generate a
> resource table for a firmware without a .resource_table? I would like to
> understand the contract between the driver and the firmware when it
> comes to what should go into the resource table.

No I always consider .resource_table section.
You answer to my point just above. .resource_table section must contain 
only the resource table and nothing else. I'm fine with that.

I'll revert RSC_SPARE type.

Regards,
Loic
>
> Regards,
> Bjorn
>

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web