iommu_put_dma_cookie() is now called by the IOMMU framework code
before each driver's domain free callback function is invoked. Remove
iommu_put_dma_cookie() accordingly.
qcom_iommu_put_resv_regions() is now replaced by
iommu_put_resv_regions(), drop all references to our qcom_ function
versions.
Change-Id: Ib9c1c431faf4988707e449ad00c1e3fe7ee2dd47
Signed-off-by: Chris Goldsworthy <quic_cgoldswo@quicinc.com>
In the current iommu-debug fastmap test device, we map and unmap the entire
iova range from 0..4G for each of the usecases. However for the following
secure usecase:
$ cd /sys/kernel/debug/iommu-test
$ cat usecase
$ echo 4 > usecase
$ cat functional_fast_dma_api
this mapping of iova range fails with following warning after about 496640
iterations of 8K-size mapping.
batched_hyp_assign: Failed to assign memory protection, ret = -22
------------[ cut here ]------------
failed to assign memory to VMID: 10 rc:-99
WARNING: CPU: 0 PID: 240 at drivers/iommu/qcom-io-pgtable-alloc.c:39 qcom_io_pgtable_alloc_page+0x110/0x120
Once this happens the memory is no longer usable by HLOS (according to
following comments batched_hyp_assign():
344 if (ret) {
345 pr_info("%s: Failed to assign memory protection, ret= %d\n",
346 __func__, ret);
347 /*
348 * Make it clear to clients that the memory may no
349 * longer be in a usable state.
350 */
351 ret = -EADDRNOTAVAIL;
352 break;
353 }
To run any other usecase, we must first destroy the device and recreate it.
But when destroying the device, we get the following warning continuously
(presumably for the 496640 mappings that succeeded):
------------[ cut here ]------------
failed to unassign memory from VMID: 10 rc: -99
WARNING: CPU: 0 PID: 240 at drivers/iommu/qcom-io-pgtable-alloc.c:54 io_pgtable_pool_release+0x1b8/0x24c
Call trace:
io_pgtable_pool_release+0x1b8/0x24c
qcom_io_pgtable_allocator_unregister+0x5c/0xa8
arm_lpae_free_pgtable+0x30/0x4c
qcom_free_io_pgtable_ops+0x80/0xa4
arm_smmu_destroy_domain_context+0xd0/0x1ec
arm_smmu_domain_free+0x34/0x50
iommu_group_release+0x5c/0xa8
kobject_cleanup+0x78/0x1dc
kobject_cleanup+0xd8/0x1dc
kobject_put+0x68/0xa8
iommu_group_remove_device+0x114/0x184
iommu_release_device+0x48/0x8c
iommu_bus_notifier+0x4c/0xa4
blocking_notifier_call_chain+0x5c/0xa8
device_del+0x2d8/0x3d4
platform_device_unregister+0x34/0xb4
of_platform_device_destroy+0xac/0xe4
iommu_debug_switch_usecase+0x38/0x194
iommu_debug_usecase_reset+0x18/0x28
iommu_debug_functional_fast_dma_api_show+0x13e8/0x1538
IOW, the device is unusable and requires a reboot. Its not clear what the
behavior should be for a fastmap test on a non-fastmap device. For now,
detect an invalid usecase and fail cleanly.
Change-Id: I77b827825215f262e836e8902143ea297448612e
Signed-off-by: Sukadev Bhattiprolu <quic_sukadev@quicinc.com>
When __full_va_sweep(), __rand_va_sweep() and __tlb_stress_sweep(), do
their cleanup, they assume that the entire iova range 0..4G was mapped
correctly (i.e assigned iova starts at 0 and goes to 4G).
But if for some reason the iova starts at a different address (eg: with
fastmap, it could start at 0xFFFFF000), we end up with the following
warning from iommu_dma_unmap_page() because the iova 0 was never mapped.
898 phys = iommu_iova_to_phys(domain, dma_handle);
899 if (WARN_ON(!phys))
900 return;
Worse, since the cleanup tries to unmap the entire 0..4G range, this
warning is repeated a large number of times, making the device unusable.
Instead, report an error on the unexpected and unmap the incorrect dma
address immediately. And when unmapping the iova range, make sure to only
unmap regions that were correctly (when iova == dma_addr) mapped.
Change-Id: Ia0ab4fd49ba5021d4866daf69fb9a3fa7e61928d
Signed-off-by: Sukadev Bhattiprolu <quic_sukadev@quicinc.com>
Current codes may don't consider the 32-bit possibility, some
compilation errors happen when try to enable smmu on sdxbaagha:
1. arm-smmu-qcom.c:
"error: shift count is negative" reports at
"FIELD_GET(QTB_OVR_ECATS_OUTFLD0_PA, val)".
2. qcom-iommu-debug-user.c:
"error: incompatible pointer types passing" reports at
"if (kstrtox_from_user(ubuf, count, 0, &iova))".
3. qcom-io-pgtable-arm.c:
"error: implicit declaration of function 'FIELD_GET'"
reports at "FIELD_GET(TOP_IGNORED_MASK, table_pte)".
4. qcom-iommu-debug-user.c:
"error: implicit declaration of function 'FIELD_GET'"
reports at "FIELD_GET(ARM_SMMU_SMR_ID, fwspec->ids[0])".
5. qcom-iommu-debug.c:
"error: implicit declaration of function 'FIELD_GET'"
reports at "FIELD_GET(ARM_SMMU_SMR_ID, (fwspec->ids[0]))".
Change-Id: I38b96e411eaf37d87e48b4c9fe860a94643bc5b7
Signed-off-by: Qingqing Zhou <quic_qqzhou@quicinc.com>
Add drop data size count and data overwritten tag for the drop
data case.
Change-Id: Ib066215ecf8c9ef2a1920d75afafb45b4a6382e7
Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com>
Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
This bit is set by hw-fence driver when it sees that the hw-fence
is already signaled at the time when a client wants to add itself
as a waiter for this hw-fence. This helps the client to avoid adding
itself as a waiter for an already signaled hw-fence.
Change-Id: I767745923066ee66c4bd8cd756ff05cd8cdbc833
Signed-off-by: Harshdeep Dhatt <quic_hdhatt@quicinc.com>
Enable CONFIG_REGMAP_QTI_DEBUGFS in pineapple GKI config so that
the regmap interfaces which uses regmap_qti_debugfs APIs can be
read using debugfs.
Enable CONFIG_REGMAP_QTI_DEBUGFS_ALLOW_WRITE in pineapple consolidate
config so that the regmap interfaces which uses regmap_qti_debugfs
APIs can be written via debugfs.
Change-Id: Ibd6f57312851c5482d2ca964cabfca76f8192ac1
Signed-off-by: Subbaraman Narayanamurthy <quic_subbaram@quicinc.com>
Updating module output lists for kalama and pineapple.
Change-Id: I0fd6cb8b586b1dab62293483f768041f12e897b8
Signed-off-by: John Moon <quic_johmoo@quicinc.com>
When disabling USB SW path ensure all calls to usb_qdss_write()
are completed before calling usb_qdss_close(), otherwise the
two APIs may race and result in out-of-order sequencing between
the underlying usb_ep_queue() and usb_ep_dequeue() calls. This
may result in usb_qdss_close() getting stuck since it is waiting
on an unqueued request to complete.
Change-Id: Ibdccf082a6273f8d3a78e664b58bd0a5b9ce8f69
Signed-off-by: Jack Pham <quic_jackp@quicinc.com>
Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com>
In order to ensure video power collapse can work fine,
the CLK_ARES is added for VIDEO_CC_XO_CLK so that
asserting/de-asserting the reset can automatically
disable/enable the clock.
Change-Id: Ibf20a768d95aa0394ebec1c8be163a0fa4d85754
Signed-off-by: Xubin Bai <quic_xubibai@quicinc.com>
Add CLK_ARES for VIDEO_CC_XO_CLK to ensure video power
collapse can work fine in Pineapple.
Change-Id: Id76e3ef29f59f5745469cd43800cefc0d82f8499
Signed-off-by: Xubin Bai <quic_xubibai@quicinc.com>
Modify msm_hw_fence_wait_update_v2 api to include the optional
parameter client_data_list, a list of values that are returned
to the client upon signaling of the corresponding fence through
the RxQ.
Change-Id: I1daeadc7812cf475fba635be2fc446157da9d73b
Signed-off-by: Grace An <quic_gracan@quicinc.com>
Work-around for hangs during bootup.
No ramdumps/tools available to debug during BU.
So, disable hibern8 during clock gating.
This would let the clocks to be off thus allowing CxPC.
Clock scaling needs SYS1CLK_1US_REG and
DME_VS_CORE_CLK_CTRL.MAX_CORE_CLK_1US_CYCLES and
PA_VS_CORE_CLK_40NS_CYCLES to be defined for 403Mhz.
Disable clock scaling until values are determined.
Change-Id: I702a561ecce627a8b00a676fc2e6118ce1ebc4a0
Signed-off-by: Asutosh Das <quic_asutoshd@quicinc.com>
