Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1636408 > unrolled thread
| Started by | Hanjun Guo <hanjun.guo@linaro.org> |
|---|---|
| First post | 2017-05-05 16:00 +0200 |
| Last post | 2017-05-05 17:40 +0200 |
| Articles | 4 — 4 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v3 3/7] ACPICA: IORT: Add Cavium ThunderX2 SMMUv3 model definition. Hanjun Guo <hanjun.guo@linaro.org> - 2017-05-05 16:00 +0200
Re: [PATCH v3 3/7] ACPICA: IORT: Add Cavium ThunderX2 SMMUv3 model definition. David Daney <ddaney.cavm@gmail.com> - 2017-05-05 17:00 +0200
Re: [PATCH v3 3/7] ACPICA: IORT: Add Cavium ThunderX2 SMMUv3 model definition. Will Deacon <will.deacon@arm.com> - 2017-05-05 17:00 +0200
Re: [PATCH v3 3/7] ACPICA: IORT: Add Cavium ThunderX2 SMMUv3 model definition. Jon Masters <jcm@redhat.com> - 2017-05-05 17:40 +0200
| From | Hanjun Guo <hanjun.guo@linaro.org> |
|---|---|
| Date | 2017-05-05 16:00 +0200 |
| Subject | Re: [PATCH v3 3/7] ACPICA: IORT: Add Cavium ThunderX2 SMMUv3 model definition. |
| Message-ID | <tDLW2-2wh-35@gated-at.bofh.it> |
On 2017/5/5 20:08, Geetha sowjanya wrote:
> From: Linu Cherian <linu.cherian@cavium.com>
>
> Add SMMUv3 model definition for ThunderX2.
>
> Signed-off-by: Linu Cherian <linu.cherian@cavium.com>
> Signed-off-by: Geetha Sowjanya <geethasowjanya.akula@cavium.com>
> ---
> include/acpi/actbl2.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
> index faa9f2c..76a6f5d 100644
> --- a/include/acpi/actbl2.h
> +++ b/include/acpi/actbl2.h
> @@ -779,6 +779,8 @@ struct acpi_iort_smmu {
> #define ACPI_IORT_SMMU_CORELINK_MMU400 0x00000002 /* ARM Corelink MMU-400 */
> #define ACPI_IORT_SMMU_CORELINK_MMU500 0x00000003 /* ARM Corelink MMU-500 */
>
> +#define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX 0x00000002 /* Cavium ThunderX2 SMMUv3 */
There are some other model numbers in the unreleased spec,
I think we need to wait for the updated IORT spec to
be released.
Thanks
Hanjun
[toc] | [next] | [standalone]
| From | David Daney <ddaney.cavm@gmail.com> |
|---|---|
| Date | 2017-05-05 17:00 +0200 |
| Message-ID | <tDMS6-35I-9@gated-at.bofh.it> |
| In reply to | #1636408 |
On 05/05/2017 06:53 AM, Hanjun Guo wrote:
> On 2017/5/5 20:08, Geetha sowjanya wrote:
>> From: Linu Cherian <linu.cherian@cavium.com>
>>
>> Add SMMUv3 model definition for ThunderX2.
>>
>> Signed-off-by: Linu Cherian <linu.cherian@cavium.com>
>> Signed-off-by: Geetha Sowjanya <geethasowjanya.akula@cavium.com>
>> ---
>> include/acpi/actbl2.h | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
>> index faa9f2c..76a6f5d 100644
>> --- a/include/acpi/actbl2.h
>> +++ b/include/acpi/actbl2.h
>> @@ -779,6 +779,8 @@ struct acpi_iort_smmu {
>> #define ACPI_IORT_SMMU_CORELINK_MMU400 0x00000002 /* ARM Corelink
>> MMU-400 */
>> #define ACPI_IORT_SMMU_CORELINK_MMU500 0x00000003 /* ARM Corelink
>> MMU-500 */
>>
>> +#define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX 0x00000002 /* Cavium
>> ThunderX2 SMMUv3 */
>
> There are some other model numbers in the unreleased spec,
> I think we need to wait for the updated IORT spec to
> be released.
>
... or if we are fairly confident that the identifier will not need to
change, we can merge this as is and establish a de facto specification
that the Real IORT specification will then be forced to follow.
Is there anything other than bureaucratic inertia holding up the real
specification?
David.
[toc] | [prev] | [next] | [standalone]
| From | Will Deacon <will.deacon@arm.com> |
|---|---|
| Date | 2017-05-05 17:00 +0200 |
| Message-ID | <tDMS6-35I-7@gated-at.bofh.it> |
| In reply to | #1636431 |
On Fri, May 05, 2017 at 07:56:17AM -0700, David Daney wrote:
> On 05/05/2017 06:53 AM, Hanjun Guo wrote:
> >On 2017/5/5 20:08, Geetha sowjanya wrote:
> >>From: Linu Cherian <linu.cherian@cavium.com>
> >>
> >>Add SMMUv3 model definition for ThunderX2.
> >>
> >>Signed-off-by: Linu Cherian <linu.cherian@cavium.com>
> >>Signed-off-by: Geetha Sowjanya <geethasowjanya.akula@cavium.com>
> >>---
> >> include/acpi/actbl2.h | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >>diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
> >>index faa9f2c..76a6f5d 100644
> >>--- a/include/acpi/actbl2.h
> >>+++ b/include/acpi/actbl2.h
> >>@@ -779,6 +779,8 @@ struct acpi_iort_smmu {
> >> #define ACPI_IORT_SMMU_CORELINK_MMU400 0x00000002 /* ARM Corelink
> >>MMU-400 */
> >> #define ACPI_IORT_SMMU_CORELINK_MMU500 0x00000003 /* ARM Corelink
> >>MMU-500 */
> >>
> >>+#define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX 0x00000002 /* Cavium ThunderX2
> >>SMMUv3 */
> >
> >There are some other model numbers in the unreleased spec,
> >I think we need to wait for the updated IORT spec to
> >be released.
> >
>
> ... or if we are fairly confident that the identifier will not need to
> change, we can merge this as is and establish a de facto specification that
> the Real IORT specification will then be forced to follow.
>
> Is there anything other than bureaucratic inertia holding up the real
> specification?
My understanding is that IORT is going to be published imminently (i.e.
before the next kernel release), so it makes sense to wait rather than fork
the spec.
Will
[toc] | [prev] | [next] | [standalone]
| From | Jon Masters <jcm@redhat.com> |
|---|---|
| Date | 2017-05-05 17:40 +0200 |
| Message-ID | <tDNuO-3Aq-21@gated-at.bofh.it> |
| In reply to | #1636432 |
On 05/05/2017 10:58 AM, Will Deacon wrote: > On Fri, May 05, 2017 at 07:56:17AM -0700, David Daney wrote: >> On 05/05/2017 06:53 AM, Hanjun Guo wrote: >>> On 2017/5/5 20:08, Geetha sowjanya wrote: >>>> From: Linu Cherian <linu.cherian@cavium.com> >>>> +#define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX 0x00000002 /* Cavium ThunderX2 >>>> SMMUv3 */ >>> >>> There are some other model numbers in the unreleased spec, >>> I think we need to wait for the updated IORT spec to >>> be released. Indeed. I've synced with the author on this and he's got it in hand. >> ... or if we are fairly confident that the identifier will not need to >> change, we can merge this as is and establish a de facto specification that >> the Real IORT specification will then be forced to follow. Can't do that - this always causes trouble ;) But if there's any delay I'll ask that the IDs at least be listed somewhere public or something. >> Is there anything other than bureaucratic inertia holding up the real >> specification? > > My understanding is that IORT is going to be published imminently (i.e. > before the next kernel release), so it makes sense to wait rather than fork > the spec. Let's track this and get the updated patches posted next week once the new ID drops. Meanwhile, I suggest reviewing them as-is for other issues. I'm tracking this for internal purposes and require this to be upstream asap so I'll be sitting on this thread for updates ;) Jon. -- Computer Architect | Sent from my Fedora powered laptop
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web