Re: [PATCH] Documentation: fb: udlfb: clean up text and formatting
On 8/27/22 18:51, Bagas Sanjaya wrote: > On 8/28/22 02:39, Randy Dunlap wrote: >> -From the command line, pass options to modprobe >> -modprobe udlfb fb_defio=0 console=1 shadow=1 >> +From the command line, pass options to modprobe:: >> >> -Or modify options on the fly at /sys/module/udlfb/parameters directory via >> -sudo nano fb_defio >> -change the parameter in place, and save the file. >> + modprobe udlfb fb_defio=0 console=1 shadow=1 >> + >> +Or modify options on the fly at /sys/module/udlfb/parameters directory via:: >> + >> + sudo nano fb_defio >> + change the parameter in place, and save the file. >> > > Better say "Or change the options on the fly by editing > /sys/module/udlfb/parameters/fb_defio." > >> Unplug/replug USB device to apply with new settings >> >> -Or for permanent option, create file like /etc/modprobe.d/udlfb.conf with >> text >> -options udlfb fb_defio=0 console=1 shadow=1 >> +Or for permanent options, create a file like /etc/modprobe.d/udlfb.conf >> +with text:: >> + >> + options udlfb fb_defio=0 console=1 shadow=1 > > Maybe we can say "Or to apply options permanently, create modprobe > configuration > like /etc/modprobe.d/udlfb.conf with::" Thanks, I'll send a v2. -- ~Randy
Re: [PATCH 1/2] drm/etnaviv: add HWDB entry for GC7000 r6203
On Fri, Aug 26, 2022 at 2:07 PM Lucas Stach wrote:
>
> From: Marco Felsch
>
> The GPU is found on the NXP i.MX8MN SoC. The feature bits are taken from
> the NXP downstream kernel driver 6.4.3.p2.
>
This series fixes an issue where I saw:
etnaviv-gpu 3800.gpu: recover hung GPU!
With mesa-22.2.0-rc3, I am able to run 3D demos.
Tested-by: Adam Ford #imx8mn-beacon-kit
> Signed-off-by: Marco Felsch
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 31 ++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> index f2fc645c7956..eaed08a3d281 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> @@ -68,6 +68,37 @@ static const struct etnaviv_chip_identity
> etnaviv_chip_identities[] = {
> .minor_features10 = 0x4040,
> .minor_features11 = 0x0024,
> },
> + {
> + .model = 0x7000,
> + .revision = 0x6203,
> + .product_id = ~0U,
> + .customer_id = ~0U,
> + .eco_id = ~0U,
> + .stream_count = 16,
> + .register_max = 64,
> + .thread_count = 512,
> + .shader_core_count = 2,
> + .vertex_cache_size = 16,
> + .vertex_output_buffer_size = 1024,
> + .pixel_pipes = 1,
> + .instruction_count = 512,
> + .num_constants = 320,
> + .buffer_size = 0,
> + .varyings_count = 16,
> + .features = 0xe0287c8d,
> + .minor_features0 = 0xc1589eff,
> + .minor_features1 = 0xfefbfad9,
> + .minor_features2 = 0xeb9d4fbf,
> + .minor_features3 = 0xedfffced,
> + .minor_features4 = 0xdb0dafc7,
> + .minor_features5 = 0x3b5ac333,
> + .minor_features6 = 0xfcce6000,
> + .minor_features7 = 0xfffbfa6f,
> + .minor_features8 = 0x00e10ef3,
> + .minor_features9 = 0x00c8003c,
> + .minor_features10 = 0x4040,
> + .minor_features11 = 0x0024,
> + },
> {
> .model = 0x7000,
> .revision = 0x6204,
> --
> 2.30.2
>
Re: [PATCH] Documentation: fb: udlfb: clean up text and formatting
On 8/28/22 02:39, Randy Dunlap wrote: > -From the command line, pass options to modprobe > -modprobe udlfb fb_defio=0 console=1 shadow=1 > +From the command line, pass options to modprobe:: > > -Or modify options on the fly at /sys/module/udlfb/parameters directory via > -sudo nano fb_defio > -change the parameter in place, and save the file. > + modprobe udlfb fb_defio=0 console=1 shadow=1 > + > +Or modify options on the fly at /sys/module/udlfb/parameters directory via:: > + > + sudo nano fb_defio > + change the parameter in place, and save the file. > Better say "Or change the options on the fly by editing /sys/module/udlfb/parameters/fb_defio." > Unplug/replug USB device to apply with new settings > > -Or for permanent option, create file like /etc/modprobe.d/udlfb.conf with > text > -options udlfb fb_defio=0 console=1 shadow=1 > +Or for permanent options, create a file like /etc/modprobe.d/udlfb.conf > +with text:: > + > + options udlfb fb_defio=0 console=1 shadow=1 Maybe we can say "Or to apply options permanently, create modprobe configuration like /etc/modprobe.d/udlfb.conf with::" -- An old man doll... just what I always wanted! - Clara
RE: [PATCH 00/15] Tidy up vfio_device life cycle
lkp reported some warnings below. I'll got them fixed in the next version. Not sure why they are not captured in my builds though I did turn on treating warnings as error. drivers/vfio/fsl-mc/vfio_fsl_mc.c:570:6: warning: no previous prototype for 'vfio_fsl_mc_release_dev' [-Wmissing-prototypes] drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c:1216:5: warning: no previous prototype for 'hisi_acc_vfio_pci_migrn_init_dev' [-Wmissing-prototypes] drivers/vfio/platform/vfio_amba.c:110:37: warning: unused variable 'vfio_platform_ops' [-Wunused-const-variable] drivers/vfio/platform/vfio_platform_common.c:608:37: warning: unused variable 'vfio_platform_ops' [-Wunused-const-variable] > From: Tian, Kevin > Sent: Sunday, August 28, 2022 1:10 AM > > The idea is to let vfio core manage the vfio_device life cycle instead > of duplicating the logic cross drivers. Besides cleaner code in driver > side this also allows adding struct device to vfio_device as the first > step toward adding cdev uAPI in the future. Another benefit is that > user can now look at sysfs to decide whether a device is bound to > vfio [1], e.g.: > > /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0 > > Though most drivers can fit the new model naturally: > > - vfio_alloc_device() to allocate and initialize vfio_device > - vfio_put_device() to release vfio_device > - dev_ops->init() for driver private initialization > - dev_ops->release() for driver private cleanup > > vfio-ccw is the only exception due to a life cycle mess that its private > structure mixes both parent and mdev info hence must be alloc/free'ed > outside of the life cycle of vfio device. > > Per prior discussions this won't be fixed in short term by IBM folks [2]. > > Instead of waiting this series introduces a few tricks to move forward: > > - vfio_init_device() to initialize a pre-allocated device structure; > > - require *EVERY* driver to implement @release and free vfio_device >inside. Then vfio-ccw can use a completion mechanism to delay the >free to css driver; > > The second trick is not a real burden to other drivers because they > all require a @release for private cleanup anyay. Later once the ccw > mess is fixed a simple cleanup can be done by moving free from @release > to vfio core. > > Thanks > Kevin > > [1] https://listman.redhat.com/archives/libvir-list/2022-August/233482.html > [2] > https://lore.kernel.org/all/0ee29bd6583f17f0ee4ec0769fa50e8ea6703623.ca > m...@linux.ibm.com/ > > Kevin Tian (6): > vfio: Add helpers for unifying vfio_device life cycle > drm/i915/gvt: Use the new device life cycle helpers > vfio/platform: Use the new device life cycle helpers > vfio/amba: Use the new device life cycle helpers > vfio/ccw: Use the new device life cycle helpers > vfio: Rename vfio_device_put() and vfio_device_try_get() > > Yi Liu (9): > vfio/pci: Use the new device life cycle helpers > vfio/mlx5: Use the new device life cycle helpers > vfio/hisi_acc: Use the new device life cycle helpers > vfio/mdpy: Use the new device life cycle helpers > vfio/mtty: Use the new device life cycle helpers > vfio/mbochs: Use the new device life cycle helpers > vfio/ap: Use the new device life cycle helpers > vfio/fsl-mc: Use the new device life cycle helpers > vfio: Add struct device to vfio_device > > drivers/gpu/drm/i915/gvt/gvt.h| 5 +- > drivers/gpu/drm/i915/gvt/kvmgt.c | 52 -- > drivers/gpu/drm/i915/gvt/vgpu.c | 31 ++-- > drivers/s390/cio/vfio_ccw_ops.c | 52 +- > drivers/s390/cio/vfio_ccw_private.h | 3 + > drivers/s390/crypto/vfio_ap_ops.c | 50 +++--- > drivers/vfio/fsl-mc/vfio_fsl_mc.c | 87 + > .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c| 80 - > drivers/vfio/pci/mlx5/main.c | 49 -- > drivers/vfio/pci/vfio_pci.c | 20 +-- > drivers/vfio/pci/vfio_pci_core.c | 23 ++- > drivers/vfio/platform/vfio_amba.c | 72 ++-- > drivers/vfio/platform/vfio_platform.c | 66 +-- > drivers/vfio/platform/vfio_platform_common.c | 61 +++ > drivers/vfio/platform/vfio_platform_private.h | 18 +- > drivers/vfio/vfio_main.c | 165 +++--- > include/linux/vfio.h | 29 ++- > include/linux/vfio_pci_core.h | 6 +- > samples/vfio-mdev/mbochs.c| 73 +--- > samples/vfio-mdev/mdpy.c | 81 + > samples/vfio-mdev/mtty.c | 67 --- > 21 files changed, 724 insertions(+), 366 deletions(-) > > > base-commit: 1c23f9e627a7b412978b4e852793c5e3c3efc555 > -- > 2.21.3
Re: [Freedreno] [PATCH v2.5] drm/msm/dsi: switch to DRM_PANEL_BRIDGE
On 8/22/2022 10:53 AM, Dmitry Baryshkov wrote:
On 15/07/2022 00:54, Abhinav Kumar wrote:
On 7/12/2022 6:22 AM, Dmitry Baryshkov wrote:
Currently the DSI driver has two separate paths: one if the next device
in a chain is a bridge and another one if the panel is connected
directly to the DSI host. Simplify the code path by using panel-bridge
driver (already selected in Kconfig) and dropping support for
handling the panel directly.
Signed-off-by: Dmitry Baryshkov
---
I'm not sending this as a separate patchset (I'd like to sort out mdp5
first), but more of a preview of changes related to
msm_dsi_manager_ext_bridge_init().
---
drivers/gpu/drm/msm/dsi/dsi.c | 35 +---
drivers/gpu/drm/msm/dsi/dsi.h | 16 +-
drivers/gpu/drm/msm/dsi/dsi_host.c | 25 ---
drivers/gpu/drm/msm/dsi/dsi_manager.c | 283 +++---
4 files changed, 36 insertions(+), 323 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c
b/drivers/gpu/drm/msm/dsi/dsi.c
index 1625328fa430..4edb9167e600 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -6,14 +6,6 @@
#include "dsi.h"
#include "dsi_cfg.h"
-struct drm_encoder *msm_dsi_get_encoder(struct msm_dsi *msm_dsi)
-{
- if (!msm_dsi || !msm_dsi_device_connected(msm_dsi))
- return NULL;
-
- return msm_dsi->encoder;
-}
-
bool msm_dsi_is_cmd_mode(struct msm_dsi *msm_dsi)
{
unsigned long host_flags =
msm_dsi_host_get_mode_flags(msm_dsi->host);
@@ -220,7 +212,6 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi,
struct drm_device *dev,
struct drm_encoder *encoder)
{
struct msm_drm_private *priv;
- struct drm_bridge *ext_bridge;
int ret;
if (WARN_ON(!encoder) || WARN_ON(!msm_dsi) || WARN_ON(!dev))
@@ -254,26 +245,10 @@ int msm_dsi_modeset_init(struct msm_dsi
*msm_dsi, struct drm_device *dev,
goto fail;
}
- /*
- * check if the dsi encoder output is connected to a panel or an
- * external bridge. We create a connector only if we're
connected to a
- * drm_panel device. When we're connected to an external bridge, we
- * assume that the drm_bridge driver will create the connector
itself.
- */
- ext_bridge = msm_dsi_host_get_bridge(msm_dsi->host);
-
- if (ext_bridge)
- msm_dsi->connector =
- msm_dsi_manager_ext_bridge_init(msm_dsi->id);
- else
- msm_dsi->connector =
- msm_dsi_manager_connector_init(msm_dsi->id);
-
- if (IS_ERR(msm_dsi->connector)) {
- ret = PTR_ERR(msm_dsi->connector);
+ ret = msm_dsi_manager_ext_bridge_init(msm_dsi->id);
+ if (ret) {
DRM_DEV_ERROR(dev->dev,
"failed to create dsi connector: %d\n", ret);
- msm_dsi->connector = NULL;
goto fail;
}
@@ -287,12 +262,6 @@ int msm_dsi_modeset_init(struct msm_dsi
*msm_dsi, struct drm_device *dev,
msm_dsi->bridge = NULL;
}
- /* don't destroy connector if we didn't make it */
- if (msm_dsi->connector && !msm_dsi->external_bridge)
- msm_dsi->connector->funcs->destroy(msm_dsi->connector);
-
- msm_dsi->connector = NULL;
From what i can see all the usages of msm_dsi->connector are removed
after this change. So can we drop that?
The connector field is dropped from the msm_dsi struct. If you are
asking about the msm_dsi_modeset_init(), we can not drop it since we
require the DRM device with GEM being initialized in order to allocate
DSI DMA buffer. We can think about moving DMA buffer allocation towards
the usage point, however this is definitely a separate commit.
[skipped]
Yes, got it.
*msm_dsi_manager_ext_bridge_init(u8 id)
ret = drm_bridge_attach(encoder, ext_bridge, int_bridge,
DRM_BRIDGE_ATTACH_NO_CONNECTOR);
if (ret == -EINVAL) {
- struct drm_connector *connector;
- struct list_head *connector_list;
-
- /* link the internal dsi bridge to the external bridge */
- drm_bridge_attach(encoder, ext_bridge, int_bridge, 0);
-
/*
- * we need the drm_connector created by the external bridge
- * driver (or someone else) to feed it to our driver's
- * priv->connector[] list, mainly for msm_fbdev_init()
+ * link the internal dsi bridge to the external bridge,
+ * connector is created by the next bridge.
*/
- connector_list = >mode_config.connector_list;
+ ret = drm_bridge_attach(encoder, ext_bridge, int_bridge, 0);
+ if (ret < 0)
+ return ret;
+ } else {
+ struct drm_connector *connector;
- list_for_each_entry(connector, connector_list, head) {
- if (drm_connector_has_possible_encoder(connector, encoder))
- return connector;
+ /* We are in charge of the connector, create one now. */
+ connector = drm_bridge_connector_init(dev, encoder);
+ if (IS_ERR(connector)) {
+ DRM_ERROR("Unable to
[RFC PATCH v3 11/17] drm/i915: Add i915_vma_is_bind_complete()
From: Niranjana Vishwanathapura
Add i915_vma_is_bind_complete() to check if the binding of a
of the VM of a specific VMA is complete.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_vma.c | 28
drivers/gpu/drm/i915/i915_vma.h | 1 +
2 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 6ca37ce2b35a8..4b8ae58cd886b 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -406,6 +406,34 @@ int i915_vma_sync(struct i915_vma *vma)
return i915_vm_sync(vma->vm);
}
+/**
+ * i915_vma_is_bind_complete() - Checks if the binding of the VM is complete
+ * @vma: virtual address where the virtual memory that is being checked for
+ * binding completion
+ *
+ * Returns true if the binding is complete, otherwise false.
+ */
+bool i915_vma_is_bind_complete(struct i915_vma *vma)
+{
+ /* Ensure vma bind is initiated */
+ if (!i915_vma_is_bound(vma, I915_VMA_BIND_MASK))
+ return false;
+
+ /* Ensure any binding started is complete */
+ if (rcu_access_pointer(vma->active.excl.fence)) {
+ struct dma_fence *fence;
+
+ rcu_read_lock();
+ fence = dma_fence_get_rcu_safe(>active.excl.fence);
+ rcu_read_unlock();
+ if (fence) {
+ dma_fence_put(fence);
+ return false;
+ }
+ }
+ return true;
+}
+
/**
* i915_vma_verify_bind_complete() - Check for the vm_bind completion of the
vma
* @vma: vma submitted for vm_bind
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index bf0b5b4abd919..9f8c369c3b466 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -444,6 +444,7 @@ void i915_vma_make_purgeable(struct i915_vma *vma);
int i915_vma_wait_for_bind(struct i915_vma *vma);
int i915_vma_verify_bind_complete(struct i915_vma *vma);
int i915_vma_sync(struct i915_vma *vma);
+bool i915_vma_is_bind_complete(struct i915_vma *vma);
/**
* i915_vma_get_current_resource - Get the current resource of the vma
--
2.34.1
[RFC PATCH v3 15/17] drm/i915: Extend getparm for VM_BIND capability
From: Niranjana Vishwanathapura
Add getparam support for VM_BIND capability version support.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_getparam.c | 3 +++
include/uapi/drm/i915_drm.h | 21 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index 6fd15b39570c1..c1d53febc5de1 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -175,6 +175,9 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
case I915_PARAM_PERF_REVISION:
value = i915_perf_ioctl_version();
break;
+ case I915_PARAM_VM_BIND_VERSION:
+ value = GRAPHICS_VER(i915) >= 12 ? 1 : 0;
+ break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index ea1906873f278..b3d3e98efa02a 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -749,6 +749,27 @@ typedef struct drm_i915_irq_wait {
/* Query if the kernel supports the I915_USERPTR_PROBE flag. */
#define I915_PARAM_HAS_USERPTR_PROBE 56
+/*
+ * VM_BIND feature version supported.
+ *
+ * The following versions of VM_BIND have been defined:
+ *
+ * 0: No VM_BIND support.
+ *
+ * 1: In VM_UNBIND calls, the UMD must specify the exact mappings created
+ *previously with VM_BIND, the ioctl will not support unbinding multiple
+ *mappings or splitting them. Similarly, VM_BIND calls will not replace
+ *any existing mappings.
+ *
+ * 2: The restrictions on unbinding partial or multiple mappings is
+ *lifted, Similarly, binding will replace any mappings in the given range.
+ *
+ * See struct drm_i915_gem_vm_bind and struct drm_i915_gem_vm_unbind.
+ *
+ * vm_bind versions are backward compatible.
+ */
+#define I915_PARAM_VM_BIND_VERSION 57
+
/* Must be kept compact -- no holes and well documented */
/**
--
2.34.1
[RFC PATCH v3 14/17] drm/i915/vm_bind: Skip vma_lookup for persistent vmas
From: Niranjana Vishwanathapura
vma_lookup is tied to segment of the object instead of section
of VA space. Hence, it do not support aliasing (ie., multiple
bindings to the same section of the object).
Skip vma_lookup for persistent vmas as it supports aliasing.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/display/intel_fb_pin.c | 2 +-
.../drm/i915/display/intel_plane_initial.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 +-
.../drm/i915/gem/i915_gem_vm_bind_object.c| 2 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 16 +++
.../i915/gem/selftests/i915_gem_client_blt.c | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 12 ++---
.../drm/i915/gem/selftests/i915_gem_migrate.c | 2 +-
.../drm/i915/gem/selftests/i915_gem_mman.c| 6 ++-
.../drm/i915/gem/selftests/igt_gem_utils.c| 2 +-
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 2 +-
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +-
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ring.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 4 +-
drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 4 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 16 +++
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 +--
drivers/gpu/drm/i915/gt/selftest_lrc.c| 2 +-
.../drm/i915/gt/selftest_ring_submission.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_rps.c| 2 +-
.../gpu/drm/i915/gt/selftest_workarounds.c| 4 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +-
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 26 +++
drivers/gpu/drm/i915/i915_vma.h | 3 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 44 +--
drivers/gpu/drm/i915/selftests/i915_request.c | 4 +-
drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
drivers/gpu/drm/i915/selftests/igt_spinner.c | 2 +-
.../drm/i915/selftests/intel_memory_region.c | 2 +-
37 files changed, 106 insertions(+), 93 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c
b/drivers/gpu/drm/i915/display/intel_fb_pin.c
index bd6e7c98e751d..d4b5cd4d1038c 100644
--- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
+++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
@@ -47,7 +47,7 @@ intel_pin_fb_obj_dpt(struct drm_framebuffer *fb,
goto err;
}
- vma = i915_vma_instance(obj, vm, view);
+ vma = i915_vma_instance(obj, vm, view, false);
if (IS_ERR(vma))
goto err;
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index d10f27d0b7b09..ce034351b0c9c 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -136,7 +136,7 @@ initial_plane_vma(struct drm_i915_private *i915,
goto err_obj;
}
- vma = i915_vma_instance(obj, _gt(i915)->ggtt->vm, NULL);
+ vma = i915_vma_instance(obj, _gt(i915)->ggtt->vm, NULL, false);
if (IS_ERR(vma))
goto err_obj;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index f85f10cf9c34b..a53e19fc48584 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -880,7 +880,7 @@ static struct i915_vma *eb_lookup_vma(struct
i915_execbuffer *eb, u32 handle)
}
}
- vma = i915_vma_instance(obj, vm, NULL);
+ vma = i915_vma_instance(obj, vm, NULL, false);
if (IS_ERR(vma)) {
i915_gem_object_put(obj);
return vma;
@@ -2212,7 +2212,7 @@ shadow_batch_pin(struct i915_execbuffer *eb,
struct i915_vma *vma;
int err;
- vma = i915_vma_instance(obj, vm, NULL);
+ vma = i915_vma_instance(obj, vm, NULL, false);
if (IS_ERR(vma))
return vma;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index e6216f49e7d58..3dc5af4600a28 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -254,7 +254,7 @@ static struct i915_vma *vm_bind_get_vma(struct
i915_address_space *vm,
view.type = I915_GGTT_VIEW_PARTIAL;
view.partial.offset = va->offset >> PAGE_SHIFT;
view.partial.size =
[RFC PATCH v3 17/17] drm/i915: Enable execbuf3 ioctl for vm_bind
From: Niranjana Vishwanathapura
Add the uapi for the implemented execbuf3 ioctl to present it for
userspace. This ioctl can be used only for vm_bind mode and vm_binded
batchbuffers can be submitted only through execbuf3 ioctl.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_driver.c | 1 +
include/uapi/drm/i915_drm.h| 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 841b5d62c2c01..f3b0bbfbe9746 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1805,6 +1805,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_INIT, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, drm_invalid_op, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2_WR, i915_gem_execbuffer2_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER3, i915_gem_execbuffer3_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_reject_pin_ioctl,
DRM_AUTH|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_reject_pin_ioctl,
DRM_AUTH|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, DRM_RENDER_ALLOW),
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index b4b844f558b24..c807d48e1f96c 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -472,6 +472,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_CREATE_EXT0x3c
#define DRM_I915_GEM_VM_BIND 0x3d
#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_EXECBUFFER3 0x3f
/* Must be kept compact -- no holes */
#define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
@@ -538,6 +539,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_VM_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_VM_DESTROY, struct drm_i915_gem_vm_control)
#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_unbind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3 DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
--
2.34.1
[RFC PATCH v3 16/17] drm/i915/ioctl: Enable the vm_bind/unbind ioctls
From: Niranjana Vishwanathapura
Add ioctls to enable the vm_bind and vm_unbind feature
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_driver.c | 2 ++
include/uapi/drm/i915_drm.h| 4
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 9a9010fd9ecfa..841b5d62c2c01 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1844,6 +1844,8 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_VM_CREATE, i915_gem_vm_create_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_VM_DESTROY, i915_gem_vm_destroy_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_VM_BIND, i915_gem_vm_bind_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_VM_UNBIND, i915_gem_vm_unbind_ioctl,
DRM_RENDER_ALLOW),
};
/*
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index b3d3e98efa02a..b4b844f558b24 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -470,6 +470,8 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_VM_CREATE 0x3a
#define DRM_I915_GEM_VM_DESTROY0x3b
#define DRM_I915_GEM_CREATE_EXT0x3c
+#define DRM_I915_GEM_VM_BIND 0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
/* Must be kept compact -- no holes */
#define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
@@ -534,6 +536,8 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_QUERY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_QUERY, struct drm_i915_query)
#define DRM_IOCTL_I915_GEM_VM_CREATE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_CREATE, struct drm_i915_gem_vm_control)
#define DRM_IOCTL_I915_GEM_VM_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_VM_DESTROY, struct drm_i915_gem_vm_control)
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_unbind)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
--
2.34.1
[RFC PATCH v3 13/17] drm/i915/vm_bind: userptr dma-resv changes
From: Niranjana Vishwanathapura
For persistent (vm_bind) vmas of userptr BOs, handle the user
page pinning by using the i915_gem_object_userptr_submit_init()
/done() functions
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 139 ++
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 10 ++
.../drm/i915/gem/i915_gem_vm_bind_object.c| 16 ++
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 4 +
drivers/gpu/drm/i915/i915_vma_types.h | 2 +
6 files changed, 142 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
index 8e0dde26194e0..72d6771da2113 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -23,6 +23,7 @@
#include "i915_gem_vm_bind.h"
#include "i915_trace.h"
+#define __EXEC3_USERPTR_USED BIT_ULL(34)
#define __EXEC3_HAS_PINBIT_ULL(33)
#define __EXEC3_ENGINE_PINNED BIT_ULL(32)
#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
@@ -157,10 +158,45 @@ static void eb_scoop_unbound_vma_all(struct
i915_address_space *vm)
spin_unlock(>vm_rebind_lock);
}
+static int eb_lookup_persistent_userptr_vmas(struct i915_execbuffer *eb)
+{
+ struct i915_address_space *vm = eb->context->vm;
+ struct i915_vma *last_vma = NULL;
+ struct i915_vma *vma;
+ int err;
+
+ lockdep_assert_held(>vm_bind_lock);
+
+ list_for_each_entry(vma, >vm_userptr_invalidated_list,
+ vm_userptr_invalidated_link) {
+ list_del_init(>vm_userptr_invalidated_link);
+ err = i915_gem_object_userptr_submit_init(vma->obj);
+ if (err)
+ return err;
+
+ last_vma = vma;
+ }
+
+ list_for_each_entry(vma, >vm_bind_list, vm_bind_link)
+ if (i915_gem_object_is_userptr(vma->obj)) {
+ err = i915_gem_object_userptr_submit_init(vma->obj);
+ if (err)
+ return err;
+
+ last_vma = vma;
+ }
+
+ if (last_vma)
+ eb->args->flags |= __EXEC3_USERPTR_USED;
+
+ return 0;
+}
+
static int eb_lookup_vma_all(struct i915_execbuffer *eb)
{
unsigned int i, current_batch = 0;
struct i915_vma *vma;
+ int err = 0;
for (i = 0; i < eb->num_batches; i++) {
vma = eb_find_vma(eb->context->vm, eb->batch_addresses[i]);
@@ -171,6 +207,10 @@ static int eb_lookup_vma_all(struct i915_execbuffer *eb)
++current_batch;
}
+ err = eb_lookup_persistent_userptr_vmas(eb);
+ if (err)
+ return err;
+
eb_scoop_unbound_vma_all(eb->context->vm);
return 0;
@@ -286,33 +326,6 @@ static int eb_validate_persistent_vma_all(struct
i915_execbuffer *eb)
return ret;
}
-static int eb_validate_vma_all(struct i915_execbuffer *eb)
-{
- /* only throttle once, even if we didn't need to throttle */
- for (bool throttle = true;; throttle = false) {
- int err;
-
- err = eb_pin_engine(eb, throttle);
- if (!err)
- err = eb_lock_vma_all(eb);
-
- if (!err)
- err = eb_validate_persistent_vma_all(eb);
-
- if (!err)
- return 0;
-
- if (err != -EDEADLK)
- return err;
-
- err = i915_gem_ww_ctx_backoff(>ww);
- if (err)
- return err;
- }
-
- return 0;
-}
-
/*
* Using two helper loops for the order of which requests / batches are created
* and added the to backend. Requests are created in order from the parent to
@@ -360,15 +373,51 @@ static void eb_move_all_persistent_vma_to_active(struct
i915_execbuffer *eb)
static int eb_move_to_gpu(struct i915_execbuffer *eb)
{
+ int err = 0, j;
+
lockdep_assert_held(>context->vm->vm_bind_lock);
assert_object_held(eb->context->vm->root_obj);
eb_move_all_persistent_vma_to_active(eb);
- /* Unconditionally flush any chipset caches (for streaming writes). */
- intel_gt_chipset_flush(eb->gt);
+#ifdef CONFIG_MMU_NOTIFIER
+ if (!err && (eb->args->flags & __EXEC3_USERPTR_USED)) {
+ struct i915_vma *vma;
- return 0;
+ lockdep_assert_held(>context->vm->vm_bind_lock);
+ assert_object_held(eb->context->vm->root_obj);
+
+ read_lock(>i915->mm.notifier_lock);
+ list_for_each_entry(vma, >context->vm->vm_bind_list,
+ vm_bind_link) {
+ if
[RFC PATCH v3 12/17] drm/i915/vm_bind: Handle persistent vmas in execbuf3
From: Niranjana Vishwanathapura
Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 200 +-
1 file changed, 199 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
index a3d767cd9f808..8e0dde26194e0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
@@ -22,6 +23,7 @@
#include "i915_gem_vm_bind.h"
#include "i915_trace.h"
+#define __EXEC3_HAS_PINBIT_ULL(33)
#define __EXEC3_ENGINE_PINNED BIT_ULL(32)
#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
@@ -45,7 +47,9 @@
* execlist. Hence, no support for implicit sync.
*
* The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
- * works with execbuf3 ioctl for submission.
+ * works with execbuf3 ioctl for submission. All BOs mapped on that VM (through
+ * VM_BIND call) at the time of execbuf3 call are deemed required for that
+ * submission.
*
* The execbuf3 ioctl directly specifies the batch addresses instead of as
* object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
@@ -61,6 +65,13 @@
* So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
* vma lookup table, implicit sync, vma active reference tracking etc., are not
* applicable for execbuf3 ioctl.
+ *
+ * During each execbuf submission, request fence is added to all VM_BIND mapped
+ * objects with DMA_RESV_USAGE_BOOKKEEP. The DMA_RESV_USAGE_BOOKKEEP usage will
+ * prevent over sync (See enum dma_resv_usage). Note that DRM_I915_GEM_WAIT and
+ * DRM_I915_GEM_BUSY ioctls do not check for DMA_RESV_USAGE_BOOKKEEP usage and
+ * hence should not be used for end of batch check. Instead, the execbuf3
+ * timeline out fence should be used for end of batch check.
*/
struct eb_fence {
@@ -108,6 +119,7 @@ struct i915_execbuffer {
};
static int eb_pin_engine(struct i915_execbuffer *eb, bool throttle);
+static void eb_unpin_engine(struct i915_execbuffer *eb);
static int eb_select_context(struct i915_execbuffer *eb)
{
@@ -132,6 +144,19 @@ eb_find_vma(struct i915_address_space *vm, u64 addr)
return i915_gem_vm_bind_lookup_vma(vm, va);
}
+static void eb_scoop_unbound_vma_all(struct i915_address_space *vm)
+{
+ struct i915_vma *vma, *vn;
+
+ spin_lock(>vm_rebind_lock);
+ list_for_each_entry_safe(vma, vn, >vm_rebind_list, vm_rebind_link) {
+ list_del_init(>vm_rebind_link);
+ if (!list_empty(>vm_bind_link))
+ list_move_tail(>vm_bind_link, >vm_bind_list);
+ }
+ spin_unlock(>vm_rebind_lock);
+}
+
static int eb_lookup_vma_all(struct i915_execbuffer *eb)
{
unsigned int i, current_batch = 0;
@@ -146,11 +171,119 @@ static int eb_lookup_vma_all(struct i915_execbuffer *eb)
++current_batch;
}
+ eb_scoop_unbound_vma_all(eb->context->vm);
+
return 0;
}
+static int eb_lock_vma_all(struct i915_execbuffer *eb)
+{
+ struct i915_address_space *vm = eb->context->vm;
+ struct i915_vma *vma;
+ int err;
+
+ err = i915_gem_object_lock(eb->context->vm->root_obj, >ww);
+ if (err)
+ return err;
+
+ list_for_each_entry(vma, >non_priv_vm_bind_list,
+ non_priv_vm_bind_link) {
+ err = i915_gem_object_lock(vma->obj, >ww);
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
+static void eb_release_persistent_vma_all(struct i915_execbuffer *eb,
+ bool final)
+{
+ struct i915_address_space *vm = eb->context->vm;
+ struct i915_vma *vma, *vn;
+
+ lockdep_assert_held(>vm_bind_lock);
+
+ if (!(eb->args->flags & __EXEC3_HAS_PIN))
+ return;
+
+ assert_object_held(vm->root_obj);
+
+ list_for_each_entry(vma, >vm_bind_list, vm_bind_link)
+ __i915_vma_unpin(vma);
+
+ eb->args->flags &= ~__EXEC3_HAS_PIN;
+ if (!final)
+ return;
+
+ list_for_each_entry_safe(vma, vn, >vm_bind_list, vm_bind_link)
+ if (i915_vma_is_bind_complete(vma))
+ list_move_tail(>vm_bind_link, >vm_bound_list);
+}
+
static void eb_release_vma_all(struct i915_execbuffer *eb, bool final)
{
+ eb_release_persistent_vma_all(eb, final);
+ eb_unpin_engine(eb);
+}
+
+static int eb_reserve_fence_for_persistent_vma_all(struct i915_execbuffer *eb)
+{
+ struct i915_address_space *vm = eb->context->vm;
+ struct i915_vma *vma;
+ int ret;
+
+ ret =
[RFC PATCH v3 08/17] drm/i915/vm_bind: Add out fence support
From: Niranjana Vishwanathapura
Add support for handling out fence of vm_bind call.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 3 +
.../drm/i915/gem/i915_gem_vm_bind_object.c| 82 +++
drivers/gpu/drm/i915/i915_vma.c | 6 +-
drivers/gpu/drm/i915/i915_vma_types.h | 7 ++
4 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
index ebc493b7dafc1..d65e6e4fb3972 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -18,4 +18,7 @@ int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file);
void i915_gem_vm_unbind_vma_all(struct i915_address_space *vm);
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+ struct dma_fence * const fence);
+
#endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 3b45529fe8d4c..e57b9c492a7f9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -5,6 +5,8 @@
#include
+#include
+
#include "gem/i915_gem_vm_bind.h"
#include "gem/i915_gem_context.h"
#include "gt/gen8_engine_cs.h"
@@ -109,6 +111,67 @@ void i915_gem_vm_bind_remove(struct i915_vma *vma, bool
release_obj)
}
}
+static int i915_vm_bind_add_fence(struct drm_file *file, struct i915_vma *vma,
+ u32 handle, u64 point)
+{
+ struct drm_syncobj *syncobj;
+
+ syncobj = drm_syncobj_find(file, handle);
+ if (!syncobj) {
+ DRM_DEBUG("Invalid syncobj handle provided\n");
+ return -ENOENT;
+ }
+
+ /*
+* For timeline syncobjs we need to preallocate chains for
+* later signaling.
+*/
+ if (point) {
+ vma->vm_bind_fence.chain_fence = dma_fence_chain_alloc();
+ if (!vma->vm_bind_fence.chain_fence) {
+ drm_syncobj_put(syncobj);
+ return -ENOMEM;
+ }
+ } else {
+ vma->vm_bind_fence.chain_fence = NULL;
+ }
+ vma->vm_bind_fence.syncobj = syncobj;
+ vma->vm_bind_fence.value = point;
+
+ return 0;
+}
+
+static void i915_vm_bind_put_fence(struct i915_vma *vma)
+{
+ if (!vma->vm_bind_fence.syncobj)
+ return;
+
+ drm_syncobj_put(vma->vm_bind_fence.syncobj);
+ dma_fence_chain_free(vma->vm_bind_fence.chain_fence);
+}
+
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+ struct dma_fence * const fence)
+{
+ struct drm_syncobj *syncobj = vma->vm_bind_fence.syncobj;
+
+ if (!syncobj)
+ return;
+
+ if (vma->vm_bind_fence.chain_fence) {
+ drm_syncobj_add_point(syncobj,
+ vma->vm_bind_fence.chain_fence,
+ fence, vma->vm_bind_fence.value);
+ /*
+* The chain's ownership is transferred to the
+* timeline.
+*/
+ vma->vm_bind_fence.chain_fence = NULL;
+ } else {
+ drm_syncobj_replace_fence(syncobj, fence);
+ }
+}
+
static int i915_gem_vm_unbind_vma(struct i915_address_space *vm,
struct i915_vma *vma,
struct drm_i915_gem_vm_unbind *va)
@@ -243,6 +306,15 @@ static int i915_gem_vm_bind_obj(struct i915_address_space
*vm,
goto unlock_vm;
}
+ if (va->fence.flags & I915_TIMELINE_FENCE_SIGNAL) {
+ ret = i915_vm_bind_add_fence(file, vma, va->fence.handle,
+va->fence.value);
+ if (ret)
+ goto put_vma;
+ }
+
+ pin_flags = va->start | PIN_OFFSET_FIXED | PIN_USER;
+
for_i915_gem_ww(, ret, true) {
retry:
ret = i915_gem_object_lock(vma->obj, );
@@ -267,12 +339,22 @@ static int i915_gem_vm_bind_obj(struct i915_address_space
*vm,
ret = i915_gem_ww_ctx_backoff();
if (!ret)
goto retry;
+
} else {
/* Hold object reference until vm_unbind */
i915_gem_object_get(vma->obj);
}
}
+ if (va->fence.flags & I915_TIMELINE_FENCE_SIGNAL)
+ i915_vm_bind_put_fence(vma);
+
+put_vma:
+ if (ret && vma) {
+ i915_vma_set_freed(vma);
+ i915_vma_destroy(vma);
+ }
+
unlock_vm:
mutex_unlock(>vm_bind_lock);
diff --git
[RFC PATCH v3 10/17] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl
From: Niranjana Vishwanathapura
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.
The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects binding would have been requested by the
userspace before submitting the execbuf3.
And the legacy support like relocations etc are removed.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/Makefile |1 +
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 1000 +
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|2 +
include/uapi/drm/i915_drm.h | 62 +
4 files changed, 1065 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4e1627e96c6e0..38cd1c5bc1a55 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -148,6 +148,7 @@ gem-y += \
gem/i915_gem_dmabuf.o \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer.o \
+ gem/i915_gem_execbuffer3.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_lmem.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
new file mode 100644
index 0..a3d767cd9f808
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -0,0 +1,1000 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include "gt/intel_context.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_gt_pm.h"
+#include "gt/intel_ring.h"
+
+#include "i915_drv.h"
+#include "i915_file_private.h"
+#include "i915_gem_context.h"
+#include "i915_gem_ioctls.h"
+#include "i915_gem_vm_bind.h"
+#include "i915_trace.h"
+
+#define __EXEC3_ENGINE_PINNED BIT_ULL(32)
+#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
+
+/* Catch emission of unexpected errors for CI! */
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+#undef EINVAL
+#define EINVAL ({ \
+ DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
+ 22; \
+})
+#endif
+
+/**
+ * DOC: User command execution with execbuf3 ioctl
+ *
+ * A VM in VM_BIND mode will not support older execbuf mode of binding.
+ * The execbuf ioctl handling in VM_BIND mode differs significantly from the
+ * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+ * Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+ * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+ * execlist. Hence, no support for implicit sync.
+ *
+ * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
+ * works with execbuf3 ioctl for submission.
+ *
+ * The execbuf3 ioctl directly specifies the batch addresses instead of as
+ * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+ * support many of the older features like in/out/submit fences, fence array,
+ * default gem context etc. (See struct drm_i915_gem_execbuffer3).
+ *
+ * In VM_BIND mode, VA allocation is completely managed by the user instead of
+ * the i915 driver. Hence all VA assignment, eviction are not applicable in
+ * VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
+ * be using the i915_vma active reference tracking. It will instead check the
+ * dma-resv object's fence list for that.
+ *
+ * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
+ * vma lookup table, implicit sync, vma active reference tracking etc., are not
+ * applicable for execbuf3 ioctl.
+ */
+
+struct eb_fence {
+ struct drm_syncobj *syncobj;
+ struct dma_fence *dma_fence;
+ u64 value;
+ struct dma_fence_chain *chain_fence;
+};
+
+/**
+ * struct i915_execbuffer - execbuf struct for execbuf3
+ * @i915: reference to the i915 instance we run on
+ * @file: drm file reference
+ * args: execbuf3 ioctl structure
+ * @gt: reference to the gt instance ioctl submitted for
+ * @context: logical state for the request
+ * @gem_context: callers context
+ * @requests: requests to be build
+ * @composite_fence: used for excl fence in dma_resv objects when > 1 BB
submitted
+ * @ww: i915_gem_ww_ctx instance
+ * @num_batches: number of batches submitted
+ * @batch_addresses: addresses corresponds to the submitted batches
+ * @batches: references to the i915_vmas corresponding to the batches
+ */
+struct i915_execbuffer {
+ struct drm_i915_private *i915;
+ struct drm_file *file;
+ struct drm_i915_gem_execbuffer3 *args;
+
+ struct intel_gt *gt;
+ struct intel_context *context;
+ struct i915_gem_context *gem_context;
+
+ struct i915_request *requests[MAX_ENGINE_INSTANCE +
[RFC PATCH v3 01/17] drm/i915: Expose vm_lookup in i915_gem_context.h
From: Niranjana Vishwanathapura
To reuse i915_gem_vm_lookup in upcoming implementation, expose it in
i915_gem_context.h
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 ++-
drivers/gpu/drm/i915/gem/i915_gem_context.h | 3 +++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index dabdfe09f5e51..fdd3e3bfd4088 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -346,7 +346,16 @@ static int proto_context_register(struct
drm_i915_file_private *fpriv,
return ret;
}
-static struct i915_address_space *
+/**
+ * i915_gem_vm_lookup() - looks up for the VM reference given the vm id
+ * @file_priv: the private data associated with the user's file
+ * @id: the VM id
+ *
+ * Finds the VM reference associated to a specific id.
+ *
+ * Returns the VM pointer on success, NULL in case of failure.
+ */
+struct i915_address_space *
i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id)
{
struct i915_address_space *vm;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index e5b0f66ea1feb..899fa8f1e0fed 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -139,6 +139,9 @@ int i915_gem_context_setparam_ioctl(struct drm_device *dev,
void *data,
int i915_gem_context_reset_stats_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+struct i915_address_space *
+i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id);
+
struct i915_gem_context *
i915_gem_context_lookup(struct drm_i915_file_private *file_priv, u32 id);
--
2.34.1
[RFC PATCH v3 07/17] drm/i915/vm_bind: Handle persistent vmas
From: Niranjana Vishwanathapura
Treat VM_BIND vmas as persistent across execbuf ioctl calls and handle
them during the request submission in the execbuff path.
Support eviction by maintaining a list of evicted persistent vmas
for rebinding during next submission.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 +
.../drm/i915/gem/i915_gem_vm_bind_object.c| 8 +++
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 4 ++
drivers/gpu/drm/i915/i915_gem_gtt.c | 38 +
drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +
drivers/gpu/drm/i915/i915_vma.c | 50 +++--
drivers/gpu/drm/i915/i915_vma.h | 56 +++
drivers/gpu/drm/i915/i915_vma_types.h | 24
9 files changed, 169 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 389e9f157ca5e..825dce41f7113 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -38,6 +38,7 @@
#include "i915_gem_mman.h"
#include "i915_gem_object.h"
#include "i915_gem_ttm.h"
+#include "i915_gem_vm_bind.h"
#include "i915_memcpy.h"
#include "i915_trace.h"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 9ff929f187cfd..3b45529fe8d4c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -91,6 +91,13 @@ void i915_gem_vm_bind_remove(struct i915_vma *vma, bool
release_obj)
{
lockdep_assert_held(>vm->vm_bind_lock);
+ spin_lock(>vm->vm_rebind_lock);
+ if (!list_empty(>vm_rebind_link))
+ list_del_init(>vm_rebind_link);
+ i915_vma_set_purged(vma);
+ i915_vma_set_freed(vma);
+ spin_unlock(>vm->vm_rebind_lock);
+
if (!list_empty(>vm_bind_link)) {
list_del_init(>vm_bind_link);
list_del_init(>non_priv_vm_bind_link);
@@ -190,6 +197,7 @@ static struct i915_vma *vm_bind_get_vma(struct
i915_address_space *vm,
vma->start = va->start;
vma->last = va->start + va->length - 1;
+ i915_vma_set_persistent(vma);
return vma;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index c4f75826213ae..97cd0089b516d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -296,6 +296,8 @@ void i915_address_space_init(struct i915_address_space *vm,
int subclass)
INIT_LIST_HEAD(>non_priv_vm_bind_list);
vm->root_obj = i915_gem_object_create_internal(vm->i915, PAGE_SIZE);
GEM_BUG_ON(IS_ERR(vm->root_obj));
+ INIT_LIST_HEAD(>vm_rebind_list);
+ spin_lock_init(>vm_rebind_lock);
}
void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 9a2665e4ec2e5..1f3b1967ec175 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -265,6 +265,10 @@ struct i915_address_space {
struct list_head vm_bind_list;
/** @vm_bound_list: List of vm_binding completed */
struct list_head vm_bound_list;
+ /* @vm_rebind_list: list of vmas to be rebinded */
+ struct list_head vm_rebind_list;
+ /* @vm_rebind_lock: protects vm_rebound_list */
+ spinlock_t vm_rebind_lock;
/* @va: tree of persistent vmas */
struct rb_root_cached va;
struct list_head non_priv_vm_bind_list;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 329ff75b80b97..f083724163deb 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -25,6 +25,44 @@
#include "i915_trace.h"
#include "i915_vgpu.h"
+/**
+ * i915_vm_sync() - Wait for all requests on private vmas of a vm to be
completed
+ * @vm: address space we need to wait for idle
+ *
+ * Waits till all requests of the vm_binded private objs are completed.
+ *
+ * Returns: 0 on success -ve errcode on failure
+ */
+int i915_vm_sync(struct i915_address_space *vm)
+{
+ int ret;
+
+ /* Wait for all requests under this vm to finish */
+ ret = dma_resv_wait_timeout(vm->root_obj->base.resv,
+ DMA_RESV_USAGE_BOOKKEEP, false,
+ MAX_SCHEDULE_TIMEOUT);
+ if (ret < 0)
+ return ret;
+ else if (ret > 0)
+ return 0;
+ else
+ return -ETIMEDOUT;
+}
+
+/**
+ * i915_vm_is_active() - Check for activeness of requests of vm
+ * @vm: address spece targetted
+ *
+ * Check whether all the requests related private vmas are completed or not
+ *
+ * Returns: True
[RFC PATCH v3 09/17] drm/i915: Do not support vm_bind mode in execbuf2
From: Niranjana Vishwanathapura
Do not support the vm in vm_bind_mode in execbuf2 ioctl.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index cd75b0ca2555f..f85f10cf9c34b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -781,6 +781,11 @@ static int eb_select_context(struct i915_execbuffer *eb)
if (unlikely(IS_ERR(ctx)))
return PTR_ERR(ctx);
+ if (ctx->vm->vm_bind_mode) {
+ i915_gem_context_put(ctx);
+ return -EOPNOTSUPP;
+ }
+
eb->gem_context = ctx;
if (i915_gem_context_has_full_ppgtt(ctx))
eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
--
2.34.1
[RFC PATCH v3 06/17] drm/i915/dmabuf: Deny the dmabuf export for VM private BOs
From: Niranjana Vishwanathapura
VM private BOs can be only mapped on specified VM and cannot be dmabuf
exported.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index f5062d0c63336..6433173c3e84d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -218,6 +218,12 @@ struct dma_buf *i915_gem_prime_export(struct
drm_gem_object *gem_obj, int flags)
struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+ if (obj->priv_root) {
+ drm_dbg(obj->base.dev,
+ "Exporting VM private objects is not allowed\n");
+ return ERR_PTR(-EINVAL);
+ }
+
exp_info.ops = _dmabuf_ops;
exp_info.size = gem_obj->size;
exp_info.flags = flags;
--
2.34.1
[RFC PATCH v3 05/17] drm/i915: Support for VM private BOs
From: Niranjana Vishwanathapura
Each VM creates a root_obj and shares it with all of its private objects
to use it as dma_resv object. This has a performance advantage as it
requires a single dma_resv object update for all private BOs vs list of
dma_resv objects update for shared BOs, in the execbuf path.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 3 +++
drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c | 9 +
drivers/gpu/drm/i915/gt/intel_gtt.c| 4
drivers/gpu/drm/i915/gt/intel_gtt.h| 2 ++
drivers/gpu/drm/i915/i915_vma.c| 1 +
drivers/gpu/drm/i915/i915_vma_types.h | 2 ++
6 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 9f6b14ec189a2..46308dcf39e99 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -241,6 +241,9 @@ struct drm_i915_gem_object {
const struct drm_i915_gem_object_ops *ops;
+ /* For VM private BO, points to root_obj in VM. NULL otherwise */
+ struct drm_i915_gem_object *priv_root;
+
struct {
/**
* @vma.lock: protect the list/tree of vmas
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index dadd1d4b1761b..9ff929f187cfd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -93,6 +93,7 @@ void i915_gem_vm_bind_remove(struct i915_vma *vma, bool
release_obj)
if (!list_empty(>vm_bind_link)) {
list_del_init(>vm_bind_link);
+ list_del_init(>non_priv_vm_bind_link);
i915_vm_bind_it_remove(vma, >vm->va);
/* Release object */
@@ -219,6 +220,11 @@ static int i915_gem_vm_bind_obj(struct i915_address_space
*vm,
goto put_obj;
}
+ if (obj->priv_root && obj->priv_root != vm->root_obj) {
+ ret = -EINVAL;
+ goto put_obj;
+ }
+
ret = mutex_lock_interruptible(>vm_bind_lock);
if (ret)
goto put_obj;
@@ -244,6 +250,9 @@ static int i915_gem_vm_bind_obj(struct i915_address_space
*vm,
list_add_tail(>vm_bind_link, >vm_bound_list);
i915_vm_bind_it_insert(vma, >va);
+ if (!obj->priv_root)
+ list_add_tail(>non_priv_vm_bind_link,
+ >non_priv_vm_bind_list);
out_ww:
if (ret == -EDEADLK) {
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index cb188377b7bd9..c4f75826213ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -177,6 +177,7 @@ int i915_vm_lock_objects(struct i915_address_space *vm,
void i915_address_space_fini(struct i915_address_space *vm)
{
drm_mm_takedown(>mm);
+ i915_gem_object_put(vm->root_obj);
GEM_BUG_ON(!RB_EMPTY_ROOT(>va.rb_root));
mutex_destroy(>vm_bind_lock);
}
@@ -292,6 +293,9 @@ void i915_address_space_init(struct i915_address_space *vm,
int subclass)
INIT_LIST_HEAD(>vm_bind_list);
INIT_LIST_HEAD(>vm_bound_list);
mutex_init(>vm_bind_lock);
+ INIT_LIST_HEAD(>non_priv_vm_bind_list);
+ vm->root_obj = i915_gem_object_create_internal(vm->i915, PAGE_SIZE);
+ GEM_BUG_ON(IS_ERR(vm->root_obj));
}
void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 06a259475816b..9a2665e4ec2e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -267,6 +267,8 @@ struct i915_address_space {
struct list_head vm_bound_list;
/* @va: tree of persistent vmas */
struct rb_root_cached va;
+ struct list_head non_priv_vm_bind_list;
+ struct drm_i915_gem_object *root_obj;
/* Global GTT */
bool is_ggtt:1;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 092ae4309d8a1..239346e0c07f2 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -236,6 +236,7 @@ vma_create(struct drm_i915_gem_object *obj,
mutex_unlock(>mutex);
INIT_LIST_HEAD(>vm_bind_link);
+ INIT_LIST_HEAD(>non_priv_vm_bind_link);
return vma;
err_unlock:
diff --git a/drivers/gpu/drm/i915/i915_vma_types.h
b/drivers/gpu/drm/i915/i915_vma_types.h
index f746fecae85ed..de5534d518cdd 100644
--- a/drivers/gpu/drm/i915/i915_vma_types.h
+++ b/drivers/gpu/drm/i915/i915_vma_types.h
@@ -291,6 +291,8 @@ struct i915_vma {
/** @vm_bind_link: node for the vm_bind related lists of vm */
[RFC PATCH v3 04/17] drm/i915: Implement bind and unbind of object
From: Niranjana Vishwanathapura Implement the bind and unbind of an object at the specified GPU virtual addresses. Signed-off-by: Niranjana Vishwanathapura Signed-off-by: Prathap Kumar Valsan Signed-off-by: Ramalingam C Signed-off-by: Andi Shyti --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 21 ++ .../drm/i915/gem/i915_gem_vm_bind_object.c| 322 ++ drivers/gpu/drm/i915/gt/intel_gtt.c | 10 + drivers/gpu/drm/i915/gt/intel_gtt.h | 9 + drivers/gpu/drm/i915/i915_driver.c| 1 + drivers/gpu/drm/i915/i915_vma.c | 3 +- drivers/gpu/drm/i915/i915_vma.h | 2 - drivers/gpu/drm/i915/i915_vma_types.h | 14 + include/uapi/drm/i915_drm.h | 163 + 10 files changed, 543 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 522ef9b4aff32..4e1627e96c6e0 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -165,6 +165,7 @@ gem-y += \ gem/i915_gem_ttm_move.o \ gem/i915_gem_ttm_pm.o \ gem/i915_gem_userptr.o \ + gem/i915_gem_vm_bind_object.o \ gem/i915_gem_wait.o \ gem/i915_gemfs.o i915-y += \ diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h new file mode 100644 index 0..ebc493b7dafc1 --- /dev/null +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h @@ -0,0 +1,21 @@ +/* SPDX-License-Identifier: MIT */ +/* + * Copyright © 2022 Intel Corporation + */ + +#ifndef __I915_GEM_VM_BIND_H +#define __I915_GEM_VM_BIND_H + +#include "i915_drv.h" + +struct i915_vma * +i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va); +void i915_gem_vm_bind_remove(struct i915_vma *vma, bool release_obj); + +int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data, + struct drm_file *file); +int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data, +struct drm_file *file); + +void i915_gem_vm_unbind_vma_all(struct i915_address_space *vm); +#endif /* __I915_GEM_VM_BIND_H */ diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c new file mode 100644 index 0..dadd1d4b1761b --- /dev/null +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c @@ -0,0 +1,322 @@ +// SPDX-License-Identifier: MIT +/* + * Copyright © 2022 Intel Corporation + */ + +#include + +#include "gem/i915_gem_vm_bind.h" +#include "gem/i915_gem_context.h" +#include "gt/gen8_engine_cs.h" + +#include "i915_drv.h" +#include "i915_gem_gtt.h" + +#define START(node) ((node)->start) +#define LAST(node) ((node)->last) + +INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last, +START, LAST, static inline, i915_vm_bind_it) + +#undef START +#undef LAST + +/** + * DOC: VM_BIND/UNBIND ioctls + * + * DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer + * objects (BOs) or sections of a BOs at specified GPU virtual addresses on a + * specified address space (VM). Multiple mappings can map to the same physical + * pages of an object (aliasing). These mappings (also referred to as persistent + * mappings) will be persistent across multiple GPU submissions (execbuf calls) + * issued by the UMD, without user having to provide a list of all required + * mappings during each submission (as required by older execbuf mode). + * + * The VM_BIND/UNBIND calls allow UMDs to request a timeline out fence for + * signaling the completion of bind/unbind operation. + * + * VM_BIND feature is advertised to user via I915_PARAM_VM_BIND_VERSION. + * User has to opt-in for VM_BIND mode of binding for an address space (VM) + * during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension. + * + * VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently + * are not ordered. Furthermore, parts of the VM_BIND/UNBIND operations can be + * done asynchronously, when valid out fence is specified. + * + * VM_BIND locking order is as below. + * + * 1) vm_bind_lock mutex will protect vm_bind lists. This lock is taken in + *vm_bind/vm_unbind ioctl calls, in the execbuf path and while releasing the + *mapping. + * + *In future, when GPU page faults are supported, we can potentially use a + *rwsem instead, so that multiple page fault handlers can take the read + *side lock to lookup the mapping and hence can run in parallel. + *The older execbuf mode of binding do not need this lock. + * + * 2) The object's dma-resv lock will protect i915_vma state and needs + *to be held while binding/unbinding a vma in the async worker and while + *updating dma-resv fence list of
[RFC PATCH v3 03/17] drm/i915/gem: expose i915_gem_object_max_page_size() in i915_gem_object.h
From: Niranjana Vishwanathapura
To reuse i915_gem_object_max_page_size() in upcoming
implementation, expose it in i915_gem_object.h
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 16 +---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 ++
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 33673fe7ee0ac..b0aebcc52f83c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -15,8 +15,17 @@
#include "i915_trace.h"
#include "i915_user_extensions.h"
-static u32 object_max_page_size(struct intel_memory_region **placements,
- unsigned int n_placements)
+/**
+ * i915_gem_object_max_page_size() - max of min_page_size of the regions
+ * @placements: list of regions
+ * @n_placements: number of the placements
+ *
+ * Calculates the max of the min_page_size of a list of placements passed in.
+ *
+ * Return: max of the min_page_size
+ */
+u32 i915_gem_object_max_page_size(struct intel_memory_region **placements,
+ unsigned int n_placements)
{
u32 max_page_size = 0;
int i;
@@ -99,7 +108,8 @@ __i915_gem_object_create_user_ext(struct drm_i915_private
*i915, u64 size,
i915_gem_flush_free_objects(i915);
- size = round_up(size, object_max_page_size(placements, n_placements));
+ size = round_up(size, i915_gem_object_max_page_size(placements,
+ n_placements));
if (size == 0)
return ERR_PTR(-EINVAL);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 6f0a3ce355670..650de22248435 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -47,6 +47,8 @@ static inline bool i915_gem_object_size_2big(u64 size)
}
void i915_gem_init__objects(struct drm_i915_private *i915);
+u32 i915_gem_object_max_page_size(struct intel_memory_region **placements,
+ unsigned int n_placements);
void i915_objects_module_exit(void);
int i915_objects_module_init(void);
--
2.34.1
[RFC PATCH v3 02/17] drm/i915: Mark vm for vm_bind usage at creation
From: Niranjana Vishwanathapura
At vm creation time, add a flag to indicate that the new vm will use
vm_bind only for object binding.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Ramalingam C
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 -
drivers/gpu/drm/i915/gt/intel_gtt.h | 8
include/uapi/drm/i915_drm.h | 3 ++-
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index fdd3e3bfd4088..2e25341f78ab6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1808,7 +1808,7 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void
*data,
if (!HAS_FULL_PPGTT(i915))
return -ENODEV;
- if (args->flags)
+ if (args->flags & I915_VM_CREATE_FLAGS_UNKNOWN)
return -EINVAL;
ppgtt = i915_ppgtt_create(to_gt(i915), 0);
@@ -1828,6 +1828,9 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void
*data,
if (err)
goto err_put;
+ if (args->flags & I915_VM_CREATE_FLAGS_USE_VM_BIND)
+ ppgtt->vm.vm_bind_mode = true;
+
GEM_BUG_ON(id == 0); /* reserved for invalid/unassigned ppgtt */
args->vm_id = id;
return 0;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index e639434e97fdb..da21088890b3b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -271,6 +271,14 @@ struct i915_address_space {
/* Skip pte rewrite on unbind for suspend. Protected by @mutex */
bool skip_pte_rewrite:1;
+ /**
+* @vm_bind_mode: flag to indicate vm_bind method of binding
+*
+* True: allow only vm_bind method of binding.
+* False: allow only legacy execbuff method of binding.
+*/
+ bool vm_bind_mode:1;
+
u8 top;
u8 pd_shift;
u8 scratch_order;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 520ad2691a99d..12435db751eb8 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -2522,7 +2522,8 @@ struct drm_i915_gem_vm_control {
/** @extensions: Zero-terminated chain of extensions. */
__u64 extensions;
- /** @flags: reserved for future usage, currently MBZ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1u << 0)
+#define I915_VM_CREATE_FLAGS_UNKNOWN (-(I915_VM_CREATE_FLAGS_USE_VM_BIND <<
1))
__u32 flags;
/** @vm_id: Id of the VM created or to be destroyed */
--
2.34.1
[RFC PATCH v3 00/17] drm/i915/vm_bind: Add VM_BIND functionality
Hi, just sending the original Niranjana's patch as an RFC. It's v3 as the v2 has been reviewed offline with Ramalingam. I'm still keeping most of the structure even though some further discussion can be done starting from here. Copy pasting Niranjana's original cover letter message: DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer objects (BOs) or sections of a BOs at specified GPU virtual addresses on a specified address space (VM). Multiple mappings can map to the same physical pages of an object (aliasing). These mappings (also referred to as persistent mappings) will be persistent across multiple GPU submissions (execbuf calls) issued by the UMD, without user having to provide a list of all required mappings during each submission (as required by older execbuf mode). This patch series support VM_BIND version 1, as described by the param I915_PARAM_VM_BIND_VERSION. Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl. The new execbuf3 ioctl will not have any execlist support and all the legacy support like relocations etc., are removed. TODOs: * Support out fence for VM_UNBIND ioctl. * Async VM_UNBIND support. * Share code between execbuf2 and execbuf3 where possible. * Cleanups and optimizations. NOTEs: * It is based on below VM_BIND design+uapi patch series. https://lists.freedesktop.org/archives/intel-gfx/2022-July/300760.html * The IGT RFC series is posted as, [RFC 0/5] vm_bind: Add VM_BIND validation support Niranjana Vishwanathapura (17): drm/i915: Expose vm_lookup in i915_gem_context.h drm/i915: Mark vm for vm_bind usage at creation drm/i915/gem: expose i915_gem_object_max_page_size() in i915_gem_object.h drm/i915: Implement bind and unbind of object drm/i915: Support for VM private BOs drm/i915/dmabuf: Deny the dmabuf export for VM private BOs drm/i915/vm_bind: Handle persistent vmas drm/i915/vm_bind: Add out fence support drm/i915: Do not support vm_bind mode in execbuf2 drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl drm/i915: Add i915_vma_is_bind_complete() drm/i915/vm_bind: Handle persistent vmas in execbuf3 drm/i915/vm_bind: userptr dma-resv changes drm/i915/vm_bind: Skip vma_lookup for persistent vmas drm/i915: Extend getparm for VM_BIND capability drm/i915/ioctl: Enable the vm_bind/unbind ioctls drm/i915: Enable execbuf3 ioctl for vm_bind drivers/gpu/drm/i915/Makefile |2 + drivers/gpu/drm/i915/display/intel_fb_pin.c |2 +- .../drm/i915/display/intel_plane_initial.c|2 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 16 +- drivers/gpu/drm/i915/gem/i915_gem_context.h |3 + drivers/gpu/drm/i915/gem/i915_gem_create.c| 16 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c|6 + .../gpu/drm/i915/gem/i915_gem_execbuffer.c|9 +- .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 1275 + drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|2 + drivers/gpu/drm/i915/gem/i915_gem_object.c|1 + drivers/gpu/drm/i915/gem/i915_gem_object.h|2 + .../gpu/drm/i915/gem/i915_gem_object_types.h |3 + drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 10 + drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 24 + .../drm/i915/gem/i915_gem_vm_bind_object.c| 437 ++ .../gpu/drm/i915/gem/selftests/huge_pages.c | 16 +- .../i915/gem/selftests/i915_gem_client_blt.c |2 +- .../drm/i915/gem/selftests/i915_gem_context.c | 12 +- .../drm/i915/gem/selftests/i915_gem_migrate.c |2 +- .../drm/i915/gem/selftests/i915_gem_mman.c|6 +- .../drm/i915/gem/selftests/igt_gem_utils.c|2 +- drivers/gpu/drm/i915/gt/gen6_ppgtt.c |2 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c |2 +- drivers/gpu/drm/i915/gt/intel_gt.c|2 +- drivers/gpu/drm/i915/gt/intel_gtt.c | 20 +- drivers/gpu/drm/i915/gt/intel_gtt.h | 27 + drivers/gpu/drm/i915/gt/intel_lrc.c |4 +- drivers/gpu/drm/i915/gt/intel_renderstate.c |2 +- drivers/gpu/drm/i915/gt/intel_ring.c |2 +- .../gpu/drm/i915/gt/intel_ring_submission.c |4 +- drivers/gpu/drm/i915/gt/intel_timeline.c |2 +- drivers/gpu/drm/i915/gt/mock_engine.c |2 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c |4 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 16 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c |6 +- drivers/gpu/drm/i915/gt/selftest_lrc.c|2 +- .../drm/i915/gt/selftest_ring_submission.c|2 +- drivers/gpu/drm/i915/gt/selftest_rps.c|2 +- .../gpu/drm/i915/gt/selftest_workarounds.c|4 +- drivers/gpu/drm/i915/gt/uc/intel_guc.c|2 +- drivers/gpu/drm/i915/i915_driver.c|4 + drivers/gpu/drm/i915/i915_gem.c |2 +- drivers/gpu/drm/i915/i915_gem_gtt.c | 38 +
[PATCH] Documentation: fb: udlfb: clean up text and formatting
Clean up punctuation, spelling, and formatting for command line usage and modprobe config file usage in udlfb.rst. Signed-off-by: Randy Dunlap Cc: Bernie Thompson Cc: linux-fb...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Helge Deller Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org --- Documentation/fb/udlfb.rst | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) --- a/Documentation/fb/udlfb.rst +++ b/Documentation/fb/udlfb.rst @@ -86,17 +86,21 @@ Module Options Special configuration for udlfb is usually unnecessary. There are a few options, however. -From the command line, pass options to modprobe -modprobe udlfb fb_defio=0 console=1 shadow=1 +From the command line, pass options to modprobe:: -Or modify options on the fly at /sys/module/udlfb/parameters directory via -sudo nano fb_defio -change the parameter in place, and save the file. + modprobe udlfb fb_defio=0 console=1 shadow=1 + +Or modify options on the fly at /sys/module/udlfb/parameters directory via:: + + sudo nano fb_defio + change the parameter in place, and save the file. Unplug/replug USB device to apply with new settings -Or for permanent option, create file like /etc/modprobe.d/udlfb.conf with text -options udlfb fb_defio=0 console=1 shadow=1 +Or for permanent options, create a file like /etc/modprobe.d/udlfb.conf +with text:: + + options udlfb fb_defio=0 console=1 shadow=1 Accepted boolean options:
Re: [PATCH v5 2/2] drm: rcar-du: Add RZ/G2L DSI driver
Hi Biju,
On Sat, Aug 27, 2022 at 07:07:20PM +, Biju Das wrote:
> Subject: Re: [PATCH v5 2/2] drm: rcar-du: Add RZ/G2L DSI driver
> > On Thu, Aug 25, 2022 at 02:42:29PM +0100, Biju Das wrote:
> > > This driver supports the MIPI DSI encoder found in the RZ/G2L SoC. It
> > > currently supports DSI mode only.
> >
> > What other modes than DSI are there ?
>
> Currently it supports video mode only (video-input operation).
>
> This mode is tested with DSI connected to ADV7535 bridge.
>
> But lot of customers are asking for DSI panel support as well.
> So going forward this driver needs to support DSI DCS commands
> for supporting DSI panels.
Ah OK. Then you can update the commit message to say "DSI video mode
only" instead of "DSI mode only".
> > > Signed-off-by: Biju Das
> > > Acked-by: Sam Ravnborg
> > > ---
> > > v4->v5:
> > > * Added Ack from Sam.
> > > * Added a trivial change, replaced rzg2l_mipi_dsi_parse_dt()
> > >with drm_of_get_data_lanes_count_ep() in probe.
> > > v3->v4:
> > > * Updated error handling in rzg2l_mipi_dsi_startup() and
> > > rzg2l_mipi_dsi_atomic_enable()
> > > v2->v3:
> > > * pass rzg2l_mipi_dsi pointer to {Link,Phy} register rd/wr function
> > > instead
> > >of the memory pointer
> > > * Fixed the comment in rzg2l_mipi_dsi_startup()
> > > * Removed unnecessary dbg message from rzg2l_mipi_dsi_start_video()
> > > * DRM bridge parameter initialization moved to probe
> > > * Replaced dev_dbg->dev_err in rzg2l_mipi_dsi_parse_dt()
> > > * Inserted the missing blank lane after return in probe()
> > > * Added missing MODULE_DEVICE_TABLE
> > > * Added include linux/bits.h in header file
> > > * Fixed various macros in header file.
> > > * Reorder the make file for DSI, so that it is no more dependent
> > >on RZ/G2L DU patch series.
> > > v1->v2:
> > > * Rework based on dt-binding change (DSI + D-PHY) as single block
> > > * Replaced link_mmio and phy_mmio with mmio in struct rzg2l_mipi_dsi
> > > * Replaced rzg2l_mipi_phy_write with rzg2l_mipi_dsi_phy_write
> > >and rzg2l_mipi_dsi_link_write
> > > * Replaced rzg2l_mipi_phy_read->rzg2l_mipi_dsi_link_read
> > > RFC->v1:
> > > * Added "depends on ARCH_RENESAS || COMPILE_TEST" on KCONFIG
> > >and dropped DRM as it is implied by DRM_BRIDGE
> > > * Used devm_reset_control_get_exclusive() for reset handle
> > > * Removed bool hsclkmode from struct rzg2l_mipi_dsi
> > > * Added error check for pm, using pm_runtime_resume_and_get() instead of
> > >pm_runtime_get_sync()
> > > * Added check for unsupported formats in rzg2l_mipi_dsi_host_attach()
> > > * Avoided read-modify-write stopping hsclock
> > > * Used devm_platform_ioremap_resource for resource allocation
> > > * Removed unnecessary assert call from probe and remove.
> > > * wrap the line after the PTR_ERR() in probe()
> > > * Updated reset failure messages in probe
> > > * Fixed the typo arstc->prstc
> > > * Made hex constants to lower case.
> > > RFC:
> > > *
> > > ---
> > > drivers/gpu/drm/rcar-du/Kconfig | 8 +
> > > drivers/gpu/drm/rcar-du/Makefile | 2 +
> > > drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 690 ++
> > > drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h | 151
> > > 4 files changed, 851 insertions(+)
> > > create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> > > create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h
--
Regards,
Laurent Pinchart
RE: [PATCH v5 2/2] drm: rcar-du: Add RZ/G2L DSI driver
Hi Laurent,
Thanks for the feedback.
> Subject: Re: [PATCH v5 2/2] drm: rcar-du: Add RZ/G2L DSI driver
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Thu, Aug 25, 2022 at 02:42:29PM +0100, Biju Das wrote:
> > This driver supports the MIPI DSI encoder found in the RZ/G2L SoC. It
> > currently supports DSI mode only.
>
> What other modes than DSI are there ?
Currently it supports video mode only (video-input operation).
This mode is tested with DSI connected to ADV7535 bridge.
But lot of customers are asking for DSI panel support as well.
So going forward this driver needs to support DSI DCS commands
for supporting DSI panels.
>
> > Signed-off-by: Biju Das
> > Acked-by: Sam Ravnborg
> > ---
> > v4->v5:
> > * Added Ack from Sam.
> > * Added a trivial change, replaced rzg2l_mipi_dsi_parse_dt()
> >with drm_of_get_data_lanes_count_ep() in probe.
> > v3->v4:
> > * Updated error handling in rzg2l_mipi_dsi_startup() and
> > rzg2l_mipi_dsi_atomic_enable()
> > v2->v3:
> > * pass rzg2l_mipi_dsi pointer to {Link,Phy} register rd/wr function
> instead
> >of the memory pointer
> > * Fixed the comment in rzg2l_mipi_dsi_startup()
> > * Removed unnecessary dbg message from rzg2l_mipi_dsi_start_video()
> > * DRM bridge parameter initialization moved to probe
> > * Replaced dev_dbg->dev_err in rzg2l_mipi_dsi_parse_dt()
> > * Inserted the missing blank lane after return in probe()
> > * Added missing MODULE_DEVICE_TABLE
> > * Added include linux/bits.h in header file
> > * Fixed various macros in header file.
> > * Reorder the make file for DSI, so that it is no more dependent
> >on RZ/G2L DU patch series.
> > v1->v2:
> > * Rework based on dt-binding change (DSI + D-PHY) as single block
> > * Replaced link_mmio and phy_mmio with mmio in struct rzg2l_mipi_dsi
> > * Replaced rzg2l_mipi_phy_write with rzg2l_mipi_dsi_phy_write
> >and rzg2l_mipi_dsi_link_write
> > * Replaced rzg2l_mipi_phy_read->rzg2l_mipi_dsi_link_read
> > RFC->v1:
> > * Added "depends on ARCH_RENESAS || COMPILE_TEST" on KCONFIG
> >and dropped DRM as it is implied by DRM_BRIDGE
> > * Used devm_reset_control_get_exclusive() for reset handle
> > * Removed bool hsclkmode from struct rzg2l_mipi_dsi
> > * Added error check for pm, using pm_runtime_resume_and_get() instead
> of
> >pm_runtime_get_sync()
> > * Added check for unsupported formats in rzg2l_mipi_dsi_host_attach()
> > * Avoided read-modify-write stopping hsclock
> > * Used devm_platform_ioremap_resource for resource allocation
> > * Removed unnecessary assert call from probe and remove.
> > * wrap the line after the PTR_ERR() in probe()
> > * Updated reset failure messages in probe
> > * Fixed the typo arstc->prstc
> > * Made hex constants to lower case.
> > RFC:
> > *
> > ---
> > drivers/gpu/drm/rcar-du/Kconfig | 8 +
> > drivers/gpu/drm/rcar-du/Makefile | 2 +
> > drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 690
> ++
> > drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h | 151
> > 4 files changed, 851 insertions(+)
> > create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> > create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h
> >
> > diff --git a/drivers/gpu/drm/rcar-du/Kconfig
> > b/drivers/gpu/drm/rcar-du/Kconfig index c959e8c6be7d..58ffb8c2443b
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > @@ -51,6 +51,14 @@ config DRM_RCAR_MIPI_DSI
> > help
> > Enable support for the R-Car Display Unit embedded MIPI DSI
> encoders.
> >
> > +config DRM_RZG2L_MIPI_DSI
> > + tristate "RZ/G2L MIPI DSI Encoder Support"
> > + depends on DRM_BRIDGE && OF
> > + depends on ARCH_RENESAS || COMPILE_TEST
> > + select DRM_MIPI_DSI
> > + help
> > + Enable support for the RZ/G2L Display Unit embedded MIPI DSI
> encoders.
> > +
> > config DRM_RCAR_VSP
> > bool "R-Car DU VSP Compositor Support" if ARM
> > default y if ARM64
> > diff --git a/drivers/gpu/drm/rcar-du/Makefile
> > b/drivers/gpu/drm/rcar-du/Makefile
> > index e7275b5e7ec8..14a3fa88cc0b 100644
> > --- a/drivers/gpu/drm/rcar-du/Makefile
> > +++ b/drivers/gpu/drm/rcar-du/Makefile
> > @@ -15,6 +15,8 @@ obj-$(CONFIG_DRM_RCAR_DW_HDMI)+=
> rcar_dw_hdmi.o
> > obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
> > obj-$(CONFIG_DRM_RCAR_MIPI_DSI)+= rcar_mipi_dsi.o
> >
> > +obj-$(CONFIG_DRM_RZG2L_MIPI_DSI) += rzg2l_mipi_dsi.o
> > +
> > # 'remote-endpoint' is fixed up at run-time
> > DTC_FLAGS_rcar_du_of_lvds_r8a7790 += -Wno-graph_endpoint
> > DTC_FLAGS_rcar_du_of_lvds_r8a7791 += -Wno-graph_endpoint diff --git
> > a/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> > b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> > new file mode 100644
> > index ..e0bdb5dc7036
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> > @@ -0,0 +1,690 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * RZ/G2L MIPI
Re: [PATCH 2/2] drm: rcar-du: Use %p4cc to print 4CC format
Hi Biju,
On Sat, Aug 27, 2022 at 09:04:25AM +, Biju Das wrote:
> Subject: Re: [PATCH 2/2] drm: rcar-du: Use %p4cc to print 4CC format
> > On Thu, Aug 25, 2022 at 11:39:05AM +0100, Biju Das wrote:
> > > Replace use of struct rcar_du_format_info with %p4cc for printing 4CC
> > > formats.
> >
> > The code change looks good, but doesn't match the commit message. You're
> > not replacing usage of struct rcar_du_format_info. I propose the
> > following commit message:
> >
> > Use the %p4cc format specifier to print 4CCs, which will provide a more
> > readable message than the raw hex value.
>
> OK.
>
> > > Reported-by: Geert Uytterhoeven
> > > Signed-off-by: Biju Das
> > > ---
> > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > index 21881fb5e84a..8c2719efda2a 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > @@ -405,8 +405,8 @@ rcar_du_fb_create(struct drm_device *dev, struct
> > > drm_file *file_priv,
> > >
> > > format = rcar_du_format_info(mode_cmd->pixel_format);
> > > if (format == NULL) {
> > > - dev_dbg(dev->dev, "unsupported pixel format %08x\n",
> > > - mode_cmd->pixel_format);
> > > + dev_dbg(dev->dev, "unsupported pixel format %p4cc\n",
> > > + _cmd->pixel_format);
> > > return ERR_PTR(-EINVAL);
> > > }
> > >
> >
> > There are two other occurrences:
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > index 26b25ca58968..83631ee2fff1 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > @@ -626,8 +626,8 @@ int __rcar_du_plane_atomic_check(struct drm_plane
> > *plane,
> >
> > *format = rcar_du_format_info(state->fb->format->format);
> > if (*format == NULL) {
> > - dev_dbg(dev->dev, "%s: unsupported format %08x\n", __func__,
> > - state->fb->format->format);
> > + dev_dbg(dev->dev, "%s: unsupported format %p4cc\n",
> > __func__,
> > + >fb->format->format);
> > return -EINVAL;
> > }
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> > index 25f50a297c11..8cd37d7b8ae2 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> > @@ -166,8 +166,8 @@ static int rcar_du_wb_enc_atomic_check(struct
> > drm_encoder *encoder,
> >
> > wb_state->format = rcar_du_format_info(fb->format->format);
> > if (wb_state->format == NULL) {
> > - dev_dbg(dev->dev, "%s: unsupported format %08x\n", __func__,
> > - fb->format->format);
> > + dev_dbg(dev->dev, "%s: unsupported format %p4cc\n",
> > __func__,
> > + >format->format);
> > return -EINVAL;
> > }
> >
> > I can add these changes to the patch and update the commit message when
> > applying if you're fine with that. In that case,
>
> I am ok with it.
>
> Is it possible for you to share the git tree with latest RCar DU changes?
> so that I can rebase RCar DU lib and RZ/G2L DU work on top of that.
>
> Currently I am rebasing on top of drm_tip. Please let me know.
Sure. The tree is available at git://linuxtv.org/pinchartl/media.git,
and my drm next branch for the DU driver is drm/du/next.
> > Reviewed-by: Laurent Pinchart
--
Regards,
Laurent Pinchart
Re: [GIT PULL] fbdev updates & fixes for v6.0-rc3
The pull request you sent on Fri, 26 Aug 2022 20:29:35 +0200: > http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git > tags/fbdev-for-6.0-rc3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/89b749d8552d78c4dd86dea86e2e6ba8aafab9fe Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH] drm/msm: fix repeated words in comments
On Fri, Aug 26, 2022 at 2:43 AM Dmitry Baryshkov
wrote:
>
> On 23/08/2022 14:54, Jilin Yuan wrote:
> > Delete the redundant word 'one'.
>
> The whitespace is unnecessary.
>
> >
> > Signed-off-by: Jilin Yuan
>
> Reviewed-by: Dmitry Baryshkov
> Fixes: 7198e6b03155 ("drm/msm: add a3xx gpu support")
>
jfyi, this comment (and associated list-head) is removed by:
https://patchwork.freedesktop.org/patch/496131/?series=105633=4
BR,
-R
>
> > ---
> > drivers/gpu/drm/msm/msm_gem.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> > index c75d3b879a53..e300c70e8904 100644
> > --- a/drivers/gpu/drm/msm/msm_gem.h
> > +++ b/drivers/gpu/drm/msm/msm_gem.h
> > @@ -118,7 +118,7 @@ struct msm_gem_object {
> >* An object is either:
> >* inactive - on priv->inactive_dontneed or priv->inactive_willneed
> >* (depending on purgeability status)
> > - * active - on one one of the gpu's active_list.. well, at
> > + * active - on one of the gpu's active_list.. well, at
> >* least for now we don't have (I don't think) hw sync between
> >* 2d and 3d one devices which have both, meaning we need to
> >* block on submit if a bo is already on other ring
>
> --
> With best wishes
> Dmitry
>
Re: [PATCH v1 00/35] drm: Analog TV Improvements
Den 26.08.2022 16.56, skrev Dom Cobley: > On Fri, 26 Aug 2022 at 05:08, Mateusz Kwiatkowski wrote: >> - Commenting out the pm_runtime_put() / pm_runtime_get_sync() calls in >> vc4_vec.c >> - Reverting this PR by Dom Cobley a.k.a. popcornmix: >>https://github.com/raspberrypi/linux/pull/4639 >> >> Either of these approaches makes VEC mode switching work again. Obviously >> neither is appropriate for a permanent solution. > > Might be worth trying the latest rpi-update firmware. > There was a change that affects restoring PIXEL/VEC clocks after a > power domain cycle. > There is also a fix for a USB boot breakage. > That firmware gives me firmware timeout references in the 5 attempts I've done. My first attempt gave me this: [ 112.454982] WARNING: CPU: 2 PID: 855 at drivers/firmware/raspberrypi.c:63 rpi_firmware_property_list+0x204/0x270 [ 112.466985] Firmware transaction timeout ... [ 112.533740] warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x270 [ 112.541449] rpi_firmware_property_list from rpi_firmware_property+0x68/0x94 [ 112.549326] rpi_firmware_property from raspberrypi_clock_property+0x50/0x84 [ 112.557197] raspberrypi_clock_property from raspberrypi_fw_set_rate+0x4c/0xc4 [ 112.565242] raspberrypi_fw_set_rate from clk_change_rate+0x16c/0x6f8 [ 112.572502] clk_change_rate from clk_core_set_rate_nolock+0x1c4/0x2a4 [ 112.579857] clk_core_set_rate_nolock from clk_set_rate_range.part.0+0x128/0x2ac [ 112.588091] clk_set_rate_range.part.0 from vc4_atomic_commit_tail+0x2b4/0x854 [vc4] [ 112.596832] vc4_atomic_commit_tail [vc4] from commit_tail+0xa4/0x19c [ 112.604269] commit_tail from drm_atomic_helper_commit+0x16c/0x194 [ 112.611279] drm_atomic_helper_commit from drm_atomic_commit+0xb4/0xec [ 112.618625] drm_atomic_commit from drm_mode_atomic_ioctl+0x8f0/0xb6c [ 112.625877] drm_mode_atomic_ioctl from drm_ioctl_kernel+0xcc/0x170 [ 112.632950] drm_ioctl_kernel from drm_ioctl+0x1d8/0x374 [ 112.639056] drm_ioctl from sys_ioctl+0xe4/0xbac [ 112.644462] sys_ioctl from ret_fast_syscall+0x0/0x1c ... [ 112.726171] raspberrypi-clk soc:firmware:clocks: Failed to change fw-clk-core frequency: -110 I've also done one with drm debug enabled. Kernel messages: https://gist.github.com/notro/53afe9fdc3d0afbf0fb12678be1ab377 Dom, in case you want to debug this I've uploaded a rpi-update'able archive plus config.txt and cmdline.txt. There are some custom overlays in there that are needed. Kernel: tronnes.org/downloads/vec-kernel-2022-08-27.gz Build/setup info from another post: https://gist.github.com/notro/41c59d77c3022dc6d931d4f9547c4ea6 I've tried this on another Pi4 (same revision: c03111) as well to rule out any hw issues. The first attempt also gave me an mmc fault (no dmesg -w) and the second one (dmesg -w) gave me the timeout. Noralf.
[pull] drm/msm: drm-msm-fixes-2022-08-27 for v6.0
(one more time without forgetting dri-devel this time) Hi Dave, A few fixes for the v6.0 cycle. I meant to send this a bit earlier but ended up at the bottom of other rabbit holes. Summary below (and in tag msg) The following changes since commit cb77085b1f0a86ef9dfba86b5f3ed6c3340c2ea3: drm/msm/dpu: Fix for non-visible planes (2022-07-08 08:10:58 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/msm.git tags/drm-msm-fixes-2022-08-27 for you to fetch changes up to 174974d8463b77c2b4065e98513adb204e64de7d: drm/msm/rd: Fix FIFO-full deadlock (2022-08-15 10:19:53 -0700) Fixes for v6.0 - Fix for inconsistent indenting in function msm_dsi_dphy_timing_calc_v3. This fixes a smatch warning reported by kbot - Fix to make eDP the first connector in the connected list. This was mainly done to address a screen corruption issue we were seeing on sc7280 boards which have eDP as the primary display. The corruption itself is from usermode but we decided to fix it this way because things work correct with the primary display as the first one for usermode - Fix to populate intf_cfg correctly before calling reset_intf_cfg(). Without this, the display pipeline is not torn down correctly for writeback - Specify the correct number of DSI regulators for SDM660. It should have been 1 but 2 was mentioned - Specify the correct number of DSI regulators for MSM8996. It should have been 3 but 2 was mentioned - Fix for removing DP_RECOVERED_CLOCK_OUT_EN bit for tps4 link training for DP. This was causing link training failures and hence no display for a specific DP to HDMI cable on chromebooks - Fix probe-deferral crash in gpu devfreq - Fix gpu debugfs deadlock Abhinav Kumar (1): drm/msm/dpu: populate wb or intf before reset_intf_cfg Bjorn Andersson (1): drm/msm/gpu: Drop qos request if devm_devfreq_add_device() fails Douglas Anderson (2): drm/msm/dsi: Fix number of regulators for msm8996_dsi_cfg drm/msm/dsi: Fix number of regulators for SDM660 Kuogee Hsieh (2): drm/msm/dp: make eDP panel as the first connected connector drm/msm/dp: delete DP_RECOVERED_CLOCK_OUT_EN to fix tps4 Rob Clark (1): drm/msm/rd: Fix FIFO-full deadlock sunliming (1): drm/msm/dsi: fix the inconsistent indenting drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 ++ drivers/gpu/drm/msm/dp/dp_ctrl.c| 2 +- drivers/gpu/drm/msm/dsi/dsi_cfg.c | 4 ++-- drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +- drivers/gpu/drm/msm/msm_drv.c | 2 ++ drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 ++ drivers/gpu/drm/msm/msm_rd.c| 3 +++ 7 files changed, 17 insertions(+), 4 deletions(-)
[Bug 216143] [bisected] garbled screen when starting X + dmesg cluttered with "[drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed in the dependencies handling -1431655766!"
https://bugzilla.kernel.org/show_bug.cgi?id=216143 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #15 from Erhard F. (erhar...@mailbox.org) --- Agreed. I'll keep it open and check the issue again on new 6.x stable kernel releases and when clang 15 becomes available. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216143] [bisected] garbled screen when starting X + dmesg cluttered with "[drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed in the dependencies handling -1431655766!"
https://bugzilla.kernel.org/show_bug.cgi?id=216143 --- Comment #14 from Michel Dänzer (mic...@daenzer.net) --- (In reply to Erhard F. from comment #13) > I'll close here as it's clear this is not strictly an AMD driver issue. Not really clear; there could be buggy amdgpu driver code, which happens not to result in noticeable issues in practice when compiled by GCC. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216143] [bisected] garbled screen when starting X + dmesg cluttered with "[drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed in the dependencies handling -1431655766!"
https://bugzilla.kernel.org/show_bug.cgi?id=216143 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #13 from Erhard F. (erhar...@mailbox.org) --- Interesting! Found out this is a gcc vs. clang issue. Using a kernel built with the attached 5.19.4 config with clang-14.0.6 leads to the issue as described. Using a kernel built with the same config but with gcc-12.2.0 just works fine! I'll close here as it's clear this is not strictly an AMD driver issue. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216143] [bisected] garbled screen when starting X + dmesg cluttered with "[drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed in the dependencies handling -1431655766!"
https://bugzilla.kernel.org/show_bug.cgi?id=216143 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #301197|0 |1 is obsolete|| Attachment #301573|0 |1 is obsolete|| Attachment #301574|0 |1 is obsolete|| --- Comment #12 from Erhard F. (erhar...@mailbox.org) --- Created attachment 301683 --> https://bugzilla.kernel.org/attachment.cgi?id=301683=edit kernel .config (kernel 5.19.4, AMD Ryzen 9 5950X) -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v3 0/3] Drivers: hv: Avoid allocating MMIO from framebuffer region for other passed through PCI devices
Changes since v2:
- Add Michael's R-b tags to PATCHes1-3 and Bjorn's A-b tag to PATCH1.
- Commit messages tweaks [Michael].
Passed through PCI device sometimes misbehave on Gen1 VMs when Hyper-V
DRM driver is also loaded. Looking at IOMEM assignment, we can see e.g.
$ cat /proc/iomem
...
f800-fffb : PCI Bus :00
f800-fbff : :00:08.0
f800-f8001fff : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe
...
fe000-f : PCI Bus :00
fe000-fe07f : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe
fe000-fe07f : 2ba2:00:02.0
fe000-fe07f : mlx4_core
the interesting part is the 'f800' region as it is actually the
VM's framebuffer:
$ lspci -v
...
:00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual
VGA (prog-if 00 [VGA controller])
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at f800 (32-bit, non-prefetchable) [size=64M]
...
Recently merged commit a0ab5abced55 ("drm/hyperv : Removing the restruction of
VRAM allocation with PCI bar size") improved the situation as resources,
reserved through vmbus_allocate_mmio() can't be allocated twice:
...
f800-fffb : PCI Bus :00
f800-fbff : :00:08.0
f800-f8001fff : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe
f810-f88f : 5620e0c7-8062-4dce-aeb7-520c7ef76171
...
Always reserve FB region on Gen1 VMs (PATCH2) and make sure we never allocate
anything besides framebuffer from there (PATCH3).
Vitaly Kuznetsov (3):
PCI: Move PCI_VENDOR_ID_MICROSOFT/PCI_DEVICE_ID_HYPERV_VIDEO
definitions to pci_ids.h
Drivers: hv: Always reserve framebuffer region for Gen1 VMs
Drivers: hv: Never allocate anything besides framebuffer from
framebuffer memory region
drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 3 -
drivers/hv/vmbus_drv.c| 56 ++-
.../net/ethernet/microsoft/mana/gdma_main.c | 4 --
drivers/video/fbdev/hyperv_fb.c | 4 --
include/linux/pci_ids.h | 3 +
5 files changed, 44 insertions(+), 26 deletions(-)
--
2.37.1
[PATCH v3 3/3] Drivers: hv: Never allocate anything besides framebuffer from framebuffer memory region
Passed through PCI device sometimes misbehave on Gen1 VMs when Hyper-V
DRM driver is also loaded. Looking at IOMEM assignment, we can see e.g.
$ cat /proc/iomem
...
f800-fffb : PCI Bus :00
f800-fbff : :00:08.0
f800-f8001fff : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe
...
fe000-f : PCI Bus :00
fe000-fe07f : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe
fe000-fe07f : 2ba2:00:02.0
fe000-fe07f : mlx4_core
the interesting part is the 'f800' region as it is actually the
VM's framebuffer:
$ lspci -v
...
:00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual
VGA (prog-if 00 [VGA controller])
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at f800 (32-bit, non-prefetchable) [size=64M]
...
hv_vmbus: registering driver hyperv_drm
hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] Synthvid Version major
3, minor 5
hyperv_drm :00:08.0: vgaarb: deactivate vga console
hyperv_drm :00:08.0: BAR 0: can't reserve [mem 0xf800-0xfbff]
hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] Cannot request
framebuffer, boot fb still active?
Note: "Cannot request framebuffer" is not a fatal error in
hyperv_setup_gen1() as the code assumes there's some other framebuffer
device there but we actually have some other PCI device (mlx4 in this
case) config space there!
The problem appears to be that vmbus_allocate_mmio() can use dedicated
framebuffer region to serve any MMIO request from any device. The
semantics one might assume of a parameter named "fb_overlap_ok"
aren't implemented because !fb_overlap_ok essentially has no effect.
The existing semantics are really "prefer_fb_overlap". This patch
implements the expected and needed semantics, which is to not allocate
from the frame buffer space when !fb_overlap_ok.
Note, Gen2 VMs are usually unaffected by the issue because
framebuffer region is already taken by EFI fb (in case kernel supports
it) but Gen1 VMs may have this region unclaimed by the time Hyper-V PCI
pass-through driver tries allocating MMIO space if Hyper-V DRM/FB drivers
load after it. Devices can be brought up in any sequence so let's
resolve the issue by always ignoring 'fb_mmio' region for non-FB
requests, even if the region is unclaimed.
Reviewed-by: Michael Kelley
Signed-off-by: Vitaly Kuznetsov
---
drivers/hv/vmbus_drv.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 536f68e563c6..3c833ea60db6 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -2331,7 +2331,7 @@ int vmbus_allocate_mmio(struct resource **new, struct
hv_device *device_obj,
bool fb_overlap_ok)
{
struct resource *iter, *shadow;
- resource_size_t range_min, range_max, start;
+ resource_size_t range_min, range_max, start, end;
const char *dev_n = dev_name(_obj->device);
int retval;
@@ -2366,6 +2366,14 @@ int vmbus_allocate_mmio(struct resource **new, struct
hv_device *device_obj,
range_max = iter->end;
start = (range_min + align - 1) & ~(align - 1);
for (; start + size - 1 <= range_max; start += align) {
+ end = start + size - 1;
+
+ /* Skip the whole fb_mmio region if not fb_overlap_ok */
+ if (!fb_overlap_ok && fb_mmio &&
+ (((start >= fb_mmio->start) && (start <=
fb_mmio->end)) ||
+((end >= fb_mmio->start) && (end <=
fb_mmio->end
+ continue;
+
shadow = __request_region(iter, start, size, NULL,
IORESOURCE_BUSY);
if (!shadow)
--
2.37.1
[PATCH v3 1/3] PCI: Move PCI_VENDOR_ID_MICROSOFT/PCI_DEVICE_ID_HYPERV_VIDEO definitions to pci_ids.h
There are already three places in kernel which define PCI_VENDOR_ID_MICROSOFT
and two for PCI_DEVICE_ID_HYPERV_VIDEO and there's a need to use these
from core Vmbus code. Move the defines where they belong.
No functional change.
Reviewed-by: Michael Kelley
Acked-by: Bjorn Helgaas # pci_ids.h
Signed-off-by: Vitaly Kuznetsov
---
drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 3 ---
drivers/net/ethernet/microsoft/mana/gdma_main.c | 4
drivers/video/fbdev/hyperv_fb.c | 4
include/linux/pci_ids.h | 3 +++
4 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
index 6d11e7938c83..40888e36f91a 100644
--- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
+++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
@@ -23,9 +23,6 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-#define PCI_VENDOR_ID_MICROSOFT 0x1414
-#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353
-
DEFINE_DRM_GEM_FOPS(hv_fops);
static struct drm_driver hyperv_driver = {
diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c
b/drivers/net/ethernet/microsoft/mana/gdma_main.c
index 5f9240182351..00d8198072ae 100644
--- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
+++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
@@ -1465,10 +1465,6 @@ static void mana_gd_shutdown(struct pci_dev *pdev)
pci_disable_device(pdev);
}
-#ifndef PCI_VENDOR_ID_MICROSOFT
-#define PCI_VENDOR_ID_MICROSOFT 0x1414
-#endif
-
static const struct pci_device_id mana_id_table[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_MICROSOFT, MANA_PF_DEVICE_ID) },
{ PCI_DEVICE(PCI_VENDOR_ID_MICROSOFT, MANA_VF_DEVICE_ID) },
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 886c564787f1..b58b445bb529 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -74,10 +74,6 @@
#define SYNTHVID_DEPTH_WIN8 32
#define SYNTHVID_FB_SIZE_WIN8 (8 * 1024 * 1024)
-#define PCI_VENDOR_ID_MICROSOFT 0x1414
-#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353
-
-
enum pipe_msg_type {
PIPE_MSG_INVALID,
PIPE_MSG_DATA,
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6feade66efdb..15b49e655ce3 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2079,6 +2079,9 @@
#define PCI_DEVICE_ID_ICE_1712 0x1712
#define PCI_DEVICE_ID_VT1724 0x1724
+#define PCI_VENDOR_ID_MICROSOFT0x1414
+#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353
+
#define PCI_VENDOR_ID_OXSEMI 0x1415
#define PCI_DEVICE_ID_OXSEMI_12PCI840 0x8403
#define PCI_DEVICE_ID_OXSEMI_PCIe840 0xC000
--
2.37.1
[PATCH v3 2/3] Drivers: hv: Always reserve framebuffer region for Gen1 VMs
vmbus_reserve_fb() tries reserving framebuffer region iff
'screen_info.lfb_base' is set. Gen2 VMs seem to have it set by EFI
and/or by the kernel EFI FB driver (or, in some edge cases like kexec,
the address where the buffer was moved, see
https://lore.kernel.org/all/20201014092429.1415040-1-kas...@redhat.com/)
but on Gen1 VM it depends on bootloader behavior. With grub, it depends
on 'gfxpayload=' setting but in some cases it is observed to be zero.
That being said, relying on 'screen_info.lfb_base' to reserve
framebuffer region is risky. For Gen1 VMs, it should always be
possible to get the address from the dedicated PCI device instead.
Check for legacy PCI video device presence and reserve the whole
region for framebuffer on Gen1 VMs.
Reviewed-by: Michael Kelley
Signed-off-by: Vitaly Kuznetsov
---
drivers/hv/vmbus_drv.c | 46 +-
1 file changed, 32 insertions(+), 14 deletions(-)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 23c680d1a0f5..536f68e563c6 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include "hyperv_vmbus.h"
@@ -2262,26 +2263,43 @@ static int vmbus_acpi_remove(struct acpi_device *device)
static void vmbus_reserve_fb(void)
{
- int size;
+ resource_size_t start = 0, size;
+ struct pci_dev *pdev;
+
+ if (efi_enabled(EFI_BOOT)) {
+ /* Gen2 VM: get FB base from EFI framebuffer */
+ start = screen_info.lfb_base;
+ size = max_t(__u32, screen_info.lfb_size, 0x80);
+ } else {
+ /* Gen1 VM: get FB base from PCI */
+ pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT,
+ PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
+ if (!pdev)
+ return;
+
+ if (pdev->resource[0].flags & IORESOURCE_MEM) {
+ start = pci_resource_start(pdev, 0);
+ size = pci_resource_len(pdev, 0);
+ }
+
+ /*
+* Release the PCI device so hyperv_drm or hyperv_fb driver can
+* grab it later.
+*/
+ pci_dev_put(pdev);
+ }
+
+ if (!start)
+ return;
+
/*
* Make a claim for the frame buffer in the resource tree under the
* first node, which will be the one below 4GB. The length seems to
* be underreported, particularly in a Generation 1 VM. So start out
* reserving a larger area and make it smaller until it succeeds.
*/
-
- if (screen_info.lfb_base) {
- if (efi_enabled(EFI_BOOT))
- size = max_t(__u32, screen_info.lfb_size, 0x80);
- else
- size = max_t(__u32, screen_info.lfb_size, 0x400);
-
- for (; !fb_mmio && (size >= 0x10); size >>= 1) {
- fb_mmio = __request_region(hyperv_mmio,
- screen_info.lfb_base, size,
- fb_mmio_name, 0);
- }
- }
+ for (; !fb_mmio && (size >= 0x10); size >>= 1)
+ fb_mmio = __request_region(hyperv_mmio, start, size,
fb_mmio_name, 0);
}
/**
--
2.37.1
RE: [PATCH v2 3/3] Drivers: hv: Never allocate anything besides framebuffer from framebuffer memory region
"Michael Kelley (LINUX)" writes:
> From: Vitaly Kuznetsov Sent: Thursday, August 25, 2022
> 2:00 AM
>>
>> Passed through PCI device sometimes misbehave on Gen1 VMs when Hyper-V
>> DRM driver is also loaded. Looking at IOMEM assignment, we can see e.g.
>>
>> $ cat /proc/iomem
>> ...
>> f800-fffb : PCI Bus :00
>> f800-fbff : :00:08.0
>> f800-f8001fff : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe
>> ...
>> fe000-f : PCI Bus :00
>> fe000-fe07f : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe
>> fe000-fe07f : 2ba2:00:02.0
>> fe000-fe07f : mlx4_core
>>
>> the interesting part is the 'f800' region as it is actually the
>> VM's framebuffer:
>>
>> $ lspci -v
>> ...
>> :00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V
>> virtual VGA
>> (prog-if 00 [VGA controller])
>> Flags: bus master, fast devsel, latency 0, IRQ 11
>> Memory at f800 (32-bit, non-prefetchable) [size=64M]
>> ...
>>
>> hv_vmbus: registering driver hyperv_drm
>> hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] Synthvid Version
>> major 3, minor 5
>> hyperv_drm :00:08.0: vgaarb: deactivate vga console
>> hyperv_drm :00:08.0: BAR 0: can't reserve [mem 0xf800-0xfbff]
>> hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] Cannot request
>> framebuffer, boot fb still active?
>>
>> Note: "Cannot request framebuffer" is not a fatal error in
>> hyperv_setup_gen1() as the code assumes there's some other framebuffer
>> device there but we actually have some other PCI device (mlx4 in this
>> case) config space there!
>
> My apologies for not getting around to commenting on the previous
> version of this patch. The function hyperv_setup_gen1() and the
> "Cannot request framebuffer" message have gone away as of
> commit a0ab5abced55.
>
True, will fix!
>>
>> The problem appears to be that vmbus_allocate_mmio() can allocate from
>> the reserved framebuffer region (fb_overlap_ok), however, if the
>> request to allocate MMIO comes from some other device before
>> framebuffer region is taken, it can happily use framebuffer region for
>> it.
>
> Interesting. I had never looked at the details of vmbus_allocate_mmio().
> The semantics one might assume of a parameter named "fb_overlap_ok"
> aren't implemented because !fb_overlap_ok essentially has no effect. The
> existing semantics are really "prefer_fb_overlap". This patch implements
> the expected and needed semantics, which is to not allocate from the frame
> buffer space when !fb_overlap_ok.
>
> If that's an accurate high level summary, maybe this commit message
> could describe it that way? The other details you provide about what can
> go wrong should still be included as well.
That's acually a very good summary! Let me update the commit message,
I'll be sending out v3 shortly.
>
>> Note, Gen2 VMs are usually unaffected by the issue because
>> framebuffer region is already taken by EFI fb (in case kernel supports
>> it) but Gen1 VMs may have this region unclaimed by the time Hyper-V PCI
>> pass-through driver tries allocating MMIO space if Hyper-V DRM/FB drivers
>> load after it. Devices can be brought up in any sequence so let's
>> resolve the issue by always ignoring 'fb_mmio' region for non-FB
>> requests, even if the region is unclaimed.
>>
>> Signed-off-by: Vitaly Kuznetsov
>> ---
>> drivers/hv/vmbus_drv.c | 10 +-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
>> index 536f68e563c6..3c833ea60db6 100644
>> --- a/drivers/hv/vmbus_drv.c
>> +++ b/drivers/hv/vmbus_drv.c
>> @@ -2331,7 +2331,7 @@ int vmbus_allocate_mmio(struct resource **new, struct
>> hv_device *device_obj,
>> bool fb_overlap_ok)
>> {
>> struct resource *iter, *shadow;
>> -resource_size_t range_min, range_max, start;
>> +resource_size_t range_min, range_max, start, end;
>> const char *dev_n = dev_name(_obj->device);
>> int retval;
>>
>> @@ -2366,6 +2366,14 @@ int vmbus_allocate_mmio(struct resource **new, struct
>> hv_device *device_obj,
>> range_max = iter->end;
>> start = (range_min + align - 1) & ~(align - 1);
>> for (; start + size - 1 <= range_max; start += align) {
>> +end = start + size - 1;
>> +
>> +/* Skip the whole fb_mmio region if not fb_overlap_ok */
>> +if (!fb_overlap_ok && fb_mmio &&
>> +(((start >= fb_mmio->start) && (start <=
>> fb_mmio->end)) ||
>> + ((end >= fb_mmio->start) && (end <=
>> fb_mmio->end
>> +continue;
>> +
>> shadow = __request_region(iter, start, size, NULL,
>>IORESOURCE_BUSY);
>> if (!shadow)
>> --
>> 2.37.1
>
> Other than my musings on the commit message,
>
>
RE: [PATCH v2 2/3] Drivers: hv: Always reserve framebuffer region for Gen1 VMs
"Michael Kelley (LINUX)" writes:
> From: Vitaly Kuznetsov Sent: Thursday, August 25, 2022
> 2:00 AM
>>
>> vmbus_reserve_fb() tries reserving framebuffer region iff
>> 'screen_info.lfb_base' is set. Gen2 VMs seem to have it set by EFI fb
>
> Just so I'm clear, by "EFI fb" you mean the EFI layer code that sets
> up the frame buffer before the Linux kernel ever boots, right?
> You are not referring to the Linux kernel EFI framebuffer
> driver, which may or may not be configured in the kernel.
My very shallow understanding is that initially, screen_info comes from
boot_params and this depends on how Linux was booted. Kernel EFI
framebuffer (when enabled), however, gets it first and can modify it
(see efifb_setup()) before we get to analyze it in Vmbus.
>
>> (or, in some edge cases like kexec, the address where the buffer was
>> moved, see
>> https://lore.kernel.org/all/20201014092429.1415040-1-kas...@redhat.com/
>> but on Gen1 VM it depends on bootloader behavior. With grub, it depends
>> on 'gfxpayload=' setting but in some cases it is observed to be zero.
>> Relying on 'screen_info.lfb_base' to reserve framebuffer region is
>> risky. Instead, it is possible to get the address from the dedicated
>> PCI device which is always present.
>>
>> Check for legacy PCI video device presence and reserve the whole
>> region for framebuffer on Gen1 VMs.
>>
>> Signed-off-by: Vitaly Kuznetsov
>> ---
>> drivers/hv/vmbus_drv.c | 46 +-
>> 1 file changed, 32 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
>> index 23c680d1a0f5..536f68e563c6 100644
>> --- a/drivers/hv/vmbus_drv.c
>> +++ b/drivers/hv/vmbus_drv.c
>> @@ -35,6 +35,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include "hyperv_vmbus.h"
>>
>> @@ -2262,26 +2263,43 @@ static int vmbus_acpi_remove(struct acpi_device
>> *device)
>>
>> static void vmbus_reserve_fb(void)
>> {
>> -int size;
>> +resource_size_t start = 0, size;
>> +struct pci_dev *pdev;
>> +
>> +if (efi_enabled(EFI_BOOT)) {
>> +/* Gen2 VM: get FB base from EFI framebuffer */
>> +start = screen_info.lfb_base;
>> +size = max_t(__u32, screen_info.lfb_size, 0x80);
>> +} else {
>> +/* Gen1 VM: get FB base from PCI */
>> +pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT,
>> + PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
>> +if (!pdev)
>> +return;
>> +
>> +if (pdev->resource[0].flags & IORESOURCE_MEM) {
>> +start = pci_resource_start(pdev, 0);
>> +size = pci_resource_len(pdev, 0);
>> +}
>> +
>> +/*
>> + * Release the PCI device so hyperv_drm or hyperv_fb driver can
>> + * grab it later.
>> + */
>> +pci_dev_put(pdev);
>> +}
>> +
>> +if (!start)
>> +return;
>> +
>> /*
>> * Make a claim for the frame buffer in the resource tree under the
>> * first node, which will be the one below 4GB. The length seems to
>> * be underreported, particularly in a Generation 1 VM. So start out
>> * reserving a larger area and make it smaller until it succeeds.
>> */
>> -
>> -if (screen_info.lfb_base) {
>> -if (efi_enabled(EFI_BOOT))
>> -size = max_t(__u32, screen_info.lfb_size, 0x80);
>> -else
>> -size = max_t(__u32, screen_info.lfb_size, 0x400);
>> -
>> -for (; !fb_mmio && (size >= 0x10); size >>= 1) {
>> -fb_mmio = __request_region(hyperv_mmio,
>> - screen_info.lfb_base, size,
>> - fb_mmio_name, 0);
>> -}
>> -}
>> +for (; !fb_mmio && (size >= 0x10); size >>= 1)
>> +fb_mmio = __request_region(hyperv_mmio, start, size,
>> fb_mmio_name, 0);
>> }
>>
>> /**
>> --
>> 2.37.1
>
> Reviewed-by: Michael Kelley
>
Thanks!
--
Vitaly
RE: [PATCH 13/15] vfio/ccw: Use the new device life cycle helpers
This missed a Suggested-by from Jason. Will add in next version.
> From: Tian, Kevin
> Sent: Sunday, August 28, 2022 1:11 AM
>
> ccw is the only exception which cannot use vfio_alloc_device() because
> its private device structure is designed to serve both mdev and parent.
> Life cycle of the parent is managed by css_driver so vfio_ccw_private
> must be allocated/freed in css_driver probe/remove path instead of
> conforming to vfio core life cycle for mdev.
>
> Given that use a wait/completion scheme so the mdev remove path waits
> after vfio_put_device() until receiving a completion notification from
> @release. The completion indicates that all active references on
> vfio_device have been released.
>
> After that point although free of vfio_ccw_private is delayed to
> css_driver it's at least guaranteed to have no parallel reference on
> released vfio device part from other code paths.
>
> memset() in @probe is removed. vfio_device is either alreary cleared
> when probed for the first time or cleared in @release from last probe.
>
> The right fix is to introduce separate structures for mdev and parent,
> but this won't happen in short term per prior discussions.
>
> Remove vfio_init/uninit_group_dev() as no user now.
>
> Signed-off-by: Kevin Tian
> ---
> drivers/s390/cio/vfio_ccw_ops.c | 52 +
> drivers/s390/cio/vfio_ccw_private.h | 3 ++
> drivers/vfio/vfio_main.c| 27 +++
> include/linux/vfio.h| 3 --
> 4 files changed, 53 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/s390/cio/vfio_ccw_ops.c
> b/drivers/s390/cio/vfio_ccw_ops.c
> index 4a806a2273b5..9f8486c0d3d3 100644
> --- a/drivers/s390/cio/vfio_ccw_ops.c
> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> @@ -87,6 +87,15 @@ static struct attribute_group *mdev_type_groups[] = {
> NULL,
> };
>
> +static int vfio_ccw_mdev_init_dev(struct vfio_device *vdev)
> +{
> + struct vfio_ccw_private *private =
> + container_of(vdev, struct vfio_ccw_private, vdev);
> +
> + init_completion(>release_comp);
> + return 0;
> +}
> +
> static int vfio_ccw_mdev_probe(struct mdev_device *mdev)
> {
> struct vfio_ccw_private *private = dev_get_drvdata(mdev-
> >dev.parent);
> @@ -98,9 +107,9 @@ static int vfio_ccw_mdev_probe(struct mdev_device
> *mdev)
> if (atomic_dec_if_positive(>avail) < 0)
> return -EPERM;
>
> - memset(>vdev, 0, sizeof(private->vdev));
> - vfio_init_group_dev(>vdev, >dev,
> - _ccw_dev_ops);
> + ret = vfio_init_device(>vdev, >dev,
> _ccw_dev_ops);
> + if (ret)
> + return ret;
>
> VFIO_CCW_MSG_EVENT(2, "sch %x.%x.%04x: create\n",
> private->sch->schid.cssid,
> @@ -109,16 +118,33 @@ static int vfio_ccw_mdev_probe(struct
> mdev_device *mdev)
>
> ret = vfio_register_emulated_iommu_dev(>vdev);
> if (ret)
> - goto err_atomic;
> + goto err_put_vdev;
> dev_set_drvdata(>dev, private);
> return 0;
>
> -err_atomic:
> - vfio_uninit_group_dev(>vdev);
> +err_put_vdev:
> + vfio_put_device(>vdev);
> atomic_inc(>avail);
> return ret;
> }
>
> +static void vfio_ccw_mdev_release_dev(struct vfio_device *vdev)
> +{
> + struct vfio_ccw_private *private =
> + container_of(vdev, struct vfio_ccw_private, vdev);
> +
> + /*
> + * We cannot free vfio_ccw_private here because it includes
> + * parent info which must be free'ed by css driver.
> + *
> + * Use a workaround by memset'ing the core device part and
> + * then notifying the remove path that all active references
> + * to this device have been released.
> + */
> + memset(vdev, 0, sizeof(*vdev));
> + complete(>release_comp);
> +}
> +
> static void vfio_ccw_mdev_remove(struct mdev_device *mdev)
> {
> struct vfio_ccw_private *private = dev_get_drvdata(mdev-
> >dev.parent);
> @@ -130,7 +156,17 @@ static void vfio_ccw_mdev_remove(struct
> mdev_device *mdev)
>
> vfio_unregister_group_dev(>vdev);
>
> - vfio_uninit_group_dev(>vdev);
> + vfio_put_device(>vdev);
> + /*
> + * Wait for all active references on mdev are released so it
> + * is safe to defer kfree() to a later point.
> + *
> + * TODO: the clean fix is to split parent/mdev info from ccw
> + * private structure so each can be managed in its own life
> + * cycle.
> + */
> + wait_for_completion(>release_comp);
> +
> atomic_inc(>avail);
> }
>
> @@ -592,6 +628,8 @@ static void vfio_ccw_mdev_request(struct vfio_device
> *vdev, unsigned int count)
> }
>
> static const struct vfio_device_ops vfio_ccw_dev_ops = {
> + .init = vfio_ccw_mdev_init_dev,
> + .release = vfio_ccw_mdev_release_dev,
> .open_device = vfio_ccw_mdev_open_device,
> .close_device = vfio_ccw_mdev_close_device,
> .read = vfio_ccw_mdev_read,
> diff --git
[PATCH 15/15] vfio: Add struct device to vfio_device
From: Yi Liu
and replace kref. With it a 'vfio-dev/vfioX' node is created under the
sysfs path of the parent, indicating the device is bound to a vfio
driver, e.g.:
/sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0
It is also a preparatory step toward adding cdev for supporting future
device-oriented uAPI.
Suggested-by: Jason Gunthorpe
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
drivers/vfio/vfio_main.c | 70 +---
include/linux/vfio.h | 6 ++--
2 files changed, 61 insertions(+), 15 deletions(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 0c5d120aeced..9ad0cbb83f1c 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -46,6 +46,8 @@ static struct vfio {
struct mutexgroup_lock; /* locks group_list */
struct ida group_ida;
dev_t group_devt;
+ struct class*device_class;
+ struct ida device_ida;
} vfio;
struct vfio_iommu_driver {
@@ -524,11 +526,19 @@ EXPORT_SYMBOL_GPL(_vfio_alloc_device);
*
* Only vfio-ccw driver should call this interface.
*/
+static void vfio_device_release(struct device *dev);
int vfio_init_device(struct vfio_device *device, struct device *dev,
const struct vfio_device_ops *ops)
{
int ret;
+ ret = ida_alloc_max(_ida, MINORMASK, GFP_KERNEL);
+ if (ret < 0) {
+ dev_dbg(dev, "Error to alloc index\n");
+ return ret;
+ }
+
+ device->index = ret;
init_completion(>comp);
device->dev = dev;
device->ops = ops;
@@ -536,11 +546,18 @@ int vfio_init_device(struct vfio_device *device, struct
device *dev,
if (ops->init) {
ret = ops->init(device);
if (ret)
- return ret;
+ goto out_ida;
}
- kref_init(>kref);
+ device_initialize(>device);
+ device->device.release = vfio_device_release;
+ device->device.class = vfio.device_class;
+ device->device.parent = device->dev;
return 0;
+
+out_ida:
+ ida_free(_ida, device->index);
+ return ret;
}
EXPORT_SYMBOL_GPL(vfio_init_device);
@@ -556,12 +573,13 @@ void vfio_free_device(struct vfio_device *device)
EXPORT_SYMBOL_GPL(vfio_free_device);
/* Release helper called by vfio_put_device() */
-void vfio_device_release(struct kref *kref)
+static void vfio_device_release(struct device *dev)
{
struct vfio_device *device =
- container_of(kref, struct vfio_device, kref);
+ container_of(dev, struct vfio_device, device);
vfio_release_device_set(device);
+ ida_free(_ida, device->index);
/*
* kvfree() cannot be done here due to a life cycle mess in
@@ -571,7 +589,6 @@ void vfio_device_release(struct kref *kref)
*/
device->ops->release(device);
}
-EXPORT_SYMBOL_GPL(vfio_device_release);
static struct vfio_group *vfio_noiommu_group_alloc(struct device *dev,
enum vfio_group_type type)
@@ -654,6 +671,7 @@ static int __vfio_register_dev(struct vfio_device *device,
struct vfio_group *group)
{
struct vfio_device *existing_device;
+ int ret;
if (IS_ERR(group))
return PTR_ERR(group);
@@ -670,16 +688,21 @@ static int __vfio_register_dev(struct vfio_device *device,
dev_WARN(device->dev, "Device already exists on group %d\n",
iommu_group_id(group->iommu_group));
vfio_device_put_registration(existing_device);
- if (group->type == VFIO_NO_IOMMU ||
- group->type == VFIO_EMULATED_IOMMU)
- iommu_group_remove_device(device->dev);
- vfio_group_put(group);
- return -EBUSY;
+ ret = -EBUSY;
+ goto err_out;
}
/* Our reference on group is moved to the device */
device->group = group;
+ ret = dev_set_name(>device, "vfio%d", device->index);
+ if (ret)
+ goto err_out;
+
+ ret = device_add(>device);
+ if (ret)
+ goto err_out;
+
/* Refcounting can't start until the driver calls register */
refcount_set(>refcount, 1);
@@ -689,6 +712,12 @@ static int __vfio_register_dev(struct vfio_device *device,
mutex_unlock(>device_lock);
return 0;
+err_out:
+ if (group->type == VFIO_NO_IOMMU ||
+ group->type == VFIO_EMULATED_IOMMU)
+ iommu_group_remove_device(device->dev);
+ vfio_group_put(group);
+ return ret;
}
int vfio_register_group_dev(struct vfio_device *device)
@@ -776,6 +805,9 @@ void vfio_unregister_group_dev(struct vfio_device *device)
group->dev_counter--;
[PATCH 14/15] vfio: Rename vfio_device_put() and vfio_device_try_get()
With the addition of vfio_put_device() now the names become confusing.
vfio_put_device() is clear from object life cycle p.o.v given kref.
vfio_device_put()/vfio_device_try_get() are helpers for tracking
users on a registered device.
Now rename them:
- vfio_device_put() -> vfio_device_put_registration()
- vfio_device_try_get() -> vfio_device_try_get_registration()
Signed-off-by: Kevin Tian
---
drivers/vfio/vfio_main.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 15a612153c13..0c5d120aeced 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -452,13 +452,13 @@ static void vfio_group_get(struct vfio_group *group)
* Device objects - create, release, get, put, search
*/
/* Device reference always implies a group reference */
-static void vfio_device_put(struct vfio_device *device)
+static void vfio_device_put_registration(struct vfio_device *device)
{
if (refcount_dec_and_test(>refcount))
complete(>comp);
}
-static bool vfio_device_try_get(struct vfio_device *device)
+static bool vfio_device_try_get_registration(struct vfio_device *device)
{
return refcount_inc_not_zero(>refcount);
}
@@ -470,7 +470,8 @@ static struct vfio_device *vfio_group_get_device(struct
vfio_group *group,
mutex_lock(>device_lock);
list_for_each_entry(device, >device_list, group_next) {
- if (device->dev == dev && vfio_device_try_get(device)) {
+ if (device->dev == dev &&
+ vfio_device_try_get_registration(device)) {
mutex_unlock(>device_lock);
return device;
}
@@ -668,7 +669,7 @@ static int __vfio_register_dev(struct vfio_device *device,
if (existing_device) {
dev_WARN(device->dev, "Device already exists on group %d\n",
iommu_group_id(group->iommu_group));
- vfio_device_put(existing_device);
+ vfio_device_put_registration(existing_device);
if (group->type == VFIO_NO_IOMMU ||
group->type == VFIO_EMULATED_IOMMU)
iommu_group_remove_device(device->dev);
@@ -727,7 +728,7 @@ static struct vfio_device *vfio_device_get_from_name(struct
vfio_group *group,
ret = !strcmp(dev_name(it->dev), buf);
}
- if (ret && vfio_device_try_get(it)) {
+ if (ret && vfio_device_try_get_registration(it)) {
device = it;
break;
}
@@ -747,7 +748,7 @@ void vfio_unregister_group_dev(struct vfio_device *device)
bool interrupted = false;
long rc;
- vfio_device_put(device);
+ vfio_device_put_registration(device);
rc = try_wait_for_completion(>comp);
while (rc <= 0) {
if (device->ops->request)
@@ -1283,7 +1284,7 @@ static int vfio_group_get_device_fd(struct vfio_group
*group, char *buf)
err_put_fdno:
put_unused_fd(fdno);
err_put_device:
- vfio_device_put(device);
+ vfio_device_put_registration(device);
return ret;
}
@@ -1458,7 +1459,7 @@ static int vfio_device_fops_release(struct inode *inode,
struct file *filep)
vfio_device_unassign_container(device);
- vfio_device_put(device);
+ vfio_device_put_registration(device);
return 0;
}
--
2.21.3
[PATCH 13/15] vfio/ccw: Use the new device life cycle helpers
ccw is the only exception which cannot use vfio_alloc_device() because
its private device structure is designed to serve both mdev and parent.
Life cycle of the parent is managed by css_driver so vfio_ccw_private
must be allocated/freed in css_driver probe/remove path instead of
conforming to vfio core life cycle for mdev.
Given that use a wait/completion scheme so the mdev remove path waits
after vfio_put_device() until receiving a completion notification from
@release. The completion indicates that all active references on
vfio_device have been released.
After that point although free of vfio_ccw_private is delayed to
css_driver it's at least guaranteed to have no parallel reference on
released vfio device part from other code paths.
memset() in @probe is removed. vfio_device is either alreary cleared
when probed for the first time or cleared in @release from last probe.
The right fix is to introduce separate structures for mdev and parent,
but this won't happen in short term per prior discussions.
Remove vfio_init/uninit_group_dev() as no user now.
Signed-off-by: Kevin Tian
---
drivers/s390/cio/vfio_ccw_ops.c | 52 +
drivers/s390/cio/vfio_ccw_private.h | 3 ++
drivers/vfio/vfio_main.c| 27 +++
include/linux/vfio.h| 3 --
4 files changed, 53 insertions(+), 32 deletions(-)
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 4a806a2273b5..9f8486c0d3d3 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -87,6 +87,15 @@ static struct attribute_group *mdev_type_groups[] = {
NULL,
};
+static int vfio_ccw_mdev_init_dev(struct vfio_device *vdev)
+{
+ struct vfio_ccw_private *private =
+ container_of(vdev, struct vfio_ccw_private, vdev);
+
+ init_completion(>release_comp);
+ return 0;
+}
+
static int vfio_ccw_mdev_probe(struct mdev_device *mdev)
{
struct vfio_ccw_private *private = dev_get_drvdata(mdev->dev.parent);
@@ -98,9 +107,9 @@ static int vfio_ccw_mdev_probe(struct mdev_device *mdev)
if (atomic_dec_if_positive(>avail) < 0)
return -EPERM;
- memset(>vdev, 0, sizeof(private->vdev));
- vfio_init_group_dev(>vdev, >dev,
- _ccw_dev_ops);
+ ret = vfio_init_device(>vdev, >dev, _ccw_dev_ops);
+ if (ret)
+ return ret;
VFIO_CCW_MSG_EVENT(2, "sch %x.%x.%04x: create\n",
private->sch->schid.cssid,
@@ -109,16 +118,33 @@ static int vfio_ccw_mdev_probe(struct mdev_device *mdev)
ret = vfio_register_emulated_iommu_dev(>vdev);
if (ret)
- goto err_atomic;
+ goto err_put_vdev;
dev_set_drvdata(>dev, private);
return 0;
-err_atomic:
- vfio_uninit_group_dev(>vdev);
+err_put_vdev:
+ vfio_put_device(>vdev);
atomic_inc(>avail);
return ret;
}
+static void vfio_ccw_mdev_release_dev(struct vfio_device *vdev)
+{
+ struct vfio_ccw_private *private =
+ container_of(vdev, struct vfio_ccw_private, vdev);
+
+ /*
+* We cannot free vfio_ccw_private here because it includes
+* parent info which must be free'ed by css driver.
+*
+* Use a workaround by memset'ing the core device part and
+* then notifying the remove path that all active references
+* to this device have been released.
+*/
+ memset(vdev, 0, sizeof(*vdev));
+ complete(>release_comp);
+}
+
static void vfio_ccw_mdev_remove(struct mdev_device *mdev)
{
struct vfio_ccw_private *private = dev_get_drvdata(mdev->dev.parent);
@@ -130,7 +156,17 @@ static void vfio_ccw_mdev_remove(struct mdev_device *mdev)
vfio_unregister_group_dev(>vdev);
- vfio_uninit_group_dev(>vdev);
+ vfio_put_device(>vdev);
+ /*
+* Wait for all active references on mdev are released so it
+* is safe to defer kfree() to a later point.
+*
+* TODO: the clean fix is to split parent/mdev info from ccw
+* private structure so each can be managed in its own life
+* cycle.
+*/
+ wait_for_completion(>release_comp);
+
atomic_inc(>avail);
}
@@ -592,6 +628,8 @@ static void vfio_ccw_mdev_request(struct vfio_device *vdev,
unsigned int count)
}
static const struct vfio_device_ops vfio_ccw_dev_ops = {
+ .init = vfio_ccw_mdev_init_dev,
+ .release = vfio_ccw_mdev_release_dev,
.open_device = vfio_ccw_mdev_open_device,
.close_device = vfio_ccw_mdev_close_device,
.read = vfio_ccw_mdev_read,
diff --git a/drivers/s390/cio/vfio_ccw_private.h
b/drivers/s390/cio/vfio_ccw_private.h
index cd24b7fada91..63d9202b29c7 100644
--- a/drivers/s390/cio/vfio_ccw_private.h
+++ b/drivers/s390/cio/vfio_ccw_private.h
@@ -88,6 +88,7 @@ struct vfio_ccw_crw {
* @req_trigger: eventfd ctx for signaling
[PATCH 12/15] vfio/amba: Use the new device life cycle helpers
Implement amba's own vfio_device_ops.
Remove vfio_platform_probe/remove_common() given no user now.
Signed-off-by: Kevin Tian
---
drivers/vfio/platform/vfio_amba.c | 72 ++-
drivers/vfio/platform/vfio_platform_common.c | 50 -
drivers/vfio/platform/vfio_platform_private.h | 3 -
3 files changed, 55 insertions(+), 70 deletions(-)
diff --git a/drivers/vfio/platform/vfio_amba.c
b/drivers/vfio/platform/vfio_amba.c
index 1aaa4f721bd2..ac31eaf8bca2 100644
--- a/drivers/vfio/platform/vfio_amba.c
+++ b/drivers/vfio/platform/vfio_amba.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include "vfio_platform_private.h"
@@ -40,20 +41,16 @@ static int get_amba_irq(struct vfio_platform_device *vdev,
int i)
return ret ? ret : -ENXIO;
}
-static int vfio_amba_probe(struct amba_device *adev, const struct amba_id *id)
+static int vfio_amba_init_dev(struct vfio_device *core_vdev)
{
- struct vfio_platform_device *vdev;
+ struct vfio_platform_device *vdev =
+ container_of(core_vdev, struct vfio_platform_device, vdev);
+ struct amba_device *adev = to_amba_device(core_vdev->dev);
int ret;
- vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
- if (!vdev)
- return -ENOMEM;
-
vdev->name = kasprintf(GFP_KERNEL, "vfio-amba-%08x", adev->periphid);
- if (!vdev->name) {
- kfree(vdev);
+ if (!vdev->name)
return -ENOMEM;
- }
vdev->opaque = (void *) adev;
vdev->flags = VFIO_DEVICE_FLAGS_AMBA;
@@ -61,26 +58,67 @@ static int vfio_amba_probe(struct amba_device *adev, const
struct amba_id *id)
vdev->get_irq = get_amba_irq;
vdev->reset_required = false;
- ret = vfio_platform_probe_common(vdev, >dev);
- if (ret) {
+ ret = vfio_platform_init_common(vdev);
+ if (ret)
kfree(vdev->name);
- kfree(vdev);
- return ret;
- }
+ return ret;
+}
+
+static const struct vfio_device_ops vfio_amba_ops;
+static int vfio_amba_probe(struct amba_device *adev, const struct amba_id *id)
+{
+ struct vfio_platform_device *vdev;
+ int ret;
+
+ vdev = vfio_alloc_device(vfio_platform_device, vdev, >dev,
+_amba_ops);
+ if (IS_ERR(vdev))
+ return PTR_ERR(vdev);
+ ret = vfio_register_group_dev(>vdev);
+ if (ret)
+ goto out_put_vdev;
+
+ pm_runtime_enable(>dev);
dev_set_drvdata(>dev, vdev);
return 0;
+
+out_put_vdev:
+ vfio_put_device(>vdev);
+ return ret;
+}
+
+static void vfio_amba_release_dev(struct vfio_device *core_vdev)
+{
+ struct vfio_platform_device *vdev =
+ container_of(core_vdev, struct vfio_platform_device, vdev);
+
+ vfio_platform_release_common(vdev);
+ kfree(vdev->name);
+ vfio_free_device(core_vdev);
}
static void vfio_amba_remove(struct amba_device *adev)
{
struct vfio_platform_device *vdev = dev_get_drvdata(>dev);
- vfio_platform_remove_common(vdev);
- kfree(vdev->name);
- kfree(vdev);
+ vfio_unregister_group_dev(>vdev);
+ pm_runtime_disable(vdev->device);
+ vfio_put_device(>vdev);
}
+static const struct vfio_device_ops vfio_platform_ops = {
+ .name = "vfio-platform",
+ .init = vfio_amba_init_dev,
+ .release= vfio_amba_release_dev,
+ .open_device= vfio_platform_open_device,
+ .close_device = vfio_platform_close_device,
+ .ioctl = vfio_platform_ioctl,
+ .read = vfio_platform_read,
+ .write = vfio_platform_write,
+ .mmap = vfio_platform_mmap,
+};
+
static const struct amba_id pl330_ids[] = {
{ 0, 0 },
};
diff --git a/drivers/vfio/platform/vfio_platform_common.c
b/drivers/vfio/platform/vfio_platform_common.c
index 4c01bf0adebb..7cc9ff87c3a3 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -674,56 +674,6 @@ void vfio_platform_release_common(struct
vfio_platform_device *vdev)
}
EXPORT_SYMBOL_GPL(vfio_platform_release_common);
-int vfio_platform_probe_common(struct vfio_platform_device *vdev,
- struct device *dev)
-{
- int ret;
-
- vfio_init_group_dev(>vdev, dev, _platform_ops);
-
- ret = vfio_platform_acpi_probe(vdev, dev);
- if (ret)
- ret = vfio_platform_of_probe(vdev, dev);
-
- if (ret)
- goto out_uninit;
-
- vdev->device = dev;
-
- ret = vfio_platform_get_reset(vdev);
- if (ret && vdev->reset_required) {
- dev_err(dev, "No reset function found for device %s\n",
- vdev->name);
- goto out_uninit;
- }
-
- ret = vfio_register_group_dev(>vdev);
- if (ret)
-
[PATCH 11/15] vfio/platform: Use the new device life cycle helpers
Move vfio_device_ops from platform core to platform drivers so device
specific init/cleanup can be added.
Introduce two new helpers vfio_platform_init/release_common() for the
use in driver @init/@release.
vfio_platform_probe/remove_common() will be deprecated.
Signed-off-by: Kevin Tian
---
drivers/vfio/platform/vfio_platform.c | 66 +++
drivers/vfio/platform/vfio_platform_common.c | 53 ---
drivers/vfio/platform/vfio_platform_private.h | 15 +
3 files changed, 111 insertions(+), 23 deletions(-)
diff --git a/drivers/vfio/platform/vfio_platform.c
b/drivers/vfio/platform/vfio_platform.c
index 04f40c5acfd6..82cedcebfd90 100644
--- a/drivers/vfio/platform/vfio_platform.c
+++ b/drivers/vfio/platform/vfio_platform.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include "vfio_platform_private.h"
@@ -36,14 +37,11 @@ static int get_platform_irq(struct vfio_platform_device
*vdev, int i)
return platform_get_irq_optional(pdev, i);
}
-static int vfio_platform_probe(struct platform_device *pdev)
+static int vfio_platform_init_dev(struct vfio_device *core_vdev)
{
- struct vfio_platform_device *vdev;
- int ret;
-
- vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
- if (!vdev)
- return -ENOMEM;
+ struct vfio_platform_device *vdev =
+ container_of(core_vdev, struct vfio_platform_device, vdev);
+ struct platform_device *pdev = to_platform_device(core_vdev->dev);
vdev->opaque = (void *) pdev;
vdev->name = pdev->name;
@@ -52,24 +50,64 @@ static int vfio_platform_probe(struct platform_device *pdev)
vdev->get_irq = get_platform_irq;
vdev->reset_required = reset_required;
- ret = vfio_platform_probe_common(vdev, >dev);
- if (ret) {
- kfree(vdev);
- return ret;
- }
+ return vfio_platform_init_common(vdev);
+}
+
+static const struct vfio_device_ops vfio_platform_ops;
+static int vfio_platform_probe(struct platform_device *pdev)
+{
+ struct vfio_platform_device *vdev;
+ int ret;
+
+ vdev = vfio_alloc_device(vfio_platform_device, vdev, >dev,
+_platform_ops);
+ if (IS_ERR(vdev))
+ return PTR_ERR(vdev);
+
+ ret = vfio_register_group_dev(>vdev);
+ if (ret)
+ goto out_put_vdev;
+
+ pm_runtime_enable(>dev);
dev_set_drvdata(>dev, vdev);
return 0;
+
+out_put_vdev:
+ vfio_put_device(>vdev);
+ return ret;
+}
+
+static void vfio_platform_release_dev(struct vfio_device *core_vdev)
+{
+ struct vfio_platform_device *vdev =
+ container_of(core_vdev, struct vfio_platform_device, vdev);
+
+ vfio_platform_release_common(vdev);
+ vfio_free_device(core_vdev);
}
static int vfio_platform_remove(struct platform_device *pdev)
{
struct vfio_platform_device *vdev = dev_get_drvdata(>dev);
- vfio_platform_remove_common(vdev);
- kfree(vdev);
+ vfio_unregister_group_dev(>vdev);
+ pm_runtime_disable(vdev->device);
+ vfio_put_device(>vdev);
return 0;
}
+static const struct vfio_device_ops vfio_platform_ops = {
+ .name = "vfio-platform",
+ .init = vfio_platform_init_dev,
+ .release= vfio_platform_release_dev,
+ .open_device= vfio_platform_open_device,
+ .close_device = vfio_platform_close_device,
+ .ioctl = vfio_platform_ioctl,
+ .read = vfio_platform_read,
+ .write = vfio_platform_write,
+ .mmap = vfio_platform_mmap,
+};
+
static struct platform_driver vfio_platform_driver = {
.probe = vfio_platform_probe,
.remove = vfio_platform_remove,
diff --git a/drivers/vfio/platform/vfio_platform_common.c
b/drivers/vfio/platform/vfio_platform_common.c
index 256f55b84e70..4c01bf0adebb 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -218,7 +218,7 @@ static int vfio_platform_call_reset(struct
vfio_platform_device *vdev,
return -EINVAL;
}
-static void vfio_platform_close_device(struct vfio_device *core_vdev)
+void vfio_platform_close_device(struct vfio_device *core_vdev)
{
struct vfio_platform_device *vdev =
container_of(core_vdev, struct vfio_platform_device, vdev);
@@ -236,8 +236,9 @@ static void vfio_platform_close_device(struct vfio_device
*core_vdev)
vfio_platform_regions_cleanup(vdev);
vfio_platform_irq_cleanup(vdev);
}
+EXPORT_SYMBOL_GPL(vfio_platform_close_device);
-static int vfio_platform_open_device(struct vfio_device *core_vdev)
+int vfio_platform_open_device(struct vfio_device *core_vdev)
{
struct vfio_platform_device *vdev =
container_of(core_vdev, struct vfio_platform_device, vdev);
@@ -273,9 +274,10 @@ static int
[PATCH 09/15] vfio/ap: Use the new device life cycle helpers
From: Yi Liu
and manage available_instances inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
drivers/s390/crypto/vfio_ap_ops.c | 50 ++-
1 file changed, 29 insertions(+), 21 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 6c8c41fac4e1..803aadfd0876 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -684,42 +684,44 @@ static bool vfio_ap_mdev_filter_matrix(unsigned long
*apm, unsigned long *aqm,
AP_DOMAINS);
}
-static int vfio_ap_mdev_probe(struct mdev_device *mdev)
+static int vfio_ap_mdev_init_dev(struct vfio_device *vdev)
{
- struct ap_matrix_mdev *matrix_mdev;
- int ret;
+ struct ap_matrix_mdev *matrix_mdev =
+ container_of(vdev, struct ap_matrix_mdev, vdev);
if ((atomic_dec_if_positive(_dev->available_instances) < 0))
return -EPERM;
- matrix_mdev = kzalloc(sizeof(*matrix_mdev), GFP_KERNEL);
- if (!matrix_mdev) {
- ret = -ENOMEM;
- goto err_dec_available;
- }
- vfio_init_group_dev(_mdev->vdev, >dev,
- _ap_matrix_dev_ops);
-
- matrix_mdev->mdev = mdev;
+ matrix_mdev->mdev = to_mdev_device(vdev->dev);
vfio_ap_matrix_init(_dev->info, _mdev->matrix);
matrix_mdev->pqap_hook = handle_pqap;
vfio_ap_matrix_init(_dev->info, _mdev->shadow_apcb);
hash_init(matrix_mdev->qtable.queues);
+ return 0;
+}
+
+static int vfio_ap_mdev_probe(struct mdev_device *mdev)
+{
+ struct ap_matrix_mdev *matrix_mdev;
+ int ret;
+
+ matrix_mdev = vfio_alloc_device(ap_matrix_mdev, vdev, >dev,
+ _ap_matrix_dev_ops);
+ if (IS_ERR(matrix_mdev))
+ return PTR_ERR(matrix_mdev);
+
ret = vfio_register_emulated_iommu_dev(_mdev->vdev);
if (ret)
- goto err_list;
+ goto err_put_vdev;
dev_set_drvdata(>dev, matrix_mdev);
mutex_lock(_dev->mdevs_lock);
list_add(_mdev->node, _dev->mdev_list);
mutex_unlock(_dev->mdevs_lock);
return 0;
-err_list:
- vfio_uninit_group_dev(_mdev->vdev);
- kfree(matrix_mdev);
-err_dec_available:
- atomic_inc(_dev->available_instances);
+err_put_vdev:
+ vfio_put_device(_mdev->vdev);
return ret;
}
@@ -766,6 +768,12 @@ static void vfio_ap_mdev_unlink_fr_queues(struct
ap_matrix_mdev *matrix_mdev)
}
}
+static void vfio_ap_mdev_release_dev(struct vfio_device *vdev)
+{
+ vfio_free_device(vdev);
+ atomic_inc(_dev->available_instances);
+}
+
static void vfio_ap_mdev_remove(struct mdev_device *mdev)
{
struct ap_matrix_mdev *matrix_mdev = dev_get_drvdata(>dev);
@@ -779,9 +787,7 @@ static void vfio_ap_mdev_remove(struct mdev_device *mdev)
list_del(_mdev->node);
mutex_unlock(_dev->mdevs_lock);
mutex_unlock(_dev->guests_lock);
- vfio_uninit_group_dev(_mdev->vdev);
- kfree(matrix_mdev);
- atomic_inc(_dev->available_instances);
+ vfio_put_device(_mdev->vdev);
}
static ssize_t name_show(struct mdev_type *mtype,
@@ -1794,6 +1800,8 @@ static const struct attribute_group vfio_queue_attr_group
= {
};
static const struct vfio_device_ops vfio_ap_matrix_dev_ops = {
+ .init = vfio_ap_mdev_init_dev,
+ .release = vfio_ap_mdev_release_dev,
.open_device = vfio_ap_mdev_open_device,
.close_device = vfio_ap_mdev_close_device,
.ioctl = vfio_ap_mdev_ioctl,
--
2.21.3
[PATCH 08/15] drm/i915/gvt: Use the new device life cycle helpers
Move vfio_device to the start of intel_vgpu as required by the new
helpers.
Change intel_gvt_create_vgpu() to use intel_vgpu as the first param
as other vgpu helpers do.
Signed-off-by: Kevin Tian
---
drivers/gpu/drm/i915/gvt/gvt.h | 5 ++-
drivers/gpu/drm/i915/gvt/kvmgt.c | 52 ++--
drivers/gpu/drm/i915/gvt/vgpu.c | 31 +++
3 files changed, 49 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 705689e64011..89fab7896fc6 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -172,6 +172,7 @@ struct intel_vgpu_submission {
#define KVMGT_DEBUGFS_FILENAME "kvmgt_nr_cache_entries"
struct intel_vgpu {
+ struct vfio_device vfio_device;
struct intel_gvt *gvt;
struct mutex vgpu_lock;
int id;
@@ -211,7 +212,6 @@ struct intel_vgpu {
u32 scan_nonprivbb;
- struct vfio_device vfio_device;
struct vfio_region *region;
int num_regions;
struct eventfd_ctx *intx_trigger;
@@ -494,8 +494,7 @@ void intel_gvt_clean_vgpu_types(struct intel_gvt *gvt);
struct intel_vgpu *intel_gvt_create_idle_vgpu(struct intel_gvt *gvt);
void intel_gvt_destroy_idle_vgpu(struct intel_vgpu *vgpu);
-struct intel_vgpu *intel_gvt_create_vgpu(struct intel_gvt *gvt,
-struct intel_vgpu_type *type);
+int intel_gvt_create_vgpu(struct intel_vgpu *vgpu, struct intel_vgpu_type
*type);
void intel_gvt_destroy_vgpu(struct intel_vgpu *vgpu);
void intel_gvt_release_vgpu(struct intel_vgpu *vgpu);
void intel_gvt_reset_vgpu_locked(struct intel_vgpu *vgpu, bool dmlr,
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index e3cd58946477..41bba40feef8 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1546,7 +1546,33 @@ static const struct attribute_group *intel_vgpu_groups[]
= {
NULL,
};
+static int intel_vgpu_init_dev(struct vfio_device *vfio_dev)
+{
+ struct mdev_device *mdev = to_mdev_device(vfio_dev->dev);
+ struct device *pdev = mdev_parent_dev(mdev);
+ struct intel_gvt *gvt = kdev_to_i915(pdev)->gvt;
+ struct intel_vgpu_type *type;
+ struct intel_vgpu *vgpu = vfio_dev_to_vgpu(vfio_dev);
+
+ type = >types[mdev_get_type_group_id(mdev)];
+ if (!type)
+ return -EINVAL;
+
+ vgpu->gvt = gvt;
+ return intel_gvt_create_vgpu(vgpu, type);
+}
+
+static void intel_vgpu_release_dev(struct vfio_device *vfio_dev)
+{
+ struct intel_vgpu *vgpu = vfio_dev_to_vgpu(vfio_dev);
+
+ intel_gvt_destroy_vgpu(vgpu);
+ vfio_free_device(vfio_dev);
+}
+
static const struct vfio_device_ops intel_vgpu_dev_ops = {
+ .init = intel_vgpu_init_dev,
+ .release= intel_vgpu_release_dev,
.open_device= intel_vgpu_open_device,
.close_device = intel_vgpu_close_device,
.read = intel_vgpu_read,
@@ -1558,35 +1584,28 @@ static const struct vfio_device_ops intel_vgpu_dev_ops
= {
static int intel_vgpu_probe(struct mdev_device *mdev)
{
- struct device *pdev = mdev_parent_dev(mdev);
- struct intel_gvt *gvt = kdev_to_i915(pdev)->gvt;
- struct intel_vgpu_type *type;
struct intel_vgpu *vgpu;
int ret;
- type = >types[mdev_get_type_group_id(mdev)];
- if (!type)
- return -EINVAL;
-
- vgpu = intel_gvt_create_vgpu(gvt, type);
+ vgpu = vfio_alloc_device(intel_vgpu, vfio_device, >dev,
+_vgpu_dev_ops);
if (IS_ERR(vgpu)) {
gvt_err("failed to create intel vgpu: %ld\n", PTR_ERR(vgpu));
return PTR_ERR(vgpu);
}
- vfio_init_group_dev(>vfio_device, >dev,
- _vgpu_dev_ops);
-
dev_set_drvdata(>dev, vgpu);
ret = vfio_register_emulated_iommu_dev(>vfio_device);
- if (ret) {
- intel_gvt_destroy_vgpu(vgpu);
- return ret;
- }
+ if (ret)
+ goto out_put_vdev;
gvt_dbg_core("intel_vgpu_create succeeded for mdev: %s\n",
dev_name(mdev_dev(mdev)));
return 0;
+
+out_put_vdev:
+ vfio_put_device(>vfio_device);
+ return ret;
}
static void intel_vgpu_remove(struct mdev_device *mdev)
@@ -1595,7 +1614,8 @@ static void intel_vgpu_remove(struct mdev_device *mdev)
if (WARN_ON_ONCE(vgpu->attached))
return;
- intel_gvt_destroy_vgpu(vgpu);
+
+ vfio_put_device(>vfio_device);
}
static struct mdev_driver intel_vgpu_mdev_driver = {
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index 46da19b3225d..2f5c21fa8166 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -302,8 +302,6 @@ void intel_gvt_destroy_vgpu(struct intel_vgpu *vgpu)
[PATCH 10/15] vfio/fsl-mc: Use the new device life cycle helpers
From: Yi Liu
Export symbol of vfio_release_device_set() so fsl-mc @init can handle
the error path cleanly instead of assuming certain vfio core API can
help release device_set afterwards.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
drivers/vfio/fsl-mc/vfio_fsl_mc.c | 87 +++
drivers/vfio/vfio_main.c | 3 +-
include/linux/vfio.h | 1 +
3 files changed, 56 insertions(+), 35 deletions(-)
diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
index 3feff729f3ce..eec3cb914f57 100644
--- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
+++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
@@ -418,16 +418,7 @@ static int vfio_fsl_mc_mmap(struct vfio_device *core_vdev,
return vfio_fsl_mc_mmap_mmio(vdev->regions[index], vma);
}
-static const struct vfio_device_ops vfio_fsl_mc_ops = {
- .name = "vfio-fsl-mc",
- .open_device= vfio_fsl_mc_open_device,
- .close_device = vfio_fsl_mc_close_device,
- .ioctl = vfio_fsl_mc_ioctl,
- .read = vfio_fsl_mc_read,
- .write = vfio_fsl_mc_write,
- .mmap = vfio_fsl_mc_mmap,
-};
-
+static const struct vfio_device_ops vfio_fsl_mc_ops;
static int vfio_fsl_mc_bus_notifier(struct notifier_block *nb,
unsigned long action, void *data)
{
@@ -518,35 +509,49 @@ static void vfio_fsl_uninit_device(struct
vfio_fsl_mc_device *vdev)
bus_unregister_notifier(_mc_bus_type, >nb);
}
-static int vfio_fsl_mc_probe(struct fsl_mc_device *mc_dev)
+static int vfio_fsl_mc_init_dev(struct vfio_device *core_vdev)
{
- struct vfio_fsl_mc_device *vdev;
- struct device *dev = _dev->dev;
+ struct vfio_fsl_mc_device *vdev =
+ container_of(core_vdev, struct vfio_fsl_mc_device, vdev);
+ struct fsl_mc_device *mc_dev = to_fsl_mc_device(core_vdev->dev);
int ret;
- vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
- if (!vdev)
- return -ENOMEM;
-
- vfio_init_group_dev(>vdev, dev, _fsl_mc_ops);
vdev->mc_dev = mc_dev;
mutex_init(>igate);
if (is_fsl_mc_bus_dprc(mc_dev))
- ret = vfio_assign_device_set(>vdev, _dev->dev);
+ ret = vfio_assign_device_set(core_vdev, _dev->dev);
else
- ret = vfio_assign_device_set(>vdev, mc_dev->dev.parent);
+ ret = vfio_assign_device_set(core_vdev, mc_dev->dev.parent);
+
if (ret)
- goto out_uninit;
+ return ret;
ret = vfio_fsl_mc_init_device(vdev);
if (ret)
- goto out_uninit;
+ goto err_assign;
+ return 0;
+
+err_assign:
+ vfio_release_device_set(core_vdev);
+ return ret;
+}
+
+static int vfio_fsl_mc_probe(struct fsl_mc_device *mc_dev)
+{
+ struct vfio_fsl_mc_device *vdev;
+ struct device *dev = _dev->dev;
+ int ret;
+
+ vdev = vfio_alloc_device(vfio_fsl_mc_device, vdev, dev,
+_fsl_mc_ops);
+ if (IS_ERR(vdev))
+ return PTR_ERR(vdev);
ret = vfio_register_group_dev(>vdev);
if (ret) {
dev_err(dev, "VFIO_FSL_MC: Failed to add to vfio group\n");
- goto out_device;
+ goto out_put_vdev;
}
ret = vfio_fsl_mc_scan_container(mc_dev);
@@ -557,30 +562,44 @@ static int vfio_fsl_mc_probe(struct fsl_mc_device *mc_dev)
out_group_dev:
vfio_unregister_group_dev(>vdev);
-out_device:
- vfio_fsl_uninit_device(vdev);
-out_uninit:
- vfio_uninit_group_dev(>vdev);
- kfree(vdev);
+out_put_vdev:
+ vfio_put_device(>vdev);
return ret;
}
+void vfio_fsl_mc_release_dev(struct vfio_device *core_vdev)
+{
+ struct vfio_fsl_mc_device *vdev =
+ container_of(core_vdev, struct vfio_fsl_mc_device, vdev);
+
+ vfio_fsl_uninit_device(vdev);
+ mutex_destroy(>igate);
+ vfio_free_device(core_vdev);
+}
+
static int vfio_fsl_mc_remove(struct fsl_mc_device *mc_dev)
{
struct device *dev = _dev->dev;
struct vfio_fsl_mc_device *vdev = dev_get_drvdata(dev);
vfio_unregister_group_dev(>vdev);
- mutex_destroy(>igate);
-
dprc_remove_devices(mc_dev, NULL, 0);
- vfio_fsl_uninit_device(vdev);
-
- vfio_uninit_group_dev(>vdev);
- kfree(vdev);
+ vfio_put_device(>vdev);
return 0;
}
+static const struct vfio_device_ops vfio_fsl_mc_ops = {
+ .name = "vfio-fsl-mc",
+ .init = vfio_fsl_mc_init_dev,
+ .release= vfio_fsl_mc_release_dev,
+ .open_device= vfio_fsl_mc_open_device,
+ .close_device = vfio_fsl_mc_close_device,
+ .ioctl = vfio_fsl_mc_ioctl,
+ .read = vfio_fsl_mc_read,
+ .write = vfio_fsl_mc_write,
+ .mmap = vfio_fsl_mc_mmap,
+};
+
static struct
[PATCH 07/15] vfio/mbochs: Use the new device life cycle helpers
From: Yi Liu
and manage avail_mbytes inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
samples/vfio-mdev/mbochs.c | 73 --
1 file changed, 46 insertions(+), 27 deletions(-)
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index 344c2901a82b..df95f25fbc0e 100644
--- a/samples/vfio-mdev/mbochs.c
+++ b/samples/vfio-mdev/mbochs.c
@@ -505,13 +505,14 @@ static int mbochs_reset(struct mdev_state *mdev_state)
return 0;
}
-static int mbochs_probe(struct mdev_device *mdev)
+static int mbochs_init_dev(struct vfio_device *vdev)
{
- int avail_mbytes = atomic_read(_avail_mbytes);
+ struct mdev_state *mdev_state =
+ container_of(vdev, struct mdev_state, vdev);
+ struct mdev_device *mdev = to_mdev_device(vdev->dev);
const struct mbochs_type *type =
_types[mdev_get_type_group_id(mdev)];
- struct device *dev = mdev_dev(mdev);
- struct mdev_state *mdev_state;
+ int avail_mbytes = atomic_read(_avail_mbytes);
int ret = -ENOMEM;
do {
@@ -520,14 +521,9 @@ static int mbochs_probe(struct mdev_device *mdev)
} while (!atomic_try_cmpxchg(_avail_mbytes, _mbytes,
avail_mbytes - type->mbytes));
- mdev_state = kzalloc(sizeof(struct mdev_state), GFP_KERNEL);
- if (mdev_state == NULL)
- goto err_avail;
- vfio_init_group_dev(_state->vdev, >dev, _dev_ops);
-
mdev_state->vconfig = kzalloc(MBOCHS_CONFIG_SPACE_SIZE, GFP_KERNEL);
- if (mdev_state->vconfig == NULL)
- goto err_mem;
+ if (!mdev_state->vconfig)
+ goto err_avail;
mdev_state->memsize = type->mbytes * 1024 * 1024;
mdev_state->pagecount = mdev_state->memsize >> PAGE_SHIFT;
@@ -535,10 +531,7 @@ static int mbochs_probe(struct mdev_device *mdev)
sizeof(struct page *),
GFP_KERNEL);
if (!mdev_state->pages)
- goto err_mem;
-
- dev_info(dev, "%s: %s, %d MB, %ld pages\n", __func__,
-type->name, type->mbytes, mdev_state->pagecount);
+ goto err_vconfig;
mutex_init(_state->ops_lock);
mdev_state->mdev = mdev;
@@ -553,19 +546,47 @@ static int mbochs_probe(struct mdev_device *mdev)
mbochs_create_config_space(mdev_state);
mbochs_reset(mdev_state);
+ dev_info(vdev->dev, "%s: %s, %d MB, %ld pages\n", __func__,
+type->name, type->mbytes, mdev_state->pagecount);
+ return 0;
+
+err_vconfig:
+ kfree(mdev_state->vconfig);
+err_avail:
+ atomic_add(type->mbytes, _avail_mbytes);
+ return ret;
+}
+
+static int mbochs_probe(struct mdev_device *mdev)
+{
+ struct mdev_state *mdev_state;
+ int ret = -ENOMEM;
+
+ mdev_state = vfio_alloc_device(mdev_state, vdev, >dev,
+ _dev_ops);
+ if (IS_ERR(mdev_state))
+ return PTR_ERR(mdev_state);
+
ret = vfio_register_emulated_iommu_dev(_state->vdev);
if (ret)
- goto err_mem;
+ goto err_put_vdev;
dev_set_drvdata(>dev, mdev_state);
return 0;
-err_mem:
- vfio_uninit_group_dev(_state->vdev);
+
+err_put_vdev:
+ vfio_put_device(_state->vdev);
+ return ret;
+}
+
+static void mbochs_release_dev(struct vfio_device *vdev)
+{
+ struct mdev_state *mdev_state =
+ container_of(vdev, struct mdev_state, vdev);
+
kfree(mdev_state->pages);
kfree(mdev_state->vconfig);
- kfree(mdev_state);
-err_avail:
- atomic_add(type->mbytes, _avail_mbytes);
- return ret;
+ vfio_free_device(vdev);
+ atomic_add(mdev_state->type->mbytes, _avail_mbytes);
}
static void mbochs_remove(struct mdev_device *mdev)
@@ -573,11 +594,7 @@ static void mbochs_remove(struct mdev_device *mdev)
struct mdev_state *mdev_state = dev_get_drvdata(>dev);
vfio_unregister_group_dev(_state->vdev);
- vfio_uninit_group_dev(_state->vdev);
- atomic_add(mdev_state->type->mbytes, _avail_mbytes);
- kfree(mdev_state->pages);
- kfree(mdev_state->vconfig);
- kfree(mdev_state);
+ vfio_put_device(_state->vdev);
}
static ssize_t mbochs_read(struct vfio_device *vdev, char __user *buf,
@@ -1397,6 +1414,8 @@ static struct attribute_group *mdev_type_groups[] = {
static const struct vfio_device_ops mbochs_dev_ops = {
.close_device = mbochs_close_device,
+ .init = mbochs_init_dev,
+ .release = mbochs_release_dev,
.read = mbochs_read,
.write = mbochs_write,
.ioctl = mbochs_ioctl,
--
2.21.3
[PATCH 06/15] vfio/mtty: Use the new device life cycle helpers
From: Yi Liu
and manage available ports inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
samples/vfio-mdev/mtty.c | 67 +++-
1 file changed, 39 insertions(+), 28 deletions(-)
diff --git a/samples/vfio-mdev/mtty.c b/samples/vfio-mdev/mtty.c
index f42a59ed2e3f..41301d50b247 100644
--- a/samples/vfio-mdev/mtty.c
+++ b/samples/vfio-mdev/mtty.c
@@ -703,9 +703,11 @@ static ssize_t mdev_access(struct mdev_state *mdev_state,
u8 *buf, size_t count,
return ret;
}
-static int mtty_probe(struct mdev_device *mdev)
+static int mtty_init_dev(struct vfio_device *vdev)
{
- struct mdev_state *mdev_state;
+ struct mdev_state *mdev_state =
+ container_of(vdev, struct mdev_state, vdev);
+ struct mdev_device *mdev = to_mdev_device(vdev->dev);
int nr_ports = mdev_get_type_group_id(mdev) + 1;
int avail_ports = atomic_read(_avail_ports);
int ret;
@@ -716,58 +718,65 @@ static int mtty_probe(struct mdev_device *mdev)
} while (!atomic_try_cmpxchg(_avail_ports,
_ports, avail_ports - nr_ports));
- mdev_state = kzalloc(sizeof(struct mdev_state), GFP_KERNEL);
- if (mdev_state == NULL) {
- ret = -ENOMEM;
- goto err_nr_ports;
- }
-
- vfio_init_group_dev(_state->vdev, >dev, _dev_ops);
-
mdev_state->nr_ports = nr_ports;
mdev_state->irq_index = -1;
mdev_state->s[0].max_fifo_size = MAX_FIFO_SIZE;
mdev_state->s[1].max_fifo_size = MAX_FIFO_SIZE;
mutex_init(_state->rxtx_lock);
- mdev_state->vconfig = kzalloc(MTTY_CONFIG_SPACE_SIZE, GFP_KERNEL);
- if (mdev_state->vconfig == NULL) {
+ mdev_state->vconfig = kzalloc(MTTY_CONFIG_SPACE_SIZE, GFP_KERNEL);
+ if (!mdev_state->vconfig) {
ret = -ENOMEM;
- goto err_state;
+ goto err_nr_ports;
}
mutex_init(_state->ops_lock);
mdev_state->mdev = mdev;
-
mtty_create_config_space(mdev_state);
+ return 0;
+
+err_nr_ports:
+ atomic_add(nr_ports, _avail_ports);
+ return ret;
+}
+
+static int mtty_probe(struct mdev_device *mdev)
+{
+ struct mdev_state *mdev_state;
+ int ret;
+
+ mdev_state = vfio_alloc_device(mdev_state, vdev, >dev,
+ _dev_ops);
+ if (IS_ERR(mdev_state))
+ return PTR_ERR(mdev_state);
ret = vfio_register_emulated_iommu_dev(_state->vdev);
if (ret)
- goto err_vconfig;
+ goto err_put_vdev;
dev_set_drvdata(>dev, mdev_state);
return 0;
-err_vconfig:
- kfree(mdev_state->vconfig);
-err_state:
- vfio_uninit_group_dev(_state->vdev);
- kfree(mdev_state);
-err_nr_ports:
- atomic_add(nr_ports, _avail_ports);
+err_put_vdev:
+ vfio_put_device(_state->vdev);
return ret;
}
+static void mtty_release_dev(struct vfio_device *vdev)
+{
+ struct mdev_state *mdev_state =
+ container_of(vdev, struct mdev_state, vdev);
+
+ kfree(mdev_state->vconfig);
+ vfio_free_device(vdev);
+ atomic_add(mdev_state->nr_ports, _avail_ports);
+}
+
static void mtty_remove(struct mdev_device *mdev)
{
struct mdev_state *mdev_state = dev_get_drvdata(>dev);
- int nr_ports = mdev_state->nr_ports;
vfio_unregister_group_dev(_state->vdev);
-
- kfree(mdev_state->vconfig);
- vfio_uninit_group_dev(_state->vdev);
- kfree(mdev_state);
- atomic_add(nr_ports, _avail_ports);
+ vfio_put_device(_state->vdev);
}
static int mtty_reset(struct mdev_state *mdev_state)
@@ -1287,6 +1296,8 @@ static struct attribute_group *mdev_type_groups[] = {
static const struct vfio_device_ops mtty_dev_ops = {
.name = "vfio-mtty",
+ .init = mtty_init_dev,
+ .release = mtty_release_dev,
.read = mtty_read,
.write = mtty_write,
.ioctl = mtty_ioctl,
--
2.21.3
[PATCH 05/15] vfio/mdpy: Use the new device life cycle helpers
From: Yi Liu
and manage mdpy_count inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
samples/vfio-mdev/mdpy.c | 81 +++-
1 file changed, 47 insertions(+), 34 deletions(-)
diff --git a/samples/vfio-mdev/mdpy.c b/samples/vfio-mdev/mdpy.c
index e8c46eb2e246..a07dac16d873 100644
--- a/samples/vfio-mdev/mdpy.c
+++ b/samples/vfio-mdev/mdpy.c
@@ -216,61 +216,77 @@ static int mdpy_reset(struct mdev_state *mdev_state)
return 0;
}
-static int mdpy_probe(struct mdev_device *mdev)
+static int mdpy_init_dev(struct vfio_device *vdev)
{
+ struct mdev_state *mdev_state =
+ container_of(vdev, struct mdev_state, vdev);
+ struct mdev_device *mdev = to_mdev_device(vdev->dev);
const struct mdpy_type *type =
_types[mdev_get_type_group_id(mdev)];
- struct device *dev = mdev_dev(mdev);
- struct mdev_state *mdev_state;
u32 fbsize;
- int ret;
+ int ret = -ENOMEM;
if (mdpy_count >= max_devices)
- return -ENOMEM;
-
- mdev_state = kzalloc(sizeof(struct mdev_state), GFP_KERNEL);
- if (mdev_state == NULL)
- return -ENOMEM;
- vfio_init_group_dev(_state->vdev, >dev, _dev_ops);
+ return ret;
mdev_state->vconfig = kzalloc(MDPY_CONFIG_SPACE_SIZE, GFP_KERNEL);
- if (mdev_state->vconfig == NULL) {
- ret = -ENOMEM;
- goto err_state;
- }
+ if (!mdev_state->vconfig)
+ return ret;
fbsize = roundup_pow_of_two(type->width * type->height * type->bytepp);
mdev_state->memblk = vmalloc_user(fbsize);
- if (!mdev_state->memblk) {
- ret = -ENOMEM;
- goto err_vconfig;
- }
- dev_info(dev, "%s: %s (%dx%d)\n", __func__, type->name, type->width,
-type->height);
+ if (!mdev_state->memblk)
+ goto out_vconfig;
mutex_init(_state->ops_lock);
mdev_state->mdev = mdev;
- mdev_state->type= type;
+ mdev_state->type = type;
mdev_state->memsize = fbsize;
mdpy_create_config_space(mdev_state);
mdpy_reset(mdev_state);
+ dev_info(vdev->dev, "%s: %s (%dx%d)\n", __func__, type->name,
type->width,
+type->height);
+
mdpy_count++;
+ return 0;
+
+out_vconfig:
+ kfree(mdev_state->vconfig);
+ return ret;
+}
+
+static int mdpy_probe(struct mdev_device *mdev)
+{
+ struct mdev_state *mdev_state;
+ int ret;
+
+ mdev_state = vfio_alloc_device(mdev_state, vdev, >dev,
+ _dev_ops);
+ if (IS_ERR(mdev_state))
+ return PTR_ERR(mdev_state);
ret = vfio_register_emulated_iommu_dev(_state->vdev);
if (ret)
- goto err_mem;
+ goto err_put_vdev;
dev_set_drvdata(>dev, mdev_state);
return 0;
-err_mem:
+
+err_put_vdev:
+ vfio_put_device(_state->vdev);
+ return ret;
+}
+
+static void mdpy_release_dev(struct vfio_device *vdev)
+{
+ struct mdev_state *mdev_state =
+ container_of(vdev, struct mdev_state, vdev);
+
vfree(mdev_state->memblk);
-err_vconfig:
kfree(mdev_state->vconfig);
-err_state:
- vfio_uninit_group_dev(_state->vdev);
- kfree(mdev_state);
- return ret;
+ vfio_free_device(vdev);
+ mdpy_count--;
}
static void mdpy_remove(struct mdev_device *mdev)
@@ -280,12 +296,7 @@ static void mdpy_remove(struct mdev_device *mdev)
dev_info(>dev, "%s\n", __func__);
vfio_unregister_group_dev(_state->vdev);
- vfree(mdev_state->memblk);
- kfree(mdev_state->vconfig);
- vfio_uninit_group_dev(_state->vdev);
- kfree(mdev_state);
-
- mdpy_count--;
+ vfio_put_device(_state->vdev);
}
static ssize_t mdpy_read(struct vfio_device *vdev, char __user *buf,
@@ -708,6 +719,8 @@ static struct attribute_group *mdev_type_groups[] = {
};
static const struct vfio_device_ops mdpy_dev_ops = {
+ .init = mdpy_init_dev,
+ .release = mdpy_release_dev,
.read = mdpy_read,
.write = mdpy_write,
.ioctl = mdpy_ioctl,
--
2.21.3
[PATCH 04/15] vfio/hisi_acc: Use the new device life cycle helpers
From: Yi Liu
Tidy up @probe so all migration specific initialization logic is moved
to migration specific @init callback.
Remove vfio_pci_core_{un}init_device() given no user now.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
.../vfio/pci/hisilicon/hisi_acc_vfio_pci.c| 80 +--
drivers/vfio/pci/vfio_pci_core.c | 30 ---
include/linux/vfio_pci_core.h | 4 -
3 files changed, 37 insertions(+), 77 deletions(-)
diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
index ea762e28c1cc..f06f9a799128 100644
--- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
+++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
@@ -1213,8 +1213,28 @@ static const struct vfio_migration_ops
hisi_acc_vfio_pci_migrn_state_ops = {
.migration_get_state = hisi_acc_vfio_pci_get_device_state,
};
+int hisi_acc_vfio_pci_migrn_init_dev(struct vfio_device *core_vdev)
+{
+ struct hisi_acc_vf_core_device *hisi_acc_vdev = container_of(core_vdev,
+ struct hisi_acc_vf_core_device, core_device.vdev);
+ struct pci_dev *pdev = to_pci_dev(core_vdev->dev);
+ struct hisi_qm *pf_qm = hisi_acc_get_pf_qm(pdev);
+
+ hisi_acc_vdev->vf_id = pci_iov_vf_id(pdev) + 1;
+ hisi_acc_vdev->pf_qm = pf_qm;
+ hisi_acc_vdev->vf_dev = pdev;
+ mutex_init(_acc_vdev->state_mutex);
+
+ core_vdev->migration_flags = VFIO_MIGRATION_STOP_COPY;
+ core_vdev->mig_ops = _acc_vfio_pci_migrn_state_ops;
+
+ return vfio_pci_core_init_dev(core_vdev);
+}
+
static const struct vfio_device_ops hisi_acc_vfio_pci_migrn_ops = {
.name = "hisi-acc-vfio-pci-migration",
+ .init = hisi_acc_vfio_pci_migrn_init_dev,
+ .release = vfio_pci_core_release_dev,
.open_device = hisi_acc_vfio_pci_open_device,
.close_device = hisi_acc_vfio_pci_close_device,
.ioctl = hisi_acc_vfio_pci_ioctl,
@@ -1228,6 +1248,8 @@ static const struct vfio_device_ops
hisi_acc_vfio_pci_migrn_ops = {
static const struct vfio_device_ops hisi_acc_vfio_pci_ops = {
.name = "hisi-acc-vfio-pci",
+ .init = vfio_pci_core_init_dev,
+ .release = vfio_pci_core_release_dev,
.open_device = hisi_acc_vfio_pci_open_device,
.close_device = vfio_pci_core_close_device,
.ioctl = vfio_pci_core_ioctl,
@@ -1239,63 +1261,36 @@ static const struct vfio_device_ops
hisi_acc_vfio_pci_ops = {
.match = vfio_pci_core_match,
};
-static int
-hisi_acc_vfio_pci_migrn_init(struct hisi_acc_vf_core_device *hisi_acc_vdev,
-struct pci_dev *pdev, struct hisi_qm *pf_qm)
-{
- int vf_id;
-
- vf_id = pci_iov_vf_id(pdev);
- if (vf_id < 0)
- return vf_id;
-
- hisi_acc_vdev->vf_id = vf_id + 1;
- hisi_acc_vdev->core_device.vdev.migration_flags =
- VFIO_MIGRATION_STOP_COPY;
- hisi_acc_vdev->pf_qm = pf_qm;
- hisi_acc_vdev->vf_dev = pdev;
- mutex_init(_acc_vdev->state_mutex);
-
- return 0;
-}
-
static int hisi_acc_vfio_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
{
struct hisi_acc_vf_core_device *hisi_acc_vdev;
+ const struct vfio_device_ops *ops = _acc_vfio_pci_ops;
struct hisi_qm *pf_qm;
+ int vf_id;
int ret;
- hisi_acc_vdev = kzalloc(sizeof(*hisi_acc_vdev), GFP_KERNEL);
- if (!hisi_acc_vdev)
- return -ENOMEM;
-
pf_qm = hisi_acc_get_pf_qm(pdev);
if (pf_qm && pf_qm->ver >= QM_HW_V3) {
- ret = hisi_acc_vfio_pci_migrn_init(hisi_acc_vdev, pdev, pf_qm);
- if (!ret) {
- vfio_pci_core_init_device(_acc_vdev->core_device,
pdev,
- _acc_vfio_pci_migrn_ops);
- hisi_acc_vdev->core_device.vdev.mig_ops =
- _acc_vfio_pci_migrn_state_ops;
- } else {
+ vf_id = pci_iov_vf_id(pdev);
+ if (vf_id >= 0)
+ ops = _acc_vfio_pci_migrn_ops;
+ else
pci_warn(pdev, "migration support failed, continue with
generic interface\n");
- vfio_pci_core_init_device(_acc_vdev->core_device,
pdev,
- _acc_vfio_pci_ops);
- }
- } else {
- vfio_pci_core_init_device(_acc_vdev->core_device, pdev,
- _acc_vfio_pci_ops);
}
+ hisi_acc_vdev = vfio_alloc_device(hisi_acc_vf_core_device,
+ core_device.vdev, >dev, ops);
+ if (IS_ERR(hisi_acc_vdev))
+ return PTR_ERR(hisi_acc_vdev);
+
dev_set_drvdata(>dev, _acc_vdev->core_device);
ret = vfio_pci_core_register_device(_acc_vdev->core_device);
if
[PATCH 03/15] vfio/mlx5: Use the new device life cycle helpers
From: Yi Liu
mlx5 has its own @init/@release for handling migration cap.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
drivers/vfio/pci/mlx5/main.c | 49 ++--
1 file changed, 36 insertions(+), 13 deletions(-)
diff --git a/drivers/vfio/pci/mlx5/main.c b/drivers/vfio/pci/mlx5/main.c
index a9b63d15c5d3..96d1f974f0b5 100644
--- a/drivers/vfio/pci/mlx5/main.c
+++ b/drivers/vfio/pci/mlx5/main.c
@@ -579,8 +579,35 @@ static const struct vfio_migration_ops mlx5vf_pci_mig_ops
= {
.migration_get_state = mlx5vf_pci_get_device_state,
};
+static int mlx5vf_pci_init_dev(struct vfio_device *core_vdev)
+{
+ struct mlx5vf_pci_core_device *mvdev = container_of(
+ core_vdev, struct mlx5vf_pci_core_device, core_device.vdev);
+ int ret;
+
+ ret = vfio_pci_core_init_dev(core_vdev);
+ if (ret)
+ return ret;
+
+ mlx5vf_cmd_set_migratable(mvdev, _pci_mig_ops);
+
+ return 0;
+
+}
+
+static void mlx5vf_pci_release_dev(struct vfio_device *core_vdev)
+{
+ struct mlx5vf_pci_core_device *mvdev = container_of(
+ core_vdev, struct mlx5vf_pci_core_device, core_device.vdev);
+
+ mlx5vf_cmd_remove_migratable(mvdev);
+ vfio_pci_core_release_dev(core_vdev);
+}
+
static const struct vfio_device_ops mlx5vf_pci_ops = {
.name = "mlx5-vfio-pci",
+ .init = mlx5vf_pci_init_dev,
+ .release = mlx5vf_pci_release_dev,
.open_device = mlx5vf_pci_open_device,
.close_device = mlx5vf_pci_close_device,
.ioctl = vfio_pci_core_ioctl,
@@ -598,21 +625,19 @@ static int mlx5vf_pci_probe(struct pci_dev *pdev,
struct mlx5vf_pci_core_device *mvdev;
int ret;
- mvdev = kzalloc(sizeof(*mvdev), GFP_KERNEL);
- if (!mvdev)
- return -ENOMEM;
- vfio_pci_core_init_device(>core_device, pdev, _pci_ops);
- mlx5vf_cmd_set_migratable(mvdev, _pci_mig_ops);
+ mvdev = vfio_alloc_device(mlx5vf_pci_core_device, core_device.vdev,
+ >dev, _pci_ops);
+ if (IS_ERR(mvdev))
+ return PTR_ERR(mvdev);
+
dev_set_drvdata(>dev, >core_device);
ret = vfio_pci_core_register_device(>core_device);
if (ret)
- goto out_free;
+ goto out_put_vdev;
return 0;
-out_free:
- mlx5vf_cmd_remove_migratable(mvdev);
- vfio_pci_core_uninit_device(>core_device);
- kfree(mvdev);
+out_put_vdev:
+ vfio_put_device(>core_device.vdev);
return ret;
}
@@ -621,9 +646,7 @@ static void mlx5vf_pci_remove(struct pci_dev *pdev)
struct mlx5vf_pci_core_device *mvdev = mlx5vf_drvdata(pdev);
vfio_pci_core_unregister_device(>core_device);
- mlx5vf_cmd_remove_migratable(mvdev);
- vfio_pci_core_uninit_device(>core_device);
- kfree(mvdev);
+ vfio_put_device(>core_device.vdev);
}
static const struct pci_device_id mlx5vf_pci_table[] = {
--
2.21.3
[PATCH 02/15] vfio/pci: Use the new device life cycle helpers
From: Yi Liu
Also introduce two pci core helpers as @init/@release for pci drivers:
- vfio_pci_core_init_dev()
- vfio_pci_core_release_dev()
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
drivers/vfio/pci/vfio_pci.c | 20 +-
drivers/vfio/pci/vfio_pci_core.c | 35
include/linux/vfio_pci_core.h| 2 ++
3 files changed, 47 insertions(+), 10 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 4d1a97415a27..c1223c458615 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -127,6 +127,8 @@ static int vfio_pci_open_device(struct vfio_device
*core_vdev)
static const struct vfio_device_ops vfio_pci_ops = {
.name = "vfio-pci",
+ .init = vfio_pci_core_init_dev,
+ .release= vfio_pci_core_release_dev,
.open_device= vfio_pci_open_device,
.close_device = vfio_pci_core_close_device,
.ioctl = vfio_pci_core_ioctl,
@@ -146,20 +148,19 @@ static int vfio_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
if (vfio_pci_is_denylisted(pdev))
return -EINVAL;
- vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
- if (!vdev)
- return -ENOMEM;
- vfio_pci_core_init_device(vdev, pdev, _pci_ops);
+ vdev = vfio_alloc_device(vfio_pci_core_device, vdev, >dev,
+_pci_ops);
+ if (IS_ERR(vdev))
+ return PTR_ERR(vdev);
dev_set_drvdata(>dev, vdev);
ret = vfio_pci_core_register_device(vdev);
if (ret)
- goto out_free;
+ goto out_put_vdev;
return 0;
-out_free:
- vfio_pci_core_uninit_device(vdev);
- kfree(vdev);
+out_put_vdev:
+ vfio_put_device(>vdev);
return ret;
}
@@ -168,8 +169,7 @@ static void vfio_pci_remove(struct pci_dev *pdev)
struct vfio_pci_core_device *vdev = dev_get_drvdata(>dev);
vfio_pci_core_unregister_device(vdev);
- vfio_pci_core_uninit_device(vdev);
- kfree(vdev);
+ vfio_put_device(>vdev);
}
static int vfio_pci_sriov_configure(struct pci_dev *pdev, int nr_virtfn)
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index c8d3b0450fb3..708b61d1b364 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -1825,6 +1825,41 @@ static void vfio_pci_vga_uninit(struct
vfio_pci_core_device *vdev)
VGA_RSRC_LEGACY_MEM);
}
+int vfio_pci_core_init_dev(struct vfio_device *core_vdev)
+{
+ struct vfio_pci_core_device *vdev =
+ container_of(core_vdev, struct vfio_pci_core_device, vdev);
+
+ vdev->pdev = to_pci_dev(core_vdev->dev);
+ vdev->irq_type = VFIO_PCI_NUM_IRQS;
+ mutex_init(>igate);
+ spin_lock_init(>irqlock);
+ mutex_init(>ioeventfds_lock);
+ INIT_LIST_HEAD(>dummy_resources_list);
+ INIT_LIST_HEAD(>ioeventfds_list);
+ mutex_init(>vma_lock);
+ INIT_LIST_HEAD(>vma_list);
+ INIT_LIST_HEAD(>sriov_pfs_item);
+ init_rwsem(>memory_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(vfio_pci_core_init_dev);
+
+void vfio_pci_core_release_dev(struct vfio_device *core_vdev)
+{
+ struct vfio_pci_core_device *vdev =
+ container_of(core_vdev, struct vfio_pci_core_device, vdev);
+
+ mutex_destroy(>igate);
+ mutex_destroy(>ioeventfds_lock);
+ mutex_destroy(>vma_lock);
+ kfree(vdev->region);
+ kfree(vdev->pm_save);
+ vfio_free_device(core_vdev);
+}
+EXPORT_SYMBOL_GPL(vfio_pci_core_release_dev);
+
void vfio_pci_core_init_device(struct vfio_pci_core_device *vdev,
struct pci_dev *pdev,
const struct vfio_device_ops *vfio_pci_ops)
diff --git a/include/linux/vfio_pci_core.h b/include/linux/vfio_pci_core.h
index 5579ece4347b..98c8c66e2400 100644
--- a/include/linux/vfio_pci_core.h
+++ b/include/linux/vfio_pci_core.h
@@ -233,6 +233,8 @@ void vfio_pci_core_close_device(struct vfio_device
*core_vdev);
void vfio_pci_core_init_device(struct vfio_pci_core_device *vdev,
struct pci_dev *pdev,
const struct vfio_device_ops *vfio_pci_ops);
+int vfio_pci_core_init_dev(struct vfio_device *core_vdev);
+void vfio_pci_core_release_dev(struct vfio_device *core_vdev);
int vfio_pci_core_register_device(struct vfio_pci_core_device *vdev);
void vfio_pci_core_uninit_device(struct vfio_pci_core_device *vdev);
void vfio_pci_core_unregister_device(struct vfio_pci_core_device *vdev);
--
2.21.3
[PATCH 01/15] vfio: Add helpers for unifying vfio_device life cycle
The idea is to let vfio core manage the vfio_device life cycle instead
of duplicating the logic cross drivers. This is also a preparatory
step for adding struct device into vfio_device.
New pair of helpers together with a kref in vfio_device:
- vfio_alloc_device()
- vfio_put_device()
Drivers can register @init/@release callbacks to manage any private
state wrapping the vfio_device.
However vfio-ccw doesn't fit this model due to a life cycle mess
that its private structure mixes both parent and mdev info hence must
be allocated/free'ed outside of the life cycle of vfio device.
Per prior discussions this won't be fixed in short term by IBM folks.
Instead of waiting introduce another helper vfio_init_device() so ccw
can call it to initialize a pre-allocated vfio_device.
Further implication of the ccw trick is that vfio_device cannot be
free'ed uniformly in vfio core. Instead, require *EVERY* driver to
implement @release and free vfio_device inside. Then ccw can choose
to delay the free at its own discretion.
Another trick down the road is that kvzalloc() is used to accommodate
the need of gvt which uses vzalloc() while all others use kzalloc().
So drivers should call a helper vfio_free_device() to free the
vfio_device instead of assuming that kfree() or vfree() is appliable.
Later once the ccw mess is fixed we can remove those tricks and
fully handle structure alloc/free in vfio core.
Existing vfio_{un}init_group_dev() will be deprecated after all
existing usages are converted to the new model.
Suggested-by: Jason Gunthorpe
Co-developed-by: Yi Liu
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
drivers/vfio/vfio_main.c | 92
include/linux/vfio.h | 25 ++-
2 files changed, 116 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 7cb56c382c97..af8aad116f2b 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -496,6 +496,98 @@ void vfio_uninit_group_dev(struct vfio_device *device)
}
EXPORT_SYMBOL_GPL(vfio_uninit_group_dev);
+/*
+ * Alloc and initialize vfio_device so it can be registered to vfio
+ * core.
+ *
+ * Drivers should use the wrapper vfio_alloc_device() for allocation.
+ * @size is the size of the structure to be allocated, including any
+ * private data used by the driver.
+ *
+ * Driver may provide an @init callback to cover device private data.
+ *
+ * Use vfio_put_device() to release the structure after success return.
+ */
+struct vfio_device *_vfio_alloc_device(size_t size, struct device *dev,
+ const struct vfio_device_ops *ops)
+{
+ struct vfio_device *device;
+ int ret;
+
+ if (WARN_ON(size < sizeof(struct vfio_device)))
+ return ERR_PTR(-EINVAL);
+
+ device = kvzalloc(size, GFP_KERNEL);
+ if (!device)
+ return ERR_PTR(-ENOMEM);
+
+ ret = vfio_init_device(device, dev, ops);
+ if (ret)
+ goto out_free;
+ return device;
+
+out_free:
+ kvfree(device);
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(_vfio_alloc_device);
+
+/*
+ * Initialize a vfio_device so it can be registered to vfio core.
+ *
+ * Only vfio-ccw driver should call this interface.
+ */
+int vfio_init_device(struct vfio_device *device, struct device *dev,
+const struct vfio_device_ops *ops)
+{
+ int ret;
+
+ vfio_init_group_dev(device, dev, ops);
+
+ if (ops->init) {
+ ret = ops->init(device);
+ if (ret)
+ goto out_uninit;
+ }
+
+ kref_init(>kref);
+ return 0;
+
+out_uninit:
+ vfio_uninit_group_dev(device);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(vfio_init_device);
+
+/*
+ * The helper called by driver @release callback to free the device
+ * structure. Drivers which don't have private data to clean can
+ * simply use this helper as its @release.
+ */
+void vfio_free_device(struct vfio_device *device)
+{
+ kvfree(device);
+}
+EXPORT_SYMBOL_GPL(vfio_free_device);
+
+/* Release helper called by vfio_put_device() */
+void vfio_device_release(struct kref *kref)
+{
+ struct vfio_device *device =
+ container_of(kref, struct vfio_device, kref);
+
+ vfio_uninit_group_dev(device);
+
+ /*
+* kvfree() cannot be done here due to a life cycle mess in
+* vfio-ccw. Before the ccw part is fixed all drivers are
+* required to support @release and call vfio_free_device()
+* from there.
+*/
+ device->ops->release(device);
+}
+EXPORT_SYMBOL_GPL(vfio_device_release);
+
static struct vfio_group *vfio_noiommu_group_alloc(struct device *dev,
enum vfio_group_type type)
{
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index e05ddc6fe6a5..e1e9e8352903 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -45,7 +45,8 @@ struct vfio_device {
struct kvm *kvm;
[PATCH 00/15] Tidy up vfio_device life cycle
The idea is to let vfio core manage the vfio_device life cycle instead of duplicating the logic cross drivers. Besides cleaner code in driver side this also allows adding struct device to vfio_device as the first step toward adding cdev uAPI in the future. Another benefit is that user can now look at sysfs to decide whether a device is bound to vfio [1], e.g.: /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0 Though most drivers can fit the new model naturally: - vfio_alloc_device() to allocate and initialize vfio_device - vfio_put_device() to release vfio_device - dev_ops->init() for driver private initialization - dev_ops->release() for driver private cleanup vfio-ccw is the only exception due to a life cycle mess that its private structure mixes both parent and mdev info hence must be alloc/free'ed outside of the life cycle of vfio device. Per prior discussions this won't be fixed in short term by IBM folks [2]. Instead of waiting this series introduces a few tricks to move forward: - vfio_init_device() to initialize a pre-allocated device structure; - require *EVERY* driver to implement @release and free vfio_device inside. Then vfio-ccw can use a completion mechanism to delay the free to css driver; The second trick is not a real burden to other drivers because they all require a @release for private cleanup anyay. Later once the ccw mess is fixed a simple cleanup can be done by moving free from @release to vfio core. Thanks Kevin [1] https://listman.redhat.com/archives/libvir-list/2022-August/233482.html [2] https://lore.kernel.org/all/0ee29bd6583f17f0ee4ec0769fa50e8ea6703623.ca...@linux.ibm.com/ Kevin Tian (6): vfio: Add helpers for unifying vfio_device life cycle drm/i915/gvt: Use the new device life cycle helpers vfio/platform: Use the new device life cycle helpers vfio/amba: Use the new device life cycle helpers vfio/ccw: Use the new device life cycle helpers vfio: Rename vfio_device_put() and vfio_device_try_get() Yi Liu (9): vfio/pci: Use the new device life cycle helpers vfio/mlx5: Use the new device life cycle helpers vfio/hisi_acc: Use the new device life cycle helpers vfio/mdpy: Use the new device life cycle helpers vfio/mtty: Use the new device life cycle helpers vfio/mbochs: Use the new device life cycle helpers vfio/ap: Use the new device life cycle helpers vfio/fsl-mc: Use the new device life cycle helpers vfio: Add struct device to vfio_device drivers/gpu/drm/i915/gvt/gvt.h| 5 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 52 -- drivers/gpu/drm/i915/gvt/vgpu.c | 31 ++-- drivers/s390/cio/vfio_ccw_ops.c | 52 +- drivers/s390/cio/vfio_ccw_private.h | 3 + drivers/s390/crypto/vfio_ap_ops.c | 50 +++--- drivers/vfio/fsl-mc/vfio_fsl_mc.c | 87 + .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c| 80 - drivers/vfio/pci/mlx5/main.c | 49 -- drivers/vfio/pci/vfio_pci.c | 20 +-- drivers/vfio/pci/vfio_pci_core.c | 23 ++- drivers/vfio/platform/vfio_amba.c | 72 ++-- drivers/vfio/platform/vfio_platform.c | 66 +-- drivers/vfio/platform/vfio_platform_common.c | 61 +++ drivers/vfio/platform/vfio_platform_private.h | 18 +- drivers/vfio/vfio_main.c | 165 +++--- include/linux/vfio.h | 29 ++- include/linux/vfio_pci_core.h | 6 +- samples/vfio-mdev/mbochs.c| 73 +--- samples/vfio-mdev/mdpy.c | 81 + samples/vfio-mdev/mtty.c | 67 --- 21 files changed, 724 insertions(+), 366 deletions(-) base-commit: 1c23f9e627a7b412978b4e852793c5e3c3efc555 -- 2.21.3
Re: [PATCH 3/4] dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
On 26/08/2022 22:24, Lucas Stach wrote: > Add binding for the i.MX8MP HDMI parallel video interface block. > > Signed-off-by: Lucas Stach > Tested-by: Marek Vasut Same question - how was it tested? This is v1, right? Rest looks good, except Laurent's comments. Best regards, Krzysztof
Re: [PATCH 1/4] dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
On 26/08/2022 22:24, Lucas Stach wrote:
> The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
> core with a little bit of SoC integration around it.
>
> Signed-off-by: Lucas Stach
> Tested-by: Marek Vasut
What tested-by means in the terms of bindings? What tests were applied
exactly?
> ---
> .../bindings/display/imx/fsl,imx8mp-hdmi.yaml | 74 +++
> 1 file changed, 74 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi.yaml
> b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi.yaml
> new file mode 100644
> index ..14f7cd47209c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/imx/fsl,imx8mp-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX8MP DWC HDMI TX Encoder
> +
> +maintainers:
> + - Lucas Stach
> +
> +description: |
> + The HDMI transmitter is a Synopsys DesignWare HDMI 2.0 TX controller IP.
> +
> +allOf:
> + - $ref: ../bridge/synopsys,dw-hdmi.yaml#
> +
> +properties:
> + compatible:
> +enum:
> + - fsl,imx8mp-hdmi
> +
> + reg:
> +maxItems: 1
> +
> + reg-io-width:
> +const: 1
> +
> + clocks:
> +maxItems: 5
> +
> + clock-names:
> +items:
> + - {}
> + - {}
Clocks should be strictly defined.
> + - const: cec
> + - const: pix
> + - const: fdcc
> +
> + interrupts:
> +maxItems: 1
This is coming from synopsys. Skip it and use unevaluatedProperties:false
reg actually as well...
> +
> + power-domains:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - interrupts
> + - power-domains
> +
> +additionalProperties: false
> +
Best regards,
Krzysztof
RE: [PATCH 2/2] drm: rcar-du: Use %p4cc to print 4CC format
Hi Laurent,
Thanks for the feedback.
> Subject: Re: [PATCH 2/2] drm: rcar-du: Use %p4cc to print 4CC format
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Thu, Aug 25, 2022 at 11:39:05AM +0100, Biju Das wrote:
> > Replace use of struct rcar_du_format_info with %p4cc for printing 4CC
> > formats.
>
> The code change looks good, but doesn't match the commit message. You're
> not replacing usage of struct rcar_du_format_info. I propose the
> following commit message:
>
> Use the %p4cc format specifier to print 4CCs, which will provide a more
> readable message than the raw hex value.
OK.
>
> > Reported-by: Geert Uytterhoeven
> > Signed-off-by: Biju Das
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > index 21881fb5e84a..8c2719efda2a 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > @@ -405,8 +405,8 @@ rcar_du_fb_create(struct drm_device *dev, struct
> > drm_file *file_priv,
> >
> > format = rcar_du_format_info(mode_cmd->pixel_format);
> > if (format == NULL) {
> > - dev_dbg(dev->dev, "unsupported pixel format %08x\n",
> > - mode_cmd->pixel_format);
> > + dev_dbg(dev->dev, "unsupported pixel format %p4cc\n",
> > + _cmd->pixel_format);
> > return ERR_PTR(-EINVAL);
> > }
> >
>
> There are two other occurrences:
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> index 26b25ca58968..83631ee2fff1 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -626,8 +626,8 @@ int __rcar_du_plane_atomic_check(struct drm_plane
> *plane,
>
> *format = rcar_du_format_info(state->fb->format->format);
> if (*format == NULL) {
> - dev_dbg(dev->dev, "%s: unsupported format %08x\n", __func__,
> - state->fb->format->format);
> + dev_dbg(dev->dev, "%s: unsupported format %p4cc\n",
> __func__,
> + >fb->format->format);
> return -EINVAL;
> }
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> index 25f50a297c11..8cd37d7b8ae2 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> @@ -166,8 +166,8 @@ static int rcar_du_wb_enc_atomic_check(struct
> drm_encoder *encoder,
>
> wb_state->format = rcar_du_format_info(fb->format->format);
> if (wb_state->format == NULL) {
> - dev_dbg(dev->dev, "%s: unsupported format %08x\n", __func__,
> - fb->format->format);
> + dev_dbg(dev->dev, "%s: unsupported format %p4cc\n",
> __func__,
> + >format->format);
> return -EINVAL;
> }
>
> I can add these changes to the patch and update the commit message when
> applying if you're fine with that. In that case,
I am ok with it.
Is it possible for you to share the git tree with latest RCar DU changes?
so that I can rebase RCar DU lib and RZ/G2L DU work on top of that.
Currently I am rebasing on top of drm_tip. Please let me know.
Thanks and regards,
Biju
>
> Reviewed-by: Laurent Pinchart
>
[PATCH] drm/panel: simple: Fix innolux_g121i1_l01 bus_format
From: Heiko Schocher
innolux_g121i1_l01 sets bpc to 6, so use the corresponding bus format:
MEDIA_BUS_FMT_RGB666_1X7X3_SPWG.
Fixes: 4ae13e486866 ("drm/panel: simple: Add more properties to Innolux
G121I1-L01")
Signed-off-by: Heiko Schocher
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index edd5a0c35437..0cb3be26e2e6 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2255,7 +2255,7 @@ static const struct panel_desc innolux_g121i1_l01 = {
.enable = 200,
.disable = 20,
},
- .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
--
2.25.1
