Hi, Jonathan
Thanks for the suggestions
On 2019/11/1 上午1:13, Jonathan Cameron wrote:
On Tue, 29 Oct 2019 14:40:15 +0800
Zhangfei Gao wrote:
From: Kenneth Lee
Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
provide Shared Virtual Addressing (SVA) between accelera
On 2019-11-04 21:53, Will Deacon wrote:
On Mon, Nov 04, 2019 at 03:15:06PM +, Will Deacon wrote:
On Sun, Nov 03, 2019 at 11:19:25PM -0600, Andy Gross wrote:
> On Fri, Nov 01, 2019 at 11:01:59PM +0530, Sai Prakash Ranjan wrote:
> > >>> What's the plan for getting this merged? I'm not happy ta
On Fri, Oct 25, 2019 at 07:08:39PM +0100, Robin Murphy wrote:
> Now that we can correctly extract top-level indices without relying on
> the remaining upper bits being zero, the only remaining impediments to
> using a given table for TTBR1 are the address validation on map/unmap
> and the awkward T
On Mon, Nov 04, 2019 at 07:14:45PM +, Will Deacon wrote:
> On Fri, Oct 25, 2019 at 07:08:38PM +0100, Robin Murphy wrote:
> > Although it's conceptually nice for the io_pgtable_cfg to provide a
> > standard VMSA TCR value, the reality is that no VMSA-compliant IOMMU
> > looks exactly like an Arm
On Mon, Nov 04, 2019 at 07:22:28PM +, Will Deacon wrote:
> On Fri, Oct 25, 2019 at 07:08:29PM +0100, Robin Murphy wrote:
> > Since the flawed first attempt, I've reworked things with an abstracted
> > TCR and an explicit TTBR1 quirk. I originally envisaged the need to pass
> > the quirk all the
On Mon, Nov 04, 2019 at 07:20:58PM +, Will Deacon wrote:
> On Mon, Nov 04, 2019 at 06:43:06PM +, Robin Murphy wrote:
> > On 04/11/2019 18:20, Will Deacon wrote:
> > > On Fri, Oct 25, 2019 at 07:08:36PM +0100, Robin Murphy wrote:
> > > > Between VMSAv8-64 and the various 32-bit formats, ther
On Wed, Oct 30, 2019 at 02:51:12PM +, Will Deacon wrote:
> By conditionally dropping support for the legacy binding and exporting
> the newly introduced 'arm_smmu_impl_init()' function we can allow the
> ARM SMMU driver to be built as a module.
>
> Signed-off-by: Will Deacon
> ---
> drivers/
Hi Robin,
On Fri, Oct 25, 2019 at 07:08:29PM +0100, Robin Murphy wrote:
> Since the flawed first attempt, I've reworked things with an abstracted
> TCR and an explicit TTBR1 quirk. I originally envisaged the need to pass
> the quirk all the way down to the TLBI calls, hence getting diverted
> into
On Mon, Nov 04, 2019 at 06:43:06PM +, Robin Murphy wrote:
> On 04/11/2019 18:20, Will Deacon wrote:
> > On Fri, Oct 25, 2019 at 07:08:36PM +0100, Robin Murphy wrote:
> > > Between VMSAv8-64 and the various 32-bit formats, there is either one
> > > 64-bit MAIR or a pair of 32-bit MAIR0/MAIR1 or
On Mon, Nov 04, 2019 at 06:36:51PM +, Robin Murphy wrote:
> On 04/11/2019 18:17, Will Deacon wrote:
> > On Fri, Oct 25, 2019 at 07:08:35PM +0100, Robin Murphy wrote:
> > > The nature of the LPAE format means that data->pg_shift is always
> > > redundant with data->bits_per_level, since they rep
On Thu, Oct 31, 2019 at 03:42:47PM +, Will Deacon wrote:
> > Sorry for the stupid question, but what prevents the iommu module from
> > being unloaded when there are active users? There are no symbol
> > dependencies to endpoint device drivers, because the interface is only
> > exposed through
On Fri, Oct 25, 2019 at 07:08:38PM +0100, Robin Murphy wrote:
> Although it's conceptually nice for the io_pgtable_cfg to provide a
> standard VMSA TCR value, the reality is that no VMSA-compliant IOMMU
> looks exactly like an Arm CPU, and they all have various other TCR
> controls which io-pgtable
On 04/11/2019 18:36, Will Deacon wrote:
On Mon, Oct 28, 2019 at 06:51:55PM +, Robin Murphy wrote:
On 28/10/2019 15:09, Steven Price wrote:
[...]
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -822,15 +822,13 @@ static struct io_pgtable *arm_v7s_alloc_pg
On 04/11/2019 18:20, Will Deacon wrote:
On Fri, Oct 25, 2019 at 07:08:36PM +0100, Robin Murphy wrote:
Between VMSAv8-64 and the various 32-bit formats, there is either one
64-bit MAIR or a pair of 32-bit MAIR0/MAIR1 or NMRR/PMRR registers.
As such, keeping two 64-bit values in io_pgtable_cfg has
On Mon, Oct 28, 2019 at 06:51:55PM +, Robin Murphy wrote:
> On 28/10/2019 15:09, Steven Price wrote:
> [...]
> > > --- a/drivers/iommu/io-pgtable-arm-v7s.c
> > > +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> > > @@ -822,15 +822,13 @@ static struct io_pgtable
> > > *arm_v7s_alloc_pgtable(struct io
On 04/11/2019 18:17, Will Deacon wrote:
On Fri, Oct 25, 2019 at 07:08:35PM +0100, Robin Murphy wrote:
The nature of the LPAE format means that data->pg_shift is always
redundant with data->bits_per_level, since they represent the size of a
page and the number of PTEs per page respectively, and t
On Fri, Oct 25, 2019 at 07:08:36PM +0100, Robin Murphy wrote:
> Between VMSAv8-64 and the various 32-bit formats, there is either one
> 64-bit MAIR or a pair of 32-bit MAIR0/MAIR1 or NMRR/PMRR registers.
> As such, keeping two 64-bit values in io_pgtable_cfg has always been
> overkill.
>
> Signed-
On Fri, Oct 25, 2019 at 07:08:35PM +0100, Robin Murphy wrote:
> The nature of the LPAE format means that data->pg_shift is always
> redundant with data->bits_per_level, since they represent the size of a
> page and the number of PTEs per page respectively, and the size of a PTE
> is constant. Thus
On Mon 04 Nov 08:23 PST 2019, Will Deacon wrote:
> On Mon, Nov 04, 2019 at 03:15:06PM +, Will Deacon wrote:
> > On Sun, Nov 03, 2019 at 11:19:25PM -0600, Andy Gross wrote:
> > > On Fri, Nov 01, 2019 at 11:01:59PM +0530, Sai Prakash Ranjan wrote:
> > > > >>> What's the plan for getting this mer
When attaching two Broadcom RAID controllers to a server, the first one
reports the failure during booting (the disks connecting to the RAID
controller cannot be detected):
megaraid_sas :42:00.0: Init cmd return status FAILED for SCSI host 0
megaraid_sas :42:00.0: Failed from megasas_i
On Fri, Sep 20, 2019 at 01:34:27PM +0530, Sai Prakash Ranjan wrote:
> From: Vivek Gautam
>
> There are scnenarios where drivers are required to make a
> scm call in atomic context, such as in one of the qcom's
> arm-smmu-500 errata [1].
>
> [1] ("https://source.codeaurora.org/quic/la/kernel/msm-
On Fri, Sep 20, 2019 at 01:34:28PM +0530, Sai Prakash Ranjan wrote:
> From: Vivek Gautam
>
> Qcom's smmu-500 needs to toggle wait-for-safe sequence to
> handle TLB invalidation sync's.
> Few firmwares allow doing that through SCM interface.
> Add API to toggle wait for safe from firmware through
On Fri, Nov 01, 2019 at 11:01:59PM +0530, Sai Prakash Ranjan wrote:
> >>> What's the plan for getting this merged? I'm not happy taking the
> >>> firmware
> >>> bits without Andy's ack, but I also think the SMMU changes should go via
> >>> the IOMMU tree to avoid conflicts.
> >>>
> >>> Andy?
> >>>
On Mon, Nov 04, 2019 at 03:15:06PM +, Will Deacon wrote:
> On Sun, Nov 03, 2019 at 11:19:25PM -0600, Andy Gross wrote:
> > On Fri, Nov 01, 2019 at 11:01:59PM +0530, Sai Prakash Ranjan wrote:
> > > >>> What's the plan for getting this merged? I'm not happy taking the
> > > >>> firmware
> > > >>>
On Mon, Nov 04, 2019 at 03:01:01PM +0800, Yong Wu wrote:
> This patchset mainly fixes a tlb flush timeout issue and use the new
> iommu_gather to re-implement the tlb flush flow. and several clean up
> patches about the tlb_flush.
>
> change note:
>
> v5: No code change. Only update the commit me
On Sun, Nov 03, 2019 at 11:19:25PM -0600, Andy Gross wrote:
> On Fri, Nov 01, 2019 at 11:01:59PM +0530, Sai Prakash Ranjan wrote:
> > >>> What's the plan for getting this merged? I'm not happy taking the
> > >>> firmware
> > >>> bits without Andy's ack, but I also think the SMMU changes should go v
On 04/11/2019 12:16, John Garry wrote:
On 01/11/2019 21:13, Saravana Kannan wrote:
On Fri, Nov 1, 2019 at 3:28 AM John Garry wrote:
On 31/10/2019 23:34, Saravana Kannan via iommu wrote:
I looked into the iommu-map property and it shouldn't be too hard to
add support for it. Looks like we can
+
On 19/09/2019 15:35, John Garry wrote:
On 19/09/2019 14:25, Robin Murphy wrote:
When the port eventually probes it gets a new, separate group.
This all seems to be as the built-in module init ordering is as
follows: pcieport drv, smmu drv, mlx5 drv
I notice that if I build the mlx5 drv as a
On 01/11/2019 21:13, Saravana Kannan wrote:
On Fri, Nov 1, 2019 at 3:28 AM John Garry wrote:
On 31/10/2019 23:34, Saravana Kannan via iommu wrote:
I looked into the iommu-map property and it shouldn't be too hard to
add support for it. Looks like we can simply hold off on probing the
root bri
For mt6779, it need to support three mtk_iommu_domains, every
mtk_iommu_domain's iova space is different.
Three mtk_iommu_domains is as below:
1. Normal mtk_iommu_domain exclude 0x4000_~0x47ff_ and
0x7da0_~7fbf_.
2. CCU mtk_iommu_domain include 0x4000_~0x47ff_.
3. VPU mtk
Based on one mtk_iommu_domain, this patch supports multiple
mtk_iommu_domains to realize different iova regions.
Every module has one smi_larb port, so we can create different
mtk_iommu_domains by smi_larb port define. So we will add port_mask
variable to mtk_domain_data, if some modules need spec
Based on previous modifications in the patchset, A mtk_iommu_data
structure represent a iommu, we will add mtk_iommu_data to mtk_iommu_domain
to show the iommu which mtk_iommu_domain belongs to, so we can get
mtk_iommu_data by mtk_iommu_domain, don't use to "mtk_iommu_get_m4u_data"
any more.
Besid
All the devices which used iommu are connected to SMI_larb port,
so when different devices driver execute initialization, iommu
can check larb_id and port_id to distinguish them and then make
them match to iommu_group accordingly. We also add dom_cnt variable
to describe the number of mtk_iommu_dom
For multiple iommu_domains, we need to reserve some iova
regions, so we will add mtk_iommu_resv_iova_region structure.
It includes the start address and size of iova and iommu_resv_type.
Based on the function, we will realize multiple mtk_iommu_domains
Signed-off-by: Anan Sun
Signed-off-by: Chao
We already have global mtk_iommu_pgtable structure to describe
page table and create it in group_device, "mtk_iommu_domain_finalise"
is as the same as that, so so we will remove mtk_iommu_domain_finalise.
Signed-off-by: Chao Hao
---
drivers/iommu/mtk_iommu.c | 48
1. Redefine mtk_iommu_domain structure, it will include iommu_group
and iommu_domain. Different mtk_iommu_domains can be distinguished by
ID. When we realize multiple mtk_iommu_domains, every mtk_iommu_domain
can describe one iova region.
2. In theory, every device has one iommu_group, so this patc
Add mtk_domain_data structure to describe how many iova regions
there are and the relevant the start and end address of each
iova region. The number of iova region is equal to the number
of mtk_iommu_domain. So we will use mtk_domain_data to initialize
the start and end iova of mtk_iommu_domain.
S
This patch will use mtk_iommu_pgtable to replace the part
of pgtable in mtk_iommu_domain, so we can remove the information
of pgtable in mtk_iommu_domain.
Signed-off-by: Chao Hao
---
drivers/iommu/mtk_iommu.c | 37 +
1 file changed, 17 insertions(+), 20 deleti
This patch will remove the usage of the m4u_dom variable.
We have already redefined mtk_iommu_domain structure and it
includes iommu_domain, so m4u_dom variable will not be used.
Signed-off-by: Chao Hao
---
drivers/iommu/mtk_iommu.c | 27 ---
1 file changed, 20 insertion
Start with this patch, we will change the SW architecture
to support multiple domains. SW architecture will has a big change,
so we need to modify a little bit by more than one patch.
The new SW overall architecture is as below:
iommu0 iommu1
1. Add mt6779 registers define for iommu.
2. Add mt6779_data define to support mt6779 iommu HW init.
3. There are two iommus, one is mm_iommu, the other is vpu_iommu.
MM_IOMMU is connected smi_larb to support multimedia engine to
access DRAM, and VPU_IOMMU is connected to APU_bus to support
VPU,MDL
I am sorry that previous patchset(2019/10/28) has a problem with e-mail format,
some websites don't recevied it,
so please based on this patchset to review, thanks!
This patchset adds mt6779 iommu support and adjusts mtk iommu software
architecture mainly.
1. Add mt6779 basic function, such as s
This patch adds description for MT6779 IOMMU.
MT6779 has two iommus, they are MM_IOMMU and APU_IOMMU which
use ARM Short-Descriptor translation format.
The MT6779 IOMMU hardware diagram is as below, it is only a brief
diagram about iommu, it don't focus on the part of smi_larb, so
I don't describ
On Fri, Nov 01, 2019 at 02:26:05PM -0700, Saravana Kannan wrote:
> On Fri, Nov 1, 2019 at 5:28 AM Lorenzo Pieralisi
> wrote:
> >
> > On Fri, Nov 01, 2019 at 12:41:48PM +0100, Jean-Philippe Brucker wrote:
> >
> > [...]
> >
> > > > > I'm also wondering about ACPI support.
> > > >
> > > > I'd love to
44 matches
Mail list logo
