From: Boaz Harrosh <boaz@plexistor.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Ingo Molnar <mingo@redhat.com>, X86 ML <x86@kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
"Roger C. Pao" <rcpao.enmotus@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Matthew Wilcox <willy@linux.intel.com>,
Andy Lutomirski <luto@amacapital.net>,
Christoph Hellwig <hch@infradead.org>,
Ross Zwisler <ross.zwisler@linux.intel.com>
Subject: Re: [PATCH 3/3] e820: Add the unknown-12 Memory type (DDR3-NvDIMM)
Date: Mon, 09 Mar 2015 13:19:35 +0200 [thread overview]
Message-ID: <54FD81C7.3080000@plexistor.com> (raw)
In-Reply-To: <CAPcyv4i5WfR48hmGwqLDgTFRpUPaAxusHXKKUKY4FBxu1Mqm+w@mail.gmail.com>
On 03/05/2015 10:56 PM, Dan Williams wrote:
> On Thu, Mar 5, 2015 at 2:24 AM, Boaz Harrosh <boaz@plexistor.com> wrote:
>>
<>
>> Now the ACPI comity, as far as I know, did not yet define a
>> standard type for NvDIMM. Also, as far as I know any NvDIMM
>> standard will only be defined for DDR4. So DDR3 NvDIMM is
>> probably stuck with this none STD type.
>
> There's no relation between E820 types and DDR technology revisions.
>
Yes and no, I mean the DDR4 has extra legs and signals defined
for NvDIMM. So DDR3 will always mean different style of NvDIMM.
You tell me. Say the standard finally comes out. Will I have a
new bios from Intel for my DDR3 system here in the lab that will
report the new STD type ?
What I meant is that DDR3 is too old for the proposed STD and probably
only DDR4 NvDIMMs will be supported in systems. The way the STD defined
it.
<>
>> In this patch I name type-12 "unknown-12". This is because of
>> ACPI politics that refuse to reserve type-12 as DDR3-NvDIMM
>
> It's not "politics". Setting standards takes time and the platforms
> in question simply jumped the gun to enable a proof-of-concept.
>
So ye, but once you have 100,000 devices out there, then the dichotomy
between standards-takes-time vs proof-of-concept, becomes politics.
This is the definition of politics, when life moves faster than some
"body", the "body" stands on its back feet and shoots fire from
his head.
>> and members keep saying:
>> "What if ACPI assigns type-12 for something else in future"
>>
>> [And I say: Then just don't. Please?]
>
> Once a standard number is assigned, platform firmwares can update
> type-12 to that number. We might consider a compile time override for
> these niche/pre-standard systems that can't/won't update, but it's not
> clear to me that we even need to go that far.
>
OK, so I do not understand what you want. Yes or No to this patch?
This patch with unknown-12 is for NOW. For systems already running.
So we can differentiate between reserved-unknown which might mean
type-13 and this here bastard type-12 which we know is NvDIMM but
for future sake we do not call by name?
Or maybe we should call it NVDIMM-12 ?
Thanks
Boaz
WARNING: multiple messages have this Message-ID (diff)
From: Boaz Harrosh <boaz@plexistor.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Ingo Molnar <mingo@redhat.com>, X86 ML <x86@kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
"Roger C. Pao" <rcpao.enmotus@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-nvdimm <linux-nvdimm@ml01.01.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Matthew Wilcox <willy@linux.intel.com>,
Andy Lutomirski <luto@amacapital.net>,
Christoph Hellwig <hch@infradead.org>,
Ross Zwisler <ross.zwisler@linux.intel.com>
Subject: Re: [PATCH 3/3] e820: Add the unknown-12 Memory type (DDR3-NvDIMM)
Date: Mon, 09 Mar 2015 13:19:35 +0200 [thread overview]
Message-ID: <54FD81C7.3080000@plexistor.com> (raw)
In-Reply-To: <CAPcyv4i5WfR48hmGwqLDgTFRpUPaAxusHXKKUKY4FBxu1Mqm+w@mail.gmail.com>
On 03/05/2015 10:56 PM, Dan Williams wrote:
> On Thu, Mar 5, 2015 at 2:24 AM, Boaz Harrosh <boaz@plexistor.com> wrote:
>>
<>
>> Now the ACPI comity, as far as I know, did not yet define a
>> standard type for NvDIMM. Also, as far as I know any NvDIMM
>> standard will only be defined for DDR4. So DDR3 NvDIMM is
>> probably stuck with this none STD type.
>
> There's no relation between E820 types and DDR technology revisions.
>
Yes and no, I mean the DDR4 has extra legs and signals defined
for NvDIMM. So DDR3 will always mean different style of NvDIMM.
You tell me. Say the standard finally comes out. Will I have a
new bios from Intel for my DDR3 system here in the lab that will
report the new STD type ?
What I meant is that DDR3 is too old for the proposed STD and probably
only DDR4 NvDIMMs will be supported in systems. The way the STD defined
it.
<>
>> In this patch I name type-12 "unknown-12". This is because of
>> ACPI politics that refuse to reserve type-12 as DDR3-NvDIMM
>
> It's not "politics". Setting standards takes time and the platforms
> in question simply jumped the gun to enable a proof-of-concept.
>
So ye, but once you have 100,000 devices out there, then the dichotomy
between standards-takes-time vs proof-of-concept, becomes politics.
This is the definition of politics, when life moves faster than some
"body", the "body" stands on its back feet and shoots fire from
his head.
>> and members keep saying:
>> "What if ACPI assigns type-12 for something else in future"
>>
>> [And I say: Then just don't. Please?]
>
> Once a standard number is assigned, platform firmwares can update
> type-12 to that number. We might consider a compile time override for
> these niche/pre-standard systems that can't/won't update, but it's not
> clear to me that we even need to go that far.
>
OK, so I do not understand what you want. Yes or No to this patch?
This patch with unknown-12 is for NOW. For systems already running.
So we can differentiate between reserved-unknown which might mean
type-13 and this here bastard type-12 which we know is NvDIMM but
for future sake we do not call by name?
Or maybe we should call it NVDIMM-12 ?
Thanks
Boaz
next prev parent reply other threads:[~2015-03-09 11:19 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-05 10:16 [PATCH 0/3 v5] e820: Fix handling of NvDIMM chips Boaz Harrosh
2015-03-05 10:16 ` Boaz Harrosh
2015-03-05 10:20 ` [PATCH 1/3] e820: Don't let unknown DIMM type come out BUSY Boaz Harrosh
2015-03-05 10:20 ` Boaz Harrosh
2015-03-05 20:41 ` Dan Williams
2015-03-05 20:41 ` Dan Williams
2015-03-09 10:54 ` Boaz Harrosh
2015-03-09 10:54 ` Boaz Harrosh
2015-03-05 10:21 ` [PATCH 2/3] resource: Add new flag IORESOURCE_MEM_WARN Boaz Harrosh
2015-03-05 10:21 ` Boaz Harrosh
2015-03-05 10:24 ` [PATCH 3/3] e820: Add the unknown-12 Memory type (DDR3-NvDIMM) Boaz Harrosh
2015-03-05 10:24 ` Boaz Harrosh
2015-03-05 20:56 ` Dan Williams
2015-03-05 20:56 ` Dan Williams
2015-03-05 23:09 ` Andy Lutomirski
2015-03-05 23:09 ` Andy Lutomirski
2015-03-09 12:10 ` Boaz Harrosh
2015-03-09 12:10 ` Boaz Harrosh
2015-03-10 5:11 ` joeyli
2015-03-10 5:11 ` joeyli
2015-03-10 8:56 ` Boaz Harrosh
2015-03-10 8:56 ` Boaz Harrosh
2015-03-10 13:19 ` Andy Lutomirski
2015-03-10 13:19 ` Andy Lutomirski
2015-03-09 11:19 ` Boaz Harrosh [this message]
2015-03-09 11:19 ` Boaz Harrosh
2015-03-09 14:44 ` Dan Williams
2015-03-09 14:44 ` Dan Williams
2015-03-09 15:14 ` Andy Lutomirski
2015-03-09 15:14 ` Andy Lutomirski
2015-03-09 15:17 ` Dan Williams
2015-03-09 15:17 ` Dan Williams
2015-03-10 8:47 ` Boaz Harrosh
2015-03-10 8:47 ` Boaz Harrosh
2015-03-05 10:32 ` [RFC 0/8] pmem: Submission of the Persistent memory block device Boaz Harrosh
2015-03-05 10:32 ` Boaz Harrosh
2015-03-05 11:55 ` [PATCH 1/8] pmem: Initial version of persistent memory driver Boaz Harrosh
2015-03-05 11:55 ` Boaz Harrosh
2015-03-05 20:35 ` Paul Bolle
2015-03-05 20:35 ` Paul Bolle
2015-03-05 23:03 ` Andy Lutomirski
2015-03-05 23:03 ` Andy Lutomirski
2015-03-09 12:20 ` Boaz Harrosh
2015-03-09 12:20 ` Boaz Harrosh
2015-03-18 18:06 ` Andy Lutomirski
2015-03-18 18:06 ` Andy Lutomirski
2015-03-26 4:00 ` Elliott, Robert (Server Storage)
2015-03-26 4:00 ` Elliott, Robert (Server Storage)
2015-03-26 7:51 ` Boaz Harrosh
2015-03-26 7:51 ` Boaz Harrosh
2015-03-26 21:31 ` Dave Chinner
2015-03-26 21:31 ` Dave Chinner
2015-03-18 17:43 ` Ross Zwisler
2015-03-18 17:43 ` Ross Zwisler
2015-03-19 9:24 ` Boaz Harrosh
2015-03-19 9:24 ` Boaz Harrosh
2015-03-20 0:11 ` Dan Williams
2015-03-20 0:11 ` Dan Williams
2015-03-05 11:55 ` [PATCH 2/8] pmem: KISS, remove register_blkdev Boaz Harrosh
2015-03-05 11:55 ` Boaz Harrosh
2015-03-05 11:56 ` [PATCH 3/8] pmem: Add support for rw_page() Boaz Harrosh
2015-03-05 11:56 ` Boaz Harrosh
2015-03-05 11:57 ` [PATCH 4/8] pmem: Add support for direct_access() Boaz Harrosh
2015-03-05 11:57 ` Boaz Harrosh
2015-03-05 11:58 ` [PATCH 5/8] mm: Let sparse_{add,remove}_one_section receive a node_id Boaz Harrosh
2015-03-05 11:58 ` Boaz Harrosh
2015-03-06 18:43 ` Ross Zwisler
2015-03-06 18:43 ` Ross Zwisler
2015-03-05 11:59 ` [PATCH 6/8] mm: New add_persistent_memory/remove_persistent_memory Boaz Harrosh
2015-03-05 11:59 ` Boaz Harrosh
2015-03-05 11:59 ` [PATCH 7/8] pmem: Add support for page structs Boaz Harrosh
2015-03-05 11:59 ` Boaz Harrosh
2015-03-23 20:59 ` Dan Williams
2015-03-23 20:59 ` Dan Williams
2015-03-05 12:01 ` [PATCH 8/8] OUT-OF-TREE: pmem: Allow request_mem to fail (BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET) Boaz Harrosh
2015-03-05 12:01 ` Boaz Harrosh
2015-03-06 18:37 ` [RFC 0/8] pmem: Submission of the Persistent memory block device Ross Zwisler
2015-03-06 18:37 ` Ross Zwisler
2015-03-07 1:39 ` Christoph Hellwig
2015-03-09 12:41 ` Boaz Harrosh
2015-03-09 12:41 ` Boaz Harrosh
2015-03-05 22:48 ` [PATCH 0/3 v5] e820: Fix handling of NvDIMM chips H. Peter Anvin
2015-03-05 23:06 ` Andy Lutomirski
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=54FD81C7.3080000@plexistor.com \
--to=boaz@plexistor.com \
--cc=dan.j.williams@intel.com \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=rcpao.enmotus@gmail.com \
--cc=ross.zwisler@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=willy@linux.intel.com \
--cc=x86@kernel.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.