== Series Details ==
Series: In order to readout DP SDPs, refactors the handling of DP SDPs (rev7)
URL : https://patchwork.freedesktop.org/series/72853/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7905 -> Patchwork_16516
== Series Details ==
Series: drm/i915: HDCP support on above PORT_E
URL : https://patchwork.freedesktop.org/series/73153/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7887_full -> Patchwork_16483_full
Summary
---
**
== Series Details ==
Series: drm/mm: Break long searches in fragmented address spaces
URL : https://patchwork.freedesktop.org/series/73154/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7887_full -> Patchwork_16484_full
Sum
On Fri, 07 Feb 2020, Anshuman Gupta wrote:
> As Gen12 onwards there are HDCP instances for each transcoder
> instead of port, remove the (port < PORT_E) hdcp support
> limitation for platform >= Gen12.
>
> v2:
> - Nuke the comment and cosmetic changes. [Jani]
>
> Cc: Jani Nikula
> Cc: Ramalingam
On Mon, Feb 10, 2020 at 04:46:11PM -0800, Dale B Stimson wrote:
> Signed-off-by: Dale B Stimson
> ---
> lib/Makefile.sources | 2 +
> lib/i915/gem_mmio_base.c | 346 +++
> lib/i915/gem_mmio_base.h | 19 +++
> lib/igt.h| 1 +
> lib/meson
When roll over detected for seq_num_m, we shouldn't continue with stream
management with rolled over value.
So we are terminating the stream management retry, on roll over of the
seq_num_m.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 10 --
1 file changed
As per the HDCP2.2 compliance test 1B-10 expectation, when stream
management for a repeater fails, we retry thrice and when it fails
in all retries, HDCP2.2 reauthentication aborted at kernel.
v2:
seq_num_m++ is extended for steam management failures too.[Anshuman]
Signed-off-by: Ramalingam C
On Tue, 11 Feb 2020, Petri Latvala wrote:
>> diff --git a/lib/i915/gem_mmio_base.c b/lib/i915/gem_mmio_base.c
>> new file mode 100644
>> index 0..8718c092f
>> --- /dev/null
>> +++ b/lib/i915/gem_mmio_base.c
>> @@ -0,0 +1,346 @@
>> +// Copyright (C) 2020 Intel Corporation
>> +//
>> +// SP
On Tue, Feb 11, 2020 at 11:30:03AM +0200, Jani Nikula wrote:
> On Tue, 11 Feb 2020, Petri Latvala wrote:
> >> diff --git a/lib/i915/gem_mmio_base.c b/lib/i915/gem_mmio_base.c
> >> new file mode 100644
> >> index 0..8718c092f
> >> --- /dev/null
> >> +++ b/lib/i915/gem_mmio_base.c
> >> @@ -0
On 2020-02-11 7:13 a.m., Nathan Chancellor wrote:
> A recent commit in clang added -Wtautological-compare to -Wall, which is
> enabled for i915 so we see the following warning:
>
> ../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1485:22: warning:
> result of comparison of constant 57646075230342
On Tue, Feb 11, 2020 at 11:37:32AM +0200, Petri Latvala wrote:
> On Tue, Feb 11, 2020 at 11:30:03AM +0200, Jani Nikula wrote:
> > On Tue, 11 Feb 2020, Petri Latvala wrote:
> > >> diff --git a/lib/i915/gem_mmio_base.c b/lib/i915/gem_mmio_base.c
> > >> new file mode 100644
> > >> index 0..87
Quoting Andi Shyti (2020-02-11 00:42:55)
> Hi Chris,
>
> On Tue, Feb 11, 2020 at 12:37:42AM +, Chris Wilson wrote:
> > The engine names are now stored inside the iterator and not as static
> > strings. If we wish to use them later, we need to make a copy.
>
> But we are not using them later.
On Thu, 2020-01-16 at 17:58 -0800, José Roberto de Souza wrote:
> This is a eDP function and it will always returns true for non-eDP
> ports.
>
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/
On Mon, Feb 10, 2020 at 10:47:36AM +0100, Thomas Zimmermann wrote:
> Hi,
>
> I smoke-tested the patchset by running X11, Weston and fbdev emulation
> on ast and udl. No apparent problems found, so
>
> Tested-by: Thomas Zimmermann
Merged patches 2-5 (first one needs to wait for amdgpu/radeon pat
On Thu, 2020-01-16 at 17:58 -0800, José Roberto de Souza wrote:
> TGL timeouts when disabling MST transcoder and fifo underruns over
> MST
> transcoders are fixed when setting TRANS_DDI_MODE_SELECT to 0(HDMI
> mode) during the disable sequence.
>
> Although BSpec disable sequence don't require thi
Quoting Janusz Krzysztofik (2020-02-04 11:41:13)
> On future hardware with missing GGTT BAR we won't be able to exercise
> dma-buf access via that path. An alternative to basic-gtt subtest for
> testing dma-buf access is required, as well as basic-fence-mmap and
> coherency-gtt subtest alternative
I guess it would still be nice to make the code less confusing
and do not call eDP specific function, for non-eDP connectors
just to immediately return true(success) value as a hack.
So simply extracted that check out from this function,
that we simply don't call it for non-eDP connectors. Bingo.
Hi Chris,
> We manipulate ring->head while active in i915_request_retire underneath
> the timeline manipulation. We cannot rely on a stable ring->head outside
> of the timeline->mutex, in particular while setting up the context for
> resume and reset.
>
> Closes: https://gitlab.freedesktop.org/dr
Chris Wilson writes:
> We manipulate ring->head while active in i915_request_retire underneath
> the timeline manipulation. We cannot rely on a stable ring->head outside
> of the timeline->mutex, in particular while setting up the context for
> resume and reset.
This solves the immediate problem
We manipulate ring->head while active in i915_request_retire underneath
the timeline manipulation. We cannot rely on a stable ring->head outside
of the timeline->mutex, in particular while setting up the context for
resume and reset.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1126
Fix
On Tue, Feb 11, 2020 at 01:40:38PM +0200, Stanislav Lisovskiy wrote:
> I guess it would still be nice to make the code less confusing
> and do not call eDP specific function, for non-eDP connectors
> just to immediately return true(success) value as a hack.
>
> So simply extracted that check out f
On retiring the request, we should not re-use these elements in the ring
(at least not until we fill the ringbuffer and knowingly reuse the space).
Leave behind some poison to (hopefully) trap ourselves if we make a
mistake.
Suggested-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Cc: Mika Kuoppa
On 11/02/2020 10:37, Chris Wilson wrote:
Quoting Andi Shyti (2020-02-11 00:42:55)
Hi Chris,
On Tue, Feb 11, 2020 at 12:37:42AM +, Chris Wilson wrote:
The engine names are now stored inside the iterator and not as static
strings. If we wish to use them later, we need to make a copy.
But
On Tue, 11 Feb 2020, Stanislav Lisovskiy wrote:
> I guess it would still be nice to make the code less confusing
> and do not call eDP specific function, for non-eDP connectors
> just to immediately return true(success) value as a hack.
>
> So simply extracted that check out from this function,
>
Quoting Tvrtko Ursulin (2020-02-11 13:00:19)
>
> On 11/02/2020 10:37, Chris Wilson wrote:
> > Quoting Andi Shyti (2020-02-11 00:42:55)
> >> Hi Chris,
> >>
> >> On Tue, Feb 11, 2020 at 12:37:42AM +, Chris Wilson wrote:
> >>> The engine names are now stored inside the iterator and not as static
On 11/02/2020 13:05, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-02-11 13:00:19)
On 11/02/2020 10:37, Chris Wilson wrote:
Quoting Andi Shyti (2020-02-11 00:42:55)
Hi Chris,
On Tue, Feb 11, 2020 at 12:37:42AM +, Chris Wilson wrote:
The engine names are now stored inside the iterat
On Tue, 2020-02-11 at 15:03 +0200, Jani Nikula wrote:
> On Tue, 11 Feb 2020, Stanislav Lisovskiy <
> stanislav.lisovs...@intel.com> wrote:
> > I guess it would still be nice to make the code less confusing
> > and do not call eDP specific function, for non-eDP connectors
> > just to immediately ret
On 10/02/2020 20:57, Chris Wilson wrote:
If we have a set of active engines marked as being non-persistent, we
lose track of those if the user replaces those engines with
I915_CONTEXT_PARAM_ENGINES. As part of our uABI contract is that
non-persistent requests are terminated if they are no longe
drm->dev_private is to be avoided. Use to_i915() on the struct
drm_device pointer instead. Rename the affected local dev_priv variables
to i915 while at it.
Cc: Wambui Karuga
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 25 +--
1 file changed, 1
On Thu, 06 Feb 2020, Wambui Karuga wrote:
> @@ -1364,11 +1372,15 @@ int intel_hdmi_hdcp_write_an_aksv(struct
> intel_digital_port *intel_dig_port,
> static int intel_hdmi_hdcp_read_bksv(struct intel_digital_port
> *intel_dig_port,
>u8 *bksv)
> {
> + stru
Chris Wilson writes:
> On retiring the request, we should not re-use these elements in the ring
> (at least not until we fill the ringbuffer and knowingly reuse the space).
> Leave behind some poison to (hopefully) trap ourselves if we make a
> mistake.
>
> Suggested-by: Mika Kuoppala
> Signed-o
On Tue, 11 Feb 2020, "Lisovskiy, Stanislav"
wrote:
> On Tue, 2020-02-11 at 15:03 +0200, Jani Nikula wrote:
>> On Tue, 11 Feb 2020, Stanislav Lisovskiy <
>> stanislav.lisovs...@intel.com> wrote:
>> > I guess it would still be nice to make the code less confusing
>> > and do not call eDP specific f
On Tue, 2020-02-11 at 15:55 +0200, Jani Nikula wrote:
> On Tue, 11 Feb 2020, "Lisovskiy, Stanislav" <
> stanislav.lisovs...@intel.com> wrote:
> > On Tue, 2020-02-11 at 15:03 +0200, Jani Nikula wrote:
> > > On Tue, 11 Feb 2020, Stanislav Lisovskiy <
> > > stanislav.lisovs...@intel.com> wrote:
> > >
Quoting Mika Kuoppala (2020-02-11 13:53:56)
> Chris Wilson writes:
>
> > On retiring the request, we should not re-use these elements in the ring
> > (at least not until we fill the ringbuffer and knowingly reuse the space).
> > Leave behind some poison to (hopefully) trap ourselves if we make a
On Thu, 06 Feb 2020, Wambui Karuga wrote:
> @@ -5990,11 +6040,13 @@ int intel_dp_hdcp_write_an_aksv(struct
> intel_digital_port *intel_dig_port,
> static int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
> u8 *bksv)
> {
> + struct intel_
On Thu, 06 Feb 2020, Wambui Karuga wrote:
> Conversion of instances of the printk based drm logging macros to the
> struct drm_device based logging macros in i915/display/intel_dp_mst.c.
> This also involves extracting the drm_i915_private device pointer from
> various intel types to use in the ma
On Thu, 06 Feb 2020, Wambui Karuga wrote:
> Conversion of the printk based drm logging macros to the struct
> drm_device based logging macros in display/intel_dp_aux_backlight.c.
> This also involves extracting the drm_i915_private device pointer from
> various intel types to use in the macros.
>
On Thu, 06 Feb 2020, Wambui Karuga wrote:
> This patchset continues the conversion of the printk based drm logging
> macros in drm/i915 to use the struct drm_device based logging macros.
> This series was done both using coccinelle and manually.
Thank you for the patches! I pushed all the patches
On Tue, 11 Feb 2020, "Lisovskiy, Stanislav"
wrote:
> Well, you can just take all those checks and put them into separate
> function. Something like:
>
> bool intel_dp_supports_mst(intel_dp) {
> if (HAS_DP_MST(i915) && !intel_dp_is_edp(intel_dp)) &&
> !(INTEL_GEN(i915) < 12 && p
Quoting Tvrtko Ursulin (2020-02-11 13:41:22)
>
> On 10/02/2020 20:57, Chris Wilson wrote:
> > +static void kill_context(struct i915_gem_context *ctx)
> > +{
> > + if (!list_empty(&ctx->stale.engines))
> > + kill_stale_engines(ctx);
>
> Lets see.. set_engines can freely race with c
On Tue, Feb 11, 2020 at 03:55:45PM +0200, Jani Nikula wrote:
> On Tue, 11 Feb 2020, "Lisovskiy, Stanislav"
> wrote:
> > On Tue, 2020-02-11 at 15:03 +0200, Jani Nikula wrote:
> >> On Tue, 11 Feb 2020, Stanislav Lisovskiy <
> >> stanislav.lisovs...@intel.com> wrote:
> >> > I guess it would still be
On Tue, 2020-02-11 at 16:12 +0200, Jani Nikula wrote:
> On Tue, 11 Feb 2020, "Lisovskiy, Stanislav" <
> stanislav.lisovs...@intel.com> wrote:
> > Well, you can just take all those checks and put them into separate
> > function. Something like:
> >
> > bool intel_dp_supports_mst(intel_dp) {
> >
Working with a userptr GEM object backed by any type of mapping to
another GEM object, not only GTT mapping currently examined bu the
test, may cause a currently unavoidable lockdep splat inside the i915
driver. Then, for as long as that issue is not resolved in the driver,
such operations are exp
If we have a set of active engines marked as being non-persistent, we
lose track of those if the user replaces those engines with
I915_CONTEXT_PARAM_ENGINES. As part of our uABI contract is that
non-persistent requests are terminated if they are no longer being
tracked by the user's context (in ord
Chris Wilson writes:
> Originally, I did not expect having to rewind a context upon
> timeslicing: the point was to replace the executing context with an idle
I think you said 'non executing' and it would fit better.
> one! However, given a second context that depends on requests from the
> fir
Apply vast quantities of poison and not tell anyone to see if we fall
for the trap of using a stale RING_HEAD.
References: 42827350f75c ("drm/i915/gt: Avoid resetting ring->head outside of
its timeline mutex")
Signed-off-by: Chris Wilson
Cc: Andi Shyti
Cc: Mika Kuoppala
---
drivers/gpu/drm/i9
Quoting Mika Kuoppala (2020-02-11 14:50:08)
> Chris Wilson writes:
> > + /* Release the hounds! */
> > + slot[0] = 1;
> > + wmb();
> > +
> > + for (i = 1; i <= 3; i++) {
> > + unsigned long timeout = jiffies + HZ / 2;
> > +
> > +
Chris Wilson writes:
> We can not require that the system process a tasklet in reasonable time
> (thanks be to ksoftirqd), but we can insist that having waited
> sufficiently for the error interrupt to have been raised and having
> kicked the tasklet, the reset has begun and the request will be m
Quoting Mika Kuoppala (2020-02-11 15:23:24)
> Chris Wilson writes:
> > + /* Kick the tasklet to process the error */
> > + intel_engine_flush_submission(engine);
>
> This pattern of usage in selftests makes me want to add mb(); to
> intel_en
== Series Details ==
Series: series starting with [1/2] drm/i915: terminate reauth at stream
management failure
URL : https://patchwork.freedesktop.org/series/73282/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7909 -> Patchwork_16517
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-02-11 15:23:24)
>> Chris Wilson writes:
>> > + /* Kick the tasklet to process the error */
>> > + intel_engine_flush_submission(engine);
>>
>> This pattern of usage in selftests makes me w
Quoting Mika Kuoppala (2020-02-11 15:54:07)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2020-02-11 15:23:24)
> >> Chris Wilson writes:
> >> > + /* Kick the tasklet to process the error */
> >> > + intel_engine_flush_submission(engin
On Mon, 10 Feb 2020, Jani Nikula wrote:
> On Mon, 10 Feb 2020, José Roberto de Souza wrote:
>> Commit 1c9d2eb24153 ("drm/i915: move intel_dp_set_m_n() to encoder for
>> DDI platforms") moved the intel_dp_set_m_n() from hsw_crtc_enable()
>> to intel_ddi_pre_enable_dp() but it missed add it to
>> i
The DMC firmware is about display. Move the handling under display. No
functional changes.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/{ => display}/intel_csr.c | 0
drivers/gpu/drm/i915/{ => display}/intel_csr.h |
On 2020-02-07 at 18:15:31 +0200, Ville Syrjälä wrote:
> On Fri, Feb 07, 2020 at 07:50:36PM +0530, Anshuman Gupta wrote:
> > Updated version after rebase and fixing few comments.
> >
> > Anshuman Gupta (6):
> > drm/i915: Iterate over pipe and skip the disabled one
> > drm/i915: Remove (pipe ==
From: Ville Syrjälä
Another respin of the possible_clones/crtcs fixing.
Changes based on v2 review:
- introduce drm_mode_config_validate()
- WARN for possible_clones!=0 when the encoder
itself isn't in the mask
- update the documentation to match the code
Other changes:
- sligth refactoring o
From: Ville Syrjälä
Many drivers are populating encoder->possible_clones wrong. Let's
persuade them to get it right by adding some loud WARNs.
We'll cross check the bits between any two encoders. So either
both encoders can clone with the other, or neither can.
We'll also complain about effecti
From: Ville Syrjälä
Let's simplify life of driver by allowing them to leave
encoder->possible_crtcs unset if they have no restrictions
in crtc<->encoder linkage. We'll just populate possible_crtcs
with the full crtc mask when registering the encoder so that
userspace doesn't have to deal with dri
From: Ville Syrjälä
It's not at all clear what cloning options this driver supports.
So let's just clear possible_clones instead of setting it to some
bogus value.
v2: Adjust the FIXME (Daniel)
Cc: Philipp Zabel
Acked-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/imx/im
From: Ville Syrjälä
I doubt the DP+DP and SDVO+SDVO cloning works for this driver.
i915 at least doesn't do those. Truthfully there could be some very
specific circumstances where some of them would do doable, but
genereally it's too much pain to deal with so we've chose not to
bother. Let's use
From: Ville Syrjälä
Replace the hand rolled encoder bitmask thing with drm_encoder_mask()
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Acked-by: Thomas Zimmermann
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
1 file changed, 2 i
From: Ville Syrjälä
The docs say possible_clones should always include the encoder itself.
Since most drivers don't want to deal with the complexities of cloning
let's allow them to set possible_clones=0 and instead we'll fix that
up in the core.
We can't put this special case into drm_encoder_i
From: Ville Syrjälä
WARN if the encoder possible_crtcs is effectively empty or contains
bits for non-existing crtcs.
v2: Move to drm_mode_config_validate() (Daniel)
Make the docs say we WARN when this is wrong (Daniel)
Extract full_crtc_mask()
Cc: Thomas Zimmermann
Cc: Daniel Vetter
S
On Tue, Feb 11, 2020 at 09:39:37PM +0530, Anshuman Gupta wrote:
> On 2020-02-07 at 18:15:31 +0200, Ville Syrjälä wrote:
> > On Fri, Feb 07, 2020 at 07:50:36PM +0530, Anshuman Gupta wrote:
> > > Updated version after rebase and fixing few comments.
> > >
> > > Anshuman Gupta (6):
> > > drm/i915:
Move vga switcheroo and dsm handler register later in
i915_driver_register(), and unregister in i915_driver_unregister(). The
dsm handler unregister is a nop, and is only added for completeness.
My unsubstantiated suspicion is that the vga switcheroo state change
would not work as early as we regi
Prefer i915 over dev_priv where possible. No functional changes.
Cc: Ville Syrjälä
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 54 -
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i9
On Tue, Feb 11, 2020 at 06:14:50PM +0200, Jani Nikula wrote:
> The DMC firmware is about display. Move the handling under display. No
> functional changes.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Acked-by: Ville Syrjälä
I'm also thinking s/csr/dmc/ migth be a good idea. I don't eve
Quoting Ville Syrjälä (2020-02-11 16:29:03)
> On Tue, Feb 11, 2020 at 06:14:50PM +0200, Jani Nikula wrote:
> > The DMC firmware is about display. Move the handling under display. No
> > functional changes.
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Jani Nikula
>
> Acked-by: Ville Syrjälä
>
On 2020-02-11 at 15:00:01 +0530, Ramalingam C wrote:
> As per the HDCP2.2 compliance test 1B-10 expectation, when stream
> management for a repeater fails, we retry thrice and when it fails
> in all retries, HDCP2.2 reauthentication aborted at kernel.
>
> v2:
> seq_num_m++ is extended for steam
On Tue, 11 Feb 2020, Ville Syrjälä wrote:
> On Tue, Feb 11, 2020 at 06:14:50PM +0200, Jani Nikula wrote:
>> The DMC firmware is about display. Move the handling under display. No
>> functional changes.
>>
>> Cc: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>
> Acked-by: Ville Syrjälä
>
> I'm al
Quoting Janusz Krzysztofik (2020-02-11 14:30:48)
> @@ -2009,8 +2016,31 @@ igt_main_args("c:", NULL, help_str, opt_handler, NULL)
> igt_subtest("invalid-null-pointer")
> test_invalid_null_pointer(fd);
>
> - igt_subtest("invalid-gtt-mapping")
>
On Tue, Feb 11, 2020 at 06:22:02PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The docs say possible_clones should always include the encoder itself.
> Since most drivers don't want to deal with the complexities of cloning
> let's allow them to set possible_clones=0 and instead we'll fi
On Tue, Feb 11, 2020 at 06:22:06PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Many drivers are populating encoder->possible_clones wrong. Let's
> persuade them to get it right by adding some loud WARNs.
>
> We'll cross check the bits between any two encoders. So either
> both encoders
On Tue, Feb 11, 2020 at 06:22:07PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> WARN if the encoder possible_crtcs is effectively empty or contains
> bits for non-existing crtcs.
>
> v2: Move to drm_mode_config_validate() (Daniel)
> Make the docs say we WARN when this is wrong (Dani
On Tue, Feb 11, 2020 at 06:22:08PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's simplify life of driver by allowing them to leave
> encoder->possible_crtcs unset if they have no restrictions
> in crtc<->encoder linkage. We'll just populate possible_crtcs
> with the full crtc mask w
On 2020-02-11 at 18:26:13 +0200, Ville Syrjälä wrote:
> On Tue, Feb 11, 2020 at 09:39:37PM +0530, Anshuman Gupta wrote:
> > On 2020-02-07 at 18:15:31 +0200, Ville Syrjälä wrote:
> > > On Fri, Feb 07, 2020 at 07:50:36PM +0530, Anshuman Gupta wrote:
> > > > Updated version after rebase and fixing few
On Tue, Feb 11, 2020 at 06:02:33PM +0100, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 06:22:06PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Many drivers are populating encoder->possible_clones wrong. Let's
> > persuade them to get it right by adding some loud WARNs.
> >
> > W
On Tue, Feb 11, 2020 at 06:05:45PM +0100, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 06:22:08PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Let's simplify life of driver by allowing them to leave
> > encoder->possible_crtcs unset if they have no restrictions
> > in crtc<->enco
Updated version after fixing some review comment provided by
ville on v2 version, which unfortunately didn't reach to mailing
list due to typo in "to address".
Anshuman Gupta (7):
drm/i915: Iterate over pipe and skip the disabled one
drm/i915: Remove (pipe == crtc->index) assumption
drm/i915
Chris Wilson writes:
> Currently on execlists, we use a local hwsp for the kernel_context,
> rather than the engine's HWSP, as this is the default for execlists.
> However, seqno rollover requires allocating a new HWSP cachline, and may
s/cachline/cacheline
> require pinning a new HWSP page in
Add a WARN_ON for a disabled pipe in pipe_mask at
intel_get_crtc_for_pipe() function.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display_types.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/dis
intel_plane_fb_max_stride should return the max stride of
primary plane for first available pipe in intel device info
pipe_mask.
Similarly glk_force_audio_cdclk() should also use the first
available CRTC instead of pipe 'A' crtc to force the cdclk
changes.
changes since RFC:
- Introduced a helper
we can't have (pipe == crtc->index) assumption in
driver in order to support 3 non-contiguous
display pipe system.
FIXME: Remove the WARN_ON(drm_crtc_index(&crtc->base) != crtc->pipe)
when we will fix all such assumption.
changes since RFC:
- Added again removed (pipe == crtc->index) WARN_ON.
- P
skl_ddb_allocation_overlaps() num_entries hass been passed as
INTEL_NUM_PIPES, it should be I915_MAX_PIPES.
Cc: Ville Syrjälä
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm
It should not be assumed that a disabled display pipe will be
always last the pipe.
for_each_pipe() should iterate over I915_MAX_PIPES and check
for the disabled pipe and skip that pipe so that it should not
initialize the intel crtc for any disabled pipes.
Below compilation error require to be ha
As a disabled pipe in pipe_mask is not having a valid intel crtc,
driver wrongly populates the possible_crtcs mask while initializing
the plane for a CRTC. Fixing up the plane possible_crtcs mask.
changes since RFC:
- Simplify the possible_crtcs initialization. [Ville]
v2:
- Removed the unnecessa
Skip the transcoder whose pipe is disabled while
initializing transcoder error state in 3 non-contiguous
display pipe system.
v2:
- Don't skip EDP_TRANSCODER error state. [Ville]
- Use a helper has_transcoder(). [Ville]
Cc: Ville Syrjälä
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/d
Chris Wilson writes:
> Apply vast quantities of poison and not tell anyone to see if we fall
> for the trap of using a stale RING_HEAD.
>
> References: 42827350f75c ("drm/i915/gt: Avoid resetting ring->head outside of
> its timeline mutex")
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
> Cc:
On 2/4/20 4:43 PM, Ye, Tony wrote:
On 1/27/2020 1:41 AM, Michal Wajdeczko wrote:
On Thu, 23 Jan 2020 16:51:58 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2020-01-23 15:38:52)
On Thu, 23 Jan 2020 16:02:17 +0100, Chris Wilson
wrote:
> Quoting Daniele Ceraolo Spurio (2020-01-22
On Tue, 11 Feb 2020, Jani Nikula wrote:
drm->dev_private is to be avoided. Use to_i915() on the struct
drm_device pointer instead. Rename the affected local dev_priv variables
to i915 while at it.
Applies cleanly, and compiles.
Changes also look good to me.
Reviewed by: Wambui Karuga
C
On Tue, 11 Feb 2020, Jani Nikula wrote:
On Thu, 06 Feb 2020, Wambui Karuga wrote:
@@ -1364,11 +1372,15 @@ int intel_hdmi_hdcp_write_an_aksv(struct
intel_digital_port *intel_dig_port,
static int intel_hdmi_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
On Tue, 2020-02-11 at 18:12 +0200, Jani Nikula wrote:
> On Mon, 10 Feb 2020, Jani Nikula wrote:
> > On Mon, 10 Feb 2020, José Roberto de Souza
> > wrote:
> > > Commit 1c9d2eb24153 ("drm/i915: move intel_dp_set_m_n() to
> > > encoder for
> > > DDI platforms") moved the intel_dp_set_m_n() from
> >
From: "Yokoyama, Caz"
MAD_INTER_CHANNEL_0_0_0_MCHBAR:
code nameoffset DRAM_DDR_TYPE
SKL 0x5000 1:0 DDR4/DDR3/LPDDR3
TGL 0x6048/0x6248/0xd800 2:0 DDR4/DDR3/LPDDR3/LPDDR4
ICL 0x5000/0x6048/0x48
Unfortunately, it turned out that the DPCD is also not a reliable way of
probing for DPCD backlight support as some panels will lie and say they
have DPCD backlight controls when they don't actually.
So, revert back to the old behavior and add a bunch of EDID-based DP
quirks for the panels that we
The whole point of using OUIs is so that we can recognize certain
devices and potentially apply quirks for them. Normally this should work
quite well, but there appears to be quite a number of laptop panels out
there that will fill the OUI but not the device ID. As such, for devices
like this I can
The X1 Extreme is one of the systems that lies about which backlight
interface that it uses in its VBIOS as PWM backlight controls don't work
at all on this machine. It's possible that this panel could be one of
the infamous ones that can switch between PWM mode and DPCD backlight
control mode, but
According to Dell, trying to match their panels via OUI is not reliable
enough and we've been told that we should check against the EDID
instead. As well, Dell seems to have some panels that are actually
intended to switch between using PWM for backlight controls and DPCD for
backlight controls dep
On Tue, Feb 11, 2020 at 08:10:27PM +0200, Andi Shyti wrote:
> From: Andi Shyti
>
> The GT has its own properties and in sysfs they should be grouped
> in the 'gt/' directory.
>
> Create the 'gt/' directory in sysfs and move the power management
> related files.
>
> Signed-off-by: Andi Shyti
>
The hotplug interruption detection was not being enabled for TC5 and
TC6 in the north detection side.
Cc: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_irq.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/d
Commit 1c9d2eb24153 ("drm/i915: move intel_dp_set_m_n() to encoder for
DDI platforms") moved the intel_dp_set_m_n() from hsw_crtc_enable()
to intel_ddi_pre_enable_dp() but it missed add it to
intel_mst_pre_enable_dp() causing MST slaves to not work.
v2: Not setting intel_ddi_set_dp_msa() twice for
1 - 100 of 137 matches
Mail list logo
