From: Olof Johansson <olof@lixom.net> To: Robin Murphy <robin.murphy@arm.com> Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>, Li Yang <leoyang.li@nxp.com>, "mark.rutland@arm.com" <mark.rutland@arm.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, "arnd@arndb.de" <arnd@arndb.de>, "m.karthikeyan@mobiveil.co.in" <m.karthikeyan@mobiveil.co.in>, "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>, "Z.q. Hou" <zhiqiang.hou@nxp.com>, "l.subrahmanya@mobiveil.co.in" <l.subrahmanya@mobiveil.co.in>, "will.deacon@arm.com" <will.deacon@arm.com>, Russell King - ARM Linux admin <linux@armlinux.org.uk>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "M.h. Lian" <minghuan.lian@nxp.com>, "robh+dt@kernel.org" <robh+dt@kernel.org>, Xiaowei Bao <xiaowei.bao@nxp.com>, "catalin.marinas@arm.com" <catalin.marinas@arm.com>, "bhelgaas@google.com" <bhelgaas@google.com>, "andrew.murray@arm.com" <andrew.murray@arm.com>, "shawnguo@kernel.org" <shawnguo@kernel.org>, Mingkai Hu <mingkai.hu@nxp.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCHv9 00/12] PCI: Recode Mobiveil driver and add PCIe Gen4 driver for NXP Layerscape SoCs Date: Tue, 11 Feb 2020 06:48:30 -0800 [thread overview] Message-ID: <CAOesGMhVA9NSbAi-BtcgQBBK90jeT+NcQ6j_FDgjuR7efE65Vg@mail.gmail.com> (raw) In-Reply-To: <aec47903-50e4-c61b-6aec-63e3e9bc9332@arm.com> On Tue, Feb 11, 2020 at 5:04 AM Robin Murphy <robin.murphy@arm.com> wrote: > > On 2020-02-11 12:13 pm, Laurentiu Tudor wrote: > [...] > >> This is a known issue about DPAA2 MC bus not working well with SMMU > >> based IO mapping. Adding Laurentiu to the chain who has been looking > >> into this issue. > > > > Yes, I'm closely following the issue. I actually have a workaround > > (attached) but haven't submitted as it will probably raise a lot of > > eyebrows. In the mean time I'm following some discussions [1][2][3] on > > the iommu list which seem to try to tackle what appears to be a similar > > issue but with framebuffers. My hope is that we will be able to leverage > > whatever turns out. > > Indeed it's more general than framebuffers - in fact there was a > specific requirement from the IORT side to accommodate network/storage > controllers with in-memory firmware/configuration data/whatever set up > by the bootloader that want to be handed off 'live' to Linux because the > overhead of stopping and restarting them is impractical. Thus this DPAA2 > setup is very much within scope of the desired solution, so please feel > free to join in (particularly on the DT parts) :) That's a real problem that nees a solution, but that's not what's happening here, since cold boots works fine. Isn't it a whole lot more likely that something isn't reset/reinitialized properly in u-boot, such that there is lingering state in the setup, causing this? > As for right now, note that your patch would only be a partial > mitigation to slightly reduce the fault window but not remove it > entirely. To be robust the SMMU driver *has* to know about live streams > before the first arm_smmu_reset() - hence the need for generic firmware > bindings - so doing anything from the MC driver is already too late (and > indeed the current iommu_request_dm_for_dev() mechanism is itself a > microcosm of the same problem). This is more likely a live stream that's left behind from the previous kernel (there are some error messages about being unable to detach domains, but the errors make it hard to tell what driver didn't unbind enough). *BUT*, even with that bug, the system should reboot reliably and come up clean. So, something isn't clearing up the state *on boot*. > > In the mean time, can you try the workaround Leo suggested? > > Agreed, I'd imagine the command-line option is probably the best choice > for these platforms, since it's likely to be easier to set that by > default in the bootloader than faff with rebuilding generic kernel configs. For the generic user, definitely. I'll give it a go later this week when I have a bit more spare time with the device physically present. -Olof
WARNING: multiple messages have this Message-ID (diff)
From: Olof Johansson <olof@lixom.net> To: Robin Murphy <robin.murphy@arm.com> Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>, "m.karthikeyan@mobiveil.co.in" <m.karthikeyan@mobiveil.co.in>, "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>, "will.deacon@arm.com" <will.deacon@arm.com>, "M.h. Lian" <minghuan.lian@nxp.com>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, Russell King - ARM Linux admin <linux@armlinux.org.uk>, Mingkai Hu <mingkai.hu@nxp.com>, "catalin.marinas@arm.com" <catalin.marinas@arm.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "arnd@arndb.de" <arnd@arndb.de>, "Z.q. Hou" <zhiqiang.hou@nxp.com>, "robh+dt@kernel.org" <robh+dt@kernel.org>, "bhelgaas@google.com" <bhelgaas@google.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Laurentiu Tudor <laurentiu.tudor@nxp.com>, Xiaowei Bao <xiaowei.bao@nxp.com>, "l.subrahmanya@mobiveil.co.in" <l.subrahmanya@mobiveil.co.in>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Li Yang <leoyang.li@nxp.com>, "andrew.murray@arm.com" <andrew.murray@arm.com>, "shawnguo@kernel.org" <shawnguo@kernel.org> Subject: Re: [PATCHv9 00/12] PCI: Recode Mobiveil driver and add PCIe Gen4 driver for NXP Layerscape SoCs Date: Tue, 11 Feb 2020 06:48:30 -0800 [thread overview] Message-ID: <CAOesGMhVA9NSbAi-BtcgQBBK90jeT+NcQ6j_FDgjuR7efE65Vg@mail.gmail.com> (raw) In-Reply-To: <aec47903-50e4-c61b-6aec-63e3e9bc9332@arm.com> On Tue, Feb 11, 2020 at 5:04 AM Robin Murphy <robin.murphy@arm.com> wrote: > > On 2020-02-11 12:13 pm, Laurentiu Tudor wrote: > [...] > >> This is a known issue about DPAA2 MC bus not working well with SMMU > >> based IO mapping. Adding Laurentiu to the chain who has been looking > >> into this issue. > > > > Yes, I'm closely following the issue. I actually have a workaround > > (attached) but haven't submitted as it will probably raise a lot of > > eyebrows. In the mean time I'm following some discussions [1][2][3] on > > the iommu list which seem to try to tackle what appears to be a similar > > issue but with framebuffers. My hope is that we will be able to leverage > > whatever turns out. > > Indeed it's more general than framebuffers - in fact there was a > specific requirement from the IORT side to accommodate network/storage > controllers with in-memory firmware/configuration data/whatever set up > by the bootloader that want to be handed off 'live' to Linux because the > overhead of stopping and restarting them is impractical. Thus this DPAA2 > setup is very much within scope of the desired solution, so please feel > free to join in (particularly on the DT parts) :) That's a real problem that nees a solution, but that's not what's happening here, since cold boots works fine. Isn't it a whole lot more likely that something isn't reset/reinitialized properly in u-boot, such that there is lingering state in the setup, causing this? > As for right now, note that your patch would only be a partial > mitigation to slightly reduce the fault window but not remove it > entirely. To be robust the SMMU driver *has* to know about live streams > before the first arm_smmu_reset() - hence the need for generic firmware > bindings - so doing anything from the MC driver is already too late (and > indeed the current iommu_request_dm_for_dev() mechanism is itself a > microcosm of the same problem). This is more likely a live stream that's left behind from the previous kernel (there are some error messages about being unable to detach domains, but the errors make it hard to tell what driver didn't unbind enough). *BUT*, even with that bug, the system should reboot reliably and come up clean. So, something isn't clearing up the state *on boot*. > > In the mean time, can you try the workaround Leo suggested? > > Agreed, I'd imagine the command-line option is probably the best choice > for these platforms, since it's likely to be easier to set that by > default in the bootloader than faff with rebuilding generic kernel configs. For the generic user, definitely. I'll give it a go later this week when I have a bit more spare time with the device physically present. -Olof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-02-11 14:48 UTC|newest] Thread overview: 128+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-20 3:45 [PATCHv9 00/12] PCI: Recode Mobiveil driver and add PCIe Gen4 driver for NXP Layerscape SoCs Z.q. Hou 2019-11-20 3:45 ` Z.q. Hou 2019-11-20 3:45 ` [PATCHv9 01/12] PCI: mobiveil: Re-abstract the private structure Z.q. Hou 2019-11-20 3:45 ` Z.q. Hou 2020-01-13 10:09 ` Andrew Murray 2020-01-13 10:09 ` Andrew Murray 2020-02-06 11:04 ` Z.q. Hou 2020-02-06 11:04 ` Z.q. Hou 2020-02-06 11:27 ` Andrew Murray 2020-02-06 11:27 ` Andrew Murray 2019-11-20 3:45 ` [PATCHv9 02/12] PCI: mobiveil: Move the host initialization into a routine Z.q. Hou 2019-11-20 3:45 ` Z.q. Hou 2020-01-13 10:19 ` Andrew Murray 2020-01-13 10:19 ` Andrew Murray 2020-02-06 11:14 ` Z.q. Hou 2020-02-06 11:14 ` Z.q. Hou 2019-11-20 3:45 ` [PATCHv9 03/12] PCI: mobiveil: Collect the interrupt related operations " Z.q. Hou 2019-11-20 3:45 ` Z.q. Hou 2020-01-13 10:34 ` Andrew Murray 2020-01-13 10:34 ` Andrew Murray 2020-02-06 11:30 ` Z.q. Hou 2020-02-06 11:30 ` Z.q. Hou 2019-11-20 3:45 ` [PATCHv9 04/12] PCI: mobiveil: Modularize the Mobiveil PCIe Host Bridge IP driver Z.q. Hou 2019-11-20 3:45 ` Z.q. Hou 2020-01-13 11:05 ` Andrew Murray 2020-01-13 11:05 ` Andrew Murray 2020-02-06 12:25 ` Z.q. Hou 2020-02-06 12:25 ` Z.q. Hou 2019-11-20 3:45 ` [PATCHv9 05/12] PCI: mobiveil: Add callback function for interrupt initialization Z.q. Hou 2019-11-20 3:45 ` Z.q. Hou 2020-01-13 11:19 ` Andrew Murray 2020-01-13 11:19 ` Andrew Murray 2020-02-06 13:25 ` Z.q. Hou 2020-02-06 13:25 ` Z.q. Hou 2019-11-20 3:45 ` [PATCHv9 06/12] PCI: mobiveil: Add callback function for link up check Z.q. Hou 2019-11-20 3:45 ` Z.q. Hou 2020-01-13 11:22 ` Andrew Murray 2020-01-13 11:22 ` Andrew Murray 2020-02-06 13:25 ` Z.q. Hou 2020-02-06 13:25 ` Z.q. Hou 2019-11-20 3:46 ` [PATCHv9 07/12] PCI: mobiveil: Make mobiveil_host_init() can be used to re-init host Z.q. Hou 2019-11-20 3:46 ` Z.q. Hou 2020-01-13 11:26 ` Andrew Murray 2020-01-13 11:26 ` Andrew Murray 2020-02-06 13:27 ` Z.q. Hou 2020-02-06 13:27 ` Z.q. Hou 2019-11-20 3:46 ` [PATCHv9 08/12] PCI: mobiveil: Add 8-bit and 16-bit CSR register accessors Z.q. Hou 2019-11-20 3:46 ` Z.q. Hou 2020-01-13 11:31 ` Andrew Murray 2020-01-13 11:31 ` Andrew Murray 2020-02-06 13:45 ` Z.q. Hou 2020-02-06 13:45 ` Z.q. Hou 2019-11-20 3:46 ` [PATCHv9 09/12] dt-bindings: PCI: Add NXP Layerscape SoCs PCIe Gen4 controller Z.q. Hou 2019-11-20 3:46 ` Z.q. Hou 2019-11-20 3:46 ` [PATCHv9 10/12] PCI: mobiveil: Add PCIe Gen4 RC driver for NXP Layerscape SoCs Z.q. Hou 2019-11-20 3:46 ` Z.q. Hou 2020-01-13 12:02 ` Andrew Murray 2020-01-13 12:02 ` Andrew Murray 2020-02-06 13:45 ` Z.q. Hou 2020-02-06 13:45 ` Z.q. Hou 2020-02-06 14:29 ` Andrew Murray 2020-02-06 14:29 ` Andrew Murray 2019-11-20 3:46 ` [PATCHv9 11/12] arm64: dts: lx2160a: Add PCIe controller DT nodes Z.q. Hou 2019-11-20 3:46 ` Z.q. Hou 2019-11-20 3:46 ` [PATCHv9 12/12] arm64: defconfig: Enable CONFIG_PCIE_LAYERSCAPE_GEN4 Z.q. Hou 2019-11-20 3:46 ` Z.q. Hou 2019-11-20 9:57 ` [PATCHv9 00/12] PCI: Recode Mobiveil driver and add PCIe Gen4 driver for NXP Layerscape SoCs Russell King - ARM Linux admin 2019-11-20 9:57 ` Russell King - ARM Linux admin 2019-11-20 10:30 ` Z.q. Hou 2019-11-20 10:30 ` Z.q. Hou 2019-12-13 18:37 ` Olof Johansson 2019-12-13 18:37 ` Olof Johansson 2019-12-17 2:50 ` Z.q. Hou 2019-12-17 2:50 ` Z.q. Hou 2020-01-10 15:33 ` Lorenzo Pieralisi 2020-01-10 15:33 ` Lorenzo Pieralisi 2020-01-10 17:05 ` Olof Johansson 2020-01-10 17:05 ` Olof Johansson 2020-02-06 10:57 ` Z.q. Hou 2020-02-06 10:57 ` Z.q. Hou 2020-02-10 15:12 ` Olof Johansson 2020-02-10 15:12 ` Olof Johansson 2020-02-10 15:22 ` Russell King - ARM Linux admin 2020-02-10 15:22 ` Russell King - ARM Linux admin 2020-02-10 15:28 ` Olof Johansson 2020-02-10 15:28 ` Olof Johansson 2020-02-10 16:15 ` Russell King - ARM Linux admin 2020-02-10 16:15 ` Russell King - ARM Linux admin 2020-02-10 17:20 ` Russell King - ARM Linux admin 2020-02-10 17:20 ` Russell King - ARM Linux admin 2020-02-10 18:33 ` Olof Johansson 2020-02-10 18:33 ` Olof Johansson 2020-02-10 18:41 ` Li Yang 2020-02-10 18:41 ` Li Yang 2020-02-10 19:48 ` Li Yang 2020-02-10 19:48 ` Li Yang 2020-02-11 12:13 ` Laurentiu Tudor 2020-02-11 12:13 ` Laurentiu Tudor 2020-02-11 13:04 ` Robin Murphy 2020-02-11 13:04 ` Robin Murphy 2020-02-11 13:55 ` Laurentiu Tudor 2020-02-11 13:55 ` Laurentiu Tudor 2020-02-11 14:51 ` Robin Murphy 2020-02-11 14:51 ` Robin Murphy 2020-02-11 14:48 ` Olof Johansson [this message] 2020-02-11 14:48 ` Olof Johansson 2020-02-11 15:14 ` Laurentiu Tudor 2020-02-11 15:14 ` Laurentiu Tudor 2020-02-29 9:55 ` Russell King - ARM Linux admin 2020-02-29 9:55 ` Russell King - ARM Linux admin 2020-02-29 11:04 ` Russell King - ARM Linux admin 2020-02-29 11:04 ` Russell King - ARM Linux admin 2020-02-29 12:08 ` Russell King - ARM Linux admin 2020-02-29 12:08 ` Russell King - ARM Linux admin 2020-02-29 13:32 ` Russell King - ARM Linux admin 2020-02-29 13:32 ` Russell King - ARM Linux admin 2020-02-29 15:19 ` Theodore Y. Ts'o 2020-02-29 15:19 ` Theodore Y. Ts'o 2020-02-29 17:03 ` Russell King - ARM Linux admin 2020-02-29 17:03 ` Russell King - ARM Linux admin 2020-02-29 18:03 ` Theodore Y. Ts'o 2020-02-29 18:03 ` Theodore Y. Ts'o 2020-06-05 23:53 ` Russell King - ARM Linux admin 2020-06-05 23:53 ` Russell King - ARM Linux admin 2020-06-06 10:19 ` Russell King - ARM Linux admin 2020-06-06 10:19 ` Russell King - ARM Linux admin 2020-02-10 15:33 ` Lorenzo Pieralisi 2020-02-10 15:33 ` Lorenzo Pieralisi
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=CAOesGMhVA9NSbAi-BtcgQBBK90jeT+NcQ6j_FDgjuR7efE65Vg@mail.gmail.com \ --to=olof@lixom.net \ --cc=andrew.murray@arm.com \ --cc=arnd@arndb.de \ --cc=bhelgaas@google.com \ --cc=catalin.marinas@arm.com \ --cc=devicetree@vger.kernel.org \ --cc=l.subrahmanya@mobiveil.co.in \ --cc=laurentiu.tudor@nxp.com \ --cc=leoyang.li@nxp.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=lorenzo.pieralisi@arm.com \ --cc=m.karthikeyan@mobiveil.co.in \ --cc=mark.rutland@arm.com \ --cc=minghuan.lian@nxp.com \ --cc=mingkai.hu@nxp.com \ --cc=robh+dt@kernel.org \ --cc=robin.murphy@arm.com \ --cc=shawnguo@kernel.org \ --cc=will.deacon@arm.com \ --cc=xiaowei.bao@nxp.com \ --cc=zhiqiang.hou@nxp.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.