05 Jun, 2019
1 commit
-
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms and conditions of the gnu general public license
version 2 as published by the free software foundation this program
is distributed in the hope it will be useful but without any
warranty without even the implied warranty of merchantability or
fitness for a particular purpose see the gnu general public license
for more details you should have received a copy of the gnu general
public license along with this program if not write to the free
software foundation inc 59 temple place suite 330 boston ma 02111
1307 usaextracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 33 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Allison Randal
Reviewed-by: Kate Stewart
Reviewed-by: Alexios Zavras
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190530000435.254582722@linutronix.de
Signed-off-by: Greg Kroah-Hartman
04 Apr, 2019
2 commits
-
HiSilicon erratum 162001800 describes the limitation of
SMMUv3 PMCG implementation on HiSilicon Hip08 platforms.On these platforms, the PMCG event counter registers
(SMMU_PMCG_EVCNTRn) are read only and as a result it
is not possible to set the initial counter period value
on event monitor start.To work around this, the current value of the counter
is read and used for delta calculations. OEM information
from ACPI header is used to identify the affected hardware
platforms.Signed-off-by: Shameer Kolothum
Reviewed-by: Hanjun Guo
Reviewed-by: Robin Murphy
Acked-by: Lorenzo Pieralisi
[will: update silicon-errata.txt and add reason string to acpi match]
Signed-off-by: Will Deacon -
Add support for the SMMU Performance Monitor Counter Group
information from ACPI. This is in preparation for its use
in the SMMUv3 PMU driver.Signed-off-by: Neil Leeder
Signed-off-by: Hanjun Guo
Signed-off-by: Shameer Kolothum
Reviewed-by: Robin Murphy
Acked-by: Lorenzo Pieralisi
Signed-off-by: Will Deacon
14 Feb, 2018
1 commit
-
On some platforms msi parent address regions have to be excluded from
normal IOVA allocation in that they are detected and decoded in a HW
specific way by system components and so they cannot be considered normal
IOVA address space.Add a helper function that retrieves ITS address regions - the msi
parent - through IORT device ITS mappings and reserves it so that
these regions will not be translated by IOMMU and will be excluded from
IOVA allocations. The function checks for the smmu model number and
only applies the msi reservation if the platform requires it.Signed-off-by: Shameer Kolothum
Reviewed-by: Lorenzo Pieralisi
[For the ITS part]
Reviewed-by: Marc Zyngier
Signed-off-by: Joerg Roedel
16 Oct, 2017
1 commit
-
Some functions definition indentations are using a style that is frowned
upon with return value type/storage class specifier in a separate line.Reindent the function definitions to fix them.
Signed-off-by: Lorenzo Pieralisi
Acked-by: Hanjun Guo
Cc: Hanjun Guo
Cc: Sudeep Holla
07 Aug, 2017
1 commit
-
Current ACPI DMA configuration set-up device DMA capabilities through
kernel defaults that do not take into account platform specific DMA
configurations reported by firmware.By leveraging the ACPI acpi_dev_get_dma_resources() API, add code
in acpi_dma_configure() to retrieve the DMA regions to correctly
set-up PCI devices DMA parameters.Rework the ACPI IORT kernel API to make sure they can accommodate
the DMA set-up required by firmware. By making PCI devices DMA set-up
ACPI IORT specific, the kernel is shielded from unwanted regressions
that could be triggered by parsing DMA resources on arches that were
previously ignoring them (ie x86/ia64), leaving kernel behaviour
unchanged on those arches.Signed-off-by: Lorenzo Pieralisi
Acked-by: Will Deacon
Tested-by: Nate Watterson
Signed-off-by: Rafael J. Wysocki
15 Jun, 2017
1 commit
-
Commit 316ca8804ea8 ("ACPI/IORT: Remove linker section for IORT entries
probing") removed the linker section for IORT entries probing.Since those IORT entries were the only iort_node_match() interface
users, the iort_node_match() became obsolete and can then be removed.Remove the ACPI IORT iort_node_match() interface from the kernel.
Acked-by: Marc Zyngier
Acked-by: Hanjun Guo
Signed-off-by: Lorenzo Pieralisi
Cc: Hanjun Guo
Signed-off-by: Will Deacon
10 May, 2017
1 commit
-
Pull IOMMU updates from Joerg Roedel:
- code optimizations for the Intel VT-d driver
- ability to switch off a previously enabled Intel IOMMU
- support for 'struct iommu_device' for OMAP, Rockchip and Mediatek
IOMMUs- header optimizations for IOMMU core code headers and a few fixes that
became necessary in other parts of the kernel because of that- ACPI/IORT updates and fixes
- Exynos IOMMU optimizations
- updates for the IOMMU dma-api code to bring it closer to use per-cpu
iova caches- new command-line option to set default domain type allocated by the
iommu core code- another command line option to allow the Intel IOMMU switched off in
a tboot environment- ARM/SMMU: TLB sync optimisations for SMMUv2, Support for using an
IDENTITY domain in conjunction with DMA ops, Support for SMR masking,
Support for 16-bit ASIDs (was previously broken)- various other small fixes and improvements
* tag 'iommu-updates-v4.12' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: (63 commits)
soc/qbman: Move dma-mapping.h include to qman_priv.h
soc/qbman: Fix implicit header dependency now causing build fails
iommu: Remove trace-events include from iommu.h
iommu: Remove pci.h include from trace/events/iommu.h
arm: dma-mapping: Don't override dma_ops in arch_setup_dma_ops()
ACPI/IORT: Fix CONFIG_IOMMU_API dependency
iommu/vt-d: Don't print the failure message when booting non-kdump kernel
iommu: Move report_iommu_fault() to iommu.c
iommu: Include device.h in iommu.h
x86, iommu/vt-d: Add an option to disable Intel IOMMU force on
iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed
iommu/arm-smmu: Correct sid to mask
iommu/amd: Fix incorrect error handling in amd_iommu_bind_pasid()
iommu: Make iommu_bus_notifier return NOTIFY_DONE rather than error code
omap3isp: Remove iommu_group related code
iommu/omap: Add iommu-group support
iommu/omap: Make use of 'struct iommu_device'
iommu/omap: Store iommu_dev pointer in arch_data
iommu/omap: Move data structures to omap-iommu.h
iommu/omap: Drop legacy-style device support
...
20 Apr, 2017
1 commit
-
The IORT linker section introduced by commit 34ceea275f62
("ACPI/IORT: Introduce linker section for IORT entries probing")
was needed to make sure SMMU drivers are registered (and therefore
probed) in the kernel before devices using the SMMU have a chance
to probe in turn.Through the introduction of deferred IOMMU configuration the linker
section based IORT probing infrastructure is not needed any longer, in
that device/SMMU probe dependencies are managed through the probe
deferral mechanism, making the IORT linker section infrastructure
unused, so that it can be removed.Remove the unused IORT linker section probing infrastructure
from the kernel to complete the ACPI IORT IOMMU configure probe
deferral mechanism implementation.Tested-by: Hanjun Guo
Reviewed-by: Robin Murphy
Signed-off-by: Lorenzo Pieralisi
Cc: Sricharan R
Signed-off-by: Joerg Roedel
30 Mar, 2017
2 commits
-
By allowing platform MSI domain to be created on ACPI platforms,
a platform device MSI domain can be set-up when it is probed.In order to do that, the MSI domain the platform device connects
to should be retrieved, so the iort_get_platform_device_domain() is
introduced to retrieve the domain from the IORT kernel layer.With the domain retrieved, we need a proper way to set the
domain to platform device.Given that some platform devices (irqchips) require the MSI irqdomain
to be their interrupt parent domain, the MSI irqdomain should be
determined before platform device is probed but after the platform
device is allocated which means that the code setting up the MSI
irqdomain, ie acpi_configure_pmsi_domain() should be called in
acpi_platform_notify() (that is triggered after adding a device but
before the respective driver is probed) for the platform MSI domain
code set-up path to work properly.Acked-by: Rafael J. Wysocki [for glue.c]
Signed-off-by: Hanjun Guo
[lorenzo.pieralisi@arm.com: rewrote commit log]
Signed-off-by: Lorenzo Pieralisi
Tested-by: Ming Lei
Tested-by: Wei Xu
Tested-by: Sinan Kaya
Cc: Marc Zyngier
Cc: Lorenzo Pieralisi
Cc: Tomasz Nowicki -
For devices connecting to an ITS, the devices need to identify themself
through a devid; this devid is represented in the IORT table in named
component node [1] for platform devices, so this patch adds code that
scans the IORT table to retrieve the devices devid.Add an IORT interface to collect ITS devices devid to carry out platform
devices MSI mappings with IORT tables.[1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
Signed-off-by: Hanjun Guo
[lorenzo.pieralisi@arm.com: rewrote commit log/dropped ITS changes]
Signed-off-by: Lorenzo Pieralisi
Tested-by: Ming Lei
Tested-by: Wei Xu
Tested-by: Sinan Kaya
Cc: Marc Zyngier
Cc: Lorenzo Pieralisi
Cc: Tomasz Nowicki
Cc: Thomas Gleixner
06 Dec, 2016
1 commit
-
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
29 Nov, 2016
4 commits
-
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 -
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 -
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 -
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
13 Sep, 2016
2 commits
-
For ITS, MSI functionality consists on building domain stack and
during that process we need to reference to domain stack components
e.g. before we create new DOMAIN_BUS_PCI_MSI domain we need to specify
its DOMAIN_BUS_NEXUS parent domain. In order to manage that process
properly, maintain list which elements contain domain token
(unique for MSI domain stack) and ITS ID: iort_register_domain_token()
and iort_deregister_domain_token(). Then retrieve domain token
any time later with ITS ID being key off: iort_find_domain_token().
With domain token and domain type we are able to find corresponding
IRQ domain.Since IORT is prepared to describe MSI domain on a per-device basis,
use existing IORT helpers and implement two calls:
1. iort_msi_map_rid() to map MSI RID for a device
2. iort_get_device_domain() to find domain token for a deviceSigned-off-by: Tomasz Nowicki
Acked-by: Rafael J. Wysocki
Reviewed-by: Hanjun Guo
Signed-off-by: Marc Zyngier -
IORT shows representation of IO topology for ARM based systems.
It describes how various components are connected together on
parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec.
http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdfInitial support allows to detect IORT table presence and save its
root pointer obtained through acpi_get_table(). The pointer validity
depends on acpi_gbl_permanent_mmap because if acpi_gbl_permanent_mmap
is not set while using IORT nodes we would dereference unmapped pointers.For the aforementioned reason call acpi_iort_init() from acpi_init()
which guarantees acpi_gbl_permanent_mmap to be set at that point.Add generic helpers which are helpful for scanning and retrieving
information from IORT table content. List of the most important helpers:
- iort_find_dev_node() finds IORT node for a given device
- iort_node_map_rid() maps device RID and returns IORT node which provides
final translationIORT support is placed under drivers/acpi/arm64/ new directory due to its
ARM64 specific nature. The code there is considered only for ARM64.
The long term plan is to keep all ARM64 specific tables support
in this place e.g. GTDT table.Signed-off-by: Tomasz Nowicki
Acked-by: Rafael J. Wysocki
Reviewed-by: Hanjun Guo
Reviewed-by: Lorenzo Pieralisi
Signed-off-by: Marc Zyngier
