On 2024-03-01 4:42 pm, abdellatif.elkhl...@arm.com wrote:
From: Abdellatif El Khlifi
introduce the bindings for Arm remoteproc support.
Signed-off-by: Abdellatif El Khlifi
---
.../bindings/remoteproc/arm,rproc.yaml| 69 +++
MAINTAINERS
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
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
- 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/arm-smmu-v3
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
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
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 when we
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-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
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,
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
^^Nit: presumably you meant "Allow" in the subject.
On 2021-03-25 17:16, Will Deacon wrote:
On Tue, Mar 23, 2021 at 01:58:00PM +0800, Yong Wu wrote:
This patch only adds support for building the IOMMU-v1 driver as module.
Correspondingly switch the config to tristate.
Signed-off-by: Yong Wu
On 2021-03-25 12:30, John Garry wrote:
Function free_iova_fast() is only referenced by dma-iommu.c, which can
only be in-built, so stop exporting it.
This was missed in an earlier tidy-up patch.
Reviewed-by: Robin Murphy
Signed-off-by: John Garry
---
drivers/iommu/iova.c | 1 -
1 file
On 2021-03-25 12:30, John Garry wrote:
Function iommu_dma_free_cpu_cached_iovas() no longer has any caller, so
delete it.
With that, function free_cpu_cached_iovas() may be made static.
Reviewed-by: Robin Murphy
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c | 9
On 2021-03-25 07:53, Sven Peter wrote:
On Tue, Mar 23, 2021, at 21:53, Rob Herring wrote:
On Sun, Mar 21, 2021 at 05:00:50PM +0100, Mark Kettenis wrote:
Date: Sat, 20 Mar 2021 15:19:33 +
From: Sven Peter
I have just noticed today though that at least the USB DWC3 controller in host
mode
On 2021-03-24 16:38, David Laight wrote:
From: Robin Murphy
Sent: 23 March 2021 12:09
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
On 2021-03-20 15:19, Sven Peter wrote:
Apple's DART iommu uses a pagetable format that's very similar to the ones
already implemented by io-pgtable.c.
Add a new format variant to support the required differences.
TBH there look to be more differences than similarities, but I guess we
already
On 2021-03-20 15:19, Sven Peter wrote:
Hi,
After Hector's initial work [1] to bring up Linux on Apple's M1 it's time to
bring up more devices. Most peripherals connected to the SoC are behind a iommu
which Apple calls "Device Address Resolution Table", or DART for short [2].
Unfortunately, it
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
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
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
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 | 30
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
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-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-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
On 2021-03-19 13:25, John Garry wrote:
Add a function to allow the max size which we want to optimise DMA mappings
for.
It seems neat in theory - particularly for packet-based interfaces that
might have a known fixed size of data unit that they're working on at
any given time - but aren't
On 2021-03-19 13:25, John Garry wrote:
Some LLDs may request DMA mappings whose IOVA length exceeds that of the
current rcache upper limit.
This means that allocations for those IOVAs will never be cached, and
always must be allocated and freed from the RB tree per DMA mapping cycle.
This has a
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.
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c | 8 --
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().
Signed-off-by: Robin Murphy
---
drivers/iommu/amd/init.c| 3
- 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.
Signed-off-by: Robin Murphy
---
This is something I hadn't got round to sending earlier, so now rebased
onto iommu/next
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
consistent with the initial post for the values on the CPUs can be
found in the patch
On 2021-03-18 21:31, Florian Fainelli wrote:
On 3/18/2021 12:53 PM, Robin Murphy wrote:
On 2021-03-18 19:43, Florian Fainelli wrote:
On 3/18/2021 12:34 PM, Robin Murphy wrote:
On 2021-03-18 19:22, Florian Fainelli wrote:
On 3/18/2021 12:18 PM, Florian Fainelli wrote:
It may be useful
On 2021-03-18 19:43, Florian Fainelli wrote:
On 3/18/2021 12:34 PM, Robin Murphy wrote:
On 2021-03-18 19:22, Florian Fainelli wrote:
On 3/18/2021 12:18 PM, Florian Fainelli wrote:
It may be useful to disable the SWIOTLB completely for testing or when a
platform is known not to have any
On 2021-03-18 19:22, Florian Fainelli wrote:
On 3/18/2021 12:18 PM, Florian Fainelli wrote:
It may be useful to disable the SWIOTLB completely for testing or when a
platform is known not to have any DRAM addressing limitations what so
ever.
Isn't that what "swiotlb=noforce" is for? If
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 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
, 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
warnin
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]
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
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 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
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
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
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
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-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
strict
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
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
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
r the 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-
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
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
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
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).
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.
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,
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
On 2021-02-25 11:09, Thierry Reding wrote:
On Wed, Feb 24, 2021 at 10:39:42PM +0100, Heiko Thiery wrote:
Hi Christoph and all,
On 23.02.21 10:56, Guillaume Tucker wrote:
Hi Christoph,
Please see the bisection report below about a boot failure on
r8a77960-ulcb on next-20210222.
Reports
On 2021-02-02 09:51, Christoph Hellwig wrote:
Add a new API that returns a potentiall virtually non-contigous sg_table
and a DMA address. This API is only properly implemented for dma-iommu
and will simply return a contigious chunk as a fallback.
The intent is that media drivers can use this
On 2021-02-10 19:21, Rob Herring wrote:
On Fri, Feb 5, 2021 at 1:21 AM Chunyan Zhang wrote:
Hi Rob,
On Fri, 5 Feb 2021 at 07:25, Rob Herring wrote:
On Wed, Feb 03, 2021 at 05:07:26PM +0800, Chunyan Zhang wrote:
From: Chunyan Zhang
This iommu module can be used by Unisoc's multimedia
On 2021-01-05 13:46, Kevin Tang wrote:
Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem.
It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
v2:
- Use drm_xxx to replace all
On 2021-02-12 17:28, Shameerali Kolothum Thodi wrote:
-Original Message-
From: Shameerali Kolothum Thodi
Sent: 12 February 2021 16:45
To: 'Robin Murphy' ; linux-kernel@vger.kernel.org;
io...@lists.linux-foundation.org
Cc: j...@8bytes.org; jean-phili...@linaro.org; w...@kernel.org
Hi Mikko,
On 2021-02-08 16:38, Mikko Perttunen wrote:
To allow for more customized device tree bindings that point to IOMMUs,
allow manual specification of iommu_spec to of_dma_configure.
The initial use case for this is with Host1x, where the driver manages
a set of device tree-defined IOMMU
On 2021-02-12 14:54, Shameerali Kolothum Thodi wrote:
Hi Robin/Joerg,
-Original Message-
From: Shameer Kolothum [mailto:shameerali.kolothum.th...@huawei.com]
Sent: 01 February 2021 12:41
To: linux-kernel@vger.kernel.org; io...@lists.linux-foundation.org
Cc: j...@8bytes.org;
On 2021-02-10 13:15, Nicolas Saenz Julienne wrote:
[ Add Robin, Catalin and Florian in case they want to chime in ]
Hi Juerg, thanks for the report!
On Wed, 2021-02-10 at 11:48 +0100, Juerg Haefliger wrote:
Trying to dump the BCM2711 registers kills the kernel:
# cat
On 2021-02-09 12:36, Sumit Garg wrote:
Hi Christoph,
On Tue, 9 Feb 2021 at 15:06, Christoph Hellwig wrote:
On Tue, Feb 09, 2021 at 10:23:12AM +0100, Greg KH wrote:
From the view point of ZeroCopy using DMABUF, is 5.4 not
mature enough, and is 5.10 enough mature ?
This is the most
On 2021-02-09 11:57, Yi Sun wrote:
On 21-02-07 18:40:36, Keqian Zhu wrote:
Hi Yi,
On 2021/2/7 17:56, Yi Sun wrote:
Hi,
On 21-01-28 23:17:41, Keqian Zhu wrote:
[...]
+static void vfio_dma_dirty_log_start(struct vfio_iommu *iommu,
+struct vfio_dma *dma)
On 2021-02-07 09:56, Yi Sun wrote:
Hi,
On 21-01-28 23:17:41, Keqian Zhu wrote:
[...]
+static void vfio_dma_dirty_log_start(struct vfio_iommu *iommu,
+struct vfio_dma *dma)
+{
+ struct vfio_domain *d;
+
+ list_for_each_entry(d, >domain_list,
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
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 the dirty state of TTD by hardware
On 2021-02-04 22:58, Barry Song wrote:
In a real dma mapping user case, after dma_map is done, data will be
transmit. Thus, in multi-threaded user scenario, IOMMU contention
should not be that severe. For example, if users enable multiple
threads to send network packets through 1G/10G/100Gbps
On 2021-01-28 15:17, Keqian Zhu wrote:
From: jiangkunkun
During dirty log tracking, user will try to retrieve dirty log from
iommu if it supports hardware dirty log. This adds a new interface
named sync_dirty_log in iommu layer and arm smmuv3 implements it,
which scans leaf TTD and treats it's
On 2021-01-28 15:17, Keqian Zhu wrote:
From: jiangkunkun
When stop dirty log tracking, we need to recover all block descriptors
which are splited when start dirty log tracking. This adds a new
interface named merge_page in iommu layer and arm smmuv3 implements it,
which reinstall block
On 2021-01-28 15:17, Keqian Zhu wrote:
From: jiangkunkun
Block descriptor is not a proper granule for dirty log tracking. This
adds a new interface named split_block in iommu layer and arm smmuv3
implements it, which splits block descriptor to an equivalent span of
page descriptors.
During
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 the dirty state of TTD by hardware. It is
essential to track dirty pages of DMA.
This adds feature detection, none functional change.
On 2021-02-03 02:01, Qiang Yu wrote:
On Tue, Feb 2, 2021 at 10:02 PM Lukasz Luba wrote:
On 2/2/21 1:01 AM, Qiang Yu wrote:
Hi Lukasz,
Thanks for the explanation. So the deferred timer option makes a mistake that
when GPU goes from idle to busy for only one poll periodic, in this
case
On 2021-02-04 07:29, Christoph Hellwig wrote:
On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote:
This patch converts several swiotlb related variables to arrays, in
order to maintain stat/status for different swiotlb buffers. Here are
variables involved:
- io_tlb_start and
On 2021-02-03 16:52, Johan Jonker wrote:
In the past Rockchip dwc3 usb nodes were manually checked.
With the conversion of snps,dwc3.yaml as common document
we now can convert rockchip,dwc3.txt to yaml as well.
Remove node wrapper.
Added properties for rk3399 are:
power-domains
resets
On 2021-02-02 14:41, Joerg Roedel wrote:
On Tue, Feb 02, 2021 at 02:34:34PM +, Robin Murphy wrote:
Nope, I believe if Arm Ltd. had any involvement in this I'd know about it :)
Okay, got confused by thinking of ARM as the CPU architecture, not the
company :)
But given the intel/ and amd
On 2021-02-02 14:01, Joerg Roedel wrote:
On Tue, Feb 02, 2021 at 06:42:57PM +0800, Chunyan Zhang wrote:
From: Chunyan Zhang
This iommu module can be used by Unisoc's multimedia devices, such as
display, Image codec(jpeg) and a few signal processors, including
VSP(video), GSP(graphic),
On 2021-02-01 23:58, Tianling Shen wrote:
From: Sumit Gupta
Removed restriction of displaying model name for 32 bit tasks only.
This can be used for 64 bit tasks as well, and it's useful for some
tools that already parse this, such as coreutils `uname -p`, Ubuntu
model name display etc.
How
On 2021-02-02 08:53, Keqian Zhu wrote:
Signed-off-by: Keqian Zhu
---
include/linux/iommu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 77e561ed57fd..e8f2efae212b 100644
--- a/include/linux/iommu.h
+++
On 2021-02-02 11:21, Andy Shevchenko wrote:
On Mon, Feb 01, 2021 at 04:25:55PM -0800, Jianxiong Gao wrote:
+ if (dma_set_min_align_mask(dev->dev, NVME_CTRL_PAGE_SIZE - 1))
Side note: we have DMA_BIT_MASK(), please use it.
FWIW I'd actually disagree on that point. Conceptually, this
Murphy
I hadn't considered that a comment is a very good idea, in case the
cleanup-script crew find this in future and try to "simplify" it :)
Thanks,
Robin.
Suggested-by: Robin Murphy
Signed-off-by: Zhen Lei
---
drivers/perf/arm_smmuv3_pmu.c | 25 +++--
1 fi
the dependency.
Reviewed-by: Robin Murphy
Signed-off-by: John Garry
diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index 3075cf171f78..77522e5efe11 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -62,7 +62,7 @@ config ARM_PMU_ACPI
config ARM_SMMU_V3_PMU
On 2021-01-30 01:54, Leizhen (ThunderTown) wrote:
On 2021/1/29 23:27, Robin Murphy wrote:
On 2021-01-27 11:32, Zhen Lei wrote:
commit 52f3fab0067d ("iommu/arm-smmu-v3: Don't reserve implementation
defined register space") only reserves the basic SMMU register space. So
the ECMD
On 2021-01-29 11:45, Tomasz Figa wrote:
On Mon, Jan 25, 2021 at 4:34 PM Yong Wu wrote:
On Mon, 2021-01-25 at 13:18 +0900, Tomasz Figa wrote:
On Wed, Jan 20, 2021 at 4:08 PM Yong Wu wrote:
On Wed, 2021-01-20 at 13:15 +0900, Tomasz Figa wrote:
On Wed, Jan 13, 2021 at 3:45 PM Yong Wu
On 2021-01-29 15:34, John Garry wrote:
On 29/01/2021 15:12, Robin Murphy wrote:
On 2021-01-27 11:32, Zhen Lei wrote:
The MODULE_SOFTDEP() gives user space a hint of the loading sequence.
And
when command "modprobe arm_smmuv3_pmu" is executed, the
arm_smmu_v3.ko is
automatica
On 2021-01-28 21:14, Will Deacon wrote:
On Thu, Jan 28, 2021 at 09:10:20PM +, Will Deacon wrote:
On Wed, Jan 27, 2021 at 05:39:16PM +0800, Yong Wu wrote:
On Tue, 2021-01-26 at 22:23 +, Will Deacon wrote:
On Mon, Jan 11, 2021 at 07:18:48PM +0800, Yong Wu wrote:
If
On 2021-01-28 00:38, Jianxiong Gao wrote:
NVMe driver relies on the address offset to function properly.
This patch adds the offset preserve mask to NVMe driver when mapping
via dma_map_sg_attrs and unmapping via nvme_unmap_sg. The mask
depends on the page size defined by CC.MPS register of NVMe
On 2021-01-28 00:38, Jianxiong Gao wrote:
Some devices rely on the address offset in a page to function
correctly (NVMe driver as an example). These devices may use
a different page size than the Linux kernel. The address offset
has to be preserved upon mapping, and in order to do so, we
need to
On 2021-01-28 15:18, Keqian Zhu wrote:
On 2021/1/27 17:39, Robin Murphy wrote:
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
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
pplanting
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/device.c
index aed
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
nks,
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-off-by:
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
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
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
1 - 100 of 2729 matches
Mail list logo
