On 12/05/2016 11:26 PM, Bjorn Andersson wrote:

On Mon 14 Nov 14:21 PST 2016, Stephen Boyd wrote:

quoted

On 11/11, Georgi Djakov wrote:

quoted

On 11/03/2016 08:28 PM, Bjorn Andersson wrote:

[..]

quoted

quoted

quoted

I'm in favour of us inventing a kicker API and it's found outside out
use cases as well (e.g. virtio/rpmsg).

I'd rather we did this kicker API as well. That way we don't need
to make a syscon and a simple-mfd to get software to work
properly. Don't other silicon vendors need a kicker API as well?
How are they kicking remote processors in other places? GPIOs?

In remoteproc I have two of these:
1) da8xx_remoteproc ioremaps a register and writes a bit in it (looks
   similar to the downstream Qualcomm way)

2) omap_remoteproc acquires a mbox channel, in which it writes a
   virtqueue id to kick the remote.

So one of the two cases could have used such mechanism.

I also see the potential users of such API mostly in the 
remoteproc/rpmgs subsystems.

We could write up a Qualcomm specific "kicker" and probe the mailing
list regarding the interest in making that generic (i.e. changing the
names in the API and DT binding).

Yes, i am planing to do this.

The sucky part is that I believe we have most of our kickers in place
already so rpm, smd, smp2p, smsm etc would all need to support both
mechanisms.

Agree.. we have to keep compatibility with existing dtbs.

Thanks,
Georgi