If the iova is 34bit, the iova[32][33] is the bit0/1 in the tlb flush
register. Add a new macro for this.

In the macro, since (iova + size - 1) may be end with 0xfff, then the
bit0/1 always is 1, thus add a mask.
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-22-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

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: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-21-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

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: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-20-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

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: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-19-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

In the original code, we lack the error handle. This patch adds them.
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-18-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

In attach device, it will update the pagetable base address register.
Move the hw_init function also here. Then it only need call
pm_runtime_get/put one time here if m4u has power domain.
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-17-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

This patch only updates oas in different SoCs.

If the SoC supports 4GB-mode and current dram size is 4GB, the oas is 33.
otherwise, it's still 32. In the lastest SoC, the oas is 35bits.
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-16-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

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: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-15-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

The standard input iova bits is 32. MediaTek quad the lvl1 pagetable
(4 * lvl1). No change for lvl2 pagetable. Then the iova bits can reach
34bit.
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-14-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

Add "cfg" as a parameter for some macros. This is a preparing patch for
mediatek extend the lvl1 pgtable. No functional change.
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Acked-by: NWill Deacon <will@kernel.org>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-13-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

The current _ARM_V7S_LVL_BITS/ARM_V7S_LVL_SHIFT use a formula to calculate
the corresponding value for level1 and level2 to pretend the code sane.
Actually their level1 and level2 values are different from each other.
This patch only clarify the two macro. No functional change.
Suggested-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-12-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

MediaTek extend the bit5 in lvl1 and lvl2 descriptor as PA34.
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Acked-by: NWill Deacon <will@kernel.org>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-11-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

Use the ias for the valid iova checking in arm_v7s_unmap. This is a
preparing patch for supporting iova 34bit for MediaTek.
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-10-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

Use the common memory header(larb-port) in the source code.
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Acked-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-9-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

This patch adds decriptions for mt8192 IOMMU and SMI.

mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
table format. The M4U-SMI HW diagram is as below:

                          EMI
                           |
                          M4U
                           |
                      ------------
                       SMI Common
                      ------------
                           |
  +-------+------+------+----------------------+-------+
  |       |      |      |       ......         |       |
  |       |      |      |                      |       |
larb0   larb1  larb2  larb4     ......      larb19   larb20
disp0   disp1   mdp    vdec                   IPE      IPE

All the connections are HW fixed, SW can NOT adjust it.

mt8192 M4U support 0~16GB iova range. we preassign different engines
into different iova ranges:

domain-id  module     iova-range                  larbs
   0       disp        0 ~ 4G                      larb0/1
   1       vcodec      4G ~ 8G                     larb4/5/7
   2       cam/mdp     8G ~ 12G             larb2/9/11/13/14/16/17/18/19/20
   3       CCU0    0x4000_0000 ~ 0x43ff_ffff     larb13: port 9/10
   4       CCU1    0x4400_0000 ~ 0x47ff_ffff     larb14: port 4/5

The iova range for CCU0/1(camera control unit) is HW requirement.
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Acked-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-6-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

Only rename the header guard for all the SoC larb port header file.
No funtional change.
Suggested-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Acked-by: NKrzysztof Kozlowski <krzk@kernel.org>
Acked-by: NRob Herring <robh@kernel.org>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-5-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

Extend the max larb number definition as mt8192 has larb_nr over 16.
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Acked-by: NRob Herring <robh@kernel.org>
Acked-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-4-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

Put all the macros about smi larb/port togethers.
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Acked-by: NRob Herring <robh@kernel.org>
Acked-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-3-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

Convert MediaTek IOMMU to DT schema.
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20210111111914.22211-2-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

IO_PGTABLE_QUIRK_TLBI_ON_MAP is now fully superseded by the
core API's iotlb_sync_map callback.
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/5abb80bba3a7c371d5ffb7e59c05586deddb9a91.1611764372.git.robin.murphy@arm.com
[will: Remove unused 'iop' local variable from arm_v7s_map()]
Signed-off-by: NWill Deacon <will@kernel.org>

The core API can now accommodate invalidate-on-map style behaviour in a
single efficient call, so hook that up instead of having io-pgatble do
it piecemeal.
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/e95223a0abf129230a0bec6743f837075f0a2fcb.1611764372.git.robin.murphy@arm.comSigned-off-by: NWill Deacon <will@kernel.org>

Until now, we have already used the tlb operations from iommu framework,
then the tlb operations for v7s can be removed.

Correspondingly, Switch the paramenter "cookie" to the internal structure.
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Acked-by: NWill Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210107122909.16317-8-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

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: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Acked-by: NWill Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210107122909.16317-7-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

This patch allows io_pgtable_tlb ops could be null since the IOMMU drivers
may use the tlb ops from iommu framework.
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Acked-by: NWill Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210107122909.16317-6-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

Currently gather->end is "unsigned long" which may be overflow in
arch32 in the corner case: 0xfff00000 + 0x100000(iova + size).
Although it doesn't affect the size(end - start), it affects the checking
"gather->end < end"

This patch changes this "end" to the real end address
(end = start + size - 1). Correspondingly, update the length to
"end - start + 1".

Fixes: a7d20dc1 ("iommu: Introduce struct iommu_iotlb_gather for batching TLB flushes")
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Acked-by: NWill Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210107122909.16317-5-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

Remove IO_PGTABLE_QUIRK_TLBI_ON_MAP to avoid tlb sync for each a small
chunk memory, Use the new iotlb_sync_map to tlb_sync once for whole the
iova range of iommu_map.
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Acked-by: NWill Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210107122909.16317-4-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

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: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Acked-by: NWill Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210107122909.16317-3-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

In the end of __iommu_map, It alway call iotlb_sync_map.

This patch moves iotlb_sync_map out from __iommu_map since it is
unnecessary to call this for each sg segment especially iotlb_sync_map
is flush tlb all currently. Add a little helper _iommu_map for this.
Signed-off-by: NYong Wu <yong.wu@mediatek.com>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Acked-by: NWill Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210107122909.16317-2-yong.wu@mediatek.comSigned-off-by: NWill Deacon <will@kernel.org>

Since commit 36e2c742 ("fs: don't allow splice read/write without
explicit ops") we've required that file operation structures explicitly
enable splice support, rather than falling back to the default handlers.

Most /proc files use the indirect 'struct proc_ops' to describe their
file operations, and were fixed up to support splice earlier in commits
40be821d..b24c30c6, but the mountinfo files interact with the
VFS directly using their own 'struct file_operations' and got missed as
a result.

This adds the necessary support for splice to work for /proc/*/mountinfo
and friends.
Reported-by: NJoan Bruguera Micó <joanbrugueram@gmail.com>
Reported-by: NJussi Kivilinna <jussi.kivilinna@iki.fi>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=209971
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull NTB fixes from Jon Mason:
 "Bug fix for IDT NTB and Intel NTB LTR management support"

* tag 'ntb-5.11' of git://github.com/jonmason/ntb:
  ntb: intel: add Intel NTB LTR vendor support for gen4 NTB
  ntb: idt: fix error check in ntb_hw_idt.c

Pull crypto fixes from Herbert Xu:
 "Fix a number of autobuild failures due to missing Kconfig
  dependencies"

* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: qat - add CRYPTO_AES to Kconfig dependencies
  crypto: keembay - Add dependency on HAS_IOMEM
  crypto: keembay - CRYPTO_DEV_KEEMBAY_OCS_AES_SM4 should depend on ARCH_KEEMBAY

Pull objtool fix from Ingo Molnar:
 "Fix a segfault that occurs when built with Clang"

* tag 'objtool-urgent-2020-12-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  objtool: Fix seg fault with Clang non-section symbols

Pull locking fixes from Ingo Molnar:
 "Misc fixes/updates:

   - Fix static keys usage in module __init sections

   - Add separate MAINTAINERS entry for static branches/calls

   - Fix lockdep splat with CONFIG_PREEMPTIRQ_EVENTS=y tracing"

* tag 'locking-urgent-2020-12-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  softirq: Avoid bad tracing / lockdep interaction
  jump_label/static_call: Add MAINTAINERS
  jump_label: Fix usage in module __init

Pull timer fixes from Ingo Molnar:
 "Update/fix two CPU sanity checks in the hotplug and the boot code, and
  fix a typo in the Kconfig help text.

  [ Context: the first two commits are the result of an ongoing
    annotation+review work of (intentional) tick_do_timer_cpu() data
    races reported by KCSAN, but the annotations aren't fully cooked
    yet ]"

* tag 'timers-urgent-2020-12-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  timekeeping: Fix spelling mistake in Kconfig "fullfill" -> "fulfill"
  tick/sched: Remove bogus boot "safety" check
  tick: Remove pointless cpu valid check in hotplug code

Pull scheduler fix from Ingo Molnar:
 "Fix a context switch performance regression"

* tag 'sched-urgent-2020-12-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched: Optimize finish_lock_switch()

Commit c9a3c4e6 ("mfd: ab8500-debugfs: Remove extraneous curly
brace") removed a left-over curly brace that caused build failures, but
Joe Perches points out that the subsequent 'seq_putc()' should also be
removed, because the commit that caused all these problems already added
the final '\n' to the seq_printf() above it.
Reported-by: NJoe Perches <joe@perches.com>
Fixes: 886c8121 ("mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc")
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull PCI fixes from Bjorn Helgaas:

 - Fix a tegra enumeration regression (Rob Herring)

 - Fix a designware-host check that warned on *success*, not failure
   (Alexander Lobakin)

* tag 'pci-v5.11-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  PCI: dwc: Fix inverted condition of DMA mask setup warning
  PCI: tegra: Fix host link initialization

Clang errors:

  drivers/mfd/ab8500-debugfs.c:1526:2: error: non-void function does not return a value [-Werror,-Wreturn-type]
          }
          ^
  drivers/mfd/ab8500-debugfs.c:1528:2: error: expected identifier or '('
  return 0;
          ^
  drivers/mfd/ab8500-debugfs.c:1529:1: error: extraneous closing brace ('}')
  }
  ^
  3 errors generated.

The cleanup in ab8500_interrupts_show left a curly brace around, remove
it to fix the error.

Fixes: 886c8121 ("mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc")
Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 660c4865 ("PCI: dwc: Set 32-bit DMA mask for MSI target address
allocation") added dma_mask_set() call to explicitly set 32-bit DMA mask
for MSI message mapping, but for now it throws a warning on ret == 0, while
dma_set_mask() returns 0 in case of success.

Fix this by inverting the condition.

[bhelgaas: join string to make it greppable]
Fixes: 660c4865 ("PCI: dwc: Set 32-bit DMA mask for MSI target address allocation")
Link: https://lore.kernel.org/r/20201222150708.67983-1-alobakin@pm.meSigned-off-by: NAlexander Lobakin <alobakin@pm.me>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>