== Series Details ==
Series: drm/i915: Add pipe scaler for Gen9 in atomic path
URL : https://patchwork.freedesktop.org/series/11764/
State : success
== Summary ==
Series 11764v1 drm/i915: Add pipe scaler for Gen9 in atomic path
http://patchwork.freedesktop.org/api/1.0/series/11764/revisions/1/
Pipe scaler is scaler registers are updated according to provided
destination size from user.
Signed-off-by: Nabendu Maiti
---
drivers/gpu/drm/i915/intel_display.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/
Pipe scaler on gen9 destination size may go out of adjusted modeset
size.This patch add limit check on user custom crtc destination size and
clamp it within modeset size.
Signed-off-by: Nabendu Maiti
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
1 file changed, 11 insertions(+)
di
Adding pipe destination co-ordinate and size property as crtc atomic drm
property to dynamically change pipe destination attributes on GEN9.
Signed-off-by: Nabendu Maiti
---
drivers/gpu/drm/drm_atomic.c | 20 +++
drivers/gpu/drm/drm_crtc.c | 32 +
driver
No boundary condition was checked while calculating pipe scaler size
in pch_panel_fitting(), which might result in blank out or
corruptions for invalid values. This patch fixes this by adding
appropriate checks and calculation for each fitting mode.
Signed-off-by: Nabendu Maiti
---
drivers/gpu/d
Following patch series add pipe scaler functionality in atomic path.The pipe
scaler can be changed dynamically without modeset.Apart from default panel
fitter supported scaling modes -CENTER/ASPECT/FULLSCREEN custom scaling mode
mode is added as there is no such restriction on GEn9 pipe scaler.
Initialization of pipe source size property as intel drm property to drm level
to dynamically change pipe source size.
Signed-off-by: Nabendu Maiti
---
drivers/gpu/drm/drm_atomic.c | 10 ++
drivers/gpu/drm/drm_crtc.c | 16
include/drm/drm_crtc.h | 7 +++
3 f
Pipe scaler Fitting mode property is added as crtc atomic property.
Signed-off-by: Nabendu Maiti
---
drivers/gpu/drm/drm_atomic.c | 5
drivers/gpu/drm/drm_crtc.c | 8 ++
drivers/gpu/drm/i915/intel_display.c | 47 ++--
include/drm/drm_c
Adding pipe source size property calculations on atomic path to
dynamically change pipe source size.
Write desired values to change the size. Write 0 to disable pipe scaler
and restore the original mode adjusted values.
Signed-off-by: Nabendu Maiti
---
drivers/gpu/drm/i915/intel_display.c | 69
Hi all:
When I just doing the driver for us chip, we would request the Nalu
header present in the data to be process. But I found the data be
Rendered to with type VASliceDataBufferType is removed the Nalu start
code. Is there any way to make the client send the data without remove
the start
Just realized this patch needs s/attached_port/port, will send out
another version.
On Mon, 2016-08-29 at 17:23 -0400, Lyude Paul wrote:
> Looks like a much better solution then the previous one.
>
> Reviewed-by: Lyude
>
> On Wed, 2016-08-24 at 00:22 -0700, Dhinakaran Pandiyan wrote:
> > Now t
With DP MST, a digital_port can carry more than one audio stream. Hence,
more than one audio_connector needs to be attached to intel_digital_port in
such cases. However, each stream is associated with an unique encoder. So,
instead of creating an array of audio_connectors per port, move
audio_conne
Confirmed on IRC, Lyude is fine with carrying over R-B from previous
version.
On Wed, 2016-08-24 at 00:22 -0700, Dhinakaran Pandiyan wrote:
> With DP MST, a digital_port can carry more than one audio stream. Hence,
> more than one audio_connector needs to be attached to intel_digital_port in
> su
drm/i915/vlv: Make intel_crt_reset() per-encoder:
4570d833390b10043d082fe535375d4a0e071d9c
drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init():
4c732e6ee9e71903934d75b12a021eb3520b6197
drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug():
21842ea84f161ae37ba25f0250c377fd19c5b307
d
Looks like a much better solution then the previous one.
Reviewed-by: Lyude
On Wed, 2016-08-24 at 00:22 -0700, Dhinakaran Pandiyan wrote:
> Now that we have the port enum stored in intel_encoder, use that instead of
> dereferencing intel_dig_port. Saves us a few locals.
>
> struct intel_encoder
Reviewed-by: Lyude
On Wed, 2016-08-24 at 00:22 -0700, Dhinakaran Pandiyan wrote:
> Storing the port enum in intel_encoder makes it convenient to know the
> port attached to an encoder. Moving the port information up from
> intel_digital_port to intel_encoder avoids unecessary intel_digital_port
>
On Mon, Aug 29, 2016 at 09:33:18AM +0200, Maarten Lankhorst wrote:
> Op 26-08-16 om 12:59 schreef Chris Wilson:
> > According to the CI test machines, SNB also uses the
> > GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE value to report a bad
> > GEN6_PCODE_MIN_FREQ_TABLE request.
> >
> > [ 157.74
On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
> If it's an Iybridge, there's no low vswing, and that explanation is
> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
> on an unpatched kernel.
CC'ed Martin who filed the bz, he can reproduce too
https://bugzilla
== Series Details ==
Series: intel_opregion_get_panel_type potential bug fix
URL : https://patchwork.freedesktop.org/series/11735/
State : success
== Summary ==
Series 11735v1 intel_opregion_get_panel_type potential bug fix
http://patchwork.freedesktop.org/api/1.0/series/11735/revisions/1/mbox
On Mon, Aug 22, 2016 at 06:41:05PM -0700, Manasi Navare wrote:
> From: Jim Bride
>
> Split out the DisplayPort and HDMI pll setup code into separate
> functions and refactor the DP code does not directly depend on
> crtc state, so that the code can be used for upfront link training.
>
> Signed-o
Hello, all. I've been attempting to track down a bug with my Panasonic
CF-30 laptop. I have a bug report[0] submitted.
In investigating the issue myself, I discovered that the root of the
problem seemed to be that the new code for getting the panel type from
the opregion seems to believe it is get
== Series Details ==
Series: drm/i915/skl: Don't try to update plane watermarks if they haven't
changed (rev3)
URL : https://patchwork.freedesktop.org/series/11654/
State : success
== Summary ==
Series 11654v3 drm/i915/skl: Don't try to update plane watermarks if they
haven't changed
http://
On Mon, Aug 29, 2016 at 04:25:25PM +0100, Chris Wilson wrote:
> On Mon, Aug 29, 2016 at 05:54:45PM +0300, Imre Deak wrote:
> > On ma, 2016-08-29 at 16:24 +0200, Takashi Iwai wrote:
> > > Hmm, this always confuses me. Is the freeze callback called to the
> > > loader kernel?
> >
> > It's called bo
i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the plane hasn't actually changed, neither
have it's watermarks.
On Thu, Aug 18, 2016 at 05:11:31PM -0700, Anusha Srivatsa wrote:
> Change intel_dp_mst_mode_valid() to use available link bandwidth
> rather than the link's maximum supported bandwidth to evaluate
> whether modes are legal for the current configuration. This takes
> into account the fact that link
On Mon, Aug 29, 2016 at 04:43:04PM +0300, Joonas Lahtinen wrote:
> On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> > +static void __i915_sw_fence_wake_up_all(struct i915_sw_fence *fence,
> > + struct list_head *continuation)
> > +{
> > + wait_queue_head_t
== Series Details ==
Series: drm/i915/skl: Don't try to update plane watermarks if they haven't
changed (rev2)
URL : https://patchwork.freedesktop.org/series/11654/
State : failure
== Summary ==
Series 11654v2 drm/i915/skl: Don't try to update plane watermarks if they
haven't changed
http://
On Mon, Aug 29, 2016 at 05:54:45PM +0300, Imre Deak wrote:
> On ma, 2016-08-29 at 16:24 +0200, Takashi Iwai wrote:
> > Hmm, this always confuses me. Is the freeze callback called to the
> > loader kernel?
>
> It's called both in loader and target kernel, before creating or
> restoring the image.
On Mon, 29 Aug 2016, Lyude wrote:
> i915 sometimes needs to disable planes in the middle of an atomic
> commit, and then reenable them later in the same commit. Because of
> this, we can't make the assumption that the state of the plane actually
> changed. Since the state of the plane hasn't actua
On Mon, 29 Aug 2016, Andrea Arcangeli wrote:
> On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
>> If it's an Iybridge, there's no low vswing, and that explanation is
>> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
>> on an unpatched kernel.
>
> What I should
On ma, 2016-08-29 at 16:24 +0200, Takashi Iwai wrote:
> On Mon, 29 Aug 2016 16:09:23 +0200,
> Imre Deak wrote:
> >
> > On ma, 2016-08-29 at 15:32 +0200, Daniel Vetter wrote:
> > > On Fri, Aug 26, 2016 at 02:42:47PM +0300, Imre Deak wrote:
> > > > On pe, 2016-08-26 at 14:10 +0300, Imre Deak wrote:
i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the plane hasn't actually changed, neither
have it's watermarks.
On Mon, 29 Aug 2016 16:09:23 +0200,
Imre Deak wrote:
>
> On ma, 2016-08-29 at 15:32 +0200, Daniel Vetter wrote:
> > On Fri, Aug 26, 2016 at 02:42:47PM +0300, Imre Deak wrote:
> > > On pe, 2016-08-26 at 14:10 +0300, Imre Deak wrote:
> > > > On pe, 2016-08-26 at 11:39 +0100, Chris Wilson wrote:
> >
On ma, 2016-08-29 at 15:32 +0200, Daniel Vetter wrote:
> On Fri, Aug 26, 2016 at 02:42:47PM +0300, Imre Deak wrote:
> > On pe, 2016-08-26 at 14:10 +0300, Imre Deak wrote:
> > > On pe, 2016-08-26 at 11:39 +0100, Chris Wilson wrote:
> > > > On Fri, Aug 26, 2016 at 12:25:01PM +0200, Takashi Iwai wrote
On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> @@ -598,7 +598,7 @@ bool __i915_spin_request(const struct
> drm_i915_gem_request *req,
> /**
> * i915_wait_request - wait until execution of request has finished
> * @req: duh!
> - * @interruptible: do an interruptible wait (normally yes
On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> Access to intel_init_emon() is strictly ordered by gt_powersave, using
How exactly?
> struct_mutex around it is overkill (and will conflict with the caller
> holding struct_mutex themselves).
>
> Signed-off-by: Chris Wilson
Was this inten
Chris Wilson writes:
> Access to intel_init_emon() is strictly ordered by gt_powersave, using
> struct_mutex around it is overkill (and will conflict with the caller
> holding struct_mutex themselves).
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/in
On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> +static void i915_sw_fence_free(struct kref *kref)
> +{
> + struct i915_sw_fence *fence = container_of(kref, typeof(*fence), kref);
> +
> + WARN_ON(atomic_read(&fence->pending) > 0);
> +
> + if (fence->flags & I915_SW_FENCE_MASK)
>
On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
> If it's an Iybridge, there's no low vswing, and that explanation is
> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
> on an unpatched kernel.
What I should look for when trying those two settings? Will they
suc
On Fri, Aug 26, 2016 at 02:42:47PM +0300, Imre Deak wrote:
> On pe, 2016-08-26 at 14:10 +0300, Imre Deak wrote:
> > On pe, 2016-08-26 at 11:39 +0100, Chris Wilson wrote:
> > > On Fri, Aug 26, 2016 at 12:25:01PM +0200, Takashi Iwai wrote:
> > > > On Fri, 26 Aug 2016 11:18:00 +0200,
> > > > Takashi I
This patch enables Transition WM for SKL+ platforms.
Transition WM are used if IPC is enabled, to decide, number of blocks
to be fetched before reducing the priority of display to fetch from
memory.
Signed-off-by: Kumar, Mahesh
---
drivers/gpu/drm/i915/intel_pm.c | 57 ++
This patch make changes to use linetime latency instead of allocated
DDB size during plane watermark calculation in switch case, This is
required to implement new DDB allocation algorithm.
In New Algorithm DDB is allocated based on WM values, because of which
number of DDB blocks will not be avail
Chris Wilson writes:
> Emulate HW to track and manage ELSP queue. A set of SW ports are defined
> and requests are assigned to these ports before submitting them to HW. This
> helps in cleaning up incomplete requests during reset recovery easier
> especially after engine reset by decoupling elsp
This patch implements new DDB allocation algorithm as per HW team
suggestion. This algo takecare of scenario where we allocate less DDB
for the planes with lower relative pixel rate, but they require more DDB
to work.
It also takes care of enabling same watermark level for each
plane, for efficient
This patch adds support to decode system memory bandwidth
which will be used for arbitrated display memory percentage
calculation in GEN9 based system.
Signed-off-by: Kumar, Mahesh
---
drivers/gpu/drm/i915/i915_drv.c | 96 +
drivers/gpu/drm/i915/i915_drv.h
This series implements new DDB allocation algorithm to solve the cases,
where we have sufficient DDB available to enable multiple planes, But
due to the current algorithm not dividing it properly among planes, we
end-up failing the flip.
It also takes care of enabling same watermark level for each
This patch implemnets Workariunds related to display arbitrated memory
bandwidth. These WA are applicabe for all gen-9 based platforms.
Signed-off-by: Kumar, Mahesh
---
drivers/gpu/drm/i915/i915_drv.h | 9 +++
drivers/gpu/drm/i915/intel_drv.h | 11 +++
drivers/gpu/drm/i915/intel_pm.c | 145
This patch make use of plane_wm variable directly instead of passing
skl_plane_wm struct. this way reduces number of argument requirement
in watermark calculation functions.
It also gives more freedom of decision making to implement Bspec WM
workarounds.
Signed-off-by: Kumar, Mahesh
---
drivers
Set the intel_crtc->active flag after pipe/crtc is actually active in
haswell_crtc_enable function.
Signed-off-by: Kumar, Mahesh
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/dr
On to, 2016-08-25 at 16:28 +0100, John Harrison wrote:
> Just had a quick look at gem_ctx_switch and that seems to notice the
> change with this patch. Without it skips non-render engines, with it
> runs a bunch of non-default context tests across all engines. Is that
> sufficient to satisfy the IG
Am 29.08.2016 um 09:08 schrieb Chris Wilson:
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate t
== Series Details ==
Series: Feature macro cleanup, batch 1
URL : https://patchwork.freedesktop.org/series/11717/
State : warning
== Summary ==
Series 11717v1 Feature macro cleanup, batch 1
http://patchwork.freedesktop.org/api/1.0/series/11717/revisions/1/mbox/
Test gem_exec_gttfill:
Final batch of INTEL_INFO()->gen to INTEL_GEN().
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 21 +++--
drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++--
drivers/gpu/drm/i915/intel_dp.c | 8 ---
Pass dev_priv to all instances of HAS_POOLED_EU(), as well as
to INTEL_INFO()->min_eu_in_pool, and make the macro
use the new non-polymorph version of INTEL_INFO().
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h
Most of our feature macros are made to take
drm_i915_private as a parameter, since the wanted
information is part of that struct.
A lot of code still passes drm_device instead, meaning
extra pointer churn. As a stop-gap solution our macros
currently implements a poor man's polymorphism by use of
Convert all instances of INTEL_INFO(dev_priv)->gen to INTEL_GEN(dev_priv).
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/i915_drv.c| 2 +-
drivers/gpu/drm/i915/i915_gem.c| 10 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 +++---
drivers/gpu/drm/i9
Modify i915_vgacntrl_reg() to take dev_priv instead of dev,
and replace its call to INTEL_INFO(dev)->gen with INTEL_GEN(dev_priv).
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/i915_drv.h | 6 +++---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
2 files changed, 5 insertions(+),
Convert all remaining instances of INTEL_INFO(dev)->gen in *.c
to INTEL_GEN(dev_priv).
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/i915_drv.c| 19 +++---
drivers/gpu/drm/i915/i915_gem.c| 4 +--
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 ++-
driv
Pass dev_priv to all instances of IS_MOBILE(), convert the
only user of INTEL_INFO()->is_mobile to use IS_MOBILE(),
and make the macro use the new non-polymorph version of INTEL_INFO().
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_g
Pass dev_priv to all instances of HAS_GMCH_DISPLAY(), and make the
macro use INTEL_GEN().
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/i915_drv.h| 5 +++--
drivers/gpu/drm/i915/intel_color.c | 11 +--
drivers/gpu/drm/i915/intel_display.c | 12 ++-
Pass dev_priv to all instances of INTEL_GEN(), and make the macro
use the new non-polymorph version of INTEL_INFO().
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem_render_state.c | 3 +--
drivers/gpu/drm/i915/intel_display.c
Introduce non-polymorph versions of INTEL_INFO(), INTEL_DEVID(),
and INTEL_REVID(), to help the transition to ridding the driver
of the polymorph versions.
These macros are only intended to be used *within* i915_drv.h,
to prevent already transitioned macros from inadvertent introduction
of new, no
Pass dev_priv to all instances of HAS_RESOURCE_STREAMER() and
HAS_CORE_RING_FREQ(), and make the macros use INTEL_GEN().
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/i915_drv.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 11 ++-
drivers/gpu/drm/i915/i915_g
Convert all instances of INTEL_INFO(dev)->gen in intel_pm.c
to INTEL_GEN(dev_priv).
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/intel_pm.c | 67 -
1 file changed, 40 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b
Convert all instances of INTEL_INFO(dev)->gen in intel_display.c
to INTEL_GEN(dev_priv).
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/intel_display.c | 176 ++-
1 file changed, 89 insertions(+), 87 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_d
My Dell XPS 13 9350 laptop just got a buffer underrun:
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A
FIFO underrun
I'm seeing this very occasionally, and they don't come in groups -- I
seem to get one underrun with a black flash and that's it. This is
with just the laptop s
On Mon, 29 Aug 2016, Ander Conselvan De Oliveira wrote:
> On Thu, 2016-08-25 at 15:04 +0300, Jani Nikula wrote:
>> The last user of for_each_intel_crtc_masked macro was removed in
>>
>> commit 0a9ab303b87a94115e361a7f3a15d9f481bc453b
>> Author: Ander Conselvan de Oliveira
>> Date: Tue Apr 21 1
On Sun, Aug 28, 2016 at 09:46:24PM +0100, Chris Wilson wrote:
> +/* Setting I915_EXEC_FENCE_OUT causes the ioctl to return a sync_file fd
> + * in the upper_32_bits(rsvd2) upon success. Ownership of the fd is given
> + * to the caller, and it should be close() after use. (The fd is a regular
> + *
Tried 4.8-rc4 on my i5-2400 PC, got this warning:
[ 14.579557] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[ 15.847321] [ cut here ]
[ 15.847346] WARNING: CPU: 0 PID: 208 at drivers/gpu/drm/i915/intel_pm.c:7866
sandybridge_pcode_write+0x109/0x1f0 [i915]
[
== Series Details ==
Series: series starting with [01/11] drm/amdgpu: Remove call to
reservation_object_test_signaled_rcu before wait
URL : https://patchwork.freedesktop.org/series/11705/
State : warning
== Summary ==
Series 11705v1 Series without cover letter
http://patchwork.freedesktop.org
Op 26-08-16 om 12:59 schreef Chris Wilson:
> According to the CI test machines, SNB also uses the
> GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE value to report a bad
> GEN6_PCODE_MIN_FREQ_TABLE request.
>
> [ 157.744641] WARNING: CPU: 5 PID: 9238 at
> drivers/gpu/drm/i915/intel_pm.c:7760 sandy
On Sun, 28 Aug 2016, Andrea Arcangeli wrote:
> Skylake was already singled out, but it doesn't cover the XPS 13 L332X
> model which is based on IvyBridge.
>
> The commit that introduced the regression is
> 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
That's a merge commit, the real one is
commit a05
In order to be completely generic, we have to double check the read
seqlock after acquiring a reference to the fence. If the driver is
allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
within an RCU grace period a fence may be freed and reallocated. The RCU
read side critical
In order to be completely generic, we have to double check the read
seqlock after acquiring a reference to the fence. If the driver is
allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
within an RCU grace period a fence may be freed and reallocated. The RCU
read side critical
In order to be completely generic, we have to double check the read
seqlock after acquiring a reference to the fence. If the driver is
allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
within an RCU grace period a fence may be freed and reallocated. The RCU
read side critical
With the seqlock now extended to cover the lookup of the fence and its
testing, we can perform that testing solely under the seqlock guard and
avoid the effective locking and serialisation of acquiring a reference to
the request. As the fence is RCU protected we know it cannot disappear
as we test
Currently we install a callback for performing poll on a dma-buf,
irrespective of the timeout. This involves taking a spinlock, as well as
unnecessary work, and greatly reduces scaling of poll(.timeout=0) across
multiple threads.
We can query whether the poll will block prior to installing the
cal
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy chec
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy chec
This variant of fence_get_rcu() takes an RCU protected pointer to a
fence and carefully returns a reference to the fence ensuring that it is
not reallocated as it does. This is required when mixing fences and
SLAB_DESTROY_BY_RCU - although it serves a more pedagogical function atm
Signed-off-by: C
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy chec
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy chec
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy chec
83 matches
Mail list logo
