On 2025-02-21 4:44 pm, Jason Gunthorpe wrote:
On Fri, Feb 21, 2025 at 03:39:45PM +, Robin Murphy wrote:
Yuck. Realistically we are going to have no more than two different
implementations of this; a fiddly callback interface seems overkill. All we
should need in the domain is a simple
s easy to solve all the
other fragility issues too.
Thanks,
Robin.
+
static inline bool iommu_is_dma_domain(struct iommu_domain *domain)
{
return domain->type & __IOMMU_DOMAIN_DMA_API;
@@ -1470,6 +1488,18 @@ static inline ioasid_t iommu_alloc_global_pasid(stru
kie()? Is is that IOMMUFD and VFIO type 1 are both
doing their own different thing with IOMMU_DOMAIN_UNMANAGED?
In general it seems like a bad smell to have a union in a structure with
not enough information within that structire itself to know which union
member is valid... :/
Thanks,
WIW, driver-wise the mapping to the reset API seems straightforward -
.assert hits RST_REQ, .deassert clears CPUWAIT (.status is possibly a
combination of CPUWAIT and RST_ACK?)
Thanks,
Robin.
+
+maintainers:
+ - Abdellatif El Khlifi
+ - Hugues Kamba Mpiana
+
+description: |
+ SSE-710 is an
ity, then describing each register and location individually
is liable to get unmanageable really fast, and a higher-level functional
grouping (e.g. these reset-related registers together as a single 8-byte
region) would likely be a better design.
Thanks,
Robin.
+
+required
On 2021/04/19 17:46 Lucas Stach wrote:
> Am Montag, dem 19.04.2021 um 07:17 + schrieb Robin Gong:
> > Hi Lucas,
> >
> > On 2021/04/14 Lucas Stach wrote:
> > > Hi Robin,
> > >
> > > Am Mittwoch, dem 14.04.2021 um 14:33 + schrieb Robin Gong
Hi Lucas,
On 2021/04/14 Lucas Stach wrote:
> Hi Robin,
>
> Am Mittwoch, dem 14.04.2021 um 14:33 + schrieb Robin Gong:
> > On 2020/05/20 17:43 Lucas Stach wrote:
> > > Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu Wang:
> > > > Hi
> > &
On 2020/05/20 17:43 Lucas Stach wrote:
> Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu Wang:
> > Hi
> >
> > On Tue, May 19, 2020 at 6:04 PM Lucas Stach
> wrote:
> > > Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu Wang:
> > > > There are two requirements that we need to mov
On 2021/04/12 17:39, Vinod Koul wrote:
> On 07-04-21, 23:30, Robin Gong wrote:
> > Add terminated list for keeping descriptor so that it could be freed
> > in worker without any potential involving next descriptor raised up
> > before this descriptor freed, because vcha
ngine provider being present, or host controller drivers
which are useless without their corresponding phy driver (and I'm
guessing you can probably also do higher-level things like include the
block layer but omit all filesystem drivers). I don't believe it's
Kconfig's job to try to guess whether a given configuration is *useful*,
only to enforce that's it's valid to build.
Robin.
next descriptor maybe freed unexpectly when it's
done in worker without this patch.
https://www.spinics.net/lists/dmaengine/msg23367.html
Signed-off-by: Robin Gong
Reported-by: Richard Leitner
---
drivers/dma/imx-sdma.c | 17 ++---
1 file changed, 10 insertions(+), 7 dele
below and put them into the path
(/lib/firmware/imx/sdma/):
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
/tree/imx/sdma
Signed-off-by: Robin Gong
Acked-by: Vinod Koul
---
drivers/dma/imx-sdma.c | 17 +++--
include/linux/platform_data
Add i.mx6ul compatible name in binding doc.
Signed-off-by: Robin Gong
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
b/Documentation/devicetree
ECSPI issue fixed from i.mx6ul at hardware level, no need
ERR009165 anymore on those chips such as i.mx8mq.
Signed-off-by: Robin Gong
Acked-by: Vinod Koul
---
drivers/dma/imx-sdma.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/imx
ERR009165 fixed on i.mx6ul/6ull/6sll. All other i.mx6/7 and
i.mx8m/8mm still need this errata. Please refer to nxp official
errata document from https://www.nxp.com/ .
For removing workaround on those chips. Add new i.mx6ul type.
Signed-off-by: Robin Gong
Acked-by: Mark Brown
---
drivers/spi
Change to XCH mode even in dma mode, please refer to the below
errata:
https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf
Signed-off-by: Robin Gong
Acked-by: Mark Brown
---
drivers/spi/spi-imx.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi-imx.c
Add mcu_2_ecspi script to fix ecspi errata ERR009165.
Signed-off-by: Robin Gong
Acked-by: Vinod Koul
---
drivers/dma/imx-sdma.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 78dcfe2..86bd383 100644
--- a/drivers/dma/imx-sdma.c
out free in case
that spi fallback into pio while dma transfer failed by sdma firmware not
ready(next ERR009165 patch depends on sdma RAM scripts/firmware).
Signed-off-by: Robin Gong
Acked-by: Vinod Koul
---
drivers/dma/imx-sdma.c | 13 +
1 file changed, 13 insertions(+)
diff --git
Since sdma_transfer_init() will do sdma_load_context before any
sdma transfer, no need once more in sdma_config_channel().
Fixes: ad0d92d7ba6a ("dmaengine: imx-sdma: refine to load context only once")
Cc:
Signed-off-by: Robin Gong
Acked-by: Vinod Koul
Tested-by: Richard Leitner
--
This reverts commit ad0d92d7ba6aecbe2705907c38ff8d8be4da1e9c, because
in spi-imx case, burst length may be changed dynamically.
Fixes: ad0d92d7ba6a ("dmaengine: imx-sdma: refine to load context only once")
Cc:
Signed-off-by: Robin Gong
Acked-by: Sascha Hauer
Tested-by: Richa
ag glitch can cause the current FIFO transfer to
be sent twice
So revert commit 'dd4b487b32a3' firstly.
Signed-off-by: Robin Gong
Acked-by: Sascha Hauer
---
arch/arm/boot/dts/imx6qdl.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boo
pty flag glitch can cause the current FIFO transfer to
be sent twice
So revert commit 'df07101e1c4a' firstly.
Signed-off-by: Robin Gong
Acked-by: Sascha Hauer
---
arch/arm/boot/dts/imx6q.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/i
le name in binding doc'
since it's been converted to yaml already.
3. add 'Fixes', 'Cc: sta...@vger.kernel.org' and 'Test-by' tags for 03,04
since they are confirmed fix by Richard Leitner:
https://lkml.org/lkml/2020/8/17/39
https://www.s
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
bytes makes the slightest bit of difference, and for people not
debugging IOMMU drivers it should be moot (per the message itself).
Robin.
here) won't be
useful for embedded users, cloud providers, etc., just that I'm not sure
it's worth it being the *only* option.
Robin.
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
an things up, but please pay a
bit of care and attention to what you're actually doing.
Robin.
Signed-off-by: Bhaskar Chowdhury
---
drivers/dma/Kconfig | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 0c2827f
On 2021-03-29 09:15, Geert Uytterhoeven wrote:
Hoi Robin,
On Mon, Mar 29, 2021 at 9:09 AM Robin van der Gracht
wrote:
On 2021-03-22 15:48, Geert Uytterhoeven wrote:
> The Holtek HT16K33 LED controller is not only used for driving
> dot-matrix displays, but also for driving segment di
+ break;
+ }
+ if (err)
+ return err;
+
+ err = linedisp_register(&seg->linedisp, dev, 4, seg->curr,
+ ht16k33_linedisp_update);
+ if (err)
+ goto err_remove_map_file;
+
+ return 0;
Groetjes/Kind regards,
Robin van der Gracht
or less the same either way, they are conceptually
different things which we have different abstractions to deal with.
Robin.
either an issue with the mvebu-pic driver itself probing, and/or perhaps
something in fw_devlink going awry - inspecting sysfs should shed a bit
more light on those.
Robin.
d->port_dev->dma_mask = parent->dma_mask;
This might happen to work out, but is far from correct. Just wait until
you try it on a platform where the USB controller is behind an IOMMU...
It looks like something is more fundamentally wrong here - the device
passed to DMA API calls
o
blow up trying to write to rodata.
In fact I do wonder a little why that wasn't happening already - maybe
the compiler is clever enough to tell that the assignment is redundant
when THIS_MODULE == 0, and elides it :/
Robin.
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
y standard practice to use "dma-ranges" to
describe host bridge inbound windows. Even if the restriction is really
out in the host-side interconnect rather than in the bridge itself, to
all intents and purposes it's indistinguishable so can still be
described the same way.
The ca
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
u64 pgd[4];
Nit: in the driver you call the registers "TTBR" rather than "PGD". The
config here tries to represent hardware/architecture definitions rather
than internal abstractions.
Robin.
+ } apple_dart_cfg;
};
};
@@ -250,5 +25
root" and "leaf" devices thing that ipmmu-vmsa
does, although I believe that represents genuine hardware differences
where the leaves are more like extra TLBs rather than fully-functional
IOMMU blocks in their own right, so that may not be a relevant model here.
Robin.
I cu
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-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
note the function
itself also shouldn't need to be public any more, no?
Robin.
Signed-off-by: John Garry
---
drivers/iommu/iova.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index c78312560425..465b3b0eeeb0 100644
--- a
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
d down the priority list while
the uaccess behaviour in general was in flux - now that the dust has
largely settled on that I should probably try to find time to pick this
up again...
Robin.
Copy 4096 bytes cost on Kunpeng920 (ms):
Without this patch:
memcpy: 143.85 copy_from_user: 172.69 co
fic assumption that an external domain won't be
provided. I can't help wondering whether that distinction is really
necessary...
Robin.
/* Resource alignment requirements */
resource_size_t (*align_resource)(struct pci_dev *dev,
light class can and more.
Maybe we can stop registering a backlight device in the fbdev case and
register a led device for both. This makes the code cleaner and drops
a dependency but will break backwards compatibility.
I'd prefer a single solution that covers both use cases, but I'm not
sure about the 'breaking backwards compatibility' consequence...
Groetjes / Kind regards,
Robin van der Gracht
resh-rate-hz' is still a required property for the dot-matrix /
fbdev setup.
If it can no longer be listed here than maybe its nice to mention that
it's required
somewhere else (in it's description?).
Rob?
Groetjes / Kind regards,
Robin van der Gracht
o err_fbdev_unregister;
}
@@ -474,7 +475,7 @@ static int ht16k33_probe(struct i2c_client *client)
if (err) {
dft_brightness = MAX_BRIGHTNESS;
} else if (dft_brightness > MAX_BRIGHTNESS) {
- dev_warn(&client->dev,
+ dev_warn(dev,
"invalid default brightness level: %u, using %u\n",
dft_brightness, MAX_BRIGHTNESS);
dft_brightness = MAX_BRIGHTNESS;
Acked-by: Robin van der Gracht
ver = {
.name = DRIVER_NAME,
Acked-by: Robin van der Gracht
On 2021-03-22 15:48, Geert Uytterhoeven wrote:
Extract the character line display core support from the simple ASCII
LCD driver for the MIPS Boston, Malta & SEAD3 development boards into
its own subdriver, so it can be reused for other displays.
Note that this moves the "message" device attribut
dev);
- err = input_register_device(keypad->dev);
- if (err)
- return err;
-
- return 0;
+ return input_register_device(keypad->dev);
}
static int ht16k33_probe(struct i2c_client *client,
Acked-by: Robin van der Gracht
(data));
Acked-by: Robin van der Gracht
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 to be
imagine that having enough inherent overhead to
end up being an impractical (but fun) waste of time.
Robin.
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c | 2 +-
include/linux/dma-map-ops.h | 1 +
include/linux/dma-mapping.h | 5 +
kernel/dma/mapping.c| 11 +
on better performance, while small systems
- that often need IOMMU scatter-gather precisely *because* memory is
tight and thus easily fragmented - don't have to pay the (not
insignificant) cost for caches they don't need.
Robin.
#define MAX_GLOBAL_MAGS 32/* magazines per
responsibility is really on any caller of free_iova_fast() to make sure
they don't get things wrong.
Robin.
+
if (size_aligned)
align_mask <<= fls_long(size - 1);
@@ -288,21 +297,10 @@ void iova_cache_put(void)
}
EXPORT_SYMBOL_GPL(iova_cache_put);
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
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.
Signed-off-by: Robin Murphy
---
This is something I hadn't got round to sending earlier, so now rebased
ont
know the precision of this value but it is better than
nothing.
But is it? If it leads to some throttling mechanism kicking in and
crippling GPU performance because it's massively overestimating power
consumption, that would be objectively worse for most users, no?
Robin.
Hopefully, o
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
it.c with a:
if (memblock_end_of_DRAM() >= SZ_4G)
swiotlb_init(1)
Modulo "swiotlb=force", of course ;)
Robin.
right now this is made unconditional whenever ARM_LPAE is enabled which
is the case for the platforms I maintain (ARCH_BRCMSTB) however we do
not really need a SWIOTLB so long
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
5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ wan_led_pin: wan-led-pin {
+ rockchip,pins = <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ /delete-node/ rockchip-key;
Ditto for &power_key.
+ rockchip
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-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 of
if we open the floodgates of allowing
implementations to return error codes here.
Robin.
debug_dma_map_sg(dev, sg, nents, ents, dir);
return ents;
be valid, shouldn't it be cleared? The circumstances in which leaving it
around could cause a problem are tenuous, but definitely possible.
Robin.
+ continue;
if (sg_dma_len(tmp) == 0)
break;
- sg = tmp;
+
if threw out the notion of segment merging it
could save a load of bother by just maintaining the direct correlation
between pages and DMA addresses.
Robin.
Any alternative ideas or feedback is welcome.
These patches are based on v5.12-rc2 and a git branch is available here:
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
s
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
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-
eries was a set of performance/efficiency
improvements, so I'm not sure there's much justification for backporting
individual patches out of context. Plus as you say this one has the
unfortunate gfp bug.
Thanks for spotting this!
Robin.
lt to a specific client device, and
passing the IOMMU device seems a bit dubious too, so maybe just NULL?
Robin.
+ fsynr & ARM_SMMU_FSYNR0_WNR ? IOMMU_FAULT_WRITE :
IOMMU_FAULT_READ);
+
+ if (ret == -ENOSYS)
+ dev_err_ratelimited(smmu->dev,
+
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: Nic
4BIT
As mentioned previously, 32-bit systems may not need the overrides for
kernel I/O accessors, but they could still need the same workarounds for
the memory-mapping implications (if this is to be a proper generic
mechanism).
+ default n
Tip: it is always redundant to stat
f the implementation already needs a hook to
filter or override register accesses for any other reason. TBH I'm not
convinced that this isn't *more* of a mess than handling it on a
SoC-specific basis...
Robin.
}
static inline u64 arm_smmu_readq(struct arm_smm
there would be
to avoid using MSIs.
i guess this card/its driver does not use MSI. Did not found anything in
"datasheet" [1] or driver [2] about msi
FWIW, no need to guess - `lspci -v` (as root) should tell you whether
the card has MSI (and/or MSI-X) capability, and whether it
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
n swiotlb_tbl_sync_single")
567d877f9a7d ("swiotlb: refactor swiotlb_tbl_map_single")
Let me know if I can help test any fixes for this.
FWIW, this sounds like it's probably the same thing for which a fix
should be pending:
https://lore.kernel.org/linux-iommu/20210223072514.ga18...@lst.de/T/#u
Robin.
(dev, vma, size, sg_page(sgt->sgl));
Same comment about pages/orig_nents as above. Although does this
function even need to have a split personality at all - how hard would
it really be to call remap_pfn_range() in a for_each_sgtable_sg() loop?
(Or perhaps for_each_sgtable_page()/vm_insert_page() would be even
closer to what you already have here...)
Robin.
+}
+EXPORT_SYMBOL_GPL(dma_mmap_noncontiguous);
+
int dma_supported(struct device *dev, u64 mask)
{
const struct dma_map_ops *ops = get_dma_ops(dev);
t *does* make complete sense to describe even
"dedicated" IOMMUs like this one, Rockchip, Exynos, etc. in DT.
Otherwise you'd be effectively forcing OSes to turn half their
display/media drivers into mini board files with secret knowledge of
which blocks are integrated with IOMMUs on which SoCs.
Robin.
ou want to report
client-specific information associated with a fault you can use
iommu_set_fault_handler() to hook in your reporting function (the IOMMU
driver should correspondingly call report_iommu_fault() from its own
fault handler).
Even regardless of the mess this seems to be respons
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...@
over to passing its own IDs too, so thanks
for the memory-jog...)
Robin.
Signed-off-by: Mikko Perttunen
---
drivers/iommu/of_iommu.c | 12
drivers/of/device.c | 9 +
include/linux/of_device.h | 34 +++---
include/linux/of_iommu.h |
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; robin.mur
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 /sys/kernel/debug/regmap
nding page structs, so it's
impossible to generate a *valid* scatterlist to represent memory from
that pool, regardless of what you might get away with provided you don't
poke too hard at it.
It is not a good API...
Robin.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/l
apping besides enable SLADE. Right?
I am not familiar with ARM smmu. :) So I want to clarify if the block
in smmu is big page, e.g. 2M page? Intel Vtd manages the memory per
page, 4KB/2MB/1GB.
Indeed, what you call large pages, we call blocks :)
Robin.
There are two ways to manage dirty p
were to come along with some other way of reporting
dirty status that didn't depend on the granularity of individual
mappings, then indeed it wouldn't need this operation.
Robin.
+
+static void vfio_dma_dirty_log_stop(struct vfio_iommu *iommu,
+ str
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
1 - 100 of 1479 matches
Mail list logo
