> -Original Message-
> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> Sent: 13 May 2022 10:50
> To: Robin Murphy ; Shameerali Kolothum Thodi
> ; raf...@kernel.org;
> j...@8bytes.org
> Cc: Shameerali Kolothum Thodi ;
> Guohanjun (Hanjun Guo) ;
> linux-arm-ker...@lists.infrade
On 2022/5/16 22:03, Jonathan Cameron wrote:
> On Mon, 16 May 2022 20:52:17 +0800
> Yicong Yang wrote:
>
>> HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex integrated
>> Endpoint(RCiEP) device, providing the capability to dynamically monitor and
>> tune the PCIe traffic and trace
On 2022/5/17 0:23, John Garry wrote:
> On 16/05/2022 13:52, Yicong Yang wrote:
>> HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex integrated
>> Endpoint(RCiEP) device, providing the capability to dynamically monitor and
>> tune the PCIe traffic and trace the TLP headers.
>>
>> Add
On 17/05/2022 09:09, Yicong Yang wrote:
+ target = cpumask_any(cpumask_of_node(dev_to_node(&hisi_ptt->pdev->dev)));
+ if (target < nr_cpumask_bits) {
the comment for cpumask_any() hints to check against nr_cpu_ids - any specific
reason to check against nr_cpumask_bits?
here should be:
On Fri, May 13, 2022 at 05:39:48PM +0200, Niklas Schnelle wrote:
> In __iommu_dma_alloc_noncontiguous() the value returned by
> iommu_map_sg_atomic() is checked for being smaller than size. Before
> commit ad8f36e4b6b1 ("iommu: return full error code from
> iommu_map_sg[_atomic]()") this simply che
On Mon, May 16, 2022 at 09:06:01PM +0800, John Garry wrote:
> For streaming DMA mappings involving an IOMMU and whose IOVA len regularly
> exceeds the IOVA rcache upper limit (meaning that they are not cached),
> performance can be reduced.
>
> Add the IOMMU callback for DMA mapping API dma_max_ma
On 17/05/2022 09:38, Christoph Hellwig wrote:
On Mon, May 16, 2022 at 09:06:01PM +0800, John Garry wrote:
For streaming DMA mappings involving an IOMMU and whose IOVA len regularly
exceeds the IOVA rcache upper limit (meaning that they are not cached),
performance can be reduced.
Add the IOMMU
On Fri, 2022-05-13 at 17:14 +0200, AngeloGioacchino Del Regno wrote:
> Add support for the M4Us found in the MT6795 Helio X10 SoC.
>
> Signed-off-by: AngeloGioacchino Del Regno <
> angelogioacchino.delre...@collabora.com>
> ---
> drivers/iommu/mtk_iommu.c | 20 +++-
> 1 file chang
On Tue, May 17, 2022 at 10:02:00AM +0100, John Garry wrote:
> BTW, on a separate topic, I noticed that even with this change my ATA
> devices have max_hw_sectors_kb of 32767, as opposed to 128 for SAS devices.
> It seems that libata-scsi - specifically ata_scsi_dev_config() - doesn't
> honour th
On 2022/5/17 16:21, John Garry wrote:
> On 17/05/2022 09:09, Yicong Yang wrote:
+ target =
cpumask_any(cpumask_of_node(dev_to_node(&hisi_ptt->pdev->dev)));
+ if (target < nr_cpumask_bits) {
>>> the comment for cpumask_any() hints to check against nr_cpu_ids - any
>>> specific
Thanks,
applied to the dma-mapping for-next tree.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Il 17/05/22 11:08, Yong Wu ha scritto:
On Fri, 2022-05-13 at 17:14 +0200, AngeloGioacchino Del Regno wrote:
Add support for the M4Us found in the MT6795 Helio X10 SoC.
Signed-off-by: AngeloGioacchino Del Regno <
angelogioacchino.delre...@collabora.com>
---
drivers/iommu/mtk_iommu.c | 20 +
On 17/05/2022 11:26, AngeloGioacchino Del Regno wrote:
Il 17/05/22 11:08, Yong Wu ha scritto:
On Fri, 2022-05-13 at 17:14 +0200, AngeloGioacchino Del Regno wrote:
Add support for the M4Us found in the MT6795 Helio X10 SoC.
Signed-off-by: AngeloGioacchino Del Regno <
angelogioacchino.delre...
On Tue, 2022-05-17 at 10:36 +0200, Christoph Hellwig wrote:
> On Fri, May 13, 2022 at 05:39:48PM +0200, Niklas Schnelle wrote:
> > In __iommu_dma_alloc_noncontiguous() the value returned by
> > iommu_map_sg_atomic() is checked for being smaller than size. Before
> > commit ad8f36e4b6b1 ("iommu: ret
On 2022-05-17 11:17, Niklas Schnelle wrote:
On Tue, 2022-05-17 at 10:36 +0200, Christoph Hellwig wrote:
On Fri, May 13, 2022 at 05:39:48PM +0200, Niklas Schnelle wrote:
In __iommu_dma_alloc_noncontiguous() the value returned by
iommu_map_sg_atomic() is checked for being smaller than size. Befor
In __iommu_dma_alloc_noncontiguous() the return value of
iommu_map_sg_atomic() is treated as an error if it is smaller than size.
Before upstream commit ad8f36e4b6b1 ("iommu: return full error code from
iommu_map_sg[_atomic]()") this simply checked if the requested size was
successfully mapped.
Af
On Tue, 2022-05-17 at 11:18 +0100, Robin Murphy wrote:
> On 2022-05-17 11:17, Niklas Schnelle wrote:
> > On Tue, 2022-05-17 at 10:36 +0200, Christoph Hellwig wrote:
> > > On Fri, May 13, 2022 at 05:39:48PM +0200, Niklas Schnelle wrote:
> > > > In __iommu_dma_alloc_noncontiguous() the value returned
On 2022-05-16 14:06, John Garry wrote:
For streaming DMA mappings involving an IOMMU and whose IOVA len regularly
exceeds the IOVA rcache upper limit (meaning that they are not cached),
performance can be reduced.
Add the IOMMU callback for DMA mapping API dma_max_mapping_size(), which
allows th
Il 16/05/22 18:03, Rob Herring ha scritto:
On Fri, 13 May 2022 17:14:10 +0200, AngeloGioacchino Del Regno wrote:
Add bindings for the MediaTek Helio X10 (MT6795) IOMMU/M4U.
Signed-off-by: AngeloGioacchino Del Regno
---
.../bindings/iommu/mediatek,iommu.yaml| 3 +
include/dt-bindin
On Tue, May 17, 2022 at 10:05:43AM +0800, Baolu Lu wrote:
> Hi Jason,
>
> On 2022/5/17 02:06, Jason Gunthorpe wrote:
> > > +static __init int tboot_force_iommu(void)
> > > +{
> > > + if (!tboot_enabled())
> > > + return 0;
> > > +
> > > + if (no_iommu || dmar_disabled)
> > > + pr_w
Hi,
Can you please send the original scenario, setup details and dumps ?
I can't find it in my mailbox.
you can send it directly to me to avoid spam.
-Max.
On 5/17/2022 11:26 AM, Mark Ruijter wrote:
Hi Robin,
I ran into the exact same problem while testing with 4 connect-x6 cards, kernel
5
On 17/05/2022 11:40, Robin Murphy wrote:
On 2022-05-16 14:06, John Garry wrote:
For streaming DMA mappings involving an IOMMU and whose IOVA len
regularly
exceeds the IOVA rcache upper limit (meaning that they are not cached),
performance can be reduced.
Add the IOMMU callback for DMA mapping
On 2022-05-17 12:26, John Garry wrote:
On 17/05/2022 11:40, Robin Murphy wrote:
On 2022-05-16 14:06, John Garry wrote:
For streaming DMA mappings involving an IOMMU and whose IOVA len
regularly
exceeds the IOVA rcache upper limit (meaning that they are not cached),
performance can be reduced.
On 2022-05-17 03:37, Baolu Lu wrote:
Hi Jason,
On 2022/5/16 21:57, Jason Gunthorpe wrote:
On Mon, May 16, 2022 at 12:22:08PM +0100, Robin Murphy wrote:
On 2022-05-16 02:57, Lu Baolu wrote:
Each IOMMU driver must provide a blocking domain ops. If the hardware
supports detaching domain from dev
On Tue, May 17, 2022 at 10:37:55AM +0800, Baolu Lu wrote:
> Hi Jason,
>
> On 2022/5/16 21:57, Jason Gunthorpe wrote:
> > On Mon, May 16, 2022 at 12:22:08PM +0100, Robin Murphy wrote:
> > > On 2022-05-16 02:57, Lu Baolu wrote:
> > > > Each IOMMU driver must provide a blocking domain ops. If the har
On Tue, May 17, 2022 at 01:43:03PM +0100, Robin Murphy wrote:
> FWIW from my point of view I'm happy with having a .detach_dev_pasid op
> meaning implicitly-blocked access for now.
If this is the path then lets not call it attach/detach
please. 'set_dev_pasid' and 'set_dev_blocking_pasid' are cl
Add property "mediatek,pericfg" to let the mtk_iommu driver retrieve
a phandle to the pericfg syscon instead of performing a per-soc
compatible lookup, as it was also done with infracfg.
Signed-off-by: AngeloGioacchino Del Regno
---
Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml |
Both MT2712 and MT8173 got a mediatek,infracfg phandle: add that to
the required properties for these SoCs to deprecate the old way of
looking for SoC-specific infracfg compatible in the entire devicetree.
Signed-off-by: AngeloGioacchino Del Regno
---
.../devicetree/bindings/iommu/mediatek,iomm
This driver will get support for more SoCs and the list of infracfg
compatibles is expected to grow: in order to prevent getting this
situation out of control and see a long list of compatible strings,
add support to retrieve a handle to infracfg's regmap through a
new "mediatek,infracfg" phandle.
The IOMMU driver now looks for the "mediatek,infracfg" phandle as a
new way to retrieve a syscon to that:
even though the old way is retained, it has been deprecated and the
driver will write a message in kmsg advertising to use the phandle
way instead.
For this reason, assign the right phandle to
Add property "mediatek,infracfg" to let the mtk_iommu driver retrieve
a phandle to the infracfg syscon instead of performing a per-soc
compatible lookup.
Signed-off-by: AngeloGioacchino Del Regno
---
Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml | 4
1 file changed, 4 inserti
On some SoCs (of which only MT8195 is supported at the time of writing),
the "R" and "W" (I/O) enable bits for the IOMMUs are in the pericfg_ao
register space and not in the IOMMU space: as it happened already with
infracfg, it is expected that this list will grow.
Instead of specifying pericfg co
The IOMMU driver now looks for the "mediatek,infracfg" phandle as a
new way to retrieve a syscon to that:
even though the old way is retained, it has been deprecated and the
driver will write a message in kmsg advertising to use the phandle
way instead.
For this reason, assign the right phandle to
The MT8195 SoC has IOMMU related registers in the pericfg_ao iospace:
require a phandle to that.
Signed-off-by: AngeloGioacchino Del Regno
---
Note for Rob: as of now, there's no iommu node in upstream mt8195 devicetrees
yet.
.../devicetree/bindings/iommu/mediatek,iommu.yaml | 10 ++
The IOMMU has registers in the infracfg and/or pericfg iospaces: as
for the currently supported SoCs, MT2712 and MT8173 need a phandle to
infracfg, while MT8195 needs one to pericfg.
Before this change, the driver was checking for a SoC-specific infra/peri
compatible but, sooner or later, these li
On 17/05/2022 13:02, Robin Murphy wrote:
Indeed, sorry but NAK for this being nonsense. As I've said at least
once before, if the unnecessary SAC address allocation attempt slows
down your workload, make it not do that in the first place. If you
don't like the existing command-line parameter
On 2022-05-17 14:21, AngeloGioacchino Del Regno wrote:
This driver will get support for more SoCs and the list of infracfg
compatibles is expected to grow: in order to prevent getting this
situation out of control and see a long list of compatible strings,
add support to retrieve a handle to infr
On 17/05/2022 15:21, AngeloGioacchino Del Regno wrote:
> Add property "mediatek,infracfg" to let the mtk_iommu driver retrieve
> a phandle to the infracfg syscon instead of performing a per-soc
> compatible lookup.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
> ---
> Documentation/devicetree
On 17/05/2022 15:21, AngeloGioacchino Del Regno wrote:
> Add property "mediatek,pericfg" to let the mtk_iommu driver retrieve
> a phandle to the pericfg syscon instead of performing a per-soc
> compatible lookup, as it was also done with infracfg.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
Hi Robin,
I ran into the exact same problem while testing with 4 connect-x6 cards, kernel
5.18-rc6.
[ 4878.273016] nvme nvme0: Successfully reconnected (3 attempts)
[ 4879.122015] nvme nvme0: starting error recovery
[ 4879.122028] infiniband mlx5_4: mlx5_handle_error_cqe:332:(pid 0): WC error:
On Mon, May 09, 2022 at 03:59:40PM +0200, Thomas Gleixner wrote:
> On Thu, May 05 2022 at 17:00, Ricardo Neri wrote:
> > Add a NMI_WATCHDOG as a new category of NMI handler. This new category
> > is to be used with the HPET-based hardlockup detector. This detector
> > does not have a direct way of
On Tue, 10 May 2022 13:55:24 -0300
Jason Gunthorpe wrote:
> This control causes the ARM SMMU drivers to choose a stage 2
> implementation for the IO pagetable (vs the stage 1 usual default),
> however this choice has no visible impact to the VFIO user. Further qemu
> never implemented this and no
On Tue, May 10, 2022 at 09:16:21PM +1000, Nicholas Piggin wrote:
> Excerpts from Ricardo Neri's message of May 6, 2022 10:00 am:
> > The HPET hardlockup detector relies on tsc_khz to estimate the value of
> > that the TSC will have when its HPET channel fires. A refined tsc_khz
> > helps to estimat
On Tue, May 10, 2022 at 01:44:05PM +0200, Thomas Gleixner wrote:
> On Tue, May 10 2022 at 21:16, Nicholas Piggin wrote:
> > Excerpts from Ricardo Neri's message of May 6, 2022 10:00 am:
> >> + /*
> >> + * If in use, the HPET hardlockup detector relies on tsc_khz.
> >> + * Reconfigure it to mak
On Sat, May 14, 2022 at 10:17:38AM +0200, Thomas Gleixner wrote:
> On Fri, May 13 2022 at 14:19, Ricardo Neri wrote:
> > On Fri, May 06, 2022 at 11:41:13PM +0200, Thomas Gleixner wrote:
> >> The argument about not bloating the code
> >> with an "obvious???" function which is quite small is slightly
On Tue, 2022-05-17 at 11:26 +0200, AngeloGioacchino Del Regno wrote:
> Il 17/05/22 11:08, Yong Wu ha scritto:
> > On Fri, 2022-05-13 at 17:14 +0200, AngeloGioacchino Del Regno
> > wrote:
> > > Add support for the M4Us found in the MT6795 Helio X10 SoC.
> > >
> > > Signed-off-by: AngeloGioacchino D
On Tue, May 17, 2022 at 03:21:06PM +0200, AngeloGioacchino Del Regno wrote:
> Both MT2712 and MT8173 got a mediatek,infracfg phandle: add that to
> the required properties for these SoCs to deprecate the old way of
> looking for SoC-specific infracfg compatible in the entire devicetree.
Wait, what
On Tue, 17 May 2022 15:21:07 +0200, AngeloGioacchino Del Regno wrote:
> The MT8195 SoC has IOMMU related registers in the pericfg_ao iospace:
> require a phandle to that.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
> ---
>
> Note for Rob: as of now, there's no iommu node in upstream mt8195
On 2022/5/17 21:13, Jason Gunthorpe wrote:
On Tue, May 17, 2022 at 01:43:03PM +0100, Robin Murphy wrote:
FWIW from my point of view I'm happy with having a .detach_dev_pasid op
meaning implicitly-blocked access for now.
If this is the path then lets not call it attach/detach
please. 'set_dev_
49 matches
Mail list logo
