Dave Airlie [Mon, 30 Jan 2023 02:43:10 +0000 (12:43 +1000)]
Merge tag 'drm-habanalabs-next-2023-01-26' of https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux into drm-next
This tag contains habanalabs driver and accel changes for v6.3:
- Moved the driver to the accel subsystem. Currently only the files were
moved (including the uapi file which was also renamed). This doesn't
include registering to the accel subsystem. This will probably be only
in the next kernel version.
- In case of decoder error (axi error) in Gaudi2, we can now find the exact
IP that initiated the erroneous transaction and print the details for
better debug.
- Add more trace events. We now can trace mmio transactions and communication
with the preboot firmware.
- Add to Gaudi2 support for abrupt reset that is done by the firmware. This
was support so far only for Gaudi1.
- Add uAPI to flush memory transactions (to the device memory). This is
needed by the communications library in case of doing p2p with a host NIC
which access our HBM directly through the PCI BAR.
- Add uAPI to pass-through a request from user-space to firmware and get the
result back to user-space. This will allow the driver code to avoid the
need to add new packet (in the communication channel with the firmware) for
every new request type.
- Remove the option to export dma-buf by memory allocation handle in our uAPI.
This was planned for Gaudi2 but was never used. Instead, we will do export
by memory address (same as Gaudi1). In addition, we added the option to
specify an offset to the address. This is needed in Gaudi2 because there
the user allocates the entire HBM in one allocation, but would like to
export only small part of it.
- Multiple bug fixes, refactors and small optimizations.
Jeffrey Hugo [Thu, 19 Jan 2023 16:26:08 +0000 (09:26 -0700)]
docs: accel: Fix debugfs path
The device specific directory in debugfs does not have "accel". For
example, the documentation says device 0 should have a debugfs entry as
/sys/kernel/debug/accel/accel0/ but in reality the entry is
/sys/kernel/debug/accel/0/
Fix the documentation to match the implementation.
Fixes: 8c5577a5ccc6 ("doc: add documentation for accel subsystem") Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Koby Elbaz [Sun, 15 Jan 2023 10:38:53 +0000 (12:38 +0200)]
habanalabs/gaudi2: find decode error root cause
When a decode error happens, we often don't know the exact root
cause (the erroneous address that was accessed) and the exact engine
that created the erroneous transaction.
To find out, we need to go over all the relevant register blocks
in the ASIC. Once we find the relevant engine, we print its details
and the offending address.
This helps tremendously when debugging an error that was created
by running a user workload.
Tomer Tayar [Tue, 17 Jan 2023 17:45:24 +0000 (19:45 +0200)]
habanalabs: clear in_compute_reset when escalating to hard reset
If resetting device upon release while the release watchdog work is
scheduled, the compute reset is replaced with hard reset.
In this case, need to clear the in_compute_reset indication in the
device reset information structure.
Moti Haimovski [Tue, 3 Jan 2023 08:28:24 +0000 (10:28 +0200)]
habanalabs: enhance info printed on FW load errors
This commit enhances the following error messages to also provide the
type of error occurred, this in order to ease debugging of errors
detected during firmware-load.
Completion timestamp is taken during the actual command submission
release. As the release happens in a work queue, the timestamp taken
is not accurate. Hence, we will take the timestamp in the interrupt
handler itself while propagating it to the release function.
Dani Liberman [Mon, 16 Jan 2023 10:00:05 +0000 (12:00 +0200)]
habanalabs/gaudi2: fix emda range registers razwi handling
Handling edma razwi is different than all other engines since edma
uses sft routers. For hbw transactions sft router contain separate
interface for each edma and for lbw there is common interface for
both edma engines of the same dcore.
To handle the razwi correctly we need to:
1. Simplify the calculation of the sft router address.
2. Add razwi handling for edma qm errors, since edma qman doesn't
reports axi error response.
Koby Elbaz [Wed, 11 Jan 2023 13:43:21 +0000 (15:43 +0200)]
habanalabs: block soft-reset on an unusable device
A device with status malfunction indicates that it can't be used.
In such a case we do not support certain reset types, e.g.,
all kinds of soft-resets (compute reset, inference soft-reset),
and reset upon device release.
A hard-reset is the only way that an unusable device can change its
status. All other reset procedures can't put the device in a reset
procedure, which might ultimately cause the device to change its
status, unintentionally, to become operational again.
Such a scenario has recently occurred, when a user requested
a hard-reset while another heavy user workload was ongoing (reset
request is queued).
Since the workload couldn't finish within reset's timeout limits, the
reset has failed and set a device status malfunction.
Eventually, when the user released the FD, an unsuccessful soft-reset
occurred, hence followed by an additional hard-reset that changed the
ASICs status back to be operational.
Dani Liberman [Tue, 10 Jan 2023 13:48:36 +0000 (15:48 +0200)]
habanalabs/gaudi2: print page fault axi transaction id
AXI transaction id holds information about the initiator which caused
the page fault. In the future it will be translated automatically by
driver to an initiator name.
Jeffrey Hugo [Tue, 17 Jan 2023 17:45:58 +0000 (10:45 -0700)]
accel: Add .mmap to DRM_ACCEL_FOPS
In reviewing the ivpu driver, DEFINE_DRM_ACCEL_FOPS could have been used
if DRM_ACCEL_FOPS defined .mmap to be drm_gem_mmap. Lets add that since
accel drivers are a variant of drm drivers, modern drm drivers are
expected to use GEM, and mmap() is a common operation that is expected
to be heavily used in accel drivers thus the common accel driver should
be able to just use DEFINE_DRM_ACCEL_FOPS() for convenience.
Jeffrey Hugo [Tue, 17 Jan 2023 18:04:30 +0000 (11:04 -0700)]
MAINTAINERS/ACCEL: Add include/drm/drm_accel.h to the accel entry
get_maintainer.pl does not suggest Oded Gabbay, the DRM COMPUTE
ACCELERATORS DRIVERS AND FRAMEWORK maintainer for changes that touch
the Accel Subsystem header - drm_accel.h. This is because that file is
missing from the Accel Subsystem entry. Fix this.
Dani Liberman [Thu, 5 Jan 2023 15:12:28 +0000 (17:12 +0200)]
habanalabs/gaudi2: read mmio razwi information
In gaudi2 there night be different routers for low b/w and high b/w
transactions. But in the code that collects razwi information, we used
the same router for high b/w and low b/w.
Fixed it by reading the information also from low b/w routers.
farah kassabri [Tue, 10 Jan 2023 10:29:55 +0000 (12:29 +0200)]
habanalabs: fix bug in timestamps registration code
Protect re-using the same timestamp buffer record before actually
adding it to the to interrupt wait list.
Mark ts buff offset as in use in the spinlock protection area of the
interrupt wait list to avoid getting in the re-use section in
ts_buff_get_kernel_ts_record before adding the node to the list.
this scenario might happen when multiple threads are racing on
same offset and one thread could set data in the ts buff in
ts_buff_get_kernel_ts_record then the other thread takes over
and get to ts_buff_get_kernel_ts_record and we will try
to re-use the same ts buff offset then we will try to
delete a non existing node from the list.
Gustavo A. R. Silva [Tue, 10 Jan 2023 01:39:47 +0000 (19:39 -0600)]
habanalabs: Replace zero-length arrays with flexible-array members
Zero-length arrays are deprecated[1] and we are moving towards
adopting C99 flexible-array members instead. So, replace zero-length
arrays in a couple of structures with flex-array members.
This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
routines on memcpy() and help us make progress towards globally
enabling -fstrict-flex-arrays=3 [2].
Dani Liberman [Tue, 3 Jan 2023 22:05:03 +0000 (00:05 +0200)]
habanalabs/gaudi2: remove use of razwi info received from f/w
Because f/w does not update razwi info when sending events, remove the
use of it.
The driver is responsible to check if razwi happened and to
collect razwi data.
Ohad Sharabi [Wed, 30 Nov 2022 12:02:00 +0000 (14:02 +0200)]
habanalabs: define events to trace PCI LBW access
There are cases where it may be useful to dump the whole LBW configs.
Yet, doing so while spamming the kernel log will probably shade other
important messages since the LBW access is done in sheer volume.
To answer this we add trace events for those too.
Koby Elbaz [Fri, 23 Dec 2022 13:02:05 +0000 (15:02 +0200)]
habanalabs: protect access to dynamic mem 'user_mappings'
When HL_INFO_USER_MAPPINGS IOCTL is called, we copy_to_user from
a dynamically allocated memory - 'user_mappings'.
Since freeing/allocating it happens in runtime (upon a page fault),
it not unlikely to access it even before being initially allocated
(i.e., accessing a NULL pointer).
The solution is to simply mark the spot when the err info has been
collected, and that way to know whether err info (either page fault
or RAZWI) is available to be read.
Tom Rix [Sat, 7 Jan 2023 18:48:27 +0000 (13:48 -0500)]
habanalabs: remove redundant memset
From reviewing the code, the line
memset(kdata, 0, usize);
is not needed because kdata is either zeroed by
kdata = kzalloc(asize, GFP_KERNEL);
when allocated at runtime or by
char stack_kdata[128] = {0};
at compile time.
Ofir Bitton [Sun, 25 Dec 2022 14:27:24 +0000 (16:27 +0200)]
habanalabs/gaudi: allow device acquire while in debug mode
During device acquire, the driver is using a QMAN for clearing some
registers. In order to avoid internal races, the driver verifies
the device is idle before submitting the register clear job.
This check introduces an issue, as debug mode will cause the device
to be non-idle which will lead to device acquire failure.
In order to overcome this issue we can entirely remove the idle
check as the driver is using the QMAN only when there is no active
context.
Oded Gabbay [Thu, 22 Dec 2022 10:28:54 +0000 (12:28 +0200)]
habanalabs: move some prints to debug level
When entering an IOCTL, the driver prints a message in case device is
not operational. This message should be printed in debug level as
it can spam the kernel log and it is not an error.
Ohad Sharabi [Sun, 18 Dec 2022 07:42:34 +0000 (09:42 +0200)]
habanalabs: add uapi to flush inbound HBM transactions
When doing p2p with a NIC device, the NIC needs to make sure all the
writes to the HBM (through the PCI bar of the Gaudi device) were
flushed.
It can be done by either the NIC or the host reading through the PCI
bar.
To support the host side, we supply a simple uapi to perform this flush
through the driver, because the user can't create such a transaction
by itself (the PCI bar isn't exposed to normal users).
Oded Gabbay [Mon, 26 Dec 2022 21:05:00 +0000 (23:05 +0200)]
habanalabs: move driver to accel subsystem
Now that we have a subsystem for compute accelerators, move the
habanalabs driver to it.
This patch only moves the files and fixes the Makefiles. Future
patches will change the existing code to register to the accel
subsystem and expose the accel device char files instead of the
habanalabs device char files.
Update the MAINTAINERS file to reflect this change.
Tomer Tayar [Thu, 15 Dec 2022 14:36:53 +0000 (16:36 +0200)]
habanalabs: fix dma-buf release handling if dma_buf_fd() fails
The dma-buf private object is freed if a call to dma_buf_fd() fails,
and because a file was already associated with the dma-buf in
dma_buf_export(), the release op will be called and will use this
object.
Mark the 'priv' field as NULL in this case, and avoid accessing it from
the release op.
farah kassabri [Wed, 16 Nov 2022 13:40:30 +0000 (15:40 +0200)]
habanalabs: pass-through request from user to f/w
Add a uAPI, as part of the INFO IOCTL, to allow users to send
requests directly to f/w, according to a pre-defined set of opcodes
that the f/w exposes.
The f/w will put the result in a kernel-allocated buffer, which the
driver will then copy to the user-supplied buffer.
This will allow f/w tools to communicate directly with the f/w
without the need to add a new uAPI to the driver for each new type
of request.
Tal Cohen [Thu, 1 Dec 2022 14:37:30 +0000 (16:37 +0200)]
habanalabs: support receiving ascii message from preboot f/w
An Ascii message that is sent from preboot towards the driver
will indicate the specific error that occurred on the f/w.
This commit supports that message and parse the ascii string
in order to print it into the kernel log
The commit also changes the way the descriptor struct is declared.
While its size increased (it now above 1024 bytes), it will be
allocated by using kmalloc instead of stack declaration.
Ohad Sharabi [Wed, 30 Nov 2022 12:26:10 +0000 (14:26 +0200)]
habanalabs/gaudi2: wait for preboot ready if HW state is dirty
Instead of waiting for BTM indication we should wait for preboot ready.
Consider the below scenario:
1. FW update is being triggered
- setting the dirty bit
2. hard reset will be triggered due to the dirty bit
3. FW initiates the reset:
- dirty bit cleared
- BTM indication cleared
- preboot ready indication cleared
4. during hard reset:
- BTM indication will be set
- BIST test performed and another reset triggered
5. only after this reset the preboot will set the preboot ready
When polling on BTM indication alone we can lose sync with FW while
trying to communicate with FW that is during reset.
To overcome this we will always wait to preboot ready indication.
Tomer Tayar [Sun, 4 Dec 2022 20:09:08 +0000 (22:09 +0200)]
habanalabs: fix handling of wait CS for interrupting signals
The -ERESTARTSYS return value is not handled correctly when a signal is
received while waiting for CS completion.
This can lead to bad output values to user when waiting for a single CS
completion, and more severe, it can cause a non-stopping loop when
waiting to multi-CS completion and until a CS timeout.
Fix the handling and exit the waiting if this return value is received.
Ohad Sharabi [Thu, 10 Nov 2022 11:43:02 +0000 (13:43 +0200)]
habanalabs: fix dmabuf to export only required size
This patch fixes a bug that was found in the dmabuf flow.
Bug description as found on Gaudi2 device:
1. User allocates 4MB of device memory
- Note that although the allocation size was 4MB the HMMU allocated
a full page of 768MB to back the request.
- The user gets a memory handle that points to a single page (768MB)
- Mapping the handle, the user gets virtual address to the start of
the page.
2. User exports the buffer
3. User registers the exported buffer in the importer. This flow has
a callback to the exporter which in turn converts the phys_page_pack
to an SG list for the importer. This SG list is of single entry of
size 768MB. However, the size that was passed to the importer was
only 4MB.
The solution for this is to make sure the importer gets exposure only
to the exported size.
This will be done by fixing the SG created by the exporter to be of
the total size of the actual exported memory requested by the user.
Ohad Sharabi [Mon, 14 Nov 2022 10:16:37 +0000 (12:16 +0200)]
habanalabs: modify export dmabuf API
A previous commit deprecated the option to export from handle, leaving
the code with no support for devices with virtual memory.
This commit modifies the export API in a way that unifies the uAPI to
user address for both cases (i.e. with and without MMU support) and add
the actual support for devices with virtual memory.
Ohad Sharabi [Tue, 29 Nov 2022 07:13:34 +0000 (09:13 +0200)]
habanalabs: helper function to validate export params
Validate export parameters in a dedicated function instead of in the
main export flow.
This will be useful later when support to export dmabuf for devices
with virtual memory will be added.
Ohad Sharabi [Tue, 29 Nov 2022 12:02:07 +0000 (14:02 +0200)]
habanalabs: remove support to export dmabuf from handle
The API to the user which allows exporting DMA buffer from handle is
deprecated here. It was never used as it is relevant only for Gaudi2,
and the user stack has yet to add support for dmabuf in Gaudi2.
Looking forward, a modified API to export DMA buffer for ASICs that
supports virtual memory will be added.
Until the new API will be ready- exporting DMA buffer will not be
supported for ASICs with virtual memory.
Ofir Bitton [Wed, 30 Nov 2022 12:35:32 +0000 (14:35 +0200)]
habanalabs/gaudi2: support abrupt device reset event
In certain scenarios, firmware might encounter a fatal event for
which a device reset is required. Hence, a proper notification
is needed for driver to be aware and initiate a reset sequence.
In secured environments the reset will be performed by firmware
without an explicit request from the driver.
Tomer Tayar [Wed, 30 Nov 2022 10:07:06 +0000 (12:07 +0200)]
habanalabs: skip device idle check in hpriv_release if in reset
When user context is released and hpriv_release() is called, there is a
device idle status check, to understand if user has left the device not
idle and then a reset is required.
However, if the user process is killed because of device hard reset,
the device at this point would always be not idle, because the device
engines were already forcefully halted.
Modify hpriv_release() to skip the idle check if reset is in progress.
Ofir Bitton [Wed, 16 Nov 2022 15:27:26 +0000 (17:27 +0200)]
habanalabs/gaudi2: remove duplicated event prints
In order to reduce error log, we try to minimize the dumped rows
while keeping all relevant error info. In addition we completely
remove clock throttling debug logs.
Ohad Sharabi [Sun, 27 Nov 2022 10:38:49 +0000 (12:38 +0200)]
habanalabs: make set_dram_properties an ASIC function
As ASICs are evolving, we will need to update the DRAM properties at
various points because we may get different information from the f/w
at different points of the initialization.
This ASIC function is a foundation for this capability.
Tomer Tayar [Thu, 24 Nov 2022 09:12:38 +0000 (11:12 +0200)]
habanalabs: use dev_dbg() when hl_mmap_mem_buf_get() fails
As hl_mmap_mem_buf_get() is called also from IOCTLs which can have a
bad handle from user, modify the print for "no match to handle" to use
dev_dbg().
Calls to this function which are not dependent on user, already have an
error print when the function fails.
Tomer Tayar [Wed, 23 Nov 2022 13:09:43 +0000 (15:09 +0200)]
habanalabs: don't allow user to destroy CB handle more than once
The refcount of a CB buffer is initialized when user allocates a CB,
and is decreased when he destroys the CB handle.
If this refcount is increased also from kernel and user sends more than
one destroy requests for the handle, the buffer will be released/freed
and later be accessed when the refcount is put from kernel side.
To avoid it, prevent user from destroying the handle more than once.
Ofir Bitton [Thu, 24 Nov 2022 09:01:44 +0000 (11:01 +0200)]
habanalabs: don't notify user about clk throttling due to power
As clock throttling due to high power consumption can happen very
frequently and there is no real reason to notify the user about it,
we skip this notification in all asics.
Tomer Tayar [Tue, 8 Nov 2022 12:34:43 +0000 (14:34 +0200)]
habanalabs: abort waiting user threads upon error
User should close the FD when being notified about an error, after
which a device reset takes place.
However, if the user has pending threads that wait for completions,
the device release won't be called and eventually the watchdog timeout
will expire, leading to hard reset and killing the user process.
To avoid it, abort such waiting threads right after the error
notification, and block following waiting operations.
Tomer Tayar [Sun, 6 Nov 2022 18:29:18 +0000 (20:29 +0200)]
habanalabs: remove releasing of user threads from device release
The device file is not in use when hl_device_release() is called,
and there aren't any user threads that use IOCTLs to wait for
interrupts. Therefore there is no need to release them at this point.
farah kassabri [Sun, 13 Nov 2022 15:44:17 +0000 (17:44 +0200)]
habanalabs: read binning info from preboot
Sometimes we need the binning info at a very early state of the
driver initialization. Therefore, support was added in preboot to
provide the binning info as part of the f/w descriptor and the driver
can now use that.
Thomas Zimmermann [Wed, 25 Jan 2023 20:04:15 +0000 (21:04 +0100)]
drm/fbdev-generic: Rename struct fb_info 'fbi' to 'info'
The generic fbdev emulation names variables of type struct fb_info
both 'fbi' and 'info'. The latter seems to be more common in fbdev
code, so name fbi accordingly.
Also replace the duplicate variable in drm_fbdev_fb_destroy().
Thomas Zimmermann [Wed, 25 Jan 2023 20:04:14 +0000 (21:04 +0100)]
drm/fbdev-generic: Inline clean-up helpers into drm_fbdev_fb_destroy()
The fbdev framebuffer cleanup in drm_fbdev_fb_destroy() calls
drm_fbdev_release() and drm_fbdev_cleanup(). Inline both into the
caller. No functional changes.
Thomas Zimmermann [Wed, 25 Jan 2023 20:04:13 +0000 (21:04 +0100)]
drm/fbdev-generic: Minimize client unregistering
For uninitialized framebuffers, only release the DRM client and
free the fbdev memory. Do not attempt to clean up the framebuffer.
DRM fbdev clients have a two-step initialization: first create
the DRM client; then create the framebuffer device on the first
successful hotplug event. In cases where the client never creates
the framebuffer, only the client state needs to be released. We
can detect which case it is, full or client-only cleanup, by
looking at the presence of fb_helper's info field.
v3:
* fix typo in commit message (Javier)
* release client before unpreparing fbdev
v2:
* remove test for (fbi != NULL) in drm_fbdev_cleanup() (Sam)
Thomas Zimmermann [Wed, 25 Jan 2023 20:04:11 +0000 (21:04 +0100)]
drm/fb-helper: Initialize fb-helper's preferred BPP in prepare function
Initialize the fb-helper's preferred_bpp field early from within
drm_fb_helper_prepare(); instead of the later client hot-plugging
callback. This simplifies the generic fbdev setup function.
No real changes, but all drivers' fbdev code has to be adapted.
v3:
* build with CONFIG_DRM_FBDEV_EMULATION unset (kernel test bot)
Thomas Zimmermann [Wed, 25 Jan 2023 20:04:09 +0000 (21:04 +0100)]
drm/fbdev-generic: Initialize fb-helper structure in generic setup
Initialize the fb-helper structure immediately after its allocation
in drm_fbdev_generic_setup(). That will make it easier to fill it with
driver-specific values, such as the preferred BPP.
Thomas Zimmermann [Wed, 25 Jan 2023 20:04:07 +0000 (21:04 +0100)]
drm/client: Add hotplug_failed flag
Signal failed hotplugging with a flag in struct drm_client_dev. If set,
the client helpers will not further try to set up the fbdev display.
This used to be signalled with a combination of cleared pointers in
struct drm_fb_helper, which prevents us from initializing these pointers
early after allocation.
The change also harmonizes behavior among DRM clients. Additional DRM
clients will now handle failed hotplugging like fbdev does.
Thomas Zimmermann [Wed, 25 Jan 2023 20:04:06 +0000 (21:04 +0100)]
drm/client: Test for connectors before sending hotplug event
Test for connectors in the client code and remove a similar test
from the generic fbdev emulation. Do nothing if the test fails.
Not having connectors indicates a driver bug.
Deepak R Varma [Wed, 25 Jan 2023 15:07:14 +0000 (20:37 +0530)]
drm/nouveau/devinit: Convert function disable() to be void
The current design of callback function disable() of struct
nvkm_devinit_func is defined to return a u64 value. In its implementation
in the driver modules, the function always returns a fixed value 0. Hence
the design and implementation of this function should be enhanced to return
void instead of a fixed value. This change also eliminates untouched
return variables.
The change is identified using the returnvar.cocci Coccinelle semantic
patch script.
Dave Airlie [Wed, 25 Jan 2023 02:07:53 +0000 (12:07 +1000)]
Merge tag 'amd-drm-next-6.3-2023-01-20' of https://gitlab.freedesktop.org/agd5f/linux into drm-next
amd-drm-next-6.3-2023-01-20:
amdgpu:
- Secure display fixes
- Fix scaling
- Misc code cleanups
- Display BW alloc logic updates
- DCN 3.2 fixes
- Fix power reporting on certain firmwares for CZN/RN
- SR-IOV fixes
- Link training cleanup and code rework
- HDCP fixes
- Reserved VMID fix
- Documentation updates
- Colorspace fixes
- RAS updates
- GC11.0 fixes
- VCN instance harvesting fixes
- DCN 3.1.4/5 workarounds for S/G displays
- Add PCIe info to the INFO IOCTL
amdkfd:
- XNACK fix
UAPI:
- Add PCIe gen/lanes info to the amdgpu INFO IOCTL
Nesa ultimately plans to use this to make decisions about buffer placement optimizations
Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20790
Daniel Vetter [Tue, 24 Jan 2023 15:06:38 +0000 (16:06 +0100)]
Merge tag 'drm-intel-gt-next-2023-01-18' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
Driver Changes:
Fixes/improvements/new stuff:
- Fix workarounds on Gen2-3 (Tvrtko Ursulin)
- Fix HuC delayed load memory leaks (Daniele Ceraolo Spurio)
- Fix a BUG caused by impendance mismatch in dma_fence_wait_timeout and GuC (Janusz Krzysztofik)
- Add DG2 workarounds Wa_18018764978 and Wa_18019271663 (Matt Atwood)
- Apply recommended L3 hashing mask tuning parameters (Gen12+) (Matt Roper)
- Improve suspend / resume times with VT-d scanout workaround active (Andi Shyti, Chris Wilson)
- Silence misleading "mailbox access failed" warning in snb_pcode_read (Ashutosh Dixit)
- Fix null pointer dereference on HSW perf/OA (Umesh Nerlige Ramappa)
- Avoid trampling the ring during buffer migration (and selftests) (Chris Wilson, Matthew Auld)
- Fix DG2 visual corruption on small BAR systems by not forgetting to copy CCS aux state (Matthew Auld)
- More fixing of DG2 visual corruption by not forgetting to copy CCS aux state of backup objects (Matthew Auld)
- Fix TLB invalidation for Gen12.50 video and compute engines (Andrzej Hajda)
- Limit Wa_22012654132 to just specific steppings (Matt Roper)
- Fix userspace crashes due eviction not working under lock contention after the object locking conversion (Matthew Auld)
- Avoid double free is user deploys a corrupt GuC firmware (John Harrison)
- Fix 32-bit builds by using "%zu" to format size_t (Nirmoy Das)
- Fix a possible BUG in TTM async unbind due not reserving enough fence slots (Nirmoy Das)
- Fix potential use after free by not exposing the GEM context id to userspace too early (Rob Clark)
- Show clamped PL1 limit to the user (hwmon) (Ashutosh Dixit)
- Workaround unreliable reset on Jasperlake (Chris Wilson)
- Cover rest of SVG unit MCR registers (Gustavo Sousa)
- Avoid PXP log spam on platforms which do not support the feature (Alan Previn)
- Re-disable RC6p on Sandy Bridge to avoid GPU hangs and visual glitches (Sasa Dragic)
Future platform enablement:
- Manage uncore->lock while waiting on MCR register (Matt Roper)
- Enable Idle Messaging for GSC CS (Vinay Belgaumkar)
- Only initialize GSC in tile 0 (José Roberto de Souza)
- Media GT and Render GT share common GGTT (Aravind Iddamsetty)
- Add dedicated MCR lock (Matt Roper)
- Implement recommended caching policy (PVC) (Wayne Boyer)
- Add hardware-level lock for steering (Matt Roper)
- Check full IP version when applying hw steering semaphore (Matt Roper)
- Enable GuC GGTT invalidation from the start (Daniele Ceraolo Spurio)
- MTL GSC firmware support (Daniele Ceraolo Spurio, Jonathan Cavitt)
- MTL OA support (Umesh Nerlige Ramappa)
- MTL initial gt workarounds (Matt Roper)
Driver refactors:
- Hold forcewake and MCR lock over PPAT setup (Matt Roper)
- Acquire fw before loop in intel_uncore_read64_2x32 (Umesh Nerlige Ramappa)
- GuC filename cleanups and use submission API version number (John Harrison)
- Promote pxp subsystem to top-level of i915 (Alan Previn)
- Finish proofing the code agains object size overflows (Chris Wilson, Gwan-gyeong Mun)
- Start adding module oriented dmesg output (John Harrison)
Miscellaneous:
- Correct kerneldoc for intel_gt_mcr_wait_for_reg() (Matt Roper)
- Bump up sample period for busy stats selftest (Umesh Nerlige Ramappa)
- Make GuC default_lists const data (Jani Nikula)
- Fix table order verification to check all FW types (John Harrison)
- Remove some limited use register access wrappers (Jani Nikula)
- Remove struct_member macro (Andrzej Hajda)
- Remove hardcoded value with a macro (Nirmoy Das)
- Use helper func to find out map type (Nirmoy Das)
- Fix a static analysis warning (John Harrison)
- Consolidate VMA active tracking helpers (Andrzej Hajda)
- Do not cover all future platforms in TLB invalidation (Tvrtko Ursulin)
- Replace zero-length arrays with flexible-array members (Gustavo A. R. Silva)
- Unwind hugepages to drop wakeref on error (Chris Wilson)
- Remove a couple of superfluous i915_drm.h includes (Jani Nikula)
Merges:
- Merge drm/drm-next into drm-intel-gt-next (Rodrigo Vivi)
danvet: Fix up merge conflict in intel_uc_fw.c, we ended up with 2
copies of try_firmware_load() somehow.
Javier Martinez Canillas [Sat, 21 Jan 2023 19:09:30 +0000 (20:09 +0100)]
drm/ssd130x: Silence a `dubious: x & !y` warning
The sparse tool complains with the following warning:
$ make M=drivers/gpu/drm/solomon/ C=2
CC [M] drivers/gpu/drm/solomon/ssd130x.o
CHECK drivers/gpu/drm/solomon/ssd130x.c
drivers/gpu/drm/solomon/ssd130x.c:363:21: warning: dubious: x & !y
This seems to be a false positive in my opinion but still we can silence
the tool while making the code easier to read. Let's also add a comment,
to explain why the "com_seq" logical not is used rather than its value.
projects / users / willy / xarray.git / log