On Wed, 06 Jul 2016, Peter Griffin wrote: > When rproc drivers are built-in the async firmware load done by rproc_add() > can fail due to the firmware not being present. Subsqeuent calls to > rproc_fw_boot() then fail, even though by this point firmware has been > successfully obtained. > > This patch changes the behaviour to re-execute rproc_fw_config_virtio() > in rproc_fw_boot() if it has previously failed, and we are sure it is > now available. > > Signed-off-by: Peter Griffin <[email protected]> > --- > drivers/remoteproc/remoteproc_core.c | 25 +++++++++++++++++++------ > drivers/remoteproc/remoteproc_internal.h | 3 +++ > 2 files changed, 22 insertions(+), 6 deletions(-) > > diff --git a/drivers/remoteproc/remoteproc_core.c > b/drivers/remoteproc/remoteproc_core.c > index db3958b..749f261 100644 > --- a/drivers/remoteproc/remoteproc_core.c > +++ b/drivers/remoteproc/remoteproc_core.c > @@ -801,8 +801,12 @@ static int rproc_fw_boot(struct rproc *rproc, const > struct firmware *fw) > struct resource_table *table, *loaded_table; > int ret, tablesz; > > + /* > + * This can happen when built-in if initial async fw load fails. > + * However we now have firmware available so retry. > + */ > if (!rproc->table_ptr) > - return -ENOMEM; > + rproc_fw_config_virtio(fw, rproc);
It's probably better to "hold that thought" on this patch, since we're going to make resource tables optional. I'm keen to tackle this issue, but need to work a few other things before doing so. Current task list: - Amend/supply new resource table from platform-specific drivers - Make resource tables optional - Obtain firmwares from the root file system - Lots more here including; co-proc DT support, co-proc console, etc [...] -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
