Hi all,
On Thu, 8 Oct 2020 14:09:03 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
In file included from include/linux/clk.h:13,
from drivers/gpu/drm/ingenic/ingenic-drm-drv.c:10:
drivers/gpu
On Wed, Sep 30, 2020 at 09:50:07AM -0700, Matt Roper wrote:
On Tue, Sep 29, 2020 at 11:42:32PM -0700, Lucas De Marchi wrote:
From: Anshuman Gupta
DC6 is not supported on DG1, so change the allowed DC mask for DG1.
Cc: Uma Shankar
Signed-off-by: Anshuman Gupta
Do we have a bspec reference
On Wed, Oct 07, 2020 at 05:33:48PM -0700, Souza, Jose wrote:
> On Wed, 2020-10-07 at 15:45 -0700, Matt Roper wrote:
> > On Tue, Sep 29, 2020 at 03:34:17PM -0700, José Roberto de Souza wrote:
> > > Child min_brightness is obsolete from VBT 234+, instead the new
> > > min_brightness field in the main
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
I noticed that the ingenic driver revert I had been waiting for appeared
in hte drm-misc tree, so I removed the BROKEN dependency for it, but it
produced the above errors, so I have marked it
Hi Lyude,
> On Oct 8, 2020, at 05:53, Lyude Paul wrote:
>
> Hi! I thought this patch rang a bell, we actually already had some discussion
> about this since there's a couple of other systems this was causing issues
> for.
> Unfortunately it never seems like that patch got sent out. Satadru?
>
On Wed, 2020-10-07 at 15:45 -0700, Matt Roper wrote:
> On Tue, Sep 29, 2020 at 03:34:17PM -0700, José Roberto de Souza wrote:
> > Child min_brightness is obsolete from VBT 234+, instead the new
> > min_brightness field in the main structure should be used.
> >
> > This new field is 16 bits wide, s
On Tue, Oct 06, 2020 at 05:33:39PM +0300, Ville Syrjälä wrote:
From: Ville Syrjälä
Use hpd_pin instead of port in the parametrized ICP+ DDI HPD
macros. Makes it clear what these refer to.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 12 ++--
drivers/gpu/drm/i915/i
On Tue, Oct 06, 2020 at 07:25:43PM +0300, Ville Syrjälä wrote:
From: Ville Syrjälä
Unify the BDW/BXT hotplug bits. BDW only has port A, but that
matches BXT port A so we can shar the same macro for both.
v2: Remember the gvt
Signed-off-by: Ville Syrjälä
Reviewed-by: Lucas De Marchi
Luca
On Tue, Oct 06, 2020 at 07:25:22PM +0300, Ville Syrjälä wrote:
From: Ville Syrjälä
Use hpd_pin to parametrize BXT_DE_PORT_HP_DDI() to make it clear
these have nothing to do with DDI ports or PHYs as such. The only
thing that matters is the HPD pin assignment.
v2: Remember the gvt
Signed-off-b
On Tue, Oct 06, 2020 at 05:33:36PM +0300, Ville Syrjälä wrote:
From: Ville Syrjälä
As with the VBT DVO port, RKL uses PHY based mapping for the
VBT AUX CH. Adjust the code to use the new AUX_USBCn names
and add a comment to explain the situation.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/d
On Tue, Oct 06, 2020 at 05:33:35PM +0300, Ville Syrjälä wrote:
From: Ville Syrjälä
Let's make the AUX CH names match the spec (AUX A-F for pre-tgl,
AUX A-C or AUX USBC1-6 for tgl+). And while at it let's include
the full encoder name in the AUX CH name as well (as opposed to
just using port_nam
On Tue, Sep 29, 2020 at 03:34:19PM -0700, José Roberto de Souza wrote:
> This will be used in future but already adding to VBT so we are
> updated with VBT changes.
>
> Signed-off-by: José Roberto de Souza
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 1 +
>
On Tue, Oct 06, 2020 at 05:33:34PM +0300, Ville Syrjälä wrote:
From: Ville Syrjälä
Just like with the DDIs tgl+ renamed the AUX CHs to reflect
the type of the DDI. Let's add the aliasing enum values for
the type-C AUX CHs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_di
On Tue, Sep 29, 2020 at 03:34:18PM -0700, José Roberto de Souza wrote:
> This will remove the "Expected child device config size for VBT
> version 235 not known" debug message seen in TGL, although this is not
> fixing anything it good to keep our VBT parser updated.
>
> Signed-off-by: José Robert
On Tue, Sep 29, 2020 at 03:34:17PM -0700, José Roberto de Souza wrote:
> Child min_brightness is obsolete from VBT 234+, instead the new
> min_brightness field in the main structure should be used.
>
> This new field is 16 bits wide, so backlight_precision_bits is needed
> to check if value needs
On Tue, Oct 06, 2020 at 05:33:33PM +0300, Ville Syrjälä wrote:
From: Ville Syrjälä
Let's pimp the DDI encoder->name to reflect what the spec calls them.
Ie. on pre-tgl DDI A-F, on tgl+ DDI A-C or DDI TC1-6.
Also since each encoder is really a combination of the DDI and the PHY
we include the P
On Tue, Oct 06, 2020 at 05:33:32PM +0300, Ville Syrjälä wrote:
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 8c93253cbd95..a39be3c9e0cf 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/in
On Tue, Oct 06, 2020 at 05:33:31PM +0300, Ville Syrjälä wrote:
From: Ville Syrjälä
Make the namespacing for enum tc_port better by adding
the TC_ to the actual enum values.
I like having the constants with the same name as the enum but with
capital letters, but then we have TC_PORT_TC which d
On Wed, 2020-10-07 at 22:22 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently we call .hpd_irq_setup() directly just before display
> resume, and follow it with another call via intel_hpd_init()
> just afterwards. Assuming the hpd pins are marked as enabled
> during the open-coded c
On Tue, Oct 06, 2020 at 05:33:30PM +0300, Ville Syrjälä wrote:
From: Ville Syrjälä
Move the DSC stuff out from the middle of the ICP HPD register
definitions. The location seems to have been selected by a
dice roll.
SHPD_FILTER_CNT addition also went astray due to the DSC
mess, so we also fix
Hi! I thought this patch rang a bell, we actually already had some discussion
about this since there's a couple of other systems this was causing issues for.
Unfortunately it never seems like that patch got sent out. Satadru?
(if I don't hear back from them soon, I'll just send out a patch for thi
Due to the debugfs flag, has_psr2 in CRTC state could have a different
value than psr.psr2_enabled and it was causing PSR2 subfeatures(DC3CO
and selective fetch) to be set to not a expected state.
So here only taking in consideration the parameter and debugfs flag
when computing PSR state, this wa
For platforms without selective fetch this register is reserved so
do not write 0 to it.
Cc: Gwan-gyeong Mun
Cc: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
Another step towards PSR2 selective fetch, here programming plane
selective fetch registers and MAN_TRK_CTL enabling selective fetch but
for now it is fetching the whole area of the planes.
The damaged area calculation will come as next and final step.
v2:
- removed warn on when no plane is visibl
From: Ville Syrjälä
Currently we call .hpd_irq_setup() directly just before display
resume, and follow it with another call via intel_hpd_init()
just afterwards. Assuming the hpd pins are marked as enabled
during the open-coded call these two things do exactly the
same thing (ie. enable HPD inter
== Series Details ==
Series: drm/i915: Exclude low pages (128KiB) of stolen from use
URL : https://patchwork.freedesktop.org/series/82443/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9109_full -> Patchwork_18648_full
Summ
The DP Standard's recommendation is to use the LTTPR non-transparent
mode link training if LTTPRs are detected, so let's do this.
Besides power-saving, the advantages of this are that the maximum number
of LTTPRs can only be used in non-transparent mode (the limit is 5-8 in
transparent mode), and
Split the prepare, link training, fallback-handling steps into their own
functions for clarity and as a preparation for the upcoming LTTPR
changes.
While at it also:
- Unexport and inline intel_dp_set_idle_link_train(), which is used at a
single place.
- Add some documentation to functions that
Add the helpers and register definitions needed to read out the common
and per-PHY LTTPR capabilities and perform link training in the LTTPR
non-transparent mode.
v2:
- Add drm_dp_dpcd_read_phy_link_status() and DP_PHY_LTTPR() here instead
of adding these to i915. (Ville)
v3:
- Use memmove() to
By default LTTPRs should be in transparent link training mode,
nevertheless in this patch we switch to this default mode explicitly.
The DP Standard recommends this, supposedly because an LTTPR may be left
in the non-transparent mode (by BIOS, previous kernel, or after reset
due to a firmware bug)
This patchset is v3 of [1], rebased on drm-tip, fixing an eDP related
check in patch 5 and addressing a review comment from Ville in patch 6.
[1] https://patchwork.freedesktop.org/series/81968/
Cc: Ville Syrjälä
Imre Deak (6):
drm/i915: Fix DP link training pattern mask
drm/i915: Simplify t
An LTTPR can be trained with training pattern 4 even if the DPCD
revision is < 1.4, but drm_dp_training_pattern_mask() would change
pattern 4 to pattern 3 on those DPCD revisions.
Since intel_dp_training_pattern() makes already sure that the proper
training pattern is used, all that needs to be ma
To prepare for a follow-up LTTPR change factor out a helper to disable
the training pattern in DPCD. We'll need to do this for each LTTPR
(without programming the port to output the idle pattern) when training
in LTTPR non-transparent mode.
While at it also move the disable-link-training logic fro
On Wed, Oct 07, 2020 at 12:54:28AM +, Patchwork wrote:
== Series Details ==
Series: series starting with [CI,1/8] drm/i915/dg1: add more PCI ids
URL : https://patchwork.freedesktop.org/series/82422/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
F
== Series Details ==
Series: drm/i915: Exclude low pages (128KiB) of stolen from use
URL : https://patchwork.freedesktop.org/series/82443/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9109 -> Patchwork_18648
Summary
--
Quoting Chris Wilson (2020-10-07 16:17:18)
> The GPU is trashing the low pages of its reserved memory upon reset. If
> we are using this memory for ringbuffers, then we will dutiful resubmit
> the trashed rings after the reset causing further resets, and worse. We
> must exclude this range from our
The GPU is trashing the low pages of its reserved memory upon reset. If
we are using this memory for ringbuffers, then we will dutiful resubmit
the trashed rings after the reset causing further resets, and worse. We
must exclude this range from our own use. The value of 128KiB was found
by empirica
== Series Details ==
Series: drm/i915/jsl: Split EHL/JSL platform info and PCI ids
URL : https://patchwork.freedesktop.org/series/82437/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9107_full -> Patchwork_18645_full
Summar
== Series Details ==
Series: drm/fb-helper: Add locking to sysrq handling
URL : https://patchwork.freedesktop.org/series/82441/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9109 -> Patchwork_18647
Summary
---
**SUCC
== Series Details ==
Series: drm/i915/gt: Ignore dt==0 for reporting underflows
URL : https://patchwork.freedesktop.org/series/82433/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9107_full -> Patchwork_18643_full
Summary
-
== Series Details ==
Series: drm/fb-helper: Add locking to sysrq handling
URL : https://patchwork.freedesktop.org/series/82441/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
da54a4f1af82 drm/fb-helper: Add locking to sysrq handling
-:69: WARNING:NO_AUTHOR_SIGN_OFF: Missing Sign
== Series Details ==
Series: series starting with [1/3] drm/i915: Mark ininitial fb obj as WT on
eLLC machines to avoid rcu lockup during fbdev init
URL : https://patchwork.freedesktop.org/series/82438/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9109 -> Patchwork_18646
===
We didn't take the kernel_fb_helper_lock mutex, which protects that
code. While at it, simplify the code
- inline the function (originally shared with kgdb I think)
- drop the error tracking and all the complications
- drop the pointless early out, it served nothing
Signed-off-by: Daniel Vetter
C
On Thu, 2020-10-01 at 10:14 -0700, Souza, Jose wrote:
> On Thu, 2020-10-01 at 12:24 +0100, Mun, Gwan-gyeong wrote:
> > On Thu, 2020-09-24 at 10:42 -0700, José Roberto de Souza wrote:
> > > Another step towards PSR2 selective fetch, here programming plane
> > > selective fetch registers and MAN_TRK_
== Series Details ==
Series: drm/i915/jsl: Split EHL/JSL platform info and PCI ids
URL : https://patchwork.freedesktop.org/series/82437/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9107 -> Patchwork_18645
Summary
---
From: Ville Syrjälä
Fix up the MOCS PTE setting to really get the LLC cacheability
from the PTE rather than hardocoding it to LLC or LLC+eLLC.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/g
From: Ville Syrjälä
Since SKL the eLLC has been sitting on the far side of the system
agent, meaning the display engine can utilize it. Let's enable that.
I chose WB for the caching mode, because my numbers are indicating
that WT might actually be WB and WC might actually be UC. I'm not
100% sur
From: Ville Syrjälä
Currently we leave the cache_level of the initial fb obj
set to NONE. This means on eLLC machines the first pin_to_display()
will try to switch it to WT which requires a vma unbind+bind.
If that happens during the fbdev initialization rcu does not
seem operational which causes
== Series Details ==
Series: drm/i915/jsl: Split EHL/JSL platform info and PCI ids
URL : https://patchwork.freedesktop.org/series/82437/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
210bd6977cda drm/i915/jsl: Split EHL/JSL platform info and PCI ids
-:214: CHECK:UNNECESSARY_PAR
== Series Details ==
Series: drm/i915/gem: Perform all asynchronous waits prior to marking payload
start
URL : https://patchwork.freedesktop.org/series/82434/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9107 -> Patchwork_18644
===
== Series Details ==
Series: drm/i915/gt: Ignore dt==0 for reporting underflows
URL : https://patchwork.freedesktop.org/series/82433/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9107 -> Patchwork_18643
Summary
---
On Tue, Oct 06, 2020 at 09:58:07PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently we call .hpd_irq_setup() directly just before display
> resume, and follow it with another call via intel_hpd_init()
> just afterwards. Assuming the hpd pins are marked as enabled
> during the open-
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-10-07 10:40:59)
>> Chris Wilson writes:
>>
>> > The initial breadcrumb marks the transition from context wait and setup
>> > into the request payload. We use the marker to determine if the request
>> > is merely waiting to begin, or is inside t
On 07/10/2020 10:36, Tejas Upadhyay wrote:
Recently we came across requirement to identify EHL and JSL
platform to program them differently. Thus Split the basic
platform definition, macros, and PCI IDs to differentiate
between EHL and JSL platforms. Also, IS_ELKHARTLAKE is replaced
with IS_JSL_
Quoting Mika Kuoppala (2020-10-07 10:40:59)
> Chris Wilson writes:
>
> > The initial breadcrumb marks the transition from context wait and setup
> > into the request payload. We use the marker to determine if the request
> > is merely waiting to begin, or is inside the payload and hung.
> > Forge
Recently we came across requirement to identify EHL and JSL
platform to program them differently. Thus Split the basic
platform definition, macros, and PCI IDs to differentiate
between EHL and JSL platforms. Also, IS_ELKHARTLAKE is replaced
with IS_JSL_EHL everywhere.
Cc : Matt Roper
Cc : Ville S
Chris Wilson writes:
> The initial breadcrumb marks the transition from context wait and setup
> into the request payload. We use the marker to determine if the request
> is merely waiting to begin, or is inside the payload and hung.
> Forgetting to include a breadcrumb before the user payload wo
Chris Wilson writes:
> We may try to preempt the currently executing request, only to find that
> after unravelling all the dependencies that the original executing
> context is still the earliest in the topological sort and re-submitted
> back to HW (if we do detect some change in the ELSP that
The initial breadcrumb marks the transition from context wait and setup
into the request payload. We use the marker to determine if the request
is merely waiting to begin, or is inside the payload and hung.
Forgetting to include a breadcrumb before the user payload would mean we
do not reset the gu
The presumption was that some time would always elapse between recording
the start and the finish of a context switch. This turns out to be a
regular occurrence and emitting a debug statement superfluous.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 4
Chris Wilson writes:
> Since we track the idle_pulse for flushing the barriers and avoid
> re-emitting the pulse upon idling if no futher action is required, this
> also impacts the heartbeat. Before emitting a fresh heartbeat, we look
> at the engine idle status and assume that if the pulse was
On Wed, Oct 7, 2020 at 9:22 AM Jason Gunthorpe wrote:
> On Tue, Oct 06, 2020 at 12:41:22PM +0200, Daniel Vetter wrote:
> > On Mon, Oct 05, 2020 at 08:56:50PM -0300, Jason Gunthorpe wrote:
> > > On Sun, Oct 04, 2020 at 06:43:36PM +0300, Leon Romanovsky wrote:
> > > > This series extends __sg_alloc_
HP DreamColor panel needs to be controlled via AUX interface. However,
it has both DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP set, so it fails to pass
intel_dp_aux_display_control_capable() test.
Skip the test if the panel has force DPCD quirk.
Signed-off-
63 matches
Mail list logo
