From: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org> To: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Cc: Vidya Sagar <vidyas-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>, bjorn-vnFzb0PiAZFBDgjK7y7TUQ@public.gmane.org, Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>, Len Brown <lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Andrew Murray <andrew.murray-5wv7dgnIgG8@public.gmane.org>, treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org, jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, kthota-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org, mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org, sagar.tv-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Subject: Re: [PATCH] PCI: Add MCFG quirks for Tegra194 host controllers Date: Mon, 20 Jan 2020 15:18:49 +0000 [thread overview] Message-ID: <20200120151849.GA24402@e121166-lin.cambridge.arm.com> (raw) In-Reply-To: <20200120111042.GA203160@ulmo> On Mon, Jan 20, 2020 at 12:10:42PM +0100, Thierry Reding wrote: [...] > > > Currently the BSP has the kernel booting through Device Tree mechanism > > > and there is a plan to support UEFI based boot as well in the future software > > > releases for which we need this quirky way of handling ECAM. > > > Tegra194 is going to be the only and last chip with this issue and next chip > > > in line in Tegra SoC series will be fully compliant with ECAM. > > > > ACPI on ARM64 works on a standard subset of systems, defined by the > > ARM SBSA: > > > > http://infocenter.arm.com/help/topic/com.arm.doc.den0029c/Server_Base_System_Architecture_v6_0_ARM_DEN_0029C_SBSA_6_0.pdf > > I don't understand what you're saying here. Are you saying that you want > to prevent vendors from upstreaming code that they need to support their > ACPI based platforms? I understand that the lack of support for proper > ECAM means that a platform will not be SBSA compatible, but I wasn't > aware that lack of SBSA compatibility meant that a platform would be > prohibited from implementing ACPI support in an upstream kernel. ACPI on ARM64 requires a set of HW components described in the SBSA. If those HW requirements are not fulfilled you can't bootstrap an ARM64 system with ACPI - it is as simple as that. It is not even appropriate to discuss this on a Linux mailing list anymore since it is HW requirements and it has been public information since ACPI on ARM64 was first enabled. > > These patches will have to be carried out of tree, the MCFG quirk > > mechanism (merged as Bjorn said more than three years ago) was supposed > > to be a temporary plaster to bootstrap server platforms with teething > > issues, the aim is to remove it eventually not to add more code to it > > indefinitely. > > Now, I fully agree that quirks are suboptimal and we'd all prefer if we > didn't have to deal with them. Unfortunately the reality is that > mistakes happen and hardware doesn't always work the way we want it to. > There's plenty of other quirk mechanisms in the kernel, and frankly this > one isn't really that bad in comparison. Because you don't have to maintain it ;) - I think I said what I had to say about the MCFG mechanism in the past - it has been three years and counting - it is time to remove it rather that adding to it. > > So I am afraid but this quirk (and any other coming our way) will not be > > merged in an upstream kernel anymore - for any queries please put Nvidia > > in touch. > > Again, I don't understand what you're trying to achieve here. You seem > to be saying that we categorically can't support this hardware because > it isn't fully SBSA compatible. I am not trying to achieve anything - I am just stating public information - let me repeat it again for interested readers: to bootstrap an ARM64 system with ACPI the platform HW design must follow the SBSA guidelines. > Do you have any alternative suggestions on how we can support this in an > upstream kernel? Booting with a device tree ? > We realized a while ago that we cannot achieve proper ECAM on Tegra194 > because of some issues with the hardware and we've provided this as > feedback to the hardware engineers. As a result, the next generation of > Tegra should no longer suffer from these issues. We will bootstrap next generation Tegra with ACPI then, there are SBSA tests available for compliancy - again, that's a matter for Nvidia and Arm to settle, not a mailing list discussion. > As for Tegra194, that chip taped out two years ago and it isn't possible > to make it fully ECAM compliant other than by revising the chip, which, > frankly, isn't going to happen. > > So I see two options here: either we find a way of dealing with this, by > either merging this quirk or finding an alternative solution, or we make > the decision that some hardware just can't be supported. > > The former is fairly common, whereas I've never heard of the latter. What does this mean ? Should I wreck the upstream kernel to make it boot with ACPI on *any* ARM64 platform out there then ? My stance is clear above and the ACPI PCI programming model - inclusive of firmware - has been there since ACPI was deployed, if ACPI support is required HW must comply, either that or it is out of tree patches and I can't be blamed for that. Thanks, Lorenzo
WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> To: Thierry Reding <thierry.reding@gmail.com> Cc: Vidya Sagar <vidyas@nvidia.com>, bjorn@helgaas.com, Bjorn Helgaas <bhelgaas@google.com>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Len Brown <lenb@kernel.org>, Andrew Murray <andrew.murray@arm.com>, treding@nvidia.com, jonathanh@nvidia.com, linux-tegra@vger.kernel.org, linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>, kthota@nvidia.com, mmaddireddy@nvidia.com, sagar.tv@gmail.com Subject: Re: [PATCH] PCI: Add MCFG quirks for Tegra194 host controllers Date: Mon, 20 Jan 2020 15:18:49 +0000 [thread overview] Message-ID: <20200120151849.GA24402@e121166-lin.cambridge.arm.com> (raw) In-Reply-To: <20200120111042.GA203160@ulmo> On Mon, Jan 20, 2020 at 12:10:42PM +0100, Thierry Reding wrote: [...] > > > Currently the BSP has the kernel booting through Device Tree mechanism > > > and there is a plan to support UEFI based boot as well in the future software > > > releases for which we need this quirky way of handling ECAM. > > > Tegra194 is going to be the only and last chip with this issue and next chip > > > in line in Tegra SoC series will be fully compliant with ECAM. > > > > ACPI on ARM64 works on a standard subset of systems, defined by the > > ARM SBSA: > > > > http://infocenter.arm.com/help/topic/com.arm.doc.den0029c/Server_Base_System_Architecture_v6_0_ARM_DEN_0029C_SBSA_6_0.pdf > > I don't understand what you're saying here. Are you saying that you want > to prevent vendors from upstreaming code that they need to support their > ACPI based platforms? I understand that the lack of support for proper > ECAM means that a platform will not be SBSA compatible, but I wasn't > aware that lack of SBSA compatibility meant that a platform would be > prohibited from implementing ACPI support in an upstream kernel. ACPI on ARM64 requires a set of HW components described in the SBSA. If those HW requirements are not fulfilled you can't bootstrap an ARM64 system with ACPI - it is as simple as that. It is not even appropriate to discuss this on a Linux mailing list anymore since it is HW requirements and it has been public information since ACPI on ARM64 was first enabled. > > These patches will have to be carried out of tree, the MCFG quirk > > mechanism (merged as Bjorn said more than three years ago) was supposed > > to be a temporary plaster to bootstrap server platforms with teething > > issues, the aim is to remove it eventually not to add more code to it > > indefinitely. > > Now, I fully agree that quirks are suboptimal and we'd all prefer if we > didn't have to deal with them. Unfortunately the reality is that > mistakes happen and hardware doesn't always work the way we want it to. > There's plenty of other quirk mechanisms in the kernel, and frankly this > one isn't really that bad in comparison. Because you don't have to maintain it ;) - I think I said what I had to say about the MCFG mechanism in the past - it has been three years and counting - it is time to remove it rather that adding to it. > > So I am afraid but this quirk (and any other coming our way) will not be > > merged in an upstream kernel anymore - for any queries please put Nvidia > > in touch. > > Again, I don't understand what you're trying to achieve here. You seem > to be saying that we categorically can't support this hardware because > it isn't fully SBSA compatible. I am not trying to achieve anything - I am just stating public information - let me repeat it again for interested readers: to bootstrap an ARM64 system with ACPI the platform HW design must follow the SBSA guidelines. > Do you have any alternative suggestions on how we can support this in an > upstream kernel? Booting with a device tree ? > We realized a while ago that we cannot achieve proper ECAM on Tegra194 > because of some issues with the hardware and we've provided this as > feedback to the hardware engineers. As a result, the next generation of > Tegra should no longer suffer from these issues. We will bootstrap next generation Tegra with ACPI then, there are SBSA tests available for compliancy - again, that's a matter for Nvidia and Arm to settle, not a mailing list discussion. > As for Tegra194, that chip taped out two years ago and it isn't possible > to make it fully ECAM compliant other than by revising the chip, which, > frankly, isn't going to happen. > > So I see two options here: either we find a way of dealing with this, by > either merging this quirk or finding an alternative solution, or we make > the decision that some hardware just can't be supported. > > The former is fairly common, whereas I've never heard of the latter. What does this mean ? Should I wreck the upstream kernel to make it boot with ACPI on *any* ARM64 platform out there then ? My stance is clear above and the ACPI PCI programming model - inclusive of firmware - has been there since ACPI was deployed, if ACPI support is required HW must comply, either that or it is out of tree patches and I can't be blamed for that. Thanks, Lorenzo
next prev parent reply other threads:[~2020-01-20 15:18 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-03 17:49 [PATCH] PCI: Add MCFG quirks for Tegra194 host controllers Vidya Sagar 2020-01-03 17:49 ` Vidya Sagar 2020-01-03 18:04 ` Bjorn Helgaas 2020-01-04 3:44 ` Vidya Sagar 2020-01-04 3:44 ` Vidya Sagar 2020-01-17 12:17 ` Lorenzo Pieralisi 2020-01-20 11:10 ` Thierry Reding 2020-01-20 15:18 ` Lorenzo Pieralisi [this message] 2020-01-20 15:18 ` Lorenzo Pieralisi [not found] ` <20200120151849.GA24402-LhTu/34fCX3ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> 2020-01-21 13:44 ` Thierry Reding 2020-01-21 13:44 ` Thierry Reding 2020-01-23 10:49 ` Lorenzo Pieralisi 2020-01-23 10:49 ` Lorenzo Pieralisi 2020-02-06 16:46 ` Thierry Reding 2020-02-07 14:50 ` Bjorn Helgaas 2020-02-07 16:51 ` Thierry Reding 2020-02-07 18:34 ` Bjorn Helgaas 2020-01-04 21:53 ` kbuild test robot 2020-01-04 21:53 ` kbuild test robot 2020-01-04 21:53 ` kbuild test robot 2020-01-06 8:27 ` [PATCH V2] " Vidya Sagar 2020-01-06 8:27 ` Vidya Sagar [not found] ` <20200106082709.14370-1-vidyas-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2020-01-10 19:14 ` [PATCH V3 0/2] " Vidya Sagar 2020-01-10 19:14 ` Vidya Sagar [not found] ` <20200110191500.9538-1-vidyas-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2020-01-10 19:14 ` [PATCH V3 1/2] arm64: tegra: Re-order PCIe aperture mappings to support ACPI boot Vidya Sagar 2020-01-10 19:14 ` Vidya Sagar 2020-06-29 13:31 ` Jon Hunter 2020-06-29 13:31 ` Jon Hunter 2020-06-30 10:52 ` Vidya Sagar 2020-06-30 10:52 ` Vidya Sagar 2020-01-10 19:15 ` [PATCH V3 2/2] PCI: Add MCFG quirks for Tegra194 host controllers Vidya Sagar 2020-01-10 19:15 ` Vidya Sagar 2020-01-17 11:42 ` Thierry Reding 2021-03-05 21:57 ` Bjorn Helgaas 2021-03-05 23:04 ` Krzysztof Wilczyński 2021-04-16 13:45 ` Vidya Sagar 2021-04-16 13:45 ` [PATCH V4] " Vidya Sagar 2021-04-16 19:06 ` Bjorn Helgaas 2021-05-13 9:40 ` [PATCH V3 2/2] " Qu Wenruo 2021-05-13 13:05 ` Vidya Sagar 2020-01-16 17:18 ` [PATCH V3 0/2] " Vidya Sagar 2020-01-16 17:18 ` Vidya Sagar
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=20200120151849.GA24402@e121166-lin.cambridge.arm.com \ --to=lorenzo.pieralisi-5wv7dgnigg8@public.gmane.org \ --cc=andrew.murray-5wv7dgnIgG8@public.gmane.org \ --cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \ --cc=bjorn-vnFzb0PiAZFBDgjK7y7TUQ@public.gmane.org \ --cc=jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \ --cc=kthota-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \ --cc=lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \ --cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \ --cc=sagar.tv-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \ --cc=vidyas-DDmLM1+adcrQT0dZR+AlfA@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: 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.