| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 5.17:
UAPI Changes:
Cross-subsystem Changes:
* dma-buf: Make fences mandatory in dma_resv_add_excl_fence
Core Changes:
* Move hashtable to legacy code
* Return error pointers from struct drm_driver.gem_create_object
* cma-helper: Improve public interfaces; Remove CONFIG_DRM_KMS_CMA_HELPER option
* mipi-dbi: Don't depend on CMA helpers
* ttm: Don't include DRM hashtable; Stop prunning fences after wait; Documentation
Driver Changes:
* aspeed: Select CONFIG_DRM_GEM_CMA_HELPER
* bridge/lontium-lt9611: Fix HDMI sensing
* bridge/parade-ps8640: Fixes
* bridge/sn65dsi86: Defer probe is no dsi host found
* fsl-dcu: Select CONFIG_DRM_GEM_CMA_HELPER
* i915: Remove dma_resv_prune
* omapdrm: Fix scatterlist export; Support virtual planes; Fixes
* panel: Boe-tv110c9m,Inx-hj110iz: Update init code
* qxl: Use dma-resv iterator
* rockchip: Use generic fbdev emulation
* tidss: Fixes
* vmwgfx: Fix leak on probe errors; Fail probing on broken hosts; New
placement for MOB page tables; Hide internal BOs from userspace; Cleanups
Signed-off-by: Dave Airlie <[email protected]>
From: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
R-Car DU updates:
- DSI output support
- Misc fixes
Signed-off-by: Dave Airlie <[email protected]>
From: Laurent Pinchart <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/Ya4/[email protected]
|
|
https://gitlab.freedesktop.org/agd5f/linux into drm-next
amd-drm-next-5.17-2021-12-02:
amdgpu:
- Use generic drm fb helpers
- PSR fixes
- Rework DCN3.1 clkmgr
- DPCD 1.3 fixes
- Misc display fixes can cleanups
- Clock query fixes for APUs
- LTTPR fixes
- DSC fixes
- Misc PM fixes
- RAS fixes
- OLED backlight fix
- SRIOV fixes
- Add STB (Smart Trace Buffer) for supported dGPUs
- IH rework
- Enable seamless boot for DCN3.01
amdkfd:
- Rework more stuff around IP discovery enumeration
- Further clean up of interfaces with amdgpu
- SVM fixes
radeon:
- Indentation fixes
UAPI:
- Add a new KFD header that defines some of the sysfs bitfields and enums that userspace has been using for a while
The corresponding bit-fields and enums in user mode are defined in
https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/blob/master/include/hsakmttypes.h
Signed-off-by: Dave Airlie <[email protected]>
# Conflicts:
# drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c
From: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 5.17:
UAPI Changes:
Cross-subsystem Changes:
* Move 'nomodeset' kernel boot option into DRM subsystem
Core Changes:
* Replace several DRM_*() logging macros with drm_*() equivalents
* panel: Add quirk for Lenovo Yoga Book X91F/L
* ttm: Documentation fixes
Driver Changes:
* Cleanup nomodeset handling in drivers
* Fixes
* bridge/anx7625: Fix reading EDID; Fix error code
* bridge/megachips: Probe both bridges before registering
* vboxvideo: Fix ERR_PTR usage
Signed-off-by: Daniel Vetter <[email protected]>
From: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Otherwise we don't get another shot at it if the bridge probes before
the dsi host is registered. It seems like this is what *most* (but not
all) of the other bridges do.
It looks like this was missed in the conversion to attach dsi host at
probe time.
Fixes: c3b75d4734cb ("drm/bridge: sn65dsi86: Register and attach our DSI device at probe")
Signed-off-by: Rob Clark <[email protected]>
Reviewed-by: Doug Anderson <[email protected]>
Tested-by: Doug Anderson <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
[dianders: squashed in Stephen's simplification]
Signed-off-by: Douglas Anderson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Using the SET_RUNTIME_PM_OPS() macro causes a warning about the
referenced functions when they are marked static but not __maybe_unused:
drivers/gpu/drm/omapdrm/dss/dss.c:1572:12: error: unused function 'dss_runtime_suspend' [-Werror,-Wunused-function]
drivers/gpu/drm/omapdrm/dss/dss.c:1584:12: error: unused function 'dss_runtime_resume' [-Werror,-Wunused-function]
drivers/gpu/drm/omapdrm/dss/dispc.c:4845:12: error: unused function 'dispc_runtime_suspend' [-Werror,-Wunused-function]
drivers/gpu/drm/omapdrm/dss/dispc.c:4860:12: error: unused function 'dispc_runtime_resume' [-Werror,-Wunused-function]
Fixes: b92f7ea556f8 ("drm/omap: dss: Make use of the helper macro SET_RUNTIME_PM_OPS()")
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
If the drm_plane has a source width that's greater than the max width
supported by a single hw overlay, then we assign a 'r_overlay' to it in
omap_plane_atomic_check().
Both overlays should have the capabilities required to handle the source
framebuffer. The only parameters that vary between the left and right
hwoverlays are the src_w, crtc_w, src_x and crtc_x as we just even chop
the fb into left and right halves.
We also take care of not creating odd width size when dealing with YUV
formats.
Since both halves need to be 'appear' side by side the zpos is
recalculated when dealing with dual overlay cases so that the other
planes zpos is consistent.
Depending on user space usage it is possible that on occasion the number
of requested planes exceeds the numbers of overlays required to display
them. In that case a failure would be returned for the plane that cannot
be handled at that time. It is up to user space to make sure the H/W
resource are not over-subscribed.
Signed-off-by: Benoit Parrot <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Now that we added specific item to our subclassed drm_plane_state
we can add omap_plane_atomic_print_state() helper to dump out our own
driver specific plane state.
Signed-off-by: Benoit Parrot <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
(re)assign the hw overlays to planes based on required caps, and to
handle situations where we could not modify an in-use plane.
This means all planes advertise the superset of formats and properties.
Userspace must (as always) use atomic TEST_ONLY step for atomic updates,
as not all planes may be available for use on every frame.
The mapping of hwoverlays to plane is stored in omap_global_state, so
that state updates are atomically committed in the same way that
plane/etc state updates are managed. This is needed because the
omap_plane_state keeps a pointer to the hwoverlay, and we don't want
global state to become out of sync with the plane state if an atomic
update fails, we hit deadlock/ backoff scenario, etc. The use of
global_state_lock keeps multiple parallel updates which both re-assign
hwoverlays properly serialized.
Signed-off-by: Benoit Parrot <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Global shared resources (like hw overlays) for omapdrm are implemented
as a part of atomic state using the drm_private_obj infrastructure
available in the atomic core.
omap_global_state is introduced as a drm atomic private object. The two
funcs omap_get_global_state() and omap_get_existing_global_state() are
the two variants that will be used to access omap_global_state.
drm_mode_config_init() needs to be called earlier because it
creates/initializes the private_obj link list maintained by the atomic
framework. The private_obj link list has to exist prior to calling
drm_atomic_private_obj_init(). Similarly the cleanup handler are
reordered appropriately.
Signed-off-by: Benoit Parrot <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
In preparation to add omap plane state specific extensions we need to
subclass drm_plane_state and add the relevant helpers.
The addition of specific extension will be done separately.
Signed-off-by: Benoit Parrot <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Split out the hardware overlay specifics from omap_plane.
To start, the hw overlays are statically assigned to planes.
The goal is to eventually assign hw overlays dynamically to planes
during plane->atomic_check() based on requested caps (scaling, YUV,
etc). And then perform hw overlay re-assignment if required.
Signed-off-by: Benoit Parrot <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
In order to be able to dynamically assign overlays to planes we need to
be able to asses the overlay capabilities.
Add a helper function to be able to retrieve the supported capabilities
of an overlay.
And export the function to check if a fourcc is supported on a given
overlay.
Signed-off-by: Benoit Parrot <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We currently assume that an overlay has the same maximum width and
maximum height as the overlay manager. This assumption is incorrect. On
some variants the overlay manager maximum width is twice the maximum
width that the overlay can handle. We need to add the appropriate data
per variant as well as export a helper function to retrieve the data so
check can be made dynamically in omap_plane_atomic_check().
Signed-off-by: Benoit Parrot <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Call drm_atomic_helper_check_plane_state() from the plane
atomic_check() callback in order to add plane state sanity
checking.
It will permit filtering out totally bad scaling factors, even
if the real check are done later in the atomic commit.
Calling drm_atomic_helper_check_plane_state() also sets
plane_state->visible which will be useful when dynamically
assigning hw overlays to planes.
Signed-off-by: Benoit Parrot <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Memory of BOs backed by TILER is not contiguous, but omap_gem_map_dma_buf()
exports it like it is. This leads to (possibly) invalid memory accesses if
another device imports such a BO.
Fix that by providing sg that correctly describes TILER memory layout.
Align TILER allocations to page, so importer to be able to correctly set
its MMU if have one. Set export size accounting for the alignment. Also,
make sure to destroy sg on unpin, as it is no longer valid.
Tested on Motorola Droid4 by using GPU (sgx540) to render.
Suggested-by: Matthijs van Duin <[email protected]>
Signed-off-by: Ivaylo Dimitrov <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
When we added the support for the AUX channel in commit 13afcdd7277e
("drm/bridge: parade-ps8640: Add support for AUX channel") we forgot
to set "drm_dev" to avoid the warning splat at the beginning of
drm_dp_aux_register(). Since everything was working I guess I never
noticed the splat when testing against mainline. In any case, it's
easy to fix. This is basically just like commit 6cba3fe43341 ("drm/dp:
Add backpointer to drm_device in drm_dp_aux") but just for the
parade-ps8640.
Fixes: 13afcdd7277e ("drm/bridge: parade-ps8640: Add support for AUX channel")
Signed-off-by: Douglas Anderson <[email protected]>
Reviewed-by: Philip Chen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/20211206162907.1.I1f5d1eba741e4663050ec1b8e39a753f6e42e38b@changeid
|
|
At present, we have enough panel to confirm the effect,
update the initial code to achieve the best effect.
Such as gamma, Gop timing. They are all minor modifications
and doesn't affect the lighting of the panel.
a)Boe-tv110c9m panel Optimized touch horizontal grain.
b)Inx-hj110iz panel Optimized GOP timing and gamma.
Signed-off-by: yangcong <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Douglas Anderson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Allow drm_fbdev_generic_setup() to pick the default bpp value for the
framebuffer.
This has no functional impact because the default is 32, given that
mode_config.preferred_depth is not set for Rockchip.
Suggested-by: Thomas Zimmermann <[email protected]>
Signed-off-by: John Keeping <[email protected]>
Signed-off-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The Rockchip fbdev code does not add anything compared to
drm_fbdev_generic_setup(); the one custom function for .fb_mmap does the
same thing as gem_prime_mmap which is called by the helper.
Signed-off-by: John Keeping <[email protected]>
Signed-off-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The driver supports the MIPI DSI/CSI-2 TX encoder found in the R-Car V3U
SoC. It currently supports DSI mode only.
Signed-off-by: LUU HOAI <[email protected]>
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Kieran Bingham <[email protected]>
Tested-by: Kieran Bingham <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Reviewed-by: Jagan Teki <[email protected]>
|
|
The R-Car MIPI DSI/CSI-2 TX is embedded in the Renesas R-Car V3U SoC. It
can operate in either DSI or CSI-2 mode, with up to four data lanes.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Kieran Bingham <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
|
|
On platforms with an external clock, both the group and crtc must be
handled accordingly to correctly pass through the external clock and
configure the DU to use the external rate.
The CRTC support was missed while adding the DSI support on the r8a779a0
which led to the output clocks being incorrectly determined.
Ensure that when a CRTC is routed through the DSI encoder, the external
clock is used without any further divider being applied.
Fixes: b291fdcf5114 ("drm: rcar-du: Add r8a779a0 device support")
Signed-off-by: Kieran Bingham <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Laurent Pinchart <[email protected]>
|
|
The DSI output names were not added when the DSI pipeline support was
introduced.
Add the correct labels for these outputs, and fix the sort order to
match 'enum rcar_du_output' while we are here.
Fixes: b291fdcf5114 ("drm: rcar-du: Add r8a779a0 device support")
Suggested-by: Biju Das <[email protected]>
Signed-off-by: Kieran Bingham <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Laurent Pinchart <[email protected]>
|
|
When the CMM is enabled, an offset of 25 pixels must be subtracted from
the HDS (horizontal display start) and HDE (horizontal display end)
registers. Fix the timings calculation, and take this into account in
the mode validation.
This fixes a visible horizontal offset in the image with VGA monitors.
HDMI monitors seem to be generally more tolerant to incorrect timings,
but may be affected too.
Signed-off-by: Laurent Pinchart <[email protected]>
|
|
The meaning of the 'imply' keyword has changed recently, and neither the
old meaning (select the symbol if its dependencies are met) nor the new
meaning (enable it by default, but let the user set any other setting)
is what we want here.
Work around this by adding two more Kconfig options that lead to
the correct behavior: if DRM_RCAR_USE_CMM and DRM_RCAR_USE_LVDS
are enabled, that portion of the driver becomes usable, and no
configuration results in a link error.
This avoids a link failure:
arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_begin':
rcar_du_crtc.c:(.text+0x1444): undefined reference to `rcar_cmm_setup'
arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_enable':
rcar_du_crtc.c:(.text+0x14d4): undefined reference to `rcar_cmm_enable'
arm-linux-gnueabi-ld: rcar_du_crtc.c:(.text+0x1548): undefined reference to `rcar_cmm_setup'
arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_disable':
rcar_du_crtc.c:(.text+0x18b8): undefined reference to `rcar_cmm_disable'
arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_kms.o: in function `rcar_du_modeset_init':
Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Reviewed-by: Randy Dunlap <[email protected]>
Signed-off-by: Laurent Pinchart <[email protected]>
|
|
The aspeed driver uses the gem_cma_helper code, but does
noto enforce enabling this through Kconfig:
x86_64-linux-ld: drivers/gpu/drm/aspeed/aspeed_gfx_drv.o:(.rodata+0x2c8): undefined reference to `drm_gem_cma_prime_import_sg_table'
x86_64-linux-ld: drivers/gpu/drm/aspeed/aspeed_gfx_drv.o:(.rodata+0x2d8): undefined reference to `drm_gem_cma_dumb_create'
x86_64-linux-ld: drivers/gpu/drm/aspeed/aspeed_gfx_crtc.o: in function `aspeed_gfx_pipe_update':
aspeed_gfx_crtc.c:(.text+0xe5): undefined reference to `drm_fb_cma_get_gem_obj'
Add the same 'select' that is used in other such drivers.
Fixes: 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option")
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The fsl-dcu driver uses the gem_cma_helper code, but does
noto enforce enabling this through Kconfig:
arm-linux-gnueabi-ld: drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.o:(.rodata+0x32c): undefined reference to `drm_gem_cma_prime_import_sg_table'
arm-linux-gnueabi-ld: drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.o:(.rodata+0x334): undefined reference to `drm_gem_cma_dumb_create'
arm-linux-gnueabi-ld: drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.o: in function `fsl_dcu_drm_plane_atomic_update':
fsl_dcu_drm_plane.c:(.text+0x144): undefined reference to `drm_fb_cma_get_gem_obj'
Add the same 'select' that is used in other such drivers.
Fixes: 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option")
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
GEM helper libraries use struct drm_driver.gem_create_object to let
drivers override GEM object allocation. On failure, the call returns
NULL.
Change the semantics to make the calls return a pointer-encoded error.
This aligns the callback with its callers. Fixes the ingenic driver,
which already returns an error pointer.
Also update the callers to handle the involved types more strictly.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Steven Price <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
git://anongit.freedesktop.org/drm/drm-intel into drm-next
drm/i915 feature pull for v5.17:
Features and functionality:
- Implement per-lane DP drive settings for ICL+ (Ville)
- Enable runtime pm autosuspend by default (Tilak Tangudu)
- ADL-P DSI support (Vandita)
- Add support for pipe C and D DMC firmware (Anusha)
- Implement (near)atomic gamma LUT updates via vblank workers (Ville)
- Split plane updates to noarm+arm phases (Ville)
- Remove the CCS FB stride restrictions on ADL-P (Imre)
- Add PSR selective fetch support for biplanar formats (Jouni)
- Add support for display audio codec keepalive (Kai)
- VRR platform support for display 11 (Manasi)
Refactoring and cleanups:
- FBC refactoring and cleanups preparing for multiple FBC instances (Ville)
- PCH modeset refactoring, move to its own file (Ville)
- Refactor and simplify handling of modifiers (Imre)
- PXP cleanups (Ville)
- Display header and include refactoring (Jani)
- Some register macro cleanups (Ville)
- Refactor DP HDMI DFP limit code (Ville)
Fixes:
- Disable DSB usage for now due to incorrect gamma LUT updates (Ville)
- Check async flip state of every crtc and plane only once (José)
- Fix DPT FB suspend/resume (Imre)
- Fix black screen on reboot due to disabled DP++ TMDS output buffers (Ville)
- Don't request GMBUS to generate irqs when called while irqs are off (Ville)
- Fix type1 DVI DP dual mode adapter heuristics for modern platforms (Ville)
- Fix fix integer overflow in 128b/132b data rate calculation (Jani)
- Fix bigjoiner state readout (Ville)
- Build fix for non-x86 (Siva)
- PSR fixes (José, Jouni, Ville)
- Disable ADL-P underrun recovery (José)
- Fix DP link parameter usage before valid DPCD (Imre)
- VRR vblank and frame counter fixes (Ville)
- Fix fastsets on TypeC ports following a non-blocking modeset (Imre)
- Compiler warning fixes (Nathan Chancellor)
- Fix DSI HS mode commands (William Tseng)
- Error return fixes (Dan Carpenter)
- Update memory bandwidth calculations (Radhakrishna)
- Implement WM0 cursor WA for DG2 (Stan)
- Fix DSI Double pixelclock on read-back for dual-link panels (Hans de Goede)
- HDMI 2.1 PCON FRL configuration fixes (Ankit)
Merges:
- DP link training delay helpers, via topic branch (Jani)
- Backmerge drm-next (Jani)
Signed-off-by: Dave Airlie <[email protected]>
From: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
[Why]
PSR currently relies on the kernel's delayed vblank on/off mechanism
as an implicit bufferring mechanism to prevent excessive entry/exit.
Without this delay the user experience is impacted since it can take
a few frames to enter/exit.
[How]
Only allow vblank disable immediate for DC when psr is not supported.
Leave a TODO indicating that this support should be extended in the
future to delay independent of the vblank interrupt.
Fixes: 92020e81ddbeac ("drm/amdgpu/display: set vblank_disable_immediate for DC")
Acked-by: Alex Deucher <[email protected]>
Reviewed-by: Harry Wentland <[email protected]>
Signed-off-by: Nicholas Kazlauskas <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
TTM takes full control over TTM_PL_SYSTEM placed buffers. This makes
driver internal usage of TTM_PL_SYSTEM prone to errors because it
requires the drivers to manually handle all interactions between TTM
which can swap out those buffers whenever it thinks it's the right
thing to do and driver.
CPU buffers which need to be fenced and shared with accelerators should
be placed in driver specific placements that can explicitly handle
CPU/accelerator buffer fencing.
Currently, apart, from things silently failing nothing is enforcing
that requirement which means that it's easy for drivers and new
developers to get this wrong. To avoid the confusion we can document
this requirement and clarify the solution.
This came up during a discussion on dri-devel:
https://lore.kernel.org/dri-devel/[email protected]
Signed-off-by: Zack Rusin <[email protected]>
Cc: Christian König <[email protected]>
Cc: Thomas Hellström <[email protected]>
Reviewed-by: Christian König <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
There's never a need to access our internal kernel bo's from
user-space. Those objects are used exclusively for internal
support to guest backed surfaces (in otable setup and mob
page tables) and there's no need to have them be of device
type, i.e. mmappable from user-space.
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Martin Krastev <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
For larger (bigger than a page) and noncontiguous mobs we have
to create page tables that allow the host to find the memory.
Those page tables just used regular system memory. Unfortunately
in TTM those BO's are not allowed to be busy thus can't be
fenced and we have to fence those bo's because we don't want
to destroy the page tables while the host is still executing
the command buffers which might be accessing them.
To solve it we introduce a new placement VMW_PL_SYSTEM which
is very similar to TTM_PL_SYSTEM except that it allows
fencing. This fixes kernel oops'es during unloading of the driver
(and pci hot remove/add) which were caused by busy BO's in
TTM_PL_SYSTEM being present in the delayed deletion list in
TTM (TTM_PL_SYSTEM manager is destroyed before the delayed
deletions are executed)
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Martin Krastev <[email protected]>
Cc: Christian König <[email protected]>
Cc: Thomas Hellström <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Some of our hosts have a bug where rescaning a pci bus results in stale
fifo memory being mapped on the host. This makes any fifo communication
impossible resulting in various kernel crashes.
Instead of unexpectedly crashing, predictably fail to load the driver
which will preserve the system.
Fixes: fb1d9738ca05 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU")
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Martin Krastev <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The ttm mem global state was leaking if the vmwgfx driver load failed.
In case of a driver load failure we have to make sure we also release
the ttm mem global state.
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Martin Krastev <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
TTM during the transition to the new page allocator lost the ability
to constrain the allocations via the lower_mem_limit. The code has
been unused since the change:
256dd44bd897 ("drm/ttm: nuke old page allocator")
and there's no reason to keep it.
Fixes: 256dd44bd897 ("drm/ttm: nuke old page allocator")
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Martin Krastev <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Calling dma_resv_add_excl_fence() with the fence as NULL and expecting
that that this frees up the fences is simply abuse of the internals of
the dma_resv object.
v2: drop the fence pruning completely.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This is just abusing internals of the dma_resv object.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The signaled bit is already used for quick testing if a fence is signaled.
Signed-off-by: Maarten Lankhorst <[email protected]>
Acked-by: Christian König <[email protected]>
Link: https://patchwork.freedesktop.org/patch/460722/
Signed-off-by: Christian König <[email protected]>
|
|
I'm not sure why it is useful to know the number of fences
in the reservation object, but we try to avoid exposing the
dma_resv_shared_list() function.
So use the iterator instead. If more information is desired
we could use dma_resv_describe() as well.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
It has been observed that with certain monitors such as the HP Z27n,
the register 0x825e reads a value of 0x79 when the HDMI cable is
connected and 0x78 when it is disconnected, i.e. bit 0 appears
to correspond to the HDMI connection status and bit 2 is never
set. Therefore, change the driver to check bit 0 instead of bit 2.
Signed-off-by: Peter Collingbourne <[email protected]>
Link: https://linux-review.googlesource.com/id/I7e76411127e1ce4988a3f6d0c8ba5f1c3d880c23
Reviewed-by: Vinod Koul <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Link drm_fb_cma_helper.o into drm_cma_helper.ko if CONFIG_DRM_KMS_HELPER
has been set. Remove CONFIG_DRM_KMS_CMA_HELPER config option. Selecting
KMS helpers and CMA will now automatically enable CMA KMS helpers.
Some drivers' Kconfig files did not correctly select KMS or CMA helpers.
Fix this as part of the change.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The MIPI DBI helpers access struct drm_gem_cma_object.vaddr in a
few places. Replace all instances with the correct generic GEM
functions. Use drm_gem_fb_vmap() for mapping a framebuffer's GEM
objects and drm_gem_fb_vunmap() for unmapping them. This removes
the dependency on CMA helpers within MIPI DBI.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Change all GEM CMA object functions that receive a GEM object
of type struct drm_gem_object to expect an object of type
struct drm_gem_cma_object instead.
This change reduces the number of upcasts from struct drm_gem_object
by moving them into callers. The C compiler can now verify that the
GEM CMA functions are called with the correct type.
For consistency, the patch also renames drm_gem_cma_free_object to
drm_gem_cma_free. It further updates documentation for a number of
functions.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Wrap GEM CMA functions for struct drm_gem_object_funcs and update
all callers. This will allow for an update of the public interfaces
of the GEM CMA helper library.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Restructure the header file for CMA helpers by moving declarations
for driver and file operations to the end of the file. No functional
changes.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Maxime Ripard <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The DRM hashtable code is only used by internal functions for legacy
UMS drivers. Move the implementation behind CONFIG_DRM_LEGACY and the
declarations into legacy header files. Unexport the symbols.
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Besides some legacy code, vmwgfx is the only user of DRM's hash-
table implementation. Copy the code into the driver, so that the
core code can be retired.
No functional changes. However, the real solution for vmwgfx is to
use Linux' generic hash-table functions.
v2:
* add TODO item for updating vmwgfx (Sam)
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Remove the include statement for drm_hashtab.h. It's not required
by TTM.
Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Christian König <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|