Re: [PATCHv9 00/12] PCI: Recode Mobiveil driver and add PCIe Gen4 driver for NXP Layerscape SoCs

From: Laurentiu Tudor
Date: Tue Feb 11 2020 - 07:13:24 EST




On 10.02.2020 20:41, Li Yang wrote:
On Mon, Feb 10, 2020 at 9:32 AM Olof Johansson <olof@xxxxxxxxx> wrote:

On Mon, Feb 10, 2020 at 4:23 PM Russell King - ARM Linux admin
<linux@xxxxxxxxxxxxxxx> wrote:

On Mon, Feb 10, 2020 at 04:12:30PM +0100, Olof Johansson wrote:
On Thu, Feb 6, 2020 at 11:57 AM Z.q. Hou <zhiqiang.hou@xxxxxxx> wrote:

Hi Olof,

Thanks a lot for your comments!
And sorry for my delay respond!

Actually, they apply with only minor conflicts on top of current -next.

Bjorn, any chance we can get you to pick these up pretty soon? They
enable full use of a promising ARM developer system, the SolidRun
HoneyComb, and would be quite valuable for me and others to be able to
use with mainline or -next without any additional patches applied --
which this patchset achieves.

I know there are pending revisions based on feedback. I'll leave it up
to you and others to determine if that can be done with incremental
patches on top, or if it should be fixed before the initial patchset
is applied. But all in all, it's holding up adaption by me and surely
others of a very interesting platform -- I'm looking to replace my
aging MacchiatoBin with one of these and would need PCIe/NVMe to work
before I do.

If you're going to be using NVMe, make sure you use a power-fail safe
version; I've already had one instance where ext4 failed to mount
because of a corrupted journal using an XPG SX8200 after the Honeycomb
Serror'd, and then I powered it down after a few hours before later
booting it back up.

EXT4-fs (nvme0n1p2): INFO: recovery required on readonly filesystem
EXT4-fs (nvme0n1p2): write access will be enabled during recovery
JBD2: journal transaction 80849 on nvme0n1p2-8 is corrupt.
EXT4-fs (nvme0n1p2): error loading journal

Hmm, using btrfs on mine, not sure if the exposure is similar or not.

Do you know if the SErr was due to a known issue and/or if it's
something that's fixed in production silicon?

(I still can't enable SMMU since across a warm reboot it fails
*completely*, with nothing coming up and working. NXP folks, you
listening? :)

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.
In the mean time, can you try the workaround Leo suggested?

[1] https://patchwork.kernel.org/patch/11327667/
[2] https://patchwork.kernel.org/patch/10967729/
[3] https://patchwork.kernel.org/cover/11279577/

---
Best Regards, Laurentiu