From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: Peter Griffin <peter.griffin@linaro.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Jassi Brar <jassisinghbrar@gmail.com>
Cc: Jassi Brar <jassisinghbrar@gmail.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Alim Akhtar <alim.akhtar@samsung.com>,
linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
andre.draszik@linaro.org, kernel-team@android.com,
willmcvicker@google.com, daniel.lezcano@linaro.org,
vincent.guittot@linaro.org, ulf.hansson@linaro.org,
arnd@arndb.de
Subject: Re: [PATCH v5 1/3] dt-bindings: mailbox: add google,gs101-mbox
Date: Wed, 18 Dec 2024 12:39:07 +0000 [thread overview]
Message-ID: <878f75cb-e85a-44d3-aae8-22ede6e7afde@linaro.org> (raw)
In-Reply-To: <CADrjBPq4mTsvCivBJPmADP3pfUORBV8hGeP5GrTg9YxASJLHXg@mail.gmail.com>
On 12/18/24 11:23 AM, Peter Griffin wrote:
> Hi,
>
> On Wed, 18 Dec 2024 at 09:29, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On Tue, Dec 17, 2024 at 09:40:20AM +0000, Tudor Ambarus wrote:
>>> +description: |
>>> + The samsung exynos mailbox controller has 16 flag bits for hardware interrupt
>>
>> If there is going to be any new posting:
>>
>> The Samsung Exynos mailbox controller, used on Google GS101 SoC, ....
>>
>>> + generation and a shared register for passing mailbox messages. When the
>>> + controller is used by the ACPM protocol the shared register is ignored and
>>> + the mailbox controller acts as a doorbell. The controller just raises the
>>> + interrupt to the firmware after the ACPM protocol has written the message to
>>> + SRAM.
>>> +
>>> +properties:
>>> + compatible:
>>> + const: google,gs101-mbox
>>> +
>>> + reg:
>>> + maxItems: 1
>>> +
>>> + clocks:
>>> + maxItems: 1
>>> +
>>> + clock-names:
>>> + items:
>>> + - const: pclk
>>> +
>>> + interrupts:
>>> + description: IRQ line for the RX mailbox.
>>> + maxItems: 1
>>> +
>>> + '#mbox-cells':
>>> + description: |
>>> + <&phandle type channel>
>>> + phandle : label name of controller.
>>> + type : channel type, doorbell or data-transfer.
>>> + channel : channel number.
>>> +
>>> + Here is how a client can reference them:
>>> + mboxes = <&ap2apm_mailbox DOORBELL 2>;
>>> + mboxes = <&ap2apm_mailbox DATA 3>;
>>
>> This ordering assumes there is channel "2" in doorbel and in data, so
>> two times "2" and of course the same for all others. If this is
>> configuration of one channel, so "2" is either doorbell or data, then
>> type should be the last.
ha, nice observation!
> My understanding was each channel is either configured for doorbell or
> data, but Tudor can confirm. With Krzysztof's feedback addressed:
For the ACPM interface use case, mailbox is always used as a doorbell
indeed. Regardless if the ACPM interface writes data or not to SRAM, it
will use the mailbox controller just to flip the interrupt bit without
touching the mbox controller data registers.
For the other cases where the mailbox controller is used to (also?) pass
data via its data registers, I can't tell whether the passing of data is
mandatory or not. At least not by reading the gs101 mailbox datasheet
that I have, it doesn't describe the SR registers. However, Exynos850 -
which has the same registers, says that:
```CPU cores can use these registers for sharing data```.
"Can" implies that writing to SR is optional.
So I assume a channel can work in both modes and clients use mboxes to
specify which mode to use. Shall I still switch the order?
Thanks,
ta
next prev parent reply other threads:[~2024-12-18 12:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-17 9:40 [PATCH v5 0/3] mailbox: add Samsung Exynos driver Tudor Ambarus
2024-12-17 9:40 ` [PATCH v5 1/3] dt-bindings: mailbox: add google,gs101-mbox Tudor Ambarus
2024-12-18 9:29 ` Krzysztof Kozlowski
2024-12-18 11:23 ` Peter Griffin
2024-12-18 12:39 ` Tudor Ambarus [this message]
2024-12-19 10:50 ` Tudor Ambarus
2024-12-21 2:19 ` Jassi Brar
2024-12-21 6:45 ` Tudor Ambarus
2025-01-03 3:39 ` Jassi Brar
2025-01-03 9:57 ` Tudor Ambarus
2025-01-08 9:38 ` Tudor Ambarus
2025-01-12 16:59 ` Jassi Brar
2025-01-13 9:34 ` Tudor Ambarus
2025-01-13 16:52 ` Jassi Brar
2024-12-17 9:40 ` [PATCH v5 2/3] mailbox: add Samsung Exynos driver Tudor Ambarus
2024-12-18 10:20 ` Krzysztof Kozlowski
2024-12-18 11:58 ` Peter Griffin
2024-12-18 16:58 ` Jassi Brar
2024-12-17 9:40 ` [PATCH v5 3/3] MAINTAINERS: add entry for Samsung Exynos mailbox driver Tudor Ambarus
2024-12-18 10:20 ` Krzysztof Kozlowski
2024-12-18 11:08 ` Peter Griffin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878f75cb-e85a-44d3-aae8-22ede6e7afde@linaro.org \
--to=tudor.ambarus@linaro.org \
--cc=alim.akhtar@samsung.com \
--cc=andre.draszik@linaro.org \
--cc=arnd@arndb.de \
--cc=conor+dt@kernel.org \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=jassisinghbrar@gmail.com \
--cc=kernel-team@android.com \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=peter.griffin@linaro.org \
--cc=robh@kernel.org \
--cc=ulf.hansson@linaro.org \
--cc=vincent.guittot@linaro.org \
--cc=willmcvicker@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).