On Mon, Oct 24, 2022 at 01:44:56PM +0100, John Garry wrote: > Hi Niklas, > > > > > For the record, I tested the pm80xx driver on a HoneyComb LX2 board > > (an arm64 board using ACPI). > > > > I tried v6.1-rc1 both with and without your series in $subject. > > > > I couldn't see any issues. > > ok, thanks for the effort. > > > > > > > What I tried: > > -Running fio: > > fio --name=test --filename=/dev/sdc --ioengine=io_uring --rw=randrw --direct=1 --iodepth=32 --bs=1M > > on three different HDDs simultaneously for 15+ minutes, > > without any errors in fio or dmesg. > > > > -Creating and mounting a btrfs volume, doing a huge dd to the filesystem > > without issues. > > > > -sg_sat_read_gplog -d --log=0x10 /dev/sda > > which successfully returned the log. > > > > > > It is worth mentioning that this arm64 board has reserved memory regions, > > but does not yet have a firmware that supplies a IORT RMR (reserved memory > > regions) revision E.d node, which means that in order to get this board to > > boot successfully, we need to supply: > > "arm-smmu.disable_bypass=0 iommu.passthrough=1" > > on the kernel command line. > > hmmm... that's interesting. I can try again with the IOMMU turned off, but, > as I recall, it did not make a difference before. I think that requiring > reserved memory regions would totally bust the driver (if not present) with > IOMMU enabled. As I recall, sas 3008 card would not work without RMR for us. At least on the HoneyComb LX2, running with "arm-smmu.disable_bypass=0 iommu.passthrough=1" gives a working system (and working pm80xx). The ACPI IOMMU code that parses the ACPI IORT RMR revision E.d node was first included in kernel v6.0: https://lore.kernel.org/linux-iommu/20220615101044.1972-1-shameerali.kolothum.thodi@xxxxxxxxxx/ However, the HoneyComb edk2-platforms code has not yet been updated to add a ACPI IORT RMR revision E.d node. Considering that it works with "arm-smmu.disable_bypass=0 iommu.passthrough=1", I assume that the ACPI IORT RMR node basically just defines a number of memory regions which the IOMMU should treat as "bypass", while all other memory has to be re-mapped via the IOMMU as per usual. Kind regards, Niklas
