All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joseph Lo <josephl@nvidia.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Alexandre Courbot <gnurou@gmail.com>,
	devicetree@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Peter De Schrijver <pdeschrijver@nvidia.com>,
	Jassi Brar <jassisinghbrar@gmail.com>,
	Will Deacon <will.deacon@arm.com>,
	linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	Matthew Longnecker <MLongnecker@nvidia.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	linux-tegra@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox
Date: Wed, 29 Jun 2016 13:56:33 +0800	[thread overview]
Message-ID: <57736311.6020304@nvidia.com> (raw)
In-Reply-To: <5772CB12.5080408@wwwdotorg.org>

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@1000 (doorbell func) <-> host CPU
>> remote_processor_C-/
>>
>> remote_processor_D -> hsp@2000 (shared mailbox) <-> CPU
>>
>> remote_processor_E -> hsp@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.

>
> Internally, the SW driver for that node can be structured however you
> want; it could register with multiple subsystems (mailbox, ...) with
> just one struct device, or the HSP driver could be an MFD device with
> sub-drivers for each separate piece of functionality the HW implements.
> All this can easily be done even while using a single DT node. And
> furthermore, we can add this SW structure later if/when we actually need
> it; in other words, there's no need to change your current patches right
> now, except to remove the nvidia,hsp-function DT property.

Thanks,
-Joseph

WARNING: multiple messages have this Message-ID (diff)
From: josephl@nvidia.com (Joseph Lo)
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 13:56:33 +0800	[thread overview]
Message-ID: <57736311.6020304@nvidia.com> (raw)
In-Reply-To: <5772CB12.5080408@wwwdotorg.org>

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.

>
> Internally, the SW driver for that node can be structured however you
> want; it could register with multiple subsystems (mailbox, ...) with
> just one struct device, or the HSP driver could be an MFD device with
> sub-drivers for each separate piece of functionality the HW implements.
> All this can easily be done even while using a single DT node. And
> furthermore, we can add this SW structure later if/when we actually need
> it; in other words, there's no need to change your current patches right
> now, except to remove the nvidia,hsp-function DT property.

Thanks,
-Joseph

WARNING: multiple messages have this Message-ID (diff)
From: Joseph Lo <josephl@nvidia.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>,
	Alexandre Courbot <gnurou@gmail.com>,
	<linux-tegra@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Peter De Schrijver <pdeschrijver@nvidia.com>,
	Matthew Longnecker <MLongnecker@nvidia.com>,
	<devicetree@vger.kernel.org>,
	Jassi Brar <jassisinghbrar@gmail.com>,
	<linux-kernel@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCH 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox
Date: Wed, 29 Jun 2016 13:56:33 +0800	[thread overview]
Message-ID: <57736311.6020304@nvidia.com> (raw)
In-Reply-To: <5772CB12.5080408@wwwdotorg.org>

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@1000 (doorbell func) <-> host CPU
>> remote_processor_C-/
>>
>> remote_processor_D -> hsp@2000 (shared mailbox) <-> CPU
>>
>> remote_processor_E -> hsp@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.

>
> Internally, the SW driver for that node can be structured however you
> want; it could register with multiple subsystems (mailbox, ...) with
> just one struct device, or the HSP driver could be an MFD device with
> sub-drivers for each separate piece of functionality the HW implements.
> All this can easily be done even while using a single DT node. And
> furthermore, we can add this SW structure later if/when we actually need
> it; in other words, there's no need to change your current patches right
> now, except to remove the nvidia,hsp-function DT property.

Thanks,
-Joseph

  reply	other threads:[~2016-06-29  5:56 UTC|newest]

Thread overview: 63+ 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 ` Joseph Lo
2016-06-27  9:02 ` 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  9:02   ` Joseph Lo
2016-06-27  9:02   ` Joseph Lo
     [not found]   ` <20160627090248.23621-2-josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-06-27 15:55     ` Stephen Warren
2016-06-27 15:55       ` Stephen Warren
2016-06-27 15:55       ` Stephen Warren
     [not found]       ` <57714C85.50802-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2016-06-28  9:15         ` Joseph Lo
2016-06-28  9:15           ` Joseph Lo
2016-06-28  9:15           ` Joseph Lo
     [not found]           ` <57724039.7080007-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-06-28 19:08             ` Stephen Warren
2016-06-28 19:08               ` Stephen Warren
2016-06-28 19:08               ` Stephen Warren
2016-06-29  5:56               ` Joseph Lo [this message]
2016-06-29  5:56                 ` Joseph Lo
2016-06-29  5:56                 ` Joseph Lo
2016-06-29 15:28                 ` Stephen Warren
2016-06-29 15:28                   ` Stephen Warren
2016-06-29 15:28                   ` Stephen Warren
2016-06-30  9:25                   ` Joseph Lo
2016-06-30  9:25                     ` Joseph Lo
2016-06-30  9:25                     ` Joseph Lo
     [not found]                     ` <5774E599.4000204-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-06-30 16:02                       ` Stephen Warren
2016-06-30 16:02                         ` Stephen Warren
2016-06-30 16:02                         ` Stephen Warren
     [not found]                         ` <5775427B.9040907-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2016-07-01  2:23                           ` Joseph Lo
2016-07-01  2:23                             ` Joseph Lo
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   ` Joseph Lo
2016-06-27  9:02   ` 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  9:02   ` Joseph Lo
2016-06-27  9:02   ` Joseph Lo
     [not found]   ` <20160627090248.23621-4-josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-06-27 16:08     ` Stephen Warren
2016-06-27 16:08       ` Stephen Warren
2016-06-27 16:08       ` Stephen Warren
     [not found]       ` <57714F7D.1040301-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2016-06-28  9:16         ` Joseph Lo
2016-06-28  9:16           ` Joseph Lo
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   ` Joseph Lo
2016-06-27  9:02   ` Joseph Lo
2016-06-27  9:02 ` [PATCH 05/10] firmware: tegra: add BPMP support Joseph Lo
2016-06-27  9:02   ` Joseph Lo
2016-06-27  9:02   ` Joseph Lo
2016-06-27  9:02 ` [PATCH 06/10] soc/tegra: Add Tegra186 support Joseph Lo
2016-06-27  9:02   ` Joseph Lo
2016-06-27  9:02   ` Joseph Lo
     [not found] ` <20160627090248.23621-1-josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-06-27  9:02   ` [PATCH 07/10] arm64: defconfig: Enable Tegra186 SoC Joseph Lo
2016-06-27  9:02     ` Joseph Lo
2016-06-27  9:02     ` Joseph Lo
2016-06-27  9:02   ` [PATCH 08/10] arm64: dts: tegra: Add Tegra186 support Joseph Lo
2016-06-27  9:02     ` Joseph Lo
2016-06-27  9:02     ` Joseph Lo
2016-06-27  9:02   ` [PATCH 10/10] arm64: dts: tegra: Add NVIDIA P2771 board support Joseph Lo
2016-06-27  9:02     ` Joseph Lo
2016-06-27  9:02     ` Joseph Lo
2016-06-27  9:02 ` [PATCH 09/10] arm64: dts: tegra: Add NVIDIA Tegra186 P3310 main " Joseph Lo
2016-06-27  9:02   ` Joseph Lo
2016-06-27  9:02   ` 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=57736311.6020304@nvidia.com \
    --to=josephl@nvidia.com \
    --cc=MLongnecker@nvidia.com \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gnurou@gmail.com \
    --cc=jassisinghbrar@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pdeschrijver@nvidia.com \
    --cc=robh+dt@kernel.org \
    --cc=swarren@wwwdotorg.org \
    --cc=thierry.reding@gmail.com \
    --cc=will.deacon@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.