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,
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>
--
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
