linux-toradex.git/drivers/acpi/arm64, branch v4.10

ACPI/IORT: Make dma masks set-up IORT specific

2016-12-06T15:57:33+00:00

The introduction of acpi_dma_configure() allows to configure DMA
and related IOMMU for any device that is DMA capable. To achieve
that goal it ensures DMA masks are set-up to sane default values
before proceeding with IOMMU and DMA ops configuration.

On x86/ia64 systems, through acpi_bind_one(), acpi_dma_configure() is
called for every device that has an ACPI companion, in that every device
is considered DMA capable on x86/ia64 systems (ie acpi_get_dma_attr() API),
which has the side effect of initializing dma masks also for
pseudo-devices (eg CPUs and memory nodes) and potentially for devices
whose dma masks were not set-up before the acpi_dma_configure() API was
introduced, which may have noxious side effects.

Therefore, in preparation for IORT firmware specific DMA masks set-up,
wrap the default DMA masks set-up in acpi_dma_configure() inside an IORT
specific wrapper that reverts to a NOP on x86/ia64 systems, restoring the
default expected behaviour on x86/ia64 systems and keeping DMA default
masks set-up on IORT based (ie ARM) arch configurations.

Signed-off-by: Lorenzo Pieralisi 
Acked-by: Will Deacon 
Acked-by: Rafael J. Wysocki 
Reviewed-by: Hanjun Guo 
Tested-by: Hanjun Guo 
Cc: Will Deacon 
Cc: Hanjun Guo 
Cc: Bjorn Helgaas 
Cc: Robin Murphy 
Cc: Tomasz Nowicki 
Cc: Joerg Roedel 
Cc: "Rafael J. Wysocki" 
Cc: Sricharan R 
Signed-off-by: Joerg Roedel

ACPI/IORT: Introduce iort_iommu_configure

2016-11-29T15:57:48+00:00

DT based systems have a generic kernel API to configure IOMMUs
for devices (ie of_iommu_configure()).

On ARM based ACPI systems, the of_iommu_configure() equivalent can
be implemented atop ACPI IORT kernel API, with the corresponding
functions to map device identifiers to IOMMUs and retrieve the
corresponding IOMMU operations necessary for DMA operations set-up.

By relying on the iommu_fwspec generic kernel infrastructure,
implement the IORT based IOMMU configuration for ARM ACPI systems
and hook it up in the ACPI kernel layer that implements DMA
configuration for a device.

Signed-off-by: Lorenzo Pieralisi 
Acked-by: Rafael J. Wysocki  [ACPI core]
Reviewed-by: Tomasz Nowicki 
Tested-by: Hanjun Guo 
Tested-by: Tomasz Nowicki 
Cc: Hanjun Guo 
Cc: Tomasz Nowicki 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Will Deacon

ACPI/IORT: Add single mapping function

2016-11-29T15:57:48+00:00

The current IORT id mapping API requires components to provide
an input requester ID (a Bus-Device-Function (BDF) identifier for
PCI devices) to translate an input identifier to an output
identifier through an IORT range mapping.

Named components do not have an identifiable source ID therefore
their respective input/output mapping can only be defined in
IORT tables through single mappings, that provide a translation
that does not require any input identifier.

Current IORT interface for requester id mappings (iort_node_map_rid())
is not suitable for components that do not provide a requester id,
so it cannot be used for IORT named components.

Add an interface to the IORT API to enable retrieval of id
by allowing an indexed walk of the single mappings array for
a given component, therefore completing the IORT mapping API.

Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Tomasz Nowicki 
Tested-by: Hanjun Guo 
Tested-by: Tomasz Nowicki 
Cc: Hanjun Guo 
Cc: Tomasz Nowicki 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Will Deacon

ACPI/IORT: Replace rid map type with type mask

2016-11-29T15:57:47+00:00

IORT tables provide data that allow the kernel to carry out
device ID mappings between endpoints and system components
(eg interrupt controllers, IOMMUs). When the mapping for a
given device ID is carried out, the translation mechanism
is done on a per-subsystem basis rather than a component
subtype (ie the IOMMU kernel layer will look for mappings
from a device to all IORT node types corresponding to IOMMU
components), therefore the corresponding mapping API should
work on a range (ie mask) of IORT node types corresponding
to a common set of components (eg IOMMUs) rather than a
specific node type.

Upgrade the IORT iort_node_map_rid() API to work with a
type mask instead of a single node type so that it can
be used for mappings that span multiple components types
(ie IOMMUs).

Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Tomasz Nowicki 
Tested-by: Hanjun Guo 
Tested-by: Tomasz Nowicki 
Acked-by: Hanjun Guo 
Cc: Hanjun Guo 
Cc: Tomasz Nowicki 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Will Deacon

iommu/arm-smmu: Add IORT configuration

2016-11-29T15:57:47+00:00

In ACPI based systems, in order to be able to create platform
devices and initialize them for ARM SMMU components, the IORT
kernel implementation requires a set of static functions to be
used by the IORT kernel layer to configure platform devices for
ARM SMMU components.

Add static configuration functions to the IORT kernel layer for
the ARM SMMU components, so that the ARM SMMU driver can
initialize its respective platform device by relying on the IORT
kernel infrastructure and by adding a corresponding ACPI device
early probe section entry.

Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Tomasz Nowicki 
Tested-by: Hanjun Guo 
Tested-by: Tomasz Nowicki 
Cc: Will Deacon 
Cc: Robin Murphy 
Cc: Joerg Roedel 
Signed-off-by: Will Deacon

iommu/arm-smmu-v3: Add IORT configuration

2016-11-29T15:57:46+00:00

In ACPI bases systems, in order to be able to create platform
devices and initialize them for ARM SMMU v3 components, the IORT
kernel implementation requires a set of static functions to be
used by the IORT kernel layer to configure platform devices for
ARM SMMU v3 components.

Add static configuration functions to the IORT kernel layer for
the ARM SMMU v3 components, so that the ARM SMMU v3 driver can
initialize its respective platform device by relying on the IORT
kernel infrastructure and by adding a corresponding ACPI device
early probe section entry.

Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Tomasz Nowicki 
Tested-by: Hanjun Guo 
Tested-by: Tomasz Nowicki 
Cc: Will Deacon 
Cc: Robin Murphy 
Cc: Joerg Roedel 
Signed-off-by: Will Deacon

ACPI/IORT: Add support for ARM SMMU platform devices creation

2016-11-29T15:57:45+00:00

In ARM ACPI systems, IOMMU components are specified through static
IORT table entries. In order to create platform devices for the
corresponding ARM SMMU components, IORT kernel code should be made
able to parse IORT table entries and create platform devices
dynamically.

This patch adds the generic IORT infrastructure required to create
platform devices for ARM SMMUs.

ARM SMMU versions have different resources requirement therefore this
patch also introduces an IORT specific structure (ie iort_iommu_config)
that contains hooks (to be defined when the corresponding ARM SMMU
driver support is added to the kernel) to be used to define the
platform devices names, init the IOMMUs, count their resources and
finally initialize them.

Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Tomasz Nowicki 
Tested-by: Hanjun Guo 
Tested-by: Tomasz Nowicki 
Acked-by: Hanjun Guo 
Cc: Hanjun Guo 
Cc: Tomasz Nowicki 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Will Deacon

ACPI/IORT: Add node match function

2016-11-29T15:57:45+00:00

Device drivers (eg ARM SMMU) need to know if a specific component
is part of the IORT table, so that kernel data structures are not
initialized at initcalls time if the respective component is not
part of the IORT table.

To this end, this patch adds a trivial function that allows detecting
if a given IORT node type is present or not in the ACPI table, providing
an ACPI IORT equivalent for of_find_matching_node().

Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Tomasz Nowicki 
Tested-by: Hanjun Guo 
Tested-by: Tomasz Nowicki 
Acked-by: Hanjun Guo 
Cc: Hanjun Guo 
Cc: Tomasz Nowicki 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Will Deacon

ACPI/IORT: Add support for IOMMU fwnode registration

2016-11-29T15:57:42+00:00

The ACPI IORT table provide entries for IOMMU (aka SMMU in ARM world)
components that allow creating the kernel data structures required to
probe and initialize the IOMMU devices.

This patch provides support in the IORT kernel code to register IOMMU
components and their respective fwnode.

Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Hanjun Guo 
Reviewed-by: Tomasz Nowicki 
Tested-by: Hanjun Guo 
Tested-by: Tomasz Nowicki 
Cc: Hanjun Guo 
Cc: Tomasz Nowicki 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Will Deacon

ACPI/IORT: Introduce linker section for IORT entries probing

2016-11-29T15:57:42+00:00

Since commit e647b532275b ("ACPI: Add early device probing
infrastructure") the kernel has gained the infrastructure that allows
adding linker script section entries to execute ACPI driver callbacks
(ie probe routines) for all subsystems that register a table entry
in the respective kernel section (eg clocksource, irqchip).

Since ARM IOMMU devices data is described through IORT tables when
booting with ACPI, the ARM IOMMU drivers must be made able to hook ACPI
callback routines that are called to probe IORT entries and initialize
the respective IOMMU devices.

To avoid adding driver specific hooks into IORT table initialization
code (breaking therefore code modularity - ie ACPI IORT code must be made
aware of ARM SMMU drivers ACPI init callbacks), this patch adds code
that allows ARM SMMU drivers to take advantage of the ACPI early probing
infrastructure, so that they can add linker script section entries
containing drivers callback to be executed on IORT tables detection.

Since IORT nodes are differentiated by a type, the callback routines
can easily parse the IORT table entries, check the IORT nodes and
carry out some actions whenever the IORT node type associated with
the driver specific callback is matched.

Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Hanjun Guo 
Reviewed-by: Tomasz Nowicki 
Tested-by: Hanjun Guo 
Tested-by: Tomasz Nowicki 
Cc: Tomasz Nowicki 
Cc: "Rafael J. Wysocki" 
Cc: Marc Zyngier 
Signed-off-by: Will Deacon