Message ID | 20230224180225.2477641-1-robdclark@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp1062668wrd; Fri, 24 Feb 2023 10:12:30 -0800 (PST) X-Google-Smtp-Source: AK7set/OqWTg7aXth4/lrzew/+F9Le6oystkeVyqERBcWsgYHobmIqHzHSwvERUzFNyPl+w44JWi X-Received: by 2002:a17:90b:4b12:b0:237:39b1:7c88 with SMTP id lx18-20020a17090b4b1200b0023739b17c88mr12101840pjb.35.1677262349690; Fri, 24 Feb 2023 10:12:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677262349; cv=none; d=google.com; s=arc-20160816; b=BJ/qrWSOySilxNNTyikx7BgKJqkMz2JECIJjBDFkyXAU9tbjWCg2q0gSymb5jifXr2 CyDnMi6wfXqaJeffFLDattxHghxzs02PDn02T5jeDFVthkK3gcg0fUTaAJSEx4LxlXOR Tc0WPiLZtRjfTqPBhe+OeptaTuyC5poYhN+34ZF23lkGbkec6QJbjPVfquzPDQqSUEUk xquwPMH4WAmycgMMNNLlI35CoFj6qoTfNRPFVDb7aRv/eZ2qVL22DaewIFzsKLuEodCV 7538QUXow30Wl9ryjW1bAdyjjsG9qhLpJt/MhekktdjCXE327IA1CIBDg6wDM3mRiAP8 7XiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=dIetUbx7EIF3EVZI4uWomKEyBANtRstOQ9q276wzqdo=; b=Qy+TfNpSLsy0eqXDBbQGlCHi6NhnL4KV81URV9TUaeRWyFkylswpH4Pro0mNZhIOuD O9Mt/uIX/bMfn9tC03G/oBVQCUpAQtj0QwHuU+RMsPShb8PFwoo1NvVyekLrgCmeOp2J cQet1Pt6l+JSr+zHGYtBmjIkdS5GsCqyKZ0jR6sAPKtFx5UFKNna8ExDwygTKgqrbd79 LeJ25zFwtr9aItEnaRsVTwegn272TH3eWkUgDuyqlg+In7jcKipvZhPIp768yL4tK5jo bH8VihUjCjCN+DoKF3MH5AN8TJSSn8c6HZqbfPr1K+kyp7xuV1+Ptly0X/nDcwqHm4x5 9U3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=MH6aam4w; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n15-20020a17090ade8f00b00230c06399e8si2927250pjv.89.2023.02.24.10.12.17; Fri, 24 Feb 2023 10:12:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=MH6aam4w; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229464AbjBXSCd (ORCPT <rfc822;jeff.pang.chn@gmail.com> + 99 others); Fri, 24 Feb 2023 13:02:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229576AbjBXSCc (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 24 Feb 2023 13:02:32 -0500 Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66295206BE for <linux-kernel@vger.kernel.org>; Fri, 24 Feb 2023 10:02:30 -0800 (PST) Received: by mail-pj1-x1036.google.com with SMTP id y2so12999752pjg.3 for <linux-kernel@vger.kernel.org>; Fri, 24 Feb 2023 10:02:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=dIetUbx7EIF3EVZI4uWomKEyBANtRstOQ9q276wzqdo=; b=MH6aam4wwxxCOP8F74s6Ll3IKPas17IyPHqfjrU5DRqREcp574aRJL7kZZuGLwFtVM 5qjwEkw++dNg3OMCh2Mtk6meGfZ10SKB8U9bSt0sReAXqCuRh6EfFKMsMx+c1OC4Pgon wyvgbEPrwlEVV0Ru6arZDsOe/vb+k7/8o0RqOFWHBPQbxxeg9MRI6yg0BjX8HvWZ4JI6 Vk8Tlb6Dr9bOk3jtTS3WAGohoRkn3p82EsApeWBwGCjmaO4fkDPz8AbSPi9uGOJTPktK Njh3v40YmDl2P0NXJLECxSCJKbMnE20Pcn+zoMIpaP3w9hWNsgQacWC49zFUwiIuY6Gn +Mdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dIetUbx7EIF3EVZI4uWomKEyBANtRstOQ9q276wzqdo=; b=s0YpC5G5OsaqaeAI0plWCeIHB0RjLt7puN0di1WW80by8ifoaoEvZGtPthott8e7Qr ByGUANdqQEHHNQ71zKZ5j/wyJEOs+xUkA0VKzxR9MpQY+uV8L03MD6/PuDmIvMf7qPMf 0pMeoy6WGNPQIIUWSW/knien5DWwjg7Wr/LZH2DvgQZR1MeNb0kVS9jvxPgGac8vxwtg lwOTClrHW8iV5+0OStMGfOpqsYt9EWrEj3CUwO5FJ3xRgZDxpFbF6l+s2Hx5g1Rhpz81 SlLhHtPRFODO+OI60a4JDi4GbG0JLnUAQKXk4nE6h4WxAcX3ZIPVPqJG8JCcXz1El1mu kktQ== X-Gm-Message-State: AO0yUKXf4M0bkqqy98QVDdDuiyH7ijzDb4CTJjOh3thnmxyEe9GU1m5J sphALosMV3Ev0nSZbTOYvOY= X-Received: by 2002:a17:902:ba83:b0:19c:be07:4af2 with SMTP id k3-20020a170902ba8300b0019cbe074af2mr4714336pls.45.1677261749322; Fri, 24 Feb 2023 10:02:29 -0800 (PST) Received: from localhost ([2a00:79e1:abd:4a00:61b:48ed:72ab:435b]) by smtp.gmail.com with ESMTPSA id h5-20020a170902704500b00198ff118fd3sm1108105plt.101.2023.02.24.10.02.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Feb 2023 10:02:28 -0800 (PST) From: Rob Clark <robdclark@gmail.com> To: dri-devel@lists.freedesktop.org Cc: Chia-I Wu <olvaffe@gmail.com>, Ryan Neph <ryanneph@chromium.org>, Dmitry Osipenko <dmitry.osipenko@collabora.com>, Rob Clark <robdclark@chromium.org>, David Airlie <airlied@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, Gurchetan Singh <gurchetansingh@chromium.org>, Daniel Vetter <daniel@ffwll.ch>, virtualization@lists.linux-foundation.org (open list:VIRTIO GPU DRIVER), linux-kernel@vger.kernel.org (open list) Subject: [PATCH] drm/virtio: Add option to disable KMS support Date: Fri, 24 Feb 2023 10:02:24 -0800 Message-Id: <20230224180225.2477641-1-robdclark@gmail.com> X-Mailer: git-send-email 2.39.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758737045317216149?= X-GMAIL-MSGID: =?utf-8?q?1758737045317216149?= |
Series |
drm/virtio: Add option to disable KMS support
|
|
Commit Message
Rob Clark
Feb. 24, 2023, 6:02 p.m. UTC
From: Rob Clark <robdclark@chromium.org> Add a build option to disable modesetting support. This is useful in cases where the guest only needs to use the GPU in a headless mode, or (such as in the CrOS usage) window surfaces are proxied to a host compositor. Signed-off-by: Rob Clark <robdclark@chromium.org> --- drivers/gpu/drm/virtio/Kconfig | 11 +++++++++++ drivers/gpu/drm/virtio/Makefile | 5 ++++- drivers/gpu/drm/virtio/virtgpu_drv.c | 6 +++++- drivers/gpu/drm/virtio/virtgpu_drv.h | 10 ++++++++++ drivers/gpu/drm/virtio/virtgpu_kms.c | 6 ++++++ 5 files changed, 36 insertions(+), 2 deletions(-)
Comments
On 2/24/23 21:02, Rob Clark wrote: > obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio-gpu.o > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c > index ae97b98750b6..9cb7d6dd3da6 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c > @@ -172,7 +172,11 @@ MODULE_AUTHOR("Alon Levy"); > DEFINE_DRM_GEM_FOPS(virtio_gpu_driver_fops); > > static const struct drm_driver driver = { > - .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_RENDER | DRIVER_ATOMIC, > + .driver_features = > +#if defined(CONFIG_DRM_VIRTIO_GPU_KMS) Could you please replace s/defined/IS_ENABLED/ and also the #ifdefs with "if (IS_ENABLED(CONFIG_DRM_VIRTIO_GPU_KMS))" in the code? The ifdefs are always not nice to have in the code. The IS_ENABLED usage will also make code compile-tested regardless of the CONFIG_DRM_VIRTIO_GPU_KMS option state. Otherwise looks good!
On Fri, Feb 24, 2023 at 10:02:24AM -0800, Rob Clark wrote: > From: Rob Clark <robdclark@chromium.org> > > Add a build option to disable modesetting support. This is useful in > cases where the guest only needs to use the GPU in a headless mode, or > (such as in the CrOS usage) window surfaces are proxied to a host > compositor. Why make that a compile time option? There is a config option for the number of scanouts (aka virtual displays) a device has. Just set that to zero (and fix the driver to not consider that configuration an error). take care, Gerd
On Sun, Feb 26, 2023 at 10:38 PM Gerd Hoffmann <kraxel@redhat.com> wrote: > > On Fri, Feb 24, 2023 at 10:02:24AM -0800, Rob Clark wrote: > > From: Rob Clark <robdclark@chromium.org> > > > > Add a build option to disable modesetting support. This is useful in > > cases where the guest only needs to use the GPU in a headless mode, or > > (such as in the CrOS usage) window surfaces are proxied to a host > > compositor. > > Why make that a compile time option? There is a config option for the > number of scanouts (aka virtual displays) a device has. Just set that > to zero (and fix the driver to not consider that configuration an > error). The goal is to not advertise DRIVER_MODESET (and DRIVER_ATOMIC).. I guess that could be done based on whether there are any scanouts, but it would mean making the drm_driver struct non-const. And I think it is legitimate to allow the guest to make this choice, regardless of what the host decides to expose, since it is about the ioctl surface area that the guest kernel exposes to guest userspace. BR, -R
On Mon, Feb 27, 2023 at 07:40:11AM -0800, Rob Clark wrote: > On Sun, Feb 26, 2023 at 10:38 PM Gerd Hoffmann <kraxel@redhat.com> wrote: > > > > On Fri, Feb 24, 2023 at 10:02:24AM -0800, Rob Clark wrote: > > > From: Rob Clark <robdclark@chromium.org> > > > > > > Add a build option to disable modesetting support. This is useful in > > > cases where the guest only needs to use the GPU in a headless mode, or > > > (such as in the CrOS usage) window surfaces are proxied to a host > > > compositor. > > > > Why make that a compile time option? There is a config option for the > > number of scanouts (aka virtual displays) a device has. Just set that > > to zero (and fix the driver to not consider that configuration an > > error). > > The goal is to not advertise DRIVER_MODESET (and DRIVER_ATOMIC).. I > guess that could be done based on whether there are any scanouts, but > it would mean making the drm_driver struct non-const. dev.driver_features is a thing.
On Mon, Feb 27, 2023 at 07:40:11AM -0800, Rob Clark wrote: > On Sun, Feb 26, 2023 at 10:38 PM Gerd Hoffmann <kraxel@redhat.com> wrote: > > > > On Fri, Feb 24, 2023 at 10:02:24AM -0800, Rob Clark wrote: > > > From: Rob Clark <robdclark@chromium.org> > > > > > > Add a build option to disable modesetting support. This is useful in > > > cases where the guest only needs to use the GPU in a headless mode, or > > > (such as in the CrOS usage) window surfaces are proxied to a host > > > compositor. > > > > Why make that a compile time option? There is a config option for the > > number of scanouts (aka virtual displays) a device has. Just set that > > to zero (and fix the driver to not consider that configuration an > > error). > > The goal is to not advertise DRIVER_MODESET (and DRIVER_ATOMIC).. I > guess that could be done based on whether there are any scanouts, but > it would mean making the drm_driver struct non-const. Apparently there is a drm_device->driver_features override, (amdgpu uses that). The driver could simply drop the DRIVER_MODESET and DRIVER_ATOMIC bits in case no scanout is present instead of throwing an error. > And I think it is legitimate to allow the guest to make this choice, > regardless of what the host decides to expose, since it is about the > ioctl surface area that the guest kernel exposes to guest userspace. I think it is a bad idea to make that a compile time option, I'd suggest a runtime switch instead, for example a module parameter to ask the driver to ignore any scanouts. take care, Gerd
Gerd Hoffmann <kraxel@redhat.com> writes: Hello Gerd, > On Mon, Feb 27, 2023 at 07:40:11AM -0800, Rob Clark wrote: >> On Sun, Feb 26, 2023 at 10:38 PM Gerd Hoffmann <kraxel@redhat.com> wrote: >> > >> > On Fri, Feb 24, 2023 at 10:02:24AM -0800, Rob Clark wrote: >> > > From: Rob Clark <robdclark@chromium.org> >> > > >> > > Add a build option to disable modesetting support. This is useful in >> > > cases where the guest only needs to use the GPU in a headless mode, or >> > > (such as in the CrOS usage) window surfaces are proxied to a host >> > > compositor. >> > >> > Why make that a compile time option? There is a config option for the >> > number of scanouts (aka virtual displays) a device has. Just set that >> > to zero (and fix the driver to not consider that configuration an >> > error). >> >> The goal is to not advertise DRIVER_MODESET (and DRIVER_ATOMIC).. I >> guess that could be done based on whether there are any scanouts, but >> it would mean making the drm_driver struct non-const. > > Apparently there is a drm_device->driver_features override, > (amdgpu uses that). The driver could simply drop the DRIVER_MODESET and > DRIVER_ATOMIC bits in case no scanout is present instead of throwing an > error. > >> And I think it is legitimate to allow the guest to make this choice, >> regardless of what the host decides to expose, since it is about the >> ioctl surface area that the guest kernel exposes to guest userspace. > > I think it is a bad idea to make that a compile time option, I'd suggest > a runtime switch instead, for example a module parameter to ask the > driver to ignore any scanouts. > I don't think there's a need for a new module parameter, there's already the virtio-gpu 'modeset' module parameter to enable/disable modsetting and the global 'nomodeset' kernel cmdline parameter to do it for all DRM drivers. Currently, many drivers just fail to probe when 'nomodeset' is present, but others only disable modsetting but keep the rendering part. In fact, most DRM only drivers just ignore the 'nomodeset' parameter. We could make virtio-gpu driver to only disable KMS with these params, something like the following (untested) patch: From 9cddee7f696f37c34d80d6160e87827f3d7a0237 Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas <javierm@redhat.com> Date: Tue, 28 Feb 2023 10:09:11 +0100 Subject: [PATCH] drm/virtio: Only disable KMS with nomodeset The virtio-gpu driver currently fails to probe if either the "nomodeset" kernel cmdline parameter is used or the module "modeset" parameter used. But there may be cases where the rendering part of the driver is needed and only the mode setting part needs to be disabled. So let's change the logic to only disable the KMS part but still keep the DRM side of it. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> --- drivers/gpu/drm/virtio/virtgpu_display.c | 16 +++++++++++++++ drivers/gpu/drm/virtio/virtgpu_drv.c | 23 ++++++++++++++-------- drivers/gpu/drm/virtio/virtgpu_kms.c | 25 +----------------------- 3 files changed, 32 insertions(+), 32 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c index 9ea7611a9e0f..e176e5e8c1a0 100644 --- a/drivers/gpu/drm/virtio/virtgpu_display.c +++ b/drivers/gpu/drm/virtio/virtgpu_display.c @@ -335,6 +335,22 @@ static const struct drm_mode_config_funcs virtio_gpu_mode_funcs = { int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev) { int i, ret; + u32 num_scanouts; + + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_EDID)) { + vgdev->has_edid = true; + } + + /* get display info */ + virtio_cread_le(vgdev->vdev, struct virtio_gpu_config, + num_scanouts, &num_scanouts); + vgdev->num_scanouts = min_t(uint32_t, num_scanouts, + VIRTIO_GPU_MAX_SCANOUTS); + if (!vgdev->num_scanouts) { + DRM_ERROR("num_scanouts is zero\n"); + return -EINVAL; + } + DRM_INFO("number of scanouts: %d\n", num_scanouts); ret = drmm_mode_config_init(vgdev->ddev); if (ret) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c index ae97b98750b6..979b5b177f49 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.c +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c @@ -40,7 +40,7 @@ #include "virtgpu_drv.h" -static const struct drm_driver driver; +static struct drm_driver driver; static int virtio_gpu_modeset = -1; @@ -69,13 +69,12 @@ static int virtio_gpu_pci_quirk(struct drm_device *dev) static int virtio_gpu_probe(struct virtio_device *vdev) { struct drm_device *dev; + struct virtio_gpu_device *vgdev; int ret; - if (drm_firmware_drivers_only() && virtio_gpu_modeset == -1) - return -EINVAL; - - if (virtio_gpu_modeset == 0) - return -EINVAL; + if ((drm_firmware_drivers_only() && virtio_gpu_modeset == -1) || + (virtio_gpu_modeset == 0)) + driver.driver_features &= ~(DRIVER_MODESET | DRIVER_ATOMIC); /* * The virtio-gpu device is a virtual device that doesn't have DMA @@ -98,11 +97,19 @@ static int virtio_gpu_probe(struct virtio_device *vdev) if (ret) goto err_free; + if (drm_core_check_feature(dev, DRIVER_MODESET)) { + vgdev = dev->dev_private; + ret = virtio_gpu_modeset_init(vgdev); + if (ret) + goto err_deinit; + } + ret = drm_dev_register(dev, 0); if (ret) goto err_deinit; - drm_fbdev_generic_setup(vdev->priv, 32); + if (drm_core_check_feature(dev, DRIVER_MODESET)) + drm_fbdev_generic_setup(vdev->priv, 32); return 0; err_deinit: @@ -171,7 +178,7 @@ MODULE_AUTHOR("Alon Levy"); DEFINE_DRM_GEM_FOPS(virtio_gpu_driver_fops); -static const struct drm_driver driver = { +static struct drm_driver driver = { .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_RENDER | DRIVER_ATOMIC, .open = virtio_gpu_driver_open, .postclose = virtio_gpu_driver_postclose, diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index 27b7f14dae89..2f5f2aac6b71 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -122,7 +122,7 @@ int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev) struct virtio_gpu_device *vgdev; /* this will expand later */ struct virtqueue *vqs[2]; - u32 num_scanouts, num_capsets; + u32 num_capsets; int ret = 0; if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) @@ -161,9 +161,6 @@ int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev) if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_VIRGL)) vgdev->has_virgl_3d = true; #endif - if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_EDID)) { - vgdev->has_edid = true; - } if (virtio_has_feature(vgdev->vdev, VIRTIO_RING_F_INDIRECT_DESC)) { vgdev->has_indirect = true; } @@ -218,28 +215,10 @@ int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev) goto err_vbufs; } - /* get display info */ - virtio_cread_le(vgdev->vdev, struct virtio_gpu_config, - num_scanouts, &num_scanouts); - vgdev->num_scanouts = min_t(uint32_t, num_scanouts, - VIRTIO_GPU_MAX_SCANOUTS); - if (!vgdev->num_scanouts) { - DRM_ERROR("num_scanouts is zero\n"); - ret = -EINVAL; - goto err_scanouts; - } - DRM_INFO("number of scanouts: %d\n", num_scanouts); - virtio_cread_le(vgdev->vdev, struct virtio_gpu_config, num_capsets, &num_capsets); DRM_INFO("number of cap sets: %d\n", num_capsets); - ret = virtio_gpu_modeset_init(vgdev); - if (ret) { - DRM_ERROR("modeset init failed\n"); - goto err_scanouts; - } - virtio_device_ready(vgdev->vdev); if (num_capsets) @@ -252,8 +231,6 @@ int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev) 5 * HZ); return 0; -err_scanouts: - virtio_gpu_free_vbufs(vgdev); err_vbufs: vgdev->vdev->config->del_vqs(vgdev->vdev); err_vqs:
On 2/28/23 12:19, Javier Martinez Canillas wrote: > Gerd Hoffmann <kraxel@redhat.com> writes: > > Hello Gerd, > >> On Mon, Feb 27, 2023 at 07:40:11AM -0800, Rob Clark wrote: >>> On Sun, Feb 26, 2023 at 10:38 PM Gerd Hoffmann <kraxel@redhat.com> wrote: >>>> On Fri, Feb 24, 2023 at 10:02:24AM -0800, Rob Clark wrote: >>>>> From: Rob Clark <robdclark@chromium.org> >>>>> >>>>> Add a build option to disable modesetting support. This is useful in >>>>> cases where the guest only needs to use the GPU in a headless mode, or >>>>> (such as in the CrOS usage) window surfaces are proxied to a host >>>>> compositor. >>>> Why make that a compile time option? There is a config option for the >>>> number of scanouts (aka virtual displays) a device has. Just set that >>>> to zero (and fix the driver to not consider that configuration an >>>> error). >>> The goal is to not advertise DRIVER_MODESET (and DRIVER_ATOMIC).. I >>> guess that could be done based on whether there are any scanouts, but >>> it would mean making the drm_driver struct non-const. >> Apparently there is a drm_device->driver_features override, >> (amdgpu uses that). The driver could simply drop the DRIVER_MODESET and >> DRIVER_ATOMIC bits in case no scanout is present instead of throwing an >> error. >> >>> And I think it is legitimate to allow the guest to make this choice, >>> regardless of what the host decides to expose, since it is about the >>> ioctl surface area that the guest kernel exposes to guest userspace. >> I think it is a bad idea to make that a compile time option, I'd suggest >> a runtime switch instead, for example a module parameter to ask the >> driver to ignore any scanouts. >> > I don't think there's a need for a new module parameter, there's already > the virtio-gpu 'modeset' module parameter to enable/disable modsetting > and the global 'nomodeset' kernel cmdline parameter to do it for all DRM > drivers. > > Currently, many drivers just fail to probe when 'nomodeset' is present, > but others only disable modsetting but keep the rendering part. In fact, > most DRM only drivers just ignore the 'nomodeset' parameter. IIUC, Rob's main point for having a config option is solely for security reasons. The config option eliminates possibility of accidentally (or intentionally) enabling KMS from software, which is better to have in case of shipping a product (Chromebook) on which multiple teams are working on.
Hi Am 28.02.23 um 10:19 schrieb Javier Martinez Canillas: > Gerd Hoffmann <kraxel@redhat.com> writes: [...] >> >> I think it is a bad idea to make that a compile time option, I'd suggest >> a runtime switch instead, for example a module parameter to ask the >> driver to ignore any scanouts. >> > > I don't think there's a need for a new module parameter, there's already > the virtio-gpu 'modeset' module parameter to enable/disable modsetting > and the global 'nomodeset' kernel cmdline parameter to do it for all DRM > drivers. > > Currently, many drivers just fail to probe when 'nomodeset' is present, > but others only disable modsetting but keep the rendering part. In fact, > most DRM only drivers just ignore the 'nomodeset' parameter. Do you have a list of these drivers? Maybe we need to adjust semantics slightly. Please see my comment below. > We could make virtio-gpu driver to only disable KMS with these params, > something like the following (untested) patch: > > From 9cddee7f696f37c34d80d6160e87827f3d7a0237 Mon Sep 17 00:00:00 2001 > From: Javier Martinez Canillas <javierm@redhat.com> > Date: Tue, 28 Feb 2023 10:09:11 +0100 > Subject: [PATCH] drm/virtio: Only disable KMS with nomodeset > > The virtio-gpu driver currently fails to probe if either the "nomodeset" > kernel cmdline parameter is used or the module "modeset" parameter used. > > But there may be cases where the rendering part of the driver is needed > and only the mode setting part needs to be disabled. So let's change the > logic to only disable the KMS part but still keep the DRM side of it. > > Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> > --- > drivers/gpu/drm/virtio/virtgpu_display.c | 16 +++++++++++++++ > drivers/gpu/drm/virtio/virtgpu_drv.c | 23 ++++++++++++++-------- > drivers/gpu/drm/virtio/virtgpu_kms.c | 25 +----------------------- > 3 files changed, 32 insertions(+), 32 deletions(-) > > diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c > index 9ea7611a9e0f..e176e5e8c1a0 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_display.c > +++ b/drivers/gpu/drm/virtio/virtgpu_display.c > @@ -335,6 +335,22 @@ static const struct drm_mode_config_funcs virtio_gpu_mode_funcs = { > int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev) > { > int i, ret; > + u32 num_scanouts; > + > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_EDID)) { > + vgdev->has_edid = true; > + } > + > + /* get display info */ > + virtio_cread_le(vgdev->vdev, struct virtio_gpu_config, > + num_scanouts, &num_scanouts); > + vgdev->num_scanouts = min_t(uint32_t, num_scanouts, > + VIRTIO_GPU_MAX_SCANOUTS); > + if (!vgdev->num_scanouts) { > + DRM_ERROR("num_scanouts is zero\n"); > + return -EINVAL; > + } > + DRM_INFO("number of scanouts: %d\n", num_scanouts); > > ret = drmm_mode_config_init(vgdev->ddev); > if (ret) > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c > index ae97b98750b6..979b5b177f49 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c > @@ -40,7 +40,7 @@ > > #include "virtgpu_drv.h" > > -static const struct drm_driver driver; > +static struct drm_driver driver; > > static int virtio_gpu_modeset = -1; > > @@ -69,13 +69,12 @@ static int virtio_gpu_pci_quirk(struct drm_device *dev) > static int virtio_gpu_probe(struct virtio_device *vdev) > { > struct drm_device *dev; > + struct virtio_gpu_device *vgdev; > int ret; > > - if (drm_firmware_drivers_only() && virtio_gpu_modeset == -1) > - return -EINVAL; > - > - if (virtio_gpu_modeset == 0) > - return -EINVAL; > + if ((drm_firmware_drivers_only() && virtio_gpu_modeset == -1) || > + (virtio_gpu_modeset == 0)) > + driver.driver_features &= ~(DRIVER_MODESET | DRIVER_ATOMIC); The kernel-wide option 'nomodeset' affects system behavior. It's a misnomer, as it actually means 'don't replace the firmware-provided framebuffer.' So if you just set these flags here, virtio-gpu would later remove the firmware driver via aperture helpers. Therefore, if drm_formware_drivers_only() returns true, we should fail probing with -ENODEV. But we could try to repurpose the module's 'modeset' option. It's already obsoleted by nomodeset anyway. I'd try to make modeset it a boolean that controls modesetting vs render-only. It will then be about the driver's feature set, rather than system behavior. Best regards Thomas > > /* > * The virtio-gpu device is a virtual device that doesn't have DMA > @@ -98,11 +97,19 @@ static int virtio_gpu_probe(struct virtio_device *vdev) > if (ret) > goto err_free; > > + if (drm_core_check_feature(dev, DRIVER_MODESET)) { > + vgdev = dev->dev_private; > + ret = virtio_gpu_modeset_init(vgdev); > + if (ret) > + goto err_deinit; > + } > + > ret = drm_dev_register(dev, 0); > if (ret) > goto err_deinit; > > - drm_fbdev_generic_setup(vdev->priv, 32); > + if (drm_core_check_feature(dev, DRIVER_MODESET)) > + drm_fbdev_generic_setup(vdev->priv, 32); > return 0; > > err_deinit: > @@ -171,7 +178,7 @@ MODULE_AUTHOR("Alon Levy"); > > DEFINE_DRM_GEM_FOPS(virtio_gpu_driver_fops); > > -static const struct drm_driver driver = { > +static struct drm_driver driver = { > .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_RENDER | DRIVER_ATOMIC, > .open = virtio_gpu_driver_open, > .postclose = virtio_gpu_driver_postclose, > diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c > index 27b7f14dae89..2f5f2aac6b71 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_kms.c > +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c > @@ -122,7 +122,7 @@ int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev) > struct virtio_gpu_device *vgdev; > /* this will expand later */ > struct virtqueue *vqs[2]; > - u32 num_scanouts, num_capsets; > + u32 num_capsets; > int ret = 0; > > if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) > @@ -161,9 +161,6 @@ int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev) > if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_VIRGL)) > vgdev->has_virgl_3d = true; > #endif > - if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_EDID)) { > - vgdev->has_edid = true; > - } > if (virtio_has_feature(vgdev->vdev, VIRTIO_RING_F_INDIRECT_DESC)) { > vgdev->has_indirect = true; > } > @@ -218,28 +215,10 @@ int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev) > goto err_vbufs; > } > > - /* get display info */ > - virtio_cread_le(vgdev->vdev, struct virtio_gpu_config, > - num_scanouts, &num_scanouts); > - vgdev->num_scanouts = min_t(uint32_t, num_scanouts, > - VIRTIO_GPU_MAX_SCANOUTS); > - if (!vgdev->num_scanouts) { > - DRM_ERROR("num_scanouts is zero\n"); > - ret = -EINVAL; > - goto err_scanouts; > - } > - DRM_INFO("number of scanouts: %d\n", num_scanouts); > - > virtio_cread_le(vgdev->vdev, struct virtio_gpu_config, > num_capsets, &num_capsets); > DRM_INFO("number of cap sets: %d\n", num_capsets); > > - ret = virtio_gpu_modeset_init(vgdev); > - if (ret) { > - DRM_ERROR("modeset init failed\n"); > - goto err_scanouts; > - } > - > virtio_device_ready(vgdev->vdev); > > if (num_capsets) > @@ -252,8 +231,6 @@ int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev) > 5 * HZ); > return 0; > > -err_scanouts: > - virtio_gpu_free_vbufs(vgdev); > err_vbufs: > vgdev->vdev->config->del_vqs(vgdev->vdev); > err_vqs: -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
Thomas Zimmermann <tzimmermann@suse.de> writes: > Hi > > Am 28.02.23 um 10:19 schrieb Javier Martinez Canillas: >> Gerd Hoffmann <kraxel@redhat.com> writes: > [...] >>> >>> I think it is a bad idea to make that a compile time option, I'd suggest >>> a runtime switch instead, for example a module parameter to ask the >>> driver to ignore any scanouts. >>> >> >> I don't think there's a need for a new module parameter, there's already >> the virtio-gpu 'modeset' module parameter to enable/disable modsetting >> and the global 'nomodeset' kernel cmdline parameter to do it for all DRM >> drivers. >> >> Currently, many drivers just fail to probe when 'nomodeset' is present, >> but others only disable modsetting but keep the rendering part. In fact, >> most DRM only drivers just ignore the 'nomodeset' parameter. > > Do you have a list of these drivers? Maybe we need to adjust semantics > slightly. Please see my comment below. > AFAIK i915 and nouveau do this. But also on the rpi4 only the vc4 display driver is disabled but the v3d driver used for rendering is not disabled. So the 'nomodeset' semantics are not consistent across all DRM drivers. [...] >> - if (virtio_gpu_modeset == 0) >> - return -EINVAL; >> + if ((drm_firmware_drivers_only() && virtio_gpu_modeset == -1) || >> + (virtio_gpu_modeset == 0)) >> + driver.driver_features &= ~(DRIVER_MODESET | DRIVER_ATOMIC); > > The kernel-wide option 'nomodeset' affects system behavior. It's a > misnomer, as it actually means 'don't replace the firmware-provided > framebuffer.' So if you just set these flags here, virtio-gpu would > later remove the firmware driver via aperture helpers. Therefore, if > drm_formware_drivers_only() returns true, we should fail probing with > -ENODEV. > Right. Or the DRM aperture helper shouldn't attempt to remove the firmware provided framebuffer if the DRM driver doesn't have the DRIVER_MODESET set. > But we could try to repurpose the module's 'modeset' option. It's > already obsoleted by nomodeset anyway. I'd try to make modeset it a > boolean that controls modesetting vs render-only. It will then be about > the driver's feature set, rather than system behavior. > Yes, that could work too. Dmitry mentioned that Rob wanted the compile-time option to reduce the attack surface area. I don't have a strong opinion on this, but just wanted to point out that there wasn't a need for a new param and that the existing module's 'modeset' could be repurposed for this case.
Hi Am 24.02.23 um 19:02 schrieb Rob Clark: > From: Rob Clark <robdclark@chromium.org> > > Add a build option to disable modesetting support. This is useful in > cases where the guest only needs to use the GPU in a headless mode, or > (such as in the CrOS usage) window surfaces are proxied to a host > compositor. We've just been discussing this on IRC, but failed to see the practical benefit. It's not like the modesetting code takes up lots of memory. What's the real-world use case? Best regards Thomas > > Signed-off-by: Rob Clark <robdclark@chromium.org> > --- > drivers/gpu/drm/virtio/Kconfig | 11 +++++++++++ > drivers/gpu/drm/virtio/Makefile | 5 ++++- > drivers/gpu/drm/virtio/virtgpu_drv.c | 6 +++++- > drivers/gpu/drm/virtio/virtgpu_drv.h | 10 ++++++++++ > drivers/gpu/drm/virtio/virtgpu_kms.c | 6 ++++++ > 5 files changed, 36 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig > index 51ec7c3240c9..ea06ff2aa4b4 100644 > --- a/drivers/gpu/drm/virtio/Kconfig > +++ b/drivers/gpu/drm/virtio/Kconfig > @@ -11,3 +11,14 @@ config DRM_VIRTIO_GPU > QEMU based VMMs (like KVM or Xen). > > If unsure say M. > + > +config DRM_VIRTIO_GPU_KMS > + bool "Virtio GPU driver modesetting support" > + depends on DRM_VIRTIO_GPU > + default y > + help > + Enable modesetting support for virtio GPU driver. This can be > + disabled in cases where only "headless" usage of the GPU is > + required. > + > + If unsure, say Y. > diff --git a/drivers/gpu/drm/virtio/Makefile b/drivers/gpu/drm/virtio/Makefile > index b99fa4a73b68..24c7ebe87032 100644 > --- a/drivers/gpu/drm/virtio/Makefile > +++ b/drivers/gpu/drm/virtio/Makefile > @@ -4,8 +4,11 @@ > # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. > > virtio-gpu-y := virtgpu_drv.o virtgpu_kms.o virtgpu_gem.o virtgpu_vram.o \ > - virtgpu_display.o virtgpu_vq.o \ > + virtgpu_vq.o \ > virtgpu_fence.o virtgpu_object.o virtgpu_debugfs.o virtgpu_plane.o \ > virtgpu_ioctl.o virtgpu_prime.o virtgpu_trace_points.o > > +virtio-gpu-$(CONFIG_DRM_VIRTIO_GPU_KMS) += \ > + virtgpu_display.o > + > obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio-gpu.o > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c > index ae97b98750b6..9cb7d6dd3da6 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c > @@ -172,7 +172,11 @@ MODULE_AUTHOR("Alon Levy"); > DEFINE_DRM_GEM_FOPS(virtio_gpu_driver_fops); > > static const struct drm_driver driver = { > - .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_RENDER | DRIVER_ATOMIC, > + .driver_features = > +#if defined(CONFIG_DRM_VIRTIO_GPU_KMS) > + DRIVER_MODESET | DRIVER_ATOMIC | > +#endif > + DRIVER_GEM | DRIVER_RENDER, > .open = virtio_gpu_driver_open, > .postclose = virtio_gpu_driver_postclose, > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h > index af6ffb696086..ffe8faf67247 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h > @@ -426,8 +426,18 @@ virtio_gpu_cmd_set_scanout_blob(struct virtio_gpu_device *vgdev, > uint32_t x, uint32_t y); > > /* virtgpu_display.c */ > +#if defined(CONFIG_DRM_VIRTIO_GPU_KMS) > int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev); > void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev); > +#else > +static inline int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev) > +{ > + return 0; > +} > +static inline void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev) > +{ > +} > +#endif > > /* virtgpu_plane.c */ > uint32_t virtio_gpu_translate_format(uint32_t drm_fourcc); > diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c > index 27b7f14dae89..293e6f0bf133 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_kms.c > +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c > @@ -161,9 +161,11 @@ int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev) > if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_VIRGL)) > vgdev->has_virgl_3d = true; > #endif > +#if defined(CONFIG_DRM_VIRTIO_GPU_KMS) > if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_EDID)) { > vgdev->has_edid = true; > } > +#endif > if (virtio_has_feature(vgdev->vdev, VIRTIO_RING_F_INDIRECT_DESC)) { > vgdev->has_indirect = true; > } > @@ -218,6 +220,7 @@ int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev) > goto err_vbufs; > } > > +#if defined(CONFIG_DRM_VIRTIO_GPU_KMS) > /* get display info */ > virtio_cread_le(vgdev->vdev, struct virtio_gpu_config, > num_scanouts, &num_scanouts); > @@ -229,6 +232,7 @@ int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev) > goto err_scanouts; > } > DRM_INFO("number of scanouts: %d\n", num_scanouts); > +#endif > > virtio_cread_le(vgdev->vdev, struct virtio_gpu_config, > num_capsets, &num_capsets); > @@ -246,10 +250,12 @@ int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev) > virtio_gpu_get_capsets(vgdev, num_capsets); > if (vgdev->has_edid) > virtio_gpu_cmd_get_edids(vgdev); > +#if defined(CONFIG_DRM_VIRTIO_GPU_KMS) > virtio_gpu_cmd_get_display_info(vgdev); > virtio_gpu_notify(vgdev); > wait_event_timeout(vgdev->resp_wq, !vgdev->display_info_pending, > 5 * HZ); > +#endif > return 0; > > err_scanouts: -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig index 51ec7c3240c9..ea06ff2aa4b4 100644 --- a/drivers/gpu/drm/virtio/Kconfig +++ b/drivers/gpu/drm/virtio/Kconfig @@ -11,3 +11,14 @@ config DRM_VIRTIO_GPU QEMU based VMMs (like KVM or Xen). If unsure say M. + +config DRM_VIRTIO_GPU_KMS + bool "Virtio GPU driver modesetting support" + depends on DRM_VIRTIO_GPU + default y + help + Enable modesetting support for virtio GPU driver. This can be + disabled in cases where only "headless" usage of the GPU is + required. + + If unsure, say Y. diff --git a/drivers/gpu/drm/virtio/Makefile b/drivers/gpu/drm/virtio/Makefile index b99fa4a73b68..24c7ebe87032 100644 --- a/drivers/gpu/drm/virtio/Makefile +++ b/drivers/gpu/drm/virtio/Makefile @@ -4,8 +4,11 @@ # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. virtio-gpu-y := virtgpu_drv.o virtgpu_kms.o virtgpu_gem.o virtgpu_vram.o \ - virtgpu_display.o virtgpu_vq.o \ + virtgpu_vq.o \ virtgpu_fence.o virtgpu_object.o virtgpu_debugfs.o virtgpu_plane.o \ virtgpu_ioctl.o virtgpu_prime.o virtgpu_trace_points.o +virtio-gpu-$(CONFIG_DRM_VIRTIO_GPU_KMS) += \ + virtgpu_display.o + obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio-gpu.o diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c index ae97b98750b6..9cb7d6dd3da6 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.c +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c @@ -172,7 +172,11 @@ MODULE_AUTHOR("Alon Levy"); DEFINE_DRM_GEM_FOPS(virtio_gpu_driver_fops); static const struct drm_driver driver = { - .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_RENDER | DRIVER_ATOMIC, + .driver_features = +#if defined(CONFIG_DRM_VIRTIO_GPU_KMS) + DRIVER_MODESET | DRIVER_ATOMIC | +#endif + DRIVER_GEM | DRIVER_RENDER, .open = virtio_gpu_driver_open, .postclose = virtio_gpu_driver_postclose, diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index af6ffb696086..ffe8faf67247 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -426,8 +426,18 @@ virtio_gpu_cmd_set_scanout_blob(struct virtio_gpu_device *vgdev, uint32_t x, uint32_t y); /* virtgpu_display.c */ +#if defined(CONFIG_DRM_VIRTIO_GPU_KMS) int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev); void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev); +#else +static inline int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev) +{ + return 0; +} +static inline void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev) +{ +} +#endif /* virtgpu_plane.c */ uint32_t virtio_gpu_translate_format(uint32_t drm_fourcc); diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index 27b7f14dae89..293e6f0bf133 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -161,9 +161,11 @@ int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev) if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_VIRGL)) vgdev->has_virgl_3d = true; #endif +#if defined(CONFIG_DRM_VIRTIO_GPU_KMS) if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_EDID)) { vgdev->has_edid = true; } +#endif if (virtio_has_feature(vgdev->vdev, VIRTIO_RING_F_INDIRECT_DESC)) { vgdev->has_indirect = true; } @@ -218,6 +220,7 @@ int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev) goto err_vbufs; } +#if defined(CONFIG_DRM_VIRTIO_GPU_KMS) /* get display info */ virtio_cread_le(vgdev->vdev, struct virtio_gpu_config, num_scanouts, &num_scanouts); @@ -229,6 +232,7 @@ int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev) goto err_scanouts; } DRM_INFO("number of scanouts: %d\n", num_scanouts); +#endif virtio_cread_le(vgdev->vdev, struct virtio_gpu_config, num_capsets, &num_capsets); @@ -246,10 +250,12 @@ int virtio_gpu_init(struct virtio_device *vdev, struct drm_device *dev) virtio_gpu_get_capsets(vgdev, num_capsets); if (vgdev->has_edid) virtio_gpu_cmd_get_edids(vgdev); +#if defined(CONFIG_DRM_VIRTIO_GPU_KMS) virtio_gpu_cmd_get_display_info(vgdev); virtio_gpu_notify(vgdev); wait_event_timeout(vgdev->resp_wq, !vgdev->display_info_pending, 5 * HZ); +#endif return 0; err_scanouts: