For iommu offset=0x48 register, only the previous mt8173/mt8183 use the
name STANDARD_AXI_MODE, all the latest SoC extend the register more
feature by different bits, for example: axi_mode, in_order_en, coherent_en
and so on. So rename REG_MMU_MISC_CTRL may be more proper.
This patch only rename
This patch adds description for MT6779 IOMMU.
MT6779 has two iommus, they are mm_iommu and apu_iommu which
both use ARM Short-Descriptor translation format.
In addition, mm_iommu and apu_iommu are two independent HW instance
, we need to set them separately.
The MT6779 IOMMU hardware diagram is
For mt6779, MMU_INV_SEL register's offset is changed from
0x38 to 0x2c, so we can put inv_sel_reg in the plat_data to
use it.
In addition, we renamed it to REG_MMU_INV_SEL_GEN1 and use it
before mt6779.
Change since v3:
1. Fix coding style
Cc: Yong Wu
Signed-off-by: Chao Hao
---
The max larb number that a iommu HW support is 8(larb0~larb7 in the below
diagram).
If the larb's number is over 8, we use a sub_common for merging
several larbs into one larb. At this case, we will extend larb_id:
bit[11:9] means common-id;
bit[8:7] means subcommon-id;
>From these two variable,
Add F_MMU_IN_ORDER_WR_EN definition in MISC_CTRL.
In order to improve performance, we always disable STANDARD_AXI_MODE
and IN_ORDER_WR_EN in MISC_CTRL.
Change since v3:
1. Rename Disable STANDARD_AXI_MODE in MISC_CTRL to Set MISC_CTRL register
2. Add F_MMU_IN_DRDER_WR_EN definition in MISC_CTRL
This patchset adds mt6779 iommu support.
mt6779 has two iommus, they are MM_IOMMU(M4U) and APU_IOMMU which used ARM
Short-Descriptor translation format.
The mt6779's MM_IOMMU-SMI and APU_IOMMU HW diagram is as below, it is only a
brief diagram:
EMI
1. Start from mt6779, INVLDT_SEL move to offset=0x2c, so we add
REG_MMU_INV_SEL_GEN2 definition and mt6779 uses it.
2. Change PROTECT_PA_ALIGN from 128 byte to 256 byte.
3. For REG_MMU_CTRL_REG register, we only need to change bit[2:0],
others bits keep default value, ex: enable victim tlb.
Some platforms(ex: mt6779) have a new register called by REG_MMU_WR_LEN
to improve performance.
This patch add this register definition.
Signed-off-by: Chao Hao
---
drivers/iommu/mtk_iommu.c | 10 ++
drivers/iommu/mtk_iommu.h | 2 ++
2 files changed, 12 insertions(+)
diff --git
On Wed, 2020-06-10 at 15:38 +0800, Tiffany Lin wrote:
> On Wed, 2020-06-10 at 15:46 +0900, Alexandre Courbot wrote:
> > On Wed, Jun 10, 2020 at 6:21 AM Rob Herring wrote:
> > >
> > > On Sat, May 30, 2020 at 04:10:02PM +0800, Yong Wu wrote:
> > > > From: Maoguang Meng
> > > >
> > > > Update
Allow the qcom_scm driver to be loadable as a
permenent module.
Cc: Andy Gross
Cc: Bjorn Andersson
Cc: Joerg Roedel
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
Cc: Linus Walleij
Cc: Lina Iyer
Cc: Saravana Kannan
Cc: Todd Kjos
Cc: Greg Kroah-Hartman
Cc:
Hi John,
+Will for the SMMU part.
On 2020-06-16 07:13, John Stultz wrote:
Allow the qcom_scm driver to be loadable as a
permenent module.
Cc: Andy Gross
Cc: Bjorn Andersson
Cc: Joerg Roedel
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
Cc: Linus Walleij
Cc: Lina Iyer
Cc:
On Fri, Jun 12, 2020 at 05:41:29PM -0700, Fenghua Yu wrote:
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 64ede5f150dc..5778db3aa42d 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -538,6 +538,10 @@ struct mm_struct {
>
On Mon, 2020-05-25 at 14:14 +0800, Yong Wu wrote:
> On Sat, 2020-05-09 at 16:36 +0800, Chao Hao wrote:
> > In order to improve performance, we always disable STANDARD_AXI_MODE in
> > MISC_CTRL.
> >
> > Signed-off-by: Chao Hao
> > ---
> > drivers/iommu/mtk_iommu.c | 8 +++-
> >
Tweaks to allow pinctrl-msm code to be loadable as a module.
This is needed in order to support having the qcom-scm driver,
which pinctrl-msm calls into, configured as a module.
Cc: Andy Gross
Cc: Bjorn Andersson
Cc: Joerg Roedel
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
Cc:
Add export for irq_domain_update_bus_token() so that
we can allow drivers like the qcom-pdc driver to be
loadable as a module.
Cc: Andy Gross
Cc: Bjorn Andersson
Cc: Joerg Roedel
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
Cc: Linus Walleij
Cc: Lina Iyer
Cc: Saravana Kannan
Cc:
Allows qcom-pdc driver to be loaded as a permenent module
Also, due to the fact that IRQCHIP_DECLARE becomes a no-op when
building as a module, we have to add the platform driver hooks
explicitly.
Thanks to Saravana for his help on pointing out the
IRQCHIP_DECLARE issue and guidance on a
Add EXPORT_SYMBOL_GPL entries for irq_chip_retrigger_hierarchy()
and irq_chip_set_vcpu_affinity_parent() so that we can allow
drivers like the qcom-pdc driver to be loadable as a module.
Cc: Andy Gross
Cc: Bjorn Andersson
Cc: Joerg Roedel
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
This patch series provides exports and config tweaks to allow
the qcom-pdc, pinctrl-msm and qcom-scm drivers to be able to be
configured as permement modules (particularlly useful for the
Android Generic Kernel Image efforts).
Feedback would be appreciated!
thanks
-john
Cc: Andy Gross
Cc:
On 6/16/20 3:48 AM, Alexander Monakov wrote:
Alexander
On 6/1/20 4:01 PM, Alexander Monakov wrote:
On Mon, 1 Jun 2020, Suravee Suthikulpanit wrote:
Moving init_iommu_perf_ctr just after iommu_flush_all_caches resolves
the issue. This is the earliest point in amd_iommu_init_pci where the
On 6/15/20 8:05 AM, Christoph Hellwig wrote:
> nommu configfs can trivially map the coherent allocations to user space,
> as no actual page table setup is required and the kernel and the user
> space programs share the same address space.
>
> Fixes: 62fcee9a3bd7 ("dma-mapping: remove
On Mon, Jun 15, 2020 at 06:17:40PM -0700, Rajat Jain wrote:
> The "ExternalFacing" devices (root ports) are still internal devices
> that sit on the internal system fabric and thus trusted. Currently they
> were being marked untrusted - likely as an unintended border case.
It was actually
It has been shown that the cmpxchg() for finding space in the cmdq can
be a real bottleneck:
- for more CPUs contending the cmdq, the cmpxchg() will fail more often
- since the software-maintained cons pointer is updated on the same 64b
memory region, the chance of cmpxchg() failure increases
Since the arm_smmu_ll_queue.prod will be for counting the "owner" value
and also HW prod pointer, calculate how many bits are available for and
used by each.
This is based on the number of possible CPUs in the system. And we require
that each CPU can issue a minimum of 2 commands per batch - 1 x
Hi,
On 6/16/2020 11:43 AM, John Stultz wrote:
Allows qcom-pdc driver to be loaded as a permenent module
typo: permanent
Also, due to the fact that IRQCHIP_DECLARE becomes a no-op when
building as a module, we have to add the platform driver hooks
explicitly.
Thanks to Saravana for his help
On Thu, 11 Jun 2020 17:27:27 -0700
Jacob Pan wrote:
> >
> > But then I thought it even better if VFIO leaves the entire
> > copy_from_user() to the layer consuming it.
> >
> OK. Sounds good, that was what Kevin suggested also. I just wasn't
> sure how much VFIO wants to inspect, I thought
Hi, Jean,
On Tue, Jun 16, 2020 at 10:28:19AM +0200, Jean-Philippe Brucker wrote:
> On Fri, Jun 12, 2020 at 05:41:29PM -0700, Fenghua Yu wrote:
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 64ede5f150dc..5778db3aa42d 100644
> > --- a/include/linux/mm_types.h
> >
As mentioned in [0], the CPU may consume many cycles processing
arm_smmu_cmdq_issue_cmdlist(). One issue we find is the cmpxchg() loop to
get space on the queue takes approx 25% of the cycles for this function.
This series removes that cmpxchg().
For my NVMe test with 3x NVMe SSDs, I'm getting a
Set "cmq" -> "cmdq".
Signed-off-by: John Garry
---
drivers/iommu/arm-smmu-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index f578677a5c41..a8e814c652fe 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++
To ensure that a CPU does not send more than a permitted amount of commands
to the cmdq, ensure that each batch includes a CMD_SYNC. When issuing a
CMD_SYNC, we always wait for the consumption of its batch of commands - as
such, we guarantee that any CPU will not issue more than its permitted
On Tue, Jun 16, 2020 at 02:26:38AM +, Tian, Kevin wrote:
> > From: Stefan Hajnoczi
> > Sent: Monday, June 15, 2020 6:02 PM
> >
> > On Thu, Jun 11, 2020 at 05:15:19AM -0700, Liu Yi L wrote:
> > > Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
> > > Intel platforms
Some PCIe devices do not expect a PASID value in PRI Page Responses.
If the "PRG Response PASID Required" bit in the PRI capability is zero,
then the OS should not set the PASID field. Similarly on Arm SMMU,
responses to stall events do not have a PASID.
Currently iommu_page_response()
On Mon, Jun 15, 2020 at 12:39:40PM +, Liu, Yi L wrote:
> > From: Stefan Hajnoczi
> > Sent: Monday, June 15, 2020 6:02 PM
> >
> > On Thu, Jun 11, 2020 at 05:15:19AM -0700, Liu Yi L wrote:
> > > Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
> > > Intel platforms allows
On Tue, Jun 16, 2020 at 04:49:28PM +0100, Stefan Hajnoczi wrote:
> Isolation between applications is preserved but there is no isolation
> between the device and the application itself. The application needs to
> trust the device.
>
> Examples:
>
> 1. The device can snoop secret data from
On Tue, Jun 16, 2020 at 04:49:28PM +0100, Stefan Hajnoczi wrote:
> On Tue, Jun 16, 2020 at 02:26:38AM +, Tian, Kevin wrote:
> > > From: Stefan Hajnoczi
> > > Sent: Monday, June 15, 2020 6:02 PM
> > >
> > > On Thu, Jun 11, 2020 at 05:15:19AM -0700, Liu Yi L wrote:
> > > > Shared Virtual
On Tue, Jun 16 2020 at 05:30 -0600, Maulik Shah wrote:
Hi,
On 6/16/2020 11:43 AM, John Stultz wrote:
Allows qcom-pdc driver to be loaded as a permenent module
typo: permanent
Also, due to the fact that IRQCHIP_DECLARE becomes a no-op when
building as a module, we have to add the platform
Hi, Peter,
On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
>
> > Or do you suggest to add a random new flag in struct thread_info instead
> > of a TIF flag?
>
> Why thread_info? What's wrong with something simple like
On Tue, Jun 16, 2020 at 12:32 AM Christoph Hellwig wrote:
>
> On Mon, Jun 15, 2020 at 06:17:42PM -0700, Rajat Jain via iommu wrote:
> > This is needed to allow the userspace to determine when an untrusted
> > device has been added, and thus allowing it to bind the driver manually
> > to it, if it
The new field in struct device 'dma_pfn_offset_map' is used to facilitate
the use of single or multiple pfn offsets between cpu addrs and dma addrs.
It subsumes the role of dev->dma_pfn_offset -- a uniform offset.
The function of_dma_get_range() has been modified to take two additional
arguments:
Patchset Summary:
Enhance a PCIe host controller driver. Because of its unusual design
we are foced to change dev->dma_pfn_offset into a more general role
allowing multiple offsets.
v5:
Commit "device core: Introduce multiple dma pfn offsets"
-- in of/address.c: "map_size = 0" =>
Currently, Linux logs the two messages below.
[0.979142] pci :00:00.2: AMD-Vi: Extended features
(0xf77ef22294ada):
[0.979546] PPR NX GT IA GA PC GA_vAPIC
The log level of these lines differs though. The first one has level
*info*, while the second has level *warn*, which
On Tue, Jun 16, 2020 at 4:30 AM Maulik Shah wrote:
>
> Hi,
>
> On 6/16/2020 11:43 AM, John Stultz wrote:
> > Allows qcom-pdc driver to be loaded as a permenent module
>
> typo: permanent
>
> > Also, due to the fact that IRQCHIP_DECLARE becomes a no-op when
> > building as a module, we have to add
41 matches
Mail list logo
