On Wed, Aug 09, 2017 at 04:14:43PM -0500, Jeremy Linton wrote: > Hi, > > Better late than never I guess.. > > On 08/03/2017 07:32 AM, Lorenzo Pieralisi wrote: > >This patch series is v3 of a previous posting: > > > >v2->v3: > > - Fixed DMA masks computation > > - Fixed size computation overflow in acpi_dma_get_range() > > > >v1->v2: > > - Reworked acpi_dma_get_range() flow and logs > > - Added IORT named component address limits > > - Renamed acpi_dev_get_resources() helper function > > - Rebased against v4.13-rc3 > > > >v2: http://lkml.kernel.org/r/20170731152323.32488-1-lorenzo.pieralisi@xxxxxxx > >v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieralisi@xxxxxxx > > > >-- Original cover letter -- > > > >As reported in: > > > >http://lkml.kernel.org/r/CAL85gmA_SSCwM80TKdkZqEe+S1beWzDEvdki1kpkmUTDRmSP7g@xxxxxxxxxxxxxx > > > >the bus connecting devices to an IOMMU bus can be smaller in size than > >the IOMMU input address bits which results in devices DMA HW bugs in > >particular related to IOVA allocation (ie chopping of higher address > >bits owing to system bus HW capabilities mismatch with the IOMMU). > > > >Fortunately this problem can be solved through an already present but never > >used ACPI 6.2 firmware bindings (ie _DMA object) allowing to define the DMA > >window for a specific bus in ACPI and therefore all upstream devices > >connected to it. > > > >This small patch series enables _DMA parsing in ACPI core code and > >use it in ACPI IORT code in order to detect DMA ranges for devices and > >update their data structures to make them work with their related DMA > >addressing restrictions. > > > >Cc: Will Deacon <will.deacon@xxxxxxx> > >Cc: Hanjun Guo <hanjun.guo@xxxxxxxxxx> > >Cc: Feng Kan <fkan@xxxxxxx> > >Cc: Jon Masters <jcm@xxxxxxxxxx> > >Cc: Robert Moore <robert.moore@xxxxxxxxx> > >Cc: Robin Murphy <robin.murphy@xxxxxxx> > >Cc: Zhang Rui <rui.zhang@xxxxxxxxx> > >Cc: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx> > > > >Lorenzo Pieralisi (5): > > ACPICA: resource_mgr: Allow _DMA method in walk resources > > ACPI: Make acpi_dev_get_resources() method agnostic > > ACPI: Introduce DMA ranges parsing > > ACPI: Make acpi_dma_configure() DMA regions aware > > ACPI/IORT: Add IORT named component memory address limits > > > > drivers/acpi/acpica/rsxface.c | 7 ++-- > > drivers/acpi/arm64/iort.c | 57 ++++++++++++++++++++++++++- > > drivers/acpi/resource.c | 82 +++++++++++++++++++++++++++++--------- > > drivers/acpi/scan.c | 91 +++++++++++++++++++++++++++++++++++++++---- > > include/acpi/acnames.h | 1 + > > include/acpi/acpi_bus.h | 2 + > > include/linux/acpi.h | 8 ++++ > > include/linux/acpi_iort.h | 5 ++- > > 8 files changed, 219 insertions(+), 34 deletions(-) > > Ok, despite being merged already I think its worthwhile to say that > I've been testing this with: > > Method(_DMA, 0, Serialized) > { > Return (ResourceTemplate() > { > QWORDMemory( > ResourceConsumer, I asked to update the ACPI specifications because this should be ResourceProducer, we need an errata to sort this out before it becomes a problem. > PosDecode, // _DEC > MinFixed, // _MIF > MaxFixed, // _MAF > Prefetchable, // _MEM > ReadWrite, // _RW > 0, // _GRA > 0x10000000, // _MIN > 0x1fffffff, // _MAX > 0x000000000, // _TRA > 0x10000000, // _LEN > , > , > , > ) > }) > } // Method(_DMA) > > (and a couple minor variations) > > and a fair number of debug statements sprinkled around to verify > that the IOVAs are appropriately limited. So I don't see anything > wrong with the code and it appears to work and the devices behind a > bridge limited like this continue to work as long as sane values are > placed in the min/max/len fields. > > Thanks, > > Tested-by: Jeremy Linton <jeremy.linton@xxxxxxx> Thank you very much Jeremy for testing it, appreciated please let me know if you spot anything wrong with it on the machines you are running tests on. Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
