From: Thomas Hellström
Break out some shmem backend utils for future reuse by the TTM backend:
shmem_alloc_st(), shmem_free_st() and __shmem_writeback() which we can
use to provide a shmem-backed TTM page pool for cached-only TTM
buffer objects.
Main functional change here is that we now compute
Fixes some object-debug splat which appeared while debugging something
unrelated.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_context.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/i
For cached objects we can allocate our pages directly in shmem. This
should make it possible(in a later patch) to utilise the existing
i915-gem shrinker code for such objects. For now this is still disabled.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
---
drivers/gpu/d
Drop the atomic shrink_pin stuff, and just have make_{un}shrinkable
update the shrinker visible lists immediately. This at least simplifies
the next patch, and does make the behaviour more obvious. The potential
downside is that make_unshrinkable now grabs a global lock even when the
object itself
This should let us do an accelerated copy directly to the shmem pages
when temporarily moving lmem-only objects, where the i915-gem shrinker
can later kick in to swap out the pages, if needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8 -
We currently just evict lmem objects to system memory when under memory
pressure. For this case we lack the usual object mm.pages, which
effectively hides the pages from the i915-gem shrinker, until we
actually "attach" the TT to the object, or in the case of lmem-only
objects it just gets migrated
Enable shmem tt backend, and enable shrinking.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index dbf06a2af8bf..
It looks like Hyper-V supports a hardware cursor feature. It is not used
by Linux VM, but the Hyper-V host still draws a point as an extra mouse
pointer, which is unwanted, especially when Xorg is running.
The hyperv_fb driver uses synthvid_send_ptr() to hide the unwanted pointer.
When the hyperv_
.
On Mon, Sep 13, 2021 at 10:48 AM Gurchetan Singh
wrote:
>
>
>
> On Fri, Sep 10, 2021 at 12:33 PM Chia-I Wu wrote:
>>
>> On Wed, Sep 8, 2021 at 6:37 PM Gurchetan Singh
>> wrote:
>> >
>> > We don't want fences from different 3D contexts (virgl, gfxstream,
>> > venus) to be on the same timeline.
Hi,
On Mon, Sep 13, 2021 at 3:59 AM yangcong
wrote:
>
> This is an incell IC, TDDI use time division multiplexing.
> Init code effect touch sensing.
> Support touch function we needed to handle were:
> a) Update init code for the panel driver, adjust the porch value.
> b) After update init code t
On Mon, Sep 13, 2021 at 01:40:34PM -0400, Eric Farman wrote:
> On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote:
> > This addresses Cornelia's remark on the earlier patch that ccw has a
> > confusing lifecycle. While it doesn't seem like the original attempt
> > was
> > functionally wrong,
On Mon, Sep 13, 2021 at 2:05 PM Alex Deucher wrote:
>
> On Mon, Sep 13, 2021 at 1:57 PM Sean Paul wrote:
> >
> > From: Sean Paul
> >
> > Hello,
> > This patchset pulls the HDCP protocol auth/exchange/check logic out from
> > i915 into a HDCP helper library which drivers can use to implement the
Panel in my Dell XPS 7590, that uses Intel's HDR backlight interface to
control brightness, apparently needs a delay before setting brightness
after power on. Without this delay the panel does accept the setting
and may come up with some arbitrary brightness (sometimes it's too dark,
sometimes it's
> -Original Message-
> From: Dexuan Cui
> Sent: Monday, September 13, 2021 2:27 PM
> To: drawat.fl...@gmail.com; Haiyang Zhang ;
> airl...@linux.ie; dan...@ffwll.ch; tzimmerm...@suse.de; dri-
> de...@lists.freedesktop.org
> Cc: linux-hyp...@vger.kernel.org; linux-ker...@vger.kernel.org;
Hi Maxime,
thanks for the ping on irc. I had accidently deleted v2 of this patch.
Sam
On Mon, Aug 30, 2021 at 11:49:09AM +0200, Maxime Ripard wrote:
> The drm_helper_hpd_irq_event() function is iterating over all the
> connectors when an hotplug event is detected.
>
> During that iterat
https://bugzilla.kernel.org/show_bug.cgi?id=214029
--- Comment #8 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 298783
--> https://bugzilla.kernel.org/attachment.cgi?id=298783&action=edit
output of kmemleak (kernel 5.15-rc1, AMD FX-8370)
Seems unchanged in kernel 5.15-rc1.
# ca
https://bugzilla.kernel.org/show_bug.cgi?id=214029
--- Comment #9 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 298785
--> https://bugzilla.kernel.org/attachment.cgi?id=298785&action=edit
kernel dmesg (kernel 5.15-rc1, AMD FX-8370)
--
You may reply to this email to add a comment
https://bugzilla.kernel.org/show_bug.cgi?id=214029
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #298525|0 |1
is obsolete|
Add a cancel request selftest that results in an engine reset to cancel
the request as it is non-preemptable. Also insert a NOP request after
the cancelled request and confirm that it completes successfully.
v2:
(Tvrtko)
- Skip test if preemption timeout compiled out
- Skip test if engine res
On 2021-09-13 3:26 p.m., Sean Paul wrote:
> On Mon, Sep 13, 2021 at 2:05 PM Alex Deucher wrote:
>>
>> On Mon, Sep 13, 2021 at 1:57 PM Sean Paul wrote:
>>>
>>> From: Sean Paul
>>>
>>> Hello,
>>> This patchset pulls the HDCP protocol auth/exchange/check logic out from
>>> i915 into a HDCP helpe
From: John Harrison
When i915 receives a context reset notification from GuC, it triggers
an error capture before resetting any outstanding requsts of that
context. Unfortunately, the error capture is not a time bound
operation. In certain situations it can take a long time, particularly
when mul
On Mon, Sep 13, 2021 at 02:10:16PM -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> When i915 receives a context reset notification from GuC, it triggers
> an error capture before resetting any outstanding requsts of that
> context. Unfortunately, the error capture is not a time
On Mon, 13 Sep 2021 13:57:43 -0400, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds the bindings for the MSM DisplayPort HDCP registers
> which are required to write the HDCP key into the display controller as
> well as the registers to enable HDCP authentication/key
> exchange/encryption.
Replace the direct i2c access (i2c_smbus_* functions) with regmap APIs,
which will simplify the future update on ps8640 driver.
Signed-off-by: Philip Chen
---
Changes in v2:
- Add separate reg map config per page
drivers/gpu/drm/bridge/parade-ps8640.c | 89 ++
1 file ch
Implement the first version of AUX support, which will be useful as
we expand the driver to support varied use cases.
WARNING: This patch is not fully verified by hardware. But as AUX CH
is not implemented for ps8640 driver until now, the patch shouldn't
cause any functional regression in practice
On Thu, Sep 9, 2021 at 12:07 PM Stephen Boyd wrote:
>
> Quoting Philip Chen (2021-09-09 11:15:27)
> > On Wed, Sep 8, 2021 at 3:27 PM Stephen Boyd wrote:
> > >
> > > Quoting Philip Chen (2021-09-08 11:18:06)
> > >
> > > > +
> > > > + data = (len - 1) & AUX_LENGTH_MASK;
> > > > + regmap
On Thu, Sep 9, 2021 at 2:27 PM Stephen Boyd wrote:
>
> Quoting Doug Anderson (2021-09-09 14:14:29)
> > On Thu, Sep 9, 2021 at 12:09 PM Stephen Boyd wrote:
> > >
> > >
> > > Oh does this have register pages? regmap has support for pages where you
> > > write some indirection register and then acce
On 9/9/2021 17:41, Matthew Brost wrote:
On Thu, Sep 09, 2021 at 03:46:43PM -0700, John Harrison wrote:
On 8/20/2021 15:44, Matthew Brost wrote:
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a scheduling of user context could be enabled.
As with earlier PM
On 9/13/2021 09:54, Matthew Brost wrote:
On Thu, Sep 09, 2021 at 03:51:27PM -0700, John Harrison wrote:
On 8/20/2021 15:44, Matthew Brost wrote:
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_conte
On 8/20/2021 15:44, Matthew Brost wrote:
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 h
On 8/20/2021 15:44, Matthew Brost wrote:
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
Hi, Markus:
Markus Schneider-Pargmann 於 2021年9月10日 週五 下午1:36寫道：
>
> Hi Chun-Kuang,
>
> On Fri, Sep 10, 2021 at 07:37:50AM +0800, Chun-Kuang Hu wrote:
> > Hi, Markus:
> >
> > Markus Schneider-Pargmann 於 2021年9月7日 週二 上午3:37寫道：
> > >
> > > This patch adds a DisplayPort driver for the Mediatek mt819
Hi,
On Mon, Sep 13, 2021 at 2:33 PM Philip Chen wrote:
>
> Implement the first version of AUX support, which will be useful as
> we expand the driver to support varied use cases.
>
> WARNING: This patch is not fully verified by hardware. But as AUX CH
> is not implemented for ps8640 driver until
This is needed to leverage the out_fence machinery for similar but
additional singalling mechanisms.
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/drm_atomic_uapi.c | 57 ---
1 file changed, 37 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_atom
The main idea behind DRM_CAP_RELEASE_FENCE is to add an additional
signaling mechanism for a pageflip completion in addition to out_fence
or DRM_EVENT_FLIP_COMPLETE event. This allows a compositor to start
a new repaint cycle with a new buffer instead of waiting for the
old buffer to be free.
Why
Cc: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_fence.c | 9 +
drivers/gpu/drm/virtio/virtgpu_kms.c |
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +++-
drivers/gpu/drm/virtio/virtgpu_vq.c | 7 +--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 9126bca47c6d..c219e
Release_fence is very similar if not the same as out_fence; it
is an additional signalling mechanism for a page flip completion.
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/drm_atomic_uapi.c | 43 +--
drivers/gpu/drm/drm_crtc.c| 2 ++
drivers/gpu/drm/d
Cc: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 63 +++---
1 file changed, 56 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index a49fd9480381..ab39254
If a driver supports this capability, it means that there would be an
additional signalling mechanism for a page flip completion in addition
to out_fence or DRM_MODE_PAGE_FLIP_EVENT.
This capability may only be relevant for Virtual KMS drivers and is currently
used only by virtio-gpu. Also, it can
Hi,
On Mon, Sep 13, 2021 at 2:33 PM Philip Chen wrote:
>
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> b/drivers/gpu/drm/bridge/parade-ps8640.c
> index 685e9c38b2db..1b2414601538 100644
> --- a/drivers/gpu/drm/bridge/parade-ps8640.c
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -
On Mon, Sep 13, 2021 at 04:06:33PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > 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
On Mon, Sep 13, 2021 at 03:26:29PM -0700, John Harrison wrote:
> On 9/9/2021 17:41, Matthew Brost wrote:
> > On Thu, Sep 09, 2021 at 03:46:43PM -0700, John Harrison wrote:
> > > On 8/20/2021 15:44, Matthew Brost wrote:
> > > > Taking a PM reference to prevent intel_gt_wait_for_idle from short
> > >
Quoting Sean Paul (2021-09-13 10:57:43)
> diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> index 64d8d9e5e47a..984301442653 100644
> --- a/Documentation/devicetree/bindings/display/msm/dp-controller
On Mon, Sep 13, 2021 at 04:19:00PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > Introduce context parent-child relationship. Once this relationship is
> > created all pinning / unpinning operations are directed to the parent
> > context. The parent context is responsib
Quoting Sean Paul (2021-09-13 10:57:44)
> From: Sean Paul
>
> This patch adds the register ranges required for HDCP to the sc7180
> device tree. These registers will be used to inject HDCP key as well as
> toggle HDCP on and off.
It doesn't look to do any of that?
>
> Signed-off-by: Sean Paul
>
On Mon, Sep 13, 2021 at 11:52 AM Chia-I Wu wrote:
> .
>
> On Mon, Sep 13, 2021 at 10:48 AM Gurchetan Singh
> wrote:
> >
> >
> >
> > On Fri, Sep 10, 2021 at 12:33 PM Chia-I Wu wrote:
> >>
> >> On Wed, Sep 8, 2021 at 6:37 PM Gurchetan Singh
> >> wrote:
> >> >
> >> > We don't want fences from dif
Hi Sean,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.15-rc1 next-20210913]
[If your patch is applied to the wrong git tree
[AMD Official Use Only]
Driver can exchange the custom profiling settings with SMU FW using the table
below:
TABLE_CUSTOM_DPM
And the related data structure is CustomDpmSettings_t.
BR
Evan
> -Original Message-
> From: Alex Deucher
> Sent: Monday, September 13, 2021 11:11 PM
> To: Danie
Hi Matthew,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on drm-exynos/exynos-drm-next linus/master v5.15-rc1
next-20210913]
[cannot apply to drm-intel/for-linux-next tegra-drm/drm/tegra/for-next
drm/drm-next]
[If
Hi Maarten,
I love your patch! Perhaps something to improve:
[auto build test WARNING on regulator/for-next]
[also build test WARNING on tegra-drm/drm/tegra/for-next v5.14]
[cannot apply to tip/locking/core linus/master next-20210909]
[If your patch is applied to the wrong git tree, kindly drop
Quoting Sankeerth Billakanti (2021-08-11 17:08:01)
> The eDP controller on SC7280 is similar to the eDP/DP controllers
> supported by the current driver implementation.
>
> SC7280 supports one EDP and one DP controller which can operate
> concurrently.
>
> The following are some required changes fo
On 1/14/21 11:40 PM, Palmer Dabbelt wrote:
From: Palmer Dabbelt
cdn_dp_resume is only used under PM_SLEEP, and now that it's static an
unused function warning is triggered undner !PM_SLEEP. This
conditionally enables the function to avoid the warning.
Fixes: 7c49abb4c2f8 ("drm/rockchip: cdn-d
To print stack entries into a buffer, users of stackdepot,
first get a list of stack entries using stack_depot_fetch
and then print this list into a buffer using stack_trace_snprint.
Provide a helper in stackdepot for this purpose.
Also change above mentioned users to use this helper.
Signed-off-b
Changes in v2:
- Addressed review comment.
- Added Acked from Vlastimil.
- Fixed one mistake, due to which stack_trace_snprint was always
getting invoked with 0 as space value.
Changed it to make use of space argument, because users that
are printing stack entries into buffer, may
On 13/9/21 6:51 pm, Vlastimil Babka wrote:
On 9/10/21 16:10, Imran Khan wrote:
To print stack entries into a buffer, users of stackdepot,
first get a list of stack entries using stack_depot_fetch
and then print this list into a buffer using stack_trace_snprint.
Provide a helper in stackdepot
An error capture allocates memory, memory allocations depend on resets,
and resets need to flush the G2H handlers to seal several races. If the
error capture is done from the G2H handler this creates a circular
dependency. To work around this, do a error capture in a work queue
asynchronously from
From: John Harrison
When i915 receives a context reset notification from GuC, it triggers
an error capture before resetting any outstanding requsts of that
context. Unfortunately, the error capture is not a time bound
operation. In certain situations it can take a long time, particularly
when mul
Rather allocating an error capture in nowait context to break a lockdep
splat [1], do the error capture async compared to the G2H processing.
Signed-off-by: Matthew Brost
[1] https://patchwork.freedesktop.org/patch/451415/?series=93704&rev=5
John Harrison (1):
drm/i915/guc: Refcount context d
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. No need to call the IRQ handler directly
either as the scrubbing code can deal with any missing G2H.
Signed-off-by: Matthew Br
Move guc_ids under submission_state sub-structure as a future patch will
use contexts_lock (global GuC submission lock) to protect more data.
Introducing the sub-structure makes ownership of the locking / fields
clear.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.
Minimum set of patches to enable GuC submission on DG1 and enable it by
default.
A little difficult to test as IGTs do not work with DG1 due to a bunch
of uAPI features being disabled (e.g. relocations, caching memory
options, etc...) and CI for DG1 isn't all that useful yet. Tested quite
thorough
From: Daniele Ceraolo Spurio
Add DG1 GuC / HuC firmware defs
Signed-off-by: Matthew Brost
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
Enable GuC submission by default on DG1
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 86c318516e14..2fef3b0bbe95 10064
From: Daniele Ceraolo Spurio
The firmware binary has to be loaded from lmem and the recommendation is
to put all other objects in there as well. Note that we don't fall back
to system memory if the allocation in lmem fails because all objects are
allocated during driver load and if we have issues
The GuC objects are perma-pinned and need to be dumped during an error
capture. Use the macro i915_gem_object_is_lmem rather than
__i915_gem_object_is_lmem to avoid a lockdep splat as the former is the
correct call if the object is perma-pinned.
Signed-off-by: Matthew Brost
Cc: Thomas Hellstrom
From: Venkata Sandeep Dhanalakota
Defining vma on stack can cause stack overflow, if
vma gets populated with new fields.
Cc: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Signed-off-by: Venkata Sandeep Dhanalakota
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915
On Tue, 14 Sept 2021 at 14:55, Matthew Brost wrote:
>
> From: Venkata Sandeep Dhanalakota
>
> Defining vma on stack can cause stack overflow, if
> vma gets populated with new fields.
Is there some higher level locking stopping that from getting trashed?
or a guarantee that uc_fw_bind_ggtt is onl
On Mon, Sep 13, 2021 at 03:38:44PM -0700, John Harrison wrote:
> On 9/13/2021 09:54, Matthew Brost wrote:
>
> On Thu, Sep 09, 2021 at 03:51:27PM -0700, John Harrison wrote:
>
> On 8/20/2021 15:44, Matthew Brost wrote:
>
> Calling switch_to_kernel_context isn't needed if t
Rather allocating an error capture in nowait context to break a lockdep
splat [1], do the error capture async compared to the G2H processing.
v2: Fix Docs warning
Signed-off-by: Matthew Brost
[1] https://patchwork.freedesktop.org/patch/451415/?series=93704&rev=5
John Harrison (1):
drm/i915/g
From: John Harrison
When i915 receives a context reset notification from GuC, it triggers
an error capture before resetting any outstanding requsts of that
context. Unfortunately, the error capture is not a time bound
operation. In certain situations it can take a long time, particularly
when mul
Move guc_ids under submission_state sub-structure as a future patch will
use contexts_lock (global GuC submission lock) to protect more data.
Introducing the sub-structure makes ownership of the locking / fields
clear.
v2:
(Docs)
- Fix Docs warning by adding comment to submission_state structur
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. No need to call the IRQ handler directly
either as the scrubbing code can deal with any missing G2H.
Signed-off-by: Matthew Br
An error capture allocates memory, memory allocations depend on resets,
and resets need to flush the G2H handlers to seal several races. If the
error capture is done from the G2H handler this creates a circular
dependency. To work around this, do a error capture in a work queue
asynchronously from
The hardware sets the TMUWCF bit back to 0 when the TMU write
combiner flush completes so we should be checking for that instead
of the L2TFLS bit.
Fixes spurious Vulkan CTS failures in:
dEQP-VK.binding_model.descriptorset_random.*
---
drivers/gpu/drm/v3d/v3d_gem.c | 2 +-
1 file changed, 1 inser
On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote:
> This addresses Cornelia's remark on the earlier patch that ccw has a
> confusing lifecycle. While it doesn't seem like the original attempt
> was
> functionally wrong, the result can be made better with a lot of
> further
> work.
I though
On Mon, 2021-09-13 at 16:24 -0300, Jason Gunthorpe wrote:
> On Mon, Sep 13, 2021 at 01:40:34PM -0400, Eric Farman wrote:
> > On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote:
> > > This addresses Cornelia's remark on the earlier patch that ccw
> > > has a
> > > confusing lifecycle. While it
On Mon, Sep 13, 2021 at 10:42:36AM +0200, Maarten Lankhorst wrote:
> > +/**
> > + * ww_mutex_trylock - tries to acquire the w/w mutex with optional acquire
> > context
> > + * @ww: mutex to lock
> > + * @ww_ctx: optional w/w acquire context
> > + *
> > + * Trylocks a mutex with the optional acqui
101 - 178 of 178 matches
Mail list logo
