On Wed, Dec 04, 2019 at 02:07:48PM +0100, Ahmad Fatoum wrote:
> Hello Sascha,
>
> On 11/25/19 9:28 AM, Sascha Hauer wrote:
> > I would assume that when I can stop the remote processor with this
> > parameter I should be able to start it here as well, no?
>
> I've yet to think some more about
Hello Sascha,
On 11/25/19 9:28 AM, Sascha Hauer wrote:
> I would assume that when I can stop the remote processor with this
> parameter I should be able to start it here as well, no?
I've yet to think some more about this, but could you merge the first
two commits now?
Cheers
Ahmad
--
On 11/25/19 9:28 AM, Sascha Hauer wrote:
> On Thu, Nov 21, 2019 at 09:40:05AM +0100, Ahmad Fatoum wrote:
>> Both the STM32 and i.MX7 remote proc drivers populate the .stop member
>> in the struct rproc, but it's not used anywhere.
>
> The .stop member in struct rproc is introduced in this patch.
On Thu, Nov 21, 2019 at 09:40:05AM +0100, Ahmad Fatoum wrote:
> Both the STM32 and i.MX7 remote proc drivers populate the .stop member
> in the struct rproc, but it's not used anywhere.
The .stop member in struct rproc is introduced in this patch.
> The firmware API is not
> really fitting to
Both the STM32 and i.MX7 remote proc drivers populate the .stop member
in the struct rproc, but it's not used anywhere. The firmware API is not
really fitting to 'unload' firmware. Add instead a device parameter to
stop a remote processor, e.g. remoteproc0.stop=1. This is similar to the
probe
