| Age | Commit message (Collapse) | Author | Files | Lines |
|
- was previously part of acquire()
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
- preparation for GSP-RM
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
- these shouldn't be necessary now, and are done in acquire()/release()
- preparation for GSP-RM, where we don't control the supervisor
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Prior to this commit, KMS would call release() prior to modeset, and the
second supervisor interrupt would update SOR routing if needed.
Now, KMS will call release() post-modeset and update routing immediately.
- preparation for GSP-RM
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
- release() is being moved post-modeset, preserve hdmi behaviour for now
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
- was previously part of acquire()
- preparation for GSP-RM
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
- adds tracking for post-UPDATE modeset operations, similar to mst[mo]'s
- audio won't work on RM without this
- we should probably have been doing this anyway
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
- we'll want this info post-UPDATE for later patches
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
- use nv_encoder.conn instead, outp->conn never changes
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
- cleanup before additional changes
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
- was previously delayed until second supervisor interrupt
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
- preparing to move protocol-specific args out of acquire() again
- avoid re-acquiring acquired output, will matter when enforced later
- sor/pior done at same time due to shared tmds/dp handling
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
- preparing to move protocol-specific args out of acquire() again
- avoid re-acquiring acquired output, will matter when enforced later
- this one is basically just a rename
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
- preparing to move protocol-specific args out of acquire() again
- no code changes
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Now that we're supporting things like Ada and the GSP, there's situations
where we really need to actually know the display state that we're starting
with when loading the driver in order to prevent breaking GSP expectations.
The first step in doing this is making it so that we can read the current
state of IORs from nvkm in DRM, so that we can fill in said into into the
atomic state.
We do this by introducing an INHERIT ioctl to nvkm/nvif. This is basically
another form of ACQUIRE, except that it will only acquire the given output
path for userspace if it's already set up in hardware. This way, we can go
through and probe each outp object we have in DRM in order to figure out
the current hardware state of each one. If the outp isn't in use, it simply
returns -ENODEV.
This is also part of the work that will be required for implementing GSP
support for display. While the GSP should mostly work without this commit,
this commit should fix some edge case bugs that can occur on initial driver
load. This also paves the way for some of the initial groundwork for
fastboot support.
Signed-off-by: Lyude Paul <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
These will be made static later in the patch series, after the code that
uses them has been cleaned up in preparation for GSP-RM support.
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
- needed to support TMDS EDID on RM
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This will check the relevant hotplug pin and skip the DDC probe we
currently do if a display is present.
- preparation for GSP-RM.
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
- preparation for a bunch of API changes, to make diffs prettier
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Programming -1 (vc_start_slot, if alloc fails) into HW probably isn't
the best idea.
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Fixes some issues when running on top of RM.
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Some of these buffers are quite large, and there's no need to preserve
them across suspend.
Mark the contents as lost to speedup suspend/resume.
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Will initially be used to tag some large grctx allocations which don't
need to be saved, to speedup suspend/resume.
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
From Turing, HW will already have handled this and locked-down the
falcon before we get control. So this *should* be a no-op.
Signed-off-by: Ben Skeggs <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The u_memcpya() function is supposed to return error pointers on
error. Returning NULL will lead to an Oops.
Fixes: e3885f712134 ("nouveau/u_memcpya: use vmemdup_user")
Reviewed-by: Lyude Paul <[email protected]>
Reviewed-by: Danilo Krummrich <[email protected]>
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
I think there are limit checks in place for most things but the
new uAPI wants to not have them.
Add a limit check and use the vmemdup_user helper instead.
Signed-off-by: Dave Airlie <[email protected]>
Reviewed-by: Danilo Krummrich <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Always stop and re-start the scheduler in order to let the scheduler
free up the timedout job in case it got signaled. In case of exec jobs
the job type specific callback will take care to signal all fences and
tear down the channel.
Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI")
Signed-off-by: Danilo Krummrich <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Fix the following warning.
drivers/gpu/drm/nouveau/nouveau_fence.c:210:45: sparse: sparse:
incorrect type in initializer (different address spaces)
@@ expected struct nouveau_channel *chan
@@ got struct nouveau_channel [noderef] __rcu *channel
We're just about to emit the fence, there is nothing to protect against
yet, hence it is safe to just cast __rcu away.
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Fixes: 978474dc8278 ("drm/nouveau: fence: fix undefined fence state after emit")
Signed-off-by: Danilo Krummrich <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
On Meteorlake onwards, HW specs require that all user contexts that
run on render or compute engines and require PXP must enforce
run-alone bit in lrc. Add this enforcement for protected contexts.
Signed-off-by: Alan Previn <[email protected]>
Reviewed-by: Vivaik Balasubrawmanian <[email protected]>
Signed-off-by: John Harrison <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Update the GSC-fw input/output HECI packet size to match
updated internal fw specs.
Signed-off-by: Alan Previn <[email protected]>
Reviewed-by: Vivaik Balasubrawmanian <[email protected]>
Signed-off-by: John Harrison <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Update the max GSC-fw response time to match updated internal
fw specs. Because this response time is an SLA on the firmware,
not inclusive of i915->GuC->HW handoff latency, when submitting
requests to the GSC fw via intel_gsc_uc_heci_cmd_submit helpers,
start the count after the request hits the GSC command streamer.
Also, move GSC_REPLY_LATENCY_MS definition from pxp header to
intel_gsc_uc_heci_cmd_submit.h since its for any GSC HECI packet.
Signed-off-by: Alan Previn <[email protected]>
Reviewed-by: Vivaik Balasubrawmanian <[email protected]>
Signed-off-by: John Harrison <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
There was a recent update in the BSpec adding an extra step to the PLL
enable sequence, which is for programming the msgbus timer. Since we
also touch PHY registers during hw readout, let's do the programming
when starting a transaction rather than only when doing the PLL enable
sequence.
This might be the missing step that was causing the timeouts
that we have recently seen during C20 SRAM register programming
sequences. With this in place, we shouldn't need the logic to bump the
timer thresholds, since now we have a documented value that should be
set peform programming the registers. As such, let's also remove
intel_cx0_bus_check_and_bump_timer(), but keep the part that checks if
hardware really detected a timeout, which might be useful debugging
information.
v2:
- Use debug level instead of warning for the message notifying that
the hardware did not detect the timeout. (Mika)
- Got a new BSpec update clarifying that we need to program the msgbus
timer of both PHY lanes. Update the changes to reflect that.
(Gustavo)
BSpec: 64568
Cc: Mika Kahola <[email protected]>
Signed-off-by: Gustavo Sousa <[email protected]>
Reviewed-by: Mika Kahola <[email protected]>
Signed-off-by: Matt Roper <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
If a sink is removed in the middle of payload addition
drm_dp_add_payload_part1() will fail as expected, either not finding the
payload's MST port or failing the payload-add AUX transaction.
Based on the above tune the error message down to a debug messge.
Cc: Lyude Paul <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
If a sink is removed in the middle of payload addition the corresponding
AUX transfer will fail as expected, so tune the error message down to a
debug messge.
Cc: Wayne Lin <[email protected]>
Cc: Lyude Paul <[email protected]>
Cc: [email protected]
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Return an error during payload addition if the payload port isn't
found. This shouldn't change the behavior since only the i915 driver
checks the return value, printing an error message in case of a failure.
While at it simplify the control flow.
Cc: Wayne Lin <[email protected]>
Cc: Lyude Paul <[email protected]>
Cc: [email protected]
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Fix the NULL dereference leading to the following stack trace:
[ 129.687181] i915 0000:00:02.0: [drm:drm_dp_add_payload_part1 [drm_display_helper]] VCPI 1 for port 000000005be4423e not in topology, not creating a payload to remote
[ 129.687257] BUG: kernel NULL pointer dereference, address: 0000000000000560
[ 129.694276] #PF: supervisor read access in kernel mode
[ 129.699459] #PF: error_code(0x0000) - not-present page
[ 129.704612] PGD 0 P4D 0
[ 129.707178] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 129.711556] CPU: 2 PID: 1623 Comm: Xorg Tainted: G U 6.6.0-rc1-imre+ #985
[ 129.719744] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023
[ 129.732509] RIP: 0010:drm_dp_mst_topology_put_port+0x19/0x170 [drm_display_helper]
[ 129.740111] Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 89 fb 48 83 ec 08 <48> 8b 87 60 05 00 00 44 8b 0f 48 8b 70 58 41 83 e9 01 48 85 f6 74
[ 129.758842] RSP: 0018:ffffc90001daf900 EFLAGS: 00010286
[ 129.764104] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000
[ 129.771246] RDX: 0000000000000000 RSI: ffffffff9e73d613 RDI: 0000000000000000
[ 129.778394] RBP: ffffc90001daf930 R08: 0000000000000000 R09: 0000000000000020
[ 129.785533] R10: 0000000000ffff10 R11: 000000000000000f R12: ffff888116c65e40
[ 129.792680] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 129.799822] FS: 00007f39f74b1a80(0000) GS:ffff88840f680000(0000) knlGS:0000000000000000
[ 129.807913] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 129.813670] CR2: 0000000000000560 CR3: 0000000138b88000 CR4: 0000000000750ee0
[ 129.820815] PKRU: 55555554
[ 129.823551] Call Trace:
[ 129.826022] <TASK>
[ 129.828154] ? show_regs+0x65/0x70
[ 129.831599] ? __die+0x24/0x70
[ 129.834683] ? page_fault_oops+0x160/0x480
[ 129.838824] ? dev_printk_emit+0x83/0xb0
[ 129.842797] ? do_user_addr_fault+0x2e2/0x680
[ 129.847175] ? exc_page_fault+0x78/0x180
[ 129.851143] ? asm_exc_page_fault+0x27/0x30
[ 129.855353] ? drm_dp_mst_topology_put_port+0x19/0x170 [drm_display_helper]
[ 129.862354] drm_dp_add_payload_part1+0x85/0x100 [drm_display_helper]
[ 129.868832] intel_mst_pre_enable_dp+0x1ef/0x240 [i915]
[ 129.874170] intel_encoders_pre_enable+0x83/0xa0 [i915]
[ 129.879524] hsw_crtc_enable+0xbe/0x750 [i915]
[ 129.884095] intel_enable_crtc+0x68/0xa0 [i915]
[ 129.888752] skl_commit_modeset_enables+0x2c4/0x5d0 [i915]
[ 129.894365] intel_atomic_commit_tail+0x765/0x1070 [i915]
[ 129.899885] intel_atomic_commit+0x3ba/0x400 [i915]
[ 129.904892] drm_atomic_commit+0x96/0xd0 [drm]
[ 129.909405] ? __pfx___drm_printfn_info+0x10/0x10 [drm]
[ 129.914698] drm_atomic_helper_set_config+0x7e/0xc0 [drm_kms_helper]
[ 129.921102] drm_mode_setcrtc+0x5af/0x8d0 [drm]
[ 129.925695] ? __pfx_drm_mode_setcrtc+0x10/0x10 [drm]
[ 129.930810] drm_ioctl_kernel+0xc4/0x170 [drm]
[ 129.935317] drm_ioctl+0x2a4/0x520 [drm]
[ 129.939305] ? __pfx_drm_mode_setcrtc+0x10/0x10 [drm]
[ 129.944415] ? __fget_light+0xa5/0x110
[ 129.948212] __x64_sys_ioctl+0x98/0xd0
[ 129.951985] do_syscall_64+0x37/0x90
[ 129.955581] entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload allocation/removement")
Cc: Wayne Lin <[email protected]>
Cc: Lyude Paul <[email protected]>
Cc: [email protected]
Reviewed-by: Lyude Paul <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Add handling of arbitration lost event.
Signed-off-by: Jernej Skrabec <[email protected]>
Reviewed-by: Robert Foss <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
As a result of the recent Kconfig reworks, the default settings for the
framebuffer interfaces changed in unexpected ways:
Configurations that leave CONFIG_FB disabled but use DRM now get
DRM_FBDEV_EMULATION by default. This also turns on the deprecated /dev/fb
device nodes for machines that don't actually want it.
In turn, configurations that previously had DRM_FBDEV_EMULATION enabled
now only get the /dev/fb front-end but not the more useful framebuffer
console, which is not selected any more.
We had previously decided that any combination of the three frontends
(FB_DEVICE, FRAMEBUFFER_CONSOLE and LOGO) should be selectable, but the
new default settings mean that a lot of defconfig files would have to
get adapted.
Change the defaults back to what they were in Linux 6.5:
- Leave DRM_FBDEV_EMULATION turned off unless CONFIG_FB
is enabled. Previously this was a hard dependency but now the two are
independent. However, configurations that enable CONFIG_FB probably
also want to keep the emulation for DRM, while those without FB
presumably did that intentionally in the past.
- Leave FB_DEVICE turned off for FB=n. Following the same
logic, the deprecated option should not automatically get enabled
here, most users that had FB turned off in the past do not want it,
even if they want the console
- Turn the FRAMEBUFFER_CONSOLE option on if
DRM_FBDEV_EMULATION is set to avoid having to change defconfig
files that relied on it being selected unconditionally in the past.
This also makes sense since both LOGO and FB_DEVICE are now disabled
by default for builds without CONFIG_FB, but DRM_FBDEV_EMULATION
would make no sense if all three are disabled.
Fixes: a5ae331edb02b ("drm: Drop select FRAMEBUFFER_CONSOLE for DRM_FBDEV_EMULATION")
Fixes: 701d2054fa317 ("fbdev: Make support for userspace interfaces configurable")
Reported-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Acked-by: Thomas Zimmermann <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
It's not necessary to carry separate suspended status information in
intel_runtime_pm struct as this information is already in underlying device
structure. Remove it and use pm_runtime_suspended() to obtain suspended
status information when needed.
Cc: Jani Nikula <[email protected]>
Cc: Imre Deak <[email protected]>
Signed-off-by: Jouni Högander <[email protected]>
Acked-by: Jani Nikula <[email protected]>
Reviewed-by: Imre Deak <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
`strncpy` is deprecated for use on NUL-terminated destination strings [1].
We should prefer more robust and less ambiguous string interfaces.
A suitable replacement is `strscpy` [2] due to the fact that it guarantees
NUL-termination on the destination buffer without unnecessarily NUL-padding.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: [email protected]
Signed-off-by: Justin Stitt <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/20230914-strncpy-drivers-gpu-drm-nouveau-nvkm-engine-pm-base-c-v1-1-4b09ed453f84@google.com
|
|
`strncpy` is deprecated for use on NUL-terminated destination strings [1].
We should prefer more robust and less ambiguous string interfaces.
A suitable replacement is `strscpy` [2] due to the fact that it guarantees
NUL-termination on the destination buffer without unnecessarily NUL-padding.
There is likely no bug in the current implementation due to the safeguard:
| cname[sizeof(cname) - 1] = '\0';
... however we can provide simpler and easier to understand code using
the newer (and recommended) `strscpy` api.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: [email protected]
Signed-off-by: Justin Stitt <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/20230914-strncpy-drivers-gpu-drm-nouveau-nvkm-core-firmware-c-v1-1-3aeae46c032f@google.com
|
|
`strncpy` is deprecated and as such we should prefer more robust and
less ambiguous string interfaces.
A suitable replacement is `strscpy_pad` due to the fact that it
guarantees NUL-termination on the destination buffer whilst also
maintaining the NUL-padding behavior that `strncpy` provides. I am not
sure whether NUL-padding is strictly needed but I see in
`nvif_object_ctor()` args is memcpy'd elsewhere so I figured we'd keep
the same functionality.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://github.com/KSPP/linux/issues/90
Cc: [email protected]
Signed-off-by: Justin Stitt <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/20230914-strncpy-drivers-gpu-drm-nouveau-nvif-client-c-v1-1-dc3b3719fcb4@google.com
|
|
If we can't load the HuC due to an injected failure, we don't want
to throw and error and trip CI. Using the gt_probe_error macro for
logging ensure that the error is only printed if it wasn't explicitly
injected.
v2: keep the line to less than 100 characters (checkpatch).
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/7061
Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Reviewed-by: Andi Shyti <[email protected]> #v1
Reviewed-by: John Harrison <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
When testing the d71 writeback layer function,
the output format is set to NV12, and the following error message is displayed:
[drm:komeda_fb_is_layer_supported] Layer TYPE: 4 doesn't support fb FMT: NV12 little-endian (0x3231564e) with modifier: 0x0..
Check the d71 data manual, writeback layer output formats includes NV12 format.
Signed-off-by: baozhu.liu <[email protected]>
Signed-off-by: Liviu Dudau <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
engine->stats is a union of execlist and guc stat objects. When execlist
specific fields are initialized, the initial state of guc stats is
affected. This results in bad busyness values when using GuC mode. Move
the execlist initialization from common code to execlist specific code.
Fixes: 77cdd054dd2c ("drm/i915/pmu: Connect engine busyness stats from GuC to pmu")
Signed-off-by: Umesh Nerlige Ramappa <[email protected]>
Reviewed-by: Alan Previn <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Invalidate instruction and State cache bit using INDIRECT_CTX on
every gpu context switch for gen12.
The goal of this workaround is to actually perform an explicit
invalidation of that cache (by re-writing the register) during every GPU
context switch, which is accomplished via a "workaround batchbuffer"
that's attached to the context via INDIRECT_CTX. (Matt Roper)
Please refer [1] for more reviews and comment on the same patch
[1] https://patchwork.freedesktop.org/series/123377/
v2:
- Remove extra parentheses from the condition (Lucas)
- Align spacing and new line (Lucas)
v3:
- Fix commit message.
v4:
- Only Gen12 changes are kept and Remove DG2+ condition (Matt Roper)
- Fix the commit message for r-b (Matt Roper)
- Rename the register bit in define
v5:
- Move out this workaround from golden context init (Matt Roper)
- Use INDIRECT_CTX to set bit on each GPU context switch (Matt Roper)
v6:
- Change IP Version base condition for Gen12 (Matt Roper)
- Made imperative form of commit version messages (Suraj)
- s/Added/Add in patch header (Suraj)
v7:
- In version descriptions s/Ropper/Roper (Matt Atwood)
BSpec: 11354
Cc: Lucas De Marchi <[email protected]>
Cc: Matt Roper <[email protected]>
Cc: Suraj Kandpal <[email protected]>
Cc: Matt Atwood <[email protected]>
Signed-off-by: Dnyaneshwar Bhadane <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Signed-off-by: Matt Roper <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Don't hide display probe in device info code.
Cc: Matt Roper <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Move gmdid selection one abstraction level higher.
Cc: Matt Roper <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Initializing i915->display.info.__device_info and DISPLAY_RUNTIME_INFO()
really belongs in display code. Move them there.
Cc: Matt Roper <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
While drm_mm test was converted form igt selftest to kunit, unexpected
value of "end" argument equal "start" was introduced to one of calls to a
function that executes the drm_test_mm_insert_range for specific start/end
pair of arguments. As a consequence, DRM_MM_BUG_ON(end <= start) is
triggered. Fix it by restoring the original value.
Fixes: fc8d29e298cf ("drm: selftest: convert drm_mm selftest to KUnit")
Signed-off-by: Janusz Krzysztofik <[email protected]>
Cc: "Maíra Canal" <[email protected]>
Cc: Arthur Grillo <[email protected]>
Cc: Javier Martinez Canillas <[email protected]>
Cc: Daniel Latypov <[email protected]>
Cc: [email protected] # v6.1+
Reviewed-by: Maíra Canal <[email protected]>
Signed-off-by: Maíra Canal <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|