Discussed with Umesh today. Below is what we came up with.
On Tue, 17 Mar 2020 17:03:30 -0700, Lionel Landwerlin wrote:
> On 16/03/2020 21:23, Dixit, Ashutosh wrote:
> > On Thu, 12 Mar 2020 16:04:59 -0700, Umesh Nerlige Ramappa wrote:
> >> From: Lionel Landwerlin
> >>
> >> We're about to introduc
Hi Dave & Daniel -
Nothing spectacular.
drm-intel-fixes-2020-03-19:
drm/i915 fixes for v5.6-rc7:
- Track active elements during dequeue
- Fix failure to handle all MCR ranges
- Revert unnecessary workaround
BR,
Jani.
The following changes since commit fb33c6510d5595144d585aa194d377cf74d31911
On 2020-03-18 at 18:48:27 +0200, Ville Syrjälä wrote:
> On Fri, Mar 13, 2020 at 12:39:17AM -0700, Lucas De Marchi wrote:
> > On Wed, Mar 11, 2020 at 02:06:32PM +0530, Anshuman Gupta wrote:
> > >Allow 3-display pipes SKU system with any combination
> > >in INTEL_INFO pipe mask.
> > >B.Spec:50075
> >
As we store the handle lookup inside a radix tree, we do not need the
gem_context->mutex except until we need to insert our lookup into the
common radix tree. This takes a small bit of rearranging to ensure that
the lut we insert into the tree is ready prior to actually inserting it
(as soon as it
%pS includes the offset, which is useful for return addresses but noise
when we are pretty printing a known (and expected) function entry point.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 2 +-
drivers/gpu
If we want to percolate information back from the HW, up through the GEM
context, we need to wait until the intel_context is scheduled out for
the last time. This is handled by the retirement of the intel_context's
barrier, i.e. by listening to the pulse after the notional unpin.
To accommodate th
Currently, we only combine a sentinel request with a max-priority
barrier such that a sentinel request is always in ELSP[0] with nothing
following it. However, we will want to create similar ELSP[] submissions
providing a full-barrier in the submission queue, but without forcing
maximum priority. A
== Series Details ==
Series: series starting with [1/4] drm/i915: Prefer '%ps' for printing function
symbol names
URL : https://patchwork.freedesktop.org/series/74864/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8157 -> Patchwork_17020
==
Currently, we only combine a sentinel request with a max-priority
barrier such that a sentinel request is always in ELSP[0] with nothing
following it. However, we will want to create similar ELSP[] submissions
providing a full-barrier in the submission queue, but without forcing
maximum priority. A
I need to keep the GEM context around a bit longer so adding an explicit
flag for syncing execbuf with closed/abandonded contexts.
v2:
* Use already available context flags. (Chris)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/g
%pS includes the offset, which is useful for return addresses but noise
when we are pretty printing a known (and expected) function entry point.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 2 +-
drivers/gpu
Currently, we only combine a sentinel request with a max-priority
barrier such that a sentinel request is always in ELSP[0] with nothing
following it. However, we will want to create similar ELSP[] submissions
providing a full-barrier in the submission queue, but without forcing
maximum priority. A
As we store the handle lookup inside a radix tree, we do not need the
gem_context->mutex except until we need to insert our lookup into the
common radix tree. This takes a small bit of rearranging to ensure that
the lut we insert into the tree is ready prior to actually inserting it
(as soon as it
Use the restored ability to check if a context is closed to decide
whether or not to immediately ban the context from further execution
after a hang.
Fixes: be90e344836a ("drm/i915/gt: Cancel banned contexts after GT reset")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
If we want to percolate information back from the HW, up through the GEM
context, we need to wait until the intel_context is scheduled out for
the last time. This is handled by the retirement of the intel_context's
barrier, i.e. by listening to the pulse after the notional unpin.
To accommodate th
Bspec says that we should timeout after 500us. Let's match this in the
code. It may help with few of the timeouts we see here and there.
Bspec: 22243, 49190
Issue: https://gitlab.freedesktop.org/drm/intel/issues/1069
Suggested-by: Uma Shankar
Cc: Imre Deak
Signed-off-by: Arkadiusz Hiler
---
dr
On Thu, Mar 19, 2020 at 11:20:34AM +0200, Arkadiusz Hiler wrote:
> Bspec says that we should timeout after 500us. Let's match this in the
> code. It may help with few of the timeouts we see here and there.
Plese disregard. it's 500us when waiting on non-idle and only 8 (16
for BXT) for back to idl
== Series Details ==
Series: series starting with [1/4] drm/i915: Prefer '%ps' for printing function
symbol names (rev2)
URL : https://patchwork.freedesktop.org/series/74864/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8157 -> Patchwork_17021
===
On Sat, 14 Mar 2020, Wambui Karuga wrote:
> This patchset continues the conversion of printk based macros to use
> the struct drm_device based drm logging macros focused on the i915/gt
> folder.
> These patches were achieved using both coccinelle and manually.
Pushed the lot, thanks for the patch
On Tue, 17 Mar 2020, Manasi Navare wrote:
> DP sink device sets the Ignore MSA bit in its
> DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
> ignore the MSA video timing paramaters and its ability to support
> seamless video timing change over a range of timing exposed by
> DisplayID
On Tue, 17 Mar 2020, Manasi Navare wrote:
> This patch adds a hook in drm_connector_helper_funcs to get the
> support of the driver for adaptive sync functionality.
>
> This can be called in the connector probe helper function after
> the connector detect() and get_modes() hooks to also
> query th
On Tue, 17 Mar 2020, Manasi Navare wrote:
> This defines the get_vrr_support hook for intel DP connector
> VRR support is set to true based on the DPCD ignore MSA and
> EDID monitor range
Yeah... but what do you use it for?
>
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Ni
== Series Details ==
Series: series starting with [1/6] drm/i915: Prefer '%ps' for printing function
symbol names
URL : https://patchwork.freedesktop.org/series/74865/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8157 -> Patchwork_17022
==
Introduce new plane and CRTC scaling filter properties to allow
userspace to select the driver's default scaling filter or
Nearest-neighbor(NN) filter for upscaling operations on CRTC and
plane.
Drivers can set up this property for a plane by calling
drm_plane_enable_scaling_filter() and for a CRT
This series is the continuation for the RFC that I posted earlier [1]
[1] RFC: https://patchwork.freedesktop.org/series/73884/
Integer scaling (IS) is a nearest-neighbor upscaling technique that
simply scales up the existing pixels by an integer (i.e., whole
number) multiplier. Nearest-neighbor (
Add documentation for newly introduced KMS plane and CRTC scaling
filter properties.
changes since v1:
* None
changes since RFC:
* Add separate documentation for plane and CRTC.
Signed-off-by: Pankaj Bharadiya
---
Documentation/gpu/drm-kms.rst | 12
1 file changed, 12 insertions(+)
Integer scaling (IS) is a nearest-neighbor upscaling technique that
simply scales up the existing pixels by an integer
(i.e., whole number) multiplier.Nearest-neighbor (NN) interpolation
works by filling in the missing color values in the upscaled image
with that of the coordinate-mapped nearest so
GEN >= 10 hardware supports the programmable scaler filter.
Attach scaling filter property for CRTC and plane for GEN >= 10
hardwares and program scaler filter based on the selected filter
type.
changes since v1:
* None
Changes since RFC:
* Enable properties for GEN >= 10 platforms (Ville)
* Do n
Introduce scaler registers and bit fields needed to configure the
scaling filter in prgrammed mode and configure scaling filter
coefficients.
changes since v1:
* None
changes since RFC:
* Parametrize scaler coeffient macros by 'set' (Ville)
Signed-off-by: Shashank Sharma
Signed-off-by: Ankit Nau
On Wednesday, March 11, 2020 8:23:19 PM CET Francisco Jerez wrote:
> The purpose of this PM QoS limit is to give device drivers additional
> control over the latency/energy efficiency trade-off made by the PM
> subsystem (particularly the CPUFREQ governor). It allows device
> drivers to set a lowe
On Tuesday, March 10, 2020 10:41:57 PM CET Francisco Jerez wrote:
> This reverts commit c4f3f70cacba2fa19545389a12d09b606d2ad1cf. A
> future commit will introduce a new update_util implementation, so the
> pstate_funcs table entry is going to be useful.
This basically means that you want to intro
== Series Details ==
Series: Introduce drm scaling filter property (rev3)
URL : https://patchwork.freedesktop.org/series/73883/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
51d1ea0ac87f drm: Introduce plane and CRTC scaling filter properties
-:138: CHECK:PARENTHESIS_ALIGNMENT:
On Tuesday, March 10, 2020 10:41:58 PM CET Francisco Jerez wrote:
> The goal of the helper code introduced here is to compute two
> informational data structures: struct vlp_input_stats aggregating
> various scheduling and PM statistics gathered in every call of the
> update_util() hook, and struct
== Series Details ==
Series: series starting with [1/4] drm/i915: Prefer '%ps' for printing function
symbol names (rev2)
URL : https://patchwork.freedesktop.org/series/74864/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8157_full -> Patchwork_17021_full
=
On Tuesday, March 10, 2020 10:41:59 PM CET Francisco Jerez wrote:
> The function introduced here calculates a P-state range derived from
> the statistics computed in the previous patch which will be used to
> drive the HWP P-state range or (if HWP is not available) as basis for
> some additional ke
== Series Details ==
Series: Introduce drm scaling filter property (rev3)
URL : https://patchwork.freedesktop.org/series/73883/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8158 -> Patchwork_17023
Summary
---
**SUCC
On Tuesday, March 10, 2020 10:42:01 PM CET Francisco Jerez wrote:
> For the moment the VLP controller is only enabled on ICL platforms
> other than server FADT profiles in order to reduce the validation
> effort of the initial submission. It should work on any other
> processors that support HWP t
== Series Details ==
Series: series starting with [1/6] drm/i915: Prefer '%ps' for printing function
symbol names
URL : https://patchwork.freedesktop.org/series/74865/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8157_full -> Patchwork_17022_full
Op 18-03-2020 om 15:37 schreef Shankar, Uma:
>
>> -Original Message-
>> From: Maarten Lankhorst
>> Sent: Wednesday, March 18, 2020 5:46 PM
>> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
>> Cc: Ville Syrjälä ; Kai Vehmanen
>> ; Khor, Swee Aun
>> Subject: Re: [PATCH] drm/i915/display
On Wed, Mar 18, 2020 at 02:50:55PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 18, 2020 at 11:52:13AM +, Lisovskiy, Stanislav wrote:
> > >> @@ -5829,6 +6068,10 @@ skl_compute_wm(struct intel_atomic_state *state)
> > >>return ret;
> > >>}
> > >>
> > >> + ret = i
== Series Details ==
Series: Introduce drm scaling filter property (rev3)
URL : https://patchwork.freedesktop.org/series/73883/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8158_full -> Patchwork_17023_full
Summary
---
On Wed, Mar 18, 2020 at 03:34:38PM -0700, Manasi Navare wrote:
> On Fri, Mar 13, 2020 at 06:48:20PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > This port sync enable/disable stuff is misplaced. It's just another step
> > of the normal TRANS_DDI_FUNC_CTL enable. Move it to its natu
On Wed, Mar 18, 2020 at 03:37:32PM -0700, Manasi Navare wrote:
> On Fri, Mar 13, 2020 at 06:48:21PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The entire crtc state has been reset before readout so
> > master_transcoder is already set to INVALID.
>
> But wont that mean that the
On 19/03/2020 09:19, Chris Wilson wrote:
%pS includes the offset, which is useful for return addresses but noise
when we are pretty printing a known (and expected) function entry point.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence.c | 2 +-
drivers/gpu/drm/i9
On 19/03/2020 09:19, Chris Wilson wrote:
As we store the handle lookup inside a radix tree, we do not need the
gem_context->mutex except until we need to insert our lookup into the
common radix tree. This takes a small bit of rearranging to ensure that
the lut we insert into the tree is ready p
On 19/03/2020 09:19, Chris Wilson wrote:
> Currently, we only combine a sentinel request with a max-priority
> barrier such that a sentinel request is always in ELSP[0] with nothing
> following it. However, we will want to create similar ELSP[] submissions
> providing a full-barrier in the submis
On 19/03/2020 09:19, Chris Wilson wrote:
If we want to percolate information back from the HW, up through the GEM
context, we need to wait until the intel_context is scheduled out for
the last time. This is handled by the retirement of the intel_context's
barrier, i.e. by listening to the pulse
On 19/03/2020 09:19, Chris Wilson wrote:
Use the restored ability to check if a context is closed to decide
whether or not to immediately ban the context from further execution
after a hang.
Fixes: be90e344836a ("drm/i915/gt: Cancel banned contexts after GT reset")
Signed-off-by: Chris Wilson
A nasty issue was found with the way we serialise the update of the GTT
(GPU virtual address space) on the GEM context and with execution via
execbuf. On update we serialise with ctx->mutex and attempt to rewrite
the GTT addresses stored within the context from inside a request (along
that context)
Allow some users the discretion to not immediately return on a normal
signal. Hopefully, they will opt to use TASK_KILLABLE instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 6 --
drivers/gpu/drm/i915/i915_active.h | 6 +-
2 files changed, 9 insertions(+), 3 d
On 19/03/2020 14:40, Tvrtko Ursulin wrote:
On 19/03/2020 09:19, Chris Wilson wrote:
Use the restored ability to check if a context is closed to decide
whether or not to immediately ban the context from further execution
after a hang.
Fixes: be90e344836a ("drm/i915/gt: Cancel banned contexts a
Allow the kernel the rights to reject updating an active VM with -EBUSY.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_param.c | 13 +++--
tests/i915/gem_vm_create.c | 11 ++-
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/tests/i915/gem_ctx_param.c b/tests/
Quoting Tvrtko Ursulin (2020-03-19 14:20:04)
>
> On 19/03/2020 09:19, Chris Wilson wrote:
> > +static struct i915_vma *eb_lookup_vma(struct i915_execbuffer *eb, u32
> > handle)
> > +{
> > + do {
> > + struct drm_i915_gem_object *obj;
> > struct i915_vma *vma;
> > +
Quoting Tvrtko Ursulin (2020-03-19 14:31:36)
>
> On 19/03/2020 09:19, Chris Wilson wrote:
> > + if (has_sentinel(last, rq))
> > goto done;
>
> I am only confused by can_merge_rq saying two sentinel requests can be
> merged together
On 18/03/2020 13:58, Andi Shyti wrote:
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_gem_drop_caches
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
gt
|
+-- dro
On 19/03/2020 15:02, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-03-19 14:31:36)
On 19/03/2020 09:19, Chris Wilson wrote:
+ if (has_sentinel(last, rq))
goto done;
I am only confused by can_merge_rq saying two sentinel
Quoting Tvrtko Ursulin (2020-03-19 15:11:49)
>
> On 19/03/2020 15:02, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-03-19 14:31:36)
> >>
> >> On 19/03/2020 09:19, Chris Wilson wrote:
> >>> + if (has_sentinel(last, rq))
> >>>
Quoting Chris Wilson (2020-03-19 15:21:41)
> First though, I have to answer the question of how I broke persistence.
Fwiw, it's the await_active update. Time to double check whether it is
flushing the barrier on demand.
-Chris
___
Intel-gfx mailing list
On Thu, Mar 19, 2020 at 12:09:18PM +0530, Manna, Animesh wrote:
> On 19-03-2020 01:34, Manasi Navare wrote:
> > On Wed, Mar 18, 2020 at 12:05:14PM +0530, Animesh Manna wrote:
> >> DP_COMP_CTL and DP_COMP_PAT register used to program DP
> >> compliance pattern.
> >>
> >> v1: Initial patch.
> >> v2:
Quoting Chris Wilson (2020-03-19 14:52:21)
> Quoting Tvrtko Ursulin (2020-03-19 14:20:04)
> >
> > On 19/03/2020 09:19, Chris Wilson wrote:
> > > +static struct i915_vma *eb_lookup_vma(struct i915_execbuffer *eb, u32
> > > handle)
> > > +{
> > > + do {
> > > + struct drm_i915_gem_o
== Series Details ==
Series: series starting with [1/2] drm/i915: Allow for different modes of
interruptible i915_active_wait
URL : https://patchwork.freedesktop.org/series/74877/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8159 -> Patchwork_17024
==
On Thu, Mar 19, 2020 at 01:23:18PM +0530, Anshuman Gupta wrote:
> On 2020-03-18 at 18:48:27 +0200, Ville Syrjälä wrote:
> > On Fri, Mar 13, 2020 at 12:39:17AM -0700, Lucas De Marchi wrote:
> > > On Wed, Mar 11, 2020 at 02:06:32PM +0530, Anshuman Gupta wrote:
> > > >Allow 3-display pipes SKU system
On Thu, Mar 19, 2020 at 11:30:03AM +0200, Arkadiusz Hiler wrote:
> On Thu, Mar 19, 2020 at 11:20:34AM +0200, Arkadiusz Hiler wrote:
> > Bspec says that we should timeout after 500us. Let's match this in the
> > code. It may help with few of the timeouts we see here and there.
>
> Plese disregard.
From: Ville Syrjälä
The DP link computation functions shouldn't modify the
adjusted_mode so make it const.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
From: Ville Syrjälä
Some new eDP panels don't like to operate at the max parameters, and
instead we need to go for an optimal confiugration. That unfortunately
doesn't work with older eDP panels which are generally only guaranteed
to work at the max parameters.
To solve these two conflicting req
From: Ville Syrjälä
Pull the common parts of intel_dp_compute_link_config_wide()
and intel_dp_compute_link_config_fast() into a shared helper
to avoid duplicated code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 76 ++---
1 file changed, 44 in
Hi,
On 3/19/20 5:38 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Some new eDP panels don't like to operate at the max parameters, and
instead we need to go for an optimal confiugration. That unfortunately
doesn't work with older eDP panels which are generally only guaranteed
to work at the max
Quoting Chris Wilson (2020-03-19 15:31:41)
> Quoting Chris Wilson (2020-03-19 15:21:41)
> > First though, I have to answer the question of how I broke persistence.
>
> Fwiw, it's the await_active update. Time to double check whether it is
> flushing the barrier on demand.
And it's because I didn'
On Thu, Mar 19, 2020 at 05:53:08PM +0100, Hans de Goede wrote:
> Hi,
>
> On 3/19/20 5:38 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Some new eDP panels don't like to operate at the max parameters, and
> > instead we need to go for an optimal confiugration. That unfortunately
> > do
I need to keep the GEM context around a bit longer so adding an explicit
flag for syncing execbuf with closed/abandonded contexts.
v2:
* Use already available context flags. (Chris)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/g
Use the restored ability to check if a context is closed to decide
whether or not to immediately ban the context from further execution
after a hang.
Fixes: be90e344836a ("drm/i915/gt: Cancel banned contexts after GT reset")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
On Mon, 2020-03-16 at 13:56 +, Lee, Shawn C wrote:
> On Wed, 2020-03-11, Lyude Paul wrote:
> > On Tue, 2020-01-07 at 01:41 +0800, Lee Shawn C wrote:
> > > Driver report physcial bandwidth for max dot clock rate.
> > > It would caused compatibility issue sometimes when physical bandwidth
> > >
This is required for legacy/static TC ports as IOM is not aware of
the connection and will not trigger the TC cold exit.
Just request PCODE to exit TCCOLD is not enough as it could enter
again be driver makes use of the port, to prevent it BSpec states that
aux powerwell should be held.
So before
== Series Details ==
Series: series starting with [1/3] drm/i915: Try to use fast+narrow link on eDP
again and fall back to the old max strategy on failure
URL : https://patchwork.freedesktop.org/series/74879/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8160 -> Patchwork_17
Testing part is left with TODO comment for anything older than gen5
Test-with: 20200319180322.5451-1-juhapekka.heikk...@gmail.com
Juha-Pekka Heikkila (1):
drm/i915: Allow gen11 to use over 32k long strides
drivers/gpu/drm/i915/display/intel_sprite.c | 30 -
1 file changed,
The stride in bytes must not exceed the size of 8K pixels.
Linear 64 bpp pixel format maximum stride in tiles is 1024
which would mean gen11 support 64k long stride.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/display/intel_sprite.c | 30 -
1 file changed, 24
== Series Details ==
Series: series starting with [1/2] drm/i915: Allow for different modes of
interruptible i915_active_wait
URL : https://patchwork.freedesktop.org/series/74877/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8159_full -> Patchwork_17024_full
On Wed, 2020-03-18 at 17:00 +0530, Uma Shankar wrote:
> If external monitors are connected during boot up, driver
> uses the same mode programmed by BIOS and avoids a full modeset.
> This results in display audio codec left uninitialized and
> display audio fails to work till user triggers a modese
== Series Details ==
Series: series starting with [1/3] drm/i915: Try to use fast+narrow link on eDP
again and fall back to the old max strategy on failure
URL : https://patchwork.freedesktop.org/series/74879/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8160_full -> Patchwo
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Use explicit flag to mark
unreachable intel_context
URL : https://patchwork.freedesktop.org/series/74880/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8160 -> Patchwork_17026
===
The stride in bytes must not exceed the size of 8K pixels.
Linear 64 bpp pixel format maximum stride in tiles is 1024
which would mean gen11 support 64k long stride.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/display/intel_sprite.c | 30 -
1 file changed, 24
Testing part is left with TODO comment for anything older than gen5
Resend because IGT part failed.
Test-with: 20200319193644.7417-1-juhapekka.heikk...@gmail.com
Juha-Pekka Heikkila (1):
drm/i915: Allow gen11 to use over 32k long strides
drivers/gpu/drm/i915/display/intel_sprite.c | 30 ++
On Wed, Mar 18, 2020 at 09:08:45PM +0200, Jani Nikula wrote:
> On Tue, 17 Mar 2020, Guru Das Srinagesh wrote:
> > Since the PWM framework is switching struct pwm_state.duty_cycle's
> > datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
> > to handle a 64-bit dividend.
> >
> > C
== Series Details ==
Series: series starting with [1/6] drm/i915/tc/tgl: Implement TCCOLD sequences
(rev2)
URL : https://patchwork.freedesktop.org/series/74851/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8160 -> Patchwork_17027
=
== Series Details ==
Series: Test over 32k long stride length on icl+ (rev2)
URL : https://patchwork.freedesktop.org/series/74884/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
62029b8972b3 drm/i915: Allow gen11 to use over 32k long strides
-:33: CHECK:SPACING: spaces preferred
On Wed, 2020-03-18 at 15:30 +0200, Ville Syrjälä wrote:
> On Fri, Mar 06, 2020 at 01:32:12AM +, Souza, Jose wrote:
> > On Thu, 2020-02-20 at 19:26 +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 18, 2020 at 05:42:30PM -0800, José Roberto de Souza
> > > wrote:
> > > > dGFX have local memory so it
On Wed, 2020-03-18 at 14:44 +0200, Ville Syrjälä wrote:
> On Thu, Mar 12, 2020 at 12:35:56AM +, Souza, Jose wrote:
> > On Thu, 2020-03-05 at 17:33 -0800, José Roberto de Souza wrote:
> > > On Thu, 2020-02-20 at 19:26 +0200, Ville Syrjälä wrote:
> > > > On Tue, Feb 18, 2020 at 05:42:30PM -0800,
dGFX have local memory so it do not have aperture and do not support
CPU fences but even for iGFX it have a small number of fences.
As replacement for fences to track frontbuffer modifications by CPU
we have a software tracking that is already in used by FBC and PSR.
PSR don't support fences so it
== Series Details ==
Series: Test over 32k long stride length on icl+ (rev2)
URL : https://patchwork.freedesktop.org/series/74884/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8160 -> Patchwork_17028
Summary
---
**S
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Use explicit flag to mark
unreachable intel_context
URL : https://patchwork.freedesktop.org/series/74880/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8160_full -> Patchwork_17026_full
=
On Thu, Mar 19, 2020 at 06:02:22PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 19, 2020 at 12:09:18PM +0530, Manna, Animesh wrote:
> > On 19-03-2020 01:34, Manasi Navare wrote:
> > > On Wed, Mar 18, 2020 at 12:05:14PM +0530, Animesh Manna wrote:
> > >> DP_COMP_CTL and DP_COMP_PAT register used to pro
== Series Details ==
Series: drm/i915/display/fbc: Make fences a nice-to-have for GEN9+
URL : https://patchwork.freedesktop.org/series/74890/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8160 -> Patchwork_17029
Summary
---
On Thu, Mar 19, 2020 at 06:38:42PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Some new eDP panels don't like to operate at the max parameters, and
> instead we need to go for an optimal confiugration. That unfortunately
> doesn't work with older eDP panels which are generally only guar
On Thu, Mar 19, 2020 at 12:14:28PM +0200, Jani Nikula wrote:
> On Tue, 17 Mar 2020, Manasi Navare wrote:
> > This defines the get_vrr_support hook for intel DP connector
> > VRR support is set to true based on the DPCD ignore MSA and
> > EDID monitor range
>
> Yeah... but what do you use it for?
On Thu, Mar 19, 2020 at 12:07:37PM +0200, Jani Nikula wrote:
> On Tue, 17 Mar 2020, Manasi Navare wrote:
> > This patch adds a hook in drm_connector_helper_funcs to get the
> > support of the driver for adaptive sync functionality.
> >
> > This can be called in the connector probe helper function
On Thu, Mar 19, 2020 at 11:59:38AM +0200, Jani Nikula wrote:
> On Tue, 17 Mar 2020, Manasi Navare wrote:
> > DP sink device sets the Ignore MSA bit in its
> > DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
> > ignore the MSA video timing paramaters and its ability to support
> > seam
== Series Details ==
Series: series starting with [1/6] drm/i915/tc/tgl: Implement TCCOLD sequences
(rev2)
URL : https://patchwork.freedesktop.org/series/74851/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8160_full -> Patchwork_17027_full
===
Hi all,
This is a revival of an earlier patch series submitted by Lionel
Landwerlin - https://patchwork.freedesktop.org/series/54280/
The patches enable interrupt support for the perf OA unit in
i915, further details can be found in the orignal series linked
above.
v2: (Umesh)
- This series will
From: Lionel Landwerlin
We're about to introduce an options to open the perf stream, giving
the user ability to configure how often it wants the kernel to poll
the OA registers for available data.
Right now the workaround against the OA tail pointer race condition
requires at least twice the int
From: Lionel Landwerlin
This new parameter let's the application choose how often the OA
buffer should be checked on the CPU side for data availability. Longer
polling period tend to reduce CPU overhead if the application does not
care about somewhat real time data collection.
v2: Allow disablin
1 - 100 of 109 matches
Mail list logo
