Re: [RESEND/PATCH v6 3/3] clk: qcom: Add A53 clock driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 12/05/2016 11:26 PM, Bjorn Andersson wrote:
On Mon 14 Nov 14:21 PST 2016, Stephen Boyd wrote:

On 11/11, Georgi Djakov wrote:
On 11/03/2016 08:28 PM, Bjorn Andersson wrote:
[..]
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux