Re: [PATCH] mailbox: add support for doorbell/signal mode controllers

[Jassi Brar]

On Thu, Nov 2, 2017 at 6:07 PM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
> On 02/11/17 12:21, Jassi Brar wrote:
>> On Thu, Nov 2, 2017 at 5:19 PM, Sudeep Holla <sudeep.holla@xxxxxxx> 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.
>
Please read the above full context and see how you wasted 4 posts just
because you had to refute my any explanation.

>>>
>>> 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.
>
If all you want to support is these 4 controllers why mess with the api?!

These 4 controllers don't use the data pointer, just use the existing
API as such
  mbox_send_message(chan, NULL);


>> 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.
>
API real estate is very precious. No redundancy should be added,
unless absolutely necessary.