Hi, Bjorn,
On Sun, Jun 6, 2021 at 1:59 AM Bjorn Helgaas wrote:
>
> On Sat, Jun 05, 2021 at 10:02:05AM +0800, Huacai Chen wrote:
> > On Sat, Jun 5, 2021 at 3:56 AM Bjorn Helgaas wrote:
> > > On Fri, Jun 04, 2021 at 12:50:03PM +0800, Huacai Chen wrote:
> > > > On Thu, Jun 3, 2021 at 2:31 AM Bjorn
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c: In function ‘vmw_vram_manager_init’:
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:678:8: error: implicit declaration of
function ‘ttm_range_man_init’;
did you mean ‘ttm_tt_mgr_init’? [-Werror=implicit-function-declaration]
ret = ttm_range_man_init(_priv->bdev,
https://bugzilla.kernel.org/show_bug.cgi?id=213391
--- Comment #10 from dimit...@gmail.com ---
Seeing the same thing on a T495 running Fedora 33 and Wayland, typically
involving Firefox: https://bugzilla.redhat.com/show_bug.cgi?id=1966384
Would it be possible for me to try that patch?
--
You
Add entry for i915 GuC submission / DRM scheduler integration plan.
Follow up patch with details of new parallel submission uAPI to come.
v2:
(Daniel Vetter)
- Expand explaination of why bonding isn't supported for GuC
submission
- CC some of the DRM scheduler maintainers
- Add
Add entry for i915 new parallel submission uAPI plan.
v2:
(Daniel Vetter):
- Expand logical order explaination
- Add dummy header
- Only allow N BBs in execbuf IOCTL
- Configure parallel submission per slot not per gem context
v3:
(Marcin Ślusarz):
- Lot's of typos / bad english fixed
Subject and patches say it all.
v2: Address comments, patches have details of changes
v3: Address comments, patches have details of changes
v4: Address comments, patches have details of changes
Signed-off-by: Matthew Brost
Matthew Brost (2):
drm/doc/rfc: i915 GuC submission / DRM scheduler
haha. turns out it actually was a good thing I was busy with work today,
because I ended up testing some backports and running into the exact same MST
bug these patches appear to fix. How convienent :)
anyway-I looked over this and this looks good to me (and IMO, I like these
fixes more then the
Understood. I saw weston client apps were failing to create render buffers
from kmsro driver and found it was because they were not allowed to
create and destroy dumb objects then I came up with this patch. I just thought
it's the simplest solution. I didn't know it violates the rule. I think I
The SPI access to s6e63m0 is using the DBI protocol, so switch
to using the elaborate DBI protocol implementation in the DRM
DBI helper library.
Cc: Douglas Anderson
Cc: Noralf Trønnes
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/panel/Kconfig | 1 +
Default list_limit and size_limit_mb are not big enough to cover all
possible use cases. For example, list_limit could be well over its default,
1024 if only one or several pages are chained in all individual list entries
when creating dmabuf backed by >4MB buffer. list_limit and size_limit_mb are
Add a small description and document struct fields of
drm_mode_get_plane.
Signed-off-by: Leandro Ribeiro
---
include/uapi/drm/drm_mode.h | 32
1 file changed, 32 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index
v2: possible_crtcs field is a bitmask, not a pointer. Suggested by
Ville Syrjälä
v3: document how userspace should find out CRTC index. Also,
document that field 'gamma_size' represents the number of
entries in the lookup table. Suggested by Pekka Paalanen
and Daniel Vetter
v4: document IN
Implement SPI reads for typec1, for SPI controllers that
can support 9bpw in addition to 8bpw (such as GPIO bit-banged
SPI).
9bpw emulation is not supported but we have to start with
something.
This is used by s6e63m0 to read display MTP information
which is used by the driver for backlight
On 6/11/21 4:33 AM, Daniel Vetter wrote:
> On Fri, Jun 11, 2021 at 9:20 AM Pekka Paalanen wrote:
>>
>> On Thu, 10 Jun 2021 17:38:24 -0300
>> Leandro Ribeiro wrote:
>>
>>> Add a small description and document struct fields of
>>> drm_mode_get_plane.
>>>
>>> Signed-off-by: Leandro Ribeiro
>>>
Just a heads up, your sender email and your signed-off-by don't match
and you had some assignments in if clauses. I've fixed those up.
Alex
On Fri, Jun 11, 2021 at 1:35 PM Alex Deucher wrote:
>
> Applied. Thanks!
>
> On Thu, Jun 10, 2021 at 5:14 PM Harry Wentland wrote:
> >
> >
> >
> > On
https://bugzilla.kernel.org/show_bug.cgi?id=213053
Jonathan Farrugia (jonfar...@gmail.com) changed:
What|Removed |Added
CC|
On Fri, Jun 04, 2021 at 07:59:05PM +0200, Daniel Vetter wrote:
> On Wed, May 26, 2021 at 04:33:57PM -0700, Matthew Brost wrote:
> > Add entry for i915 new parallel submission uAPI plan.
> >
> > v2:
> > (Daniel Vetter):
> > - Expand logical order explaination
> > - Add dummy header
> > -
Hi,
On Fri, Jun 11, 2021 at 10:18 AM Douglas Anderson wrote:
>
> The primary goal of this series is to try to properly fix EDID reading
> for eDP panels using the ti-sn65dsi86 bridge.
>
> Previously we had a patch that added EDID reading but it turned out
> not to work at bootup. This caused
The pull request you sent on Fri, 11 Jun 2021 13:41:34 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-06-11
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f21b807c3cf8cd7c5ca9e406b27bf1cd2f1c1238
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, Jun 11, 2021 at 10:07 AM Linus Torvalds
wrote:
>
> I think anongit.freedesktop.org is sick. Can you ask somebody to give
> it some tender loving? It's just disconnecting immediately..
Either somebody gave the site a hug, or it decided to just get better
on its own. It's working now,
On Fri, Jun 11, 2021 at 2:01 AM Dmitry Baryshkov
wrote:
>
> Hi,
>
> On Fri, 11 Jun 2021 at 10:07, John Stultz wrote:
> >
> > On Wed, Mar 31, 2021 at 3:58 AM Dmitry Baryshkov
> > wrote:
> > >
> > > The 7nm, 10nm and 14nm drivers would store interim data used during
> > > VCO/PLL rate setting in
On Thu, Jun 10, 2021 at 03:35:57PM +0200, Michal Wajdeczko wrote:
>
>
> On 10.06.2021 06:36, Matthew Brost wrote:
> > As part of enabling GuC submission [1] we need to update to the latest
> > and greatest firmware. This series does that. This is a destructive
> > change. e.g. Without all the
On Mon, Jun 07, 2021 at 03:19:11PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
> > As part of enabling GuC submission [1] we need to update to the latest
> > and greatest firmware. This series does that. This is a destructive
> > change. e.g. Without all
On Thu, Jun 10, 2021 at 03:19:50PM +0200, Michal Wajdeczko wrote:
>
>
> On 10.06.2021 06:38, Matthew Brost wrote:
> > On Wed, Jun 09, 2021 at 10:07:21PM +0200, Michal Wajdeczko wrote:
> >>
> >>
> >> On 09.06.2021 19:36, John Harrison wrote:
> >>> On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
On Friday 11 June 2021 14:38:18 Christian König wrote:
>
> Am 10.06.21 um 19:59 schrieb Christian König:
> > Am 10.06.21 um 19:50 schrieb Ondrej Zary:
> >> [SNIP]
> >>> I can't see how this is called from the nouveau code, only
> >>> possibility I
> >>> see is that it is maybe called through the
Applied. Thanks!
On Thu, Jun 10, 2021 at 5:14 PM Harry Wentland wrote:
>
>
>
> On 2021-06-07 10:53 a.m., Mark Yacoub wrote:
> > On Fri, Jun 4, 2021 at 4:17 PM Harry Wentland
> > wrote:
> >>
> >>
> >>
> >> On 2021-06-04 1:01 p.m., Mark Yacoub wrote:
> >>> From: Mark Yacoub
> >>>
> >>> For
This is really just a revert of commit 58074b08c04a ("drm/bridge:
ti-sn65dsi86: Read EDID blob over DDC"), resolving conflicts.
The old code failed to read the EDID properly in a very important
case: before the bridge's pre_enable() was called. The way things need
to work:
1. Read the EDID.
2.
Putting the panel under the bridge chip (under the aux-bus node)
allows the panel driver to get access to the DP AUX bus, enabling all
sorts of fabulous new features.
While we're at this, get rid of a level of hierarchy for the panel
node. It doesn't need "ports / port" and can just have a "port"
As I was testing to make sure that the DEFER path worked well with my
patch series, I got tired of seeing this scary message in my logs just
because the panel needed to defer:
[drm:ti_sn_bridge_probe] *ERROR* could not find any panel node
Let's use dev_err_probe() which nicely quiets this error
On its own, this change looks a little strange and doesn't do too much
useful. To understand why we're doing this we need to look forward to
future patches where we're going to probe our panel using the new DP
AUX bus. See the patch ("drm/bridge: ti-sn65dsi86: Add support for the
DP AUX bus").
We want to provide our panel with access to the DP AUX channel. The
way to do this is to let our panel be a child of ours using the fancy
new DP AUX bus support.
Signed-off-by: Douglas Anderson
Acked-by: Linus Walleij
Reviewed-by: Lyude Paul
---
(no changes since v9)
Changes in v9:
- Rebased
If panel-simple is instantiated as a DP AUX bus endpoint then we have
access to the DP AUX bus. Let's stash it in the panel-simple
structure, leaving it NULL for the cases where the panel is
instantiated in other ways.
If we happen to have access to the DP AUX bus and we weren't provided
the
The panel-simple driver can already have devices instantiated as
platform devices or MIPI DSI devices. Let's add a 3rd way to
instantiate it: as DP AUX endpoint devices.
At the moment there is no benefit to instantiating it in this way,
but:
- In the next patch we'll give it access to the DDC
Historically "simple" eDP panels have been handled by panel-simple
which is a basic platform_device. In the device tree, the panel node
was at the top level and not connected to anything else.
Let's change it so that, instead, panels can be represented as being
children of the "DP AUX bus".
The patch ("dt-bindings: drm: Introduce the DP AUX bus") talks about
how using the DP AUX bus is better than learning how to slice
bread. Let's add it to the ti-sn65dsi86 bindings.
Signed-off-by: Douglas Anderson
Reviewed-by: Rob Herring
Reviewed-by: Linus Walleij
---
(no changes since v9)
We want to be able to list an eDP panel as a child of an eDP
controller node to represent the fact that the panel is connected to
the controller's DP AUX bus. Though the panel and the controller are
connected in several ways, the DP AUX bus is the primary control
interface between the two and thus
The HPD (Hot Plug Detect) signal is present in many (probably even
"most") eDP panels. For eDP, this signal isn't actually used for
detecting hot-plugs of the panel but is more akin to a "panel ready"
signal. After you provide power to the panel, panel timing diagrams
typically say that you should
The primary goal of this series is to try to properly fix EDID reading
for eDP panels using the ti-sn65dsi86 bridge.
Previously we had a patch that added EDID reading but it turned out
not to work at bootup. This caused some extra churn at bootup as we
tried (and failed) to read the EDID several
On Thu, Jun 10, 2021 at 8:41 PM Dave Airlie wrote:
>
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-06-11
I think anongit.freedesktop.org is sick. Can you ask somebody to give
it some tender loving? It's just disconnecting immediately..
Linus
Handling of the interrupt callback lists is done in dpu_core_irq.c,
under the "cb_lock" spinlock. When these operations results in the need
for enableing or disabling the IRQ in the hardware the code jumps to
dpu_hw_interrupts.c, which protects its operations with "irq_lock"
spinlock.
When an
Hi Dave,
The following changes since commit 671cc352acd3e2b2832b59787ed8027d9f80ccc9:
drm/tegra: Correct DRM_FORMAT_MOD_NVIDIA_SECTOR_LAYOUT (2021-05-31 14:29:44
+0200)
are available in the Git repository at:
ssh://git.freedesktop.org/git/tegra/linux.git tags/drm/tegra/for-5.14-rc1
for
Some comments down below:
On Mon, 2021-06-07 at 10:05 -0700, Douglas Anderson wrote:
> Historically "simple" eDP panels have been handled by panel-simple
> which is a basic platform_device. In the device tree, the panel node
> was at the top level and not connected to anything else.
>
> Let's
On Fri, Jun 11, 2021 at 6:31 PM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> A little bit of documentation covering the topics of engine discovery,
> context engine maps and virtual engines. It is not very detailed but
> supposed to be a starting point of giving a brief high level overview
On Fri, 11 Jun 2021 at 15:55, Thomas Hellström
wrote:
>
> For discrete, use TTM for both cached and WC system memory. That means
> we currently rely on the TTM memory accounting / shrinker. For cached
> system memory we should consider remaining shmem-backed, which can be
> implemented from our
From: Tvrtko Ursulin
A little bit of documentation covering the topics of engine discovery,
context engine maps and virtual engines. It is not very detailed but
supposed to be a starting point of giving a brief high level overview of
general principles and intended use cases.
Signed-off-by:
On Fri, 11 Jun 2021 at 15:55, Thomas Hellström
wrote:
>
> After a TTM move we need to update the i915 gem flags and caching
> settings to reflect the new placement.
> Also introduce gpu_binds_iomem() and cpu_maps_iomem() to clean up the
> various ways we previously used to detect this.
> Finally,
On Fri, 11 Jun 2021 at 15:55, Thomas Hellström
wrote:
>
> The object ops i915_GEM_OBJECT_HAS_IOMEM and the object
> I915_BO_ALLOC_STRUCT_PAGE flags are considered immutable by
> much of our code. Introduce a new mem_flags member to hold these
> and make sure checks for these flags being set are
On Fri, 11 Jun 2021 at 15:55, Thomas Hellström
wrote:
>
> Instead of relying on a static placement, calculate at get_pages() time.
> This should work for LMEM regions and system for now. For stolen we need
> to take preallocated range into account. That well be added later.
That will be
>
>
I don't have the HW to verify the change. Hopefully I use the right
device struct for is_swiotlb_active.
I'm not sure if this would break arch/x86/pci/sta2x11-fixup.c
swiotlb_late_init_with_default_size is called here
https://elixir.bootlin.com/linux/v5.13-rc5/source/arch/x86/pci/sta2x11-fixup.c#L60
On Fri, Jun 11, 2021 at 11:27 PM Claire Chang wrote:
>
> Always have the pointer to the swiotlb pool
v9 here: https://lore.kernel.org/patchwork/cover/1445081/
On Mon, Jun 7, 2021 at 11:28 AM Claire Chang wrote:
>
> On Sat, Jun 5, 2021 at 1:48 AM Will Deacon wrote:
> >
> > Hi Claire,
> >
> > On Thu, May 27, 2021 at 08:58:30PM +0800, Claire Chang wrote:
> > > This series implements mitigations
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 33 +
drivers/of/device.c | 3 +++
drivers/of/of_private.h | 6
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 reserved-memory node.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 36
The restricted DMA pool is preferred if available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system
needs to provide a way to lock
Add the functions, swiotlb_{alloc,free} to support the memory allocation
from restricted DMA pool.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 15 +++
kernel/dma/swiotlb.c| 35 +--
2 files changed, 48 insertions(+), 2 deletions(-)
Add a new wrapper __dma_direct_free_pages() that will be useful later
for swiotlb_free().
Signed-off-by: Claire Chang
---
kernel/dma/direct.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index
Add a new function, release_slots, to make the code reusable for supporting
different bounce buffer pools, e.g. restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git
Move the maintenance of alloc_size to find_slots for better code
reusability later.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index e5ccc198d0a7..364c6c822063
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
drivers/pci/xen-pcifront.c
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/iommu/dma-iommu.c | 12 ++--
drivers/xen/swiotlb-xen.c | 2 +-
include/linux/swiotlb.h | 7 ---
kernel/dma/direct.c
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 3 +-
kernel/dma/Kconfig | 14
kernel/dma/swiotlb.c| 75 +
3 files changed, 91
Always have the pointer to the swiotlb pool used in struct device. This
could help simplify the code for other pools.
Signed-off-by: Claire Chang
---
drivers/of/device.c | 3 +++
include/linux/device.h | 4
include/linux/swiotlb.h | 8
kernel/dma/swiotlb.c| 8
4
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools, e.g. restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/swiotlb.c
Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 53 ++--
1 file changed, 27 insertions(+), 26 deletions(-)
diff --git
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for
On Fri, Jun 11, 2021 at 09:53:19AM +0300, Tomi Valkeinen wrote:
> On 11/06/2021 08:54, Maxime Ripard wrote:
> > Hi,
> >
> > On Thu, Jun 10, 2021 at 11:00:05PM +0200, Daniel Vetter wrote:
> > > On Thu, Jun 10, 2021 at 7:47 PM Maxime Ripard wrote:
> > > >
> > > > New KMS properties come with a
On Fri, Jun 11, 2021 at 12:12:45PM +0200, Christian König wrote:
> Am 11.06.21 um 11:17 schrieb Daniel Vetter:
> > On Thu, Jun 10, 2021 at 11:18:00AM +0200, Christian König wrote:
> > > Drop the workaround and instead implement a better solution.
> > >
> > > Basically we are now chaining all
On Fri, Jun 11, 2021 at 12:09:19PM +0200, Christian König wrote:
> Am 11.06.21 um 11:07 schrieb Daniel Vetter:
> > On Thu, Jun 10, 2021 at 11:17:59AM +0200, Christian König wrote:
> > > Unwrap a the explicit fence if it is a dma_fence_chain and
> > > sync to the first fence not matching the owner
On Fri, Jun 11, 2021 at 12:07:00PM +0200, Christian König wrote:
> Am 11.06.21 um 10:58 schrieb Daniel Vetter:
> > On Thu, Jun 10, 2021 at 11:17:57AM +0200, Christian König wrote:
> > > Add some rather sophisticated lockless garbage collection
> > > for dma_fence_chain objects.
> > >
> > > For
Am 11.06.21 um 16:56 schrieb Daniel Vetter:
On Fri, Jun 11, 2021 at 02:03:01PM +0200, Christian König wrote:
Drop the workaround and instead implement a better solution.
Basically we are now chaining all submissions using a dma_fence_chain
container and adding them as exclusive fence to the
On Fri, Jun 11, 2021 at 12:03:31PM +0200, Christian König wrote:
> Am 11.06.21 um 11:33 schrieb Daniel Vetter:
> > On Fri, Jun 11, 2021 at 09:42:07AM +0200, Christian König wrote:
> > > Am 11.06.21 um 09:20 schrieb Daniel Vetter:
> > > > On Fri, Jun 11, 2021 at 8:55 AM Christian König
> > > >
On Fri, Jun 11, 2021 at 01:43:20PM +1000, Alistair Popple wrote:
> On Friday, 11 June 2021 11:00:34 AM AEST Peter Xu wrote:
> > On Fri, Jun 11, 2021 at 09:17:14AM +1000, Alistair Popple wrote:
> > > On Friday, 11 June 2021 9:04:19 AM AEST Peter Xu wrote:
> > > > On Fri, Jun 11, 2021 at 12:21:26AM
On Fri, Jun 11, 2021 at 02:03:01PM +0200, Christian König wrote:
> Drop the workaround and instead implement a better solution.
>
> Basically we are now chaining all submissions using a dma_fence_chain
> container and adding them as exclusive fence to the dma_resv object.
>
> This way other
On Fri, Jun 11, 2021 at 04:53:11PM +0200, Christian König wrote:
>
>
> Am 11.06.21 um 16:47 schrieb Daniel Vetter:
> > On Fri, Jun 11, 2021 at 02:02:57PM +0200, Christian König wrote:
> > > As the name implies if testing all fences is requested we
> > > should indeed test all fences and not skip
For discrete, use TTM for both cached and WC system memory. That means
we currently rely on the TTM memory accounting / shrinker. For cached
system memory we should consider remaining shmem-backed, which can be
implemented from our ttm_tt_populate calback. We can then also reuse our
own very
After a TTM move we need to update the i915 gem flags and caching
settings to reflect the new placement.
Also introduce gpu_binds_iomem() and cpu_maps_iomem() to clean up the
various ways we previously used to detect this.
Finally, initialize the TTM object reserved to be able to update
flags and
Instead of relying on a static placement, calculate at get_pages() time.
This should work for LMEM regions and system for now. For stolen we need
to take preallocated range into account. That well be added later.
Signed-off-by: Thomas Hellström
---
v2:
- Fixed a style issue (Reported by Matthew
The object ops i915_GEM_OBJECT_HAS_IOMEM and the object
I915_BO_ALLOC_STRUCT_PAGE flags are considered immutable by
much of our code. Introduce a new mem_flags member to hold these
and make sure checks for these flags being set are either done
under the object lock or with pages properly pinned.
Early implementation of moving system memory for discrete cards over to
TTM. We first add the notion of objects being migratable under the object
lock to i915 gem, and add some asserts to verify that objects are either
locked or pinned when the placement is checked by the gem code.
Patch 2 and 3
Am 11.06.21 um 16:52 schrieb Daniel Vetter:
On Fri, Jun 11, 2021 at 02:02:59PM +0200, Christian König wrote:
Add a common allocation helper. Cleaning up the mix of kzalloc/kmalloc
and some unused code in the selftest.
v2: polish kernel doc a bit
Signed-off-by: Christian König
Reviewed-by:
Am 11.06.21 um 16:47 schrieb Daniel Vetter:
On Fri, Jun 11, 2021 at 02:02:57PM +0200, Christian König wrote:
As the name implies if testing all fences is requested we
should indeed test all fences and not skip the exclusive
one because we see shared ones.
Signed-off-by: Christian König
Hm
On Fri, Jun 11, 2021 at 02:02:59PM +0200, Christian König wrote:
> Add a common allocation helper. Cleaning up the mix of kzalloc/kmalloc
> and some unused code in the selftest.
>
> v2: polish kernel doc a bit
>
> Signed-off-by: Christian König
> Reviewed-by: Daniel Vetter
Given how
On Fri, Jun 11, 2021 at 02:02:57PM +0200, Christian König wrote:
> As the name implies if testing all fences is requested we
> should indeed test all fences and not skip the exclusive
> one because we see shared ones.
>
> Signed-off-by: Christian König
Hm I thought we've had the rule that when
On Fri, Jun 11, 2021 at 1:48 PM Christian König
wrote:
>
> Am 11.06.21 um 09:54 schrieb Daniel Vetter:
> > On Thu, Jun 10, 2021 at 11:17:55AM +0200, Christian König wrote:
> >> Add a common allocation helper. Cleaning up the mix of kzalloc/kmalloc
> >> and some unused code in the selftest.
> >>
>
On Fri, 11 Jun 2021 at 14:22, Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> Just tidy one instance of incorrect context parameter name and a stray
> sentence ending from before reporting was converted to be class based.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Matthew Auld
If memory allocation fails, `node->base.imem` does not get populated,
causing a NULL pointer dereference on instobj destruction. Fix this
by dereferencing it only if the allocation was successful.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 4 ++--
1
On Thu, Jun 10, 2021 at 02:44:13PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Wire up support to stall the SMMU on iova fault, and collect a devcore-
> dump snapshot for easier debugging of faults.
>
> Currently this is a6xx-only, but mostly only because so far it is the
> only one using
On Thu, Jun 10, 2021 at 02:44:12PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Add, via the adreno-smmu-priv interface, a way for the GPU to request
> the SMMU to stall translation on faults, and then later resume the
> translation, either retrying or terminating the current translation.
>
>
On Fri, Jun 11, 2021 at 08:56:04AM -0400, Alyssa Rosenzweig wrote:
> > What I'm expected to see in the future is new functionality that gets
> > implemented by
> > one hardware vendor and the kernel developers trying to enable that for
> > userspace. It
> > could be that the new property is
From: Tvrtko Ursulin
Just tidy one instance of incorrect context parameter name and a stray
sentence ending from before reporting was converted to be class based.
Signed-off-by: Tvrtko Ursulin
---
include/uapi/drm/i915_drm.h | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff
> What I'm expected to see in the future is new functionality that gets
> implemented by
> one hardware vendor and the kernel developers trying to enable that for
> userspace. It
> could be that the new property is generic, but there is no way of testing
> that on
> more than one implementation
On Mon, Jun 07 2021, Jason Gunthorpe wrote:
> For some reason the vfio_mdev shim mdev_driver has its own module and
> kconfig. As the next patch requires access to it from mdev.ko merge the
> two modules together and remove VFIO_MDEV_DEVICE.
>
> A later patch deletes this driver entirely.
>
>
Am 10.06.21 um 19:59 schrieb Christian König:
Am 10.06.21 um 19:50 schrieb Ondrej Zary:
[SNIP]
I can't see how this is called from the nouveau code, only
possibility I
see is that it is maybe called through the AGP code somehow.
Yes, you're right:
[ 13.192663] Call Trace:
[ 13.192678]
On Fri, Jun 11, 2021 at 08:14:59AM +, Simon Ser wrote:
> On Thursday, June 10th, 2021 at 23:00, Daniel Vetter
> wrote:
>
> > If there's a strong consensus that we really need this then I'm not
> > going to nack this, but this really needs a pile of acks from
> > compositor folks that
Unwrap the explicit fence if it is a dma_fence_chain and
sync to the first fence not matching the owner rules.
Signed-off-by: Christian König
Acked-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 118 +--
1 file changed, 68 insertions(+), 50 deletions(-)
The callback and the irq work are never used at the same
time. Putting them into an union saves us 24 bytes and
makes the structure only 120 bytes in size.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
---
drivers/dma-buf/dma-fence-chain.c | 2 +-
include/linux/dma-fence-chain.h
Add a common allocation helper. Cleaning up the mix of kzalloc/kmalloc
and some unused code in the selftest.
v2: polish kernel doc a bit
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
---
drivers/dma-buf/st-dma-fence-chain.c | 16 -
Drop the workaround and instead implement a better solution.
Basically we are now chaining all submissions using a dma_fence_chain
container and adding them as exclusive fence to the dma_resv object.
This way other drivers can still sync to the single exclusive fence
while amdgpu only sync to
As the name implies if testing all fences is requested we
should indeed test all fences and not skip the exclusive
one because we see shared ones.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 33 -
1 file changed, 12 insertions(+), 21
1 - 100 of 153 matches
Mail list logo
