[Intel-gfx] i915: slow startup
Hi, I'm experiencing a longer boot up with recent kernels. Looking at the kernel log, it seems to be related to the i915 driver. See excerpts of the logs below: 2.6.38.4: [0.533344] Linux agpgart interface v0.103 [0.533411] agpgart-intel :00:00.0: Intel GM45 Chipset [0.533597] agpgart-intel :00:00.0: detected gtt size: 2097152K total, 26 2144K mappable [0.534839] agpgart-intel :00:00.0: detected 32768K stolen memory [0.534957] agpgart-intel :00:00.0: AGP aperture is 256M @ 0xd000 [0.535023] [drm] Initialized drm 1.1.0 20060810 [0.535045] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [0.535050] i915 :00:02.0: setting latency timer to 64 [0.625997] i915 :00:02.0: irq 45 for MSI/MSI-X [0.626013] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [0.626015] [drm] Driver supports precise vblank timestamp query. [0.704773] composite sync not supported [0.706220] fixme: max PWM is zero. [0.714167] composite sync not supported [0.728223] fbcon: inteldrmfb (fb0) is primary device [0.732710] Console: switching to colour frame buffer device 160x50 [0.735365] fb0: inteldrmfb frame buffer device [0.735366] drm: registered panic notifier [0.755610] acpi device:06: registered as cooling_device0 [0.755786] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input4 [0.755792] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [0.755888] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 -- And for 3.2-rc1 (though 3.1 and 3.0 have similar timings): [0.611279] Linux agpgart interface v0.103 [0.611346] agpgart-intel :00:00.0: Intel GM45 Chipset [0.611541] agpgart-intel :00:00.0: detected gtt size: 2097152K total, 26 2144K mappable [0.612758] agpgart-intel :00:00.0: detected 32768K stolen memory [0.612890] agpgart-intel :00:00.0: AGP aperture is 256M @ 0xd000 [0.612938] [drm] Initialized drm 1.1.0 20060810 [0.612958] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [0.612963] i915 :00:02.0: setting latency timer to 64 [0.705279] i915 :00:02.0: irq 45 for MSI/MSI-X [0.705284] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [0.705286] [drm] Driver supports precise vblank timestamp query. [0.757666] composite sync not supported [0.757702] fixme: max PWM is zero. [1.220708] composite sync not supported [1.239559] fbcon: inteldrmfb (fb0) is primary device [1.532030] Refined TSC clocksource calibration: 2194.499 MHz. [1.532034] Switching to clocksource tsc [1.763692] Console: switching to colour frame buffer device 160x50 [1.766367] fb0: inteldrmfb frame buffer device [1.766368] drm: registered panic notifier [1.806045] acpi device:06: registered as cooling_device0 [1.806169] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input4 [1.806175] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [1.806205] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 -- While in 2.6.38 the message [drm] Initialized... came after 0.75s, in 3.[012] it's taking 1.8s. These kernels have similar configs, so I don't think it's because of new features. However I can not be sure it's intel's driver fault because the log is not much verbose. If I turn verbose logging, the timings and messages change a lot and it's difficult to compare those kernels. Do you know of major changes in the intel driver that might be causing this delay? My card is the following one: 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07) Subsystem: Dell Device 02bb Flags: bus master, fast devsel, latency 0 Capabilities: access denied Kernel driver in use: agpgart-intel 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller]) Subsystem: Dell Device 02bb Flags: bus master, fast devsel, latency 0, IRQ 45 Memory at f640 (64-bit, non-prefetchable) [size=4M] Memory at d000 (64-bit, prefetchable) [size=256M] I/O ports at 1800 [size=8] Capabilities: access denied Kernel driver in use: i915 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) Subsystem: Dell Device 02bb Flags: bus master, fast devsel, latency 0 Memory at f610 (64-bit, non-prefetchable) [size=1M] Thanks Lucas De Marchi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Apply Wa Display #1183 on skl, kbl, and cfl
On Wed, Nov 15, 2017 at 6:26 PM, Lucas De Marchi
<lucas.demar...@intel.com> wrote:
> Wa Display #1183 was recently added to workaround
> "Failures when enabling DPLL0 with eDP link rate 2.16
> or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz
> (CDCLK_CTL CD Frequency Select 10b or 11b) used in this
> enabling or in previous enabling."
>
> This Workaround was designed to minimize the impact only
> to save the bad case with that link rates. But HW engineers
> indicated that it should be safe to apply broadly, although
> they were expecting the DPLL0 link rate to be unchanged on
> runtime.
>
> We need to cover 2 cases: when we are in fact enabling DPLL0
> and when we are just changing the frequency with small
> differences.
>
> This is based on previous patch by Rodrigo Vivi with suggestions
> from Ville Syrjälä.
>
> Cc: Arthur J Runyan <arthur.j.run...@intel.com>
> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> drivers/gpu/drm/i915/intel_cdclk.c | 44
> +++--
> drivers/gpu/drm/i915/intel_runtime_pm.c | 10
> 3 files changed, 43 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index cfdf4f821ac3..b0a1bf5f549c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7019,6 +7019,7 @@ enum {
> #define RESET_PCH_HANDSHAKE_ENABLE(1<<4)
>
> #define GEN8_CHICKEN_DCPR_1_MMIO(0x46430)
> +#define SKL_SELECT_ALTERNATE_DC_EXIT (1<<30)
> #define MASK_WAKEMEM (1<<13)
>
> #define SKL_DFSM _MMIO(0x51000)
> @@ -8573,6 +8574,7 @@ enum skl_power_gate {
> #define BXT_CDCLK_CD2X_DIV_SEL_2 (2<<22)
> #define BXT_CDCLK_CD2X_DIV_SEL_4 (3<<22)
> #define BXT_CDCLK_CD2X_PIPE(pipe) ((pipe)<<20)
> +#define CDCLK_DIVMUX_CD_OVERRIDE (1<<19)
> #define BXT_CDCLK_CD2X_PIPE_NONE BXT_CDCLK_CD2X_PIPE(3)
> #define BXT_CDCLK_SSA_PRECHARGE_ENABLE(1<<16)
> #define CDCLK_FREQ_DECIMAL_MASK (0x7ff)
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index e8884c2ade98..0a995c0f955e 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -931,16 +931,10 @@ static void skl_set_preferred_cdclk_vco(struct
> drm_i915_private *dev_priv,
>
> static void skl_dpll0_enable(struct drm_i915_private *dev_priv, int vco)
> {
> - int min_cdclk = skl_calc_cdclk(0, vco);
> u32 val;
>
> WARN_ON(vco != 810 && vco != 864);
>
> - /* select the minimum CDCLK before enabling DPLL 0 */
> - val = CDCLK_FREQ_337_308 | skl_cdclk_decimal(min_cdclk);
> - I915_WRITE(CDCLK_CTL, val);
> - POSTING_READ(CDCLK_CTL);
> -
> /*
> * We always enable DPLL0 with the lowest link rate possible, but
> still
> * taking into account the VCO required to operate the eDP panel at
> the
> @@ -994,7 +988,8 @@ static void skl_set_cdclk(struct drm_i915_private
> *dev_priv,
> {
> int cdclk = cdclk_state->cdclk;
> int vco = cdclk_state->vco;
> - u32 freq_select;
> + u32 freq_select, cdclk_ctl;
> + bool need_dpll0_enable;
> int ret;
>
> mutex_lock(_priv->pcu_lock);
> @@ -1009,7 +1004,7 @@ static void skl_set_cdclk(struct drm_i915_private
> *dev_priv,
> return;
> }
>
> - /* set CDCLK_CTL */
> + /* Choose frequency for this cdclk */
> switch (cdclk) {
> default:
> WARN_ON(cdclk != dev_priv->cdclk.hw.ref);
> @@ -1032,16 +1027,39 @@ static void skl_set_cdclk(struct drm_i915_private
> *dev_priv,
> break;
> }
>
> - if (dev_priv->cdclk.hw.vco != 0 &&
> - dev_priv->cdclk.hw.vco != vco)
> + need_dpll0_enable = dev_priv->cdclk.hw.vco != vco;
> +
> + if (dev_priv->cdclk.hw.vco != 0 && need_dpll0_enable)
> skl_dpll0_disable(dev_priv);
>
> - if (dev_priv->cdclk.hw.vco != vco)
> - skl_dpll0_enable(dev_priv, vco);
> + cdclk_ctl = I915_READ(CDCLK_CTL);
> + cdclk_ctl &= ~(CDCLK_FREQ_SEL_MASK | CDCLK_FREQ_DECIMAL_MASK);
Ooops, this line should be inside the `if ()` below... I fixed it up
and forgot it stashed. I'll wait for a review
Re: [Intel-gfx] [PATCH] drm/i915/cnl: WA Display #1178 to fix some type C dongles
On Thu, Nov 23, 2017 at 7:21 AM, Ville Syrjälä
<ville.syrj...@linux.intel.com> wrote:
> On Wed, Nov 22, 2017 at 10:55:14AM -0800, Lucas De Marchi wrote:
>> WA Display #1178 is meant to fix Aux channel voltage swing too low with
>> some type C dongles. Although it is for type C, HW engineers reported
>> that it can be applied to all external ports even if they are not going
>> to type C.
>>
>> For CNL we apply the workaround every time Aux B, C and D are powering
>> up since they will lose the configuration when powered down.
>>
>> Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
>> Cc: Arthur J Runyan <arthur.j.run...@intel.com>
>> Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
>> ---
>>
>> Since this is a workaround I think it would be desirable not to be
>> so intrusive. The simplest thing to do is to add the
>> IS_CANNONLAKE() and workaround as done here.
>>
>> An alternative that may be more elegant (but also more intrusive) is to
>> declare a new ops for CNL for AUX B/C/D. Let me know what you think.
>>
>> For the type-C dongles that I have here it worked both with and without
>> this patch, so bear in mind I couldn't actually reproduce the problem.
>>
>> drivers/gpu/drm/i915/i915_reg.h | 11 +++
>> drivers/gpu/drm/i915/intel_runtime_pm.c | 9 +
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 96c80fa0fcac..32064605f82d 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -8332,6 +8332,17 @@ enum skl_power_gate {
>> #define SKL_PW_TO_PG(pw)((pw) - SKL_DISP_PW_1 +
>> SKL_PG1)
>> #define SKL_FUSE_PG_DIST_STATUS(pg) (1 << (27 - (pg)))
>>
>> +#define _CNL_AUX_REG_IDX(pw) ((pw - 1) >> 4)
>> +#define _CNL_AUX_ANAOVRD1_B 0x162250
>> +#define _CNL_AUX_ANAOVRD1_C 0x162210
>> +#define _CNL_AUX_ANAOVRD1_D 0x1622D0
>> +#define CNL_AUX_ANAOVRD1(pw) _MMIO(_PICK(_CNL_AUX_REG_IDX(pw), \
>> + _CNL_AUX_ANAOVRD1_B, \
>> + _CNL_AUX_ANAOVRD1_C, \
>> + _CNL_AUX_ANAOVRD1_D))
>> +#define CNL_AUX_ANAOVRD1_ENABLE(1<<16)
>> +#define CNL_AUX_ANAOVRD1_LDO_BYPASS(1<<23)
>
> I can't actually find these registers in bspec. How do you come up with
> the names and stuff?
>
> Based on the offset they look like PHY registers to me, so probably
> should be placed somewhere around the existing PHY registers.
>
>> +
>> /* Per-pipe DDI Function Control */
>> #define _TRANS_DDI_FUNC_CTL_A0x60400
>> #define _TRANS_DDI_FUNC_CTL_B0x61400
>> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> index 8315499452dc..9bf200e4885d 100644
>> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> @@ -388,6 +388,15 @@ static void hsw_power_well_enable(struct
>> drm_i915_private *dev_priv,
>> I915_WRITE(HSW_PWR_WELL_CTL_DRIVER(id), val |
>> HSW_PWR_WELL_CTL_REQ(id));
>> hsw_wait_for_power_well_enable(dev_priv, power_well);
>>
>> + /* WA Display #1178 */
>
> Pls stick to a consistent w/a comment style.
Are you suggesting to change to "/* Display Wa #1178 */"? It seems the
most common style in the
codebase, although others are used.
- "Wa Display #number" is used in my other pending patch that was
based on first version by Rodrigo and
has 1 occurence
- "Display WA #number" has 13 occurrences
- "Display Wa #number" has 1 occurrence
- "WaName" has several occurrences and is by far the most common,
although I don't think all Wa have names
like these
Should I send a fix to these as well?
Thanks
Lucas De Marchi
>
>> + if (IS_CANNONLAKE(dev_priv) &&
>> + (id == CNL_DISP_PW_AUX_B || id == CNL_DISP_PW_AUX_C ||
>> + id == CNL_DISP_PW_AUX_D)) {
>> + val = I915_READ(CNL_AUX_ANAOVRD1(id));
>> + val |= CNL_AUX_ANAOVRD1_ENABLE | CNL_AUX_ANAOVRD1_LDO_BYPASS;
>> + I915_WRITE(CNL_AUX_ANAOVRD1(id), val);
>> + }
>> +
>> if (wait_fuses)
>> gen9_wait_for_power_well_fuses(dev_priv, pg);
>>
>> --
>> 2.14.3
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: follow single notation for workaround number
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_hdmi.c| 2 +-
drivers/gpu/drm/i915/intel_pm.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 76c75d34e799..9a0ebf205435 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15126,7 +15126,7 @@ get_encoder_power_domains(struct drm_i915_private
*dev_priv)
static void intel_early_display_was(struct drm_i915_private *dev_priv)
{
- /* Display WA #1185 WaDisableDARBFClkGating:cnl,glk */
+ /* Display WA #1185 WaDisableDARBFClkGating: cnl,glk */
if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
I915_WRITE(GEN9_CLKGATE_DIS_0, I915_READ(GEN9_CLKGATE_DIS_0) |
DARBF_GATING_DIS);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 9d5e72728475..691600ce48c4 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1380,7 +1380,7 @@ static bool hdmi_12bpc_possible(const struct
intel_crtc_state *crtc_state)
}
}
- /* Display Wa #1139 */
+ /* Display WA #1139 */
if (IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1) &&
crtc_state->base.adjusted_mode.htotal > 5460)
return false;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a80c322c5b43..7905b8313e40 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -61,7 +61,7 @@ static void gen9_init_clock_gating(struct drm_i915_private
*dev_priv)
if (HAS_LLC(dev_priv)) {
/*
* WaCompressedResourceDisplayNewHashMode:skl,kbl
-* Display WA#0390: skl,kbl
+* Display WA #0390: skl,kbl
*
* Must match Sampler, Pixel Back End, and Media. See
* WaCompressedResourceSamplerPbeMediaNewHashMode.
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: add platform tag to WA
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com> Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com> --- drivers/gpu/drm/i915/intel_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 691600ce48c4..c42a6c672b73 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1380,7 +1380,7 @@ static bool hdmi_12bpc_possible(const struct intel_crtc_state *crtc_state) } } - /* Display WA #1139 */ + /* Display WA #1139: glk */ if (IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1) && crtc_state->base.adjusted_mode.htotal > 5460) return false; -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/cnl: apply Display WA #1178 to fix type C dongles
Display WA #1178 is meant to fix Aux channel voltage swing too low with
some type C dongles. Although it is for type C, HW engineers reported
that it can be applied to all external ports even if they are not going
to type C.
For CNL we apply the workaround every time Aux B, C and D are powering
up since they will lose the configuration when powered down.
v2: Use common tag for WA
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Cc: Arthur J Runyan <arthur.j.run...@intel.com>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
---
drivers/gpu/drm/i915/i915_reg.h | 11 +++
drivers/gpu/drm/i915/intel_runtime_pm.c | 9 +
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 09bf043c1c2e..0214327d8af7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8335,6 +8335,17 @@ enum skl_power_gate {
#define SKL_PW_TO_PG(pw) ((pw) - SKL_DISP_PW_1 + SKL_PG1)
#define SKL_FUSE_PG_DIST_STATUS(pg) (1 << (27 - (pg)))
+#define _CNL_AUX_REG_IDX(pw) ((pw - 1) >> 4)
+#define _CNL_AUX_ANAOVRD1_B0x162250
+#define _CNL_AUX_ANAOVRD1_C0x162210
+#define _CNL_AUX_ANAOVRD1_D0x1622D0
+#define CNL_AUX_ANAOVRD1(pw) _MMIO(_PICK(_CNL_AUX_REG_IDX(pw), \
+ _CNL_AUX_ANAOVRD1_B, \
+ _CNL_AUX_ANAOVRD1_C, \
+ _CNL_AUX_ANAOVRD1_D))
+#define CNL_AUX_ANAOVRD1_ENABLE (1<<16)
+#define CNL_AUX_ANAOVRD1_LDO_BYPASS (1<<23)
+
/* Per-pipe DDI Function Control */
#define _TRANS_DDI_FUNC_CTL_A 0x60400
#define _TRANS_DDI_FUNC_CTL_B 0x61400
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 8315499452dc..29f14e724f41 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -388,6 +388,15 @@ static void hsw_power_well_enable(struct drm_i915_private
*dev_priv,
I915_WRITE(HSW_PWR_WELL_CTL_DRIVER(id), val | HSW_PWR_WELL_CTL_REQ(id));
hsw_wait_for_power_well_enable(dev_priv, power_well);
+ /* Display WA #1178: cnl */
+ if (IS_CANNONLAKE(dev_priv) &&
+ (id == CNL_DISP_PW_AUX_B || id == CNL_DISP_PW_AUX_C ||
+id == CNL_DISP_PW_AUX_D)) {
+ val = I915_READ(CNL_AUX_ANAOVRD1(id));
+ val |= CNL_AUX_ANAOVRD1_ENABLE | CNL_AUX_ANAOVRD1_LDO_BYPASS;
+ I915_WRITE(CNL_AUX_ANAOVRD1(id), val);
+ }
+
if (wait_fuses)
gen9_wait_for_power_well_fuses(dev_priv, pg);
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/cnl: WA Display #1178 to fix some type C dongles
WA Display #1178 is meant to fix Aux channel voltage swing too low with
some type C dongles. Although it is for type C, HW engineers reported
that it can be applied to all external ports even if they are not going
to type C.
For CNL we apply the workaround every time Aux B, C and D are powering
up since they will lose the configuration when powered down.
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Cc: Arthur J Runyan <arthur.j.run...@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
---
Since this is a workaround I think it would be desirable not to be
so intrusive. The simplest thing to do is to add the
IS_CANNONLAKE() and workaround as done here.
An alternative that may be more elegant (but also more intrusive) is to
declare a new ops for CNL for AUX B/C/D. Let me know what you think.
For the type-C dongles that I have here it worked both with and without
this patch, so bear in mind I couldn't actually reproduce the problem.
drivers/gpu/drm/i915/i915_reg.h | 11 +++
drivers/gpu/drm/i915/intel_runtime_pm.c | 9 +
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 96c80fa0fcac..32064605f82d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8332,6 +8332,17 @@ enum skl_power_gate {
#define SKL_PW_TO_PG(pw) ((pw) - SKL_DISP_PW_1 + SKL_PG1)
#define SKL_FUSE_PG_DIST_STATUS(pg) (1 << (27 - (pg)))
+#define _CNL_AUX_REG_IDX(pw) ((pw - 1) >> 4)
+#define _CNL_AUX_ANAOVRD1_B0x162250
+#define _CNL_AUX_ANAOVRD1_C0x162210
+#define _CNL_AUX_ANAOVRD1_D0x1622D0
+#define CNL_AUX_ANAOVRD1(pw) _MMIO(_PICK(_CNL_AUX_REG_IDX(pw), \
+ _CNL_AUX_ANAOVRD1_B, \
+ _CNL_AUX_ANAOVRD1_C, \
+ _CNL_AUX_ANAOVRD1_D))
+#define CNL_AUX_ANAOVRD1_ENABLE (1<<16)
+#define CNL_AUX_ANAOVRD1_LDO_BYPASS (1<<23)
+
/* Per-pipe DDI Function Control */
#define _TRANS_DDI_FUNC_CTL_A 0x60400
#define _TRANS_DDI_FUNC_CTL_B 0x61400
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 8315499452dc..9bf200e4885d 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -388,6 +388,15 @@ static void hsw_power_well_enable(struct drm_i915_private
*dev_priv,
I915_WRITE(HSW_PWR_WELL_CTL_DRIVER(id), val | HSW_PWR_WELL_CTL_REQ(id));
hsw_wait_for_power_well_enable(dev_priv, power_well);
+ /* WA Display #1178 */
+ if (IS_CANNONLAKE(dev_priv) &&
+ (id == CNL_DISP_PW_AUX_B || id == CNL_DISP_PW_AUX_C ||
+id == CNL_DISP_PW_AUX_D)) {
+ val = I915_READ(CNL_AUX_ANAOVRD1(id));
+ val |= CNL_AUX_ANAOVRD1_ENABLE | CNL_AUX_ANAOVRD1_LDO_BYPASS;
+ I915_WRITE(CNL_AUX_ANAOVRD1(id), val);
+ }
+
if (wait_fuses)
gen9_wait_for_power_well_fuses(dev_priv, pg);
--
2.14.3
___
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: Implement WaDisableVFclkgate.
Hi,
On Fri, Dec 1, 2017 at 3:40 PM, Rafael Antognolli
<rafael.antogno...@intel.com> wrote:
> This workaround supposedly fixes some hangs in the VF unit.
>
> Signed-off-by: Rafael Antognolli <rafael.antogno...@intel.com>
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_pm.c | 5 +
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 09bf043c1c2e..1358ce1513f6 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3875,6 +3875,9 @@ enum {
> #define SARBUNIT_CLKGATE_DIS (1 << 5)
> #define RCCUNIT_CLKGATE_DIS (1 << 7)
>
> +#define UNSLICE_UNIT_LEVEL_CLOCK _MMIO(0x9434)
I think this should follow the other names
(UNSLICE_UNIT_LEVEL_CLKGATE). Otherwise it LGTM.
Lucas De Marchi
> +#define VFUNIT_CLKGATE_DIS(1 << 20)
> +
> /*
> * Display engine regs
> */
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 67f326230a7e..87b9bdee48e5 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -8446,6 +8446,11 @@ static void cnl_init_clock_gating(struct
> drm_i915_private *dev_priv)
> if (IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0))
> val |= SARBUNIT_CLKGATE_DIS;
> I915_WRITE(SLICE_UNIT_LEVEL_CLKGATE, val);
> +
> + /* WaDisableVFclkgate:cnl */
> + val = I915_READ(UNSLICE_UNIT_LEVEL_CLOCK);
> + val |= VFUNIT_CLKGATE_DIS;
> + I915_WRITE(UNSLICE_UNIT_LEVEL_CLOCK, val);
> }
>
> static void cfl_init_clock_gating(struct drm_i915_private *dev_priv)
> --
> 2.13.6
>
> ___________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Implement WaDisableEarlyEOT.
On Fri, Dec 1, 2017 at 3:40 PM, Rafael Antognolli
<rafael.antogno...@intel.com> wrote:
> There seems to be another clock gating issue which the workaround is
> described as:
>
>"WA: Set 0xE4F0[1] = 1 to disable Early EOT of thread."
>
> Signed-off-by: Rafael Antognolli <rafael.antogno...@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demar...@intel.com>
Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_reg.h| 1 +
> drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1358ce1513f6..0f07f5900a6f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8145,6 +8145,7 @@ enum {
> #define PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE(1<<8)
> #define STALL_DOP_GATING_DISABLE (1<<5)
> #define THROTTLE_12_5(7<<2)
> +#define DISABLE_EARLY_EOT(1<<1)
>
> #define GEN7_ROW_CHICKEN2 _MMIO(0xe4f4)
> #define GEN7_ROW_CHICKEN2_GT2 _MMIO(0xf4f4)
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 86d4c85c8725..bf581a0bb789 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1272,6 +1272,9 @@ static int cnl_init_workarounds(struct intel_engine_cs
> *engine)
> if (ret)
> return ret;
>
> + /* WaDisableEarlyEOT:cnl */
> + WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN, DISABLE_EARLY_EOT);
> +
> return 0;
> }
>
> --
> 2.13.6
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915: Apply Display WA #1183 on skl, kbl, and cfl
Display WA #1183 was recently added to workaround
"Failures when enabling DPLL0 with eDP link rate 2.16
or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz
(CDCLK_CTL CD Frequency Select 10b or 11b) used in this
enabling or in previous enabling."
This workaround was designed to minimize the impact only
to save the bad case with that link rates. But HW engineers
indicated that it should be safe to apply broadly, although
they were expecting the DPLL0 link rate to be unchanged on
runtime.
We need to cover 2 cases: when we are in fact enabling DPLL0
and when we are just changing the frequency with small
differences.
This is based on previous patch by Rodrigo Vivi with suggestions
from Ville Syrjälä.
Cc: Arthur J Runyan <arthur.j.run...@intel.com>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Cc: sta...@vger.kernel.org
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_cdclk.c | 35 -
drivers/gpu/drm/i915/intel_runtime_pm.c | 10 ++
3 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 09bf043c1c2e..73335e709ed6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7021,6 +7021,7 @@ enum {
#define RESET_PCH_HANDSHAKE_ENABLE(1<<4)
#define GEN8_CHICKEN_DCPR_1_MMIO(0x46430)
+#define SKL_SELECT_ALTERNATE_DC_EXIT (1<<30)
#define MASK_WAKEMEM (1<<13)
#define SKL_DFSM _MMIO(0x51000)
@@ -8575,6 +8576,7 @@ enum skl_power_gate {
#define BXT_CDCLK_CD2X_DIV_SEL_2 (2<<22)
#define BXT_CDCLK_CD2X_DIV_SEL_4 (3<<22)
#define BXT_CDCLK_CD2X_PIPE(pipe) ((pipe)<<20)
+#define CDCLK_DIVMUX_CD_OVERRIDE (1<<19)
#define BXT_CDCLK_CD2X_PIPE_NONE BXT_CDCLK_CD2X_PIPE(3)
#define BXT_CDCLK_SSA_PRECHARGE_ENABLE(1<<16)
#define CDCLK_FREQ_DECIMAL_MASK (0x7ff)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index 9c5ceb98d48f..d77e2bec1e29 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -931,16 +931,10 @@ static void skl_set_preferred_cdclk_vco(struct
drm_i915_private *dev_priv,
static void skl_dpll0_enable(struct drm_i915_private *dev_priv, int vco)
{
- int min_cdclk = skl_calc_cdclk(0, vco);
u32 val;
WARN_ON(vco != 810 && vco != 864);
- /* select the minimum CDCLK before enabling DPLL 0 */
- val = CDCLK_FREQ_337_308 | skl_cdclk_decimal(min_cdclk);
- I915_WRITE(CDCLK_CTL, val);
- POSTING_READ(CDCLK_CTL);
-
/*
* We always enable DPLL0 with the lowest link rate possible, but still
* taking into account the VCO required to operate the eDP panel at the
@@ -994,7 +988,7 @@ static void skl_set_cdclk(struct drm_i915_private *dev_priv,
{
int cdclk = cdclk_state->cdclk;
int vco = cdclk_state->vco;
- u32 freq_select;
+ u32 freq_select, cdclk_ctl;
int ret;
mutex_lock(_priv->pcu_lock);
@@ -1009,7 +1003,7 @@ static void skl_set_cdclk(struct drm_i915_private
*dev_priv,
return;
}
- /* set CDCLK_CTL */
+ /* Choose frequency for this cdclk */
switch (cdclk) {
default:
WARN_ON(cdclk != dev_priv->cdclk.hw.ref);
@@ -1036,10 +1030,33 @@ static void skl_set_cdclk(struct drm_i915_private
*dev_priv,
dev_priv->cdclk.hw.vco != vco)
skl_dpll0_disable(dev_priv);
+ cdclk_ctl = I915_READ(CDCLK_CTL);
+
+ if (dev_priv->cdclk.hw.vco != vco) {
+ /* Wa Display #1183: skl,kbl,cfl */
+ cdclk_ctl &= ~(CDCLK_FREQ_SEL_MASK | CDCLK_FREQ_DECIMAL_MASK);
+ cdclk_ctl |= freq_select | skl_cdclk_decimal(cdclk);
+ I915_WRITE(CDCLK_CTL, cdclk_ctl);
+ }
+
+ /* Wa Display #1183: skl,kbl,cfl */
+ cdclk_ctl |= CDCLK_DIVMUX_CD_OVERRIDE;
+ I915_WRITE(CDCLK_CTL, cdclk_ctl);
+ POSTING_READ(CDCLK_CTL);
+
if (dev_priv->cdclk.hw.vco != vco)
skl_dpll0_enable(dev_priv, vco);
- I915_WRITE(CDCLK_CTL, freq_select | skl_cdclk_decimal(cdclk));
+ /* Wa Display #1183: skl,kbl,cfl */
+ cdclk_ctl &= ~(CDCLK_FREQ_SEL_MASK | CDCLK_FREQ_DECIMAL_MASK);
+ I915_WRITE(CDCLK_CTL, cdclk_ctl);
+
+ cdclk_ctl |= freq_select | skl_cdclk_decimal(cdclk);
+ I915_WRITE(CDCLK_CTL, cdclk_ctl);
+
+ /* Wa Display #1183: skl,kbl,cfl */
+ cdclk_ctl &= ~CDCLK_DIVMUX_CD_OVERRIDE;
+ I915_WRITE(CDCLK_CTL, cdclk_ctl);
POSTING_READ(CDCLK_CTL);
/* inform PCU of the change */
diff --git a/drivers/gpu/d
[Intel-gfx] [PATCH v2 2/2] drm/i915: add platform tag to WA
v2: add more missing platform tags Cc: Ville Syrjälä <ville.syrj...@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.v...@intel.com> Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com> --- drivers/gpu/drm/i915/intel_hdmi.c | 2 +- drivers/gpu/drm/i915/intel_pm.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 691600ce48c4..c42a6c672b73 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1380,7 +1380,7 @@ static bool hdmi_12bpc_possible(const struct intel_crtc_state *crtc_state) } } - /* Display WA #1139 */ + /* Display WA #1139: glk */ if (IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1) && crtc_state->base.adjusted_mode.htotal > 5460) return false; diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 07ee5ad5a13f..f3384e5f5c49 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -8417,7 +8417,7 @@ static void cnp_init_clock_gating(struct drm_i915_private *dev_priv) if (!HAS_PCH_CNP(dev_priv)) return; - /* Display WA #1181 */ + /* Display WA #1181: gen9,gen10 */ I915_WRITE(SOUTH_DSPCLK_GATE_D, I915_READ(SOUTH_DSPCLK_GATE_D) | CNP_PWM_CGE_GATING_DISABLE); } -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915: follow single notation for workaround number
v2: Allow to have or omit space before platform
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
---
drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 9d5e72728475..691600ce48c4 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1380,7 +1380,7 @@ static bool hdmi_12bpc_possible(const struct
intel_crtc_state *crtc_state)
}
}
- /* Display Wa #1139 */
+ /* Display WA #1139 */
if (IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1) &&
crtc_state->base.adjusted_mode.htotal > 5460)
return false;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 67f326230a7e..07ee5ad5a13f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -58,7 +58,7 @@ static void gen9_init_clock_gating(struct drm_i915_private
*dev_priv)
if (HAS_LLC(dev_priv)) {
/*
* WaCompressedResourceDisplayNewHashMode:skl,kbl
-* Display WA#0390: skl,kbl
+* Display WA #0390: skl,kbl
*
* Must match Sampler, Pixel Back End, and Media. See
* WaCompressedResourceSamplerPbeMediaNewHashMode.
@@ -8417,7 +8417,7 @@ static void cnp_init_clock_gating(struct drm_i915_private
*dev_priv)
if (!HAS_PCH_CNP(dev_priv))
return;
- /* Wa #1181 */
+ /* Display WA #1181 */
I915_WRITE(SOUTH_DSPCLK_GATE_D, I915_READ(SOUTH_DSPCLK_GATE_D) |
CNP_PWM_CGE_GATING_DISABLE);
}
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] x86/gpu: add CFL to early quirks
On Tue, Dec 12, 2017 at 1:53 AM, Joonas Lahtinen <joonas.lahti...@linux.intel.com> wrote: > + Jani, who'll continue with -fixes > > On Mon, 2017-12-11 at 13:50 -0800, Lucas De Marchi wrote: >> On Mon, Dec 11, 2017 at 2:26 AM, Joonas Lahtinen >> <joonas.lahti...@linux.intel.com> wrote: >> > On Fri, 2017-12-08 at 10:47 -0800, Lucas De Marchi wrote: >> > > CFL was missing from intel_early_ids[]. >> > > >> > > Cc: Ingo Molnar <mi...@kernel.org> >> > > Cc: H. Peter Anvin <h...@zytor.com> >> > > Cc: Thomas Gleixner <t...@linutronix.de> >> > > Cc: x...@kernel.org >> > > Cc: Rodrigo Vivi <rodrigo.v...@intel.com> >> > > Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com> >> > >> > This should come with a Fixes: line to be picked up to -fixes. The IDs >> >> I thought this didn't deserve CC to stable since alpha support was >> removed for CFL only for 4.15. > > I don't think system memory corruption is really acceptable even for > alpha quality support :P > >> > have been added in smaller chunks and reworked after, so backporting >> > will be required. For this level of fix, my recommendation would be to >> > actively provide a cleanly applying backports to affected stable >> > versions. >> >> Are you saying this should be proactive rather than reactive? I don't >> see this mentioned on >> Documentation/process/stable-kernel-rules.rst... the only thing I see >> there regarding patches that don't apply >> cleanly is that I may bring more patches through a tag for each version. >> >> If we are indeed going to cc stable I can submit a v2 with added tags. >> If a patch that can be cc'ed to stable >> needs to be provided we may need to improve our docs, too. > > That's correct. But once Cc:d stable, we can see from the GIT history > that it'll bounce back because it won't apply. For this specific case > that might cause system memory corruption, I'd make an exception and be > proactive. Another option would be to cherry-pick 0890540e21cf1156b4cf960a4c1c734db4e816f9 and 41693fd5237397d3c61b311af0fda1f6f39297c2 so then all commits apply cleanly. Lucas De Marchi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] x86/gpu: add CFL to early quirks
On Wed, Dec 13, 2017 at 2:11 AM, Jani Nikula <jani.nik...@linux.intel.com> wrote: > On Tue, 12 Dec 2017, Lucas De Marchi <lucas.de.mar...@gmail.com> wrote: >> On Tue, Dec 12, 2017 at 1:53 AM, Joonas Lahtinen >> <joonas.lahti...@linux.intel.com> wrote: >>> + Jani, who'll continue with -fixes >>> >>> On Mon, 2017-12-11 at 13:50 -0800, Lucas De Marchi wrote: >>>> On Mon, Dec 11, 2017 at 2:26 AM, Joonas Lahtinen >>>> <joonas.lahti...@linux.intel.com> wrote: >>>> > On Fri, 2017-12-08 at 10:47 -0800, Lucas De Marchi wrote: >>>> > > CFL was missing from intel_early_ids[]. >>>> > > >>>> > > Cc: Ingo Molnar <mi...@kernel.org> >>>> > > Cc: H. Peter Anvin <h...@zytor.com> >>>> > > Cc: Thomas Gleixner <t...@linutronix.de> >>>> > > Cc: x...@kernel.org >>>> > > Cc: Rodrigo Vivi <rodrigo.v...@intel.com> >>>> > > Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com> >>>> > >>>> > This should come with a Fixes: line to be picked up to -fixes. The IDs >>>> >>>> I thought this didn't deserve CC to stable since alpha support was >>>> removed for CFL only for 4.15. >>> >>> I don't think system memory corruption is really acceptable even for >>> alpha quality support :P >>> >>>> > have been added in smaller chunks and reworked after, so backporting >>>> > will be required. For this level of fix, my recommendation would be to >>>> > actively provide a cleanly applying backports to affected stable >>>> > versions. >>>> >>>> Are you saying this should be proactive rather than reactive? I don't >>>> see this mentioned on >>>> Documentation/process/stable-kernel-rules.rst... the only thing I see >>>> there regarding patches that don't apply >>>> cleanly is that I may bring more patches through a tag for each version. >>>> >>>> If we are indeed going to cc stable I can submit a v2 with added tags. >>>> If a patch that can be cc'ed to stable >>>> needs to be provided we may need to improve our docs, too. >>> >>> That's correct. But once Cc:d stable, we can see from the GIT history >>> that it'll bounce back because it won't apply. For this specific case >>> that might cause system memory corruption, I'd make an exception and be >>> proactive. >> >> Another option would be to cherry-pick >> 0890540e21cf1156b4cf960a4c1c734db4e816f9 and >> 41693fd5237397d3c61b311af0fda1f6f39297c2 so then all commits apply cleanly. > > There's a cc: stable annotation for dependencies like that, see stable Yep, that's why I suggested the alternative. I think bring those commits to stable will be better because they will always cause conflicts on future backports. If we have them applied it will make future backports to apply cleanly rather than needing to diverge more from master. > kernel rules. I think Greg has stated a preference for picking up > dependencies rather than having manually backported patches. Great. I will follow that approach for v2. thanks Lucas De Marchi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] x86/gpu: add CFL to early quirks
CFL was missing from intel_early_ids[]. The PCI ID needs to be there to
allow the memory region to be stolen, otherwise we could have RAM being
arbitrarily overwritten if for example we keep using the UEFI framebuffer,
depending on how BIOS has set up the e820 map.
Fixes: b056f8f3d6b9 ("drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.")
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Cc: Anusha Srivatsa <anusha.sriva...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Cc: David Airlie <airl...@linux.ie>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: Ingo Molnar <mi...@kernel.org>
Cc: H. Peter Anvin <h...@zytor.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: x...@kernel.org
Cc: <sta...@vger.kernel.org> # v4.13+ 0890540e21cf drm/i915: add GT number to
intel_device_info
Cc: <sta...@vger.kernel.org> # v4.13+ 41693fd52373 drm/i915/kbl: Change a KBL
pci id to GT2 from GT1.5
Cc: <sta...@vger.kernel.org> # v4.13+
Reviewed-by: Rodrigo Vivi <rodrigo.v...@intel.com>
---
v2: improve commit message, add Fixes tag and CC stable
arch/x86/kernel/early-quirks.c | 1 +
include/drm/i915_pciids.h | 6 ++
2 files changed, 7 insertions(+)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 3cbb2c78a9df..bae0d32e327b 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -528,6 +528,7 @@ static const struct pci_device_id intel_early_ids[]
__initconst = {
INTEL_SKL_IDS(_early_ops),
INTEL_BXT_IDS(_early_ops),
INTEL_KBL_IDS(_early_ops),
+ INTEL_CFL_IDS(_early_ops),
INTEL_GLK_IDS(_early_ops),
INTEL_CNL_IDS(_early_ops),
};
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 972a25633525..c65e4489006d 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -392,6 +392,12 @@
INTEL_VGA_DEVICE(0x3EA8, info), /* ULT GT3 */ \
INTEL_VGA_DEVICE(0x3EA5, info) /* ULT GT3 */
+#define INTEL_CFL_IDS(info) \
+ INTEL_CFL_S_GT1_IDS(info), \
+ INTEL_CFL_S_GT2_IDS(info), \
+ INTEL_CFL_H_GT2_IDS(info), \
+ INTEL_CFL_U_GT3_IDS(info)
+
/* CNL U 2+2 */
#define INTEL_CNL_U_GT2_IDS(info) \
INTEL_VGA_DEVICE(0x5A52, info), \
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix function name in comment
Commit 78597996370c (drm/i915/bxt: Fix PPS lost state after suspend breaking eDP link training) renamed the function to intel_power_sequencer_reset() but forgot to update comment. Cc: Imre Deak <imre.d...@intel.com> Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com> --- drivers/gpu/drm/i915/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index efe18269115f..c9c416389d0e 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -441,7 +441,7 @@ static void pps_lock(struct intel_dp *intel_dp) struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp)); /* -* See vlv_power_sequencer_reset() why we need +* See intel_power_sequencer_reset() why we need * a power domain reference here. */ intel_display_power_get(dev_priv, intel_dp->aux_power_domain); -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5] drm/i915: Apply Wa Display #1183 on skl, kbl, and cfl
Wa Display #1183 was recently added to workaround
"Failures when enabling DPLL0 with eDP link rate 2.16
or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz
(CDCLK_CTL CD Frequency Select 10b or 11b) used in this
enabling or in previous enabling."
This Workaround was designed to minimize the impact only
to save the bad case with that link rates. But HW engineers
indicated that it should be safe to apply broadly, although
they were expecting the DPLL0 link rate to be unchanged on
runtime.
We need to cover 2 cases: when we are in fact enabling DPLL0
and when we are just changing the frequency with small
differences.
This is based on previous patch by Rodrigo Vivi with suggestions
from Ville Syrjälä.
Cc: Arthur J Runyan <arthur.j.run...@intel.com>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_cdclk.c | 36 -
drivers/gpu/drm/i915/intel_runtime_pm.c | 10 +
3 files changed, 38 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 96c80fa0fcac..6dd3538c2074 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7018,6 +7018,7 @@ enum {
#define RESET_PCH_HANDSHAKE_ENABLE(1<<4)
#define GEN8_CHICKEN_DCPR_1_MMIO(0x46430)
+#define SKL_SELECT_ALTERNATE_DC_EXIT (1<<30)
#define MASK_WAKEMEM (1<<13)
#define SKL_DFSM _MMIO(0x51000)
@@ -8572,6 +8573,7 @@ enum skl_power_gate {
#define BXT_CDCLK_CD2X_DIV_SEL_2 (2<<22)
#define BXT_CDCLK_CD2X_DIV_SEL_4 (3<<22)
#define BXT_CDCLK_CD2X_PIPE(pipe) ((pipe)<<20)
+#define CDCLK_DIVMUX_CD_OVERRIDE (1<<19)
#define BXT_CDCLK_CD2X_PIPE_NONE BXT_CDCLK_CD2X_PIPE(3)
#define BXT_CDCLK_SSA_PRECHARGE_ENABLE(1<<16)
#define CDCLK_FREQ_DECIMAL_MASK (0x7ff)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index e8884c2ade98..7f899a0e1e4a 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -931,16 +931,10 @@ static void skl_set_preferred_cdclk_vco(struct
drm_i915_private *dev_priv,
static void skl_dpll0_enable(struct drm_i915_private *dev_priv, int vco)
{
- int min_cdclk = skl_calc_cdclk(0, vco);
u32 val;
WARN_ON(vco != 810 && vco != 864);
- /* select the minimum CDCLK before enabling DPLL 0 */
- val = CDCLK_FREQ_337_308 | skl_cdclk_decimal(min_cdclk);
- I915_WRITE(CDCLK_CTL, val);
- POSTING_READ(CDCLK_CTL);
-
/*
* We always enable DPLL0 with the lowest link rate possible, but still
* taking into account the VCO required to operate the eDP panel at the
@@ -994,7 +988,7 @@ static void skl_set_cdclk(struct drm_i915_private *dev_priv,
{
int cdclk = cdclk_state->cdclk;
int vco = cdclk_state->vco;
- u32 freq_select;
+ u32 freq_select, cdclk_ctl;
int ret;
mutex_lock(_priv->pcu_lock);
@@ -1009,7 +1003,7 @@ static void skl_set_cdclk(struct drm_i915_private
*dev_priv,
return;
}
- /* set CDCLK_CTL */
+ /* Choose frequency for this cdclk */
switch (cdclk) {
default:
WARN_ON(cdclk != dev_priv->cdclk.hw.ref);
@@ -1036,11 +1030,33 @@ static void skl_set_cdclk(struct drm_i915_private
*dev_priv,
dev_priv->cdclk.hw.vco != vco)
skl_dpll0_disable(dev_priv);
+ cdclk_ctl = I915_READ(CDCLK_CTL);
+
+ if (dev_priv->cdclk.hw.vco != vco) {
+ /* Wa Display #1183: skl,kbl,cfl */
+ cdclk_ctl &= ~(CDCLK_FREQ_SEL_MASK | CDCLK_FREQ_DECIMAL_MASK);
+ cdclk_ctl |= freq_select | skl_cdclk_decimal(cdclk);
+ I915_WRITE(CDCLK_CTL, cdclk_ctl);
+ }
+
+ /* Wa Display #1183: skl,kbl,cfl */
+ cdclk_ctl |= CDCLK_DIVMUX_CD_OVERRIDE;
+ I915_WRITE(CDCLK_CTL, cdclk_ctl);
+ POSTING_READ(CDCLK_CTL);
+
if (dev_priv->cdclk.hw.vco != vco)
skl_dpll0_enable(dev_priv, vco);
- I915_WRITE(CDCLK_CTL, freq_select | skl_cdclk_decimal(cdclk));
- POSTING_READ(CDCLK_CTL);
+ /* Wa Display #1183: skl,kbl,cfl */
+ cdclk_ctl &= ~(CDCLK_FREQ_SEL_MASK | CDCLK_FREQ_DECIMAL_MASK);
+ I915_WRITE(CDCLK_CTL, cdclk_ctl);
+
+ cdclk_ctl |= freq_select | skl_cdclk_decimal(cdclk);
+ I915_WRITE(CDCLK_CTL, cdclk_ctl);
+
+ /* Wa Display #1183: skl,kbl,cfl */
+ cdclk_ctl &= ~CDCLK_DIVMUX_CD_OVERRIDE;
+ I915_WRITE(CDCLK_CTL, cdclk_ctl);
/* inform PCU of the change */
mutex_lock(_priv->pcu_lock);
diff --gi
Re: [Intel-gfx] [PATCH v3] drm/i915: Apply Wa Display #1183 on skl, kbl, and cfl
On Tue, Nov 14, 2017 at 5:10 AM, Ville Syrjälä
<ville.syrj...@linux.intel.com> wrote:
> On Mon, Nov 13, 2017 at 01:47:26PM -0800, Lucas De Marchi wrote:
>> Hi Ville,
>>
>> On Thu, Nov 9, 2017 at 8:58 AM, Ville Syrjälä
>> <ville.syrj...@linux.intel.com> wrote:
>> > On Thu, Nov 09, 2017 at 08:02:40AM -0800, Lucas De Marchi wrote:
>> >> On Thu, Nov 9, 2017 at 5:11 AM, Ville Syrjälä
>> >> <ville.syrj...@linux.intel.com> wrote:
>> >> > On Thu, Nov 09, 2017 at 02:58:04AM -0800, Lucas De Marchi wrote:
>> >> >> Wa Display #1183 was recently added to workaround
>> >> >> "Failures when enabling DPLL0 with eDP link rate 2.16
>> >> >> or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz
>> >> >> (CDCLK_CTL CD Frequency Select 10b or 11b) used in this
>> >> >> enabling or in previous enabling."
>> >> >>
>> >> >> This Workaround was designed to minimize the impact only
>> >> >> to save the bad case with that link rates. But HW engineers
>> >> >> indicated that it should be safe to apply broadly. Although
>> >> >> they were expecting the DPLL0 link rate to be unchanged on
>> >> >> runtime.
>> >> >>
>> >> >> We need to cover 2 cases: when we are in fact enabling DPLL0
>> >> >> and when we are just changing the frequency. The workaround
>> >> >> for those cases are similar but different enough to have them
>> >> >> done in different places.
>> >> >>
>> >> >> This is based on previous patch by Rodrigo Vivi with suggestions
>> >> >> from Ville Syrjälä.
>> >> >
>> >> > Still doesn't look like what I suggested.
>> >>
>> >> I agree with your suggestion of moving stuff to skl_set_cdclk() to
>> >> cover the case in which
>> >> vco isn't changing. However see the paragraph I added above on why I
>> >> need to do it
>> >> differently. In short: the sequence on the WA for enabling and
>> >> updating cdclck are different,
>> >> with some code duplication unfortunately. I don't see you covering
>> >> that case in your
>> >> suggestion. Have I missed anything?
>> >
>> > Even if we follow the spec literally I think we can do it all
>> > in skl_set_cdclk(). I think the following should dtrt:
>>
>> There are some subtle differences wrt to the initialize and update
>> sequences according to the WA
>> that I'd like to clarify.
>>
>> >
>> > pcu start
>> >
>> > if (...)
>> > disable_dpll0()
>> >
>> > cdclk_sel = real
>>
>> We should only do this if we are enabling, but not when updating. In
>> the latter case
>> cdclk_sel should only be touched after setting divmux to 1.
>
> Seems like a pointless distinction to me. We'll be doing the 0->real
> toggle anyway while divmux_override==1. But if we want to be pedantic,
> then we could of course just skip this if the DPLL is already enabled.
>
>>
>> >
>> > if (need_wa)
>> > divmux=1
>>
>> Reading the WA to the letter, in the enabling case this should happen between
>> DPLL_CTRL1 and LCPLL1_CTL are written. Here you are moving it to happen
>> before
>> the write to DPLL_CTRL1.
>
> I assume that until the DPLL is enabled the settings in DPLL_CTRL1
> don't actually matter.
>
>>
>> >
>> > if (...)
>> > enable_dpll0()
>> >
>> > if (need_wa) {
>> > cdclk_sel = 0
>> > cdclk_sel = real
>>
>> When updating we should set both freq_sel and and freq_decimal. When
>> enabling, only freq_sel (but I guess
>> it doesn't matter since we set this same register above).
>
> I think the implication is just that the "decimal" frequency doesn't
> matter until something actually starts to use cdclk. The safe bet
> would be to always program it to match the frequency select.
>
>>
>>
>> > divmux=0
>> > }
>>
>> With this sequence you would actually not change the frequency for the
>> cases in which the WA is not
>> required. AFAIU from previous version of this patch it's ok to always
>> follow the WA path so we wouldn't
>> have a "need_wa". Is that ok? I can come up with a patch that shares
>> more code, but I don't think your
>> approach is following the spec literally.
>
> Yeah, the exact conditions for need_wa seem a bit unlcear to me since it
> says "... used in this enabling or in previous enabling". I'm not sure
> if it's referring to the DPLL or CDCLK frequency or both. Maybe safer to
> just always follow the w/a sequence.
Ok. I thought it would be better to follow the exact steps from the WA
as I actually
couldn't reproduce the bug. I implemented what you said and tested
both approaches
to check it's not regressing. I will submit a new version with your
comments addressed.
thanks
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915: Apply Wa Display #1183 on skl, kbl, and cfl
Wa Display #1183 was recently added to workaround
"Failures when enabling DPLL0 with eDP link rate 2.16
or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz
(CDCLK_CTL CD Frequency Select 10b or 11b) used in this
enabling or in previous enabling."
This Workaround was designed to minimize the impact only
to save the bad case with that link rates. But HW engineers
indicated that it should be safe to apply broadly, although
they were expecting the DPLL0 link rate to be unchanged on
runtime.
We need to cover 2 cases: when we are in fact enabling DPLL0
and when we are just changing the frequency with small
differences.
This is based on previous patch by Rodrigo Vivi with suggestions
from Ville Syrjälä.
Cc: Arthur J Runyan <arthur.j.run...@intel.com>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_cdclk.c | 44 +++--
drivers/gpu/drm/i915/intel_runtime_pm.c | 10
3 files changed, 43 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cfdf4f821ac3..b0a1bf5f549c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7019,6 +7019,7 @@ enum {
#define RESET_PCH_HANDSHAKE_ENABLE(1<<4)
#define GEN8_CHICKEN_DCPR_1_MMIO(0x46430)
+#define SKL_SELECT_ALTERNATE_DC_EXIT (1<<30)
#define MASK_WAKEMEM (1<<13)
#define SKL_DFSM _MMIO(0x51000)
@@ -8573,6 +8574,7 @@ enum skl_power_gate {
#define BXT_CDCLK_CD2X_DIV_SEL_2 (2<<22)
#define BXT_CDCLK_CD2X_DIV_SEL_4 (3<<22)
#define BXT_CDCLK_CD2X_PIPE(pipe) ((pipe)<<20)
+#define CDCLK_DIVMUX_CD_OVERRIDE (1<<19)
#define BXT_CDCLK_CD2X_PIPE_NONE BXT_CDCLK_CD2X_PIPE(3)
#define BXT_CDCLK_SSA_PRECHARGE_ENABLE(1<<16)
#define CDCLK_FREQ_DECIMAL_MASK (0x7ff)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index e8884c2ade98..0a995c0f955e 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -931,16 +931,10 @@ static void skl_set_preferred_cdclk_vco(struct
drm_i915_private *dev_priv,
static void skl_dpll0_enable(struct drm_i915_private *dev_priv, int vco)
{
- int min_cdclk = skl_calc_cdclk(0, vco);
u32 val;
WARN_ON(vco != 810 && vco != 864);
- /* select the minimum CDCLK before enabling DPLL 0 */
- val = CDCLK_FREQ_337_308 | skl_cdclk_decimal(min_cdclk);
- I915_WRITE(CDCLK_CTL, val);
- POSTING_READ(CDCLK_CTL);
-
/*
* We always enable DPLL0 with the lowest link rate possible, but still
* taking into account the VCO required to operate the eDP panel at the
@@ -994,7 +988,8 @@ static void skl_set_cdclk(struct drm_i915_private *dev_priv,
{
int cdclk = cdclk_state->cdclk;
int vco = cdclk_state->vco;
- u32 freq_select;
+ u32 freq_select, cdclk_ctl;
+ bool need_dpll0_enable;
int ret;
mutex_lock(_priv->pcu_lock);
@@ -1009,7 +1004,7 @@ static void skl_set_cdclk(struct drm_i915_private
*dev_priv,
return;
}
- /* set CDCLK_CTL */
+ /* Choose frequency for this cdclk */
switch (cdclk) {
default:
WARN_ON(cdclk != dev_priv->cdclk.hw.ref);
@@ -1032,16 +1027,39 @@ static void skl_set_cdclk(struct drm_i915_private
*dev_priv,
break;
}
- if (dev_priv->cdclk.hw.vco != 0 &&
- dev_priv->cdclk.hw.vco != vco)
+ need_dpll0_enable = dev_priv->cdclk.hw.vco != vco;
+
+ if (dev_priv->cdclk.hw.vco != 0 && need_dpll0_enable)
skl_dpll0_disable(dev_priv);
- if (dev_priv->cdclk.hw.vco != vco)
- skl_dpll0_enable(dev_priv, vco);
+ cdclk_ctl = I915_READ(CDCLK_CTL);
+ cdclk_ctl &= ~(CDCLK_FREQ_SEL_MASK | CDCLK_FREQ_DECIMAL_MASK);
- I915_WRITE(CDCLK_CTL, freq_select | skl_cdclk_decimal(cdclk));
+ if (need_dpll0_enable) {
+ /* Wa Display #1183: skl,kbl,cfl */
+ cdclk_ctl |= freq_select | skl_cdclk_decimal(cdclk);
+ I915_WRITE(CDCLK_CTL, cdclk_ctl);
+ }
+
+ /* Wa Display #1183: skl,kbl,cfl */
+ cdclk_ctl |= CDCLK_DIVMUX_CD_OVERRIDE;
+ I915_WRITE(CDCLK_CTL, cdclk_ctl);
POSTING_READ(CDCLK_CTL);
+ if (need_dpll0_enable)
+ skl_dpll0_enable(dev_priv, vco);
+
+ /* Wa Display #1183: skl,kbl,cfl */
+ cdclk_ctl &= ~(CDCLK_FREQ_SEL_MASK | CDCLK_FREQ_DECIMAL_MASK);
+ I915_WRITE(CDCLK_CTL, cdclk_ctl);
+
+ cdclk_ctl |= freq_select | skl_cdclk_decimal(c
Re: [Intel-gfx] [PATCH v3] drm/i915: Apply Wa Display #1183 on skl, kbl, and cfl
Hi Ville,
On Thu, Nov 9, 2017 at 8:58 AM, Ville Syrjälä
<ville.syrj...@linux.intel.com> wrote:
> On Thu, Nov 09, 2017 at 08:02:40AM -0800, Lucas De Marchi wrote:
>> On Thu, Nov 9, 2017 at 5:11 AM, Ville Syrjälä
>> <ville.syrj...@linux.intel.com> wrote:
>> > On Thu, Nov 09, 2017 at 02:58:04AM -0800, Lucas De Marchi wrote:
>> >> Wa Display #1183 was recently added to workaround
>> >> "Failures when enabling DPLL0 with eDP link rate 2.16
>> >> or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz
>> >> (CDCLK_CTL CD Frequency Select 10b or 11b) used in this
>> >> enabling or in previous enabling."
>> >>
>> >> This Workaround was designed to minimize the impact only
>> >> to save the bad case with that link rates. But HW engineers
>> >> indicated that it should be safe to apply broadly. Although
>> >> they were expecting the DPLL0 link rate to be unchanged on
>> >> runtime.
>> >>
>> >> We need to cover 2 cases: when we are in fact enabling DPLL0
>> >> and when we are just changing the frequency. The workaround
>> >> for those cases are similar but different enough to have them
>> >> done in different places.
>> >>
>> >> This is based on previous patch by Rodrigo Vivi with suggestions
>> >> from Ville Syrjälä.
>> >
>> > Still doesn't look like what I suggested.
>>
>> I agree with your suggestion of moving stuff to skl_set_cdclk() to
>> cover the case in which
>> vco isn't changing. However see the paragraph I added above on why I
>> need to do it
>> differently. In short: the sequence on the WA for enabling and
>> updating cdclck are different,
>> with some code duplication unfortunately. I don't see you covering
>> that case in your
>> suggestion. Have I missed anything?
>
> Even if we follow the spec literally I think we can do it all
> in skl_set_cdclk(). I think the following should dtrt:
There are some subtle differences wrt to the initialize and update
sequences according to the WA
that I'd like to clarify.
>
> pcu start
>
> if (...)
> disable_dpll0()
>
> cdclk_sel = real
We should only do this if we are enabling, but not when updating. In
the latter case
cdclk_sel should only be touched after setting divmux to 1.
>
> if (need_wa)
> divmux=1
Reading the WA to the letter, in the enabling case this should happen between
DPLL_CTRL1 and LCPLL1_CTL are written. Here you are moving it to happen before
the write to DPLL_CTRL1.
>
> if (...)
> enable_dpll0()
>
> if (need_wa) {
> cdclk_sel = 0
> cdclk_sel = real
When updating we should set both freq_sel and and freq_decimal. When
enabling, only freq_sel (but I guess
it doesn't matter since we set this same register above).
> divmux=0
> }
With this sequence you would actually not change the frequency for the
cases in which the WA is not
required. AFAIU from previous version of this patch it's ok to always
follow the WA path so we wouldn't
have a "need_wa". Is that ok? I can come up with a patch that shares
more code, but I don't think your
approach is following the spec literally.
thanks
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Apply Wa Display #1183 on skl, kbl, and cfl
Wa Display #1183 was recently added to workaround
"Failures when enabling DPLL0 with eDP link rate 2.16
or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz
(CDCLK_CTL CD Frequency Select 10b or 11b) used in this
enabling or in previous enabling."
This Workaround was designed to minimize the impact only
to save the bad case with that link rates. But HW engineers
indicated that it should be safe to apply broadly. Although
they were expecting the DPLL0 link rate to be unchanged on
runtime.
We need to cover 2 cases: when we are in fact enabling DPLL0
and when we are just changing the frequency. The workaround
for those cases are similar but different enough to have them
done in different places.
This is based on previous patch by Rodrigo Vivi with suggestions
from Ville Syrjälä.
Cc: Arthur J Runyan <arthur.j.run...@intel.com>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
---
I tried to test this but both on SKL and KBL that I have the bug that requires
the WA isn't triggered.
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_cdclk.c | 51 ++---
drivers/gpu/drm/i915/intel_runtime_pm.c | 10 +++
3 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6ef33422f762..a32d8200bb47 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6981,6 +6981,7 @@ enum {
#define RESET_PCH_HANDSHAKE_ENABLE(1<<4)
#define GEN8_CHICKEN_DCPR_1_MMIO(0x46430)
+#define SKL_SELECT_ALTERNATE_DC_EXIT (1<<30)
#define MASK_WAKEMEM (1<<13)
#define SKL_DFSM _MMIO(0x51000)
@@ -8535,6 +8536,7 @@ enum skl_power_gate {
#define BXT_CDCLK_CD2X_DIV_SEL_2 (2<<22)
#define BXT_CDCLK_CD2X_DIV_SEL_4 (3<<22)
#define BXT_CDCLK_CD2X_PIPE(pipe) ((pipe)<<20)
+#define CDCLK_DIVMUX_CD_OVERRIDE (1<<19)
#define BXT_CDCLK_CD2X_PIPE_NONE BXT_CDCLK_CD2X_PIPE(3)
#define BXT_CDCLK_SSA_PRECHARGE_ENABLE(1<<16)
#define CDCLK_FREQ_DECIMAL_MASK (0x7ff)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index e8884c2ade98..5e6fc2602711 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -929,17 +929,18 @@ static void skl_set_preferred_cdclk_vco(struct
drm_i915_private *dev_priv,
intel_update_max_cdclk(dev_priv);
}
-static void skl_dpll0_enable(struct drm_i915_private *dev_priv, int vco)
+static void skl_dpll0_enable(struct drm_i915_private *dev_priv, int vco,
+u32 freq_select, u32 cdclk)
{
- int min_cdclk = skl_calc_cdclk(0, vco);
- u32 val;
+ u32 val, cdctl;
WARN_ON(vco != 810 && vco != 864);
- /* select the minimum CDCLK before enabling DPLL 0 */
- val = CDCLK_FREQ_337_308 | skl_cdclk_decimal(min_cdclk);
- I915_WRITE(CDCLK_CTL, val);
- POSTING_READ(CDCLK_CTL);
+ /* Wa Display #1183: skl,kbl,cfl */
+ cdctl = I915_READ(CDCLK_CTL);
+ cdctl &= ~(CDCLK_FREQ_SEL_MASK | CDCLK_FREQ_DECIMAL_MASK);
+ cdctl |= freq_select | skl_cdclk_decimal(cdclk);
+ I915_WRITE(CDCLK_CTL, cdctl);
/*
* We always enable DPLL0 with the lowest link rate possible, but still
@@ -965,6 +966,10 @@ static void skl_dpll0_enable(struct drm_i915_private
*dev_priv, int vco)
I915_WRITE(DPLL_CTRL1, val);
POSTING_READ(DPLL_CTRL1);
+ /* Wa Display #1183: skl,kbl,cfl */
+ cdctl |= CDCLK_DIVMUX_CD_OVERRIDE;
+ I915_WRITE(CDCLK_CTL, cdctl);
+
I915_WRITE(LCPLL1_CTL, I915_READ(LCPLL1_CTL) | LCPLL_PLL_ENABLE);
if (intel_wait_for_register(dev_priv,
@@ -972,6 +977,17 @@ static void skl_dpll0_enable(struct drm_i915_private
*dev_priv, int vco)
5))
DRM_ERROR("DPLL0 not locked\n");
+ /* Wa Display #1183: skl,kbl,cfl */
+ cdctl &= ~CDCLK_FREQ_SEL_MASK;
+ I915_WRITE(CDCLK_CTL, cdctl);
+
+ cdctl |= freq_select;
+ I915_WRITE(CDCLK_CTL, cdctl);
+
+ cdctl &= ~CDCLK_DIVMUX_CD_OVERRIDE;
+ I915_WRITE(CDCLK_CTL, cdctl);
+ POSTING_READ(CDCLK_CTL);
+
dev_priv->cdclk.hw.vco = vco;
/* We'll want to keep using the current vco from now on. */
@@ -1037,10 +1053,25 @@ static void skl_set_cdclk(struct drm_i915_private
*dev_priv,
skl_dpll0_disable(dev_priv);
if (dev_priv->cdclk.hw.vco != vco)
- skl_dpll0_enable(dev_priv, vco);
+ skl_dpll0_enable(dev_priv, vco, freq_select, cdclk);
+ else {
+ u32 cdctl = I915_READ(CDCLK_CTL);
- I915_WRITE(CD
Re: [Intel-gfx] [PATCH v3] drm/i915: Apply Wa Display #1183 on skl, kbl, and cfl
On Thu, Nov 9, 2017 at 5:11 AM, Ville Syrjälä
<ville.syrj...@linux.intel.com> wrote:
> On Thu, Nov 09, 2017 at 02:58:04AM -0800, Lucas De Marchi wrote:
>> Wa Display #1183 was recently added to workaround
>> "Failures when enabling DPLL0 with eDP link rate 2.16
>> or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz
>> (CDCLK_CTL CD Frequency Select 10b or 11b) used in this
>> enabling or in previous enabling."
>>
>> This Workaround was designed to minimize the impact only
>> to save the bad case with that link rates. But HW engineers
>> indicated that it should be safe to apply broadly. Although
>> they were expecting the DPLL0 link rate to be unchanged on
>> runtime.
>>
>> We need to cover 2 cases: when we are in fact enabling DPLL0
>> and when we are just changing the frequency. The workaround
>> for those cases are similar but different enough to have them
>> done in different places.
>>
>> This is based on previous patch by Rodrigo Vivi with suggestions
>> from Ville Syrjälä.
>
> Still doesn't look like what I suggested.
I agree with your suggestion of moving stuff to skl_set_cdclk() to
cover the case in which
vco isn't changing. However see the paragraph I added above on why I
need to do it
differently. In short: the sequence on the WA for enabling and
updating cdclck are different,
with some code duplication unfortunately. I don't see you covering
that case in your
suggestion. Have I missed anything?
Lucas De Marchi
>
>>
>> Cc: Arthur J Runyan <arthur.j.run...@intel.com>
>> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
>> Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
>> Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
>> ---
>>
>> I tried to test this but both on SKL and KBL that I have the bug that
>> requires
>> the WA isn't triggered.
>>
>> drivers/gpu/drm/i915/i915_reg.h | 2 ++
>> drivers/gpu/drm/i915/intel_cdclk.c | 51
>> ++---
>> drivers/gpu/drm/i915/intel_runtime_pm.c | 10 +++
>> 3 files changed, 53 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 6ef33422f762..a32d8200bb47 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -6981,6 +6981,7 @@ enum {
>> #define RESET_PCH_HANDSHAKE_ENABLE (1<<4)
>>
>> #define GEN8_CHICKEN_DCPR_1 _MMIO(0x46430)
>> +#define SKL_SELECT_ALTERNATE_DC_EXIT (1<<30)
>> #define MASK_WAKEMEM (1<<13)
>>
>> #define SKL_DFSM _MMIO(0x51000)
>> @@ -8535,6 +8536,7 @@ enum skl_power_gate {
>> #define BXT_CDCLK_CD2X_DIV_SEL_2(2<<22)
>> #define BXT_CDCLK_CD2X_DIV_SEL_4(3<<22)
>> #define BXT_CDCLK_CD2X_PIPE(pipe) ((pipe)<<20)
>> +#define CDCLK_DIVMUX_CD_OVERRIDE(1<<19)
>> #define BXT_CDCLK_CD2X_PIPE_NONEBXT_CDCLK_CD2X_PIPE(3)
>> #define BXT_CDCLK_SSA_PRECHARGE_ENABLE (1<<16)
>> #define CDCLK_FREQ_DECIMAL_MASK (0x7ff)
>> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
>> b/drivers/gpu/drm/i915/intel_cdclk.c
>> index e8884c2ade98..5e6fc2602711 100644
>> --- a/drivers/gpu/drm/i915/intel_cdclk.c
>> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
>> @@ -929,17 +929,18 @@ static void skl_set_preferred_cdclk_vco(struct
>> drm_i915_private *dev_priv,
>> intel_update_max_cdclk(dev_priv);
>> }
>>
>> -static void skl_dpll0_enable(struct drm_i915_private *dev_priv, int vco)
>> +static void skl_dpll0_enable(struct drm_i915_private *dev_priv, int vco,
>> + u32 freq_select, u32 cdclk)
>> {
>> - int min_cdclk = skl_calc_cdclk(0, vco);
>> - u32 val;
>> + u32 val, cdctl;
>>
>> WARN_ON(vco != 810 && vco != 864);
>>
>> - /* select the minimum CDCLK before enabling DPLL 0 */
>> - val = CDCLK_FREQ_337_308 | skl_cdclk_decimal(min_cdclk);
>> - I915_WRITE(CDCLK_CTL, val);
>> - POSTING_READ(CDCLK_CTL);
>> + /* Wa Display #1183: skl,kbl,cfl */
>> + cdctl = I915_READ(CDCLK_CTL);
>> + cdctl &= ~(CDCLK_FREQ_SEL_MASK | CDCLK_FREQ_DECIMAL_MASK);
>> + cdctl |= freq_select | skl_cdclk_decimal(cdclk);
>> + I915_WRITE(CDCLK_CTL, cdctl);
>>
>> /*
>>* We always enable DPLL0 with the lowest link rate possible, but still
>> @@ -965,6 +966,10 @@ static void s
[Intel-gfx] [PATCH v3 1/2] drm/i915: follow single notation for workaround number
v2: Allow to have or omit space before platform
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.v...@intel.com>
---
drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 9d5e72728475..691600ce48c4 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1380,7 +1380,7 @@ static bool hdmi_12bpc_possible(const struct
intel_crtc_state *crtc_state)
}
}
- /* Display Wa #1139 */
+ /* Display WA #1139 */
if (IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1) &&
crtc_state->base.adjusted_mode.htotal > 5460)
return false;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 67f326230a7e..07ee5ad5a13f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -58,7 +58,7 @@ static void gen9_init_clock_gating(struct drm_i915_private
*dev_priv)
if (HAS_LLC(dev_priv)) {
/*
* WaCompressedResourceDisplayNewHashMode:skl,kbl
-* Display WA#0390: skl,kbl
+* Display WA #0390: skl,kbl
*
* Must match Sampler, Pixel Back End, and Media. See
* WaCompressedResourceSamplerPbeMediaNewHashMode.
@@ -8417,7 +8417,7 @@ static void cnp_init_clock_gating(struct drm_i915_private
*dev_priv)
if (!HAS_PCH_CNP(dev_priv))
return;
- /* Wa #1181 */
+ /* Display WA #1181 */
I915_WRITE(SOUTH_DSPCLK_GATE_D, I915_READ(SOUTH_DSPCLK_GATE_D) |
CNP_PWM_CGE_GATING_DISABLE);
}
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/2] drm/i915: add platform tag to WA
v2: add more missing platform tags v3: change tag to cnp rather than using gen9,gen10 Cc: Ville Syrjälä <ville.syrj...@linux.intel.com> Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.v...@intel.com> --- drivers/gpu/drm/i915/intel_hdmi.c | 2 +- drivers/gpu/drm/i915/intel_pm.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 691600ce48c4..c42a6c672b73 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1380,7 +1380,7 @@ static bool hdmi_12bpc_possible(const struct intel_crtc_state *crtc_state) } } - /* Display WA #1139 */ + /* Display WA #1139: glk */ if (IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1) && crtc_state->base.adjusted_mode.htotal > 5460) return false; diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 07ee5ad5a13f..5836181d6f8a 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -8417,7 +8417,7 @@ static void cnp_init_clock_gating(struct drm_i915_private *dev_priv) if (!HAS_PCH_CNP(dev_priv)) return; - /* Display WA #1181 */ + /* Display WA #1181: cnp */ I915_WRITE(SOUTH_DSPCLK_GATE_D, I915_READ(SOUTH_DSPCLK_GATE_D) | CNP_PWM_CGE_GATING_DISABLE); } -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] x86/gpu: add CFL to early quirks
CFL was missing from intel_early_ids[].
Cc: Ingo Molnar <mi...@kernel.org>
Cc: H. Peter Anvin <h...@zytor.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: x...@kernel.org
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
---
Like it was done for other platforms, ideally we should get an ack from x86
maintainers and apply this through the drm-intel tree.
arch/x86/kernel/early-quirks.c | 1 +
include/drm/i915_pciids.h | 6 ++
2 files changed, 7 insertions(+)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 1e82f787c160..c87560e1e3ef 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -527,6 +527,7 @@ static const struct pci_device_id intel_early_ids[]
__initconst = {
INTEL_SKL_IDS(_early_ops),
INTEL_BXT_IDS(_early_ops),
INTEL_KBL_IDS(_early_ops),
+ INTEL_CFL_IDS(_early_ops),
INTEL_GLK_IDS(_early_ops),
INTEL_CNL_IDS(_early_ops),
};
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 972a25633525..c65e4489006d 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -392,6 +392,12 @@
INTEL_VGA_DEVICE(0x3EA8, info), /* ULT GT3 */ \
INTEL_VGA_DEVICE(0x3EA5, info) /* ULT GT3 */
+#define INTEL_CFL_IDS(info) \
+ INTEL_CFL_S_GT1_IDS(info), \
+ INTEL_CFL_S_GT2_IDS(info), \
+ INTEL_CFL_H_GT2_IDS(info), \
+ INTEL_CFL_U_GT3_IDS(info)
+
/* CNL U 2+2 */
#define INTEL_CNL_U_GT2_IDS(info) \
INTEL_VGA_DEVICE(0x5A52, info), \
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] x86/gpu: add CFL to early quirks
On Mon, Dec 11, 2017 at 2:26 AM, Joonas Lahtinen
<joonas.lahti...@linux.intel.com> wrote:
> On Fri, 2017-12-08 at 10:47 -0800, Lucas De Marchi wrote:
>> CFL was missing from intel_early_ids[].
>>
>> Cc: Ingo Molnar <mi...@kernel.org>
>> Cc: H. Peter Anvin <h...@zytor.com>
>> Cc: Thomas Gleixner <t...@linutronix.de>
>> Cc: x...@kernel.org
>> Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
>> Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
>
> This should come with a Fixes: line to be picked up to -fixes. The IDs
I thought this didn't deserve CC to stable since alpha support was
removed for CFL only for 4.15.
> have been added in smaller chunks and reworked after, so backporting
> will be required. For this level of fix, my recommendation would be to
> actively provide a cleanly applying backports to affected stable
> versions.
Are you saying this should be proactive rather than reactive? I don't
see this mentioned on
Documentation/process/stable-kernel-rules.rst... the only thing I see
there regarding patches that don't apply
cleanly is that I may bring more patches through a tag for each version.
If we are indeed going to cc stable I can submit a v2 with added tags.
If a patch that can be cc'ed to stable
needs to be provided we may need to improve our docs, too.
>
> Counting from the first CFL PCI addition, this should have following
> tags (adding them to this mail);
>
> Fixes: b056f8f3d6b9 ("drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.")
> Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> Cc: Anusha Srivatsa <anusha.sriva...@intel.com>
> Cc: Jani Nikula <jani.nik...@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> Cc: David Airlie <airl...@linux.ie>
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: <sta...@vger.kernel.org> # v4.13+
>
> Please improve the commit message to describe why the code is critical
> to be there and what is the impact on systems without the code. (Should
> be something about RAM being arbitarily overwritten if you keep using
> UEFI framebuffer for example, depending on how BIOS has set up the e820
> map.)
Noted.
thanks
Lucas De Marchi
>
> Regards, Joonas
>
>> ---
>>
>> Like it was done for other platforms, ideally we should get an ack from x86
>> maintainers and apply this through the drm-intel tree.
>>
>> arch/x86/kernel/early-quirks.c | 1 +
>> include/drm/i915_pciids.h | 6 ++
>> 2 files changed, 7 insertions(+)
>>
>> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
>> index 1e82f787c160..c87560e1e3ef 100644
>> --- a/arch/x86/kernel/early-quirks.c
>> +++ b/arch/x86/kernel/early-quirks.c
>> @@ -527,6 +527,7 @@ static const struct pci_device_id intel_early_ids[]
>> __initconst = {
>> INTEL_SKL_IDS(_early_ops),
>> INTEL_BXT_IDS(_early_ops),
>> INTEL_KBL_IDS(_early_ops),
>> + INTEL_CFL_IDS(_early_ops),
>> INTEL_GLK_IDS(_early_ops),
>> INTEL_CNL_IDS(_early_ops),
>> };
>> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
>> index 972a25633525..c65e4489006d 100644
>> --- a/include/drm/i915_pciids.h
>> +++ b/include/drm/i915_pciids.h
>> @@ -392,6 +392,12 @@
>> INTEL_VGA_DEVICE(0x3EA8, info), /* ULT GT3 */ \
>> INTEL_VGA_DEVICE(0x3EA5, info) /* ULT GT3 */
>>
>> +#define INTEL_CFL_IDS(info) \
>> + INTEL_CFL_S_GT1_IDS(info), \
>> + INTEL_CFL_S_GT2_IDS(info), \
>> + INTEL_CFL_H_GT2_IDS(info), \
>> + INTEL_CFL_U_GT3_IDS(info)
>> +
>> /* CNL U 2+2 */
>> #define INTEL_CNL_U_GT2_IDS(info) \
>> INTEL_VGA_DEVICE(0x5A52, info), \
> --
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] lib/i915_pciids.h: synchronize with kernel header
This copies include/drm/i915_pciids.h from kernel as of drm-tip: drm-tip: 2017y-12m-08d-21h-06m-35s UTC + patch adding INTEL_CFL_IDS that was missing there[1]. The goal is to keep track of the PCI IDs in a single place (kernel). Right now a simple copy is done to catch up with latest changes there, although in future it could be more sofisticated pointing the build system to the external header. [1] https://patchwork.freedesktop.org/patch/192410/ Cc: Paulo Zanoni <paulo.r.zan...@intel.com> Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com> --- lib/i915_pciids.h | 178 ++ 1 file changed, 111 insertions(+), 67 deletions(-) diff --git a/lib/i915_pciids.h b/lib/i915_pciids.h index 8d6c7270..c65e4489 100644 --- a/lib/i915_pciids.h +++ b/lib/i915_pciids.h @@ -118,92 +118,125 @@ #define INTEL_IRONLAKE_M_IDS(info) \ INTEL_VGA_DEVICE(0x0046, info) -#define INTEL_SNB_D_IDS(info) \ +#define INTEL_SNB_D_GT1_IDS(info) \ INTEL_VGA_DEVICE(0x0102, info), \ - INTEL_VGA_DEVICE(0x0112, info), \ - INTEL_VGA_DEVICE(0x0122, info), \ INTEL_VGA_DEVICE(0x010A, info) -#define INTEL_SNB_M_IDS(info) \ - INTEL_VGA_DEVICE(0x0106, info), \ +#define INTEL_SNB_D_GT2_IDS(info) \ + INTEL_VGA_DEVICE(0x0112, info), \ + INTEL_VGA_DEVICE(0x0122, info) + +#define INTEL_SNB_D_IDS(info) \ + INTEL_SNB_D_GT1_IDS(info), \ + INTEL_SNB_D_GT2_IDS(info) + +#define INTEL_SNB_M_GT1_IDS(info) \ + INTEL_VGA_DEVICE(0x0106, info) + +#define INTEL_SNB_M_GT2_IDS(info) \ INTEL_VGA_DEVICE(0x0116, info), \ INTEL_VGA_DEVICE(0x0126, info) +#define INTEL_SNB_M_IDS(info) \ + INTEL_SNB_M_GT1_IDS(info), \ + INTEL_SNB_M_GT2_IDS(info) + +#define INTEL_IVB_M_GT1_IDS(info) \ + INTEL_VGA_DEVICE(0x0156, info) /* GT1 mobile */ + +#define INTEL_IVB_M_GT2_IDS(info) \ + INTEL_VGA_DEVICE(0x0166, info) /* GT2 mobile */ + #define INTEL_IVB_M_IDS(info) \ - INTEL_VGA_DEVICE(0x0156, info), /* GT1 mobile */ \ - INTEL_VGA_DEVICE(0x0166, info) /* GT2 mobile */ + INTEL_IVB_M_GT1_IDS(info), \ + INTEL_IVB_M_GT2_IDS(info) -#define INTEL_IVB_D_IDS(info) \ +#define INTEL_IVB_D_GT1_IDS(info) \ INTEL_VGA_DEVICE(0x0152, info), /* GT1 desktop */ \ + INTEL_VGA_DEVICE(0x015a, info) /* GT1 server */ + +#define INTEL_IVB_D_GT2_IDS(info) \ INTEL_VGA_DEVICE(0x0162, info), /* GT2 desktop */ \ - INTEL_VGA_DEVICE(0x015a, info), /* GT1 server */ \ INTEL_VGA_DEVICE(0x016a, info) /* GT2 server */ +#define INTEL_IVB_D_IDS(info) \ + INTEL_IVB_D_GT1_IDS(info), \ + INTEL_IVB_D_GT2_IDS(info) + #define INTEL_IVB_Q_IDS(info) \ INTEL_QUANTA_VGA_DEVICE(info) /* Quanta transcode */ -#define INTEL_HSW_IDS(info) \ +#define INTEL_HSW_GT1_IDS(info) \ INTEL_VGA_DEVICE(0x0402, info), /* GT1 desktop */ \ - INTEL_VGA_DEVICE(0x0412, info), /* GT2 desktop */ \ - INTEL_VGA_DEVICE(0x0422, info), /* GT3 desktop */ \ INTEL_VGA_DEVICE(0x040a, info), /* GT1 server */ \ - INTEL_VGA_DEVICE(0x041a, info), /* GT2 server */ \ - INTEL_VGA_DEVICE(0x042a, info), /* GT3 server */ \ INTEL_VGA_DEVICE(0x040B, info), /* GT1 reserved */ \ - INTEL_VGA_DEVICE(0x041B, info), /* GT2 reserved */ \ - INTEL_VGA_DEVICE(0x042B, info), /* GT3 reserved */ \ INTEL_VGA_DEVICE(0x040E, info), /* GT1 reserved */ \ - INTEL_VGA_DEVICE(0x041E, info), /* GT2 reserved */ \ - INTEL_VGA_DEVICE(0x042E, info), /* GT3 reserved */ \ INTEL_VGA_DEVICE(0x0C02, info), /* SDV GT1 desktop */ \ - INTEL_VGA_DEVICE(0x0C12, info), /* SDV GT2 desktop */ \ - INTEL_VGA_DEVICE(0x0C22, info), /* SDV GT3 desktop */ \ INTEL_VGA_DEVICE(0x0C0A, info), /* SDV GT1 server */ \ - INTEL_VGA_DEVICE(0x0C1A, info), /* SDV GT2 server */ \ - INTEL_VGA_DEVICE(0x0C2A, info), /* SDV GT3 server */ \ INTEL_VGA_DEVICE(0x0C0B, info), /* SDV GT1 reserved */ \ - INTEL_VGA_DEVICE(0x0C1B, info), /* SDV GT2 reserved */ \ - INTEL_VGA_DEVICE(0x0C2B, info), /* SDV GT3 reserved */ \ INTEL_VGA_DEVICE(0x0C0E, info), /* SDV GT1 reserved */ \ - INTEL_VGA_DEVICE(0x0C1E, info), /* SDV GT2 reserved */ \ - INTEL_VGA_DEVICE(0x0C2E, info), /* SDV GT3 reserved */ \ INTEL_VGA_DEVICE(0x0A02, info), /* ULT GT1 desktop */ \ - INTEL_VGA_DEVICE(0x0A12, info), /* ULT GT2 desktop */ \ - INTEL_VGA_DEVICE(0x0A22, info), /* ULT GT3 desktop */ \ INTEL_VGA_DEVICE(0x0A0A, info), /* ULT GT1 server */ \ - INTEL_VGA_DEVICE(0x0A1A, info), /* ULT GT2 server */ \ - INTEL_VGA_DEVICE(0x0A2A, info), /* ULT GT3 server */ \ INTEL_VGA_DEVICE(0x0A0B, info), /* ULT GT1 reserved */ \ - INTEL_VGA_DEVICE(0x0A1B, info), /* ULT GT2 reserved */ \ - INTEL_VGA_DEVICE(0x0A2B, info), /* ULT GT3 reserved */ \ INTEL_VGA_DEVICE(0x0D02, info), /* CRW
Re: [Intel-gfx] [PATCH] dim: replace pipe commands with single sed
Now CC the right mailing list. The way dim sets up the repository you
can't have individual git configs, e.g. to set a different
sendemail.to for dim-tools :(
Lucas De Marchi
On Wed, May 9, 2018 at 2:28 PM, Lucas De Marchi
<lucas.demar...@intel.com> wrote:
> A single sed can do the job of taking the second line after a match and
> it looks simpler.
>
> Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
> ---
>
> I noticed this while reviewing "[PATCH 2/4] dim: shut up sed broken pipe
> noise in apply-pull".
>
> dim | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dim b/dim
> index 6b684ba5308c..f7cf255db3e1 100755
> --- a/dim
> +++ b/dim
> @@ -924,7 +924,7 @@ function dim_apply_pull
>
> cat > $file
>
> - pull_branch=$(sed -e '0,/[gG]it repository at:$/d' $file | head -n 2
> | tail -n 1)
> + pull_branch=$(sed -ne '/[gG]it repository at:$/{n;n;p}' $file)
>
> if [[ -z "$pull_branch" ]] ; then
> echoerr "no pull request found"
> --
> 2.17.0
>
> _______
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] dim: replace pipe commands with single sed
A single sed can do the job of taking the second line after a match and
it looks simpler.
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
---
I noticed this while reviewing "[PATCH 2/4] dim: shut up sed broken pipe
noise in apply-pull".
dim | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dim b/dim
index 6b684ba5308c..f7cf255db3e1 100755
--- a/dim
+++ b/dim
@@ -924,7 +924,7 @@ function dim_apply_pull
cat > $file
- pull_branch=$(sed -e '0,/[gG]it repository at:$/d' $file | head -n 2 |
tail -n 1)
+ pull_branch=$(sed -ne '/[gG]it repository at:$/{n;n;p}' $file)
if [[ -z "$pull_branch" ]] ; then
echoerr "no pull request found"
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Revert "drm/i915/edp: Do not do link training fallback or prune modes on EDP"
This reverts commit c0cfb10d9e1de490e36d3b9d4228c0ea0ca30677.
This fails on a Dell XPS13 9350 machine giving me just a black screen.
[drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
Passed at Link Rate = 54, Lane count = 4
[drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link
Training failed at link rate = 54, lane count = 4
[drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
Passed at Link Rate = 54, Lane count = 4
[drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
Passed at Link Rate = 54, Lane count = 4
[drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
Passed at Link Rate = 54, Lane count = 4
[drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link
Training failed at link rate = 54, lane count = 4
[drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link
Training failed at link rate = 54, lane count = 4
[drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
Passed at Link Rate = 54, Lane count = 4
[drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link
Training failed at link rate = 54, lane count = 4
[drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
Passed at Link Rate = 54, Lane count = 4
[drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
Passed at Link Rate = 54, Lane count = 4
[drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link
Training failed at link rate = 54, lane count = 4
On a working kernel, previous to this commit I have:
[drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
failed at link rate = 54, lane count = 4
[drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
Passed at Link Rate = 27, Lane count = 4
Cc: Clinton Taylor <clinton.a.tay...@intel.com>
Cc: Jim Bride <jim.br...@linux.intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: Ville Syrjala <ville.syrj...@linux.intel.com>
Cc: Dave Airlie <airl...@redhat.com>
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: Manasi Navare <manasi.d.nav...@intel.com>
Cc: Ville Syrjala <ville.syrj...@linux.intel.com>
Cc: Imre Deak <imre.d...@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
---
I'm sending this for reference and discussion only, but it doesn't seem
to be the right fix. Not only because it would mean IGT failing on CI,
but also because we seem to be having several link training running
concurrently and the last one failing leaves the panel at that state.
drivers/gpu/drm/i915/intel_dp_link_training.c | 26 +++
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index f59b59bb0a21..78f1fe934da3 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -330,22 +330,14 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
return;
failure_handling:
- /* Dont fallback and prune modes if its eDP */
- if (!intel_dp_is_edp(intel_dp)) {
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link
rate = %d, lane count = %d",
- intel_connector->base.base.id,
- intel_connector->base.name,
- intel_dp->link_rate, intel_dp->lane_count);
- if (!intel_dp_get_link_train_fallback_values(intel_dp,
-
intel_dp->link_rate,
-
intel_dp->lane_count))
- /* Schedule a Hotplug Uevent to userspace to start
modeset */
- schedule_work(_connector->modeset_retry_work);
- } else {
- DRM_ERROR("[CONNECTOR:%d:%s] Link Training failed at link rate
= %d, lane count = %d",
- intel_connector->base.base.id,
- intel_connector->base.name,
- intel_dp->link_rate, intel_dp->lane_count);
- }
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate =
%d, lane count = %d",
+ intel_connector->base.base.id,
+ intel_connector->base.name,
+ intel_dp->link_rate, intel_dp->lane_count);
+ if (!intel_dp_get_link_train_fallback_values(intel_dp,
+intel_dp->link_rate,
+intel_dp->lane_count))
+ /* Schedule a Hotplug Uevent to userspace to start modeset */
+ schedule_work(_co
Re: [Intel-gfx] [PATCH 11/24] drm/i915/icl: Get DDI clock for ICL based on PLLs.
On Tue, May 22, 2018 at 02:44:43PM +0300, Mika Kahola wrote:
> On Mon, 2018-05-21 at 17:25 -0700, Paulo Zanoni wrote:
> > From: Manasi Navare <manasi.d.nav...@intel.com>
> >
> > PLLs are the source clocks for the DDIs so in order
> > to determine the ddi clock we need to check the PLL
> > configuration.
> >
> > This gets a little tricky for ICL since there is
> > no register bit that maps directly to the link clock.
> > So this patch creates a separate function in intel_dpll_mgr.c
> > to obtain the write array PLL Params and compares the set
> > pll_params with the table to get the corresponding link
> > clock.
> >
> > Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> > Cc: Mika Kahola <mika.kah...@intel.com>
> > Cc: Paulo Zanoni <paulo.r.zan...@intel.com>
> > Signed-off-by: Manasi Navare <manasi.d.nav...@intel.com>
> > Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demar...@intel.com>
> > Signed-off-by: Paulo Zanoni <paulo.r.zan...@intel.com>
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 3 ++
> > drivers/gpu/drm/i915/intel_ddi.c | 26 ++
> > drivers/gpu/drm/i915/intel_dpll_mgr.c | 66
> > +++
> > drivers/gpu/drm/i915/intel_dpll_mgr.h | 2 ++
> > 4 files changed, 97 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 7f27fe2e38c7..26903cffabf6 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -9182,13 +9182,16 @@ enum skl_power_gate {
> > #define DPLL_CFGCR1_QDIV_RATIO_MASK (0xff << 10)
> > #define DPLL_CFGCR1_QDIV_RATIO_SHIFT (10)
> > #define DPLL_CFGCR1_QDIV_RATIO(x) ((x) << 10)
> > +#define DPLL_CFGCR1_QDIV_MODE_SHIFT (9)
> > #define DPLL_CFGCR1_QDIV_MODE(x) ((x) << 9)
> > #define DPLL_CFGCR1_KDIV_MASK (7 << 6)
> > +#define DPLL_CFGCR1_KDIV_SHIFT(6)
> > #define DPLL_CFGCR1_KDIV(x) ((x) << 6)
> > #define DPLL_CFGCR1_KDIV_1(1 << 6)
> > #define DPLL_CFGCR1_KDIV_2(2 << 6)
> > #define DPLL_CFGCR1_KDIV_4(4 << 6)
> > #define DPLL_CFGCR1_PDIV_MASK (0xf << 2)
> > +#define DPLL_CFGCR1_PDIV_SHIFT(2)
> > #define DPLL_CFGCR1_PDIV(x) ((x) << 2)
> > #define DPLL_CFGCR1_PDIV_2(1 << 2)
> > #define DPLL_CFGCR1_PDIV_3(2 << 2)
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index d8ae82001f83..0d8bed8e2200 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1458,6 +1458,30 @@ static void ddi_dotclock_get(struct
> > intel_crtc_state *pipe_config)
> > pipe_config->base.adjusted_mode.crtc_clock = dotclock;
> > }
> >
> > +static void icl_ddi_clock_get(struct intel_encoder *encoder,
> > + struct intel_crtc_state *pipe_config)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(encoder-
> > >base.dev);
> > + enum port port = encoder->port;
> > + int link_clock = 0;
> > + uint32_t pll_id;
> > +
> > + pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config-
> > >shared_dpll);
> > + if (port == PORT_A || port == PORT_B) {
> > + if (encoder->type == INTEL_OUTPUT_HDMI)
> > + link_clock = cnl_calc_wrpll_link(dev_priv,
> > pll_id);
> > + else
> > + link_clock =
> > icl_calc_dp_combo_pll_link(dev_priv,
> > + pll_
> > id);
> > + } else {
> > + /* FIXME - Add for MG PLL */
> > + WARN(1, "MG PLL clock_get code not implemented
> > yet\n");
> > + }
> > +
> > + pipe_config->port_clock = link_clock;
> > + ddi_dotclock_get(pipe_config);
> > +}
> > +
> > static void cnl_ddi_clock_get(struct intel_encoder *encoder,
> > struct intel_crtc_state *pipe_config)
> > {
> > @@ -1651,6 +1675,8 @@ static void intel_ddi_clock_get(struct
> > intel_encoder *encoder,
> > bxt_ddi_clock_get(encoder, pipe_config);
> > else if (IS_CANNONLAKE(dev_priv))
> > cnl_ddi_clock_get(encoder, pipe_
[Intel-gfx] [PATCH] drm/i915/icl: fix icl_unmap/map_plls_to_ports
From: Mahesh Kumar <mahesh1.ku...@intel.com>
All connectors may not have best_encoder attached, so don't dereference
encoder pointer for each connector.
Fixes: c27e917e2bda (drm/i915/icl: add basic support for the ICL clocks)
Signed-off-by: Mahesh Kumar <mahesh1.ku...@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demar...@intel.com>
---
drivers/gpu/drm/i915/intel_ddi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 3b8f12883ca7..c33b19705e39 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2444,12 +2444,13 @@ void icl_map_plls_to_ports(struct drm_crtc *crtc,
for_each_new_connector_in_state(old_state, conn, conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(conn_state->best_encoder);
- enum port port = encoder->port;
+ enum port port;
uint32_t val;
if (conn_state->crtc != crtc)
continue;
+ port = encoder->port;
mutex_lock(_priv->dpll_lock);
val = I915_READ(DPCLKA_CFGCR0_ICL);
@@ -2481,11 +2482,12 @@ void icl_unmap_plls_to_ports(struct drm_crtc *crtc,
for_each_old_connector_in_state(old_state, conn, old_conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(old_conn_state->best_encoder);
- enum port port = encoder->port;
+ enum port port;
if (old_conn_state->crtc != crtc)
continue;
+ port = encoder->port;
mutex_lock(_priv->dpll_lock);
I915_WRITE(DPCLKA_CFGCR0_ICL,
I915_READ(DPCLKA_CFGCR0_ICL) |
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 25/24] drm/i915/icl: fix gmbus gpio pin mapping
On Fri, May 25, 2018 at 07:24:07PM +0300, Ville Syrjälä wrote:
> On Thu, May 24, 2018 at 05:36:37PM -0700, Lucas De Marchi wrote:
> > On Thu, May 24, 2018 at 04:42:36PM -0700, Paulo Zanoni wrote:
> > > From: Mahesh Kumar <mahesh1.ku...@intel.com>
> > >
> > > ICP has GPIO pin 1/2 mapped to combo-phy ports & GPIO pins 9/10/11/12
> > > mapped to tc ports[1-4].
> > > This patch defines GPIOCTL registers for GPIO pins 9-12 & uses them in
> > > GPIO
> > > pin mapping table.
> > >
> > > Cc: Anusha Srivatsa <anusha.sriva...@intel.com>
> > > Cc: Madhav Chauhan <madhav.chau...@intel.com>
> > > Cc: Lucas De Marchi <lucas.demar...@intel.com>
> > > Signed-off-by: Mahesh Kumar <mahesh1.ku...@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h | 4
> > > drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
> > > drivers/gpu/drm/i915/intel_i2c.c | 12 ++--
> > > 3 files changed, 11 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 452356a4af07..e48b717769b2 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -3015,6 +3015,10 @@ enum i915_power_well_id {
> > > #define GPIOF_MMIO(0x5024)
> > > #define GPIOG_MMIO(0x5028)
> > > #define GPIOH_MMIO(0x502c)
> > > +#define GPIOJ_MMIO(0x5034)
> > > +#define GPIOK_MMIO(0x5038)
> > > +#define GPIOL_MMIO(0x503C)
> > > +#define GPIOM_MMIO(0x5040)
> >
> > I was reviewing again this and I think again I was puzzled why the spec
> > has them as 0xc5034, ...
> >
> > Probably same conclusion as I had when I first reviewed this. Maybe it
> > would be nice to add a comment to PCH_GPIO* saying PCH_GPIOA is used
> > only for calculation the gpio base and remove the rest. I can send this
> > is a separate patch, what do you think?
> >
> > ---8<---
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 6953419881c4..40b9aa57078b 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7442,12 +7442,8 @@ enum {
> > #define PORTE_HOTPLUG_SHORT_DETECT(1 << 0)
> > #define PORTE_HOTPLUG_LONG_DETECT (2 << 0)
> >
> > +/* Used just for calculating the gpio base for PCH */
> > #define PCH_GPIOA _MMIO(0xc5010)
> > -#define PCH_GPIOB _MMIO(0xc5014)
> > -#define PCH_GPIOC _MMIO(0xc5018)
> > -#define PCH_GPIOD _MMIO(0xc501c)
> > -#define PCH_GPIOE _MMIO(0xc5020)
> > -#define PCH_GPIOF _MMIO(0xc5024)
>
> Maybe just have
>
> #define PCH_GPIO_BASE ...
>
> and throw out the PCH_GPIO/GMBUS defines entirely?
Yeah just thought about this after sending the email. I will spin a
patch with that.
thanks
Lucas De Marchi
>
> >
> > #define PCH_GMBUS0 _MMIO(0xc5100)
> > #define PCH_GMBUS1 _MMIO(0xc5104)
> > ---8<---
> >
> >
> > Other than that,
> >
> > Reviewed-by: Lucas De Marchi <lucas.demar...@intel.com>
> >
> > > # define GPIO_CLOCK_DIR_MASK (1 << 0)
> > > # define GPIO_CLOCK_DIR_IN (0 << 1)
> > > # define GPIO_CLOCK_DIR_OUT (1 << 1)
> > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > > b/drivers/gpu/drm/i915/intel_hdmi.c
> > > index 75f02a0e7d39..3db2459c79b1 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > > @@ -2276,7 +2276,7 @@ static u8 intel_hdmi_ddc_pin(struct
> > > drm_i915_private *dev_priv,
> > > ddc_pin = bxt_port_to_ddc_pin(dev_priv, port);
> > > else if (HAS_PCH_CNP(dev_priv))
> > > ddc_pin = cnp_port_to_ddc_pin(dev_priv, port);
> > > - else if (IS_ICELAKE(dev_priv))
> > > + else if (HAS_PCH_ICP(dev_priv))
> > > ddc_pin = icl_port_to_ddc_pin(dev_priv, port);
> > > else
> > > ddc_pin = g4x_port_to_ddc_pin(dev_priv, port);
> > > diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> > > b/drivers/gpu/drm/i915/intel_i2c.c
> > > index e6875509bcd9..b91e
Re: [Intel-gfx] [PATCH 07/24] drm/i915/icl: Add DDI HDMI level selection for ICL
On Mon, May 21, 2018 at 05:25:41PM -0700, Paulo Zanoni wrote:
> From: Manasi Navare <manasi.d.nav...@intel.com>
>
> This patch adds a proper HDMI DDI entry level for vswing
> programming sequences on ICL.
>
> Spec doesn't specify any default for HDMI tables,
> so let's pick the last entry as the default for now
> to stay consistent with older platform like CNL.
>
> Cc: Paulo Zanoni <paulo.r.zan...@intel.com>
> Cc: Rakshmi Bhatia <rakshmi.bha...@intel.com>
> Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> Signed-off-by: Manasi Navare <manasi.d.nav...@intel.com>
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 1665bc588241..d8ae82001f83 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -915,7 +915,14 @@ static int intel_ddi_hdmi_level(struct drm_i915_private
> *dev_priv, enum port por
>
> level = dev_priv->vbt.ddi_port_info[port].hdmi_level_shift;
>
> - if (IS_CANNONLAKE(dev_priv)) {
> + if (IS_ICELAKE(dev_priv)) {
> + if (port == PORT_A || port == PORT_B)
This should be using the helper you introduced in patch 3. Either a
'if (!intel_port_is_tc()' or add a 'if (intel_port_is_combo)'.
With that,
Reviewed-by: Lucas De Marchi <lucas.demar...@intel.com>
Lucas De Marchi
> + icl_get_combo_buf_trans(dev_priv, port,
> + INTEL_OUTPUT_HDMI, _entries);
> + else
> + n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations);
> + default_entry = n_entries - 1;
> + } else if (IS_CANNONLAKE(dev_priv)) {
> cnl_get_buf_trans_hdmi(dev_priv, _entries);
> default_entry = n_entries - 1;
> } else if (IS_GEN9_LP(dev_priv)) {
> --
> 2.14.3
>
> ___
> 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/24] drm/i915/ICL: Add register definition for DFLEXDPMLE
On Thu, May 24, 2018 at 05:26:38PM -0700, Paulo Zanoni wrote:
> Em Seg, 2018-05-21 às 17:25 -0700, Paulo Zanoni escreveu:
> > From: Manasi Navare <manasi.d.nav...@intel.com>
> >
> > DFLEXDPMLE register is required to tell the FIA hardware which
> > main links of DP are enabled on TCC Connectors. FIA uses this
> > information to program PHY to Controller signal mapping.
> > This register is applicable in both TC connector's Alternate mode
> > as well as DP connector mode.
> >
> > Cc: Jani Nikula <jani.nik...@linux.intel.com>
> > Cc: Animesh Manna <animesh.ma...@intel.com>
> > Cc: Madhav Chauhan <madhav.chau...@intel.com>
> > Cc: Anusha Srivatsa <anusha.sriva...@intel.com>
> > Cc: Paulo Zanoni <paulo.r.zan...@intel.com>
> > Signed-off-by: Manasi Navare <manasi.d.nav...@intel.com>
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 28ce96ce0484..7f27fe2e38c7 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1990,6 +1990,11 @@ enum i915_power_well_id {
> >_ICL_PORT_COMP_DW
> > 10_A, \
> >_ICL_PORT_COMP_DW
> > 10_B)
> >
> > +/* ICL PHY DFLEX registers */
> > +#define ICL_PORT_TX_DFLEXDPMLE1_MMIO(0x1638C0)
>
> We can probably remove the ICL_ prefix since the register did not exist
> before.
And while at it s/ICL/icl/ in the commit message?
Lucas De Marchi
>
> With or without that:
> Reviewed-by: Paulo Zanoni <paulo.r.zan...@intel.com>
>
> Note: the patch that uses the register was removed from the series due
> to some problems identified. Will be upstreamed as soon as it's fixed.
>
> > +#define DFLEXDPMLE1_DPMLETC_MASK(n) (0xf << (4 * (n)))
> > +#define DFLEXDPMLE1_DPMLETC(n, x)((x) << (4 * (n)))
> > +
> > /* BXT PHY Ref registers */
> > #define _PORT_REF_DW3_A0x16218C
> > #define _PORT_REF_DW3_BC 0x6C18C
> ___
> 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 25/24] drm/i915/icl: fix gmbus gpio pin mapping
On Thu, May 24, 2018 at 04:42:36PM -0700, Paulo Zanoni wrote:
> From: Mahesh Kumar <mahesh1.ku...@intel.com>
>
> ICP has GPIO pin 1/2 mapped to combo-phy ports & GPIO pins 9/10/11/12
> mapped to tc ports[1-4].
> This patch defines GPIOCTL registers for GPIO pins 9-12 & uses them in GPIO
> pin mapping table.
>
> Cc: Anusha Srivatsa <anusha.sriva...@intel.com>
> Cc: Madhav Chauhan <madhav.chau...@intel.com>
> Cc: Lucas De Marchi <lucas.demar...@intel.com>
> Signed-off-by: Mahesh Kumar <mahesh1.ku...@intel.com>
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4
> drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
> drivers/gpu/drm/i915/intel_i2c.c | 12 ++--
> 3 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 452356a4af07..e48b717769b2 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3015,6 +3015,10 @@ enum i915_power_well_id {
> #define GPIOF_MMIO(0x5024)
> #define GPIOG_MMIO(0x5028)
> #define GPIOH_MMIO(0x502c)
> +#define GPIOJ_MMIO(0x5034)
> +#define GPIOK_MMIO(0x5038)
> +#define GPIOL_MMIO(0x503C)
> +#define GPIOM_MMIO(0x5040)
I was reviewing again this and I think again I was puzzled why the spec
has them as 0xc5034, ...
Probably same conclusion as I had when I first reviewed this. Maybe it
would be nice to add a comment to PCH_GPIO* saying PCH_GPIOA is used
only for calculation the gpio base and remove the rest. I can send this
is a separate patch, what do you think?
---8<---
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6953419881c4..40b9aa57078b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7442,12 +7442,8 @@ enum {
#define PORTE_HOTPLUG_SHORT_DETECT(1 << 0)
#define PORTE_HOTPLUG_LONG_DETECT (2 << 0)
+/* Used just for calculating the gpio base for PCH */
#define PCH_GPIOA _MMIO(0xc5010)
-#define PCH_GPIOB _MMIO(0xc5014)
-#define PCH_GPIOC _MMIO(0xc5018)
-#define PCH_GPIOD _MMIO(0xc501c)
-#define PCH_GPIOE _MMIO(0xc5020)
-#define PCH_GPIOF _MMIO(0xc5024)
#define PCH_GMBUS0 _MMIO(0xc5100)
#define PCH_GMBUS1 _MMIO(0xc5104)
---8<---
Other than that,
Reviewed-by: Lucas De Marchi <lucas.demar...@intel.com>
> # define GPIO_CLOCK_DIR_MASK (1 << 0)
> # define GPIO_CLOCK_DIR_IN (0 << 1)
> # define GPIO_CLOCK_DIR_OUT (1 << 1)
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 75f02a0e7d39..3db2459c79b1 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -2276,7 +2276,7 @@ static u8 intel_hdmi_ddc_pin(struct drm_i915_private
> *dev_priv,
> ddc_pin = bxt_port_to_ddc_pin(dev_priv, port);
> else if (HAS_PCH_CNP(dev_priv))
> ddc_pin = cnp_port_to_ddc_pin(dev_priv, port);
> - else if (IS_ICELAKE(dev_priv))
> + else if (HAS_PCH_ICP(dev_priv))
> ddc_pin = icl_port_to_ddc_pin(dev_priv, port);
> else
> ddc_pin = g4x_port_to_ddc_pin(dev_priv, port);
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index e6875509bcd9..b91e418028cb 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -77,12 +77,12 @@ static const struct gmbus_pin gmbus_pins_cnp[] = {
> };
>
> static const struct gmbus_pin gmbus_pins_icp[] = {
> - [GMBUS_PIN_1_BXT] = { "dpa", GPIOA },
> - [GMBUS_PIN_2_BXT] = { "dpb", GPIOB },
> - [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOC },
> - [GMBUS_PIN_10_TC2_ICP] = { "tc2", GPIOD },
> - [GMBUS_PIN_11_TC3_ICP] = { "tc3", GPIOE },
> - [GMBUS_PIN_12_TC4_ICP] = { "tc4", GPIOF },
> + [GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
> + [GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
> + [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOJ },
> + [GMBUS_PIN_10_TC2_ICP] = { "tc2", GPIOK },
> + [GMBUS_PIN_11_TC3_ICP] = { "tc3", GPIOL },
> + [GMBUS_PIN_12_TC4_ICP] = { "tc4", GPIOM },
> };
>
> /* pin is expected to be valid */
> --
> 2.14.3
>
> ___
> 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 05/24] drm/i915/icp: Add Interrupt Support
On Thu, May 24, 2018 at 05:45:43PM -0700, Dhinakaran Pandiyan wrote:
> On Thu, 2018-05-24 at 16:53 -0700, Lucas De Marchi wrote:
> > On Mon, May 21, 2018 at 05:25:39PM -0700, Paulo Zanoni wrote:
> > >
> > > From: Anusha Srivatsa <anusha.sriva...@intel.com>
> > >
> > > This patch addresses Interrupts from south display engine (SDE).
> > >
> > > ICP has two registers - SHOTPLUG_CTL_DDI and SHOTPLUG_CTL_TC.
> > > Introduce these registers and their intended values.
> > >
> > > Introduce icp_irq_handler().
> > >
> > > Cc: Paulo Zanoni <paulo.r.zan...@intel.com>
> > > Cc: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > Cc: Ville Syrjala <ville.syrj...@linux.intel.com>
> > > Signed-off-by: Anusha Srivatsa <anusha.sriva...@intel.com>
> > > [Paulo: coding style bikesheds and rebases].
> > > Signed-off-by: Paulo Zanoni <paulo.r.zan...@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/i915_irq.c | 134
> > > +++-
> > > drivers/gpu/drm/i915/i915_reg.h | 40
> > > 2 files changed, 172 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index 9bcec5fdb9d0..6b109991786f 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -122,6 +122,15 @@ static const u32 hpd_tc_gen11[HPD_NUM_PINS] =
> > > {
> > > [HPD_PORT_F] = GEN11_TC4_HOTPLUG
> > > };
> > >
> > > +static const u32 hpd_icp[HPD_NUM_PINS] = {
> > > + [HPD_PORT_A] = ICP_DDIA_HOTPLUG,
> > > + [HPD_PORT_B] = ICP_DDIB_HOTPLUG,
> > > + [HPD_PORT_C] = ICP_TC1_HOTPLUG,
> > > + [HPD_PORT_D] = ICP_TC2_HOTPLUG,
> > > + [HPD_PORT_E] = ICP_TC3_HOTPLUG,
> > > + [HPD_PORT_F] = ICP_TC4_HOTPLUG
> > > +};
> > > +
> > > /* IIR can theoretically queue up two events. Be paranoid. */
> > > #define GEN8_IRQ_RESET_NDX(type, which) do { \
> > > I915_WRITE(GEN8_##type##_IMR(which), 0x); \
> > > @@ -1586,6 +1595,34 @@ static bool
> > > bxt_port_hotplug_long_detect(enum port port, u32 val)
> > > }
> > > }
> > >
> > > +static bool icp_ddi_port_hotplug_long_detect(enum port port, u32
> > > val)
> > > +{
> > > + switch (port) {
> > > + case PORT_A:
> > > + return val & ICP_DDIA_HPD_LONG_DETECT;
> > > + case PORT_B:
> > > + return val & ICP_DDIB_HPD_LONG_DETECT;
> > > + default:
> > > + return false;
> > > + }
> > > +}
> > > +
> > > +static bool icp_tc_port_hotplug_long_detect(enum port port, u32
> > > val)
> > > +{
> > > + switch (port) {
> > > + case PORT_C:
> > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC1);
> > > + case PORT_D:
> > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC2);
> > > + case PORT_E:
> > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC3);
> > > + case PORT_F:
> > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC4);
> > > + default:
> > > + return false;
> > > + }
> > > +}
> > > +
> > > static bool spt_port_hotplug2_long_detect(enum port port, u32 val)
> > > {
> > > switch (port) {
> > > @@ -2377,6 +2414,43 @@ static void cpt_irq_handler(struct
> > > drm_i915_private *dev_priv, u32 pch_iir)
> > > cpt_serr_int_handler(dev_priv);
> > > }
> > >
> > > +static void icp_irq_handler(struct drm_i915_private *dev_priv, u32
> > > pch_iir)
> > > +{
> > > + u32 ddi_hotplug_trigger = pch_iir & ICP_SDE_DDI_MASK;
> > > + u32 tc_hotplug_trigger = pch_iir & ICP_SDE_TC_MASK;
> > > + u32 pin_mask = 0, long_mask = 0;
> > > +
> > > + if (ddi_hotplug_trigger) {
> > > + u32 dig_hotplug_reg;
> > > +
> > > + dig_hotplug_reg = I915_READ(SHOTPLUG_CTL_DDI);
> > > + I915_WRITE(SHOTPLUG_CTL_DDI, dig_hotplug_reg);
> > > +
> > > + intel_get_hpd_pins(dev_priv, _mask,
> > > _mask,
> > > + ddi_hotplug_trigger,
> > > + dig_hotplug_reg, hpd_icp,
> > > + icp_ddi_port_hotplug_long_detec
> &
Re: [Intel-gfx] [PATCH 05/24] drm/i915/icp: Add Interrupt Support
ret = IRQ_HANDLED;
>
> - if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv) ||
> - HAS_PCH_CNP(dev_priv))
> + if (HAS_PCH_ICP(dev_priv))
> + icp_irq_handler(dev_priv, iir);
> + else if (HAS_PCH_SPT(dev_priv) ||
> + HAS_PCH_KBP(dev_priv) ||
> + HAS_PCH_CNP(dev_priv))
> spt_irq_handler(dev_priv, iir);
> else
> cpt_irq_handler(dev_priv, iir);
> @@ -3548,6 +3625,9 @@ static void gen11_irq_reset(struct drm_device *dev)
> GEN3_IRQ_RESET(GEN11_DE_HPD_);
> GEN3_IRQ_RESET(GEN11_GU_MISC_);
> GEN3_IRQ_RESET(GEN8_PCU_);
> +
> + if (HAS_PCH_ICP(dev_priv))
> + GEN3_IRQ_RESET(ICP_SDE_);
> }
>
> void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
> @@ -3664,6 +3744,35 @@ static void ibx_hpd_irq_setup(struct drm_i915_private
> *dev_priv)
> ibx_hpd_detection_setup(dev_priv);
> }
>
> +static void icp_hpd_detection_setup(struct drm_i915_private *dev_priv)
> +{
> + u32 hotplug;
> +
> + hotplug = I915_READ(SHOTPLUG_CTL_DDI);
> + hotplug |= ICP_DDIA_HPD_ENABLE |
> +ICP_DDIB_HPD_ENABLE;
> + I915_WRITE(SHOTPLUG_CTL_DDI, hotplug);
> +
> + hotplug = I915_READ(SHOTPLUG_CTL_TC);
> + hotplug |= ICP_TC_HPD_ENABLE(PORT_TC1) |
> +ICP_TC_HPD_ENABLE(PORT_TC2) |
> +ICP_TC_HPD_ENABLE(PORT_TC3) |
> +ICP_TC_HPD_ENABLE(PORT_TC4);
> + I915_WRITE(SHOTPLUG_CTL_TC, hotplug);
> +}
> +
> +static void icp_hpd_irq_setup(struct drm_i915_private *dev_priv)
> +{
> + u32 hotplug_irqs, enabled_irqs;
> +
> + hotplug_irqs = ICP_SDE_DDI_MASK | ICP_SDE_TC_MASK;
> + enabled_irqs = intel_hpd_enabled_irqs(dev_priv, hpd_icp);
> +
> + ibx_display_interrupt_update(dev_priv, hotplug_irqs, enabled_irqs);
> +
> + icp_hpd_detection_setup(dev_priv);
> +}
> +
> static void gen11_hpd_detection_setup(struct drm_i915_private *dev_priv)
> {
> u32 hotplug;
> @@ -3690,6 +3799,9 @@ static void gen11_hpd_irq_setup(struct drm_i915_private
> *dev_priv)
> POSTING_READ(GEN11_DE_HPD_IMR);
>
> gen11_hpd_detection_setup(dev_priv);
> +
> + if (HAS_PCH_ICP(dev_priv))
> + icp_hpd_irq_setup(dev_priv);
> }
>
> static void spt_hpd_detection_setup(struct drm_i915_private *dev_priv)
> @@ -4121,11 +4233,29 @@ static void gen11_gt_irq_postinstall(struct
> drm_i915_private *dev_priv)
> I915_WRITE(GEN11_GPM_WGBOXPERF_INTR_MASK, ~0);
> }
>
> +static void icp_irq_postinstall(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + u32 mask = ICP_GMBUS;
> +
> + WARN_ON(I915_READ(ICP_SDE_IER) != 0);
> + I915_WRITE(ICP_SDE_IER, 0x);
> + POSTING_READ(ICP_SDE_IER);
> +
> + gen3_assert_iir_is_zero(dev_priv, ICP_SDE_IIR);
> + I915_WRITE(ICP_SDE_IMR, ~mask);
> +
> + icp_hpd_detection_setup(dev_priv);
> +}
> +
> static int gen11_irq_postinstall(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> u32 gu_misc_masked = GEN11_GU_MISC_GSE;
>
> + if (HAS_PCH_ICP(dev_priv))
> + icp_irq_postinstall(dev);
> +
> gen11_gt_irq_postinstall(dev_priv);
> gen8_de_irq_postinstall(dev_priv);
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 19600097581f..28ce96ce0484 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7460,6 +7460,46 @@ enum {
> #define PORTE_HOTPLUG_SHORT_DETECT (1 << 0)
> #define PORTE_HOTPLUG_LONG_DETECT (2 << 0)
>
> +/* ICP */
> +#define ICP_SDE_ISR _MMIO(0xc4000)
> +#define ICP_SDE_IMR _MMIO(0xc4004)
> +#define ICP_SDE_IIR _MMIO(0xc4008)
> +#define ICP_SDE_IER _MMIO(0xc400c)
These are exactly the same registers as SDE{ISR,IMR,IIR,IER}. For all
the other platforms what we do is rather postfix the platform name.
I think we should follow what they do here.
> +#define ICP_TC4_HOTPLUG(1 << 27)
> +#define ICP_TC3_HOTPLUG(1 << 26)
> +#define ICP_TC2_HOTPLUG(1 << 25)
> +#define ICP_TC1_HOTPLUG(1 << 24)
> +#define ICP_GMBUS (1 << 23)
> +#define ICP_DDIB_HOTPLUG (1 << 17)
> +#define ICP_DDIA_HOTPLUG (1 <&
Re: [Intel-gfx] [PATCH] drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode
On Thu, May 17, 2018 at 12:28 AM, Jani Nikula
<jani.nik...@linux.intel.com> wrote:
> On Wed, 16 May 2018, Manasi Navare <manasi.d.nav...@intel.com> wrote:
>> This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp:
>> Do not do link training fallback or prune modes on EDP") that causes
>> a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350)
>> where first link training fails and a retraining is required by falling
>> back to lower link rate/lane count.
>> In case of some panels they advertise higher link rate/lane count
>> than whats required for supporting the panel's native mode.
>> But we always link train at highest link rate/lane count for eDP
>> and if that fails we can still fallback to lower link rate/lane count
>> as long as the fallback link BW still fits the native mode to avoid
>> pruning the panel's native mode yet retraining at fallback values
>> to recover from a blank screen.
>
> What eDP revision is the faulty panel? Does [1] help for that? Then we'd
> not need this.
# dd if=/dev/drm_dp_aux0 bs=1 | hexdump -C
...
0700 02
So, should be eDP rev 1.3
>
> I think this also ties in with the alternate/downclock mode. It fails
> now and should be reverted [2]. However, if we know the panel has a
> valid mode with lower refresh rate, we might have a mode that actually
> fits a link with reduced bandwidth.
>
> IMO we need [1], [2], and patches to disconnect downclock mode from drrs
> support (so we/user can choose the downclock mode independent of drrs),
> and finally eDP link fallback selection based on if there's a downclock
> mode and if it fits a link with reduced link rate or lane count.
>
> BR,
> Jani.
>
>
> [1]
> http://patchwork.freedesktop.org/patch/msgid/20180509071321.28563-1-jani.nik...@intel.com
> [2]
> http://patchwork.freedesktop.org/patch/msgid/20180516080110.22770-1-jani.nik...@intel.com
Tested both patches and still the same problem.
Lucas De Marchi
>
>
>
>>
>> Cc: Clinton Taylor <clinton.a.tay...@intel.com>
>> Cc: Jani Nikula <jani.nik...@linux.intel.com>
>> Cc: Ville Syrjala <ville.syrj...@linux.intel.com>
>> Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
>> Cc: Lucas De Marchi <lucas.demar...@intel.com>
>> Signed-off-by: Manasi Navare <manasi.d.nav...@intel.com>
>> ---
>> drivers/gpu/drm/i915/intel_dp.c | 25 +
>> drivers/gpu/drm/i915/intel_dp_link_training.c | 26
>> +-
>> 2 files changed, 34 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index 2cc58596..7f7202a 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -387,6 +387,21 @@ static bool intel_dp_link_params_valid(struct intel_dp
>> *intel_dp, int link_rate,
>> return true;
>> }
>>
>> +static bool intel_dp_can_link_train_fallback_for_edp(struct intel_dp
>> *intel_dp,
>> + int link_rate,
>> + uint8_t lane_count)
>> +{
>> + struct drm_display_mode *fixed_mode =
>> intel_dp->attached_connector->panel.fixed_mode;
>> + int mode_rate, max_rate;
>> +
>> + mode_rate = intel_dp_link_required(fixed_mode->clock, 18);
>> + max_rate = intel_dp_max_data_rate(link_rate, lane_count);
>> + if (mode_rate > max_rate)
>> + return false;
>> +
>> + return true;
>> +}
>> +
>> int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
>> int link_rate, uint8_t lane_count)
>> {
>> @@ -396,9 +411,19 @@ int intel_dp_get_link_train_fallback_values(struct
>> intel_dp *intel_dp,
>> intel_dp->num_common_rates,
>> link_rate);
>> if (index > 0) {
>> + if (intel_dp_is_edp(intel_dp) &&
>> + !intel_dp_can_link_train_fallback_for_edp(intel_dp,
>> +
>> intel_dp->common_rates[index-1],
>> + lane_count))
>> + return -1;
>> intel_dp->max_link_rate = intel_dp->common_rates[index - 1];
>> intel_dp->max_link_lane_count = lane_count;
>> } else if (lane_count > 1) {
>> + if (i
[Intel-gfx] [PATCH v2] drm/i915: remove check for aux irq
This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
GMBUS and AUX interrupts on gen4/g4x").
v2: Move comment about HW behavior to where decision is made to enable
MSI (Ville).
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
---
drivers/gpu/drm/i915/i915_drv.c | 6 ++
drivers/gpu/drm/i915/i915_drv.h | 10 --
drivers/gpu/drm/i915/intel_dp.c | 22 +++---
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_psr.c | 2 +-
5 files changed, 14 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9c449b8d8eab..a1461de20472 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1189,6 +1189,12 @@ static int i915_driver_init_hw(struct drm_i915_private
*dev_priv)
* get lost on g4x as well, and interrupt delivery seems to stay
* properly dead afterwards. So we'll just disable them for all
* pre-gen5 chipsets.
+*
+* dp aux and gmbus irq on gen4 seems to be able to generate legacy
+* interrupts even when in MSI mode. This results in spurious
+* interrupt warnings if the legacy irq no. is shared with another
+* device. The kernel then disables that interrupt source and so
+* prevents the other device from working properly.
*/
if (INTEL_GEN(dev_priv) >= 5) {
if (pci_enable_msi(pdev) < 0)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b86ed6401120..c5e1f648c47c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2558,16 +2558,6 @@ intel_info(const struct drm_i915_private *dev_priv)
(IS_CANNONLAKE(dev_priv) || \
IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
-/*
- * dp aux and gmbus irq on gen4 seems to be able to generate legacy interrupts
- * even when in MSI mode. This results in spurious interrupt warnings if the
- * legacy irq no. is shared with another device. The kernel then disables that
- * interrupt source and so prevents the other device from working properly.
- *
- * Since we don't enable MSI anymore on gen4, we can always use GMBUS/AUX
- * interrupts.
- */
-#define HAS_AUX_IRQ(dev_priv) true
#define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
/* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ce07bd794aed..1dab40056df7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -936,7 +936,7 @@ intel_dp_check_edp(struct intel_dp *intel_dp)
}
static uint32_t
-intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
+intel_dp_aux_wait_done(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
@@ -944,14 +944,10 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool
has_aux_irq)
bool done;
#define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) ==
0)
- if (has_aux_irq)
- done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
- msecs_to_jiffies_timeout(10));
- else
- done = wait_for(C, 10) == 0;
+ done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
+ msecs_to_jiffies_timeout(10));
if (!done)
- DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
- has_aux_irq);
+ DRM_ERROR("dp aux hw did not signal timeout!\n");
#undef C
return status;
@@ -1016,7 +1012,6 @@ static uint32_t skl_get_aux_clock_divider(struct intel_dp
*intel_dp, int index)
}
static uint32_t g4x_get_aux_send_ctl(struct intel_dp *intel_dp,
-bool has_aux_irq,
int send_bytes,
uint32_t aux_clock_divider)
{
@@ -1037,7 +1032,7 @@ static uint32_t g4x_get_aux_send_ctl(struct intel_dp
*intel_dp,
return DP_AUX_CH_CTL_SEND_BUSY |
DP_AUX_CH_CTL_DONE |
- (has_aux_irq ? DP_AUX_CH_CTL_INTERRUPT : 0) |
+ DP_AUX_CH_CTL_INTERRUPT |
DP_AUX_CH_CTL_TIME_OUT_ERROR |
timeout |
DP_AUX_CH_CTL_RECEIVE_ERROR |
@@ -1047,13 +1042,12 @@ static uint32_t g4x_get_aux_send_ctl(struct intel_dp
*intel_dp,
}
static uint32_t skl_get_aux_send_ctl(struct intel_dp *intel_dp,
- bool has_aux_irq,
int send_bytes,
uint32_t unused)
{
return DP_AUX_CH_CTL_SEND_BUSY |
Re: [Intel-gfx] [PATCH 07/24] drm/i915/icl: Add DDI HDMI level selection for ICL
On Fri, Jun 1, 2018 at 3:32 PM Paulo Zanoni wrote:
>
> Em Sex, 2018-05-25 às 09:26 -0700, Lucas De Marchi escreveu:
> > On Mon, May 21, 2018 at 05:25:41PM -0700, Paulo Zanoni wrote:
> > > From: Manasi Navare
> > >
> > > This patch adds a proper HDMI DDI entry level for vswing
> > > programming sequences on ICL.
> > >
> > > Spec doesn't specify any default for HDMI tables,
> > > so let's pick the last entry as the default for now
> > > to stay consistent with older platform like CNL.
> > >
> > > Cc: Paulo Zanoni
> > > Cc: Rakshmi Bhatia
> > > Cc: Rodrigo Vivi
> > > Signed-off-by: Manasi Navare
> > > ---
> > > drivers/gpu/drm/i915/intel_ddi.c | 9 -
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 1665bc588241..d8ae82001f83 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -915,7 +915,14 @@ static int intel_ddi_hdmi_level(struct
> > > drm_i915_private *dev_priv, enum port por
> > >
> > > level = dev_priv-
> > > >vbt.ddi_port_info[port].hdmi_level_shift;
> > >
> > > - if (IS_CANNONLAKE(dev_priv)) {
> > > + if (IS_ICELAKE(dev_priv)) {
> > > + if (port == PORT_A || port == PORT_B)
> >
> > This should be using the helper you introduced in patch 3. Either a
> > 'if (!intel_port_is_tc()' or add a 'if (intel_port_is_combo)'.
> >
> > With that,
> >
> > Reviewed-by: Lucas De Marchi
>
> I don't think the !intel_port_is_tc() is a good call, and we don't have
> the intel_port_is_combo() as part of the ICL series, although we could
> have done it. Perhaps when we actually submit the patch adding
> intel_port_is_combo() then we can fix this issue on that patch? It
ok, I stand my r-b without it.
Lucas De Marchi
> would also help justifying the patch's existence.
>
> >
> > Lucas De Marchi
> >
> > > + icl_get_combo_buf_trans(dev_priv, port,
> > > + INTEL_OUTPUT_HDMI,
> > > _entries);
> > > + else
> > > + n_entries =
> > > ARRAY_SIZE(icl_mg_phy_ddi_translations);
> > > + default_entry = n_entries - 1;
> > > + } else if (IS_CANNONLAKE(dev_priv)) {
> > > cnl_get_buf_trans_hdmi(dev_priv, _entries);
> > > default_entry = n_entries - 1;
> > > } else if (IS_GEN9_LP(dev_priv)) {
> > > --
> > > 2.14.3
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/7] drm/i915: move towards kernel types
On Tue, Jun 12, 2018 at 3:15 AM Jani Nikula wrote: > > On Tue, 12 Jun 2018, Tvrtko Ursulin wrote: > > On 12/06/2018 10:19, Jani Nikula wrote: > >> Semi-RFC. Do we want to do this? Here's a batch of conversions that > >> shouldn't > >> conflict much with in-flight patches. > >> > >> The trouble with mixed use is that it's inconsistent, and any remaining C99 > >> types will encourage their use. We could at least do the low hanging fruit? > > > > Ack from me. Doesn't seem so big to cause much pain. > > > > When you say low-hanging fruit, that implies you only dealt with a > > particular class of occurrences? > > I meant the files which don't have massive amounts of C99 types and > aren't under active development right now. I just wanted to avoid > trouble for starters. ;) If using kernel types is where we want to go (which I agree with), maybe it would be better to have a single conversion rather than several small ones as we are doing with dev_priv -> i915? This allows in-flight-but-not-yet-sent patches to easily keep up with the changes rather than conflicting every other rebase. Lucas De Marchi > > > Also going forward we have to make sure we will be able to stop them > > creeping back in. Is checkpatch perhaps covering this? Or we could put > > something in dim? > > We can stop ignoring PREFER_KERNEL_TYPES in checkpatch (the ignores are > in dim). We don't even have to change everything for that, we just need > to change enough to make the S/N better. People tend to use the types > near the places they change. > > BR, > Jani. > > > > > > Regards, > > > > Tvrtko > > > >> $ git grep "uint\(8\|16\|32\|64\)_t" -- drivers/gpu/drm/i915/ | sed > >> 's/:.*//' | sort | uniq -c | sort -n > >> > >> BR, > >> Jani. > >> > >> > >> Jani Nikula (7): > >>drm/i915/vbt: switch to kernel unsigned int types > >>drm/i915/hdmi: switch to kernel unsigned int types > >>drm/i915/uncore: switch to kernel unsigned int types > >>drm/i915/dvo: switch to kernel unsigned int types > >>drm/i915/backlight: switch to kernel unsigned int types > >>drm/i915/audio: switch to kernel unsigned int types > >>drm/i915/lspcon: switch to kernel unsigned int types > >> > >> drivers/gpu/drm/i915/dvo_ch7017.c | 20 ++-- > >> drivers/gpu/drm/i915/dvo_ch7xxx.c | 22 +++--- > >> drivers/gpu/drm/i915/dvo_ivch.c | 26 > >> drivers/gpu/drm/i915/dvo_ns2501.c | 44 > >> +-- > >> drivers/gpu/drm/i915/dvo_sil164.c | 10 +++--- > >> drivers/gpu/drm/i915/dvo_tfp410.c | 16 +- > >> drivers/gpu/drm/i915/intel_audio.c| 36 +++--- > >> drivers/gpu/drm/i915/intel_bios.c | 4 +-- > >> drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 12 > >> drivers/gpu/drm/i915/intel_dvo.c | 2 +- > >> drivers/gpu/drm/i915/intel_hdmi.c | 14 - > >> drivers/gpu/drm/i915/intel_lspcon.c | 2 +- > >> drivers/gpu/drm/i915/intel_panel.c| 8 ++--- > >> drivers/gpu/drm/i915/intel_uncore.h | 22 +++--- > >> drivers/gpu/drm/i915/intel_vbt_defs.h | 2 +- > >> 15 files changed, 120 insertions(+), 120 deletions(-) > >> > > -- > Jani Nikula, Intel Open Source Graphics Center > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Lucas De Marchi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems
On Fri, Jun 8, 2018 at 5:34 AM Jani Nikula wrote:
>
> On Thu, 31 May 2018, Lucas De Marchi wrote:
> > On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote:
> >> Virtualized non-PCH systems such as Broxton or Geminilake should use
> >> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a
> >> specific case to indicate a PCH system without south display.
> >
> > Then let's go ahead and document it?
>
> Please avoid sending suggestion patches in-reply-to existing
> series. This confused patchwork and screwed up CI for the series, which
> was already a resend just to get CI. :(
ugh, sorry. Sometimes just adding a oneline diff is much better than
a hundred words explaining :( ... IMO pw is trying to be smarter than
it should here or not being smart enough. Nonetheless I won't do that
anymore.
Lucas De Marchi
>
> I'm resending the series, with your documentation patch added, but I'm
> keeping the extra explanatory text in the last patch. I think it's
> warranted.
>
> BR,
> Jani.
>
>
> >
> > -
> > Subject: [PATCH] drm/i915: document PCH_NOP
> >
> > There's a difference between PCH_NONE and PCH_NOP: the former means we
> > don't have a PCH while in the latter we do, but it doesn't have the
> > south display.
> >
> > Cc: Jani Nikula
> > Signed-off-by: Lucas De Marchi
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 72150f89f200..aa395a898258 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -631,7 +631,7 @@ enum intel_pch {
> > PCH_KBP,/* Kaby Lake PCH */
> > PCH_CNP,/* Cannon Lake PCH */
> > PCH_ICP,/* Ice Lake PCH */
> > - PCH_NOP,
> > + PCH_NOP,/* PCH without south display */
> > };
> >
> > enum intel_sbi_destination {
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems
On Wed, Jun 13, 2018 at 1:11 AM Arkadiusz Hiler wrote: > > On Wed, Jun 13, 2018 at 09:49:09AM +0300, Jani Nikula wrote: > > On Tue, 12 Jun 2018, Lucas De Marchi wrote: > > > On Fri, Jun 8, 2018 at 5:34 AM Jani Nikula wrote: > > >> > > >> On Thu, 31 May 2018, Lucas De Marchi wrote: > > >> > On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote: > > >> >> Virtualized non-PCH systems such as Broxton or Geminilake should use > > >> >> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a > > >> >> specific case to indicate a PCH system without south display. > > >> > > > >> > Then let's go ahead and document it? > > >> > > >> Please avoid sending suggestion patches in-reply-to existing > > >> series. This confused patchwork and screwed up CI for the series, which > > >> was already a resend just to get CI. :( > > > > > > ugh, sorry. Sometimes just adding a oneline diff is much better than > > > a hundred words explaining :( ... > > > > I feel you, a patch is more precise. > > > > > IMO pw is trying to be smarter than it should here or not being smart > > > enough. Nonetheless I won't do that anymore. > > > > I think there were earlier complaints about what it did recognize and > > what it didn't. I'd be open to only accepting new versions of patches > > from whoever sent the original patch. Or requiring patch subjects don't > > start with "Re:". Or both. > > No matter what you do here it will misbehave in some scenarios and > break someone's workflow :< > > Originally we required the patches to have X-Mailer set to > git-send-email, which seems reasonable, but that annoyed people because > their servers were stripping out those headers. > > Other people send out the patches by feeding them to the drafts folder > through IMAP and then sending them out. This, depending on the > provider's configuration, also gobbles up a thing or two. > > Because of the above I am not sure about trusting "Re:" and matching > "From:" headers as good enough indicators either. > > It just adds more opaque "smartness". I already can foresee questions > asking "why my v2 was not picked up?" and someone would have to debug it > down the line. > > Was the address different (+XYZ before @)? Has that someone used > --subject-prefix=re:? Is it an actual bug? Etc. > > > > I was annoyed, but I'm perhaps more annoyed that you can't do this > > without confusing patchwork. In the end, I wouldn't want to hamper > > review by blocking something that comes naturally to people. > > > > Arek? > > Just add the following header: > "X-Patchwork-Hint: comment" > to emails that you type out manually. > > For mutt it's as easy as adding: > "my_hdr X-Patchwork-Hint: comment" > to your .muttrc This may not work for the same reasons you pointed out that wouldn't work if people are sending patches. Is there a format I can use that will not trigger patchwork from parsing a _reply_? Does removing the "" help? Under the hood does it use git am --scissors or similar? Lucas De Marchi > > https://github.com/dlespiau/patchwork/commit/148f10115525 > > -- > Cheers, > Arek -- Lucas De Marchi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems
On Wed, Jun 13, 2018 at 10:09 AM Lucas De Marchi wrote: > > On Wed, Jun 13, 2018 at 1:11 AM Arkadiusz Hiler > wrote: > > > > On Wed, Jun 13, 2018 at 09:49:09AM +0300, Jani Nikula wrote: > > > On Tue, 12 Jun 2018, Lucas De Marchi wrote: > > > > On Fri, Jun 8, 2018 at 5:34 AM Jani Nikula > > > > wrote: > > > >> > > > >> On Thu, 31 May 2018, Lucas De Marchi wrote: > > > >> > On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote: > > > >> >> Virtualized non-PCH systems such as Broxton or Geminilake should use > > > >> >> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a > > > >> >> specific case to indicate a PCH system without south display. > > > >> > > > > >> > Then let's go ahead and document it? > > > >> > > > >> Please avoid sending suggestion patches in-reply-to existing > > > >> series. This confused patchwork and screwed up CI for the series, which > > > >> was already a resend just to get CI. :( > > > > > > > > ugh, sorry. Sometimes just adding a oneline diff is much better than > > > > a hundred words explaining :( ... > > > > > > I feel you, a patch is more precise. > > > > > > > IMO pw is trying to be smarter than it should here or not being smart > > > > enough. Nonetheless I won't do that anymore. > > > > > > I think there were earlier complaints about what it did recognize and > > > what it didn't. I'd be open to only accepting new versions of patches > > > from whoever sent the original patch. Or requiring patch subjects don't > > > start with "Re:". Or both. > > > > No matter what you do here it will misbehave in some scenarios and > > break someone's workflow :< > > > > Originally we required the patches to have X-Mailer set to > > git-send-email, which seems reasonable, but that annoyed people because > > their servers were stripping out those headers. > > > > Other people send out the patches by feeding them to the drafts folder > > through IMAP and then sending them out. This, depending on the > > provider's configuration, also gobbles up a thing or two. > > > > Because of the above I am not sure about trusting "Re:" and matching > > "From:" headers as good enough indicators either. > > > > It just adds more opaque "smartness". I already can foresee questions > > asking "why my v2 was not picked up?" and someone would have to debug it > > down the line. > > > > Was the address different (+XYZ before @)? Has that someone used > > --subject-prefix=re:? Is it an actual bug? Etc. > > > > > > > I was annoyed, but I'm perhaps more annoyed that you can't do this > > > without confusing patchwork. In the end, I wouldn't want to hamper > > > review by blocking something that comes naturally to people. > > > > > > Arek? > > > > Just add the following header: > > "X-Patchwork-Hint: comment" > > to emails that you type out manually. > > > > For mutt it's as easy as adding: > > "my_hdr X-Patchwork-Hint: comment" > > to your .muttrc > > This may not work for the same reasons you pointed out that wouldn't > work if people are sending patches. Is there a format I can use that > will not trigger patchwork from parsing a _reply_? Does removing the > "" help? Under the hood does it use git am --scissors or > similar? Humn... it has its own parser. So if I read https://github.com/dlespiau/patchwork/blob/master/patchwork/parser.py#L36 correctly, it should be just a matter of omitting the "diff | ---" lines (or prepending with a "#"). It does make things more difficult if the other person would use "git am --scissors" though. Lucas De Marchi > > > Lucas De Marchi > > > > > https://github.com/dlespiau/patchwork/commit/148f10115525 > > > > -- > > Cheers, > > Arek > > > > -- > Lucas De Marchi -- Lucas De Marchi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/24] drm/i915/icl: Support for TC North Display interrupts
+Chris
On Mon, May 21, 2018 at 05:25:38PM -0700, Paulo Zanoni wrote:
> From: Dhinakaran Pandiyan
>
> The hotplug interrupts for the ports can be routed to either North
> Display or South Display depending on the output mode. DP Alternate or
> DP over TBT outputs will have hotplug interrupts routed to the North
> Display while interrupts for legacy modes will be routed to the South
> Display in PCH. This patch adds hotplug interrupt handling support for
> DP Alternate mode.
>
> Cc: Jani Nikula
> Cc: Anusha Srivatsa
> Signed-off-by: Dhinakaran Pandiyan
> [Paulo: coding style changes]
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_irq.c | 95
> +++--
> drivers/gpu/drm/i915/i915_reg.h | 20 +
> 2 files changed, 112 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index dde938bbfb0a..9bcec5fdb9d0 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -115,6 +115,13 @@ static const u32 hpd_bxt[HPD_NUM_PINS] = {
> [HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
> };
>
> +static const u32 hpd_tc_gen11[HPD_NUM_PINS] = {
> + [HPD_PORT_C] = GEN11_TC1_HOTPLUG,
> + [HPD_PORT_D] = GEN11_TC2_HOTPLUG,
> + [HPD_PORT_E] = GEN11_TC3_HOTPLUG,
> + [HPD_PORT_F] = GEN11_TC4_HOTPLUG
> +};
> +
> /* IIR can theoretically queue up two events. Be paranoid. */
> #define GEN8_IRQ_RESET_NDX(type, which) do { \
> I915_WRITE(GEN8_##type##_IMR(which), 0x); \
> @@ -1549,6 +1556,22 @@ static void gen8_gt_irq_handler(struct
> drm_i915_private *i915,
> }
> }
>
> +static bool gen11_port_hotplug_long_detect(enum port port, u32 val)
> +{
> + switch (port) {
> + case PORT_C:
> + return val & GEN11_HOTPLUG_CTL_LONG_DETECT(PORT_TC1);
> + case PORT_D:
> + return val & GEN11_HOTPLUG_CTL_LONG_DETECT(PORT_TC2);
> + case PORT_E:
> + return val & GEN11_HOTPLUG_CTL_LONG_DETECT(PORT_TC3);
> + case PORT_F:
> + return val & GEN11_HOTPLUG_CTL_LONG_DETECT(PORT_TC4);
> + default:
> + return false;
> + }
> +}
> +
> static bool bxt_port_hotplug_long_detect(enum port port, u32 val)
> {
> switch (port) {
> @@ -2590,6 +2613,25 @@ static void bxt_hpd_irq_handler(struct
> drm_i915_private *dev_priv,
> intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
> }
>
> +static void gen11_hpd_irq_handler(struct drm_i915_private *dev_priv, u32 iir)
> +{
> + u32 pin_mask = 0, long_mask = 0;
> + u32 trigger_tc, dig_hotplug_reg;
> +
> + trigger_tc = iir & GEN11_DE_TC_HOTPLUG_MASK;
> + if (trigger_tc) {
> + dig_hotplug_reg = I915_READ(GEN11_TC_HOTPLUG_CTL);
> + I915_WRITE(GEN11_TC_HOTPLUG_CTL, dig_hotplug_reg);
> +
> + intel_get_hpd_pins(dev_priv, _mask, _mask, trigger_tc,
> +dig_hotplug_reg, hpd_tc_gen11,
> +gen11_port_hotplug_long_detect);
> + intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
> + } else {
> + DRM_ERROR("Unexpected DE HPD interrupt 0x%08x\n", iir);
> + }
> +}
> +
> static irqreturn_t
> gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
> {
> @@ -2626,6 +2668,17 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
> u32 master_ctl)
> DRM_ERROR("The master control interrupt lied (DE
> MISC)!\n");
> }
>
> + if (INTEL_GEN(dev_priv) >= 11 && (master_ctl & GEN11_DE_HPD_IRQ)) {
> + iir = I915_READ(GEN11_DE_HPD_IIR);
> + if (iir) {
> + I915_WRITE(GEN11_DE_HPD_IIR, iir);
> + ret = IRQ_HANDLED;
> + gen11_hpd_irq_handler(dev_priv, iir);
I think the same question as for the 2nd patch remains here. Shouldn't
we being re-enabling the master interrupt before doing any further
processing?
However all gens are like that. A change here seems to belong on a
different patch... it's also the case for previous gens. Chris, is there
anything different you are seeing on gen11?
Lucas De Marchi
> + } else {
> + DRM_ERROR("The master control interrupt lied, (DE
> HPD)!\n");
> + }
> + }
> +
> if (master_ctl & GEN8_DE_PORT_IRQ) {
> iir = I915_READ(GEN8_DE_PORT_IIR);
> if (iir) {
> @@ -3492,6 +3545,7 @@ static void gen11_irq_reset(struct drm_device *dev)
>
> GEN3_IRQ_RESET(GEN8_DE_POR
Re: [Intel-gfx] [PATCH 10/24] drm/i915/icl: add icelake_get_ddi_pll()
On Wed, Jun 13, 2018 at 04:51:57PM -0700, Paulo Zanoni wrote:
> Em Qua, 2018-06-13 às 16:15 -0700, Lucas De Marchi escreveu:
> > On Mon, May 21, 2018 at 05:25:44PM -0700, Paulo Zanoni wrote:
> > > Implement the hardware state readout code.
> > >
> > > Thanks to Animesh Manna for spotting this problem.
> > >
> > > Cc: Animesh Manna
> > > Credits-to: Animesh Manna
> > > Signed-off-by: Paulo Zanoni
> > > ---
> > > drivers/gpu/drm/i915/intel_display.c | 42
> > > +++-
> > > 1 file changed, 41 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 64593b0fbebd..d5a19c1b3b20 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -9146,6 +9146,44 @@ static void cannonlake_get_ddi_pll(struct
> > > drm_i915_private *dev_priv,
> > > pipe_config->shared_dpll =
> > > intel_get_shared_dpll_by_id(dev_priv, id);
> > > }
> > >
> > > +static void icelake_get_ddi_pll(struct drm_i915_private *dev_priv,
> > > + enum port port,
> > > + struct intel_crtc_state
> > > *pipe_config)
> > > +{
> > > + enum intel_dpll_id id;
> > > + u32 temp;
> > > +
> > > + /* TODO: TBT pll not implemented. */
> > > + switch (port) {
> > > + case PORT_A:
> > > + case PORT_B:
> > > + temp = I915_READ(DPCLKA_CFGCR0_ICL) &
> > > +DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
> > > + id = temp >>
> > > DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port);
> >
> > This could be simpler:
> >
> > temp = I915_READ(DPCLKA_CFGCR0_ICL) >>
> > DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port);
> > id = temp & DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(0);
>
> I fail to understand why this is simpler... The same operations, just
> on a different order.
If you open up the macros you will see there are more operations on what
we are doing right now... and we wouldn't need to depend on the port for
this if we had done this way. However we already depend on having the
port as an argument in other places, so there's nothing to do
differently on this particular patch.
Lucas De Marchi
>
>
> >
> > But this ship has sailed, aka MASK above requires the port and
> > hardcoding 0 doesn't make it better IMO.
> >
> >
> > Reviewed-by: Lucas De Marchi
> >
>
> Thanks!
>
> >
> > Lucas De Marchi
> >
> > > +
> > > + if (WARN_ON(id != DPLL_ID_ICL_DPLL0 && id !=
> > > DPLL_ID_ICL_DPLL1))
> > > + return;
> > > + break;
> > > + case PORT_C:
> > > + id = DPLL_ID_ICL_MGPLL1;
> > > + break;
> > > + case PORT_D:
> > > + id = DPLL_ID_ICL_MGPLL2;
> > > + break;
> > > + case PORT_E:
> > > + id = DPLL_ID_ICL_MGPLL3;
> > > + break;
> > > + case PORT_F:
> > > + id = DPLL_ID_ICL_MGPLL4;
> > > + break;
> > > + default:
> > > + MISSING_CASE(port);
> > > + return;
> > > + }
> > > +
> > > + pipe_config->shared_dpll =
> > > intel_get_shared_dpll_by_id(dev_priv, id);
> > > +}
> > > +
> > > static void bxt_get_ddi_pll(struct drm_i915_private *dev_priv,
> > > enum port port,
> > > struct intel_crtc_state
> > > *pipe_config)
> > > @@ -9333,7 +9371,9 @@ static void haswell_get_ddi_port_state(struct
> > > intel_crtc *crtc,
> > >
> > > port = (tmp & TRANS_DDI_PORT_MASK) >>
> > > TRANS_DDI_PORT_SHIFT;
> > >
> > > - if (IS_CANNONLAKE(dev_priv))
> > > + if (IS_ICELAKE(dev_priv))
> > > + icelake_get_ddi_pll(dev_priv, port, pipe_config);
> > > + else if (IS_CANNONLAKE(dev_priv))
> > > cannonlake_get_ddi_pll(dev_priv, port,
> > > pipe_config);
> > > else if (IS_GEN9_BC(dev_priv))
> > > skylake_get_ddi_pll(dev_priv, port, pipe_config);
> > > --
> > > 2.14.3
> > >
> > > ___
> > > 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 14/24] drm/i915/icl: start adding the TBT pll
On Mon, May 21, 2018 at 05:25:48PM -0700, Paulo Zanoni wrote:
> This commit just adds the register addresses and the basic skeleton of
> the code. The next commits will expand on more specific functions.
>
> Signed-off-by: Paulo Zanoni
Reviewed-by: Lucas De Marchi
Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6 ++
> drivers/gpu/drm/i915/intel_ddi.c | 16
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 20
> drivers/gpu/drm/i915/intel_dpll_mgr.h | 14 +-
> 4 files changed, 47 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 26903cffabf6..ce79913466a7 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8878,6 +8878,10 @@ enum skl_power_gate {
> #define DDI_CLK_SEL(port)PORT_CLK_SEL(port)
> #define DDI_CLK_SEL_NONE(0x0 << 28)
> #define DDI_CLK_SEL_MG (0x8 << 28)
> +#define DDI_CLK_SEL_TBT_162 (0xC << 28)
> +#define DDI_CLK_SEL_TBT_270 (0xD << 28)
> +#define DDI_CLK_SEL_TBT_540 (0xE << 28)
> +#define DDI_CLK_SEL_TBT_810 (0xF << 28)
> #define DDI_CLK_SEL_MASK(0xF << 28)
>
> /* Transcoder clock selection */
> @@ -9027,6 +9031,8 @@ enum skl_power_gate {
> #define PLL_POWER_STATE (1 << 26)
> #define CNL_DPLL_ENABLE(pll) _MMIO_PLL(pll, DPLL0_ENABLE, DPLL1_ENABLE)
>
> +#define TBT_PLL_ENABLE _MMIO(0x46020)
> +
> #define _MG_PLL1_ENABLE 0x46030
> #define _MG_PLL2_ENABLE 0x46034
> #define _MG_PLL3_ENABLE 0x46038
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 32e7482b64dd..1d5bfec57c33 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1062,6 +1062,8 @@ static uint32_t hsw_pll_to_ddi_pll_sel(const struct
> intel_shared_dpll *pll)
> static uint32_t icl_pll_to_ddi_pll_sel(struct intel_encoder *encoder,
> const struct intel_shared_dpll *pll)
> {
> + struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
> + int clock = crtc->config->port_clock;
> const enum intel_dpll_id id = pll->info->id;
>
> switch (id) {
> @@ -1070,6 +1072,20 @@ static uint32_t icl_pll_to_ddi_pll_sel(struct
> intel_encoder *encoder,
> case DPLL_ID_ICL_DPLL0:
> case DPLL_ID_ICL_DPLL1:
> return DDI_CLK_SEL_NONE;
> + case DPLL_ID_ICL_TBTPLL:
> + switch (clock) {
> + case 162000:
> + return DDI_CLK_SEL_TBT_162;
> + case 27:
> + return DDI_CLK_SEL_TBT_270;
> + case 54:
> + return DDI_CLK_SEL_TBT_540;
> + case 81:
> + return DDI_CLK_SEL_TBT_810;
> + default:
> + MISSING_CASE(clock);
> + break;
> + }
> case DPLL_ID_ICL_MGPLL1:
> case DPLL_ID_ICL_MGPLL2:
> case DPLL_ID_ICL_MGPLL3:
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 3cc837f74ffb..72f15e727d07 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2853,10 +2853,17 @@ icl_get_dpll(struct intel_crtc *crtc, struct
> intel_crtc_state *crtc_state,
> case PORT_D:
> case PORT_E:
> case PORT_F:
> - min = icl_port_to_mg_pll_id(port);
> - max = min;
> - ret = icl_calc_mg_pll_state(crtc_state, encoder, clock,
> - _state);
> + if (0 /* TODO: TBT PLLs */) {
> + min = DPLL_ID_ICL_TBTPLL;
> + max = min;
> + ret = icl_calc_dpll_state(crtc_state, encoder, clock,
> + _state);
> + } else {
> + min = icl_port_to_mg_pll_id(port);
> + max = min;
> + ret = icl_calc_mg_pll_state(crtc_state, encoder, clock,
> + _state);
> + }
> break;
> default:
> MISSING_CASE(port);
> @@ -2889,6 +2896,8 @@ static i915_reg_t icl_pll_id_to_enable_reg(enum
> intel_dpll_id id)
> case DPLL_ID_ICL_DPLL0:
> case DPLL_ID_ICL_DPLL1:
> return CNL_DPLL_ENABLE(id);
> + case DPLL_ID_ICL_TBTPLL:
>
Re: [Intel-gfx] [PATCH 05/24] drm/i915/icp: Add Interrupt Support
On Tue, May 29, 2018 at 05:04:58PM -0700, Lucas De Marchi wrote:
> On Thu, May 24, 2018 at 05:43:24PM -0700, Lucas De Marchi wrote:
> > On Thu, May 24, 2018 at 05:45:43PM -0700, Dhinakaran Pandiyan wrote:
> > > On Thu, 2018-05-24 at 16:53 -0700, Lucas De Marchi wrote:
> > > > On Mon, May 21, 2018 at 05:25:39PM -0700, Paulo Zanoni wrote:
> > > > >
> > > > > From: Anusha Srivatsa
> > > > >
> > > > > This patch addresses Interrupts from south display engine (SDE).
> > > > >
> > > > > ICP has two registers - SHOTPLUG_CTL_DDI and SHOTPLUG_CTL_TC.
> > > > > Introduce these registers and their intended values.
> > > > >
> > > > > Introduce icp_irq_handler().
> > > > >
> > > > > Cc: Paulo Zanoni
> > > > > Cc: Dhinakaran Pandiyan
> > > > > Cc: Ville Syrjala
> > > > > Signed-off-by: Anusha Srivatsa
> > > > > [Paulo: coding style bikesheds and rebases].
> > > > > Signed-off-by: Paulo Zanoni
> > > > > ---
> > > > > drivers/gpu/drm/i915/i915_irq.c | 134
> > > > > +++-
> > > > > drivers/gpu/drm/i915/i915_reg.h | 40
> > > > > 2 files changed, 172 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > > index 9bcec5fdb9d0..6b109991786f 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > > @@ -122,6 +122,15 @@ static const u32 hpd_tc_gen11[HPD_NUM_PINS] =
> > > > > {
> > > > > [HPD_PORT_F] = GEN11_TC4_HOTPLUG
> > > > > };
> > > > >
> > > > > +static const u32 hpd_icp[HPD_NUM_PINS] = {
> > > > > + [HPD_PORT_A] = ICP_DDIA_HOTPLUG,
> > > > > + [HPD_PORT_B] = ICP_DDIB_HOTPLUG,
> > > > > + [HPD_PORT_C] = ICP_TC1_HOTPLUG,
> > > > > + [HPD_PORT_D] = ICP_TC2_HOTPLUG,
> > > > > + [HPD_PORT_E] = ICP_TC3_HOTPLUG,
> > > > > + [HPD_PORT_F] = ICP_TC4_HOTPLUG
> > > > > +};
> > > > > +
> > > > > /* IIR can theoretically queue up two events. Be paranoid. */
> > > > > #define GEN8_IRQ_RESET_NDX(type, which) do { \
> > > > > I915_WRITE(GEN8_##type##_IMR(which), 0x); \
> > > > > @@ -1586,6 +1595,34 @@ static bool
> > > > > bxt_port_hotplug_long_detect(enum port port, u32 val)
> > > > > }
> > > > > }
> > > > >
> > > > > +static bool icp_ddi_port_hotplug_long_detect(enum port port, u32
> > > > > val)
> > > > > +{
> > > > > + switch (port) {
> > > > > + case PORT_A:
> > > > > + return val & ICP_DDIA_HPD_LONG_DETECT;
> > > > > + case PORT_B:
> > > > > + return val & ICP_DDIB_HPD_LONG_DETECT;
> > > > > + default:
> > > > > + return false;
> > > > > + }
> > > > > +}
> > > > > +
> > > > > +static bool icp_tc_port_hotplug_long_detect(enum port port, u32
> > > > > val)
> > > > > +{
> > > > > + switch (port) {
> > > > > + case PORT_C:
> > > > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC1);
> > > > > + case PORT_D:
> > > > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC2);
> > > > > + case PORT_E:
> > > > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC3);
> > > > > + case PORT_F:
> > > > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC4);
> > > > > + default:
> > > > > + return false;
> > > > > + }
> > > > > +}
> > > > > +
> > > > > static bool spt_port_hotplug2_long_detect(enum port port, u32 val)
> > > > > {
> > > > > switch (port) {
> > > > > @@ -2377,6 +2414,43 @@ static void cpt_irq_handler(struct
> > > > > drm_i915_private *dev_priv, u32 pch_iir)
> > > > > cpt_serr_
Re: [Intel-gfx] [PATCH 10/24] drm/i915/icl: add icelake_get_ddi_pll()
On Mon, May 21, 2018 at 05:25:44PM -0700, Paulo Zanoni wrote:
> Implement the hardware state readout code.
>
> Thanks to Animesh Manna for spotting this problem.
>
> Cc: Animesh Manna
> Credits-to: Animesh Manna
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_display.c | 42
> +++-
> 1 file changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 64593b0fbebd..d5a19c1b3b20 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9146,6 +9146,44 @@ static void cannonlake_get_ddi_pll(struct
> drm_i915_private *dev_priv,
> pipe_config->shared_dpll = intel_get_shared_dpll_by_id(dev_priv, id);
> }
>
> +static void icelake_get_ddi_pll(struct drm_i915_private *dev_priv,
> + enum port port,
> + struct intel_crtc_state *pipe_config)
> +{
> + enum intel_dpll_id id;
> + u32 temp;
> +
> + /* TODO: TBT pll not implemented. */
> + switch (port) {
> + case PORT_A:
> + case PORT_B:
> + temp = I915_READ(DPCLKA_CFGCR0_ICL) &
> +DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
> + id = temp >> DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port);
This could be simpler:
temp = I915_READ(DPCLKA_CFGCR0_ICL) >>
DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port);
id = temp & DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(0);
But this ship has sailed, aka MASK above requires the port and
hardcoding 0 doesn't make it better IMO.
Reviewed-by: Lucas De Marchi
Lucas De Marchi
> +
> + if (WARN_ON(id != DPLL_ID_ICL_DPLL0 && id != DPLL_ID_ICL_DPLL1))
> + return;
> + break;
> + case PORT_C:
> + id = DPLL_ID_ICL_MGPLL1;
> + break;
> + case PORT_D:
> + id = DPLL_ID_ICL_MGPLL2;
> + break;
> + case PORT_E:
> + id = DPLL_ID_ICL_MGPLL3;
> + break;
> + case PORT_F:
> + id = DPLL_ID_ICL_MGPLL4;
> + break;
> + default:
> + MISSING_CASE(port);
> + return;
> + }
> +
> + pipe_config->shared_dpll = intel_get_shared_dpll_by_id(dev_priv, id);
> +}
> +
> static void bxt_get_ddi_pll(struct drm_i915_private *dev_priv,
> enum port port,
> struct intel_crtc_state *pipe_config)
> @@ -9333,7 +9371,9 @@ static void haswell_get_ddi_port_state(struct
> intel_crtc *crtc,
>
> port = (tmp & TRANS_DDI_PORT_MASK) >> TRANS_DDI_PORT_SHIFT;
>
> - if (IS_CANNONLAKE(dev_priv))
> + if (IS_ICELAKE(dev_priv))
> + icelake_get_ddi_pll(dev_priv, port, pipe_config);
> + else if (IS_CANNONLAKE(dev_priv))
> cannonlake_get_ddi_pll(dev_priv, port, pipe_config);
> else if (IS_GEN9_BC(dev_priv))
> skylake_get_ddi_pll(dev_priv, port, pipe_config);
> --
> 2.14.3
>
> ___
> 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 13/24] drm/i915/icl: unconditionally init DDI for every port
On Mon, May 21, 2018 at 05:25:47PM -0700, Paulo Zanoni wrote:
> On ICP, port present straps are no longer supported. Software should
ICP?? Doesn't it make more sense to say on ICL here?
> determine the presence through BIOS VBT, hotplug or other mechanisms.
>
> Signed-off-by: Paulo Zanoni
Reviewed-by: Lucas De Marchi
Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_display.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index d5a19c1b3b20..528d9f9c456d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13965,7 +13965,14 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> if (intel_crt_present(dev_priv))
> intel_crt_init(dev_priv);
>
> - if (IS_GEN9_LP(dev_priv)) {
> + if (IS_ICELAKE(dev_priv)) {
> + intel_ddi_init(dev_priv, PORT_A);
> + intel_ddi_init(dev_priv, PORT_B);
> + intel_ddi_init(dev_priv, PORT_C);
> + intel_ddi_init(dev_priv, PORT_D);
> + intel_ddi_init(dev_priv, PORT_E);
> + intel_ddi_init(dev_priv, PORT_F);
> + } else if (IS_GEN9_LP(dev_priv)) {
> /*
>* FIXME: Broxton doesn't support port detection via the
>* DDI_BUF_CTL_A or SFUSE_STRAP registers, find another way to
> --
> 2.14.3
>
> ___
> 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] drm/i915: remove check for aux irq
On Fri, Jun 15, 2018 at 08:58:28PM +0300, Ville Syrjälä wrote:
> On Wed, May 23, 2018 at 11:04:35AM -0700, Lucas De Marchi wrote:
> > This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> > GMBUS and AUX interrupts on gen4/g4x").
> >
> > v2: Move comment about HW behavior to where decision is made to enable
> > MSI (Ville).
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Lucas De Marchi
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 6 ++
> > drivers/gpu/drm/i915/i915_drv.h | 10 --
> > drivers/gpu/drm/i915/intel_dp.c | 22 +++---
> > drivers/gpu/drm/i915/intel_drv.h | 1 -
> > drivers/gpu/drm/i915/intel_psr.c | 2 +-
> > 5 files changed, 14 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 9c449b8d8eab..a1461de20472 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1189,6 +1189,12 @@ static int i915_driver_init_hw(struct
> > drm_i915_private *dev_priv)
> > * get lost on g4x as well, and interrupt delivery seems to stay
> > * properly dead afterwards. So we'll just disable them for all
> > * pre-gen5 chipsets.
> > +*
> > +* dp aux and gmbus irq on gen4 seems to be able to generate legacy
> > +* interrupts even when in MSI mode. This results in spurious
> > +* interrupt warnings if the legacy irq no. is shared with another
> > +* device. The kernel then disables that interrupt source and so
> > +* prevents the other device from working properly.
> > */
> > if (INTEL_GEN(dev_priv) >= 5) {
> > if (pci_enable_msi(pdev) < 0)
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index b86ed6401120..c5e1f648c47c 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2558,16 +2558,6 @@ intel_info(const struct drm_i915_private *dev_priv)
> > (IS_CANNONLAKE(dev_priv) || \
> > IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> >
> > -/*
> > - * dp aux and gmbus irq on gen4 seems to be able to generate legacy
> > interrupts
> > - * even when in MSI mode. This results in spurious interrupt warnings if
> > the
> > - * legacy irq no. is shared with another device. The kernel then disables
> > that
> > - * interrupt source and so prevents the other device from working properly.
> > - *
> > - * Since we don't enable MSI anymore on gen4, we can always use GMBUS/AUX
> > - * interrupts.
> > - */
> > -#define HAS_AUX_IRQ(dev_priv) true
> > #define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
> >
> > /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index ce07bd794aed..1dab40056df7 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -936,7 +936,7 @@ intel_dp_check_edp(struct intel_dp *intel_dp)
> > }
> >
> > static uint32_t
> > -intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
> > +intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> > {
> > struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
> > i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
> > @@ -944,14 +944,10 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp,
> > bool has_aux_irq)
> > bool done;
> >
> > #define C (((status = I915_READ_NOTRACE(ch_ctl)) &
> > DP_AUX_CH_CTL_SEND_BUSY) == 0)
> > - if (has_aux_irq)
> > - done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
> > - msecs_to_jiffies_timeout(10));
> > - else
> > - done = wait_for(C, 10) == 0;
> > + done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
> > + msecs_to_jiffies_timeout(10));
> > if (!done)
> > - DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
> > - has_aux_irq);
> > + DRM_ERROR("dp aux hw did not signal timeout!\n");
> > #undef C
> >
> > return status;
> > @@ -1016,7 +1012,6 @@ static uint32_t skl_get_aux_clock_divider(struct
> > intel_dp *intel_dp, int index)
> > }
> >
> > static uint32_t g4x_get_aux_send_c
Re: [Intel-gfx] [PATCH 18/24] drm/i915/icl: implement icl_digital_port_connected()
On Mon, May 21, 2018 at 05:25:52PM -0700, Paulo Zanoni wrote:
> Do like the other functions and check for the ISR bits. We have plans
> to add a few more checks in this code in the next patches, that's why
> it's a little more verbose than it could be.
>
> Cc: Animesh Manna
> Signed-off-by: Paulo Zanoni
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 5
> drivers/gpu/drm/i915/intel_dp.c | 57
> +
> 2 files changed, 62 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 49a72320e794..24308d4435f5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7055,6 +7055,7 @@ enum {
> #define GEN11_TC3_HOTPLUG (1 << 18)
> #define GEN11_TC2_HOTPLUG (1 << 17)
> #define GEN11_TC1_HOTPLUG (1 << 16)
> +#define GEN11_TC_HOTPLUG(tc_port) (1 << ((tc_port) + 16))
> #define GEN11_DE_TC_HOTPLUG_MASK(GEN11_TC4_HOTPLUG | \
>GEN11_TC3_HOTPLUG | \
>GEN11_TC2_HOTPLUG | \
> @@ -7063,6 +7064,7 @@ enum {
> #define GEN11_TBT3_HOTPLUG (1 << 2)
> #define GEN11_TBT2_HOTPLUG (1 << 1)
> #define GEN11_TBT1_HOTPLUG (1 << 0)
> +#define GEN11_TBT_HOTPLUG(tc_port) (1 << (tc_port))
> #define GEN11_DE_TBT_HOTPLUG_MASK (GEN11_TBT4_HOTPLUG | \
>GEN11_TBT3_HOTPLUG | \
>GEN11_TBT2_HOTPLUG | \
> @@ -7486,6 +7488,9 @@ enum {
> #define ICP_GMBUS (1 << 23)
> #define ICP_DDIB_HOTPLUG (1 << 17)
> #define ICP_DDIA_HOTPLUG (1 << 16)
> +#define ICP_TC_HOTPLUG(tc_port) (1 << ((tc_port) + 24))
> +#define ICP_DDI_HOTPLUG(port)(1 << ((port) + 16))
> +
>
> #define ICP_SDE_DDI_MASK (ICP_DDIB_HOTPLUG | \
>ICP_DDIA_HOTPLUG)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 102070940095..b477124717e7 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4722,6 +4722,61 @@ static bool bxt_digital_port_connected(struct
> intel_encoder *encoder)
> return I915_READ(GEN8_DE_PORT_ISR) & bit;
> }
>
> +static bool icl_combo_port_connected(struct drm_i915_private *dev_priv,
> + struct intel_digital_port *intel_dig_port)
> +{
> + enum port port = intel_dig_port->base.port;
> +
> + return I915_READ(ICP_SDE_ISR) & ICP_DDI_HOTPLUG(port);
> +}
> +
> +static bool icl_tc_port_connected(struct drm_i915_private *dev_priv,
> + struct intel_digital_port *intel_dig_port)
> +{
> + enum port port = intel_dig_port->base.port;
> + enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> + u32 legacy_bit = ICP_TC_HOTPLUG(tc_port);
> + u32 typec_bit = GEN11_TC_HOTPLUG(tc_port);
> + u32 tbt_bit = GEN11_TBT_HOTPLUG(tc_port);
> + bool is_legacy = false, is_typec = false, is_tbt = false;
> + u32 cpu_isr;
why *cpu*_isr? hpd_isr, isr or val would be better IMO
> +
> + if (I915_READ(ICP_SDE_ISR) & legacy_bit)
> + is_legacy = true;
> +
> + cpu_isr = I915_READ(GEN11_DE_HPD_ISR);
> + if (cpu_isr & typec_bit)
> + is_typec = true;
> + if (cpu_isr & tbt_bit)
> + is_tbt = true;
> +
> + WARN_ON(is_legacy + is_typec + is_tbt > 1);
> + if (!is_legacy && !is_typec && !is_tbt)
> + return false;
> +
> + return true;
you know you could "return is_legacy + is_typec + is_tbt;", right? you
are already doing it above, it may make sense to remove the extra
branch. Or not.
Feel free to disagree and push.
Reviewed-by: Lucas De Marchi
Lucas De Marchi
> +}
> +
> +static bool icl_digital_port_connected(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> +
> + switch (encoder->hpd_pin) {
> + case HPD_PORT_A:
> + case HPD_PORT_B:
> + return icl_combo_port_connected(dev_priv, dig_port);
> + case HPD_PORT_C:
> + case HPD_PORT_D:
> + case HPD_PORT_E:
> + case HPD_PORT_F:
> + return icl_tc
Re: [Intel-gfx] [PATCH v2] drm/i915: remove check for aux irq
On Tue, Jun 19, 2018 at 7:06 AM Ville Syrjälä
wrote:
>
> On Fri, Jun 15, 2018 at 02:51:06PM -0700, Lucas De Marchi wrote:
> > On Fri, Jun 15, 2018 at 08:58:28PM +0300, Ville Syrjälä wrote:
> > > On Wed, May 23, 2018 at 11:04:35AM -0700, Lucas De Marchi wrote:
> > > > This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> > > > GMBUS and AUX interrupts on gen4/g4x").
> > > >
> > > > v2: Move comment about HW behavior to where decision is made to enable
> > > > MSI (Ville).
> > > >
> > > > Cc: Ville Syrjälä
> > > > Signed-off-by: Lucas De Marchi
> > > > ---
> > > > drivers/gpu/drm/i915/i915_drv.c | 6 ++
> > > > drivers/gpu/drm/i915/i915_drv.h | 10 --
> > > > drivers/gpu/drm/i915/intel_dp.c | 22 +++---
> > > > drivers/gpu/drm/i915/intel_drv.h | 1 -
> > > > drivers/gpu/drm/i915/intel_psr.c | 2 +-
> > > > 5 files changed, 14 insertions(+), 27 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > index 9c449b8d8eab..a1461de20472 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > @@ -1189,6 +1189,12 @@ static int i915_driver_init_hw(struct
> > > > drm_i915_private *dev_priv)
> > > >* get lost on g4x as well, and interrupt delivery seems to stay
> > > >* properly dead afterwards. So we'll just disable them for all
> > > >* pre-gen5 chipsets.
> > > > + *
> > > > + * dp aux and gmbus irq on gen4 seems to be able to generate legacy
> > > > + * interrupts even when in MSI mode. This results in spurious
> > > > + * interrupt warnings if the legacy irq no. is shared with another
> > > > + * device. The kernel then disables that interrupt source and so
> > > > + * prevents the other device from working properly.
> > > >*/
> > > > if (INTEL_GEN(dev_priv) >= 5) {
> > > > if (pci_enable_msi(pdev) < 0)
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index b86ed6401120..c5e1f648c47c 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2558,16 +2558,6 @@ intel_info(const struct drm_i915_private
> > > > *dev_priv)
> > > > (IS_CANNONLAKE(dev_priv) || \
> > > >IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> > > >
> > > > -/*
> > > > - * dp aux and gmbus irq on gen4 seems to be able to generate legacy
> > > > interrupts
> > > > - * even when in MSI mode. This results in spurious interrupt warnings
> > > > if the
> > > > - * legacy irq no. is shared with another device. The kernel then
> > > > disables that
> > > > - * interrupt source and so prevents the other device from working
> > > > properly.
> > > > - *
> > > > - * Since we don't enable MSI anymore on gen4, we can always use
> > > > GMBUS/AUX
> > > > - * interrupts.
> > > > - */
> > > > -#define HAS_AUX_IRQ(dev_priv) true
> > > > #define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
> > > >
> > > > /* With the 945 and later, Y tiling got adjusted so that it was 32
> > > > 128-byte
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index ce07bd794aed..1dab40056df7 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -936,7 +936,7 @@ intel_dp_check_edp(struct intel_dp *intel_dp)
> > > > }
> > > >
> > > > static uint32_t
> > > > -intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
> > > > +intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> > > > {
> > > > struct drm_i915_private *dev_priv =
> > > > to_i915(intel_dp_to_dev(intel_dp));
> > > > i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
> > > > @@ -944,14 +944,10 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp,
> > > > bool has_aux_irq)
> > > > bool done;
> > > >
> > > >
Re: [Intel-gfx] [PATCH 16/24] drm/i915/icl: Handle hotplug interrupts for DP over TBT
On Mon, May 21, 2018 at 05:25:50PM -0700, Paulo Zanoni wrote:
> From: Dhinakaran Pandiyan
>
> This patch enables hotplug interrupts for DP over TBT output on TC
> ports. The TBT interrupts are enabled and handled irrespective of the
> actual output type which could be DP Alternate, DP over TBT, native DP
> or native HDMI.
>
> Cc: Animesh Manna
> Cc: Paulo Zanoni
> Cc: Anusha Srivatsa
> Cc: Manasi Navare
> Signed-off-by: Dhinakaran Pandiyan
> Signed-off-by: Paulo Zanoni
Reviewed-by: Lucas De Marchi
Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_irq.c | 49
> ++---
> drivers/gpu/drm/i915/i915_reg.h | 11 -
> 2 files changed, 46 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 6b109991786f..9f1b01ca4ed1 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -115,11 +115,11 @@ static const u32 hpd_bxt[HPD_NUM_PINS] = {
> [HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
> };
>
> -static const u32 hpd_tc_gen11[HPD_NUM_PINS] = {
> - [HPD_PORT_C] = GEN11_TC1_HOTPLUG,
> - [HPD_PORT_D] = GEN11_TC2_HOTPLUG,
> - [HPD_PORT_E] = GEN11_TC3_HOTPLUG,
> - [HPD_PORT_F] = GEN11_TC4_HOTPLUG
> +static const u32 hpd_gen11[HPD_NUM_PINS] = {
> + [HPD_PORT_C] = GEN11_TC1_HOTPLUG | GEN11_TBT1_HOTPLUG,
> + [HPD_PORT_D] = GEN11_TC2_HOTPLUG | GEN11_TBT2_HOTPLUG,
> + [HPD_PORT_E] = GEN11_TC3_HOTPLUG | GEN11_TBT3_HOTPLUG,
> + [HPD_PORT_F] = GEN11_TC4_HOTPLUG | GEN11_TBT4_HOTPLUG
> };
>
> static const u32 hpd_icp[HPD_NUM_PINS] = {
> @@ -2690,20 +2690,35 @@ static void bxt_hpd_irq_handler(struct
> drm_i915_private *dev_priv,
> static void gen11_hpd_irq_handler(struct drm_i915_private *dev_priv, u32 iir)
> {
> u32 pin_mask = 0, long_mask = 0;
> - u32 trigger_tc, dig_hotplug_reg;
> + u32 trigger_tc = iir & GEN11_DE_TC_HOTPLUG_MASK;
> + u32 trigger_tbt = iir & GEN11_DE_TBT_HOTPLUG_MASK;
>
> - trigger_tc = iir & GEN11_DE_TC_HOTPLUG_MASK;
> if (trigger_tc) {
> + u32 dig_hotplug_reg;
> +
> dig_hotplug_reg = I915_READ(GEN11_TC_HOTPLUG_CTL);
> I915_WRITE(GEN11_TC_HOTPLUG_CTL, dig_hotplug_reg);
>
> intel_get_hpd_pins(dev_priv, _mask, _mask, trigger_tc,
> -dig_hotplug_reg, hpd_tc_gen11,
> +dig_hotplug_reg, hpd_gen11,
> +gen11_port_hotplug_long_detect);
> + }
> +
> + if (trigger_tbt) {
> + u32 dig_hotplug_reg;
> +
> + dig_hotplug_reg = I915_READ(GEN11_TBT_HOTPLUG_CTL);
> + I915_WRITE(GEN11_TBT_HOTPLUG_CTL, dig_hotplug_reg);
> +
> + intel_get_hpd_pins(dev_priv, _mask, _mask, trigger_tbt,
> +dig_hotplug_reg, hpd_gen11,
> gen11_port_hotplug_long_detect);
> + }
> +
> + if (pin_mask)
> intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
> - } else {
> + else
> DRM_ERROR("Unexpected DE HPD interrupt 0x%08x\n", iir);
> - }
> }
>
> static irqreturn_t
> @@ -3783,6 +3798,13 @@ static void gen11_hpd_detection_setup(struct
> drm_i915_private *dev_priv)
> GEN11_HOTPLUG_CTL_ENABLE(PORT_TC3) |
> GEN11_HOTPLUG_CTL_ENABLE(PORT_TC4);
> I915_WRITE(GEN11_TC_HOTPLUG_CTL, hotplug);
> +
> + hotplug = I915_READ(GEN11_TBT_HOTPLUG_CTL);
> + hotplug |= GEN11_HOTPLUG_CTL_ENABLE(PORT_TC1) |
> +GEN11_HOTPLUG_CTL_ENABLE(PORT_TC2) |
> +GEN11_HOTPLUG_CTL_ENABLE(PORT_TC3) |
> +GEN11_HOTPLUG_CTL_ENABLE(PORT_TC4);
> + I915_WRITE(GEN11_TBT_HOTPLUG_CTL, hotplug);
> }
>
> static void gen11_hpd_irq_setup(struct drm_i915_private *dev_priv)
> @@ -3790,8 +3812,8 @@ static void gen11_hpd_irq_setup(struct drm_i915_private
> *dev_priv)
> u32 hotplug_irqs, enabled_irqs;
> u32 val;
>
> - enabled_irqs = intel_hpd_enabled_irqs(dev_priv, hpd_tc_gen11);
> - hotplug_irqs = GEN11_DE_TC_HOTPLUG_MASK;
> + enabled_irqs = intel_hpd_enabled_irqs(dev_priv, hpd_gen11);
> + hotplug_irqs = GEN11_DE_TC_HOTPLUG_MASK | GEN11_DE_TBT_HOTPLUG_MASK;
>
> val = I915_READ(GEN11_DE_HPD_IMR);
> val &= ~hotplug_irqs;
> @@ -4176,7 +4198,8 @@ static void gen8_de_irq_postinstall(struct
> drm_i915_private *dev_priv)
>
> if (INTEL_GEN(dev_priv) >= 11) {
> u32 de_hpd_masked = 0;
> - u32 de_hpd_enables = GEN11_DE_TC_HOTP
Re: [Intel-gfx] [PATCH 05/24] drm/i915/icp: Add Interrupt Support
On Thu, May 24, 2018 at 05:43:24PM -0700, Lucas De Marchi wrote:
> On Thu, May 24, 2018 at 05:45:43PM -0700, Dhinakaran Pandiyan wrote:
> > On Thu, 2018-05-24 at 16:53 -0700, Lucas De Marchi wrote:
> > > On Mon, May 21, 2018 at 05:25:39PM -0700, Paulo Zanoni wrote:
> > > >
> > > > From: Anusha Srivatsa
> > > >
> > > > This patch addresses Interrupts from south display engine (SDE).
> > > >
> > > > ICP has two registers - SHOTPLUG_CTL_DDI and SHOTPLUG_CTL_TC.
> > > > Introduce these registers and their intended values.
> > > >
> > > > Introduce icp_irq_handler().
> > > >
> > > > Cc: Paulo Zanoni
> > > > Cc: Dhinakaran Pandiyan
> > > > Cc: Ville Syrjala
> > > > Signed-off-by: Anusha Srivatsa
> > > > [Paulo: coding style bikesheds and rebases].
> > > > Signed-off-by: Paulo Zanoni
> > > > ---
> > > > drivers/gpu/drm/i915/i915_irq.c | 134
> > > > +++-
> > > > drivers/gpu/drm/i915/i915_reg.h | 40
> > > > 2 files changed, 172 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > index 9bcec5fdb9d0..6b109991786f 100644
> > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > @@ -122,6 +122,15 @@ static const u32 hpd_tc_gen11[HPD_NUM_PINS] =
> > > > {
> > > > [HPD_PORT_F] = GEN11_TC4_HOTPLUG
> > > > };
> > > >
> > > > +static const u32 hpd_icp[HPD_NUM_PINS] = {
> > > > + [HPD_PORT_A] = ICP_DDIA_HOTPLUG,
> > > > + [HPD_PORT_B] = ICP_DDIB_HOTPLUG,
> > > > + [HPD_PORT_C] = ICP_TC1_HOTPLUG,
> > > > + [HPD_PORT_D] = ICP_TC2_HOTPLUG,
> > > > + [HPD_PORT_E] = ICP_TC3_HOTPLUG,
> > > > + [HPD_PORT_F] = ICP_TC4_HOTPLUG
> > > > +};
> > > > +
> > > > /* IIR can theoretically queue up two events. Be paranoid. */
> > > > #define GEN8_IRQ_RESET_NDX(type, which) do { \
> > > > I915_WRITE(GEN8_##type##_IMR(which), 0x); \
> > > > @@ -1586,6 +1595,34 @@ static bool
> > > > bxt_port_hotplug_long_detect(enum port port, u32 val)
> > > > }
> > > > }
> > > >
> > > > +static bool icp_ddi_port_hotplug_long_detect(enum port port, u32
> > > > val)
> > > > +{
> > > > + switch (port) {
> > > > + case PORT_A:
> > > > + return val & ICP_DDIA_HPD_LONG_DETECT;
> > > > + case PORT_B:
> > > > + return val & ICP_DDIB_HPD_LONG_DETECT;
> > > > + default:
> > > > + return false;
> > > > + }
> > > > +}
> > > > +
> > > > +static bool icp_tc_port_hotplug_long_detect(enum port port, u32
> > > > val)
> > > > +{
> > > > + switch (port) {
> > > > + case PORT_C:
> > > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC1);
> > > > + case PORT_D:
> > > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC2);
> > > > + case PORT_E:
> > > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC3);
> > > > + case PORT_F:
> > > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC4);
> > > > + default:
> > > > + return false;
> > > > + }
> > > > +}
> > > > +
> > > > static bool spt_port_hotplug2_long_detect(enum port port, u32 val)
> > > > {
> > > > switch (port) {
> > > > @@ -2377,6 +2414,43 @@ static void cpt_irq_handler(struct
> > > > drm_i915_private *dev_priv, u32 pch_iir)
> > > > cpt_serr_int_handler(dev_priv);
> > > > }
> > > >
> > > > +static void icp_irq_handler(struct drm_i915_private *dev_priv, u32
> > > > pch_iir)
> > > > +{
> > > > + u32 ddi_hotplug_trigger = pch_iir & ICP_SDE_DDI_MASK;
> > > > + u32 tc_hotplug_trigger = pch_iir & ICP_SDE_TC_MASK;
> > > > + u32 pin_mask = 0, long_mask = 0;
> > >
Re: [Intel-gfx] [PATCH 4/4] drm/i915: fix PCH_NOP setting for non-PCH platforms
On Thu, May 31, 2018 at 02:56:24PM +0300, Jani Nikula wrote:
> Setting PCH type to PCH_NOP before checking whether we actually have a
> PCH ends up returning true for HAS_PCH_SPLIT() on all non-PCH split
> platforms. Fix this by using PCH_NOP only for platforms that actually
> have a PCH.
>
> Cc: Ville Syrjala
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.c | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1842a067a604..5deee698881b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -246,14 +246,6 @@ static void intel_detect_pch(struct drm_i915_private
> *dev_priv)
> {
> struct pci_dev *pch = NULL;
>
> - /* In all current cases, num_pipes is equivalent to the PCH_NOP setting
> - * (which really amounts to a PCH but no South Display).
> - */
> - if (INTEL_INFO(dev_priv)->num_pipes == 0) {
> - dev_priv->pch_type = PCH_NOP;
> - return;
> - }
> -
> /*
>* The reason to probe ISA bridge instead of Dev31:Fun0 is to
>* make graphics device passthrough work easy for VMM, that only
> @@ -293,6 +285,17 @@ static void intel_detect_pch(struct drm_i915_private
> *dev_priv)
> break;
> }
> }
> +
> + /*
> + * Use PCH_NOP (PCH but no South Display) for PCH platforms without
Like I said on patch 1 I'd rather document in the enum what it is and
here just a "Use PCH_NOP for PCH platforms without display"
Lucas De Marchi
> + * display.
> + */
> + if (pch && INTEL_INFO(dev_priv)->num_pipes == 0) {
> + DRM_DEBUG_KMS("Display disabled, reverting to NOP PCH\n");
> + dev_priv->pch_type = PCH_NOP;
> + dev_priv->pch_id = 0;
> + }
> +
> if (!pch)
> DRM_DEBUG_KMS("No PCH found.\n");
>
> --
> 2.11.0
>
> ___
> 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 1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems
On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote:
> Virtualized non-PCH systems such as Broxton or Geminilake should use
> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a
> specific case to indicate a PCH system without south display.
Then let's go ahead and document it?
-
Subject: [PATCH] drm/i915: document PCH_NOP
There's a difference between PCH_NONE and PCH_NOP: the former means we
don't have a PCH while in the latter we do, but it doesn't have the
south display.
Cc: Jani Nikula
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 72150f89f200..aa395a898258 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -631,7 +631,7 @@ enum intel_pch {
PCH_KBP,/* Kaby Lake PCH */
PCH_CNP,/* Cannon Lake PCH */
PCH_ICP,/* Ice Lake PCH */
- PCH_NOP,
+ PCH_NOP,/* PCH without south display */
};
enum intel_sbi_destination {
--
Feel free to squash something like that if you agree.
Lucas De Marchi
>
> Reported-by: Colin Xu
> Cc: Colin Xu
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 8f002ae22e62..c42e389a27f3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -287,7 +287,7 @@ static void intel_detect_pch(struct drm_i915_private
> *dev_priv)
> if (WARN_ON(pch_type == PCH_NONE))
> pch_type = PCH_NOP;
> } else {
> - pch_type = PCH_NOP;
> + pch_type = PCH_NONE;
> }
> dev_priv->pch_type = pch_type;
> dev_priv->pch_id = id;
> --
> 2.11.0
>
> ___
> 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/icp: Add Interrupt Support
On Tue, Jun 26, 2018 at 1:56 PM Anusha Srivatsa
wrote:
>
> This patch addresses Interrupts from south display engine (SDE).
>
> ICP has two registers - SHOTPLUG_CTL_DDI and SHOTPLUG_CTL_TC.
> Introduce these registers and their intended values.
>
> Introduce icp_irq_handler().
>
> The icp_irq_postinstall() takes care of
> enabling all PCH interrupt sources, to unmask
> them as needed with SDEIMR, as is done
> done by ibx_irq_pre_postinstall() for earlier platforms.
> We do not need to explicitly call the ibx_irq_pre_postinstall().
>
> Also, while changing these,
> s/CPT/PPT/CPT-CNP comment.
>
> v2:
> - remove redundant register defines.(Lucas)
> - Change register names to be more consistent with
> previous platforms (Lucas)
>
> v3:
> -Reorder bit defines to a more appropriate location.
> Change the comments. Confirm in the commit message that
> icp_irq_postinstall() need not go to
> ibx_irq_pre_postinstall() and ibx_irq_postinstall()
> as in earlier platforms. (Paulo)
>
> Cc: Lucas De Marchi
Better now.
Reviewed-by: Lucas De Marchi
Lucas De Marchi
> Cc: Paulo Zanoni
> Cc: Dhinakaran Pandiyan
> Cc: Ville Syrjala
> Signed-off-by: Anusha Srivatsa
> [Paulo: coding style bikesheds and rebases].
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_irq.c | 134
> +++-
> drivers/gpu/drm/i915/i915_reg.h | 42 -
> 2 files changed, 173 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 46aaef5..7a7c4a2 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -122,6 +122,15 @@ static const u32 hpd_gen11[HPD_NUM_PINS] = {
> [HPD_PORT_F] = GEN11_TC4_HOTPLUG | GEN11_TBT4_HOTPLUG
> };
>
> +static const u32 hpd_icp[HPD_NUM_PINS] = {
> + [HPD_PORT_A] = SDE_DDIA_HOTPLUG_ICP,
> + [HPD_PORT_B] = SDE_DDIB_HOTPLUG_ICP,
> + [HPD_PORT_C] = SDE_TC1_HOTPLUG_ICP,
> + [HPD_PORT_D] = SDE_TC2_HOTPLUG_ICP,
> + [HPD_PORT_E] = SDE_TC3_HOTPLUG_ICP,
> + [HPD_PORT_F] = SDE_TC4_HOTPLUG_ICP
> +};
> +
> /* IIR can theoretically queue up two events. Be paranoid. */
> #define GEN8_IRQ_RESET_NDX(type, which) do { \
> I915_WRITE(GEN8_##type##_IMR(which), 0x); \
> @@ -1586,6 +1595,34 @@ static bool bxt_port_hotplug_long_detect(enum port
> port, u32 val)
> }
> }
>
> +static bool icp_ddi_port_hotplug_long_detect(enum port port, u32 val)
> +{
> + switch (port) {
> + case PORT_A:
> + return val & ICP_DDIA_HPD_LONG_DETECT;
> + case PORT_B:
> + return val & ICP_DDIB_HPD_LONG_DETECT;
> + default:
> + return false;
> + }
> +}
> +
> +static bool icp_tc_port_hotplug_long_detect(enum port port, u32 val)
> +{
> + switch (port) {
> + case PORT_C:
> + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC1);
> + case PORT_D:
> + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC2);
> + case PORT_E:
> + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC3);
> + case PORT_F:
> + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC4);
> + default:
> + return false;
> + }
> +}
> +
> static bool spt_port_hotplug2_long_detect(enum port port, u32 val)
> {
> switch (port) {
> @@ -2385,6 +2422,43 @@ static void cpt_irq_handler(struct drm_i915_private
> *dev_priv, u32 pch_iir)
> cpt_serr_int_handler(dev_priv);
> }
>
> +static void icp_irq_handler(struct drm_i915_private *dev_priv, u32 pch_iir)
> +{
> + u32 ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
> + u32 tc_hotplug_trigger = pch_iir & SDE_TC_MASK_ICP;
> + u32 pin_mask = 0, long_mask = 0;
> +
> + if (ddi_hotplug_trigger) {
> + u32 dig_hotplug_reg;
> +
> + dig_hotplug_reg = I915_READ(SHOTPLUG_CTL_DDI);
> + I915_WRITE(SHOTPLUG_CTL_DDI, dig_hotplug_reg);
> +
> + intel_get_hpd_pins(dev_priv, _mask, _mask,
> + ddi_hotplug_trigger,
> + dig_hotplug_reg, hpd_icp,
> + icp_ddi_port_hotplug_long_detect);
> + }
> +
> + if (tc_hotplug_trigger) {
> + u32 dig_hotplug_reg;
> +
> + dig_hotplug_reg = I915_READ(SHOTPLUG_CTL_TC);
> + I915_WRITE(SHOTPLUG_CTL_TC, dig_hotplug_reg);
> +
> + intel_get_hpd_pins(dev_priv, _mask, _mask,
> +
Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: implement icl_digital_port_connected()
On Wed, Jun 20, 2018 at 02:36:05PM -0700, Anusha Srivatsa wrote:
> From: Paulo Zanoni
>
> Do like the other functions and check for the ISR bits. We have plans
> to add a few more checks in this code in the next patches, that's why
> it's a little more verbose than it could be.
>
> v2:
> - Change the register names, to be consistent with
> the rest of the platforms.
>
> Cc: Animesh Manna
> Cc: Lucas De Marchi
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Paulo Zanoni
> Signed-off-by: Rodrigo Vivi
My review stands for v2 as done in v1:
Reviewed-by: Lucas De Marchi
Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 5
> drivers/gpu/drm/i915/intel_dp.c | 57
> +
> 2 files changed, 62 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e347055..f55e889 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7093,6 +7093,7 @@ enum {
> #define GEN11_TC3_HOTPLUG (1 << 18)
> #define GEN11_TC2_HOTPLUG (1 << 17)
> #define GEN11_TC1_HOTPLUG (1 << 16)
> +#define GEN11_TC_HOTPLUG(tc_port) (1 << ((tc_port) + 16))
> #define GEN11_DE_TC_HOTPLUG_MASK(GEN11_TC4_HOTPLUG | \
>GEN11_TC3_HOTPLUG | \
>GEN11_TC2_HOTPLUG | \
> @@ -7101,6 +7102,7 @@ enum {
> #define GEN11_TBT3_HOTPLUG (1 << 2)
> #define GEN11_TBT2_HOTPLUG (1 << 1)
> #define GEN11_TBT1_HOTPLUG (1 << 0)
> +#define GEN11_TBT_HOTPLUG(tc_port) (1 << (tc_port))
> #define GEN11_DE_TBT_HOTPLUG_MASK (GEN11_TBT4_HOTPLUG | \
>GEN11_TBT3_HOTPLUG | \
>GEN11_TBT2_HOTPLUG | \
> @@ -7525,6 +7527,9 @@ enum {
> #define SDE_GMBUS_ICP (1 << 23)
> #define SDE_DDIB_HOTPLUG_ICP (1 << 17)
> #define SDE_DDIA_HOTPLUG_ICP (1 << 16)
> +#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_DDIB_HOTPLUG_ICP | \
>SDE_DDIA_HOTPLUG_ICP)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 6ac6c87..224cc71 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4750,6 +4750,61 @@ static bool bxt_digital_port_connected(struct
> intel_encoder *encoder)
> return I915_READ(GEN8_DE_PORT_ISR) & bit;
> }
>
> +static bool icl_combo_port_connected(struct drm_i915_private *dev_priv,
> + struct intel_digital_port *intel_dig_port)
> +{
> + enum port port = intel_dig_port->base.port;
> +
> + return I915_READ(SDEISR) & SDE_DDI_HOTPLUG_ICP(port);
> +}
> +
> +static bool icl_tc_port_connected(struct drm_i915_private *dev_priv,
> + struct intel_digital_port *intel_dig_port)
> +{
> + enum port port = intel_dig_port->base.port;
> + enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> + u32 legacy_bit = SDE_TC_HOTPLUG_ICP(tc_port);
> + u32 typec_bit = GEN11_TC_HOTPLUG(tc_port);
> + u32 tbt_bit = GEN11_TBT_HOTPLUG(tc_port);
> + bool is_legacy = false, is_typec = false, is_tbt = false;
> + u32 cpu_isr;
> +
> + if (I915_READ(SDEISR) & legacy_bit)
> + is_legacy = true;
> +
> + cpu_isr = I915_READ(GEN11_DE_HPD_ISR);
> + if (cpu_isr & typec_bit)
> + is_typec = true;
> + if (cpu_isr & tbt_bit)
> + is_tbt = true;
> +
> + WARN_ON(is_legacy + is_typec + is_tbt > 1);
> + if (!is_legacy && !is_typec && !is_tbt)
> + return false;
> +
> + return true;
> +}
> +
> +static bool icl_digital_port_connected(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> +
> + switch (encoder->hpd_pin) {
> + case HPD_PORT_A:
> + case HPD_PORT_B:
> + return icl_combo_port_connected(dev_priv, dig_port);
> + case HPD_PORT_C:
> + case HPD_PORT_D:
> + case HPD_PORT_E:
> + case HPD_PORT_F:
> + return icl_tc_port_conne
Re: [Intel-gfx] [PATCH] drm/i915: remove check for aux irq
On Thu, Apr 26, 2018 at 06:50:05PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 26, 2018 at 08:42:54AM -0700, Lucas De Marchi wrote:
> > On Thu, Apr 26, 2018 at 06:27:26PM +0300, Ville Syrjälä wrote:
> > > On Thu, Apr 26, 2018 at 08:22:12AM -0700, Lucas De Marchi wrote:
> > > > On Thu, Apr 26, 2018 at 04:43:38PM +0300, Ville Syrjälä wrote:
> > > > > On Wed, Apr 25, 2018 at 02:55:24PM -0700, Lucas De Marchi wrote:
> > > > > > This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> > > > > > GMBUS and AUX interrupts on gen4/g4x").
> > > > > >
> > > > > > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > > > > > Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/i915_drv.h | 3 +--
> > > > > > drivers/gpu/drm/i915/intel_dp.c | 22 +++---
> > > > > > drivers/gpu/drm/i915/intel_drv.h | 1 -
> > > > > > drivers/gpu/drm/i915/intel_psr.c | 2 +-
> > > > > > 4 files changed, 9 insertions(+), 19 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > index 8444ca8d5aa3..09e1c2289ea1 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > @@ -2545,7 +2545,7 @@ intel_info(const struct drm_i915_private
> > > > > > *dev_priv)
> > > > > > IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> > > > > >
> > > > > > /*
> > > > > > - * dp aux and gmbus irq on gen4 seems to be able to generate
> > > > > > legacy interrupts
> > > > > > + * gmbus irq on gen4 seems to be able to generate legacy interrupts
> > > > >
> > > > > Why are you removing vital information from the comment?
> > > >
> > > > Because it wouldn't match the code anymore. We always use aux irq.
> > >
> > > The comment is documenting the hardware behaviour. We don't want to lose
> > > that information.
> >
> > IMO it's confusing to have the comment saying one thing and then code
> > not following it. Reading it again I see the second paragraph you added
> > actually document the code and the first the HW behavior. Maybe starting
> > the second paragraph with a "However" would make it clearer. Or I can just
> > drop this change in the comment.
>
> Or you can move the relevant parts of the comment to the place where
> we do the "MSI or not to MSI" decision.
Humn, not sure I fully understand what you mean by relevant part. Do you
mean something like this?
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b7dbeba72dec..3fc6b915dac1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1183,6 +1183,9 @@ static int i915_driver_init_hw(struct drm_i915_private
*dev_priv)
* get lost on g4x as well, and interrupt delivery seems to stay
* properly dead afterwards. So we'll just disable them for all
* pre-gen5 chipsets.
+*
+* Since we don't enable MSI on gen <= 4 we can always use GMBUS/AUX
+* interrupts.
*/
if (INTEL_GEN(dev_priv) >= 5) {
if (pci_enable_msi(pdev) < 0)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 09e1c2289ea1..5fd47227da23 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2545,13 +2545,10 @@ intel_info(const struct drm_i915_private *dev_priv)
IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
/*
- * gmbus irq on gen4 seems to be able to generate legacy interrupts
+ * dp aux and gmbus irq on gen4 seems to be able to generate legacy interrupts
* even when in MSI mode. This results in spurious interrupt warnings if the
* legacy irq no. is shared with another device. The kernel then disables that
* interrupt source and so prevents the other device from working properly.
- *
- * Since we don't enable MSI anymore on gen4, we can always use GMBUS/AUX
- * interrupts.
*/
#define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
---
It doesn't seem clearer to me.
Lucas De Marchi
>
> --
> 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: remove check for aux irq
On Thu, Apr 26, 2018 at 04:43:38PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 25, 2018 at 02:55:24PM -0700, Lucas De Marchi wrote:
> > This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> > GMBUS and AUX interrupts on gen4/g4x").
> >
> > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 3 +--
> > drivers/gpu/drm/i915/intel_dp.c | 22 +++---
> > drivers/gpu/drm/i915/intel_drv.h | 1 -
> > drivers/gpu/drm/i915/intel_psr.c | 2 +-
> > 4 files changed, 9 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 8444ca8d5aa3..09e1c2289ea1 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2545,7 +2545,7 @@ intel_info(const struct drm_i915_private *dev_priv)
> > IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> >
> > /*
> > - * dp aux and gmbus irq on gen4 seems to be able to generate legacy
> > interrupts
> > + * gmbus irq on gen4 seems to be able to generate legacy interrupts
>
> Why are you removing vital information from the comment?
Because it wouldn't match the code anymore. We always use aux irq.
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: remove check for aux irq
On Thu, Apr 26, 2018 at 06:27:26PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 26, 2018 at 08:22:12AM -0700, Lucas De Marchi wrote:
> > On Thu, Apr 26, 2018 at 04:43:38PM +0300, Ville Syrjälä wrote:
> > > On Wed, Apr 25, 2018 at 02:55:24PM -0700, Lucas De Marchi wrote:
> > > > This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> > > > GMBUS and AUX interrupts on gen4/g4x").
> > > >
> > > > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > > > Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/i915_drv.h | 3 +--
> > > > drivers/gpu/drm/i915/intel_dp.c | 22 +++---
> > > > drivers/gpu/drm/i915/intel_drv.h | 1 -
> > > > drivers/gpu/drm/i915/intel_psr.c | 2 +-
> > > > 4 files changed, 9 insertions(+), 19 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 8444ca8d5aa3..09e1c2289ea1 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2545,7 +2545,7 @@ intel_info(const struct drm_i915_private
> > > > *dev_priv)
> > > > IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> > > >
> > > > /*
> > > > - * dp aux and gmbus irq on gen4 seems to be able to generate legacy
> > > > interrupts
> > > > + * gmbus irq on gen4 seems to be able to generate legacy interrupts
> > >
> > > Why are you removing vital information from the comment?
> >
> > Because it wouldn't match the code anymore. We always use aux irq.
>
> The comment is documenting the hardware behaviour. We don't want to lose
> that information.
IMO it's confusing to have the comment saying one thing and then code
not following it. Reading it again I see the second paragraph you added
actually document the code and the first the HW behavior. Maybe starting
the second paragraph with a "However" would make it clearer. Or I can just
drop this change in the comment.
thanks
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] meson: use message() rather than warning()
warning() was only added to the meson interpreter in 0.44 which is
currently the last version. Let's use message() as we are currently
requiring meson > 0.40. Otherwise we get the following error:
Meson encountered an error in file overlay/meson.build, line 62, column
1:
Unknown function "warning".
Fixes: 865a47ca ("overlay: parse tracepoints from sysfs to figure out fields'
location")
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
Cc: Rhys Kidd <rhysk...@gmail.com>
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: Petri Latvala <petri.latv...@intel.com>
---
overlay/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/overlay/meson.build b/overlay/meson.build
index 8b5c52b4..546c8377 100644
--- a/overlay/meson.build
+++ b/overlay/meson.build
@@ -59,7 +59,7 @@ if leg.found()
command: [leg, '-P', '-o', '@OUTPUT@', '@INPUT@'])
gpu_overlay_src += leg_file
else
- warning('leg command not found, disabling overlay; try : apt-get
install peg')
+ message('WARNING: leg command not found, disabling overlay; try :
apt-get install peg')
endif
if leg.found() and xrandr.found() and cairo.found()
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/11] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.
On Tue, Jan 9, 2018 at 10:48 AM, Paulo Zanoni <paulo.r.zan...@intel.com> wrote:
> Em Sex, 2017-12-22 às 15:18 -0800, Rodrigo Vivi escreveu:
>> By the Spec all CNL skus are GT2.
>
> This is definitely not my understanding, some of the PCI IDs in our
> driver are clearly marked as GT1 on the spec.
>
> But since we don't use this GTX number anywhere for CNL for the Kernel
> driver, can't we just KISS and go with intel_cannonlake_info until we
> actually need it?
After reviewing the docs again, I agree with Paulo. Since we are not
using it, we could simplify and get rid of it.
>
> Besides that, I really think this patch should be split in 2: one that
> only adds the new PCI IDs, and another that does the macro/info rework.
> This should help any possible backports.
In the end I think any future backport will end up needing to bring
both patches to avoid conflicts (it's easier to bring back a small
rework as dependency than keep having conflicts in the same place as
we backport IDs)... so the split per se seems good so each commit does
only one thing, but I'm not sure about the backport argument.
Lucas De Marchi
>
>>
>> v2: Really include the PCI IDs to the picidlist[];
>> v3: Add the PCI Id for another SKU (Anusha).
>> v4: Update IDs, really include to pciidlists again.
>> v5: Unify all GT2 IDs.
>> v6: Unify in a way that we don't break early-quirks.c
>>
>> Cc: Lucas De Marchi <lucas.demar...@intel.com>
>> Signed-off-by: Anusha Srivatsa <anusha.sriva...@intel.com>
>> Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
>> ---
>> drivers/gpu/drm/i915/i915_pci.c | 3 +--
>> include/drm/i915_pciids.h | 18 +++---
>> 2 files changed, 8 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_pci.c
>> b/drivers/gpu/drm/i915/i915_pci.c
>> index 36d48422b475..cc87d741135d 100644
>> --- a/drivers/gpu/drm/i915/i915_pci.c
>> +++ b/drivers/gpu/drm/i915/i915_pci.c
>> @@ -636,8 +636,7 @@ static const struct pci_device_id pciidlist[] = {
>> INTEL_CFL_U_GT1_IDS(_coffeelake_gt1_info),
>> INTEL_CFL_U_GT2_IDS(_coffeelake_gt2_info),
>> INTEL_CFL_U_GT3_IDS(_coffeelake_gt3_info),
>> - INTEL_CNL_U_GT2_IDS(_cannonlake_gt2_info),
>> - INTEL_CNL_Y_GT2_IDS(_cannonlake_gt2_info),
>> + INTEL_CNL_IDS(_cannonlake_gt2_info),
>> {0, 0, 0}
>> };
>> MODULE_DEVICE_TABLE(pci, pciidlist);
>> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
>> index 5db0458dd832..9e1fe6634424 100644
>> --- a/include/drm/i915_pciids.h
>> +++ b/include/drm/i915_pciids.h
>> @@ -414,24 +414,20 @@
>> INTEL_CFL_U_GT2_IDS(info), \
>> INTEL_CFL_U_GT3_IDS(info)
>>
>> -/* CNL U 2+2 */
>> -#define INTEL_CNL_U_GT2_IDS(info) \
>> +/* CNL */
>> +#define INTEL_CNL_IDS(info) \
>> INTEL_VGA_DEVICE(0x5A52, info), \
>> INTEL_VGA_DEVICE(0x5A5A, info), \
>> INTEL_VGA_DEVICE(0x5A42, info), \
>> - INTEL_VGA_DEVICE(0x5A4A, info)
>> -
>> -/* CNL Y 2+2 */
>> -#define INTEL_CNL_Y_GT2_IDS(info) \
>> + INTEL_VGA_DEVICE(0x5A4A, info), \
>> INTEL_VGA_DEVICE(0x5A51, info), \
>> INTEL_VGA_DEVICE(0x5A59, info), \
>> INTEL_VGA_DEVICE(0x5A41, info), \
>> INTEL_VGA_DEVICE(0x5A49, info), \
>> INTEL_VGA_DEVICE(0x5A71, info), \
>> - INTEL_VGA_DEVICE(0x5A79, info)
>> -
>> -#define INTEL_CNL_IDS(info) \
>> - INTEL_CNL_U_GT2_IDS(info), \
>> - INTEL_CNL_Y_GT2_IDS(info)
>> + INTEL_VGA_DEVICE(0x5A79, info), \
>> + INTEL_VGA_DEVICE(0x5A54, info), \
>> + INTEL_VGA_DEVICE(0x5A5C, info), \
>> + INTEL_VGA_DEVICE(0x5A44, info)
>>
>> #endif /* _I915_PCIIDS_H */
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnp: Properly handle VBT ddc pin out of bounds.
On Thu, Jan 25, 2018 at 05:52:26PM +0200, Jani Nikula wrote:
> On Thu, 25 Jan 2018, Rodrigo Vivi <rodrigo.v...@intel.com> wrote:
> > If the table result is out of bounds on the array map
> > there is something really wrong with VBT pin so we don't
> > return that vbt_pin, but only return 0 instead.
> >
> > This basically reverts commit 'a8e6f3888b05 ("drm/i915/cnp:
> > Ignore VBT request for know invalid DDC pin.")'
> >
> > Also this properly fixes commit 9c3b2689d01f ("drm/i915/cnl:
> > Map VBT DDC Pin to BSpec DDC Pin.")
> >
> > v2: Do in a way that we don't break other platforms. (Jani)
> > v3: Keep debug message (Jani)
> >
> > Fixes: a8e6f3888b05 ("drm/i915/cnp: Ignore VBT request for know invalid DDC
> > pin.")
> > Fixes: 9c3b2689d01f ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.")
> > Cc: Radhakrishna Sripada <radhakrishna.srip...@intel.com>
> > Cc: Jani Nikula <jani.nik...@intel.com>
> > Cc: Kai Heng Feng <kai.heng.f...@canonical.com>
> > Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_bios.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c
> > b/drivers/gpu/drm/i915/intel_bios.c
> > index 95f0b310d656..06526b17a011 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -1116,9 +1116,9 @@ static const u8 cnp_ddc_pin_map[] = {
> > static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin)
> > {
> > if (HAS_PCH_CNP(dev_priv)) {
> > - if (vbt_pin > 0 && vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map))
> > + if (vbt_pin > 0 && vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map)) {
> > return cnp_ddc_pin_map[vbt_pin];
> > - if (vbt_pin > GMBUS_PIN_4_CNP) {
> > + } else {
>
> You're going to hate me, but I just realized this will now complain
> about vbt_pin == 0, which I guess is valid for N/A.
>
> Why are simple things so hard sometimes... :(
>
> else if (vbt_pin) ?
vpt_pin is unsigned so we are just special-casing the vpt_pin == 0
already. What about stopping doing that by adding it to the array, like
below (to be squashed)
---
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 06526b17a011..cf3f8f1ba6f7 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1107,6 +1107,7 @@ static void sanitize_aux_ch(struct drm_i915_private
*dev_priv,
}
static const u8 cnp_ddc_pin_map[] = {
+ [0] = 0, /* N/A */
[DDC_BUS_DDI_B] = GMBUS_PIN_1_BXT,
[DDC_BUS_DDI_C] = GMBUS_PIN_2_BXT,
[DDC_BUS_DDI_D] = GMBUS_PIN_4_CNP, /* sic */
@@ -1116,7 +1117,7 @@ static const u8 cnp_ddc_pin_map[] = {
static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin)
{
if (HAS_PCH_CNP(dev_priv)) {
- if (vbt_pin > 0 && vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map)) {
+ if (vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map)) {
return cnp_ddc_pin_map[vbt_pin];
} else {
DRM_DEBUG_KMS("Ignoring alternate pin: VBT claims DDC
pin %d, which is not valid for this platform\n", vbt_pin);
---
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnp: Properly handle VBT ddc pin out of bounds.
On Thu, Jan 25, 2018 at 02:25:24PM -0800, Rodrigo Vivi wrote:
> If the table result is out of bounds on the array map
> there is something really wrong with VBT pin so we don't
> return that vbt_pin, but only return 0 instead.
>
> This basically reverts commit 'a8e6f3888b05 ("drm/i915/cnp:
> Ignore VBT request for know invalid DDC pin.")'
In this version it's not really a revert anymore as the debug message is
still there. I'd say it fixes, but doesn't revert.
>
> Also this properly fixes commit 9c3b2689d01f ("drm/i915/cnl:
> Map VBT DDC Pin to BSpec DDC Pin.")
>
> v2: Do in a way that we don't break other platforms. (Jani)
>
> v3: Keep debug message (Jani)
>
> v4: Don't mess with 0 mapping was noticed by Jani and
> addressed with a simple solution suggested by Lucas
> that makes this even simpler.
>
> Fixes: a8e6f3888b05 ("drm/i915/cnp: Ignore VBT request for know invalid DDC
> pin.")
> Fixes: 9c3b2689d01f ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.")
> Cc: Radhakrishna Sripada <radhakrishna.srip...@intel.com>
> Cc: Jani Nikula <jani.nik...@intel.com>
> Cc: Kai Heng Feng <kai.heng.f...@canonical.com>
> Cc: Lucas De Marchi <lucas.demar...@intel.com>
> Suggested-by: Lucas De Marchi <lucas.demar...@intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
Not sure about the suggested-by vs reviewed-by, but:
Reviewed-by: Lucas De Marchi <lucas.demar...@intel.com>
Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_bios.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 95f0b310d656..cf3f8f1ba6f7 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1107,6 +1107,7 @@ static void sanitize_aux_ch(struct drm_i915_private
> *dev_priv,
> }
>
> static const u8 cnp_ddc_pin_map[] = {
> + [0] = 0, /* N/A */
> [DDC_BUS_DDI_B] = GMBUS_PIN_1_BXT,
> [DDC_BUS_DDI_C] = GMBUS_PIN_2_BXT,
> [DDC_BUS_DDI_D] = GMBUS_PIN_4_CNP, /* sic */
> @@ -1116,9 +1117,9 @@ static const u8 cnp_ddc_pin_map[] = {
> static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin)
> {
> if (HAS_PCH_CNP(dev_priv)) {
> - if (vbt_pin > 0 && vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map))
> + if (vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map)) {
> return cnp_ddc_pin_map[vbt_pin];
> - if (vbt_pin > GMBUS_PIN_4_CNP) {
> + } else {
> DRM_DEBUG_KMS("Ignoring alternate pin: VBT claims DDC
> pin %d, which is not valid for this platform\n", vbt_pin);
> return 0;
> }
> --
> 2.13.6
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] lib/i915_pciids.h: synchronize with kernel header
Synchronize with kernel header as of
c99d7832dcd7 ("drm/i915/cfl: Adding more Coffee Lake PCI IDs.")
Signed-off-by: Lucas De Marchi <lucas.demar...@intel.com>
---
lib/i915_pciids.h | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/lib/i915_pciids.h b/lib/i915_pciids.h
index c65e4489..5db0458d 100644
--- a/lib/i915_pciids.h
+++ b/lib/i915_pciids.h
@@ -373,29 +373,45 @@
/* CFL S */
#define INTEL_CFL_S_GT1_IDS(info) \
INTEL_VGA_DEVICE(0x3E90, info), /* SRV GT1 */ \
- INTEL_VGA_DEVICE(0x3E93, info) /* SRV GT1 */
+ INTEL_VGA_DEVICE(0x3E93, info), /* SRV GT1 */ \
+ INTEL_VGA_DEVICE(0x3E99, info) /* SRV GT1 */
#define INTEL_CFL_S_GT2_IDS(info) \
INTEL_VGA_DEVICE(0x3E91, info), /* SRV GT2 */ \
INTEL_VGA_DEVICE(0x3E92, info), /* SRV GT2 */ \
- INTEL_VGA_DEVICE(0x3E96, info) /* SRV GT2 */
+ INTEL_VGA_DEVICE(0x3E96, info), /* SRV GT2 */ \
+ INTEL_VGA_DEVICE(0x3E9A, info) /* SRV GT2 */
/* CFL H */
#define INTEL_CFL_H_GT2_IDS(info) \
INTEL_VGA_DEVICE(0x3E9B, info), /* Halo GT2 */ \
INTEL_VGA_DEVICE(0x3E94, info) /* Halo GT2 */
-/* CFL U */
+/* CFL U GT1 */
+#define INTEL_CFL_U_GT1_IDS(info) \
+ INTEL_VGA_DEVICE(0x3EA1, info), \
+ INTEL_VGA_DEVICE(0x3EA4, info)
+
+/* CFL U GT2 */
+#define INTEL_CFL_U_GT2_IDS(info) \
+ INTEL_VGA_DEVICE(0x3EA0, info), \
+ INTEL_VGA_DEVICE(0x3EA3, info), \
+ INTEL_VGA_DEVICE(0x3EA9, info)
+
+/* CFL U GT3 */
#define INTEL_CFL_U_GT3_IDS(info) \
+ INTEL_VGA_DEVICE(0x3EA2, info), /* ULT GT3 */ \
+ INTEL_VGA_DEVICE(0x3EA5, info), /* ULT GT3 */ \
INTEL_VGA_DEVICE(0x3EA6, info), /* ULT GT3 */ \
INTEL_VGA_DEVICE(0x3EA7, info), /* ULT GT3 */ \
- INTEL_VGA_DEVICE(0x3EA8, info), /* ULT GT3 */ \
- INTEL_VGA_DEVICE(0x3EA5, info) /* ULT GT3 */
+ INTEL_VGA_DEVICE(0x3EA8, info) /* ULT GT3 */
-#define INTEL_CFL_IDS(info) \
+#define INTEL_CFL_IDS(info) \
INTEL_CFL_S_GT1_IDS(info), \
INTEL_CFL_S_GT2_IDS(info), \
INTEL_CFL_H_GT2_IDS(info), \
+ INTEL_CFL_U_GT1_IDS(info), \
+ INTEL_CFL_U_GT2_IDS(info), \
INTEL_CFL_U_GT3_IDS(info)
/* CNL U 2+2 */
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] meson: Bump required version to 0.44.0
On Sun, Dec 24, 2017 at 6:49 AM, Rhys Kidd <rhysk...@gmail.com> wrote:
> warning() needs that, which was introduced in a 865a47ca failure path.
>
> Otherwise we get error messages on that failure path like:
> ...
> Program leg found: NO
>
> Meson encountered an error in file overlay/meson.build, line 62, column 1:
> Unknown function "warning".
> FAILED: build.ninja
> ...
>
> Fixes: 865a47ca ("overlay: parse tracepoints from sysfs to figure out fields'
> location")
> Signed-off-by: Rhys Kidd <rhysk...@gmail.com>
I just had this error and prepared a patch to do the other way around:
use message() rather than warning().
I think we could delay raising the dependency to the latest meson
version on Fedora 27 for example we have
meson 0.43 available, not 0.44 (although we could install 0.44 from pypi).
I'm not sure which one is best.
Lucas De Marchi
> ---
> meson.build | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index 0950d3c7..20064ae1 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -5,7 +5,7 @@ project('IGT gpu tests', 'c',
>'c_std=gnu99',
> ],
> license : 'MIT',
> - meson_version : '>0.40.0')
> + meson_version : '>=0.44.0')
>
> cc = meson.get_compiler('c')
>
> --
> 2.14.1
>
> ___________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: remove check for aux irq
On Tue, Jun 19, 2018 at 01:17:10PM -0700, Dhinakaran Pandiyan wrote:
> On Tue, 2018-06-19 at 08:24 -0700, Lucas De Marchi wrote:
> > On Tue, Jun 19, 2018 at 7:06 AM Ville Syrjälä
> > wrote:
> > >
> > >
> > > On Fri, Jun 15, 2018 at 02:51:06PM -0700, Lucas De Marchi wrote:
> > > >
> > > > On Fri, Jun 15, 2018 at 08:58:28PM +0300, Ville Syrjälä wrote:
> > > > >
> > > > > On Wed, May 23, 2018 at 11:04:35AM -0700, Lucas De Marchi
> > > > > wrote:
> > > > > >
> > > > > > This became dead code with commit 309bd8ed464f ("drm/i915:
> > > > > > Reinstate
> > > > > > GMBUS and AUX interrupts on gen4/g4x").
> > > > > >
> > > > > > v2: Move comment about HW behavior to where decision is made
> > > > > > to enable
> > > > > > MSI (Ville).
> > > > > >
> > > > > > Cc: Ville Syrjälä
> > > > > > Signed-off-by: Lucas De Marchi
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/i915_drv.c | 6 ++
> > > > > > drivers/gpu/drm/i915/i915_drv.h | 10 --
> > > > > > drivers/gpu/drm/i915/intel_dp.c | 22 +++---
> > > > > > drivers/gpu/drm/i915/intel_drv.h | 1 -
> > > > > > drivers/gpu/drm/i915/intel_psr.c | 2 +-
> > > > > > 5 files changed, 14 insertions(+), 27 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > > > index 9c449b8d8eab..a1461de20472 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > > > @@ -1189,6 +1189,12 @@ static int i915_driver_init_hw(struct
> > > > > > drm_i915_private *dev_priv)
> > > > > > * get lost on g4x as well, and interrupt delivery seems to
> > > > > > stay
> > > > > > * properly dead afterwards. So we'll just disable them for
> > > > > > all
> > > > > > * pre-gen5 chipsets.
> > > > > > + *
> > > > > > + * dp aux and gmbus irq on gen4 seems to be able to
> > > > > > generate legacy
> > > > > > + * interrupts even when in MSI mode. This results in
> > > > > > spurious
> > > > > > + * interrupt warnings if the legacy irq no. is shared with
> > > > > > another
> > > > > > + * device. The kernel then disables that interrupt source
> > > > > > and so
> > > > > > + * prevents the other device from working properly.
> > > > > > */
> > > > > > if (INTEL_GEN(dev_priv) >= 5) {
> > > > > > if (pci_enable_msi(pdev) < 0)
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > index b86ed6401120..c5e1f648c47c 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > @@ -2558,16 +2558,6 @@ intel_info(const struct
> > > > > > drm_i915_private *dev_priv)
> > > > > > (IS_CANNONLAKE(dev_priv) || \
> > > > > > IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> > > > > >
> > > > > > -/*
> > > > > > - * dp aux and gmbus irq on gen4 seems to be able to generate
> > > > > > legacy interrupts
> > > > > > - * even when in MSI mode. This results in spurious interrupt
> > > > > > warnings if the
> > > > > > - * legacy irq no. is shared with another device. The kernel
> > > > > > then disables that
> > > > > > - * interrupt source and so prevents the other device from
> > > > > > working properly.
> > > > > > - *
> > > > > > - * Since we don't enable MSI anymore on gen4, we can always
> > > > > > use GMBUS/AUX
> > > > > > - * interrupts.
> > > > > > - */
> > > > > > -#define HAS_AUX_IRQ(dev_priv) true
> > > > > > #define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
> > > > > >
> > > &g
Re: [Intel-gfx] [PATCH 0/7] drm/i915: move towards kernel types
On Fri, Jun 15, 2018 at 2:08 AM Jani Nikula wrote: > > On Thu, 14 Jun 2018, Rodrigo Vivi wrote: > > On Wed, Jun 13, 2018 at 09:55:38AM +0300, Jani Nikula wrote: > >> On Tue, 12 Jun 2018, Lucas De Marchi wrote: > >> > On Tue, Jun 12, 2018 at 3:15 AM Jani Nikula > >> > wrote: > >> >> > >> >> On Tue, 12 Jun 2018, Tvrtko Ursulin > >> >> wrote: > >> >> > On 12/06/2018 10:19, Jani Nikula wrote: > >> >> >> Semi-RFC. Do we want to do this? Here's a batch of conversions that > >> >> >> shouldn't > >> >> >> conflict much with in-flight patches. > >> >> >> > >> >> >> The trouble with mixed use is that it's inconsistent, and any > >> >> >> remaining C99 > >> >> >> types will encourage their use. We could at least do the low hanging > >> >> >> fruit? > >> >> > > >> >> > Ack from me. Doesn't seem so big to cause much pain. > >> >> > > >> >> > When you say low-hanging fruit, that implies you only dealt with a > >> >> > particular class of occurrences? > >> >> > >> >> I meant the files which don't have massive amounts of C99 types and > >> >> aren't under active development right now. I just wanted to avoid > >> >> trouble for starters. ;) > >> > > >> > If using kernel types is where we want to go (which I agree with), > >> > maybe it would be better to have a single conversion rather than > >> > several small ones as we are doing with dev_priv -> i915? This allows > >> > in-flight-but-not-yet-sent patches to easily keep up with the changes > >> > rather than conflicting every other rebase. > >> > >> I'm thinking we can do a lot of changes without conflicting anything or > >> very little. At least for starters before the sudden ripping off the > >> band-aid. > > > > I'm with Lucas. I'd prefer one single massive move than many small ones. > > Easier for the internal maintenance. We fix it only once and not one per > > day for months and months like dev_priv/i915 case. > > For everything else, I believe smaller patches are easier. For example, > who is going to review the massive change? Halt everything until it's > reviewed and merged? For merge conflicts I think git can do a better job > of managing the rerere with piecemeal changes. Internal is not the only > consideration. A change like this would be a matter of having a sed/cocci/whatever script that can be reproduced later. The end result can be split in logical chunks for review/merge, I never said it ought to be in one patch. Lucas De Marchi > > BR, > Jani. > > > > >> > >> BR, > >> Jani. > >> > >> > > >> > Lucas De Marchi > >> > > >> >> > >> >> > Also going forward we have to make sure we will be able to stop them > >> >> > creeping back in. Is checkpatch perhaps covering this? Or we could put > >> >> > something in dim? > >> >> > >> >> We can stop ignoring PREFER_KERNEL_TYPES in checkpatch (the ignores are > >> >> in dim). We don't even have to change everything for that, we just need > >> >> to change enough to make the S/N better. People tend to use the types > >> >> near the places they change. > >> >> > >> >> BR, > >> >> Jani. > >> >> > >> >> > >> >> > > >> >> > Regards, > >> >> > > >> >> > Tvrtko > >> >> > > >> >> >> $ git grep "uint\(8\|16\|32\|64\)_t" -- drivers/gpu/drm/i915/ | sed > >> >> >> 's/:.*//' | sort | uniq -c | sort -n > >> >> >> > >> >> >> BR, > >> >> >> Jani. > >> >> >> > >> >> >> > >> >> >> Jani Nikula (7): > >> >> >>drm/i915/vbt: switch to kernel unsigned int types > >> >> >>drm/i915/hdmi: switch to kernel unsigned int types > >> >> >>drm/i915/uncore: switch to kernel unsigned int types > >> >> >>drm/i915/dvo: switch to kernel unsigned int types > >> >> >>drm/i915/backlight: switch to kernel unsigned int types > >> >> >>drm/i915/audio: switch to ke
Re: [Intel-gfx] [PATCH 1/4] drm/i915: fix guest virtual PCH detection on non-PCH systems
On Wed, Jun 13, 2018 at 11:57 PM Arkadiusz Hiler wrote: > > On Wed, Jun 13, 2018 at 10:16:07AM -0700, Lucas De Marchi wrote: > > On Wed, Jun 13, 2018 at 10:09 AM Lucas De Marchi > > wrote: > > > > > > On Wed, Jun 13, 2018 at 1:11 AM Arkadiusz Hiler > > > wrote: > > > > > > > > On Wed, Jun 13, 2018 at 09:49:09AM +0300, Jani Nikula wrote: > > > > > On Tue, 12 Jun 2018, Lucas De Marchi > > > > > wrote: > > > > > > On Fri, Jun 8, 2018 at 5:34 AM Jani Nikula > > > > > > wrote: > > > > > >> > > > > > >> On Thu, 31 May 2018, Lucas De Marchi > > > > > >> wrote: > > > > > >> > On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote: > > > > > >> >> Virtualized non-PCH systems such as Broxton or Geminilake > > > > > >> >> should use > > > > > >> >> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a > > > > > >> >> specific case to indicate a PCH system without south display. > > > > > >> > > > > > > >> > Then let's go ahead and document it? > > > > > >> > > > > > >> Please avoid sending suggestion patches in-reply-to existing > > > > > >> series. This confused patchwork and screwed up CI for the series, > > > > > >> which > > > > > >> was already a resend just to get CI. :( > > > > > > > > > > > > ugh, sorry. Sometimes just adding a oneline diff is much better > > > > > > than > > > > > > a hundred words explaining :( ... > > > > > > > > > > I feel you, a patch is more precise. > > > > > > > > > > > IMO pw is trying to be smarter than it should here or not being > > > > > > smart > > > > > > enough. Nonetheless I won't do that anymore. > > > > > > > > > > I think there were earlier complaints about what it did recognize and > > > > > what it didn't. I'd be open to only accepting new versions of patches > > > > > from whoever sent the original patch. Or requiring patch subjects > > > > > don't > > > > > start with "Re:". Or both. > > > > > > > > No matter what you do here it will misbehave in some scenarios and > > > > break someone's workflow :< > > > > > > > > Originally we required the patches to have X-Mailer set to > > > > git-send-email, which seems reasonable, but that annoyed people because > > > > their servers were stripping out those headers. > > > > > > > > Other people send out the patches by feeding them to the drafts folder > > > > through IMAP and then sending them out. This, depending on the > > > > provider's configuration, also gobbles up a thing or two. > > > > > > > > Because of the above I am not sure about trusting "Re:" and matching > > > > "From:" headers as good enough indicators either. > > > > > > > > It just adds more opaque "smartness". I already can foresee questions > > > > asking "why my v2 was not picked up?" and someone would have to debug it > > > > down the line. > > > > > > > > Was the address different (+XYZ before @)? Has that someone used > > > > --subject-prefix=re:? Is it an actual bug? Etc. > > > > > > > > > > > > > I was annoyed, but I'm perhaps more annoyed that you can't do this > > > > > without confusing patchwork. In the end, I wouldn't want to hamper > > > > > review by blocking something that comes naturally to people. > > > > > > > > > > Arek? > > > > > > > > Just add the following header: > > > > "X-Patchwork-Hint: comment" > > > > to emails that you type out manually. > > > > > > > > For mutt it's as easy as adding: > > > > "my_hdr X-Patchwork-Hint: comment" > > > > to your .muttrc > > > > > > This may not work for the same reasons you pointed out that wouldn't > > > work if people are sending patches. Is there a format I can use that > > > will not trigger patchwork from parsing a _reply_? Does removing the > > > "----"
Re: [Intel-gfx] [PATCH 01/10] drm/i915/icl: Fix power well anonymous union initializers
On Fri, Jul 20, 2018 at 05:14:55PM +0300, Imre Deak wrote:
> Similarly to
> 0a445945be6d ("drm/i915: Work around GCC anonymous union initialization bug")
> we need to initialize anonymous unions inside extra braces to work
> around a GCC4.4 build error.
Aren't we jumping to gcc 4.5 as minimum version? Or was it 4.6/4.8?
Lucas De Marchi
>
> Cc: Chris Wilson
> Cc: Ville Syrjala
> Cc: Paulo Zanoni
> Cc: Jani Nikula
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 22 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 6b5aa3b074ec..1a87176a85c1 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -2620,14 +2620,18 @@ static struct i915_power_well icl_power_wells[] = {
> .domains = 0,
> .ops = _power_well_ops,
> .id = ICL_DISP_PW_1,
> - .hsw.has_fuses = true,
> + {
> + .hsw.has_fuses = true,
> + },
> },
> {
> .name = "power well 2",
> .domains = ICL_PW_2_POWER_DOMAINS,
> .ops = _power_well_ops,
> .id = ICL_DISP_PW_2,
> - .hsw.has_fuses = true,
> + {
> + .hsw.has_fuses = true,
> + },
> },
> {
> .name = "DC off",
> @@ -2640,9 +2644,11 @@ static struct i915_power_well icl_power_wells[] = {
> .domains = ICL_PW_3_POWER_DOMAINS,
> .ops = _power_well_ops,
> .id = ICL_DISP_PW_3,
> - .hsw.irq_pipe_mask = BIT(PIPE_B),
> - .hsw.has_vga = true,
> - .hsw.has_fuses = true,
> + {
> + .hsw.irq_pipe_mask = BIT(PIPE_B),
> + .hsw.has_vga = true,
> + .hsw.has_fuses = true,
> + },
> },
> {
> .name = "DDI A IO",
> @@ -2745,8 +2751,10 @@ static struct i915_power_well icl_power_wells[] = {
> .domains = ICL_PW_4_POWER_DOMAINS,
> .ops = _power_well_ops,
> .id = ICL_DISP_PW_4,
> - .hsw.has_fuses = true,
> - .hsw.irq_pipe_mask = BIT(PIPE_C),
> + {
> + .hsw.has_fuses = true,
> + .hsw.irq_pipe_mask = BIT(PIPE_C),
> + },
> },
> };
>
> --
> 2.13.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
[Intel-gfx] [PATCH i-g-t] docs: fix typo sharding->sharing
I was grepping for shard as the tests run on CI, but the only occurrence
was this one which seems to be a typo since it's about prime tests.
Fixes: 76bce773 ("docs: Update documentation generation with missing entries")
Signed-off-by: Lucas De Marchi
---
docs/reference/igt-gpu-tools/igt_test_programs.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/reference/igt-gpu-tools/igt_test_programs.xml
b/docs/reference/igt-gpu-tools/igt_test_programs.xml
index ec05d53e..95c4653e 100644
--- a/docs/reference/igt-gpu-tools/igt_test_programs.xml
+++ b/docs/reference/igt-gpu-tools/igt_test_programs.xml
@@ -229,7 +229,7 @@
Prime Tests
- Tests for buffer sharding
+ Tests for buffer sharing
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/10] drm/i915/icl: Fix power well anonymous union initializers
On Fri, Aug 3, 2018 at 3:24 AM Imre Deak wrote:
>
> On Thu, Aug 02, 2018 at 05:24:36PM -0700, Paulo Zanoni wrote:
> > Em Qui, 2018-08-02 às 16:17 -0700, Lucas De Marchi escreveu:
> > > On Fri, Jul 20, 2018 at 05:14:55PM +0300, Imre Deak wrote:
> > > > Similarly to
> > > > 0a445945be6d ("drm/i915: Work around GCC anonymous union
> > > > initialization bug")
> > > > we need to initialize anonymous unions inside extra braces to work
> > > > around a GCC4.4 build error.
> > >
> > > Aren't we jumping to gcc 4.5 as minimum version? Or was it 4.6/4.8?
> >
> > https://cgit.freedesktop.org/drm-tip/tree/Documentation/process/changes.rst#n32
> >
> > 3.2 is still the theoretical minimum for us.
we can't build with a 3.2 compiler... just nobody bothered to update
the docs. AFAIK 4.1 is the current minimum.
>
> There do seems to be a plan [1] to make the minimum 4.8. But yea, that's
> still just a plan. In any case I'd use one form of initialization for
> consistency, now it's both ways in the code.
ok
Lucas De Marchi
>
> [1] https://www.linuxjournal.com/content/minimum-gcc-version-likely-jump-32-48
>
> >
> > >
> > > Lucas De Marchi
> > >
> > > >
> > > > Cc: Chris Wilson
> > > > Cc: Ville Syrjala
> > > > Cc: Paulo Zanoni
> > > > Cc: Jani Nikula
> > > > Signed-off-by: Imre Deak
> > > > ---
> > > > drivers/gpu/drm/i915/intel_runtime_pm.c | 22 +++
> > > > ---
> > > > 1 file changed, 15 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > > index 6b5aa3b074ec..1a87176a85c1 100644
> > > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > > @@ -2620,14 +2620,18 @@ static struct i915_power_well
> > > > icl_power_wells[] = {
> > > > .domains = 0,
> > > > .ops = _power_well_ops,
> > > > .id = ICL_DISP_PW_1,
> > > > - .hsw.has_fuses = true,
> > > > + {
> > > > + .hsw.has_fuses = true,
> > > > + },
> > > > },
> > > > {
> > > > .name = "power well 2",
> > > > .domains = ICL_PW_2_POWER_DOMAINS,
> > > > .ops = _power_well_ops,
> > > > .id = ICL_DISP_PW_2,
> > > > - .hsw.has_fuses = true,
> > > > + {
> > > > + .hsw.has_fuses = true,
> > > > + },
> > > > },
> > > > {
> > > > .name = "DC off",
> > > > @@ -2640,9 +2644,11 @@ static struct i915_power_well
> > > > icl_power_wells[] = {
> > > > .domains = ICL_PW_3_POWER_DOMAINS,
> > > > .ops = _power_well_ops,
> > > > .id = ICL_DISP_PW_3,
> > > > - .hsw.irq_pipe_mask = BIT(PIPE_B),
> > > > - .hsw.has_vga = true,
> > > > - .hsw.has_fuses = true,
> > > > + {
> > > > + .hsw.irq_pipe_mask = BIT(PIPE_B),
> > > > + .hsw.has_vga = true,
> > > > + .hsw.has_fuses = true,
> > > > + },
> > > > },
> > > > {
> > > > .name = "DDI A IO",
> > > > @@ -2745,8 +2751,10 @@ static struct i915_power_well
> > > > icl_power_wells[] = {
> > > > .domains = ICL_PW_4_POWER_DOMAINS,
> > > > .ops = _power_well_ops,
> > > > .id = ICL_DISP_PW_4,
> > > > - .hsw.has_fuses = true,
> > > > - .hsw.irq_pipe_mask = BIT(PIPE_C),
> > > > + {
> > > > + .hsw.has_fuses = true,
> > > > + .hsw.irq_pipe_mask = BIT(PIPE_C),
> > > > + },
> > > > },
> > > > };
> > > >
> > > > --
> > > > 2.13.2
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/2] drm/i915: kill resource streamer
After disabling resource streamer on ICL (due to it actually not
existing there), I got feedback that there have been some experimental
patches for mesa to use RS years ago, but nothing ever landed or shipped
because there was no performance improvement.
This removes it from kernel keeping the uapi defines around for
compatibility.
v2: - re-add the inadvertent removal of CTX_CTRL_INHIBIT_SYN_CTX_SWITCH
- don't bother trying to document removed params on uapi header:
applications should know that from the query.
(from Chris)
v3: - disable CTX_CTRL_RS_CTX_ENABLE istead of removing it
- reword commit message after Daniele confirmed no performance
regression on his machine
- reword commit message to make clear RS is being removed due to
never been used
v4: - move I915_EXEC_RESOURCE_STREAMER to __I915_EXEC_ILLEGAL_FLAGS so
the check on ioctl() is made much earlier by
i915_gem_check_execbuffer() (suggested by Tvrtko)
Signed-off-by: Lucas De Marchi
Acked-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_drv.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 2 --
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 17 ++---
drivers/gpu/drm/i915/i915_pci.c| 4
drivers/gpu/drm/i915/intel_device_info.h | 1 -
drivers/gpu/drm/i915/intel_lrc.c | 10 --
drivers/gpu/drm/i915/intel_ringbuffer.c| 4 +---
drivers/gpu/drm/i915/intel_ringbuffer.h| 1 -
8 files changed, 8 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 64e0ea4bef67..3857e7963fc5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -373,7 +373,7 @@ static int i915_getparam_ioctl(struct drm_device *dev, void
*data,
value = 2;
break;
case I915_PARAM_HAS_RESOURCE_STREAMER:
- value = HAS_RESOURCE_STREAMER(dev_priv);
+ value = 0;
break;
case I915_PARAM_HAS_POOLED_EU:
value = HAS_POOLED_EU(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4aca5344863d..657f46e0cae9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2610,8 +2610,6 @@ intel_info(const struct drm_i915_private *dev_priv)
#define USES_GUC_SUBMISSION(dev_priv) intel_uc_is_using_guc_submission()
#define USES_HUC(dev_priv) intel_uc_is_using_huc()
-#define HAS_RESOURCE_STREAMER(dev_priv)
((dev_priv)->info.has_resource_streamer)
-
#define HAS_POOLED_EU(dev_priv)((dev_priv)->info.has_pooled_eu)
#define INTEL_PCH_DEVICE_ID_MASK 0xff80
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1932bc227942..06bb434644e5 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -64,7 +64,8 @@ enum {
#define BATCH_OFFSET_BIAS (256*1024)
#define __I915_EXEC_ILLEGAL_FLAGS \
- (__I915_EXEC_UNKNOWN_FLAGS | I915_EXEC_CONSTANTS_MASK)
+ (__I915_EXEC_UNKNOWN_FLAGS | I915_EXEC_CONSTANTS_MASK | \
+I915_EXEC_RESOURCE_STREAMER)
/* Catch emission of unexpected errors for CI! */
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
@@ -2221,20 +,6 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (!eb.engine)
return -EINVAL;
- if (args->flags & I915_EXEC_RESOURCE_STREAMER) {
- if (!HAS_RESOURCE_STREAMER(eb.i915)) {
- DRM_DEBUG("RS is only allowed for Haswell and Gen8 -
Gen10\n");
- return -EINVAL;
- }
- if (eb.engine->id != RCS) {
- DRM_DEBUG("RS is not available on %s\n",
-eb.engine->name);
- return -EINVAL;
- }
-
- eb.batch_flags |= I915_DISPATCH_RS;
- }
-
if (args->flags & I915_EXEC_FENCE_IN) {
in_fence = sync_file_get_fence(lower_32_bits(args->rsvd2));
if (!in_fence)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 8a9a9009db62..e931b48369dd 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -368,7 +368,6 @@ static const struct intel_device_info intel_valleyview_info
= {
.has_ddi = 1, \
.has_fpga_dbg = 1, \
.has_psr = 1, \
- .has_resource_streamer = 1, \
.has_dp_mst = 1, \
.has_rc6p = 0 /* RC6p removed-by HSW */, \
.has_runtime_pm = 1
@@ -441,7 +440,6 @@ static const struct intel_device_info intel_cherryview_info
= {
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.has_64bit_reloc = 1,
.has_runtime_pm = 1,
- .has_resource_streamer = 1,
.ha
[Intel-gfx] [PATCH v4 1/3] drm/i915: make PCH_GMBUS* definitions private to gvt
This is the only place that they are being used - the others use the
GMBUS* macros that rely on dev_priv being already properly initialized.
Cc: intel-gvt-...@lists.freedesktop.org
Cc: Zhenyu Wang
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gvt/reg.h | 7 +++
drivers/gpu/drm/i915/i915_reg.h | 7 ---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/reg.h b/drivers/gpu/drm/i915/gvt/reg.h
index d4f7ce6dc1d7..fd5fd25d0a0f 100644
--- a/drivers/gpu/drm/i915/gvt/reg.h
+++ b/drivers/gpu/drm/i915/gvt/reg.h
@@ -77,4 +77,11 @@
#define _RING_CTL_BUF_SIZE(ctl) (((ctl) & RB_TAIL_SIZE_MASK) + \
I915_GTT_PAGE_SIZE)
+#define PCH_GMBUS0 _MMIO(0xc5100)
+#define PCH_GMBUS1 _MMIO(0xc5104)
+#define PCH_GMBUS2 _MMIO(0xc5108)
+#define PCH_GMBUS3 _MMIO(0xc510c)
+#define PCH_GMBUS4 _MMIO(0xc5110)
+#define PCH_GMBUS5 _MMIO(0xc5120)
+
#endif
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5530c470f30d..07606677168c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7875,13 +7875,6 @@ enum {
#define PCH_GPIOE _MMIO(0xc5020)
#define PCH_GPIOF _MMIO(0xc5024)
-#define PCH_GMBUS0 _MMIO(0xc5100)
-#define PCH_GMBUS1 _MMIO(0xc5104)
-#define PCH_GMBUS2 _MMIO(0xc5108)
-#define PCH_GMBUS3 _MMIO(0xc510c)
-#define PCH_GMBUS4 _MMIO(0xc5110)
-#define PCH_GMBUS5 _MMIO(0xc5120)
-
#define _PCH_DPLL_A 0xc6014
#define _PCH_DPLL_B 0xc6018
#define PCH_DPLL(pll) _MMIO((pll) == 0 ? _PCH_DPLL_A : _PCH_DPLL_B)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 3/3] drm/i915: remove confusing GPIO vs PCH_GPIO
Instead of defining all registers twice, define just a PCH_GPIO_BASE
that has the same address as PCH_GPIO_A and use that to calculate all
the others. This also brings VLV and !HAS_GMCH_DISPLAY in line, doing
the same thing.
v2: Fix GMBUS registers to be relative to gpio base; create GPIO()
macro to return a particular gpio address and move the enum out of
i915_reg.h (suggested by Jani)
v3: Move base offset inside the GPIO() macro so the GMBUS defines don't
actually need to be changed (suggested by Daniel/Ville)
v4: Move definition of i915_gpio to intel_display.h and remove
GMBUS/GPIO handling from gvt since now they have their own
defines.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/i915_reg.h | 24 +---
drivers/gpu/drm/i915/intel_display.h | 16
drivers/gpu/drm/i915/intel_i2c.c | 16
4 files changed, 31 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0f49f9988dfa..19ad2a52ab04 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1604,7 +1604,8 @@ struct drm_i915_private {
struct mutex gmbus_mutex;
/**
-* Base address of the gmbus and gpio block.
+* Base address of where the gmbus and gpio blocks are located (either
+* on PCH or on SoC for platforms without PCH).
*/
uint32_t gpio_mmio_base;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 07606677168c..827d442e1b12 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3168,18 +3168,9 @@ enum i915_power_well_id {
/*
* GPIO regs
*/
-#define GPIOA _MMIO(0x5010)
-#define GPIOB _MMIO(0x5014)
-#define GPIOC _MMIO(0x5018)
-#define GPIOD _MMIO(0x501c)
-#define GPIOE _MMIO(0x5020)
-#define GPIOF _MMIO(0x5024)
-#define GPIOG _MMIO(0x5028)
-#define GPIOH _MMIO(0x502c)
-#define GPIOJ _MMIO(0x5034)
-#define GPIOK _MMIO(0x5038)
-#define GPIOL _MMIO(0x503C)
-#define GPIOM _MMIO(0x5040)
+#define GPIO(gpio) _MMIO(dev_priv->gpio_mmio_base + 0x5010 + \
+ 4 * (gpio))
+
# define GPIO_CLOCK_DIR_MASK (1 << 0)
# define GPIO_CLOCK_DIR_IN (0 << 1)
# define GPIO_CLOCK_DIR_OUT(1 << 1)
@@ -7574,6 +7565,8 @@ enum {
/* PCH */
+#define PCH_DISPLAY_BASE 0xcu
+
/* south display engine interrupt: IBX */
#define SDE_AUDIO_POWER_D (1 << 27)
#define SDE_AUDIO_POWER_C (1 << 26)
@@ -7868,13 +7861,6 @@ enum {
#define ICP_TC_HPD_LONG_DETECT(tc_port) (2 << (tc_port) * 4)
#define ICP_TC_HPD_SHORT_DETECT(tc_port) (1 << (tc_port) * 4)
-#define PCH_GPIOA _MMIO(0xc5010)
-#define PCH_GPIOB _MMIO(0xc5014)
-#define PCH_GPIOC _MMIO(0xc5018)
-#define PCH_GPIOD _MMIO(0xc501c)
-#define PCH_GPIOE _MMIO(0xc5020)
-#define PCH_GPIOF _MMIO(0xc5024)
-
#define _PCH_DPLL_A 0xc6014
#define _PCH_DPLL_B 0xc6018
#define PCH_DPLL(pll) _MMIO((pll) == 0 ? _PCH_DPLL_A : _PCH_DPLL_B)
diff --git a/drivers/gpu/drm/i915/intel_display.h
b/drivers/gpu/drm/i915/intel_display.h
index 0a79a46d5805..e7f49f107e57 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -25,6 +25,22 @@
#ifndef _INTEL_DISPLAY_H_
#define _INTEL_DISPLAY_H_
+enum i915_gpio {
+ GPIOA,
+ GPIOB,
+ GPIOC,
+ GPIOD,
+ GPIOE,
+ GPIOF,
+ GPIOG,
+ GPIOH,
+ __GPIOI_UNUSED,
+ GPIOJ,
+ GPIOK,
+ GPIOL,
+ GPIOM,
+};
+
enum pipe {
INVALID_PIPE = -1,
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index bef32b7c248e..33d87ab93fdd 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -37,7 +37,7 @@
struct gmbus_pin {
const char *name;
- i915_reg_t reg;
+ enum i915_gpio gpio;
};
/* Map gmbus pin pairs to names and registers. */
@@ -121,8 +121,7 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private
*dev_priv,
else
size = ARRAY_SIZE(gmbus_pins);
- return pin < size &&
- i915_mmio_reg_valid(get_gmbus_pin(dev_priv, pin)->reg);
+ return pin < size && get_gmbus_pin(dev_priv, pin)->name;
}
/* Intel GPIO access functions */
@@ -292,8 +291,7 @@ intel_gpio_setup(struct intel_gmbus *bus, unsigned int pin)
algo = >bit_algo;
- bus->gpio_reg = _MMIO(dev_priv->gpio_mmio_base +
-
[Intel-gfx] [PATCH v4 2/3] drm/i915/gvt: use its own define for gpio
The definition on i915_reg.h is going to change to depend on dev_priv->gpio_mmio_base being properly initialized. Define our own macros since init_generic_mmio_info() is called before than gpio_mmio_base being set. Cc: intel-gvt-...@lists.freedesktop.org Cc: Zhenyu Wang Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/gvt/handlers.c | 2 +- drivers/gpu/drm/i915/gvt/reg.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gvt/handlers.c b/drivers/gpu/drm/i915/gvt/handlers.c index 7a58ca555197..0dc8692d7eb3 100644 --- a/drivers/gpu/drm/i915/gvt/handlers.c +++ b/drivers/gpu/drm/i915/gvt/handlers.c @@ -2118,7 +2118,7 @@ static int init_generic_mmio_info(struct intel_gvt *gvt) MMIO_F(PCH_GMBUS0, 4 * 4, 0, 0, 0, D_ALL, gmbus_mmio_read, gmbus_mmio_write); - MMIO_F(PCH_GPIOA, 6 * 4, F_UNALIGN, 0, 0, D_ALL, NULL, NULL); + MMIO_F(PCH_GPIO_BASE, 6 * 4, F_UNALIGN, 0, 0, D_ALL, NULL, NULL); MMIO_F(_MMIO(0xe4f00), 0x28, 0, 0, 0, D_ALL, NULL, NULL); MMIO_F(_MMIO(_PCH_DPB_AUX_CH_CTL), 6 * 4, 0, 0, 0, D_PRE_SKL, NULL, diff --git a/drivers/gpu/drm/i915/gvt/reg.h b/drivers/gpu/drm/i915/gvt/reg.h index fd5fd25d0a0f..c9d6cf6cc623 100644 --- a/drivers/gpu/drm/i915/gvt/reg.h +++ b/drivers/gpu/drm/i915/gvt/reg.h @@ -77,6 +77,8 @@ #define _RING_CTL_BUF_SIZE(ctl) (((ctl) & RB_TAIL_SIZE_MASK) + \ I915_GTT_PAGE_SIZE) +#define PCH_GPIO_BASE _MMIO(0xc5010) + #define PCH_GMBUS0 _MMIO(0xc5100) #define PCH_GMBUS1 _MMIO(0xc5104) #define PCH_GMBUS2 _MMIO(0xc5108) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] docs: fix typo sharding->sharing
On Wed, Aug 15, 2018 at 2:09 AM Daniel Vetter wrote:
>
> On Tue, Aug 14, 2018 at 10:29:02AM -0700, Lucas De Marchi wrote:
> > On Fri, Aug 03, 2018 at 12:07:43PM +0300, Petri Latvala wrote:
> > > On Thu, Aug 02, 2018 at 03:09:37PM -0700, Lucas De Marchi wrote:
> > > > I was grepping for shard as the tests run on CI, but the only occurrence
> > > > was this one which seems to be a typo since it's about prime tests.
> > > >
> > > > Fixes: 76bce773 ("docs: Update documentation generation with missing
> > > > entries")
> > > > Signed-off-by: Lucas De Marchi
> > >
> > > Reviewed-by: Petri Latvala
> >
> > just a heads up that this is not yet applied...
>
> Sounds like time to fix you up with commit rights asap:
>
> https://www.freedesktop.org/wiki/AccountRequests/
>
> Please paste your account request here so we can move it forward (igt
> maintainers are on board too, I pinged them over irc).
I had an account created in 2015 for another project:
https://bugs.freedesktop.org/show_bug.cgi?id=89446
I still have the keys, so if the account wasn't dropped by inactivity
it should be good enough.
thanks
Lucas De Marchi
> -Daniel
>
> >
> > thanks
> > Lucas De Marchi
> >
> > >
> > >
> > > > ---
> > > > docs/reference/igt-gpu-tools/igt_test_programs.xml | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > > > b/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > > > index ec05d53e..95c4653e 100644
> > > > --- a/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > > > +++ b/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > > > @@ -229,7 +229,7 @@
> > > >
> > > >
> > > >Prime Tests
> > > > - Tests for buffer sharding
> > > > + Tests for buffer sharing
> > > >
> > > >
> > > >
> > > > --
> > > > 2.17.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
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] docs: fix typo sharding->sharing
On Fri, Aug 03, 2018 at 12:07:43PM +0300, Petri Latvala wrote:
> On Thu, Aug 02, 2018 at 03:09:37PM -0700, Lucas De Marchi wrote:
> > I was grepping for shard as the tests run on CI, but the only occurrence
> > was this one which seems to be a typo since it's about prime tests.
> >
> > Fixes: 76bce773 ("docs: Update documentation generation with missing
> > entries")
> > Signed-off-by: Lucas De Marchi
>
> Reviewed-by: Petri Latvala
just a heads up that this is not yet applied...
thanks
Lucas De Marchi
>
>
> > ---
> > docs/reference/igt-gpu-tools/igt_test_programs.xml | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > b/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > index ec05d53e..95c4653e 100644
> > --- a/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > +++ b/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > @@ -229,7 +229,7 @@
> >
> >
> >Prime Tests
> > - Tests for buffer sharding
> > + Tests for buffer sharing
> >
> >
> >
> > --
> > 2.17.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
___
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: remove confusing GPIO vs PCH_GPIO
On Fri, Jul 27, 2018 at 12:36:47PM -0700, Lucas De Marchi wrote:
> Instead of defining all registers twice, define just a PCH_GPIO_BASE
> that has the same address as PCH_GPIO_A and use that to calculate all
> the others. This also brings VLV and !HAS_GMCH_DISPLAY in line, doing
> the same thing.
>
> v2: Fix GMBUS registers to be relative to gpio base; create GPIO()
> macro to return a particular gpio address and move the enum out of
> i915_reg.h (suggested by Jani)
>
> v3: Move base offset inside the GPIO() macro so the GMBUS defines don't
> actually need to be changed (suggested by Daniel/Ville)
>
> v4: Move definition of i915_gpio to intel_display.h and remove
> GMBUS/GPIO handling from gvt since now they have their own
> defines.
>
> Signed-off-by: Lucas De Marchi
> ---
Adding people that should have been in CC. Let me know if there's
anything missing.
Lucas De Marchi
> drivers/gpu/drm/i915/i915_drv.h | 3 ++-
> drivers/gpu/drm/i915/i915_reg.h | 24 +---
> drivers/gpu/drm/i915/intel_display.h | 16
> drivers/gpu/drm/i915/intel_i2c.c | 16
> 4 files changed, 31 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 0f49f9988dfa..19ad2a52ab04 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1604,7 +1604,8 @@ struct drm_i915_private {
> struct mutex gmbus_mutex;
>
> /**
> - * Base address of the gmbus and gpio block.
> + * Base address of where the gmbus and gpio blocks are located (either
> + * on PCH or on SoC for platforms without PCH).
>*/
> uint32_t gpio_mmio_base;
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 07606677168c..827d442e1b12 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3168,18 +3168,9 @@ enum i915_power_well_id {
> /*
> * GPIO regs
> */
> -#define GPIOA_MMIO(0x5010)
> -#define GPIOB_MMIO(0x5014)
> -#define GPIOC_MMIO(0x5018)
> -#define GPIOD_MMIO(0x501c)
> -#define GPIOE_MMIO(0x5020)
> -#define GPIOF_MMIO(0x5024)
> -#define GPIOG_MMIO(0x5028)
> -#define GPIOH_MMIO(0x502c)
> -#define GPIOJ_MMIO(0x5034)
> -#define GPIOK_MMIO(0x5038)
> -#define GPIOL_MMIO(0x503C)
> -#define GPIOM_MMIO(0x5040)
> +#define GPIO(gpio) _MMIO(dev_priv->gpio_mmio_base + 0x5010 + \
> + 4 * (gpio))
> +
> # define GPIO_CLOCK_DIR_MASK (1 << 0)
> # define GPIO_CLOCK_DIR_IN (0 << 1)
> # define GPIO_CLOCK_DIR_OUT (1 << 1)
> @@ -7574,6 +7565,8 @@ enum {
>
> /* PCH */
>
> +#define PCH_DISPLAY_BASE 0xcu
> +
> /* south display engine interrupt: IBX */
> #define SDE_AUDIO_POWER_D(1 << 27)
> #define SDE_AUDIO_POWER_C(1 << 26)
> @@ -7868,13 +7861,6 @@ enum {
> #define ICP_TC_HPD_LONG_DETECT(tc_port)(2 << (tc_port) * 4)
> #define ICP_TC_HPD_SHORT_DETECT(tc_port) (1 << (tc_port) * 4)
>
> -#define PCH_GPIOA _MMIO(0xc5010)
> -#define PCH_GPIOB _MMIO(0xc5014)
> -#define PCH_GPIOC _MMIO(0xc5018)
> -#define PCH_GPIOD _MMIO(0xc501c)
> -#define PCH_GPIOE _MMIO(0xc5020)
> -#define PCH_GPIOF _MMIO(0xc5024)
> -
> #define _PCH_DPLL_A 0xc6014
> #define _PCH_DPLL_B 0xc6018
> #define PCH_DPLL(pll) _MMIO((pll) == 0 ? _PCH_DPLL_A : _PCH_DPLL_B)
> diff --git a/drivers/gpu/drm/i915/intel_display.h
> b/drivers/gpu/drm/i915/intel_display.h
> index 0a79a46d5805..e7f49f107e57 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -25,6 +25,22 @@
> #ifndef _INTEL_DISPLAY_H_
> #define _INTEL_DISPLAY_H_
>
> +enum i915_gpio {
> + GPIOA,
> + GPIOB,
> + GPIOC,
> + GPIOD,
> + GPIOE,
> + GPIOF,
> + GPIOG,
> + GPIOH,
> + __GPIOI_UNUSED,
> + GPIOJ,
> + GPIOK,
> + GPIOL,
> + GPIOM,
> +};
> +
> enum pipe {
> INVALID_PIPE = -1,
>
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index bef32b7c248e..33d87ab93fdd 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +
[Intel-gfx] [PATCH libdrm 1/4] intel: add IS_GENX() generic macro
This will allow platforms to reuse kernel IDs instead of manually
keeping them in sync. In most of the cases we only need to extend
IS_9XX(). Current platforms that fit this requirement can be ported
over to use this macro.
The i915_pciids.h header is in sync with kernel tree on
drm-tip 2018y-08m-20d-21h-41m-11s.
Signed-off-by: Lucas De Marchi
---
intel/i915_pciids.h | 461 ++
intel/intel_chipset.h | 20 ++
2 files changed, 481 insertions(+)
create mode 100644 intel/i915_pciids.h
diff --git a/intel/i915_pciids.h b/intel/i915_pciids.h
new file mode 100644
index ..fd965ffb
--- /dev/null
+++ b/intel/i915_pciids.h
@@ -0,0 +1,461 @@
+/*
+ * Copyright 2013 Intel Corporation
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+#ifndef _I915_PCIIDS_H
+#define _I915_PCIIDS_H
+
+/*
+ * A pci_device_id struct {
+ * __u32 vendor, device;
+ * __u32 subvendor, subdevice;
+ * __u32 class, class_mask;
+ * kernel_ulong_t driver_data;
+ * };
+ * Don't use C99 here because "class" is reserved and we want to
+ * give userspace flexibility.
+ */
+#define INTEL_VGA_DEVICE(id, info) { \
+ 0x8086, id, \
+ ~0, ~0, \
+ 0x03, 0xff, \
+ (unsigned long) info }
+
+#define INTEL_QUANTA_VGA_DEVICE(info) {\
+ 0x8086, 0x16a, \
+ 0x152d, 0x8990, \
+ 0x03, 0xff, \
+ (unsigned long) info }
+
+#define INTEL_I810_IDS(info) \
+ INTEL_VGA_DEVICE(0x7121, info), /* I810 */ \
+ INTEL_VGA_DEVICE(0x7123, info), /* I810_DC100 */\
+ INTEL_VGA_DEVICE(0x7125, info) /* I810_E */
+
+#define INTEL_I815_IDS(info) \
+ INTEL_VGA_DEVICE(0x1132, info) /* I815*/
+
+#define INTEL_I830_IDS(info) \
+ INTEL_VGA_DEVICE(0x3577, info)
+
+#define INTEL_I845G_IDS(info) \
+ INTEL_VGA_DEVICE(0x2562, info)
+
+#define INTEL_I85X_IDS(info) \
+ INTEL_VGA_DEVICE(0x3582, info), /* I855_GM */ \
+ INTEL_VGA_DEVICE(0x358e, info)
+
+#define INTEL_I865G_IDS(info) \
+ INTEL_VGA_DEVICE(0x2572, info) /* I865_G */
+
+#define INTEL_I915G_IDS(info) \
+ INTEL_VGA_DEVICE(0x2582, info), /* I915_G */ \
+ INTEL_VGA_DEVICE(0x258a, info) /* E7221_G */
+
+#define INTEL_I915GM_IDS(info) \
+ INTEL_VGA_DEVICE(0x2592, info) /* I915_GM */
+
+#define INTEL_I945G_IDS(info) \
+ INTEL_VGA_DEVICE(0x2772, info) /* I945_G */
+
+#define INTEL_I945GM_IDS(info) \
+ INTEL_VGA_DEVICE(0x27a2, info), /* I945_GM */ \
+ INTEL_VGA_DEVICE(0x27ae, info) /* I945_GME */
+
+#define INTEL_I965G_IDS(info) \
+ INTEL_VGA_DEVICE(0x2972, info), /* I946_GZ */ \
+ INTEL_VGA_DEVICE(0x2982, info), /* G35_G */ \
+ INTEL_VGA_DEVICE(0x2992, info), /* I965_Q */\
+ INTEL_VGA_DEVICE(0x29a2, info) /* I965_G */
+
+#define INTEL_G33_IDS(info)\
+ INTEL_VGA_DEVICE(0x29b2, info), /* Q35_G */ \
+ INTEL_VGA_DEVICE(0x29c2, info), /* G33_G */ \
+ INTEL_VGA_DEVICE(0x29d2, info) /* Q33_G */
+
+#define INTEL_I965GM_IDS(info) \
+ INTEL_VGA_DEVICE(0x2a02, info), /* I965_GM */ \
+ INTEL_VGA_DEVICE(0x2a12, info) /* I965_GME */
+
+#define INTEL_GM45_IDS(info) \
+ INTEL_VGA_DEVICE(0x2a42, info) /* GM45_G */
+
+#define INTEL_G45_IDS(info)\
+
[Intel-gfx] [PATCH libdrm 3/4] intel: make gen10 use generic gen macro
Signed-off-by: Lucas De Marchi
---
intel/intel_chipset.h | 33 +
1 file changed, 1 insertion(+), 32 deletions(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 163fb536..82f3b5a0 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -246,21 +246,6 @@
#define PCI_CHIP_WHISKEYLAKE_U_GT3_2 0x3EA3
#define PCI_CHIP_WHISKEYLAKE_U_GT3_3 0x3EA4
-#define PCI_CHIP_CANNONLAKE_0 0x5A51
-#define PCI_CHIP_CANNONLAKE_1 0x5A59
-#define PCI_CHIP_CANNONLAKE_2 0x5A41
-#define PCI_CHIP_CANNONLAKE_3 0x5A49
-#define PCI_CHIP_CANNONLAKE_4 0x5A52
-#define PCI_CHIP_CANNONLAKE_5 0x5A5A
-#define PCI_CHIP_CANNONLAKE_6 0x5A42
-#define PCI_CHIP_CANNONLAKE_7 0x5A4A
-#define PCI_CHIP_CANNONLAKE_8 0x5A50
-#define PCI_CHIP_CANNONLAKE_9 0x5A40
-#define PCI_CHIP_CANNONLAKE_10 0x5A54
-#define PCI_CHIP_CANNONLAKE_11 0x5A5C
-#define PCI_CHIP_CANNONLAKE_12 0x5A44
-#define PCI_CHIP_CANNONLAKE_13 0x5A4C
-
#define IS_MOBILE(devid) ((devid) == PCI_CHIP_I855_GM || \
(devid) == PCI_CHIP_I915_GM || \
(devid) == PCI_CHIP_I945_GM || \
@@ -527,23 +512,6 @@
IS_GEMINILAKE(devid) || \
IS_COFFEELAKE(devid))
-#define IS_CANNONLAKE(devid) ((devid) == PCI_CHIP_CANNONLAKE_0 || \
-(devid) == PCI_CHIP_CANNONLAKE_1 || \
-(devid) == PCI_CHIP_CANNONLAKE_2 || \
-(devid) == PCI_CHIP_CANNONLAKE_3 || \
-(devid) == PCI_CHIP_CANNONLAKE_4 || \
-(devid) == PCI_CHIP_CANNONLAKE_5 || \
-(devid) == PCI_CHIP_CANNONLAKE_6 || \
-(devid) == PCI_CHIP_CANNONLAKE_7 || \
-(devid) == PCI_CHIP_CANNONLAKE_8 || \
-(devid) == PCI_CHIP_CANNONLAKE_9 || \
-(devid) == PCI_CHIP_CANNONLAKE_10 || \
-(devid) == PCI_CHIP_CANNONLAKE_11 || \
-(devid) == PCI_CHIP_CANNONLAKE_12 || \
-(devid) == PCI_CHIP_CANNONLAKE_13)
-
-#define IS_GEN10(devid)(IS_CANNONLAKE(devid))
-
/* New platforms use kernel pci ids */
#include "i915_pciids.h"
@@ -563,6 +531,7 @@ struct pci_device_id {
break; \
__i < __n;})
+#define IS_GEN10(devid) IS_GENX(CNL, devid)
#define IS_GEN11(devid) IS_GENX(ICL_11, devid)
/* all platforms */
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH libdrm 4/4] intel: make gen9 use generic gen macro
The 2 PCI IDs that are used for the command line overrid mechanism were left defined. The rest can be gone and then we just use the kernel defines. Signed-off-by: Lucas De Marchi --- intel/intel_chipset.h | 188 +- 1 file changed, 3 insertions(+), 185 deletions(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index 82f3b5a0..6887605e 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -165,86 +165,8 @@ #define PCI_CHIP_CHERRYVIEW_2 0x22b2 #define PCI_CHIP_CHERRYVIEW_3 0x22b3 -#define PCI_CHIP_SKYLAKE_DT_GT10x1902 -#define PCI_CHIP_SKYLAKE_ULT_GT1 0x1906 -#define PCI_CHIP_SKYLAKE_SRV_GT1 0x190A /* Reserved */ -#define PCI_CHIP_SKYLAKE_H_GT1 0x190B -#define PCI_CHIP_SKYLAKE_ULX_GT1 0x190E /* Reserved */ #define PCI_CHIP_SKYLAKE_DT_GT20x1912 -#define PCI_CHIP_SKYLAKE_FUSED0_GT20x1913 /* Reserved */ -#define PCI_CHIP_SKYLAKE_FUSED1_GT20x1915 /* Reserved */ -#define PCI_CHIP_SKYLAKE_ULT_GT2 0x1916 -#define PCI_CHIP_SKYLAKE_FUSED2_GT20x1917 /* Reserved */ -#define PCI_CHIP_SKYLAKE_SRV_GT2 0x191A /* Reserved */ -#define PCI_CHIP_SKYLAKE_HALO_GT2 0x191B -#define PCI_CHIP_SKYLAKE_WKS_GT2 0x191D -#define PCI_CHIP_SKYLAKE_ULX_GT2 0x191E -#define PCI_CHIP_SKYLAKE_MOBILE_GT20x1921 /* Reserved */ -#define PCI_CHIP_SKYLAKE_ULT_GT3_0 0x1923 -#define PCI_CHIP_SKYLAKE_ULT_GT3_1 0x1926 -#define PCI_CHIP_SKYLAKE_ULT_GT3_2 0x1927 -#define PCI_CHIP_SKYLAKE_SRV_GT4 0x192A -#define PCI_CHIP_SKYLAKE_HALO_GT3 0x192B /* Reserved */ -#define PCI_CHIP_SKYLAKE_SRV_GT3 0x192D -#define PCI_CHIP_SKYLAKE_DT_GT40x1932 -#define PCI_CHIP_SKYLAKE_SRV_GT4X 0x193A -#define PCI_CHIP_SKYLAKE_H_GT4 0x193B -#define PCI_CHIP_SKYLAKE_WKS_GT4 0x193D - -#define PCI_CHIP_KABYLAKE_ULT_GT2 0x5916 -#define PCI_CHIP_KABYLAKE_ULT_GT1_50x5913 -#define PCI_CHIP_KABYLAKE_ULT_GT1 0x5906 -#define PCI_CHIP_KABYLAKE_ULT_GT3_00x5923 -#define PCI_CHIP_KABYLAKE_ULT_GT3_10x5926 -#define PCI_CHIP_KABYLAKE_ULT_GT3_20x5927 -#define PCI_CHIP_KABYLAKE_ULT_GT2F 0x5921 -#define PCI_CHIP_KABYLAKE_ULX_GT1_50x5915 -#define PCI_CHIP_KABYLAKE_ULX_GT1 0x590E -#define PCI_CHIP_KABYLAKE_ULX_GT2_00x591E #define PCI_CHIP_KABYLAKE_DT_GT2 0x5912 -#define PCI_CHIP_KABYLAKE_M_GT20x5917 -#define PCI_CHIP_KABYLAKE_DT_GT1 0x5902 -#define PCI_CHIP_KABYLAKE_HALO_GT2 0x591B -#define PCI_CHIP_KABYLAKE_HALO_GT4 0x593B -#define PCI_CHIP_KABYLAKE_HALO_GT1_0 0x5908 -#define PCI_CHIP_KABYLAKE_HALO_GT1_1 0x590B -#define PCI_CHIP_KABYLAKE_SRV_GT2 0x591A -#define PCI_CHIP_KABYLAKE_SRV_GT1 0x590A -#define PCI_CHIP_KABYLAKE_WKS_GT2 0x591D - -#define PCI_CHIP_AMBERLAKE_ULX_GT2_1 0x591C -#define PCI_CHIP_AMBERLAKE_ULX_GT2_2 0x87C0 - -#define PCI_CHIP_BROXTON_0 0x0A84 -#define PCI_CHIP_BROXTON_1 0x1A84 -#define PCI_CHIP_BROXTON_2 0x5A84 -#define PCI_CHIP_BROXTON_3 0x1A85 -#define PCI_CHIP_BROXTON_4 0x5A85 - -#define PCI_CHIP_GLK 0x3184 -#define PCI_CHIP_GLK_2X6 0x3185 - -#define PCI_CHIP_COFFEELAKE_S_GT1_1 0x3E90 -#define PCI_CHIP_COFFEELAKE_S_GT1_2 0x3E93 -#define PCI_CHIP_COFFEELAKE_S_GT1_3 0x3E99 -#define PCI_CHIP_COFFEELAKE_S_GT2_1 0x3E91 -#define PCI_CHIP_COFFEELAKE_S_GT2_2 0x3E92 -#define PCI_CHIP_COFFEELAKE_S_GT2_3 0x3E96 -#define PCI_CHIP_COFFEELAKE_S_GT2_4 0x3E98 -#define PCI_CHIP_COFFEELAKE_S_GT2_5 0x3E9A -#define PCI_CHIP_COFFEELAKE_H_GT2_1 0x3E9B -#define PCI_CHIP_COFFEELAKE_H_GT2_2 0x3E94 -#define PCI_CHIP_COFFEELAKE_U_GT2_1 0x3EA9 -#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA5 -#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA6 -#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7 -#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8 - -#define PCI_CHIP_WHISKEYLAKE_U_GT1_1 0x3EA1 -#define PCI_CHIP_WHISKEYLAKE_U_GT2_1 0x3EA0 -#define PCI_CHIP_WHISKEYLAKE_U_GT3_1 0x3EA2 -#define PCI_CHIP_WHISKEYLAKE_U_GT3_2 0x3EA3 -#define PCI_CHIP_WHISKEYLAKE_U_GT3_3 0x3EA4 #define IS_MOBILE(devid) ((devid) == PCI_CHIP_I855_GM || \ (devid) == PCI_CHIP_I915_GM || \ @@ -405,113 +327,6 @@ #define IS_GEN8(devid) (IS_BROADWELL(devid) || \ IS_CHERRYVIEW(devid)) -#define IS_SKL_GT1(devid) ((devid) == PCI_CHIP_SKYLAKE_DT_GT1 || \ -(devid) == PCI_CHIP_SKYLAKE_ULT_GT1|| \ -(devid) == PCI_CHIP_SKYLAKE_SRV_GT1|| \ -(devid) == PCI_CHIP_SKYLAKE_H_GT1 || \ -(devid) == PCI_CHIP_SKYLAKE_ULX_GT1) - -#define IS_SKL_GT2(devid) ((devid) == PCI_CHIP_SKYLAKE_DT_GT2
[Intel-gfx] [PATCH libdrm 2/4] intel: make gen11 use generic gen macro
Signed-off-by: Lucas De Marchi
---
intel/intel_chipset.h | 26 ++
1 file changed, 2 insertions(+), 24 deletions(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 8a0e3e76..163fb536 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -261,16 +261,6 @@
#define PCI_CHIP_CANNONLAKE_12 0x5A44
#define PCI_CHIP_CANNONLAKE_13 0x5A4C
-#define PCI_CHIP_ICELAKE_11_0 0x8A50
-#define PCI_CHIP_ICELAKE_11_1 0x8A51
-#define PCI_CHIP_ICELAKE_11_2 0x8A5C
-#define PCI_CHIP_ICELAKE_11_3 0x8A5D
-#define PCI_CHIP_ICELAKE_11_4 0x8A52
-#define PCI_CHIP_ICELAKE_11_5 0x8A5A
-#define PCI_CHIP_ICELAKE_11_6 0x8A5B
-#define PCI_CHIP_ICELAKE_11_7 0x8A71
-#define PCI_CHIP_ICELAKE_11_8 0x8A70
-
#define IS_MOBILE(devid) ((devid) == PCI_CHIP_I855_GM || \
(devid) == PCI_CHIP_I915_GM || \
(devid) == PCI_CHIP_I945_GM || \
@@ -554,20 +544,6 @@
#define IS_GEN10(devid)(IS_CANNONLAKE(devid))
-#define IS_ICELAKE_11(devid) ((devid) == PCI_CHIP_ICELAKE_11_0 || \
-(devid) == PCI_CHIP_ICELAKE_11_1 || \
-(devid) == PCI_CHIP_ICELAKE_11_2 || \
-(devid) == PCI_CHIP_ICELAKE_11_3 || \
-(devid) == PCI_CHIP_ICELAKE_11_4 || \
-(devid) == PCI_CHIP_ICELAKE_11_5 || \
-(devid) == PCI_CHIP_ICELAKE_11_6 || \
-(devid) == PCI_CHIP_ICELAKE_11_7 || \
-(devid) == PCI_CHIP_ICELAKE_11_8)
-
-#define IS_ICELAKE(devid) (IS_ICELAKE_11(devid))
-
-#define IS_GEN11(devid)(IS_ICELAKE_11(devid))
-
/* New platforms use kernel pci ids */
#include "i915_pciids.h"
@@ -587,6 +563,8 @@ struct pci_device_id {
break; \
__i < __n;})
+#define IS_GEN11(devid) IS_GENX(ICL_11, devid)
+
/* all platforms */
#define IS_9XX(dev)(IS_GEN3(dev) || \
IS_GEN4(dev) || \
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH libdrm 0/4] intel: rework how we add PCI IDs
Adding PCI IDs to different projects is a boring manual task that motivated me to create this series. The idea is to centralize the IDs in the kernel header and let other projects copy it. Initially my plan was to convert all gens, back to gen2, but that proved slightly difficult since there are some corner cases to cover and I didn't want to block the important part, i.e.: for recent gens, there's no risk of missing a PCI ID. It does increase the size a little bit, but doesn't explode. Size diff below showing ~3k: - 36533176 40 367498f8d build/intel/intel@@drm_intel@sha/intel_bufmgr_gem.c.o - 66237 1384 24 67645 1083d build/intel/intel@@drm_intel@sha/intel_decode.c.o + 39362176 40 395789a9a build/intel/intel@@drm_intel@sha/intel_bufmgr_gem.c.o + 68935 1384 24 70343 112c7 build/intel/intel@@drm_intel@sha/intel_decode.c.o Let me know what you think. Lucas De Marchi (4): intel: add IS_GENX() generic macro intel: make gen11 use generic gen macro intel: make gen10 use generic gen macro intel: make gen9 use generic gen macro intel/i915_pciids.h | 461 ++ intel/intel_chipset.h | 267 +++- 2 files changed, 487 insertions(+), 241 deletions(-) create mode 100644 intel/i915_pciids.h -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm 1/4] intel: add IS_GENX() generic macro
On Tue, Aug 28, 2018 at 09:38:59AM +0100, Chris Wilson wrote:
> Quoting Lucas De Marchi (2018-08-28 02:00:27)
> > On Sat, Aug 25, 2018 at 10:35:23AM +0100, Chris Wilson wrote:
> > > Quoting Lucas De Marchi (2018-08-25 00:56:46)
> > > > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> > > > index 4a34b7be..8a0e3e76 100644
> > > > --- a/intel/intel_chipset.h
> > > > +++ b/intel/intel_chipset.h
> > > > @@ -568,6 +568,26 @@
> > > >
> > > > #define IS_GEN11(devid)(IS_ICELAKE_11(devid))
> > > >
> > > > +/* New platforms use kernel pci ids */
> > > > +#include "i915_pciids.h"
> > > > +
> > > > +struct pci_device_id {
> > >
> > > Don't call it pci_device_id, depending on caller that name may already
> > > be taken by libpciaccess.
> > >
> > > > + uint32_t unused0, device;
> > > > + uint32_t unused1, unused2;
> > > > + uint32_t unused3, unused4;
> > > These are all uint16_t.
> >
> > more on this:
> >
> > I can make the first 2 uint16_t, but not the rest due to the way they
> > are declared in INTEL_VGA_DEVICE: (~0 has int type by default), unused3
> > and unused4 are clearly not uint16_t
>
> I had it in my mind that we did have one extra level of macro in there
> that would allow us to drop unused fields. We could redef
we don't have right now, that needs to be added. And for any extra level
of macro we need to redef INTEL_VGA_DEVICE nonetheless because it
expands to "{ ... }". I don't know any cpp trick to remove the extra
fields if it keeps the braces.
> INTEL_VGA_DEVICE() and INTEL_QUANTA_VGA_DEVICE() but one extra level of
> macro would be easier for future.
So... I don't see a way out except to redef it. This works today for
libdrm (on top of my unsent version of this patch):
[ NO CI ] diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
[ NO CI ] index 79581819..8ea24194 100644
[ NO CI ] --- a/intel/intel_chipset.c
[ NO CI ] +++ b/intel/intel_chipset.c
@@ -27,11 +27,12 @@
#include "i915_pciids.h"
+#undef INTEL_VGA_DEVICE
+#define INTEL_VGA_DEVICE(id, gen) { id, gen }
+
static const struct pci_device {
- uint16_t unused0, device;
- uint32_t unused1, unused2;
- uint32_t unused3, unused4;
- int gen;
+ uint16_t device;
+ uint16_t gen;
} pciids[] = {
INTEL_ICL_11_IDS(11),
INTEL_CNL_IDS(10),
>
> And then while you are there, add the missing 'u' to ~0u
> -Chris.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: reword documentation of possible pci_device_id struct
On Tue, Aug 28, 2018 at 07:05:46PM +0100, Chris Wilson wrote: > Quoting Lucas De Marchi (2018-08-28 18:41:46) > > Document it like a real struct for ease of copy and paste, remove > > comment of C99 compatibility and document that in some cases the first 2 > > I do recall that we couldn't use either C99 or class due to userspace you can't actually use a c++ compiler. For C it works with any of -std=c99, gnu99, c11, gnu11, c17, gnu17. Tested with both gcc and clang. I've never heard of class being a reserved keyword and section 6.4.5 of said standard doesn't list it neither. Here the struct definition is in a *comment*... i.e. the user will copy and paste somewhere else and probably change __u16 to uint16_t in userspace. If he's building with g++, he can name the field to something else. If it was something we were defining in this header than I would agree with you... to retain compatibility with c++, not c99. Lucas De Marchi > compatibility... The essence is that we need a reminder that we can't > assume the relaxed nature of kcc here. > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: make field unsigned
subvendor and subdevice are unsigned, so fix their initialization in
INTEL_VGA_DEVICE.
Cc: Chris Wilson
Signed-off-by: Lucas De Marchi
---
include/drm/i915_pciids.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index fd965ffbb92e..754ce4b10129 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -37,7 +37,7 @@
*/
#define INTEL_VGA_DEVICE(id, info) { \
0x8086, id, \
- ~0, ~0, \
+ ~0u, ~0u, \
0x03, 0xff, \
(unsigned long) info }
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: reword documentation of possible pci_device_id struct
Document it like a real struct for ease of copy and paste, remove
comment of C99 compatibility and document that in some cases the first 2
fields can be u16.
Cc: Chris Wilson
Signed-off-by: Lucas De Marchi
---
include/drm/i915_pciids.h | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 754ce4b10129..0c2cc43f916c 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -26,14 +26,16 @@
#define _I915_PCIIDS_H
/*
- * A pci_device_id struct {
- * __u32 vendor, device;
- * __u32 subvendor, subdevice;
- * __u32 class, class_mask;
- * kernel_ulong_t driver_data;
+ * These macros can be used with a struct declared like this:
+ *
+ * struct pci_device_id {
+ * __u32 vendor, device;
+ * __u32 subvendor, subdevice;
+ * __u32 class, class_mask;
+ * kernel_ulong_t driver_data;
* };
- * Don't use C99 here because "class" is reserved and we want to
- * give userspace flexibility.
+ *
+ * First two fields may be __u16 if PCI_DEVICE_ANY is not used
*/
#define INTEL_VGA_DEVICE(id, info) { \
0x8086, id, \
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: reword documentation of possible pci_device_id struct
On Tue, Aug 28, 2018 at 09:06:15PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 28, 2018 at 10:41:46AM -0700, Lucas De Marchi wrote:
> > Document it like a real struct for ease of copy and paste, remove
> > comment of C99 compatibility and document that in some cases the first 2
> > fields can be u16.
> >
> > Cc: Chris Wilson
> > Signed-off-by: Lucas De Marchi
> > ---
> > include/drm/i915_pciids.h | 16 +---
> > 1 file changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> > index 754ce4b10129..0c2cc43f916c 100644
> > --- a/include/drm/i915_pciids.h
> > +++ b/include/drm/i915_pciids.h
> > @@ -26,14 +26,16 @@
> > #define _I915_PCIIDS_H
> >
> > /*
> > - * A pci_device_id struct {
> > - * __u32 vendor, device;
> > - * __u32 subvendor, subdevice;
> > - * __u32 class, class_mask;
> > - * kernel_ulong_t driver_data;
> > + * These macros can be used with a struct declared like this:
> > + *
> > + * struct pci_device_id {
> > + * __u32 vendor, device;
> > + * __u32 subvendor, subdevice;
> > + * __u32 class, class_mask;
> > + * kernel_ulong_t driver_data;
> > * };
> > - * Don't use C99 here because "class" is reserved and we want to
> > - * give userspace flexibility.
> > + *
> > + * First two fields may be __u16 if PCI_DEVICE_ANY is not used
>
> PCI_DEVICE_ANY undefined?
this should be PCI_ANY_ID, but now I'm not sure if I should even mention
it since it's defined somewhere that's private to kernel.
>
> Also you can surely use u16 just fine as long as you're careful when
> comparing with ~0?
nops, since ~0u is unsigned int (~0 being int before patch 1), it will
overflow and cause a warning due to -Woverflow. This is what happens in
igt if I do what you said:
../intel/i915_pciids.h:40:2: warning: conversion from ‘unsigned int’ to ‘short
unsigned int’ changes value from ‘4294967295’ to ‘65535’ [-Woverflow]
~0u, ~0u,\
^
Lucas De Marchi
>
> > */
> > #define INTEL_VGA_DEVICE(id, info) { \
> > 0x8086, id, \
> > --
> > 2.17.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH libdrm v2 5/5] intel: get gen once for gen >= 9
We don't need to call IS_GEN() for each gen >= 9: we can rather use the
new intel_is_genx() helper to iterate the pciids array once.
Signed-off-by: Lucas De Marchi
---
intel/intel_bufmgr_gem.c | 8 +---
intel/intel_decode.c | 8 ++--
2 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 8c3a4b20..d6587b76 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3656,13 +3656,7 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
bufmgr_gem->gen = 7;
else if (IS_GEN8(bufmgr_gem->pci_device))
bufmgr_gem->gen = 8;
- else if (IS_GEN9(bufmgr_gem->pci_device))
- bufmgr_gem->gen = 9;
- else if (IS_GEN10(bufmgr_gem->pci_device))
- bufmgr_gem->gen = 10;
- else if (IS_GEN11(bufmgr_gem->pci_device))
- bufmgr_gem->gen = 11;
- else {
+ else if (!intel_get_genx(bufmgr_gem->pci_device, _gem->gen)) {
free(bufmgr_gem);
bufmgr_gem = NULL;
goto exit;
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index b24861b1..0ff095bc 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -3823,12 +3823,8 @@ drm_intel_decode_context_alloc(uint32_t devid)
ctx->devid = devid;
ctx->out = stdout;
- if (IS_GEN11(devid))
- ctx->gen = 11;
- else if (IS_GEN10(devid))
- ctx->gen = 10;
- else if (IS_GEN9(devid))
- ctx->gen = 9;
+ if (intel_get_genx(devid, >gen))
+ ;
else if (IS_GEN8(devid))
ctx->gen = 8;
else if (IS_GEN7(devid))
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH libdrm v2 1/5] intel: add generic functions to check PCI ID
This will allow platforms to reuse kernel IDs instead of manually
keeping them in sync. In most of the cases we only need to extend
IS_9XX(). Current platforms that fit this requirement can be ported
over to use this macro. Right now it's a nop since it doesn't have any
PCI ID added.
The i915_pciids.h header is in sync with kernel tree on
drm-tip 2018y-08m-20d-21h-41m-11s.
v2: - move to a separate .c so we can have the array in a single
compilation unit
- use a single array for all gens
- add real functions to get or check gen by pciid
- define our own pci device struct rather than inherit the one
kernel uses: we can throw away most of the fields
Cc: Chris Wilson
Signed-off-by: Lucas De Marchi
---
intel/Makefile.sources | 1 +
intel/i915_pciids.h| 461 +
intel/intel_chipset.c | 77 +++
intel/intel_chipset.h | 10 +-
intel/meson.build | 2 +-
5 files changed, 549 insertions(+), 2 deletions(-)
create mode 100644 intel/i915_pciids.h
create mode 100644 intel/intel_chipset.c
diff --git a/intel/Makefile.sources b/intel/Makefile.sources
index 6947ab74..61f43aeb 100644
--- a/intel/Makefile.sources
+++ b/intel/Makefile.sources
@@ -5,6 +5,7 @@ LIBDRM_INTEL_FILES := \
intel_bufmgr_gem.c \
intel_decode.c \
intel_chipset.h \
+ intel_chipset.c \
mm.c \
mm.h \
uthash.h
diff --git a/intel/i915_pciids.h b/intel/i915_pciids.h
new file mode 100644
index ..fd965ffb
--- /dev/null
+++ b/intel/i915_pciids.h
@@ -0,0 +1,461 @@
+/*
+ * Copyright 2013 Intel Corporation
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+#ifndef _I915_PCIIDS_H
+#define _I915_PCIIDS_H
+
+/*
+ * A pci_device_id struct {
+ * __u32 vendor, device;
+ * __u32 subvendor, subdevice;
+ * __u32 class, class_mask;
+ * kernel_ulong_t driver_data;
+ * };
+ * Don't use C99 here because "class" is reserved and we want to
+ * give userspace flexibility.
+ */
+#define INTEL_VGA_DEVICE(id, info) { \
+ 0x8086, id, \
+ ~0, ~0, \
+ 0x03, 0xff, \
+ (unsigned long) info }
+
+#define INTEL_QUANTA_VGA_DEVICE(info) {\
+ 0x8086, 0x16a, \
+ 0x152d, 0x8990, \
+ 0x03, 0xff, \
+ (unsigned long) info }
+
+#define INTEL_I810_IDS(info) \
+ INTEL_VGA_DEVICE(0x7121, info), /* I810 */ \
+ INTEL_VGA_DEVICE(0x7123, info), /* I810_DC100 */\
+ INTEL_VGA_DEVICE(0x7125, info) /* I810_E */
+
+#define INTEL_I815_IDS(info) \
+ INTEL_VGA_DEVICE(0x1132, info) /* I815*/
+
+#define INTEL_I830_IDS(info) \
+ INTEL_VGA_DEVICE(0x3577, info)
+
+#define INTEL_I845G_IDS(info) \
+ INTEL_VGA_DEVICE(0x2562, info)
+
+#define INTEL_I85X_IDS(info) \
+ INTEL_VGA_DEVICE(0x3582, info), /* I855_GM */ \
+ INTEL_VGA_DEVICE(0x358e, info)
+
+#define INTEL_I865G_IDS(info) \
+ INTEL_VGA_DEVICE(0x2572, info) /* I865_G */
+
+#define INTEL_I915G_IDS(info) \
+ INTEL_VGA_DEVICE(0x2582, info), /* I915_G */ \
+ INTEL_VGA_DEVICE(0x258a, info) /* E7221_G */
+
+#define INTEL_I915GM_IDS(info) \
+ INTEL_VGA_DEVICE(0x2592, info) /* I915_GM */
+
+#define INTEL_I945G_IDS(info) \
+ INTEL_VGA_DEVICE(0x2772, info) /* I945_G */
+
+#define INTEL_I945GM_IDS(info) \
+ INTEL_VGA_DEVICE(0x27a2, info), /* I945_GM */ \
+ INTEL_VGA_DEV
[Intel-gfx] [PATCH libdrm v2 4/5] intel: make gen9 use generic gen macro
The 2 PCI IDs that are used for the command line overrid mechanism
were left defined. The rest can be gone and then we just use the kernel
defines.
Signed-off-by: Lucas De Marchi
---
intel/intel_chipset.c | 5 ++
intel/intel_chipset.h | 187 +-
2 files changed, 6 insertions(+), 186 deletions(-)
diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
index 0c2ba884..c984d8ac 100644
--- a/intel/intel_chipset.c
+++ b/intel/intel_chipset.c
@@ -36,6 +36,11 @@ static const struct pci_device {
} pciids[] = {
INTEL_ICL_11_IDS(11),
INTEL_CNL_IDS(10),
+ INTEL_CFL_IDS(9),
+ INTEL_GLK_IDS(9),
+ INTEL_KBL_IDS(9),
+ INTEL_BXT_IDS(9),
+ INTEL_SKL_IDS(9),
};
bool intel_is_genx(unsigned int devid, int gen)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 6790f728..19263e19 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -165,86 +165,8 @@
#define PCI_CHIP_CHERRYVIEW_2 0x22b2
#define PCI_CHIP_CHERRYVIEW_3 0x22b3
-#define PCI_CHIP_SKYLAKE_DT_GT10x1902
-#define PCI_CHIP_SKYLAKE_ULT_GT1 0x1906
-#define PCI_CHIP_SKYLAKE_SRV_GT1 0x190A /* Reserved */
-#define PCI_CHIP_SKYLAKE_H_GT1 0x190B
-#define PCI_CHIP_SKYLAKE_ULX_GT1 0x190E /* Reserved */
#define PCI_CHIP_SKYLAKE_DT_GT20x1912
-#define PCI_CHIP_SKYLAKE_FUSED0_GT20x1913 /* Reserved */
-#define PCI_CHIP_SKYLAKE_FUSED1_GT20x1915 /* Reserved */
-#define PCI_CHIP_SKYLAKE_ULT_GT2 0x1916
-#define PCI_CHIP_SKYLAKE_FUSED2_GT20x1917 /* Reserved */
-#define PCI_CHIP_SKYLAKE_SRV_GT2 0x191A /* Reserved */
-#define PCI_CHIP_SKYLAKE_HALO_GT2 0x191B
-#define PCI_CHIP_SKYLAKE_WKS_GT2 0x191D
-#define PCI_CHIP_SKYLAKE_ULX_GT2 0x191E
-#define PCI_CHIP_SKYLAKE_MOBILE_GT20x1921 /* Reserved */
-#define PCI_CHIP_SKYLAKE_ULT_GT3_0 0x1923
-#define PCI_CHIP_SKYLAKE_ULT_GT3_1 0x1926
-#define PCI_CHIP_SKYLAKE_ULT_GT3_2 0x1927
-#define PCI_CHIP_SKYLAKE_SRV_GT4 0x192A
-#define PCI_CHIP_SKYLAKE_HALO_GT3 0x192B /* Reserved */
-#define PCI_CHIP_SKYLAKE_SRV_GT3 0x192D
-#define PCI_CHIP_SKYLAKE_DT_GT40x1932
-#define PCI_CHIP_SKYLAKE_SRV_GT4X 0x193A
-#define PCI_CHIP_SKYLAKE_H_GT4 0x193B
-#define PCI_CHIP_SKYLAKE_WKS_GT4 0x193D
-
-#define PCI_CHIP_KABYLAKE_ULT_GT2 0x5916
-#define PCI_CHIP_KABYLAKE_ULT_GT1_50x5913
-#define PCI_CHIP_KABYLAKE_ULT_GT1 0x5906
-#define PCI_CHIP_KABYLAKE_ULT_GT3_00x5923
-#define PCI_CHIP_KABYLAKE_ULT_GT3_10x5926
-#define PCI_CHIP_KABYLAKE_ULT_GT3_20x5927
-#define PCI_CHIP_KABYLAKE_ULT_GT2F 0x5921
-#define PCI_CHIP_KABYLAKE_ULX_GT1_50x5915
-#define PCI_CHIP_KABYLAKE_ULX_GT1 0x590E
-#define PCI_CHIP_KABYLAKE_ULX_GT2_00x591E
#define PCI_CHIP_KABYLAKE_DT_GT2 0x5912
-#define PCI_CHIP_KABYLAKE_M_GT20x5917
-#define PCI_CHIP_KABYLAKE_DT_GT1 0x5902
-#define PCI_CHIP_KABYLAKE_HALO_GT2 0x591B
-#define PCI_CHIP_KABYLAKE_HALO_GT4 0x593B
-#define PCI_CHIP_KABYLAKE_HALO_GT1_0 0x5908
-#define PCI_CHIP_KABYLAKE_HALO_GT1_1 0x590B
-#define PCI_CHIP_KABYLAKE_SRV_GT2 0x591A
-#define PCI_CHIP_KABYLAKE_SRV_GT1 0x590A
-#define PCI_CHIP_KABYLAKE_WKS_GT2 0x591D
-
-#define PCI_CHIP_AMBERLAKE_ULX_GT2_1 0x591C
-#define PCI_CHIP_AMBERLAKE_ULX_GT2_2 0x87C0
-
-#define PCI_CHIP_BROXTON_0 0x0A84
-#define PCI_CHIP_BROXTON_1 0x1A84
-#define PCI_CHIP_BROXTON_2 0x5A84
-#define PCI_CHIP_BROXTON_3 0x1A85
-#define PCI_CHIP_BROXTON_4 0x5A85
-
-#define PCI_CHIP_GLK 0x3184
-#define PCI_CHIP_GLK_2X6 0x3185
-
-#define PCI_CHIP_COFFEELAKE_S_GT1_1 0x3E90
-#define PCI_CHIP_COFFEELAKE_S_GT1_2 0x3E93
-#define PCI_CHIP_COFFEELAKE_S_GT1_3 0x3E99
-#define PCI_CHIP_COFFEELAKE_S_GT2_1 0x3E91
-#define PCI_CHIP_COFFEELAKE_S_GT2_2 0x3E92
-#define PCI_CHIP_COFFEELAKE_S_GT2_3 0x3E96
-#define PCI_CHIP_COFFEELAKE_S_GT2_4 0x3E98
-#define PCI_CHIP_COFFEELAKE_S_GT2_5 0x3E9A
-#define PCI_CHIP_COFFEELAKE_H_GT2_1 0x3E9B
-#define PCI_CHIP_COFFEELAKE_H_GT2_2 0x3E94
-#define PCI_CHIP_COFFEELAKE_U_GT2_1 0x3EA9
-#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA5
-#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA6
-#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7
-#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8
-
-#define PCI_CHIP_WHISKEYLAKE_U_GT1_1 0x3EA1
-#define PCI_CHIP_WHISKEYLAKE_U_GT2_1 0x3EA0
-#define PCI_CHIP_WHISKEYLAKE_U_GT3_1 0x3EA2
-#define PCI_CHIP_WHISKEYLAKE_U_GT3_2 0x3EA3
-#define PCI_CHIP_WHISKEYLAKE_U_GT3_3 0x3EA4
#define IS_MOBILE(devid) ((devid) == PCI_CHIP_I855_GM || \
(devid) == PCI_CHIP_I915_GM || \
@@ -405,119 +327,13 @@
#define IS_GEN8(devid) (IS_BROADWELL(devid) || \
IS_CHERRYVIEW(devid
[Intel-gfx] [PATCH libdrm v2 3/5] intel: make gen10 use generic gen macro
Signed-off-by: Lucas De Marchi
---
intel/intel_chipset.c | 1 +
intel/intel_chipset.h | 34 +-
2 files changed, 2 insertions(+), 33 deletions(-)
diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
index 5a549ba4..0c2ba884 100644
--- a/intel/intel_chipset.c
+++ b/intel/intel_chipset.c
@@ -35,6 +35,7 @@ static const struct pci_device {
uint16_t gen;
} pciids[] = {
INTEL_ICL_11_IDS(11),
+ INTEL_CNL_IDS(10),
};
bool intel_is_genx(unsigned int devid, int gen)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 2bf480d1..6790f728 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -246,21 +246,6 @@
#define PCI_CHIP_WHISKEYLAKE_U_GT3_2 0x3EA3
#define PCI_CHIP_WHISKEYLAKE_U_GT3_3 0x3EA4
-#define PCI_CHIP_CANNONLAKE_0 0x5A51
-#define PCI_CHIP_CANNONLAKE_1 0x5A59
-#define PCI_CHIP_CANNONLAKE_2 0x5A41
-#define PCI_CHIP_CANNONLAKE_3 0x5A49
-#define PCI_CHIP_CANNONLAKE_4 0x5A52
-#define PCI_CHIP_CANNONLAKE_5 0x5A5A
-#define PCI_CHIP_CANNONLAKE_6 0x5A42
-#define PCI_CHIP_CANNONLAKE_7 0x5A4A
-#define PCI_CHIP_CANNONLAKE_8 0x5A50
-#define PCI_CHIP_CANNONLAKE_9 0x5A40
-#define PCI_CHIP_CANNONLAKE_10 0x5A54
-#define PCI_CHIP_CANNONLAKE_11 0x5A5C
-#define PCI_CHIP_CANNONLAKE_12 0x5A44
-#define PCI_CHIP_CANNONLAKE_13 0x5A4C
-
#define IS_MOBILE(devid) ((devid) == PCI_CHIP_I855_GM || \
(devid) == PCI_CHIP_I915_GM || \
(devid) == PCI_CHIP_I945_GM || \
@@ -527,29 +512,13 @@
IS_GEMINILAKE(devid) || \
IS_COFFEELAKE(devid))
-#define IS_CANNONLAKE(devid) ((devid) == PCI_CHIP_CANNONLAKE_0 || \
-(devid) == PCI_CHIP_CANNONLAKE_1 || \
-(devid) == PCI_CHIP_CANNONLAKE_2 || \
-(devid) == PCI_CHIP_CANNONLAKE_3 || \
-(devid) == PCI_CHIP_CANNONLAKE_4 || \
-(devid) == PCI_CHIP_CANNONLAKE_5 || \
-(devid) == PCI_CHIP_CANNONLAKE_6 || \
-(devid) == PCI_CHIP_CANNONLAKE_7 || \
-(devid) == PCI_CHIP_CANNONLAKE_8 || \
-(devid) == PCI_CHIP_CANNONLAKE_9 || \
-(devid) == PCI_CHIP_CANNONLAKE_10 || \
-(devid) == PCI_CHIP_CANNONLAKE_11 || \
-(devid) == PCI_CHIP_CANNONLAKE_12 || \
-(devid) == PCI_CHIP_CANNONLAKE_13)
-
-#define IS_GEN10(devid)(IS_CANNONLAKE(devid))
-
/* New platforms use kernel pci ids */
#include
bool intel_is_genx(unsigned int devid, int gen);
bool intel_get_genx(unsigned int devid, int *gen);
+#define IS_GEN10(devid) intel_is_genx(devid, 10)
#define IS_GEN11(devid) intel_is_genx(devid, 11)
/* all platforms */
@@ -560,7 +529,6 @@ bool intel_get_genx(unsigned int devid, int *gen);
IS_GEN7(dev) || \
IS_GEN8(dev) || \
IS_GEN9(dev) || \
-IS_GEN10(dev) || \
intel_get_genx(dev, NULL))
#endif /* _INTEL_CHIPSET_H */
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH libdrm v2 0/5] intel: rework how we add PCI IDs
Adding PCI IDs to different projects is a boring manual task that motivated me to create this series. The idea is to centralize the IDs in the kernel header and let other projects copy it. Initially my plan was to convert all gens, back to gen2, but that proved slightly difficult since there are some corner cases to cover and I didn't want to block the important part, i.e.: for recent gens, there's no risk of missing a PCI ID. v2: address comments from Chris by pulling it out to a separate .c Lucas De Marchi (5): intel: add generic functions to check PCI ID intel: make gen11 use generic gen macro intel: make gen10 use generic gen macro intel: make gen9 use generic gen macro intel: get gen once for gen >= 9 intel/Makefile.sources | 1 + intel/i915_pciids.h | 461 +++ intel/intel_bufmgr_gem.c | 8 +- intel/intel_chipset.c| 84 +++ intel/intel_chipset.h| 254 + intel/intel_decode.c | 8 +- intel/meson.build| 2 +- 7 files changed, 561 insertions(+), 257 deletions(-) create mode 100644 intel/i915_pciids.h create mode 100644 intel/intel_chipset.c -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH libdrm v2 2/5] intel: make gen11 use generic gen macro
Signed-off-by: Lucas De Marchi
---
intel/intel_chipset.c | 1 +
intel/intel_chipset.h | 27 ++-
2 files changed, 3 insertions(+), 25 deletions(-)
diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
index 8af99ad9..5a549ba4 100644
--- a/intel/intel_chipset.c
+++ b/intel/intel_chipset.c
@@ -34,6 +34,7 @@ static const struct pci_device {
uint16_t device;
uint16_t gen;
} pciids[] = {
+ INTEL_ICL_11_IDS(11),
};
bool intel_is_genx(unsigned int devid, int gen)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 0e14c58f..2bf480d1 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -261,16 +261,6 @@
#define PCI_CHIP_CANNONLAKE_12 0x5A44
#define PCI_CHIP_CANNONLAKE_13 0x5A4C
-#define PCI_CHIP_ICELAKE_11_0 0x8A50
-#define PCI_CHIP_ICELAKE_11_1 0x8A51
-#define PCI_CHIP_ICELAKE_11_2 0x8A5C
-#define PCI_CHIP_ICELAKE_11_3 0x8A5D
-#define PCI_CHIP_ICELAKE_11_4 0x8A52
-#define PCI_CHIP_ICELAKE_11_5 0x8A5A
-#define PCI_CHIP_ICELAKE_11_6 0x8A5B
-#define PCI_CHIP_ICELAKE_11_7 0x8A71
-#define PCI_CHIP_ICELAKE_11_8 0x8A70
-
#define IS_MOBILE(devid) ((devid) == PCI_CHIP_I855_GM || \
(devid) == PCI_CHIP_I915_GM || \
(devid) == PCI_CHIP_I945_GM || \
@@ -554,26 +544,14 @@
#define IS_GEN10(devid)(IS_CANNONLAKE(devid))
-#define IS_ICELAKE_11(devid) ((devid) == PCI_CHIP_ICELAKE_11_0 || \
-(devid) == PCI_CHIP_ICELAKE_11_1 || \
-(devid) == PCI_CHIP_ICELAKE_11_2 || \
-(devid) == PCI_CHIP_ICELAKE_11_3 || \
-(devid) == PCI_CHIP_ICELAKE_11_4 || \
-(devid) == PCI_CHIP_ICELAKE_11_5 || \
-(devid) == PCI_CHIP_ICELAKE_11_6 || \
-(devid) == PCI_CHIP_ICELAKE_11_7 || \
-(devid) == PCI_CHIP_ICELAKE_11_8)
-
-#define IS_ICELAKE(devid) (IS_ICELAKE_11(devid))
-
-#define IS_GEN11(devid)(IS_ICELAKE_11(devid))
-
/* New platforms use kernel pci ids */
#include
bool intel_is_genx(unsigned int devid, int gen);
bool intel_get_genx(unsigned int devid, int *gen);
+#define IS_GEN11(devid) intel_is_genx(devid, 11)
+
/* all platforms */
#define IS_9XX(dev)(IS_GEN3(dev) || \
IS_GEN4(dev) || \
@@ -583,7 +561,6 @@ bool intel_get_genx(unsigned int devid, int *gen);
IS_GEN8(dev) || \
IS_GEN9(dev) || \
IS_GEN10(dev) || \
-IS_GEN11(dev) || \
intel_get_genx(dev, NULL))
#endif /* _INTEL_CHIPSET_H */
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm 1/4] intel: add IS_GENX() generic macro
On Sat, Aug 25, 2018 at 10:35:23AM +0100, Chris Wilson wrote:
> Quoting Lucas De Marchi (2018-08-25 00:56:46)
> > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> > index 4a34b7be..8a0e3e76 100644
> > --- a/intel/intel_chipset.h
> > +++ b/intel/intel_chipset.h
> > @@ -568,6 +568,26 @@
> >
> > #define IS_GEN11(devid)(IS_ICELAKE_11(devid))
> >
> > +/* New platforms use kernel pci ids */
> > +#include "i915_pciids.h"
> > +
> > +struct pci_device_id {
>
> Don't call it pci_device_id, depending on caller that name may already
> be taken by libpciaccess.
ok. I can actually move it inside the function/macro and use an
autogenerated name.
>
> > + uint32_t unused0, device;
> > + uint32_t unused1, unused2;
> > + uint32_t unused3, unused4;
> These are all uint16_t.
kernel "document" them as uint32_t:
/*
* A pci_device_id struct {
* __u32 vendor, device;
* __u32 subvendor, subdevice;
* __u32 class, class_mask;
* kernel_ulong_t driver_data;
* };
* Don't use C99 here because "class" is reserved and we want to
* give userspace flexibility.
>
> > + unsigned long unused5;
>
> Simply make the unused disappear from the macro.
>
> > +};
> > +
> > +#define IS_GENX(x, devid) ({ \
> > + struct pci_device_id __ids[] = { INTEL_ ## x ## _IDS(0) }; \
>
> While that's a neat trick it's instantiating the array for each caller,
> and it does appear that we repeat a few of the macros.
>
> The best I can offer to keep the change non-invasive (other than just
> switching to a platform bitmask and filling (devid, gen, platform) from
> the pci match data on initialisation) is a two pass approach.
>
> static inline int __find_in_pciid(uint16_t devid,
> const struct pci_device_id *ids, size_t count)
> {
> size_t i = 0; /* we should rethink this if we think there are more than
> 4B of them! */
> for (i = 0; i < count; i++) {
> if (ids[i].device == devid)
> return 1;
> }
> return 0;
> }
>
>
> #define __is_genx(x) \
here I would name this DEFINE_IS_GENX, since it's a macro to define
the functions, not to be used in other places.
> static inline int __is_gen##x(uint16_t devid) \
> { \
> static const struct pci_device_id __ids[] = { INTEL_ ## x ## _IDS(0) };
> \
> return __find_in_pciid(devid, __ids, sizeof(__ids)/sizeof(__ids[0]); \
> }
> __is_genx(3);
> __is_genx(4);
> __is_genx(5);
> __is_genx(6);
> __is_genx(7);
> __is_genx(8);
> __is_genx(9);
> __is_genx(10);
> __is_genx(11);
>
> #define IS_GENX(x, devid) __is_gen##x(devid)
i915_pciids.h is not consistent with how the macros are called. See that
in my patch. So here I'd have:
#define DEFINE_IS_GENX(x, pfx) \
static inline int __is_gen##x(uint16_t devid) \
{ \
static const struct pci_device_id __ids[] = { INTEL_ ## pfx ## _IDS(0)
}; \
return __find_in_pciid(devid, __ids, sizeof(__ids)/sizeof(__ids[0]); \
}
#define IS_GEN10(devid) IS_GENX(10, CNL, devid)
For gen9 is more complicated as it needs several ids.
>
> That should help cut down the object size expansion. But longer term I'd
I'm not opposed to turning it into inline function, but if the goal is
to reduce the object size expansion, just making the array static const
should suffice... we do call the macros several times, but most of the
size is for constructing the array, not to find the elements.
> prefer if we moved to towards finding the match data once. Also we need
> to pull into the canonical header the friendly names for mesa.
what do you mean by "friendly names for mesa".
The other option that is actually my preferred is to let the kernel tell
user space what it is. What do you think about having an ioctl that returns
what is the gen + additional interesting info? Then user space could
base its decisions on features and fallback to gen version when there
isn't a way to discover if a feature/bug is present. This would allow
to simply remove the pci ids from user space projects which IMO would be
a good thing.
Lucas De Marchi
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm 1/4] intel: add IS_GENX() generic macro
On Mon, Aug 27, 2018 at 10:40:28PM +0100, Chris Wilson wrote: > Quoting Lucas De Marchi (2018-08-27 22:19:54) > > On Sat, Aug 25, 2018 at 10:35:23AM +0100, Chris Wilson wrote: > > > Quoting Lucas De Marchi (2018-08-25 00:56:46) > > > That should help cut down the object size expansion. But longer term I'd > > > > I'm not opposed to turning it into inline function, but if the goal is > > to reduce the object size expansion, just making the array static const > > should suffice... we do call the macros several times, but most of the > > size is for constructing the array, not to find the elements. > > It'll construct the array on the stack, painfully. I thought you were > trying for a minimal change :) the way I meant it it won't construct in the stack. > > > > prefer if we moved to towards finding the match data once. Also we need > > > to pull into the canonical header the friendly names for mesa. > > > > what do you mean by "friendly names for mesa". > > > > The other option that is actually my preferred is to let the kernel tell > > user space what it is. What do you think about having an ioctl that returns > > what is the gen + additional interesting info? Then user space could > > base its decisions on features and fallback to gen version when there > > isn't a way to discover if a feature/bug is present. This would allow > > to simply remove the pci ids from user space projects which IMO would be > > a good thing. > > There simply wasn't enough interest. The key point is selling it to > mesa, see include/pci_ids/i965_pci_ids.h > > The challenge with the centralised db of interesting info is that it > will always be out of date for userspace (think userspace having to cope > with a 5 year kernel, and a kernel having to cope with 10 year old > userspace) and never enough so they still have to supplement it without > their own db. > > That isn't to say that there isn't a lot of interesting hw properties > that userspace needs to know, but they are also tend to be the ones tied > to fuses and not pciid. > > What we do all duplicate are the pci-ids, so pulling those into a > central header containing the commonly used per-id information in a format > that can be embedded into any of the caller's structs is challenge > enough. I think kernel, igt and libdrm would be happy with either runtime or a common header. Checking now what mesa does, giving a friendly name and assigning the properties for each and every device is out of reach, at least for now. So fair enough regarding the runtime option. However I don't think that means we shouldn't try improve libdrm/igt just because it won't solve it for mesa (at least with the "common header approach"). I'll try to spin a new version to handle your comment. Lucas De Marchi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
