On 02/11/17 12:21, Jassi Brar wrote: > On Thu, Nov 2, 2017 at 5:19 PM, Sudeep Holla <sudeep.ho...@arm.com> wrote: >> On 02/11/17 11:26, Jassi Brar wrote: > >>>>> 1) Where does the "whatever_value_to_trigger_signal" come from? >>>> >>>> Controller specific. >>>> >>>>> That has to come from client. >>>> >>>> No. >>>> >>> Again, let me know what does the controller expect 'val' to be >>> >>> writel(val, MAILBOX_A2B_CMD(chans->idx)) >>> >> >> It depends on the controller. Whatever value that can generate a signal >> to remote. >> > As you _know_, the controller expects any non-zero value. Now what > value would you write in there? >
I just said its *non-zero value* to give example. What action needs to be done to trigger the doorbell is *entirely* controller specific and typically it's a bit in the register. >> >> 1. pcc_send_data (drivers/mailbox/pcc.c) >> 2. sti_mbox_send_data (drivers/mailbox/mailbox-sti.c) >> 3. qcom_apcs_ipc_send_data (drivers/mailbox/qcom-apcs-ipc-mailbox.c) >> 4. tegra_hsp_doorbell_send_data (drivers/mailbox/tegra-hsp.c) >> >> And SCMI fits the above case. >> > These are only 4 out of 14. Can we overlook that your implementation > rules out 70% controllers. > I am *not* saying we will break other 10 controllers. All I am says there are 4 controllers that can make use of this new feature. 4 is good number IMO to generalize something. > BTW these 4 don't even need any send_signal() api, they would remain > unchanged. What's the new api for? > Sure, it's working fine doesn't mean it can't be used at all. That's not a right argument TBH. -- Regards, Sudeep
