On Fri, Jun 4, 2021 at 11:57 PM Kai-Heng Feng
wrote:
>
> On Thu, May 20, 2021 at 2:58 PM Kai-Heng Feng
> wrote:
> >
> > On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
> > to discrete GFX after S3. This is not desirable, because userspace will
> > treat connected display a
On Thu, 10 Jun 2021 16:14:42 -0500
Jason Ekstrand wrote:
> This adds a new "DMA Buffer ioctls" section to the dma-buf docs and adds
> documentation for DMA_BUF_IOCTL_SYNC.
>
> v2 (Daniel Vetter):
> - Fix a couple typos
> - Add commentary about synchronization with other devices
> - Use item l
On Fri, Jun 04, 2021 at 09:48:39PM +0200, Hans de Goede wrote:
> Make dp_altmode_notify() handle the dp->data.conf == 0 case too,
> rather then having separate code-paths for this in various places
> which call it.
>
> Reviewed-by: Heikki Krogerus
> Tested-by: Heikki Krogerus
> Signed-off-by: Ha
On Fri, Jun 04, 2021 at 09:48:40PM +0200, Hans de Goede wrote:
> Use the new drm_connector_oob_hotplug_event() functions to let drm/kms
> drivers know about DisplayPort over Type-C hotplug events.
>
> Reviewed-by: Heikki Krogerus
> Tested-by: Heikki Krogerus
> Signed-off-by: Hans de Goede
Revi
On Fri, Jun 04, 2021 at 09:48:32PM +0200, Hans de Goede wrote:
> Here is v3 of my patchset making DP over Type-C work on devices where the
> Type-C controller does not drive the HPD pin on the GPU, but instead
> we need to forward HPD events from the Type-C controller to the DRM driver.
>
> Change
Hello Bhanu,
Sorry for the trouble. Kindly can you check if rev 3 is okay? Thanks a lot.
Regards
Vidya
-Original Message-
From: Srinivas, Vidya
Sent: Friday, June 11, 2021 6:28 PM
To: Modem, Bhanuprakash ;
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: RE: [Int
On Mon, Jun 14, 2021 at 08:04:03PM +0530, Kirti Wankhede wrote:
> Jason,
>
> I couldn't find patch 1,2,4 and 5 of these series. Can you please keep
> k...@vger.kernel.org cc for all patches?
It is an error, sorry
> Also it will be helpful if you can add version prefix, eg. 'v3' for this
> series
On Mon, Jun 14, 2021 at 05:08:40PM +0200, Christoph Hellwig wrote:
> @@ -679,8 +666,6 @@ static int really_probe(struct device *dev, struct
> device_driver *drv)
> dev->pm_domain->dismiss(dev);
> pm_runtime_reinit(dev);
> dev_pm_set_driver_flags(dev, 0);
> - if (prob
Hi,
On 6/15/21 9:40 AM, Greg Kroah-Hartman wrote:
> On Fri, Jun 04, 2021 at 09:48:32PM +0200, Hans de Goede wrote:
>> Here is v3 of my patchset making DP over Type-C work on devices where the
>> Type-C controller does not drive the HPD pin on the GPU, but instead
>> we need to forward HPD events f
On Mon, Jun 14, 2021 at 08:34:31PM -0700, Matt Roper wrote:
> From: Daniele Ceraolo Spurio
>
> New steering cases will be added in the follow-up patches, so prepare a
> common helper to avoid code duplication.
>
> Cc: Tvrtko Ursulin
> Signed-off-by: Daniele Ceraolo Spurio
> Signed-off-by: Matt
== Series Details ==
Series: drm/i915/ehl: Update MOCS table for EHL (rev3)
URL : https://patchwork.freedesktop.org/series/61409/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10222_full -> Patchwork_20360_full
Summary
On 14.06.2021 21:42, Matthew Brost wrote:
> From: Michal Wajdeczko
>
> Most of the changes to the 62.0.0 firmware revolved around CTB
> communication channel. Conform to the new (stable) CTB protocol.
>
> Signed-off-by: John Harrison
> Signed-off-by: Michal Wajdeczko
> Signed-off-by: Matthe
On Mon, Jun 14, 2021 at 08:34:32PM -0700, Matt Roper wrote:
> Although most of our multicast registers are replicated per-subslice, we
> also have a small number of multicast registers that are replicated
> per-l3 bank instead. For both types of multicast registers we need to
> make sure we steer
On Tue, Jun 15, 2021 at 05:08:20AM -0400, Rodrigo Vivi wrote:
> On Mon, Jun 14, 2021 at 08:34:32PM -0700, Matt Roper wrote:
> > Although most of our multicast registers are replicated per-subslice, we
> > also have a small number of multicast registers that are replicated
> > per-l3 bank instead.
== Series Details ==
Series: series starting with [01/10] driver core: Pull required checks into
driver_probe_device()
URL : https://patchwork.freedesktop.org/series/91461/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10222_full -> Patchwork_20361_full
==
From: Tvrtko Ursulin
When a non-persistent context exits we currently mark it as banned in
order to trigger fast termination of any outstanding GPU jobs it may have
left running.
In doing so we apply a very strict 1ms limit in which the left over job
has to preempt before we issues an engine res
Invokes the pipelined page migration through blt, for
i915_ttm_move requests of eviction and also obj clear.
v2:
- subfunction for accel_move (Thomas)
- engine_pm_get/put around context_move/clear (Thomas)
- Invalidation at accel_clear (Thomas)
v3:
- Timeout is set for MAX_SCHEDULE_TIMEOUT (T
On Mon, Jun 14, 2021 at 05:18:51PM +0530, Tejas Upadhyay wrote:
> When pipe A is disabled and MIPI DSI is enabled on pipe B,
> the AMT KVMR feature will incorrectly see pipe A as enabled.
> Set 0x42080 bit 23=1 before enabling DSI on pipe B and leave
> it set while DSI is enabled on pipe B. No impa
On 15/06/2021 04:34, Matt Roper wrote:
Because Render Power Gating restricts us to just a single subslice as a
valid steering target for reads of multicast registers in a SUBSLICE
range, the default steering we setup at init may not lead to a suitable
target for L3BANK multicast register. In c
== Series Details ==
Series: i915 TTM sync accelerated migration and clear
URL : https://patchwork.freedesktop.org/series/91463/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10222_full -> Patchwork_20362_full
Summary
-
On Mon, Jun 14 2021, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> Checking if the dev is dead or if the dev is already bound is a required
> precondition to invoking driver_probe_device(). All the call chains
> leading here duplicate these checks.
>
> Add it directly to driver_probe_devi
On Mon, Jun 14 2021, Christoph Hellwig wrote:
> Currently really_probe() returns 1 on success and 0 if the probe() call
> fails. This return code arrangement is designed to be useful for
> __device_attach_driver() which is walking the device list and trying every
> driver. 0 means to keep trying.
On Mon, Jun 14 2021, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> This is intended as a replacement API for device_bind_driver(). It has at
> least the following benefits:
>
> - Internal locking. Few of the users of device_bind_driver() follow the
> locking rules
>
> - Calls device dri
On Mon, Jun 14 2021, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> 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
On Mon, Jun 14 2021, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> This allows a mdev driver to opt out of using vfio_mdev.c, instead the
> driver will provide a 'struct mdev_driver' and register directly with the
> driver core.
>
> Much of mdev_parent_ops becomes unused in this mode:
> -
== Series Details ==
Series: drm/i915: Move system memory to TTM for discrete (rev5)
URL : https://patchwork.freedesktop.org/series/90898/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10222_full -> Patchwork_20363_full
Sum
When pipe A is disabled and MIPI DSI is enabled on pipe B,
the AMT KVMR feature will incorrectly see pipe A as enabled.
Set 0x42080 bit 23=1 before enabling DSI on pipe B and leave
it set while DSI is enabled on pipe B. No impact to setting
it all the time.
Changes since V5:
- Added review
On Thu, May 27, 2021 at 3:42 PM Hsin-Yi Wang wrote:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in
To help avoid evicting already resident buffers from the batch we're
processing, perform locking as a separate step.
Signed-off-by: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 25 ---
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/
== Series Details ==
Series: i915 TTM sync accelerated migration and clear (rev2)
URL : https://patchwork.freedesktop.org/series/91463/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile
== Series Details ==
Series: Update firmware to v62.0.0 (rev3)
URL : https://patchwork.freedesktop.org/series/91106/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10222_full -> Patchwork_20364_full
Summary
---
**SUCC
== Series Details ==
Series: drm/i915: Be more gentle with exiting non-persistent context (rev4)
URL : https://patchwork.freedesktop.org/series/89644/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10225 -> Patchwork_20366
S
== Series Details ==
Series: drm/i915/jsl: Add W/A 1409054076 for JSL (rev6)
URL : https://patchwork.freedesktop.org/series/90129/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10225 -> Patchwork_20368
Summary
---
**
Fix two memory leaks introduced with the ttm backend.
Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_
Op 15-06-2021 om 14:24 schreef Thomas Hellström:
> Fix two memory leaks introduced with the ttm backend.
>
> Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
> Signed-off-by: Thomas Hellström
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 ++
> 1 file changed, 2
== Series Details ==
Series: drm/i915: Perform execbuffer object locking as a separate step
URL : https://patchwork.freedesktop.org/series/91506/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10225 -> Patchwork_20369
Summar
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, June 10, 2021 11:12 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Chiu
> Subject: [Intel-gfx] [PATCH] drm/i915: Force a TypeC PHY disconnect during
> suspend/shutdown
>
> Disconnect TypeC PHYs du
This patchset implements synchronous accelerated migration and clearing
for i915 on TTM. We plan to follow up with these operations made
asynchronous to the extent of TTM support for that:
A couple of patches from Chris which implement pipelined migration and
clears by atomically writing the PTEs
As we're about to add more ww-related functionality,
break out the dma_resv ww locking utilities to their own files
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2:
- Make sure filenames are sorted in include file lists and Makefile
(Reported by Matthew Auld)
---
drivers/gpu/
Since the ww transaction endpoint easily end up far out-of-scope of
the objects on the ww object list, particularly for contending lock
objects, make sure we reference objects on the list so they don't
disappear under us.
This comes with a performance penalty so it's been debated whether this
is r
From: Chris Wilson
In the next patch, we will want to write a PTE for an explicit
dma address, outside of the usual vma.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/driv
From: Chris Wilson
In the next patch, we will want to look at the dma addresses of
individual page tables, so add a routine to iterate over them.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 49
drivers/gpu/drm/i
From: Chris Wilson
Allow internal clients to create and destroy a pinned context.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
v2:
- (Thomas) Export also the pinned context destructor
---
drivers/gpu/drm/i915/gt/intel_engine.h| 11 +
drivers/gpu/drm/i915/gt/intel_engi
Introduce a for_i915_gem_ww(){} utility to help make the code
around a ww transaction more readable.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_ww.h | 31 +-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git
From: Chris Wilson
Set up a default migration context on the GT and use it from the
selftests.
Add a perf selftest and make sure we exercise LMEM if available.
Signed-off-by: Chris Wilson
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v3:
- Sk
From: Chris Wilson
If we pipeline the PTE updates and then do the copy of those pages
within a single unpreemptible command packet, we can submit the copies
and leave them to be scheduled without having to synchronously wait
under a global lock. In order to manage migration, we need to
preallocat
From: Chris Wilson
Update the PTE and emit a clear within a single unpreemptible packet
such that we can schedule and pipeline clears.
Signed-off-by: Chris Wilson
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
---
v3:
- Handle engine instances correctly (Reported by Matthew
From: Ramalingam C
Invokes the pipelined page migration through blt, for
i915_ttm_move requests of eviction and also obj clear.
Signed-off-by: Ramalingam C
Reviewed-by: Thomas Hellström
---
v2:
- subfunction for accel_move (Thomas)
- engine_pm_get/put around context_move/clear (Thomas)
- In
It's not used anywhere.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v4:
- Add back the igt_client_tiled_blits selftest (Suggested by Matthew Auld)
---
drivers/gpu/drm/i915/Makefile | 2 +-
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 355 --
It's unused with the exception of selftest. Replace a call in the
memory_region live selftest with a call into a corresponding
function in the new migrate code.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 1 -
.../gpu/drm/i915/
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 Wi
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 | 49 ++--
1 file changed, 24 insertions(+), 25 deletions(-)
diff --git a/kernel/dma/swio
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index c64
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/base/core.c| 4
include/linux/device.h | 4
kernel/dma/swiotlb.c | 8
3 files changed, 12 insertions(+), 4 deleti
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for different pools.
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 | 6
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for different pools.
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
Propagate the swiotlb_force setting into io_tlb_default_mem->force and
use it to determine whether to bounce the data or not. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 11 +++
kernel/dma/direct.c | 2 +-
kernel/
Rename find_slots to swiotlb_find_slots and move the maintenance of
alloc_size to it for better code reusability later.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swio
Add a new function, swiotlb_release_slots, to make the code reusable for
supporting different bounce buffer pools.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/kernel/dma/swiotlb.c b
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
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 unexpec
Add the functions, swiotlb_{alloc,free} to support the memory allocation
from restricted DMA pool.
The restricted DMA pool is preferred if available.
Note that since coherent allocation needs remapping, one must set up
another device coherent pool by shared-dma-pool and use
dma_alloc_from_dev_coh
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
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 +
== Series Details ==
Series: drm/i915/ttm: Fix memory leaks
URL : https://patchwork.freedesktop.org/series/91512/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10225 -> Patchwork_20370
Summary
---
**SUCCESS**
No r
== Series Details ==
Series: i915 TTM sync accelerated migration and clear (rev3)
URL : https://patchwork.freedesktop.org/series/91463/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
84d52ccba4bc drm/i915: Reference objects on the ww object list
dad033f5d41d drm/i915: Break out
This is my alternative take on this series from Jason:
https://lore.kernel.org/dri-devel/87czsszi9i@redhat.com/T/
The mdev/vfio parts are exactly the same, but this solves the driver core
changes for the direct probing without the in/out flag that Greg hated,
which cause a little more work, b
From: Jason Gunthorpe
Checking if the dev is dead or if the dev is already bound is a required
precondition to invoking driver_probe_device(). All the call chains
leading here duplicate these checks.
Add it directly to driver_probe_device() so the precondition is clear and
remove the checks from
v10 here: https://lore.kernel.org/patchwork/cover/1446882/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Jun 15, 2021 at 09:27:00PM +0800, Claire Chang wrote:
> Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
> initialization to make the code reusable.
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Int
On Tue, Jun 15, 2021 at 09:27:01PM +0800, Claire Chang wrote:
> Split the debugfs creation to make the code reusable for supporting
> different bounce buffer pools.
>
> Signed-off-by: Claire Chang
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-
really_probe tries to special case errors from ->probe, but due to all
other initialization added to the function over time now a lot of
internal errors hit that code path as well. Untangle that by adding
a new probe_err local variable and apply the special casing only to
that.
Signed-off-by: Chr
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Currently really_probe() returns 1 on success and 0 if the probe() call
fails. This return code arrangement is designed to be useful for
__device_attach_driver() which is walking the device list and trying every
driver. 0 means to keep trying.
However, it is not useful for the other places that ca
On Tue, Jun 15, 2021 at 09:27:03PM +0800, Claire Chang wrote:
> Update is_swiotlb_buffer to add a struct device argument. This will be
> useful later to allow for different pools.
>
> Signed-off-by: Claire Chang
Looks good,
Reviewed-by: Christoph Hellwig
___
On Tue, Jun 15, 2021 at 09:27:04PM +0800, Claire Chang wrote:
> Update is_swiotlb_active to add a struct device argument. This will be
> useful later to allow for different pools.
>
> Signed-off-by: Claire Chang
Looks good,
Reviewed-by: Christoph Hellwig
___
EPROBE_DEFER is an internal kernel error code and it should not be leaked
to userspace via the bind_store() sysfs. Userspace doesn't have this
constant and cannot understand it.
Further, it doesn't really make sense to have userspace trigger a deferred
probe via bind_store(), which could eventuall
On Tue, Jun 15, 2021 at 09:27:05PM +0800, Claire Chang wrote:
> Propagate the swiotlb_force setting into io_tlb_default_mem->force and
> use it to determine whether to bounce the data or not. This will be
> useful later to allow for different pools.
>
> Signed-off-by: Claire Chang
Looks good,
R
On Tue, Jun 15, 2021 at 09:27:06PM +0800, Claire Chang wrote:
> Rename find_slots to swiotlb_find_slots and move the maintenance of
> alloc_size to it for better code reusability later.
>
> Signed-off-by: Claire Chang
Looks good,
Reviewed-by: Christoph Hellwig
_
From: Jason Gunthorpe
This is intended as a replacement API for device_bind_driver(). It has at
least the following benefits:
- Internal locking. Few of the users of device_bind_driver() follow the
locking rules
- Calls device driver probe() internally. Notably this means that devm
support
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Jun 15, 2021 at 09:27:08PM +0800, Claire Chang wrote:
> Add the initialization function to create restricted DMA pools from
> matching reserved-memory nodes.
>
> Regardless of swiotlb setting, the restricted DMA pool is preferred if
> available.
>
> The restricted DMA pools provide a basi
From: Jason Gunthorpe
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.
Signed-off-by: Jason Gunthorpe
Signe
From: Jason Gunthorpe
This allows a mdev driver to opt out of using vfio_mdev.c, instead the
driver will provide a 'struct mdev_driver' and register directly with the
driver core.
Much of mdev_parent_ops becomes unused in this mode:
- create()/remove() are done via the mdev_driver probe()/remove
On Tue, Jun 15, 2021 at 09:27:09PM +0800, Claire Chang wrote:
> Add the functions, swiotlb_{alloc,free} to support the memory allocation
> from restricted DMA pool.
>
> The restricted DMA pool is preferred if available.
>
> Note that since coherent allocation needs remapping, one must set up
> an
From: Jason Gunthorpe
This is straightforward conversion, the mdev_state is actually serving as
the vfio_device and we can replace all the mdev_get_drvdata()'s and the
wonky dead code with a simple container_of()
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
Signed-off-by: Chri
From: Jason Gunthorpe
This is straightforward conversion, the mdev_state is actually serving as
the vfio_device and we can replace all the mdev_get_drvdata()'s and the
wonky dead code with a simple container_of().
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
Signed-off-by: Chr
From: Jason Gunthorpe
This is straightforward conversion, the mdev_state is actually serving as
the vfio_device and we can replace all the mdev_get_drvdata()'s and the
wonky dead code with a simple container_of().
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
Signed-off-by: Chr
On Tue, Jun 15 2021, Christoph Hellwig wrote:
> really_probe tries to special case errors from ->probe, but due to all
> other initialization added to the function over time now a lot of
> internal errors hit that code path as well. Untangle that by adding
> a new probe_err local variable and ap
On Tue, Jun 15 2021, Christoph Hellwig wrote:
> EPROBE_DEFER is an internal kernel error code and it should not be leaked
> to userspace via the bind_store() sysfs. Userspace doesn't have this
> constant and cannot understand it.
>
> Further, it doesn't really make sense to have userspace trigger
== Series Details ==
Series: Restricted DMA
URL : https://patchwork.freedesktop.org/series/91518/
State : failure
== Summary ==
Applying: swiotlb: Refactor swiotlb init functions
Applying: swiotlb: Refactor swiotlb_create_debugfs
Applying: swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool u
== Series Details ==
Series: i915 TTM sync accelerated migration and clear (rev3)
URL : https://patchwork.freedesktop.org/series/91463/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10225 -> Patchwork_20371
Summary
---
On Tue, Jun 15 2021, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> This allows a mdev driver to opt out of using vfio_mdev.c, instead the
> driver will provide a 'struct mdev_driver' and register directly with the
> driver core.
>
> Much of mdev_parent_ops becomes unused in this mode:
> -
On Tue, Jun 15, 2021 at 03:53:46PM +0200, Cornelia Huck wrote:
> On Tue, Jun 15 2021, Christoph Hellwig wrote:
>
> > really_probe tries to special case errors from ->probe, but due to all
> > other initialization added to the function over time now a lot of
> > internal errors hit that code path
On Tue, Jun 15, 2021 at 03:35:11PM +0200, Christoph Hellwig wrote:
> really_probe tries to special case errors from ->probe, but due to all
> other initialization added to the function over time now a lot of
> internal errors hit that code path as well. Untangle that by adding
> a new probe_err lo
On Tue, Jun 15, 2021 at 03:35:14PM +0200, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> This is intended as a replacement API for device_bind_driver(). It has at
> least the following benefits:
>
> - Internal locking. Few of the users of device_bind_driver() follow the
> locking rules
>
On Tue, Jun 15, 2021 at 03:35:15PM +0200, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> 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
On Tue, Jun 15, 2021 at 03:35:16PM +0200, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> This allows a mdev driver to opt out of using vfio_mdev.c, instead the
> driver will provide a 'struct mdev_driver' and register directly with the
> driver core.
>
> Much of mdev_parent_ops becomes unu
== Series Details ==
Series: series starting with [01/10] driver core: Pull required checks into
driver_probe_device()
URL : https://patchwork.freedesktop.org/series/91520/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6d13827dce62 driver core: Pull required checks into driver
On Tue, Jun 15, 2021 at 03:35:17PM +0200, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> This is straightforward conversion, the mdev_state is actually serving as
> the vfio_device and we can replace all the mdev_get_drvdata()'s and the
> wonky dead code with a simple container_of()
>
> Re
On Tue, Jun 15, 2021 at 03:35:18PM +0200, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> This is straightforward conversion, the mdev_state is actually serving as
> the vfio_device and we can replace all the mdev_get_drvdata()'s and the
> wonky dead code with a simple container_of().
>
> R
1 - 100 of 220 matches
Mail list logo
