From: Joseph Lo <josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Alexandre Courbot
<gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Peter De Schrijver
<pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Matthew Longnecker
<MLongnecker-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jassi Brar
<jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Subject: Re: [PATCH 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox
Date: Tue, 28 Jun 2016 17:15:37 +0800 [thread overview]
Message-ID: <57724039.7080007@nvidia.com> (raw)
In-Reply-To: <57714C85.50802-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
On 06/27/2016 11:55 PM, Stephen Warren wrote:
> On 06/27/2016 03:02 AM, Joseph Lo wrote:
>> Add DT binding for the Hardware Synchronization Primitives (HSP). The
>> HSP is designed for the processors to share resources and communicate
>> together. It provides a set of hardware synchronization primitives for
>> interprocessor communication. So the interprocessor communication (IPC)
>> protocols can use hardware synchronization primitive, when operating
>> between two processors not in an SMP relationship.
>
> This binding is quite different to the binding you sent to internal IP
> review. I wonder why it changed? Specific comments below:
>
Due to some enhancements for supporting multiple functions of HSP
sub-modules in the same driver, I re-wrote some parts of the bindings
and driver.
>> diff --git
>> a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
>> b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
>
>> +NVIDIA Tegra Hardware Synchronization Primitives (HSP)
>> +
>> +The HSP modules are used for the processors to share resources and
>> communicate
>> +together. It provides a set of hardware synchronization primitives for
>> +interprocessor communication. So the interprocessor communication (IPC)
>> +protocols can use hardware synchronization primitives, when operating
>> between
>> +two processors not in an SMP relationship.
>> +
>> +The features that HSP supported are shared mailboxes, shared semaphores,
>> +arbitrated semaphores and doorbells.
>> +
>> +Required properties:
>> +- name : Should be hsp
>> +- compatible : Should be "nvidia,tegra<chip>-hsp"
>
> I think this should explicitly list the value values of the compatible
> property, rather than being a generic/wildcard description:
>
> - compatible
> Array of strings.
> One of:
> - "nvidia,tegra186-hsp"
>
> If/when this binding supports other SoCs in the future, we'll add more
> entries into that list.
>
>> +- reg : Offset and length of the register set for the device
>> +- interrupts : Should contain the HSP interrupts
>> +- interrupt-names: Should contain the names of the HSP interrupts
>> that the
>> + client are using.
>> + "doorbell"
>
> The binding should describe the HW, and not be affected by anything
> "that the client(s) are using". If there are multiple interrupts, we
> should list them all here, from the start.
>
> When revising this, I would consider the following wording canonical:
Okay.
>
> - interrupt-names
> Array of strings.
> Contains a list of names for the interrupts described by the
> interrupts property. May contain the following entries, in any
> order:
> - "doorbell"
> - "..." (no doubt many more items will be listed here, e.g.
> for semaphores, etc.).
I think I will just list "doorbell" for now. And adding more later once
we add other HSP sub-module support.
> Users of this binding MUST look up entries in the interrupts
> property by name, using this interrupts-names property to do so.
> - interrupts
> Array of interrupt specifiers.
> Must contain one entry per entry in the interrupt-names property,
> in a matching order.
>
>> +- nvidia,hsp-function : Specifies one of the HSP functions that the
>> HSP unit
>> + will be supported. The function ID can be found in the
>> + header file <dt-bindings/mailbox/tegra-hsp.h>.
>
> This property wasn't in the internal patch.
>
> This doesn't make sense. The HW feature-set is fixed. This sounds like
> some kind of software configuration option, or a way to allow different
> drivers to handle different aspects of the HW? In general, the binding
> shouldn't be influenced by software structure. Please delete this property.
>
> Now, if you're attempting to set up a binding where each function
> (semaphores, shared mailboxes, doorbells, etc.) has a different DT node,
> then (a) splitting up HW modules into sub-blocks has usually turned out
> to be a mistake in the past, and (b) the differences should likely be
> represented by using a different compatible property for each
> sub-component, rather than via a custom property.
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?
>
>
> The following properties were included in the internal patch:
>
> nvidia,num-SM = <0x8>;
> nvidia,num-AS = <0x2>;
> nvidia,num-SS = <0x2>;
> nvidia,num-DB = <0x7>;
> nvidia,num-SI = <0x8>;
>
> ... yet aren't here. True the compatible value implies those values; was
> that why the properties were removed?
Because these values are available in the HSP_INT_DIMENSIONING register,
so remove them.
>
>> +Example:
>> +
>> +hsp_top: hsp@3c00000 {
> ...
>> +bpmp@d0000000 {
>> + ...
>> + mboxes = <&hsp_top HSP_DB_MASTER_BPMP>;
>> + ...
>> +};
>
> I'd suggest not including the bpmp node in the example, since it's not
> part of the HSP node. If you do, recall that bpmp has no reg property
> and hence the node name shouldn't include a unit address.
Okay.
>
>> diff --git a/include/dt-bindings/mailbox/tegra-hsp.h
>> b/include/dt-bindings/mailbox/tegra-hsp.h
>
> This file should probably be named tegra186-hsp, since I doubt the
> master ID values will be stable between chips.
Yes, true. Will fix.
>
>> +/*
>> + * This header provides constants for binding nvidia,tegra<chip>-hsp.
>
> That should say "186" not "<chip>"
>
>> +#ifndef _DT_BINDINGS_MAILBOX_TEGRA186_HSP_H
>> +#define _DT_BINDINGS_MAILBOX_TEGRA186_HSP_H
>
> The two changes mentioned above would be consistent with that include
> guard's name including the text "186".
>
>> +#define HSP_SHARED_MAILBOX 0
>> +#define HSP_SHARED_SEMAPHORE 1
>> +#define HSP_ARBITRATED_SEMAPHORE 2
>> +#define HSP_DOORBELL 3
>
> I think those should be removed, along with the nvidia,hsp-function
> property.
>
Okay.
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: Tue, 28 Jun 2016 17:15:37 +0800 [thread overview]
Message-ID: <57724039.7080007@nvidia.com> (raw)
In-Reply-To: <57714C85.50802@wwwdotorg.org>
On 06/27/2016 11:55 PM, Stephen Warren wrote:
> On 06/27/2016 03:02 AM, Joseph Lo wrote:
>> Add DT binding for the Hardware Synchronization Primitives (HSP). The
>> HSP is designed for the processors to share resources and communicate
>> together. It provides a set of hardware synchronization primitives for
>> interprocessor communication. So the interprocessor communication (IPC)
>> protocols can use hardware synchronization primitive, when operating
>> between two processors not in an SMP relationship.
>
> This binding is quite different to the binding you sent to internal IP
> review. I wonder why it changed? Specific comments below:
>
Due to some enhancements for supporting multiple functions of HSP
sub-modules in the same driver, I re-wrote some parts of the bindings
and driver.
>> diff --git
>> a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
>> b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
>
>> +NVIDIA Tegra Hardware Synchronization Primitives (HSP)
>> +
>> +The HSP modules are used for the processors to share resources and
>> communicate
>> +together. It provides a set of hardware synchronization primitives for
>> +interprocessor communication. So the interprocessor communication (IPC)
>> +protocols can use hardware synchronization primitives, when operating
>> between
>> +two processors not in an SMP relationship.
>> +
>> +The features that HSP supported are shared mailboxes, shared semaphores,
>> +arbitrated semaphores and doorbells.
>> +
>> +Required properties:
>> +- name : Should be hsp
>> +- compatible : Should be "nvidia,tegra<chip>-hsp"
>
> I think this should explicitly list the value values of the compatible
> property, rather than being a generic/wildcard description:
>
> - compatible
> Array of strings.
> One of:
> - "nvidia,tegra186-hsp"
>
> If/when this binding supports other SoCs in the future, we'll add more
> entries into that list.
>
>> +- reg : Offset and length of the register set for the device
>> +- interrupts : Should contain the HSP interrupts
>> +- interrupt-names: Should contain the names of the HSP interrupts
>> that the
>> + client are using.
>> + "doorbell"
>
> The binding should describe the HW, and not be affected by anything
> "that the client(s) are using". If there are multiple interrupts, we
> should list them all here, from the start.
>
> When revising this, I would consider the following wording canonical:
Okay.
>
> - interrupt-names
> Array of strings.
> Contains a list of names for the interrupts described by the
> interrupts property. May contain the following entries, in any
> order:
> - "doorbell"
> - "..." (no doubt many more items will be listed here, e.g.
> for semaphores, etc.).
I think I will just list "doorbell" for now. And adding more later once
we add other HSP sub-module support.
> Users of this binding MUST look up entries in the interrupts
> property by name, using this interrupts-names property to do so.
> - interrupts
> Array of interrupt specifiers.
> Must contain one entry per entry in the interrupt-names property,
> in a matching order.
>
>> +- nvidia,hsp-function : Specifies one of the HSP functions that the
>> HSP unit
>> + will be supported. The function ID can be found in the
>> + header file <dt-bindings/mailbox/tegra-hsp.h>.
>
> This property wasn't in the internal patch.
>
> This doesn't make sense. The HW feature-set is fixed. This sounds like
> some kind of software configuration option, or a way to allow different
> drivers to handle different aspects of the HW? In general, the binding
> shouldn't be influenced by software structure. Please delete this property.
>
> Now, if you're attempting to set up a binding where each function
> (semaphores, shared mailboxes, doorbells, etc.) has a different DT node,
> then (a) splitting up HW modules into sub-blocks has usually turned out
> to be a mistake in the past, and (b) the differences should likely be
> represented by using a different compatible property for each
> sub-component, rather than via a custom property.
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?
>
>
> The following properties were included in the internal patch:
>
> nvidia,num-SM = <0x8>;
> nvidia,num-AS = <0x2>;
> nvidia,num-SS = <0x2>;
> nvidia,num-DB = <0x7>;
> nvidia,num-SI = <0x8>;
>
> ... yet aren't here. True the compatible value implies those values; was
> that why the properties were removed?
Because these values are available in the HSP_INT_DIMENSIONING register,
so remove them.
>
>> +Example:
>> +
>> +hsp_top: hsp at 3c00000 {
> ...
>> +bpmp at d0000000 {
>> + ...
>> + mboxes = <&hsp_top HSP_DB_MASTER_BPMP>;
>> + ...
>> +};
>
> I'd suggest not including the bpmp node in the example, since it's not
> part of the HSP node. If you do, recall that bpmp has no reg property
> and hence the node name shouldn't include a unit address.
Okay.
>
>> diff --git a/include/dt-bindings/mailbox/tegra-hsp.h
>> b/include/dt-bindings/mailbox/tegra-hsp.h
>
> This file should probably be named tegra186-hsp, since I doubt the
> master ID values will be stable between chips.
Yes, true. Will fix.
>
>> +/*
>> + * This header provides constants for binding nvidia,tegra<chip>-hsp.
>
> That should say "186" not "<chip>"
>
>> +#ifndef _DT_BINDINGS_MAILBOX_TEGRA186_HSP_H
>> +#define _DT_BINDINGS_MAILBOX_TEGRA186_HSP_H
>
> The two changes mentioned above would be consistent with that include
> guard's name including the text "186".
>
>> +#define HSP_SHARED_MAILBOX 0
>> +#define HSP_SHARED_SEMAPHORE 1
>> +#define HSP_ARBITRATED_SEMAPHORE 2
>> +#define HSP_DOORBELL 3
>
> I think those should be removed, along with the nvidia,hsp-function
> property.
>
Okay.
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: Tue, 28 Jun 2016 17:15:37 +0800 [thread overview]
Message-ID: <57724039.7080007@nvidia.com> (raw)
In-Reply-To: <57714C85.50802@wwwdotorg.org>
On 06/27/2016 11:55 PM, Stephen Warren wrote:
> On 06/27/2016 03:02 AM, Joseph Lo wrote:
>> Add DT binding for the Hardware Synchronization Primitives (HSP). The
>> HSP is designed for the processors to share resources and communicate
>> together. It provides a set of hardware synchronization primitives for
>> interprocessor communication. So the interprocessor communication (IPC)
>> protocols can use hardware synchronization primitive, when operating
>> between two processors not in an SMP relationship.
>
> This binding is quite different to the binding you sent to internal IP
> review. I wonder why it changed? Specific comments below:
>
Due to some enhancements for supporting multiple functions of HSP
sub-modules in the same driver, I re-wrote some parts of the bindings
and driver.
>> diff --git
>> a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
>> b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
>
>> +NVIDIA Tegra Hardware Synchronization Primitives (HSP)
>> +
>> +The HSP modules are used for the processors to share resources and
>> communicate
>> +together. It provides a set of hardware synchronization primitives for
>> +interprocessor communication. So the interprocessor communication (IPC)
>> +protocols can use hardware synchronization primitives, when operating
>> between
>> +two processors not in an SMP relationship.
>> +
>> +The features that HSP supported are shared mailboxes, shared semaphores,
>> +arbitrated semaphores and doorbells.
>> +
>> +Required properties:
>> +- name : Should be hsp
>> +- compatible : Should be "nvidia,tegra<chip>-hsp"
>
> I think this should explicitly list the value values of the compatible
> property, rather than being a generic/wildcard description:
>
> - compatible
> Array of strings.
> One of:
> - "nvidia,tegra186-hsp"
>
> If/when this binding supports other SoCs in the future, we'll add more
> entries into that list.
>
>> +- reg : Offset and length of the register set for the device
>> +- interrupts : Should contain the HSP interrupts
>> +- interrupt-names: Should contain the names of the HSP interrupts
>> that the
>> + client are using.
>> + "doorbell"
>
> The binding should describe the HW, and not be affected by anything
> "that the client(s) are using". If there are multiple interrupts, we
> should list them all here, from the start.
>
> When revising this, I would consider the following wording canonical:
Okay.
>
> - interrupt-names
> Array of strings.
> Contains a list of names for the interrupts described by the
> interrupts property. May contain the following entries, in any
> order:
> - "doorbell"
> - "..." (no doubt many more items will be listed here, e.g.
> for semaphores, etc.).
I think I will just list "doorbell" for now. And adding more later once
we add other HSP sub-module support.
> Users of this binding MUST look up entries in the interrupts
> property by name, using this interrupts-names property to do so.
> - interrupts
> Array of interrupt specifiers.
> Must contain one entry per entry in the interrupt-names property,
> in a matching order.
>
>> +- nvidia,hsp-function : Specifies one of the HSP functions that the
>> HSP unit
>> + will be supported. The function ID can be found in the
>> + header file <dt-bindings/mailbox/tegra-hsp.h>.
>
> This property wasn't in the internal patch.
>
> This doesn't make sense. The HW feature-set is fixed. This sounds like
> some kind of software configuration option, or a way to allow different
> drivers to handle different aspects of the HW? In general, the binding
> shouldn't be influenced by software structure. Please delete this property.
>
> Now, if you're attempting to set up a binding where each function
> (semaphores, shared mailboxes, doorbells, etc.) has a different DT node,
> then (a) splitting up HW modules into sub-blocks has usually turned out
> to be a mistake in the past, and (b) the differences should likely be
> represented by using a different compatible property for each
> sub-component, rather than via a custom property.
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?
>
>
> The following properties were included in the internal patch:
>
> nvidia,num-SM = <0x8>;
> nvidia,num-AS = <0x2>;
> nvidia,num-SS = <0x2>;
> nvidia,num-DB = <0x7>;
> nvidia,num-SI = <0x8>;
>
> ... yet aren't here. True the compatible value implies those values; was
> that why the properties were removed?
Because these values are available in the HSP_INT_DIMENSIONING register,
so remove them.
>
>> +Example:
>> +
>> +hsp_top: hsp@3c00000 {
> ...
>> +bpmp@d0000000 {
>> + ...
>> + mboxes = <&hsp_top HSP_DB_MASTER_BPMP>;
>> + ...
>> +};
>
> I'd suggest not including the bpmp node in the example, since it's not
> part of the HSP node. If you do, recall that bpmp has no reg property
> and hence the node name shouldn't include a unit address.
Okay.
>
>> diff --git a/include/dt-bindings/mailbox/tegra-hsp.h
>> b/include/dt-bindings/mailbox/tegra-hsp.h
>
> This file should probably be named tegra186-hsp, since I doubt the
> master ID values will be stable between chips.
Yes, true. Will fix.
>
>> +/*
>> + * This header provides constants for binding nvidia,tegra<chip>-hsp.
>
> That should say "186" not "<chip>"
>
>> +#ifndef _DT_BINDINGS_MAILBOX_TEGRA186_HSP_H
>> +#define _DT_BINDINGS_MAILBOX_TEGRA186_HSP_H
>
> The two changes mentioned above would be consistent with that include
> guard's name including the text "186".
>
>> +#define HSP_SHARED_MAILBOX 0
>> +#define HSP_SHARED_SEMAPHORE 1
>> +#define HSP_ARBITRATED_SEMAPHORE 2
>> +#define HSP_DOORBELL 3
>
> I think those should be removed, along with the nvidia,hsp-function
> property.
>
Okay.
Thanks,
-Joseph
next prev parent reply other threads:[~2016-06-28 9:15 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 [this message]
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
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
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 ` 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
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=57724039.7080007@nvidia.com \
--to=josephl-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
--cc=MLongnecker-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
/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.