[PATCH 1/2] soc: ti: Use remoteproc auto_boot feature

Suman Anna s-anna at ti.com
Fri Dec 23 09:05:58 PST 2016


Hi Sarang,

>>
>> On 12/15/2016 06:03 PM, Sarangdhar Joshi wrote:
>>> The function wkup_m3_rproc_boot_thread waits for asynchronous
>>> firmware loading to complete successfully before calling
>>> rproc_boot(). The same can be achieved by just setting
>>> rproc->auto_boot flag. Change this. As a result this change
>>> removes wkup_m3_rproc_boot_thread and moves m3_ipc->sync_complete
>>> initialization to the wkup_m3_ipc_probe().
>>>
>>> Other than the current usage, the firmware_loading_complete is
>>> only used in rproc_del() where it's no longer needed.  This
>>> change is in preparation for removing firmware_loading_complete
>>> completely.
>>
>> Based on the comments so far, I am assuming that you are dropping this
>> series.
> 
> No, may not be dropping this. Will try to handle it differently in
> rproc_del() (probably by making use of some state flag).
>>
>> In any case, this series did break our PM stack. We definitely don't
>> want to auto-boot the wkup_m3_rproc device, that responsibility will
>> need to stay with the wkup_m3_ipc driver.
> 
> Which scenario did it break? Booting up rproc device before
> wkup_m3_ipc_probe() causes issues?

Yes, our state machine requires the wkup_m3_ipc driver to control the
boot of the wkup_m3 remoteproc. The wkup_m3 is not a typical remoteproc,
it is our PM master and is responsible for putting the host processor
into suspend and waking it up in system suspend/cpuidle paths.
The remoteproc infrastructure is only used for load/boot, but the Linux
PM state machine and communication is all controlled by the wkup_m3_ipc
driver.

> 
> Nevertheless, I think Bjorn's suggestion of just dropping the call to
> wait_for_completion() and keeping kthread looks good, also because of
> the fact that rproc_boot() anyways calls request_firmware() and no
> longer needed to wait on asynchronous loading of firmware.

Yeah, I will have to test this, but looking at current code, this should
mostly be ok because of the remoteproc core changes w.r.t resource table
parsing.

regards
Suman



More information about the linux-arm-kernel mailing list