The QEMU model for the Bochs display has no VGA memory section at offset
0x400 [1]. By writing to this register Linux can create a write to
unassigned memory which depending on machine and architecture can result
in a store fault.
I don't see any reference to this address at OSDev [2] or in the Bochs
source code.
Removing this write still allows graphics to work inside QEMU with
the bochs-display.
1: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/bochs-display…
2. https://…
[View More]wiki.osdev.org/Bochs_VBE_Extensions
Reported-by: Khem Raj <raj.khem(a)gmail.com>
Signed-off-by: Alistair Francis <alistair.francis(a)wdc.com>
---
drivers/gpu/drm/bochs/bochs_hw.c | 15 ---------------
1 file changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index b615b7dfdd9d..dfb2a5363c62 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -10,19 +10,6 @@
/* ---------------------------------------------------------------------- */
-static void bochs_vga_writeb(struct bochs_device *bochs, u16 ioport, u8 val)
-{
- if (WARN_ON(ioport < 0x3c0 || ioport > 0x3df))
- return;
-
- if (bochs->mmio) {
- int offset = ioport - 0x3c0 + 0x400;
- writeb(val, bochs->mmio + offset);
- } else {
- outb(val, ioport);
- }
-}
-
static u16 bochs_dispi_read(struct bochs_device *bochs, u16 reg)
{
u16 ret = 0;
@@ -217,8 +204,6 @@ void bochs_hw_setmode(struct bochs_device *bochs,
bochs->xres, bochs->yres, bochs->bpp,
bochs->yres_virtual);
- bochs_vga_writeb(bochs, 0x3c0, 0x20); /* unblank */
-
bochs_dispi_write(bochs, VBE_DISPI_INDEX_ENABLE, 0);
bochs_dispi_write(bochs, VBE_DISPI_INDEX_BPP, bochs->bpp);
bochs_dispi_write(bochs, VBE_DISPI_INDEX_XRES, bochs->xres);
--
2.25.0
[View Less]
Unfortunately, it turned out that the DPCD is also not a reliable way of
probing for DPCD backlight support as some panels will lie and say they
have DPCD backlight controls when they don't actually.
So, revert back to the old behavior and add a bunch of EDID-based DP
quirks for the panels that we know need this. As you might have already
guessed, OUI quirks didn't seem to be a very safe bet for these panels
due to them not having their device IDs filled out.
Lyude Paul (3):
drm/dp: …
[View More]Introduce EDID-based quirks
drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED
panel
drm/i915: Force DPCD backlight mode for some Dell CML 2020 panels
drivers/gpu/drm/drm_dp_helper.c | 79 +++++++++++++++++++
drivers/gpu/drm/drm_dp_mst_topology.c | 3 +-
.../drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 11 ++-
.../drm/i915/display/intel_dp_aux_backlight.c | 25 +++++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
include/drm/drm_dp_helper.h | 21 ++++-
8 files changed, 130 insertions(+), 14 deletions(-)
--
2.24.1
[View Less]
In order to reduce CPU usage [1] and in theory TLB misses this patchset enables
huge- and giant page-table entries for TTM and TTM-enabled graphics drivers.
Patch 1 and 2 introduce a vma_is_special_huge() function to make the mm code
take the same path as DAX when splitting huge- and giant page table entries,
(which currently means zapping the page-table entry and rely on re-faulting).
Patch 3 makes the mm code split existing huge page-table entries
on huge_fault fallbacks. Typically on COW …
[View More]or on buffer-objects that want
write-notify. COW and write-notification is always done on the lowest
page-table level. See the patch log message for additional considerations.
Patch 4 introduces functions to allow the graphics drivers to manipulate
the caching- and encryption flags of huge page-table entries without ugly
hacks.
Patch 5 implements the huge_fault handler in TTM.
This enables huge page-table entries, provided that the kernel is configured
to support transhuge pages, either by default or using madvise().
However, they are unlikely to be inserted unless the kernel buffer object
pfns and user-space addresses align perfectly. There are various options
here, but since buffer objects that reside in system pages typically start
at huge page boundaries if they are backed by huge pages, we try to enforce
buffer object starting pfns and user-space addresses to be huge page-size
aligned if their size exceeds a huge page-size. If pud-size transhuge
("giant") pages are enabled by the arch, the same holds for those.
Patch 6 implements a specialized huge_fault handler for vmwgfx.
The vmwgfx driver may perform dirty-tracking and needs some special code
to handle that correctly.
Patch 7 implements a drm helper to align user-space addresses according
to the above scheme, if possible.
Patch 8 implements a TTM range manager for vmwgfx that does the same for
graphics IO memory. This may later be reused by other graphics drivers
if necessary.
Patch 9 finally hooks up the helpers of patch 7 and 8 to the vmwgfx driver.
A similar change is needed for graphics drivers that want a reasonable
likelyhood of actually using huge page-table entries.
If a buffer object size is not huge-page or giant-page aligned,
its size will NOT be inflated by this patchset. This means that the buffer
object tail will use smaller size page-table entries and thus no memory
overhead occurs. Drivers that want to pay the memory overhead price need to
implement their own scheme to inflate buffer-object sizes.
PMD size huge page-table-entries have been tested with vmwgfx and found to
work well both with system memory backed and IO memory backed buffer objects.
PUD size giant page-table-entries have seen limited (fault and COW) testing
using a modified kernel (to support 1GB page allocations) and a fake vmwgfx
TTM memory type. The vmwgfx driver does otherwise not support 1GB-size IO
memory resources.
Comments and suggestions welcome.
Thomas
Changes since RFC:
* Check for buffer objects present in contigous IO Memory (Christian König)
* Rebased on the vmwgfx emulated coherent memory functionality. That rebase
adds patch 5.
Changes since v1:
* Make the new TTM range manager vmwgfx-specific. (Christian König)
* Minor fixes for configs that don't support or only partially support
transhuge pages.
Changes since v2:
* Minor coding style and doc fixes in patch 5/9 (Christian König)
* Patch 5/9 doesn't touch mm. Remove from the patch title.
Changes since v3:
* Added reviews and acks
* Implemented ugly but generic ttm_pgprot_is_wrprotecting() instead of arch
specific code.
Changes since v4:
* Added timings (Andrew Morton)
* Updated function documentation (Andrew Morton)
[1]
The below test program generates the following gnu time output when run on a
vmwgfx-enabled kernel without the patch series:
4.78user 6.02system 0:10.91elapsed 99%CPU (0avgtext+0avgdata 1624maxresident)k
0inputs+0outputs (0major+640077minor)pagefaults 0swaps
and with the patch series:
1.71user 3.60system 0:05.40elapsed 98%CPU (0avgtext+0avgdata 1656maxresident)k
0inputs+0outputs (0major+20079minor)pagefaults 0swaps
A consistent number of reduced graphics page-faults can be seen with normal
graphics applications, but due to the aggressive buffer object caching in
vmwgfx user-space drivers the CPU time reduction is within the error marginal.
#include <unistd.h>
#include <string.h>
#include <sys/mman.h>
#include <xf86drm.h>
static void checkerr(int ret, const char *name)
{
if (ret < 0) {
perror(name);
exit(-1);
}
}
int main(int agc, const char *argv[])
{
struct drm_mode_create_dumb c_arg = {0};
struct drm_mode_map_dumb m_arg = {0};
struct drm_mode_destroy_dumb d_arg = {0};
int ret, i, fd;
void *map;
fd = open("/dev/dri/card0", O_RDWR);
checkerr(fd, argv[0]);
for (i = 0; i < 10000; ++i) {
c_arg.bpp = 32;
c_arg.width = 1024;
c_arg.height = 1024;
ret = drmIoctl(fd, DRM_IOCTL_MODE_CREATE_DUMB, &c_arg);
checkerr(fd, argv[0]);
m_arg.handle = c_arg.handle;
ret = drmIoctl(fd, DRM_IOCTL_MODE_MAP_DUMB, &m_arg);
checkerr(fd, argv[0]);
map = mmap(NULL, c_arg.size, PROT_READ | PROT_WRITE, MAP_SHARED, fd,
m_arg.offset);
checkerr(map == MAP_FAILED ? -1 : 0, argv[0]);
(void) madvise((void *) map, c_arg.size, MADV_HUGEPAGE);
memset(map, 0x67, c_arg.size);
munmap(map, c_arg.size);
d_arg.handle = c_arg.handle;
ret = drmIoctl(fd, DRM_IOCTL_MODE_DESTROY_DUMB, &d_arg);
checkerr(ret, argv[0]);
}
close(fd);
}
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: "Matthew Wilcox (Oracle)" <willy(a)infradead.org>
Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Cc: Ralph Campbell <rcampbell(a)nvidia.com>
Cc: "Jérôme Glisse" <jglisse(a)redhat.com>
Cc: "Christian König" <christian.koenig(a)amd.com>
Cc: Dan Williams <dan.j.williams(a)intel.com>
[View Less]
This set of patches convert display-timing.txt to DT schema.
To do that add a panel-timing.yaml file that include all the
panel-timing properties and use this in panel-common and in display-timings.
panel-dpi was also converted so we have no .txt users left of panel-timing
in panel/
Everything passed dt_binding_check - and the trivial errors I tried in
the examples was all catched during validation.
This work was triggered by a patch-set from Oleksandr Suvorov aiming
at updating panel-lvds …
[View More]to support panel-dpi.
This will make it simple to add additional properties to panel-dpi.
Thanks for the quick responses on v2 and likewise the quick
feedback on the request for the license change!
Highlight from v3 - se individual patches for details.
- Added panel-dpi support to panel-simple.
We can now add a simple panel just by addding timing parameters
in a DT node
The patch [5/5] is RFC as test is pending
- To support panel-dpi in panel-simple - add a data-mapping
property to panel-dpi
Highlights from v2 - see individual patches for details.
- Got acks for the license change
- Simplfied panel-timings bindings
- panel-dpi can now be used without a panel specific compatible
So panel-dpi can be used as a generic binding for dumb panels
Feedback welcome!
Sam
Sam Ravnborg (5):
dt-bindings: display: add panel-timing.yaml
dt-bindings: display: convert display-timings to DT schema
dt-bindings: display: convert panel-dpi to DT schema
dt-bindings: display: add data-mapping to panel-dpi
drm/panel: simple: add panel-dpi support
.../bindings/display/panel/display-timing.txt | 124 +----------
.../bindings/display/panel/display-timings.yaml | 77 +++++++
.../bindings/display/panel/panel-common.yaml | 15 +-
.../bindings/display/panel/panel-dpi.txt | 50 -----
.../bindings/display/panel/panel-dpi.yaml | 82 ++++++++
.../bindings/display/panel/panel-timing.yaml | 227 +++++++++++++++++++++
drivers/gpu/drm/panel/panel-simple.c | 74 ++++++-
7 files changed, 470 insertions(+), 179 deletions(-)
[View Less]