On 2021-03-19 14:35, Daniel Lezcano wrote:
Hi Robin,
On 19/03/2021 13:17, Robin Murphy wrote:
On 2021-03-19 11:05, Daniel Lezcano wrote:
The DTPM framework is looking for upstream SoC candidates to share the
power numbers.
We can see around different numbers but the one which seems to be
On 2021-03-19 16:58, John Garry wrote:
On 19/03/2021 16:13, Robin Murphy wrote:
On 2021-03-19 13:25, John Garry wrote:
Move the IOVA size power-of-2 rcache roundup into the IOVA allocator.
This is to eventually make it possible to be able to configure the upper
limit of the IOVA rcache range
On 2021-03-22 18:46, Marc Zyngier wrote:
The new 'no_msi' attribute solves the problem of advertising the lack
of MSI capability for host bridges that know for sure that there will
be no MSI for their end-points.
However, there is a whole class of host bridges that cannot know
whether MSIs will
On 2021-03-23 07:34, Yang Yingliang wrote:
When copy over 128 bytes, src/dst is added after
each ldp/stp instruction, it will cost more time.
To improve this, we only add src/dst after load
or store 64 bytes.
This breaks the required behaviour for copy_*_user(), since the fault
handler expects
On 2021-03-01 12:12, John Garry wrote:
Like the intel IOMMU driver already does, flush the per-IOVA domain
CPU rcache when a CPU goes offline - there's no point in keeping it.
Thanks John!
Reviewed-by: Robin Murphy
Signed-off-by: John Garry
---
drivers/iommu/iova.c
On 2021-03-01 12:12, John Garry wrote:
Function free_cpu_cached_iovas() is not only called when a CPU is
hotplugged, so remove that part of the code comment.
FWIW I read it as clarifying why this is broken out into a separate
function vs. a monolithic "free all cached IOVAs" routine that handl
On 2021-03-23 13:32, Will Deacon wrote:
On Tue, Mar 23, 2021 at 12:08:56PM +, Robin Murphy wrote:
On 2021-03-23 07:34, Yang Yingliang wrote:
When copy over 128 bytes, src/dst is added after
each ldp/stp instruction, it will cost more time.
To improve this, we only add src/dst after load
or
On 2021-03-23 18:09, Marc Zyngier wrote:
Hi Robin,
On Tue, 23 Mar 2021 11:45:02 +,
Robin Murphy wrote:
On 2021-03-22 18:46, Marc Zyngier wrote:
The new 'no_msi' attribute solves the problem of advertising the lack
of MSI capability for host bridges that know for sure that the
On 2021-03-04 08:43, Pavel Machek wrote:
Hi!
[ Upstream commit d8c1df02ac7f2c802a9b2afc0f5c888c4217f1d5 ]
In the end of __iommu_map, It alway call iotlb_sync_map.
This patch moves iotlb_sync_map out from __iommu_map since it is
unnecessary to call this for each sg segment especially iotlb_syn
he sake of fixing the inadvertent breakage of the Intel-specific
parameter, remove the dmar_forcedac remnants and hook it up as an alias
while documenting the transition to the new common parameter.
Fixes: c588072bba6b ("iommu/vt-d: Convert intel iommu driver to the iommu ops")
Signed-
wasted walking through the whole populated upper range
just to reach the initial limit. We can improve on that by implementing
a proper tree traversal to find the first node above the relevant limit,
and set the exact start point.
Signed-off-by: Robin Murphy
---
drivers/iommu/iova.c | 39
Repeating the rb_entry() boilerplate all over the place gets old fast.
Before adding yet more instances, add a little hepler to tidy it up.
Signed-off-by: Robin Murphy
---
drivers/iommu/iova.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers
On 2021-03-29 00:53, Bhaskar Chowdhury wrote:
s/Synopsys/Synopsis/ .two different places.
Erm, that is definitely not a typo... :/
..and for some unknown reason it introduce a empty line deleted and added
back.
Presumably your editor is configured to trim trailing whitespace on save.
On 2021-03-22 15:01, John Garry wrote:
On 19/03/2021 19:20, Robin Murphy wrote:
Hi Robin,
So then we have the issue of how to dynamically increase this rcache
threshold. The problem is that we may have many devices associated with
the same domain. So, in theory, we can't assume that wh
On 2021-03-19 17:26, John Garry wrote:
[...]
@@ -25,7 +25,8 @@ struct iova {
struct iova_magazine;
struct iova_cpu_rcache;
-#define IOVA_RANGE_CACHE_MAX_SIZE 6 /* log of max cached IOVA
range size (in pages) */
+#define IOVA_RANGE_CACHE_DEFAULT_SIZE 6
+#define IOVA_RANGE_CACHE_MAX_SIZE 1
On 2021-03-13 13:22, CN_SZTL wrote:
Robin Murphy 于2021年3月13日周六 下午7:55写道：
On 2021-03-13 03:25, Tianling Shen wrote:
This adds support for the NanoPi R4S from FriendlyArm.
Rockchip RK3399 SoC
1GB DDR3 or 4GB LPDDR4 RAM
Gigabit Ethernet (WAN)
Gigabit Ethernet (PCIe) (LAN)
USB 3.0 Port x 2
On 2021-03-26 07:02, rentao.b...@gmail.com wrote:
From: Tao Ren
Set aspeed-usb vhub port_dev's dma mask to pass the dma_mask test in
"dma_map_page_attrs" function, and the dma_mask test was added in
'commit f959dcd6ddfd ("dma-direct: Fix potential NULL pointer
dereference")'.
Below is the back
On 2021-03-25 21:39, Paul Menzel wrote:
Dear Linux folks,
On the Marvell Prestera switch, Linux 5.10.4 prints the error (with an
additional info level message) below.
[ 0.00] Linux version 5.10.4 (robimarko@onlbuilder9)
(aarch64-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516, GN
On 2021-03-26 17:26, Mark Kettenis wrote:
From: Arnd Bergmann
Date: Fri, 26 Mar 2021 17:38:24 +0100
On Fri, Mar 26, 2021 at 5:10 PM Sven Peter wrote:
On Fri, Mar 26, 2021, at 16:59, Mark Kettenis wrote:
Some of the DARTs provide a bypass facility. That code make using the
standard "dma-rang
On 2021-04-09 14:39, David Hildenbrand wrote:
On 09.04.21 15:35, Arnd Bergmann wrote:
On Fri, Apr 9, 2021 at 1:21 PM David Hildenbrand
wrote:
Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n). Applicable drivers would like to use DMA_CMA,
which dep
Rather than have separate opaque setter functions that are easy to
overlook and lead to repetitive boilerplate in drivers, let's pass the
relevant initialisation parameters directly to iommu_device_register().
Acked-by: Will Deacon
Signed-off-by: Robin Murphy
---
v2: Add some kerneldoc a
dular - like the new sprd-iommu driver which now has a potential
bug in that regard - so let's just statically set the module owner and
let ops remain const wherever possible.
Reviewed-by: Christoph Hellwig
Acked-by: Will Deacon
Signed-off-by: Robin Murphy
---
drivers/iommu/arm/arm-smmu-v3/a
On 2021-04-01 10:39, Geert Uytterhoeven wrote:
Hi Steven,
On Wed, Mar 31, 2021 at 3:40 PM Steven Rostedt wrote:
On Wed, 31 Mar 2021 11:31:03 +0200
Geert Uytterhoeven wrote:
This reduces kernel size by ca. 0.5 KiB.
If you are worried about size, disable tracing and it will go away
entirely
On 2021-03-18 11:38, John Garry wrote:
On 10/03/2021 17:47, John Garry wrote:
On 09/03/2021 15:55, John Garry wrote:
On 05/03/2021 16:35, Robin Murphy wrote:
Hi Robin,
When restarting after searching below the cached node fails, resetting
the start point to the anchor node is often overly
On 2020-12-09 11:12, Christoph Hellwig wrote:
On Tue, Dec 08, 2020 at 01:54:00PM +0900, Tomasz Figa wrote:
>From the media perspective, it would be good to have the vmap
optional, similarly to the DMA_ATTR_NO_KERNEL_MAPPING attribute for
coherent allocations. Actually, in the media drivers, the
On 2020-11-24 15:38, Ricardo Ribalda wrote:
On architectures where the is no coherent caching such as ARM use the
dma_alloc_noncontiguos API and handle manually the cache flushing using
dma_sync_single().
With this patch on the affected architectures we can measure up to 20x
performance improvem
d the boilerplate that wouldn't end up making
things even more ugly and complicated, so:
Reviewed-by: Robin Murphy
Signed-off-by: Yong Wu
---
drivers/iommu/iommu.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/iommu.c b/dri
: Robin Murphy
Signed-off-by: Yong Wu
---
drivers/iommu/iommu.c | 6 +++---
drivers/iommu/tegra-gart.c | 3 ++-
include/linux/iommu.h | 3 ++-
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index decef851fa3a..df87c8e825f7
On 2020-11-19 06:18, Yong Wu wrote:
Add a granule_ignore option when tlb gather for some HW which don't care
about granule when it flush tlb.
Signed-off-by: Yong Wu
---
include/linux/iommu.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/iommu.h b/includ
On 2020-11-19 06:18, Yong Wu wrote:
MediaTek TLB flush don't care about granule. when unmap, it could gather
whole the iova range then do tlb flush once.
In current v7s, If unmap the lvl2 pagetable, the steps are:
step1: set this current pdg to 0.
step2: tlb flush for this lvl2 block iova(1M).
s
ess we need to make a decision up-front about which series should go
first. Other than that, though:
Reviewed-by: Robin Murphy
+}
+
static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
dma_addr_t iova)
{
@@ -540,6 +547,7 @@ static
On 2020-11-25 15:50, laurentiu.tu...@nxp.com wrote:
From: Laurentiu Tudor
Add a NXP specific hook to preserve SMMU mappings present at
boot time (created by the boot loader). These are needed for
MC firmware present on some NXP chips to continue working
across kernel boot and SMMU initializatio
On 2020-12-18 08:38, Isaac J. Manjarres wrote:
The io-pgtable-arm and io-pgtable-arm-v7s source files will
be compiled as separate modules, along with the io-pgtable
source. Export the symbols for the io-pgtable init function
structures for the io-pgtable module to use.
In my current build tree
On 2021-02-25 13:54, John Garry wrote:
On 29/01/2021 12:03, Robin Murphy wrote:
On 2021-01-29 09:48, Leizhen (ThunderTown) wrote:
Currently, we are thinking about the solution to the problem.
However, because the end time of v5.11 is approaching, this patch is
sent first.
However, that
On 2021-03-11 23:31, Logan Gunthorpe wrote:
Hi,
This is a rework of the first half of my RFC for doing P2PDMA in userspace
with O_DIRECT[1].
The largest issue with that series was the gross way of flagging P2PDMA
SGL segments. This RFC proposes a different approach, (suggested by
Dan Williams[2
On 2021-03-11 23:31, Logan Gunthorpe wrote:
When a PCI P2PDMA page is seen, set the IOVA length of the segment
to zero so that it is not mapped into the IOVA. Then, in finalise_sg(),
apply the appropriate bus address to the segment. The IOVA is not
created if the scatterlist only consists of P2PD
On 2021-03-11 23:31, Logan Gunthorpe wrote:
Add PCI P2PDMA support for dma_direct_map_sg() so that it can map
PCI P2PDMA pages directly without a hack in the callers. This allows
for heterogeneous SGLs that contain both P2PDMA and regular pages.
SGL segments that contain PCI bus addresses are ma
On 2021-03-12 16:18, Logan Gunthorpe wrote:
On 2021-03-12 8:51 a.m., Robin Murphy wrote:
On 2021-03-11 23:31, Logan Gunthorpe wrote:
Hi,
This is a rework of the first half of my RFC for doing P2PDMA in
userspace
with O_DIRECT[1].
The largest issue with that series was the gross way of
On 2021-03-12 16:24, Logan Gunthorpe wrote:
On 2021-03-12 8:52 a.m., Robin Murphy wrote:
+
sg->dma_address = dma_direct_map_page(dev, sg_page(sg),
sg->offset, sg->length, dir, attrs);
if (sg->dma_address == DMA_MAPPING_ERROR)
@@ -411,7 +
On 2021-03-12 17:03, Logan Gunthorpe wrote:
On 2021-03-12 8:52 a.m., Robin Murphy wrote:
On 2021-03-11 23:31, Logan Gunthorpe wrote:
When a PCI P2PDMA page is seen, set the IOVA length of the segment
to zero so that it is not mapped into the IOVA. Then, in finalise_sg(),
apply the
On 2021-03-13 03:25, Tianling Shen wrote:
This adds support for the NanoPi R4S from FriendlyArm.
Rockchip RK3399 SoC
1GB DDR3 or 4GB LPDDR4 RAM
Gigabit Ethernet (WAN)
Gigabit Ethernet (PCIe) (LAN)
USB 3.0 Port x 2
MicroSD slot
Reset button
WAN - LAN - SYS LED
[initial DTS file]
Co-developed-by:
, the commit adding the cast does specifically speak about
converting to __wsum, so I'm not sure what happened there... :/
Anyway, this seems to make sense.
Acked-by: Robin Murphy
Signed-off-by: Alex Elder
---
With this patch in place, quite a few "different base types" sparse
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(&dom->pgtlock, flags);
+ for (i = 0; i < page_num; i++) {
+ pgt_base_iova[i] = pabase >> SPRD_IOMMU_PA
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 SMMU
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 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 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 tree
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
On 2021-03-01 14:06, Frank Wunderlich wrote:
Gesendet: Montag, 01. März 2021 um 14:31 Uhr
Von: "Marc Zyngier"
Frank,
i guess it's a bug in ath10k driver or my r64 board (it is a v1.1
which has missing capacitors on tx lines).
No, this definitely looks like a bug in the MTK PCIe driver,
wher
On 2021-02-26 14:03, Nicolas Saenz Julienne wrote:
Some arm SMMU implementations might sit on a bus that doesn't support
64bit memory accesses. In that case default to using hi_lo_{readq,
writeq}() and BUG if such platform tries to use AArch64 formats as they
rely on writeq()'s atomicity.
Signed
On 2021-02-26 14:02, Nicolas Saenz Julienne wrote:
Some devices might inadvertently sit on buses that don't support 64bit
MMIO access, and need a mechanism to query these limitations without
prejudice to other buses in the system (i.e. defaulting to 32bit access
system wide isn't an option).
Int
On 2021-02-26 14:03, Nicolas Saenz Julienne wrote:
arm-smmu can now deal with integrations on buses that don't support
64bit MMIO accesses. No need to create a special case for that on
Marvell's integration.
This breaks compatibility with existing DTs.
Robin.
Signed-off-by: Nicolas Saenz Jul
On 2021-02-25 17:51, Jordan Crouse wrote:
Call report_iommu_fault() to allow upper-level drivers to register their
own fault handlers.
Signed-off-by: Jordan Crouse
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/
On 2021-03-05 17:41, John Garry wrote:
On 05/03/2021 16:32, Robin Murphy wrote:
In converting intel-iommu over to the common IOMMU DMA ops, it quietly
lost the functionality of its "forcedac" option. Since this is a handy
thing both for testing and for performance optimisation
On 2021-03-01 15:48, John Garry wrote:
On 01/03/2021 13:20, Robin Murphy wrote:
FWIW, I'm 99% sure that what you really want is [1], but then you get
to battle against an unknown quantity of dodgy firmware instead.
Something which has not been said before is that this only happens for
s
On 2021-01-21 02:04, Leizhen (ThunderTown) wrote:
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
On 2021-01-21 15:48, Rob Herring wrote:
On Wed, Jan 20, 2021 at 7:10 PM Robin Murphy
wrote:
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
On 2021-01-21 17:46, Will Deacon wrote:
On Thu, Jan 21, 2021 at 10:21:50PM +0530, Prathu Baronia wrote:
This patch removes the unnecessary kmap calls in the hugepage zeroing path and
improves the timing by 62%.
I had proposed a similar change in Apr-May'20 timeframe in memory.c where I
proposed
On 2021-01-21 19:16, Moritz Fischer wrote:
Address issue observed on real world system with suboptimal IORT table
where DMA masks of PCI devices would get set to 0 as result.
iort_dma_setup() would query the root complex' IORT entry for a DMA
mask, and use that over the one the device has been c
On 2021-01-21 11:23, Chunyan Zhang wrote:
From: Chunyan Zhang
This patch only adds display iommu support, the driver was tested with sprd
dpu and image codec processor.
The iommu support for others would be added once finished tests with those
devices, such as a few signal processors, includin
On 2021-01-21 21:17, Moritz Fischer wrote:
Robin,
On Thu, Jan 21, 2021 at 08:08:42PM +, Robin Murphy wrote:
On 2021-01-21 19:16, Moritz Fischer wrote:
Address issue observed on real world system with suboptimal IORT table
where DMA masks of PCI devices would get set to 0 as result
On 2021-01-22 12:13, Catalin Marinas wrote:
On Thu, Jan 21, 2021 at 06:59:37PM +, Robin Murphy wrote:
On 2021-01-21 17:46, Will Deacon wrote:
On Thu, Jan 21, 2021 at 10:21:50PM +0530, Prathu Baronia wrote:
This patch removes the unnecessary kmap calls in the hugepage zeroing path and
On 2021-01-22 12:41, Will Deacon wrote:
On Tue, Nov 24, 2020 at 12:15:58PM -0700, Jordan Crouse wrote:
Call report_iommu_fault() to allow upper-level drivers to register their
own fault handlers.
Signed-off-by: Jordan Crouse
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 16 +---
On 2021-01-22 12:51, Will Deacon wrote:
On Thu, Nov 26, 2020 at 11:42:30AM +0800, Zhen Lei wrote:
When changing from a set of pages/smaller blocks to a larger block for an
address, the software should follow the sequence of BBML processing.
When changing from a block to a set of pages/smaller b
On 2021-01-21 21:30, isa...@codeaurora.org wrote:
On 2021-01-12 08:00, Robin Murphy wrote:
On 2021-01-11 14:54, Isaac J. Manjarres wrote:
The iommu_map_sg() code currently iterates through the given
scatter-gather list, and in the worst case, invokes iommu_map()
for each element in the scatter
writing up a patch to kill off this bit
entirely, but either way we still can't meaningfully interpret a
supposed DMA limit of 0 bits in a table describing DMA-capable devices,
so for this patch as a fix,
Reviewed-by: Robin Murphy
Thanks,
Robin.
}
*dma_addr = dmaaddr;
On 2021-03-03 17:36, Shameer Kolothum wrote:
The device iommu probe/attach might have failed leaving dev->iommu
to NULL and device drivers may still invoke these functions resulting
in a crash in iommu vendor driver code.
Hence make sure we check that.
Reviewed-by: Robin Murphy
Fi
On 2021-02-05 11:48, Robin Murphy wrote:
On 2021-02-05 09:13, Keqian Zhu wrote:
Hi Robin and Jean,
On 2021/2/5 3:50, Robin Murphy wrote:
On 2021-01-28 15:17, Keqian Zhu wrote:
From: jiangkunkun
The SMMU which supports HTTU (Hardware Translation Table Update) can
update the access flag and
s are
strictly validated in arm_smmu_probe_device()...
Fix the SMR mask extraction step for bootloader programmed SMRs
by masking out the valid bit when we know that we're already
working with a valid SMR.
This seems like the neatest approach to me.
Reviewed-by: Robin Murphy
Fixes: 07a7f2caaa5a ("
On 2021-01-25 21:51, Jordan Crouse wrote:
On Fri, Jan 22, 2021 at 12:53:17PM +, Robin Murphy wrote:
On 2021-01-22 12:41, Will Deacon wrote:
On Tue, Nov 24, 2020 at 12:15:58PM -0700, Jordan Crouse wrote:
Call report_iommu_fault() to allow upper-level drivers to register their
own fault
ead of the iommu_attach_device(). The external interface
iommu_attach_device() is not suitable for handling this situation.
No objection to the cosmetic change - arguably parsing "attach" as a
verb rather than a noun is more normal anyway :)
Thus my previous review still stands:
Reviewed-by: Ro
On Tue, 26 Jan 2021 13:06:29 +
Shameer Kolothum wrote:
> The device iommu probe/attach might have failed leaving dev->iommu
> to NULL and device drivers may still invoke these functions resulting
> a crash in iommu vendor driver code. Hence make sure we check that.
>
> Signed-off-by: Shameer
On 2021-01-26 16:05, Rob Clark wrote:
On Tue, Jan 26, 2021 at 3:41 AM Robin Murphy wrote:
On 2021-01-25 21:51, Jordan Crouse wrote:
On Fri, Jan 22, 2021 at 12:53:17PM +, Robin Murphy wrote:
On 2021-01-22 12:41, Will Deacon wrote:
On Tue, Nov 24, 2020 at 12:15:58PM -0700, Jordan Crouse
On 2021-01-26 16:40, Shameerali Kolothum Thodi wrote:
Hi Robin,
-Original Message-
From: Robin Murphy [mailto:robin.mur...@arm.com]
Sent: 26 January 2021 13:51
To: Shameerali Kolothum Thodi
Cc: linux-kernel@vger.kernel.org; io...@lists.linux-foundation.org;
jean-phili...@linaro.org; w
On 2021-01-15 14:26, lijiang wrote:
Hi, Robin
Thank you for the comment.
在 2021年01月13日 01:29, Robin Murphy 写道:
On 2021-01-05 07:52, lijiang wrote:
在 2021年01月05日 11:55, lijiang 写道:
Hi,
Also add Joerg to cc list.
Also add more people to cc list, Jerry Snitselaar and Tom Lendacky.
Thanks
On 2021-01-15 17:32, Jean-Philippe Brucker wrote:
On Thu, Dec 10, 2020 at 02:23:09AM +0800, John Garry wrote:
Leizhen reported some time ago that IOVA performance may degrade over time
[0], but unfortunately his solution to fix this problem was not given
attention.
To summarize, the issue is th
On 2021-01-15 17:58, Paul Kocialkowski wrote:
A mechanism was recently introduced for the sunxi architecture where
the DMA offset for specific devices (under the MBUS) is set by a common
driver (sunxi_mbus). This driver calls dma_direct_set_offset to set
the device's dma_range_map manually.
Howe
On 2021-01-22 17:50, Moritz Fischer wrote:
Hi Robin,
On Fri, Jan 22, 2021 at 02:42:05PM +, Robin Murphy wrote:
On 2021-01-22 01:24, Moritz Fischer wrote:
Address issue observed on real world system with suboptimal IORT table
where DMA masks of PCI devices would get set to 0 as result
On 2021-01-23 10:20, Leizhen (ThunderTown) wrote:
On 2021/1/22 21:00, Robin Murphy wrote:
On 2021-01-22 12:51, Will Deacon wrote:
On Thu, Nov 26, 2020 at 11:42:30AM +0800, Zhen Lei wrote:
When changing from a set of pages/smaller blocks to a larger block for an
address, the software should
On 2021-01-23 10:08, Leizhen (ThunderTown) wrote:
On 2021/1/22 20:51, Will Deacon wrote:
On Thu, Nov 26, 2020 at 11:42:30AM +0800, Zhen Lei wrote:
When changing from a set of pages/smaller blocks to a larger block for an
address, the software should follow the sequence of BBML processing.
Wh
On 2021-01-27 07:36, Keqian Zhu wrote:
On 2021/1/27 10:01, Leizhen (ThunderTown) wrote:
On 2021/1/26 18:12, Will Deacon wrote:
On Mon, Jan 25, 2021 at 08:23:40PM +, Robin Murphy wrote:
Now we probably will need some degreee of BBML feature awareness for the
sake of SVA if and when we
Hi,
On 2020-06-25 23:34, Nitesh Narayan Lal wrote:
From: Alex Belits
The current implementation of cpumask_local_spread() does not respect the
isolated CPUs, i.e., even if a CPU has been isolated for Real-Time task,
it will return it to the caller for pinning of its IRQ threads. Having
these u
On 2021-01-27 12:19, Marcelo Tosatti wrote:
On Wed, Jan 27, 2021 at 11:57:16AM +, Robin Murphy wrote:
Hi,
On 2020-06-25 23:34, Nitesh Narayan Lal wrote:
From: Alex Belits
The current implementation of cpumask_local_spread() does not respect the
isolated CPUs, i.e., even if a CPU has
Thanks,
Robin.
Cheers,
Paul
[1]
https://lore.kernel.org/linux-arm-kernel/5c7946f3-b56e-da00-a750-be097c7ce...@arm.com/
CC: Rob Herring
CC: Frank Rowand
Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting
dma_pfn_offset"),
Suggested-by: Robin Murphy
Signed-of
On 2021-01-27 13:09, Marcelo Tosatti wrote:
On Wed, Jan 27, 2021 at 12:36:30PM +, Robin Murphy wrote:
On 2021-01-27 12:19, Marcelo Tosatti wrote:
On Wed, Jan 27, 2021 at 11:57:16AM +, Robin Murphy wrote:
Hi,
On 2020-06-25 23:34, Nitesh Narayan Lal wrote:
From: Alex Belits
The
A range map, supplanting
dma_pfn_offset"),
Suggested-by: Robin Murphy
Signed-off-by: Yong Wu
Signed-off-by: Paul Kocialkowski
Reviewed-by: Rob Herring
---
drivers/of/device.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/of/device.c b/drivers/of/dev
On 2021-01-27 19:09, Rob Herring wrote:
On Wed, Jan 27, 2021 at 7:13 AM Robin Murphy wrote:
[ + Christoph, Marek ]
On 2021-01-27 13:00, Paul Kocialkowski wrote:
Hi,
On Tue 19 Jan 21, 18:52, Yong Wu wrote:
The commit e0d072782c73 ("dma-mapping: introduce DMA range map,
suppla
On 2020-12-15 11:47, Tomasz Figa wrote:
On Tue, Dec 15, 2020 at 8:16 PM Stanimir Varbanov
wrote:
Hi,
Cc: Robin
On 12/14/20 2:57 PM, Alexandre Courbot wrote:
This driver uses the SG vb2 ops, but effectively only ever accesses the
first entry of the SG table, indicating that it expects a flat
On 2020-12-16 10:36, Yong Wu wrote:
Currently gather->end is "unsigned long" which may be overflow in
arch32 in the corner case: 0xfff0 + 0x10(iova + size).
Although it doesn't affect the size(end - start), it affects the checking
"gather->end < end"
This won't help the same situation a
On 2020-12-13 16:32, Heiner Kallweit wrote:
Zillions of drivers use the unlikely() hint when checking the result of
dma_mapping_error(). This is an inline function anyway, so we can move
the hint into this function and remove it from drivers.
Reviewed-by: Robin Murphy
FWIW I consider this
4 hats are doing they clearly
aren't doing it with GPIO2_A4 either way.
Reviewed-by: Robin Murphy
Fixes: e7a095908227 ("arm64: dts: rockchip: Add devicetree for NanoPC-T4")
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts | 1 +
arch/arm64
On 2020-12-15 11:16, Stanimir Varbanov wrote:
Hi,
Cc: Robin
On 12/14/20 2:57 PM, Alexandre Courbot wrote:
This driver uses the SG vb2 ops, but effectively only ever accesses the
first entry of the SG table, indicating that it expects a flat layout.
Switch it to use the contiguous ops to make s
On 2020-11-20 09:06, Yong Wu wrote:
Currently direct_mapping always use the smallest pgsize which is SZ_4K
normally to mapping. This is unnecessary. we could gather the size, and
call iommu_map then, iommu_map could decide how to map better with the
just right pgsize.
From the original comment,
th is probably
more valuable for now.
Reviewed-by: Robin Murphy
Signed-off-by: Yong Wu
---
drivers/iommu/io-pgtable-arm-v7s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-pgtable-arm-v7s.c
index a688f22
On 2020-11-11 12:38, Yong Wu wrote:
MediaTek extend the bit5 in lvl1 and lvl2 descriptor as PA34.
Reviewed-by: Robin Murphy
Signed-off-by: Yong Wu
Acked-by: Will Deacon
---
drivers/iommu/io-pgtable-arm-v7s.c | 9 +++--
drivers/iommu/mtk_iommu.c | 2 +-
include/linux/io
functional change.
Grammar nit: to "clear" the macro sounds like you're making it empty or
removing it entirely; I think you mean to say "clarify" here. English is
the worst language sometimes... :)
Reviewed-by: Robin Murphy
Suggested-by: Robin Murphy
Signed-off-b
On 2020-11-11 12:38, Yong Wu wrote:
Add "cfg" as a parameter for some macros. This is a preparing patch for
mediatek extend the lvl1 pgtable. No functional change.
Reviewed-by: Robin Murphy
Signed-off-by: Yong Wu
Acked-by: Will Deacon
---
drivers/iommu/io-pgtable-arm-
On 2020-11-11 12:38, Yong Wu wrote:
The standard input iova bits is 32. MediaTek quad the lvl1 pagetable
(4 * lvl1). No change for lvl2 pagetable. Then the iova bits can reach
34bit.
Yay, I love how simple the actual change becomes now!
Reviewed-by: Robin Murphy
Signed-off-by: Yong Wu
On 2020-11-11 12:38, Yong Wu wrote:
In attach device, it will update the pagetable base address register.
Move the hw_init function also here. Then it only need call
pm_runtime_get/put one time here if m4u has power domain.
Doesn't that mean you'll end up writing most of the registers twice
ev
On 2020-11-11 12:38, Yong Wu wrote:
Defaultly the iova range is 0-4G. here we add a single-domain(0-4G)
for the previous SoC. this also is a preparing patch for supporting
multi-domains.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 12
1 file changed, 12 insertions(+)
501 - 600 of 1747 matches
Mail list logo
