Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Peter Wu <peter@lekensteyn.nl>
To:     Gerd Hoffmann <kraxel@redhat.com>
Cc:     virtualization@lists.linux-foundation.org,
        dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        =?UTF-8?q?Noralf=20Tr=C3=B8nnes?= <noralf@tronnes.org>
Subject: [PATCH v2 0/4] bochs fixes and fb-helper documentation updates
Date:   Fri,  7 Sep 2018 00:18:06 +0200
Message-Id: <20180906221810.20170-1-peter@lekensteyn.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,

These series tries to improve the bochs driver and update documentation based on
my brief experience with the fb-helper API. Thank you Daniel and Gerd for your
previous feedback and helpful suggestions.

Patch 2 was previously posted and is unmodified except for acked-by + rebase on
drm-misc-next (9a09a42369a4a37a959c051d8e1a1f948c1529a4). Patch 1 is a trivial
(build) fix that was missing last time.

Patch 3 converts from the legacy API to the modern drm_dev_register approach.
This seems required for the "generic" fbdev API as suggested by Daniel, but as
bochs does not implement the required "gem_prime_vmap" function, the conversion
cannot be completed for now.

Patch 4 includes some documentation updates that would have helped me during
qxl/bochs development and a warning that made me realize that "a virtual address
and that can be mmap'ed" in the documentation referred to "gem_prime_vmap". It
is to my best of understanding, so please correct me if I am wrong.

Side note: I originally tried to fix the unbind/remove crash in QXL and then
turned to bochs as it seemed simpler to learn how to work on DRM drivers.
Hopefully I manage to eventually figure out how to fix QXL. QXL is a bit
strange, it advertises PRIME "support" but it only has stub functions (including
a stub gem_prime_vmap).

After my recent patch ("qxl: fix null-pointer crash during suspend") qxl can
suspend/resume in the normal situation, but doing anything (suspend or unload)
after unbinding just fails (suspend then fails with "failed to wait on release
23 after spincount 301", unload triggers a use-after-free according to KASAN).
On the other hand, bochs passes these tests:

    # 1. s/r with unbound console
    modprobe bochs_drm
    echo 0 > /sys/class/vtconsole/vtcon1/bind
    rtcwake -s 1 -m mem
    # 2. s/r in normal sitation
    echo 1 > /sys/class/vtconsole/vtcon1/bind
    rtcwake -s 1 -m mem
    # 3. unload module (and s/r for good measure)
    echo 0 > /sys/class/vtconsole/vtcon1/bind
    rmmod bochs_drm
    rtcwake -s 1 -m mem

Kind regards,
Peter

Peter Wu (4):
  bochs: use drm_fb_helper_set_suspend_unlocked in suspend/resume
  bochs: convert to drm_fb_helper_fbdev_setup/teardown
  bochs: convert to drm_dev_register
  drm/fb-helper: improve documentation and print warnings

 drivers/gpu/drm/bochs/bochs.h       | 21 ++------
 drivers/gpu/drm/bochs/bochs_drv.c   | 46 +++++++++++------
 drivers/gpu/drm/bochs/bochs_fbdev.c | 79 +++++++----------------------
 drivers/gpu/drm/bochs/bochs_hw.c    |  2 +-
 drivers/gpu/drm/bochs/bochs_kms.c   |  7 +--
 drivers/gpu/drm/bochs/bochs_mm.c    | 74 ---------------------------
 drivers/gpu/drm/drm_fb_helper.c     | 25 ++++++---
 7 files changed, 73 insertions(+), 181 deletions(-)

-- 
2.18.0