Message-ID: <b20b5878-902a-91e2-2b00-50d34d27a628@ti.com>
Date:	Thu, 11 Aug 2016 11:48:08 -0500
From:	Suman Anna <s-anna@...com>
To:	Bjorn Andersson <bjorn.andersson@...aro.org>,
	Loic PALLARDY <loic.pallardy@...com>
CC:	"linux-remoteproc@...r.kernel.org" <linux-remoteproc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Lee Jones <lee.jones@...aro.org>,
	Sarangdhar Joshi <spjoshi@...eaurora.org>,
	Eric FINCO <eric.finco@...com>,
	Russell Wayman <russell.wayman@...aro.org>,
	Matthew Locke <matthew.locke@...aro.org>,
	Kumar Gala <kumar.gala@...aro.org>,
	Bill Fletcher <bill.fletcher@...aro.org>,
	Puja Gupta <pujag@...eaurora.org>,
	Ohad Ben-Cohen <ohad@...ery.com>
Subject: Re: Ongoing remoteproc discussions

On 08/10/2016 03:22 PM, Bjorn Andersson wrote:
> On Wed 03 Aug 07:52 PDT 2016, Loic PALLARDY wrote:
> 
>>> == Auto-boot or always-on:
> [..]
>>>
>> [LPA] As already mentioned in patch review, I would prefer auto-boot
>> name rather than always-on for this feature.
> 
> Agreed.
> 
>> What about coprocessor already loaded and started at boot stage? It
>> may be the case of coprocessor used by bootloader and can't reset
>> without breaking use case or coprocessor with security constraints.
> 
> For the cases I've dealt with we just didn't represent the remote
> processor in the kernel, we just reserved the carveouts and communicated
> with it.

Yeah, we have a similar usecase as well, and we do want the remoteproc
to behave as in the normal case once the kernel has booted up and the
corresponding driver has been probed. We have had to do some magic (not
zeroing memory) for presenting the remoteproc still to Linux-side
applications and client drivers.

This indeed brings me one of the list of enhancements I have in mind -
to add an ops for individual driver control for allocating memory on
carveouts, vrings etc with a fall-back to the dma_alloc API in the
remoteproc core.

Bjorn, I take it that you are not using rpmsg here if that lifecycle is
managed separately from remoteproc.

> 
>> In that case, remoteproc should allocate rproc resource at linux level
>> and sync on current rproc state.
> 
> Sure.
> 
>>>
> [..]
>>> == Resource-less firmware:
>>> To be able to use remoteproc with firmware either without a resource table
>>> or resource data in other forms we today provide a resource table stub in
>>> each driver, instead we could refactor the resource table parsing code.
>>>
>>> * We replace the find_rsc_table operation in rproc_fw_ops with a parse
>>>   operation, that uses the newly created API (above) to register the
>>>   resources with the core; largely decoupling the resource table format
>>>   from the remoteproc core.
>>>
>>> * We make the parse() function in rproc_fw_ops optional, allowing
>>>   remoteproc drivers to specify that there's no resource parsing to be
>>>   done (they can still provide resources programmatically between
>>>   rproc_alloc() and rproc_add()).
>>>
>>> This setup allows custom resource building functions to be implemented,
>>> one such example is the Qualcomm firmware files where most resource data
>>> is a combination of static information (DT) and data from the ELF header.
>> [LPA] Do you have a list of resources you would like to support here?
> 
> With resources here I meant the existing remoteproc resources, i.e.
> carveouts, devmem, trace and vdev/vrings.
> 
>> In ST we plan to have DT for rproc resource description (PIO,
>> peripheral bus...). Today coprocessor resources are managed
>> dynamically using resource manager developed by TI on omap.
>> But this solution is consuming time and code size.
>> We would like to implement rproc resource allocation at rproc_boot
>> time, parsing associated DT section and getting the different
>> requested resources...

Yeah, this becomes somewhat complicated when we are talking about
peripherals, because it depends on they get used. I see the following
usage patterns:
1. do not instantiate the devices on Linux, and leave them to be managed
completely by s/w running on remoteproc.
2. resources that can be managed alongside the remoteproc state (request
them up before rproc_boot, and release them after rproc_shutdown). This
can always be done within the respective remoteproc driver as the
peripherals used are specific to each platform.
3. resources that only need to be managed at runtime, especially if the
PM around them in controlled on the Linux-side.

> 
> Are you talking about the resmgr found in downstream TI trees? What
> kinds of resources and how would this look like?
> 
>> Is it aligned with your view?
>>
> 
> I'm generally considering these resources (e.g. regulators exposed by
> resmgr) not being part of the life cycle management of the remote
> processor, but rather related to the application running on the remote
> processor; as such I don't think they should reside in the remoteproc
> core.

Agreed, we did use resmgr specifically for #3. It also allowed us to
recover these resources in case of a remoteproc crash while holding them.

> 
> That said, for resmgr to move upstream I think it needs to be
> generalized.

Indeed, the TI resmgr was written before DT, and it would need rework if
we were to go down that path.

That said, if the management is moving towards the System Control
Processor like frameworks, this won't be needed.

regards
Suman

> 
>>>
>>>
> [..]
>>> == Ramdump:
> [..]
>>>
>>>     * Shutdown the remoteproc
> 
>> [LPA] just a technical remark, shutting down the remoteproc may switch
>> off some power domain and disable access to remoteproc memories or
>> registers.
>> An intermediate state is need to allow snapshot generation.
> 
> Ahh, you're right. Then we need to complicate this dance a little bit,
> and probably make it possible for drivers to take part in it.
> 
>>
>>>     * Shutdown virtio devices
>>>     * Take snapshot
>>>     * Register virtio devices
>>>     * Start the remoteproc
>>>
> 
> Thanks for your reply Loic.
> 
> Regards,
> Bjorn
> 

Powered by blists - more mailing lists