John Harrison [Thu, 3 Jun 2021 16:48:12 +0000 (09:48 -0700)]
drm/i915/uc: Use platform specific defaults for GuC/HuC enabling
The meaning of 'default' for the enable_guc module parameter has been
updated to accurately reflect what is supported on current platforms.
So start using the defaults instead of forcing everything off.
Although, note that right now, the default is for everything to be off
anyway. So this is not a change for current platforms.
drm/i915/guc: Use guc_class instead of engine_class in fw interface
GuC has its own defines for the engine classes. They're currently
mapping 1:1 to the defines used by the driver, but there is no guarantee
this will continue in the future. Given that we've been caught off-guard
in the past by similar divergences, we can prepare for the changes by
introducing helper functions to convert from engine class to GuC class and
back again.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-21-matthew.brost@intel.com
drm/i915/guc: Early initialization of GuC send registers
Base offset and count of the GuC scratch registers, used for
sending MMIO messages to GuC, can be initialized earlier with
other GuC members that also depends on platform.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-20-matthew.brost@intel.com
drm/i915/guc: Always copy CT message to new allocation
Since most of future CT traffic will be based on G2H requests,
instead of copying incoming CT message to static buffer and then
create new allocation for such request, always copy incoming CT
message to new allocation. Also by doing it while reading CT
header, we can safely fallback if that atomic allocation fails.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-19-matthew.brost@intel.com
drm/i915/guc: Stop using mutex while sending CTB messages
We are no longer using descriptor to hold G2H replies and we are
protecting access to the descriptor and command buffer by the
separate spinlock, so we can stop using mutex.
Matthew Brost [Thu, 3 Jun 2021 05:16:25 +0000 (22:16 -0700)]
drm/i915/guc: Ensure H2G buffer updates visible before tail update
Ensure H2G buffer updates are visible before descriptor tail updates by
inserting a barrier between the H2G buffer update and the tail. The
barrier is simple wmb() for SMEM and is register write for LMEM. This is
needed if more than 1 H2G can be inflight at once.
If this barrier is not inserted it is possible the descriptor tail
update is scene by the GuC before H2G buffer update which results in the
GuC reading a corrupt H2G value. This can bring down the H2G channel
among other bad things.
drm/i915/guc: Replace CTB array with explicit members
Upcoming GuC firmware will always require just two CTBs and we
also plan to configure them with different sizes, so definining
them as array is no longer suitable.
v2: Use %p for ptrdiff print
v3: Use %tx for ptrdiff print
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603230408.54856-1-matthew.brost@intel.com
Matthew Brost [Thu, 3 Jun 2021 05:16:16 +0000 (22:16 -0700)]
drm/i915/guc: Drop guc->interrupts.enabled
Drop the variable guc->interrupts.enabled as this variable is just
leading to bugs creeping into the code.
e.g. A full GPU reset disables the GuC interrupts but forgot to clear
guc->interrupts.enabled, guc->interrupts.enabled being true suppresses
interrupts from getting re-enabled and now we are broken.
It is harmless to enable interrupt while already enabled so let's just
delete this variable to avoid bugs like this going forward.
Our fwif.h file is now mix of strict firmware ABI definitions and
set of our helpers. In anticipation of upcoming changes to the GuC
interface try to keep them separate in smaller maintainable files.
drm/i915/guc: enable only the user interrupt when using GuC submission
In GuC submission mode the CS is owned by the GuC FW, so all CS status
interrupts are handled by it. We only need the user interrupt as that
signals request completion.
Since we're now starting the engines directly in GuC submission mode
when selected, we can stop switching back and forth between the
execlists and the GuC programming and select directly the correct
interrupt mask.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <john.c.harrison@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-4-matthew.brost@intel.com
drm/i915/guc: use probe_error log for CT enablement failure
We have a couple of failure injection points in the CT enablement path,
so we need to use i915_probe_error() to select the appropriate log level.
A new macro (CT_PROBE_ERROR) has been added to the set of CT logging
macros to be used in this scenario and upcoming ones.
While adding the new macros, fix the underlying logging mechanics used
by the existing ones (DRM_DEV_* -> drm_*) and move the inlines to
before they're used inside the macros.
drm/i915/guc: skip disabling CTBs before sanitizing the GuC
If we're about to sanitize the GuC, something might have going wrong
beforehand, so we should avoid trying to talk to it. Even if GuC is
still running fine, the sanitize will reset its internal state and clear
the CTB registration, so there is still no need to explicitly do so.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/2469 Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603051630.2635-2-matthew.brost@intel.com
drm/i915/ttm: Embed a ttm buffer object in the i915 gem object
Embed a struct ttm_buffer_object into the i915 gem object, making sure
we alias the gem object part. It's a bit unfortunate that the
struct ttm_buffer_ojbect embeds a gem object since we otherwise could
make the TTM part private to the TTM backend, and use the usual
i915 gem object for the other backends.
To make this a bit more storage efficient for the other backends,
we'd have to use a pointer for the gem object which would require
a lot of changes in the driver. We postpone that for later.
We are unfortunately seeing more issues like we did in 293837b9ac8d
("Revert "i915: fix remap_io_sg to verify the pgprot""), except this is
now for the vm_fault_gtt path, where we are now hitting the same
BUG_ON(!pte_none(*pte)):
Reverting this commit is reported to fix the issue.
Reported-by: Eero Tamminen <eero.t.tamminen@intel.com>
References: https://gitlab.freedesktop.org/drm/intel/-/issues/3519 Fixes: b739f125e4eb ("i915: use io_mapping_map_user") Cc: Christoph Hellwig <hch@lst.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210527185145.458021-1-matthew.auld@intel.com
Zhihao Cheng [Tue, 1 Jun 2021 09:19:35 +0000 (09:19 +0000)]
drm/i915/selftests: Fix return value check in live_breadcrumbs_smoketest()
In case of error, the function live_context() returns ERR_PTR() and never
returns NULL. The NULL test in the return value check should be replaced
with IS_ERR().
Dave Airlie [Wed, 2 Jun 2021 04:04:29 +0000 (14:04 +1000)]
Merge tag 'drm-intel-gt-next-2021-05-28' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
UAPI Changes:
- Add reworked uAPI for DG1 behind CONFIG_BROKEN (Matt A, Abdiel)
Driver Changes:
- Fix for Gitlab issues #3293 and #3450:
Avoid kernel crash on older L-shape memory machines
- Add Wa_14010733141 (VDBox SFC reset) for Gen11+ (Aditya)
- Fix crash in auto_retire active retire callback due to
misalignment (Stephane)
- Fix overlay active retire callback alignment (Tvrtko)
- Eliminate need to align active retire callbacks (Matt A, Ville,
Daniel)
- Program FF_MODE2 tuning value for all Gen12 platforms (Caz)
- Add Wa_14011060649 for TGL,RKL,DG1 and ADLS (Swathi)
- Create stolen memory region from local memory on DG1 (CQ)
- Place PD in LMEM on dGFX (Matt A)
- Use WC when default state object is allocated in LMEM (Venkata)
- Determine the coherent map type based on object location (Venkata)
- Use lmem physical addresses for fb_mmap() on discrete (Mohammed)
- Bypass aperture on fbdev when LMEM is available (Anusha)
- Return error value when displayable BO not in LMEM for dGFX (Mohammed)
- Do release kernel context if breadcrumb measure fails (Janusz)
- Hide modparams for compiled-out features (Tvrtko)
- Apply Wa_22010271021 for all Gen11 platforms (Caz)
- Fix unlikely ref count race in arming the watchdog timer (Tvrtko)
- Check actual RC6 enable status in PMU (Tvrtko)
- Fix a double free in gen8_preallocate_top_level_pdp (Lv)
- Use trylock in shrinker for GGTT on BSW VT-d and BXT (Maarten)
- Remove erroneous i915_is_ggtt check for
I915_GEM_OBJECT_UNBIND_VM_TRYLOCK (Maarten)
- Convert uAPI headers to real kerneldoc (Matt A)
- Clean up kerneldoc warnings headers (Matt A, Maarten)
- Fail driver if LMEM training failed (Matt R)
- Avoid div-by-zero on Gen2 (Ville)
- Read C0DRB3/C1DRB3 as 16 bits again and add _BW suffix (Ville)
- Remove reference to struct drm_device.pdev (Thomas)
- Increase separation between GuC and execlists code (Chris, Matt B)
- Use might_alloc() (Bernard)
- Split DGFX_FEATURES from GEN12_FEATURES (Lucas)
- Deduplicate Wa_22010271021 programming on (Jose)
- Drop duplicate WaDisable4x2SubspanOptimization:hsw (Tvrtko)
- Selftest improvements (Chris, Hsin-Yi, Tvrtko)
- Shuffle around init_memory_region for stolen (Matt)
- Typo fixes (wengjianfeng)
* drm/nouveau: Implement mmap as GEM object function
* drm/radeon: Implement mmap as GEM object function
* drm/rockchip: Remove generic drivers during init; Add scaling for RK3036
win1; Fix missing registers for RK3066 and 3188; Add alpha support for
RK3036, RK3066, RK3126 and RK3188; Fixes and cleanups
* drm/simpledrm: Use %p4cc: format-string modifier
drm/i915: Fix i915_sg_page_sizes to record dma segments rather than physical pages
All users of this function actually want the dma segment sizes, but that's
not what's calculated. Fix that and rename the function to
i915_sg_dma_sizes to reflect what's calculated.
We are currently sharing the VM reservation locks across a number of
gem objects with page-table memory. Since TTM will individiualize the
reservation locks when freeing objects, including accessing the shared
locks, make sure that the shared locks are not freed until that is done.
For PPGTT we add an additional refcount, for GGTT we take additional
measures to make sure objects sharing the GGTT reservation lock are
freed at GGTT takedown
Any sleeping dma_resv lock taken while the vma pages_mutex is held
will cause a lockdep splat.
Move the i915_gem_object_pin_pages() call out of the pages_mutex
critical section.
Simon Ser [Tue, 18 May 2021 11:11:31 +0000 (13:11 +0200)]
drm: document minimum kernel version for DRM_CLIENT_CAP_*
The kernel versions including the following commits are referenced:
DRM_CLIENT_CAP_STEREO_3D 61d8e3282541 ("drm: Add a STEREO_3D capability to the SET_CLIENT_CAP ioctl")
DRM_CLIENT_CAP_UNIVERSAL_PLANES 681e7ec73044 ("drm: Allow userspace to ask for universal plane list (v2)") c7dbc6c9ae5c ("drm: Remove command line guard for universal planes")
Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Daniel Stone <daniels@collabora.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/434202/
Simon Ser [Tue, 18 May 2021 09:56:54 +0000 (11:56 +0200)]
drm: clarify and linkify DRM_CLIENT_CAP_WRITEBACK_CONNECTORS docs
Make it clear that the client is responsible for enabling ATOMIC
prior to enabling WRITEBACK_CONNECTORS. Linkify the reference to
ATOMIC.
Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Daniel Stone <daniels@collabora.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/434200/
Simon Ser [Tue, 18 May 2021 09:51:18 +0000 (11:51 +0200)]
drm: reference mode flags in DRM_CLIENT_CAP_* docs
In the docs for DRM_CLIENT_CAP_STEREO_3D and
DRM_CLIENT_CAP_ASPECT_RATIO, reference the DRM_MODE_FLAG_* defines
that get set when the cap is enabled.
Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Daniel Stone <daniels@collabora.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/434201/
Yu Kuai [Mon, 31 May 2021 13:56:22 +0000 (21:56 +0800)]
drm: bridge: cdns-mhdp8546: Fix PM reference leak in
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
Johan Jonker [Sun, 31 Jan 2021 12:50:16 +0000 (13:50 +0100)]
drm/rockchip: vop: add PX30 version info
To reduce memory various Rockchip VOP versions share
common reg structures. However more recent added SoCs not
always have to same futures as the old ones.
Add PX30 missing version info, so all VOP version checks
work correct if needed in the future.
Colin Ian King [Tue, 15 Sep 2020 16:20:49 +0000 (17:20 +0100)]
drm/rockchip: cdn-dp: fix sign extension on an int multiply for a u64 result
The variable bit_per_pix is a u8 and is promoted in the multiplication
to an int type and then sign extended to a u64. If the result of the
int multiplication is greater than 0x7fffffff then the upper 32 bits will
be set to 1 as a result of the sign extension. Avoid this by casting
tu_size_reg to u64 to avoid sign extension and also a potential overflow.
Thomas Hebb [Mon, 19 Apr 2021 02:03:04 +0000 (19:03 -0700)]
drm/rockchip: dsi: remove extra component_del() call
commit cf6d100dd238 ("drm/rockchip: dsi: add dual mipi support") added
this devcnt field and call to component_del(). However, these both
appear to be erroneous changes left over from an earlier version of the
patch. In the version merged, nothing ever modifies devcnt, meaning
component_del() runs unconditionally and in addition to the
component_del() calls in dw_mipi_dsi_rockchip_host_detach(). The second
call fails to delete anything and produces a warning in dmesg.
If we look at the previous version of the patch[1], however, we see that
it had logic to calculate devcnt and call component_add() in certain
situations. This was removed in v6, and the fact that the deletion code
was not appears to have been an oversight.
Thomas Hebb [Mon, 19 Apr 2021 02:04:10 +0000 (19:04 -0700)]
drm/rockchip: dsi: move all lane config except LCDC mux to bind()
When we first enable the DSI encoder, we currently program some per-chip
configuration that we look up in rk3399_chip_data based on the device
tree compatible we match. This data configures various parameters of the
MIPI lanes, including on RK3399 whether DSI1 is slaved to DSI0 in a
dual-mode configuration. It also selects which LCDC (i.e. VOP) to scan
out from.
This causes a problem in RK3399 dual-mode configurations, though: panel
prepare() callbacks run before the encoder gets enabled and expect to be
able to write commands to the DSI bus, but the bus isn't fully
functional until the lane and master/slave configuration have been
programmed. As a result, dual-mode panels (and possibly others too) fail
to turn on when the rockchipdrm driver is initially loaded.
Because the LCDC mux is the only thing we don't know until enable time
(and is the only thing that can ever change), we can actually move most
of the initialization to bind() and get it out of the way early. That's
what this change does. (Rockchip's 4.4 BSP kernel does it in mode_set(),
which also avoids the issue, but bind() seems like the more correct
place to me.)
Tested on a Google Scarlet board (Acer Chromebook Tab 10), which has a
Kingdisplay KD097D04 dual-mode panel. Prior to this change, the panel's
backlight would turn on but no image would appear when initially loading
rockchipdrm. If I kept rockchipdrm loaded and reloaded the panel driver,
it would come on. With this change, the panel successfully turns on
during initial rockchipdrm load as expected.
The CDP DP component of the rockchip GPU driver requires firmware
so define MODULE_FIRMWARE for rockchip/dptx.bin so the details
are available in the module info.
Alex Bee [Fri, 28 May 2021 13:05:53 +0000 (15:05 +0200)]
drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
With
commit 2aae8ed1f390 ("drm/rockchip: Add per-pixel alpha support for the PX30 VOP")
alpha support was introduced for PX30's VOP.
RK3036, RK3066, RK3126 and RK3188 VOPs support alpha blending in the
same manner.
With the exception of RK3066 all of them support pre-multiplied alpha.
Alex Bee [Fri, 28 May 2021 13:05:52 +0000 (15:05 +0200)]
drm: rockchip: add missing registers for RK3066
Add dither_up, dsp_lut_en and data_blank registers to enable their
respective functionality for RK3066's VOP.
While at that also fix .rb_swap and .format registers for all windows,
which have to be set though RK3066_SYS_CTRL1 register.
Also remove .scl from win1: Scaling is only supported on the primary
plane.
Alex Bee [Fri, 28 May 2021 13:05:51 +0000 (15:05 +0200)]
drm: rockchip: add missing registers for RK3188
Add dither_up, dsp_lut_en and data_blank registers to enable their
respective functionality for RK3188's VOP.
While at that also fix .dsp_blank register which is (only) set with
BIT24 (same as RK3066)
drm/rockchip: remove existing generic drivers to take over the device
There are drivers that register framebuffer devices very early in the boot
process and make use of the existing framebuffer as setup by the firmware.
If one of those drivers has registered a fbdev, then the fallback fbdev of
the DRM driver won't be bound to the framebuffer console. To avoid that,
remove any existing generic driver and take over the graphics device.
By doing that, the fb mapped to the console is switched correctly from the
early fbdev to the one registered by the rockchip DRM driver:
[ 40.752420] fb0: switching to rockchip-drm-fb from EFI VGA
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210516074833.451643-1-javierm@redhat.com
Paul Cercueil [Thu, 27 May 2021 23:03:34 +0000 (00:03 +0100)]
drm: Fix for GEM buffers with write-combine memory
The previous commit wrongly assumed that dma_mmap_wc() could be replaced
by pgprot_writecombine() + dma_mmap_pages(). It did work on my setup,
but did not work everywhere.
Use dma_mmap_wc() when the buffer has the write-combine cache attribute,
and dma_mmap_pages() when it has the non-coherent cache attribute.
Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reported-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Fixes: cf8ccbc72d61 ("drm: Add support for GEM buffers backed by non-coherent memory") Link: https://patchwork.freedesktop.org/patch/msgid/20210527230334.151947-1-paul@crapouillou.net
Nikola Cornij [Wed, 12 May 2021 21:00:11 +0000 (17:00 -0400)]
drm/dp_mst: Use kHz as link rate units when settig source max link caps at init
[why]
Link rate in kHz is what is eventually required to calculate the link
bandwidth, which makes kHz a more generic unit. This should also make
forward-compatibility with new DP standards easier.
[how]
- Replace 'link rate DPCD code' with 'link rate in kHz' when used with
drm_dp_mst_topology_mgr_init()
- Add/remove related DPCD code conversion from/to kHz where applicable
Aditya Swarup [Wed, 26 May 2021 09:48:52 +0000 (02:48 -0700)]
drm/i915: Add Wa_14010733141
The WA requires the following procedure for VDBox SFC reset:
If (MFX-SFC usage is 1) {
1.Issue a MFX-SFC forced lock
2.Wait for MFX-SFC forced lock ack
3.Check the MFX-SFC usage bit
If (MFX-SFC usage bit is 1)
Reset VDBOX and SFC
else
Reset VDBOX
Release the force lock MFX-SFC
}
else if(HCP+SFC usage is 1) {
1.Issue a VE-SFC forced lock
2.Wait for SFC forced lock ack
3.Check the VE-SFC usage bit
If (VE-SFC usage bit is 1)
Reset VDBOX
else
Reset VDBOX and SFC
Release the force lock VE-SFC.
}
else
Reset VDBOX
- Restructure: the changes to the original code flow should stay
relatively minimal; we only need to do an extra HCP check after the
usual VD-MFX check and, if true, switch the register/bit we're
performing the lock on.(MattR)
v2:
- Assign unlock mask using paired_engine->mask instead of using
BIT(paired_vecs->id). (Daniele)
Bspec: 52890, 53509
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Co-developed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210526094852.286424-2-aditya.swarup@intel.com
drm/bridge: DRM_CROS_EC_ANX7688 should depend on I2C_CROS_EC_TUNNEL
The ChromeOS EC ANX7688 bridge is connected to a ChromeOS Embedded
Controller, and is accessed using I2C tunneling through the Embedded
Controller. Hence add a dependency on I2C_CROS_EC_TUNNEL, to prevent
asking the user about this driver when configuring a kernel without
support for the ChromeOS EC tunnel I2C bus.
Zou Wei [Mon, 24 May 2021 07:21:02 +0000 (15:21 +0800)]
drm/bridge: cdns: Fix PM reference leak in cdns_dsi_transfer()
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
Tvrtko Ursulin [Wed, 26 May 2021 14:19:46 +0000 (15:19 +0100)]
drm/i915/params: Align visibility of device level and global modparams
We have a few modparams which get conditionally exposed based on a Kconfig
options and in most cases this also means portions of the driver
implementing the respective feature are also left out.
Align the visibility of device level and global modparams to make them
consistent in this respect.
Sakari Ailus [Sun, 16 May 2021 12:13:14 +0000 (14:13 +0200)]
drm: Remove drm_get_format_name()
The %p4cc printk format modifier was recently added to print fourcc codes,
replacing drm_get_format_name(). The function is no longer needed, so
remove it.
Framebuffer devices that are registered by DRM drivers for fbdev emulation
have a "drmfb" suffix in their name. But makes them to be quite confusing
for drivers that already have "drm" in their name:
$ cat /proc/fb
0 rockchipdrmdrmfb
$ cat /proc/fb
0 simpledrmdrmfb
Also, there isn't a lot of value in adding these "drmfb" suffices to their
names, since users shouldn't really care if the FB devices were registered
by a real fbdev driver or a DRM driver using the fbdev emulation.
What programs should be interested about is if there's a DRM device, and
there are better ways to query that info than reading this procfs entry.
So let's just remove the suffix, which leads to much better device names:
drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver
The vmwgfx driver is the only remaining user of ttm_bo_mmap(). Inline
the code. The internal helper ttm_bo_vm_lookup() is now also part of
vmwgfx as vmw_bo_vm_lookup().
drm/nouveau: Implement mmap as GEM object function
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
The GEM object function is provided by GEM TTM helpers. Nouveau's
implementation of verify_access is unused and has been removed. Access
permissions are validated by the DRM helpers.
As a side effect, nouveau_ttm_vm_ops and nouveau_ttm_fault() are now
implemented in nouveau's GEM code.
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change also allows to support prime-based mmap via DRM's helper
drm_gem_prime_mmap().
Permission checks are implemented by drm_gem_mmap(), with an additional
check for radeon_ttm_tt_has_userptr() in the GEM object function. The
function radeon_verify_access() is now unused and has thus been removed.
As a side effect, radeon_ttm_vm_ops and radeon_ttm_fault() are now
implemented in amdgpu's GEM code.
v3:
* remove unnecessary checks from mmap (Christian)
v2:
* rename radeon_ttm_vm_ops and radeon_ttm_fault() to
radeon_gem_vm_ops and radeon_gem_fault() (Christian)
* fix commit description (Alex)
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change resolves several inconsistencies between regular mmap and
prime-based mmap. The vm_ops field in vma is now set for all mmap'ed
areas. Previously it way only set for regular mmap calls, prime-based
mmap used TTM's default vm_ops. The function amdgpu_verify_access() is
no longer being called and therefore removed by this patch.
As a side effect, amdgpu_ttm_vm_ops and amdgpu_ttm_fault() are now
implemented in amdgpu's GEM code.
v4:
* rebased
v3:
* rename mmap function to amdgpu_gem_object_mmap() (Christian)
* remove unnecessary checks from mmap (Christian)
v2:
* rename amdgpu_ttm_vm_ops and amdgpu_ttm_fault() to
amdgpu_gem_vm_ops and amdgpu_gem_fault() (Christian)
* the check for kfd_bo has meanwhile been removed
Problem:
When device goes into runtime suspend due to prolonged
inactivity (e.g. BACO sleep) and then hot unplugged,
PCI core will try to wake up the device as part of
unplug process. Since the device is gone all HW
programming during rpm resume fails leading
to a bad SW state later during pci remove handling.
Fix:
Use a flag we use for PCIe error recovery to avoid
accessing registres. This allows to successfully complete
rpm resume sequence and finish pci remove.
Chris Wilson [Fri, 21 May 2021 18:32:13 +0000 (11:32 -0700)]
drm/i915/gt: Move engine setup out of set_default_submission
Now that we no longer switch back and forth between guc and execlists,
we no longer need to restore the backend's vfunc and can leave them set
after initialisation. The only catch is that we lose the submission on
wedging and still need to reset the submit_request vfunc on unwedging.
Paul Cercueil [Sun, 23 May 2021 17:04:15 +0000 (18:04 +0100)]
drm/ingenic: Add option to alloc cached GEM buffers
Alloc GEM buffers backed by noncoherent memory on SoCs where it is
actually faster than write-combine.
This dramatically speeds up software rendering on these SoCs, even for
tasks where write-combine memory should in theory be faster (e.g. simple
blits).
v3: The option is now selected per-SoC instead of being a module
parameter.
v5: - Fix drm_atomic_get_new_plane_state() used to retrieve the old
state
- Use custom drm_gem_fb_create()
- Only check damage clips and sync DMA buffers if non-coherent
buffers are used
Paul Cercueil [Sun, 23 May 2021 17:04:14 +0000 (18:04 +0100)]
drm: Add and export function drm_fb_cma_sync_non_coherent
This function can be used by drivers that use damage clips and have
CMA GEM objects backed by non-coherent memory. Calling this function
in a plane's .atomic_update ensures that all the data in the backing
memory have been written to RAM.
v3: - Only sync data if using GEM objects backed by non-coherent memory.
- Use a drm_device pointer instead of device pointer in prototype
v5: - Rename to drm_fb_cma_sync_non_coherent
- Invert loops for better cache locality
- Only sync BOs that have the non-coherent flag
- Move to drm_fb_cma_helper.c to avoid circular dependency
Paul Cercueil [Sun, 23 May 2021 17:04:13 +0000 (18:04 +0100)]
drm: Add support for GEM buffers backed by non-coherent memory
Having GEM buffers backed by non-coherent memory is interesting in the
particular case where it is faster to render to a non-coherent buffer
then sync the data cache, than to render to a write-combine buffer, and
(by extension) much faster than using a shadow buffer. This is true for
instance on some Ingenic SoCs, where even simple blits (e.g. memcpy)
are about three times faster using this method.
Add a 'map_noncoherent' flag to the drm_gem_cma_object structure, which
can be set by the drivers when they create the dumb buffer.
Since this really only applies to software rendering, disable this flag
as soon as the CMA objects are exported via PRIME.
v3: New patch. Now uses a simple 'map_noncoherent' flag to control how
the objects are mapped, and use the new dma_mmap_pages function.
v4: Make sure map_noncoherent is always disabled when creating GEM
objects meant to be used with dma-buf.
Zou Wei [Mon, 24 May 2021 07:20:54 +0000 (15:20 +0800)]
drm/vc4: hdmi: Fix PM reference leak in vc4_hdmi_encoder_pre_crtc_co()
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
The PM Runtime docs specifically call out the need to call
pm_runtime_dont_use_autosuspend() in the remove() callback if
pm_runtime_use_autosuspend() was called in probe():
> Drivers in ->remove() callback should undo the runtime PM changes done
> in ->probe(). Usually this means calling pm_runtime_disable(),
> pm_runtime_dont_use_autosuspend() etc.
We should do this. This fixes a warning splat that I saw when I was
testing out the panel-simple's remove().
Maxime Ripard [Fri, 7 May 2021 15:05:14 +0000 (17:05 +0200)]
drm/vc4: hdmi: Add a workqueue to set scrambling
It looks like some displays (like the LG 27UL850-W) don't enable the
scrambling when the HDMI driver enables it. However, if we set later the
scrambler enable bit, the display will work as expected.
Let's create delayed work queue to periodically look at the display
scrambling status, and if it's not set yet try to enable it again.
Maxime Ripard [Fri, 7 May 2021 15:05:12 +0000 (17:05 +0200)]
drm/vc4: hdmi: Check and warn if we can't reach 4kp60 frequencies
In order to reach the frequencies needed to output at 594MHz, the
firmware needs to be configured with the appropriate parameters in the
config.txt file (enable_hdmi_4kp60 and force_turbo).
Let's detect it at bind time, warn the user if we can't, and filter out
the relevant modes.
Maxime Ripard [Fri, 7 May 2021 15:05:10 +0000 (17:05 +0200)]
drm/vc4: hvs: Make the HVS bind first
We'll need to have the HVS binding before the HDMI controllers so that
we can check whether the firmware allows to run in 4kp60. Reorder a bit
the component list, and document the current constraints we're aware of.
Maxime Ripard [Fri, 7 May 2021 15:05:09 +0000 (17:05 +0200)]
drm/vc4: hdmi: Prevent clock unbalance
Since we fixed the hooks to disable the encoder at boot, we now have an
unbalanced clk_disable call at boot since we never enabled them in the
first place.
Let's mimic the state of the hardware and enable the clocks at boot if
the controller is enabled to get the use-count right.
Maxime Ripard [Fri, 7 May 2021 15:05:08 +0000 (17:05 +0200)]
drm/vc4: crtc: Lookup the encoder from the register at boot
At boot, we can't rely on the vc4_get_crtc_encoder since we don't have a
state yet and thus will not be able to figure out which connector is
attached to our CRTC.
However, we have a muxing bit in the CRTC register we can use to get the
encoder currently connected to the pixelvalve. We can thus read that
register, lookup the associated register through the vc4_pv_data
structure, and then pass it to vc4_crtc_disable so that we can perform
the proper operations.
Maxime Ripard [Fri, 7 May 2021 15:05:07 +0000 (17:05 +0200)]
drm/vc4: crtc: Fix vc4_get_crtc_encoder logic
The vc4_get_crtc_encoder function currently only works when the
connector->state->crtc pointer is set, which is only true when the
connector is currently enabled.
However, we use it as part of the disable path as well, and our lookup
will fail in that case, resulting in it returning a null pointer we
can't act on.
We can access the connector that used to be connected to that crtc
though using the old connector state in the disable path.
Since we want to support both the enable and disable path, we can
support it by passing the state accessor variant as a function pointer,
together with the atomic state.
Maxime Ripard [Fri, 7 May 2021 15:05:06 +0000 (17:05 +0200)]
drm/vc4: crtc: Pass the drm_atomic_state to config_pv
The vc4_crtc_config_pv will need to access the drm_atomic_state
structure and its only parent function, vc4_crtc_atomic_enable already
has access to it. Let's pass it as a parameter.
projects / kernel.git / log