On 2021-01-20 15:22, Oleksij Rempel wrote:
Add touchscreen support to the Protonic VT7 board.
Co-Developed-by: Robin van der Gracht
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-prtvt7.dts | 20
1 file changed, 20
Hello Jani,
On 2019-12-09 15:03, Jani Nikula wrote:
On Tue, 03 Dec 2019, Jani Nikula wrote:
Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.
Cc: Miguel Ojeda Sandonis
Cc: Robin van der Gracht
Reviewed-by: Daniel Vetter
Reviewed-by: Miguel
On 2019-11-29 11:29, Jani Nikula wrote:
Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.
Cc: Miguel Ojeda Sandonis
Cc: Robin van der Gracht
Signed-off-by: Jani Nikula
---
drivers/auxdisplay/cfag12864bfb.c | 2 +-
drivers/auxdisplay/ht16k33.c
d that the drivers should go into a different
category/folder instead and then the other were added.
In any case, I am removing the original ones since I cannot test them
anymore and there are likely no user. The only other fb user could be
relocated if Robin agrees.
The ht16k33 driver r
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
On 2021/04/22 Lucas Stach wrote:
> > But the timer of runtime_auto_suspend decide when enter runtime
> > suspend rather than hardware, while transfer data size and transfer
> > rate on IP bus decide when the dma interrupt happen.
> >
> But it isn't the hardware that decides to drop the rpm refcoun
device or not (possibly
they want to be using dma_max_mapping_size() now anyway - TBH I'm
struggling to make sense of what the swiotlb_max_segment business is
supposed to mean).
Otherwise, patch #9 will need to touch here as well to make sure that
per-device forced bouncing is reflected cor
de, "memory-region", i);
+ /* There might be multiple memory regions, but only one
+* restriced-dma-pool region is allowed.
+*/
What's the use-case for having multiple regions if the restricted pool
is by definition the only one accessible?
Robin.
+
evices - in that case we need
to return a non-cacheable address, but we can't simply fall through into
the remapping path below in GFP_ATOMIC context. That's why we need the
atomic pool concept in the first place :/
Unless I've overlooked something, we're still using t
NO_WARN are also for
coherent allocations rather than streaming mappings.
I'll see if I can whip up a patch to make the API documentation clearer...
Thanks,
Robin.
@@ -64,7 +64,7 @@ void i915_gem_gtt_finish_pages(struct drm_i915_gem_object
*obj,
usleep_range(100, 250);
the corresponding
alloc was, but on closer inspection it seems there isn't one. AFAICS
priv->dma_buf is only ever assigned with NULL (and priv->dev doesn't
seem to be assigned at all), so this could likely just be removed. In
fact it looks like all the references to DMA i
implementations do.
This avoids repeated warnings on a small minority of systems where the
display is behind an IOMMU, and has a simple driver which does not
override drm_gem_cma_default_funcs.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/drm_gem_cma_helper.c | 1 +
1 file changed, 1 insertion
API, and the plan to change
that is slowly climbing up my to-do list.
Robin.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/dri
On 2021-08-26 16:17, Lucas Stach wrote:
Am Donnerstag, dem 26.08.2021 um 16:00 +0100 schrieb Robin Murphy:
On 2021-08-26 13:10, Michael Walle wrote:
The DMA configuration of the virtual device is inherited from the first
actual etnaviv device. Unfortunately, this doesn't work with an
On 2021-03-11 08:26, Christoph Hellwig wrote:
On Wed, Mar 10, 2021 at 06:39:57PM +, Robin Murphy wrote:
Actually... Just mirroring the iommu_dma_strict value into
struct iommu_domain should solve all of that with very little
boilerplate code.
Yes, my initial thought was to directly
On 2021-03-15 08:33, Christoph Hellwig wrote:
On Fri, Mar 12, 2021 at 04:18:24PM +, Robin Murphy wrote:
Let me know what you think of the version here:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/iommu-cleanup
I'll happily switch the patch to you as the auth
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-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
From: Robin Murphy
Instead make the global iommu_dma_strict paramete in iommu.c canonical by
exporting helpers to get and set it and use those directly in the drivers.
This make sure
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin Murphy wrote:
On 2021-03-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
From: Robin Murphy
Instead make the global iommu_dma_strict paramete in iommu.c
On 2021-03-31 12:49, Will Deacon wrote:
On Tue, Mar 30, 2021 at 05:28:19PM +0100, Robin Murphy wrote:
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin Murphy wrote:
On 2021-03-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100
On 2021-03-31 16:32, Will Deacon wrote:
On Wed, Mar 31, 2021 at 02:09:37PM +0100, Robin Murphy wrote:
On 2021-03-31 12:49, Will Deacon wrote:
On Tue, Mar 30, 2021 at 05:28:19PM +0100, Robin Murphy wrote:
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin
@ -761,6 +761,9 @@ static int arm_smmu_init_domain_context(struct iommu_domain
*domain,
.iommu_dev = smmu->dev,
};
+ if (!iommu_get_dma_strict())
Ditto here.
Sorry for not spotting that sooner :(
Robin.
+ pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
+
actually uses a struct instead
of all the random variables.
Indeed, I skimmed the cover letter and immediately thought that this
whole thing is just the restricted DMA pool concept[1] again, only from
a slightly different angle.
Robin.
[1]
https://lore.kernel.org/linux-iommu
to have deferred timer when device is suspended for
power saving,
and delayed timer when device in working state. User knows this and
can use sysfs
to change it.
Doesn't devfreq_suspend_device() already cancel any timer work either
way in that case?
Robin.
Set the delayed timer as defa
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 |
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
their private options back to iommu_dma_strict
(and allow Intel's caching mode to override it as well), then have
iommu_dma_init_domain just test !iommu_dma_strict &&
domain->ops->flush_iotlb_all.
Robin.
Also remove the now unused iommu_domain_get_attr functionality.
tween the IOMMU core and drivers) if that's your concern.
Robin.
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
drivers/iommu/arm/arm-smmu/arm-smmu.c | 40 +++--
drivers/iommu/iommu.c | 9 ++
include/linux/iommu.h |
On 2021-03-10 09:25, Christoph Hellwig wrote:
On Wed, Mar 10, 2021 at 10:15:01AM +0100, Christoph Hellwig wrote:
On Thu, Mar 04, 2021 at 03:25:27PM +, Robin Murphy wrote:
On 2021-03-01 08:42, Christoph Hellwig wrote:
Use explicit methods for setting and querying the information instead
On 2021-05-17 10:27, Joerg Roedel wrote:
On Fri, Apr 30, 2021 at 08:20:10PM +0800, Kevin Tang wrote:
Cc Robin & Joerg
This is just some GPU internal MMU being used here, it seems. It doesn't
use the IOMMU core code, so no Ack needed from the IOMMU side.
Except the actual MMU bein
ler should ever hit it, and thus it really doesn't need
optimising. Although using tlb_flush_walk there may technically be
more heavyweight than needed, it does the job and saves everyone else
having to carry around useless baggage.
Signed-off-by: Robin Murphy
---
Reviewing the Mediatek T
On 2020-11-25 17:29, Robin Murphy wrote:
The only user of tlb_flush_leaf is a particularly hairy corner of the
Arm short-descriptor code, which wants a synchronous invalidation to
minimise the races inherent in trying to split a large page mapping.
This is already far enough into "he
presumably
returning an unexpected -ENODEV from the of_dma_set_restricted_buffer()
stub. That should probably be returning 0 instead, since either way it's
not an error condition for it to simply do nothing.
Robin.
Guenter
---
# bad: [fb0ca446157a86b75502c1636b0d81e642fe6bf1] Add linux
rribly on my laptop if I pass
swiotlb=force, even with the distro 5.10 kernel)
FWIW I'd imagine you probably need to massively increase the SWIOTLB
buffer size to have hope of that working.
Robin.
dma_io_tlb_mem should always be valid to follow.
FWIW I was pondering the question of whether to do something along those
lines or just scrap the default assignment entirely, so since I hadn't
got round to saying that I've gone ahead and hacked up the alternative
(similarly untested)
On 2021-07-06 15:05, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something along those
lines or just scrap the default assignment entirely, so since I hadn't got
round to saying that I've
tion of it downstream, and based on previous experience
I'm suspicious that it might be just the parent of hclk, and thus should
not need to be explicitly claimed by the device or baked into it's binding.
Robin.
Signed-off-by: Benjamin Gaignard
---
version 2:
- Add the clock
just a case of dw-hdmi
additionally registering itself as a phy provider if the internal phy is
present - the only difference then should be that it can end up calling
back into itself via the common phy API rather than directly via
internal special-cases.
Robin.
As a more pragmatic alternative,
that
way the workaround could be confined to a single dedicated place and
look somewhat similar to other special cases like sta2x11, rather than
being duplicated all over the place.
Robin.
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
This driver unconditionally sets the offset. Why c
rch64-* targets in BE
mode, if you want to flesh out the list even more. In principle there's
also "__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__" which should supposedly be
consistent across platforms, but I don't know if that's even more of a
specific GCC-ism.
Robin.
Sig
this series, having an interim workaround does seem more
reasonable now that we understand *why* we need it.
Thanks,
Robin.
underlying purpose on the other
thread, I suggest we call the new clock "niu" and describe it as
something like "Additional clock required to ungate the bus interface on
certain SoCs".
Cheers,
Robin.
Signed-off-by: Sascha Hauer
Acked-by: Rob Herring
---
Notes:
Cha
to test this on my
board tonight and see if I can see 24MHz on the CEC pin... :)
Robin.
On 2022-03-14 11:31, Robin Murphy wrote:
On 2022-03-13 12:56, Peter Geis wrote:
On Sun, Mar 13, 2022 at 6:13 AM Piotr Oniszczuk
wrote:
Wiadomość napisana przez Peter Geis w dniu
26.01.2022, o godz. 21:24:
The hdmi-cec clock must be 32khz in order for cec to work correctly.
Ensure after
#x27;s IOMMU DMA
+* ops in this case since GPU device is sitting on a separate (from PCI)
+* virtio-bus.
+*/
+ if (!strcmp(vdev->dev.parent->bus->name, "pci"))
Nit: dev_is_pci() ?
However, what about other VirtIO transports? Wouldn't virtio-mmi
the other option that Elaine mentioned, of just
marking hclk_vo as critical for now. If it's likely to turn into a
"nothing's as permanent as a temporary fix" situation, though, then the
DT binding has less functional impact, even if it does leave us
developers with baggage dow
tion/driver-api/device-io.rst).
Of course *then* you might find that on some systems the
interconnect/PCIe implementation/endpoint doesn't actually like
unaligned accesses once the CPU MMU starts allowing them to be sent out,
but hey, one step at a time ;)
Robin.
Christian
On 2022-03-23 10:11, Gerd Hoffmann wrote:
On Wed, Mar 23, 2022 at 09:45:13AM +, Robin Murphy wrote:
On 2022-03-23 07:15, Christian K�nig wrote:
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped as
1x
node itself? From a DT perspective I'm not sure the intermediate node
really fits meaningfully, and I can't see that it serves much purpose in
practice either, other than perhaps defeating fw_devlink.
Robin.
Signed-off-by: Mikko Perttunen
---
v3:
* New patch
---
.../bindings/dis
On 2022-02-21 15:28, Mikko Perttunen wrote:
On 2/21/22 17:23, Robin Murphy wrote:
On 2022-02-18 11:39, Mikko Perttunen via iommu wrote:
Add schema information for the memory-contexts property used to
specify context stream IDs. This uses the standard iommu-map property
inside a child node
channel = vic_close_channel,
.submit = tegra_drm_submit,
+ .get_streamid_offset = vic_get_streamid_offset,
The patch order seems off here, since the .get_streamid_offset member
isn't defined yet.
Robin.
};
#define NVIDIA_TEGRA_124_VIC_FIRMWARE "nvidia/tegra124/vic03_ucode.bin"
out having
to export all the low-level bus types.
Yup, as it happens that was the first step on my mission :)
https://gitlab.arm.com/linux-arm/linux-rm/-/commits/iommu/bus
Still a way to go with the main meat of that work, though, so I was
figuring this could probably land as-is and I'll sweep it up in due course.
Robin.
rf" clock. If not, then
we're back to suspecting something more insidiously wrong elsewhere.
Robin.
On 2022-02-25 13:11, Sascha Hauer wrote:
On Fri, Feb 25, 2022 at 12:41:23PM +, Robin Murphy wrote:
On 2022-02-25 11:10, Dmitry Osipenko wrote:
25.02.2022 13:49, Sascha Hauer пишет:
On Fri, Feb 25, 2022 at 01:26:14PM +0300, Dmitry Osipenko wrote:
25.02.2022 10:51, Sascha Hauer пишет:
The
15 need to ensure the CPU's instruction cache is coherent
with its data cache? Is it a self-modifying driver?
Robin.
(Note that the above is somewhat of a loaded question, and I do actually
have half an idea of what you're trying to do here and why it won't fly,
but I'd like to a
On 2022-02-28 14:19, Sascha Hauer wrote:
On Fri, Feb 25, 2022 at 02:11:54PM +0100, Sascha Hauer wrote:
On Fri, Feb 25, 2022 at 12:41:23PM +, Robin Murphy wrote:
On 2022-02-25 11:10, Dmitry Osipenko wrote:
25.02.2022 13:49, Sascha Hauer пишет:
On Fri, Feb 25, 2022 at 01:26:14PM +0300
27;s the best choice.
Reviewed-by: Robin Murphy
Cheers,
Robin.
+usable stream IDs.
+
required:
- reg-names
On 2022-02-25 19:27, Michael Cheng wrote:
Hi Robin,
[ +arm64 maintainers for their awareness, which would have been a good
thing to do from the start ]
* Thanks for adding the arm64 maintainer and sorry I didn't rope them
in sooner.
Why does i915 need to ensure the CPU's i
On 2022-03-02 15:55, Michael Cheng wrote:
Thanks for the feedback Robin!
Sorry my choices of word weren't that great, but what I meant is to
understand how ARM flushes a range of dcache for device drivers, and not
an equal to x86 clflush.
I believe the concern is if the CPU writes an u
PES);
Nit: I know nothing about this code, but from the context alone it would
seem sensible to do
if (WARN_ON(type >= TTM_NUM_MEM_TYPES))
return;
to avoid making the subsequent assignment when we *know* it's invalid
and likely to corrupt memory.
Robin.
Hi Daniel,
On 2021-10-13 18:08, Daniel Vetter wrote:
On Wed, Oct 13, 2021 at 10:36:54AM -0400, Alyssa Rosenzweig wrote:
From: Robin Murphy
drm_gem_cma_mmap() cannot assume every implementation of dma_mmap_wc()
will end up calling remap_pfn_range() (which happens to set the relevant
vma flag
ommon iommu-dma layer operates on. In fact it already uses
them to pick chunk sizes for composing large buffer allocations.
Robin.
hardware.
Conversely I recently cobbled an ancient PCI VGA card into an arm64
machine and was slightly disappointed that there didn't seem to be any
driver that was usable straight off :)
(Yes, I might give v86d + uvesafb a go at some point...)
Robin.
+ help
+ If you use a
for CEC to
function.
Wouldn't it make far more sense to just stick a suitable clk_set_rate()
call in the driver? AFAICS it's already explicitly aware of the CEC clock.
Robin.
+ power-domains = <&power RK3568_PD_VO>;
+ reg-io-width =
On 2022-01-26 18:44, Peter Geis wrote:
On Wed, Jan 26, 2022 at 12:56 PM Robin Murphy wrote:
On 2022-01-26 16:04, Peter Geis wrote:
On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer wrote:
Add support for the HDMI port found on RK3568.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts
27;s nice
symmetry with the aforementioned device_match API helpers too).
Thanks,
Robin.
+static inline void release_of(struct device *dev, void *data)
+{
+ of_node_put(data);
+}
+
+static inline int compare_dev(struct device *dev, void *data)
+{
+ return dev == data;
+}
+
void
the cross product of various kernel config
options and all PCIe-capable SoCs in existence.
Cheers,
Robin.
;
domain = iommu_get_domain_for_dev(i915->drm.dev);
if (domain && (domain->type & __IOMMU_DOMAIN_PAGING))
return true;
...
This would be okay as a first step?
Elsewhere in the thread Robin suggested looking at the dec->dma_ops and
comparing ag
e entries and registers - that sort of
thing is always tricky to get right. You're correct that that's
something that wants debugging in its own right, though.
Robin.
: linux-te...@vger.kernel.org
Signed-off-by: Robin Murphy
---
Feel free to pick this into drm-misc-next or drm-misc-fixes straight
away if that suits - it's only to avoid a build breakage once the rest
of the series gets queued.
Robin.
drivers/gpu/host1x/bus.c | 1 +
1 file changed, 1 inse
On 2021-11-23 14:10, Robin Murphy wrote:
Host1x seems to be relying on picking up dma-mapping.h transitively from
iova.h, which has no reason to include it in the first place. Fix the
former issue before we totally break things by fixing the latter one.
CC: Thierry Reding
CC: Mikko Perttunen
transitive
inclusion currently providing it is going to break soon.
Fixes: 20e7dce255e9 ("drm/tegra: Remove memory allocation from Falcon library")
Signed-off-by: Robin Murphy
---
It also doesn't appear to handle failure of the tegra_drm_alloc() path
either, but that's a loose thread
mples
of it around). So from the IOMMU perspective,
Acked-by: Robin Murphy
Perhaps the AGP driver could also be tweaked and intel_iommu_gfx_mapped
cleaned away entirely, but I'll leave that for Baolu to think about :)
Cheers,
Robin.
It was suggested to additionally
e the
for_each_sgtable_sg() helper ;)
Robin.
Signed-off-by: Guangming
---
drivers/dma-buf/heaps/system_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 23a7e74ef966..ce10d4eb674c 100644
ps, for the change itself:
Reviewed-by: Robin Murphy
Thanks,
Robin.
Signed-off-by: Guangming
---
drivers/dma-buf/heaps/system_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 23a7e74e
mask, the dma_set_mask() call
effectively does nothing and both masks will end up reading back as 32 bits.
Robin.
+ dev_dbg(&pdev->dev, "No suitable DMA available\n");
+ return -ENODEV;
+ }
+
/*
* Apply the same DMA configurati
On 2021-12-01 13:41, Lucas Stach wrote:
Hi Robin,
Am Mittwoch, dem 01.12.2021 um 12:50 + schrieb Robin Murphy:
Sorry I missed this earlier...
On 2021-09-07 17:49, Michael Walle wrote:
The STLB and the first command buffer (which is used to set up the TLBs)
has a 32 bit size restriction
lp feeling wary that defining additional names for
vendor integration details in the core binding may quickly grow into a
mess of mutually-incompatible sets of values, for no great benefit. At
the very least, it would seem more sensible to put them in the
SoC-specific conditional schemas.
Robin.
ower. Use devm_regulator_get(), and if the
real supply is missing from the DT for whatever reason you should get a
dummy regulator back, which you can then successfully disable and enable
without all the conditional mess.
Robin.
+ if (IS_ERR(hdmi->avdd_0v9)) {
+ if (PTR
D_0V9 - I'm not sure it's worth
splitting hairs that far in terms of the property name itself, but I'll
leave that for others to decide.
+ avdd-1v8-supply:
+description: A 1.8V supply that powers up the SoC internal circuitry.
At least HDMI_AVDD_1V8 seems more consis
-off-by: Robin Murphy
---
v2: No change
drivers/gpu/host1x/bus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 218e3718fd68..881fad5c3307 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -5,6 +5,7
transitive
inclusion currently providing it is going to break soon.
Fixes: 20e7dce255e9 ("drm/tegra: Remove memory allocation from Falcon library")
CC: Thierry Reding
CC: Mikko Perttunen
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Robin Murphy
---
It also doesn't appear to handle
rate that the bus .dma_configure
method isn't used?), but the SMMU patch seems fine given the Kconfig
solution to avoid module linkage problems.
Cheers,
Robin.
o match it.
I don't have access to a QHD display to test this myself; I've only
played around with weirder 4:3, 5:4 and 16:10 modes on PC monitors.
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.
map() or not.
(I'm assuming the initial fault was memset() with 0 trying to perform
"DC ZVA" on a Device-type mapping from ioremap() - FYI a stacktrace on
its own without the rest of the error dump showing what actually
triggered it isn't overly useful)
Robin.
For amdgpu
On 2020-12-17 14:02, Christian König wrote:
Am 17.12.20 um 14:45 schrieb Robin Murphy:
On 2020-12-17 10:25, Christian König wrote:
Am 17.12.20 um 02:07 schrieb Chen Li:
On Wed, 16 Dec 2020 22:19:11 +0800,
Christian König wrote:
Am 16.12.20 um 14:48 schrieb Chen Li:
On Wed, 16 Dec 2020 15:59
O mappings, which has more restrictions but stricter
ordering guarantees.
Hi, Robin. I cannot understand it allow unaligned accesses. prefetchable PCI bar should also be mmio, and accesses will end with device memory, so why does this allow unaligned access?
Because even Device-GRE is a bit too rest
On 2020-12-18 14:33, Christian König wrote:
Am 18.12.20 um 15:17 schrieb Robin Murphy:
On 2020-12-17 14:02, Christian König wrote:
[SNIP]
Do you have some background why some ARM boards fail with that?
We had a couple of reports that memset/memcpy fail in userspace
(usually system just
ving
ARM_SMMU=y and IO_PGTABLE_ARM_V7S=m, but at worst it's now a runtime
failure rather than a build error, so unless and until anyone
demonstrates that it actually matters I don't feel particularly inclined
to give it much thought.
Robin.
for having the io-pgtable formats as m
he existing one ;)
(and if you think you're concerned about memory, consider that just the
list head plus lock is already half the size of the table)
Other than that, I think this all looks pretty promising - I'd suggest
sending a non-RFC after rc1 so that it gets everyone&#x
On 2020-12-22 19:49, isa...@codeaurora.org wrote:
On 2020-12-22 11:27, Robin Murphy wrote:
On 2020-12-22 00:44, Isaac J. Manjarres wrote:
The SMMU driver depends on the availability of the ARM LPAE and
ARM V7S io-pgtable format code to work properly. In preparation
Nit: we don't r
On 2020-12-22 19:54, isa...@codeaurora.org wrote:
On 2020-12-22 11:27, Robin Murphy wrote:
On 2020-12-22 00:44, Isaac J. Manjarres wrote:
The io-pgtable code constructs an array of init functions for each
page table format at compile time. This is not ideal, as this
increases the footprint of
Include dma-mapping.h directly in the remaining places that touch the
DMA API, to avoid imminent breakage from refactoring other headers.
Signed-off-by: Robin Murphy
---
This makes arm64 allmodconfig build cleanly for me with the IOVA series,
so hopefully is the last of it...
drivers/gpu/drm
e than a year after
that commit ;)
As an improvement rather than a fix, though,
Reviewed-by: Robin Murphy
Signed-off-by: Lu Baolu
---
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/
-coherent and you're missing the
"dma-coherent" property in your DT.
Thanks,
Robin.
Signed-off-by: Alexey Sheplyakov
Signed-off-by: Vadim V. Vlasov
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Vadim V. Vlasov
---
drivers/gpu/drm/panf
precedence, so revert this change until the real underlying
problem can be fixed.
Signed-off-by: Robin Murphy
---
Alex, Ben, Dave,
I know Alex was looking into this, but since we're nearly at -rc6 already
it looks like the only thing to do for 4.6 is pick the lesser of two evils...
T
ueried the appropriate value from MMU_FEATURES, but as soon as
reasonably possible after that should suffice.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 5 -
drivers/gpu/drm/panfrost/panfrost_gpu.c | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git
, RAM above 4GB, and DVFS abstracted behind a firmware
interface.
Robin.
Robin Murphy (4):
drm/panfrost: Set DMA masks earlier
drm/panfrost: Disable PM on probe failure
drm/panfrost: Don't scream about deferred probe
drm/panfrost: Show stored feature registers
drivers/gpu/dr
Make sure to disable runtime PM again if probe fails after we've enabled
it. Otherwise, any subsequent attempt to re-probe starts triggering
"Unbalanced pm_runtime_enable!" assertions from the driver core.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/panfrost/panfrost_drv.
ned-off-by: Robin Murphy
---
Just in case anyone else is interested. Note that I've not been using
this exact patch, since my Juno is running the new SCMI-based firmware
which needs not-yet-upstream MHU changes, but this should in theory be
the equivalent change for the upstrea
1 - 100 of 570 matches
Mail list logo
