Re: [PATCH linux-next] drm: drop unneeded assignment in the fx_v6_0_enable_mgcg()

Hi, Le 21/08/2021 à 04:08, CGEL a écrit : From: Luo penghao The first assignment is not used. In order to keep the code style consistency of the whole file, the first 'data' assignment should be deleted. The clang_analyzer complains as follows: drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:2608:10:

Re: [PATCH 19/27] drm/i915/guc: Move guc_blocked fence to struct guc_state

On 8/18/2021 11:16 PM, Matthew Brost wrote: Move guc_blocked fence to struct guc_state as the lock which protects the fence lives there. s/ce->guc_blocked/ce->guc_state.blocked_fence/g Could also call it just ce->guc_state.blocked, blocked_fence sounds to me like the fence itself is

Re: [PATCH 17/27] drm/i915/guc: Flush G2H work queue during reset

On 8/18/2021 11:16 PM, Matthew Brost wrote: It isn't safe to scrub for missing G2H or continue with the reset until all G2H processing is complete. Flush the G2H work queue during reset to ensure it is done running. Might be worth moving this patch closer to "drm/i915/guc: Process all G2H

Re: [PATCH 15/27] drm/i915/guc: Reset LRC descriptor if register returns -ENODEV

On 8/18/2021 11:16 PM, Matthew Brost wrote: Reset LRC descriptor if a context register returns -ENODEV as this means we are mid-reset. Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface") Signed-off-by: Matthew Brost Reviewed-by: Daniele Ceraolo Spurio

Re: [PATCH 13/27] drm/i915/guc: Take context ref when cancelling request

On 8/18/2021 11:16 PM, Matthew Brost wrote: A context can get destroyed after cancelling a request so take a reference to context when cancelling a request. What's the exact race? AFAICS __i915_request_skip does not have a context_put(). Daniele Fixes: 62eaf0ae217d ("drm/i915/guc:

Re: [PATCH v3 15/15] drm/mediatek: add mediatek-drm of vdosys1 support for MT8195

Hi, Nancy: Nancy.Lin 於 2021年8月18日 週三 下午5:18寫道： > > Add driver data of mt8195 vdosys1 to mediatek-drm and modify drm for > multi-mmsys support. The two mmsys (vdosys0 and vdosys1) will bring > up two drm drivers, only one drm driver register as the drm device. > Each drm driver binds its own

[PATCH 18/27] drm/i915/guc: Update debugfs for GuC multi-lrc

Display the workqueue status in debugfs for GuC contexts that are in parent-child relationship. Signed-off-by: Matthew Brost --- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 51 ++- 1 file changed, 37 insertions(+), 14 deletions(-) diff --git

[PATCH 20/27] drm/i915/guc: Connect UAPI to GuC multi-lrc interface

Introduce 'set parallel submit' extension to connect UAPI to GuC multi-lrc interface. Kernel doc in new uAPI should explain it all. IGT: https://patchwork.freedesktop.org/patch/447008/?series=93071=1 media UMD: link to come v2: (Daniel Vetter) - Add IGT link and placeholder for media UMD link

[PATCH 19/27] drm/i915: Fix bug in user proto-context creation that leaked contexts

Set number of engines before attempting to create contexts so the function free_engines can clean up properly. Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") Signed-off-by: Matthew Brost Cc: --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-

[PATCH 22/27] drm/i915/guc: Add basic GuC multi-lrc selftest

Add very basic (single submission) multi-lrc selftest. Signed-off-by: Matthew Brost --- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 + .../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 180 ++ .../drm/i915/selftests/i915_live_selftests.h | 1 + 3 files changed, 182

[PATCH 24/27] drm/i915: Multi-BB execbuf

Allow multiple batch buffers to be submitted in a single execbuf IOCTL after a context has been configured with the 'set_parallel' extension. The number batches is implicit based on the contexts configuration. This is implemented with a series of loops. First a loop is used to find all the

[PATCH 26/27] drm/i915: Enable multi-bb execbuf

Enable multi-bb execbuf by enabling the set_parallel extension. Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c index

[PATCH 13/27] drm/i915/guc: Ensure GuC schedule operations do not operate on child contexts

In GuC parent-child contexts the parent context controls the scheduling, ensure only the parent does the scheduling operations. Signed-off-by: Matthew Brost --- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 24 ++- 1 file changed, 18 insertions(+), 6 deletions(-) diff --git

[PATCH 25/27] drm/i915/guc: Handle errors in multi-lrc requests

If an error occurs in the front end when multi-lrc requests are getting generated we need to skip these in the backend but we still need to emit the breadcrumbs seqno. An issues arrises because with multi-lrc breadcrumbs there is a handshake between the parent and children to make forwad progress.

[PATCH 21/27] drm/i915/doc: Update parallel submit doc to point to i915_drm.h

Update parallel submit doc to point to i915_drm.h Signed-off-by: Matthew Brost --- Documentation/gpu/rfc/i915_parallel_execbuf.h | 122 -- Documentation/gpu/rfc/i915_scheduler.rst | 4 +- 2 files changed, 2 insertions(+), 124 deletions(-) delete mode 100644

[PATCH 23/27] drm/i915/guc: Implement no mid batch preemption for multi-lrc

For some users of multi-lrc, e.g. split frame, it isn't safe to preempt mid BB. To safely enable preemption at the BB boundary, a handshake between to parent and child is needed. This is implemented via custom emit_bb_start & emit_fini_breadcrumb functions and enabled via by default if a context

[PATCH 16/27] drm/i915/guc: Insert submit fences between requests in parent-child relationship

The GuC must receive requests in the order submitted for contexts in a parent-child relationship to function correctly. To ensure this, insert a submit fence between the current request and last request submitted for requests / contexts in a parent child relationship. This is conceptually similar

[PATCH 17/27] drm/i915/guc: Implement multi-lrc reset

Update context and full GPU reset to work with multi-lrc. The idea is parent context tracks all the active requests inflight for itself and its' children. The parent context owns the reset replaying / canceling requests as needed. Signed-off-by: Matthew Brost ---

[PATCH 14/27] drm/i915/guc: Assign contexts in parent-child relationship consecutive guc_ids

Assign contexts in parent-child relationship consecutive guc_ids. This is accomplished by partitioning guc_id space between ones that need to be consecutive (1/16 available guc_ids) and ones that do not (15/16 of available guc_ids). The consecutive search is implemented via the bitmap API. This

[PATCH 06/27] drm/i915/guc: Take engine PM when a context is pinned with GuC submission

Taking a PM reference to prevent intel_gt_wait_for_idle from short circuiting while a scheduling of user context could be enabled. v2: (Daniel Vetter) - Add might_lock annotations to pin / unpin function Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/intel_context.c | 3 ++

[PATCH 27/27] drm/i915/execlists: Weak parallel submission support for execlists

A weak implementation of parallel submission (multi-bb execbuf IOCTL) for execlists. Basically doing as little as possible to support this interface for execlists - basically just passing submit fences between each request generated and virtual engines are not allowed. This is on par with what is

[PATCH 04/27] drm/i915/guc: Take GT PM ref when deregistering context

Taking a PM reference to prevent intel_gt_wait_for_idle from short circuiting while a deregister context H2G is in flight. FIXME: Move locking / structure changes into different patch Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/intel_context.c | 2 +

[PATCH 01/27] drm/i915/guc: Squash Clean up GuC CI failures, simplify locking, and kernel DOC

https://patchwork.freedesktop.org/series/93704/ Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/intel_context.c | 19 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 81 +- .../drm/i915/gt/intel_execlists_submission.c | 4 - drivers/gpu/drm/i915/gt/selftest_hangcheck.c |

[PATCH 03/27] drm/i915/guc: Connect the number of guc_ids to debugfs

For testing purposes it may make sense to reduce the number of guc_ids available to be allocated. Add debugfs support for setting the number of guc_ids. Signed-off-by: Matthew Brost --- .../gpu/drm/i915/gt/uc/intel_guc_debugfs.c| 31 +++

[PATCH 02/27] drm/i915/guc: Allow flexible number of context ids

Number of available GuC contexts ids might be limited. Stop referring in code to macro and use variable instead. Signed-off-by: Michal Wajdeczko Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/uc/intel_guc.h| 4 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 15

[PATCH 07/27] drm/i915/guc: Don't call switch_to_kernel_context with GuC submission

Calling switch_to_kernel_context isn't needed if the engine PM reference is taken while all contexts are pinned. By not calling switch_to_kernel_context we save on issuing a request to the engine. v2: (Daniel Vetter) - Add FIXME comment about pushing switch_to_kernel_context to backend

[PATCH 10/27] drm/i915/guc: Introduce context parent-child relationship

Introduce context parent-child relationship. Once this relationship is created all pinning / unpinning operations are directed to the parent context. The parent context is responsible for pinning all of its' children and itself. This is a precursor to the full GuC multi-lrc implementation but

[PATCH 11/27] drm/i915/guc: Implement parallel context pin / unpin functions

Parallel contexts are perma-pinned by the upper layers which makes the backend implementation rather simple. The parent pins the guc_id and children increment the parent's pin count on pin to ensure all the contexts are unpinned before we disable scheduling with the GuC / or deregister the

[PATCH 05/27] drm/i915: Add GT PM unpark worker

Sometimes it is desirable to queue work up for later if the GT PM isn't held and run that work on next GT PM unpark. Implemented with a list in the GT of all pending work, workqueues in the list, a callback to add a workqueue to the list, and finally a wakeref post_get callback that iterates /

[PATCH 15/27] drm/i915/guc: Implement multi-lrc submission

Implement multi-lrc submission via a single workqueue entry and single H2G. The workqueue entry contains an updated tail value for each request, of all the contexts in the multi-lrc submission, and updates these values simultaneously. As such, the tasklet and bypass path have been updated to

[PATCH 12/27] drm/i915/guc: Add multi-lrc context registration

Add multi-lrc context registration H2G. In addition a workqueue and process descriptor are setup during multi-lrc context registration as these data structures are needed for multi-lrc submission. Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/intel_context_types.h | 12 ++

[PATCH 09/27] drm/i915: Expose logical engine instance to user

Expose logical engine instance to user via query engine info IOCTL. This is required for split-frame workloads as these needs to be placed on engines in a logically contiguous order. The logical mapping can change based on fusing. Rather than having user have knowledge of the fusing we simply just

[PATCH 08/27] drm/i915: Add logical engine mapping

Add logical engine mapping. This is required for split-frame, as workloads need to be placed on engines in a logically contiguous manner. v2: (Daniel Vetter) - Add kernel doc for new fields Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 60

[PATCH 00/27] Parallel submission aka multi-bb execbuf

As discussed in [1] we are introducing a new parallel submission uAPI for the i915 which allows more than 1 BB to be submitted in an execbuf IOCTL. This is the implemenation for both GuC and execlists. In addition to selftests in the series, an IGT is available implemented in the first 4 patches

[PATCH 3/3] drm/panfrost: Clamp lock region to Bifrost minimum

When locking a region, we currently clamp to a PAGE_SIZE as the minimum lock region. While this is valid for Midgard, it is invalid for Bifrost, where the minimum locking size is 8x larger than the 4k page size. Add a hardware definition for the minimum lock region size (corresponding to

[PATCH 2/3] drm/panfrost: Use u64 for size in lock_region

Mali virtual addresses are 48-bit. Use a u64 instead of size_t to ensure we can express the "lock everything" condition as ~0ULL without relying on platform-specific behaviour. Signed-off-by: Alyssa Rosenzweig Suggested-by: Rob Herring Tested-by: Chris Morgan ---

[PATCH 1/3] drm/panfrost: Simplify lock_region calculation

In lock_region, simplify the calculation of the region_width parameter. This field is the size, but encoded as log2(ceil(size)) - 1. log2(ceil(size)) may be computed directly as fls(size - 1). However, we want to use the 64-bit versions as the amount to lock can exceed 32-bits. This avoids

[PATCH 0/3] drm/panfrost: Bug fixes for lock_region

Chris Morgan reported UBSAN errors in panfrost and tracked them down to the size computation in lock_region. This calculation is overcomplicated (seemingly cargo culted from kbase) and can be simplified with kernel helpers and some mathematical identities. The first patch in the series rewrites

Re: [PATCH 2/4] drm/dp_mst: Only create connector for connected end device

On Fri, 2021-08-20 at 11:20 +, Lin, Wayne wrote: > [Public] > > > -Original Message- > > From: Lyude Paul > > Sent: Thursday, August 19, 2021 2:59 AM > > To: Lin, Wayne ; dri-devel@lists.freedesktop.org > > Cc: Kazlauskas, Nicholas ; Wentland, Harry < > > harry.wentl...@amd.com>;

[PATCH 3/8] drm/etnaviv: stop abusing mmu_context as FE running marker

While the DMA frontend can only be active when the MMU context is set, the reverse isn't necessarily true, as the frontend can be stopped while the MMU state is kept. Stop treating mmu_context being set as a indication that the frontend is running and instead add a explicit property. Cc:

[PATCH 4/8] drm/etnaviv: keep MMU context across runtime suspend/resume

The MMU state may be kept across a runtime suspend/resume cycle, as we avoid a full hardware reset to keep the latency of the runtime PM small. Don't pretend that the MMU state is lost in driver state. The MMU context is pushed out when new HW jobs with a different context are coming in. The only

[PATCH 5/8] drm/etnaviv: exec and MMU state is lost when resetting the GPU

When the GPU is reset both the current exec state, as well as all MMU state is lost. Move the driver side state tracking into the reset function to keep hardware and software state from diverging. Cc: sta...@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach Tested-by: Michael Walle ---

[PATCH 6/8] drm/etnaviv: fix MMU context leak on GPU reset

After a reset the GPU is no longer using the MMU context and may be restarted with a different context. While the mmu_state proeprly was cleared, the context wasn't unreferenced, leading to a memory leak. Cc: sta...@vger.kernel.org # 5.4 Reported-by: Michael Walle Signed-off-by: Lucas Stach

[PATCH 7/8] drm/etnaviv: reference MMU context when setting up hardware state

Move the refcount manipulation of the MMU context to the point where the hardware state is programmed. At that point it is also known if a previous MMU state is still there, or the state needs to be reprogrammed with a potentially different context. Cc: sta...@vger.kernel.org # 5.4 Signed-off-by:

[PATCH 8/8] drm/etnaviv: add missing MMU context put when reaping MMU mapping

When we forcefully evict a mapping from the the address space and thus the MMU context, the MMU context is leaked, as the mapping no longer points to it, so it doesn't get freed when the GEM object is destroyed. Add the mssing context put to fix the leak. Cc: sta...@vger.kernel.org # 5.4

[PATCH 2/8] drm/etnaviv: put submit prev MMU context when it exists

The prev context is the MMU context at the time of the job queueing in hardware. As a job might be queued multiple times due to recovery after a GPU hang, we need to make sure to put the stale prev MMU context from a prior queuing, to avoid the reference and thus the MMU context leaking. Cc:

[PATCH 1/8] drm/etnaviv: return context from etnaviv_iommu_context_get

Being able to have the refcount manipulation in an assignment makes it much easier to parse the code. Cc: sta...@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach Tested-by: Michael Walle --- drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 3 +-- drivers/gpu/drm/etnaviv/etnaviv_gem.c| 3

Re: [git pull] drm fixes for 5.14-rc7

The pull request you sent on Fri, 20 Aug 2021 15:36:29 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-08-20-3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8ba9fbe1e4b8a28050c283792344ee8b6bc3465c Thank you! -- Deet-doot-dot, I am a bot.

Re: refactor the i915 GVT support

On Fri, Aug 20, 2021 at 04:17:24PM +0200, Christoph Hellwig wrote: > On Thu, Aug 19, 2021 at 04:29:29PM +0800, Zhenyu Wang wrote: > > I'm working on below patch to resolve this. But I met a weird issue in > > case when building i915 as module and also kvmgt module, it caused > > busy wait on

Re: [PATCH 07/27] Revert "drm/i915/gt: Propagate change in error status to children on unhold"

On Thu, Aug 19, 2021 at 1:22 AM Matthew Brost wrote: > > Propagating errors to dependent fences is wrong, don't do it. A selftest > in the following exposed the propagating of an error to a dependent > fence after an engine reset. I feel like we could still have a bit of a better message. Maybe

Re: [syzbot] WARNING in drm_gem_shmem_vm_open

On Fri, Aug 20, 2021 at 9:23 PM Thomas Zimmermann wrote: > Hi > > Am 20.08.21 um 17:45 schrieb syzbot: > > syzbot has bisected this issue to: > > Good bot! > > > > > commit ea40d7857d5250e5400f38c69ef9e17321e9c4a2 > > Author: Daniel Vetter > > Date: Fri Oct 9 23:21:56 2020 + > > > >

Re: [syzbot] WARNING in drm_gem_shmem_vm_open

Hi Am 20.08.21 um 17:45 schrieb syzbot: syzbot has bisected this issue to: Good bot! commit ea40d7857d5250e5400f38c69ef9e17321e9c4a2 Author: Daniel Vetter Date: Fri Oct 9 23:21:56 2020 + drm/vkms: fbdev emulation support Here's a guess. GEM SHMEM + fbdev emulation requires

Re: [Intel-gfx] [PATCH 10/27] drm/i915/guc: Don't enable scheduling on a banned context, guc_id invalid, not registered

On Fri, Aug 20, 2021 at 11:42:38AM -0700, Daniele Ceraolo Spurio wrote: > > > On 8/18/2021 11:16 PM, Matthew Brost wrote: > > When unblocking a context, do not enable scheduling if the context is > > banned, guc_id invalid, or not registered. > > > > Fixes: 62eaf0ae217d ("drm/i915/guc: Support

Re: [Intel-gfx] [PATCH 10/27] drm/i915/guc: Don't enable scheduling on a banned context, guc_id invalid, not registered

On 8/18/2021 11:16 PM, Matthew Brost wrote: When unblocking a context, do not enable scheduling if the context is banned, guc_id invalid, or not registered. Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Matthew Brost Cc: ---

Re: [Intel-gfx] [PATCH 09/27] drm/i915/guc: Kick tasklet after queuing a request

On Fri, Aug 20, 2021 at 11:31:56AM -0700, Daniele Ceraolo Spurio wrote: > > > On 8/18/2021 11:16 PM, Matthew Brost wrote: > > Kick tasklet after queuing a request so it submitted in a timely manner. > > > > Fixes: 3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for > > new

Re: [Intel-gfx] [PATCH 09/27] drm/i915/guc: Kick tasklet after queuing a request

On 8/18/2021 11:16 PM, Matthew Brost wrote: Kick tasklet after queuing a request so it submitted in a timely manner. Fixes: 3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for new inteface") Is this actually a bug or just a performance issue? in the latter case I don't

Re: [PATCH v3 1/3] dt-bindings: Add YAML bindings for NVDEC

On Wed, Aug 18, 2021 at 8:18 AM Thierry Reding wrote: > > On Wed, Aug 18, 2021 at 11:24:28AM +0300, Mikko Perttunen wrote: > > On 8/18/21 12:20 AM, Rob Herring wrote: > > > On Wed, Aug 11, 2021 at 01:50:28PM +0300, Mikko Perttunen wrote: > > > > Add YAML device tree bindings for NVDEC, now in a

Re: [PATCH] drm/i915: Actually delete gpu reloc selftests

On Fri, Aug 20, 2021 at 7:00 PM Rodrigo Vivi wrote: > > On Fri, Aug 20, 2021 at 05:49:32PM +0200, Daniel Vetter wrote: > > In > > > > commit 8e02cceb1f1f4f254625e5338dd997ff61ab40d7 > > Author: Daniel Vetter > > Date: Tue Aug 3 14:48:33 2021 +0200 > > > > drm/i915: delete gpu reloc code >

[GIT PULL] drm-misc + drm-intel: Add support for out-of-band hotplug notification

Hello drm-misc and drm-intel maintainers, My "Add support for out-of-band hotplug notification" patchset: https://patchwork.freedesktop.org/series/93763/ Is ready for merging now, as discussed on IRC I based this series on top drm-tip and when trying to apply the i915 parts on top of drm-misc

[GIT PULL] etnaviv-next for 5.15

Hi Dave, Daniel, things are still slow in etnaviv land. Just one hardware support addition for the GPU found on the NXP Layerscape LS1028A SoC from Michael and the GEM mmap cleanup from Thomas. Regards, Lucas The following changes since commit 8a02ea42bc1d4c448caf1bab0e05899dad503f74: Merge

Re: [PATCH v3] drm/i915/dp: Use max params for panels < eDP 1.4

On Fri, Aug 20, 2021 at 03:52:59PM +0800, Kai-Heng Feng wrote: > Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use > fast+narrow link on eDP again and fall back to the old max strategy on > failure"), the screen starts to have wobbly effect. > > Commit a5c936add6a2

[pull] amdgpu, amdkfd, radeon drm-next-5.15

Hi Dave, Daniel, Updates for 5.15. Mainly bug fixes and cleanups. The following changes since commit 554594567b1fa3da74f88ec7b2dc83d000c58e98: drm/display: fix possible null-pointer dereference in dcn10_set_clock() (2021-08-11 17:19:54 -0400) are available in the Git repository at:

Re: [PATCH] drm/i915: Actually delete gpu reloc selftests

On Fri, Aug 20, 2021 at 05:49:32PM +0200, Daniel Vetter wrote: > In > > commit 8e02cceb1f1f4f254625e5338dd997ff61ab40d7 > Author: Daniel Vetter > Date: Tue Aug 3 14:48:33 2021 +0200 > > drm/i915: delete gpu reloc code it would be better with dim cite format... do we need the Fixes: tag?

Re: [PATCH v2 0/8] drm/bridge: Make panel and bridge probe order consistent

Hi Andrzej, On Wed, Aug 04, 2021 at 04:09:38PM +0200, a.hajda wrote: > Hi Maxime, > > I have been busy with other tasks, and I did not follow the list last > time, so sorry for my late response. > > On 28.07.2021 15:32, Maxime Ripard wrote: > > Hi, > > > > We've encountered an issue with the

Re: [PATCH] drm/i915/gt: Potential error pointer dereference in pinned_context()

On Fri, Aug 13, 2021 at 04:01:06PM +0200, Thomas Hellström wrote: > > On 8/13/21 1:36 PM, Dan Carpenter wrote: > > If the intel_engine_create_pinned_context() function returns an error > > pointer, then dereferencing "ce" will Oops. Use "vm" instead of > > "ce->vm". > > > > Fixes: cf586021642d

Re: [PATCH rdma-next v3 0/3] SG fix together with update to RDMA umem

On Thu, Jul 29, 2021 at 12:39:10PM +0300, Leon Romanovsky wrote: > From: Leon Romanovsky > > Changelog: > v3: > * Rewrote to new API suggestion > * Split for more patches > v2: https://lore.kernel.org/lkml/cover.1626605893.git.leo...@nvidia.com > * Changed implementation of first patch, based

Re: [PATCH v2 55/63] HID: roccat: Use struct_group() to zero kone_mouse_event

On Fri, 20 Aug 2021, Kees Cook wrote: > > > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > > > > > field bounds checking for memset(), avoid intentionally writing across > > > > > neighboring fields. > > > > > > > > > > Add struct_group() to mark region of struct

Re: [BUG - BISECTED] display not detected anymore

On Thu, Aug 19, 2021 at 09:07:26PM +0300, Ville Syrjälä wrote: > > ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder") > > > > With that commit the display is not detected anymore, one commit > > before that it still works. So this one seems to be broken. > > > > Ville, Stanislav,

Re: [PATCH v2 02/14] drm/arm/hdlcd: Convert to Linux IRQ interfaces

On Tue, Aug 03, 2021 at 11:06:52AM +0200, Thomas Zimmermann wrote: > Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's > IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers > don't benefit from using it. > > DRM IRQ callbacks are now being called directly or inlined.

Re: [PATCH rdma-next v3 2/3] lib/scatterlist: Fix wrong update of orig_nents

On Fri, Aug 20, 2021 at 12:54:25PM -0300, Jason Gunthorpe wrote: > On Thu, Jul 29, 2021 at 12:39:12PM +0300, Leon Romanovsky wrote: > > > +/** > > + * __sg_free_table - Free a previously mapped sg table > > + * @table: The sg table header to use > > + * @max_ents: The maximum number of

Re: [PATCH v2 55/63] HID: roccat: Use struct_group() to zero kone_mouse_event

On Fri, Aug 20, 2021 at 05:27:35PM +0200, Jiri Kosina wrote: > On Fri, 20 Aug 2021, Kees Cook wrote: > > > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > > > > field bounds checking for memset(), avoid intentionally writing across > > > > neighboring fields. > > > >

Re: [PATCH v2 56/63] RDMA/mlx5: Use struct_group() to zero struct mlx5_ib_mr

On Fri, Aug 20, 2021 at 09:34:00AM -0300, Jason Gunthorpe wrote: > On Thu, Aug 19, 2021 at 11:14:37AM -0700, Kees Cook wrote: > > > Which do you mean? When doing the conversions I tended to opt for > > struct_group() since it provides more robust "intentionality". Strictly > > speaking, the new

Re: [PATCH v2 57/63] powerpc/signal32: Use struct_group() to zero spe regs

On Fri, Aug 20, 2021 at 05:49:35PM +1000, Michael Ellerman wrote: > Kees Cook writes: > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > > field bounds checking for memset(), avoid intentionally writing across > > neighboring fields. > > > > Add a struct_group() for the

Re: [PATCH rdma-next v3 2/3] lib/scatterlist: Fix wrong update of orig_nents

On Thu, Jul 29, 2021 at 12:39:12PM +0300, Leon Romanovsky wrote: > +/** > + * __sg_free_table - Free a previously mapped sg table > + * @table: The sg table header to use > + * @max_ents:The maximum number of entries per single scatterlist > + * @total_ents: The total number of

Re: [PATCH v2 55/63] HID: roccat: Use struct_group() to zero kone_mouse_event

On Fri, Aug 20, 2021 at 05:27:35PM +0200, Jiri Kosina wrote: > On Fri, 20 Aug 2021, Kees Cook wrote: > > > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > > > > field bounds checking for memset(), avoid intentionally writing across > > > > neighboring fields. > > > >

[PATCH] drm/i915: Actually delete gpu reloc selftests

In commit 8e02cceb1f1f4f254625e5338dd997ff61ab40d7 Author: Daniel Vetter Date: Tue Aug 3 14:48:33 2021 +0200 drm/i915: delete gpu reloc code I deleted the gpu relocation code and the selftest include and enabling, but accidentally forgot about the selftest source code. Fix this

Re: [PATCH v2 22/63] HID: cp2112: Use struct_group() for memcpy() region

On Fri, Aug 20, 2021 at 03:01:43PM +0200, Jiri Kosina wrote: > On Tue, 17 Aug 2021, Kees Cook wrote: > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > > field bounds checking for memcpy(), memmove(), and memset(), avoid > > intentionally writing across neighboring

[PATCH V3 4/9] PCI/VGA: Remove empty vga_arb_device_card_gone()

From: Bjorn Helgaas vga_arb_device_card_gone() has always been empty. Remove it. Signed-off-by: Bjorn Helgaas --- drivers/pci/vgaarb.c | 16 +--- 1 file changed, 1 insertion(+), 15 deletions(-) diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c index

[PATCH V3 3/9] PCI/VGA: Use unsigned format string to print lock counts

From: Bjorn Helgaas In struct vga_device, io_lock_cnt and mem_lock_cnt are unsigned, but we previously printed them with "%d", the signed decimal format. Print them with the unsigned format "%u" instead. Signed-off-by: Bjorn Helgaas --- drivers/pci/vgaarb.c | 2 +- 1 file changed, 1

[PATCH V3 6/9] PCI/VGA: Prefer vga_default_device()

Use the vga_default_device() interface consistently instead of directly testing vga_default. No functional change intended. [bhelgaas: split to separate patch and extended] Signed-off-by: Huacai Chen Signed-off-by: Bjorn Helgaas --- drivers/pci/vgaarb.c | 6 +++--- 1 file changed, 3

[PATCH V3 1/9] PCI/VGA: Move vgaarb to drivers/pci

From: Bjorn Helgaas The VGA arbiter is really PCI-specific and doesn't depend on any GPU things. Move it to the PCI subsystem. Signed-off-by: Bjorn Helgaas --- drivers/gpu/vga/Kconfig | 19 --- drivers/gpu/vga/Makefile | 1 - drivers/pci/Kconfig

[PATCH V3 0/9] PCI/VGA: Rework default VGA device selection

My original work is at [1]. Bjorn do some rework and extension in V2. It moves the VGA arbiter to the PCI subsystem, fixes a few nits, and breaks a few pieces to make the main patch a little smaller. V3 rewrite the commit log of the last patch (which is also summarized by Bjorn). All comments

[PATCH V3 7/9] PCI/VGA: Split out vga_arb_update_default_device()

If there's no default VGA device, and we find a VGA device that owns the legacy VGA resources, we make that device the default. Split this logic out from vga_arbiter_add_pci_device() into a new function, vga_arb_update_default_device(). [bhelgaas: split another piece to separate patch]

[PATCH V3 8/9] PCI/VGA: Log bridge control messages when adding devices

Previously vga_arb_device_init() iterated through all VGA devices and indicated whether legacy VGA routing to each could be controlled by an upstream bridge. But we determine that information in vga_arbiter_add_pci_device(), which we call for every device, so we can log it there without iterating

Re: [syzbot] WARNING in drm_gem_shmem_vm_open

syzbot has bisected this issue to: commit ea40d7857d5250e5400f38c69ef9e17321e9c4a2 Author: Daniel Vetter Date: Fri Oct 9 23:21:56 2020 + drm/vkms: fbdev emulation support bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11c31d5530 start commit: 614cb2751d31 Merge

[PATCH V3 9/9] PCI/VGA: Rework default VGA device selection

Current default VGA device selection fails in some cases: - On BMC system, the AST2500 bridge [1a03:1150] does not implement PCI_BRIDGE_CTL_VGA [1]. This is perfectly legal but means the legacy VGA resources won't reach downstream devices unless they're included in the usual bridge

[PATCH V3 2/9] PCI/VGA: Replace full MIT license text with SPDX identifier

From: Bjorn Helgaas Per Documentation/process/license-rules.rst, the SPDX MIT identifier is equivalent to including the entire MIT license text from LICENSES/preferred/MIT. Replace the MIT license text with the equivalent SPDX identifier. Signed-off-by: Bjorn Helgaas --- drivers/pci/vgaarb.c

[PATCH V3 5/9] PCI/VGA: Move vga_arb_integrated_gpu() earlier in file

Move vga_arb_integrated_gpu() earlier in file to prepare for future patch. No functional change intended. [bhelgaas: split to separate patch] Signed-off-by: Huacai Chen Signed-off-by: Bjorn Helgaas --- drivers/pci/vgaarb.c | 28 ++-- 1 file changed, 14 insertions(+), 14

Re: [PATCH v8 12/13] drm/mediatek: add MERGE support for mediatek-drm

Hi, Jason: jason-jh.lin 於 2021年8月19日 週四 上午10:23寫道： > > Add MERGE engine file: > MERGE module is used to merge two slice-per-line inputs > into one side-by-side output. > > Signed-off-by: jason-jh.lin > --- > drivers/gpu/drm/mediatek/Makefile | 1 + >

Re: [PATCH] drm/amd/pm: And destination bounds checking to struct copy

On Thu, Aug 19, 2021 at 4:14 PM Kees Cook wrote: > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > field bounds checking for memcpy(), memmove(), and memset(), avoid > intentionally writing across neighboring fields. > > The "Board Parameters" members of the structs: >

Re: [PATCH v2 55/63] HID: roccat: Use struct_group() to zero kone_mouse_event

On Fri, 20 Aug 2021, Kees Cook wrote: > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > > > field bounds checking for memset(), avoid intentionally writing across > > > neighboring fields. > > > > > > Add struct_group() to mark region of struct kone_mouse_event that

Re: [PATCH v2 22/63] HID: cp2112: Use struct_group() for memcpy() region

On Fri, Aug 20, 2021, 6:01 AM Jiri Kosina wrote: > On Tue, 17 Aug 2021, Kees Cook wrote: > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > > field bounds checking for memcpy(), memmove(), and memset(), avoid > > intentionally writing across neighboring fields. > > >

Re: [PATCH v2 55/63] HID: roccat: Use struct_group() to zero kone_mouse_event

On Fri, Aug 20, 2021, 6:02 AM Jiri Kosina wrote: > On Tue, 17 Aug 2021, Kees Cook wrote: > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > > field bounds checking for memset(), avoid intentionally writing across > > neighboring fields. > > > > Add struct_group() to

Re: [RFC] Make use of non-dynamic dmabuf in RDMA

On Fri, Aug 20, 2021 at 03:58:33PM +0300, Gal Pressman wrote: > Though it would've been nicer if we could agree on a solution that could work > for more than 1-2 RDMA devices, using the existing tools the RDMA subsystem > has. I don't think it can really be done, revoke is necessary, and isn't

Re: [PATCH v2] Revert "drm/scheduler: Avoid accessing freed bad job."

On 2021-08-20 3:12 a.m., Liu, Monk wrote: [AMD Official Use Only] @Daniel Vetter @Grodzovsky, Andrey @Koenig, Christian Do you have any concern on the kthread_park() approach ? Theoretically speaking sched_main shall run there exclusively with job_timeout since they both touches jobs,

Re: [PATCH v2] Revert "drm/scheduler: Avoid accessing freed bad job."

I believe we have some minor confusion here On 2021-08-20 4:09 a.m., Jingwen Chen wrote: Hi all, I just submit a v3 patch according your opinion on using kthread_park instead. Thanks, Jingwen On Fri Aug 20, 2021 at 09:20:42AM +0200, Christian König wrote: No, that perfectly works for me.

Re: [PATCH v8 07/34] clk: tegra: Support runtime PM and power domain

[...] > > > > I'm creating platform device for the clocks that require DVFS. These > > clocks don't use regulator, they are attached to the CORE domain. > > GENPD framework manages the performance state, aggregating perf votes > > from each device, i.e. from each clock individually. > > > > You

Re: [PATCH v2 55/63] HID: roccat: Use struct_group() to zero kone_mouse_event

On Tue, 17 Aug 2021, Kees Cook wrote: > In preparation for FORTIFY_SOURCE performing compile-time and run-time > field bounds checking for memset(), avoid intentionally writing across > neighboring fields. > > Add struct_group() to mark region of struct kone_mouse_event that should > be

Re: [PATCH v2 22/63] HID: cp2112: Use struct_group() for memcpy() region

On Tue, 17 Aug 2021, Kees Cook wrote: > In preparation for FORTIFY_SOURCE performing compile-time and run-time > field bounds checking for memcpy(), memmove(), and memset(), avoid > intentionally writing across neighboring fields. > > Use struct_group() in struct cp2112_string_report around

Re: [PATCH v8 01/34] opp: Add dev_pm_opp_sync() helper

On Fri, 20 Aug 2021 at 07:18, Viresh Kumar wrote: > > On 19-08-21, 16:55, Ulf Hansson wrote: > > Right, that sounds reasonable. > > > > We already have pm_genpd_opp_to_performance_state() which translates > > an OPP to a performance state. This function invokes the > >

  1   2   >