[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABb+yY11a3y8A8NGUXED8qzg0aS_ikMK-EvB3yG31kP5pewNNw@mail.gmail.com>
Date: Thu, 2 Nov 2017 17:51:56 +0530
From: Jassi Brar <jassisinghbrar@...il.com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Arnd Bergmann <arnd@...db.de>,
Bjorn Andersson <bjorn.andersson@...aro.org>
Subject: Re: [PATCH] mailbox: add support for doorbell/signal mode controllers
On Thu, Nov 2, 2017 at 5:19 PM, Sudeep Holla <sudeep.holla@....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?
>
> 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.
BTW these 4 don't even need any send_signal() api, they would remain
unchanged. What's the new api for?
Powered by blists - more mailing lists