On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
> Introduce the new compatible string, restricted-dma-pool, for restricted
> DMA. One can specify the address and length of the restricted DMA memory
> region by restricted-dma-pool in the device tree.
If this goes into DT, I think we
On Fri, Jan 15, 2021 at 02:08:14PM +0100, Ricardo Ribalda wrote:
> > > Did you have time to look into this?
> > >
> > > No hurry, I just want to make sure that I didn't miss anything ;)
> >
> > Haven't managed to get to it, sorry.
>
> No worries!, is there something we can do to help you with
On 2021-01-20 16:53, Rob Herring wrote:
On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the device
On Tue, Jan 19, 2021 at 12:27:59PM +, Jonathan Cameron wrote:
> On Fri, 8 Jan 2021 15:52:13 +0100
> Jean-Philippe Brucker wrote:
>
> > The IOPF (I/O Page Fault) feature is now enabled independently from the
> > SVA feature, because some IOPF implementations are device-specific and
> > do not
On Tue, Jan 19, 2021 at 11:11:44AM +, Jonathan Cameron wrote:
> On Fri, 8 Jan 2021 15:52:09 +0100
> Jean-Philippe Brucker wrote:
>
> > Commit 986d5ecc5699 ("iommu: Move fwspec->iommu_priv to struct
> > dev_iommu") removed iommu_priv from fwspec. Update the struct doc.
> >
> > Signed-off-by:
On 2021-01-20 14:14, Leizhen (ThunderTown) wrote:
On 2021/1/20 21:27, Robin Murphy wrote:
On 2021-01-20 09:26, Leizhen (ThunderTown) wrote:
On 2021/1/20 11:37, Leizhen (ThunderTown) wrote:
On 2021/1/19 20:32, Robin Murphy wrote:
On 2021-01-19 01:59, Zhen Lei wrote:
Some SMMUv3
On Wed, 2021-01-20 at 13:06 +0100, Greg KH wrote:
> On Wed, Jan 20, 2021 at 09:42:43AM +, David Woodhouse wrote:
> > On Thu, 2020-09-24 at 15:08 +0100, David Woodhouse wrote:
> > > From: David Woodhouse
> > >
> > > Instead of bailing out completely, such a unit can still be used for
> > >
On Wed, Jan 20, 2021 at 03:55:05PM +, David Woodhouse wrote:
> On Wed, 2021-01-20 at 13:06 +0100, Greg KH wrote:
> > On Wed, Jan 20, 2021 at 09:42:43AM +, David Woodhouse wrote:
> > > On Thu, 2020-09-24 at 15:08 +0100, David Woodhouse wrote:
> > > > From: David Woodhouse
> > > >
> > > >
On Tue, Jan 19, 2021 at 01:38:19PM +, Jonathan Cameron wrote:
> On Fri, 8 Jan 2021 15:52:14 +0100
> Jean-Philippe Brucker wrote:
>
> > Some systems allow devices to handle I/O Page Faults in the core mm. For
> > example systems implementing the PCIe PRI extension or Arm SMMU stall
> > model.
On Tue, Jan 19, 2021 at 05:28:21PM +, Robin Murphy wrote:
> On 2021-01-08 14:52, Jean-Philippe Brucker wrote:
> > +#define EVTQ_1_PRIV(1UL << 33)
> > +#define EVTQ_1_EXEC(1UL << 34)
> > +#define EVTQ_1_READ(1UL << 35)
>
>
On 1/8/2021 7:52 AM, Jean-Philippe Brucker wrote:
The IOPF (I/O Page Fault) feature is now enabled independently from the
SVA feature, because some IOPF implementations are device-specific and
do not require IOMMU support for PCIe PRI or Arm SMMU stall.
Enable IOPF unconditionally when
On Wed, Jan 20, 2021 at 11:30 AM Robin Murphy wrote:
>
> On 2021-01-20 16:53, Rob Herring wrote:
> > On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
> >> Introduce the new compatible string, restricted-dma-pool, for restricted
> >> DMA. One can specify the address and length of the
> On Jan 19, 2021, at 9:11 PM, Lu Baolu wrote:
>
> On 1/19/21 10:37 PM, Chuck Lever wrote:
>>> On Jan 18, 2021, at 8:22 PM, Lu Baolu wrote:
>>>
>>> Do you mind posting the cap and ecap of the iommu used by your device?
>>>
>>> You can get it via sysfs, for example:
>>>
>>>
On Wed, 2021-01-20 at 18:04 +0100, Greg KH wrote:
> I tried applying these to 5.4, 4.19, and 4.14, and they all fail to
> build:
>
> drivers/iommu/dmar.c: In function ‘free_iommu’:
> drivers/iommu/dmar.c:1140:35: error: ‘struct intel_iommu’ has no member named
> ‘drhd’
> 1140 | if
On Wed, 20 Jan 2021 at 20:29, Robin Murphy wrote:
>
> On 2021-01-20 11:40, Chunyan Zhang wrote:
> [...]
> >>> + pgt_base_iova = dom->pgt_va +
> >>> + ((iova - mdata->iova_start) >> SPRD_IOMMU_PAGE_SHIFT);
> >>> +
> >>> + spin_lock_irqsave(>pgtlock, flags);
> >>> + for (i =
In this file, we have 2 drivers, smi-common and smi-larb.
Use platform_register_drivers.
Signed-off-by: Yong Wu
---
drivers/memory/mtk-smi.c | 25 ++---
1 file changed, 6 insertions(+), 19 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index
This patch switches MTK_SMI to tristate. Support it could be 'm'.
Meanwhile, Fix a build issue while MTK_SMI is built as module.
Signed-off-by: Yong Wu
---
This patch has a little conflict with the mt8192 iommu patch which
delete the MTK_LARB_NR_MAX in smi.h(It's still reviewing).
This patch
This patchset mainly support MTK_SMI could be modular. No other function add.
The MTK_IOMMU config will be another patchset.
rebase on v5.11-rc1.
Yong Wu (3):
memory: mtk-smi: Use platform_register_drivers
memory: mtk-smi: Add module_exit and module_license
memory: mtk-smi: Switch MTK_SMI
The config MTK_SMI always depends on MTK_IOMMU which is built-in
currently. Thus we don't have module_exit before. This patch adds
module_exit and module_license. It is a preparing patch for supporting
MTK_SMI could been built as a module.
Signed-off-by: Yong Wu
---
drivers/memory/mtk-smi.c |
On Wed, 13 Jan 2021 at 21:47, Rob Herring wrote:
>
> On Fri, Jan 8, 2021 at 5:34 AM Chunyan Zhang wrote:
> >
> > On Fri, 8 Jan 2021 at 10:25, Rob Herring wrote:
> > >
> > > On Wed, Dec 23, 2020 at 07:16:32PM +0800, Chunyan Zhang wrote:
> > > > From: Chunyan Zhang
> > > >
> > > > This patch
On 2021-01-20 21:31, Rob Herring wrote:
On Wed, Jan 20, 2021 at 11:30 AM Robin Murphy wrote:
On 2021-01-20 16:53, Rob Herring wrote:
On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify
Add compatible for the ARM SMMU found in the Qualcomm SC8180x platform.
Signed-off-by: Bjorn Andersson
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
The primary SMMU found in Qualcomm SC8180X platform needs to use the
Qualcomm implementation, so add a specific compatible for this.
Signed-off-by: Bjorn Andersson
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
On 2021/1/20 23:02, Robin Murphy wrote:
> On 2021-01-19 01:59, Zhen Lei wrote:
>> This reverts commit 52f3fab0067d6fa9e99c1b7f63265dd48ca76046.
>>
>> This problem has been fixed by another patch. The original method had side
>> effects, it was not mapped to the user-specified resource size. The
So that the uses could get chances to know what happened.
Suggested-by: Ashok Raj
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/svm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index
This includes some misc tweaks in the VT-d SVA implementation. I will
plan them for v5.12 if no objections.
Best regards,
baolu
Lu Baolu (3):
iommu/vt-d: Add rate limited information when PRQ overflows
iommu/vt-d: Allow devices to have more than 32 outstanding PRQ
iommu/vt-d: Use INVALID
The VT-d IOMMU response RESPONSE_FAILURE for a page request in below
cases:
- When it gets a Page_Request with no PASID;
- When it gets a Page_Request with PASID that is not in use for this
device.
This is allowed by the spec, but IOMMU driver doesn't support such cases
today. When the device
The minimum per-IOMMU PRQ queue size is one 4K page, this is more entries
than the hardcoded limit of 32 in the current VT-d code. Some devices can
support up to 512 outstanding PRQs but underutilized by this limit of 32.
Although, 32 gives some rough fairness when multiple devices share the same
On 2021/1/20 23:54, Robin Murphy wrote:
> On 2021-01-20 14:14, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2021/1/20 21:27, Robin Murphy wrote:
>>> On 2021-01-20 09:26, Leizhen (ThunderTown) wrote:
On 2021/1/20 11:37, Leizhen (ThunderTown) wrote:
>
>
> On 2021/1/19 20:32,
On 2021-01-19 01:59, Zhen Lei wrote:
This reverts commit 52f3fab0067d6fa9e99c1b7f63265dd48ca76046.
This problem has been fixed by another patch. The original method had side
effects, it was not mapped to the user-specified resource size. The code
will become more complex when ECMDQ is supported
On Thu, 2020-09-24 at 15:08 +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> Instead of bailing out completely, such a unit can still be used for
> interrupt remapping.
>
> Signed-off-by: David Woodhouse
Could we have this for stable too please, along with the trivial
subsequent
> -Original Message-
> From: Lu Baolu
> Sent: Wednesday, January 20, 2021 10:35 AM
> To: Zhang, Tina
> Cc: baolu...@linux.intel.com; iommu@lists.linux-foundation.org; Joerg
> Roedel ; Mehta, Sohil ; Jacob
> Pan ; Sun, Yi
> Subject: Re: [PATCH] iommu/vt-d: debugfs: Check
On 2021/1/20 11:37, Leizhen (ThunderTown) wrote:
>
>
> On 2021/1/19 20:32, Robin Murphy wrote:
>> On 2021-01-19 01:59, Zhen Lei wrote:
>>> Some SMMUv3 implementation embed the Perf Monitor Group Registers (PMCG)
>>> inside the first 64kB region of the SMMU. Since SMMU and PMCG are managed
>>>
Hi Robin,
On Wed, 13 Jan 2021 at 03:10, Robin Murphy wrote:
>
> On 2021-01-08 11:38, Chunyan Zhang wrote:
> > From: Chunyan Zhang
> >
> > This patch only adds display iommu support, the driver was tested with sprd
> > dpu.
> >
> > The iommu support for others would be added once finished tests
On 2021-01-20 11:40, Chunyan Zhang wrote:
[...]
+ pgt_base_iova = dom->pgt_va +
+ ((iova - mdata->iova_start) >> SPRD_IOMMU_PAGE_SHIFT);
+
+ spin_lock_irqsave(>pgtlock, flags);
+ for (i = 0; i < page_num; i++) {
+ pgt_base_iova[i] = pabase >>
I will send out v2 of this patch. Please ignore this v1.
Thanks,
Suravee
On 1/18/21 12:19 PM, Suravee Suthikulpanit wrote:
IOMMU Extended Feature Register (EFR) is used to communicate
the supported features for each IOMMU to the IOMMU driver.
This is normally read from the PCI MMIO register
On 2021/1/20 16:41, Zhang, Tina wrote:
-Original Message-
From: Lu Baolu
Sent: Wednesday, January 20, 2021 10:35 AM
To: Zhang, Tina
Cc: baolu...@linux.intel.com; iommu@lists.linux-foundation.org; Joerg
Roedel ; Mehta, Sohil ; Jacob
Pan ; Sun, Yi
Subject: Re: [PATCH] iommu/vt-d:
Just like MSI/MSI-X, IO-APIC interrupts are remapped by Microsoft
Hypervisor when Linux runs as the root partition. Implement an IRQ
domain to handle mapping and unmapping of IO-APIC interrupts.
Signed-off-by: Wei Liu
---
arch/x86/hyperv/irqdomain.c | 54 ++
The IOMMU code needs more work. We're sure for now the IRQ remapping
hooks are not applicable when Linux is the root partition.
Signed-off-by: Wei Liu
Acked-by: Joerg Roedel
Reviewed-by: Vitaly Kuznetsov
---
drivers/iommu/hyperv-iommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
> -Original Message-
> From: Lu Baolu
> Sent: Wednesday, January 20, 2021 7:37 PM
> To: Zhang, Tina
> Cc: baolu...@linux.intel.com; iommu@lists.linux-foundation.org; Joerg
> Roedel ; Mehta, Sohil ; Jacob
> Pan ; Sun, Yi
> Subject: Re: [PATCH] iommu/vt-d: debugfs: Check
On Wed, Jan 20, 2021 at 09:42:43AM +, David Woodhouse wrote:
> On Thu, 2020-09-24 at 15:08 +0100, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > Instead of bailing out completely, such a unit can still be used for
> > interrupt remapping.
> >
> > Signed-off-by: David Woodhouse
>
On 2021/1/20 21:27, Robin Murphy wrote:
> On 2021-01-20 09:26, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2021/1/20 11:37, Leizhen (ThunderTown) wrote:
>>>
>>>
>>> On 2021/1/19 20:32, Robin Murphy wrote:
On 2021-01-19 01:59, Zhen Lei wrote:
> Some SMMUv3 implementation embed the Perf
On 2021-01-20 09:26, Leizhen (ThunderTown) wrote:
On 2021/1/20 11:37, Leizhen (ThunderTown) wrote:
On 2021/1/19 20:32, Robin Murphy wrote:
On 2021-01-19 01:59, Zhen Lei wrote:
Some SMMUv3 implementation embed the Perf Monitor Group Registers (PMCG)
inside the first 64kB region of the
IOMMU Extended Feature Register (EFR) is used to communicate
the supported features for each IOMMU to the IOMMU driver.
This is normally read from the PCI MMIO register offset 0x30,
and used by the iommu_feature() helper function.
However, there are certain scenarios where the information is
44 matches
Mail list logo
