Re: [Intel-gfx] [PATCH] drm: Split out drm_probe_helper.h
On Mon, Jan 21, 2019 at 11:13 PM Sam Ravnborg wrote: > > Hi Daniel et al. > > > > > > > Yeah the drm_crtc_helper.h header is a bit the miniature drmP.h for legacy > > > kms drivers. Just removing it from all the atomic drivers caused lots of > > > fallout, I expect even more if you entirely remove the includes it has. > > > Maybe a todo, care to pls create that patch since it's your idea? > > > > The main reason I bailed out initially was that this would create > > small changes to several otherwise seldomly touched files. > > And then we would later come and remove drmP.h - so lots of > > small but incremental changes to the same otherwise seldomly > > edited files. > > And the job was only partially done. > > > > I will try to experiment with an approach where I clean up the > > include/drm/*.h files a little (like suggested above, +delete drmP.h > > and maybe a bit more). > > > > Then to try on a driver by driver basis to make it build with a > > cleaned set of include files. > > I hope that the cleaned up driver can still build without the > > cleaned header files so the changes can be submitted piecemal. > > > > Will do so with an eye on the lesser maintained drivers to try it > > out to avoid creating too much chrunch for others. > > I have now a few patches queued, but the result is not too pretty. > I did the following: > > - For all files in include/drm/*.h the set of include files > were adjusted to the minimum number of files required to make > them build without any other files included first. > > Created one .c file for each .h file. Then included the .h > file and adjusted to the minimal set of include files. > In the process a lot of forwards were added. > > - Deleted drmP.h > > - Fixed build of a few drivers: sti, tilcdc, gma500, tve200, via > > Some observations: > > - Killing all the includes not needed in the headers files > results in a a lot of extra changes. > Examples: > drm_modseset_helper_vtables.h is no longer > included by anyone, so needs to be added in many files > > drm_atomic_state_helper.h is no longer included > by anyone so likewise needs to be added in many files > > - It is very tedious to do this properly. > The process I followed was: > - delete / comment out all include files > - add back the obvious from a quick scan of the code > - build - fix - build - fix - build - fix ... > - next file... > > - The result is errorprone as only the allyesconfig + allmodconfig > variants are tested. But reallife configurations are more diverse. > > Current diffstat: >111 files changed, 771 insertions(+), 401 deletions(-) > > This is for the 5 drivers alone and not the header cleanup. > So long story short - this is not good and not the way forward. > > I will try to come up with a few improvements to make the > headers files selfcontained, but restricted to the changes that > add forwards/include to avoid the chrunch in all the drivers. > > And then post for review a few patches to clean up some headers. > If the cleanup gets a go I will try to persuade the introduction > of these. > This will include, but will not be limited to, the above mentioned > drm_crtc_helper.h header file. > > For now too much time was already spent on this, so it is at the > moment pushed back on my TODO list. > This mail serve also as a kind of "where had I left", when/if I > pick this up again. > > If there are anyone that knows some tooling that can help in the > process of adjusting the header files I am all ears. Yeah in the process of splitting up drmP.h we've created a few smaller such piles of headers. I think in some cases it's just not going to be worth it to fully split them up, e.g. drm_crtc_helper.h is going to be a pure legacy helper, only needed by pre-atomic drivers. Splitting that up doesn't seem to useful to me. Similarly we might want drm_atomic_helper.h to keep pulling in the other helper headers. So probably going to be a judgement call on a case-by-case basis. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/7] drm/i915/crt: split out intel_crt_present() to platform specific setup
With new platforms not having CRT support and most conditions in
intel_crt_present() being specific to DDI, split out the CRT
initialization to platform specific blocks in the if ladder. Add new
Pineview block for this.
This puts intel_crt_init() more in line with the rest of the outputs,
and makes it slightly easier for the uninitiated to figure out which
platforms actually have what.
v2: keep gen >= 9 check in intel_ddi_crt_present() (Ville)
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 34
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2fa9f4aec08e..9e0f34524d0b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14245,7 +14245,7 @@ static bool has_edp_a(struct drm_i915_private *dev_priv)
return true;
}
-static bool intel_crt_present(struct drm_i915_private *dev_priv)
+static bool intel_ddi_crt_present(struct drm_i915_private *dev_priv)
{
if (INTEL_GEN(dev_priv) >= 9)
return false;
@@ -14253,15 +14253,12 @@ static bool intel_crt_present(struct drm_i915_private
*dev_priv)
if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
return false;
- if (IS_CHERRYVIEW(dev_priv))
- return false;
-
if (HAS_PCH_LPT_H(dev_priv) &&
I915_READ(SFUSE_STRAP) & SFUSE_STRAP_CRT_DISABLED)
return false;
/* DDI E can't be used if DDI A requires 4 lanes */
- if (HAS_DDI(dev_priv) && I915_READ(DDI_BUF_CTL(PORT_A)) & DDI_A_4_LANES)
+ if (I915_READ(DDI_BUF_CTL(PORT_A)) & DDI_A_4_LANES)
return false;
if (!dev_priv->vbt.int_crt_support)
@@ -14323,9 +14320,6 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
*/
intel_lvds_init(dev_priv);
- if (intel_crt_present(dev_priv))
- intel_crt_init(dev_priv);
-
if (IS_ICELAKE(dev_priv)) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
@@ -14354,6 +14348,9 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
} else if (HAS_DDI(dev_priv)) {
int found;
+ if (intel_ddi_crt_present(dev_priv))
+ intel_crt_init(dev_priv);
+
/*
* Haswell uses DDI functions to detect digital outputs.
* On SKL pre-D0 the strap isn't connected, so we assume
@@ -14385,6 +14382,10 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
} else if (HAS_PCH_SPLIT(dev_priv)) {
int found;
+
+ if (dev_priv->vbt.int_crt_support)
+ intel_crt_init(dev_priv);
+
dpd_is_edp = intel_dp_is_port_edp(dev_priv, PORT_D);
if (has_edp_a(dev_priv))
@@ -14413,6 +14414,9 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
bool has_edp, has_port;
+ if (IS_VALLEYVIEW(dev_priv) && dev_priv->vbt.int_crt_support)
+ intel_crt_init(dev_priv);
+
/*
* The DP_DETECTED bit is the latched state of the DDC
* SDA pin at boot. However since eDP doesn't require DDC
@@ -14455,9 +14459,15 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
}
vlv_dsi_init(dev_priv);
- } else if (!IS_GEN(dev_priv, 2) && !IS_PINEVIEW(dev_priv)) {
+ } else if (IS_PINEVIEW(dev_priv)) {
+ if (dev_priv->vbt.int_crt_support)
+ intel_crt_init(dev_priv);
+ } else if (IS_GEN_RANGE(dev_priv, 3, 4)) {
bool found = false;
+ if (dev_priv->vbt.int_crt_support)
+ intel_crt_init(dev_priv);
+
if (I915_READ(GEN3_SDVOB) & SDVO_DETECTED) {
DRM_DEBUG_KMS("probing SDVOB\n");
found = intel_sdvo_init(dev_priv, GEN3_SDVOB, PORT_B);
@@ -14489,8 +14499,12 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
if (IS_G4X(dev_priv) && (I915_READ(DP_D) & DP_DETECTED))
intel_dp_init(dev_priv, DP_D, PORT_D);
- } else if (IS_GEN(dev_priv, 2))
+ } else if (IS_GEN(dev_priv, 2)) {
+ if (dev_priv->vbt.int_crt_support)
+ intel_crt_init(dev_priv);
+
intel_dvo_init(dev_priv);
+ }
if (SUPPORTS_TV(dev_priv))
intel_tv_init(dev_priv);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 7/7] drm/i915/crt: simplify CRT VBT check on pre-VLV/DDI
The VBT int_crt_support can't be trusted on earlier platforms, and is
always set to true in intel_bios.c for pre-DDI and pre-VLV platforms. We
can simplify the output setup by unconditionally calling
intel_crt_init() for these platforms.
Suggested-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ed3780f24638..d328599240cb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14382,9 +14382,7 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
* incorrect sharing of the PPS.
*/
intel_lvds_init(dev_priv);
-
- if (dev_priv->vbt.int_crt_support)
- intel_crt_init(dev_priv);
+ intel_crt_init(dev_priv);
dpd_is_edp = intel_dp_is_port_edp(dev_priv, PORT_D);
@@ -14461,17 +14459,14 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
vlv_dsi_init(dev_priv);
} else if (IS_PINEVIEW(dev_priv)) {
intel_lvds_init(dev_priv);
-
- if (dev_priv->vbt.int_crt_support)
- intel_crt_init(dev_priv);
+ intel_crt_init(dev_priv);
} else if (IS_GEN_RANGE(dev_priv, 3, 4)) {
bool found = false;
if (IS_MOBILE(dev_priv))
intel_lvds_init(dev_priv);
- if (dev_priv->vbt.int_crt_support)
- intel_crt_init(dev_priv);
+ intel_crt_init(dev_priv);
if (I915_READ(GEN3_SDVOB) & SDVO_DETECTED) {
DRM_DEBUG_KMS("probing SDVOB\n");
@@ -14511,9 +14506,7 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
if (IS_I85X(dev_priv))
intel_lvds_init(dev_priv);
- if (dev_priv->vbt.int_crt_support)
- intel_crt_init(dev_priv);
-
+ intel_crt_init(dev_priv);
intel_dvo_init(dev_priv);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/7] drm/i915/tv: only call intel_tv_init() on platforms that might have TV
With most platforms not having TV support, only call intel_tv_init() on
platforms that might actually have TV, specifically gens 3 and 4.
This puts intel_tv_init() more in line with the rest of the outputs, and
makes it slightly easier for the uninitiated to figure out which
platforms actually have what.
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index db0f15242ccf..8e89f04ddd9c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14504,6 +14504,9 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
if (IS_G4X(dev_priv) && (I915_READ(DP_D) & DP_DETECTED))
intel_dp_init(dev_priv, DP_D, PORT_D);
+
+ if (SUPPORTS_TV(dev_priv))
+ intel_tv_init(dev_priv);
} else if (IS_GEN(dev_priv, 2)) {
if (IS_MOBILE(dev_priv) && !IS_I830(dev_priv))
intel_lvds_init(dev_priv);
@@ -14514,9 +14517,6 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
intel_dvo_init(dev_priv);
}
- if (SUPPORTS_TV(dev_priv))
- intel_tv_init(dev_priv);
-
intel_psr_init(dev_priv);
for_each_intel_encoder(&dev_priv->drm, encoder) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915/lvds: nuke intel_lvds_supported()
On Mon, 21 Jan 2019, Ville Syrjälä wrote:
> On Mon, Jan 21, 2019 at 04:21:32PM +0200, Jani Nikula wrote:
>> Now that intel_lvds_init() is only called for platforms that might have
>> LVDS, move the remaining checks to intel_setup_outputs(), again similar
>> to other outputs, and remove the overlapping checks.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 6 --
>> drivers/gpu/drm/i915/intel_lvds.c| 23 ---
>> 2 files changed, 4 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 4b5704a87934..4207ee0b83ce 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -14464,7 +14464,8 @@ static void intel_setup_outputs(struct
>> drm_i915_private *dev_priv)
>
> Had to read the earlier patch twice to make sure we're not leaving
> ibx/cpt/ppt or pnv behind.
>
>> } else if (IS_GEN_RANGE(dev_priv, 3, 4)) {
>> bool found = false;
>>
>> -intel_lvds_init(dev_priv);
>> +if (IS_MOBILE(dev_priv))
>> +intel_lvds_init(dev_priv);
>>
>> if (dev_priv->vbt.int_crt_support)
>> intel_crt_init(dev_priv);
>> @@ -14501,7 +14502,8 @@ static void intel_setup_outputs(struct
>> drm_i915_private *dev_priv)
>> if (IS_G4X(dev_priv) && (I915_READ(DP_D) & DP_DETECTED))
>> intel_dp_init(dev_priv, DP_D, PORT_D);
>> } else if (IS_GEN(dev_priv, 2)) {
>> -intel_lvds_init(dev_priv);
>> +if (IS_MOBILE(dev_priv) && !IS_I830(dev_priv))
>
> aka. IS_I85X()
Made the change in a separate patch.
> Reviewed-by: Ville Syrjälä
Thanks,
Jani.
>
>> +intel_lvds_init(dev_priv);
>>
>> if (dev_priv->vbt.int_crt_support)
>> intel_crt_init(dev_priv);
>> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
>> b/drivers/gpu/drm/i915/intel_lvds.c
>> index 46a5dfd5cdf7..815ed463d9c5 100644
>> --- a/drivers/gpu/drm/i915/intel_lvds.c
>> +++ b/drivers/gpu/drm/i915/intel_lvds.c
>> @@ -798,26 +798,6 @@ static bool compute_is_dual_link_lvds(struct
>> intel_lvds_encoder *lvds_encoder)
>> return (val & LVDS_CLKB_POWER_MASK) == LVDS_CLKB_POWER_UP;
>> }
>>
>> -static bool intel_lvds_supported(struct drm_i915_private *dev_priv)
>> -{
>> -/*
>> - * With the introduction of the PCH we gained a dedicated
>> - * LVDS presence pin, use it.
>> - */
>> -if (HAS_PCH_IBX(dev_priv) || HAS_PCH_CPT(dev_priv))
>> -return true;
>> -
>> -/*
>> - * Otherwise LVDS was only attached to mobile products,
>> - * except for the inglorious 830gm
>> - */
>> -if (INTEL_GEN(dev_priv) <= 4 &&
>> -IS_MOBILE(dev_priv) && !IS_I830(dev_priv))
>> -return true;
>> -
>> -return false;
>> -}
>> -
>> /**
>> * intel_lvds_init - setup LVDS connectors on this device
>> * @dev_priv: i915 device
>> @@ -842,9 +822,6 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
>> u8 pin;
>> u32 allowed_scalers;
>>
>> -if (!intel_lvds_supported(dev_priv))
>> -return;
>> -
>> /* Skip init on machines we know falsely report LVDS */
>> if (dmi_check_system(intel_no_lvds)) {
>> WARN(!dev_priv->vbt.int_lvds_support,
>> --
>> 2.20.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/7] drm/i915/lvds: nuke intel_lvds_supported()
Now that intel_lvds_init() is only called for platforms that might have
LVDS, move the remaining checks to intel_setup_outputs(), again similar
to other outputs, and remove the overlapping checks.
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 6 --
drivers/gpu/drm/i915/intel_lvds.c| 23 ---
2 files changed, 4 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 29a7dd4afe0e..db0f15242ccf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14467,7 +14467,8 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
} else if (IS_GEN_RANGE(dev_priv, 3, 4)) {
bool found = false;
- intel_lvds_init(dev_priv);
+ if (IS_MOBILE(dev_priv))
+ intel_lvds_init(dev_priv);
if (dev_priv->vbt.int_crt_support)
intel_crt_init(dev_priv);
@@ -14504,7 +14505,8 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
if (IS_G4X(dev_priv) && (I915_READ(DP_D) & DP_DETECTED))
intel_dp_init(dev_priv, DP_D, PORT_D);
} else if (IS_GEN(dev_priv, 2)) {
- intel_lvds_init(dev_priv);
+ if (IS_MOBILE(dev_priv) && !IS_I830(dev_priv))
+ intel_lvds_init(dev_priv);
if (dev_priv->vbt.int_crt_support)
intel_crt_init(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 46a5dfd5cdf7..815ed463d9c5 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -798,26 +798,6 @@ static bool compute_is_dual_link_lvds(struct
intel_lvds_encoder *lvds_encoder)
return (val & LVDS_CLKB_POWER_MASK) == LVDS_CLKB_POWER_UP;
}
-static bool intel_lvds_supported(struct drm_i915_private *dev_priv)
-{
- /*
-* With the introduction of the PCH we gained a dedicated
-* LVDS presence pin, use it.
-*/
- if (HAS_PCH_IBX(dev_priv) || HAS_PCH_CPT(dev_priv))
- return true;
-
- /*
-* Otherwise LVDS was only attached to mobile products,
-* except for the inglorious 830gm
-*/
- if (INTEL_GEN(dev_priv) <= 4 &&
- IS_MOBILE(dev_priv) && !IS_I830(dev_priv))
- return true;
-
- return false;
-}
-
/**
* intel_lvds_init - setup LVDS connectors on this device
* @dev_priv: i915 device
@@ -842,9 +822,6 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
u8 pin;
u32 allowed_scalers;
- if (!intel_lvds_supported(dev_priv))
- return;
-
/* Skip init on machines we know falsely report LVDS */
if (dmi_check_system(intel_no_lvds)) {
WARN(!dev_priv->vbt.int_lvds_support,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/7] drm/i915/lvds: simplify gen 2 lvds presence
Gen 2 mobile and not I830 is, in fact, I85X. Simplify.
Suggested-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9895ea566f99..ed3780f24638 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14508,7 +14508,7 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
if (SUPPORTS_TV(dev_priv))
intel_tv_init(dev_priv);
} else if (IS_GEN(dev_priv, 2)) {
- if (IS_MOBILE(dev_priv) && !IS_I830(dev_priv))
+ if (IS_I85X(dev_priv))
intel_lvds_init(dev_priv);
if (dev_priv->vbt.int_crt_support)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/7] drm/i915: rename has_edp_a() to ilk_has_edp_a()
Clarify that the name is specific to ILK+ PCH platforms.
v2: prefix the name with ilk rather than pch (Ville)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8e89f04ddd9c..9895ea566f99 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14231,7 +14231,7 @@ static int intel_encoder_clones(struct intel_encoder
*encoder)
return index_mask;
}
-static bool has_edp_a(struct drm_i915_private *dev_priv)
+static bool ilk_has_edp_a(struct drm_i915_private *dev_priv)
{
if (!IS_MOBILE(dev_priv))
return false;
@@ -14388,7 +14388,7 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
dpd_is_edp = intel_dp_is_port_edp(dev_priv, PORT_D);
- if (has_edp_a(dev_priv))
+ if (ilk_has_edp_a(dev_priv))
intel_dp_init(dev_priv, DP_A, PORT_A);
if (I915_READ(PCH_HDMIB) & SDVO_DETECTED) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/7] drm/i915/lvds: only call intel_lvds_init() on platforms that might have LVDS
With new platforms not having LVDS support, only call intel_lvds_init()
on platforms that might actually have LVDS. Move the comment about eDP
init to the PCH block where it's relevant.
This puts intel_lvds_init() more in line with the rest of the outputs,
and makes it slightly easier for the uninitiated to figure out which
platforms actually have what.
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9e0f34524d0b..29a7dd4afe0e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14313,13 +14313,6 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
if (!HAS_DISPLAY(dev_priv))
return;
- /*
-* intel_edp_init_connector() depends on this completing first, to
-* prevent the registeration of both eDP and LVDS and the incorrect
-* sharing of the PPS.
-*/
- intel_lvds_init(dev_priv);
-
if (IS_ICELAKE(dev_priv)) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
@@ -14383,6 +14376,13 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
} else if (HAS_PCH_SPLIT(dev_priv)) {
int found;
+ /*
+* intel_edp_init_connector() depends on this completing first,
+* to prevent the registration of both eDP and LVDS and the
+* incorrect sharing of the PPS.
+*/
+ intel_lvds_init(dev_priv);
+
if (dev_priv->vbt.int_crt_support)
intel_crt_init(dev_priv);
@@ -14460,11 +14460,15 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
vlv_dsi_init(dev_priv);
} else if (IS_PINEVIEW(dev_priv)) {
+ intel_lvds_init(dev_priv);
+
if (dev_priv->vbt.int_crt_support)
intel_crt_init(dev_priv);
} else if (IS_GEN_RANGE(dev_priv, 3, 4)) {
bool found = false;
+ intel_lvds_init(dev_priv);
+
if (dev_priv->vbt.int_crt_support)
intel_crt_init(dev_priv);
@@ -14500,6 +14504,8 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
if (IS_G4X(dev_priv) && (I915_READ(DP_D) & DP_DETECTED))
intel_dp_init(dev_priv, DP_D, PORT_D);
} else if (IS_GEN(dev_priv, 2)) {
+ intel_lvds_init(dev_priv);
+
if (dev_priv->vbt.int_crt_support)
intel_crt_init(dev_priv);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915/tv: only call intel_tv_init() on platforms that might have TV
On Mon, 21 Jan 2019, Ville Syrjälä wrote:
> On Mon, Jan 21, 2019 at 04:21:33PM +0200, Jani Nikula wrote:
>> With most platforms not having TV support, only call intel_tv_init() on
>> platforms that might actually have TV, specifically gens 3 and 4.
>>
>> This puts intel_tv_init() more in line with the rest of the outputs, and
>> makes it slightly easier for the uninitiated to figure out which
>> platforms actually have what.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 4207ee0b83ce..6960004fdc94 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -14501,6 +14501,9 @@ static void intel_setup_outputs(struct
>> drm_i915_private *dev_priv)
>>
>> if (IS_G4X(dev_priv) && (I915_READ(DP_D) & DP_DETECTED))
>> intel_dp_init(dev_priv, DP_D, PORT_D);
>> +
>> +if (SUPPORTS_TV(dev_priv))
>> +intel_tv_init(dev_priv);
>
> Since PNV was split into its own thing I think this could actually
> be replaced with IS_MOBILE().
If I'd been able to get rid of SUPPORTS_TV() with that altogether, I
probably would've made the change. But there's still a user in CRC code,
so I left this as-is.
BR,
Jani.
>
> Either way
> Reviewed-by: Ville Syrjälä
>
>> } else if (IS_GEN(dev_priv, 2)) {
>> if (IS_MOBILE(dev_priv) && !IS_I830(dev_priv))
>> intel_lvds_init(dev_priv);
>> @@ -14511,9 +14514,6 @@ static void intel_setup_outputs(struct
>> drm_i915_private *dev_priv)
>> intel_dvo_init(dev_priv);
>> }
>>
>> -if (SUPPORTS_TV(dev_priv))
>> -intel_tv_init(dev_priv);
>> -
>> intel_psr_init(dev_priv);
>>
>> for_each_intel_encoder(&dev_priv->drm, encoder) {
>> --
>> 2.20.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915/crt: split out intel_crt_present() to platform specific setup
On Mon, 21 Jan 2019, Ville Syrjälä wrote:
> On Mon, Jan 21, 2019 at 04:21:30PM +0200, Jani Nikula wrote:
>> With new platforms not having CRT support and most conditions in
>> intel_crt_present() being specific to DDI, split out the CRT
>> initialization to platform specific blocks in the if ladder. Add new
>> Pineview block for this.
>>
>> This puts intel_crt_init() more in line with the rest of the outputs,
>> and makes it slightly easier for the uninitiated to figure out which
>> platforms actually have what.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 37 ++--
>> 1 file changed, 24 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 2fa9f4aec08e..e8bc297c60ab 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -14245,23 +14245,17 @@ static bool has_edp_a(struct drm_i915_private
>> *dev_priv)
>> return true;
>> }
>>
>> -static bool intel_crt_present(struct drm_i915_private *dev_priv)
>> +static bool intel_ddi_crt_present(struct drm_i915_private *dev_priv)
>> {
>> -if (INTEL_GEN(dev_priv) >= 9)
>> -return false;
>
> We should probably keep this in case the vbt is bonkers.
Oh, definitely, thanks for spotting!
>
>> -
>> if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
>> return false;
>>
>> -if (IS_CHERRYVIEW(dev_priv))
>> -return false;
>> -
>> if (HAS_PCH_LPT_H(dev_priv) &&
>> I915_READ(SFUSE_STRAP) & SFUSE_STRAP_CRT_DISABLED)
>> return false;
>>
>> /* DDI E can't be used if DDI A requires 4 lanes */
>> -if (HAS_DDI(dev_priv) && I915_READ(DDI_BUF_CTL(PORT_A)) & DDI_A_4_LANES)
>> +if (I915_READ(DDI_BUF_CTL(PORT_A)) & DDI_A_4_LANES)
>> return false;
>>
>> if (!dev_priv->vbt.int_crt_support)
>> @@ -14323,9 +14317,6 @@ static void intel_setup_outputs(struct
>> drm_i915_private *dev_priv)
>> */
>> intel_lvds_init(dev_priv);
>>
>> -if (intel_crt_present(dev_priv))
>> -intel_crt_init(dev_priv);
>> -
>> if (IS_ICELAKE(dev_priv)) {
>> intel_ddi_init(dev_priv, PORT_A);
>> intel_ddi_init(dev_priv, PORT_B);
>> @@ -14354,6 +14345,9 @@ static void intel_setup_outputs(struct
>> drm_i915_private *dev_priv)
>> } else if (HAS_DDI(dev_priv)) {
>> int found;
>>
>> +if (intel_ddi_crt_present(dev_priv))
>> +intel_crt_init(dev_priv);
>> +
>> /*
>> * Haswell uses DDI functions to detect digital outputs.
>> * On SKL pre-D0 the strap isn't connected, so we assume
>> @@ -14385,6 +14379,10 @@ static void intel_setup_outputs(struct
>> drm_i915_private *dev_priv)
>>
>> } else if (HAS_PCH_SPLIT(dev_priv)) {
>> int found;
>> +
>> +if (dev_priv->vbt.int_crt_support)
>> +intel_crt_init(dev_priv);
>> +
>> dpd_is_edp = intel_dp_is_port_edp(dev_priv, PORT_D);
>>
>> if (has_edp_a(dev_priv))
>> @@ -14413,6 +14411,9 @@ static void intel_setup_outputs(struct
>> drm_i915_private *dev_priv)
>> } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
>> bool has_edp, has_port;
>>
>> +if (IS_VALLEYVIEW(dev_priv) && dev_priv->vbt.int_crt_support)
>> +intel_crt_init(dev_priv);
>> +
>> /*
>> * The DP_DETECTED bit is the latched state of the DDC
>> * SDA pin at boot. However since eDP doesn't require DDC
>> @@ -14455,9 +14456,15 @@ static void intel_setup_outputs(struct
>> drm_i915_private *dev_priv)
>> }
>>
>> vlv_dsi_init(dev_priv);
>> -} else if (!IS_GEN(dev_priv, 2) && !IS_PINEVIEW(dev_priv)) {
>> +} else if (IS_PINEVIEW(dev_priv)) {
>> +if (dev_priv->vbt.int_crt_support)
>> +intel_crt_init(dev_priv);
>> +} else if (IS_GEN_RANGE(dev_priv, 3, 4)) {
>> bool found = false;
>>
>> +if (dev_priv->vbt.int_crt_support)
>> +intel_crt_init(dev_priv);
>> +
>> if (I915_READ(GEN3_SDVOB) & SDVO_DETECTED) {
>> DRM_DEBUG_KMS("probing SDVOB\n");
>> found = intel_sdvo_init(dev_priv, GEN3_SDVOB, PORT_B);
>> @@ -14489,8 +14496,12 @@ static void intel_setup_outputs(struct
>> drm_i915_private *dev_priv)
>>
>> if (IS_G4X(dev_priv) && (I915_READ(DP_D) & DP_DETECTED))
>> intel_dp_init(dev_priv, DP_D, PORT_D);
>> -} else if (IS_GEN(dev_priv, 2))
>> +} else if (IS_GEN(dev_priv, 2)) {
>> +if (dev_priv->vbt.int_crt_support)
>> +intel_crt_init(dev_priv);
>
> int_crt_support is always true for pre-vlv/pre-hsw so we could
> skip the check in most of these cases. Either way
Re: [Intel-gfx] [PATCH] drm/dp: use DRM_DEBUG_DP() instead of drm_dbg for logging
On Mon, 21 Jan 2019, Ville Syrjälä wrote:
> On Mon, Jan 21, 2019 at 01:27:58PM +0200, Jani Nikula wrote:
>> We have a wrapper for a reason.
>>
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Ville Syrjälä
Thanks, pushed to drm-misc-next.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/drm_dp_helper.c | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index 26835d174939..4def0bface85 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -194,11 +194,11 @@ drm_dp_dump_access(const struct drm_dp_aux *aux,
>> const char *arrow = request == DP_AUX_NATIVE_READ ? "->" : "<-";
>>
>> if (ret > 0)
>> -drm_dbg(DRM_UT_DP, "%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
>> -aux->name, offset, arrow, ret, min(ret, 20), buffer);
>> +DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
>> + aux->name, offset, arrow, ret, min(ret, 20),
>> buffer);
>> else
>> -drm_dbg(DRM_UT_DP, "%s: 0x%05x AUX %s (ret=%3d)\n",
>> -aux->name, offset, arrow, ret);
>> +DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d)\n",
>> + aux->name, offset, arrow, ret);
>> }
>>
>> /**
>> --
>> 2.20.1
>>
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf: Enhance dma-fence tracing
Am 22.01.19 um 00:20 schrieb Chris Wilson: > Rather than every backend and GPU driver reinventing the same wheel for > user level debugging of HW execution, the common dma-fence framework > should include the tracing infrastructure required for most client API > level flow visualisation. > > With these common dma-fence level tracepoints, the userspace tools can > establish a detailed view of the client <-> HW flow across different > kernels. There is a strong ask to have this available, so that the > userspace developer can effectively assess if they're doing a good job > about feeding the beast of a GPU hardware. > > In the case of needing to look into more fine-grained details of how > kernel internals work towards the goal of feeding the beast, the tools > may optionally amend the dma-fence tracing information with the driver > implementation specific. But for such cases, the tools should have a > graceful degradation in case the expected extra tracepoints have > changed or their format differs from the expected, as the kernel > implementation internals are not expected to stay the same. > > It is important to distinguish between tracing for the purpose of client > flow visualisation and tracing for the purpose of low-level kernel > debugging. The latter is highly implementation specific, tied to > a particular HW and driver, whereas the former addresses a common goal > of user level tracing and likely a common set of userspace tools. > Having made the distinction that these tracepoints will be consumed for > client API tooling, we raise the spectre of tracepoint ABI stability. It > is hoped that by defining a common set of dma-fence tracepoints, we avoid > the pitfall of exposing low level details and so restrict ourselves only > to the high level flow that is applicable to all drivers and hardware. > Thus the reserved guarantee that this set of tracepoints will be stable > (with the emphasis on depicting client <-> HW flow as opposed to > driver <-> HW). > > In terms of specific changes to the dma-fence tracing, we remove the > emission of the strings for every tracepoint (reserving them for > dma_fence_init for cases where they have unique dma_fence_ops, and > preferring to have descriptors for the whole fence context). strings do > not pack as well into the ftrace ringbuffer and we would prefer to > reduce the amount of indirect callbacks required for frequent tracepoint > emission. > > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen > Cc: Tvrtko Ursulin > Cc: Alex Deucher > Cc: "Christian König" > Cc: Eric Anholt > Cc: Pierre-Loup Griffais > Cc: Michael Sartain > Cc: Steven Rostedt In general yes please! If possible please separate out the changes to the common dma_fence infrastructure from the i915 changes. One thing I'm wondering is why the enable_signaling trace point doesn't need to be exported any more. Is that only used internally in the common infrastructure? Apart from that I'm on sick leave today, so give me at least a few days to recover and take a closer look. Thanks, Christian. > --- > drivers/dma-buf/dma-fence.c | 9 +- > drivers/gpu/drm/i915/i915_gem_clflush.c | 5 + > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 1 - > drivers/gpu/drm/i915/i915_request.c | 16 +- > drivers/gpu/drm/i915/i915_timeline.c| 5 + > drivers/gpu/drm/i915/i915_trace.h | 134 --- > drivers/gpu/drm/i915/intel_guc_submission.c | 10 ++ > drivers/gpu/drm/i915/intel_lrc.c| 6 + > drivers/gpu/drm/i915/intel_ringbuffer.h | 2 + > include/trace/events/dma_fence.h| 177 +++- > 10 files changed, 214 insertions(+), 151 deletions(-) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index 3aa8733f832a..5c93ed34b1ff 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -27,8 +27,15 @@ > #define CREATE_TRACE_POINTS > #include > > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_context_create); > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_context_destroy); > + > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_await); > EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit); > -EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal); > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_execute_start); > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_execute_end); > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_wait_start); > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_wait_end); > > static DEFINE_SPINLOCK(dma_fence_stub_lock); > static struct dma_fence dma_fence_stub; > diff --git a/drivers/gpu/drm/i915/i915_gem_clflush.c > b/drivers/gpu/drm/i915/i915_gem_clflush.c > index 8e74c23cbd91..435c1303ecc8 100644 > --- a/drivers/gpu/drm/i915/i915_gem_clflush.c > +++ b/drivers/gpu/drm/i915/i915_gem_clflush.c > @@ -22,6 +22,8 @@ >* >*/ > > +#include > + > #include "i915_drv.h" > #include "intel_frontbuffer.h" > #include "i915_gem_clflush.h" > @@ -73,6 +75,7 @@ static void i915_clflush_work(
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/7] drm/i915/crt: split out intel_crt_present() to platform specific setup
== Series Details ==
Series: series starting with [v2,1/7] drm/i915/crt: split out
intel_crt_present() to platform specific setup
URL : https://patchwork.freedesktop.org/series/55540/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5459 -> Patchwork_12003
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55540/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12003 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-apl-guc: PASS -> DMESG-WARN [fdo#108529] / [fdo#108566]
Possible fixes
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u2}:FAIL [fdo#103167] -> PASS
* igt@pm_rpm@module-reload:
- {fi-icl-u2}:DMESG-WARN [fdo#108654] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#108529]: https://bugs.freedesktop.org/show_bug.cgi?id=108529
[fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108654]: https://bugs.freedesktop.org/show_bug.cgi?id=108654
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
Participating hosts (47 -> 41)
--
Additional (1): fi-glk-j4005
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-peppy fi-byt-squawks
fi-bsw-cyan fi-pnv-d510 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5459 -> Patchwork_12003
CI_DRM_5459: 0f693a275dd91391b476ada7481cf08f4fe610aa @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4780: 1c1612bdc36b44a704095e7b0ba5542818ce793f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12003: f6c1b42bdd25a3c26ffd12155b322eb57131deba @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f6c1b42bdd25 drm/i915/crt: simplify CRT VBT check on pre-VLV/DDI
8f9fa9fb8dff drm/i915/lvds: simplify gen 2 lvds presence
a74fbf6829d4 drm/i915: rename has_edp_a() to ilk_has_edp_a()
2574de0daa85 drm/i915/tv: only call intel_tv_init() on platforms that might
have TV
cdba4c424c11 drm/i915/lvds: nuke intel_lvds_supported()
66e5eb4fa89d drm/i915/lvds: only call intel_lvds_init() on platforms that might
have LVDS
3ae75b736cf4 drm/i915/crt: split out intel_crt_present() to platform specific
setup
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12003/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf: Enhance dma-fence tracing
Quoting Koenig, Christian (2019-01-22 08:49:30) > Am 22.01.19 um 00:20 schrieb Chris Wilson: > > Rather than every backend and GPU driver reinventing the same wheel for > > user level debugging of HW execution, the common dma-fence framework > > should include the tracing infrastructure required for most client API > > level flow visualisation. > > > > With these common dma-fence level tracepoints, the userspace tools can > > establish a detailed view of the client <-> HW flow across different > > kernels. There is a strong ask to have this available, so that the > > userspace developer can effectively assess if they're doing a good job > > about feeding the beast of a GPU hardware. > > > > In the case of needing to look into more fine-grained details of how > > kernel internals work towards the goal of feeding the beast, the tools > > may optionally amend the dma-fence tracing information with the driver > > implementation specific. But for such cases, the tools should have a > > graceful degradation in case the expected extra tracepoints have > > changed or their format differs from the expected, as the kernel > > implementation internals are not expected to stay the same. > > > > It is important to distinguish between tracing for the purpose of client > > flow visualisation and tracing for the purpose of low-level kernel > > debugging. The latter is highly implementation specific, tied to > > a particular HW and driver, whereas the former addresses a common goal > > of user level tracing and likely a common set of userspace tools. > > Having made the distinction that these tracepoints will be consumed for > > client API tooling, we raise the spectre of tracepoint ABI stability. It > > is hoped that by defining a common set of dma-fence tracepoints, we avoid > > the pitfall of exposing low level details and so restrict ourselves only > > to the high level flow that is applicable to all drivers and hardware. > > Thus the reserved guarantee that this set of tracepoints will be stable > > (with the emphasis on depicting client <-> HW flow as opposed to > > driver <-> HW). > > > > In terms of specific changes to the dma-fence tracing, we remove the > > emission of the strings for every tracepoint (reserving them for > > dma_fence_init for cases where they have unique dma_fence_ops, and > > preferring to have descriptors for the whole fence context). strings do > > not pack as well into the ftrace ringbuffer and we would prefer to > > reduce the amount of indirect callbacks required for frequent tracepoint > > emission. > > > > Signed-off-by: Chris Wilson > > Cc: Joonas Lahtinen > > Cc: Tvrtko Ursulin > > Cc: Alex Deucher > > Cc: "Christian König" > > Cc: Eric Anholt > > Cc: Pierre-Loup Griffais > > Cc: Michael Sartain > > Cc: Steven Rostedt > > In general yes please! If possible please separate out the changes to > the common dma_fence infrastructure from the i915 changes. Sure, I was just stressing the impact: remove some randomly placed internal debugging tracepoints, try to define useful ones instead :) On the list of things to do was to convert at least 2 other drivers (I was thinking nouveau/msm for simplicity, vc4 for a simpler introduction to drm_sched than amdgpu) over to be sure we have the right tracepoints. > One thing I'm wondering is why the enable_signaling trace point doesn't > need to be exported any more. Is that only used internally in the common > infrastructure? Right. Only used inside the core, and I don't see much call for making it easy for drivers to fiddle around bypassing the core enable_signaling/signal. (I'm not sure it's useful for client flow either, it feels more like dma-fence debugging, but they can just not listen to that tracepoint.) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/34] drm/i915: Pull VM lists under the VM mutex.
On 21/01/2019 22:20, Chris Wilson wrote:
A starting point to counter the pervasive struct_mutex. For the goal of
avoiding (or at least blocking under them!) global locks during user
request submission, a simple but important step is being able to manage
each clients GTT separately. For which, we want to replace using the
struct_mutex as the guard for all things GTT/VM and switch instead to a
specific mutex inside i915_address_space.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
---
drivers/gpu/drm/i915/i915_gem.c | 14 --
drivers/gpu/drm/i915/i915_gem_evict.c | 2 ++
drivers/gpu/drm/i915/i915_gem_gtt.c | 15 +--
drivers/gpu/drm/i915/i915_gem_shrinker.c| 4
drivers/gpu/drm/i915/i915_gem_stolen.c | 2 ++
drivers/gpu/drm/i915/i915_vma.c | 11 +++
drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 3 +++
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 3 +++
8 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f45186ddb236..538fa5404603 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -245,18 +245,19 @@ int
i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct i915_ggtt *ggtt = &dev_priv->ggtt;
+ struct i915_ggtt *ggtt = &to_i915(dev)->ggtt;
struct drm_i915_gem_get_aperture *args = data;
struct i915_vma *vma;
u64 pinned;
+ mutex_lock(&ggtt->vm.mutex);
+
pinned = ggtt->vm.reserved;
- mutex_lock(&dev->struct_mutex);
list_for_each_entry(vma, &ggtt->vm.bound_list, vm_link)
if (i915_vma_is_pinned(vma))
pinned += vma->node.size;
- mutex_unlock(&dev->struct_mutex);
+
+ mutex_unlock(&ggtt->vm.mutex);
args->aper_size = ggtt->vm.total;
args->aper_available_size = args->aper_size - pinned;
@@ -1529,20 +1530,21 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void
*data,
static void i915_gem_object_bump_inactive_ggtt(struct drm_i915_gem_object *obj)
{
- struct drm_i915_private *i915;
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct list_head *list;
struct i915_vma *vma;
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
+ mutex_lock(&i915->ggtt.vm.mutex);
for_each_ggtt_vma(vma, obj) {
if (!drm_mm_node_allocated(&vma->node))
continue;
list_move_tail(&vma->vm_link, &vma->vm->bound_list);
}
+ mutex_unlock(&i915->ggtt.vm.mutex);
- i915 = to_i915(obj->base.dev);
spin_lock(&i915->mm.obj_lock);
list = obj->bind_count ? &i915->mm.bound_list : &i915->mm.unbound_list;
list_move_tail(&obj->mm.link, list);
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 5cfe4b75e7d6..dc137701acb8 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -432,6 +432,7 @@ int i915_gem_evict_vm(struct i915_address_space *vm)
}
INIT_LIST_HEAD(&eviction_list);
+ mutex_lock(&vm->mutex);
list_for_each_entry(vma, &vm->bound_list, vm_link) {
if (i915_vma_is_pinned(vma))
continue;
@@ -439,6 +440,7 @@ int i915_gem_evict_vm(struct i915_address_space *vm)
__i915_vma_pin(vma);
list_add(&vma->evict_link, &eviction_list);
}
+ mutex_unlock(&vm->mutex);
ret = 0;
list_for_each_entry_safe(vma, next, &eviction_list, evict_link) {
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 2ad9070a54c1..49b00996a15e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1931,7 +1931,10 @@ static struct i915_vma *pd_vma_create(struct
gen6_hw_ppgtt *ppgtt, int size)
vma->ggtt_view.type = I915_GGTT_VIEW_ROTATED; /* prevent fencing */
INIT_LIST_HEAD(&vma->obj_link);
+
+ mutex_lock(&vma->vm->mutex);
list_add(&vma->vm_link, &vma->vm->unbound_list);
+ mutex_unlock(&vma->vm->mutex);
return vma;
}
@@ -3504,9 +3507,10 @@ void i915_gem_restore_gtt_mappings(struct
drm_i915_private *dev_priv)
i915_check_and_clear_faults(dev_priv);
+ mutex_lock(&ggtt->vm.mutex);
+
/* First fill our portion of the GTT with scratch pages */
ggtt->vm.clear_range(&ggtt->vm, 0, ggtt->vm.total);
-
ggtt->vm.closed = true; /* skip rewriting PTE on VMA unbind */
/* clflush objects bound into the GGTT and rebind them. */
@@ -3516,19 +3520,26 @@ void i915_gem_restore_gtt_mappings(struct
drm_i915_private *dev_priv)
if (!(vma->flag
Re: [Intel-gfx] [PATCH] dma-buf: Enhance dma-fence tracing
On Tue, Jan 22, 2019 at 10:06 AM Chris Wilson wrote: > > Quoting Koenig, Christian (2019-01-22 08:49:30) > > Am 22.01.19 um 00:20 schrieb Chris Wilson: > > > Rather than every backend and GPU driver reinventing the same wheel for > > > user level debugging of HW execution, the common dma-fence framework > > > should include the tracing infrastructure required for most client API > > > level flow visualisation. > > > > > > With these common dma-fence level tracepoints, the userspace tools can > > > establish a detailed view of the client <-> HW flow across different > > > kernels. There is a strong ask to have this available, so that the > > > userspace developer can effectively assess if they're doing a good job > > > about feeding the beast of a GPU hardware. > > > > > > In the case of needing to look into more fine-grained details of how > > > kernel internals work towards the goal of feeding the beast, the tools > > > may optionally amend the dma-fence tracing information with the driver > > > implementation specific. But for such cases, the tools should have a > > > graceful degradation in case the expected extra tracepoints have > > > changed or their format differs from the expected, as the kernel > > > implementation internals are not expected to stay the same. > > > > > > It is important to distinguish between tracing for the purpose of client > > > flow visualisation and tracing for the purpose of low-level kernel > > > debugging. The latter is highly implementation specific, tied to > > > a particular HW and driver, whereas the former addresses a common goal > > > of user level tracing and likely a common set of userspace tools. > > > Having made the distinction that these tracepoints will be consumed for > > > client API tooling, we raise the spectre of tracepoint ABI stability. It > > > is hoped that by defining a common set of dma-fence tracepoints, we avoid > > > the pitfall of exposing low level details and so restrict ourselves only > > > to the high level flow that is applicable to all drivers and hardware. > > > Thus the reserved guarantee that this set of tracepoints will be stable > > > (with the emphasis on depicting client <-> HW flow as opposed to > > > driver <-> HW). > > > > > > In terms of specific changes to the dma-fence tracing, we remove the > > > emission of the strings for every tracepoint (reserving them for > > > dma_fence_init for cases where they have unique dma_fence_ops, and > > > preferring to have descriptors for the whole fence context). strings do > > > not pack as well into the ftrace ringbuffer and we would prefer to > > > reduce the amount of indirect callbacks required for frequent tracepoint > > > emission. > > > > > > Signed-off-by: Chris Wilson > > > Cc: Joonas Lahtinen > > > Cc: Tvrtko Ursulin > > > Cc: Alex Deucher > > > Cc: "Christian König" > > > Cc: Eric Anholt > > > Cc: Pierre-Loup Griffais > > > Cc: Michael Sartain > > > Cc: Steven Rostedt > > > > In general yes please! If possible please separate out the changes to > > the common dma_fence infrastructure from the i915 changes. > > Sure, I was just stressing the impact: remove some randomly placed > internal debugging tracepoints, try to define useful ones instead :) > > On the list of things to do was to convert at least 2 other drivers > (I was thinking nouveau/msm for simplicity, vc4 for a simpler > introduction to drm_sched than amdgpu) over to be sure we have the right > tracepoints. I think sprinkling these over the scheduler (maybe just as an opt-in, for the case where the driver doesn't have some additional queueing somewhere) would be good. I haven't checked whether it fits, but would give you a bunch of drivers at once. It might also not cover all the cases (I guess the wait related ones would need to be somewhere else). -Daniel > > One thing I'm wondering is why the enable_signaling trace point doesn't > > need to be exported any more. Is that only used internally in the common > > infrastructure? > > Right. Only used inside the core, and I don't see much call for making > it easy for drivers to fiddle around bypassing the core > enable_signaling/signal. (I'm not sure it's useful for client flow > either, it feels more like dma-fence debugging, but they can just > not listen to that tracepoint.) > -Chris > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't use the second dbuf slice on icl
Hi,
On Mon, Jan 21, 2019 at 9:01 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> The code managing the dbuf slices is borked and needs some
> real work to fix. In the meantime let's just stop using the
> second slice.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
> index 8b63afa3a221..1e41c899ffe2 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3618,7 +3618,8 @@ static u8
intel_enabled_dbuf_slices_num(struct drm_i915_private *dev_priv)
> enabled_slices = 1;
>
> /* Gen prior to GEN11 have only one DBuf slice */
> - if (INTEL_GEN(dev_priv) < 11)
> + /* FIXME dbuf slice code is broken: see intel_get_ddb_size() */
> + if (1 || INTEL_GEN(dev_priv) < 11)
> return enabled_slices;
IMHO we may not need this, If we return from above we'll never disable
second slice in case it's enabled by bios.
Anyhow code change in intel_get_ddb_size will take care of enabling
only one slice.
>
> if (I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE)
> @@ -3827,8 +3828,13 @@ static u16 intel_get_ddb_size(struct
drm_i915_private *dev_priv,
>
> /*
> * 12GB/s is maximum BW supported by single DBuf slice.
> +*
> +* FIXME dbuf slice code is broken:
> +* - must wait for planes to stop using the slice before
powering it off
AFAIR we were already doing it and disabling slice only after
update_crtcs, and skl_update_crtc code is taking care of waiting for
vblank in case it's required.
> +* - plane straddling both slices is illegal in
multi-pipe scenarios
This is something new :)
although this change introduce a major limitation with number and size
of planes we can display, yet
As code is broken and mentioned conditions need to be taken care of,
This change should be ok until proper fix.
~Mahesh
> +* - should validate we stay within the hw bandwidth limits
> */
> - if (num_active > 1 || total_data_bw >= GBps(12)) {
> + if (0 && (num_active > 1 || total_data_bw >= GBps(12))) {
> ddb->enabled_slices = 2;
> } else {
> ddb->enabled_slices = 1;
> --
> 2.19.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 25/38] drm/i915/pmu: Always sample an active ringbuffer
On 18/01/2019 14:00, Chris Wilson wrote:
As we no longer have a precise indication of requests queued to an
engine, make no presumptions and just sample the ring registers to see
if the engine is busy.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_pmu.c | 47 +++--
1 file changed, 16 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index b1cb2d3cae16..452589a7e473 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -148,14 +148,6 @@ void i915_pmu_gt_unparked(struct drm_i915_private *i915)
spin_unlock_irq(&i915->pmu.lock);
}
-static bool grab_forcewake(struct drm_i915_private *i915, bool fw)
-{
- if (!fw)
- intel_uncore_forcewake_get(i915, FORCEWAKE_ALL);
-
- return true;
-}
-
static void
add_sample(struct i915_pmu_sample *sample, u32 val)
{
@@ -168,7 +160,6 @@ engines_sample(struct drm_i915_private *dev_priv, unsigned
int period_ns)
struct intel_engine_cs *engine;
enum intel_engine_id id;
intel_wakeref_t wakeref;
- bool fw = false;
if ((dev_priv->pmu.enable & ENGINE_SAMPLE_MASK) == 0)
return;
@@ -180,37 +171,31 @@ engines_sample(struct drm_i915_private *dev_priv,
unsigned int period_ns)
if (!wakeref)
return;
+ intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
for_each_engine(engine, dev_priv, id) {
- u32 current_seqno = intel_engine_get_seqno(engine);
- u32 last_seqno = intel_engine_last_submit(engine);
+ typeof(engine->pmu) *pmu = &engine->pmu;
Or name the struct?
u32 val;
- val = !i915_seqno_passed(current_seqno, last_seqno);
-
- if (val)
- add_sample(&engine->pmu.sample[I915_SAMPLE_BUSY],
- period_ns);
+ val = I915_READ_FW(RING_MI_MODE(engine->mmio_base));
+ if (val & MODE_IDLE)
+ continue;
- if (val && (engine->pmu.enable &
- (BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA {
- fw = grab_forcewake(dev_priv, fw);
+ add_sample(&pmu->sample[I915_SAMPLE_BUSY], period_ns);
+ if (pmu->enable &
+ (BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA))) {
val = I915_READ_FW(RING_CTL(engine->mmio_base));
- } else {
- val = 0;
- }
- if (val & RING_WAIT)
- add_sample(&engine->pmu.sample[I915_SAMPLE_WAIT],
- period_ns);
+ if (val & RING_WAIT)
+ add_sample(&pmu->sample[I915_SAMPLE_WAIT],
+ period_ns);
- if (val & RING_WAIT_SEMAPHORE)
- add_sample(&engine->pmu.sample[I915_SAMPLE_SEMA],
- period_ns);
+ if (val & RING_WAIT_SEMAPHORE)
+ add_sample(&pmu->sample[I915_SAMPLE_SEMA],
+ period_ns);
+ }
}
-
- if (fw)
- intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+ intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
intel_runtime_pm_put(dev_priv, wakeref);
}
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't use the second dbuf slice on icl
Hi,
On Mon, Jan 21, 2019 at 9:01 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> The code managing the dbuf slices is borked and needs some
> real work to fix. In the meantime let's just stop using the
> second slice.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 8b63afa3a221..1e41c899ffe2 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3618,7 +3618,8 @@ static u8 intel_enabled_dbuf_slices_num(struct
> drm_i915_private *dev_priv)
> enabled_slices = 1;
>
> /* Gen prior to GEN11 have only one DBuf slice */
> - if (INTEL_GEN(dev_priv) < 11)
> + /* FIXME dbuf slice code is broken: see intel_get_ddb_size() */
> + if (1 || INTEL_GEN(dev_priv) < 11)
> return enabled_slices;
IMHO we may not need this, If we return from above we'll never disable
second slice in case it's enabled by bios.
Anyhow code changes in intel_get_ddb_size will take care of enabling
only one slice.
>
> if (I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE)
> @@ -3827,8 +3828,13 @@ static u16 intel_get_ddb_size(struct drm_i915_private
> *dev_priv,
>
> /*
> * 12GB/s is maximum BW supported by single DBuf slice.
> +*
> +* FIXME dbuf slice code is broken:
> +* - must wait for planes to stop using the slice before powering it
> off
AFAIR we're already doing it and disabling slice only after
update_crtcs, and skl_update_crtcs code is taking care of waiting for
vblank in case it's required.
> +* - plane straddling both slices is illegal in multi-pipe scenarios
This is something new :)
although this change introduce a major limitation with number and size
of planes we can display, yet
As code is broken and mentioned conditions need to be taken care of,
This change should be ok until proper fix.
~Mahesh
> +* - should validate we stay within the hw bandwidth limits
> */
> - if (num_active > 1 || total_data_bw >= GBps(12)) {
> + if (0 && (num_active > 1 || total_data_bw >= GBps(12))) {
> ddb->enabled_slices = 2;
> } else {
> ddb->enabled_slices = 1;
> --
> 2.19.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/38] drm/i915: Introduce the i915_user_extension_method
On 18/01/2019 14:00, Chris Wilson wrote:
An idea for extending uABI inspired by Vulkan's extension chains.
Instead of expanding the data struct for each ioctl every time we need
to add a new feature, define an extension chain instead. As we add
optional interfaces to control the ioctl, we define a new extension
struct that can be linked into the ioctl data only when required by the
user. The key advantage being able to ignore large control structs for
optional interfaces/extensions, while being able to process them in a
consistent manner.
In comparison to other extensible ioctls, the key difference is the
use of a linked chain of extension structs vs an array of tagged
pointers. For example,
struct drm_amdgpu_cs_chunk {
__u32 chunk_id;
__u32 length_dw;
__u64 chunk_data;
};
struct drm_amdgpu_cs_in {
__u32 ctx_id;
__u32 bo_list_handle;
__u32 num_chunks;
__u32 _pad;
__u64 chunks;
};
allows userspace to pass in array of pointers to extension structs, but
must therefore keep constructing that array along side the command stream.
In dynamic situations like that, a linked list is preferred and does not
similar from extra cache line misses as the extension structs themselves
s/similar/suffer/ I think.
must still be loaded separate to the chunks array.
v2: Apply the tail call optimisation directly to nip the worry of stack
overflow in the bud.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_user_extensions.c | 42 +
drivers/gpu/drm/i915/i915_user_extensions.h | 20 ++
include/uapi/drm/i915_drm.h | 20 ++
4 files changed, 83 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_user_extensions.c
create mode 100644 drivers/gpu/drm/i915/i915_user_extensions.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 65ed00db..f206fbc85cee 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -45,6 +45,7 @@ i915-y := i915_drv.o \
i915_sw_fence.o \
i915_syncmap.o \
i915_sysfs.o \
+ i915_user_extensions.o \
intel_csr.o \
intel_device_info.o \
intel_pm.o \
diff --git a/drivers/gpu/drm/i915/i915_user_extensions.c
b/drivers/gpu/drm/i915/i915_user_extensions.c
new file mode 100644
index ..5d90c368f185
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_user_extensions.c
@@ -0,0 +1,42 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "i915_user_extensions.h"
+
+int i915_user_extensions(struct i915_user_extension __user *ext,
+const i915_user_extension_fn *tbl,
+unsigned long count,
I would be tempted to limit the count to unsigned int. 4 billion
extensions should be enough for everyone. :)
ABI can remain u64, but implementation I think in this form does not
need it.
+void *data)
+{
+ while (ext) {
+ int err;
+ u64 x;
+
+ cond_resched();
+ if (signal_pending(current))
+ return -EINTR;
What was your thinking behind this? It feels like, since here we are not
doing any explicit wait/sleeps, that at this level the code shouldn't
bother with it.
+
+ if (get_user(x, &ext->name))
+ return -EFAULT;
+
+ err = -EINVAL;
+ if (x < count && tbl[x])
+ err = tbl[x](ext, data);
+ if (err)
+ return err;
We talked about providing unwind on failure ie. option for destructor
call backs. You gave up on that?
+
+ if (get_user(x, &ext->next_extension))
+ return -EFAULT;
+
+ ext = u64_to_user_ptr(x);
+ }
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/i915_user_extensions.h
b/drivers/gpu/drm/i915/i915_user_extensions.h
new file mode 100644
index ..313a510b068a
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_user_extensions.h
@@ -0,0 +1,20 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#ifndef I915_USER_EXTENSIONS_H
+#define I915_USER_EXTENSIONS_H
+
+struct i915_user_extension;
+
+typedef int (*i915_user_extension_fn)(struct i915_user_extension __user *ext,
+ void *data);
+
+int i915_user_extensions(struct i915_user_extension __user *ext,
+const i915_user_extension_fn *tbl,
+unsigned long count,
+void *data);
+
+#endif /* I915_USER_EXTENSIONS_H */
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 298b2e197
Re: [Intel-gfx] [PATCH 18/34] drm/i915/selftests: Use common mock_engine::advance
On 21/01/2019 22:21, Chris Wilson wrote:
Replace the open-coding of advance with a call instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/mock_engine.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_engine.c
b/drivers/gpu/drm/i915/selftests/mock_engine.c
index 968a7e139a67..386dfa7e2d5c 100644
--- a/drivers/gpu/drm/i915/selftests/mock_engine.c
+++ b/drivers/gpu/drm/i915/selftests/mock_engine.c
@@ -67,11 +67,10 @@ static struct mock_request *first_request(struct
mock_engine *engine)
link);
}
-static void advance(struct mock_engine *engine,
- struct mock_request *request)
+static void advance(struct mock_request *request)
{
list_del_init(&request->link);
- mock_seqno_advance(&engine->base, request->base.global_seqno);
+ mock_seqno_advance(request->base.engine, request->base.global_seqno);
}
static void hw_delay_complete(struct timer_list *t)
@@ -84,7 +83,7 @@ static void hw_delay_complete(struct timer_list *t)
/* Timer fired, first request is complete */
request = first_request(engine);
if (request)
- advance(engine, request);
+ advance(request);
/*
* Also immediately signal any subsequent 0-delay requests, but
@@ -96,7 +95,7 @@ static void hw_delay_complete(struct timer_list *t)
break;
}
- advance(engine, request);
+ advance(request);
}
spin_unlock(&engine->hw_lock);
@@ -180,7 +179,7 @@ static void mock_submit_request(struct i915_request
*request)
if (mock->delay)
mod_timer(&engine->hw_delay, jiffies + mock->delay);
else
- advance(engine, mock);
+ advance(mock);
}
spin_unlock_irq(&engine->hw_lock);
}
@@ -240,10 +239,8 @@ void mock_engine_flush(struct intel_engine_cs *engine)
del_timer_sync(&mock->hw_delay);
spin_lock_irq(&mock->hw_lock);
- list_for_each_entry_safe(request, rn, &mock->hw_queue, link) {
- list_del_init(&request->link);
- mock_seqno_advance(&mock->base, request->base.global_seqno);
- }
+ list_for_each_entry_safe(request, rn, &mock->hw_queue, link)
+ advance(request);
spin_unlock_irq(&mock->hw_lock);
}
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/34] drm/i915: Tidy common test_bit probing of i915_request->fence.flags
On 21/01/2019 22:21, Chris Wilson wrote:
A repeated pattern is to test the signaled bit of our
request->fence.flags. Make this an inline to shorten a few lines and
remove unnecessary line continuations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 3 +--
drivers/gpu/drm/i915/i915_request.c | 2 +-
drivers/gpu/drm/i915/i915_request.h | 5 +
drivers/gpu/drm/i915/intel_breadcrumbs.c | 3 +--
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +--
7 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1abfc3fa76ad..5fd5080c4ccb 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1182,8 +1182,7 @@ static void notify_ring(struct intel_engine_cs *engine)
struct i915_request *waiter = wait->request;
if (waiter &&
- !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
- &waiter->fence.flags) &&
+ !i915_request_signaled(waiter) &&
intel_wait_check_request(wait, waiter))
rq = i915_request_get(waiter);
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index 80232de8e2be..2721a356368f 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -198,7 +198,7 @@ static void __retire_engine_request(struct intel_engine_cs
*engine,
spin_unlock(&engine->timeline.lock);
spin_lock(&rq->lock);
- if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &rq->fence.flags))
+ if (!i915_request_signaled(rq))
dma_fence_signal_locked(&rq->fence);
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &rq->fence.flags))
intel_engine_cancel_signaling(rq);
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index d014b0605445..c0f084ca4f29 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -280,6 +280,11 @@ long i915_request_wait(struct i915_request *rq,
#define I915_WAIT_ALL BIT(3) /* used by i915_gem_object_wait() */
#define I915_WAIT_FOR_IDLE_BOOST BIT(4)
+static inline bool i915_request_signaled(const struct i915_request *rq)
+{
+ return test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &rq->fence.flags);
+}
+
static inline bool intel_engine_has_started(struct intel_engine_cs *engine,
u32 seqno);
static inline bool intel_engine_has_completed(struct intel_engine_cs *engine,
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 4fad93fe3678..b58915b8708b 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -631,8 +631,7 @@ static int intel_breadcrumbs_signaler(void *arg)
rq->signaling.wait.seqno = 0;
__list_del_entry(&rq->signaling.link);
-if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
- &rq->fence.flags)) {
+ if (!i915_request_signaled(rq)) {
list_add_tail(&rq->signaling.link,
&list);
i915_request_get(rq);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index bc65d8006e16..464dd309fa99 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -855,7 +855,7 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
list_for_each_entry(rq, &engine->timeline.requests, link) {
GEM_BUG_ON(!rq->global_seqno);
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &rq->fence.flags))
+ if (i915_request_signaled(rq))
continue;
dma_fence_set_error(&rq->fence, -EIO);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8b63afa3a221..fdc28a3d2936 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6662,7 +6662,7 @@ void gen6_rps_boost(struct i915_request *rq,
if (!rps->enabled)
return;
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &rq->fence.flags))
+ if (i915_request_signaled(rq))
return;
/* Serializes with i915_request_retire() */
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 66dc8e2fa353..bc620ae297b4 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -876,8 +876,7 @@ static void cancel_requests(struct intel_engine_cs *engine)
Re: [Intel-gfx] [PATCH 1/3] drm: Add debug prints for the various object lookup errors
On Mon, Jan 21, 2019 at 10:24:28PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Only some of the drm mode object lookups have a corresponding debug
> print for the lookup failure. That makes logs a bit hard to parse
> when you can't see where the bad object ID is being used. Add a bunch
> more debug prints, and unify their appearance.
>
> Signed-off-by: Ville Syrjälä
Instead of sprinkling these all over, what about the reverse route and
pushing this into drm_mode_object_find? We can dump id + object type, that
should be all we need really. If we go this way maybe add kerneldoc to the
various drm_*_find/lookup functions so this doesn't get copypasted again
...
-Daniel
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 5 +
> drivers/gpu/drm/drm_color_mgmt.c | 8 ++--
> drivers/gpu/drm/drm_connector.c | 5 -
> drivers/gpu/drm/drm_crtc.c| 12 +++-
> drivers/gpu/drm/drm_encoder.c | 4 +++-
> drivers/gpu/drm/drm_framebuffer.c | 4 +++-
> drivers/gpu/drm/drm_mode_object.c | 17 ++---
> drivers/gpu/drm/drm_plane.c | 13 +
> drivers/gpu/drm/drm_property.c| 12 +---
> drivers/gpu/drm/drm_vblank.c | 8 ++--
> 10 files changed, 66 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 9a1f41adfc67..06390307e5a3 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1321,11 +1321,14 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>
> obj = drm_mode_object_find(dev, file_priv, obj_id,
> DRM_MODE_OBJECT_ANY);
> if (!obj) {
> + DRM_DEBUG_ATOMIC("Unknown object ID %d\n", obj_id);
> ret = -ENOENT;
> goto out;
> }
>
> if (!obj->properties) {
> + DRM_DEBUG_ATOMIC("Object ID %d has no properties\n",
> + obj_id);
> drm_mode_object_put(obj);
> ret = -ENOENT;
> goto out;
> @@ -1352,6 +1355,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>
> prop = drm_mode_obj_find_prop_id(obj, prop_id);
> if (!prop) {
> + DRM_DEBUG_ATOMIC("Unknown property ID %d\n",
> + prop_id);
> drm_mode_object_put(obj);
> ret = -ENOENT;
> goto out;
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 07dcf47daafe..a99ee15b8328 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -245,8 +245,10 @@ int drm_mode_gamma_set_ioctl(struct drm_device *dev,
> return -EOPNOTSUPP;
>
> crtc = drm_crtc_find(dev, file_priv, crtc_lut->crtc_id);
> - if (!crtc)
> + if (!crtc) {
> + DRM_DEBUG_KMS("Unknown CRTC ID %d\n", crtc_lut->crtc_id);
> return -ENOENT;
> + }
>
> if (crtc->funcs->gamma_set == NULL)
> return -ENOSYS;
> @@ -313,8 +315,10 @@ int drm_mode_gamma_get_ioctl(struct drm_device *dev,
> return -EOPNOTSUPP;
>
> crtc = drm_crtc_find(dev, file_priv, crtc_lut->crtc_id);
> - if (!crtc)
> + if (!crtc) {
> + DRM_DEBUG_KMS("Unknown CRTC ID %d\n", crtc_lut->crtc_id);
> return -ENOENT;
> + }
>
> /* memcpy into gamma store */
> if (crtc_lut->gamma_size != crtc->gamma_size)
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 847539645558..8745eb132fd4 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1952,8 +1952,11 @@ int drm_mode_getconnector(struct drm_device *dev, void
> *data,
> memset(&u_mode, 0, sizeof(struct drm_mode_modeinfo));
>
> connector = drm_connector_lookup(dev, file_priv,
> out_resp->connector_id);
> - if (!connector)
> + if (!connector) {
> + DRM_DEBUG_KMS("Unknown connector ID %d\n",
> + out_resp->connector_id);
> return -ENOENT;
> + }
>
> drm_connector_for_each_possible_encoder(connector, encoder, i)
> encoders_count++;
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 7dabbaf033a1..e5f234ffcd23 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -369,8 +369,10 @@ int drm_mode_getcrtc(struct drm_device *dev,
> return -EOPNOTSUPP;
>
> crtc = drm_crtc_find(dev, file_priv, crtc_resp->crtc_id);
> - if (!crtc)
> + if (!crtc) {
> + DRM_DEBUG_KMS("Unknown CRTC ID %d\n", crtc_resp->crtc_id);
> return -ENOENT;
> + }
>
> plane = crtc->primary;
>
> @@ -586
Re: [Intel-gfx] [PATCH 2/3] drm: Sync errno values for property lookup errors
On Mon, Jan 21, 2019 at 10:24:29PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use ENOENT consistently for the case where the requested property
> isn't found, and EINVAL for the case where the object has no
> properties whatsoever. Currenrly these are handled differently
> in the atomic and legacy codepaths.
>
> Signed-off-by: Ville Syrjälä
Matches
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values
Reviewed-by: Daniel Vetter
Any igts that blow up with this? We should have at least some trying to do
invalid stuff ...
-Daniel
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
> drivers/gpu/drm/drm_mode_object.c | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 06390307e5a3..2a54f826cf65 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1330,7 +1330,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> DRM_DEBUG_ATOMIC("Object ID %d has no properties\n",
>obj_id);
> drm_mode_object_put(obj);
> - ret = -ENOENT;
> + ret = -EINVAL;
> goto out;
> }
>
> diff --git a/drivers/gpu/drm/drm_mode_object.c
> b/drivers/gpu/drm/drm_mode_object.c
> index e8dac94d576d..31730d935842 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -527,6 +527,7 @@ int drm_mode_obj_set_property_ioctl(struct drm_device
> *dev, void *data,
> property = drm_mode_obj_find_prop_id(arg_obj, arg->prop_id);
> if (!property) {
> DRM_DEBUG_KMS("Unknown property ID %d\n", arg->prop_id);
> + ret = -ENOENT;
> goto out_unref;
> }
>
> --
> 2.19.2
>
> ___
> 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm: Add a debug print for drm_modeset_backoff()
On Mon, Jan 21, 2019 at 10:24:30PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Logs can get confusing when some operations are done multiple times
> due to the ww mutex backoff. Add a debug print into
> drm_modeset_backoff() so that at least the reason for the odd
> looking logs will be obvious.
>
> Signed-off-by: Ville Syrjälä
Makes sense. Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_modeset_lock.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c
> b/drivers/gpu/drm/drm_modeset_lock.c
> index 81dd11901ffd..1277ff18d993 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -295,6 +295,8 @@ int drm_modeset_backoff(struct drm_modeset_acquire_ctx
> *ctx)
> {
> struct drm_modeset_lock *contended = ctx->contended;
>
> + DRM_DEBUG_KMS("Retrying to avoid deadlock\n");
> +
> ctx->contended = NULL;
>
> if (WARN_ON(!contended))
> --
> 2.19.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/7] drm/i915/crt: split out intel_crt_present() to platform specific setup
== Series Details ==
Series: series starting with [v2,1/7] drm/i915/crt: split out
intel_crt_present() to platform specific setup
URL : https://patchwork.freedesktop.org/series/55540/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5459_full -> Patchwork_12003_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12003_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_schedule@pi-ringfull-blt:
- shard-apl: NOTRUN -> FAIL [fdo#103158]
* igt@kms_content_protection@legacy:
- shard-apl: NOTRUN -> FAIL [fdo#108597]
* igt@kms_cursor_crc@cursor-128x42-sliding:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-wc:
- shard-glk: PASS -> FAIL [fdo#103167]
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl: PASS -> FAIL [fdo#103166]
Possible fixes
* igt@kms_busy@extended-pageflip-hang-oldfb-render-b:
- shard-snb: {SKIP} [fdo#109271] / [fdo#109278] -> PASS
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-apl: DMESG-WARN [fdo#107956] -> PASS +1
* igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
- shard-glk: FAIL [fdo#108145] -> PASS
* igt@kms_cursor_crc@cursor-128x42-random:
- shard-apl: FAIL [fdo#103232] -> PASS +1
* igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-untiled:
- shard-snb: {SKIP} [fdo#109271] -> PASS +4
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-glk: FAIL [fdo#103166] -> PASS
* igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl: FAIL -> PASS
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-apl: DMESG-FAIL [fdo#108950] -> PASS
* igt@kms_setmode@basic:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
Warnings
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-glk: DMESG-FAIL [fdo#105763] / [fdo#106538] -> FAIL
[fdo#109381]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103158]: https://bugs.freedesktop.org/show_bug.cgi?id=103158
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
[fdo#106538]: https://bugs.freedesktop.org/show_bug.cgi?id=106538
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108597]: https://bugs.freedesktop.org/show_bug.cgi?id=108597
[fdo#108950]: https://bugs.freedesktop.org/show_bug.cgi?id=108950
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109381]: https://bugs.freedesktop.org/show_bug.cgi?id=109381
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5459 -> Patchwork_12003
CI_DRM_5459: 0f693a275dd91391b476ada7481cf08f4fe610aa @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4780: 1c1612bdc36b44a704095e7b0ba5542818ce793f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12003: f6c1b42bdd25a3c26ffd12155b322eb57131deba @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12003/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Forced push done to drm-intel-next-queued
On Tue, Jan 15, 2019 at 12:46:50PM +0100, Hans de Goede wrote:
> Hi,
>
> On 15-01-19 10:56, Daniel Vetter wrote:
> > On Thu, Dec 27, 2018 at 04:24:51PM +0100, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 27-12-18 15:42, Jani Nikula wrote:
> > > > On Tue, 25 Dec 2018, Hans de Goede wrote:
> > > > > Hi,
> > > > >
> > > > > As mentioned in the "I messed up drm-intel-next-queued!" mail-thread
> > > > > I made a big mistake yesterday:
> > > > >
> > > > > "Ugh, I just messed up drm-intel-next-queued big time.
> > > > >
> > > > > I somehow rebased my work on top of drm-tip (I believe I did the
> > > > > rebase
> > > > > in the wrong dir) and then after running a bunch of tests I
> > > > > did a "dim push-branch drm-intel-next-queued" which pushed the
> > > > > patches I intended to push rebased on top of drm-tip
> > > > > pushing drm-tip to dinq :(
> > > > >
> > > > > I'm so sorry about this.
> > > > >
> > > > > I just checked my reflog and the last commit before me messing
> > > > > up is commit d4de753526f4d99f541f1b6ed1d963005c09700c
> > > > > ("drm/i915: Unwind failure on pinning the gen7 ppgtt")"
> > > > >
> > > > > To fix this I've just done a forced push resetting
> > > > > drm-intel-next-queued to the mentioned d4de753526f4 commit.
> > > > >
> > > > > I first checked no-one pushed anything on top of my mess,
> > > > > but if you pushed anything to drm-intel-next-queued in the
> > > > > last 24 hours, please double-check it is there.
> > > > >
> > > > > Once more my apologies for this.
> > > >
> > > > It happens, don't worry about it. Thanks for being open about it instead
> > > > of trying to brush it under the rug.
> > >
> > > Thanks.
> > >
> > > > Did you pass -f to dim? I suspect drm-tip wouldn't pass the push checks
> > > > in dim without it. Perhaps we'll need to add more.
> > >
> > > No I did not pass -f, I did wonder myself how the push managed to
> > > proceed after my screw-up. Looking at how dim builds drm-tip, it seems
> > > it starts with dinq and then merges in other branches, so a push
> > > from a drm-tip based branch to dinq is a fast-forward (I think),
> > > so dinq is special in this case.
> >
> > Do you still have the git tree you've pushed wrongly and could publish it
> > somewhere? I'm suprised that dim push didn't catch this, we've added a few
> > more sanity checks last time around this happened. I'd have expected dim
> > to complain about all the patches lacking you're signed-off-by, since a
> > rebase would have changed a lot of patches to be committed by you.
>
> I'm afraid I don't have that tree around anymore. What I did was I
> accidentally
> rebased the 2 patches I wanted to push on top of drm-tip, so I pushed the
> last drm-tip push (including the integration manifest) with my 2 patches on
> top.
>
> So I pushed the latest unmodified state of drm-tip and none of the patches
> in there were re-commited by me during the rebase.
>
> Basically what I believe I pushed is a fast-forward from dinq to drm-tip +
> the 2 patches I intended to push.
Hm right we filter for committer, so if you're not the one who pushed the
very latest drm-tip then all the merge commits in there (and the
integration manifest) won't trigger and checks of dim push.
> I even did a gitk before pushing to graphically check what I was pushing
> (I always do this) and I saw my 2 patches on top of a remote branch, which
> looked fine. What I did not notice it was the wrong remote and the wrong
> branch. This is something which I've learned to also check now.
>
> One check which I believe would have caught this is checking there are no
> merge-commits in what is being pushed and require some commandline option
> to override this for special cases.
The problem with that is that you train maintainers (who routinely need to
push merge commits, that's their job) to ignore dim warnings. Which also
is not great. Jani&me had a few discussions and failed starts (had to back
a few changes out of dim again), not sure what exactly we could check more
now :-(
I guess mea culpa, perhaps we'll come up with a better idea in the future.
Thanks anyway for helping with debugging this tooling issue.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf: Enhance dma-fence tracing
Quoting Daniel Vetter (2019-01-22 09:11:53) > On Tue, Jan 22, 2019 at 10:06 AM Chris Wilson > wrote: > > > > Quoting Koenig, Christian (2019-01-22 08:49:30) > > > Am 22.01.19 um 00:20 schrieb Chris Wilson: > > > > Rather than every backend and GPU driver reinventing the same wheel for > > > > user level debugging of HW execution, the common dma-fence framework > > > > should include the tracing infrastructure required for most client API > > > > level flow visualisation. > > > > > > > > With these common dma-fence level tracepoints, the userspace tools can > > > > establish a detailed view of the client <-> HW flow across different > > > > kernels. There is a strong ask to have this available, so that the > > > > userspace developer can effectively assess if they're doing a good job > > > > about feeding the beast of a GPU hardware. > > > > > > > > In the case of needing to look into more fine-grained details of how > > > > kernel internals work towards the goal of feeding the beast, the tools > > > > may optionally amend the dma-fence tracing information with the driver > > > > implementation specific. But for such cases, the tools should have a > > > > graceful degradation in case the expected extra tracepoints have > > > > changed or their format differs from the expected, as the kernel > > > > implementation internals are not expected to stay the same. > > > > > > > > It is important to distinguish between tracing for the purpose of client > > > > flow visualisation and tracing for the purpose of low-level kernel > > > > debugging. The latter is highly implementation specific, tied to > > > > a particular HW and driver, whereas the former addresses a common goal > > > > of user level tracing and likely a common set of userspace tools. > > > > Having made the distinction that these tracepoints will be consumed for > > > > client API tooling, we raise the spectre of tracepoint ABI stability. It > > > > is hoped that by defining a common set of dma-fence tracepoints, we > > > > avoid > > > > the pitfall of exposing low level details and so restrict ourselves only > > > > to the high level flow that is applicable to all drivers and hardware. > > > > Thus the reserved guarantee that this set of tracepoints will be stable > > > > (with the emphasis on depicting client <-> HW flow as opposed to > > > > driver <-> HW). > > > > > > > > In terms of specific changes to the dma-fence tracing, we remove the > > > > emission of the strings for every tracepoint (reserving them for > > > > dma_fence_init for cases where they have unique dma_fence_ops, and > > > > preferring to have descriptors for the whole fence context). strings do > > > > not pack as well into the ftrace ringbuffer and we would prefer to > > > > reduce the amount of indirect callbacks required for frequent tracepoint > > > > emission. > > > > > > > > Signed-off-by: Chris Wilson > > > > Cc: Joonas Lahtinen > > > > Cc: Tvrtko Ursulin > > > > Cc: Alex Deucher > > > > Cc: "Christian König" > > > > Cc: Eric Anholt > > > > Cc: Pierre-Loup Griffais > > > > Cc: Michael Sartain > > > > Cc: Steven Rostedt > > > > > > In general yes please! If possible please separate out the changes to > > > the common dma_fence infrastructure from the i915 changes. > > > > Sure, I was just stressing the impact: remove some randomly placed > > internal debugging tracepoints, try to define useful ones instead :) > > > > On the list of things to do was to convert at least 2 other drivers > > (I was thinking nouveau/msm for simplicity, vc4 for a simpler > > introduction to drm_sched than amdgpu) over to be sure we have the right > > tracepoints. > > I think sprinkling these over the scheduler (maybe just as an opt-in, > for the case where the driver doesn't have some additional queueing > somewhere) would be good. I haven't checked whether it fits, but would > give you a bunch of drivers at once. It might also not cover all the > cases (I guess the wait related ones would need to be somewhere else). And the other thing (that got explicitly asked for!) was that we have some igt to make sure we don't surreptitiously break the tracepoints in future. Another task would to devise the set of tracepoints to describe the modesetting flow; that more or less is the flow of atomic helpers I guess: prepare; wait-on-fences; commit; signal; cleanup. For system snooping, knowing a target frame (msc or ust) and how late it was delayed and the HW execution flow up to the frame and being able to tie that back to the GL/VK client is the grand plan. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf: Enhance dma-fence tracing
On Tue, Jan 22, 2019 at 10:58 AM Chris Wilson wrote: > > Quoting Daniel Vetter (2019-01-22 09:11:53) > > On Tue, Jan 22, 2019 at 10:06 AM Chris Wilson > > wrote: > > > > > > Quoting Koenig, Christian (2019-01-22 08:49:30) > > > > Am 22.01.19 um 00:20 schrieb Chris Wilson: > > > > > Rather than every backend and GPU driver reinventing the same wheel > > > > > for > > > > > user level debugging of HW execution, the common dma-fence framework > > > > > should include the tracing infrastructure required for most client API > > > > > level flow visualisation. > > > > > > > > > > With these common dma-fence level tracepoints, the userspace tools can > > > > > establish a detailed view of the client <-> HW flow across different > > > > > kernels. There is a strong ask to have this available, so that the > > > > > userspace developer can effectively assess if they're doing a good job > > > > > about feeding the beast of a GPU hardware. > > > > > > > > > > In the case of needing to look into more fine-grained details of how > > > > > kernel internals work towards the goal of feeding the beast, the tools > > > > > may optionally amend the dma-fence tracing information with the driver > > > > > implementation specific. But for such cases, the tools should have a > > > > > graceful degradation in case the expected extra tracepoints have > > > > > changed or their format differs from the expected, as the kernel > > > > > implementation internals are not expected to stay the same. > > > > > > > > > > It is important to distinguish between tracing for the purpose of > > > > > client > > > > > flow visualisation and tracing for the purpose of low-level kernel > > > > > debugging. The latter is highly implementation specific, tied to > > > > > a particular HW and driver, whereas the former addresses a common goal > > > > > of user level tracing and likely a common set of userspace tools. > > > > > Having made the distinction that these tracepoints will be consumed > > > > > for > > > > > client API tooling, we raise the spectre of tracepoint ABI stability. > > > > > It > > > > > is hoped that by defining a common set of dma-fence tracepoints, we > > > > > avoid > > > > > the pitfall of exposing low level details and so restrict ourselves > > > > > only > > > > > to the high level flow that is applicable to all drivers and hardware. > > > > > Thus the reserved guarantee that this set of tracepoints will be > > > > > stable > > > > > (with the emphasis on depicting client <-> HW flow as opposed to > > > > > driver <-> HW). > > > > > > > > > > In terms of specific changes to the dma-fence tracing, we remove the > > > > > emission of the strings for every tracepoint (reserving them for > > > > > dma_fence_init for cases where they have unique dma_fence_ops, and > > > > > preferring to have descriptors for the whole fence context). strings > > > > > do > > > > > not pack as well into the ftrace ringbuffer and we would prefer to > > > > > reduce the amount of indirect callbacks required for frequent > > > > > tracepoint > > > > > emission. > > > > > > > > > > Signed-off-by: Chris Wilson > > > > > Cc: Joonas Lahtinen > > > > > Cc: Tvrtko Ursulin > > > > > Cc: Alex Deucher > > > > > Cc: "Christian König" > > > > > Cc: Eric Anholt > > > > > Cc: Pierre-Loup Griffais > > > > > Cc: Michael Sartain > > > > > Cc: Steven Rostedt > > > > > > > > In general yes please! If possible please separate out the changes to > > > > the common dma_fence infrastructure from the i915 changes. > > > > > > Sure, I was just stressing the impact: remove some randomly placed > > > internal debugging tracepoints, try to define useful ones instead :) > > > > > > On the list of things to do was to convert at least 2 other drivers > > > (I was thinking nouveau/msm for simplicity, vc4 for a simpler > > > introduction to drm_sched than amdgpu) over to be sure we have the right > > > tracepoints. > > > > I think sprinkling these over the scheduler (maybe just as an opt-in, > > for the case where the driver doesn't have some additional queueing > > somewhere) would be good. I haven't checked whether it fits, but would > > give you a bunch of drivers at once. It might also not cover all the > > cases (I guess the wait related ones would need to be somewhere else). > > And the other thing (that got explicitly asked for!) was that we have > some igt to make sure we don't surreptitiously break the tracepoints > in future. > > Another task would to devise the set of tracepoints to describe the > modesetting flow; that more or less is the flow of atomic helpers I > guess: prepare; wait-on-fences; commit; signal; cleanup. For system > snooping, knowing a target frame (msc or ust) and how late it was > delayed and the HW execution flow up to the frame and being able to tie > that back to the GL/VK client is the grand plan. Yeah with atomic helpers this should be doable, as long as the driver uses the commit tracking part of the helpers. That's the st
Re: [Intel-gfx] [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
On Fri, Jan 18, 2019 at 12:17:05PM +, Eric Wong wrote:
> @@ -5411,6 +5411,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20,
> quirk_iommu_g4x_gfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_g4x_gfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, quirk_iommu_g4x_gfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e90, quirk_iommu_g4x_gfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0044, quirk_iommu_g4x_gfx);
>
> static void quirk_iommu_rwbf(struct pci_dev *dev)
> {
> @@ -5457,7 +5458,6 @@ static void quirk_calpella_no_shadow_gtt(struct pci_dev
> *dev)
> }
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0040,
> quirk_calpella_no_shadow_gtt);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0044,
> quirk_calpella_no_shadow_gtt);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0062,
> quirk_calpella_no_shadow_gtt);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x006a,
> quirk_calpella_no_shadow_gtt);
This seems to make sense to me. Joonas, any comments or objections?
Regards,
Joerg
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
On Tue, Jan 22, 2019 at 11:39 AM Joerg Roedel wrote:
>
> On Fri, Jan 18, 2019 at 12:17:05PM +, Eric Wong wrote:
> > @@ -5411,6 +5411,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20,
> > quirk_iommu_g4x_gfx);
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_g4x_gfx);
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, quirk_iommu_g4x_gfx);
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e90, quirk_iommu_g4x_gfx);
> > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0044, quirk_iommu_g4x_gfx);
> >
> > static void quirk_iommu_rwbf(struct pci_dev *dev)
> > {
> > @@ -5457,7 +5458,6 @@ static void quirk_calpella_no_shadow_gtt(struct
> > pci_dev *dev)
> > }
> > }
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0040,
> > quirk_calpella_no_shadow_gtt);
> > -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0044,
> > quirk_calpella_no_shadow_gtt);
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0062,
> > quirk_calpella_no_shadow_gtt);
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x006a,
> > quirk_calpella_no_shadow_gtt);
>
> This seems to make sense to me. Joonas, any comments or objections?
This is ironlake, which has a huge iommu hack in the gpu driver to
work around hard hangs, which:
- causes massive stalls and kills performance
- isn't well tested (it's the only one that needs this), so tends to break
So if we do this then imo we should:
- probably nuke that w/a too (check for needs_idle_maps and all the
related stuff in i915_gem_gtt.c)
- roll it out for all affected chips (i.e. need to include 0x0040).
Note that the string of platforms which have various issues with iommu
and igfx is very long, thus far we only disabled it where there's no
workaround to stop it from hanging the box, but otherwise left it
enabled. So if we make a policy change to also disable it anywhere
where it doesn't work well (instead of not at all), there's a pile
more platforms to switch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/38] drm/i915: Introduce the i915_user_extension_method
Quoting Tvrtko Ursulin (2019-01-22 09:31:31)
>
> On 18/01/2019 14:00, Chris Wilson wrote:
> > +/*
> > + * SPDX-License-Identifier: MIT
> > + *
> > + * Copyright © 2018 Intel Corporation
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include "i915_user_extensions.h"
> > +
> > +int i915_user_extensions(struct i915_user_extension __user *ext,
> > + const i915_user_extension_fn *tbl,
> > + unsigned long count,
>
> I would be tempted to limit the count to unsigned int. 4 billion
> extensions should be enough for everyone. :)
I just picked the natural type, thinking having it the same width as
ARRAY_SIZE might save a few questions from semantic analysers.
> > +{
> > + while (ext) {
> > + int err;
> > + u64 x;
> > +
> > + cond_resched();
> > + if (signal_pending(current))
> > + return -EINTR;
>
> What was your thinking behind this? It feels like, since here we are not
> doing any explicit wait/sleeps, that at this level the code shouldn't
> bother with it.
This ties into the discussion vvv
> > + if (get_user(x, &ext->name))
> > + return -EFAULT;
> > +
> > + err = -EINVAL;
> > + if (x < count && tbl[x])
> > + err = tbl[x](ext, data);
> > + if (err)
> > + return err;
>
> We talked about providing unwind on failure ie. option for destructor
> call backs. You gave up on that?
The patch is simply called 'merde'. Yes, unwind on failure does not lend
itself to a simple tail call implementation :) And it doesn't lend
itself nicely to writing the stacked cleanup handlers either. (So I
stuck with the solution of just doing a single cleanup on failure, safe
in the knowledge that the most complicated case in this series is
trivial.)
Thinking about the issues with providing a stack for unwind, leads to
the nasty question of how big a stack exactly do we want to provide.
Limiting the chain is required for defense against misuse, but what
depth? For the chained parameter setup of a single shot context create,
we could easily be into the dozens of parameters and extensions blocks.
The extreme I've been contemplating is a multi-batch execbuf setup (with
all the fancy extensions for e.g. semi-privileged fancy register setup),
for that I've been thinking about how this interface would extend to
supporting many chained chunks. What makes a good upper bound for stack
depth? 32? 64? 512? Pick a number, it won't be enough for someone. (Now,
really passing that much information through an ioctl means our design
is broken ;)
So... The break on interrupt there was for the silly protection against
recursion, if it doesn't result in an invalid command.
Another reason the patch was called merde.
I think the chained API extension is very powerful. Being able to do
arbitrary things like a single-shot context creation ioctl and still be
able to redefine/extend the interface as needs demands, is compelling.
> > +/*
> > + * i915_user_extension: Base class for defining a chain of extensions
> > + *
> > + * Many interfaces need to grow over time. In most cases we can simply
> > + * extend the struct and have userspace pass in more data. Another option,
> > + * as demonstrated by Vulkan's approach to providing extensions for forward
> > + * and backward compatibility, is to use a list of optional structs to
> > + * provide those extra details.
> > + *
> > + * The key advantage to using an extension chain is that it allows us to
> > + * redefine the interface more easily than an ever growing struct of
> > + * increasing complexity, and for large parts of that interface to be
> > + * entirely optional. The downside is more pointer chasing; chasing across
> > + * the __user boundary with pointers encapsulated inside u64.
> > + */
> > +struct i915_user_extension {
> > + __u64 next_extension;
> > + __u64 name;
>
> s/name/id/ ?
I think name is common parlance for extensions/parameters? At least I've
been using it like it was :) And I was trying to retrospectively restrict
'id' for handles tracked by an idr! :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 23/34] drm/i915: Share per-timeline HWSP using a slab suballocator
On 21/01/2019 22:21, Chris Wilson wrote:
If we restrict ourselves to only using a cacheline for each timeline's
HWSP (we could go smaller, but want to avoid needless polluting
cachelines on different engines between different contexts), then we can
suballocate a single 4k page into 64 different timeline HWSP. By
treating each fresh allocation as a slab of 64 entries, we can keep it
around for the next 64 allocation attempts until we need to refresh the
slab cache.
John Harrison noted the issue of fragmentation leading to the same worst
case performance of one page per timeline as before, which can be
mitigated by adopting a freelist.
v2: Keep all partially allocated HWSP on a freelist
This is still without migration, so it is possible for the system to end
up with each timeline in its own page, but we ensure that no new
allocation would needless allocate a fresh page!
v3: Throw a selftest at the allocator to try and catch invalid cacheline
reuse.
Signed-off-by: Chris Wilson
Cc: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h | 4 +
drivers/gpu/drm/i915/i915_timeline.c | 117 ---
drivers/gpu/drm/i915/i915_timeline.h | 1 +
drivers/gpu/drm/i915/i915_vma.h | 12 ++
drivers/gpu/drm/i915/selftests/i915_random.c | 33 -
drivers/gpu/drm/i915/selftests/i915_random.h | 3 +
.../gpu/drm/i915/selftests/i915_timeline.c| 140 ++
7 files changed, 282 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 364067f811f7..c00eaf2889fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1978,6 +1978,10 @@ struct drm_i915_private {
struct i915_gt_timelines {
struct mutex mutex; /* protects list, tainted by GPU */
struct list_head list;
+
+ /* Pack multiple timelines' seqnos into the same page */
+ spinlock_t hwsp_lock;
+ struct list_head hwsp_free_list;
} timelines;
struct list_head active_rings;
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index 8d5792311a8f..69ee33dfa340 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -9,6 +9,12 @@
#include "i915_timeline.h"
#include "i915_syncmap.h"
+struct i915_timeline_hwsp {
+ struct i915_vma *vma;
+ struct list_head free_link;
+ u64 free_bitmap;
+};
+
static struct i915_vma *__hwsp_alloc(struct drm_i915_private *i915)
{
struct drm_i915_gem_object *obj;
@@ -27,28 +33,92 @@ static struct i915_vma *__hwsp_alloc(struct
drm_i915_private *i915)
return vma;
}
-static int hwsp_alloc(struct i915_timeline *timeline)
+static struct i915_vma *
+hwsp_alloc(struct i915_timeline *timeline, int *offset)
{
- struct i915_vma *vma;
+ struct drm_i915_private *i915 = timeline->i915;
+ struct i915_gt_timelines *gt = &i915->gt.timelines;
+ struct i915_timeline_hwsp *hwsp;
+ int cacheline;
- vma = __hwsp_alloc(timeline->i915);
- if (IS_ERR(vma))
- return PTR_ERR(vma);
+ BUILD_BUG_ON(BITS_PER_TYPE(u64) * CACHELINE_BYTES > PAGE_SIZE);
- timeline->hwsp_ggtt = vma;
- timeline->hwsp_offset = 0;
+ spin_lock(>->hwsp_lock);
- return 0;
+ /* hwsp_free_list only contains HWSP that have available cachelines */
+ hwsp = list_first_entry_or_null(>->hwsp_free_list,
+ typeof(*hwsp), free_link);
+ if (!hwsp) {
+ struct i915_vma *vma;
+
+ spin_unlock(>->hwsp_lock);
+
+ hwsp = kmalloc(sizeof(*hwsp), GFP_KERNEL);
+ if (!hwsp)
+ return ERR_PTR(-ENOMEM);
+
+ vma = __hwsp_alloc(i915);
+ if (IS_ERR(vma)) {
+ kfree(hwsp);
+ return vma;
+ }
+
+ vma->private = hwsp;
+ hwsp->vma = vma;
+ hwsp->free_bitmap = ~0ull;
+
+ spin_lock(>->hwsp_lock);
+ list_add(&hwsp->free_link, >->hwsp_free_list);
+ }
+
+ GEM_BUG_ON(!hwsp->free_bitmap);
+ cacheline = __ffs64(hwsp->free_bitmap);
+ hwsp->free_bitmap &= ~BIT_ULL(cacheline);
+ if (!hwsp->free_bitmap)
+ list_del(&hwsp->free_link);
+
+ spin_unlock(>->hwsp_lock);
+
+ GEM_BUG_ON(hwsp->vma->private != hwsp);
+
+ *offset = cacheline * CACHELINE_BYTES;
+ return hwsp->vma;
+}
+
+static void hwsp_free(struct i915_timeline *timeline)
+{
+ struct i915_gt_timelines *gt = &timeline->i915->gt.timelines;
+ struct i915_timeline_hwsp *hwsp;
+
+ hwsp = i915_timeline_hwsp(timeline);
+ if (!hwsp) /* leave global HWSP alone! */
Later you add i915_timeline_is_g
Re: [Intel-gfx] [PATCH 0/7] drm/i915/perf: add OA interrupt support
Any taker? -Lionel On 16/01/2019 15:36, Lionel Landwerlin wrote: Taking the RFC off this series. To quite the vTune team that tried the previous version : "It reduces data collection overhead in VTune by 11x. It is great!" The GPA team's report on the previous version was a drop in CPU consumption from 17~20% down to 2~3%. This version includes : - a fix for an issue reported by Chris on the IMR register access on Haswell - the ability to completely disable the i915 OA head/tail polling - a new ioctl on the perf stream file descript (not the i915 drm master/render node) to force i915 to look at the OA head/tail register (see explanation in last patch). Cheers, Lionel Landwerlin (7): drm/i915/perf: rework aging tail workaround drm/i915/perf: reset pollin when perf stream is enabled drm/i915/perf: only append status when data is available drm/i915/perf: add new open param to configure polling of OA buffer drm/i915: handle interrupts from the OA unit drm/i915/perf: add interrupt enabling parameter drm/i915/perf: add flushing ioctl drivers/gpu/drm/i915/i915_drv.h | 59 +++- drivers/gpu/drm/i915/i915_irq.c | 39 ++- drivers/gpu/drm/i915/i915_perf.c| 388 +++- drivers/gpu/drm/i915/i915_reg.h | 7 + drivers/gpu/drm/i915/intel_ringbuffer.c | 2 + include/uapi/drm/i915_drm.h | 35 +++ 6 files changed, 357 insertions(+), 173 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
Hi Daniel, On Tue, Jan 22, 2019 at 11:46:39AM +0100, Daniel Vetter wrote: > Note that the string of platforms which have various issues with iommu > and igfx is very long, thus far we only disabled it where there's no > workaround to stop it from hanging the box, but otherwise left it > enabled. So if we make a policy change to also disable it anywhere > where it doesn't work well (instead of not at all), there's a pile > more platforms to switch. I think its best to just disable iommu for the igfx devices on these platforms. Can you pick up Eric's patch and extend it with the list of affected platforms? Thanks, Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/38] drm/i915: Introduce the i915_user_extension_method
On 22/01/2019 10:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-22 09:31:31)
On 18/01/2019 14:00, Chris Wilson wrote:
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "i915_user_extensions.h"
+
+int i915_user_extensions(struct i915_user_extension __user *ext,
+ const i915_user_extension_fn *tbl,
+ unsigned long count,
I would be tempted to limit the count to unsigned int. 4 billion
extensions should be enough for everyone. :)
I just picked the natural type, thinking having it the same width as
ARRAY_SIZE might save a few questions from semantic analysers.
+{
+ while (ext) {
+ int err;
+ u64 x;
+
+ cond_resched();
+ if (signal_pending(current))
+ return -EINTR;
What was your thinking behind this? It feels like, since here we are not
doing any explicit wait/sleeps, that at this level the code shouldn't
bother with it.
This ties into the discussion vvv
+ if (get_user(x, &ext->name))
+ return -EFAULT;
+
+ err = -EINVAL;
+ if (x < count && tbl[x])
+ err = tbl[x](ext, data);
+ if (err)
+ return err;
We talked about providing unwind on failure ie. option for destructor
call backs. You gave up on that?
The patch is simply called 'merde'. Yes, unwind on failure does not lend
itself to a simple tail call implementation :) And it doesn't lend
itself nicely to writing the stacked cleanup handlers either. (So I
stuck with the solution of just doing a single cleanup on failure, safe
in the knowledge that the most complicated case in this series is
trivial.)
Thinking about the issues with providing a stack for unwind, leads to
the nasty question of how big a stack exactly do we want to provide.
Limiting the chain is required for defense against misuse, but what
depth? For the chained parameter setup of a single shot context create,
we could easily be into the dozens of parameters and extensions blocks.
The extreme I've been contemplating is a multi-batch execbuf setup (with
all the fancy extensions for e.g. semi-privileged fancy register setup),
for that I've been thinking about how this interface would extend to
supporting many chained chunks. What makes a good upper bound for stack
depth? 32? 64? 512? Pick a number, it won't be enough for someone. (Now,
really passing that much information through an ioctl means our design
is broken ;)
So... The break on interrupt there was for the silly protection against
recursion, if it doesn't result in an invalid command.
Another reason the patch was called merde.
I think the chained API extension is very powerful. Being able to do
arbitrary things like a single-shot context creation ioctl and still be
able to redefine/extend the interface as needs demands, is compelling.
I did not think about unwind implementation details. :)
We could make the ABI double linked list? But the feeling is bad..
Or have some reasonable stack size and if overflows fall back to a very
inefficient lookup from root to walk backwards. Sounds okay for this use
case since we would never overflow even a small stack, and even the
inefficient walk on unwind would be a) fast and b) rare.
But since you mention stack sizes like 512 I wonder I did not quite
grasp how much you'd want to use extensions in the future. :)
+/*
+ * i915_user_extension: Base class for defining a chain of extensions
+ *
+ * Many interfaces need to grow over time. In most cases we can simply
+ * extend the struct and have userspace pass in more data. Another option,
+ * as demonstrated by Vulkan's approach to providing extensions for forward
+ * and backward compatibility, is to use a list of optional structs to
+ * provide those extra details.
+ *
+ * The key advantage to using an extension chain is that it allows us to
+ * redefine the interface more easily than an ever growing struct of
+ * increasing complexity, and for large parts of that interface to be
+ * entirely optional. The downside is more pointer chasing; chasing across
+ * the __user boundary with pointers encapsulated inside u64.
+ */
+struct i915_user_extension {
+ __u64 next_extension;
+ __u64 name;
s/name/id/ ?
I think name is common parlance for extensions/parameters? At least I've
been using it like it was :) And I was trying to retrospectively restrict
'id' for handles tracked by an idr! :)
I don't know if it is common, it is completely new to me. Maybe it is..
Or how about type?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 23/34] drm/i915: Share per-timeline HWSP using a slab suballocator
Quoting Tvrtko Ursulin (2019-01-22 10:47:11)
>
> On 21/01/2019 22:21, Chris Wilson wrote:
> > If we restrict ourselves to only using a cacheline for each timeline's
> > HWSP (we could go smaller, but want to avoid needless polluting
> > cachelines on different engines between different contexts), then we can
> > suballocate a single 4k page into 64 different timeline HWSP. By
> > treating each fresh allocation as a slab of 64 entries, we can keep it
> > around for the next 64 allocation attempts until we need to refresh the
> > slab cache.
> >
> > John Harrison noted the issue of fragmentation leading to the same worst
> > case performance of one page per timeline as before, which can be
> > mitigated by adopting a freelist.
> >
> > v2: Keep all partially allocated HWSP on a freelist
> >
> > This is still without migration, so it is possible for the system to end
> > up with each timeline in its own page, but we ensure that no new
> > allocation would needless allocate a fresh page!
> >
> > v3: Throw a selftest at the allocator to try and catch invalid cacheline
> > reuse.
> >
> > Signed-off-by: Chris Wilson
> > Cc: John Harrison
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 4 +
> > drivers/gpu/drm/i915/i915_timeline.c | 117 ---
> > drivers/gpu/drm/i915/i915_timeline.h | 1 +
> > drivers/gpu/drm/i915/i915_vma.h | 12 ++
> > drivers/gpu/drm/i915/selftests/i915_random.c | 33 -
> > drivers/gpu/drm/i915/selftests/i915_random.h | 3 +
> > .../gpu/drm/i915/selftests/i915_timeline.c| 140 ++
> > 7 files changed, 282 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 364067f811f7..c00eaf2889fb 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1978,6 +1978,10 @@ struct drm_i915_private {
> > struct i915_gt_timelines {
> > struct mutex mutex; /* protects list, tainted by GPU
> > */
> > struct list_head list;
> > +
> > + /* Pack multiple timelines' seqnos into the same page
> > */
> > + spinlock_t hwsp_lock;
> > + struct list_head hwsp_free_list;
> > } timelines;
> >
> > struct list_head active_rings;
> > diff --git a/drivers/gpu/drm/i915/i915_timeline.c
> > b/drivers/gpu/drm/i915/i915_timeline.c
> > index 8d5792311a8f..69ee33dfa340 100644
> > --- a/drivers/gpu/drm/i915/i915_timeline.c
> > +++ b/drivers/gpu/drm/i915/i915_timeline.c
> > @@ -9,6 +9,12 @@
> > #include "i915_timeline.h"
> > #include "i915_syncmap.h"
> >
> > +struct i915_timeline_hwsp {
> > + struct i915_vma *vma;
> > + struct list_head free_link;
> > + u64 free_bitmap;
> > +};
> > +
> > static struct i915_vma *__hwsp_alloc(struct drm_i915_private *i915)
> > {
> > struct drm_i915_gem_object *obj;
> > @@ -27,28 +33,92 @@ static struct i915_vma *__hwsp_alloc(struct
> > drm_i915_private *i915)
> > return vma;
> > }
> >
> > -static int hwsp_alloc(struct i915_timeline *timeline)
> > +static struct i915_vma *
> > +hwsp_alloc(struct i915_timeline *timeline, int *offset)
> > {
> > - struct i915_vma *vma;
> > + struct drm_i915_private *i915 = timeline->i915;
> > + struct i915_gt_timelines *gt = &i915->gt.timelines;
> > + struct i915_timeline_hwsp *hwsp;
> > + int cacheline;
> >
> > - vma = __hwsp_alloc(timeline->i915);
> > - if (IS_ERR(vma))
> > - return PTR_ERR(vma);
> > + BUILD_BUG_ON(BITS_PER_TYPE(u64) * CACHELINE_BYTES > PAGE_SIZE);
> >
> > - timeline->hwsp_ggtt = vma;
> > - timeline->hwsp_offset = 0;
> > + spin_lock(>->hwsp_lock);
> >
> > - return 0;
> > + /* hwsp_free_list only contains HWSP that have available cachelines */
> > + hwsp = list_first_entry_or_null(>->hwsp_free_list,
> > + typeof(*hwsp), free_link);
> > + if (!hwsp) {
> > + struct i915_vma *vma;
> > +
> > + spin_unlock(>->hwsp_lock);
> > +
> > + hwsp = kmalloc(sizeof(*hwsp), GFP_KERNEL);
> > + if (!hwsp)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + vma = __hwsp_alloc(i915);
> > + if (IS_ERR(vma)) {
> > + kfree(hwsp);
> > + return vma;
> > + }
> > +
> > + vma->private = hwsp;
> > + hwsp->vma = vma;
> > + hwsp->free_bitmap = ~0ull;
> > +
> > + spin_lock(>->hwsp_lock);
> > + list_add(&hwsp->free_link, >->hwsp_free_list);
> > + }
> > +
> > + GEM_BUG_ON(!hwsp->free_bitmap);
> > + cacheline = __ffs64(hwsp->free_bitmap);
> > + hwsp->free_bitmap &= ~BIT_ULL(cacheline);
> > + if (!hwsp->free_bitmap)
> > + list_del(&hwsp->free_li
Re: [Intel-gfx] [PATCH 23/34] drm/i915: Share per-timeline HWSP using a slab suballocator
On 22/01/2019 11:12, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-22 10:47:11)
On 21/01/2019 22:21, Chris Wilson wrote:
If we restrict ourselves to only using a cacheline for each timeline's
HWSP (we could go smaller, but want to avoid needless polluting
cachelines on different engines between different contexts), then we can
suballocate a single 4k page into 64 different timeline HWSP. By
treating each fresh allocation as a slab of 64 entries, we can keep it
around for the next 64 allocation attempts until we need to refresh the
slab cache.
John Harrison noted the issue of fragmentation leading to the same worst
case performance of one page per timeline as before, which can be
mitigated by adopting a freelist.
v2: Keep all partially allocated HWSP on a freelist
This is still without migration, so it is possible for the system to end
up with each timeline in its own page, but we ensure that no new
allocation would needless allocate a fresh page!
v3: Throw a selftest at the allocator to try and catch invalid cacheline
reuse.
Signed-off-by: Chris Wilson
Cc: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h | 4 +
drivers/gpu/drm/i915/i915_timeline.c | 117 ---
drivers/gpu/drm/i915/i915_timeline.h | 1 +
drivers/gpu/drm/i915/i915_vma.h | 12 ++
drivers/gpu/drm/i915/selftests/i915_random.c | 33 -
drivers/gpu/drm/i915/selftests/i915_random.h | 3 +
.../gpu/drm/i915/selftests/i915_timeline.c| 140 ++
7 files changed, 282 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 364067f811f7..c00eaf2889fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1978,6 +1978,10 @@ struct drm_i915_private {
struct i915_gt_timelines {
struct mutex mutex; /* protects list, tainted by GPU */
struct list_head list;
+
+ /* Pack multiple timelines' seqnos into the same page */
+ spinlock_t hwsp_lock;
+ struct list_head hwsp_free_list;
} timelines;
struct list_head active_rings;
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index 8d5792311a8f..69ee33dfa340 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -9,6 +9,12 @@
#include "i915_timeline.h"
#include "i915_syncmap.h"
+struct i915_timeline_hwsp {
+ struct i915_vma *vma;
+ struct list_head free_link;
+ u64 free_bitmap;
+};
+
static struct i915_vma *__hwsp_alloc(struct drm_i915_private *i915)
{
struct drm_i915_gem_object *obj;
@@ -27,28 +33,92 @@ static struct i915_vma *__hwsp_alloc(struct
drm_i915_private *i915)
return vma;
}
-static int hwsp_alloc(struct i915_timeline *timeline)
+static struct i915_vma *
+hwsp_alloc(struct i915_timeline *timeline, int *offset)
{
- struct i915_vma *vma;
+ struct drm_i915_private *i915 = timeline->i915;
+ struct i915_gt_timelines *gt = &i915->gt.timelines;
+ struct i915_timeline_hwsp *hwsp;
+ int cacheline;
- vma = __hwsp_alloc(timeline->i915);
- if (IS_ERR(vma))
- return PTR_ERR(vma);
+ BUILD_BUG_ON(BITS_PER_TYPE(u64) * CACHELINE_BYTES > PAGE_SIZE);
- timeline->hwsp_ggtt = vma;
- timeline->hwsp_offset = 0;
+ spin_lock(>->hwsp_lock);
- return 0;
+ /* hwsp_free_list only contains HWSP that have available cachelines */
+ hwsp = list_first_entry_or_null(>->hwsp_free_list,
+ typeof(*hwsp), free_link);
+ if (!hwsp) {
+ struct i915_vma *vma;
+
+ spin_unlock(>->hwsp_lock);
+
+ hwsp = kmalloc(sizeof(*hwsp), GFP_KERNEL);
+ if (!hwsp)
+ return ERR_PTR(-ENOMEM);
+
+ vma = __hwsp_alloc(i915);
+ if (IS_ERR(vma)) {
+ kfree(hwsp);
+ return vma;
+ }
+
+ vma->private = hwsp;
+ hwsp->vma = vma;
+ hwsp->free_bitmap = ~0ull;
+
+ spin_lock(>->hwsp_lock);
+ list_add(&hwsp->free_link, >->hwsp_free_list);
+ }
+
+ GEM_BUG_ON(!hwsp->free_bitmap);
+ cacheline = __ffs64(hwsp->free_bitmap);
+ hwsp->free_bitmap &= ~BIT_ULL(cacheline);
+ if (!hwsp->free_bitmap)
+ list_del(&hwsp->free_link);
+
+ spin_unlock(>->hwsp_lock);
+
+ GEM_BUG_ON(hwsp->vma->private != hwsp);
+
+ *offset = cacheline * CACHELINE_BYTES;
+ return hwsp->vma;
+}
+
+static void hwsp_free(struct i915_timeline *timeline)
+{
+ struct i915_gt_timelines *gt = &timeline->i915->gt.timelines;
+ struct i915_timeline_hwsp *hwsp;
+
+ hwsp = i915_timeline_hwsp(timeline);
+ if (!hwsp) /* leave global HWSP alone! */
Late
Re: [Intel-gfx] [PATCH 1/4] drm/i915/vbt: Add 'tp4' to varibles holding TP2/3/4 PSR wakeup time
On Wed, 16 Jan 2019, José Roberto de Souza wrote:
> Recent update in spec made the field holding the TP2 and TP3 wakeup
> time for PSR also hold the TP4, so lets rename the variables to
> reflect that.
>
> BSpec: 20131
>
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_bios.c | 16
> drivers/gpu/drm/i915/intel_psr.c | 14 +++---
> drivers/gpu/drm/i915/intel_vbt_defs.h | 2 +-
> 4 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 310d9e1e1620..e717c3132692 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -996,7 +996,7 @@ struct intel_vbt_data {
> int idle_frames;
> enum psr_lines_to_wait lines_to_wait;
> int tp1_wakeup_time_us;
> - int tp2_tp3_wakeup_time_us;
> + int tp2_tp3_tp4_wakeup_time_us;
I think this is too long, perhaps just tp234_wakeup_time_us or
something?
BR,
Jani.
> } psr;
>
> struct {
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 561a4f9f044c..cd99bf88bf6c 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -738,27 +738,27 @@ parse_psr(struct drm_i915_private *dev_priv, const
> struct bdb_header *bdb)
> break;
> }
>
> - switch (psr_table->tp2_tp3_wakeup_time) {
> + switch (psr_table->tp2_tp3_tp4_wakeup_time) {
> case 0:
> - dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 500;
> + dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us = 500;
> break;
> case 1:
> - dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 100;
> + dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us = 100;
> break;
> case 3:
> - dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 0;
> + dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us = 0;
> break;
> default:
> - DRM_DEBUG_KMS("VBT tp2_tp3 wakeup time value %d is
> outside range[0-3], defaulting to max value 2500us\n",
> - psr_table->tp2_tp3_wakeup_time);
> + DRM_DEBUG_KMS("VBT tp2_tp3_tp4 wakeup time value %d is
> outside range[0-3], defaulting to max value 2500us\n",
> + psr_table->tp2_tp3_tp4_wakeup_time);
> /* fallthrough */
> case 2:
> - dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 2500;
> + dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us = 2500;
> break;
> }
> } else {
> dev_priv->vbt.psr.tp1_wakeup_time_us =
> psr_table->tp1_wakeup_time * 100;
> - dev_priv->vbt.psr.tp2_tp3_wakeup_time_us =
> psr_table->tp2_tp3_wakeup_time * 100;
> + dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us =
> psr_table->tp2_tp3_tp4_wakeup_time * 100;
> }
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 0f6b2b4702e3..49b4b3371bef 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -468,11 +468,11 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
> else
> val |= EDP_PSR_TP1_TIME_2500us;
>
> - if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us == 0)
> + if (dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us == 0)
> val |= EDP_PSR_TP2_TP3_TIME_0us;
> - else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 100)
> + else if (dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us <= 100)
> val |= EDP_PSR_TP2_TP3_TIME_100us;
> - else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 500)
> + else if (dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us <= 500)
> val |= EDP_PSR_TP2_TP3_TIME_500us;
> else
> val |= EDP_PSR_TP2_TP3_TIME_2500us;
> @@ -509,12 +509,12 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>
> val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency + 1);
>
> - if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us >= 0 &&
> - dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 50)
> + if (dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us >= 0 &&
> + dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us <= 50)
> val |= EDP_PSR2_TP2_TIME_50us;
> - else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 100)
> + else if (dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us <= 100)
> val |= EDP_PSR2_TP2_TIME_100us;
> - else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 500)
> + else if (dev_p
Re: [Intel-gfx] [PATCH 05/34] drm/i915/selftests: Track evict objects explicitly
On Mon, 21 Jan 2019 at 22:22, Chris Wilson wrote:
>
> During review of commit 71fc448c1aaf ("drm/i915/selftests: Make evict
> tolerant of foreign objects"), Matthew mentioned it would be better if
> we explicitly tracked the objects we created. We have an obj->st_link
> hook for this purpose, so add the corresponding list of objects and
> reduce our loops to only consider our own list.
>
> References: 71fc448c1aaf ("drm/i915/selftests: Make evict tolerant of foreign
> objects")
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: always return something
Patch look ok to me.
On Thu, 2019-01-17 at 12:21 -0800, Lucas De Marchi wrote:
> Even if we don't have the correct clock and get a warning, we should
> not
> skip the return.
>
> Fixes: 1fa11ee2d9d0 ("drm/i915/icl: start adding the TBT pll")
> Cc: Paulo Zanoni
> Cc: # v4.19+
Reviewed-by: Mika Kahola
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 8dbf6c9e22fb..4dc03e8c6c10 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1021,7 +1021,7 @@ static uint32_t icl_pll_to_ddi_pll_sel(struct
> intel_encoder *encoder,
> return DDI_CLK_SEL_TBT_810;
> default:
> MISSING_CASE(clock);
> - break;
> + return DDI_CLK_SEL_NONE;
> }
> case DPLL_ID_ICL_MGPLL1:
> case DPLL_ID_ICL_MGPLL2:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/34] drm/i915/selftests: Create a clean GGTT for vma/gtt selftesting
On Mon, 21 Jan 2019 at 23:41, Chris Wilson wrote: > > Some tests (e.g. igt_vma_pin1) presume that we have a completely clean > GGTT so that it can probe boundaries without fear that something is > already allocated there. However, the mock device is starting to get > complicated and following similar rules to the live device, i.e. we > can't guarantee that i915->ggtt remains clean, so create a temporary > address_space equivalent to the mock ggtt for the purpose. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/psr: Store VBT TP wakeup times into a enum
On Wed, 16 Jan 2019, José Roberto de Souza wrote:
> Newer VBTs and the PSR registers uses a enum to set the TPs wakeup
> time, so lets use this format to store wakeup times and avoid
> conversions every time that PSR is activated.
The VBT is a messy blob of data, and intel_bios.c in many places tries
very hard to abstract and hide all the quirks in there from the
driver. Observe how intel_vbt_defs.h has extra safeguards to try to keep
it private to intel_bios.c. We don't want the VBT implementation details
to leak into the driver.
This patch goes against that abstraction. Please don't do it.
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_drv.h | 12 +-
> drivers/gpu/drm/i915/i915_reg.h | 16 ++--
> drivers/gpu/drm/i915/intel_bios.c | 65 +++
> drivers/gpu/drm/i915/intel_psr.c | 29 ++
> 4 files changed, 47 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e717c3132692..d9893d35f0e2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -959,6 +959,14 @@ enum psr_lines_to_wait {
> PSR_8_LINES_TO_WAIT
> };
>
> +enum psr_tp_wakeup_time {
> + PSR_TP_WAKEUP_TIME_500USEC = 0,
> + PSR_TP_WAKEUP_TIME_100USEC,
> + PSR_TP_WAKEUP_TIME_2500USEC,
> + PSR_TP_WAKEUP_TIME_NONE,
> + PSR_TP_WAKEUP_TIME_LAST
> +};
Here's the problem. This enum now describes both the VBT internals as
well as the hardware register contents. Imagine either the VBT or the
hardware changing to a different bit layout. You'll be in trouble
decoupling them again. (Yeah, they'll say neither will change. They've
said things like that before.)
Moreover, this looks like an innocent enumeration here, separated from
both the VBT parsing and the hardware.
The VBT needs to be described in intel_vbt_defs.h and intel_bios.c, and
the register needs to be desribed in i915_regs.h.
> +
> struct intel_vbt_data {
> struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
> struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
> @@ -995,8 +1003,8 @@ struct intel_vbt_data {
> bool require_aux_wakeup;
> int idle_frames;
> enum psr_lines_to_wait lines_to_wait;
> - int tp1_wakeup_time_us;
> - int tp2_tp3_tp4_wakeup_time_us;
> + enum psr_tp_wakeup_time tp1_wakeup_time;
> + enum psr_tp_wakeup_time tp2_tp3_tp4_wakeup_time;
> } psr;
>
> struct {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index fad5a9e8b44d..5faca634ee70 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4161,14 +4161,8 @@ enum {
> #define EDP_PSR_TP1_TP2_SEL(0 << 11)
> #define EDP_PSR_TP1_TP3_SEL(1 << 11)
> #define EDP_PSR_CRC_ENABLE (1 << 10) /* BDW+ */
> -#define EDP_PSR_TP2_TP3_TIME_500us (0 << 8)
> -#define EDP_PSR_TP2_TP3_TIME_100us (1 << 8)
> -#define EDP_PSR_TP2_TP3_TIME_2500us(2 << 8)
> -#define EDP_PSR_TP2_TP3_TIME_0us (3 << 8)
> -#define EDP_PSR_TP1_TIME_500us (0 << 4)
> -#define EDP_PSR_TP1_TIME_100us (1 << 4)
> -#define EDP_PSR_TP1_TIME_2500us(2 << 4)
> -#define EDP_PSR_TP1_TIME_0us (3 << 4)
> +#define EDP_PSR_TP2_TP3_TIME_SHIFT (8)
> +#define EDP_PSR_TP1_TIME_SHIFT (4)
Please do not remove these. They describe the register contents as we
understand them, and not everyone has access or cares to dig up bspec
every time they need to figure things out.
Side note, parens are superfluous for plain values.
> #define EDP_PSR_IDLE_FRAME_SHIFT 0
>
> /* Bspec claims those aren't shifted but stay at 0x64800 */
> @@ -4234,11 +4228,7 @@ enum {
> #define EDP_Y_COORDINATE_ENABLE(1 << 25) /* GLK and CNL+ */
> #define EDP_MAX_SU_DISABLE_TIME(t) ((t) << 20)
> #define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f << 20)
> -#define EDP_PSR2_TP2_TIME_500us(0 << 8)
> -#define EDP_PSR2_TP2_TIME_100us(1 << 8)
> -#define EDP_PSR2_TP2_TIME_2500us (2 << 8)
> -#define EDP_PSR2_TP2_TIME_50us (3 << 8)
> -#define EDP_PSR2_TP2_TIME_MASK (3 << 8)
> +#define EDP_PSR2_TP2_TP3_TIME_SHIFT(8)
Ditto.
> #define EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
> #define EDP_PSR2_FRAME_BEFORE_SU_MASK (0xf << 4)
> #define EDP_PSR2_FRAME_BEFORE_SU(a)((a) << 4)
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index cd99bf88bf6c..6de6f6f1deec 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -719,46 +719,43 @@ parse_psr(struct drm_i915_private *dev_priv, const
> struct bdb_header *bdb)
> if (bdb->version >= 205 &&
>
Re: [Intel-gfx] [PATCH 3/4] drm/i915/vbt: Parse and use the new field with PSR2 TP2/3/4 wakeup time
On Wed, 16 Jan 2019, José Roberto de Souza wrote:
> A new field with the training pattern(TP) wakeup time for PSR2 was
> added to VBT, so lets use it when available otherwise it will
> fallback to PSR1 wakeup time.
Same problems as with the two previous patches:
- The new field name is too long.
- The abstraction between VBT and hardware is lost.
BR,
Jani.
>
> BSpec: 20131
>
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_drv.h | 8
> drivers/gpu/drm/i915/intel_bios.c | 10 ++
> drivers/gpu/drm/i915/intel_psr.c | 2 +-
> drivers/gpu/drm/i915/intel_vbt_defs.h | 3 +++
> 4 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d9893d35f0e2..e739ed9ce60c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -967,6 +967,13 @@ enum psr_tp_wakeup_time {
> PSR_TP_WAKEUP_TIME_LAST
> };
>
> +enum psr2_tp_wakeup_time {
> + PSR2_TP_WAKEUP_TIME_500USEC = 0,
> + PSR2_TP_WAKEUP_TIME_100USEC,
> + PSR2_TP_WAKEUP_TIME_2500USEC,
> + PSR2_TP_WAKEUP_TIME_50USEC
> +};
> +
> struct intel_vbt_data {
> struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
> struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
> @@ -1005,6 +1012,7 @@ struct intel_vbt_data {
> enum psr_lines_to_wait lines_to_wait;
> enum psr_tp_wakeup_time tp1_wakeup_time;
> enum psr_tp_wakeup_time tp2_tp3_tp4_wakeup_time;
> + enum psr2_tp_wakeup_time psr2_tp2_tp3_tp4_wakeup_time;
> } psr;
>
> struct {
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 6de6f6f1deec..23130e0d5e6c 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -757,6 +757,16 @@ parse_psr(struct drm_i915_private *dev_priv, const
> struct bdb_header *bdb)
>
> dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time = wakeup_time;
> }
> +
> + if (bdb->version >= 226) {
> + u32 wakeup_time = psr_table->psr2_tp2_tp3_tp4_wakeup_time;
> +
> + wakeup_time = (wakeup_time >> (2 * panel_type)) & 0x3;
> + dev_priv->vbt.psr.psr2_tp2_tp3_tp4_wakeup_time = wakeup_time;
> + } else {
> + /* Reusing PSR1 wakeup time for PSR2 in older VBTs */
> + dev_priv->vbt.psr.psr2_tp2_tp3_tp4_wakeup_time =
> dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time;
> + }
> }
>
> static void parse_dsi_backlight_ports(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 5daf0b9e2b42..2fc537fb6e78 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -494,7 +494,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>
> val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency + 1);
>
> - val |= dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time <<
> EDP_PSR2_TP2_TP3_TIME_SHIFT;
> + val |= dev_priv->vbt.psr.psr2_tp2_tp3_tp4_wakeup_time <<
> EDP_PSR2_TP2_TP3_TIME_SHIFT;
>
> I915_WRITE(EDP_PSR2_CTL, val);
> }
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index 4ed66efde49f..dc0a14977953 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -772,6 +772,9 @@ struct psr_table {
> /* TP wake up time in multiple of 100 */
> u16 tp1_wakeup_time;
> u16 tp2_tp3_tp4_wakeup_time;
> +
> + /* PSR2 TP2/TP3/TP4 wakeup time for 16 panels */
> + u32 psr2_tp2_tp3_tp4_wakeup_time;
> } __packed;
>
> struct bdb_psr {
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 24/34] drm/i915: Track the context's seqno in its own timeline HWSP
On 21/01/2019 22:21, Chris Wilson wrote:
Now that we have allocated ourselves a cacheline to store a breadcrumb,
we can emit a write from the GPU into the timeline's HWSP of the
per-context seqno as we complete each request. This drops the mirroring
of the per-engine HWSP and allows each context to operate independently.
We do not need to unwind the per-context timeline, and so requests are
always consistent with the timeline breadcrumb, greatly simplifying the
completion checks as we no longer need to be concerned about the
global_seqno changing mid check.
One complication though is that we have to be wary that the request may
outlive the HWSP and so avoid touching the potentially danging pointer
after we have retired the fence. We also have to guard our access of the
HWSP with RCU, the release of the obj->mm.pages should already be RCU-safe.
At this point, we are emitting both per-context and global seqno and
still using the single per-engine execution timeline for resolving
interrupts.
v2: s/fake_complete/mark_complete/
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_request.c | 3 +-
drivers/gpu/drm/i915/i915_request.h | 30 +++
drivers/gpu/drm/i915/i915_reset.c| 1 +
drivers/gpu/drm/i915/i915_vma.h | 6 ++
drivers/gpu/drm/i915/intel_engine_cs.c | 7 +-
drivers/gpu/drm/i915/intel_lrc.c | 35 +---
drivers/gpu/drm/i915/intel_ringbuffer.c | 88 +++-
drivers/gpu/drm/i915/selftests/mock_engine.c | 20 -
9 files changed, 132 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 761714448ff3..4e0de22f0166 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2890,7 +2890,7 @@ i915_gem_find_active_request(struct intel_engine_cs
*engine)
*/
spin_lock_irqsave(&engine->timeline.lock, flags);
list_for_each_entry(request, &engine->timeline.requests, link) {
- if (__i915_request_completed(request, request->global_seqno))
+ if (i915_request_completed(request))
continue;
active = request;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index d61e86c6a1d1..bb2885f1dc1e 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -199,6 +199,7 @@ static void __retire_engine_request(struct intel_engine_cs
*engine,
spin_unlock(&engine->timeline.lock);
spin_lock(&rq->lock);
+ i915_request_mark_complete(rq);
if (!i915_request_signaled(rq))
dma_fence_signal_locked(&rq->fence);
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &rq->fence.flags))
@@ -621,7 +622,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq->ring = ce->ring;
rq->timeline = ce->ring->timeline;
GEM_BUG_ON(rq->timeline == &engine->timeline);
- rq->hwsp_seqno = &engine->status_page.addr[I915_GEM_HWS_INDEX];
+ rq->hwsp_seqno = rq->timeline->hwsp_seqno;
spin_lock_init(&rq->lock);
dma_fence_init(&rq->fence,
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index ade010fe6e26..96c586d6ff4d 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -289,6 +289,7 @@ long i915_request_wait(struct i915_request *rq,
static inline bool i915_request_signaled(const struct i915_request *rq)
{
+ /* The request may live longer than its HWSP, so check flags first! */
return test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &rq->fence.flags);
}
@@ -340,32 +341,23 @@ static inline u32 hwsp_seqno(const struct i915_request *rq)
*/
static inline bool i915_request_started(const struct i915_request *rq)
{
- u32 seqno;
-
- seqno = i915_request_global_seqno(rq);
- if (!seqno) /* not yet submitted to HW */
- return false;
+ if (i915_request_signaled(rq))
+ return true;
- return i915_seqno_passed(hwsp_seqno(rq), seqno - 1);
-}
-
-static inline bool
-__i915_request_completed(const struct i915_request *rq, u32 seqno)
-{
- GEM_BUG_ON(!seqno);
- return i915_seqno_passed(hwsp_seqno(rq), seqno) &&
- seqno == i915_request_global_seqno(rq);
+ return i915_seqno_passed(hwsp_seqno(rq), rq->fence.seqno - 1);
}
static inline bool i915_request_completed(const struct i915_request *rq)
{
- u32 seqno;
+ if (i915_request_signaled(rq))
+ return true;
- seqno = i915_request_global_seqno(rq);
- if (!seqno)
- return false;
+ return i915_seqno_passed(hwsp_seqno(rq), rq->fence.seqno);
+}
- return __i915_request_completed(rq, seqno);
+static inline void i915_request_mark_complete(struct i915_requ
Re: [Intel-gfx] [PATCH 07/34] drm/i915: Refactor out intel_context_init()
On Mon, 21 Jan 2019 at 23:41, Chris Wilson wrote: > > Prior to adding a third instance of intel_context_init() and extending > the information stored therewithin, refactor out the common assignments. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/34] drm/i915: Show all active engines on hangcheck
Chris Wilson writes:
> This turns out to be quite useful if one happens to be debugging
> semaphore deadlocks.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_hangcheck.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c
> b/drivers/gpu/drm/i915/intel_hangcheck.c
> index 7dc11fcb13de..741441daae32 100644
> --- a/drivers/gpu/drm/i915/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/intel_hangcheck.c
> @@ -195,10 +195,6 @@ static void hangcheck_accumulate_sample(struct
> intel_engine_cs *engine,
> break;
>
> case ENGINE_DEAD:
> - if (GEM_SHOW_DEBUG()) {
> - struct drm_printer p = drm_debug_printer("hangcheck");
> - intel_engine_dump(engine, &p, "%s\n", engine->name);
> - }
> break;
>
> default:
> @@ -285,6 +281,17 @@ static void i915_hangcheck_elapsed(struct work_struct
> *work)
> wedged |= intel_engine_flag(engine);
> }
>
> + if (GEM_SHOW_DEBUG() && (hung | stuck)) {
> + struct drm_printer p = drm_debug_printer("hangcheck");
> +
> + for_each_engine(engine, dev_priv, id) {
> + if (intel_engine_is_idle(engine))
> + continue;
Looks rather harmless tho there is that local_bh_disable.
I was pondering if it was worthwhile to determine idle here
with more lightweight approach, but as we already use
the exact same method on determining hangcheck action, lets
stick to this as it is should be then in parity with the
engine action we got earlier.
Reviewed-by: Mika Kuoppala
> +
> + intel_engine_dump(engine, &p, "%s\n", engine->name);
> + }
> + }
> +
> if (wedged) {
> dev_err(dev_priv->drm.dev,
> "GPU recovery timed out,"
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/34] drm/i915/selftests: Refactor common live_test framework
On Mon, 21 Jan 2019 at 22:22, Chris Wilson wrote: > > Before adding yet another copy of struct live_test and its handler, > refactor the existing code into a common framework for live selftests. > For many live selftests, we want to know if the GPU hung or otherwise > misbehaved during the execution of the test (beyond any infraction in > the behaviour under test), live_test provides this by comparing the > GPU state before and after, alerting if it unexpectedly changed (e.g. > the reset counter changed). It also ensures that the GPU is idle before > and after the test, so that residual code running on the GPU is flushed > before testing. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/34] drm/i915: Refactor out intel_context_init()
Chris Wilson writes:
> Prior to adding a third instance of intel_context_init() and extending
> the information stored therewithin, refactor out the common assignments.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 7 ++-
> drivers/gpu/drm/i915/i915_gem_context.h | 8
> drivers/gpu/drm/i915/selftests/mock_context.c | 7 ++-
> 3 files changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 5933adbe3d99..fae68c4c4683 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -338,11 +338,8 @@ __create_hw_context(struct drm_i915_private *dev_priv,
> ctx->i915 = dev_priv;
> ctx->sched.priority = I915_USER_PRIORITY(I915_PRIORITY_NORMAL);
>
> - for (n = 0; n < ARRAY_SIZE(ctx->__engine); n++) {
> - struct intel_context *ce = &ctx->__engine[n];
> -
> - ce->gem_context = ctx;
> - }
> + for (n = 0; n < ARRAY_SIZE(ctx->__engine); n++)
> + intel_context_init(&ctx->__engine[n], ctx, dev_priv->engine[n]);
>
> INIT_RADIX_TREE(&ctx->handles_vma, GFP_KERNEL);
> INIT_LIST_HEAD(&ctx->handles_list);
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
> b/drivers/gpu/drm/i915/i915_gem_context.h
> index f6d870b1f73e..47d82ce7ba6a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.h
> +++ b/drivers/gpu/drm/i915/i915_gem_context.h
> @@ -364,4 +364,12 @@ static inline void i915_gem_context_put(struct
> i915_gem_context *ctx)
> kref_put(&ctx->ref, i915_gem_context_release);
> }
>
> +static inline void
> +intel_context_init(struct intel_context *ce,
> +struct i915_gem_context *ctx,
> +struct intel_engine_cs *engine)
> +{
> + ce->gem_context = ctx;
> +}
> +
Audience was also waiting intel_context_init_engines()
Reviewed-by: Mika Kuoppala
> #endif /* !__I915_GEM_CONTEXT_H__ */
> diff --git a/drivers/gpu/drm/i915/selftests/mock_context.c
> b/drivers/gpu/drm/i915/selftests/mock_context.c
> index d937bdff26f9..b646cdcdd602 100644
> --- a/drivers/gpu/drm/i915/selftests/mock_context.c
> +++ b/drivers/gpu/drm/i915/selftests/mock_context.c
> @@ -45,11 +45,8 @@ mock_context(struct drm_i915_private *i915,
> INIT_LIST_HEAD(&ctx->handles_list);
> INIT_LIST_HEAD(&ctx->hw_id_link);
>
> - for (n = 0; n < ARRAY_SIZE(ctx->__engine); n++) {
> - struct intel_context *ce = &ctx->__engine[n];
> -
> - ce->gem_context = ctx;
> - }
> + for (n = 0; n < ARRAY_SIZE(ctx->__engine); n++)
> + intel_context_init(&ctx->__engine[n], ctx, i915->engine[n]);
>
> ret = i915_gem_context_pin_hw_id(ctx);
> if (ret < 0)
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Use fb width to measure fb width instead of visible plane width when verify NV12
Using visible plane width for testing NV12 source suitability may fail
randomly when plane is clipped.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109381
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index b02d3d9..a15c5ef 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1516,7 +1516,7 @@ static int skl_plane_check_nv12_rotation(const struct
intel_plane_state *plane_s
{
const struct drm_framebuffer *fb = plane_state->base.fb;
unsigned int rotation = plane_state->base.rotation;
- int src_w = drm_rect_width(&plane_state->base.src) >> 16;
+ int src_w = plane_state->base.fb->width;
/* Display WA #1106 */
if (fb->format->format == DRM_FORMAT_NV12 && src_w & 3 &&
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/34] drm/i915: Show all active engines on hangcheck
Quoting Mika Kuoppala (2019-01-22 12:33:00)
> Chris Wilson writes:
>
> > This turns out to be quite useful if one happens to be debugging
> > semaphore deadlocks.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_hangcheck.c | 15 +++
> > 1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c
> > b/drivers/gpu/drm/i915/intel_hangcheck.c
> > index 7dc11fcb13de..741441daae32 100644
> > --- a/drivers/gpu/drm/i915/intel_hangcheck.c
> > +++ b/drivers/gpu/drm/i915/intel_hangcheck.c
> > @@ -195,10 +195,6 @@ static void hangcheck_accumulate_sample(struct
> > intel_engine_cs *engine,
> > break;
> >
> > case ENGINE_DEAD:
> > - if (GEM_SHOW_DEBUG()) {
> > - struct drm_printer p = drm_debug_printer("hangcheck");
> > - intel_engine_dump(engine, &p, "%s\n", engine->name);
> > - }
> > break;
> >
> > default:
> > @@ -285,6 +281,17 @@ static void i915_hangcheck_elapsed(struct work_struct
> > *work)
> > wedged |= intel_engine_flag(engine);
> > }
> >
> > + if (GEM_SHOW_DEBUG() && (hung | stuck)) {
> > + struct drm_printer p = drm_debug_printer("hangcheck");
> > +
> > + for_each_engine(engine, dev_priv, id) {
> > + if (intel_engine_is_idle(engine))
> > + continue;
>
> Looks rather harmless tho there is that local_bh_disable.
> I was pondering if it was worthwhile to determine idle here
> with more lightweight approach, but as we already use
> the exact same method on determining hangcheck action, lets
> stick to this as it is should be then in parity with the
> engine action we got earlier.
Plus it's only for glancing at the dmesg; the error state is meant to be
the be-all-end-all of debugging information. I just find it convenient
when watching netconsole and most kernel bugs can be deduced from the
register state itself.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/34] drm/i915: Refactor out intel_context_init()
Quoting Mika Kuoppala (2019-01-22 12:39:08)
> Chris Wilson writes:
> > +static inline void
> > +intel_context_init(struct intel_context *ce,
> > +struct i915_gem_context *ctx,
> > +struct intel_engine_cs *engine)
> > +{
> > + ce->gem_context = ctx;
> > +}
> > +
>
> Audience was also waiting intel_context_init_engines()
struct intel_context is the per-engine instance, and it's not actually
guaranteed that there will be a contiguous set :) One should always skip
to the end of the novel to find out it was the butler who did it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 02/15] drm/i915: Don't try to use the hardware frame counter with i965gm TV output
On Tue, Nov 27, 2018 at 10:05:50PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On i965gm the hardware frame counter does not work when
> the TV encoder is active. So let's not try to consult
> the hardware frame counter in that case. Instead we'll
> fall back to the timestamp based guesstimation method
> used on gen2.
>
> Note that the pipe timings generated by the TV encoder
> are also rather peculiar. Apparently the pipe wants to
> run at a much higher speed (related to the oversample
> clock somehow it seems) but during the vertical active
> period the TV encoder stalls the pipe every few lines
> to keep its speed in check. But once the vertical
> blanking period is reached the pipe gets to run at full
> speed. This means our vblank timestamp estimates are
> suspect. Fixing all that would require quite a bit
> more work. This simple fix at least avoids the nasty
> vblank timeouts that are happening currently.
>
> Curiously the frame counter works just fine on i945gm
> and gm45. I don't really understand what kind of mishap
> occurred with the hardware design on i965gm. Sadly
> I wasn't able to find any chicken bits etc. that would
> fix the frame counter :(
>
> v2: Move the zero vs. non-zero hw counter value handling
> into i915_get_vblank_counter() (Daniel)
> Use the per-crtc maximum exclusively, leaving the
> per-device maximum at zero
> v3: max_vblank_count not populated yet in intel_enable_pipe()
> use intel_crtc_max_vblank_count() instead
>
> Cc: sta...@vger.kernel.org
> Cc: Daniel Vetter
> Fixes: 51e31d49c890 ("drm/i915: Use generic vblank wait")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93782
> Signed-off-by: Ville Syrjälä
>
> fix# _slub_broken.S
^ some remnant
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_irq.c | 27 ++--
> drivers/gpu/drm/i915/intel_display.c | 48 +++-
> 2 files changed, 58 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index d447d7d508f4..ab2d4eefef18 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -822,11 +822,26 @@ static void i915_enable_asle_pipestat(struct
> drm_i915_private *dev_priv)
> static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
> + struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
> + const struct drm_display_mode *mode = &vblank->hwmode;
> i915_reg_t high_frame, low_frame;
> u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
> - const struct drm_display_mode *mode = &dev->vblank[pipe].hwmode;
> unsigned long irqflags;
>
> + /*
> + * On i965gm TV output the frame counter only works up to
> + * the point when we enable the TV encoder. After that the
> + * frame counter ceases to work and reads zero. We need a
> + * vblank wait before enabling the TV encoder and so we
> + * have to enable vblank interrupts while the frame counter
> + * is still in a working state. However the core vblank code
> + * does not like us returning non-zero frame counter values
> + * when we've told it that we don't have a working frame
> + * counter. Thus we must stop non-zero values leaking out.
> + */
> + if (!vblank->max_vblank_count)
> + return 0;
> +
> htotal = mode->crtc_htotal;
> hsync_start = mode->crtc_hsync_start;
> vbl_start = mode->crtc_vblank_start;
> @@ -4836,16 +4851,10 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
> if (INTEL_GEN(dev_priv) >= 8)
> rps->pm_intrmsk_mbz |= GEN8_PMINTR_DISABLE_REDIRECT_TO_GUC;
>
> - if (IS_GEN2(dev_priv)) {
> - /* Gen2 doesn't have a hardware frame counter */
> - dev->max_vblank_count = 0;
> - } else if (IS_G4X(dev_priv) || INTEL_GEN(dev_priv) >= 5) {
> - dev->max_vblank_count = 0x; /* full 32 bit counter */
> + if (INTEL_GEN(dev_priv) >= 5 || IS_G4X(dev_priv))
> dev->driver->get_vblank_counter = g4x_get_vblank_counter;
> - } else {
> + else if (INTEL_GEN(dev_priv) >= 3)
> dev->driver->get_vblank_counter = i915_get_vblank_counter;
> - dev->max_vblank_count = 0xff; /* only 24 bits of frame
> count */
> - }
>
> /*
>* Opt out of the vblank disable timer on everything except gen2.
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index e9f4e22b2a4e..cb13eff78ad9 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1754,6 +1754,35 @@ enum pipe intel_crtc_pch_transcoder(struct intel_crtc
> *crtc)
> return crtc->pipe;
> }
>
> +static u32 intel_crtc_max_vblank_count(const struct intel_crtc_state
> *crtc_state)
> +{
> + struct drm_i
Re: [Intel-gfx] [PATCH 03/15] drm/i915/tv: Fix interlaced ysize calculation
On Mon, Nov 12, 2018 at 06:59:47PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Fix the calculation of the vertical active period for interlaced > TV modes. > > Signed-off-by: Ville Syrjälä Matches the spec: Reviewed-by: Imre Deak > --- > drivers/gpu/drm/i915/intel_tv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c > index 860f306a23ba..219a16d6dcc2 100644 > --- a/drivers/gpu/drm/i915/intel_tv.c > +++ b/drivers/gpu/drm/i915/intel_tv.c > @@ -1087,7 +1087,7 @@ static void intel_tv_pre_enable(struct intel_encoder > *encoder, > if (tv_mode->progressive) > ysize = tv_mode->nbr_end + 1; > else > - ysize = 2*tv_mode->nbr_end + 1; > + ysize = 2 * (tv_mode->nbr_end + 1); > > xpos += conn_state->tv.margins.left; > ypos += conn_state->tv.margins.top; > -- > 2.18.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/15] drm/i915/tv: Fix tv mode clocks
On Mon, Nov 12, 2018 at 06:59:48PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The oversample clock is always supposed to be either 108 MHz
> or 148.5 MHz. Make it so.
>
> Signed-off-by: Ville Syrjälä
Matches the spec:
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 219a16d6dcc2..dea24ef88763 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -636,7 +636,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "480p",
> - .clock = 107520,
> + .clock = 108000,
> .refresh= 59940,
> .oversample = TV_OVERSAMPLE_4X,
> .component_only = 1,
> @@ -660,7 +660,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "576p",
> - .clock = 107520,
> + .clock = 108000,
> .refresh= 5,
> .oversample = TV_OVERSAMPLE_4X,
> .component_only = 1,
> @@ -684,7 +684,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "720p@60Hz",
> - .clock = 148800,
> + .clock = 148500,
> .refresh= 6,
> .oversample = TV_OVERSAMPLE_2X,
> .component_only = 1,
> @@ -708,7 +708,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "720p@50Hz",
> - .clock = 148800,
> + .clock = 148500,
> .refresh= 5,
> .oversample = TV_OVERSAMPLE_2X,
> .component_only = 1,
> @@ -733,7 +733,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "1080i@50Hz",
> - .clock = 148800,
> + .clock = 148500,
> .refresh= 5,
> .oversample = TV_OVERSAMPLE_2X,
> .component_only = 1,
> @@ -759,7 +759,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "1080i@60Hz",
> - .clock = 148800,
> + .clock = 148500,
> .refresh= 6,
> .oversample = TV_OVERSAMPLE_2X,
> .component_only = 1,
> @@ -1114,7 +1114,7 @@ static void intel_tv_pre_enable(struct intel_encoder
> *encoder,
> static const struct drm_display_mode reported_modes[] = {
> {
> .name = "NTSC 480i",
> - .clock = 107520,
> + .clock = 108000,
> .hdisplay = 1280,
> .hsync_start = 1368,
> .hsync_end = 1496,
> --
> 2.18.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Avoid divide by zero
Avoid divide by zero warning on static analysis. Signed-off-by: Mika Kahola --- drivers/gpu/drm/i915/intel_pm.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 8b63afa3a221..6a8e8b3f44c2 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3912,8 +3912,10 @@ skl_ddb_get_pipe_allocation_limits(struct drm_i915_private *dev_priv, pipe_width = hdisplay; } - alloc->start = ddb_size * width_before_pipe / total_width; - alloc->end = ddb_size * (width_before_pipe + pipe_width) / total_width; + alloc->start = total_width == 0 ? + 0 : ddb_size * width_before_pipe / total_width; + alloc->end = total_width == 0 ? + 0 : ddb_size * (width_before_pipe + pipe_width) / total_width; } static unsigned int skl_cursor_allocation(int num_active) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/15] drm/i915/tv: Store the TV oversampling factor in the TV mode
On Mon, Nov 12, 2018 at 06:59:49PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Store the oversampling factor as a number in the TV modes. We
> shall want to arithmetic with this which is easier if it's
> a number we can use directly.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 42 ++---
> 1 file changed, 28 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index dea24ef88763..96257b29d07c 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -307,7 +307,7 @@ struct tv_mode {
>
> u32 clock;
> u16 refresh; /* in millihertz (for precision) */
> - u32 oversample;
> + u8 oversample;
> u8 hsync_end;
> u16 hblank_start, hblank_end, htotal;
> bool progressive : 1, trilevel_sync : 1, component_only : 1;
> @@ -379,7 +379,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "NTSC-M",
> .clock = 108000,
> .refresh= 59940,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
>
> @@ -422,7 +422,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "NTSC-443",
> .clock = 108000,
> .refresh= 59940,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 4.43MHz */
> .hsync_end = 64, .hblank_end = 124,
> @@ -464,7 +464,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "NTSC-J",
> .clock = 108000,
> .refresh= 59940,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
>
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
> @@ -507,7 +507,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "PAL-M",
> .clock = 108000,
> .refresh= 59940,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
>
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
> @@ -551,7 +551,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "PAL-N",
> .clock = 108000,
> .refresh= 5,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
>
> .hsync_end = 64, .hblank_end = 128,
> @@ -596,7 +596,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "PAL",
> .clock = 108000,
> .refresh= 5,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
>
> .hsync_end = 64, .hblank_end = 142,
> @@ -638,7 +638,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "480p",
> .clock = 108000,
> .refresh= 59940,
> - .oversample = TV_OVERSAMPLE_4X,
> + .oversample = 4,
> .component_only = 1,
>
> .hsync_end = 64, .hblank_end = 122,
> @@ -662,7 +662,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "576p",
> .clock = 108000,
> .refresh= 5,
> - .oversample = TV_OVERSAMPLE_4X,
> + .oversample = 4,
> .component_only = 1,
>
> .hsync_end = 64, .hblank_end = 139,
> @@ -686,7 +686,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "720p@60Hz",
> .clock = 148500,
> .refresh= 6,
> - .oversample = TV_OVERSAMPLE_2X,
> + .oversample = 2,
> .component_only = 1,
>
> .hsync_end = 80, .hblank_end = 300,
> @@ -710,7 +710,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "720p@50Hz",
> .clock = 148500,
> .refresh= 5,
> - .oversample = TV_OVERSAMPLE_2X,
> + .oversample = 2,
> .component_only = 1,
>
> .hsync_end = 80, .hblank_en
Re: [Intel-gfx] [PATCH] drm/i915: Avoid divide by zero
On Tue, 22 Jan 2019, Mika Kahola wrote: > Avoid divide by zero warning on static analysis. > > Signed-off-by: Mika Kahola > --- > drivers/gpu/drm/i915/intel_pm.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 8b63afa3a221..6a8e8b3f44c2 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -3912,8 +3912,10 @@ skl_ddb_get_pipe_allocation_limits(struct > drm_i915_private *dev_priv, > pipe_width = hdisplay; > } if (WARN_ON(total_width == 0)) return; ? BR, Jani. > > - alloc->start = ddb_size * width_before_pipe / total_width; > - alloc->end = ddb_size * (width_before_pipe + pipe_width) / total_width; > + alloc->start = total_width == 0 ? > + 0 : ddb_size * width_before_pipe / total_width; > + alloc->end = total_width == 0 ? > + 0 : ddb_size * (width_before_pipe + pipe_width) / total_width; > } > > static unsigned int skl_cursor_allocation(int num_active) -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/15] drm/i915/tv: Use bools where appropriate
On Mon, Nov 12, 2018 at 06:59:50PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> 'component_only' is a bool. Initialize it like a bool.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 96257b29d07c..72de154b8627 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -380,7 +380,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 59940,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
>
> .hsync_end = 64, .hblank_end = 124,
> @@ -423,7 +423,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 59940,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 4.43MHz */
> .hsync_end = 64, .hblank_end = 124,
> .hblank_start = 836, .htotal = 857,
> @@ -465,7 +465,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 59940,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
>
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
> .hsync_end = 64, .hblank_end = 124,
> @@ -508,7 +508,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 59940,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
>
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
> .hsync_end = 64, .hblank_end = 124,
> @@ -552,7 +552,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 5,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
>
> .hsync_end = 64, .hblank_end = 128,
> .hblank_start = 844,.htotal = 863,
> @@ -597,7 +597,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 5,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
>
> .hsync_end = 64, .hblank_end = 142,
> .hblank_start = 844, .htotal = 863,
> @@ -639,7 +639,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 59940,
> .oversample = 4,
> - .component_only = 1,
> + .component_only = true,
>
> .hsync_end = 64, .hblank_end = 122,
> .hblank_start = 842, .htotal = 857,
> @@ -663,7 +663,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 5,
> .oversample = 4,
> - .component_only = 1,
> + .component_only = true,
>
> .hsync_end = 64, .hblank_end = 139,
> .hblank_start = 859, .htotal = 863,
> @@ -687,7 +687,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 148500,
> .refresh= 6,
> .oversample = 2,
> - .component_only = 1,
> + .component_only = true,
>
> .hsync_end = 80, .hblank_end = 300,
> .hblank_start = 1580, .htotal = 1649,
> @@ -711,7 +711,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 148500,
> .refresh= 5,
> .oversample = 2,
> - .component_only = 1,
> + .component_only = true,
>
> .hsync_end = 80, .hblank_end = 300,
> .hblank_start = 1580, .htotal = 1979,
> @@ -736,7 +736,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 148500,
> .refresh= 5,
Re: [Intel-gfx] [PATCH 07/15] drm/i915/tv: Nuke silly 0 initialzation of xpos/ypos
On Mon, Nov 12, 2018 at 06:59:51PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Just assign the margin values directly to xpos/ypos instead > of first initializing to zero and then adding the values. > > Signed-off-by: Ville Syrjälä Reviewed-by: Imre Deak > --- > drivers/gpu/drm/i915/intel_tv.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c > index 72de154b8627..97a82878359f 100644 > --- a/drivers/gpu/drm/i915/intel_tv.c > +++ b/drivers/gpu/drm/i915/intel_tv.c > @@ -994,7 +994,7 @@ static void intel_tv_pre_enable(struct intel_encoder > *encoder, > const struct video_levels *video_levels; > const struct color_conversion *color_conversion; > bool burst_ena; > - int xpos = 0x0, ypos = 0x0; > + int xpos, ypos; > unsigned int xsize, ysize; > > if (!tv_mode) > @@ -1103,8 +1103,8 @@ static void intel_tv_pre_enable(struct intel_encoder > *encoder, > else > ysize = 2 * (tv_mode->nbr_end + 1); > > - xpos += conn_state->tv.margins.left; > - ypos += conn_state->tv.margins.top; > + xpos = conn_state->tv.margins.left; > + ypos = conn_state->tv.margins.top; > xsize -= (conn_state->tv.margins.left + > conn_state->tv.margins.right); > ysize -= (conn_state->tv.margins.top + > -- > 2.18.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid divide by zero
On Tue, 2019-01-22 at 15:07 +0200, Jani Nikula wrote: > On Tue, 22 Jan 2019, Mika Kahola wrote: > > Avoid divide by zero warning on static analysis. > > > > Signed-off-by: Mika Kahola > > --- > > drivers/gpu/drm/i915/intel_pm.c | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > > b/drivers/gpu/drm/i915/intel_pm.c > > index 8b63afa3a221..6a8e8b3f44c2 100644 > > --- a/drivers/gpu/drm/i915/intel_pm.c > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > @@ -3912,8 +3912,10 @@ skl_ddb_get_pipe_allocation_limits(struct > > drm_i915_private *dev_priv, > > pipe_width = hdisplay; > > } > > if (WARN_ON(total_width == 0)) > return; Warning might be enough here. Switching to use this in this patch. Thanks for the review! Cheers, Mika > > ? > > BR, > Jani. > > > > > > - alloc->start = ddb_size * width_before_pipe / total_width; > > - alloc->end = ddb_size * (width_before_pipe + pipe_width) / > > total_width; > > + alloc->start = total_width == 0 ? > > + 0 : ddb_size * width_before_pipe / total_width; > > + alloc->end = total_width == 0 ? > > + 0 : ddb_size * (width_before_pipe + pipe_width) / > > total_width; > > } > > > > static unsigned int skl_cursor_allocation(int num_active) > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use fb width to measure fb width instead of visible plane width when verify NV12
Please ignore this. This patch is all wrong.
/Juha-Pekka
On 22.1.2019 14.41, Juha-Pekka Heikkila wrote:
Using visible plane width for testing NV12 source suitability may fail
randomly when plane is clipped.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109381
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index b02d3d9..a15c5ef 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1516,7 +1516,7 @@ static int skl_plane_check_nv12_rotation(const struct
intel_plane_state *plane_s
{
const struct drm_framebuffer *fb = plane_state->base.fb;
unsigned int rotation = plane_state->base.rotation;
- int src_w = drm_rect_width(&plane_state->base.src) >> 16;
+ int src_w = plane_state->base.fb->width;
/* Display WA #1106 */
if (fb->format->format == DRM_FORMAT_NV12 && src_w & 3 &&
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/38] drm/i915: Stop tracking MRU activity on VMA
Quoting Tvrtko Ursulin (2019-01-18 16:03:27) > > On 18/01/2019 14:00, Chris Wilson wrote: > > Our goal is to remove struct_mutex and replace it with fine grained > > locking. One of the thorny issues is our eviction logic for reclaiming > > space for an execbuffer (or GTT mmaping, among a few other examples). > > While eviction itself is easy to move under a per-VM mutex, performing > > the activity tracking is less agreeable. One solution is not to do any > > MRU tracking and do a simple coarse evaluation during eviction of > > active/inactive, with a loose temporal ordering of last > > insertion/evaluation. That keeps all the locking constrained to when we > > are manipulating the VM itself, neatly avoiding the tricky handling of > > possible recursive locking during execbuf and elsewhere. > > > > Note that discarding the MRU is unlikely to impact upon our efficiency > > to reclaim VM space (where we think a LRU model is best) as our > > current strategy is to use random idle replacement first before doing > > a search, and over time the use of softpinned 48b per-ppGTT is growing > > (thereby eliminating any need to perform any eviction searches, in > > theory at least). > > There is still no mention of list consolidation. "Note that discarding the MRU (currently implemented as a pair of lists, to avoid scanning the active list for a NONBLOCKING search)" Is that enough to make it clear? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 1/7] drm/i915: initialize unused MOCS entries to PTE
Quoting Lucas De Marchi (2019-01-22 05:12:21) > Instead of initializing them to uncached, let's set them to PTE for > kernel tracking. While at it do some minor adjustments to comments and > coding style. > > Signed-off-by: Lucas De Marchi I'm in favour. I do not think this contributes an ABI change, as these values are explicitly outside of the ABI. What it does mean is that the buffer contents are consistent with our cache tracking; and for userspace the results were always undefined. So we should at least be able to guarantee that the data written by userspace from the CPU is visible. After that, your caches are on your own. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 3/7] drm/i915/skl: Rework MOCS tables to keep common part in a define
Quoting Lucas De Marchi (2019-01-22 05:12:23)
> From: Tomasz Lis
>
> The MOCS tables are going to be very similar across platforms.
>
> To reduce the amount of copied code, this patch rips the common part and
> puts it into a definition valid for all gen9 platforms.
>
> v2: Made defines for or-ing flags. Renamed macros from MOCS_TABLE
> to MOCS_ENTRIES. (Joonas)
> v3 (Lucas):
> - Fix indentation
> - Rebase on rework done by additional patch
> - Remove define for or-ing flags as it made the table more complex by
> requiring zeroed values to be passed
> - Do not embed comma in the macro, so to treat that just as another
> item and please source code formatting tools
>
> Signed-off-by: Tomasz Lis
> Suggested-by: Lucas De Marchi
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_mocs.c | 57 ++-
> 1 file changed, 25 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_mocs.c
> b/drivers/gpu/drm/i915/intel_mocs.c
> index 4ea80bb7dcc8..c7a2a8d81d90 100644
> --- a/drivers/gpu/drm/i915/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/intel_mocs.c
> @@ -93,46 +93,39 @@ struct drm_i915_mocs_table {
> * may only be updated incrementally by adding entries at the
> * end.
> */
> +
> +#define GEN9_MOCS_ENTRIES \
> + [I915_MOCS_UNCACHED] = { \
> + /* 0x0009 */ \
> + .control_value = LE_1_UC | LE_TC_2_LLC_ELLC, \
> + /* 0x0010 */ \
> + .l3cc_value = L3_1_UC, \
> + }, \
> + [I915_MOCS_PTE] = { \
> + /* 0x0038 */ \
> + .control_value = LE_0_PAGETABLE | LE_TC_2_LLC_ELLC |
> LE_LRUM(3), \
> + /* 0x0030 */ \
> + .l3cc_value = L3_3_WB, \
> + }
> +
> static const struct drm_i915_mocs_entry skylake_mocs_table[] = {
> - [I915_MOCS_UNCACHED] = {
> - /* 0x0009 */
> - .control_value = LE_1_UC | LE_TC_2_LLC_ELLC,
> - /* 0x0010 */
> - .l3cc_value =L3_1_UC,
> - },
> - [I915_MOCS_PTE] = {
> - /* 0x0038 */
> - .control_value = LE_0_PAGETABLE | LE_TC_2_LLC_ELLC | LE_LRUM(3),
> - /* 0x0030 */
> - .l3cc_value =L3_3_WB,
> - },
> + GEN9_MOCS_ENTRIES,
> [I915_MOCS_CACHED] = {
> - /* 0x003b */
> - .control_value = LE_3_WB | LE_TC_2_LLC_ELLC | LE_LRUM(3),
> - /* 0x0030 */
> - .l3cc_value = L3_3_WB,
> + /* 0x003b */
You scared me with the indentation change at the same time.
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 4/7] drm/i915: use a macro to define MOCS entries
Quoting Lucas De Marchi (2019-01-22 05:12:24) > Let's use a macro to make tables smaller and at the same time allow us > to add fields that apply to all entries in future. > > For the sake of readability, I'm calling an exception on 80 chars limit. > Lines are aligned for easy comparison of the entry values. > + MOCS_ENTRY(I915_MOCS_UNCACHED, LE_1_UC | LE_TC_2_LLC_ELLC, \ > + L3_1_UC), \ MOCS_ENTRY(I915_MOCS_UNCACHED, LE_1_UC | LE_TC_2_LLC_ELLC, L3_1_UC), \ is even more readable with the visual clustering of attribute flags. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 6/7] drm/i915: cache number of MOCS entries
Quoting Lucas De Marchi (2019-01-22 05:12:26) > Instead of checking the gen number every time we need to know the max > number of entries, just save it into the table struct so we don't need > extra branches throughout the code. This will be useful for Ice Lake > that has 64 rather than 62 defined entries. Ice Lake changes will be > added in a follow up. > > v2: make size and n_entries `unsigned int` and introduce changes as a > pre-work for the Ice Lake changes (Tvrtko) > > Suggested-by: Tvrtko Ursulin > Signed-off-by: Lucas De Marchi Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use fb width to measure fb width instead of visible plane width when verify NV12
== Series Details ==
Series: drm/i915: Use fb width to measure fb width instead of visible plane
width when verify NV12
URL : https://patchwork.freedesktop.org/series/8/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5463 -> Patchwork_12004
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/8/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12004 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:PASS -> DMESG-FAIL [fdo#108735]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#108767]
Possible fixes
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u3}:FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109316]: https://bugs.freedesktop.org/show_bug.cgi?id=109316
Participating hosts (41 -> 39)
--
Additional (2): fi-icl-u2 fi-apl-guc
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5463 -> Patchwork_12004
CI_DRM_5463: 6bd1569466edcb2f890a374be27f0eb6780963f9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4782: 96f3a1b876e0dd24706b85fb872f12031a436e84 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12004: d607a5109524a7bf7a9d77b1465a627a20c42021 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d607a5109524 drm/i915: Use fb width to measure fb width instead of visible
plane width when verify NV12
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12004/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 5/7] drm/i915: keep track of used entries in MOCS table
Quoting Lucas De Marchi (2019-01-22 05:12:25)
> Instead of considering we have defined entries for any index in the
> table, let's keep track of the ones we explicitly defined. This will
> allow Gen 11 to have it's new table defined in which we have holes of
> undefined entries.
>
> Repeated comments about the meaning of undefined entries were removed
> since they are overly verbose and copy-pasted in several functions: now
> the definition is in the top only.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_mocs.c | 88 ---
> 1 file changed, 57 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_mocs.c
> b/drivers/gpu/drm/i915/intel_mocs.c
> index faae2eefc5cc..af2ae2f396ae 100644
> --- a/drivers/gpu/drm/i915/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/intel_mocs.c
> @@ -28,6 +28,7 @@
> struct drm_i915_mocs_entry {
> u32 control_value;
> u16 l3cc_value;
> + u16 used;
> };
> + /* Set unused values to PTE */
> + unused_index = I915_MOCS_PTE;
> +
> + for (i = 0; i < table.size / 2; i++) {
> + u16 low = table.table[2 * i].used ?
> + 2 * i : unused_index;
> + u16 high = table.table[2 * i + 1].used ?
> + 2 * i + 1 : unused_index;
I'm underwhelmed here.
Could we not do something like
static unsigned int
get_entry_index(struct tbl *tbl, unsigned int idx, unsigned int unused_index)
{
return tbl->used ? idx : unused_index;
}
u16 lo = get_entry_index(table.table, 2 * i, unused_index);
u16 hi = get_entry_index(table.table, 2 * i + 1, unused_index);
That just fits and repeated enough to be worth a little extra effort.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/15] drm/i915/tv: Deobfuscate preferred mode selection
On Mon, Nov 12, 2018 at 06:59:53PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rewrite the preferred mode selection to just check
> whether the TV modes is HD or SD. For SD TV modes we
> favor 480 line modes, for 720p we prefer 720 line modes,
> and for 1080i/p we prefer 1080 line modes.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 50 -
> 1 file changed, 30 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 97a82878359f..54189080cfb1 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -860,6 +860,14 @@ intel_tv_mode_valid(struct drm_connector *connector,
> return MODE_CLOCK_RANGE;
> }
>
> +static int
> +intel_tv_mode_vdisplay(const struct tv_mode *tv_mode)
> +{
> + if (tv_mode->progressive)
> + return tv_mode->nbr_end + 1;
> + else
> + return 2 * (tv_mode->nbr_end + 1);
> +}
>
> static void
> intel_tv_get_config(struct intel_encoder *encoder,
> @@ -1098,10 +1106,7 @@ static void intel_tv_pre_enable(struct intel_encoder
> *encoder,
> /* Filter ctl must be set before TV_WIN_SIZE */
> I915_WRITE(TV_FILTER_CTL_1, TV_AUTO_SCALE);
> xsize = tv_mode->hblank_start - tv_mode->hblank_end;
> - if (tv_mode->progressive)
> - ysize = tv_mode->nbr_end + 1;
> - else
> - ysize = 2 * (tv_mode->nbr_end + 1);
> + ysize = intel_tv_mode_vdisplay(tv_mode);
>
> xpos = conn_state->tv.margins.left;
> ypos = conn_state->tv.margins.top;
> @@ -1320,22 +1325,28 @@ static const struct input_res {
> {"1920x1080", 1920, 1080},
> };
>
> -/*
> - * Chose preferred mode according to line number of TV format
> - */
> +/* Choose preferred mode according to line number of TV format */
> +static bool
> +intel_tv_is_preferred_mode(const struct drm_display_mode *mode,
> +const struct tv_mode *tv_mode)
> +{
> + int vdisplay = intel_tv_mode_vdisplay(tv_mode);
> +
> + /* prefer 480 line modes for all SD TV modes */
> + if (vdisplay <= 576)
> + vdisplay = 480;
> +
> + return vdisplay == mode->vdisplay;
> +}
> +
> static void
> -intel_tv_choose_preferred_modes(const struct tv_mode *tv_mode,
> -struct drm_display_mode *mode_ptr)
> +intel_tv_set_mode_type(struct drm_display_mode *mode,
> +const struct tv_mode *tv_mode)
> {
> - if (tv_mode->nbr_end < 480 && mode_ptr->vdisplay == 480)
> - mode_ptr->type |= DRM_MODE_TYPE_PREFERRED;
> - else if (tv_mode->nbr_end > 480) {
> - if (tv_mode->progressive == true && tv_mode->nbr_end < 720) {
> - if (mode_ptr->vdisplay == 720)
> - mode_ptr->type |= DRM_MODE_TYPE_PREFERRED;
> - } else if (mode_ptr->vdisplay == 1080)
> - mode_ptr->type |= DRM_MODE_TYPE_PREFERRED;
> - }
> + mode->type = DRM_MODE_TYPE_DRIVER;
> +
> + if (intel_tv_is_preferred_mode(mode, tv_mode))
> + mode->type |= DRM_MODE_TYPE_PREFERRED;
> }
>
> static int
> @@ -1383,8 +1394,7 @@ intel_tv_get_modes(struct drm_connector *connector)
> tmp = div_u64(tmp, 100);
> mode_ptr->clock = (int) tmp;
>
> - mode_ptr->type = DRM_MODE_TYPE_DRIVER;
> - intel_tv_choose_preferred_modes(tv_mode, mode_ptr);
> + intel_tv_set_mode_type(mode_ptr, tv_mode);
> drm_mode_probed_add(connector, mode_ptr);
> count++;
> }
> --
> 2.18.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/15] drm/i915/tv: Use drm_mode_set_name() to name TV modes
On Mon, Nov 12, 2018 at 06:59:54PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> No point in storing the mode names in the array. drm_mode_set_name()
> will give us the same names without wasting space for these string
> constants.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 54189080cfb1..433f538261c1 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1313,16 +1313,15 @@ intel_tv_detect(struct drm_connector *connector,
> }
>
> static const struct input_res {
> - const char *name;
> - int w, h;
> + u16 w, h;
> } input_res_table[] = {
> - {"640x480", 640, 480},
> - {"800x600", 800, 600},
> - {"1024x768", 1024, 768},
> - {"1280x1024", 1280, 1024},
> - {"848x480", 848, 480},
> - {"1280x720", 1280, 720},
> - {"1920x1080", 1920, 1080},
> + { 640, 480 },
> + { 800, 600 },
> + { 1024, 768 },
> + { 1280, 1024 },
> + { 848, 480 },
> + { 1280, 720 },
> + { 1920, 1080 },
> };
>
> /* Choose preferred mode according to line number of TV format */
> @@ -1373,7 +1372,6 @@ intel_tv_get_modes(struct drm_connector *connector)
> mode_ptr = drm_mode_create(connector->dev);
> if (!mode_ptr)
> continue;
> - strlcpy(mode_ptr->name, input->name, DRM_DISPLAY_MODE_LEN);
>
> mode_ptr->hdisplay = hactive_s;
> mode_ptr->hsync_start = hactive_s + 1;
> @@ -1395,6 +1393,9 @@ intel_tv_get_modes(struct drm_connector *connector)
> mode_ptr->clock = (int) tmp;
>
> intel_tv_set_mode_type(mode_ptr, tv_mode);
> +
> + drm_mode_set_name(mode_ptr);
> +
> drm_mode_probed_add(connector, mode_ptr);
> count++;
> }
> --
> 2.18.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
Quoting Joerg Roedel (2019-01-22 13:01:09) > Hi Daniel, > > On Tue, Jan 22, 2019 at 11:46:39AM +0100, Daniel Vetter wrote: > > Note that the string of platforms which have various issues with iommu > > and igfx is very long, thus far we only disabled it where there's no > > workaround to stop it from hanging the box, but otherwise left it > > enabled. So if we make a policy change to also disable it anywhere > > where it doesn't work well (instead of not at all), there's a pile > > more platforms to switch. > > I think its best to just disable iommu for the igfx devices on these > platforms. Can you pick up Eric's patch and extend it with the list of > affected platforms? We've been discussing this again more actively since a few months ago, and the discussion is still ongoing internally. According to our IOMMU folks there exists some desire to be able to assign the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off due to how the devices might be grouped in IOMMU groups. Even when you would not be using the iGFX device. So for some uses, the fact that the device (group) is assignable seems to be more important than the iGFX device to be working. I'm afraid that retroactively disabling the assignment for such an old platform might break those usage scenarios. By my quick reading of the code, there's no way for user to turn the iGFX DMAR on once the quirk disables it. I guess one solution would be to default to intel_iommu=igfx_off for platforms that are older than certain threshold. But still allow user to enable. But that then requires duplicating the PCI ID database into iommu code. I don't really have winning moves to present, but I'm open to hearing how we can avoid more damage than starting to default to intel_iommu=on did already. Regards, Joonas > > Thanks, > > Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/15] drm/i915/tv: Make TV mode autoselection actually useable
On Mon, Nov 12, 2018 at 06:59:55PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The current code insists on picking a new TV mode when
> switching between component and non-component cables.
> That's super annoying. Let's just keep the current TV
> mode unless the new cable type actually disagrees with it.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 433f538261c1..32a8786fe0da 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1253,16 +1253,18 @@ static void intel_tv_find_better_format(struct
> drm_connector *connector)
> const struct tv_mode *tv_mode = intel_tv_mode_find(connector->state);
> int i;
>
> - if ((intel_tv->type == DRM_MODE_CONNECTOR_Component) ==
> - tv_mode->component_only)
> + /* Component supports everything so we can keep the current mode */
> + if (intel_tv->type == DRM_MODE_CONNECTOR_Component)
> return;
>
> + /* If the current mode is fine don't change it */
> + if (!tv_mode->component_only)
> + return;
>
> for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
> - tv_mode = tv_modes + i;
> + tv_mode = &tv_modes[i];
>
> - if ((intel_tv->type == DRM_MODE_CONNECTOR_Component) ==
> - tv_mode->component_only)
> + if (!tv_mode->component_only)
> break;
> }
>
> --
> 2.18.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 25/34] drm/i915: Track active timelines
On 21/01/2019 22:21, Chris Wilson wrote:
Now that we pin timelines around use, we have a clearly defined lifetime
and convenient points at which we can track only the active timelines.
This allows us to reduce the list iteration to only consider those
active timelines and not all.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 4 +--
drivers/gpu/drm/i915/i915_reset.c| 2 +-
drivers/gpu/drm/i915/i915_timeline.c | 39 ++--
4 files changed, 29 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c00eaf2889fb..5577e0e1034f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1977,7 +1977,7 @@ struct drm_i915_private {
struct i915_gt_timelines {
struct mutex mutex; /* protects list, tainted by GPU */
- struct list_head list;
+ struct list_head active_list;
/* Pack multiple timelines' seqnos into the same page */
spinlock_t hwsp_lock;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4e0de22f0166..9c499edb4c13 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3246,7 +3246,7 @@ wait_for_timelines(struct drm_i915_private *i915,
return timeout;
mutex_lock(>->mutex);
- list_for_each_entry(tl, >->list, link) {
+ list_for_each_entry(tl, >->active_list, link) {
struct i915_request *rq;
rq = i915_gem_active_get_unlocked(&tl->last_request);
@@ -3274,7 +3274,7 @@ wait_for_timelines(struct drm_i915_private *i915,
/* restart after reacquiring the lock */
mutex_lock(>->mutex);
- tl = list_entry(>->list, typeof(*tl), link);
+ tl = list_entry(>->active_list, typeof(*tl), link);
}
mutex_unlock(>->mutex);
diff --git a/drivers/gpu/drm/i915/i915_reset.c b/drivers/gpu/drm/i915/i915_reset.c
index 09edf488f711..9b9169508139 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -852,7 +852,7 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
* No more can be submitted until we reset the wedged bit.
*/
mutex_lock(&i915->gt.timelines.mutex);
- list_for_each_entry(tl, &i915->gt.timelines.list, link) {
+ list_for_each_entry(tl, &i915->gt.timelines.active_list, link) {
struct i915_request *rq;
long timeout;
diff --git a/drivers/gpu/drm/i915/i915_timeline.c b/drivers/gpu/drm/i915/i915_timeline.c
index 69ee33dfa340..007348b1b469 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -117,7 +117,6 @@ int i915_timeline_init(struct drm_i915_private *i915,
const char *name,
struct i915_vma *hwsp)
{
- struct i915_gt_timelines *gt = &i915->gt.timelines;
void *vaddr;
/*
@@ -161,10 +160,6 @@ int i915_timeline_init(struct drm_i915_private *i915,
i915_syncmap_init(&timeline->sync);
- mutex_lock(>->mutex);
- list_add(&timeline->link, >->list);
- mutex_unlock(>->mutex);
-
return 0;
}
@@ -173,7 +168,7 @@ void i915_timelines_init(struct drm_i915_private *i915)
struct i915_gt_timelines *gt = &i915->gt.timelines;
mutex_init(>->mutex);
- INIT_LIST_HEAD(>->list);
+ INIT_LIST_HEAD(>->active_list);
spin_lock_init(>->hwsp_lock);
INIT_LIST_HEAD(>->hwsp_free_list);
@@ -182,6 +177,24 @@ void i915_timelines_init(struct drm_i915_private *i915)
i915_gem_shrinker_taints_mutex(i915, >->mutex);
}
+static void timeline_active(struct i915_timeline *tl)
+{
+ struct i915_gt_timelines *gt = &tl->i915->gt.timelines;
+
+ mutex_lock(>->mutex);
+ list_add(&tl->link, >->active_list);
+ mutex_unlock(>->mutex);
+}
+
+static void timeline_inactive(struct i915_timeline *tl)
+{
+ struct i915_gt_timelines *gt = &tl->i915->gt.timelines;
+
+ mutex_lock(>->mutex);
+ list_del(&tl->link);
+ mutex_unlock(>->mutex);
+}
Bike shedding comments only:
Would it be better to use a verb suffix? Even though timeline_activate
also wouldn't sound perfect. Since it is file local - activate_timeline?
Or even just inline to pin/unpin. Unless more gets put into them later..
+
/**
* i915_timelines_park - called when the driver idles
* @i915: the drm_i915_private device
@@ -198,7 +211,7 @@ void i915_timelines_park(struct drm_i915_private *i915)
struct i915_timeline *timeline;
mutex_lock(>->mutex);
- list_for_each_entry(timeline, >->list, link) {
+ list_for_each_entry(timeline, >->active_list, link) {
/*
* All known fences are completed so we can scrap
Re: [Intel-gfx] [PATCH 11/15] drm/i915/tv: Nuke reported_modes[]
On Mon, Nov 12, 2018 at 06:59:56PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove the silly reported_modes[] array. I suppse once upon a time
> this actually had something to do with modes we reported to userspace.
> Now it is just the placeholder for the mode we use for load detection.
> We don't need it even for that, and instead we can just rely on
> the fallback mode in intel_get_load_detect_pipe().
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 22 +-
> 1 file changed, 1 insertion(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 32a8786fe0da..c39e9a5b43db 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1130,23 +1130,6 @@ static void intel_tv_pre_enable(struct intel_encoder
> *encoder,
> I915_WRITE(TV_CTL, tv_ctl);
> }
>
> -static const struct drm_display_mode reported_modes[] = {
> - {
> - .name = "NTSC 480i",
> - .clock = 108000,
> - .hdisplay = 1280,
> - .hsync_start = 1368,
> - .hsync_end = 1496,
> - .htotal = 1712,
> -
> - .vdisplay = 1024,
> - .vsync_start = 1027,
> - .vsync_end = 1034,
> - .vtotal = 1104,
> - .type = DRM_MODE_TYPE_DRIVER,
> - },
> -};
> -
> static int
> intel_tv_detect_type(struct intel_tv *intel_tv,
> struct drm_connector *connector)
> @@ -1276,7 +1259,6 @@ intel_tv_detect(struct drm_connector *connector,
> struct drm_modeset_acquire_ctx *ctx,
> bool force)
> {
> - struct drm_display_mode mode;
> struct intel_tv *intel_tv = intel_attached_tv(connector);
> enum drm_connector_status status;
> int type;
> @@ -1285,13 +1267,11 @@ intel_tv_detect(struct drm_connector *connector,
> connector->base.id, connector->name,
> force);
>
> - mode = reported_modes[0];
> -
> if (force) {
> struct intel_load_detect_pipe tmp;
> int ret;
>
> - ret = intel_get_load_detect_pipe(connector, &mode, &tmp, ctx);
> + ret = intel_get_load_detect_pipe(connector, NULL, &tmp, ctx);
> if (ret < 0)
> return ret;
>
> --
> 2.18.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/15] drm/i915/tv: Add 1080p30/50/60 TV modes
On Mon, Nov 12, 2018 at 06:59:57PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add the missing 1080p TV modes. On gen4 all of them work just fine,
> whereas on gen3 only the 30Hz mode actually works correctly.
>
> Signed-off-by: Ville Syrjälä
Matches the spec:
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 90 +++--
> 1 file changed, 86 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index c39e9a5b43db..216525dd144a 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -783,6 +783,84 @@ static const struct tv_mode tv_modes[] = {
>
> .filter_table = filter_table,
> },
> +
> + {
> + .name = "1080p@30Hz",
> + .clock = 148500,
> + .refresh= 3,
> + .oversample = 2,
> + .component_only = true,
> +
> + .hsync_end = 88, .hblank_end = 235,
> + .hblank_start = 2155, .htotal = 2199,
> +
> + .progressive= true, .trilevel_sync = true,
> +
> + .vsync_start_f1 = 8, .vsync_start_f2 = 8,
> + .vsync_len = 10,
> +
> + .veq_ena= false,.veq_start_f1 = 0,
> + .veq_start_f2 = 0,.veq_len= 0,
> +
> + .vi_end_f1 = 44, .vi_end_f2 = 44,
> + .nbr_end= 1079,
> +
> + .burst_ena = false,
> +
> + .filter_table = filter_table,
> + },
> +
> + {
> + .name = "1080p@50Hz",
> + .clock = 148500,
> + .refresh= 5,
> + .oversample = 1,
> + .component_only = true,
> +
> + .hsync_end = 88, .hblank_end = 235,
> + .hblank_start = 2155, .htotal = 2639,
> +
> + .progressive= true, .trilevel_sync = true,
> +
> + .vsync_start_f1 = 8, .vsync_start_f2 = 8,
> + .vsync_len = 10,
> +
> + .veq_ena= false,.veq_start_f1 = 0,
> + .veq_start_f2 = 0,.veq_len= 0,
> +
> + .vi_end_f1 = 44, .vi_end_f2 = 44,
> + .nbr_end= 1079,
> +
> + .burst_ena = false,
> +
> + .filter_table = filter_table,
> + },
> +
> + {
> + .name = "1080p@60Hz",
> + .clock = 148500,
> + .refresh= 6,
> + .oversample = 1,
> + .component_only = true,
> +
> + .hsync_end = 88, .hblank_end = 235,
> + .hblank_start = 2155, .htotal = 2199,
> +
> + .progressive= true, .trilevel_sync = true,
> +
> + .vsync_start_f1 = 8, .vsync_start_f2 = 8,
> + .vsync_len = 10,
> +
> + .veq_ena= false,.veq_start_f1
> = 0,
> + .veq_start_f2 = 0,.veq_len= 0,
> +
> + .vi_end_f1 = 44, .vi_end_f2 = 44,
> + .nbr_end= 1079,
> +
> + .burst_ena = false,
> +
> + .filter_table = filter_table,
> + },
> };
>
> static struct intel_tv *enc_to_tv(struct intel_encoder *encoder)
> @@ -1538,11 +1616,15 @@ intel_tv_init(struct drm_i915_private *dev_priv)
> connector->doublescan_allowed = false;
>
> /* Create TV properties then attach current values */
> - for (i = 0; i < ARRAY_SIZE(tv_modes); i++)
> + for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
> + /* 1080p50/1080p60 not supported on gen3 */
> + if (IS_GEN3(dev_priv) &&
> + tv_modes[i].oversample == 1)
> + break;
> +
> tv_format_names[i] = tv_modes[i].name;
> - drm_mode_create_tv_properties(dev,
> - ARRAY_SIZE(tv_modes),
> - tv_format_names);
> + }
> + drm_mode_create_tv_properties(dev, i, tv_format_names);
>
> drm_object_attach_property(&connector->base,
> dev->mode_config.tv_mode_property,
> state->tv.mode);
> --
> 2.18.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 25/34] drm/i915: Track active timelines
Quoting Tvrtko Ursulin (2019-01-22 14:56:32)
>
> On 21/01/2019 22:21, Chris Wilson wrote:
> > Now that we pin timelines around use, we have a clearly defined lifetime
> > and convenient points at which we can track only the active timelines.
> > This allows us to reduce the list iteration to only consider those
> > active timelines and not all.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 2 +-
> > drivers/gpu/drm/i915/i915_gem.c | 4 +--
> > drivers/gpu/drm/i915/i915_reset.c| 2 +-
> > drivers/gpu/drm/i915/i915_timeline.c | 39 ++--
> > 4 files changed, 29 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index c00eaf2889fb..5577e0e1034f 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1977,7 +1977,7 @@ struct drm_i915_private {
> >
> > struct i915_gt_timelines {
> > struct mutex mutex; /* protects list, tainted by GPU
> > */
> > - struct list_head list;
> > + struct list_head active_list;
> >
> > /* Pack multiple timelines' seqnos into the same page
> > */
> > spinlock_t hwsp_lock;
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 4e0de22f0166..9c499edb4c13 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3246,7 +3246,7 @@ wait_for_timelines(struct drm_i915_private *i915,
> > return timeout;
> >
> > mutex_lock(>->mutex);
> > - list_for_each_entry(tl, >->list, link) {
> > + list_for_each_entry(tl, >->active_list, link) {
> > struct i915_request *rq;
> >
> > rq = i915_gem_active_get_unlocked(&tl->last_request);
> > @@ -3274,7 +3274,7 @@ wait_for_timelines(struct drm_i915_private *i915,
> >
> > /* restart after reacquiring the lock */
> > mutex_lock(>->mutex);
> > - tl = list_entry(>->list, typeof(*tl), link);
> > + tl = list_entry(>->active_list, typeof(*tl), link);
> > }
> > mutex_unlock(>->mutex);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reset.c
> > b/drivers/gpu/drm/i915/i915_reset.c
> > index 09edf488f711..9b9169508139 100644
> > --- a/drivers/gpu/drm/i915/i915_reset.c
> > +++ b/drivers/gpu/drm/i915/i915_reset.c
> > @@ -852,7 +852,7 @@ bool i915_gem_unset_wedged(struct drm_i915_private
> > *i915)
> >* No more can be submitted until we reset the wedged bit.
> >*/
> > mutex_lock(&i915->gt.timelines.mutex);
> > - list_for_each_entry(tl, &i915->gt.timelines.list, link) {
> > + list_for_each_entry(tl, &i915->gt.timelines.active_list, link) {
> > struct i915_request *rq;
> > long timeout;
> >
> > diff --git a/drivers/gpu/drm/i915/i915_timeline.c
> > b/drivers/gpu/drm/i915/i915_timeline.c
> > index 69ee33dfa340..007348b1b469 100644
> > --- a/drivers/gpu/drm/i915/i915_timeline.c
> > +++ b/drivers/gpu/drm/i915/i915_timeline.c
> > @@ -117,7 +117,6 @@ int i915_timeline_init(struct drm_i915_private *i915,
> > const char *name,
> > struct i915_vma *hwsp)
> > {
> > - struct i915_gt_timelines *gt = &i915->gt.timelines;
> > void *vaddr;
> >
> > /*
> > @@ -161,10 +160,6 @@ int i915_timeline_init(struct drm_i915_private *i915,
> >
> > i915_syncmap_init(&timeline->sync);
> >
> > - mutex_lock(>->mutex);
> > - list_add(&timeline->link, >->list);
> > - mutex_unlock(>->mutex);
> > -
> > return 0;
> > }
> >
> > @@ -173,7 +168,7 @@ void i915_timelines_init(struct drm_i915_private *i915)
> > struct i915_gt_timelines *gt = &i915->gt.timelines;
> >
> > mutex_init(>->mutex);
> > - INIT_LIST_HEAD(>->list);
> > + INIT_LIST_HEAD(>->active_list);
> >
> > spin_lock_init(>->hwsp_lock);
> > INIT_LIST_HEAD(>->hwsp_free_list);
> > @@ -182,6 +177,24 @@ void i915_timelines_init(struct drm_i915_private *i915)
> > i915_gem_shrinker_taints_mutex(i915, >->mutex);
> > }
> >
> > +static void timeline_active(struct i915_timeline *tl)
> > +{
> > + struct i915_gt_timelines *gt = &tl->i915->gt.timelines;
> > +
> > + mutex_lock(>->mutex);
> > + list_add(&tl->link, >->active_list);
> > + mutex_unlock(>->mutex);
> > +}
> > +
> > +static void timeline_inactive(struct i915_timeline *tl)
> > +{
> > + struct i915_gt_timelines *gt = &tl->i915->gt.timelines;
> > +
> > + mutex_lock(>->mutex);
> > + list_del(&tl->link);
> > + mutex_unlock(>->mutex);
> > +}
>
> Bike shedding comments only:
> Would it be better to use a verb suffix? Even though timeline_activate
> also wouldn't sound perfect. Since it is file local - activate_timeline?
> Or even just inli
Re: [Intel-gfx] [PATCH 26/34] drm/i915: Identify active requests
On 21/01/2019 22:21, Chris Wilson wrote:
To allow requests to forgo a common execution timeline, one question we
need to be able to answer is "is this request running?". To track
whether a request has started on HW, we can emit a breadcrumb at the
beginning of the request and check its timeline's HWSP to see if the
breadcrumb has advanced past the start of this request. (This is in
contrast to the global timeline where we need only ask if we are on the
global timeline and if the timeline has advanced past the end of the
previous request.)
There is still confusion from a preempted request, which has already
started but relinquished the HW to a high priority request. For the
common case, this discrepancy should be negligible. However, for
identification of hung requests, knowing which one was running at the
time of the hang will be much more important.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 +++
drivers/gpu/drm/i915/i915_request.c | 9 ++--
drivers/gpu/drm/i915/i915_request.h | 1 +
drivers/gpu/drm/i915/i915_timeline.c | 1 +
drivers/gpu/drm/i915/i915_timeline.h | 2 +
drivers/gpu/drm/i915/intel_engine_cs.c | 4 +-
drivers/gpu/drm/i915/intel_lrc.c | 47
drivers/gpu/drm/i915/intel_ringbuffer.c | 43 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 6 ++-
drivers/gpu/drm/i915/selftests/mock_engine.c | 2 +-
10 files changed, 86 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index f250109e1f66..defe7d60bb88 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1976,6 +1976,12 @@ static int eb_submit(struct i915_execbuffer *eb)
return err;
}
+ if (eb->engine->emit_init_breadcrumb) {
+ err = eb->engine->emit_init_breadcrumb(eb->request);
+ if (err)
+ return err;
+ }
+
err = eb->engine->emit_bb_start(eb->request,
eb->batch->node.start +
eb->batch_start_offset,
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index bb2885f1dc1e..0a8a2a1bf55d 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -333,6 +333,7 @@ void i915_request_retire_upto(struct i915_request *rq)
static u32 timeline_get_seqno(struct i915_timeline *tl)
{
+ tl->seqno += tl->has_initial_breadcrumb;
return ++tl->seqno;
return tl->seqno += 1 + tl->has_initial_breadcrumb?
Not sure if it would make any difference in the code.
}
@@ -382,8 +383,8 @@ void __i915_request_submit(struct i915_request *request)
intel_engine_enable_signaling(request, false);
spin_unlock(&request->lock);
- engine->emit_breadcrumb(request,
- request->ring->vaddr + request->postfix);
+ engine->emit_fini_breadcrumb(request,
+request->ring->vaddr + request->postfix);
/* Transfer from per-context onto the global per-engine timeline */
move_to_timeline(request, &engine->timeline);
@@ -657,7 +658,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
* around inside i915_request_add() there is sufficient space at
* the beginning of the ring as well.
*/
- rq->reserved_space = 2 * engine->emit_breadcrumb_sz * sizeof(u32);
+ rq->reserved_space = 2 * engine->emit_fini_breadcrumb_sz * sizeof(u32);
Logic being fini breadcrumb is at least as big as the init one? I can't
think of any easy asserts to verify that.
Also, a little bit of ring space wastage but I guess we don't care.
/*
* Record the position of the start of the request so that
@@ -908,7 +909,7 @@ void i915_request_add(struct i915_request *request)
* GPU processing the request, we never over-estimate the
* position of the ring's HEAD.
*/
- cs = intel_ring_begin(request, engine->emit_breadcrumb_sz);
+ cs = intel_ring_begin(request, engine->emit_fini_breadcrumb_sz);
GEM_BUG_ON(IS_ERR(cs));
request->postfix = intel_ring_offset(request, cs);
diff --git a/drivers/gpu/drm/i915/i915_request.h b/drivers/gpu/drm/i915/i915_request.h
index 96c586d6ff4d..340d6216791c 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -344,6 +344,7 @@ static inline bool i915_request_started(const struct
i915_request *rq)
if (i915_request_signaled(rq))
return true;
+ /* Remember: started but may have since been preempted! */
return i915_seqno_passed(hwsp_seqno(rq), rq->fence.seqno - 1);
}
diff --git a/drivers/gpu/drm/i915/i915_timeli
Re: [Intel-gfx] [PATCH 26/34] drm/i915: Identify active requests
Quoting Tvrtko Ursulin (2019-01-22 15:34:07)
>
> On 21/01/2019 22:21, Chris Wilson wrote:
> > To allow requests to forgo a common execution timeline, one question we
> > need to be able to answer is "is this request running?". To track
> > whether a request has started on HW, we can emit a breadcrumb at the
> > beginning of the request and check its timeline's HWSP to see if the
> > breadcrumb has advanced past the start of this request. (This is in
> > contrast to the global timeline where we need only ask if we are on the
> > global timeline and if the timeline has advanced past the end of the
> > previous request.)
> >
> > There is still confusion from a preempted request, which has already
> > started but relinquished the HW to a high priority request. For the
> > common case, this discrepancy should be negligible. However, for
> > identification of hung requests, knowing which one was running at the
> > time of the hang will be much more important.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 +++
> > drivers/gpu/drm/i915/i915_request.c | 9 ++--
> > drivers/gpu/drm/i915/i915_request.h | 1 +
> > drivers/gpu/drm/i915/i915_timeline.c | 1 +
> > drivers/gpu/drm/i915/i915_timeline.h | 2 +
> > drivers/gpu/drm/i915/intel_engine_cs.c | 4 +-
> > drivers/gpu/drm/i915/intel_lrc.c | 47
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 43 ++
> > drivers/gpu/drm/i915/intel_ringbuffer.h | 6 ++-
> > drivers/gpu/drm/i915/selftests/mock_engine.c | 2 +-
> > 10 files changed, 86 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index f250109e1f66..defe7d60bb88 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -1976,6 +1976,12 @@ static int eb_submit(struct i915_execbuffer *eb)
> > return err;
> > }
> >
> > + if (eb->engine->emit_init_breadcrumb) {
> > + err = eb->engine->emit_init_breadcrumb(eb->request);
> > + if (err)
> > + return err;
> > + }
> > +
> > err = eb->engine->emit_bb_start(eb->request,
> > eb->batch->node.start +
> > eb->batch_start_offset,
> > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > b/drivers/gpu/drm/i915/i915_request.c
> > index bb2885f1dc1e..0a8a2a1bf55d 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -333,6 +333,7 @@ void i915_request_retire_upto(struct i915_request *rq)
> >
> > static u32 timeline_get_seqno(struct i915_timeline *tl)
> > {
> > + tl->seqno += tl->has_initial_breadcrumb;
> > return ++tl->seqno;
>
> return tl->seqno += 1 + tl->has_initial_breadcrumb?
>
> Not sure if it would make any difference in the code.
Identical code generation, but looks better than conditional increment
then pre-increment.
> > @@ -382,8 +383,8 @@ void __i915_request_submit(struct i915_request *request)
> > intel_engine_enable_signaling(request, false);
> > spin_unlock(&request->lock);
> >
> > - engine->emit_breadcrumb(request,
> > - request->ring->vaddr + request->postfix);
> > + engine->emit_fini_breadcrumb(request,
> > + request->ring->vaddr + request->postfix);
> >
> > /* Transfer from per-context onto the global per-engine timeline */
> > move_to_timeline(request, &engine->timeline);
> > @@ -657,7 +658,7 @@ i915_request_alloc(struct intel_engine_cs *engine,
> > struct i915_gem_context *ctx)
> >* around inside i915_request_add() there is sufficient space at
> >* the beginning of the ring as well.
> >*/
> > - rq->reserved_space = 2 * engine->emit_breadcrumb_sz * sizeof(u32);
> > + rq->reserved_space = 2 * engine->emit_fini_breadcrumb_sz *
> > sizeof(u32);
>
> Logic being fini breadcrumb is at least as big as the init one? I can't
> think of any easy asserts to verify that.
We emit engine->emit_init_breadcrumbs() normally, it's just
engine->emit_fini_breadcrumbs() that is in the reserved portion.
The factor of 2 is to waste space on wraparound.
> Also, a little bit of ring space wastage but I guess we don't care.
We don't actually waste space, we only use emit_fini_breadcrumbs_sz, we
just flush enough of the ring for 2*sz to be sure that even if we have
to wrap, there's enough room at the start of the ring for our emit.
So overzealous on flushing if the ring is full, in which case we are
throttling a millisecond earlier than is strictly required (given that
the ring already contains about a few seconds worth of batches)
The real problem here is that throttling one client,
Re: [Intel-gfx] [PATCH 27/34] drm/i915: Remove the intel_engine_notify tracepoint
On 21/01/2019 22:21, Chris Wilson wrote:
The global seqno is defunct and so we have no meaningful indicator of
forward progress for an engine. You need to listen to the request
signaling tracepoints instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 2 --
drivers/gpu/drm/i915/i915_trace.h | 25 -
2 files changed, 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5fd5080c4ccb..71d11dc2c235 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1209,8 +1209,6 @@ static void notify_ring(struct intel_engine_cs *engine)
wake_up_process(tsk);
rcu_read_unlock();
-
- trace_intel_engine_notify(engine, wait);
}
static void vlv_c0_read(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 33d90eca9cdd..cb5bc65d575d 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -750,31 +750,6 @@ trace_i915_request_out(struct i915_request *rq)
#endif
#endif
-TRACE_EVENT(intel_engine_notify,
- TP_PROTO(struct intel_engine_cs *engine, bool waiters),
- TP_ARGS(engine, waiters),
-
- TP_STRUCT__entry(
-__field(u32, dev)
-__field(u16, class)
-__field(u16, instance)
-__field(u32, seqno)
-__field(bool, waiters)
-),
-
- TP_fast_assign(
- __entry->dev = engine->i915->drm.primary->index;
- __entry->class = engine->uabi_class;
- __entry->instance = engine->instance;
- __entry->seqno = intel_engine_get_seqno(engine);
- __entry->waiters = waiters;
- ),
-
- TP_printk("dev=%u, engine=%u:%u, seqno=%u, waiters=%u",
- __entry->dev, __entry->class, __entry->instance,
- __entry->seqno, __entry->waiters)
-);
-
DEFINE_EVENT(i915_request, i915_request_retire,
TP_PROTO(struct i915_request *rq),
TP_ARGS(rq)
I cannot decide if keeping what we can would make it useful. Certainly
not for debugging intel_engine_breadcrumbs_irq.. a sequence of
intel_engine_notify(dev, class, instance) -> dma_fence_signaled would be
a very unreliable trace of what engine actually executed something. What
do you think?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Avoid divide by zero
== Series Details ==
Series: drm/i915: Avoid divide by zero
URL : https://patchwork.freedesktop.org/series/55560/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5464 -> Patchwork_12005
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55560/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12005 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#107341]
* igt@i915_module_load@reload:
- fi-blb-e6850: NOTRUN -> INCOMPLETE [fdo#107718]
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#108767]
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998]
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: PASS -> FAIL [fdo#104008]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107341]: https://bugs.freedesktop.org/show_bug.cgi?id=107341
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (45 -> 41)
--
Additional (1): fi-skl-6770hq
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-icl-y
Build changes
-
* Linux: CI_DRM_5464 -> Patchwork_12005
CI_DRM_5464: af90b519a670a3aec89045d9fcca8f2d174adeda @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4782: 96f3a1b876e0dd24706b85fb872f12031a436e84 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12005: d2fc4d12140ad34b584bb8c0ca2074af9a821794 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d2fc4d12140a drm/i915: Avoid divide by zero
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12005/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid divide by zero
On Tue, Jan 22, 2019 at 02:58:24PM +0200, Mika Kahola wrote: > Avoid divide by zero warning on static analysis. > > Signed-off-by: Mika Kahola > --- > drivers/gpu/drm/i915/intel_pm.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 8b63afa3a221..6a8e8b3f44c2 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -3912,8 +3912,10 @@ skl_ddb_get_pipe_allocation_limits(struct > drm_i915_private *dev_priv, > pipe_width = hdisplay; > } > > - alloc->start = ddb_size * width_before_pipe / total_width; > - alloc->end = ddb_size * (width_before_pipe + pipe_width) / total_width; > + alloc->start = total_width == 0 ? > + 0 : ddb_size * width_before_pipe / total_width; > + alloc->end = total_width == 0 ? > + 0 : ddb_size * (width_before_pipe + pipe_width) / total_width; Can't happen. > } > > static unsigned int skl_cursor_allocation(int num_active) > -- > 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
Re: [Intel-gfx] [PATCH 7/7] drm/i915/perf: add flushing ioctl
Quoting Lionel Landwerlin (2019-01-16 17:36:22)
> With the currently available parameters for the i915-perf stream,
> there are still situations that are not well covered :
>
> If an application opens the stream with polling disable or at very low
> frequency and OA interrupt enabled, no data will be available even
> though somewhere between nothing and half of the OA buffer worth of
> data might have landed in memory.
>
> To solve this issue we have a new flush ioctl on the perf stream that
> forces the i915-perf driver to look at the state of the buffer when
> called and makes any data available through both poll() & read() type
> syscalls.
>
> Signed-off-by: Lionel Landwerlin
Link to userspace changes?
Regards, Joonas
> ---
> drivers/gpu/drm/i915/i915_perf.c | 17 +
> include/uapi/drm/i915_drm.h | 19 +++
> 2 files changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index da721fce2543..6c98ffa2135e 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -2433,6 +2433,20 @@ static void i915_perf_disable_locked(struct
> i915_perf_stream *stream)
> stream->ops->disable(stream);
> }
>
> +/**
> + * i915_perf_flush_data - handle `I915_PERF_IOCTL_FLUSH_DATA` ioctl
> + * @stream: An enabled i915 perf stream
> + *
> + * The intention is to flush all the data available for reading from the OA
> + * buffer
> + */
> +static void i915_perf_flush_data(struct i915_perf_stream *stream)
> +{
> + struct drm_i915_private *dev_priv = stream->dev_priv;
> +
> + dev_priv->perf.oa.pollin = oa_buffer_check(stream->dev_priv, true);
> +}
> +
> /**
> * i915_perf_ioctl - support ioctl() usage with i915 perf stream FDs
> * @stream: An i915 perf stream
> @@ -2456,6 +2470,9 @@ static long i915_perf_ioctl_locked(struct
> i915_perf_stream *stream,
> case I915_PERF_IOCTL_DISABLE:
> i915_perf_disable_locked(stream);
> return 0;
> + case I915_PERF_IOCTL_FLUSH_DATA:
> + i915_perf_flush_data(stream);
> + return 0;
> }
>
> return -EINVAL;
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index b6db5e544a35..0f0d20080572 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -1594,6 +1594,25 @@ struct drm_i915_perf_open_param {
> */
> #define I915_PERF_IOCTL_DISABLE_IO('i', 0x1)
>
> +/**
> + * Actively check the availability of data from a stream.
> + *
> + * A stream data availability can be driven by two types of events :
> + *
> + * - if enabled, the kernel's hrtimer checking the amount of available data
> + * in the OA buffer through head/tail registers.
> + *
> + * - if enabled, the OA unit's interrupt mechanism
> + *
> + * The kernel hrtimer incur a cost of running callback at fixed time
> + * intervals, while the OA interrupt might only happen rarely. In the
> + * situation where the application has disabled the kernel's hrtimer and only
> + * uses the OA interrupt to know about available data, the application can
> + * request an active check of the available OA data through this ioctl. This
> + * will make any data in the OA buffer available with either poll() or
> read().
> + */
> +#define I915_PERF_IOCTL_FLUSH_DATA _IO('i', 0x2)
> +
> /**
> * Common to all i915 perf records
> */
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: correct the pitch check for NV12 framebuffer
Hi Ville,
NV12 support for small src viewport sizes and rotation vs clipping scenarios
are added into IGT by JP.
Commit details are as follows.
commit 8614d5eb114a660c3bd7ff77eab8bed53424cd30
Author: Juha-Pekka Heikkila
Date: Fri Dec 21 15:42:33 2018 +0200
tests/kms_rotation_crc: add NV12 support for multiplane* tests
Can you please review the patch again? As suggested I have removed the if..else
check in intel_framebuffer_init().
Regards,
Raviraj
> -Original Message-
> From: Sitaram, Raviraj P
> Sent: Wednesday, December 19, 2018 1:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Sitaram, Raviraj P ; Hwang, Dongseong
> ; Konduru, Chandra ;
> Srinivas, Vidya ; Ville Syrjälä
> ; Juha-Pekka Heikkila
>
> Subject: [PATCH v3] drm/i915: correct the pitch check for NV12 framebuffer
>
> From: P Raviraj Sitaram
>
> framebuffer for NV12 requires the pitch to the multiplier of 4, instead of
> the width.
> This patch corrects it.
>
> For instance, a 480p video, whose width and pitch are 854 and 896
> respectively, is
> excluded for NV12 plane so far.
>
> Changes since v1:
> - Removed check for NV12 buffer dimensions since additional checks
> are done for viewport size in intel_sprite.c
>
> Signed-off-by: Dongseong Hwang
> Signed-off-by: P Raviraj Sitaram
> Cc: Chandra Konduru
> Cc: Vidya Srinivas
> Cc: Ville Syrjälä
> Cc: Juha-Pekka Heikkila
> ---
> drivers/gpu/drm/i915/intel_display.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 3b7094822aa9..fa349182d0da 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14597,14 +14597,6 @@ static int intel_framebuffer_init(struct
> intel_framebuffer
> *intel_fb,
>
> drm_helper_mode_fill_fb_struct(&dev_priv->drm, fb, mode_cmd);
>
> - if (fb->format->format == DRM_FORMAT_NV12 &&
> - (fb->width < SKL_MIN_YUV_420_SRC_W ||
> - fb->height < SKL_MIN_YUV_420_SRC_H ||
> - (fb->width % 4) != 0 || (fb->height % 4) != 0)) {
> - DRM_DEBUG_KMS("src dimensions not correct for NV12\n");
> - goto err;
> - }
> -
> for (i = 0; i < fb->format->num_planes; i++) {
> u32 stride_alignment;
>
> --
> 2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote: > According to our IOMMU folks there exists some desire to be able to assign > the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off > due to how the devices might be grouped in IOMMU groups. Even when you > would not be using the iGFX device. You can force the igfx device into a SI domain, or does that also trigger the iommu issues on the chipset? In any case, if iommu=on breaks these systems I want to make them work again with opt-out, even at the cost of breaking assignability. Regards, Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use fb width to measure fb width instead of visible plane width when verify NV12
== Series Details ==
Series: drm/i915: Use fb width to measure fb width instead of visible plane
width when verify NV12
URL : https://patchwork.freedesktop.org/series/8/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5463_full -> Patchwork_12004_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12004_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_nop@signal-all:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_color@pipe-c-ctm-max:
- shard-apl: PASS -> FAIL [fdo#108147]
* igt@kms_cursor_crc@cursor-256x256-sliding:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-glk: PASS -> FAIL [fdo#105363]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-fullscreen:
- shard-glk: PASS -> FAIL [fdo#103167]
* igt@kms_setmode@basic:
- shard-kbl: PASS -> FAIL [fdo#99912]
Possible fixes
* igt@kms_cursor_crc@cursor-128x42-sliding:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- shard-apl: FAIL [fdo#103166] -> PASS
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-kbl: FAIL [fdo#109381] -> PASS
* igt@kms_setmode@basic:
- shard-apl: FAIL [fdo#99912] -> PASS
* igt@perf_pmu@rc6:
- shard-kbl: {SKIP} [fdo#109271] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109381]: https://bugs.freedesktop.org/show_bug.cgi?id=109381
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5463 -> Patchwork_12004
CI_DRM_5463: 6bd1569466edcb2f890a374be27f0eb6780963f9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4782: 96f3a1b876e0dd24706b85fb872f12031a436e84 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12004: d607a5109524a7bf7a9d77b1465a627a20c42021 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12004/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/15] drm/i915/tv: Generate better pipe timings for TV encoder
On Mon, Nov 12, 2018 at 06:59:58PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To make vblank timestamps work better with the TV encoder let's
> scale the pipe timings such that the relationship between the
> TV active and TV blanking periods is mirrored in the
> corresponding pipe timings.
>
> Note that in reality the pipe runs at a faster speed during the
> TV vblank, and correspondigly there are periods when the pipe
> is enitrely stopped. We pretend that this isn't the case and
> as such we incur some error in the vblank timestamps during
> the TV vblank. Further explanation of the issues in a big
> comment in the code.
>
> This makes the vblank timestamps good enough to make
> i965gm (which doesn't have a working frame counter with
> the TV encoder) report correct frame numbers. Previously
> you could get all kinds of nonsense which resulted in
> eg. glxgears reporting that it's running at twice the
> actual framerate in most cases.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_tv.c | 322 +++-
> 2 files changed, 278 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index fe4b913e46ac..10813ae7bee7 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4848,6 +4848,7 @@ enum {
> # define TV_OVERSAMPLE_NONE (2 << 18)
> /* Selects 8x oversampling */
> # define TV_OVERSAMPLE_8X(3 << 18)
> +# define TV_OVERSAMPLE_MASK (3 << 18)
> /* Selects progressive mode rather than interlaced */
> # define TV_PROGRESSIVE (1 << 17)
> /* Sets the colorburst to PAL mode. Required for non-M PAL modes. */
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 216525dd144a..75126fce655d 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -340,7 +340,6 @@ struct tv_mode {
> const struct video_levels *composite_levels, *svideo_levels;
> const struct color_conversion *composite_color, *svideo_color;
> const u32 *filter_table;
> - u16 max_srcw;
> };
>
>
> @@ -729,7 +728,6 @@ static const struct tv_mode tv_modes[] = {
> .burst_ena = false,
>
> .filter_table = filter_table,
> - .max_srcw = 800
> },
> {
> .name = "1080i@50Hz",
> @@ -947,13 +945,183 @@ intel_tv_mode_vdisplay(const struct tv_mode *tv_mode)
> return 2 * (tv_mode->nbr_end + 1);
> }
>
> +static void
> +intel_tv_mode_to_mode(struct drm_display_mode *mode,
> + const struct tv_mode *tv_mode)
> +{
> + mode->clock = tv_mode->clock /
> + (tv_mode->oversample >> !tv_mode->progressive);
> +
> + /*
> + * tv_mode horizontal timings:
> + *
> + * hsync_end
> + *| hblank_end
> + *|| hblank_start
> + *|| | htotal
> + *| ___|
> + * / \___
> + * \__/\
> + */
> + mode->hdisplay =
> + tv_mode->hblank_start - tv_mode->hblank_end;
> + mode->hsync_start = mode->hdisplay +
> + tv_mode->htotal - tv_mode->hblank_start;
> + mode->hsync_end = mode->hsync_start +
> + tv_mode->hsync_end;
> + mode->htotal = tv_mode->htotal + 1;
> +
> + /*
> + * tv_mode vertical timings:
> + *
> + * vsync_start
> + *| vsync_end
> + *| | vi_end nbr_end
> + *| || |
> + *| | ___
> + * \__/ \
> + *\__/
> + */
> + mode->vdisplay = intel_tv_mode_vdisplay(tv_mode);
> + if (tv_mode->progressive) {
> + mode->vsync_start = mode->vdisplay +
> + tv_mode->vsync_start_f1 + 1;
> + mode->vsync_end = mode->vsync_start +
> + tv_mode->vsync_len;
> + mode->vtotal = mode->vdisplay +
> + tv_mode->vi_end_f1 + 1;
> + } else {
> + mode->vsync_start = mode->vdisplay +
> + tv_mode->vsync_start_f1 + 1 +
> + tv_mode->vsync_start_f2 + 1;
> + mode->vsync_end = mode->vsync_start +
> + 2 * tv_mode->vsync_len;
> + mode->vtotal = mode->vdisplay +
> + tv_mode->vi_end_f1 + 1 +
> + tv_mode->vi_end_f2 + 1;
> + }
> +
> + /* TV has it's own notion of sync and other mode flags, so clear them.
> */
> + mode->flags = 0;
> +
> + mode->vrefresh = 0;
Redundant line.
> + mode->vrefresh = drm_mode_vrefresh(mode);
> +
> + snprintf(mode->name, sizeof(mode->name),
> + "%dx%d%c (%s)",
> + mode->hdisplay, mode->vdisplay,
> + tv_mode->progressive ? 'p' : 'i',
> + tv_mode->name
Re: [Intel-gfx] [PATCH 13/15] drm/i915/tv: Generate better pipe timings for TV encoder
On Tue, Jan 22, 2019 at 07:22:24PM +0200, Imre Deak wrote:
> On Mon, Nov 12, 2018 at 06:59:58PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > To make vblank timestamps work better with the TV encoder let's
> > scale the pipe timings such that the relationship between the
> > TV active and TV blanking periods is mirrored in the
> > corresponding pipe timings.
> >
> > Note that in reality the pipe runs at a faster speed during the
> > TV vblank, and correspondigly there are periods when the pipe
> > is enitrely stopped. We pretend that this isn't the case and
> > as such we incur some error in the vblank timestamps during
> > the TV vblank. Further explanation of the issues in a big
> > comment in the code.
> >
> > This makes the vblank timestamps good enough to make
> > i965gm (which doesn't have a working frame counter with
> > the TV encoder) report correct frame numbers. Previously
> > you could get all kinds of nonsense which resulted in
> > eg. glxgears reporting that it's running at twice the
> > actual framerate in most cases.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > drivers/gpu/drm/i915/intel_tv.c | 322 +++-
> > 2 files changed, 278 insertions(+), 45 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index fe4b913e46ac..10813ae7bee7 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4848,6 +4848,7 @@ enum {
> > # define TV_OVERSAMPLE_NONE(2 << 18)
> > /* Selects 8x oversampling */
> > # define TV_OVERSAMPLE_8X (3 << 18)
> > +# define TV_OVERSAMPLE_MASK(3 << 18)
> > /* Selects progressive mode rather than interlaced */
> > # define TV_PROGRESSIVE(1 << 17)
> > /* Sets the colorburst to PAL mode. Required for non-M PAL modes. */
> > diff --git a/drivers/gpu/drm/i915/intel_tv.c
> > b/drivers/gpu/drm/i915/intel_tv.c
> > index 216525dd144a..75126fce655d 100644
> > --- a/drivers/gpu/drm/i915/intel_tv.c
> > +++ b/drivers/gpu/drm/i915/intel_tv.c
> > @@ -340,7 +340,6 @@ struct tv_mode {
> > const struct video_levels *composite_levels, *svideo_levels;
> > const struct color_conversion *composite_color, *svideo_color;
> > const u32 *filter_table;
> > - u16 max_srcw;
> > };
> >
> >
> > @@ -729,7 +728,6 @@ static const struct tv_mode tv_modes[] = {
> > .burst_ena = false,
> >
> > .filter_table = filter_table,
> > - .max_srcw = 800
> > },
> > {
> > .name = "1080i@50Hz",
> > @@ -947,13 +945,183 @@ intel_tv_mode_vdisplay(const struct tv_mode *tv_mode)
> > return 2 * (tv_mode->nbr_end + 1);
> > }
> >
> > +static void
> > +intel_tv_mode_to_mode(struct drm_display_mode *mode,
> > + const struct tv_mode *tv_mode)
> > +{
> > + mode->clock = tv_mode->clock /
> > + (tv_mode->oversample >> !tv_mode->progressive);
> > +
> > + /*
> > +* tv_mode horizontal timings:
> > +*
> > +* hsync_end
> > +*| hblank_end
> > +*|| hblank_start
> > +*|| | htotal
> > +*| ___|
> > +* / \___
> > +* \__/\
> > +*/
> > + mode->hdisplay =
> > + tv_mode->hblank_start - tv_mode->hblank_end;
> > + mode->hsync_start = mode->hdisplay +
> > + tv_mode->htotal - tv_mode->hblank_start;
> > + mode->hsync_end = mode->hsync_start +
> > + tv_mode->hsync_end;
> > + mode->htotal = tv_mode->htotal + 1;
> > +
> > + /*
> > +* tv_mode vertical timings:
> > +*
> > +* vsync_start
> > +*| vsync_end
> > +*| | vi_end nbr_end
> > +*| || |
> > +*| | ___
> > +* \__/ \
> > +*\__/
> > +*/
> > + mode->vdisplay = intel_tv_mode_vdisplay(tv_mode);
> > + if (tv_mode->progressive) {
> > + mode->vsync_start = mode->vdisplay +
> > + tv_mode->vsync_start_f1 + 1;
> > + mode->vsync_end = mode->vsync_start +
> > + tv_mode->vsync_len;
> > + mode->vtotal = mode->vdisplay +
> > + tv_mode->vi_end_f1 + 1;
> > + } else {
> > + mode->vsync_start = mode->vdisplay +
> > + tv_mode->vsync_start_f1 + 1 +
> > + tv_mode->vsync_start_f2 + 1;
> > + mode->vsync_end = mode->vsync_start +
> > + 2 * tv_mode->vsync_len;
> > + mode->vtotal = mode->vdisplay +
> > + tv_mode->vi_end_f1 + 1 +
> > + tv_mode->vi_end_f2 + 1;
> > + }
> > +
> > + /* TV has it's own notion of sync and other mode flags, so clear them.
> > */
> > + mode->flags = 0;
> > +
> > + mode->vrefresh = 0;
>
> Redundant line.
drm_mode_vrefresh() won't recompute the value if it's already
s
Re: [Intel-gfx] [PATCH 1/5] drm/i915/backlight: Restore backlight on resume, v3.
On Tue, 08 Jan 2019, Maarten Lankhorst
wrote:
> Restore our saved values for backlight. This way even with fastset on
> S4 resume we will correctly restore the backlight to the active values.
>
> Changes since v1:
> - Call enable_backlight() when backlight.level is set. On suspend
> backlight.enabled is always cleared, this makes it not a good
> indicator. Also check for crtc->state->active.
> Changes since v2:
> - Use the new update_pipe() callback to run this on resume as well.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Tolga Cakir
> Cc: Basil Eric Rabi
> Cc: Hans de Goede
> Cc: Ville Syrjälä
> Reported-by: Ville Syrjälä
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/icl_dsi.c | 1 +
> drivers/gpu/drm/i915/intel_ddi.c | 2 ++
> drivers/gpu/drm/i915/intel_dp.c| 1 +
> drivers/gpu/drm/i915/intel_drv.h | 3 ++
> drivers/gpu/drm/i915/intel_lvds.c | 1 +
> drivers/gpu/drm/i915/intel_panel.c | 49 +++---
> drivers/gpu/drm/i915/vlv_dsi.c | 1 +
> 7 files changed, 47 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index 4dd793b78996..3f92881600c5 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -1378,6 +1378,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
> encoder->disable = gen11_dsi_disable;
> encoder->port = port;
> encoder->get_config = gen11_dsi_get_config;
> + encoder->update_pipe = intel_panel_update_backlight;
> encoder->compute_config = gen11_dsi_compute_config;
> encoder->get_hw_state = gen11_dsi_get_hw_state;
> encoder->type = INTEL_OUTPUT_DSI;
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 2d6ed990a232..d32865dc44e8 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3548,6 +3548,8 @@ static void intel_ddi_update_pipe_dp(struct
> intel_encoder *encoder,
>
> intel_psr_enable(intel_dp, crtc_state);
> intel_edp_drrs_enable(intel_dp, crtc_state);
> +
> + intel_panel_update_backlight(encoder, crtc_state, conn_state);
> }
>
> static void intel_ddi_update_pipe(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 62fd11540942..0cbacdc70b07 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -6981,6 +6981,7 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
> intel_encoder->compute_config = intel_dp_compute_config;
> intel_encoder->get_hw_state = intel_dp_get_hw_state;
> intel_encoder->get_config = intel_dp_get_config;
> + intel_encoder->update_pipe = intel_panel_update_backlight;
> intel_encoder->suspend = intel_dp_encoder_suspend;
> if (IS_CHERRYVIEW(dev_priv)) {
> intel_encoder->pre_pll_enable = chv_dp_pre_pll_enable;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1a11c2beb7f3..0a6fb42e2086 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -2023,6 +2023,9 @@ int intel_panel_setup_backlight(struct drm_connector
> *connector,
> enum pipe pipe);
> void intel_panel_enable_backlight(const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state *conn_state);
> +void intel_panel_update_backlight(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state,
> + const struct drm_connector_state *conn_state);
> void intel_panel_disable_backlight(const struct drm_connector_state
> *old_conn_state);
> extern struct drm_display_mode *intel_find_panel_downclock(
> struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds.c
> index b85e195f7c8a..189693b4c5e8 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -909,6 +909,7 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
> }
> intel_encoder->get_hw_state = intel_lvds_get_hw_state;
> intel_encoder->get_config = intel_lvds_get_config;
> + intel_encoder->update_pipe = intel_panel_update_backlight;
> intel_connector->get_hw_state = intel_connector_get_hw_state;
>
> intel_connector_attach_encoder(intel_connector, intel_encoder);
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index ee3e0842d542..f71b33cf1c97 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1087,20 +1087,11 @@ static void pwm_enable_backlight(const struct
> intel_crtc_state *crtc_state,
> intel_panel_actually_set_backlight(conn_state, panel->backlight.level);
Re: [Intel-gfx] [PATCH 2/5] drm/i915/backlight: Fix backlight takeover on LPT, v3.
On Tue, 08 Jan 2019, Maarten Lankhorst
wrote:
> On lynxpoint the bios sometimes sets up the backlight using the CPU
> display, but the driver expects using the PWM PCH override register.
>
> Read the value from the CPU register, then convert it to the other
> units by converting from the old duty cycle, to freq, to the new units.
>
> This value is then programmed in the override register, after which
> we set the override and disable the CPU display control. This allows
> us to switch the source without flickering, and make the backlight
> controls work in the driver.
>
> Changes since v1:
> - Read BLC_PWM_CPU_CTL2 to cpu_ctl2.
> - Clean up cpu_mode if slightly.
> - Always disable BLM_PWM_ENABLE in cpu_ctl2.
> Changes since v2:
> - Simplify cpu_mode handling (Jani)
>
> Signed-off-by: Maarten Lankhorst
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108225
> Cc: Basil Eric Rabi
> Cc: Hans de Goede
> Cc: Tolga Cakir
> Cc: Ville Syrjälä
> Tested-by: Tolga Cakir
> Cc: Jani Nikula
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_panel.c | 26 ++
> 1 file changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index f71b33cf1c97..1c9ef54d58fe 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1493,8 +1493,8 @@ static int lpt_setup_backlight(struct intel_connector
> *connector, enum pipe unus
> {
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> struct intel_panel *panel = &connector->panel;
> - u32 pch_ctl1, pch_ctl2, val;
> - bool alt;
> + u32 cpu_ctl2, pch_ctl1, pch_ctl2, val;
> + bool alt, cpu_mode;
>
> if (HAS_PCH_LPT(dev_priv))
> alt = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY;
> @@ -1508,6 +1508,8 @@ static int lpt_setup_backlight(struct intel_connector
> *connector, enum pipe unus
> pch_ctl2 = I915_READ(BLC_PWM_PCH_CTL2);
> panel->backlight.max = pch_ctl2 >> 16;
>
> + cpu_ctl2 = I915_READ(BLC_PWM_CPU_CTL2);
> +
> if (!panel->backlight.max)
> panel->backlight.max = get_backlight_max_vbt(connector);
>
> @@ -1516,12 +1518,28 @@ static int lpt_setup_backlight(struct intel_connector
> *connector, enum pipe unus
>
> panel->backlight.min = get_backlight_min_vbt(connector);
>
> - val = lpt_get_backlight(connector);
> + panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
> +
> + cpu_mode = panel->backlight.enabled && HAS_PCH_LPT(dev_priv) &&
> +!(pch_ctl1 & BLM_PCH_OVERRIDE_ENABLE) &&
> +(cpu_ctl2 & BLM_PWM_ENABLE);
> + if (cpu_mode)
> + val = pch_get_backlight(connector);
> + else
> + val = lpt_get_backlight(connector);
> val = intel_panel_compute_brightness(connector, val);
> panel->backlight.level = clamp(val, panel->backlight.min,
> panel->backlight.max);
>
> - panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
> + if (cpu_mode) {
> + DRM_DEBUG_KMS("CPU backlight register was enabled, switching to
> PCH override\n");
> +
> + /* Write converted CPU PWM value to PCH override register */
> + lpt_set_backlight(connector->base.state,
> panel->backlight.level);
> + I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1 |
> BLM_PCH_OVERRIDE_ENABLE);
> +
> + I915_WRITE(BLC_PWM_CPU_CTL2, cpu_ctl2 & ~BLM_PWM_ENABLE);
> + }
>
> return 0;
> }
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Enable fastset for non-boot modesets.
On Tue, 08 Jan 2019, Maarten Lankhorst
wrote:
> Now that our state comparison functions are pretty complete, we should
> enable fastset by default when a modeset can be avoided. Even if we're
> not completely certain about the inherited state, we can be certain
> after the first modeset that our sw state matches the hw state.
>
> There is one testcase explicitly testing fastset,
> kms_panel_fitting.atomic-fastset but other testcases do so indirectly
> because most tests don't clean up the display during exit, or otherwise
> indirectly preserve mode by doing igt_display_reset or inheriting during
> init.
>
> Signed-off-by: Maarten Lankhorst
> Reviewed-by: Hans de Goede
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 696e6f5680df..f8cbdd50fa38 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11671,6 +11671,11 @@ intel_pipe_config_compare(struct drm_i915_private
> *dev_priv,
> (current_config->base.mode.private_flags &
> I915_MODE_FLAG_INHERITED) &&
> !(pipe_config->base.mode.private_flags &
> I915_MODE_FLAG_INHERITED);
>
> + if (fixup_inherited && !i915_modparams.fastboot) {
> + drm_dbg(DRM_UT_KMS, "initial modeset and fastboot not set\n");
DRM_DEBUG_KMS() please.
> + ret = false;
> + }
> +
> #define PIPE_CONF_CHECK_X(name) do { \
> if (current_config->name != pipe_config->name) { \
> pipe_config_err(adjust, __stringify(name), \
> @@ -12694,8 +12699,7 @@ static int intel_atomic_check(struct drm_device *dev,
> return ret;
> }
>
> - if (i915_modparams.fastboot &&
> - intel_pipe_config_compare(dev_priv,
> + if (intel_pipe_config_compare(dev_priv,
> to_intel_crtc_state(old_crtc_state),
> pipe_config, true)) {
> crtc_state->mode_changed = false;
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/perf: add flushing ioctl
On 22/01/2019 16:25, Joonas Lahtinen wrote: Quoting Lionel Landwerlin (2019-01-16 17:36:22) With the currently available parameters for the i915-perf stream, there are still situations that are not well covered : If an application opens the stream with polling disable or at very low frequency and OA interrupt enabled, no data will be available even though somewhere between nothing and half of the OA buffer worth of data might have landed in memory. To solve this issue we have a new flush ioctl on the perf stream that forces the i915-perf driver to look at the state of the buffer when called and makes any data available through both poll() & read() type syscalls. Signed-off-by: Lionel Landwerlin Link to userspace changes? Regards, Joonas Trying to get them uploaded to a branch on https://github.com/intel/metrics-discovery I'll let you know when it's available. -Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid divide by zero
On Tue, 22 Jan 2019, Ville Syrjälä wrote: > On Tue, Jan 22, 2019 at 02:58:24PM +0200, Mika Kahola wrote: >> Avoid divide by zero warning on static analysis. >> >> Signed-off-by: Mika Kahola >> --- >> drivers/gpu/drm/i915/intel_pm.c | 6 -- >> 1 file changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_pm.c >> b/drivers/gpu/drm/i915/intel_pm.c >> index 8b63afa3a221..6a8e8b3f44c2 100644 >> --- a/drivers/gpu/drm/i915/intel_pm.c >> +++ b/drivers/gpu/drm/i915/intel_pm.c >> @@ -3912,8 +3912,10 @@ skl_ddb_get_pipe_allocation_limits(struct >> drm_i915_private *dev_priv, >> pipe_width = hdisplay; >> } >> >> -alloc->start = ddb_size * width_before_pipe / total_width; >> -alloc->end = ddb_size * (width_before_pipe + pipe_width) / total_width; >> +alloc->start = total_width == 0 ? >> +0 : ddb_size * width_before_pipe / total_width; >> +alloc->end = total_width == 0 ? >> +0 : ddb_size * (width_before_pipe + pipe_width) / total_width; > > Can't happen. Yeah, it's about stfu the checker... > >> } >> >> static unsigned int skl_cursor_allocation(int num_active) >> -- >> 2.17.1 >> >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Apply a subtest filter
In bringup on simulated HW even rudimentary tests are slow, and so many
may fail that we want to be able to filter out the noise to focus on the
specific problem. Even just the tests groups provided for igt is not
specific enough, and we would like to isolate one particular subtest
(and probably subsubtests!). For simplicity, allow the user to provide a
command line parameter such as
i915.st_filter=i915_timeline_mock_selftests/igt_sync
to restrict ourselves to only running on subtest. The exact name to use
is given during a normal run, highlighted as an error if it failed,
debug otherwise. The test group is optional, and then all subtests are
compared for an exact match with the filter (most subtests have unique
names). The filter can be negated, e.g. i915.st_filter=!igt_sync and
then all tests but those that match will be run. More than one match can
be supplied separated by a comma, e.g.
i915.st_filter=igt_vma_create,igt_vma_pin1
to only run those specified, or
i915.st_filter=!igt_vma_create,!igt_vma_pin1
to run all but those named. Mixing a blacklist and whitelist will only
execute those subtests matching the whitelist so long as they are
previously blacklisted.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_selftest.h | 1 +
.../gpu/drm/i915/selftests/i915_selftest.c| 47 +++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_selftest.h
b/drivers/gpu/drm/i915/i915_selftest.h
index a73472dd12fd..207e21b478f2 100644
--- a/drivers/gpu/drm/i915/i915_selftest.h
+++ b/drivers/gpu/drm/i915/i915_selftest.h
@@ -31,6 +31,7 @@ struct i915_selftest {
unsigned long timeout_jiffies;
unsigned int timeout_ms;
unsigned int random_seed;
+ char *filter;
int mock;
int live;
};
diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 86c54ea37f48..b77dbf3f0690 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -197,6 +197,49 @@ int i915_live_selftests(struct pci_dev *pdev)
return 0;
}
+static bool apply_subtest_filter(const char *caller, const char *name)
+{
+ char *str, *filter, *tok;
+ bool result = true;
+
+ str = kstrdup(i915_selftest.filter, GFP_KERNEL);
+ if (!str)
+ return false;
+
+ for (filter = str; (tok = strsep(&filter, ","));) {
+ bool allow = true;
+ char *sl;
+
+ if (*tok == '!') {
+ allow = false;
+ tok++;
+ }
+
+ sl = strchr(tok, '/');
+ if (sl) {
+ *sl++ = '\0';
+ if (strcmp(tok, caller)) {
+ if (allow)
+ result = false;
+ continue;
+ }
+ tok = sl;
+ }
+
+ if (strcmp(tok, name)) {
+ if (allow)
+ result = false;
+ continue;
+ }
+
+ result = allow;
+ break;
+ }
+
+ kfree(str);
+ return result;
+}
+
int __i915_subtests(const char *caller,
const struct i915_subtest *st,
unsigned int count,
@@ -209,6 +252,9 @@ int __i915_subtests(const char *caller,
if (signal_pending(current))
return -EINTR;
+ if (!apply_subtest_filter(caller, st->name))
+ continue;
+
pr_debug(DRIVER_NAME ": Running %s/%s\n", caller, st->name);
GEM_TRACE("Running %s/%s\n", caller, st->name);
@@ -244,6 +290,7 @@ bool __igt_timeout(unsigned long timeout, const char *fmt,
...)
module_param_named(st_random_seed, i915_selftest.random_seed, uint, 0400);
module_param_named(st_timeout, i915_selftest.timeout_ms, uint, 0400);
+module_param_named(st_filter, i915_selftest.filter, charp, 0400);
module_param_named_unsafe(mock_selftests, i915_selftest.mock, int, 0400);
MODULE_PARM_DESC(mock_selftests, "Run selftests before loading, using mock
hardware (0:disabled [default], 1:run tests then load driver, -1:run tests then
exit module)");
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/selftest: Allow filtering of individual subtests
Take an environment variable, SELFTESTS=foo,bar, and pass that along to
the kernel (as i915.st_filter=foo,bar) to provide fine grained test
selection. This can be either as an exact match to select only that
test, or to exclude only test. For example,
SELFTESTS=igt_vma_create,igt_vma_pin1 i915_selftest --run mock_vma
SELFTESTS=!igt_vma_create i915_selftest --run mock_vma
Signed-off-by: Chris Wilson
---
tests/i915/selftest.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/tests/i915/selftest.c b/tests/i915/selftest.c
index 80e515c61..b8d7f0af1 100644
--- a/tests/i915/selftest.c
+++ b/tests/i915/selftest.c
@@ -28,10 +28,16 @@ IGT_TEST_DESCRIPTION("Basic unit tests for i915.ko");
igt_main
{
- igt_kselftests("i915",
- "mock_selftests=-1 disable_display=1",
- NULL, "mock");
- igt_kselftests("i915",
- "live_selftests=-1 disable_display=1",
- "live_selftests", "live");
+ const char *env = getenv("SELFTESTS");
+ char opts[1024];
+
+ igt_assert(snprintf(opts, sizeof(opts),
+ "mock_selftests=-1 disable_display=1 st_filter=%s",
+ env) < sizeof(opts));
+ igt_kselftests("i915", opts, NULL, "mock");
+
+ igt_assert(snprintf(opts, sizeof(opts),
+ "live_selftests=-1 disable_display=1 st_filter=%s",
+ env) < sizeof(opts));
+ igt_kselftests("i915", opts, "live_selftests", "live");
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid divide by zero
On Tue, Jan 22, 2019 at 08:09:40PM +0200, Jani Nikula wrote: > On Tue, 22 Jan 2019, Ville Syrjälä wrote: > > On Tue, Jan 22, 2019 at 02:58:24PM +0200, Mika Kahola wrote: > >> Avoid divide by zero warning on static analysis. > >> > >> Signed-off-by: Mika Kahola > >> --- > >> drivers/gpu/drm/i915/intel_pm.c | 6 -- > >> 1 file changed, 4 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/intel_pm.c > >> b/drivers/gpu/drm/i915/intel_pm.c > >> index 8b63afa3a221..6a8e8b3f44c2 100644 > >> --- a/drivers/gpu/drm/i915/intel_pm.c > >> +++ b/drivers/gpu/drm/i915/intel_pm.c > >> @@ -3912,8 +3912,10 @@ skl_ddb_get_pipe_allocation_limits(struct > >> drm_i915_private *dev_priv, > >>pipe_width = hdisplay; > >>} > >> > >> - alloc->start = ddb_size * width_before_pipe / total_width; > >> - alloc->end = ddb_size * (width_before_pipe + pipe_width) / total_width; > >> + alloc->start = total_width == 0 ? > >> + 0 : ddb_size * width_before_pipe / total_width; > >> + alloc->end = total_width == 0 ? > >> + 0 : ddb_size * (width_before_pipe + pipe_width) / total_width; > > > > Can't happen. > > Yeah, it's about stfu the checker... Feels like the tip of an iceberg. How many more uglies are we going to have to add? > > > > >> } > >> > >> static unsigned int skl_cursor_allocation(int num_active) > >> -- > >> 2.17.1 > >> > >> ___ > >> Intel-gfx mailing list > >> Intel-gfx@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Jani Nikula, Intel Open Source Graphics Center -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Apply a subtest filter
In bringup on simulated HW even rudimentary tests are slow, and so many
may fail that we want to be able to filter out the noise to focus on the
specific problem. Even just the tests groups provided for igt is not
specific enough, and we would like to isolate one particular subtest
(and probably subsubtests!). For simplicity, allow the user to provide a
command line parameter such as
i915.st_filter=i915_timeline_mock_selftests/igt_sync
to restrict ourselves to only running on subtest. The exact name to use
is given during a normal run, highlighted as an error if it failed,
debug otherwise. The test group is optional, and then all subtests are
compared for an exact match with the filter (most subtests have unique
names). The filter can be negated, e.g. i915.st_filter=!igt_sync and
then all tests but those that match will be run. More than one match can
be supplied separated by a comma, e.g.
i915.st_filter=igt_vma_create,igt_vma_pin1
to only run those specified, or
i915.st_filter=!igt_vma_create,!igt_vma_pin1
to run all but those named. Mixing a blacklist and whitelist will only
execute those subtests matching the whitelist so long as they are
previously excluded in the blacklist.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
Fixup the no filter fail.
-Chris
---
drivers/gpu/drm/i915/i915_selftest.h | 1 +
.../gpu/drm/i915/selftests/i915_selftest.c| 47 +++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_selftest.h
b/drivers/gpu/drm/i915/i915_selftest.h
index a73472dd12fd..207e21b478f2 100644
--- a/drivers/gpu/drm/i915/i915_selftest.h
+++ b/drivers/gpu/drm/i915/i915_selftest.h
@@ -31,6 +31,7 @@ struct i915_selftest {
unsigned long timeout_jiffies;
unsigned int timeout_ms;
unsigned int random_seed;
+ char *filter;
int mock;
int live;
};
diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 86c54ea37f48..050af81b8028 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -197,6 +197,49 @@ int i915_live_selftests(struct pci_dev *pdev)
return 0;
}
+static bool apply_subtest_filter(const char *caller, const char *name)
+{
+ char *str, *filter, *tok;
+ bool result = true;
+
+ str = kstrdup(i915_selftest.filter, GFP_KERNEL);
+ if (!str)
+ return true;
+
+ for (filter = str; (tok = strsep(&filter, ","));) {
+ bool allow = true;
+ char *sl;
+
+ if (*tok == '!') {
+ allow = false;
+ tok++;
+ }
+
+ sl = strchr(tok, '/');
+ if (sl) {
+ *sl++ = '\0';
+ if (strcmp(tok, caller)) {
+ if (allow)
+ result = false;
+ continue;
+ }
+ tok = sl;
+ }
+
+ if (strcmp(tok, name)) {
+ if (allow)
+ result = false;
+ continue;
+ }
+
+ result = allow;
+ break;
+ }
+
+ kfree(str);
+ return result;
+}
+
int __i915_subtests(const char *caller,
const struct i915_subtest *st,
unsigned int count,
@@ -209,6 +252,9 @@ int __i915_subtests(const char *caller,
if (signal_pending(current))
return -EINTR;
+ if (!apply_subtest_filter(caller, st->name))
+ continue;
+
pr_debug(DRIVER_NAME ": Running %s/%s\n", caller, st->name);
GEM_TRACE("Running %s/%s\n", caller, st->name);
@@ -244,6 +290,7 @@ bool __igt_timeout(unsigned long timeout, const char *fmt,
...)
module_param_named(st_random_seed, i915_selftest.random_seed, uint, 0400);
module_param_named(st_timeout, i915_selftest.timeout_ms, uint, 0400);
+module_param_named(st_filter, i915_selftest.filter, charp, 0400);
module_param_named_unsafe(mock_selftests, i915_selftest.mock, int, 0400);
MODULE_PARM_DESC(mock_selftests, "Run selftests before loading, using mock
hardware (0:disabled [default], 1:run tests then load driver, -1:run tests then
exit module)");
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Avoid divide by zero
== Series Details ==
Series: drm/i915: Avoid divide by zero
URL : https://patchwork.freedesktop.org/series/55560/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5464_full -> Patchwork_12005_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12005_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_available_modes_crc@available_mode_test_crc:
- shard-apl: PASS -> FAIL [fdo#106641]
- shard-glk: PASS -> FAIL [fdo#106641]
* igt@kms_busy@extended-pageflip-hang-newfb-render-a:
- shard-glk: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-snb: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_color@pipe-c-ctm-max:
- shard-apl: PASS -> FAIL [fdo#108147]
* igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x64-onscreen:
- shard-apl: PASS -> FAIL [fdo#103232] +2
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: PASS -> FAIL [fdo#105767]
* igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-hsw: PASS -> FAIL [fdo#103355]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
- shard-glk: PASS -> FAIL [fdo#103167] +1
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-c-tiling-x:
- shard-glk: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- shard-apl: PASS -> FAIL [fdo#103166] +1
Possible fixes
* igt@gem_tiled_swapping@non-threaded:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-snb: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-apl: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_cursor_crc@cursor-256x256-dpms:
- shard-glk: FAIL [fdo#103232] -> PASS +3
* igt@kms_cursor_legacy@cursora-vs-flipa-atomic-transitions-varying-size:
- shard-snb: {SKIP} [fdo#109271] -> PASS +4
* igt@kms_cursor_legacy@pipe-c-torture-move:
- shard-hsw: DMESG-WARN [fdo#107122] -> PASS
* igt@kms_flip@flip-vs-expired-vblank:
- shard-glk: FAIL [fdo#105363] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: FAIL [fdo#103167] -> PASS +1
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-move:
- shard-glk: FAIL [fdo#103167] -> PASS
* igt@kms_plane@pixel-format-pipe-a-planes-source-clamping:
- shard-apl: FAIL [fdo#108948] -> PASS
* igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-apl: FAIL [fdo#103166] -> PASS +2
* igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-glk: FAIL [fdo#103166] -> PASS +1
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-apl: DMESG-FAIL [fdo#108950] -> PASS
* igt@kms_setmode@basic:
- shard-glk: FAIL [fdo#99912] -> PASS
* igt@prime_vgem@basic-fence-flip:
- shard-kbl: FAIL [fdo#104008] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103355]: https://bugs.freedesktop.org/show_bug.cgi?id=103355
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#105767]: https://bugs.freedesktop.org/show_bug.cgi?id=105767
[fdo#106641]: https://bugs.freedesktop.org/show_bug.cgi?id=106641
[fdo#107122]: https://bugs.freedesktop.org/show_bug.cgi?id=107122
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147
[fdo#108948]: https://bugs.freedesktop.org/show_bug.cgi?id=108948
[fdo#108950]: https://bugs.freedesktop.org/show_bug.cgi?id=108950
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Apply a subtest filter (rev2)
== Series Details ==
Series: drm/i915/selftests: Apply a subtest filter (rev2)
URL : https://patchwork.freedesktop.org/series/55576/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5464 -> Patchwork_12006
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55576/revisions/2/mbox/
Known issues
Here are the changes found in Patchwork_12006 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#107341]
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: PASS -> INCOMPLETE [fdo#108602] / [fdo#108744]
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#107341]: https://bugs.freedesktop.org/show_bug.cgi?id=107341
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (45 -> 42)
--
Additional (1): fi-skl-6770hq
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5464 -> Patchwork_12006
CI_DRM_5464: af90b519a670a3aec89045d9fcca8f2d174adeda @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4782: 96f3a1b876e0dd24706b85fb872f12031a436e84 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12006: 7f8a9a520a95c1a5db71698787756cdeab8f78c6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7f8a9a520a95 drm/i915/selftests: Apply a subtest filter
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12006/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
