| Message ID | 1472676622-32533-8-git-send-email-loic.pallardy@st.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 > -- To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 > -- To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h index d0c0793..4e2f822 100644 --- a/include/linux/remoteproc.h +++ b/include/linux/remoteproc.h @@ -100,6 +100,7 @@ struct fw_rsc_hdr { * the remote processor will be writing logs. * @RSC_VDEV: declare support for a virtio device, and serve as its * virtio header. + * @RSC_SPARE: spare area in resource table for resource appending * @RSC_LAST: just keep this one at the end * * For more details regarding a specific resource type, please see its @@ -115,7 +116,8 @@ enum fw_resource_type { RSC_DEVMEM = 1, RSC_TRACE = 2, RSC_VDEV = 3, - RSC_LAST = 4, + RSC_SPARE = 4, + RSC_LAST = 5, }; #define FW_RSC_ADDR_ANY (0xFFFFFFFFFFFFFFFF) @@ -306,6 +308,15 @@ struct fw_rsc_vdev { } __packed; /** + * struct fw_rsc_spare - resource table spare area definition + * @len: length of spare area in byte + */ +struct fw_rsc_spare { + u32 len; + u8 spare_bytes[0]; +} __packed; + +/** * struct rproc_mem_entry - memory entry descriptor * @va: virtual address * @dma: dma address
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. Signed-off-by: Loic Pallardy <loic.pallardy@st.com> --- include/linux/remoteproc.h | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)