This error path is supposed to return -EINVAL. It used to return
directly but we added some clean up and accidentally removed the
error code. Also I fixed a typo in the error message.
Fixes: c0b57581b7 ("iommu/mediatek: Add power-domain operation")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
Link: https://lore.kernel.org/r/YB0+GU5akSdu29Vu@mwanda
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit a92a90ac62)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: I65e9f85408625df6c827ef835089d847a8ab7257
After extending v7s, our pagetable already support iova reach
16GB(34bit). the master got the iova via dma_alloc_attrs may reach
34bits, but its HW register still is 32bit. then how to set the
bit32/bit33 iova? this depend on a SMI larb setting(bank_sel).
we separate whole 16GB iova to four banks:
bank: 0: 0~4G; 1: 4~8G; 2: 8-12G; 3: 12-16G;
The bank number is (iova >> 32).
We will preassign which bank the larbs belong to. currently we don't
have a interface for master to adjust its bank number.
Each a bank is a iova_region which is a independent iommu-domain.
the iova range for each iommu-domain can't cross 4G.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org> #for memory part
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-31-yong.wu@mediatek.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 8d2c749e52)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: I0d397b100026b04747c753233f0dea0a1d5cf2ee
Some HW IP(ex: CCU) require the special iova range. That means the iova
got from dma_alloc_attrs for that devices must locate in his special range.
In this patch, we prepare a iommu group(domain) for each a iova range
requirement.
Meanwhile we still use one pagetable which support 16GB iova.
After this patch, If the iova range of a master is over 4G, the master
should:
a) Declare its special dma-ranges in its dtsi node. For example, If we
preassign the iova 4G-8G for vcodec, then the vcodec dtsi node should
add this:
/*
* iova start at 0x1_0000_0000, pa still start at 0x4000_0000
* size is 0x1_0000_0000.
*/
dma-ranges = <0x1 0x0 0x0 0x40000000 0x1 0x0>; /* 4G ~ 8G */
Note: we don't have a actual bus concept here. the master doesn't have its
special parent node, thus this dma-ranges can only be put in the master's
node.
b) Update the dma_mask:
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(33));
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-29-yong.wu@mediatek.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit c3045f3924)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: Id104c9ffa0ffae47b13be5f9d71029bead0cd926
Add a new interface _get_domain_id from dev->dma_range_map,
The iommu consumer device will use dma-ranges in dtsi node to indicate
its dma address region requirement. In this iommu driver, we will get
the requirement and decide which iova domain it should locate.
In the lastest SoC, there will be several iova-regions(domains), we will
compare and calculate which domain is right. If the start/end of device
requirement equal some region. it is best fit of course. If it is inside
some region, it is also ok. the iova requirement of a device should not
be inside two or more regions.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-28-yong.wu@mediatek.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 803cf9e5a6)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: Ic41106a406bcbb375aa8f507232ab847a2d9c4e0
Currently domain_alloc only has a parameter(type), We have no chance to
input some special data. This patch moves the domain_finalise into
attach_device which has the device information, then could update
the domain's geometry.aperture ranges for each a device.
Strictly, I should use the data from mtk_iommu_get_m4u_data as the
parameter of mtk_iommu_domain_finalise in this patch. but dom->data
only is used in tlb ops in which the data is get from the m4u_list, thus
it is ok here.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-25-yong.wu@mediatek.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 4f956c97d2)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: I1abc9d7a17eb7a4df5fae01b422525fd4f012384
In the previous SoC, the M4U HW is in the EMI power domain which is
always on. the latest M4U is in the display power domain which may be
turned on/off, thus we have to add pm_runtime interface for it.
When the engine work, the engine always enable the power and clocks for
smi-larb/smi-common, then the M4U's power will always be powered on
automatically via the device link with smi-common.
Note: we don't enable the M4U power in iommu_map/unmap for tlb flush.
If its power already is on, of course it is ok. if the power is off,
the main tlb will be reset while M4U power on, thus the tlb flush while
m4u power off is unnecessary, just skip it.
Therefore, we increase the ref_count for pm when pm status is ACTIVE,
otherwise, skip it. Meanwhile, the tlb_flush_range is called so often,
thus, update pm ref_count while the SoC has power-domain to avoid touch the
dev->power.lock. and the tlb_flush_all only is called when boot, so no
need check if the SoC has power-domain to keep code clean.
There will be one case that pm runctime status is not expected when tlb
flush. After boot, the display may call dma_alloc_attrs before it call
pm_runtime_get(disp-dev), then the m4u's pm status is not active inside
the dma_alloc_attrs. Since it only happens after boot, the tlb is clean
at that time, I also think this is ok.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-21-yong.wu@mediatek.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit c0b57581b7)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: Ice851a821fdc1c04cb2835a495e852a61bc9536f
In pm runtime case, all the registers backup/restore and bclk are
controlled in the pm_runtime callback, Rename the original
suspend/resume to the runtime_suspend/resume.
Use pm_runtime_force_suspend/resume as the normal suspend/resume.
iommu should suspend after iommu consumer devices, thus use _LATE_.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-20-yong.wu@mediatek.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 34665c7929)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: Ib0eff40d127500ad0d05aee767130728831405a3
In the lastest SoC, M4U has its special power domain. thus, If the engine
begin to work, it should help enable the power for M4U firstly.
Currently if the engine work, it always enable the power/clocks for
smi-larbs/smi-common. This patch adds device_link for smi-common and M4U.
then, if smi-common power is enabled, the M4U power also is powered on
automatically.
Normally M4U connect with several smi-larbs and their smi-common always
are the same, In this patch it get smi-common dev from the last smi-larb
device, then add the device_link.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-19-yong.wu@mediatek.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit baf94e6ebf)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: Ie57e065de705464cdec6ef7fc4a34a0abfa2572c
Add a HW flag for if the HW support 34bit IOVA. the previous SoC
still use 32bit. normally the lvl1 pgtable size is 16KB when ias == 32.
if ias == 34, lvl1 pgtable size is 16KB * 4. The purpose of this patch
is to save 16KB*3 continuous memory for the previous SoC.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-15-yong.wu@mediatek.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 2f317da433)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: I1b648641c580e875d84dc2c36bcc8e24b536fccd
In current iommu_unmap, this code is:
iommu_iotlb_gather_init(&iotlb_gather);
ret = __iommu_unmap(domain, iova, size, &iotlb_gather);
iommu_iotlb_sync(domain, &iotlb_gather);
We could gather the whole iova range in __iommu_unmap, and then do tlb
synchronization in the iommu_iotlb_sync.
This patch implement this, Gather the range in mtk_iommu_unmap.
then iommu_iotlb_sync call tlb synchronization for the gathered iova range.
we don't call iommu_iotlb_gather_add_page since our tlb synchronization
could be regardless of granule size.
In this way, gather->start is impossible ULONG_MAX, remove the checking.
This patch aims to do tlb synchronization *once* in the iommu_unmap.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210107122909.16317-7-yong.wu@mediatek.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit f21ae3b100)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: Ieab4a1b914d7a1f0fe5100306f3d5ff13437127a
iotlb_sync_map allow IOMMU drivers tlb sync after completing the whole
mapping. This patch adds iova and size as the parameters in it. then the
IOMMU driver could flush tlb with the whole range once after iova mapping
to improve performance.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210107122909.16317-3-yong.wu@mediatek.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 2ebbd25873)
(YongWu: this branch has this commit which is not in mainline:
c8ab4bae58 FROMLIST: iommu: Introduce map_sg() as an IOMMU op for IOMMU drivers
)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: Ie463d3cf7efa9320661e7e5fb0042f54d9f1a892
The only user of tlb_flush_leaf is a particularly hairy corner of the
Arm short-descriptor code, which wants a synchronous invalidation to
minimise the races inherent in trying to split a large page mapping.
This is already far enough into "here be dragons" territory that no
sensible caller should ever hit it, and thus it really doesn't need
optimising. Although using tlb_flush_walk there may technically be
more heavyweight than needed, it does the job and saves everyone else
having to carry around useless baggage.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://lore.kernel.org/r/9844ab0c5cb3da8b2f89c6c2da16941910702b41.1606324115.git.robin.murphy@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit fefe8527a1)
BUG=b:174513569
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Change-Id: I04128ee941e78b3aad53d7d227d8d825e9ee6fe6
Add below kernel symbols for vendor modules to collect
debug information from running/panic kernel. These debug
information could be related to ftrace, irqstat, dmesg
etc.
android_debug_per_cpu_symbol
android_debug_symbol
copy_from_kernel_nofault
ipi_desc_get
kstat
kstat_irqs_cpu
kstat_irqs_usr
log_buf_addr_get
log_buf_len_get
nr_ipi_get
nr_irqs
per_cpu_ptr_to_phys
register_die_notifier
register_module_notifier
seq_buf_printf
__tracepoint_android_vh_ftrace_dump_buffer
__tracepoint_android_vh_ftrace_format_check
__tracepoint_android_vh_ftrace_oops_enter
__tracepoint_android_vh_ftrace_oops_exit
__tracepoint_android_vh_ftrace_size_check
unregister_die_notifier
unregister_module_notifier
Bug: 183479351
Change-Id: I8547e3f15a2cb12a72bc43e449fbaa8f31ec8759
Signed-off-by: Mukesh Ojha <mojha@codeaurora.org>
This is an incompatible ABI XML version change.
Bitfield offsets are now correct.
Bug: 183612421
Change-Id: I641f2f36c94182409664fb60045d41b2b8e30010
Signed-off-by: Giuliano Procida <gprocida@google.com>
Add vendor hook to get the binder message for vendor-specific tuning.
Bug: 182496370
Signed-off-by: Zhuguangqing <zhuguangqing@xiaomi.com>
Change-Id: Id47e59c4e3ccd07b26eef758ada147b98cd1964e
timerfd doesn't create any wakelocks, but eventpoll can. When it does,
it names them after the underlying file descriptor, and since all
timerfd file descriptors are named "[timerfd]" (which saves memory on
systems like desktops with potentially many timerfd instances), all
wakesources created as a result of using the eventpoll-on-timerfd idiom
are called... "[timerfd]".
However, it becomes impossible to tell which "[timerfd]" wakesource is
affliated with which process and hence troubleshooting is difficult.
Adding vendor hooks to allow vendor to assign appropriate names to
timerfd descriptors and eventoll wakesource.
Bug: 155142106
Signed-off-by: Manish Varma <varmam@google.com>
Change-Id: I330a42ab48bed4b26d5eb2f636925c66061165ec
Leaf changes summary: 526 artifacts changed
Changed leaf types summary: 3 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 502 Changed, 11 Added functions
Removed/Changed/Added variables summary: 0 Removed, 10 Changed, 0 Added variable
11 Added functions:
[A] 'function int is_dma_buf_file(file*)'
[A] 'function xhci_command* xhci_alloc_command(xhci_hcd*, bool, unsigned int)'
[A] 'function int xhci_alloc_erst(xhci_hcd*, xhci_ring*, xhci_erst*, gfp_t)'
[A] 'function void xhci_free_command(xhci_hcd*, xhci_command*)'
[A] 'function void xhci_free_erst(xhci_hcd*, xhci_erst*)'
[A] 'function unsigned int xhci_get_endpoint_index(usb_endpoint_descriptor*)'
[A] 'function int xhci_queue_stop_endpoint(xhci_hcd*, xhci_command*, int, unsigned int, int)'
[A] 'function xhci_ring* xhci_ring_alloc(xhci_hcd*, unsigned int, unsigned int, xhci_ring_type, unsigned int, gfp_t)'
[A] 'function void xhci_ring_cmd_db(xhci_hcd*)'
[A] 'function void xhci_ring_free(xhci_hcd*, xhci_ring*)'
[A] 'function long long unsigned int xhci_trb_virt_to_dma(xhci_segment*, xhci_trb*)'
502 functions with some sub-type change:
[C] 'function void __ClearPageMovable(page*)' at compaction.c:138:1 has some sub-type changes:
CRC (modversions) changed from 0xb9a01cb4 to 0x2f37d230
[C] 'function void __SetPageMovable(page*, address_space*)' at compaction.c:130:1 has some sub-type changes:
CRC (modversions) changed from 0x8981e72b to 0x5eea6e25
[C] 'function int __clk_determine_rate(clk_hw*, clk_rate_request*)' at clk.c:1428:1 has some sub-type changes:
CRC (modversions) changed from 0xe702ac17 to 0x6599ee5b
... 499 omitted; 502 symbols have only CRC changes
10 Changed variables:
[C] 'console* console_drivers' was changed at printk.c:89:1:
CRC (modversions) changed from 0x77f8713d to 0x3a383b45
[C] 'device_type i2c_adapter_type' was changed at i2c-core-base.c:1259:1:
CRC (modversions) changed from 0x36d2db2 to 0x6046b60c
[C] 'bus_type i2c_bus_type' was changed at i2c-core-base.c:628:1:
CRC (modversions) changed from 0xcfff93e7 to 0xe73eb163
... 7 omitted; 10 symbols have only CRC changes
'struct perf_cpu_context at perf_event.h:859:1' changed:
type size changed from 3200 to 3392 (in bits)
1 data member insertion:
'list_head perf_cpu_context::sched_cb_entry', at offset 2944 (in bits) at perf_event.h:876:1
there are data member changes:
3 ('int perf_cpu_context::sched_cb_usage' .. 'int perf_cpu_context::heap_size') offsets changed (by +160 bits)
2 ('perf_event** perf_cpu_context::heap' .. 'perf_event* perf_cpu_context::heap_default[2]') offsets changed (by +192 bits)
855 impacted interfaces
'struct shash_desc at hash.h:150:1' changed (indirectly):
type size changed from 1024 to 128 (in bits)
there are data member changes:
'void* shash_desc::__ctx[]' offset changed (by -896 bits)
2 impacted interfaces
'struct snd_usb_audio at usbaudio.h:24:1' changed:
type size hasn't changed
1 data member insertion:
'uint16_t snd_usb_audio::quirk_type', at offset 1248 (in bits) at usbaudio.h:30:1
2 impacted interfaces
Bug: 183612421
Change-Id: Ic30906915d808f6e6921a1fe79bd3cd414104d35
Signed-off-by: Giuliano Procida <gprocida@google.com>
This reverts commit 7d212a5102.
This commit is superseded by commit a0a0b3f42e ("FROMLIST: mm: fs:
Invalidate BH LRU during page migration").
Conflicts:
fs/buffer.c
1. In fs/buffer.c had to keep invalidate_bh_lrus_cpu() function that was
introduced in commit a0a0b3f42e as well as in the reverted commit.
Bug: 174118021
Signed-off-by: Chris Goldsworthy <cgoldswo@codeaurora.org>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I60d0a4e8beb35389727f29fea6ca4640ecee40a7
