Hi, Yong:
On Mon, 2019-06-10 at 20:55 +0800, Yong Wu wrote:
> MediaTek IOMMU has already added the device_link between the consumer
> and smi-larb device. If the drm device call the pm_runtime_get_sync,
> the smi-larb's pm_runtime_get_sync also be called automatically.
>
> CC: CK Hu
> CC: Philip
On Mon, Jun 10, 2019 at 9:21 PM Yong Wu wrote:
>
> Normally the M4U HW connect EMI with smi. the diagram is like below:
> EMI
>|
> M4U
>|
> smi-common
>|
>-
>||| |
Hi,
On 6/17/19 9:20 PM, Qian Cai wrote:
The linux-next commit "iommu/vt-d: Duplicate iommu_resv_region objects
per device list" [1] left out an unused variable,
drivers/iommu/intel-iommu.c: In function 'dmar_parse_one_rmrr':
drivers/iommu/intel-iommu.c:4014:9: warning: variable 'length' set but
Stephane,
On Mon, 17 Jun 2019, Stephane Eranian wrote:
> On Mon, Jun 17, 2019 at 1:25 AM Thomas Gleixner wrote:
> > Great that there is no trace of any mail from Andi or Stephane about this
> > on LKML. There is no problem with talking offlist about this stuff, but
> > then you should at least pr
Hi,
On Mon, Jun 17, 2019 at 1:25 AM Thomas Gleixner wrote:
>
> On Sun, 16 Jun 2019, Thomas Gleixner wrote:
> > On Thu, 23 May 2019, Ricardo Neri wrote:
> > > When the hardlockup detector is enabled, the function
> > > hld_hpet_intremapactivate_irq() activates the recently created entry
> > > in t
Hi Christoph,
On Fri, Jun 14, 2019 at 12:21 PM Christoph Hellwig wrote:
> can you take a look at the (untested) patches below? They convert m68k
> to use the generic remapping DMA allocator, which is also used by
> arm64 and csky.
Thanks. But what does this buy us?
bloat-o-meter says:
add/rem
Hi John,
On Mon, Jun 17, 2019 at 02:38:59PM +0100, John Garry wrote:
> On 11/06/2019 14:45, Will Deacon wrote:
> > Hi all,
> >
> > This patch series is an attempt to reduce lock contention when inserting
> > commands into the Arm SMMUv3 command queue. Unfortunately, our initial
> > benchmarking h
On 10/06/2019 14:18, Yong Wu wrote:
> Switch to SPDX license identifier for MediaTek iommu/smi and their
> header files.
>
> Signed-off-by: Yong Wu
> Reviewed-by: Rob Herring
> Reviewed-by: Evan Green
Reviewed-by: Matthias Brugger
> ---
> drivers/iommu/mtk_iommu.c | 1
On 10/06/2019 14:17, Yong Wu wrote:
> The register VLD_PA_RNG(0x118) was forgot to backup while adding 4GB
> mode support for mt2712. this patch add it.
>
> Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
> for 4GB mode")
> Signed-off-by: Yong Wu
> Reviewed-by: Evan Green
On 13/06/2019 10:20, Pi-Hsun Shih wrote:
> (Sorry for the possibly double-posting, my last mail got rejected by
> some mailing lists.)
>
> Hi,
> When I tested this patch series (Based on linux 5.2.0-rc2, and with
> various other patch series about MT8183) with lockdep enabled, and I'm
> seeing
On 10/06/2019 14:17, Yong Wu wrote:
> There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
> mmu0 or mmu1 to balance the bandwidth via the smi-common register
> SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
>
> In mt8183, For better performance, we switch larb1/2/5/7 to enter
>
On 10/06/2019 14:17, Yong Wu wrote:
> This patch only move the clk_prepare_enable and config_port into the
> runtime suspend/resume callback. It doesn't change the code content
> and sequence.
>
> This is a preparing patch for adjusting SMI_BUS_SEL for mt8183.
> (SMI_BUS_SEL need to be restored
On Mon, 17 Jun 2019, Arnd Bergmann wrote:
> On architectures that have a larger dma_addr_t than phys_addr_t,
> the swiotlb_tbl_map_single() function truncates its return code
> in the failure path, making it impossible to identify the error
> later, as we compare to the original value:
>
> kernel/
On 10/06/2019 14:17, Yong Wu wrote:
> Normally the M4U HW connect EMI with smi. the diagram is like below:
> EMI
>|
> M4U
>|
> smi-common
>|
>-
>||| |...
>
On 10/06/2019 14:17, Yong Wu wrote:
> The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use
> the ARM Short-descriptor like mt8173, and most of the HW registers
> are the same.
>
> Here list main differences between mt8183 and mt8173/mt2712:
> 1) mt8183 has only one M4U HW like mt
On Mon 01 Apr 08:40 PDT 2019, Marc Gonzalez wrote:
> The MSM8998 ANOC1(*) SMMU services BLSP2, PCIe, UFS, and USB.
> (*) Aggregate Network-on-Chip #1
>
> Based on the following DTS downstream:
> https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/arch/arm/boot/dts/qcom/msm-arm-smmu-8998.dts
On 10/06/2019 14:17, Yong Wu wrote:
> In some SoCs like mt8183, SMI add GALS(Global Async Local Sync) module
> which can help synchronize for the modules in different clock frequency.
> It can be seen as a "asynchronous fifo". This is a example diagram:
>
> M4U
> |
>
Hi Qian,
On 6/17/19 3:20 PM, Qian Cai wrote:
> The linux-next commit "iommu/vt-d: Duplicate iommu_resv_region objects
> per device list" [1] left out an unused variable,
>
> drivers/iommu/intel-iommu.c: In function 'dmar_parse_one_rmrr':
> drivers/iommu/intel-iommu.c:4014:9: warning: variable 'le
On 11/06/2019 14:45, Will Deacon wrote:
Hi all,
This patch series is an attempt to reduce lock contention when inserting
commands into the Arm SMMUv3 command queue. Unfortunately, our initial
benchmarking has shown mixed results across the board and the changes in
the last patch don't appear to
Hi Christoph,
On 14/6/19 8:21 pm, Christoph Hellwig wrote:
Hi Geert and Greg,
can you take a look at the (untested) patches below? They convert m68k
to use the generic remapping DMA allocator, which is also used by
arm64 and csky.
No impact to ColdFire targets, so I'll have to defer to Geert
On 32-bit architectures, phys_addr_t may be different from dma_add_t,
both smaller and bigger. This can lead to an overflow during an assignment
that clang warns about:
drivers/iommu/dma-iommu.c:230:10: error: implicit conversion from 'dma_addr_t'
(aka 'unsigned long long') to
'phys_addr_t'
On architectures that have a larger dma_addr_t than phys_addr_t,
the swiotlb_tbl_map_single() function truncates its return code
in the failure path, making it impossible to identify the error
later, as we compare to the original value:
kernel/dma/swiotlb.c:551:9: error: implicit conversion from '
On 14/06/2019 16:34, Christoph Hellwig wrote:
On Fri, Jun 14, 2019 at 05:30:32PM +0200, Greg KH wrote:
On Fri, Jun 14, 2019 at 04:48:57PM +0200, Christoph Hellwig wrote:
On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
Perhaps a hint as to how we can fix this up? This is the first tim
The linux-next commit "iommu/vt-d: Duplicate iommu_resv_region objects
per device list" [1] left out an unused variable,
drivers/iommu/intel-iommu.c: In function 'dmar_parse_one_rmrr':
drivers/iommu/intel-iommu.c:4014:9: warning: variable 'length' set but
not used [-Wunused-but-set-variable]
[1]
On 10/06/2019 14:17, Yong Wu wrote:
> Both mt8173 and mt8183 don't have this vld_pa_rng(valid physical address
> range) register while mt2712 have. Move it into the plat_data.
>
> Signed-off-by: Yong Wu
> Reviewed-by: Evan Green
Reviewed-by: Matthias Brugger
> ---
> drivers/iommu/mtk_iomm
On 10/06/2019 14:17, Yong Wu wrote:
> In mt8173 and mt8183, 0x48 is REG_MMU_STANDARD_AXI_MODE while it is
> REG_MMU_CTRL in the other SoCs, and the bits meaning is completely
> different with the REG_MMU_STANDARD_AXI_MODE.
>
> This patch moves this property to plat_data, it's also a preparing
>
On 10/06/2019 14:17, Yong Wu wrote:
> The protect memory setting is a little different in the different SoCs.
> In the register REG_MMU_CTRL_REG(0x110), the TF_PROT(translation fault
> protect) shift bit is normally 4 while it shift 5 bits only in the
> mt8173. This patch delete the complex MACR
On 10/06/2019 14:17, Yong Wu wrote:
> The larb-id may be remapped in the smi-common, this means the
> larb-id reported in the mtk_iommu_isr isn't the real larb-id,
>
> Take mt8183 as a example:
>M4U
> |
> --
> drivers/infiniband/hw/cxgb4/qp.c
>129 static int alloc_host_sq(struct c4iw_rdev *rdev, struct t4_sq *sq)
>130 {
>131 sq->queue = dma_alloc_coherent(&(rdev->lldi.pdev->dev),
> sq->memsize,
>132 &(sq->dma_addr), GFP_KERNEL);
>1
On Sun, 16 Jun 2019, Thomas Gleixner wrote:
> On Thu, 23 May 2019, Ricardo Neri wrote:
> > When the hardlockup detector is enabled, the function
> > hld_hpet_intremapactivate_irq() activates the recently created entry
> > in the interrupt remapping table via the modify_irte() functions. While
> > d
I once wrote a Smatch check based on a commit message that said we can't
pass dma_alloc_coherent() pointers to virt_to_phys(). But then I never
felt like I understood the rules enough to actually report the warnings
as bugs.
drivers/platform/x86/dcdbas.c:108 smi_data_buf_realloc() error: 'buf' ca
Hi Christoph,
> From: Christoph Hellwig, Sent: Monday, June 17, 2019 3:54 PM
>
> On Mon, Jun 17, 2019 at 06:46:33AM +, Yoshihiro Shimoda wrote:
> > > can_merge seems a little too generic a name to me. Maybe can_iommu_merge?
> >
> > I'll fix the name. Also, only the device_iommu_mapped() cond
32 matches
Mail list logo
