From: Jon Masters <jcm@redhat.com> To: Tomasz Nowicki <tn@semihalf.com>, Gabriele Paoloni <gabriele.paoloni@huawei.com>, "helgaas@kernel.org" <helgaas@kernel.org>, "arnd@arndb.de" <arnd@arndb.de>, "will.deacon@arm.com" <will.deacon@arm.com>, "catalin.marinas@arm.com" <catalin.marinas@arm.com>, "rafael@kernel.org" <rafael@kernel.org>, "hanjun.guo@linaro.org" <hanjun.guo@linaro.org>, "Lorenzo.Pieralisi@arm.com" <Lorenzo.Pieralisi@arm.com>, "okaya@codeaurora.org" <okaya@codeaurora.org>, "jchandra@broadcom.com" <jchandra@broadcom.com> Cc: "robert.richter@caviumnetworks.com" <robert.richter@caviumnetworks.com>, "mw@semihalf.com" <mw@semihalf.com>, "Liviu.Dudau@arm.com" <Liviu.Dudau@arm.com>, "ddaney@caviumnetworks.com" <ddaney@caviumnetworks.com>, Wangyijing <wangyijing@huawei.com>, "Suravee.Suthikulpanit@amd.com" <Suravee.Suthikulpanit@amd.com>, "msalter@redhat.com" <msalter@redhat.com>, "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>, "jcm@redhat.com" <jcm@redhat.com>, "andrea.gallo@linaro.org" <andrea.gallo@linaro.org>, "dhdang@apm.com" <dhdang@apm.com>, "jeremy.linton@arm.com" <jeremy.linton@arm.com> Subject: Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Date: Fri, 20 May 2016 00:41:28 -0400 [thread overview] Message-ID: <3d4aae09-51c4-f007-5100-191a4a85e27a@redhat.com> (raw) In-Reply-To: <57331290.7070104@semihalf.com> Hi Tomasz, all, On 05/11/2016 07:08 AM, Tomasz Nowicki wrote: > On 11.05.2016 12:41, Gabriele Paoloni wrote: >>> v6 -> v7 >>> - drop quirks handling >> >> Maybe I missed something in the v6 discussion thread; when was it >> decided to drop quirk handling? > > I had such requests in previous series. A quick note on quirk handling. This, I believe, applies post-merge of the base infrastructure, which I realize will likely not have quirks. We've some "gen1" ARMv8 server platforms where we end up doing quirks (for things like forcing 32-bit config space accessors and the like) due to people repurposing existing embedded PCIe IP blocks or using them for the first time (especially in servers), and those being involved in the design not necessarily seeing this problem ahead of time, or not realizing that it would be an issue for servers. In the early days of ARM server designs 3-4 years ago, many of us had never really played with ECAM or realized how modern topologies are built. Anyway. We missed this one in our SBSA requirements. They say (words to the effect of) "thou shalt do PCIe the way it is done on servers" but they aren't prescriptive, and they don't tell people how that actually is in reality. That is being fixed. A lot of things are happening behind the scenes - especially with third party IP block providers (all of whom myself and others are speaking with directly about this) - to ensure that the next wave of designs won't repeat these mistakes. We don't have a time machine, but we can contain this from becoming an ongoing mess for upstream, and we will do so. It won't be a zoo. Various proposals have arisen for how to handle quirks in the longer term, including elaborate frameworks and tables to describe them generically. I would like to caution against such approaches, especially in the case that they deviate from practice on x86, or prior to being standardized fully with other Operating System vendors. I don't expect there to be too many more than the existing initial set of quirks we have seen posted. A number of "future" server SoCs have already been fixed prior to silicon, and new design starts are being warned not to make this a problem for us to have to clean up later. So, I would like to suggest that the eventual framework mirror the existing approach on x86 systems (matching DMI, etc.) and not be made into some kind of generic, utopia. This is a case where we want there to be pain involved (and upstream patches required) when people screw up, so that they have a level of pain in response to ever making this mistake in the future. If we try to create too grand a generic scheme and make it too easy to handle this kind of situation beyond the small number of existing offenders, we undermine efforts to force vendors to ensure that their IP blocks are compliant going forward. Side note: if you're a third party IP vendor and we didn't already speak about this one, drop me a line, and let's collaborate also on your test frameworks to make sure you're covered as well. Jon. -- Computer Architect | Sent from my Fedora powered laptop
WARNING: multiple messages have this Message-ID (diff)
From: jcm@redhat.com (Jon Masters) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Date: Fri, 20 May 2016 00:41:28 -0400 [thread overview] Message-ID: <3d4aae09-51c4-f007-5100-191a4a85e27a@redhat.com> (raw) In-Reply-To: <57331290.7070104@semihalf.com> Hi Tomasz, all, On 05/11/2016 07:08 AM, Tomasz Nowicki wrote: > On 11.05.2016 12:41, Gabriele Paoloni wrote: >>> v6 -> v7 >>> - drop quirks handling >> >> Maybe I missed something in the v6 discussion thread; when was it >> decided to drop quirk handling? > > I had such requests in previous series. A quick note on quirk handling. This, I believe, applies post-merge of the base infrastructure, which I realize will likely not have quirks. We've some "gen1" ARMv8 server platforms where we end up doing quirks (for things like forcing 32-bit config space accessors and the like) due to people repurposing existing embedded PCIe IP blocks or using them for the first time (especially in servers), and those being involved in the design not necessarily seeing this problem ahead of time, or not realizing that it would be an issue for servers. In the early days of ARM server designs 3-4 years ago, many of us had never really played with ECAM or realized how modern topologies are built. Anyway. We missed this one in our SBSA requirements. They say (words to the effect of) "thou shalt do PCIe the way it is done on servers" but they aren't prescriptive, and they don't tell people how that actually is in reality. That is being fixed. A lot of things are happening behind the scenes - especially with third party IP block providers (all of whom myself and others are speaking with directly about this) - to ensure that the next wave of designs won't repeat these mistakes. We don't have a time machine, but we can contain this from becoming an ongoing mess for upstream, and we will do so. It won't be a zoo. Various proposals have arisen for how to handle quirks in the longer term, including elaborate frameworks and tables to describe them generically. I would like to caution against such approaches, especially in the case that they deviate from practice on x86, or prior to being standardized fully with other Operating System vendors. I don't expect there to be too many more than the existing initial set of quirks we have seen posted. A number of "future" server SoCs have already been fixed prior to silicon, and new design starts are being warned not to make this a problem for us to have to clean up later. So, I would like to suggest that the eventual framework mirror the existing approach on x86 systems (matching DMI, etc.) and not be made into some kind of generic, utopia. This is a case where we want there to be pain involved (and upstream patches required) when people screw up, so that they have a level of pain in response to ever making this mistake in the future. If we try to create too grand a generic scheme and make it too easy to handle this kind of situation beyond the small number of existing offenders, we undermine efforts to force vendors to ensure that their IP blocks are compliant going forward. Side note: if you're a third party IP vendor and we didn't already speak about this one, drop me a line, and let's collaborate also on your test frameworks to make sure you're covered as well. Jon. -- Computer Architect | Sent from my Fedora powered laptop
next prev parent reply other threads:[~2016-05-20 4:41 UTC|newest] Thread overview: 239+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-05-10 15:19 [PATCH V7 00/11] Support for generic ACPI based PCI host controller Tomasz Nowicki 2016-05-10 15:19 ` Tomasz Nowicki 2016-05-10 15:19 ` [PATCH V7 01/11] PCI: Provide common functions for ECAM mapping Tomasz Nowicki 2016-05-10 15:19 ` Tomasz Nowicki 2016-05-10 15:19 ` Tomasz Nowicki 2016-05-10 15:19 ` [PATCH V7 02/11] PCI: generic, thunder: update to use generic ECAM API Tomasz Nowicki 2016-05-10 15:19 ` Tomasz Nowicki 2016-05-10 15:19 ` [PATCH V7 03/11] pci, of: Move the PCI I/O space management to PCI core code Tomasz Nowicki 2016-05-10 15:19 ` Tomasz Nowicki 2016-05-10 15:19 ` Tomasz Nowicki 2016-05-10 17:59 ` Rafael J. Wysocki 2016-05-10 17:59 ` Rafael J. Wysocki 2016-05-10 17:59 ` Rafael J. Wysocki 2016-05-10 17:59 ` Rafael J. Wysocki 2016-05-11 7:36 ` Tomasz Nowicki 2016-05-11 7:36 ` Tomasz Nowicki 2016-05-11 7:36 ` Tomasz Nowicki 2016-05-11 7:36 ` Tomasz Nowicki 2016-05-11 11:01 ` Arnd Bergmann 2016-05-11 11:01 ` Arnd Bergmann 2016-05-11 11:01 ` Arnd Bergmann 2016-05-11 11:01 ` Arnd Bergmann 2016-05-10 15:19 ` [PATCH V7 04/11] pci: Add new function to unmap IO resources Tomasz Nowicki 2016-05-10 15:19 ` Tomasz Nowicki 2016-05-10 15:19 ` Tomasz Nowicki 2016-05-23 8:28 ` Jayachandran C 2016-05-23 8:28 ` Jayachandran C 2016-05-23 8:28 ` Jayachandran C 2016-05-10 15:19 ` [PATCH V7 05/11] acpi, pci: Support IO resources when parsing PCI host bridge resources Tomasz Nowicki 2016-05-10 15:19 ` Tomasz Nowicki 2016-05-10 18:20 ` Rafael J. Wysocki 2016-05-10 18:20 ` Rafael J. Wysocki 2016-05-10 18:20 ` Rafael J. Wysocki 2016-05-10 18:20 ` Rafael J. Wysocki 2016-05-11 7:39 ` Tomasz Nowicki 2016-05-11 7:39 ` Tomasz Nowicki 2016-05-11 7:39 ` Tomasz Nowicki 2016-05-11 7:39 ` Tomasz Nowicki 2016-05-10 15:19 ` [PATCH V7 06/11] pci, acpi: Provide a way to assign bus domain number Tomasz Nowicki 2016-05-10 15:19 ` Tomasz Nowicki 2016-05-10 15:19 ` [PATCH V7 07/11] pci, acpi: Handle ACPI companion assignment Tomasz Nowicki 2016-05-10 15:19 ` Tomasz Nowicki 2016-05-10 15:19 ` Tomasz Nowicki 2016-05-10 18:37 ` Rafael J. Wysocki 2016-05-10 18:37 ` Rafael J. Wysocki 2016-05-10 18:37 ` Rafael J. Wysocki 2016-05-10 18:37 ` Rafael J. Wysocki 2016-05-10 18:43 ` Rafael J. Wysocki 2016-05-10 18:43 ` Rafael J. Wysocki 2016-05-10 18:43 ` Rafael J. Wysocki 2016-05-10 18:43 ` Rafael J. Wysocki 2016-05-11 10:11 ` Lorenzo Pieralisi 2016-05-11 10:11 ` Lorenzo Pieralisi 2016-05-11 10:11 ` Lorenzo Pieralisi 2016-05-11 10:11 ` Lorenzo Pieralisi 2016-05-11 20:30 ` Rafael J. Wysocki 2016-05-11 20:30 ` Rafael J. Wysocki 2016-05-11 20:30 ` Rafael J. Wysocki 2016-05-11 20:30 ` Rafael J. Wysocki 2016-05-11 22:43 ` Bjorn Helgaas 2016-05-11 22:43 ` Bjorn Helgaas 2016-05-11 22:43 ` Bjorn Helgaas 2016-05-11 22:43 ` Bjorn Helgaas 2016-05-12 10:01 ` Lorenzo Pieralisi 2016-05-12 10:01 ` Lorenzo Pieralisi 2016-05-12 10:01 ` Lorenzo Pieralisi 2016-05-12 10:01 ` Lorenzo Pieralisi 2016-05-12 10:43 ` Jayachandran C 2016-05-12 10:43 ` Jayachandran C 2016-05-12 10:43 ` Jayachandran C 2016-05-12 10:43 ` Jayachandran C 2016-05-12 11:27 ` Rafael J. Wysocki 2016-05-12 11:27 ` Rafael J. Wysocki 2016-05-12 11:27 ` Rafael J. Wysocki 2016-05-12 11:27 ` Rafael J. Wysocki 2016-05-13 10:32 ` Lorenzo Pieralisi 2016-05-13 10:32 ` Lorenzo Pieralisi 2016-05-13 10:32 ` Lorenzo Pieralisi 2016-05-13 10:32 ` Lorenzo Pieralisi 2016-05-12 10:50 ` Tomasz Nowicki 2016-05-12 10:50 ` Tomasz Nowicki 2016-05-12 10:50 ` Tomasz Nowicki 2016-05-12 10:50 ` Tomasz Nowicki 2016-05-12 12:08 ` Bjorn Helgaas 2016-05-12 12:08 ` Bjorn Helgaas 2016-05-12 12:08 ` Bjorn Helgaas 2016-05-12 12:08 ` Bjorn Helgaas 2016-05-17 3:11 ` Dongdong Liu 2016-05-17 3:11 ` Dongdong Liu 2016-05-17 3:11 ` Dongdong Liu 2016-05-17 13:44 ` Tomasz Nowicki 2016-05-17 13:44 ` Tomasz Nowicki 2016-05-10 15:19 ` [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller Tomasz Nowicki 2016-05-10 15:19 ` Tomasz Nowicki 2016-05-10 17:54 ` Rafael J. Wysocki 2016-05-10 17:54 ` Rafael J. Wysocki 2016-05-10 17:54 ` Rafael J. Wysocki 2016-05-10 17:54 ` Rafael J. Wysocki 2016-05-10 18:18 ` Rafael J. Wysocki 2016-05-10 18:18 ` Rafael J. Wysocki 2016-05-10 18:18 ` Rafael J. Wysocki 2016-05-10 18:18 ` Rafael J. Wysocki 2016-05-13 11:25 ` Jayachandran C 2016-05-13 11:25 ` Jayachandran C 2016-05-13 11:25 ` Jayachandran C 2016-05-13 11:31 ` Rafael J. Wysocki 2016-05-13 11:31 ` Rafael J. Wysocki 2016-05-13 11:31 ` Rafael J. Wysocki 2016-05-13 11:31 ` Rafael J. Wysocki 2016-05-13 11:42 ` Tomasz Nowicki 2016-05-13 11:42 ` Tomasz Nowicki 2016-05-13 11:42 ` Tomasz Nowicki 2016-05-13 11:42 ` Tomasz Nowicki 2016-05-14 9:07 ` Jayachandran C 2016-05-14 9:07 ` Jayachandran C 2016-05-14 9:07 ` Jayachandran C 2016-05-23 11:34 ` Tomasz Nowicki 2016-05-23 11:34 ` Tomasz Nowicki 2016-05-23 11:34 ` Tomasz Nowicki 2016-05-19 16:56 ` Matthias Brugger 2016-05-19 16:56 ` Matthias Brugger 2016-05-10 15:19 ` [PATCH V7 09/11] arm64, pci, acpi: ACPI support for legacy IRQs parsing and consolidation with DT code Tomasz Nowicki 2016-05-10 15:19 ` Tomasz Nowicki 2016-05-10 15:20 ` [PATCH V7 10/11] arm64, pci, acpi: Provide ACPI-specific prerequisites for PCI bus enumeration Tomasz Nowicki 2016-05-10 15:20 ` Tomasz Nowicki 2016-05-10 15:20 ` [PATCH V7 11/11] arm64, pci, acpi: Start using ACPI based PCI host controller driver for ARM64 Tomasz Nowicki 2016-05-10 15:20 ` Tomasz Nowicki 2016-05-11 10:41 ` [PATCH V7 00/11] Support for generic ACPI based PCI host controller Gabriele Paoloni 2016-05-11 10:41 ` Gabriele Paoloni 2016-05-11 10:41 ` Gabriele Paoloni 2016-05-11 10:41 ` Gabriele Paoloni 2016-05-11 11:08 ` Tomasz Nowicki 2016-05-11 11:08 ` Tomasz Nowicki 2016-05-11 11:08 ` Tomasz Nowicki 2016-05-11 11:08 ` Tomasz Nowicki 2016-05-11 12:53 ` Gabriele Paoloni 2016-05-11 12:53 ` Gabriele Paoloni 2016-05-11 12:53 ` Gabriele Paoloni 2016-05-11 12:53 ` Gabriele Paoloni 2016-05-20 4:41 ` Jon Masters [this message] 2016-05-20 4:41 ` Jon Masters 2016-05-20 4:41 ` Jon Masters 2016-05-20 7:37 ` Ard Biesheuvel 2016-05-20 7:37 ` Ard Biesheuvel 2016-05-20 7:37 ` Ard Biesheuvel 2016-05-20 7:37 ` Ard Biesheuvel 2016-05-20 8:01 ` Jon Masters 2016-05-20 8:01 ` Jon Masters 2016-05-20 8:01 ` Jon Masters 2016-05-20 8:01 ` Jon Masters 2016-05-20 8:28 ` Ard Biesheuvel 2016-05-20 8:28 ` Ard Biesheuvel 2016-05-20 8:28 ` Ard Biesheuvel 2016-05-20 8:28 ` Ard Biesheuvel 2016-05-20 8:40 ` Gabriele Paoloni 2016-05-20 8:40 ` Gabriele Paoloni 2016-05-20 8:40 ` Gabriele Paoloni 2016-05-20 8:40 ` Gabriele Paoloni 2016-05-20 9:14 ` Ard Biesheuvel 2016-05-20 9:14 ` Ard Biesheuvel 2016-05-20 9:14 ` Ard Biesheuvel 2016-05-20 9:14 ` Ard Biesheuvel 2016-05-23 10:56 ` Lorenzo Pieralisi 2016-05-23 10:56 ` Lorenzo Pieralisi 2016-05-23 10:56 ` Lorenzo Pieralisi 2016-05-23 10:56 ` Lorenzo Pieralisi 2016-05-23 15:16 ` Gabriele Paoloni 2016-05-23 15:16 ` Gabriele Paoloni 2016-05-23 15:16 ` Gabriele Paoloni 2016-05-23 15:16 ` Gabriele Paoloni 2016-05-23 23:39 ` Bjorn Helgaas 2016-05-23 23:39 ` Bjorn Helgaas 2016-05-23 23:39 ` Bjorn Helgaas 2016-05-23 23:39 ` Bjorn Helgaas 2016-05-24 1:11 ` Jon Masters 2016-05-24 1:11 ` Jon Masters 2016-05-24 1:11 ` Jon Masters 2016-05-24 1:11 ` Jon Masters 2016-05-24 1:48 ` Jon Masters 2016-05-24 1:48 ` Jon Masters 2016-05-24 1:48 ` Jon Masters 2016-05-24 1:48 ` Jon Masters 2016-05-24 14:33 ` Gabriele Paoloni 2016-05-24 14:33 ` Gabriele Paoloni 2016-05-24 14:33 ` Gabriele Paoloni 2016-05-24 14:33 ` Gabriele Paoloni 2016-05-24 7:23 ` Gabriele Paoloni 2016-05-24 7:23 ` Gabriele Paoloni 2016-05-24 7:23 ` Gabriele Paoloni 2016-05-24 7:23 ` Gabriele Paoloni 2016-05-24 14:38 ` Jon Masters 2016-05-24 14:38 ` Jon Masters 2016-05-24 14:38 ` Jon Masters 2016-05-24 14:38 ` Jon Masters 2016-05-24 17:24 ` Lorenzo Pieralisi 2016-05-24 17:24 ` Lorenzo Pieralisi 2016-05-24 17:24 ` Lorenzo Pieralisi 2016-05-24 17:24 ` Lorenzo Pieralisi 2016-05-24 17:35 ` Jon Masters 2016-05-24 17:35 ` Jon Masters 2016-05-24 17:35 ` Jon Masters 2016-05-24 17:35 ` Jon Masters 2016-05-24 19:00 ` Bjorn Helgaas 2016-05-24 19:00 ` Bjorn Helgaas 2016-05-24 19:00 ` Bjorn Helgaas 2016-05-24 19:00 ` Bjorn Helgaas 2016-05-26 9:58 ` Gabriele Paoloni 2016-05-26 9:58 ` Gabriele Paoloni 2016-05-26 9:58 ` Gabriele Paoloni 2016-05-26 9:58 ` Gabriele Paoloni 2016-05-25 6:31 ` Gabriele Paoloni 2016-05-25 6:31 ` Gabriele Paoloni 2016-05-25 6:31 ` Gabriele Paoloni 2016-05-25 6:31 ` Gabriele Paoloni 2016-05-24 4:20 ` Jon Masters 2016-05-24 4:20 ` Jon Masters 2016-05-24 4:20 ` Jon Masters 2016-05-24 4:20 ` Jon Masters 2016-05-20 8:11 ` Gabriele Paoloni 2016-05-20 8:11 ` Gabriele Paoloni 2016-05-20 8:11 ` Gabriele Paoloni 2016-05-20 8:11 ` Gabriele Paoloni 2016-05-20 8:24 ` Jon Masters 2016-05-20 8:24 ` Jon Masters 2016-05-20 8:24 ` Jon Masters 2016-05-20 8:24 ` Jon Masters 2016-05-13 2:55 ` Duc Dang 2016-05-13 2:55 ` Duc Dang 2016-05-13 2:55 ` Duc Dang 2016-05-19 18:18 ` Jeremy Linton 2016-05-19 18:18 ` Jeremy Linton 2016-05-20 7:46 ` Jon Masters 2016-05-20 7:46 ` Jon Masters 2016-05-20 7:46 ` Jon Masters 2016-05-23 11:25 ` Dongdong Liu 2016-05-23 11:25 ` Dongdong Liu 2016-05-23 11:25 ` Dongdong Liu 2016-05-23 15:36 ` Sinan Kaya 2016-05-23 15:36 ` Sinan Kaya
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=3d4aae09-51c4-f007-5100-191a4a85e27a@redhat.com \ --to=jcm@redhat.com \ --cc=Liviu.Dudau@arm.com \ --cc=Lorenzo.Pieralisi@arm.com \ --cc=Suravee.Suthikulpanit@amd.com \ --cc=andrea.gallo@linaro.org \ --cc=arnd@arndb.de \ --cc=catalin.marinas@arm.com \ --cc=ddaney@caviumnetworks.com \ --cc=dhdang@apm.com \ --cc=gabriele.paoloni@huawei.com \ --cc=hanjun.guo@linaro.org \ --cc=helgaas@kernel.org \ --cc=jchandra@broadcom.com \ --cc=jeremy.linton@arm.com \ --cc=linaro-acpi@lists.linaro.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=msalter@redhat.com \ --cc=mw@semihalf.com \ --cc=okaya@codeaurora.org \ --cc=rafael@kernel.org \ --cc=robert.richter@caviumnetworks.com \ --cc=tn@semihalf.com \ --cc=wangyijing@huawei.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: linkBe 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.