Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree
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/drm/ingenic/ingenic-drm-drv.c: In function
'ingenic_drm_update_palette':
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct ingenic_drm'
has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~~
include/linux/kernel.h:47:33: note: in definition of macro 'ARRAY_SIZE'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
| ^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct ingenic_drm'
has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~~
include/linux/kernel.h:47:48: note: in definition of macro 'ARRAY_SIZE'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|^~~
In file included from include/linux/bits.h:22,
from include/linux/bitops.h:5,
from drivers/gpu/drm/ingenic/ingenic-drm.h:10,
from drivers/gpu/drm/ingenic/ingenic-drm-drv.c:7:
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct ingenic_drm'
has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~~
include/linux/build_bug.h:16:62: note: in definition of macro
'BUILD_BUG_ON_ZERO'
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
| ^
include/linux/compiler.h:224:46: note: in expansion of macro '__same_type'
224 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
| ^~~
include/linux/kernel.h:47:59: note: in expansion of macro '__must_be_array'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|
^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in expansion of macro
'ARRAY_SIZE'
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct ingenic_drm'
has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~~
include/linux/build_bug.h:16:62: note: in definition of macro
'BUILD_BUG_ON_ZERO'
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
| ^
include/linux/compiler.h:224:46: note: in expansion of macro '__same_type'
224 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
| ^~~
include/linux/kernel.h:47:59: note: in expansion of macro '__must_be_array'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|
^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in expansion of macro
'ARRAY_SIZE'
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~
include/linux/build_bug.h:16:51: error: bit-field '' width not an
integer constant
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
| ^
include/linux/compiler.h:224:28: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
224 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
|^
include/linux/kernel.h:47:59: note: in expansion of macro '__must_be_array'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|
^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in expansion of macro
'ARRAY_SIZE'
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
| ^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:453:9: error: 'struct ingenic_drm'
has no member named 'dma_hwdescs'; did you mean 'dma_hwdesc_f0'?
453 | priv->dma_hwdescs->palette[i] = color;
|
Re: [Intel-gfx] [PATCH v6 22/24] drm/i915/dg1: DG1 does not support DC6
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 for this? I can't find anything specific
about this from a casual skim of the pages I'd expect it to be mentioned
on.
If we have a reference added (or a note clarifying that we have offline
confirmation from hardware architects),
Reviewed-by: Matt Roper
I received confirmation from HW people that DG1 doesn't support DC6 and
spec is going to be updated.
Lucas De Marchi
At some point I think we should re-write this section of the code in
general. The magic numbers used here are annoying, and a driver
modparam named 'enable_dc' really sounds like it should be a bitmask of
the exact DCs supported (rather than defining a combination of 'up to'
values + DC3CO and omitting DC9 completely). But we don't need to do
that in a DG1 enabling patch.
Matt
---
drivers/gpu/drm/i915/display/intel_display_power.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 0827e68a9d89..7dfc697ccf78 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -4689,7 +4689,10 @@ static u32 get_allowed_dc_mask(const struct
drm_i915_private *dev_priv,
int max_dc;
if (INTEL_GEN(dev_priv) >= 12) {
- max_dc = 4;
+ if (IS_DG1(dev_priv))
+ max_dc = 3;
+ else
+ max_dc = 4;
/*
* DC9 has a separate HW flow from the rest of the DC states,
* not depending on the DMC firmware. It's needed by system
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/vbt: Fix backlight parsing for VBT 234+
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 structure should be used.
> > >
> > > This new field is 16 bits wide, so backlight_precision_bits is needed
> > > to check if value needs to be scaled down but it is only available in
> > > VBT 236+ so working around it by using the also new backlight_level
> > > in the main struct.
> > >
> > > v2:
> > > - missed that backlight_data->level is also obsolete
> > >
> > > BSpec: 20149
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/display/intel_bios.c | 30 +--
> > > drivers/gpu/drm/i915/display/intel_vbt_defs.h | 12 ++--
> > > 2 files changed, 38 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > > b/drivers/gpu/drm/i915/display/intel_bios.c
> > > index 4716484af62d..58e5657a77bb 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > > @@ -425,6 +425,7 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
> > > const struct bdb_lfp_backlight_data *backlight_data;
> > > const struct lfp_backlight_data_entry *entry;
> > > int panel_type = dev_priv->vbt.panel_type;
> > > + u16 level;
> > >
> > >
> > >
> > >
> > > backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);
> > > if (!backlight_data)
> > > @@ -459,14 +460,39 @@ parse_lfp_backlight(struct drm_i915_private
> > > *dev_priv,
> > >
> > >
> > >
> > >
> > > dev_priv->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
> > > dev_priv->vbt.backlight.active_low_pwm = entry->active_low_pwm;
> > > - dev_priv->vbt.backlight.min_brightness = entry->min_brightness;
> > > +
> > > + if (bdb->version >= 234) {
> > > + bool scale = false;
> > > + u16 min_level;
> > > +
> > > + level = backlight_data->backlight_level[panel_type].level;
> > > + min_level =
> > > backlight_data->backlight_min_level[panel_type].level;
> > > +
> > > + if (bdb->version >= 236)
> > > + scale =
> > > backlight_data->backlight_precision_bits[panel_type] == 16;
> > > + else
> > > + scale = level > 255;
> >
> > I'm not sure I follow the 'else' arm here. On version 234/235 we'd have
> > 16-bit level values. In the absence of any other precision information
> > wouldn't we assume that all the bits are used and that we have a full
> > 16-bit precision? If the level is < 256 (or for that matter if we have
> > any value where level & 0xFF is non-zero) wouldn't that definitely mean
> > that there are 16-bits of precision since otherwise those low bits would
> > have to be 0's?
>
> My understand is that in version 234 or 235 all brightness levels could be
> set as 16bits or 8bits wide by vendors and it did not had a clear way for
> driver to know what it is, then version 236 came fixing it.
>
> So working around it by using the regular brightness level(supposed the one
> that vendor wants the panel to have by default) and we can suppose that it
> will be higher than the minimum so for 16bits of precision it will be higher
> than 255.
> Anyways I doubt that any production product will have VBT version 234 or 235.
Okay. I guess since it was described with the term "precision" in the
spec that made me think of it as "only the highest 8 bits in use" rather
than an actual 8-bit range (i.e., just lower bits), but I guess there
wouldn't really be a need to specify it if that were the case. So I
think your logic here is probably correct.
With the s/backlight/brightness/ rename and the u32 -> u16
simplification suggested by Jani,
Reviewed-by: Matt Roper
>
> >
> > > +
> > > + if (scale)
> > > + min_level = min_level / 255;
> > > +
> > > + if (min_level > 255) {
> > > + drm_warn(_priv->drm, "Backlight min level > 255\n");
> > > + level = 255;
> > > + }
> > > + dev_priv->vbt.backlight.min_brightness = min_level;
> > > + } else {
> > > + level = backlight_data->level[panel_type];
> > > + dev_priv->vbt.backlight.min_brightness = entry->min_brightness;
> > > + }
> > > +
> > > drm_dbg_kms(_priv->drm,
> > > "VBT backlight PWM modulation frequency %u Hz, "
> > > "active %s, min brightness %u, level %u, controller %u\n",
> > > dev_priv->vbt.backlight.pwm_freq_hz,
> > > dev_priv->vbt.backlight.active_low_pwm ? "low" : "high",
> > > dev_priv->vbt.backlight.min_brightness,
> > > - backlight_data->level[panel_type],
> > > + level,
> > > dev_priv->vbt.backlight.controller);
> > > }
> > >
> > >
> > >
> > >
> > >
> > >
> > >
[Intel-gfx] linux-next: build failure after merge of the drm-misc tree
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 BROKEN again. -- Cheers, Stephen Rothwell pgpzU0SuNYvli.pgp Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/dpcd_bl: Skip testing control capability with force DPCD quirk
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?
>
> (if I don't hear back from them soon, I'll just send out a patch for this
> myself)
>
> JFYI - the proper fix here is to just drop the
> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP check from the code entirely. As long
> as
> the backlight supports AUX_SET_CAP, that should be enough for us to control
> it.
Does the proper fix include dropping DP_QUIRK_FORCE_DPCD_BACKLIGHT entirely?
Kai-Heng
>
>
> On Wed, 2020-10-07 at 14:58 +0800, Kai-Heng Feng wrote:
>> 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-by: Kai-Heng Feng
>> ---
>> drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 10 ++
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> index acbd7eb66cbe..acf2e1c65290 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> @@ -347,9 +347,13 @@ int intel_dp_aux_init_backlight_funcs(struct
>> intel_connector *intel_connector)
>> struct intel_panel *panel = _connector->panel;
>> struct intel_dp *intel_dp = enc_to_intel_dp(intel_connector->encoder);
>> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>> +bool force_dpcd;
>> +
>> +force_dpcd = drm_dp_has_quirk(_dp->desc, intel_dp->edid_quirks,
>> + DP_QUIRK_FORCE_DPCD_BACKLIGHT);
>>
>> if (i915->params.enable_dpcd_backlight == 0 ||
>> -!intel_dp_aux_display_control_capable(intel_connector))
>> +(!force_dpcd &&
>> !intel_dp_aux_display_control_capable(intel_connector)))
>> return -ENODEV;
>>
>> /*
>> @@ -358,9 +362,7 @@ int intel_dp_aux_init_backlight_funcs(struct
>> intel_connector *intel_connector)
>> */
>> if (i915->vbt.backlight.type !=
>> INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
>> -i915->params.enable_dpcd_backlight != 1 &&
>> -!drm_dp_has_quirk(_dp->desc, intel_dp->edid_quirks,
>> - DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
>> +i915->params.enable_dpcd_backlight != 1 && !force_dpcd) {
>> drm_info(>drm,
>> "Panel advertises DPCD backlight support, but "
>> "VBT disagrees. If your backlight controls "
> --
> Sincerely,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/vbt: Fix backlight parsing for VBT 234+
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, so backlight_precision_bits is needed
> > to check if value needs to be scaled down but it is only available in
> > VBT 236+ so working around it by using the also new backlight_level
> > in the main struct.
> >
> > v2:
> > - missed that backlight_data->level is also obsolete
> >
> > BSpec: 20149
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_bios.c | 30 +--
> > drivers/gpu/drm/i915/display/intel_vbt_defs.h | 12 ++--
> > 2 files changed, 38 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index 4716484af62d..58e5657a77bb 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -425,6 +425,7 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
> > const struct bdb_lfp_backlight_data *backlight_data;
> > const struct lfp_backlight_data_entry *entry;
> > int panel_type = dev_priv->vbt.panel_type;
> > + u16 level;
> >
> >
> >
> >
> > backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);
> > if (!backlight_data)
> > @@ -459,14 +460,39 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
> >
> >
> >
> >
> > dev_priv->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
> > dev_priv->vbt.backlight.active_low_pwm = entry->active_low_pwm;
> > - dev_priv->vbt.backlight.min_brightness = entry->min_brightness;
> > +
> > + if (bdb->version >= 234) {
> > + bool scale = false;
> > + u16 min_level;
> > +
> > + level = backlight_data->backlight_level[panel_type].level;
> > + min_level =
> > backlight_data->backlight_min_level[panel_type].level;
> > +
> > + if (bdb->version >= 236)
> > + scale =
> > backlight_data->backlight_precision_bits[panel_type] == 16;
> > + else
> > + scale = level > 255;
>
> I'm not sure I follow the 'else' arm here. On version 234/235 we'd have
> 16-bit level values. In the absence of any other precision information
> wouldn't we assume that all the bits are used and that we have a full
> 16-bit precision? If the level is < 256 (or for that matter if we have
> any value where level & 0xFF is non-zero) wouldn't that definitely mean
> that there are 16-bits of precision since otherwise those low bits would
> have to be 0's?
My understand is that in version 234 or 235 all brightness levels could be set
as 16bits or 8bits wide by vendors and it did not had a clear way for
driver to know what it is, then version 236 came fixing it.
So working around it by using the regular brightness level(supposed the one
that vendor wants the panel to have by default) and we can suppose that it
will be higher than the minimum so for 16bits of precision it will be higher
than 255.
Anyways I doubt that any production product will have VBT version 234 or 235.
>
> > +
> > + if (scale)
> > + min_level = min_level / 255;
> > +
> > + if (min_level > 255) {
> > + drm_warn(_priv->drm, "Backlight min level > 255\n");
> > + level = 255;
> > + }
> > + dev_priv->vbt.backlight.min_brightness = min_level;
> > + } else {
> > + level = backlight_data->level[panel_type];
> > + dev_priv->vbt.backlight.min_brightness = entry->min_brightness;
> > + }
> > +
> > drm_dbg_kms(_priv->drm,
> > "VBT backlight PWM modulation frequency %u Hz, "
> > "active %s, min brightness %u, level %u, controller %u\n",
> > dev_priv->vbt.backlight.pwm_freq_hz,
> > dev_priv->vbt.backlight.active_low_pwm ? "low" : "high",
> > dev_priv->vbt.backlight.min_brightness,
> > - backlight_data->level[panel_type],
> > + level,
> > dev_priv->vbt.backlight.controller);
> > }
> >
> >
> >
> >
> >
> >
> >
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > index 54bcc6a6947c..b4742c4fde97 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > @@ -782,7 +782,7 @@ struct lfp_backlight_data_entry {
> > u8 active_low_pwm:1;
> > u8 obsolete1:5;
> > u16 pwm_freq_hz;
> > - u8 min_brightness;
> > + u8 min_brightness; /* Obsolete from 234+ */
> > u8 obsolete2;
> > u8 obsolete3;
> > } __packed;
> > @@ -792,11 +792,19 @@ struct lfp_backlight_control_method {
> > u8 controller:4;
> > } __packed;
Re: [Intel-gfx] [PATCH 10/20] drm/i915: s/port/hpd_pin/ for icp+ ddi hpd bits
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/i915_reg.h | 34 -
2 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6b824db1424a..b64f83f3d686 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -141,9 +141,9 @@ static const u32 hpd_gen11[HPD_NUM_PINS] = {
};
static const u32 hpd_icp[HPD_NUM_PINS] = {
- [HPD_PORT_A] = SDE_DDI_HOTPLUG_ICP(PORT_A),
- [HPD_PORT_B] = SDE_DDI_HOTPLUG_ICP(PORT_B),
- [HPD_PORT_C] = SDE_DDI_HOTPLUG_ICP(PORT_C),
+ [HPD_PORT_A] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_A),
+ [HPD_PORT_B] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_B),
+ [HPD_PORT_C] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_C),
[HPD_PORT_TC1] = SDE_TC_HOTPLUG_ICP(TC_PORT_TC1),
[HPD_PORT_TC2] = SDE_TC_HOTPLUG_ICP(TC_PORT_TC2),
[HPD_PORT_TC3] = SDE_TC_HOTPLUG_ICP(TC_PORT_TC3),
@@ -1069,11 +1069,11 @@ static bool icp_ddi_port_hotplug_long_detect(enum
hpd_pin pin, u32 val)
{
switch (pin) {
case HPD_PORT_A:
- return val & SHOTPLUG_CTL_DDI_HPD_LONG_DETECT(PORT_A);
+ return val & SHOTPLUG_CTL_DDI_HPD_LONG_DETECT(HPD_PORT_A);
case HPD_PORT_B:
- return val & SHOTPLUG_CTL_DDI_HPD_LONG_DETECT(PORT_B);
+ return val & SHOTPLUG_CTL_DDI_HPD_LONG_DETECT(HPD_PORT_B);
case HPD_PORT_C:
- return val & SHOTPLUG_CTL_DDI_HPD_LONG_DETECT(PORT_C);
+ return val & SHOTPLUG_CTL_DDI_HPD_LONG_DETECT(HPD_PORT_C);
default:
return false;
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 969266e59f56..206e8ab64bd4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8317,16 +8317,16 @@ enum {
/* south display engine interrupt: ICP/TGP */
#define SDE_GMBUS_ICP (1 << 23)
#define SDE_TC_HOTPLUG_ICP(tc_port) (1 << ((tc_port) + 24))
-#define SDE_DDI_HOTPLUG_ICP(port) (1 << ((port) + 16))
-#define SDE_DDI_MASK_ICP (SDE_DDI_HOTPLUG_ICP(PORT_B) | \
-SDE_DDI_HOTPLUG_ICP(PORT_A))
+#define SDE_DDI_HOTPLUG_ICP(hpd_pin) REG_BIT(16 + _HPD_PIN_DDI(hpd_pin))
+#define SDE_DDI_MASK_ICP (SDE_DDI_HOTPLUG_ICP(HPD_PORT_B) | \
+SDE_DDI_HOTPLUG_ICP(HPD_PORT_A))
#define SDE_TC_MASK_ICP (SDE_TC_HOTPLUG_ICP(TC_PORT_TC4) | \
SDE_TC_HOTPLUG_ICP(TC_PORT_TC3) | \
SDE_TC_HOTPLUG_ICP(TC_PORT_TC2) | \
SDE_TC_HOTPLUG_ICP(TC_PORT_TC1))
-#define SDE_DDI_MASK_TGP (SDE_DDI_HOTPLUG_ICP(PORT_C) | \
-SDE_DDI_HOTPLUG_ICP(PORT_B) | \
-SDE_DDI_HOTPLUG_ICP(PORT_A))
+#define SDE_DDI_MASK_TGP (SDE_DDI_HOTPLUG_ICP(HPD_PORT_C) | \
+SDE_DDI_HOTPLUG_ICP(HPD_PORT_B) | \
+SDE_DDI_HOTPLUG_ICP(HPD_PORT_A))
Reviewed-by: Lucas De Marchi
Lucas De Marchi
#define SDE_TC_MASK_TGP (SDE_TC_HOTPLUG_ICP(TC_PORT_TC6) | \
SDE_TC_HOTPLUG_ICP(TC_PORT_TC5) | \
SDE_TC_HOTPLUG_ICP(TC_PORT_TC4) | \
@@ -8400,12 +8400,12 @@ enum {
*/
#define SHOTPLUG_CTL_DDI_MMIO(0xc4030)
-#define SHOTPLUG_CTL_DDI_HPD_ENABLE(port)(0x8 << (4 * (port)))
-#define SHOTPLUG_CTL_DDI_HPD_STATUS_MASK(port) (0x3 << (4 * (port)))
-#define SHOTPLUG_CTL_DDI_HPD_NO_DETECT(port) (0x0 << (4 * (port)))
-#define SHOTPLUG_CTL_DDI_HPD_SHORT_DETECT(port) (0x1 << (4 * (port)))
-#define SHOTPLUG_CTL_DDI_HPD_LONG_DETECT(port) (0x2 << (4 * (port)))
-#define SHOTPLUG_CTL_DDI_HPD_SHORT_LONG_DETECT(port) (0x3 << (4 * (port)))
+#define SHOTPLUG_CTL_DDI_HPD_ENABLE(hpd_pin) (0x8 <<
(_HPD_PIN_DDI(hpd_pin) * 4))
+#define SHOTPLUG_CTL_DDI_HPD_STATUS_MASK(hpd_pin)(0x3 <<
(_HPD_PIN_DDI(hpd_pin) * 4))
+#define SHOTPLUG_CTL_DDI_HPD_NO_DETECT(hpd_pin) (0x0 <<
(_HPD_PIN_DDI(hpd_pin) * 4))
+#define SHOTPLUG_CTL_DDI_HPD_SHORT_DETECT(hpd_pin) (0x1 <<
(_HPD_PIN_DDI(hpd_pin) * 4))
+#define SHOTPLUG_CTL_DDI_HPD_LONG_DETECT(hpd_pin)(0x2 <<
(_HPD_PIN_DDI(hpd_pin) * 4))
+#define SHOTPLUG_CTL_DDI_HPD_SHORT_LONG_DETECT(hpd_pin) (0x3 <<
(_HPD_PIN_DDI(hpd_pin) * 4))
#define SHOTPLUG_CTL_TC _MMIO(0xc4034)
Re: [Intel-gfx] [PATCH v2 09/20] drm/i915: Introduce GEN8_DE_PORT_HOTPLUG()
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
Lucas De Marchi
---
drivers/gpu/drm/i915/gvt/display.c | 14 +++---
drivers/gpu/drm/i915/i915_irq.c| 18 +-
drivers/gpu/drm/i915/i915_reg.h| 10 +-
3 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/display.c
b/drivers/gpu/drm/i915/gvt/display.c
index c124734e114c..5b5c71a0b4af 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -174,23 +174,23 @@ static void emulate_monitor_status_change(struct
intel_vgpu *vgpu)
if (IS_BROXTON(dev_priv)) {
vgpu_vreg_t(vgpu, GEN8_DE_PORT_ISR) &=
- ~(BXT_DE_PORT_HP_DDI(HPD_PORT_A) |
- BXT_DE_PORT_HP_DDI(HPD_PORT_B) |
- BXT_DE_PORT_HP_DDI(HPD_PORT_C));
+ ~(GEN8_DE_PORT_HOTPLUG(HPD_PORT_A) |
+ GEN8_DE_PORT_HOTPLUG(HPD_PORT_B) |
+ GEN8_DE_PORT_HOTPLUG(HPD_PORT_C));
if (intel_vgpu_has_monitor_on_port(vgpu, PORT_A)) {
vgpu_vreg_t(vgpu, GEN8_DE_PORT_ISR) |=
- BXT_DE_PORT_HP_DDI(HPD_PORT_A);
+ GEN8_DE_PORT_HOTPLUG(HPD_PORT_A);
}
if (intel_vgpu_has_monitor_on_port(vgpu, PORT_B)) {
vgpu_vreg_t(vgpu, GEN8_DE_PORT_ISR) |=
- BXT_DE_PORT_HP_DDI(HPD_PORT_B);
+ GEN8_DE_PORT_HOTPLUG(HPD_PORT_B);
}
if (intel_vgpu_has_monitor_on_port(vgpu, PORT_C)) {
vgpu_vreg_t(vgpu, GEN8_DE_PORT_ISR) |=
- BXT_DE_PORT_HP_DDI(HPD_PORT_C);
+ GEN8_DE_PORT_HOTPLUG(HPD_PORT_C);
}
return;
@@ -328,7 +328,7 @@ static void emulate_monitor_status_change(struct intel_vgpu
*vgpu)
if (intel_vgpu_has_monitor_on_port(vgpu, PORT_A)) {
if (IS_BROADWELL(dev_priv))
vgpu_vreg_t(vgpu, GEN8_DE_PORT_ISR) |=
- GEN8_PORT_DP_A_HOTPLUG;
+ GEN8_DE_PORT_HOTPLUG(HPD_PORT_A);
else
vgpu_vreg_t(vgpu, SDEISR) |= SDE_PORTA_HOTPLUG_SPT;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 9b92b95f7a6f..6b824db1424a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -71,7 +71,7 @@ static const u32 hpd_ivb[HPD_NUM_PINS] = {
};
static const u32 hpd_bdw[HPD_NUM_PINS] = {
- [HPD_PORT_A] = GEN8_PORT_DP_A_HOTPLUG,
+ [HPD_PORT_A] = GEN8_DE_PORT_HOTPLUG(HPD_PORT_A),
};
static const u32 hpd_ibx[HPD_NUM_PINS] = {
@@ -126,9 +126,9 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
};
static const u32 hpd_bxt[HPD_NUM_PINS] = {
- [HPD_PORT_A] = BXT_DE_PORT_HP_DDI(HPD_PORT_A),
- [HPD_PORT_B] = BXT_DE_PORT_HP_DDI(HPD_PORT_B),
- [HPD_PORT_C] = BXT_DE_PORT_HP_DDI(HPD_PORT_C),
+ [HPD_PORT_A] = GEN8_DE_PORT_HOTPLUG(HPD_PORT_A),
+ [HPD_PORT_B] = GEN8_DE_PORT_HOTPLUG(HPD_PORT_B),
+ [HPD_PORT_C] = GEN8_DE_PORT_HOTPLUG(HPD_PORT_C),
};
static const u32 hpd_gen11[HPD_NUM_PINS] = {
@@ -2367,7 +2367,7 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
u32 master_ctl)
found = true;
}
} else if (IS_BROADWELL(dev_priv)) {
- tmp_mask = iir & GEN8_PORT_DP_A_HOTPLUG;
+ tmp_mask = iir & BDW_DE_PORT_HOTPLUG_MASK;
if (tmp_mask) {
ilk_hpd_irq_handler(dev_priv, tmp_mask);
found = true;
@@ -3391,13 +3391,13 @@ static void __bxt_hpd_detection_setup(struct
drm_i915_private *dev_priv,
* For BXT invert bit has to be set based on AOB design
* for HPD detection logic, update it based on VBT fields.
*/
- if ((enabled_irqs & BXT_DE_PORT_HP_DDI(HPD_PORT_A)) &&
+ if ((enabled_irqs & GEN8_DE_PORT_HOTPLUG(HPD_PORT_A)) &&
intel_bios_is_port_hpd_inverted(dev_priv, PORT_A))
hotplug |= BXT_DDIA_HPD_INVERT;
- if ((enabled_irqs & BXT_DE_PORT_HP_DDI(HPD_PORT_B)) &&
+ if ((enabled_irqs & GEN8_DE_PORT_HOTPLUG(HPD_PORT_B)) &&
intel_bios_is_port_hpd_inverted(dev_priv, PORT_B))
hotplug |= BXT_DDIB_HPD_INVERT;
- if ((enabled_irqs & BXT_DE_PORT_HP_DDI(HPD_PORT_C)) &&
+ if ((enabled_irqs & GEN8_DE_PORT_HOTPLUG(HPD_PORT_C))
Re: [Intel-gfx] [PATCH v2 08/20] drm/i915: Parametrize BXT_DE_PORT_HP_DDI with hpd_pin
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-by: Ville Syrjälä
Reviewed-by: Lucas De Marchi
Lucas De Marchi
---
drivers/gpu/drm/i915/gvt/display.c | 13 +++--
drivers/gpu/drm/i915/i915_irq.c| 12 ++--
drivers/gpu/drm/i915/i915_reg.h| 12 ++--
3 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/display.c
b/drivers/gpu/drm/i915/gvt/display.c
index 7ba16ddfe75f..c124734e114c 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -173,23 +173,24 @@ static void emulate_monitor_status_change(struct
intel_vgpu *vgpu)
int pipe;
if (IS_BROXTON(dev_priv)) {
- vgpu_vreg_t(vgpu, GEN8_DE_PORT_ISR) &= ~(BXT_DE_PORT_HP_DDIA |
- BXT_DE_PORT_HP_DDIB |
- BXT_DE_PORT_HP_DDIC);
+ vgpu_vreg_t(vgpu, GEN8_DE_PORT_ISR) &=
+ ~(BXT_DE_PORT_HP_DDI(HPD_PORT_A) |
+ BXT_DE_PORT_HP_DDI(HPD_PORT_B) |
+ BXT_DE_PORT_HP_DDI(HPD_PORT_C));
if (intel_vgpu_has_monitor_on_port(vgpu, PORT_A)) {
vgpu_vreg_t(vgpu, GEN8_DE_PORT_ISR) |=
- BXT_DE_PORT_HP_DDIA;
+ BXT_DE_PORT_HP_DDI(HPD_PORT_A);
}
if (intel_vgpu_has_monitor_on_port(vgpu, PORT_B)) {
vgpu_vreg_t(vgpu, GEN8_DE_PORT_ISR) |=
- BXT_DE_PORT_HP_DDIB;
+ BXT_DE_PORT_HP_DDI(HPD_PORT_B);
}
if (intel_vgpu_has_monitor_on_port(vgpu, PORT_C)) {
vgpu_vreg_t(vgpu, GEN8_DE_PORT_ISR) |=
- BXT_DE_PORT_HP_DDIC;
+ BXT_DE_PORT_HP_DDI(HPD_PORT_C);
}
return;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d9438194c2f0..9b92b95f7a6f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -126,9 +126,9 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
};
static const u32 hpd_bxt[HPD_NUM_PINS] = {
- [HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
- [HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
- [HPD_PORT_C] = BXT_DE_PORT_HP_DDIC,
+ [HPD_PORT_A] = BXT_DE_PORT_HP_DDI(HPD_PORT_A),
+ [HPD_PORT_B] = BXT_DE_PORT_HP_DDI(HPD_PORT_B),
+ [HPD_PORT_C] = BXT_DE_PORT_HP_DDI(HPD_PORT_C),
};
static const u32 hpd_gen11[HPD_NUM_PINS] = {
@@ -3391,13 +3391,13 @@ static void __bxt_hpd_detection_setup(struct
drm_i915_private *dev_priv,
* For BXT invert bit has to be set based on AOB design
* for HPD detection logic, update it based on VBT fields.
*/
- if ((enabled_irqs & BXT_DE_PORT_HP_DDIA) &&
+ if ((enabled_irqs & BXT_DE_PORT_HP_DDI(HPD_PORT_A)) &&
intel_bios_is_port_hpd_inverted(dev_priv, PORT_A))
hotplug |= BXT_DDIA_HPD_INVERT;
- if ((enabled_irqs & BXT_DE_PORT_HP_DDIB) &&
+ if ((enabled_irqs & BXT_DE_PORT_HP_DDI(HPD_PORT_B)) &&
intel_bios_is_port_hpd_inverted(dev_priv, PORT_B))
hotplug |= BXT_DDIB_HPD_INVERT;
- if ((enabled_irqs & BXT_DE_PORT_HP_DDIC) &&
+ if ((enabled_irqs & BXT_DE_PORT_HP_DDI(HPD_PORT_C)) &&
intel_bios_is_port_hpd_inverted(dev_priv, PORT_C))
hotplug |= BXT_DDIC_HPD_INVERT;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2e378d9b21c5..72f93ec38aea 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7786,6 +7786,8 @@ enum {
(GEN9_DE_PIPE_IRQ_FAULT_ERRORS | \
GEN11_PIPE_PLANE5_FAULT)
+#define _HPD_PIN_DDI(hpd_pin) ((hpd_pin) - HPD_PORT_A)
+
#define GEN8_DE_PORT_ISR _MMIO(0x0)
#define GEN8_DE_PORT_IMR _MMIO(0x4)
#define GEN8_DE_PORT_IIR _MMIO(0x8)
@@ -7799,12 +7801,10 @@ enum {
#define GEN9_AUX_CHANNEL_B (1 << 25)
#define DSI1_TE(1 << 24)
#define DSI0_TE(1 << 23)
-#define BXT_DE_PORT_HP_DDIC (1 << 5)
-#define BXT_DE_PORT_HP_DDIB (1 << 4)
-#define BXT_DE_PORT_HP_DDIA (1 << 3)
-#define BXT_DE_PORT_HOTPLUG_MASK (BXT_DE_PORT_HP_DDIA | \
-BXT_DE_PORT_HP_DDIB | \
-BXT_DE_PORT_HP_DDIC)
+#define BXT_DE_PORT_HP_DDI(hpd_pin) REG_BIT(3 + _HPD_PIN_DDI(hpd_pin))
+#define BXT_DE_PORT_HOTPLUG_MASK (BXT_DE_PORT_HP_DDI(HPD_PORT_A) | \
+BXT_DE_PORT_HP_DDI(HPD_PORT_B) | \
+
Re: [Intel-gfx] [PATCH 07/20] drm/i915: Use AUX_CH_USBCn for the RKL VBT AUX CH setup
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/drm/i915/display/intel_bios.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c index 179029c3d3d5..77c86f51c36d 100644 --- a/drivers/gpu/drm/i915/display/intel_bios.c +++ b/drivers/gpu/drm/i915/display/intel_bios.c @@ -2636,10 +2636,14 @@ enum aux_ch intel_bios_port_aux_ch(struct drm_i915_private *dev_priv, aux_ch = AUX_CH_B; break; case DP_AUX_C: - aux_ch = IS_ROCKETLAKE(dev_priv) ? AUX_CH_D : AUX_CH_C; + /* +* RKL VBT uses PHY based mapping. Combo PHYs A,B,C,D +* map to DDI A,B,TC1,TC2 respectively. This will conflict with DG1 that was just merged and use the same mapping as RKL. Change here LGTM. Reviewed-by: Lucas De Marchi Lucas De Marchi +*/ + aux_ch = IS_ROCKETLAKE(dev_priv) ? AUX_CH_USBC1 : AUX_CH_C; break; case DP_AUX_D: - aux_ch = IS_ROCKETLAKE(dev_priv) ? AUX_CH_E : AUX_CH_D; + aux_ch = IS_ROCKETLAKE(dev_priv) ? AUX_CH_USBC2 : AUX_CH_D; break; case DP_AUX_E: aux_ch = AUX_CH_E; -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/20] drm/i915: Pimp AUX CH names
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_name() which wouldn't give us the right thing on
tgl+).
Signed-off-by: Ville Syrjälä
Reviewed-by: Lucas De Marchi
Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_dp.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index a73c354c920e..299dc444a777 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1877,6 +1877,7 @@ intel_dp_aux_init(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *encoder = _port->base;
+ enum aux_ch aux_ch = dig_port->aux_ch;
if (INTEL_GEN(dev_priv) >= 12) {
intel_dp->aux_ch_ctl_reg = tgl_aux_ctl_reg;
@@ -1909,9 +1910,15 @@ intel_dp_aux_init(struct intel_dp *intel_dp)
drm_dp_aux_init(_dp->aux);
/* Failure to allocate our preferred name is not critical */
- intel_dp->aux.name = kasprintf(GFP_KERNEL, "AUX %c/port %c",
- aux_ch_name(dig_port->aux_ch),
- port_name(encoder->port));
+ if (INTEL_GEN(dev_priv) >= 12 && aux_ch >= AUX_CH_USBC1)
+ intel_dp->aux.name = kasprintf(GFP_KERNEL, "AUX USBC%c/%s",
+ aux_ch - AUX_CH_USBC1 + '1',
+ encoder->base.name);
+ else
+ intel_dp->aux.name = kasprintf(GFP_KERNEL, "AUX %c/%s",
+ aux_ch_name(aux_ch),
+ encoder->base.name);
+
intel_dp->aux.transfer = intel_dp_aux_transfer;
}
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/vbt: Add VRR VBT toggle
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 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index b4742c4fde97..46f3f4804c9e 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -835,6 +835,7 @@ struct bdb_lfp_power {
> u16 lace_enabled_status;
> struct agressiveness_profile_entry aggressivenes[16];
> u16 hobl; /* 232+ */
> + u16 vrr_feature_enabled; /* 233+ */
> } __packed;
>
> /*
> --
> 2.28.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/20] drm/i915: Introduce AUX_CH_USBCn
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_display.h | 8 +++
drivers/gpu/drm/i915/display/intel_dp.c | 53 ++--
2 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index a39be3c9e0cf..cba876721ea0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -290,6 +290,14 @@ enum aux_ch {
AUX_CH_G,
AUX_CH_H,
AUX_CH_I,
+
+ /* tgl+ */
+ AUX_CH_USBC1 = AUX_CH_D,
+ AUX_CH_USBC2,
+ AUX_CH_USBC3,
+ AUX_CH_USBC4,
+ AUX_CH_USBC5,
+ AUX_CH_USBC6,
};
#define aux_ch_name(a) ((a) + 'A')
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 239016dcd544..a73c354c920e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1792,7 +1792,6 @@ static i915_reg_t skl_aux_ctl_reg(struct intel_dp
*intel_dp)
case AUX_CH_D:
case AUX_CH_E:
case AUX_CH_F:
- case AUX_CH_G:
return DP_AUX_CH_CTL(aux_ch);
default:
MISSING_CASE(aux_ch);
@@ -1813,7 +1812,52 @@ static i915_reg_t skl_aux_data_reg(struct intel_dp
*intel_dp, int index)
case AUX_CH_D:
case AUX_CH_E:
case AUX_CH_F:
- case AUX_CH_G:
+ return DP_AUX_CH_DATA(aux_ch, index);
+ default:
+ MISSING_CASE(aux_ch);
+ return DP_AUX_CH_DATA(AUX_CH_A, index);
+ }
+}
+
+static i915_reg_t tgl_aux_ctl_reg(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ enum aux_ch aux_ch = dig_port->aux_ch;
+
+ switch (aux_ch) {
+ case AUX_CH_A:
+ case AUX_CH_B:
+ case AUX_CH_C:
+ case AUX_CH_USBC1:
+ case AUX_CH_USBC2:
+ case AUX_CH_USBC3:
+ case AUX_CH_USBC4:
+ case AUX_CH_USBC5:
+ case AUX_CH_USBC6:
+ return DP_AUX_CH_CTL(aux_ch);
+ default:
+ MISSING_CASE(aux_ch);
+ return DP_AUX_CH_CTL(AUX_CH_A);
+ }
+}
+
+static i915_reg_t tgl_aux_data_reg(struct intel_dp *intel_dp, int index)
+{
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ enum aux_ch aux_ch = dig_port->aux_ch;
+
+ switch (aux_ch) {
+ case AUX_CH_A:
+ case AUX_CH_B:
+ case AUX_CH_C:
+ case AUX_CH_USBC1:
+ case AUX_CH_USBC2:
+ case AUX_CH_USBC3:
+ case AUX_CH_USBC4:
+ case AUX_CH_USBC5:
+ case AUX_CH_USBC6:
return DP_AUX_CH_DATA(aux_ch, index);
default:
MISSING_CASE(aux_ch);
@@ -1834,7 +1878,10 @@ intel_dp_aux_init(struct intel_dp *intel_dp)
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *encoder = _port->base;
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (INTEL_GEN(dev_priv) >= 12) {
+ intel_dp->aux_ch_ctl_reg = tgl_aux_ctl_reg;
why is this even a function pointer rather than just the reg? AFAICS it
only depends on dig_port->aux_ch that is initialized in intel_ddi_init()
but could be orthogonal to the change here.
Reviewed-by: Lucas De Marchi
Lucas De Marchi
+ intel_dp->aux_ch_data_reg = tgl_aux_data_reg;
+ } else if (INTEL_GEN(dev_priv) >= 9) {
intel_dp->aux_ch_ctl_reg = skl_aux_ctl_reg;
intel_dp->aux_ch_data_reg = skl_aux_data_reg;
} else if (HAS_PCH_SPLIT(dev_priv)) {
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/vbt: Update the version and expected size of BDB_GENERAL_DEFINITIONS map
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é Roberto de Souza
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 58e5657a77bb..6ce0b848e342 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1915,7 +1915,7 @@ parse_general_definitions(struct drm_i915_private
> *dev_priv,
> expected_size = 37;
> } else if (bdb->version <= 215) {
> expected_size = 38;
> - } else if (bdb->version <= 229) {
> + } else if (bdb->version <= 237) {
> expected_size = 39;
> } else {
> expected_size = sizeof(*child);
> --
> 2.28.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/vbt: Fix backlight parsing for VBT 234+
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 to be scaled down but it is only available in
> VBT 236+ so working around it by using the also new backlight_level
> in the main struct.
>
> v2:
> - missed that backlight_data->level is also obsolete
>
> BSpec: 20149
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 30 +--
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 12 ++--
> 2 files changed, 38 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 4716484af62d..58e5657a77bb 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -425,6 +425,7 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
> const struct bdb_lfp_backlight_data *backlight_data;
> const struct lfp_backlight_data_entry *entry;
> int panel_type = dev_priv->vbt.panel_type;
> + u16 level;
>
> backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);
> if (!backlight_data)
> @@ -459,14 +460,39 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
>
> dev_priv->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
> dev_priv->vbt.backlight.active_low_pwm = entry->active_low_pwm;
> - dev_priv->vbt.backlight.min_brightness = entry->min_brightness;
> +
> + if (bdb->version >= 234) {
> + bool scale = false;
> + u16 min_level;
> +
> + level = backlight_data->backlight_level[panel_type].level;
> + min_level =
> backlight_data->backlight_min_level[panel_type].level;
> +
> + if (bdb->version >= 236)
> + scale =
> backlight_data->backlight_precision_bits[panel_type] == 16;
> + else
> + scale = level > 255;
I'm not sure I follow the 'else' arm here. On version 234/235 we'd have
16-bit level values. In the absence of any other precision information
wouldn't we assume that all the bits are used and that we have a full
16-bit precision? If the level is < 256 (or for that matter if we have
any value where level & 0xFF is non-zero) wouldn't that definitely mean
that there are 16-bits of precision since otherwise those low bits would
have to be 0's?
> +
> + if (scale)
> + min_level = min_level / 255;
> +
> + if (min_level > 255) {
> + drm_warn(_priv->drm, "Backlight min level > 255\n");
> + level = 255;
> + }
> + dev_priv->vbt.backlight.min_brightness = min_level;
> + } else {
> + level = backlight_data->level[panel_type];
> + dev_priv->vbt.backlight.min_brightness = entry->min_brightness;
> + }
> +
> drm_dbg_kms(_priv->drm,
> "VBT backlight PWM modulation frequency %u Hz, "
> "active %s, min brightness %u, level %u, controller %u\n",
> dev_priv->vbt.backlight.pwm_freq_hz,
> dev_priv->vbt.backlight.active_low_pwm ? "low" : "high",
> dev_priv->vbt.backlight.min_brightness,
> - backlight_data->level[panel_type],
> + level,
> dev_priv->vbt.backlight.controller);
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index 54bcc6a6947c..b4742c4fde97 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -782,7 +782,7 @@ struct lfp_backlight_data_entry {
> u8 active_low_pwm:1;
> u8 obsolete1:5;
> u16 pwm_freq_hz;
> - u8 min_brightness;
> + u8 min_brightness; /* Obsolete from 234+ */
> u8 obsolete2;
> u8 obsolete3;
> } __packed;
> @@ -792,11 +792,19 @@ struct lfp_backlight_control_method {
> u8 controller:4;
> } __packed;
>
> +struct lfp_backlight_level {
> + u32 level : 16;
> + u32 reserved : 16;
> +} __packed;
> +
> struct bdb_lfp_backlight_data {
> u8 entry_size;
> struct lfp_backlight_data_entry data[16];
> - u8 level[16];
> + u8 level[16]; /* Obsolete from 234+ */
> struct lfp_backlight_control_method backlight_control[16];
> + struct lfp_backlight_level backlight_level[16]; /* 234+ */
> + struct lfp_backlight_level backlight_min_level[16]; /* 234+ */
Technically these two are described as "brightness level" rather than
"backlight level" in the spec. Matching the spec's terminology might
make this slightly easier to follow when people look at it in the
future, but up to you.
Matt
> + u8
Re: [Intel-gfx] [PATCH 04/20] drm/i915: Give DDI encoders even better names
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 PHY name as well.
ICL is a bit special since it already has the two different types
of DDIs (combo or TC) but it still calls them just DDI A-F regarless
of the type. For that let's add an extra "(TC)" note to remind
is which type of DDI it really is.
The code is darn ugly, but not sure there's much we can do about it.
Signed-off-by: Ville Syrjälä
this also achieves one of the goals of my old series I never
completed (https://patchwork.freedesktop.org/series/71330/).
I'm ok going this direction instead.
Reviewed-by: Lucas De Marchi
Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_ddi.c | 27 ++--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index d1e4cb04e90d..5a30bc6a6c49 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -5171,8 +5171,31 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
encoder = _port->base;
- drm_encoder_init(_priv->drm, >base, _ddi_funcs,
-DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));
+ if (INTEL_GEN(dev_priv) >= 12) {
+ enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
+
+ drm_encoder_init(_priv->drm, >base,
_ddi_funcs,
+DRM_MODE_ENCODER_TMDS,
+"DDI %s%c/PHY %s%c",
+port >= PORT_TC1 ? "TC" : "",
+port >= PORT_TC1 ? port_name(port) : port -
PORT_TC1 + '1',
+tc_port != TC_PORT_NONE ? "TC" : "",
+tc_port != TC_PORT_NONE ? phy_name(phy) :
tc_port - TC_PORT_TC1 + '1');
+ } else if (INTEL_GEN(dev_priv) >= 11) {
+ enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
+
+ drm_encoder_init(_priv->drm, >base,
_ddi_funcs,
+DRM_MODE_ENCODER_TMDS,
+"DDI %c%s/PHY %s%c",
+port_name(port),
+port >= PORT_C ? " (TC)" : "",
+tc_port != TC_PORT_NONE ? "TC" : "",
+tc_port != TC_PORT_NONE ? phy_name(phy) :
tc_port - TC_PORT_TC1 + '1');
+ } else {
+ drm_encoder_init(_priv->drm, >base,
_ddi_funcs,
+DRM_MODE_ENCODER_TMDS,
+"DDI %c/PHY %c", port_name(port),
phy_name(phy));
+ }
mutex_init(_port->hdcp_mutex);
dig_port->num_hdcp_streams = 0;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/20] drm/i915: Add PORT_TCn aliases to enum port
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/intel_display.h
@@ -207,6 +207,14 @@ enum port {
PORT_H,
PORT_I,
+ /* tgl+ */
+ PORT_TC1 = PORT_D,
ICL also uses TC ports but there PORT_TC1 would be PORT_C. Just ignore
that and only add the aliases for tgl+ or should we also add for ICL to
avoid confusion?
Lucas De Marchi
+ PORT_TC2,
+ PORT_TC3,
+ PORT_TC4,
+ PORT_TC5,
+ PORT_TC6,
+
I915_MAX_PORTS
};
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/20] drm/i915: s/PORT_TC/TC_PORT_TC/
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 doesn't sound great.
Maybe TC_PORT_1, TC_PORT_2, TC_PORT_3, ...?
When we added enum tc_port we didn't have enum phy. Maybe now we can
actually remove tc_port.
Lucas De Marchi
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.h | 14 ++--
drivers/gpu/drm/i915/display/intel_tc.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 78 ++--
drivers/gpu/drm/i915/i915_reg.h | 60 +++
5 files changed, 78 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 907e1d155443..32d24c60ff96 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7367,7 +7367,7 @@ enum phy intel_port_to_phy(struct drm_i915_private *i915,
enum port port)
enum tc_port intel_port_to_tc(struct drm_i915_private *dev_priv, enum port port)
{
if (!intel_phy_is_tc(dev_priv, intel_port_to_phy(dev_priv, port)))
- return PORT_TC_NONE;
+ return TC_PORT_NONE;
if (INTEL_GEN(dev_priv) >= 12)
return port - PORT_D;
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index d10b7c8cde3f..8c93253cbd95 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -243,14 +243,14 @@ static inline const char *port_identifier(enum port port)
}
enum tc_port {
- PORT_TC_NONE = -1,
+ TC_PORT_NONE = -1,
- PORT_TC1 = 0,
- PORT_TC2,
- PORT_TC3,
- PORT_TC4,
- PORT_TC5,
- PORT_TC6,
+ TC_PORT_TC1 = 0,
+ TC_PORT_TC2,
+ TC_PORT_TC3,
+ TC_PORT_TC4,
+ TC_PORT_TC5,
+ TC_PORT_TC6,
I915_MAX_TC_PORTS
};
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 8f67aef18b2d..1cb548d757e1 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -652,7 +652,7 @@ void intel_tc_port_init(struct intel_digital_port
*dig_port, bool is_legacy)
enum port port = dig_port->base.port;
enum tc_port tc_port = intel_port_to_tc(i915, port);
- if (drm_WARN_ON(>drm, tc_port == PORT_TC_NONE))
+ if (drm_WARN_ON(>drm, tc_port == TC_PORT_NONE))
return;
snprintf(dig_port->tc_port_name, sizeof(dig_port->tc_port_name),
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b753c77c9a77..d9438194c2f0 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -132,24 +132,24 @@ static const u32 hpd_bxt[HPD_NUM_PINS] = {
};
static const u32 hpd_gen11[HPD_NUM_PINS] = {
- [HPD_PORT_TC1] = GEN11_TC_HOTPLUG(PORT_TC1) |
GEN11_TBT_HOTPLUG(PORT_TC1),
- [HPD_PORT_TC2] = GEN11_TC_HOTPLUG(PORT_TC2) |
GEN11_TBT_HOTPLUG(PORT_TC2),
- [HPD_PORT_TC3] = GEN11_TC_HOTPLUG(PORT_TC3) |
GEN11_TBT_HOTPLUG(PORT_TC3),
- [HPD_PORT_TC4] = GEN11_TC_HOTPLUG(PORT_TC4) |
GEN11_TBT_HOTPLUG(PORT_TC4),
- [HPD_PORT_TC5] = GEN11_TC_HOTPLUG(PORT_TC5) |
GEN11_TBT_HOTPLUG(PORT_TC5),
- [HPD_PORT_TC6] = GEN11_TC_HOTPLUG(PORT_TC6) |
GEN11_TBT_HOTPLUG(PORT_TC6),
+ [HPD_PORT_TC1] = GEN11_TC_HOTPLUG(TC_PORT_TC1) |
GEN11_TBT_HOTPLUG(TC_PORT_TC1),
+ [HPD_PORT_TC2] = GEN11_TC_HOTPLUG(TC_PORT_TC2) |
GEN11_TBT_HOTPLUG(TC_PORT_TC2),
+ [HPD_PORT_TC3] = GEN11_TC_HOTPLUG(TC_PORT_TC3) |
GEN11_TBT_HOTPLUG(TC_PORT_TC3),
+ [HPD_PORT_TC4] = GEN11_TC_HOTPLUG(TC_PORT_TC4) |
GEN11_TBT_HOTPLUG(TC_PORT_TC4),
+ [HPD_PORT_TC5] = GEN11_TC_HOTPLUG(TC_PORT_TC5) |
GEN11_TBT_HOTPLUG(TC_PORT_TC5),
+ [HPD_PORT_TC6] = GEN11_TC_HOTPLUG(TC_PORT_TC6) |
GEN11_TBT_HOTPLUG(TC_PORT_TC6),
};
static const u32 hpd_icp[HPD_NUM_PINS] = {
[HPD_PORT_A] = SDE_DDI_HOTPLUG_ICP(PORT_A),
[HPD_PORT_B] = SDE_DDI_HOTPLUG_ICP(PORT_B),
[HPD_PORT_C] = SDE_DDI_HOTPLUG_ICP(PORT_C),
- [HPD_PORT_TC1] = SDE_TC_HOTPLUG_ICP(PORT_TC1),
- [HPD_PORT_TC2] = SDE_TC_HOTPLUG_ICP(PORT_TC2),
- [HPD_PORT_TC3] = SDE_TC_HOTPLUG_ICP(PORT_TC3),
- [HPD_PORT_TC4] = SDE_TC_HOTPLUG_ICP(PORT_TC4),
- [HPD_PORT_TC5] = SDE_TC_HOTPLUG_ICP(PORT_TC5),
- [HPD_PORT_TC6] = SDE_TC_HOTPLUG_ICP(PORT_TC6),
+ [HPD_PORT_TC1] = SDE_TC_HOTPLUG_ICP(TC_PORT_TC1),
+ [HPD_PORT_TC2] = SDE_TC_HOTPLUG_ICP(TC_PORT_TC2),
+ [HPD_PORT_TC3] = SDE_TC_HOTPLUG_ICP(TC_PORT_TC3),
+ [HPD_PORT_TC4] = SDE_TC_HOTPLUG_ICP(TC_PORT_TC4),
+ [HPD_PORT_TC5] =
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Reorder hpd init vs. display resume
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 call these two things do exactly the
> same thing (ie. enable HPD interrupts). Which even makes sense
> since we definitely need working HPD interrupts for MST sideband
> during the display resume.
>
> So let's nuke the open-coded call and move the intel_hpd_init()
> call earlier. However we need to leave the poll_init_work stuff
> behind after the display resume as that will trigger display
> detection while we're resuming. We don't want that trampling over
> the display resume process. To make this a bit more symmetric
> we turn this into a intel_hpd_poll_{enable,disable}() pair.
> So we end up with the following transformation:
> intel_hpd_poll_init() -> intel_hpd_poll_enable()
> lone intel_hpd_init() -> intel_hpd_init()+intel_hpd_poll_disable()
> .hpd_irq_setup()+resume+intel_hpd_init() ->
> intel_hpd_init()+resume+intel_hpd_poll_disable()
>
> If we really would like to prevent all *long* HPD processing during
> display resume we'd need some kind of software mechanism to simply
> ignore all long HPDs. Currently we appear to have that just for
> fbdev via ifbdev->hpd_suspended. Since we aren't exploding left and
> right all the time I guess that's mostly sufficient.
>
> For a bit of history on this, we first got a mechanism to block
> hotplug processing during suspend in commit 15239099d7a7 ("drm/i915:
> enable irqs earlier when resuming") on account of moving the irq enable
> earlier. This then got removed in commit 50c3dc970a09 ("drm/fb-helper:
> Fix hpd vs. initial config races") because the fdev initial config
> got pushed to a later point. The second ad-hoc hpd_irq_setup() for
> resume was added in commit 0e32b39ceed6 ("drm/i915: add DP 1.2 MST
> support (v0.7)") to be able to do MST sideband during the resume.
> And finally we got a partial resurrection of the hpd blocking
> mechanism in commit e8a8fedd57fd ("drm/i915: Block fbdev HPD
> processing during suspend"), but this time it only prevent fbdev
> from handling hpd while resuming.
>
> v2: Leave the poll_init_work behind
>
> Cc: Lyude Paul
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 9 ++--
> .../drm/i915/display/intel_display_power.c| 3 +-
> drivers/gpu/drm/i915/display/intel_hotplug.c | 42 ++-
> drivers/gpu/drm/i915/display/intel_hotplug.h | 3 +-
> drivers/gpu/drm/i915/i915_drv.c | 23 --
> 5 files changed, 46 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 907e1d155443..0d5607ae97c4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5036,18 +5036,15 @@ void intel_finish_reset(struct drm_i915_private
> *dev_priv)
> intel_pps_unlock_regs_wa(dev_priv);
> intel_modeset_init_hw(dev_priv);
> intel_init_clock_gating(dev_priv);
> -
> - spin_lock_irq(_priv->irq_lock);
> - if (dev_priv->display.hpd_irq_setup)
> - dev_priv->display.hpd_irq_setup(dev_priv);
> - spin_unlock_irq(_priv->irq_lock);
> + intel_hpd_init(dev_priv);
> + intel_hpd_poll_disable(dev_priv);
>
> ret = __intel_display_resume(dev, state, ctx);
> if (ret)
> drm_err(_priv->drm,
> "Restoring old state failed with %i\n", ret);
>
> - intel_hpd_init(dev_priv);
> + intel_hpd_poll_disable(dev_priv);
Looks like you're calling intel_hpd_poll_disable() twice here, is this
intentional?
> }
>
> drm_atomic_state_put(state);
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 7277e58b01f1..20ddc54298cb 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -1424,6 +1424,7 @@ static void vlv_display_power_well_init(struct
> drm_i915_private *dev_priv)
> return;
>
> intel_hpd_init(dev_priv);
> + intel_hpd_poll_disable(dev_priv);
>
> /* Re-enable the ADPA, if we have one */
> for_each_intel_encoder(_priv->drm, encoder) {
> @@ -1449,7 +1450,7 @@ static void vlv_display_power_well_deinit(struct
> drm_i915_private *dev_priv)
>
> /* Prevent us from re-enabling polling on accident in late suspend */
> if (!dev_priv->drm.dev->power.is_suspended)
> - intel_hpd_poll_init(dev_priv);
> + intel_hpd_poll_enable(dev_priv);
> }
>
> static void vlv_display_power_well_enable(struct
Re: [Intel-gfx] [PATCH 01/20] drm/i915: Sort the mess around ICP TC hotplugs regs
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 that vs. ICP_TC_HPD_{SHORT,LONG}_DETECT().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 215
1 file changed, 107 insertions(+), 108 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6ad9ee4243a0..efe51a4ef719 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4618,6 +4618,110 @@ enum {
#define PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME REG_BIT(2)
#define PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE REG_BIT(1)
+/* Icelake DSC Rate Control Range Parameter Registers */
+#define DSCA_RC_RANGE_PARAMETERS_0 _MMIO(0x6B240)
+#define DSCA_RC_RANGE_PARAMETERS_0_UDW _MMIO(0x6B240 + 4)
+#define DSCC_RC_RANGE_PARAMETERS_0 _MMIO(0x6BA40)
+#define DSCC_RC_RANGE_PARAMETERS_0_UDW _MMIO(0x6BA40 + 4)
+#define _ICL_DSC0_RC_RANGE_PARAMETERS_0_PB (0x78208)
+#define _ICL_DSC0_RC_RANGE_PARAMETERS_0_UDW_PB (0x78208 + 4)
+#define _ICL_DSC1_RC_RANGE_PARAMETERS_0_PB (0x78308)
+#define _ICL_DSC1_RC_RANGE_PARAMETERS_0_UDW_PB (0x78308 + 4)
+#define _ICL_DSC0_RC_RANGE_PARAMETERS_0_PC (0x78408)
+#define _ICL_DSC0_RC_RANGE_PARAMETERS_0_UDW_PC (0x78408 + 4)
+#define _ICL_DSC1_RC_RANGE_PARAMETERS_0_PC (0x78508)
+#define _ICL_DSC1_RC_RANGE_PARAMETERS_0_UDW_PC (0x78508 + 4)
+#define ICL_DSC0_RC_RANGE_PARAMETERS_0(pipe) _MMIO_PIPE((pipe) -
PIPE_B, \
+
_ICL_DSC0_RC_RANGE_PARAMETERS_0_PB, \
+
_ICL_DSC0_RC_RANGE_PARAMETERS_0_PC)
+#define ICL_DSC0_RC_RANGE_PARAMETERS_0_UDW(pipe) _MMIO_PIPE((pipe) -
PIPE_B, \
+
_ICL_DSC0_RC_RANGE_PARAMETERS_0_UDW_PB, \
+
_ICL_DSC0_RC_RANGE_PARAMETERS_0_UDW_PC)
+#define ICL_DSC1_RC_RANGE_PARAMETERS_0(pipe) _MMIO_PIPE((pipe) -
PIPE_B, \
+
_ICL_DSC1_RC_RANGE_PARAMETERS_0_PB, \
+
_ICL_DSC1_RC_RANGE_PARAMETERS_0_PC)
+#define ICL_DSC1_RC_RANGE_PARAMETERS_0_UDW(pipe) _MMIO_PIPE((pipe) -
PIPE_B, \
+
_ICL_DSC1_RC_RANGE_PARAMETERS_0_UDW_PB, \
+
_ICL_DSC1_RC_RANGE_PARAMETERS_0_UDW_PC)
+#define RC_BPG_OFFSET_SHIFT10
+#define RC_MAX_QP_SHIFT5
+#define RC_MIN_QP_SHIFT0
+
+#define DSCA_RC_RANGE_PARAMETERS_1 _MMIO(0x6B248)
+#define DSCA_RC_RANGE_PARAMETERS_1_UDW _MMIO(0x6B248 + 4)
+#define DSCC_RC_RANGE_PARAMETERS_1 _MMIO(0x6BA48)
+#define DSCC_RC_RANGE_PARAMETERS_1_UDW _MMIO(0x6BA48 + 4)
+#define _ICL_DSC0_RC_RANGE_PARAMETERS_1_PB (0x78210)
+#define _ICL_DSC0_RC_RANGE_PARAMETERS_1_UDW_PB (0x78210 + 4)
+#define _ICL_DSC1_RC_RANGE_PARAMETERS_1_PB (0x78310)
+#define _ICL_DSC1_RC_RANGE_PARAMETERS_1_UDW_PB (0x78310 + 4)
+#define _ICL_DSC0_RC_RANGE_PARAMETERS_1_PC (0x78410)
+#define _ICL_DSC0_RC_RANGE_PARAMETERS_1_UDW_PC (0x78410 + 4)
+#define _ICL_DSC1_RC_RANGE_PARAMETERS_1_PC (0x78510)
+#define _ICL_DSC1_RC_RANGE_PARAMETERS_1_UDW_PC (0x78510 + 4)
+#define ICL_DSC0_RC_RANGE_PARAMETERS_1(pipe) _MMIO_PIPE((pipe) -
PIPE_B, \
+
_ICL_DSC0_RC_RANGE_PARAMETERS_1_PB, \
+
_ICL_DSC0_RC_RANGE_PARAMETERS_1_PC)
+#define ICL_DSC0_RC_RANGE_PARAMETERS_1_UDW(pipe) _MMIO_PIPE((pipe) -
PIPE_B, \
+
_ICL_DSC0_RC_RANGE_PARAMETERS_1_UDW_PB, \
+
_ICL_DSC0_RC_RANGE_PARAMETERS_1_UDW_PC)
+#define ICL_DSC1_RC_RANGE_PARAMETERS_1(pipe) _MMIO_PIPE((pipe) -
PIPE_B, \
+
_ICL_DSC1_RC_RANGE_PARAMETERS_1_PB, \
+
_ICL_DSC1_RC_RANGE_PARAMETERS_1_PC)
+#define ICL_DSC1_RC_RANGE_PARAMETERS_1_UDW(pipe) _MMIO_PIPE((pipe) -
PIPE_B, \
+
_ICL_DSC1_RC_RANGE_PARAMETERS_1_UDW_PB, \
+
_ICL_DSC1_RC_RANGE_PARAMETERS_1_UDW_PC)
+
+#define DSCA_RC_RANGE_PARAMETERS_2 _MMIO(0x6B250)
+#define DSCA_RC_RANGE_PARAMETERS_2_UDW _MMIO(0x6B250 + 4)
+#define DSCC_RC_RANGE_PARAMETERS_2 _MMIO(0x6BA50)
Re: [Intel-gfx] [PATCH 1/2] drm/i915/dpcd_bl: Skip testing control capability with force DPCD quirk
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 this
myself)
JFYI - the proper fix here is to just drop the
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP check from the code entirely. As long as
the backlight supports AUX_SET_CAP, that should be enough for us to control it.
On Wed, 2020-10-07 at 14:58 +0800, Kai-Heng Feng wrote:
> 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-by: Kai-Heng Feng
> ---
> drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index acbd7eb66cbe..acf2e1c65290 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -347,9 +347,13 @@ int intel_dp_aux_init_backlight_funcs(struct
> intel_connector *intel_connector)
> struct intel_panel *panel = _connector->panel;
> struct intel_dp *intel_dp = enc_to_intel_dp(intel_connector->encoder);
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + bool force_dpcd;
> +
> + force_dpcd = drm_dp_has_quirk(_dp->desc, intel_dp->edid_quirks,
> + DP_QUIRK_FORCE_DPCD_BACKLIGHT);
>
> if (i915->params.enable_dpcd_backlight == 0 ||
> - !intel_dp_aux_display_control_capable(intel_connector))
> + (!force_dpcd &&
> !intel_dp_aux_display_control_capable(intel_connector)))
> return -ENODEV;
>
> /*
> @@ -358,9 +362,7 @@ int intel_dp_aux_init_backlight_funcs(struct
> intel_connector *intel_connector)
>*/
> if (i915->vbt.backlight.type !=
> INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
> - i915->params.enable_dpcd_backlight != 1 &&
> - !drm_dp_has_quirk(_dp->desc, intel_dp->edid_quirks,
> - DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
> + i915->params.enable_dpcd_backlight != 1 && !force_dpcd) {
> drm_info(>drm,
>"Panel advertises DPCD backlight support, but "
>"VBT disagrees. If your backlight controls "
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/3] drm/i915/display: Check PSR parameter and flag only in state compute phase
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 way the CRTC state will also have
the correct state.
intel_psr_fastset_force() was already broken as
intel_psr_compute_config() was already only enabling PSR when
psr_global_enabled() and all other PSR requirements are met.
So some changes was required in this function, now it iterates over
all connectors, if it is a eDP connector and is active force a modeset
in the CRTC driving this connector, what will cause the new PSR state
to be set based on the debugfs flag.
v2:
- end connector iterator in error cases
Cc: Gwan-gyeong Mun
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_psr.c | 73 +---
1 file changed, 41 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 4e09ae61d4aa..02f74b0ddec1 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -91,19 +91,14 @@ static bool psr_global_enabled(struct drm_i915_private
*i915)
}
}
-static bool intel_psr2_enabled(struct drm_i915_private *dev_priv,
- const struct intel_crtc_state *crtc_state)
+static bool psr2_global_enabled(struct drm_i915_private *dev_priv)
{
- /* Cannot enable DSC and PSR2 simultaneously */
- drm_WARN_ON(_priv->drm, crtc_state->dsc.compression_enable &&
- crtc_state->has_psr2);
-
switch (dev_priv->psr.debug & I915_PSR_DEBUG_MODE_MASK) {
case I915_PSR_DEBUG_DISABLE:
case I915_PSR_DEBUG_FORCE_PSR1:
return false;
default:
- return crtc_state->has_psr2;
+ return true;
}
}
@@ -729,6 +724,11 @@ static bool intel_psr2_config_valid(struct intel_dp
*intel_dp,
return false;
}
+ if (!psr2_global_enabled(dev_priv)) {
+ drm_dbg_kms(_priv->drm, "PSR2 disabled by flag\n");
+ return false;
+ }
+
/*
* DSC and PSR2 cannot be enabled simultaneously. If a requested
* resolution requires DSC to be enabled, priority is given to DSC
@@ -817,8 +817,11 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
if (intel_dp != dev_priv->psr.dp)
return;
- if (!psr_global_enabled(dev_priv))
+ if (!psr_global_enabled(dev_priv)) {
+ drm_dbg_kms(_priv->drm, "PSR disabled by flag\n");
return;
+ }
+
/*
* HSW spec explicitly says PSR is tied to port A.
* BDW+ platforms have a instance of PSR registers per transcoder but
@@ -959,7 +962,7 @@ static void intel_psr_enable_locked(struct drm_i915_private
*dev_priv,
drm_WARN_ON(_priv->drm, dev_priv->psr.enabled);
- dev_priv->psr.psr2_enabled = intel_psr2_enabled(dev_priv, crtc_state);
+ dev_priv->psr.psr2_enabled = crtc_state->has_psr2;
dev_priv->psr.busy_frontbuffer_bits = 0;
dev_priv->psr.pipe = to_intel_crtc(crtc_state->uapi.crtc)->pipe;
dev_priv->psr.dc3co_enabled = !!crtc_state->dc3co_exitline;
@@ -1029,15 +1032,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
drm_WARN_ON(_priv->drm, dev_priv->drrs.dp);
mutex_lock(_priv->psr.lock);
-
- if (!psr_global_enabled(dev_priv)) {
- drm_dbg_kms(_priv->drm, "PSR disabled by flag\n");
- goto unlock;
- }
-
intel_psr_enable_locked(dev_priv, crtc_state, conn_state);
-
-unlock:
mutex_unlock(_priv->psr.lock);
}
@@ -1222,8 +1217,8 @@ void intel_psr_update(struct intel_dp *intel_dp,
mutex_lock(_priv->psr.lock);
- enable = crtc_state->has_psr && psr_global_enabled(dev_priv);
- psr2_enable = intel_psr2_enabled(dev_priv, crtc_state);
+ enable = crtc_state->has_psr;
+ psr2_enable = crtc_state->has_psr2;
if (enable == psr->enabled && psr2_enable == psr->psr2_enabled) {
/* Force a PSR exit when enabling CRC to avoid CRC timeouts */
@@ -1320,11 +1315,12 @@ static bool __psr_wait_for_idle_locked(struct
drm_i915_private *dev_priv)
static int intel_psr_fastset_force(struct drm_i915_private *dev_priv)
{
+ struct drm_connector_list_iter conn_iter;
struct drm_device *dev = _priv->drm;
struct drm_modeset_acquire_ctx ctx;
struct drm_atomic_state *state;
- struct intel_crtc *crtc;
- int err;
+ struct drm_connector *conn;
+ int err = 0;
state = drm_atomic_state_alloc(dev);
if (!state)
@@ -1334,25 +1330,38 @@ static int intel_psr_fastset_force(struct
drm_i915_private *dev_priv)
[Intel-gfx] [PATCH v5 1/3] drm/i915/display: Ignore IGNORE_PSR2_HW_TRACKING for platforms without sel fetch
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(-) diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index 8a9d0bdde1bf..4e09ae61d4aa 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -942,7 +942,7 @@ static void intel_psr_enable_source(struct intel_dp *intel_dp, intel_de_write(dev_priv, EXITLINE(cpu_transcoder), val); } - if (HAS_PSR_HW_TRACKING(dev_priv)) + if (HAS_PSR_HW_TRACKING(dev_priv) && HAS_PSR2_SEL_FETCH(dev_priv)) intel_de_rmw(dev_priv, CHICKEN_PAR1_1, IGNORE_PSR2_HW_TRACKING, dev_priv->psr.psr2_sel_fetch_enabled ? IGNORE_PSR2_HW_TRACKING : 0); -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 3/3] drm/i915/display: Program PSR2 selective fetch registers
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 visible in state
- removed calculations using plane damaged area in
intel_psr2_program_plane_sel_fetch()
v3:
- do not shift 16 positions the plane dst coordinates, only src is
shifted
v4:
- only setting PLANE_SEL_FETCH_CTL_ENABLE and MCURSOR_MODE in
PLANE_SEL_FETCH_CTL
v5:
- not masking bits for cursor
BSpec: 55229
Cc: Gwan-gyeong Mun
Cc: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display.c | 10 +-
drivers/gpu/drm/i915/display/intel_psr.c | 117 ++-
drivers/gpu/drm/i915/display/intel_psr.h | 10 +-
drivers/gpu/drm/i915/display/intel_sprite.c | 3 +
4 files changed, 131 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 907e1d155443..8b80e03694e2 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11872,6 +11872,9 @@ static void i9xx_update_cursor(struct intel_plane
*plane,
if (INTEL_GEN(dev_priv) >= 9)
skl_write_cursor_wm(plane, crtc_state);
+ if (!needs_modeset(crtc_state))
+ intel_psr2_program_plane_sel_fetch(plane, crtc_state,
plane_state, 0);
+
if (plane->cursor.base != base ||
plane->cursor.size != fbc_ctl ||
plane->cursor.cntl != cntl) {
@@ -12883,8 +12886,11 @@ static int intel_crtc_atomic_check(struct
intel_atomic_state *state,
}
- if (!mode_changed)
- intel_psr2_sel_fetch_update(state, crtc);
+ if (!mode_changed) {
+ ret = intel_psr2_sel_fetch_update(state, crtc);
+ if (ret)
+ return ret;
+ }
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 02f74b0ddec1..a591a475f148 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1166,6 +1166,38 @@ static void psr_force_hw_tracking_exit(struct
drm_i915_private *dev_priv)
intel_psr_exit(dev_priv);
}
+void intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
+ const struct intel_crtc_state
*crtc_state,
+ const struct intel_plane_state
*plane_state,
+ int color_plane)
+{
+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+ enum pipe pipe = plane->pipe;
+ u32 val;
+
+ if (!crtc_state->enable_psr2_sel_fetch)
+ return;
+
+ val = plane_state ? plane_state->ctl : 0;
+ val &= plane->id == PLANE_CURSOR ? val : PLANE_SEL_FETCH_CTL_ENABLE;
+ intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane->id), val);
+ if (!val || plane->id == PLANE_CURSOR)
+ return;
+
+ val = plane_state->uapi.dst.y1 << 16 | plane_state->uapi.dst.x1;
+ intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_POS(pipe, plane->id), val);
+
+ val = plane_state->color_plane[color_plane].y << 16;
+ val |= plane_state->color_plane[color_plane].x;
+ intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_OFFSET(pipe, plane->id),
+ val);
+
+ /* Sizes are 0 based */
+ val = ((drm_rect_height(_state->uapi.src) >> 16) - 1) << 16;
+ val |= (drm_rect_width(_state->uapi.src) >> 16) - 1;
+ intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_SIZE(pipe, plane->id), val);
+}
+
void intel_psr2_program_trans_man_trk_ctl(const struct intel_crtc_state
*crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -1180,16 +1212,91 @@ void intel_psr2_program_trans_man_trk_ctl(const struct
intel_crtc_state *crtc_st
crtc_state->psr2_man_track_ctl);
}
-void intel_psr2_sel_fetch_update(struct intel_atomic_state *state,
-struct intel_crtc *crtc)
+static void psr2_man_trk_ctl_calc(struct intel_crtc_state *crtc_state,
+ struct drm_rect *clip, bool full_update)
+{
+ u32 val = PSR2_MAN_TRK_CTL_ENABLE;
+
+ if (full_update) {
+ val |= PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
+ goto exit;
+ }
+
+ if (clip->y1 == -1)
+ goto exit;
+
+ val |= PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE;
+ val |= PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(clip->y1 / 4 + 1);
+ val |= PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(DIV_ROUND_UP(clip->y2, 4) +
1);
+exit:
+ crtc_state->psr2_man_track_ctl = val;
+}
+
+static void clip_area_update(struct drm_rect
[Intel-gfx] [PATCH v2 1/3] drm/i915: Reorder hpd init vs. display resume
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 interrupts). Which even makes sense
since we definitely need working HPD interrupts for MST sideband
during the display resume.
So let's nuke the open-coded call and move the intel_hpd_init()
call earlier. However we need to leave the poll_init_work stuff
behind after the display resume as that will trigger display
detection while we're resuming. We don't want that trampling over
the display resume process. To make this a bit more symmetric
we turn this into a intel_hpd_poll_{enable,disable}() pair.
So we end up with the following transformation:
intel_hpd_poll_init() -> intel_hpd_poll_enable()
lone intel_hpd_init() -> intel_hpd_init()+intel_hpd_poll_disable()
.hpd_irq_setup()+resume+intel_hpd_init() ->
intel_hpd_init()+resume+intel_hpd_poll_disable()
If we really would like to prevent all *long* HPD processing during
display resume we'd need some kind of software mechanism to simply
ignore all long HPDs. Currently we appear to have that just for
fbdev via ifbdev->hpd_suspended. Since we aren't exploding left and
right all the time I guess that's mostly sufficient.
For a bit of history on this, we first got a mechanism to block
hotplug processing during suspend in commit 15239099d7a7 ("drm/i915:
enable irqs earlier when resuming") on account of moving the irq enable
earlier. This then got removed in commit 50c3dc970a09 ("drm/fb-helper:
Fix hpd vs. initial config races") because the fdev initial config
got pushed to a later point. The second ad-hoc hpd_irq_setup() for
resume was added in commit 0e32b39ceed6 ("drm/i915: add DP 1.2 MST
support (v0.7)") to be able to do MST sideband during the resume.
And finally we got a partial resurrection of the hpd blocking
mechanism in commit e8a8fedd57fd ("drm/i915: Block fbdev HPD
processing during suspend"), but this time it only prevent fbdev
from handling hpd while resuming.
v2: Leave the poll_init_work behind
Cc: Lyude Paul
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 9 ++--
.../drm/i915/display/intel_display_power.c| 3 +-
drivers/gpu/drm/i915/display/intel_hotplug.c | 42 ++-
drivers/gpu/drm/i915/display/intel_hotplug.h | 3 +-
drivers/gpu/drm/i915/i915_drv.c | 23 --
5 files changed, 46 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 907e1d155443..0d5607ae97c4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5036,18 +5036,15 @@ void intel_finish_reset(struct drm_i915_private
*dev_priv)
intel_pps_unlock_regs_wa(dev_priv);
intel_modeset_init_hw(dev_priv);
intel_init_clock_gating(dev_priv);
-
- spin_lock_irq(_priv->irq_lock);
- if (dev_priv->display.hpd_irq_setup)
- dev_priv->display.hpd_irq_setup(dev_priv);
- spin_unlock_irq(_priv->irq_lock);
+ intel_hpd_init(dev_priv);
+ intel_hpd_poll_disable(dev_priv);
ret = __intel_display_resume(dev, state, ctx);
if (ret)
drm_err(_priv->drm,
"Restoring old state failed with %i\n", ret);
- intel_hpd_init(dev_priv);
+ intel_hpd_poll_disable(dev_priv);
}
drm_atomic_state_put(state);
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 7277e58b01f1..20ddc54298cb 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -1424,6 +1424,7 @@ static void vlv_display_power_well_init(struct
drm_i915_private *dev_priv)
return;
intel_hpd_init(dev_priv);
+ intel_hpd_poll_disable(dev_priv);
/* Re-enable the ADPA, if we have one */
for_each_intel_encoder(_priv->drm, encoder) {
@@ -1449,7 +1450,7 @@ static void vlv_display_power_well_deinit(struct
drm_i915_private *dev_priv)
/* Prevent us from re-enabling polling on accident in late suspend */
if (!dev_priv->drm.dev->power.is_suspended)
- intel_hpd_poll_init(dev_priv);
+ intel_hpd_poll_enable(dev_priv);
}
static void vlv_display_power_well_enable(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 5c58c1ed6493..30bd4c86d146 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -584,7 +584,7 @@
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Exclude low pages (128KiB) of stolen from use
== 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 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18648_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18648_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18648_full: ### IGT changes ### Possible regressions * igt@gem_exec_fence@parallel@bcs0: - shard-hsw: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/shard-hsw2/igt@gem_exec_fence@paral...@bcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/shard-hsw6/igt@gem_exec_fence@paral...@bcs0.html * igt@gem_exec_reloc@basic-many-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/shard-iclb2/igt@gem_exec_reloc@basic-many-act...@vcs1.html * igt@gen3_render_tiledy_blits: - shard-snb: NOTRUN -> [FAIL][4] +4 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/shard-snb7/igt@gen3_render_tiledy_blits.html Warnings * igt@gem_partial_pwrite_pread@writes-after-reads-display: - shard-hsw: [FAIL][5] ([i915#1888]) -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/shard-hsw2/igt@gem_partial_pwrite_pr...@writes-after-reads-display.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/shard-hsw6/igt@gem_partial_pwrite_pr...@writes-after-reads-display.html Known issues Here are the changes found in Patchwork_18648_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fence@parallel@vecs0: - shard-hsw: [PASS][7] -> [FAIL][8] ([i915#1888]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/shard-hsw2/igt@gem_exec_fence@paral...@vecs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/shard-hsw6/igt@gem_exec_fence@paral...@vecs0.html * igt@gem_userptr_blits@unsync-unmap-cycles: - shard-skl: [PASS][9] -> [TIMEOUT][10] ([i915#2424]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/shard-skl6/igt@gem_userptr_bl...@unsync-unmap-cycles.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/shard-skl2/igt@gem_userptr_bl...@unsync-unmap-cycles.html * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/shard-kbl6/igt@gem_workarou...@suspend-resume-fd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/shard-kbl7/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_module_load@reload: - shard-tglb: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/shard-tglb6/igt@i915_module_l...@reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/shard-tglb3/igt@i915_module_l...@reload.html * igt@kms_big_fb@y-tiled-8bpp-rotate-0: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#1635] / [i915#1982]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/shard-apl8/igt@kms_big...@y-tiled-8bpp-rotate-0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/shard-apl8/igt@kms_big...@y-tiled-8bpp-rotate-0.html * igt@kms_cursor_edge_walk@pipe-a-256x256-right-edge: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +7 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/shard-skl1/igt@kms_cursor_edge_w...@pipe-a-256x256-right-edge.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/shard-skl5/igt@kms_cursor_edge_w...@pipe-a-256x256-right-edge.html * igt@kms_cursor_legacy@cursor-vs-flip-toggle: - shard-hsw: [PASS][19] -> [FAIL][20] ([i915#2370]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/shard-hsw4/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/shard-hsw1/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html * igt@kms_flip@2x-flip-vs-expired-vblank@ac-hdmi-a1-hdmi-a2: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#79]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/shard-glk4/igt@kms_flip@2x-flip-vs-expired-vbl...@ac-hdmi-a1-hdmi-a2.html [22]:
[Intel-gfx] [PATCH v3 6/6] drm/i915: Switch to LTTPR non-transparent mode link training
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 it provides a way to narrow down the reason for a
link training failure to a given link segment. Non-transparent mode is
probably also the mode that was tested the most by the industry.
The changes in this patchset:
- Pass the DP PHY that is currently link trained to all LT helpers, so
that these can access the correct LTTPR/DPRX DPCD registers.
- During LT take into account the LTTPR common lane rate/count and the
per LTTPR-PHY vswing/pre-emph limits.
- Switch to LTTPR non-transparent LT mode and train each link segment
according to the sequence in DP Standard v2.0 (complete CR/EQ for
each segment before continuing with the next segment).
v2:
- Switch to non-transparent mode during connector detection, which is
required before reading the per-PHY LTTPR capabilities.
- Move the DP_PHY_LTTPR() macro to drm_dp_helper.h (Ville)
- Use the new drm_dp_dpcd_read_phy_link_status() instead of adding the
same logic to intel_dp_get_link_status(). (Ville)
- Make intel_dp_lttpr_phy_caps() return a pointer to the whole array
instead of a pointer to its first element. (Ville)
- Add the intel_dp_phy_is_downstream_of_source() helper. (Ville)
- Add a code comment about the disable->enable quirk of
non-transparent mode.
- Add the intel_dp_training_pattern_set_reg() helper.
- Fix checkpatch/sparse warns.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 28 +-
drivers/gpu/drm/i915/display/intel_dp.h | 2 -
.../drm/i915/display/intel_dp_link_training.c | 362 +++---
.../drm/i915/display/intel_dp_link_training.h | 1 +
5 files changed, 321 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index c05b466a0210..df99fdc323e4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1298,6 +1298,7 @@ struct intel_dp {
u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE];
u8 lttpr_common_caps[DP_LTTPR_COMMON_CAP_SIZE];
+ u8 lttpr_phy_caps[DP_MAX_LTTPR_COUNT][DP_LTTPR_PHY_CAP_SIZE];
u8 fec_capable;
/* source rates */
int num_source_rates;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2e4786df8d51..8e437acff03d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -161,6 +161,7 @@ static void intel_dp_set_sink_rates(struct intel_dp
*intel_dp)
162000, 27, 54, 81
};
int i, max_rate;
+ int max_lttpr_rate;
if (drm_dp_has_quirk(_dp->desc, 0,
DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS)) {
@@ -174,6 +175,9 @@ static void intel_dp_set_sink_rates(struct intel_dp
*intel_dp)
}
max_rate =
drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
+ max_lttpr_rate =
drm_dp_lttpr_max_link_rate(intel_dp->lttpr_common_caps);
+ if (max_lttpr_rate)
+ max_rate = min(max_rate, max_lttpr_rate);
for (i = 0; i < ARRAY_SIZE(dp_rates); i++) {
if (dp_rates[i] > max_rate)
@@ -219,6 +223,10 @@ static int intel_dp_max_common_lane_count(struct intel_dp
*intel_dp)
int source_max = dig_port->max_lanes;
int sink_max = drm_dp_max_lane_count(intel_dp->dpcd);
int fia_max = intel_tc_port_fia_max_lane_count(dig_port);
+ int lttpr_max =
drm_dp_lttpr_max_lane_count(intel_dp->lttpr_common_caps);
+
+ if (lttpr_max)
+ sink_max = min(sink_max, lttpr_max);
return min3(source_max, sink_max, fia_max);
}
@@ -4206,17 +4214,6 @@ static void chv_dp_post_pll_disable(struct
intel_atomic_state *state,
chv_phy_post_pll_disable(encoder, old_crtc_state);
}
-/*
- * Fetch AUX CH registers 0x202 - 0x207 which contain
- * link status information
- */
-bool
-intel_dp_get_link_status(struct intel_dp *intel_dp, u8
link_status[DP_LINK_STATUS_SIZE])
-{
- return drm_dp_dpcd_read(_dp->aux, DP_LANE0_1_STATUS, link_status,
- DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
-}
-
static u8 intel_dp_voltage_max_2(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state)
{
@@ -5619,13 +5616,15 @@ static void intel_dp_process_phy_request(struct
intel_dp *intel_dp,
_dp->compliance.test_data.phytest;
u8 link_status[DP_LINK_STATUS_SIZE];
- if
[Intel-gfx] [PATCH v3 2/6] drm/i915: Simplify the link training functions
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 are exported or that can use
a better description about which part of the LT sequence they
implement.
v2: (Ville)
- Unexport/inline intel_dp_set_idle_link_train()
- Make the documentation of
intel_dp_prepare_link_train()/intel_dp_stop_link_train() more accurate
wrt. HW specific details.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 7 --
drivers/gpu/drm/i915/display/intel_dp.h | 2 -
.../drm/i915/display/intel_dp_link_training.c | 100 ++
3 files changed, 79 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 8124c3d551f5..046958bf3707 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4599,13 +4599,6 @@ intel_dp_program_link_training_pattern(struct intel_dp
*intel_dp,
intel_dp->set_link_train(intel_dp, crtc_state, dp_train_pat);
}
-void intel_dp_set_idle_link_train(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state)
-{
- if (intel_dp->set_idle_link_train)
- intel_dp->set_idle_link_train(intel_dp, crtc_state);
-}
-
static void
intel_dp_link_down(struct intel_encoder *encoder,
const struct intel_crtc_state *old_crtc_state)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 6c201377fdc0..11d05ca74dd4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -97,8 +97,6 @@ intel_dp_program_link_training_pattern(struct intel_dp
*intel_dp,
void
intel_dp_set_signal_levels(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state);
-void intel_dp_set_idle_link_train(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state);
void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
u8 *link_bw, u8 *rate_select);
bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index b2ff88a152cd..51d1316c37d5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -153,15 +153,15 @@ static bool intel_dp_link_max_vswing_reached(struct
intel_dp *intel_dp,
return true;
}
-/* Enable corresponding port and start training pattern 1 */
+/*
+ * Prepare link training by configuring the link parameters. On DDI platforms
+ * also enable the port here.
+ */
static bool
-intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state)
+intel_dp_prepare_link_train(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- u8 voltage;
- int voltage_tries, cr_tries, max_cr_tries;
- bool max_vswing_reached = false;
u8 link_config[2];
u8 link_bw, rate_select;
@@ -196,6 +196,19 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp,
intel_dp->DP |= DP_PORT_EN;
+ return true;
+}
+
+/* Perform the link training clock recovery phase using training pattern 1. */
+static bool
+intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ u8 voltage;
+ int voltage_tries, cr_tries, max_cr_tries;
+ bool max_vswing_reached = false;
+
/* clock recovery */
if (!intel_dp_reset_link_train(intel_dp, crtc_state,
DP_TRAINING_PATTERN_1 |
@@ -318,6 +331,10 @@ static u32 intel_dp_training_pattern(struct intel_dp
*intel_dp,
return DP_TRAINING_PATTERN_2;
}
+/*
+ * Perform the link training channel equalization phase using one of training
+ * pattern 2, 3 or 4 depending on the source and sink capabilities.
+ */
static bool
intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp,
const struct intel_crtc_state
*crtc_state)
@@ -383,12 +400,28 @@ intel_dp_link_training_channel_equalization(struct
intel_dp *intel_dp,
"Channel equalization failed 5 times\n");
}
- intel_dp_set_idle_link_train(intel_dp,
[Intel-gfx] [PATCH v3 4/6] drm/dp: Add LTTPR helpers
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 convert LTTPR to DPRX link status format. (Ville)
Cc: dri-de...@lists.freedesktop.org
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_helper.c | 232 +++-
include/drm/drm_dp_helper.h | 62 +
2 files changed, 290 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 478dd51f738d..79732402336d 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -150,11 +150,8 @@ void drm_dp_link_train_clock_recovery_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
}
EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
-void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+static void __drm_dp_link_train_channel_eq_delay(unsigned long rd_interval)
{
- unsigned long rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
-DP_TRAINING_AUX_RD_MASK;
-
if (rd_interval > 4)
DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
rd_interval);
@@ -166,8 +163,35 @@ void drm_dp_link_train_channel_eq_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
usleep_range(rd_interval, rd_interval * 2);
}
+
+void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ __drm_dp_link_train_channel_eq_delay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+DP_TRAINING_AUX_RD_MASK);
+}
EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
+void drm_dp_lttpr_link_train_clock_recovery_delay(void)
+{
+ usleep_range(100, 200);
+}
+EXPORT_SYMBOL(drm_dp_lttpr_link_train_clock_recovery_delay);
+
+static u8 dp_lttpr_phy_cap(const u8 phy_cap[DP_LTTPR_PHY_CAP_SIZE], int r)
+{
+ return phy_cap[r - DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1];
+}
+
+void drm_dp_lttpr_link_train_channel_eq_delay(const u8
phy_cap[DP_LTTPR_PHY_CAP_SIZE])
+{
+ u8 interval = dp_lttpr_phy_cap(phy_cap,
+
DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1) &
+ DP_TRAINING_AUX_RD_MASK;
+
+ __drm_dp_link_train_channel_eq_delay(interval);
+}
+EXPORT_SYMBOL(drm_dp_lttpr_link_train_channel_eq_delay);
+
u8 drm_dp_link_rate_to_bw_code(int link_rate)
{
/* Spec says link_bw = link_rate / 0.27Gbps */
@@ -363,6 +387,59 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
}
EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
+/**
+ * drm_dp_dpcd_read_phy_link_status - get the link status information for a DP
PHY
+ * @aux: DisplayPort AUX channel
+ * @dp_phy: the DP PHY to get the link status for
+ * @link_status: buffer to return the status in
+ *
+ * Fetch the AUX DPCD registers for the DPRX or an LTTPR PHY link status. The
+ * layout of the returned @link_status matches the DPCD register layout of the
+ * DPRX PHY link status.
+ *
+ * Returns 0 if the information was read successfully or a negative error code
+ * on failure.
+ */
+int drm_dp_dpcd_read_phy_link_status(struct drm_dp_aux *aux,
+enum drm_dp_phy dp_phy,
+u8 link_status[DP_LINK_STATUS_SIZE])
+{
+ int ret;
+
+ if (dp_phy == DP_PHY_DPRX) {
+ ret = drm_dp_dpcd_read(aux,
+ DP_LANE0_1_STATUS,
+ link_status,
+ DP_LINK_STATUS_SIZE);
+
+ if (ret < 0)
+ return ret;
+
+ WARN_ON(ret != DP_LINK_STATUS_SIZE);
+
+ return 0;
+ }
+
+ ret = drm_dp_dpcd_read(aux,
+ DP_LANE0_1_STATUS_PHY_REPEATER(dp_phy),
+ link_status,
+ DP_LINK_STATUS_SIZE - 1);
+
+ if (ret < 0)
+ return ret;
+
+ WARN_ON(ret != DP_LINK_STATUS_SIZE - 1);
+
+ /* Convert the LTTPR to the sink PHY link status layout */
+ memmove(_status[DP_SINK_STATUS - DP_LANE0_1_STATUS + 1],
+ _status[DP_SINK_STATUS - DP_LANE0_1_STATUS],
+ DP_LINK_STATUS_SIZE - (DP_SINK_STATUS - DP_LANE0_1_STATUS) - 1);
+ link_status[DP_SINK_STATUS - DP_LANE0_1_STATUS] = 0;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_dpcd_read_phy_link_status);
+
static bool is_edid_digital_input_dp(const struct edid *edid)
{
return edid && edid->revision >= 4 &&
@@ -2098,6 +2175,153 @@ int drm_dp_dsc_sink_supported_input_bpcs(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_S
}
EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
+/**
+ *
[Intel-gfx] [PATCH v3 5/6] drm/i915: Switch to LTTPR transparent mode link training
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). I haven't seen this happening, but let's follow
the DP Standard.
v2:
- Add a code comment about the explicit disabling of non-transparent
mode.
v3:
- Move check to prevent initing LTTPRs on eDP to init_dp_lttpr_init().
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 2 +
.../drm/i915/display/intel_dp_link_training.c | 55 +++
.../drm/i915/display/intel_dp_link_training.h | 2 +
4 files changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 65ae2070576f..c05b466a0210 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1297,6 +1297,7 @@ struct intel_dp {
u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE];
+ u8 lttpr_common_caps[DP_LTTPR_COMMON_CAP_SIZE];
u8 fec_capable;
/* source rates */
int num_source_rates;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 046958bf3707..2e4786df8d51 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4817,6 +4817,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
{
int ret;
+ intel_dp_lttpr_init(intel_dp);
+
if (drm_dp_read_dpcd_caps(_dp->aux, intel_dp->dpcd))
return false;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 71a8c9a546a3..a19f0fd50c69 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -34,6 +34,55 @@ intel_dp_dump_link_status(const u8
link_status[DP_LINK_STATUS_SIZE])
link_status[3], link_status[4], link_status[5]);
}
+static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp)
+{
+ if (drm_dp_read_lttpr_common_caps(_dp->aux,
+ intel_dp->lttpr_common_caps) < 0) {
+ memset(intel_dp->lttpr_common_caps, 0,
+ sizeof(intel_dp->lttpr_common_caps));
+ return false;
+ }
+
+ drm_dbg_kms(_to_i915(intel_dp)->drm,
+ "LTTPR common capabilities: %*ph\n",
+ (int)sizeof(intel_dp->lttpr_common_caps),
+ intel_dp->lttpr_common_caps);
+
+ return true;
+}
+
+static bool
+intel_dp_set_lttpr_transparent_mode(struct intel_dp *intel_dp, bool enable)
+{
+ u8 val = enable ? DP_PHY_REPEATER_MODE_TRANSPARENT :
+ DP_PHY_REPEATER_MODE_NON_TRANSPARENT;
+
+ return drm_dp_dpcd_write(_dp->aux, DP_PHY_REPEATER_MODE, , 1)
== 1;
+}
+
+/**
+ * intel_dp_lttpr_init - detect LTTPRs and init the LTTPR link training mode
+ * @intel_dp: Intel DP struct
+ *
+ * Read the LTTPR common capabilities and switch to transparent link training
+ * mode.
+ */
+int intel_dp_lttpr_init(struct intel_dp *intel_dp)
+{
+ if (intel_dp_is_edp(intel_dp))
+ return 0;
+
+ intel_dp_read_lttpr_common_caps(intel_dp);
+
+ /*
+* See DP Standard v2.0 3.6.6.1. about the explicit disabling of
+* non-transparent mode.
+*/
+ intel_dp_set_lttpr_transparent_mode(intel_dp, true);
+
+ return 0;
+}
+
static u8 dp_voltage_max(u8 preemph)
{
switch (preemph & DP_TRAIN_PRE_EMPHASIS_MASK) {
@@ -492,6 +541,12 @@ static void
intel_dp_schedule_fallback_link_training(struct intel_dp *intel_dp,
void intel_dp_start_link_train(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state)
{
+ /*
+* TODO: Reiniting LTTPRs here won't be needed once proper connector
+* HW state readout is added.
+*/
+ intel_dp_lttpr_init(intel_dp);
+
if (!intel_dp_link_train(intel_dp, crtc_state))
intel_dp_schedule_fallback_link_training(intel_dp, crtc_state);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
index bf9474e41aed..b3fb1d125b9b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
@@ -11,6 +11,8 @@
struct intel_crtc_state;
struct intel_dp;
+int intel_dp_lttpr_init(struct intel_dp *intel_dp);
+
void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
[Intel-gfx] [PATCH v3 0/6] rm/i915: Add support for LTTPR non-transparent link training mode
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 the link training functions drm/i915: Factor out a helper to disable the DPCD training pattern drm/dp: Add LTTPR helpers drm/i915: Switch to LTTPR transparent mode link training drm/i915: Switch to LTTPR non-transparent mode link training drivers/gpu/drm/drm_dp_helper.c | 232 +++- drivers/gpu/drm/i915/display/intel_ddi.c | 3 +- .../drm/i915/display/intel_display_types.h| 2 + drivers/gpu/drm/i915/display/intel_dp.c | 47 +- drivers/gpu/drm/i915/display/intel_dp.h | 4 - .../drm/i915/display/intel_dp_link_training.c | 502 +++--- .../drm/i915/display/intel_dp_link_training.h | 9 + include/drm/drm_dp_helper.h | 62 +++ 8 files changed, 755 insertions(+), 106 deletions(-) -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/6] drm/i915: Fix DP link training pattern mask
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 masked out is the
scrambling disable flag, which is or'd to the mask later based on the
training pattern.
v2:
- Use a helper instead of open-coding the masking. (Ville)
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +--
drivers/gpu/drm/i915/display/intel_dp.c | 10 +-
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp_link_training.h | 6 ++
4 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 6f7bd67732f2..d21b2ccea182 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4259,13 +4259,12 @@ static void intel_ddi_set_link_train(struct intel_dp
*intel_dp,
{
struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- u8 train_pat_mask = drm_dp_training_pattern_mask(intel_dp->dpcd);
u32 temp;
temp = intel_de_read(dev_priv, dp_tp_ctl_reg(encoder, crtc_state));
temp &= ~DP_TP_CTL_LINK_TRAIN_MASK;
- switch (dp_train_pat & train_pat_mask) {
+ switch (intel_dp_training_pattern_symbol(dp_train_pat)) {
case DP_TRAINING_PATTERN_DISABLE:
temp |= DP_TP_CTL_LINK_TRAIN_NORMAL;
break;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 239016dcd544..8124c3d551f5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3856,7 +3856,7 @@ cpt_set_link_train(struct intel_dp *intel_dp,
*DP &= ~DP_LINK_TRAIN_MASK_CPT;
- switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
+ switch (intel_dp_training_pattern_symbol(dp_train_pat)) {
case DP_TRAINING_PATTERN_DISABLE:
*DP |= DP_LINK_TRAIN_OFF_CPT;
break;
@@ -3887,7 +3887,7 @@ g4x_set_link_train(struct intel_dp *intel_dp,
*DP &= ~DP_LINK_TRAIN_MASK;
- switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
+ switch (intel_dp_training_pattern_symbol(dp_train_pat)) {
case DP_TRAINING_PATTERN_DISABLE:
*DP |= DP_LINK_TRAIN_OFF;
break;
@@ -4589,12 +4589,12 @@ intel_dp_program_link_training_pattern(struct intel_dp
*intel_dp,
u8 dp_train_pat)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- u8 train_pat_mask = drm_dp_training_pattern_mask(intel_dp->dpcd);
- if (dp_train_pat & train_pat_mask)
+ if ((intel_dp_training_pattern_symbol(dp_train_pat)) !=
+ DP_TRAINING_PATTERN_DISABLE)
drm_dbg_kms(_priv->drm,
"Using DP training pattern TPS%d\n",
- dp_train_pat & train_pat_mask);
+ intel_dp_training_pattern_symbol(dp_train_pat));
intel_dp->set_link_train(intel_dp, crtc_state, dp_train_pat);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 51e8d46d9b7f..b2ff88a152cd 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -100,7 +100,7 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
dp_train_pat);
buf[0] = dp_train_pat;
- if ((dp_train_pat & DP_TRAINING_PATTERN_MASK) ==
+ if (intel_dp_training_pattern_symbol(dp_train_pat) ==
DP_TRAINING_PATTERN_DISABLE) {
/* don't write DP_TRAINING_LANEx_SET on disable */
len = 1;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
index 648a6d1f9fa2..bf9474e41aed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
@@ -19,4 +19,10 @@ void intel_dp_start_link_train(struct intel_dp *intel_dp,
void intel_dp_stop_link_train(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state);
+/* Get the TPSx symbol type of the value programmed to DP_TRAINING_PATTERN_SET
*/
+static inline u8 intel_dp_training_pattern_symbol(u8 pattern)
+{
+ return pattern & ~DP_LINK_SCRAMBLING_DISABLE;
+}
+
#endif /* __INTEL_DP_LINK_TRAINING_H__ */
--
2.25.1
___
Intel-gfx mailing list
[Intel-gfx] [PATCH v3 3/6] drm/i915: Factor out a helper to disable the DPCD training pattern
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 from
intel_dp_set_link_train() to intel_dp_stop_link_train(), since the
latter is the only user of this.
v2:
- Move the disable-link-training logic to intel_dp_stop_link_train()
(Ville)
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_dp_link_training.c | 33 ++-
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 51d1316c37d5..71a8c9a546a3 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -94,26 +94,18 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
u8 dp_train_pat)
{
u8 buf[sizeof(intel_dp->train_set) + 1];
- int ret, len;
+ int len;
intel_dp_program_link_training_pattern(intel_dp, crtc_state,
dp_train_pat);
buf[0] = dp_train_pat;
- if (intel_dp_training_pattern_symbol(dp_train_pat) ==
- DP_TRAINING_PATTERN_DISABLE) {
- /* don't write DP_TRAINING_LANEx_SET on disable */
- len = 1;
- } else {
- /* DP_TRAINING_LANEx_SET follow DP_TRAINING_PATTERN_SET */
- memcpy(buf + 1, intel_dp->train_set, crtc_state->lane_count);
- len = crtc_state->lane_count + 1;
- }
+ /* DP_TRAINING_LANEx_SET follow DP_TRAINING_PATTERN_SET */
+ memcpy(buf + 1, intel_dp->train_set, crtc_state->lane_count);
+ len = crtc_state->lane_count + 1;
- ret = drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET,
- buf, len);
-
- return ret == len;
+ return drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET,
+buf, len) == len;
}
static bool
@@ -406,6 +398,13 @@ intel_dp_link_training_channel_equalization(struct
intel_dp *intel_dp,
return channel_eq;
}
+static bool intel_dp_disable_dpcd_training_pattern(struct intel_dp *intel_dp)
+{
+ u8 val = DP_TRAINING_PATTERN_DISABLE;
+
+ return drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET, ,
1) == 1;
+}
+
/**
* intel_dp_stop_link_train - stop link training
* @intel_dp: DP struct
@@ -427,8 +426,10 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp,
{
intel_dp->link_trained = true;
- intel_dp_set_link_train(intel_dp, crtc_state,
- DP_TRAINING_PATTERN_DISABLE);
+ intel_dp_program_link_training_pattern(intel_dp,
+ crtc_state,
+ DP_TRAINING_PATTERN_DISABLE);
+ intel_dp_disable_dpcd_training_pattern(intel_dp);
}
static bool
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/8] drm/i915/dg1: add more PCI ids
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 Fast mode used, each commit won't be checked separately. - +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block something wrong with sparse in CI? $ ../maintainer-tools/dim sparse drm-tip/drm-tip Sparse version: v0.6.2 Commit: drm/i915/dg1: add more PCI ids Okay! Commit: drm/i915/dg1: Initialize RAWCLK properly Okay! Commit: drm/i915/dg1: Define MOCS table for DG1 Okay! Commit: drm/i915/dg1: Increase mmio size to 4MB Okay! Commit: drm/i915/dg1: gmbus pin mapping Okay! Commit: drm/i915/dg1: Don't program PHY_MISC for PHY-C and PHY-D Okay! Commit: drm/i915/dg1: Update comp master/slave relationships for PHYs Okay! Commit: drm/i915/dg1: provide port/phy mapping for vbt Okay! And also with tip of tree with sparse: $ ../maintainer-tools/dim sparse drm-tip/drm-tip Sparse version: v0.6.2-218-gc0e96d6d Commit: drm/i915/dg1: add more PCI ids Okay! Commit: drm/i915/dg1: Initialize RAWCLK properly Okay! Commit: drm/i915/dg1: Define MOCS table for DG1 Okay! Commit: drm/i915/dg1: Increase mmio size to 4MB Okay! Commit: drm/i915/dg1: gmbus pin mapping Okay! Commit: drm/i915/dg1: Don't program PHY_MISC for PHY-C and PHY-D Okay! Commit: drm/i915/dg1: Update comp master/slave relationships for PHYs Okay! Commit: drm/i915/dg1: provide port/phy mapping for vbt Okay! Lucas De Marchi +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Exclude low pages (128KiB) of stolen from use
== 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
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/index.html
Known issues
Here are the changes found in Patchwork_18648 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-u2: [PASS][3] -> [DMESG-FAIL][4] ([i915#2373])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
* igt@vgem_basic@unload:
- fi-skl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#2203])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-skl-guc/igt@vgem_ba...@unload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/fi-skl-guc/igt@vgem_ba...@unload.html
- fi-kbl-x1275: [PASS][7] -> [DMESG-WARN][8] ([i915#95])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-kbl-x1275/igt@vgem_ba...@unload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/fi-kbl-x1275/igt@vgem_ba...@unload.html
Possible fixes
* {igt@core_hotunplug@unbind-rebind}:
- fi-blb-e6850: [INCOMPLETE][9] ([i915#2540]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html
* igt@i915_pm_rpm@module-reload:
- fi-apl-guc: [DMESG-WARN][11] ([i915#1635] / [i915#1982]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-apl-guc/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/fi-apl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +4 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18648/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#2373]: https://gitlab.freedesktop.org/drm/intel/issues/2373
[i915#2540]: https://gitlab.freedesktop.org/drm/intel/issues/2540
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (45
Re: [Intel-gfx] [PATCH] drm/i915: Exclude low pages (128KiB) of stolen from use
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 own use. The value of 128KiB was found > by empirical measurement on gen9. Probably should double it to 256K, just to be on the safe side? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Exclude low pages (128KiB) of stolen from use
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 empirical measurement on gen9.
Signed-off-by: Chris Wilson
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 0be5e8683337..c0cc2a972a11 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -53,8 +53,9 @@ int i915_gem_stolen_insert_node(struct drm_i915_private *i915,
struct drm_mm_node *node, u64 size,
unsigned alignment)
{
- return i915_gem_stolen_insert_node_in_range(i915, node, size,
- alignment, 0, U64_MAX);
+ return i915_gem_stolen_insert_node_in_range(i915, node,
+ size, alignment,
+ SZ_128K, U64_MAX);
}
void i915_gem_stolen_remove_node(struct drm_i915_private *i915,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/jsl: Split EHL/JSL platform info and PCI ids
== 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
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_18645_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18645_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_18645_full:
### IGT changes ###
Warnings
* igt@gem_partial_pwrite_pread@writes-after-reads-display:
- shard-hsw: [FAIL][1] ([i915#1888]) -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-hsw6/igt@gem_partial_pwrite_pr...@writes-after-reads-display.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/shard-hsw8/igt@gem_partial_pwrite_pr...@writes-after-reads-display.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_async_flips@alternate-sync-async-flip}:
- shard-skl: NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/shard-skl8/igt@kms_async_fl...@alternate-sync-async-flip.html
Known issues
Here are the changes found in Patchwork_18645_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_whisper@basic-queues-forked-all:
- shard-glk: [PASS][4] -> [DMESG-WARN][5] ([i915#118] / [i915#95])
+1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-glk7/igt@gem_exec_whis...@basic-queues-forked-all.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/shard-glk3/igt@gem_exec_whis...@basic-queues-forked-all.html
* igt@gem_fenced_exec_thrash@no-spare-fences:
- shard-snb: [PASS][6] -> [INCOMPLETE][7] ([i915#82])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-snb2/igt@gem_fenced_exec_thr...@no-spare-fences.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/shard-snb6/igt@gem_fenced_exec_thr...@no-spare-fences.html
* igt@gem_userptr_blits@sync-unmap-cycles:
- shard-skl: [PASS][8] -> [TIMEOUT][9] ([i915#2424])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-skl8/igt@gem_userptr_bl...@sync-unmap-cycles.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/shard-skl4/igt@gem_userptr_bl...@sync-unmap-cycles.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-skl: [PASS][10] -> [INCOMPLETE][11] ([i915#300])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-suspend.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/shard-skl10/igt@kms_cursor_...@pipe-b-cursor-suspend.html
* igt@kms_cursor_edge_walk@pipe-a-256x256-right-edge:
- shard-skl: [PASS][12] -> [DMESG-WARN][13] ([i915#1982]) +7
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-skl9/igt@kms_cursor_edge_w...@pipe-a-256x256-right-edge.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/shard-skl3/igt@kms_cursor_edge_w...@pipe-a-256x256-right-edge.html
* igt@kms_cursor_legacy@cursor-vs-flip-varying-size:
- shard-hsw: [PASS][14] -> [FAIL][15] ([i915#2370])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-hsw5/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/shard-hsw8/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html
* igt@kms_frontbuffer_tracking@fbc-rgb565-draw-render:
- shard-tglb: [PASS][16] -> [DMESG-WARN][17] ([i915#1982]) +3
similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-tglb1/igt@kms_frontbuffer_track...@fbc-rgb565-draw-render.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/shard-tglb5/igt@kms_frontbuffer_track...@fbc-rgb565-draw-render.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-kbl: [PASS][18] -> [DMESG-WARN][19] ([i915#180]) +8
similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-kbl2/igt@kms_...@bpc-switch-suspend.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/shard-kbl2/igt@kms_...@bpc-switch-suspend.html
* igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#109441]) +2 similar
issues
[20]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/fb-helper: Add locking to sysrq handling
== 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
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18647/index.html
Known issues
Here are the changes found in Patchwork_18647 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-tgl-u2: [PASS][1] -> [DMESG-WARN][2] ([i915#1982] /
[k.org#205379])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-tgl-u2/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18647/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18647/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18647/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
- fi-bsw-kefka: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18647/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-apl-guc: [DMESG-WARN][9] ([i915#1635] / [i915#1982]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-apl-guc/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18647/fi-apl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18647/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18647/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18647/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][17] ([i915#62]) -> [DMESG-FAIL][18]
([i915#62] / [i915#95])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18647/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
- fi-skl-6700k2: [DMESG-WARN][19] ([i915#2203]) -> [INCOMPLETE][20]
([i915#151] / [i915#2203])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-skl-6700k2/igt@i915_pm_...@module-reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18647/fi-skl-6700k2/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#62] / [i915#92]) +3 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18647/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[24]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Ignore dt==0 for reporting underflows
== 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
---
**FAILURE**
Serious unknown changes coming with Patchwork_18643_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18643_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_18643_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_reloc@basic-many-active@vcs0:
- shard-glk: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-glk5/igt@gem_exec_reloc@basic-many-act...@vcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/shard-glk2/igt@gem_exec_reloc@basic-many-act...@vcs0.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_async_flips@alternate-sync-async-flip}:
- shard-skl: NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/shard-skl1/igt@kms_async_fl...@alternate-sync-async-flip.html
Known issues
Here are the changes found in Patchwork_18643_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@in-flight-contexts-1us:
- shard-skl: [PASS][4] -> [INCOMPLETE][5] ([i915#1909])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-skl10/igt@gem_...@in-flight-contexts-1us.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/shard-skl7/igt@gem_...@in-flight-contexts-1us.html
* igt@gem_exec_whisper@basic-queues-forked-all:
- shard-glk: [PASS][6] -> [DMESG-WARN][7] ([i915#118] / [i915#95])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-glk7/igt@gem_exec_whis...@basic-queues-forked-all.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/shard-glk4/igt@gem_exec_whis...@basic-queues-forked-all.html
* igt@gem_userptr_blits@unsync-unmap-cycles:
- shard-skl: [PASS][8] -> [TIMEOUT][9] ([i915#2424])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-skl4/igt@gem_userptr_bl...@unsync-unmap-cycles.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/shard-skl1/igt@gem_userptr_bl...@unsync-unmap-cycles.html
* igt@gem_workarounds@suspend-resume:
- shard-skl: [PASS][10] -> [INCOMPLETE][11] ([i915#198])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-skl2/igt@gem_workarou...@suspend-resume.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/shard-skl9/igt@gem_workarou...@suspend-resume.html
* igt@i915_module_load@reload-with-fault-injection:
- shard-skl: [PASS][12] -> [DMESG-WARN][13] ([i915#1982]) +8
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-skl8/igt@i915_module_l...@reload-with-fault-injection.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/shard-skl2/igt@i915_module_l...@reload-with-fault-injection.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-skl: [PASS][14] -> [INCOMPLETE][15] ([i915#300])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-skl9/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/shard-skl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html
* igt@kms_flip@flip-vs-absolute-wf_vblank@a-dp1:
- shard-kbl: [PASS][16] -> [DMESG-WARN][17] ([i915#1982])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-kbl7/igt@kms_flip@flip-vs-absolute-wf_vbl...@a-dp1.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/shard-kbl4/igt@kms_flip@flip-vs-absolute-wf_vbl...@a-dp1.html
* igt@kms_flip@flip-vs-expired-vblank@a-edp1:
- shard-skl: [PASS][18] -> [DMESG-FAIL][19] ([i915#1982] /
[i915#79])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-skl5/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/shard-skl5/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html
* igt@kms_flip@flip-vs-expired-vblank@c-edp1:
- shard-skl: [PASS][20] -> [FAIL][21] ([i915#79]) +1 similar issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/shard-skl5/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html
[21]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/fb-helper: Add locking to sysrq handling
== 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 Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 45 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init
== 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
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/index.html
Known issues
Here are the changes found in Patchwork_18646 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][1] -> [DMESG-WARN][2] ([i915#62] / [i915#92] /
[i915#95])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
* igt@vgem_basic@unload:
- fi-skl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#2203])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-skl-guc/igt@vgem_ba...@unload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-skl-guc/igt@vgem_ba...@unload.html
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-apl-guc: [DMESG-WARN][9] ([i915#1635] / [i915#1982]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-apl-guc/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-apl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][15] ([i915#62]) -> [DMESG-FAIL][16]
([i915#62] / [i915#95])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +4 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
[Intel-gfx] [PATCH] drm/fb-helper: Add locking to sysrq handling
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
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 26 +-
1 file changed, 5 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 8697554ccd41..c2f72bb6afb1 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -281,18 +281,12 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
drm_fb_helper *fb_helper)
EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode_unlocked);
#ifdef CONFIG_MAGIC_SYSRQ
-/*
- * restore fbcon display for all kms driver's using this helper, used for sysrq
- * and panic handling.
- */
-static bool drm_fb_helper_force_kernel_mode(void)
+/* emergency restore, don't bother with error reporting */
+static void drm_fb_helper_restore_work_fn(struct work_struct *ignored)
{
- bool ret, error = false;
struct drm_fb_helper *helper;
- if (list_empty(_fb_helper_list))
- return false;
-
+ mutex_lock(_fb_helper_lock);
list_for_each_entry(helper, _fb_helper_list, kernel_fb_list) {
struct drm_device *dev = helper->dev;
@@ -300,22 +294,12 @@ static bool drm_fb_helper_force_kernel_mode(void)
continue;
mutex_lock(>lock);
- ret = drm_client_modeset_commit_locked(>client);
- if (ret)
- error = true;
+ drm_client_modeset_commit_locked(>client);
mutex_unlock(>lock);
}
- return error;
+ mutex_unlock(_fb_helper_lock);
}
-static void drm_fb_helper_restore_work_fn(struct work_struct *ignored)
-{
- bool ret;
-
- ret = drm_fb_helper_force_kernel_mode();
- if (ret == true)
- DRM_ERROR("Failed to restore crtc configuration\n");
-}
static DECLARE_WORK(drm_fb_helper_restore_work, drm_fb_helper_restore_work_fn);
static void drm_fb_helper_sysrq(int dummy1)
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/display: Program PSR2 selective fetch registers
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_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 visible in state
> > > - removed calculations using plane damaged area in
> > > intel_psr2_program_plane_sel_fetch()
> > >
> > > v3:
> > > - do not shift 16 positions the plane dst coordinates, only src
> > > is
> > > shifted
> > >
> > > v4:
> > > - only setting PLANE_SEL_FETCH_CTL_ENABLE and MCURSOR_MODE in
> > > PLANE_SEL_FETCH_CTL
> > >
> > > BSpec: 55229
> > > Cc: Gwan-gyeong Mun <
> > > gwan-gyeong@intel.com
> > > Cc: Ville Syrjälä <
> > > ville.syrj...@linux.intel.com
> > > Signed-off-by: José Roberto de Souza <
> > > jose.so...@intel.com
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 10 +-
> > > drivers/gpu/drm/i915/display/intel_psr.c | 118
> > > ++-
> > > drivers/gpu/drm/i915/display/intel_psr.h | 10 +-
> > > drivers/gpu/drm/i915/display/intel_sprite.c | 3 +
> > > 4 files changed, 132 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 5a9d933e425a..96bc515497c1 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -11812,6 +11812,9 @@ static void i9xx_update_cursor(struct
> > > intel_plane *plane,
> > > if (INTEL_GEN(dev_priv) >= 9)
> > > skl_write_cursor_wm(plane, crtc_state);
> > >
> > > + if (!needs_modeset(crtc_state))
> > > + intel_psr2_program_plane_sel_fetch(plane, crtc_state,
> > > plane_state, 0);
> > > +
> > > if (plane->cursor.base != base ||
> > > plane->cursor.size != fbc_ctl ||
> > > plane->cursor.cntl != cntl) {
> > > @@ -12823,8 +12826,11 @@ static int
> > > intel_crtc_atomic_check(struct
> > > intel_atomic_state *state,
> > >
> > > }
> > >
> > > - if (!mode_changed)
> > > - intel_psr2_sel_fetch_update(state, crtc);
> > > + if (!mode_changed) {
> > > + ret = intel_psr2_sel_fetch_update(state, crtc);
> > > + if (ret)
> > > + return ret;
> > > + }
> > >
> > > return 0;
> > > }
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 02f74b0ddec1..f6e0a192d5e5 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -1166,6 +1166,39 @@ static void
> > > psr_force_hw_tracking_exit(struct
> > > drm_i915_private *dev_priv)
> > > intel_psr_exit(dev_priv);
> > > }
> > >
> > > +void intel_psr2_program_plane_sel_fetch(struct intel_plane
> > > *plane,
> > > + const struct intel_crtc_state
> > > *crtc_state,
> > > + const struct intel_plane_state
> > > *plane_state,
> > > + int color_plane)
> > > +{
> > > + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> > > + enum pipe pipe = plane->pipe;
> > > + u32 val;
> > > +
> > > + if (!crtc_state->enable_psr2_sel_fetch)
> > > + return;
> > > +
> > > + val = plane_state ? plane_state->ctl : 0;
> > > + val = plane->id == PLANE_CURSOR ? val & MCURSOR_MODE :
> > > + val &
> > > PLANE_SEL_FETCH_CTL_ENABLE;
> >
> > I could not find details of MCURSOR_MODE for selective_fetch. (on
> > bspec
> > 50420) why do you set MCURSOR_MODE here?
>
> Bsepc: 55229
>
> SEL_FETCH_CUR_CTL Cursor Mode Select = If update region, translated
> to pipe source coordinates, overlaps this cursor ? CUR_CTL Cursor
> Mode Select :
> Disable
> Oh and I missed this: Program the other fields in SEL_FETCH_CUR_CTL
> to match CUR_CTL.
>
> So the v3 version of this patch is better, unless you still think
> that SEL_FETCH_PLANE_CTL only needs to have the bit 31 set, like I
> said spares are
> different than reserved, we can set spares.
>
>
Thank you for explaining.
But the v3 missed setting of PLANE_SEL_FETCH_CTL_ENABLE for normal
plane.
if you don't mind I suggest this.
val = plane->id == PLANE_CURSOR ? val : val &
PLANE_SEL_FETCH_CTL_ENABLE;
except for this, the rest of the parts seems good to me.
> > > + intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane-
> > > > id), val);
> > >
> > > + if (!val || plane->id == PLANE_CURSOR)
> > > + return;
> > > +
> >
> > in order to set just PLANE_SEL_FETCH_CTL_ENABLE bit, I suggest to
> > use
> > like this
> > val = intel_de_read_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane-
> > >
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/jsl: Split EHL/JSL platform info and PCI ids
== 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
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/index.html
Known issues
Here are the changes found in Patchwork_18645 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@vgem_basic@unload:
- fi-kbl-x1275: [PASS][5] -> [DMESG-WARN][6] ([i915#62] / [i915#92])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-kbl-x1275/igt@vgem_ba...@unload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/fi-kbl-x1275/igt@vgem_ba...@unload.html
Possible fixes
* {igt@core_hotunplug@unbind-rebind}:
- fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-kbl-x1275/igt@core_hotunp...@unbind-rebind.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/fi-kbl-x1275/igt@core_hotunp...@unbind-rebind.html
* igt@i915_module_load@reload:
- fi-tgl-u2: [DMESG-WARN][9] ([i915#1982] / [k.org#205379]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-tgl-u2/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][13] ([i915#2203]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-skl-guc/igt@vgem_ba...@unload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/fi-skl-guc/igt@vgem_ba...@unload.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][15] ([i915#62]) -> [DMESG-FAIL][16]
([i915#62] / [i915#95])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
- fi-kbl-guc: [DMESG-WARN][17] ([i915#2203]) -> [SKIP][18]
([fdo#109271])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#62] / [i915#92]) +2 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
* igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +6 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18645/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#289]:
[Intel-gfx] [PATCH 2/3] drm/i915: Fix MOCS PTE setting for gen9+
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/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 632e08a4592b..6f771a482608 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -124,7 +124,7 @@ struct drm_i915_mocs_table {
LE_1_UC | LE_TC_2_LLC_ELLC, \
L3_1_UC), \
MOCS_ENTRY(I915_MOCS_PTE, \
- LE_0_PAGETABLE | LE_TC_2_LLC_ELLC | LE_LRUM(3), \
+ LE_0_PAGETABLE | LE_TC_0_PAGETABLE | LE_LRUM(3), \
L3_3_WB)
static const struct drm_i915_mocs_entry skl_mocs_table[] = {
@@ -274,7 +274,7 @@ static const struct drm_i915_mocs_entry icl_mocs_table[] = {
L3_1_UC),
/* Base - L3 + LeCC:PAT (Deprecated) */
MOCS_ENTRY(I915_MOCS_PTE,
- LE_0_PAGETABLE | LE_TC_1_LLC,
+ LE_0_PAGETABLE | LE_TC_0_PAGETABLE,
L3_3_WB),
GEN11_MOCS_ENTRIES
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Enable eLLC caching of display buffers for SKL+
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% sure that is indeed the case but at least my simple rendercopy
based benchmark didn't see any difference in performance.
Also if I configure things to do LLCeLLC+WT I still get cache dirt
on my screen, suggesting that is in fact operating in WB mode
anyway. This is also the reason I had to fix the MOCS target cache
to really say PTE rather than LLC+eLLC.
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.
Eero's earlier benchmarks numbers:
"* Results in GfxBench and Unigine (Valley/Heaven) tests were within daily
variation on the tested SKL machines
* SKL GT4e (128MB eLLC) / Wayland / Weston:
+15-20% SynMark TexMem512 (512MB of textures)
+4-6% SynMark TerrainFly*, CSCloth, ShMapVsm
-5-10% SynMark TexMem128 (128MB of textures)
* SKL GT3e (64MB eLLC) / Xorg / Unity:
+4-8% GpuTest Triangle fullscreen (FullHD)
-5-10% GpuTest Triangle windowed (1/2 screen)
* SKL GT2 (no eLLC) / Xorg / Unity:
* Some of the higher FPS SynMark pixel and vertex shader tests
are few percent higher, more than daily variance
=> Do you see any reason why this machine would be impacted
although it doesn't eLLC?"
Caveats:
- Still haven't tested with a prime setup
- Still not entirely sure this a good idea, but I've been
using it on my cfl anyway :)
v2: Split the MOCS PTE change out
Cc: Eero Tamminen
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gt/intel_gtt.c | 10 --
drivers/gpu/drm/i915/i915_drv.h | 3 +--
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 3f1114b58b01..7bfe9072be9a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -324,7 +324,7 @@ static void cnl_setup_private_ppat(struct intel_uncore
*uncore)
GEN8_PPAT_WC | GEN8_PPAT_LLCELLC);
intel_uncore_write(uncore,
GEN10_PAT_INDEX(2),
- GEN8_PPAT_WT | GEN8_PPAT_LLCELLC);
+ GEN8_PPAT_WB | GEN8_PPAT_ELLC_OVERRIDE);
intel_uncore_write(uncore,
GEN10_PAT_INDEX(3),
GEN8_PPAT_UC);
@@ -349,17 +349,23 @@ static void cnl_setup_private_ppat(struct intel_uncore
*uncore)
*/
static void bdw_setup_private_ppat(struct intel_uncore *uncore)
{
+ struct drm_i915_private *i915 = uncore->i915;
u64 pat;
pat = GEN8_PPAT(0, GEN8_PPAT_WB | GEN8_PPAT_LLC) | /* for normal
objects, no eLLC */
GEN8_PPAT(1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC) | /* for
something pointing to ptes? */
- GEN8_PPAT(2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC) | /* for scanout
with eLLC */
GEN8_PPAT(3, GEN8_PPAT_UC) | /* Uncached
objects, mostly for scanout */
GEN8_PPAT(4, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(0))
|
GEN8_PPAT(5, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(1))
|
GEN8_PPAT(6, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(2))
|
GEN8_PPAT(7, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(3));
+ /* for scanout with eLLC */
+ if (INTEL_GEN(i915) >= 9)
+ pat |= GEN8_PPAT(2, GEN8_PPAT_WB | GEN8_PPAT_ELLC_OVERRIDE);
+ else
+ pat |= GEN8_PPAT(2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC);
+
intel_uncore_write(uncore, GEN8_PRIVATE_PAT_LO, lower_32_bits(pat));
intel_uncore_write(uncore, GEN8_PRIVATE_PAT_HI, upper_32_bits(pat));
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eef9a821c49c..76cf014eaa6b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1638,8 +1638,7 @@ tgl_revids_get(struct drm_i915_private *dev_priv)
#define HAS_SNOOP(dev_priv)(INTEL_INFO(dev_priv)->has_snoop)
#define HAS_EDRAM(dev_priv)((dev_priv)->edram_size_mb)
#define HAS_SECURE_BATCHES(dev_priv) (INTEL_GEN(dev_priv) < 6)
-#define HAS_WT(dev_priv) ((IS_HASWELL(dev_priv) || \
-IS_BROADWELL(dev_priv)) && HAS_EDRAM(dev_priv))
+#define HAS_WT(dev_priv) HAS_EDRAM(dev_priv)
#define HWS_NEEDS_PHYSICAL(dev_priv)
(INTEL_INFO(dev_priv)->hws_needs_physical)
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init
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 the unbind to get stuck. To
most appearances this looks like a dead machine on boot.
Avoid the unbind by already marking the object cache_level
as WT when creating it. We still do an excplicit ggtt pin
which will rewrite the PTEs anyway, so they will match whatever
cache level we set.
Cc: # v5.7+
Suggested-by: Chris Wilson
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2381
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 907e1d155443..00c08600c60a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3445,6 +3445,14 @@ initial_plane_vma(struct drm_i915_private *i915,
if (IS_ERR(obj))
return NULL;
+ /*
+* Mark it WT ahead of time to avoid changing the
+* cache_level during fbdev initialization. The
+* unbind there would get stuck waiting for rcu.
+*/
+ i915_gem_object_set_cache_coherency(obj, HAS_WT(i915) ?
+ I915_CACHE_WT : I915_CACHE_NONE);
+
switch (plane_config->tiling) {
case I915_TILING_NONE:
break;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/jsl: Split EHL/JSL platform info and PCI ids
== 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_PARENTHESES: Unnecessary parentheses around 'pll->info->id == DPLL_ID_EHL_DPLL4' #214: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:155: + if (IS_JSL_EHL(i915) && (pll->info->id == DPLL_ID_EHL_DPLL4)) -:325: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible side-effects? #325: FILE: drivers/gpu/drm/i915/i915_drv.h:1420: +#define IS_JSL_EHL(dev_priv) (IS_PLATFORM(dev_priv, INTEL_JASPERLAKE) || \ + IS_PLATFORM(dev_priv, INTEL_ELKHARTLAKE)) -:336: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects? #336: FILE: drivers/gpu/drm/i915/i915_drv.h:1562: +#define IS_JSL_EHL_REVID(p, since, until) \ + (IS_JSL_EHL(p) && IS_REVID(p, since, until)) -:444: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #444: FILE: include/drm/i915_pciids.h:592: +#define INTEL_JSL_IDS(info) \ + INTEL_VGA_DEVICE(0x4E71, info), \ INTEL_VGA_DEVICE(0x4E61, info), \ INTEL_VGA_DEVICE(0x4E57, info), \ INTEL_VGA_DEVICE(0x4E55, info), \ -:444: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'info' - possible side-effects? #444: FILE: include/drm/i915_pciids.h:592: +#define INTEL_JSL_IDS(info) \ + INTEL_VGA_DEVICE(0x4E71, info), \ INTEL_VGA_DEVICE(0x4E61, info), \ INTEL_VGA_DEVICE(0x4E57, info), \ INTEL_VGA_DEVICE(0x4E55, info), \ total: 1 errors, 0 warnings, 4 checks, 331 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: Perform all asynchronous waits prior to marking payload start
== 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
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18644 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18644, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18644/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18644:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gt_heartbeat:
- fi-tgl-u2: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-tgl-u2/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18644/fi-tgl-u2/igt@i915_selftest@live@gt_heartbeat.html
Known issues
Here are the changes found in Patchwork_18644 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-byt-j1900/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18644/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18644/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@i915_module_load@reload:
- fi-tgl-u2: [DMESG-WARN][7] ([i915#1982] / [k.org#205379]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-tgl-u2/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18644/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18644/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][11] ([i915#2203]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-skl-guc/igt@vgem_ba...@unload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18644/fi-skl-guc/igt@vgem_ba...@unload.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][13] ([i915#62]) -> [DMESG-FAIL][14]
([i915#62] / [i915#95])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18644/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][16] ([i915#62] / [i915#92]) +2 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18644/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18644/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#289]: https://gitlab.freedesktop.org/drm/intel/issues/289
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Ignore dt==0 for reporting underflows
== 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
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/index.html
Known issues
Here are the changes found in Patchwork_18643 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
Possible fixes
* igt@i915_module_load@reload:
- fi-tgl-u2: [DMESG-WARN][3] ([i915#1982] / [k.org#205379]) ->
[PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-tgl-u2/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/fi-tgl-u2/igt@i915_module_l...@reload.html
- fi-kbl-x1275: [DMESG-WARN][5] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-kbl-x1275/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/fi-kbl-x1275/igt@i915_module_l...@reload.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92]) ->
[DMESG-WARN][12] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][14] ([i915#62] / [i915#92]) +1 similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9107/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#289]: https://gitlab.freedesktop.org/drm/intel/issues/289
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
[k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379
Participating hosts (45 -> 39)
--
Missing(6): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9107 -> Patchwork_18643
CI-20190529: 20190529
CI_DRM_9107: f0a9b069a83f0ab30eb2f4d632cc869555f98cde @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5803: 33f07391e5f6a8d9323e471c81db3f29f91ed4d7 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18643: 39770a56c7b00683daff65f5ce05433ea7a4edba @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
39770a56c7b0 drm/i915/gt: Ignore dt==0 for reporting underflows
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18643/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Reorder hpd init vs. display resume
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-coded call these two things do exactly the
> same thing (ie. enable HPD interrupts). Which even makes sense
> since we definitely need working HPD interrupts for MST sideband
> during the display resume.
>
> So let's just nuke the open-coded call and move the intel_hpd_init()
> call earlier.
>
> If we really would like to prevent all *long* HPD processing during
> display resume we'd need some kind of software mechanism to simply
> ignore all long HPDs. Currently we appear to have that just for
> fbdev via ifbdev->hpd_suspended. Since we aren't exploding left and
> right all the time I guess that's mostly sufficient.
Daniel suggested including the archaeological record here.
This is what I was planning to amend here:
"For a bit of history on this, we first got a mechanism to block
hotplug processing during suspend in commit 15239099d7a7 ("drm/i915:
enable irqs earlier when resuming") on account of moving the irq enable
earlier. This then got removed in commit 50c3dc970a09 ("drm/fb-helper:
Fix hpd vs. initial config races") because the fdev initial config
got pushed to a later point. The second ad-hoc hpd_irq_setup() for
resume was added in commit 0e32b39ceed6 ("drm/i915: add DP 1.2 MST
support (v0.7)") to be able to do MST sideband during resume. And
finally we got a partial resurrection of the hpd blocking
mechanism in commit e8a8fedd57fd ("drm/i915: Block fbdev HPD
processing during suspend"), but this time it only prevent fbdev
from handling the hpd while resuming."
But looks like I was far too optimistic and this did in fact blow
up in CI. So I'll need to do some actual work to figure out what's
going on...
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8 +---
> drivers/gpu/drm/i915/i915_drv.c | 16 ++--
> 2 files changed, 3 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 907e1d155443..87df7167433f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5036,18 +5036,12 @@ void intel_finish_reset(struct drm_i915_private
> *dev_priv)
> intel_pps_unlock_regs_wa(dev_priv);
> intel_modeset_init_hw(dev_priv);
> intel_init_clock_gating(dev_priv);
> -
> - spin_lock_irq(_priv->irq_lock);
> - if (dev_priv->display.hpd_irq_setup)
> - dev_priv->display.hpd_irq_setup(dev_priv);
> - spin_unlock_irq(_priv->irq_lock);
> + intel_hpd_init(dev_priv);
>
> ret = __intel_display_resume(dev, state, ctx);
> if (ret)
> drm_err(_priv->drm,
> "Restoring old state failed with %i\n", ret);
> -
> - intel_hpd_init(dev_priv);
> }
>
> drm_atomic_state_put(state);
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ebc15066d108..b2a050d916e3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1226,26 +1226,14 @@ static int i915_drm_resume(struct drm_device *dev)
>
> intel_modeset_init_hw(dev_priv);
> intel_init_clock_gating(dev_priv);
> + intel_hpd_init(dev_priv);
>
> - spin_lock_irq(_priv->irq_lock);
> - if (dev_priv->display.hpd_irq_setup)
> - dev_priv->display.hpd_irq_setup(dev_priv);
> - spin_unlock_irq(_priv->irq_lock);
> -
> + /* MST sideband requires HPD interrupts enabled */
> intel_dp_mst_resume(dev_priv);
> -
> intel_display_resume(dev);
>
> drm_kms_helper_poll_enable(dev);
>
> - /*
> - * ... but also need to make sure that hotplug processing
> - * doesn't cause havoc. Like in the driver load code we don't
> - * bother with the tiny race here where we might lose hotplug
> - * notifications.
> - * */
> - intel_hpd_init(dev_priv);
> -
> intel_opregion_resume(dev_priv);
>
> intel_fbdev_set_suspend(dev, FBINFO_STATE_RUNNING, false);
> --
> 2.26.2
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gem: Perform all asynchronous waits prior to marking payload start
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 the payload and hung.
>> > Forgetting to include a breadcrumb before the user payload would mean we
>> > do not reset the guilty user request, and conversely if the initial
>> > breadcrumb is too early we blame the user for a problem elsewhere.
>>
>> Agreed.
>>
>> >
>> > Signed-off-by: Chris Wilson
>> > ---
>> > drivers/gpu/drm/i915/gem/i915_gem_client_blt.c | 18 +-
>> > 1 file changed, 9 insertions(+), 9 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
>> > b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
>> > index 272cf3ea68d5..44821d94544f 100644
>> > --- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
>> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
>> > @@ -202,12 +202,6 @@ static void clear_pages_worker(struct work_struct
>> > *work)
>> > if (unlikely(err))
>> > goto out_request;
>> >
>> > - if (w->ce->engine->emit_init_breadcrumb) {
>> > - err = w->ce->engine->emit_init_breadcrumb(rq);
>> > - if (unlikely(err))
>> > - goto out_request;
>> > - }
>> > -
>> > /*
>> >* w->dma is already exported via (vma|obj)->resv we need only
>> >* keep track of the GPU activity within this vma/request, and
>> > @@ -217,9 +211,15 @@ static void clear_pages_worker(struct work_struct
>> > *work)
>> > if (err)
>> > goto out_request;
>> >
>> > - err = w->ce->engine->emit_bb_start(rq,
>> > -batch->node.start,
>> > batch->node.size,
>> > -0);
>>
>> We don't have to do any extra steps to counter
>>
>> __i915_vma_move_to_active(vma, rq);
>>
>> in error path?
>
> No. We always submit the request, and the request is always serialised
> with the steps that have been setup before. So if we fail in adding
> another serialisation step, we can safely abort and complete all the
> steps prior to this point (by submitting the empty request), and
> anything that subsequently wants to wait on those resources we have
> already claimed will wait on this request (which in turn waits on the
> previous resource holders and so forth, the lock chain is never broken).
So decision of emitting anything is crossing the rubicon. No matter
if it part of the breadcrumbs. Well makes sense as rollback after
that decision is prolly much harder than just to emit empty.
Reviewed-by: Mika Kuoppala
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/jsl: Split EHL/JSL platform info and PCI ids
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_EHL everywhere.
Existance of IS_JSL_EHL (IS_JASPERLAKE || IS_ELKHARTLAKE), removal of
IS_ELKHARTLAKE and absence of IS_JASPERLAKE is making me ask whether
going the subplatform route would be useful or more handy in this case?
Don't know how separate or close the platforms are, just mentioning the
option in case it makes sense. (Like JASPERLAKE, subplatform ELKHARTLAKE.)
Regards,
Tvrtko
Cc : Matt Roper
Cc : Ville Syrjälä
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/display/icl_dsi.c | 4 ++--
drivers/gpu/drm/i915/display/intel_cdclk.c | 4 ++--
drivers/gpu/drm/i915/display/intel_combo_phy.c | 6 +++---
drivers/gpu/drm/i915/display/intel_ddi.c | 12 ++--
drivers/gpu/drm/i915/display/intel_display.c | 8
drivers/gpu/drm/i915/display/intel_dp.c| 2 +-
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 16
drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c| 4 ++--
drivers/gpu/drm/i915/i915_drv.h| 7 ---
drivers/gpu/drm/i915/i915_pci.c| 9 +
drivers/gpu/drm/i915/intel_device_info.c | 1 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/intel_pch.c | 6 +++---
include/drm/i915_pciids.h | 9 ++---
15 files changed, 53 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 4400e83f783f..096652921453 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -455,7 +455,7 @@ static void gen11_dsi_config_phy_lanes_sequence(struct
intel_encoder *encoder)
intel_de_write(dev_priv, ICL_PORT_TX_DW2_GRP(phy), tmp);
/* For EHL, TGL, set latency optimization for PCS_DW1 lanes */
- if (IS_ELKHARTLAKE(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
+ if (IS_JSL_EHL(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
tmp = intel_de_read(dev_priv,
ICL_PORT_PCS_DW1_AUX(phy));
tmp &= ~LATENCY_OPTIM_MASK;
@@ -612,7 +612,7 @@ gen11_dsi_setup_dphy_timings(struct intel_encoder *encoder,
}
}
- if (IS_ELKHARTLAKE(dev_priv)) {
+ if (IS_JSL_EHL(dev_priv)) {
for_each_dsi_phy(phy, intel_dsi->phys) {
tmp = intel_de_read(dev_priv, ICL_DPHY_CHKN(phy));
tmp |= ICL_DPHY_CHKN_AFE_OVER_PPI_STRAP;
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index cb93f6cf6d37..c6e87569b3d6 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2588,7 +2588,7 @@ static int intel_compute_max_dotclk(struct
drm_i915_private *dev_priv)
*/
void intel_update_max_cdclk(struct drm_i915_private *dev_priv)
{
- if (IS_ELKHARTLAKE(dev_priv)) {
+ if (IS_JSL_EHL(dev_priv)) {
if (dev_priv->cdclk.hw.ref == 24000)
dev_priv->max_cdclk_freq = 552000;
else
@@ -2815,7 +2815,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private
*dev_priv)
dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
dev_priv->display.calc_voltage_level = tgl_calc_voltage_level;
dev_priv->cdclk.table = icl_cdclk_table;
- } else if (IS_ELKHARTLAKE(dev_priv)) {
+ } else if (IS_JSL_EHL(dev_priv)) {
dev_priv->display.set_cdclk = bxt_set_cdclk;
dev_priv->display.bw_calc_min_cdclk = skl_bw_calc_min_cdclk;
dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
b/drivers/gpu/drm/i915/display/intel_combo_phy.c
index 157d8c8c605a..d59ceaa2916a 100644
--- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
@@ -188,7 +188,7 @@ static bool has_phy_misc(struct drm_i915_private *i915,
enum phy phy)
* PHY-B and may not even have instances of the register for the
* other combo PHY's.
*/
- if (IS_ELKHARTLAKE(i915) ||
+ if (IS_JSL_EHL(i915) ||
IS_ROCKETLAKE(i915))
return phy < PHY_C;
@@ -282,7 +282,7 @@ static bool icl_combo_phy_verify_state(struct drm_i915_private *dev_priv,
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW8(phy),
IREFGEN, IREFGEN);
- if
Re: [Intel-gfx] [PATCH] drm/i915/gem: Perform all asynchronous waits prior to marking payload start
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.
> > Forgetting to include a breadcrumb before the user payload would mean we
> > do not reset the guilty user request, and conversely if the initial
> > breadcrumb is too early we blame the user for a problem elsewhere.
>
> Agreed.
>
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_client_blt.c | 18 +-
> > 1 file changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> > index 272cf3ea68d5..44821d94544f 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> > @@ -202,12 +202,6 @@ static void clear_pages_worker(struct work_struct
> > *work)
> > if (unlikely(err))
> > goto out_request;
> >
> > - if (w->ce->engine->emit_init_breadcrumb) {
> > - err = w->ce->engine->emit_init_breadcrumb(rq);
> > - if (unlikely(err))
> > - goto out_request;
> > - }
> > -
> > /*
> >* w->dma is already exported via (vma|obj)->resv we need only
> >* keep track of the GPU activity within this vma/request, and
> > @@ -217,9 +211,15 @@ static void clear_pages_worker(struct work_struct
> > *work)
> > if (err)
> > goto out_request;
> >
> > - err = w->ce->engine->emit_bb_start(rq,
> > -batch->node.start,
> > batch->node.size,
> > -0);
>
> We don't have to do any extra steps to counter
>
> __i915_vma_move_to_active(vma, rq);
>
> in error path?
No. We always submit the request, and the request is always serialised
with the steps that have been setup before. So if we fail in adding
another serialisation step, we can safely abort and complete all the
steps prior to this point (by submitting the empty request), and
anything that subsequently wants to wait on those resources we have
already claimed will wait on this request (which in turn waits on the
previous resource holders and so forth, the lock chain is never broken).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/jsl: Split EHL/JSL platform info and PCI ids
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 Syrjälä
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/display/icl_dsi.c | 4 ++--
drivers/gpu/drm/i915/display/intel_cdclk.c | 4 ++--
drivers/gpu/drm/i915/display/intel_combo_phy.c | 6 +++---
drivers/gpu/drm/i915/display/intel_ddi.c | 12 ++--
drivers/gpu/drm/i915/display/intel_display.c | 8
drivers/gpu/drm/i915/display/intel_dp.c| 2 +-
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 16
drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c| 4 ++--
drivers/gpu/drm/i915/i915_drv.h| 7 ---
drivers/gpu/drm/i915/i915_pci.c| 9 +
drivers/gpu/drm/i915/intel_device_info.c | 1 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/intel_pch.c | 6 +++---
include/drm/i915_pciids.h | 9 ++---
15 files changed, 53 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 4400e83f783f..096652921453 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -455,7 +455,7 @@ static void gen11_dsi_config_phy_lanes_sequence(struct
intel_encoder *encoder)
intel_de_write(dev_priv, ICL_PORT_TX_DW2_GRP(phy), tmp);
/* For EHL, TGL, set latency optimization for PCS_DW1 lanes */
- if (IS_ELKHARTLAKE(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
+ if (IS_JSL_EHL(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
tmp = intel_de_read(dev_priv,
ICL_PORT_PCS_DW1_AUX(phy));
tmp &= ~LATENCY_OPTIM_MASK;
@@ -612,7 +612,7 @@ gen11_dsi_setup_dphy_timings(struct intel_encoder *encoder,
}
}
- if (IS_ELKHARTLAKE(dev_priv)) {
+ if (IS_JSL_EHL(dev_priv)) {
for_each_dsi_phy(phy, intel_dsi->phys) {
tmp = intel_de_read(dev_priv, ICL_DPHY_CHKN(phy));
tmp |= ICL_DPHY_CHKN_AFE_OVER_PPI_STRAP;
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index cb93f6cf6d37..c6e87569b3d6 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2588,7 +2588,7 @@ static int intel_compute_max_dotclk(struct
drm_i915_private *dev_priv)
*/
void intel_update_max_cdclk(struct drm_i915_private *dev_priv)
{
- if (IS_ELKHARTLAKE(dev_priv)) {
+ if (IS_JSL_EHL(dev_priv)) {
if (dev_priv->cdclk.hw.ref == 24000)
dev_priv->max_cdclk_freq = 552000;
else
@@ -2815,7 +2815,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private
*dev_priv)
dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
dev_priv->display.calc_voltage_level = tgl_calc_voltage_level;
dev_priv->cdclk.table = icl_cdclk_table;
- } else if (IS_ELKHARTLAKE(dev_priv)) {
+ } else if (IS_JSL_EHL(dev_priv)) {
dev_priv->display.set_cdclk = bxt_set_cdclk;
dev_priv->display.bw_calc_min_cdclk = skl_bw_calc_min_cdclk;
dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
b/drivers/gpu/drm/i915/display/intel_combo_phy.c
index 157d8c8c605a..d59ceaa2916a 100644
--- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
@@ -188,7 +188,7 @@ static bool has_phy_misc(struct drm_i915_private *i915,
enum phy phy)
* PHY-B and may not even have instances of the register for the
* other combo PHY's.
*/
- if (IS_ELKHARTLAKE(i915) ||
+ if (IS_JSL_EHL(i915) ||
IS_ROCKETLAKE(i915))
return phy < PHY_C;
@@ -282,7 +282,7 @@ static bool icl_combo_phy_verify_state(struct
drm_i915_private *dev_priv,
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW8(phy),
IREFGEN, IREFGEN);
- if (IS_ELKHARTLAKE(dev_priv)) {
+ if (IS_JSL_EHL(dev_priv)) {
if (ehl_vbt_ddi_d_present(dev_priv))
expected_val = ICL_PHY_MISC_MUX_DDID;
@@ -376,7 +376,7 @@ static void icl_combo_phys_init(struct drm_i915_private
*dev_priv)
* "internal" child devices.
*/
val = intel_de_read(dev_priv, ICL_PHY_MISC(phy));
-
Re: [Intel-gfx] [PATCH] drm/i915/gem: Perform all asynchronous waits prior to marking payload start
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 would mean we
> do not reset the guilty user request, and conversely if the initial
> breadcrumb is too early we blame the user for a problem elsewhere.
Agreed.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gem/i915_gem_client_blt.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> index 272cf3ea68d5..44821d94544f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> @@ -202,12 +202,6 @@ static void clear_pages_worker(struct work_struct *work)
> if (unlikely(err))
> goto out_request;
>
> - if (w->ce->engine->emit_init_breadcrumb) {
> - err = w->ce->engine->emit_init_breadcrumb(rq);
> - if (unlikely(err))
> - goto out_request;
> - }
> -
> /*
>* w->dma is already exported via (vma|obj)->resv we need only
>* keep track of the GPU activity within this vma/request, and
> @@ -217,9 +211,15 @@ static void clear_pages_worker(struct work_struct *work)
> if (err)
> goto out_request;
>
> - err = w->ce->engine->emit_bb_start(rq,
> -batch->node.start, batch->node.size,
> -0);
We don't have to do any extra steps to counter
__i915_vma_move_to_active(vma, rq);
in error path?
-Mika
> + if (rq->engine->emit_init_breadcrumb) {
> + err = rq->engine->emit_init_breadcrumb(rq);
> + if (unlikely(err))
> + goto out_request;
> + }
> +
> + err = rq->engine->emit_bb_start(rq,
> + batch->node.start, batch->node.size,
> + 0);
> out_request:
> if (unlikely(err)) {
> i915_request_set_error_once(rq, err);
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Undo forced context restores after trivial preemptions
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 requires
> re-submission). However, due to the way we check for wrap-around during
> the unravelling, we mark any context that has been submitted just once
> (i.e. with the rq->wa_tail set, but the ring->tail earlier) as
> potentially wrapping and requiring a forced restore on resubmission.
> This was expected to be not a problem, as it was anticipated that most
> unwinding for preemption would result in a context switch and the few
> that did not would be lost in the noise. It did not take long for
> someone to find one particular workload where the cost of those extra
> context restores was measurable.
>
> However, since we know the wa_tail is of fixed size, and we know that a
> request must be larger than the wa_tail itself, we can safely maintain
> the check for request wrapping and check against a slightly future point
> in the ring that includes an expected wa_tail. (That is if the
> ring->tail is already set to rq->wa_tail, including another 8 bytes in
> the check does not invalidate the incremental wrap detection.)
>
> Fixes: 8ab3a3812aa9 ("drm/i915/gt: Incrementally check for rewinding")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Bruce Chang
> Cc: Ramalingam C
> Cc: Joonas Lahtinen
> Cc: # v5.4+
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 287537089c77..3aa05588834b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1140,9 +1140,8 @@ __unwind_incomplete_requests(struct intel_engine_cs
> *engine)
>
> /* Check in case we rollback so far we wrap [size/2] */
My parser hickups. /* Make sure rollback doesn't make hardware think we
went forward */
But for this patch,
Reviewed-by: Mika Kuoppala
> if (intel_ring_direction(rq->ring,
> - intel_ring_wrap(rq->ring,
> - rq->tail),
> - rq->ring->tail) > 0)
> + rq->tail,
> + rq->ring->tail + 8) > 0)
> rq->context->lrc.desc |= CTX_DESC_FORCE_RESTORE;
>
> active = rq;
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gem: Perform all asynchronous waits prior to marking payload start
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 guilty user request, and conversely if the initial
breadcrumb is too early we blame the user for a problem elsewhere.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_client_blt.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 272cf3ea68d5..44821d94544f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -202,12 +202,6 @@ static void clear_pages_worker(struct work_struct *work)
if (unlikely(err))
goto out_request;
- if (w->ce->engine->emit_init_breadcrumb) {
- err = w->ce->engine->emit_init_breadcrumb(rq);
- if (unlikely(err))
- goto out_request;
- }
-
/*
* w->dma is already exported via (vma|obj)->resv we need only
* keep track of the GPU activity within this vma/request, and
@@ -217,9 +211,15 @@ static void clear_pages_worker(struct work_struct *work)
if (err)
goto out_request;
- err = w->ce->engine->emit_bb_start(rq,
- batch->node.start, batch->node.size,
- 0);
+ if (rq->engine->emit_init_breadcrumb) {
+ err = rq->engine->emit_init_breadcrumb(rq);
+ if (unlikely(err))
+ goto out_request;
+ }
+
+ err = rq->engine->emit_bb_start(rq,
+ batch->node.start, batch->node.size,
+ 0);
out_request:
if (unlikely(err)) {
i915_request_set_error_once(rq, err);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Ignore dt==0 for reporting underflows
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 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 287537089c77..d288d92e2cd9 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1307,7 +1307,7 @@ static void reset_active(struct i915_request *rq,
static void st_update_runtime_underflow(struct intel_context *ce, s32 dt)
{
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
- ce->runtime.num_underflow += dt < 0;
+ ce->runtime.num_underflow++;
ce->runtime.max_underflow = max_t(u32, ce->runtime.max_underflow, -dt);
#endif
}
@@ -1324,7 +1324,7 @@ static void intel_context_update_runtime(struct
intel_context *ce)
ce->runtime.last = intel_context_get_runtime(ce);
dt = ce->runtime.last - old;
- if (unlikely(dt <= 0)) {
+ if (unlikely(dt < 0)) {
CE_TRACE(ce, "runtime underflow: last=%u, new=%u, delta=%d\n",
old, ce->runtime.last, dt);
st_update_runtime_underflow(ce, dt);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/gt: Track the most recent pulse for the heartbeat
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 the last
> request emitted along the heartbeat, the engine is idling and a
> heartbeat pulse not required. This assumption fails, but we can reuse
> the idle pulse as the heartbeat if we are yet to emit one, and so track
> the status of that pulse for our engine health check.
>
> This impacts tgl/rcs0 as we rely on the heartbeat for our healthcheck for
> the normal preemption detection mechanism is disabled by default.
>
> Testcase: igt/gem_exec_schedule/preempt-hang/rcs0 #tgl
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> index 5067d0524d4b..9060385cd69e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> @@ -41,6 +41,8 @@ static void idle_pulse(struct intel_engine_cs *engine,
> struct i915_request *rq)
> {
> engine->wakeref_serial = READ_ONCE(engine->serial) + 1;
> i915_request_add_active_barriers(rq);
> + if (!engine->heartbeat.systole && intel_engine_has_heartbeat(engine))
> + engine->heartbeat.systole = i915_request_get(rq);
> }
>
> static void show_heartbeat(const struct i915_request *rq,
> @@ -144,8 +146,6 @@ static void heartbeat(struct work_struct *wrk)
> goto unlock;
>
> idle_pulse(engine, rq);
> - if (engine->i915->params.enable_hangcheck)
> - engine->heartbeat.systole = i915_request_get(rq);
>
> __i915_request_commit(rq);
> __i915_request_queue(rq, );
> @@ -153,7 +153,7 @@ static void heartbeat(struct work_struct *wrk)
> unlock:
> mutex_unlock(>timeline->mutex);
> out:
> - if (!next_heartbeat(engine))
> + if (!engine->i915->params.enable_hangcheck || !next_heartbeat(engine))
> i915_request_put(fetch_and_zero(>heartbeat.systole));
> intel_engine_pm_put(engine);
> }
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH rdma-next v5 0/4] Dynamicaly allocate SG table from the pages
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_table_from_pages to allow chaining of > > > > new pages to already initialized SG table. > > > > > > > > This allows for the drivers to utilize the optimization of merging > > > > contiguous > > > > pages without a need to pre allocate all the pages and hold them in > > > > a very large temporary buffer prior to the call to SG table > > > > initialization. > > > > > > > > The second patch changes the Infiniband driver to use the new API. It > > > > removes duplicate functionality from the code and benefits the > > > > optimization of allocating dynamic SG table from pages. > > > > > > > > In huge pages system of 2MB page size, without this change, the SG table > > > > would contain x512 SG entries. > > > > E.g. for 100GB memory registration: > > > > > > > > Number of entries Size > > > > Before26214400 600.0MB > > > > After512001.2MB > > > > > > > > Thanks > > > > > > > > Maor Gottlieb (2): > > > > lib/scatterlist: Add support in dynamic allocation of SG table from > > > > pages > > > > RDMA/umem: Move to allocate SG table from pages > > > > > > > > Tvrtko Ursulin (2): > > > > tools/testing/scatterlist: Rejuvenate bit-rotten test > > > > tools/testing/scatterlist: Show errors in human readable form > > > > > > This looks OK, I'm going to send it into linux-next on the hmm tree > > > for awhile to see if anything gets broken. If there is more > > > remarks/tags/etc please continue > > > > An idea that just crossed my mind: A pin_user_pages_sgt might be useful > > for both rdma and drm, since this would avoid the possible huge interim > > struct pages array for thp pages. Or anything else that could be coalesced > > down into a single sg entry. > > > > Not sure it's worth it, but would at least give a slightly neater > > interface I think. > > We've talked about it. Christoph wants to see this area move to a biovec > interface instead of sgl, but it might still be worthwhile to have an > interm step at least as an API consolidation. Hm but then we'd need a new struct for the mapped side of things (which would still be what you get from dma-buf). That would be quite a bit of work to roll out everywhere, and sgt isn't such a huge misfit for passing buffer object mappings and system memory backing storage around, and hence what we (very slowly) converging drivers/gpu towards over the past 10 years or so. And moving the dma_map step out of dma-buf doesn't work, because some of the use-cases we have is for very special iommus which are managed by the gpu driver directly. Stuff that e.g. rotates/retiles/compresses on the fly, and is accessible by other (gfx related like video code, camera, ..) devices. Not something I expect to ever be relevant for rdma since this exist mostly on some small soc, but it's a thing. Without that dma-buf could hand out biovec for struct_page backed stuff, or some pfn_vec for the p2p stuff. Anyway was just an idea, I guess we'll have to live with some impedance mismatch since rolling out the one an only iovec structure which suits everyone is I think impossible :-) > Avoiding the page list would be complicated as we'd somehow have to > code share the page table iterator scheme. We're (slowly) getting towards thp for vram mappings and everything so I guess for drivers/gpu we might make that happen. But yeah it'd be not so pretty I think. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/dpcd_bl: Skip testing control capability with force DPCD quirk
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-by: Kai-Heng Feng
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index acbd7eb66cbe..acf2e1c65290 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -347,9 +347,13 @@ int intel_dp_aux_init_backlight_funcs(struct
intel_connector *intel_connector)
struct intel_panel *panel = _connector->panel;
struct intel_dp *intel_dp = enc_to_intel_dp(intel_connector->encoder);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ bool force_dpcd;
+
+ force_dpcd = drm_dp_has_quirk(_dp->desc, intel_dp->edid_quirks,
+ DP_QUIRK_FORCE_DPCD_BACKLIGHT);
if (i915->params.enable_dpcd_backlight == 0 ||
- !intel_dp_aux_display_control_capable(intel_connector))
+ (!force_dpcd &&
!intel_dp_aux_display_control_capable(intel_connector)))
return -ENODEV;
/*
@@ -358,9 +362,7 @@ int intel_dp_aux_init_backlight_funcs(struct
intel_connector *intel_connector)
*/
if (i915->vbt.backlight.type !=
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
- i915->params.enable_dpcd_backlight != 1 &&
- !drm_dp_has_quirk(_dp->desc, intel_dp->edid_quirks,
- DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
+ i915->params.enable_dpcd_backlight != 1 && !force_dpcd) {
drm_info(>drm,
"Panel advertises DPCD backlight support, but "
"VBT disagrees. If your backlight controls "
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
