linux.git/include/drm, branch v5.7.15

drm/drm_fb_helper: fix fbdev with sparc64

2020-08-11T13:35:36+00:00

[ Upstream commit 2a1658bf922ffd9b7907e270a7d9cdc9643fc45d ]

Recent kernels have been reported to panic using the bochs_drm
framebuffer under qemu-system-sparc64 which was bisected to
commit 7a0483ac4ffc ("drm/bochs: switch to generic drm fbdev emulation").

The backtrace indicates that the shadow framebuffer copy in
drm_fb_helper_dirty_blit_real() is trying to access the real
framebuffer using a virtual address rather than use an IO access
typically implemented using a physical (ASI_PHYS) access on SPARC.

The fix is to replace the memcpy with memcpy_toio() from io.h.

memcpy_toio() uses writeb() where the original fbdev code
used sbus_memcpy_toio(). The latter uses sbus_writeb().

The difference between writeb() and sbus_memcpy_toio() is
that writeb() writes bytes in little-endian, where sbus_writeb() writes
bytes in big-endian. As endian does not matter for byte writes they are
the same. So we can safely use memcpy_toio() here.

Note that this only fixes bochs, in general fbdev helpers still have
issues with mixing up system memory and __iomem space. Fixing that will
require a lot more work.

v3:
  - Improved changelog (Daniel)
  - Added FIXME to fbdev_use_iomem (Daniel)

v2:
  - Added missing __iomem cast (kernel test robot)
  - Made changelog readable and fix typos (Mark)
  - Add flag to select iomem - and set it in the bochs driver

Signed-off-by: Sam Ravnborg 
Reported-by: Mark Cave-Ayland 
Reported-by: kernel test robot 
Tested-by: Mark Cave-Ayland 
Reviewed-by: Daniel Vetter 
Cc: Mark Cave-Ayland 
Cc: Thomas Zimmermann 
Cc: Gerd Hoffmann 
Cc: "David S. Miller" 
Cc: sparclinux@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200709193016.291267-1-sam@ravnborg.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200725191012.GA434957@ravnborg.org
Signed-off-by: Sasha Levin

drm: fix trivial field description cut-and-paste error

2020-05-11T17:48:53+00:00

As reported by Amarnath Baliyase, the drm_mode_status enumeration
documentation describes MODE_V_ILLEGAL as "mode has illegal horizontal
timings".  But that's just a cut-and-paste error from the previous line.
The "V" stands for vertical, of course.

I'm just fixing this directly rather than bothering with going through
the proper channels.  Less work for everybody.

Reported-by: Amarnath Baliyase 
Signed-off-by: Linus Torvalds

drm/bridge: analogix_dp: Split bind() into probe() and real bind()

2020-04-09T08:29:35+00:00

Analogix_dp driver acquires all its resources in the ->bind() callback,
what is a bit against the component driver based approach, where the
driver initialization is split into a probe(), where all resources are
gathered, and a bind(), where all objects are created and a compound
driver is initialized.

Extract all the resource related operations to analogix_dp_probe() and
analogix_dp_remove(), then call them before/after registration of the
device components from the main Exynos DP and Rockchip DP drivers. Also
move the plat_data initialization to the probe() to make it available for
the analogix_dp_probe() function.

This fixes the multiple calls to the bind() of the DRM compound driver
when the DP PHY driver is not yet loaded/probed:

[drm] Exynos DRM: using 14400000.fimd device for DMA mapping operations
exynos-drm exynos-drm: bound 14400000.fimd (ops fimd_component_ops [exynosdrm])
exynos-drm exynos-drm: bound 14450000.mixer (ops mixer_component_ops [exynosdrm])
exynos-dp 145b0000.dp-controller: no DP phy configured
exynos-drm exynos-drm: failed to bind 145b0000.dp-controller (ops exynos_dp_ops [exynosdrm]): -517
exynos-drm exynos-drm: master bind failed: -517
...
[drm] Exynos DRM: using 14400000.fimd device for DMA mapping operations
exynos-drm exynos-drm: bound 14400000.fimd (ops hdmi_enable [exynosdrm])
exynos-drm exynos-drm: bound 14450000.mixer (ops hdmi_enable [exynosdrm])
exynos-drm exynos-drm: bound 145b0000.dp-controller (ops hdmi_enable [exynosdrm])
exynos-drm exynos-drm: bound 14530000.hdmi (ops hdmi_enable [exynosdrm])
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
Console: switching to colour frame buffer device 170x48
exynos-drm exynos-drm: fb0: exynosdrmfb frame buffer device
[drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1
...

Signed-off-by: Marek Szyprowski 
Acked-by: Andy Yan 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Andrzej Hajda 
Link: https://patchwork.freedesktop.org/patch/msgid/20200310103427.26048-1-m.szyprowski@samsung.com
(cherry picked from commit 83a196773b8bc6702f49df1eddc848180e350340)
Signed-off-by: Maxime Ripard

drm/legacy: Fix type for drm_local_map.offset

2020-04-09T07:06:45+00:00

drm_local_map.offset is not only used for resource_size_t but also
dma_addr_t which may be of different sizes.

Reported-by: Nathan Chancellor 
Fixes: 8e4ff9b56957 ("drm: Remove the dma_alloc_coherent wrapper for internal usage")
Tested-by: Nathan Chancellor  # build
Signed-off-by: Chris Wilson 
Cc: Dave Airlie 
Cc: Nathan Chancellor 
Cc: Linus Torvalds 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20200402215926.30714-1-chris@chris-wilson.co.uk

Merge branch 'ttm-transhuge' of git://people.freedesktop.org/~thomash/linux into drm-next

2020-04-02T23:07:49+00:00

Huge page-table entries for TTM

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.

Signed-off-by: Dave Airlie 
From: Thomas Hellstrom (VMware) 
Link: https://patchwork.freedesktop.org/patch/msgid/20200325073102.6129-1-thomas_os@shipmail.org

Merge v5.6 into drm-next

2020-03-31T05:15:47+00:00

msm needed rc6, so I just went and merged release
(msm has been in drm-next outside of this tree)

Signed-off-by: Dave Airlie

drm: Add a drm_get_unmapped_area() helper

2020-03-24T17:49:26+00:00

Unaligned virtual addresses makes it unlikely that huge page-table entries
can be used.
So align virtual buffer object address huge page boundaries to the
underlying physical address huge page boundaries taking buffer object
sizes into account to determine when it might be possible to use huge
page-table entries.

Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: "Matthew Wilcox (Oracle)" 
Cc: "Kirill A. Shutemov" 
Cc: Ralph Campbell 
Cc: "Jérôme Glisse" 
Cc: "Christian König" 
Cc: Dan Williams 
Signed-off-by: Thomas Hellstrom (VMware) 
Reviewed-by: Roland Scheidegger 
Acked-by: Christian König

drm/ttm, drm/vmwgfx: Support huge TTM pagefaults

2020-03-24T17:48:33+00:00

Support huge (PMD-size and PUD-size) page-table entries by providing a
huge_fault() callback.
We still support private mappings and write-notify by splitting the huge
page-table entries on write-access.

Note that for huge page-faults to occur, either the kernel needs to be
compiled with trans-huge-pages always enabled, or the kernel needs to be
compiled with trans-huge-pages enabled using madvise, and the user-space
app needs to call madvise() to enable trans-huge pages on a per-mapping
basis.

Furthermore huge page-faults will not succeed unless buffer objects and
user-space addresses are aligned on huge page size boundaries.

Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: "Matthew Wilcox (Oracle)" 
Cc: "Kirill A. Shutemov" 
Cc: Ralph Campbell 
Cc: "Jérôme Glisse" 
Cc: "Christian König" 
Cc: Dan Williams 
Signed-off-by: Thomas Hellstrom (VMware) 
Reviewed-by: Roland Scheidegger 
Reviewed-by: Christian König

Merge tag 'amd-drm-next-5.7-2020-03-19' of git://people.freedesktop.org/~agd5f/linux into drm-next

2020-03-20T02:54:51+00:00

amd-drm-next-5.7-2020-03-19:

amdgpu:
- SR-IOV fixes
- RAS fixes
- Fallthrough cleanups
- Kconfig fix for ACP
- Fix load balancing with VCN
- DC fixes
- GPU reset fixes
- Various cleanups

scheduler:
- Revert job distribution optimization
- Add a helper to pick the least loaded scheduler

Signed-off-by: Dave Airlie 
From: Alex Deucher 
Link: https://patchwork.freedesktop.org/patch/msgid/20200319175418.4237-1-alexander.deucher@amd.com

Merge tag 'drm-misc-next-2020-03-17' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

2020-03-19T01:01:58+00:00

drm-misc-next for 5.7:

UAPI Changes:

Cross-subsystem Changes:

Core Changes:
  - dp-mst: Remove register_connector callback, add drm_dp_destroy_connector
  - Changes to scnprintf on multiple instances

Driver Changes:
  - meson: Support for YUV420
  - panel: Support Ortustech COM37H3M, idk-1110wr and idk-2121wr,
           multiple dotclock fixes

Signed-off-by: Dave Airlie 

From: Maxime Ripard 
Link: https://patchwork.freedesktop.org/patch/msgid/20200317082858.lubmvlmvoprn2tuh@gilmour.lan