Some hardware is capable of retaining register values during power
collapse. Add an option (configurable via DT) to enable this feature.
This is implemented by always enabling/disabling regulators every time
clocks are enabled/disabled.
Change-Id: I89d9a4f4a2eb29f0868b309d55a77cc4ed50e22e
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Hardware requires that the ATOS command be issued with a single 64-bit
write instead of two 32-bit writes as we're currently doing. Fix this.
Change-Id: I43104c89c2f27b75d1176c8cbcd214666321244f
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Thulium has a hardware errata that requires that the SMMU be halted and
that a TLBIALL be issued before the ATOS command. Add a DT option that
implements this workaround.
Change-Id: Ic40c7b93d64eebb97fe77082d8335debab624af1
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Some hardware prohibits multiple ATOS commands from being issued
concurrently. Add a lock to avoid concurrent ATOS commands from being
issued.
Change-Id: Ie728464f8f03b3d60807a75b9e7c2b50ab62fa43
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
The meaning of the arguments to readl_poll_timeout_atomic have changed
since the arm-smmu code was written that uses it. Sync up to the new
API semantics.
Change-Id: Ibdcd53fb61303e1261f7f6378b3395700ce38b6e
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently we do a STLBIALL when we initialize the SMMU. However, in
some configurations that register is not supposed to be touched and is
marked as "Secure only" in the spec. Rip it out.
Change-Id: I3a6e3f171f8f9fd82257270e3a7202ecbc8bd6ad
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
When running under a hypervisor, the number of context banks visible to
Linux could be different from what we see when running standalone. This
is problematic since the context bank interrupts are hard-coded into the
DT configuration, and we'd like to share that configuration whether
we're running under a hypervisor or not. Remove a warning when a
mismatch in the number of CBs and CB interrupts is detected and don't
return failure while probing.
Change-Id: I9271e4e04ecafe61f4bb12d1e1148cb2bcec2439
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Some clients need to get the base address of the page table for a given
IOMMU domain. This functionality is provided by the
DOMAIN_ATTR_PT_BASE_ADDR domain attribute. Implement it in the ARM SMMU
driver.
Change-Id: Ibe4b11a6eaf2ca42aec326c764777373cff769cc
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently we're repurposing the definitions used for the TTBCR2.PASize
field for TTBCR2.SEP since they conveniently have the same values.
However, this might look like a bug at first glance to the casual
passer-by, appearing that we're using the wrong bit definitions for the
field. For example, we're using TTBCR2_ADDR_32 to indicate that the
Sign Extension Bit should live at 31 (not 32 as the name of the macro
might imply). Reduce cumulative human cognitive load by adding some
definitions specifically for the SEP field.
Change-Id: Ia406951499453e2badca42a1cc4cdbc566af4dab
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently there's no way to clear DOMAIN_ATTR_COHERENT_HTW_DISABLE=0 if
you've ever set it. Fix this.
Change-Id: I10d3bb2f72a94b2b91d4a0500e0e2d9462efcf36
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
According to the IOMMU API, a domain doesn't necessarily need to be
attached to an IOMMU device before setting up mappings on that domain.
However, in the ARM SMMU driver we currently make the assumption that
the domain has already been attached to an SMMU. We use this assumption
for the following information:
(1) To know whether this is a stage1 or stage2 mapping
(2) To know whether we need to do an invalidate
(ARM_SMMU_OPT_INVALIDATE_ON_MAP)
(3) Address sanity checks based on the stage-1 and stage-2
sizes (which are determined by the SMMU configuration)
(4) To call the correct cache maintenance routines based on the SMMU
device pointer
Handle (1) by assuming that the mapping is stage1 by default. If
there's an SMMU attached we can check if this is a stage1 or stage2
mapping. This works for us at the moment because no one is setting up
stage2 mappings in the kernel.
Handle (2) by not invalidating on map if the domain isn't attached to an
SMMU since we shouldn't have anything to invalidate in that case
anyways.
Handle (3) by skipping the sanity checks for unattached domains.
Handle (4) by using the low-level caching APIs.
Currently we don't even free up the context bank when the device is
detached, presumably so that we don't have to set it up again on
re-attach. This limits the number of domains that can be attached to an
SMMU, even if they detach from it before the next one attaches. Remove
this 1-to-1 domain-to-SMMU assumption by freeing up the "domain
context" (context bank allocation, etc) on detach.
CRs-Fixed: 752812
Change-Id: I990a11ed52381ce4ecea0f82b4c6e2d54e08f2d6
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently we expose a domain attribute to disable/enable coherent
hardware table walks. However, while we're building page tables, we
flush the cache based on the SMMU's capability to perform coherent
hardware table walks, rather than flushing based on whether coherent
hardware table walks are actually enabled for the domain. We also allow
domains that have asked to enable coherent hardware table walks to be
attached to SMMU devices that don't support it.
Fix these issues by doing validation of the domain attributes against
the SMMU device to which the domain is attached. We need to do this at
domain attribute set time and at attach time since domain attributes can
be set before and after they are attached to a device.
This also allows us to drop the check for whether the SMMU supports
coherent table walks in the page table flushing code. We can simply
check the domain attributes instead of checking both the domain
attributes and the SMMU features.
CRs-Fixed: 752812
Change-Id: Ibee9316a340f481664f5fb7757a24f136e0ed74c
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
We're currently taking the upper 52 bits from the CB_PAR register and
using them for the output physical address. That doesn't make sense for
a few reasons, not the least of which is the fact that physical
addresses are only 48 bits on ARM64 and even less on ARM32. Also, when
using V7L and V8 descriptor formats the top byte of the CB_PAR register
contains the memory attributes for the translation. Fix this by masking
out everything above the valid physical address bits with PHYS_MASK.
Change-Id: I96096a6515dc42025d3134933a90b072e5153968
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
We recently increased the maximum number of stream IDs from 8 to 16 in
[85fac623740fc: "iommu/arm-smmu: increase maximum stream ids"].
However, we can actually have many more than 16. Go ahead and increase
this limit to accomodate the maximum number of stream IDs as outlined in
the SMMUv2 spec.
Change-Id: I23cee7ad78f0d388e339a4c8a1058f0674f3edc3
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
We support way more than 8 SIDs but currently error out if we get more
than that. Fix this.
Change-Id: I50e70b07ffbee783d3e6582fa7d9a175a1b26fe5
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
We currently don't check whether register_smmu_master while parsing the
device tree and adding device masters. Add error checking to facilitate
debugging and avoid probing of bogus devices.
Change-Id: I79c70d193c4705c21ea6a2e03ee048e7a4813b71
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently we only program the VMID (in the CBAR register) for stage-2
context banks. The VMID is valid and often used in stage-1 context banks
as well. Program it in both cases.
Change-Id: Id4381e67f1c4c318c3137a5d56256af711491f08
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
dev_err already prints the device name. Remove the `dev_name(dev)' from
the print statement in arm_smmu_iova_to_phys_hard.
Change-Id: I5f5bcaf57349aba157789070e2f1441184ee62a6
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently there could be races between different domains performing an
ATOS operation. Fix this by taking the domain lock around the ATOS.
Change-Id: I32e6e0a0c67ce82aff5abfc892098c684d399b2d
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently, we return garbage when iova_to_phys fails when we're using
hardware translation features (ATOS). iova_to_phys should return 0 when
it fails. Fix this.
Change-Id: I3bfefce7315e43a684c7c29c4fa7ef5960182ea8
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
ARM SMMUs support memory access control via some bits in the translation
table descriptor memory attributes. Currently we assume all translations
are "unprivileged". Add support for privileged mappings, controlled by
the IOMMU_PRIV prot flag.
Also sneak in a whitespace change for consistency with nearby code.
Change-Id: I9d922c19d7dc8e64e07b216fc1bab373aa2e733d
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Some platforms require certain implementation-defined registers to be
programmed when first attaching to the SMMU. Add support for this via
specifying register offset, value pairs in the device tree.
Change-Id: Iac2fe42684c3849a24d0d1251a206954262257c5
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Work around a hardware bug where some SMMUs cache invalid PTEs and mess
up the transaction logic. PTEs must be zero'd out completely rather than
just setting the last two bits to zero to work around this bug.
Change-Id: I98ac18142eda6f7817c78ab27a4850cdecf24913
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
We should avoid setting the ARM SMMU driver up as the IOMMU for the PCI
bus if there aren't any IOMMUs on the bus. Provide a Kconfig knob to
control this.
Change-Id: I748f689cd5f512aa7e45e146c6d7ddccadc47e44
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
[pdaly@codeaurora.org Resolve minor conflicts]
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
The ACTLR must be programmed according to the hardware design in order
for the coherent table walk feature to work on certain Qualcomm
hardware. Provide a new compatible string ("qcom,smmu-v2") to indicate
the relevant hardware and do the programming as needed.
Change-Id: I7e807384c821fc3d07274f35726abb28d0d75ee0
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Under certain conditions coherent hardware translation table walks can
result in degraded performance. Add a new domain attribute to
disable/enable this feature in generic code along with the domain
attribute setter and getter to handle it in the ARM SMMU driver.
Change-Id: Ic9812d5047af19093ec2db8246a7f0f9ccb626ab
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Add a workaround for some buggy hardware that requires a TLB invalidate
operation to occur at map time. Activate the feature with the
qcom,smmu-invalidate-on-map boolean DT property.
Change-Id: I081a279fead983ae3d736b44cda371078e55a750
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Generic IOMMU device tree bindings were recently added in [bb1e25b9ed:
"devicetree: Add generic IOMMU device tree bindings"]. Implement the
bindings in the ARM SMMU driver.
See Documentation/devicetree/bindings/iommu/iommu.txt for the bindings
themselves.
Change-Id: I318b4cc347caccf3e142ce021057599eaea07814
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently, we provide the iommu_ops.iova_to_phys service by doing a
table walk in software to translate IO virtual addresses to physical
addresses. On SMMUs that support it, it can be useful to ask the SMMU
itself to do the translation. This can be used to warm the TLBs for an
SMMU. It can also be useful for testing and hardware validation.
Since the address translation registers are optional on SMMUv2, only
enable hardware translations when using SMMUv1 or when SMMU_IDR0.S1TS=1
and SMMU_IDR0.ATOSNS=0, as described in the ARM SMMU v1-v2 spec.
Change-Id: I07157ced4b2d8a5974b69f84f0ba47ca1b99481b
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
On some power-constrained platforms it's useful to disable power when a
device is not in use. Add support for specifying regulators for SMMUs
and only leave power on as long as the SMMU is in use (attached).
Change-Id: I87191d325423f160ddd4b71f5bf3a92f4942b821
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
On some platforms with tight power constraints it is polite to only
leave your clocks on for as long as you absolutely need them. Currently
we assume that all clocks necessary for SMMU register access are always
on.
Add some optional device tree properties to specify any clocks that are
necessary for SMMU register access and turn them on and off as needed.
If no clocks are specified in the device tree things continue to work
the way they always have: we assume all necessary clocks are always
turned on.
Change-Id: Ie42647e117b51a45c939aa479487fa4b5f101c68
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
In preparation for the forthcoming flurry of cherry-picks, match things
up with the 3.14 fork point by making the arm_smmu_ops variable
non-const. With this in place we should be able to cleanly cherry-pick
everything from the 3.14 fork point to the end of the msm-3.14 branch.
Change-Id: Ifa9d786e27be6d182edfecc1c05e033bc931cbd0
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
The memory to be mapped by the smmu needs to be uncached
since the bus is non-coherent. Pass coherent flag as false
to make sure that the memory is marked as uncached.
CRs-Fixed: 786121
Change-Id: Ie2849b1e1ec901e60e89706519cbd89d278e0b3e
Signed-off-by: Neeti Desai <neetid@codeaurora.org>
IOMMU virtual addresses use the dma_addr_t type since they can be up to
64-bits. We're currently using an `unsigned int' to store our IOVA in
arm_iommu_map_sg, which could result in truncation. Use the correct
type for an I/O virtual address: dma_addr_t.
Change-Id: Ie63bf17268ca70d102ab9d472ed9bcc6f4a793d7
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
In arm_iommu_map_sg, currently we map each individual link in the given
scatterlist into the SMMU individually such that they may or may not be
virtually contiguous. However, in most (all?) of our use cases we
actually want the entire sg list mapped into the SMMU as a single
contiguous range. Use iommu_map_range to accomplish this.
Change-Id: Icf72ece50c3120a0091dbfab1523ff11da20f807
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
dma_ops should be const since they shouldn't be changing after being
defined (there's even a checkpatch warning for this). Convert existing
dma_ops to const.
Change-Id: Ic27ba9a0832b12cae43cd45c72f053335845fd8f
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Conflicts:
arch/arm64/include/asm/dma-mapping.h
arch/arm64/mm/dma-mapping.c
When CONFIG_ARM64_DMA_USE_IOMMU is not selected, drivers that make use
of the ARM DMA IOMMU mapping APIs currently don't link. First instinct
might be to add a dependency on CONFIG_ARM64_DMA_USE_IOMMU to those
drivers, but they might not actually want to do that because they might
have other ways of getting DMA-able memory.
Allow compilation when CONFIG_ARM64_DMA_USE_IOMMU is not selected by
providing necessary stub functions.
Change-Id: I172e00a0748c70676b8ff7555e217a1e6122e3e6
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
On systems with IOMMUs, it's useful to handle IOMMU mappings in the
dma-mapping layer. This is currently supported on arm but not arm64. Add
support in arm64 by gratuitously lifting most of the IOMMU-related stuff
from dma-mapping.c in arm.
The original arm work was done by Marek Szyprowski in [4ce63fcd91:
"ARM: dma-mapping: add support for IOMMU mapper"].
Change-Id: I1c3c8fe15049fe456751074398fd179ebd2ec64e
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
[pdaly@codeaurora.org Disable upstream implementation]
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
It's incredibly useful to be able to see where reserved regions
were placed. Make those prints pr_info instead of just pr_debug.
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Currently, the decision on which page protection to use
is limited to writecombine and coherent. Expand to include
strongly ordered memory and non consistent memory.
Change-Id: I7585fe3ce804cf321a5585c3d93deb7a7c95045c
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Reset the following files:
arm-smmu.c
iommu.c
include/linux/iommu.h
include/trace/events/iommu.h
to the git merge base between 3.18 and 4.4:
b2776bf714
Change-Id: I9aa58e08125e3a72d1e9742e26d4a6fab34b0ed5
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
Move qpnp-power-on driver as input driver, also update
regulator related api in order to accomodate regualtor
framework
Signed-off-by: Jigarkumar Kishorkumar Zala <j_zala@codeaurora.org>
Dummy release event is sent when system resumes. This behavior
makes long press detection failed for some keys like POWER key
and HEADSET key. Add INPUT_PROP_NO_DUMMY_RELEASE to make it is
possible for some input to avoid this behavior.
Need add set_bit(INPUT_PROP_NO_DUMMY_RELEASE,inputdevice->propbit)
in specific drivers that don't want the DUMMY release event.
Change-Id: I30ba5045273aca9a4613b7f6dcdcf7a7173b5c27
Signed-off-by: Kun Liang <kunliang@codeaurora.org>
[joshc: Renumbered flag due to conflict, adapted to upstream
input_reset_device() changes upstream.]
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
[abhimany: Renumbered flag due to conflict]
Signed-off-by: Abhimanyu Kapur <abhimany@codeaurora.org>
The status of the CoreSight fuses can be derived from the AUTHSTATUS
register. This patch add support to read AUTHSTATUS, which could be used
by Coresight device drivers to determine if that component is functional
in hardware.
Change-Id: I6b7ac2a3558c238ac5fca452ddfb6c88eef14b8b
Signed-off-by: Shashank Mittal <mittals@codeaurora.org>
PMIC VADC_TM driver provides clients to set
threholds on supported VADC channels such as
vph_pwr and thermistors and receive notification
on threshold crossing.
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
QPNP PMIC VADC driver provides clients ability
to read voltage channels supported by the PMIC such
as vph_pwr and board thermistors.
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
This snapshot is taken as of msm-3.18 commit dbdb6776f
(Merge "msm: camera: Add dummy sub module in sensor pipeline")
Fixup compilation to support int type for temperature
value as part of thermal ops API upgrade.
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
SCM (Secure Channel Manager) driver is used to communicate
with the secure world entities like trustzone and hypervisor.
As a part of the communication we expect to give certain
input, output operands and the caller of the scm_callX
API would expect that output values or return values
of the scm_callX should not get corrupted (if they depend on it).
Due to Kasan instrumentation of the SCM driver following
code is getting instrumented with Kasan __asan_store8_noabort
APIs which would internally check if the memory access is allowed
and it is the functionality of the Kasan to check/instrument
the load and stores.
if (ret1)
*ret1 = r1;
if (ret2)
*ret2 = r2;
if (ret3)
*ret3 = r2;
All will be fine for the first *ret1 = r1; execution since
GCC has generated the code which saves the x1 value (r1)
into the another register but the execution of the
__asan_store8_noabort API after the saving of the register
corrupts the x2 and x3 when it returns. GCC has no knowledge
at this point to save the x2 and x3.
Due to this x2 and x3 is loaded with the Kasan shadow
offset value and Kasan shifted (>> 3) address.
Since x2 and x3 (r2 and r3 in the code above) would be used
as the ret2 and ret3 for the caller of the scm_callX API
the caller would get the wrong return values (if it needs them).
QSEECOM is one such driver which uses these ret2 and ret3 values
and due to this corruption QSEECOM driver was treating it as
SCM call failure, though the bug described above due to Kasan
instrumentation would be applicable to any caller needing
the right values of the ret2 and ret3.
SCM driver is very small and simple and we would not expect
the Out of bound or use-after-free errors for it, so it would
be fine to skip it from the Kasan instrumentation.
Change-Id: I8b2a17759295375c21abc520110f855f349faf4b
Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
[satyap: trivial merge conflict resolution]
Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
Allow enabling KASAN on a per-directory or per-file basis rather than
for the entire kernel.
Change-Id: I9a491d3ab0df4c42302a258b9edb3b78cf4e1db0
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
[satyap: trivial merge conflict resolution]
Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
