From: swarren@wwwdotorg•org (Stephen Warren)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox
Date: Wed, 29 Jun 2016 09:28:00 -0600 [thread overview]
Message-ID: <5773E900.8060903@wwwdotorg.org> (raw)
In-Reply-To: <57736311.6020304@nvidia.com>
On 06/28/2016 11:56 PM, Joseph Lo wrote:
> On 06/29/2016 03:08 AM, Stephen Warren wrote:
>> On 06/28/2016 03:15 AM, Joseph Lo wrote:
>>> On 06/27/2016 11:55 PM, Stephen Warren wrote:
>>>> On 06/27/2016 03:02 AM, Joseph Lo wrote:
> snip.
>>>
>>> Currently the usage of HSP HW in the downstream kernel is something like
>>> the model below.
>>>
>>> remote_processor_A-\
>>> remote_processor_B--->hsp at 1000 (doorbell func) <-> host CPU
>>> remote_processor_C-/
>>>
>>> remote_processor_D -> hsp at 2000 (shared mailbox) <-> CPU
>>>
>>> remote_processor_E -> hsp at 3000 (shared mailbox) <-> CPU
>>>
>>> I am thinking if we can just add the appropriate compatible strings for
>>> it to replace "nvidia,tegra186-hsp". e.g. "nvidia,tegra186-hsp-doorbell"
>>> and "nvidia,tegra186-hsp-sharedmailbox". So the driver can probe and
>>> initialize correctly depend on the compatible property. How do you think
>>> about it? Is this the same as the (b) you mentioned above?
>>
>> Yes, that would be (b) above.
>>
>> However, please do note (a): I expect that splitting things up will turn
>> out to be a mistake, as it has for other HW modules in the past. I would
>> far rather see a single hsp node in DT, since there is a single HSP
>> block in HW. Sure that block has multiple sub-functions. However, there
>> is common logic that affects all of those sub-functions and binds
>> everything into a single HW module. If you represent the HW module using
>> multiple different DT nodes, it will be hard to correctly represent that
>> common logic. Conversely, I see no real advantage to splitting up the DT
>> node. I strongly believe we should have a single "hsp" node in DT.
>
> We have 6 HSP block in HW. FYI.
Yes, we have 6 /instances/ of the overall HSP block. Those should each
have their own node, since they're entirely separate modules, all
instances of the same configurable IP block.
Above, I was talking about the sub-blocks within each HSP instance,
which should all be represented into a single node per instance, for a
total of 6 DT nodes overall.
next prev parent reply other threads:[~2016-06-29 15:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-27 9:02 [PATCH 00/10] arm64: tegra: add BPMP support Joseph Lo
2016-06-27 9:02 ` [PATCH 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox Joseph Lo
2016-06-27 15:55 ` Stephen Warren
2016-06-28 9:15 ` Joseph Lo
2016-06-28 19:08 ` Stephen Warren
2016-06-29 5:56 ` Joseph Lo
2016-06-29 15:28 ` Stephen Warren [this message]
2016-06-30 9:25 ` Joseph Lo
2016-06-30 16:02 ` Stephen Warren
2016-07-01 2:23 ` Joseph Lo
2016-06-27 9:02 ` [PATCH 02/10] mailbox: tegra-hsp: Add HSP(Hardware Synchronization Primitives) driver Joseph Lo
2016-06-27 9:02 ` [PATCH 03/10] Documentation: dt-bindings: firmware: tegra: add bindings of the BPMP Joseph Lo
2016-06-27 16:08 ` Stephen Warren
2016-06-28 9:16 ` Joseph Lo
2016-06-27 9:02 ` [PATCH 04/10] firmware: tegra: add IVC library Joseph Lo
2016-06-27 9:02 ` [PATCH 05/10] firmware: tegra: add BPMP support Joseph Lo
2016-06-27 9:02 ` [PATCH 06/10] soc/tegra: Add Tegra186 support Joseph Lo
2016-06-27 9:02 ` [PATCH 07/10] arm64: defconfig: Enable Tegra186 SoC Joseph Lo
2016-06-27 9:02 ` [PATCH 08/10] arm64: dts: tegra: Add Tegra186 support Joseph Lo
2016-06-27 9:02 ` [PATCH 09/10] arm64: dts: tegra: Add NVIDIA Tegra186 P3310 main board support Joseph Lo
2016-06-27 9:02 ` [PATCH 10/10] arm64: dts: tegra: Add NVIDIA P2771 " Joseph Lo
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=5773E900.8060903@wwwdotorg.org \
--to=swarren@wwwdotorg$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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