[Intel-gfx] [PATCH] drm/i915/audio: Fix audio detection issue on GLK
On Geminilake, sometimes audio card is not getting detected after reboot. This is a spurious issue happening on Geminilake. HW codec and HD audio controller link was going out of sync for which there was a fix in i915 driver but was not getting invoked for GLK. Extending this fix to GLK as well. Tested by Du,Wenkai on GLK board. Bspec: 21829 v2: Instead of checking GEN9_BC, BXT and GLK macros, use IS_GEN9 macro Signed-off-by: Gaurav K Singh Reviewed-by: Jani Nikula --- drivers/gpu/drm/i915/intel_audio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c index 656f6c931341..3ea566f99450 100644 --- a/drivers/gpu/drm/i915/intel_audio.c +++ b/drivers/gpu/drm/i915/intel_audio.c @@ -729,7 +729,7 @@ static void i915_audio_component_codec_wake_override(struct device *kdev, struct drm_i915_private *dev_priv = kdev_to_i915(kdev); u32 tmp; - if (!IS_GEN9_BC(dev_priv) && !IS_BROXTON(dev_priv)) + if (!IS_GEN9(dev_priv)) return; i915_audio_component_get_power(kdev); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> Lets move this to intel-gfx to get more eyes on it.
>
>> -Original Message-
>> From: Srinivas, Vidya
>> Sent: tiistai 17. huhtikuuta 2018 5.47
>> To: Maarten Lankhorst ; intel-gfx-
>> try...@lists.freedesktop.org
>> Cc: Kamath, Sunil ; Saarinen, Jani
>>
>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
>>
>>
>>
>>> -Original Message-
>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>>> Sent: Monday, April 16, 2018 8:00 PM
>>> To: Srinivas, Vidya ; intel-gfx-
>>> try...@lists.freedesktop.org
>>> Cc: Kamath, Sunil ; Saarinen, Jani
>>>
>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
>>> NV12
>>>
>>> Hmm, more thought about src adjustments...
>>>
>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
We skip src trunction/adjustments for
NV12 case and handle the sizes directly.
Without this, pipe fifo underruns are seen on APL/KBL.
v2: For NV12, making the src coordinates multiplier of 4
Credits-to: Maarten Lankhorst
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
drivers/gpu/drm/i915/intel_sprite.c | 15 +++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bc83f10..f64708f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
>>> intel_plane *plane,
bool can_position = false;
int ret;
uint32_t pixel_format = 0;
+ struct drm_plane_state *plane_state = &state->base;
+ struct drm_rect *src = &plane_state->src;
+
+ *src = drm_plane_state_src(plane_state);
if (INTEL_GEN(dev_priv) >= 9) {
/* use scaler when colorkey is not required */ @@ -13001,6
+13005,13 @@ intel_check_primary_plane(struct intel_plane *plane,
if (!state->base.fb)
return 0;
+ if (pixel_format == DRM_FORMAT_NV12) {
+ src->x1 = (((src->x1 >> 16)/4)*4) << 16;
+ src->x2 = (((src->x2 >> 16)/4)*4) << 16;
+ src->y1 = (((src->y1 >> 16)/4)*4) << 16;
+ src->y2 = (((src->y2 >> 16)/4)*4) << 16;
+ }
>>> Lets reject non multiple of 4 coordinates for plane_state's src_x and
>>> src_y, and before adjustment also reject non multiple of 4
>>> src_w/src_h.fter that we can also reject clipping to the right/bottom
>>> edge of the screen, if the pipe_src_w/h is not a multiple of 4. That
>>> way an application trying to go beyond the screen.
>> kms_plane_scaling and some other tests during execution generate lots of
>> non mult of 4 buffer width/height. All these tests will show fail in the IGT
>> BAT.
>> In some cases, even thought the width and height will be multiple of 4
>> before the Adjustment (say our 16x16 buffer), this after adjustment
>> becomes a 15 in intel_check_sprite_plane.
>> This again would cause underrun. If we reject non multiple of 4s in our
>> skl_update_scaler also, then even simple tests with 16x16 like rotation will
>> fail due to it getting adjusted.
Correct. This is why we fix up to a multiple of 4 after adjustments, and
reject user passed coordinates before adjustment.. plane_state->src_x/y/w/h
is the property set by the user, while the plane_state->src rect is set and
fixed up in the kernel.
Rejecting clipping with positive coordinates if pipe_src w/h
is not a multiple of 4 will fix a border case that shouldn't affect most modes,
where the plane wouldn't extend to the crtc borders, which is what userspace
wants there.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 10/11] drm: Add aspect ratio parsing in DRM layer
On Tue, Apr 17, 2018 at 10:45:07AM +0530, Nautiyal, Ankit K wrote:
>
> On 4/6/2018 11:14 PM, Ville Syrjälä wrote:
> > On Fri, Apr 06, 2018 at 10:55:14PM +0530, Nautiyal, Ankit K wrote:
> > > This patch is causing failure of IGT test kms_3d. The kms_3d test
> > > expects the no. of 3d modes to be 13.
> > >
> > > (The test has hard-coded value for expected no. of 3d modes as 13)
> > >
> > > But due to the addition of "matching aspect_ratio" in drm_mode_equal in
> > > this patch, the total no. of
> > >
> > > modes in the connector modelist is increased by 2, resulting in failure
> > > of assertion 'mode_count==13'.
> > If kms_3d isn't setting the aspect ratio cap how is it affected by these
> > changes?
> In drm_mode.c, the drm_mode_connector_list_update() uses drm_mode_equal,
> to remove duplicate modes in connector_modes from the
> connector->probe_modes.
> Earlier, it wasn't matching for aspect-ratio and was discarding two of the
> modes with aspect ratio,
> as duplicates of other modes in the list.
>
> Later, when we are pruning the modes in drm_mode_get_connector, the logic
> there assumes,
> that the modes are in a sorted order so that we just match with the last
> valid mode for uniqueness.
> This isn't the case with the spoofed edid in kms_3d.
> Earlier, I was thinking if we should change the no. of expected modes in
> kms_3d,
> but that's not correct approach.
>
> So finally, The pruning logic needs to be changed, to do away with any
> assumption and check
> all the modes in the list for duplicates. This however will take more time
> to remove duplicates.
Agreed that the best option looks like just fixing the pruning logic.
Since we're talking about very few modes, and in the probe path (where
reading edid takes 20ms easily) the additional cpu overhead really doesn't
matter I think.
-Daniel
> Any other suggestions on this?
>
> Regards
> -Ankit
>
> >
> > > Perhaps this need to be handled in the test.
> > >
> > > -Regards,
> > >
> > > Ankit
> > >
> > >
> > > On 4/6/2018 10:34 PM, Nautiyal, Ankit K wrote:
> > > > From: "Sharma, Shashank"
> > > >
> > > > Current DRM layer functions don't parse aspect ratio information
> > > > while converting a user mode->kernel mode or vice versa. This
> > > > causes modeset to pick mode with wrong aspect ratio, eventually
> > > > causing failures in HDMI compliance test cases, due to wrong VIC.
> > > >
> > > > This patch adds aspect ratio information in DRM's mode conversion
> > > > and mode comparision functions, to make sure kernel picks mode
> > > > with right aspect ratio (as per the VIC).
> > > >
> > > > Background:
> > > > This patch was once reviewed and merged, and later reverted due to
> > > > lack of DRM cap protection. This is a re-spin of this patch, this
> > > > time with DRM cap protection, to avoid aspect ratio information, when
> > > > the client doesn't request for it.
> > > >
> > > > Review link: https://pw-emeril.freedesktop.org/patch/104068/
> > > > Background discussion: https://patchwork.kernel.org/patch/9379057/
> > > >
> > > > Signed-off-by: Shashank Sharma
> > > > Signed-off-by: Lin, Jia
> > > > Signed-off-by: Akashdeep Sharma
> > > > Reviewed-by: Jim Bride (V2)
> > > > Reviewed-by: Jose Abreu (V4)
> > > >
> > > > Cc: Ville Syrjala
> > > > Cc: Jim Bride
> > > > Cc: Jose Abreu
> > > > Cc: Ankit Nautiyal
> > > >
> > > > V3: modified the aspect-ratio check in drm_mode_equal as per new flags
> > > > provided by Ville. https://patchwork.freedesktop.org/patch/188043/
> > > > V4: rebase
> > > > V5: rebase
> > > > V6: As recommended by Ville, avoided matching of aspect-ratio in
> > > > drm_fb_helper, while trying to find a common mode among connectors
> > > > for the target clone mode.
> > > > V7: rebase
> > > > V8: rebase
> > > > V9: rebase
> > > > V10: rebase
> > > > ---
> > > >drivers/gpu/drm/drm_fb_helper.c | 12 ++--
> > > >drivers/gpu/drm/drm_modes.c | 35
> > > > ++-
> > > >2 files changed, 44 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > > b/drivers/gpu/drm/drm_fb_helper.c
> > > > index 0646b10..2ee1eaa 100644
> > > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > > @@ -2183,7 +2183,11 @@ static bool drm_target_cloned(struct
> > > > drm_fb_helper *fb_helper,
> > > > for (j = 0; j < i; j++) {
> > > > if (!enabled[j])
> > > > continue;
> > > > - if (!drm_mode_equal(modes[j], modes[i]))
> > > > + if (!drm_mode_match(modes[j], modes[i],
> > > > + DRM_MODE_MATCH_TIMINGS |
> > > > + DRM_MODE_MATCH_CLOCK |
> > > > + DRM_MODE_MATCH_FLAGS |
> > > > + DRM_MODE_MATCH_3D_FLAGS))
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, April 17, 2018 12:55 PM
> To: Saarinen, Jani ; Srinivas, Vidya
> ; intel-gfx-try...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org
> Cc: Kamath, Sunil
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
>
> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> > Lets move this to intel-gfx to get more eyes on it.
> >
> >> -Original Message-
> >> From: Srinivas, Vidya
> >> Sent: tiistai 17. huhtikuuta 2018 5.47
> >> To: Maarten Lankhorst ; intel-gfx-
> >> try...@lists.freedesktop.org
> >> Cc: Kamath, Sunil ; Saarinen, Jani
> >>
> >> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >> for NV12
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>> Sent: Monday, April 16, 2018 8:00 PM
> >>> To: Srinivas, Vidya ; intel-gfx-
> >>> try...@lists.freedesktop.org
> >>> Cc: Kamath, Sunil ; Saarinen, Jani
> >>>
> >>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>> for
> >>> NV12
> >>>
> >>> Hmm, more thought about src adjustments...
> >>>
> >>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> We skip src trunction/adjustments for
> NV12 case and handle the sizes directly.
> Without this, pipe fifo underruns are seen on APL/KBL.
>
> v2: For NV12, making the src coordinates multiplier of 4
>
> Credits-to: Maarten Lankhorst
> Signed-off-by: Vidya Srinivas
> ---
> drivers/gpu/drm/i915/intel_display.c | 11 +++
> drivers/gpu/drm/i915/intel_sprite.c | 15 +++
> 2 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index bc83f10..f64708f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
> >>> intel_plane *plane,
> bool can_position = false;
> int ret;
> uint32_t pixel_format = 0;
> +struct drm_plane_state *plane_state = &state->base;
> +struct drm_rect *src = &plane_state->src;
> +
> +*src = drm_plane_state_src(plane_state);
>
> if (INTEL_GEN(dev_priv) >= 9) {
> /* use scaler when colorkey is not required */ @@
> -13001,6
> +13005,13 @@ intel_check_primary_plane(struct intel_plane *plane,
> if (!state->base.fb)
> return 0;
>
> +if (pixel_format == DRM_FORMAT_NV12) {
> +src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> +src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> +src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> +src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> +}
> >>> Lets reject non multiple of 4 coordinates for plane_state's src_x
> >>> and src_y, and before adjustment also reject non multiple of 4
> >>> src_w/src_h.fter that we can also reject clipping to the
> >>> right/bottom edge of the screen, if the pipe_src_w/h is not a
> >>> multiple of 4. That way an application trying to go beyond the screen.
> >> kms_plane_scaling and some other tests during execution generate lots
> >> of non mult of 4 buffer width/height. All these tests will show fail
> >> in the IGT BAT.
> >> In some cases, even thought the width and height will be multiple of
> >> 4 before the Adjustment (say our 16x16 buffer), this after adjustment
> >> becomes a 15 in intel_check_sprite_plane.
> >> This again would cause underrun. If we reject non multiple of 4s in
> >> our skl_update_scaler also, then even simple tests with 16x16 like
> >> rotation will fail due to it getting adjusted.
>
> Correct. This is why we fix up to a multiple of 4 after adjustments, and
> reject
> user passed coordinates before adjustment.. plane_state->src_x/y/w/h is
> the property set by the user, while the plane_state->src rect is set and fixed
> up in the kernel.
>
> Rejecting clipping with positive coordinates if pipe_src w/h is not a multiple
> of 4 will fix a border case that shouldn't affect most modes, where the plane
> wouldn't extend to the crtc borders, which is what userspace wants there.
>
Thank you. Oh okay. Sorry. I thought we just reject and not do the fixing (mult
of 4 later).
Sure, I will change the patch to also reject the coordinates before adjustment
(if its not
Mult of 4).
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
>
>> -Original Message-
>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>> Sent: Tuesday, April 17, 2018 12:55 PM
>> To: Saarinen, Jani ; Srinivas, Vidya
>> ; intel-gfx-try...@lists.freedesktop.org; intel-
>> g...@lists.freedesktop.org
>> Cc: Kamath, Sunil
>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
>> NV12
>>
>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
>>> Lets move this to intel-gfx to get more eyes on it.
>>>
-Original Message-
From: Srinivas, Vidya
Sent: tiistai 17. huhtikuuta 2018 5.47
To: Maarten Lankhorst ; intel-gfx-
try...@lists.freedesktop.org
Cc: Kamath, Sunil ; Saarinen, Jani
Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
for NV12
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, April 16, 2018 8:00 PM
> To: Srinivas, Vidya ; intel-gfx-
> try...@lists.freedesktop.org
> Cc: Kamath, Sunil ; Saarinen, Jani
>
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> for
> NV12
>
> Hmm, more thought about src adjustments...
>
> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
>> We skip src trunction/adjustments for
>> NV12 case and handle the sizes directly.
>> Without this, pipe fifo underruns are seen on APL/KBL.
>>
>> v2: For NV12, making the src coordinates multiplier of 4
>>
>> Credits-to: Maarten Lankhorst
>> Signed-off-by: Vidya Srinivas
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 11 +++
>> drivers/gpu/drm/i915/intel_sprite.c | 15 +++
>> 2 files changed, 26 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index bc83f10..f64708f 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
> intel_plane *plane,
>> bool can_position = false;
>> int ret;
>> uint32_t pixel_format = 0;
>> +struct drm_plane_state *plane_state = &state->base;
>> +struct drm_rect *src = &plane_state->src;
>> +
>> +*src = drm_plane_state_src(plane_state);
>>
>> if (INTEL_GEN(dev_priv) >= 9) {
>> /* use scaler when colorkey is not required */ @@
>> -13001,6
>> +13005,13 @@ intel_check_primary_plane(struct intel_plane *plane,
>> if (!state->base.fb)
>> return 0;
>>
>> +if (pixel_format == DRM_FORMAT_NV12) {
>> +src->x1 = (((src->x1 >> 16)/4)*4) << 16;
>> +src->x2 = (((src->x2 >> 16)/4)*4) << 16;
>> +src->y1 = (((src->y1 >> 16)/4)*4) << 16;
>> +src->y2 = (((src->y2 >> 16)/4)*4) << 16;
>> +}
> Lets reject non multiple of 4 coordinates for plane_state's src_x
> and src_y, and before adjustment also reject non multiple of 4
> src_w/src_h.fter that we can also reject clipping to the
> right/bottom edge of the screen, if the pipe_src_w/h is not a
> multiple of 4. That way an application trying to go beyond the screen.
kms_plane_scaling and some other tests during execution generate lots
of non mult of 4 buffer width/height. All these tests will show fail
in the IGT BAT.
In some cases, even thought the width and height will be multiple of
4 before the Adjustment (say our 16x16 buffer), this after adjustment
becomes a 15 in intel_check_sprite_plane.
This again would cause underrun. If we reject non multiple of 4s in
our skl_update_scaler also, then even simple tests with 16x16 like
rotation will fail due to it getting adjusted.
>> Correct. This is why we fix up to a multiple of 4 after adjustments, and
>> reject
>> user passed coordinates before adjustment.. plane_state->src_x/y/w/h is
>> the property set by the user, while the plane_state->src rect is set and
>> fixed
>> up in the kernel.
>>
>> Rejecting clipping with positive coordinates if pipe_src w/h is not a
>> multiple
>> of 4 will fix a border case that shouldn't affect most modes, where the plane
>> wouldn't extend to the crtc borders, which is what userspace wants there.
>>
> Thank you. Oh okay. Sorry. I thought we just reject and not do the fixing
> (mult of 4 later).
> Sure, I will change the patch to also reject the coordinates before
> adjustment (if its not
> Mult of 4).
>
>
This can be done in skl_check_plane_surface, plane_state->src_{x,y,w,h}
contains the user requested values.
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listin
Re: [Intel-gfx] [PATCH] drm/i915/audio: Fix audio detection issue on GLK
On Tue, 17 Apr 2018, Gaurav K Singh wrote: > On Geminilake, sometimes audio card is not getting > detected after reboot. This is a spurious issue happening on > Geminilake. HW codec and HD audio controller link was going > out of sync for which there was a fix in i915 driver but > was not getting invoked for GLK. Extending this fix to GLK as well. > > Tested by Du,Wenkai on GLK board. > > Bspec: 21829 > > v2: Instead of checking GEN9_BC, BXT and GLK macros, use IS_GEN9 macro > > Signed-off-by: Gaurav K Singh > Reviewed-by: Jani Nikula That Reviewed-by is jumping to conclusions I'm afraid. Giving review comments does not mean Reviewed-by. Only explicit Reviewed-by reply does. I can only say that this is the right approach *if* glk is to be covered here, but I have no data to actually say if that's the right thing to do. BR, Jani. > --- > drivers/gpu/drm/i915/intel_audio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_audio.c > b/drivers/gpu/drm/i915/intel_audio.c > index 656f6c931341..3ea566f99450 100644 > --- a/drivers/gpu/drm/i915/intel_audio.c > +++ b/drivers/gpu/drm/i915/intel_audio.c > @@ -729,7 +729,7 @@ static void > i915_audio_component_codec_wake_override(struct device *kdev, > struct drm_i915_private *dev_priv = kdev_to_i915(kdev); > u32 tmp; > > - if (!IS_GEN9_BC(dev_priv) && !IS_BROXTON(dev_priv)) > + if (!IS_GEN9(dev_priv)) > return; > > i915_audio_component_get_power(kdev); -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/audio: Fix audio detection issue on GLK (rev2)
== Series Details == Series: drm/i915/audio: Fix audio detection issue on GLK (rev2) URL : https://patchwork.freedesktop.org/series/41334/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4058 -> Patchwork_8701 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_8701 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8701, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41334/revisions/2/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8701: === IGT changes === Possible regressions igt@gem_exec_suspend@basic-s3: fi-ivb-3520m: PASS -> DMESG-WARN Warnings igt@prime_vgem@basic-fence-flip: fi-cnl-y3: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_8701 that come from known issues: === IGT changes === Possible fixes igt@debugfs_test@read_all_entries: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 == Participating hosts (35 -> 33) == Additional (1): fi-glk-1 Missing(3): fi-ilk-m540 fi-cnl-psr fi-skl-6700hq == Build changes == * Linux: CI_DRM_4058 -> Patchwork_8701 CI_DRM_4058: 241d827c86078c4709c00251d22ea8f7554e3e36 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4432: 8b77704db49167f7ebfd1c470d9c129d3b862cb6 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8701: 55226f577b074d07d717a4894646ead57dfd4cf2 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4432: 93b35926a150e318439d2505901288594b3548f5 @ git://anongit.freedesktop.org/piglit == Linux commits == 55226f577b07 drm/i915/audio: Fix audio detection issue on GLK == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8701/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, April 17, 2018 1:21 PM
> To: Srinivas, Vidya ; Saarinen, Jani
> ; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
>
> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Tuesday, April 17, 2018 12:55 PM
> >> To: Saarinen, Jani ; Srinivas, Vidya
> >> ; intel-gfx-try...@lists.freedesktop.org;
> >> intel- g...@lists.freedesktop.org
> >> Cc: Kamath, Sunil
> >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >> for
> >> NV12
> >>
> >> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> >>> Lets move this to intel-gfx to get more eyes on it.
> >>>
> -Original Message-
> From: Srinivas, Vidya
> Sent: tiistai 17. huhtikuuta 2018 5.47
> To: Maarten Lankhorst ;
> intel-gfx- try...@lists.freedesktop.org
> Cc: Kamath, Sunil ; Saarinen, Jani
>
> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> for NV12
>
>
>
> > -Original Message-
> > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > Sent: Monday, April 16, 2018 8:00 PM
> > To: Srinivas, Vidya ; intel-gfx-
> > try...@lists.freedesktop.org
> > Cc: Kamath, Sunil ; Saarinen, Jani
> >
> > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> > for
> > NV12
> >
> > Hmm, more thought about src adjustments...
> >
> > Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> >> We skip src trunction/adjustments for
> >> NV12 case and handle the sizes directly.
> >> Without this, pipe fifo underruns are seen on APL/KBL.
> >>
> >> v2: For NV12, making the src coordinates multiplier of 4
> >>
> >> Credits-to: Maarten Lankhorst
> >> Signed-off-by: Vidya Srinivas
> >> ---
> >> drivers/gpu/drm/i915/intel_display.c | 11 +++
> >> drivers/gpu/drm/i915/intel_sprite.c | 15 +++
> >> 2 files changed, 26 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index bc83f10..f64708f 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
> > intel_plane *plane,
> >>bool can_position = false;
> >>int ret;
> >>uint32_t pixel_format = 0;
> >> + struct drm_plane_state *plane_state = &state->base;
> >> + struct drm_rect *src = &plane_state->src;
> >> +
> >> + *src = drm_plane_state_src(plane_state);
> >>
> >>if (INTEL_GEN(dev_priv) >= 9) {
> >>/* use scaler when colorkey is not required */ @@ -
> 13001,6
> >> +13005,13 @@ intel_check_primary_plane(struct intel_plane
> *plane,
> >>if (!state->base.fb)
> >>return 0;
> >>
> >> + if (pixel_format == DRM_FORMAT_NV12) {
> >> + src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> >> + src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> >> + src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> >> + src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> >> + }
> > Lets reject non multiple of 4 coordinates for plane_state's src_x
> > and src_y, and before adjustment also reject non multiple of 4
> > src_w/src_h.fter that we can also reject clipping to the
> > right/bottom edge of the screen, if the pipe_src_w/h is not a
> > multiple of 4. That way an application trying to go beyond the screen.
> kms_plane_scaling and some other tests during execution generate
> lots of non mult of 4 buffer width/height. All these tests will
> show fail in the IGT BAT.
> In some cases, even thought the width and height will be multiple
> of
> 4 before the Adjustment (say our 16x16 buffer), this after
> adjustment becomes a 15 in intel_check_sprite_plane.
> This again would cause underrun. If we reject non multiple of 4s in
> our skl_update_scaler also, then even simple tests with 16x16 like
> rotation will fail due to it getting adjusted.
> >> Correct. This is why we fix up to a multiple of 4 after adjustments,
> >> and reject user passed coordinates before adjustment..
> >> plane_state->src_x/y/w/h is the property set by the user, while the
> >> plane_state->src rect is set and fixed up in the kernel.
> >>
> >> Rejecting clipping with positive coordinates if pipe_src w/h is not a
> >> multiple of 4 will fix a border case that shouldn't affect most
> >> modes, where the plane wouldn't extend to the crtc borders, which is
> what userspace want
Re: [Intel-gfx] [Freedreno] [PATCH 01/10] include: Move ascii85 functions from i915 to linux/ascii85.h
On Mon, Apr 16, 2018 at 10:52:59AM -0700, Eric Anholt wrote: > Chris Wilson writes: > > > Quoting Jordan Crouse (2018-04-05 23:06:53) > >> On Thu, Apr 05, 2018 at 04:00:47PM -0600, Jordan Crouse wrote: > >> > The i915 DRM driver very cleverly used ascii85 encoding for their > >> > GPU state file. Move the encode functions to a general header file to > >> > support other drivers that might be interested in the same > >> > functionality. > >> > >> In a previous version of this patch, Chris asked what tree I wanted this > >> applied > >> to, and the answer is: I'm not sure? I'm hoping that Rob will be cool with > >> picking the rest up for msm-next for 4.18 but I'm okay with putting this > >> particular patch wherever it is easiest for the maintainers. > > > > We are a bit late to sneak it into the 4.17 drm base via i915. I don't > > anticipate any problems (for i915) with this patch going in through > > msm-next, so happy to have it land there and percolate back to i915 3 > > months later. > > I'd love to have it in drm-misc-next, so I can build a similar hang dump > interface for vc5. But most importantly, I'd like to have it somewhere > soon. Maarten will likely send the first pull for drm-misc-next at the end of this week. So if you just push it there today, there's no hold-up for msm (or anyone else) really. -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] ✗ Fi.CI.BAT: failure for drm/i915/audio: Fix audio detection issue on GLK (rev2)
On 17/04/18 11:00, Patchwork wrote: > == Series Details == > > Series: drm/i915/audio: Fix audio detection issue on GLK (rev2) > URL : https://patchwork.freedesktop.org/series/41334/ > State : failure > > == Summary == > > = CI Bug Log - changes from CI_DRM_4058 -> Patchwork_8701 = > > == Summary - FAILURE == > > Serious unknown changes coming with Patchwork_8701 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_8701, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://patchwork.freedesktop.org/api/1.0/series/41334/revisions/2/mbox/ > > == Possible new issues == > > Here are the unknown changes that may have been introduced in > Patchwork_8701: > > === IGT changes === > > Possible regressions > > igt@gem_exec_suspend@basic-s3: > fi-ivb-3520m: PASS -> DMESG-WARN https://bugs.freedesktop.org/show_bug.cgi?id=106084 I re-queued the testing to get the shards. > > > Warnings > > igt@prime_vgem@basic-fence-flip: > fi-cnl-y3: SKIP -> PASS > > > == Known issues == > > Here are the changes found in Patchwork_8701 that come from known issues: > > === IGT changes === > > Possible fixes > > igt@debugfs_test@read_all_entries: > fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS > > igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: > fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS > > > fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 > fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 > > > == Participating hosts (35 -> 33) == > > Additional (1): fi-glk-1 > Missing(3): fi-ilk-m540 fi-cnl-psr fi-skl-6700hq > > > == Build changes == > > * Linux: CI_DRM_4058 -> Patchwork_8701 > > CI_DRM_4058: 241d827c86078c4709c00251d22ea8f7554e3e36 @ > git://anongit.freedesktop.org/gfx-ci/linux > IGT_4432: 8b77704db49167f7ebfd1c470d9c129d3b862cb6 @ > git://anongit.freedesktop.org/xorg/app/intel-gpu-tools > Patchwork_8701: 55226f577b074d07d717a4894646ead57dfd4cf2 @ > git://anongit.freedesktop.org/gfx-ci/linux > piglit_4432: 93b35926a150e318439d2505901288594b3548f5 @ > git://anongit.freedesktop.org/piglit > > > == Linux commits == > > 55226f577b07 drm/i915/audio: Fix audio detection issue on GLK > > == Logs == > > For more details see: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8701/issues.html > ___ > 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] [RFC v4 19/25] drm/client: Finish the in-kernel client API
On Mon, Apr 16, 2018 at 05:58:23PM +0200, Noralf Trønnes wrote:
>
> Den 16.04.2018 10.27, skrev Daniel Vetter:
> > On Sat, Apr 14, 2018 at 01:53:12PM +0200, Noralf Trønnes wrote:
> > > The modesetting code is already present, this adds the rest of the API.
> > Mentioning the TODO in the commit message would be good. Helps readers
> > like me who have an attention span measured in seconds :-)
> >
> > Just commenting on the create_buffer leak here
> >
> > > +static struct drm_client_buffer *
> > > +drm_client_buffer_create(struct drm_client_dev *client, u32 width, u32
> > > height, u32 format)
> > > +{
> > > + struct drm_mode_create_dumb dumb_args = { };
> > > + struct drm_prime_handle prime_args = { };
> > > + struct drm_client_buffer *buffer;
> > > + struct dma_buf *dma_buf;
> > > + void *vaddr;
> > > + int ret;
> > > +
> > > + buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
> > > + if (!buffer)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + buffer->client = client;
> > > + buffer->width = width;
> > > + buffer->height = height;
> > > + buffer->format = format;
> > > +
> > > + dumb_args.width = buffer->width;
> > > + dumb_args.height = buffer->height;
> > > + dumb_args.bpp = drm_format_plane_cpp(format, 0) * 8;
> > > + ret = drm_mode_create_dumb(client->dev, &dumb_args, client->file);
> > > + if (ret)
> > > + goto err_free;
> > > +
> > > + buffer->handle = dumb_args.handle;
> > > + buffer->pitch = dumb_args.pitch;
> > > + buffer->size = dumb_args.size;
> > > +
> > > + prime_args.handle = dumb_args.handle;
> > > + ret = drm_prime_handle_to_fd(client->dev, &prime_args, client->file);
> > > + if (ret)
> > > + goto err_delete;
> > > +
> > > + dma_buf = dma_buf_get(prime_args.fd);
> > > + if (IS_ERR(dma_buf)) {
> > > + ret = PTR_ERR(dma_buf);
> > > + goto err_delete;
> > > + }
> > > +
> > > + /*
> > > + * If called from a worker the dmabuf fd isn't closed and the ref
> > > + * doesn't drop to zero on free.
> > > + * If I use __close_fd() it's all fine, but that function is not
> > > exported.
> > > + *
> > > + * How do I get rid of this fd when in a worker/kernel thread?
> > > + * The fd isn't used beyond this function.
> > > + */
> > > +// WARN_ON(__close_fd(current->files, prime_args.fd));
> > Hm, this isn't 100% what I had in mind as the sequence for generic buffer
> > creation. Pseudo-code:
> >
> > ret = drm_mode_create_dumb(client->dev, &dumb_args, client->file);
> > if (ret)
> > goto err_free;
> >
> > gem_bo = drm_gem_object_lookup(client->file, dumb_args.handle);
> >
> > gives you _really_ directly the underlying gem_bo. Of course this doesn't
> > work for non-gem based driver, but reality is that (almost) all of them
> > are. And we will not accept any new drivers which aren't gem based. So
> > ignoring vmwgfx for this drm_client work is imo perfectly fine. We should
> > ofc keep the option in the fb helpers to use non-gem buffers (so that
> > vmwgfx could switch over from their own in-driver fbdev helpers). All we
> > need for that is to keep the fb_probe callback.
> >
> > Was there any other reason than vmwgfx for using prime buffers instead of
> > just directly using gem?
>
> The reason for using a prime buffer is that it gives me easy access to a
> dma_buf which I use to get the virtual address (dma_buf_vmap) and for
> mmap (dma_buf_mmap).
Ah yes, I missed that.
Wrt mmap, not sure we should use the dma-buf mmap or the dumb mmap. I
guess in the end it wont matter much really.
>
> Would this stripped down version of drm_gem_prime_handle_to_fd() work?
>
> struct dma_buf *drm_gem_to_dmabuf(struct drm_gem_object *obj)
> {
> struct dma_buf *dmabuf;
>
> mutex_lock(&obj->dev->object_name_lock);
> /* re-export the original imported object */
> if (obj->import_attach) {
> dmabuf = obj->import_attach->dmabuf;
> get_dma_buf(dmabuf);
> goto out;
> }
>
> if (obj->dma_buf) {
> dmabuf = obj->dma_buf;
> get_dma_buf(dmabuf);
> goto out;
> }
>
> dmabuf = export_and_register_object(obj->dev, obj, 0);
> out:
> mutex_unlock(&obj->dev->object_name_lock);
>
> return dmabuf;
> }
>
> Now I could do this:
>
> ret = drm_mode_create_dumb(dev, &dumb_args, file);
>
> obj = drm_gem_object_lookup(file, dumb_args.handle);
>
> dmabuf = drm_gem_to_dmabuf(obj);
>
> vaddr = dma_buf_vmap(dmabuf);
Nah, if we need the dma-buf anyway, I'd try to go directly from the handle
to the dma-buf. So roughly:
ret = drm_mode_create_dumb(dev, &dumb_args, file);
dma_buf = drm_gem_prime_handle_to_dmabuf(file, dumb_args.handle);
See my reply to the ioctl wrapper patch for details.
-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 v2 6/6] drm/i915: Do not do fb src adjustments for NV12
> -Original Message-
> From: Srinivas, Vidya
> Sent: Tuesday, April 17, 2018 1:32 PM
> To: 'Maarten Lankhorst' ; Saarinen,
> Jani ; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil
> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
>
>
>
> > -Original Message-
> > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > Sent: Tuesday, April 17, 2018 1:21 PM
> > To: Srinivas, Vidya ; Saarinen, Jani
> > ; intel-gfx@lists.freedesktop.org
> > Cc: Kamath, Sunil
> > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> > NV12
> >
> > Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> > >
> > >> -Original Message-
> > >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > >> Sent: Tuesday, April 17, 2018 12:55 PM
> > >> To: Saarinen, Jani ; Srinivas, Vidya
> > >> ; intel-gfx-try...@lists.freedesktop.org;
> > >> intel- g...@lists.freedesktop.org
> > >> Cc: Kamath, Sunil
> > >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> > >> for
> > >> NV12
> > >>
> > >> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> > >>> Lets move this to intel-gfx to get more eyes on it.
> > >>>
> > -Original Message-
> > From: Srinivas, Vidya
> > Sent: tiistai 17. huhtikuuta 2018 5.47
> > To: Maarten Lankhorst ;
> > intel-gfx- try...@lists.freedesktop.org
> > Cc: Kamath, Sunil ; Saarinen, Jani
> >
> > Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> > adjustments for NV12
> >
> >
> >
> > > -Original Message-
> > > From: Maarten Lankhorst
> > > [mailto:maarten.lankho...@linux.intel.com]
> > > Sent: Monday, April 16, 2018 8:00 PM
> > > To: Srinivas, Vidya ; intel-gfx-
> > > try...@lists.freedesktop.org
> > > Cc: Kamath, Sunil ; Saarinen, Jani
> > >
> > > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > adjustments for
> > > NV12
> > >
> > > Hmm, more thought about src adjustments...
> > >
> > > Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> > >> We skip src trunction/adjustments for
> > >> NV12 case and handle the sizes directly.
> > >> Without this, pipe fifo underruns are seen on APL/KBL.
> > >>
> > >> v2: For NV12, making the src coordinates multiplier of 4
> > >>
> > >> Credits-to: Maarten Lankhorst
> > >>
> > >> Signed-off-by: Vidya Srinivas
> > >> ---
> > >> drivers/gpu/drm/i915/intel_display.c | 11 +++
> > >> drivers/gpu/drm/i915/intel_sprite.c | 15 +++
> > >> 2 files changed, 26 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> > >> b/drivers/gpu/drm/i915/intel_display.c
> > >> index bc83f10..f64708f 100644
> > >> --- a/drivers/gpu/drm/i915/intel_display.c
> > >> +++ b/drivers/gpu/drm/i915/intel_display.c
> > >> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
> > > intel_plane *plane,
> > >> bool can_position = false;
> > >> int ret;
> > >> uint32_t pixel_format = 0;
> > >> +struct drm_plane_state *plane_state = &state->base;
> > >> +struct drm_rect *src = &plane_state->src;
> > >> +
> > >> +*src = drm_plane_state_src(plane_state);
> > >>
> > >> if (INTEL_GEN(dev_priv) >= 9) {
> > >> /* use scaler when colorkey is not required */ @@ -
> > 13001,6
> > >> +13005,13 @@ intel_check_primary_plane(struct intel_plane
> > *plane,
> > >> if (!state->base.fb)
> > >> return 0;
> > >>
> > >> +if (pixel_format == DRM_FORMAT_NV12) {
> > >> +src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> > >> +src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> > >> +src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> > >> +src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> > >> +}
> > > Lets reject non multiple of 4 coordinates for plane_state's
> > > src_x and src_y, and before adjustment also reject non multiple
> > > of 4 src_w/src_h.fter that we can also reject clipping to the
> > > right/bottom edge of the screen, if the pipe_src_w/h is not a
> > > multiple of 4. That way an application trying to go beyond the
> screen.
> > kms_plane_scaling and some other tests during execution generate
> > lots of non mult of 4 buffer width/height. All these tests will
> > show fail in the IGT BAT.
> > In some cases, even thought the width and height will be multiple
> > of
> > 4 before the Adjustment (say our 16x16 buffer), this after
> > adjustment becomes a 15 in intel_check_sprite_plane.
> > This again would cause underrun. If we reject non multiple of 4s
> > in our skl_update_scaler also, then even simple tests with 16x16
> > like rotation will fail due to it getting adjusted.
> > >> Correct. This is w
Re: [Intel-gfx] [RFC v4 00/25] drm: Add generic fbdev emulation
On Mon, Apr 16, 2018 at 08:49:23PM +0200, Noralf Trønnes wrote: > > Den 16.04.2018 10.21, skrev Daniel Vetter: > > On Sat, Apr 14, 2018 at 01:52:53PM +0200, Noralf Trønnes wrote: > > > This patchset explores the possibility of having generic fbdev emulation > > > in DRM for drivers that supports dumb buffers which they can export. An > > > API is added to support in-kernel clients in general. > > > > > > In this version I was able to reuse the modesetting code from > > > drm_fb_helper in the client API. This avoids code duplication, carries > > > over lessons learned and the modesetting code is bisectable. The > > > downside is that it takes +10 patches to rip drm_fb_helper in two, so > > > maybe it's not worth it wrt possible breakage and a challenging review. > > So my idea wasn't to rip the fbdev helper in half first (that's indeed a > > lot of work). But start out right away with using every piece of the > > drm_client infrastructure you're adding in the existing fbdev code. > > > > That way there's not a huge patch series which just adds code, with no > > users, but every step of the way and every addition is tested almost right > > away. That makes more gradual merging also easier. The things I have in > > mind here is the generic fb_probe, or the drm_client block/unblock masters > > and all that stuff. > > > > Then, once we've demonstrated all these auxiliary pieces necessary for > > drm_client.c work, we can cut the fb-helper in half and move the modeset > > code into the drm_client library. > > I agree. I wished for a way to cut this patchset in half, but I just > couldn't see how. I was tired of working on this, so I just put it out > hoping that you would provide some clarity. Which you did, thanks :-) Yeah, that's why I'm also ok with things as-is. I think we've reached agreement on the design and big picture now, which really is the important part. How exactly we get there (as long as it's gradual steps in bisectable patches) doesn't matter that much really. > So, I think I'll strip this down to just the buffer part of the client API > and use that in the generic fbdev emulation, and start converting some > drivers. Yes the buffer stuff is definitely the core parts. I think rolling out the master_block/unblock stuff after that would be really neat too, since it would fix a long-standing race in our fbdev emulation. > I'll pick up the rest of the client API when I'm done with moving tinydrm > over to vmalloc buffers and have added support for device unplug. Sounds like a good plan. -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] [RFC v4 21/25] drm/fb-helper: Add drm_fb_helper_fb_open/release()
On Mon, Apr 16, 2018 at 06:10:07PM +0200, Noralf Trønnes wrote:
>
> Den 16.04.2018 10.46, skrev Daniel Vetter:
> > On Sat, Apr 14, 2018 at 01:53:14PM +0200, Noralf Trønnes wrote:
> > > These helpers keep track of fbdev users and drm_driver.last_close will
> > > only restore fbdev when actually in use. Additionally the display is
> > > turned off when the last user is closing. fbcon is a user in this context.
> > >
> > > If struct fb_ops is defined in a library, fb_open() takes a ref on the
> > > library (fb_ops.owner) instead of the driver module. Fix that by ensuring
> > > that the driver module is pinned.
> > >
> > > The functions are not added to the DRM_FB_HELPER_DEFAULT_OPS() macro,
> > > because some of its users do set fb_open/release themselves.
> > >
> > > Signed-off-by: Noralf Trønnes
> > > ---
> > > drivers/gpu/drm/drm_fb_helper.c | 54
> > > -
> > > include/drm/drm_fb_helper.h | 29 ++
> > > 2 files changed, 82 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index 98e5bc92c9f2..b1124c08b1ed 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -177,7 +177,7 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
> > > drm_fb_helper *fb_helper)
> > > if (!drm_fbdev_emulation || !fb_helper)
> > > return -ENODEV;
> > > - if (READ_ONCE(fb_helper->deferred_setup))
> > > + if (READ_ONCE(fb_helper->deferred_setup) ||
> > > !READ_ONCE(fb_helper->open_count))
> > > return 0;
> > > mutex_lock(&fb_helper->lock);
> > > @@ -368,6 +368,7 @@ void drm_fb_helper_prepare(struct drm_device *dev,
> > > struct drm_fb_helper *helper,
> > > INIT_WORK(&helper->dirty_work, drm_fb_helper_dirty_work);
> > > helper->dirty_clip.x1 = helper->dirty_clip.y1 = ~0;
> > > mutex_init(&helper->lock);
> > > + helper->open_count = 1;
> > > helper->funcs = funcs;
> > > helper->dev = dev;
> > > }
> > > @@ -620,6 +621,53 @@ int drm_fb_helper_defio_init(struct drm_fb_helper
> > > *fb_helper)
> > > }
> > > EXPORT_SYMBOL(drm_fb_helper_defio_init);
> > > +/**
> > > + * drm_fb_helper_fb_open - implementation for &fb_ops.fb_open
> > > + * @info: fbdev registered by the helper
> > > + * @user: 1=userspace, 0=fbcon
> > > + *
> > > + * Increase fbdev use count.
> > > + * If &fb_ops is wrapped in a library, pin the driver module.
> > > + */
> > > +int drm_fb_helper_fb_open(struct fb_info *info, int user)
> > > +{
> > > + struct drm_fb_helper *fb_helper = info->par;
> > > + struct drm_device *dev = fb_helper->dev;
> > > +
> > > + if (info->fbops->owner != dev->driver->fops->owner) {
> > > + if (!try_module_get(dev->driver->fops->owner))
> > > + return -ENODEV;
> > > + }
> > > +
> > > + fb_helper->open_count++;
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL(drm_fb_helper_fb_open);
> > > +
> > > +/**
> > > + * drm_fb_helper_fb_release - implementation for &fb_ops.fb_release
> > > + * @info: fbdev registered by the helper
> > > + * @user: 1=userspace, 0=fbcon
> > > + *
> > > + * Decrease fbdev use count and turn off if there are no users left.
> > > + * If &fb_ops is wrapped in a library, unpin the driver module.
> > > + */
> > > +int drm_fb_helper_fb_release(struct fb_info *info, int user)
> > > +{
> > > + struct drm_fb_helper *fb_helper = info->par;
> > > + struct drm_device *dev = fb_helper->dev;
> > > +
> > > + if (!(--fb_helper->open_count))
> > > + drm_fb_helper_dpms(info, DRM_MODE_DPMS_OFF);
> > > +
> > > + if (info->fbops->owner != dev->driver->fops->owner)
> > > + module_put(dev->driver->fops->owner);
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL(drm_fb_helper_fb_release);
> > > +
> > > /**
> > >* drm_fb_helper_sys_read - wrapper around fb_sys_read
> > >* @info: fb_info struct pointer
> > > @@ -1436,6 +1484,10 @@ static int drm_fb_helper_single_fb_probe(struct
> > > drm_fb_helper *fb_helper,
> > > if (ret < 0)
> > > return ret;
> > > + /* Block restore without users if we do track it */
> > > + if (fb_helper->fbdev->fbops->fb_open == drm_fb_helper_fb_open)
> > > + fb_helper->open_count = 0;
> > Since we kzcalloc, isn't this entirely redundant? Looks confusing to me at
> > least.
>
> I have to keep the existing restore behaviour for those that don't use
> drm_fb_helper_fb_open(). I do this by setting fb_helper->open_count = 1
> in drm_fb_helper_prepare(). I have tried to give a describtion in the
> @open_count docs.
Ah I missed that. I think having the fbops->fb_op == drm_fb_helper_fb_open
check in the restore function itself, plus a big comment explaining what
you're doing, would be clearer. So instead of always checking the
open_count, only check it when this helper is in use.
> Ofc I could have changed all drive
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gvt: Deliver guest cursor hotspot info (rev2)
On 16/04/18 14:45, Patchwork wrote: > == Series Details == > > Series: drm/i915/gvt: Deliver guest cursor hotspot info (rev2) > URL : https://patchwork.freedesktop.org/series/41727/ > State : failure > > == Summary == > > = CI Bug Log - changes from CI_DRM_4054_full -> Patchwork_8694_full = > > == Summary - FAILURE == > > Serious unknown changes coming with Patchwork_8694_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_8694_full, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://patchwork.freedesktop.org/api/1.0/series/41727/revisions/2/mbox/ > > == Possible new issues == > > Here are the unknown changes that may have been introduced in > Patchwork_8694_full: > > === IGT changes === > > Possible regressions > > igt@gem_exec_store@pages-vebox: > shard-hsw: PASS -> FAIL Known issue: https://bugs.freedesktop.org/show_bug.cgi?id=17 > > > Warnings > > igt@gem_mocs_settings@mocs-rc6-ctx-dirty-render: > shard-kbl: SKIP -> PASS +1 > > > == Known issues == > > Here are the changes found in Patchwork_8694_full that come from known > issues: > > === IGT changes === > > Issues hit > > igt@kms_cursor_crc@cursor-256x256-rapid-movement: > shard-kbl: PASS -> INCOMPLETE (fdo#103665) > > igt@kms_flip@2x-dpms-vs-vblank-race: > shard-hsw: PASS -> FAIL (fdo#103060) > > igt@kms_flip@plain-flip-fb-recreate: > shard-hsw: PASS -> FAIL (fdo#100368) > > igt@kms_rotation_crc@sprite-rotation-180: > shard-snb: PASS -> FAIL (fdo#103925) > > igt@kms_setmode@basic: > shard-apl: PASS -> FAIL (fdo#99912) > > igt@kms_sysfs_edid_timing: > shard-apl: PASS -> WARN (fdo#100047) > > > Possible fixes > > igt@kms_cursor_legacy@flip-vs-cursor-toggle: > shard-hsw: FAIL (fdo#102670) -> PASS > > igt@kms_flip@wf_vblank-ts-check: > shard-hsw: FAIL (fdo#103928) -> PASS > > > fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 > fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 > fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 > fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 > fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 > fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925 > fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 > fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 > > > == Participating hosts (6 -> 4) == > > Missing(2): shard-glk shard-glkb > > > == Build changes == > > * Linux: CI_DRM_4054 -> Patchwork_8694 > > CI_DRM_4054: a0e39233b88795009de32094efa8a2135f34338f @ > git://anongit.freedesktop.org/gfx-ci/linux > IGT_4430: 8b77704db49167f7ebfd1c470d9c129d3b862cb6 @ > git://anongit.freedesktop.org/xorg/app/intel-gpu-tools > Patchwork_8694: a117fc1be218228651a8f966f1106912287f3135 @ > git://anongit.freedesktop.org/gfx-ci/linux > piglit_4430: 93b35926a150e318439d2505901288594b3548f5 @ > git://anongit.freedesktop.org/piglit > > == Logs == > > For more details see: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8694/shards.html > ___ > 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] [CI i-g-t 1/2] tests/gem_exec_latency: New subtests for checking submission from RT tasks
From: Tvrtko Ursulin
We want to make sure RT tasks which use a lot of CPU times can submit
batch buffers with roughly the same latency (and certainly not worse)
compared to normal tasks.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
tests/gem_exec_latency.c | 176 +++
1 file changed, 176 insertions(+)
diff --git a/tests/gem_exec_latency.c b/tests/gem_exec_latency.c
index 9498c0921e60..420ede0f83a0 100644
--- a/tests/gem_exec_latency.c
+++ b/tests/gem_exec_latency.c
@@ -36,11 +36,15 @@
#include
#include
#include
+#include
#include "drm.h"
#include "igt_sysfs.h"
#include "igt_vgem.h"
+#include "igt_dummyload.h"
+#include "igt_stats.h"
+
#include "i915/gem_ring.h"
#define LOCAL_I915_EXEC_NO_RELOC (1<<11)
@@ -351,6 +355,172 @@ static void latency_from_ring(int fd,
}
}
+static void __rearm_spin_batch(igt_spin_t *spin)
+{
+ const uint32_t mi_arb_chk = 0x5 << 23;
+
+ *spin->batch = mi_arb_chk;
+ *spin->running = 0;
+ __sync_synchronize();
+}
+
+static void
+__submit_spin_batch(int fd, igt_spin_t *spin, unsigned int flags)
+{
+ struct drm_i915_gem_execbuffer2 eb = spin->execbuf;
+
+ eb.flags &= ~(0x3f | I915_EXEC_BSD_MASK);
+ eb.flags |= flags | I915_EXEC_NO_RELOC;
+
+ gem_execbuf(fd, &eb);
+}
+
+struct rt_pkt
+{
+#define RT_OK (0)
+#define RT_FAIL (1)
+#define RT_TIMEOUT (2)
+ int status;
+ struct igt_mean mean;
+ double max;
+};
+
+static void __spin_wait(struct rt_pkt *msg, igt_spin_t *spin, double *t_wait)
+{
+ struct timespec ts = { };
+ uint64_t t_last = 0;
+
+ igt_nsec_elapsed(&ts);
+
+ while (!READ_ONCE(*spin->running)) {
+ uint64_t t = igt_nsec_elapsed(&ts);
+
+ if ((t - t_last) > 5UL * NSEC_PER_SEC) {
+/* Absolute timeout to save time. */
+ msg->status = RT_TIMEOUT;
+ } else if ((t - t_last) > NSEC_PER_SEC / 10) {
+ /* Backoff every 100ms to give it chance to complete. */
+ t_last = t;
+ usleep(1);
+ }
+ }
+
+ *t_wait = igt_nsec_elapsed(&ts) / 1e9;
+
+ msg->status = RT_OK;
+}
+
+/*
+ * Test whether RT thread which hogs the CPU a lot can submit work with
+ * reasonable latency.
+ */
+static void
+rthog_latency_on_ring(int fd, unsigned int ring, const char *name)
+{
+ const char *passname[] = { "warmup", "normal", "rt" };
+ struct rt_pkt res[3];
+ unsigned int i;
+ int link[2];
+ int ret;
+
+ igt_require(gem_can_store_dword(fd, ring));
+
+ igt_assert(pipe(link) == 0);
+
+ memset(res, 0, sizeof(res));
+
+igt_fork(child, 1) {
+ unsigned int pass = 0; /* Three passes: warmup, normal, rt. */
+
+ do {
+ struct rt_pkt msg = { };
+ igt_spin_t *spin;
+
+ igt_mean_init(&msg.mean);
+
+ if (pass == 2) {
+ struct sched_param rt =
+ { .sched_priority = 99 };
+
+ ret = sched_setscheduler(0,
+ SCHED_FIFO |
SCHED_RESET_ON_FORK,
+ &rt);
+ if (ret) {
+ igt_warn("Failed to set scheduling
policy!\n");
+ msg.status = RT_FAIL;
+ write(link[1], &msg, sizeof(msg));
+ exit(1);
+ }
+ }
+
+ spin = __igt_spin_batch_new_poll(fd, 0, ring);
+ if (!spin) {
+ igt_warn("Failed to create spinner! (%s)\n",
+passname[pass]);
+ msg.status = RT_FAIL;
+ write(link[1], &msg, sizeof(msg));
+ exit(1);
+ }
+ igt_spin_busywait_until_running(spin);
+
+ igt_until_timeout(pass > 0 ? 5 : 2) {
+ double t;
+
+ igt_spin_batch_end(spin);
+ gem_sync(fd, spin->handle);
+
+ __rearm_spin_batch(spin);
+ __submit_spin_batch(fd, spin, ring);
+
+ __spin_wait(&msg, spin, &t);
+ if (msg.status != RT_OK) {
+ igt_warn("Wait timeout! (%s)\n",
+passname[pass]);
+ write(link[1], &msg, sizeof(msg));
+
[Intel-gfx] [CI i-g-t 2/2] HACK enable new test
From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- tests/intel-ci/blacklist.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt index d65d8ff35217..bdba838a50ac 100644 --- a/tests/intel-ci/blacklist.txt +++ b/tests/intel-ci/blacklist.txt @@ -18,7 +18,7 @@ igt@gem_exec_alignment@(?!.*single).* igt@gem_exec_fence@(?!.*basic).* igt@gem_exec_flush@(?!.*basic).* igt@gem_exec_gttfill@(?!.*basic).* -igt@gem_exec_latency(@.*)? +igt@gem_exec_latency@(?!.*rthog).* igt@gem_exec_lut_handle(@.*)? igt@gem_exec_nop@(?!.*(basic|signal-all)).* igt@gem_exec_reloc@(?!.*basic).* -- 2.14.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake
On Mon, 16 Apr 2018, "Srivatsa, Anusha" wrote: >>-Original Message- >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >>Sent: Wednesday, April 11, 2018 5:27 AM >>To: Ian W MORRISON >>Cc: Vivi, Rodrigo ; Srivatsa, Anusha >>; Wajdeczko, Michal >>; Greg KH ; >>airl...@linux.ie; joonas.lahti...@linux.intel.com; >>linux-ker...@vger.kernel.org; >>sta...@vger.kernel.org; intel-gfx@lists.freedesktop.org; dri- >>de...@lists.freedesktop.org >>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for >>Geminilake >> >>On Wed, 11 Apr 2018, Ian W MORRISON wrote: >>> >>> NAK on indiscriminate Cc: stable. There are zero guarantees that older kernels will work with whatever firmware you throw at them. >>> >>> I included 'Cc: stable' so the patch would get added to the v4.16 and >>> v4.15 kernels which I have tested with the patch. I found that earlier >>> kernels didn't support the 'linux-firmware' package required to get >>> wifi working on Intel's new Gemini Lake NUC. >> >>You realize that this patch should have nothing to do with wifi? >> >>Rodrigo, Anusha, if you think Cc: stable is appropriate, please indicate the >>specific >>versions of stable it is appropriate for. > > Hi Jani, > > The stable kernel version is 4.12 and beyond. > It is appropriate to add the CC: stable in my opinion Who tested the firmware with v4.12 and later? We only have the CI results against *current* drm-tip. We don't even know about v4.16. I'm not going to ack and take responsibility for the stable backports unless someone actually comes forward with credible Tested-bys. BR, Jani. > > Anusha >>BR, >>Jani. >> >>> PS. How is this a "RESEND"? I haven't seen this before. >>> >>> It is a 'RESEND' for that very reason. I initially sent the patch to >>> the same people as a similar patch >>> (https://patchwork.kernel.org/patch/10143637/) however after realising >>> this omitted required addresses I added them and resent the patch. >>> >>> Best regards, >>> Ian >> >>-- >>Jani Nikula, Intel Open Source Technology Center -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 0/2] GMBUS changes
I am not aware if there is a reason for restricting the Bytes per GMBUS WR/RD to 256 at present. But HW has 9Bits for Total Byte count for a single read or Write cycle. Means we can extend a cycle of RD/WR to 511Bytes. At present nothing much as ROI, as most of the usecases are for less than 256Bytes. On GLK tested for 300Bytes on single normal read, found to be working fine. First patch does it. But I have restricted the extension to Gen9 onwards, as I am not sure about the legacy platforms. And second patch is enabling the burst read for all GMBUS read of more than 511Bytes, on supported platforms. Basically this Burst read is enabled in HW for HDCP2.2 compliance requirement. Instead of enabling the burst read only for HDCP on special API this patch enables it for all GMBUS read of >511Bytes, on capable platforms. Changes in V3: --Avoided the flag for burst read notification [Jani] --Runtime Detection of the need for burst_read [Jani] --Simplified the calculation for bytes_af_burst. Ramalingam C (2): drm/i915/gmbus: Increase the Bytes per Rd/Wr Op drm/i915/gmbus: Enable burst read drivers/gpu/drm/i915/i915_drv.h | 3 +++ drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_i2c.c | 31 --- 3 files changed, 33 insertions(+), 3 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/2] drm/i915/gmbus: Enable burst read
Support for Burst read in HW is added for HDCP2.2 compliance
requirement.
This patch enables the burst read for all the gmbus read of more than
511Bytes, on capable platforms.
v2:
Extra line is removed.
v3:
Macro is added for detecting the BURST_READ Support [Jani]
Runtime detection of the need for burst_read [Jani]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_i2c.c | 22 --
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5373b171bb96..9cddcaa3efb2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2548,6 +2548,9 @@ intel_info(const struct drm_i915_private *dev_priv)
*/
#define HAS_AUX_IRQ(dev_priv) true
#define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
+#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \
+ IS_GEMINILAKE(dev_priv) || \
+ IS_KABYLAKE(dev_priv))
/* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
* rows, which changed the alignment requirements and fence programming.
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index be6114a0e8ab..8b4e6363c7d2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2984,6 +2984,7 @@ enum i915_power_well_id {
#define GMBUS_RATE_400KHZ(2<<8) /* reserved on Pineview */
#define GMBUS_RATE_1MHZ (3<<8) /* reserved on Pineview */
#define GMBUS_HOLD_EXT (1<<7) /* 300ns hold time, rsvd on Pineview */
+#define GMBUS_BYTE_CNT_OVERRIDE (1<<6)
#define GMBUS_PIN_DISABLED 0
#define GMBUS_PIN_SSC1
#define GMBUS_PIN_VGADDC 2
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 4367827d7661..cb260f667cfa 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -373,10 +373,21 @@ gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
unsigned short addr, u8 *buf, unsigned int len,
u32 gmbus1_index)
{
+ unsigned int bytes_af_override = 0, size = len;
+ bool burst_read = len > gmbus_max_xfer_size(dev_priv);
+
+ if (burst_read) {
+ bytes_af_override = (len % 256) + 256;
+ size = bytes_af_override;
+
+ I915_WRITE_FW(GMBUS0, (I915_READ_FW(GMBUS0) |
+ GMBUS_BYTE_CNT_OVERRIDE));
+ }
+
I915_WRITE_FW(GMBUS1,
gmbus1_index |
GMBUS_CYCLE_WAIT |
- (len << GMBUS_BYTE_COUNT_SHIFT) |
+ (size << GMBUS_BYTE_COUNT_SHIFT) |
(addr << GMBUS_SLAVE_ADDR_SHIFT) |
GMBUS_SLAVE_READ | GMBUS_SW_RDY);
while (len) {
@@ -392,6 +403,10 @@ gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
*buf++ = val & 0xff;
val >>= 8;
} while (--len && ++loop < 4);
+
+ if (burst_read && len == (bytes_af_override - 4))
+ I915_WRITE_FW(GMBUS0, (I915_READ_FW(GMBUS0) &
+ ~GMBUS_BYTE_CNT_OVERRIDE));
}
return 0;
@@ -407,7 +422,10 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct
i2c_msg *msg,
int ret;
do {
- len = min(rx_size, gmbus_max_xfer_size(dev_priv));
+ if (HAS_GMBUS_BURST_READ(dev_priv))
+ len = rx_size;
+ else
+ len = min(rx_size, gmbus_max_xfer_size(dev_priv));
ret = gmbus_xfer_read_chunk(dev_priv, msg->addr,
buf, len, gmbus1_index);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
From Gen9 onwards Bspec says HW supports Max Bytes per single RD/WR op is
511Bytes instead of previous 256Bytes used in SW.
This change allows the max bytes per op upto 511Bytes from Gen9 onwards.
v2:
No Change.
v3:
Inline function for max_xfer_size and renaming of the macro.[Jani]
Cc: Jani Nikula
Cc: Chris Wilson
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_i2c.c | 11 +--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 475cac07d3e6..be6114a0e8ab 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3013,6 +3013,7 @@ enum i915_power_well_id {
#define GMBUS_CYCLE_STOP (4<<25)
#define GMBUS_BYTE_COUNT_SHIFT 16
#define GMBUS_BYTE_COUNT_MAX 256U
+#define GEN9_GMBUS_BYTE_COUNT_MAX 511U
#define GMBUS_SLAVE_INDEX_SHIFT 8
#define GMBUS_SLAVE_ADDR_SHIFT 1
#define GMBUS_SLAVE_READ (1<<0)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index e6875509bcd9..4367827d7661 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -361,6 +361,13 @@ gmbus_wait_idle(struct drm_i915_private *dev_priv)
return ret;
}
+static inline
+unsigned int gmbus_max_xfer_size(struct drm_i915_private *dev_priv)
+{
+ return (INTEL_GEN(dev_priv) >= 9) ? GEN9_GMBUS_BYTE_COUNT_MAX :
+ GMBUS_BYTE_COUNT_MAX;
+}
+
static int
gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
unsigned short addr, u8 *buf, unsigned int len,
@@ -400,7 +407,7 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct
i2c_msg *msg,
int ret;
do {
- len = min(rx_size, GMBUS_BYTE_COUNT_MAX);
+ len = min(rx_size, gmbus_max_xfer_size(dev_priv));
ret = gmbus_xfer_read_chunk(dev_priv, msg->addr,
buf, len, gmbus1_index);
@@ -462,7 +469,7 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, struct
i2c_msg *msg,
int ret;
do {
- len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
+ len = min(tx_size, gmbus_max_xfer_size(dev_priv));
ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len,
gmbus1_index);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Pack params to engine->schedule() into a struct
On 12/04/2018 00:00, Chris Wilson wrote:
Today we only want to pass along the priority to engine->schedule(), but
in the future we want to have much more control over the various aspects
of the GPU during a context's execution, for example controlling the
frequency allowed. As we need an ever growing number of parameters for
scheduling, move those into a struct for convenience.
Sounds sensible in principle. Do you already have a tree implementing
ctx freq on top of this so I can get a better idea how exactly it will
be used?
For instance I am at the moment unsure if frequencies are not enough to
be stored in the context which is available via requests at all
scheduling sites.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/scheduler.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 3 +-
drivers/gpu/drm/i915/i915_gem.c | 18 ++---
drivers/gpu/drm/i915/i915_gem_context.c | 8 +--
drivers/gpu/drm/i915/i915_gem_context.h | 13 +---
drivers/gpu/drm/i915/i915_gpu_error.c | 8 +--
drivers/gpu/drm/i915/i915_gpu_error.h | 5 +-
drivers/gpu/drm/i915/i915_request.c | 4 +-
drivers/gpu/drm/i915/i915_request.h | 39 +--
drivers/gpu/drm/i915/i915_scheduler.h | 65 +++
Separating code movement and changes is our usual best practice, so if
not too hard it would be good to do it like that.
Regards,
Tvrtko
drivers/gpu/drm/i915/intel_display.c | 4 +-
drivers/gpu/drm/i915/intel_engine_cs.c| 18 -
drivers/gpu/drm/i915/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c | 20 +++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +-
.../gpu/drm/i915/selftests/intel_hangcheck.c | 4 +-
drivers/gpu/drm/i915/selftests/intel_lrc.c| 8 ++-
17 files changed, 133 insertions(+), 92 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_scheduler.h
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 638abe84857c..f3d21849b0cb 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -1135,7 +1135,7 @@ int intel_vgpu_setup_submission(struct intel_vgpu *vgpu)
return PTR_ERR(s->shadow_ctx);
if (HAS_LOGICAL_RING_PREEMPTION(vgpu->gvt->dev_priv))
- s->shadow_ctx->priority = INT_MAX;
+ s->shadow_ctx->sched.priority = INT_MAX;
bitmap_zero(s->shadow_ctx_desc_updated, I915_NUM_ENGINES);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 649c0f2f3bae..fad860f54386 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -75,6 +75,7 @@
#include "i915_gem_timeline.h"
#include "i915_gpu_error.h"
#include "i915_request.h"
+#include "i915_scheduler.h"
#include "i915_vma.h"
#include "intel_gvt.h"
@@ -3159,7 +3160,7 @@ int i915_gem_object_wait(struct drm_i915_gem_object *obj,
struct intel_rps_client *rps);
int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
unsigned int flags,
- int priority);
+ const struct i915_sched_attr *attr);
#define I915_PRIORITY_DISPLAY I915_PRIORITY_MAX
int __must_check
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 60cf7cfc24ee..61e6be84362f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -563,7 +563,8 @@ i915_gem_object_wait_reservation(struct reservation_object
*resv,
return timeout;
}
-static void __fence_set_priority(struct dma_fence *fence, int prio)
+static void __fence_set_priority(struct dma_fence *fence,
+const struct i915_sched_attr *attr)
{
struct i915_request *rq;
struct intel_engine_cs *engine;
@@ -576,11 +577,12 @@ static void __fence_set_priority(struct dma_fence *fence,
int prio)
rcu_read_lock();
if (engine->schedule)
- engine->schedule(rq, prio);
+ engine->schedule(rq, attr);
rcu_read_unlock();
}
-static void fence_set_priority(struct dma_fence *fence, int prio)
+static void fence_set_priority(struct dma_fence *fence,
+ const struct i915_sched_attr *attr)
{
/* Recurse once into a fence-array */
if (dma_fence_is_array(fence)) {
@@ -588,16 +590,16 @@ static void fence_set_priority(struct dma_fence *fence,
int prio)
int i;
for (i = 0; i < array->num_fences; i++)
- __fence_set_priority(array->fences[i], prio);
+ __fence_set_priority(array->fences[i], attr);
} else {
- __fence_set_priority(fence, prio);
+ __fence_set_priority(fence, attr);
}
}
int
i915_gem_obj
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
On Fri, 2018-04-13 at 17:44 +0530, Vidya Srinivas wrote:
> We skip src trunction/adjustments for
> NV12 case and handle the sizes directly.
> Without this, pipe fifo underruns are seen on APL/KBL.
>
> v2: For NV12, making the src coordinates multiplier of 4
>
> Credits-to: Maarten Lankhorst
> Signed-off-by: Vidya Srinivas
> ---
> drivers/gpu/drm/i915/intel_display.c | 11 +++
> drivers/gpu/drm/i915/intel_sprite.c | 15 +++
> 2 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index bc83f10..f64708f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct intel_plane
> *plane,
> bool can_position = false;
> int ret;
> uint32_t pixel_format = 0;
> + struct drm_plane_state *plane_state = &state->base;
> + struct drm_rect *src = &plane_state->src;
This seems unnecessary. We could use the line below to get the src's.
> +
> + *src = drm_plane_state_src(plane_state);
>
> if (INTEL_GEN(dev_priv) >= 9) {
> /* use scaler when colorkey is not required */
> @@ -13001,6 +13005,13 @@ intel_check_primary_plane(struct intel_plane
> *plane,
> if (!state->base.fb)
> return 0;
>
> + if (pixel_format == DRM_FORMAT_NV12) {
> + src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> + src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> + src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> + src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> + }
> +
> if (INTEL_GEN(dev_priv) >= 9) {
> ret = skl_check_plane_surface(crtc_state, state);
> if (ret)
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 8b7947d..c1dd85e 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1035,11 +1035,20 @@ intel_check_sprite_plane(struct intel_plane
> *plane,
> return vscale;
> }
>
> + if (fb->format->format == DRM_FORMAT_NV12) {
> + if (src->x2 >> 16 == 16)
> + src->x2 = 16 << 16;
> + if (src->y2 >> 16 == 16)
> + src->y2 = 16 << 16;
> + goto nv12_min_no_clip;
> + }
> +
> /* Make the source viewport size an exact multiple
> of the scaling factors. */
> drm_rect_adjust_size(src,
> drm_rect_width(dst) * hscale -
> drm_rect_width(src),
> drm_rect_height(dst) * vscale -
> drm_rect_height(src));
>
> +nv12_min_no_clip:
> drm_rect_rotate_inv(src, fb->width << 16, fb->height
> << 16,
> state->base.rotation);
>
> @@ -1105,6 +1114,12 @@ intel_check_sprite_plane(struct intel_plane
> *plane,
> src->x2 = (src_x + src_w) << 16;
> src->y1 = src_y << 16;
> src->y2 = (src_y + src_h) << 16;
> + if (fb->format->format == DRM_FORMAT_NV12) {
> + src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> + src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> + src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> + src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> + }
> }
>
> dst->x1 = crtc_x;
--
Mika Kahola - Intel OTC
___
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/audio: Fix audio detection issue on GLK (rev2)
== Series Details == Series: drm/i915/audio: Fix audio detection issue on GLK (rev2) URL : https://patchwork.freedesktop.org/series/41334/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4058 -> Patchwork_8702 = == Summary - WARNING == Minor unknown changes coming with Patchwork_8702 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8702, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41334/revisions/2/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8702: === IGT changes === Warnings igt@prime_vgem@basic-fence-flip: fi-cnl-y3: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_8702 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-ivb-3520m: PASS -> DMESG-WARN (fdo#106084) igt@vgem_basic@dmabuf-fence-before: fi-glk-1: NOTRUN -> INCOMPLETE (k.org#198133, fdo#103359) Possible fixes igt@debugfs_test@read_all_entries: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: FAIL (fdo#102575) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-ivb-3520m: DMESG-WARN (fdo#106084) -> PASS fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (35 -> 33) == Additional (1): fi-glk-1 Missing(3): fi-ilk-m540 fi-cnl-psr fi-skl-6700hq == Build changes == * Linux: CI_DRM_4058 -> Patchwork_8702 CI_DRM_4058: 241d827c86078c4709c00251d22ea8f7554e3e36 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4432: 8b77704db49167f7ebfd1c470d9c129d3b862cb6 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8702: 6dad30273262e306bac397d83d45f603da5607f0 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4432: 93b35926a150e318439d2505901288594b3548f5 @ git://anongit.freedesktop.org/piglit == Linux commits == 6dad30273262 drm/i915/audio: Fix audio detection issue on GLK == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8702/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
> -Original Message-
> From: Kahola, Mika
> Sent: Tuesday, April 17, 2018 2:49 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src
> adjustments for NV12
>
> On Fri, 2018-04-13 at 17:44 +0530, Vidya Srinivas wrote:
> > We skip src trunction/adjustments for
> > NV12 case and handle the sizes directly.
> > Without this, pipe fifo underruns are seen on APL/KBL.
> >
> > v2: For NV12, making the src coordinates multiplier of 4
> >
> > Credits-to: Maarten Lankhorst
> > Signed-off-by: Vidya Srinivas
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 11 +++
> > drivers/gpu/drm/i915/intel_sprite.c | 15 +++
> > 2 files changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index bc83f10..f64708f 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
> intel_plane
> > *plane,
> > bool can_position = false;
> > int ret;
> > uint32_t pixel_format = 0;
> > + struct drm_plane_state *plane_state = &state->base;
> > + struct drm_rect *src = &plane_state->src;
> This seems unnecessary. We could use the line below to get the src's.
Sure thank you, am moving all the handling code to skl_check_nv12_aux_surface
as suggested
By Maarten. So this wont be necessary.
Regards
Vidya
>
> > +
> > + *src = drm_plane_state_src(plane_state);
> >
> > if (INTEL_GEN(dev_priv) >= 9) {
> > /* use scaler when colorkey is not required */ @@ -13001,6
> > +13005,13 @@ intel_check_primary_plane(struct intel_plane *plane,
> > if (!state->base.fb)
> > return 0;
> >
> > + if (pixel_format == DRM_FORMAT_NV12) {
> > + src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> > + src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> > + src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> > + src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> > + }
> > +
> > if (INTEL_GEN(dev_priv) >= 9) {
> > ret = skl_check_plane_surface(crtc_state, state);
> > if (ret)
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 8b7947d..c1dd85e 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1035,11 +1035,20 @@ intel_check_sprite_plane(struct intel_plane
> > *plane,
> > return vscale;
> > }
> >
> > + if (fb->format->format == DRM_FORMAT_NV12) {
> > + if (src->x2 >> 16 == 16)
> > + src->x2 = 16 << 16;
> > + if (src->y2 >> 16 == 16)
> > + src->y2 = 16 << 16;
> > + goto nv12_min_no_clip;
> > + }
> > +
> > /* Make the source viewport size an exact multiple of the
> scaling
> > factors. */
> > drm_rect_adjust_size(src,
> > drm_rect_width(dst) * hscale -
> drm_rect_width(src),
> > drm_rect_height(dst) * vscale -
> drm_rect_height(src));
> >
> > +nv12_min_no_clip:
> > drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
> > state->base.rotation);
> >
> > @@ -1105,6 +1114,12 @@ intel_check_sprite_plane(struct intel_plane
> > *plane,
> > src->x2 = (src_x + src_w) << 16;
> > src->y1 = src_y << 16;
> > src->y2 = (src_y + src_h) << 16;
> > + if (fb->format->format == DRM_FORMAT_NV12) {
> > + src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> > + src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> > + src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> > + src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> > + }
> > }
> >
> > dst->x1 = crtc_x;
> --
> Mika Kahola - Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1 2/2] i915: content-type property for HDMI connector
Hi Sean,
Thank you for comments!
Could you please clarify a bit more here, as I've just
started recently working on drm side, so I took an
aspect ratio property as an example.
> @@ -491,6 +491,8 @@ static void intel_hdmi_set_avi_infoframe(struct
> drm_encoder *encoder,
>
> intel_hdmi->rgb_quant_range_selectable,
> is_hdmi2_sink);
>
> + frame.avi.content_type = connector->state->content_type;
> +
> /* TODO: handle pixel repetition for YCBCR420 outputs */
> intel_write_infoframe(encoder, crtc_state, &frame); } @@ -2065,7
> +2067,9 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct
> drm_connector *c
> intel_attach_force_audio_property(connector);
> intel_attach_broadcast_rgb_property(connector);
> intel_attach_aspect_ratio_property(connector);
> + intel_attach_content_type_property(connector);
> connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> + connector->state->content_type = HDMI_CONTENT_TYPE_GRAPHICS;
>This is redudant, the attach function already sets this.
As you can see aspect ratio is set exactly same way,
which is also an HDMI avi info frame property.
Also there are actually two different enums: HDMI_CONTENT_TYPE_*
and DRM_MODE_CONTENT_TYPE_* i.e:
there are one in drm_connector.c:
static const struct drm_prop_enum_list drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_NONE, "Automatic" },
{ DRM_MODE_PICTURE_ASPECT_4_3, "4:3" },
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
};
so I added
static const struct drm_prop_enum_list drm_content_type_enum_list[] = {
{ DRM_MODE_CONTENT_TYPE_GRAPHICS, "GRAPHICS" },
{ DRM_MODE_CONTENT_TYPE_PHOTO, "PHOTO" },
{ DRM_MODE_CONTENT_TYPE_CINEMA, "CINEMA" },
{ DRM_MODE_CONTENT_TYPE_GAME, "GAME" },
};
and the one in linux/hdmi.h:
enum hdmi_picture_aspect {
HDMI_PICTURE_ASPECT_NONE,
HDMI_PICTURE_ASPECT_4_3,
HDMI_PICTURE_ASPECT_16_9,
HDMI_PICTURE_ASPECT_64_27,
HDMI_PICTURE_ASPECT_256_135,
HDMI_PICTURE_ASPECT_RESERVED,
};
enum hdmi_content_type {
HDMI_CONTENT_TYPE_GRAPHICS,
HDMI_CONTENT_TYPE_PHOTO,
HDMI_CONTENT_TYPE_CINEMA,
HDMI_CONTENT_TYPE_GAME,
};
For some reason the latter enums are used in drm_connector_state, but not
the drm_content_type_enum_list(those are actually defined values which simply
match):
From drm_connector.c:
/**
* @picture_aspect_ratio: Connector property to control the
* HDMI infoframe aspect ratio setting.
*
* The %DRM_MODE_PICTURE_ASPECT_\* values much match the
* values for &enum hdmi_picture_aspect
*/
enum hdmi_picture_aspect picture_aspect_ratio;
/**
* @content_type: Connector property to control the
* HDMI infoframe content type setting.
*
* The %DRM_MODE_CONTENT_TYPE_\* values much match the
* values for &enum hdmi_content_type
*/
enum hdmi_content_type content_type;
That's why I did it exactly as it is done with aspect ratio. Just want to
clarify,
as I was assuming this was done for reason.
> }
>
> /*
> diff --git a/drivers/gpu/drm/i915/intel_modes.c
> b/drivers/gpu/drm/i915/intel_modes.c
> index b39846613e3c..232811ab71a3 100644
> --- a/drivers/gpu/drm/i915/intel_modes.c
> +++ b/drivers/gpu/drm/i915/intel_modes.c
> @@ -133,3 +133,13 @@ intel_attach_aspect_ratio_property(struct drm_connector
> *connector)
> connector->dev->mode_config.aspect_ratio_property,
> DRM_MODE_PICTURE_ASPECT_NONE);
> }
> +
> +void
> +intel_attach_content_type_property(struct drm_connector *connector) {
> + if (!drm_mode_create_content_type_property(connector->dev))
> + drm_object_attach_property(&connector->base,
> + connector->dev->mode_config.content_type_property,
> + DRM_MODE_CONTENT_TYPE_GRAPHICS);
> +}
>I think the "in" thing to do is to add this helper to the core, since this is
>a core property.
Could you please explain a bit more, what do you mean by core here?
I just thought it is one of HDMI infoframe properties, as stated in spec:
https://www.hdmi.org/manufacturer/hdmi_1_4/content_type.aspx
Best Regards,
Lisovskiy Stanislav
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
>
>> -Original Message-
>> From: Srinivas, Vidya
>> Sent: Tuesday, April 17, 2018 1:32 PM
>> To: 'Maarten Lankhorst' ; Saarinen,
>> Jani ; intel-gfx@lists.freedesktop.org
>> Cc: Kamath, Sunil
>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
>> NV12
>>
>>
>>
>>> -Original Message-
>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>>> Sent: Tuesday, April 17, 2018 1:21 PM
>>> To: Srinivas, Vidya ; Saarinen, Jani
>>> ; intel-gfx@lists.freedesktop.org
>>> Cc: Kamath, Sunil
>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
>>> NV12
>>>
>>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, April 17, 2018 12:55 PM
> To: Saarinen, Jani ; Srinivas, Vidya
> ; intel-gfx-try...@lists.freedesktop.org;
> intel- g...@lists.freedesktop.org
> Cc: Kamath, Sunil
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> for
> NV12
>
> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
>> Lets move this to intel-gfx to get more eyes on it.
>>
>>> -Original Message-
>>> From: Srinivas, Vidya
>>> Sent: tiistai 17. huhtikuuta 2018 5.47
>>> To: Maarten Lankhorst ;
>>> intel-gfx- try...@lists.freedesktop.org
>>> Cc: Kamath, Sunil ; Saarinen, Jani
>>>
>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
>>> adjustments for NV12
>>>
>>>
>>>
-Original Message-
From: Maarten Lankhorst
[mailto:maarten.lankho...@linux.intel.com]
Sent: Monday, April 16, 2018 8:00 PM
To: Srinivas, Vidya ; intel-gfx-
try...@lists.freedesktop.org
Cc: Kamath, Sunil ; Saarinen, Jani
Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
adjustments for
NV12
Hmm, more thought about src adjustments...
Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> We skip src trunction/adjustments for
> NV12 case and handle the sizes directly.
> Without this, pipe fifo underruns are seen on APL/KBL.
>
> v2: For NV12, making the src coordinates multiplier of 4
>
> Credits-to: Maarten Lankhorst
>
> Signed-off-by: Vidya Srinivas
> ---
> drivers/gpu/drm/i915/intel_display.c | 11 +++
> drivers/gpu/drm/i915/intel_sprite.c | 15 +++
> 2 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index bc83f10..f64708f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
intel_plane *plane,
> bool can_position = false;
> int ret;
> uint32_t pixel_format = 0;
> + struct drm_plane_state *plane_state = &state->base;
> + struct drm_rect *src = &plane_state->src;
> +
> + *src = drm_plane_state_src(plane_state);
>
> if (INTEL_GEN(dev_priv) >= 9) {
> /* use scaler when colorkey is not required */ @@ -
>>> 13001,6
> +13005,13 @@ intel_check_primary_plane(struct intel_plane
>>> *plane,
> if (!state->base.fb)
> return 0;
>
> + if (pixel_format == DRM_FORMAT_NV12) {
> + src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> + src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> + src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> + src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> + }
Lets reject non multiple of 4 coordinates for plane_state's
src_x and src_y, and before adjustment also reject non multiple
of 4 src_w/src_h.fter that we can also reject clipping to the
right/bottom edge of the screen, if the pipe_src_w/h is not a
multiple of 4. That way an application trying to go beyond the
>> screen.
>>> kms_plane_scaling and some other tests during execution generate
>>> lots of non mult of 4 buffer width/height. All these tests will
>>> show fail in the IGT BAT.
>>> In some cases, even thought the width and height will be multiple
>>> of
>>> 4 before the Adjustment (say our 16x16 buffer), this after
>>> adjustment becomes a 15 in intel_check_sprite_plane.
>>> This again would cause underrun. If we reject non multiple of 4s
>>> in our skl_update_scaler also, then even simple tests with 16x16
>>> like rotation will fail due to it getting adjusted.
> Correct. This is why we fix up to a multiple of 4 a
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, April 17, 2018 3:04 PM
> To: Srinivas, Vidya ; Saarinen, Jani
> ; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
>
> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Srinivas, Vidya
> >> Sent: Tuesday, April 17, 2018 1:32 PM
> >> To: 'Maarten Lankhorst' ;
> >> Saarinen, Jani ;
> >> intel-gfx@lists.freedesktop.org
> >> Cc: Kamath, Sunil
> >> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >> for
> >> NV12
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>> Sent: Tuesday, April 17, 2018 1:21 PM
> >>> To: Srinivas, Vidya ; Saarinen, Jani
> >>> ; intel-gfx@lists.freedesktop.org
> >>> Cc: Kamath, Sunil
> >>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>> for
> >>> NV12
> >>>
> >>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> > -Original Message-
> > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > Sent: Tuesday, April 17, 2018 12:55 PM
> > To: Saarinen, Jani ; Srinivas, Vidya
> > ;
> > intel-gfx-try...@lists.freedesktop.org;
> > intel- g...@lists.freedesktop.org
> > Cc: Kamath, Sunil
> > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> > for
> > NV12
> >
> > Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> >> Lets move this to intel-gfx to get more eyes on it.
> >>
> >>> -Original Message-
> >>> From: Srinivas, Vidya
> >>> Sent: tiistai 17. huhtikuuta 2018 5.47
> >>> To: Maarten Lankhorst ;
> >>> intel-gfx- try...@lists.freedesktop.org
> >>> Cc: Kamath, Sunil ; Saarinen, Jani
> >>>
> >>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>> adjustments for NV12
> >>>
> >>>
> >>>
> -Original Message-
> From: Maarten Lankhorst
> [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, April 16, 2018 8:00 PM
> To: Srinivas, Vidya ; intel-gfx-
> try...@lists.freedesktop.org
> Cc: Kamath, Sunil ; Saarinen, Jani
>
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> adjustments for
> NV12
>
> Hmm, more thought about src adjustments...
>
> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> > We skip src trunction/adjustments for
> > NV12 case and handle the sizes directly.
> > Without this, pipe fifo underruns are seen on APL/KBL.
> >
> > v2: For NV12, making the src coordinates multiplier of 4
> >
> > Credits-to: Maarten Lankhorst
> >
> > Signed-off-by: Vidya Srinivas
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 11 +++
> > drivers/gpu/drm/i915/intel_sprite.c | 15 +++
> > 2 files changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index bc83f10..f64708f 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
> intel_plane *plane,
> > bool can_position = false;
> > int ret;
> > uint32_t pixel_format = 0;
> > + struct drm_plane_state *plane_state = &state->base;
> > + struct drm_rect *src = &plane_state->src;
> > +
> > + *src = drm_plane_state_src(plane_state);
> >
> > if (INTEL_GEN(dev_priv) >= 9) {
> > /* use scaler when colorkey is not required */ @@ -
> >>> 13001,6
> > +13005,13 @@ intel_check_primary_plane(struct intel_plane
> >>> *plane,
> > if (!state->base.fb)
> > return 0;
> >
> > + if (pixel_format == DRM_FORMAT_NV12) {
> > + src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> > + src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> > + src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> > + src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> > + }
> Lets reject non multiple of 4 coordinates for plane_state's
> src_x and src_y, and before adjustment also reject non multiple
> of 4 src_w/src_h.fter that we can also reject clipping to the
> right/bottom edge of the screen, if the pipe_src_w/h is not a
> multiple of 4. That way an application trying to go beyond the
> >> screen.
> >>> kms_plane_scaling and some other tests during execution generate
> >>> lots of non mult of 4 buffer widt
Re: [Intel-gfx] [PATCH v2] drm/i915: Pack params to engine->schedule() into a struct
Quoting Tvrtko Ursulin (2018-04-17 10:12:05) > > On 12/04/2018 00:00, Chris Wilson wrote: > > Today we only want to pass along the priority to engine->schedule(), but > > in the future we want to have much more control over the various aspects > > of the GPU during a context's execution, for example controlling the > > frequency allowed. As we need an ever growing number of parameters for > > scheduling, move those into a struct for convenience. > > Sounds sensible in principle. Do you already have a tree implementing > ctx freq on top of this so I can get a better idea how exactly it will > be used? It's because I want to pass in frequency adjustments from the caller and percolate those through the dependencies, rather than pull them from the context at that later timer. It also gets around the thorny issue of what to do when the context is changed at runtime. What I'm playing around with is https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=prescheduler&id=e734f100cd74b340ff9675811268a30cbe9a7959 -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
Op 17-04-18 om 11:42 schreef Srinivas, Vidya:
>
>> -Original Message-
>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>> Sent: Tuesday, April 17, 2018 3:04 PM
>> To: Srinivas, Vidya ; Saarinen, Jani
>> ; intel-gfx@lists.freedesktop.org
>> Cc: Kamath, Sunil
>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
>> NV12
>>
>> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
-Original Message-
From: Srinivas, Vidya
Sent: Tuesday, April 17, 2018 1:32 PM
To: 'Maarten Lankhorst' ;
Saarinen, Jani ;
intel-gfx@lists.freedesktop.org
Cc: Kamath, Sunil
Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
for
NV12
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, April 17, 2018 1:21 PM
> To: Srinivas, Vidya ; Saarinen, Jani
> ; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> for
> NV12
>
> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
>>> -Original Message-
>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>>> Sent: Tuesday, April 17, 2018 12:55 PM
>>> To: Saarinen, Jani ; Srinivas, Vidya
>>> ;
>>> intel-gfx-try...@lists.freedesktop.org;
>>> intel- g...@lists.freedesktop.org
>>> Cc: Kamath, Sunil
>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
>>> for
>>> NV12
>>>
>>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
Lets move this to intel-gfx to get more eyes on it.
> -Original Message-
> From: Srinivas, Vidya
> Sent: tiistai 17. huhtikuuta 2018 5.47
> To: Maarten Lankhorst ;
> intel-gfx- try...@lists.freedesktop.org
> Cc: Kamath, Sunil ; Saarinen, Jani
>
> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> adjustments for NV12
>
>
>
>> -Original Message-
>> From: Maarten Lankhorst
>> [mailto:maarten.lankho...@linux.intel.com]
>> Sent: Monday, April 16, 2018 8:00 PM
>> To: Srinivas, Vidya ; intel-gfx-
>> try...@lists.freedesktop.org
>> Cc: Kamath, Sunil ; Saarinen, Jani
>>
>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
>> adjustments for
>> NV12
>>
>> Hmm, more thought about src adjustments...
>>
>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
>>> We skip src trunction/adjustments for
>>> NV12 case and handle the sizes directly.
>>> Without this, pipe fifo underruns are seen on APL/KBL.
>>>
>>> v2: For NV12, making the src coordinates multiplier of 4
>>>
>>> Credits-to: Maarten Lankhorst
>>>
>>> Signed-off-by: Vidya Srinivas
>>> ---
>>> drivers/gpu/drm/i915/intel_display.c | 11 +++
>>> drivers/gpu/drm/i915/intel_sprite.c | 15 +++
>>> 2 files changed, 26 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>> b/drivers/gpu/drm/i915/intel_display.c
>>> index bc83f10..f64708f 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
>> intel_plane *plane,
>>> bool can_position = false;
>>> int ret;
>>> uint32_t pixel_format = 0;
>>> + struct drm_plane_state *plane_state = &state->base;
>>> + struct drm_rect *src = &plane_state->src;
>>> +
>>> + *src = drm_plane_state_src(plane_state);
>>>
>>> if (INTEL_GEN(dev_priv) >= 9) {
>>> /* use scaler when colorkey is not required */ @@ -
> 13001,6
>>> +13005,13 @@ intel_check_primary_plane(struct intel_plane
> *plane,
>>> if (!state->base.fb)
>>> return 0;
>>>
>>> + if (pixel_format == DRM_FORMAT_NV12) {
>>> + src->x1 = (((src->x1 >> 16)/4)*4) << 16;
>>> + src->x2 = (((src->x2 >> 16)/4)*4) << 16;
>>> + src->y1 = (((src->y1 >> 16)/4)*4) << 16;
>>> + src->y2 = (((src->y2 >> 16)/4)*4) << 16;
>>> + }
>> Lets reject non multiple of 4 coordinates for plane_state's
>> src_x and src_y, and before adjustment also reject non multiple
>> of 4 src_w/src_h.fter that we can also reject clipping to the
>> right/bottom edge of the screen, if the pipe_src_w/h is not a
>> multiple of 4. That way an application trying to go beyond the
screen.
> kms_plane_scaling and some other tests during execution g
[Intel-gfx] [PATCH] drm/i915: Remove skl dc6 enable/disable functions
One is outright unused, other can be made static.
Drive-by cleanup while accidentally reading dc code.
Cc: Imre Deak
Acked-by: Imre Deak
Cc: Rodrigo Vivi
Cc. Dhinakaran Pandiyan
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_drv.h| 2 --
drivers/gpu/drm/i915/intel_runtime_pm.c | 14 +-
2 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5bd2263407b2..8b20824e806e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1580,8 +1580,6 @@ void bxt_enable_dc9(struct drm_i915_private *dev_priv);
void bxt_disable_dc9(struct drm_i915_private *dev_priv);
void gen9_enable_dc5(struct drm_i915_private *dev_priv);
unsigned int skl_cdclk_get_vco(unsigned int freq);
-void skl_enable_dc6(struct drm_i915_private *dev_priv);
-void skl_disable_dc6(struct drm_i915_private *dev_priv);
void intel_dp_get_m_n(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
void intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set m_n);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 92199f2f3401..1fb8b6080dfe 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -635,7 +635,7 @@ static void assert_can_enable_dc6(struct drm_i915_private
*dev_priv)
assert_csr_loaded(dev_priv);
}
-void skl_enable_dc6(struct drm_i915_private *dev_priv)
+static void skl_enable_dc6(struct drm_i915_private *dev_priv)
{
assert_can_enable_dc6(dev_priv);
@@ -645,18 +645,6 @@ void skl_enable_dc6(struct drm_i915_private *dev_priv)
}
-void skl_disable_dc6(struct drm_i915_private *dev_priv)
-{
- DRM_DEBUG_KMS("Disabling DC6\n");
-
- /* Wa Display #1183: skl,kbl,cfl */
- if (IS_GEN9_BC(dev_priv))
- I915_WRITE(GEN8_CHICKEN_DCPR_1, I915_READ(GEN8_CHICKEN_DCPR_1) |
- SKL_SELECT_ALTERNATE_DC_EXIT);
-
- gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
-}
-
static void hsw_power_well_sync_hw(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/audio: Fix audio detection issue on GLK (rev2)
== Series Details == Series: drm/i915/audio: Fix audio detection issue on GLK (rev2) URL : https://patchwork.freedesktop.org/series/41334/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4058_full -> Patchwork_8702_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_8702_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8702_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41334/revisions/2/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8702_full: === IGT changes === Possible regressions igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible: shard-apl: PASS -> FAIL Warnings igt@gem_mocs_settings@mocs-rc6-ctx-render: shard-kbl: SKIP -> PASS igt@kms_cursor_legacy@flip-vs-cursor-crc-legacy: shard-snb: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_8702_full that come from known issues: === IGT changes === Issues hit igt@gem_exec_store@cachelines-bsd: shard-hsw: PASS -> FAIL (fdo#17) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#105189) -> PASS igt@kms_flip@blocking-wf_vblank: shard-hsw: FAIL (fdo#103928) -> PASS fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (6 -> 4) == Missing(2): shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4058 -> Patchwork_8702 CI_DRM_4058: 241d827c86078c4709c00251d22ea8f7554e3e36 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4432: 8b77704db49167f7ebfd1c470d9c129d3b862cb6 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8702: 6dad30273262e306bac397d83d45f603da5607f0 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4432: 93b35926a150e318439d2505901288594b3548f5 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8702/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI i-g-t 1/2] tests/gem_exec_latency: New subtests for checking submission from RT tasks
Quoting Tvrtko Ursulin (2018-04-17 09:41:11)
> From: Tvrtko Ursulin
>
> We want to make sure RT tasks which use a lot of CPU times can submit
> batch buffers with roughly the same latency (and certainly not worse)
> compared to normal tasks.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> ---
> tests/gem_exec_latency.c | 176
> +++
> 1 file changed, 176 insertions(+)
>
> diff --git a/tests/gem_exec_latency.c b/tests/gem_exec_latency.c
> index 9498c0921e60..420ede0f83a0 100644
> --- a/tests/gem_exec_latency.c
> +++ b/tests/gem_exec_latency.c
> @@ -36,11 +36,15 @@
> #include
> #include
> #include
> +#include
>
> #include "drm.h"
>
> #include "igt_sysfs.h"
> #include "igt_vgem.h"
> +#include "igt_dummyload.h"
> +#include "igt_stats.h"
> +
> #include "i915/gem_ring.h"
>
> #define LOCAL_I915_EXEC_NO_RELOC (1<<11)
> @@ -351,6 +355,172 @@ static void latency_from_ring(int fd,
> }
> }
>
> +static void __rearm_spin_batch(igt_spin_t *spin)
> +{
> + const uint32_t mi_arb_chk = 0x5 << 23;
> +
> + *spin->batch = mi_arb_chk;
> + *spin->running = 0;
> + __sync_synchronize();
> +}
> +
> +static void
> +__submit_spin_batch(int fd, igt_spin_t *spin, unsigned int flags)
> +{
> + struct drm_i915_gem_execbuffer2 eb = spin->execbuf;
> +
> + eb.flags &= ~(0x3f | I915_EXEC_BSD_MASK);
> + eb.flags |= flags | I915_EXEC_NO_RELOC;
> +
> + gem_execbuf(fd, &eb);
> +}
> +
> +struct rt_pkt
> +{
> +#define RT_OK (0)
> +#define RT_FAIL (1)
> +#define RT_TIMEOUT (2)
> + int status;
> + struct igt_mean mean;
> + double max;
> +};
> +
> +static void __spin_wait(struct rt_pkt *msg, igt_spin_t *spin, double *t_wait)
> +{
> + struct timespec ts = { };
> + uint64_t t_last = 0;
> +
> + igt_nsec_elapsed(&ts);
> +
> + while (!READ_ONCE(*spin->running)) {
> + uint64_t t = igt_nsec_elapsed(&ts);
> +
> + if ((t - t_last) > 5UL * NSEC_PER_SEC) {
> +/* Absolute timeout to save time. */
> + msg->status = RT_TIMEOUT;
> + } else if ((t - t_last) > NSEC_PER_SEC / 10) {
> + /* Backoff every 100ms to give it chance to complete.
> */
> + t_last = t;
> + usleep(1);
> + }
> + }
> +
> + *t_wait = igt_nsec_elapsed(&ts) / 1e9;
(I would keep this as nanonseconds in the double until we need to
convert into human readable units.)
> + msg->status = RT_OK;
> +}
> +
> +/*
> + * Test whether RT thread which hogs the CPU a lot can submit work with
> + * reasonable latency.
> + */
> +static void
> +rthog_latency_on_ring(int fd, unsigned int ring, const char *name)
> +{
> + const char *passname[] = { "warmup", "normal", "rt" };
> + struct rt_pkt res[3];
> + unsigned int i;
> + int link[2];
> + int ret;
> +
> + igt_require(gem_can_store_dword(fd, ring));
> +
> + igt_assert(pipe(link) == 0);
> +
> + memset(res, 0, sizeof(res));
> +
> +igt_fork(child, 1) {
> + unsigned int pass = 0; /* Three passes: warmup, normal, rt. */
> +
> + do {
> + struct rt_pkt msg = { };
> + igt_spin_t *spin;
> +
> + igt_mean_init(&msg.mean);
> +
> + if (pass == 2) {
> + struct sched_param rt =
> + { .sched_priority = 99 };
> +
> + ret = sched_setscheduler(0,
> + SCHED_FIFO |
> SCHED_RESET_ON_FORK,
> + &rt);
> + if (ret) {
> + igt_warn("Failed to set scheduling
> policy!\n");
> + msg.status = RT_FAIL;
> + write(link[1], &msg, sizeof(msg));
> + exit(1);
> + }
> + }
> +
> + spin = __igt_spin_batch_new_poll(fd, 0, ring);
> + if (!spin) {
> + igt_warn("Failed to create spinner! (%s)\n",
> +passname[pass]);
> + msg.status = RT_FAIL;
> + write(link[1], &msg, sizeof(msg));
> + exit(1);
> + }
> + igt_spin_busywait_until_running(spin);
> +
> + igt_until_timeout(pass > 0 ? 5 : 2) {
> + double t;
> +
> + igt_spin_batch_end(spin);
> + gem_sync(fd, spin->handle);
> +
> +
Re: [Intel-gfx] [RFC v4 23/25] drm: Add DRM device registered notifier
On Sat, Apr 14, 2018 at 01:53:16PM +0200, Noralf Trønnes wrote:
> Add a notifier that fires when a new DRM device is registered.
> This can be used by the bootsplash client to connect to all devices.
>
> Signed-off-by: Noralf Trønnes
So I freaked out temporarily about your usage of notifiers here. But I
think this one of the few cases where using notifiers is actually
perfectly fine. Still not sure we really want that, instead of just
hard-coding calls to the various register functions directly (and using a
dummy no-op replacement if that part isn't enabled in Kconfig).
-Daniel
> ---
> drivers/gpu/drm/drm_drv.c | 32
> include/drm/drm_drv.h | 4
> 2 files changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 6f21bafb29be..e42ce320ad07 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -79,6 +80,8 @@ static struct dentry *drm_debugfs_root;
>
> DEFINE_STATIC_SRCU(drm_unplug_srcu);
>
> +static BLOCKING_NOTIFIER_HEAD(drm_dev_notifier);
> +
> /*
> * DRM Minors
> * A DRM device can provide several char-dev interfaces on the DRM-Major.
> Each
> @@ -837,6 +840,8 @@ int drm_dev_register(struct drm_device *dev, unsigned
> long flags)
>dev->dev ? dev_name(dev->dev) : "virtual device",
>dev->primary->index);
>
> + blocking_notifier_call_chain(&drm_dev_notifier, 0, dev);
> +
> goto out_unlock;
>
> err_minors:
> @@ -894,6 +899,33 @@ void drm_dev_unregister(struct drm_device *dev)
> }
> EXPORT_SYMBOL(drm_dev_unregister);
>
> +/**
> + * drm_dev_register_notifier - Register a notifier for new DRM devices
> + * @nb: Notifier block
> + *
> + * Register a notifier that fires when a new &drm_device is registered.
> + *
> + * Note:
> + * Users of this function has to be linked into drm.ko. This is done to make
> + * life simple avoiding tricky race situations.
> + */
> +void drm_dev_register_notifier(struct notifier_block *nb)
> +{
> + /* Currently this can't fail, but catch it in case this changes */
> + WARN_ON(blocking_notifier_chain_register(&drm_dev_notifier, nb));
> +}
> +
> +/**
> + * drm_dev_unregister_notifier - Unregister DRM device notifier
> + * @nb: Notifier block
> + *
> + * This is a no-op if the notifier isn't registered.
> + */
> +void drm_dev_unregister_notifier(struct notifier_block *nb)
> +{
> + blocking_notifier_chain_unregister(&drm_dev_notifier, nb);
> +}
> +
> /**
> * drm_dev_set_unique - Set the unique name of a DRM device
> * @dev: device of which to set the unique name
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 13356e6fd40c..5e6c6ed0d59d 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -40,6 +40,7 @@ struct drm_minor;
> struct dma_buf_attachment;
> struct drm_display_mode;
> struct drm_mode_create_dumb;
> +struct notifier_block;
> struct drm_printer;
>
> /* driver capabilities and requirements mask */
> @@ -641,6 +642,9 @@ struct drm_device *drm_dev_alloc(struct drm_driver
> *driver,
> int drm_dev_register(struct drm_device *dev, unsigned long flags);
> void drm_dev_unregister(struct drm_device *dev);
>
> +void drm_dev_register_notifier(struct notifier_block *nb);
> +void drm_dev_unregister_notifier(struct notifier_block *nb);
> +
> void drm_dev_get(struct drm_device *dev);
> void drm_dev_put(struct drm_device *dev);
> void drm_dev_unref(struct drm_device *dev);
> --
> 2.15.1
>
> ___
> 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
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, April 17, 2018 3:32 PM
> To: Srinivas, Vidya ; Saarinen, Jani
> ; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
>
> Op 17-04-18 om 11:42 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Tuesday, April 17, 2018 3:04 PM
> >> To: Srinivas, Vidya ; Saarinen, Jani
> >> ; intel-gfx@lists.freedesktop.org
> >> Cc: Kamath, Sunil
> >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >> for
> >> NV12
> >>
> >> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
> -Original Message-
> From: Srinivas, Vidya
> Sent: Tuesday, April 17, 2018 1:32 PM
> To: 'Maarten Lankhorst' ;
> Saarinen, Jani ;
> intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil
> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> for
> NV12
>
>
>
> > -Original Message-
> > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > Sent: Tuesday, April 17, 2018 1:21 PM
> > To: Srinivas, Vidya ; Saarinen, Jani
> > ; intel-gfx@lists.freedesktop.org
> > Cc: Kamath, Sunil
> > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> > for
> > NV12
> >
> > Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> >>> -Original Message-
> >>> From: Maarten Lankhorst
> >>> [mailto:maarten.lankho...@linux.intel.com]
> >>> Sent: Tuesday, April 17, 2018 12:55 PM
> >>> To: Saarinen, Jani ; Srinivas, Vidya
> >>> ;
> >>> intel-gfx-try...@lists.freedesktop.org;
> >>> intel- g...@lists.freedesktop.org
> >>> Cc: Kamath, Sunil
> >>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>> adjustments for
> >>> NV12
> >>>
> >>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> Lets move this to intel-gfx to get more eyes on it.
>
> > -Original Message-
> > From: Srinivas, Vidya
> > Sent: tiistai 17. huhtikuuta 2018 5.47
> > To: Maarten Lankhorst ;
> > intel-gfx- try...@lists.freedesktop.org
> > Cc: Kamath, Sunil ; Saarinen, Jani
> >
> > Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> > adjustments for NV12
> >
> >
> >
> >> -Original Message-
> >> From: Maarten Lankhorst
> >> [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Monday, April 16, 2018 8:00 PM
> >> To: Srinivas, Vidya ; intel-gfx-
> >> try...@lists.freedesktop.org
> >> Cc: Kamath, Sunil ; Saarinen, Jani
> >>
> >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> >> adjustments for
> >> NV12
> >>
> >> Hmm, more thought about src adjustments...
> >>
> >> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> >>> We skip src trunction/adjustments for
> >>> NV12 case and handle the sizes directly.
> >>> Without this, pipe fifo underruns are seen on APL/KBL.
> >>>
> >>> v2: For NV12, making the src coordinates multiplier of 4
> >>>
> >>> Credits-to: Maarten Lankhorst
> >>>
> >>> Signed-off-by: Vidya Srinivas
> >>> ---
> >>> drivers/gpu/drm/i915/intel_display.c | 11 +++
> >>> drivers/gpu/drm/i915/intel_sprite.c | 15 +++
> >>> 2 files changed, 26 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>> b/drivers/gpu/drm/i915/intel_display.c
> >>> index bc83f10..f64708f 100644
> >>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>> @@ -12978,6 +12978,10 @@
> intel_check_primary_plane(struct
> >> intel_plane *plane,
> >>> bool can_position = false;
> >>> int ret;
> >>> uint32_t pixel_format = 0;
> >>> + struct drm_plane_state *plane_state = &state->base;
> >>> + struct drm_rect *src = &plane_state->src;
> >>> +
> >>> + *src = drm_plane_state_src(plane_state);
> >>>
> >>> if (INTEL_GEN(dev_priv) >= 9) {
> >>> /* use scaler when colorkey is not required */ @@ -
> > 13001,6
> >>> +13005,13 @@ intel_check_primary_plane(struct intel_plane
> > *plane,
> >>> if (!state->base.fb)
> >>> return 0;
> >>>
> >>> + if (pixel_format == DRM_FORMAT_NV12) {
> >>> + src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> >>> + src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> >>> + src->y1 = (((src->y1 >>
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Handle a potential failure of intel_ring_begin
Quoting Oscar Mateo (2018-04-16 22:57:01)
> Silence smatch over:
>
> drivers/gpu/drm/i915/selftests/intel_workarounds.c:58 read_nonprivs() error:
> 'cs' dereferencing possible ERR_PTR()
>
> by handling a potential (but unlikely) failure of intel_ring_begin.
>
> Fixes: f4ecfbfc32ed ("drm/i915: Check whitelist registers across resets")
> Signed-off-by: Oscar Mateo
> Cc: Chris Wilson
Serves me right for forgetting to check with smatch myself.
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] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Handle a potential failure of intel_ring_begin
Quoting Patchwork (2018-04-17 00:47:27) > == Series Details == > > Series: drm/i915/selftests: Handle a potential failure of intel_ring_begin > URL : https://patchwork.freedesktop.org/series/41773/ > State : failure > > == Summary == > > = CI Bug Log - changes from CI_DRM_4058_full -> Patchwork_8700_full = > > == Summary - FAILURE == > > Serious unknown changes coming with Patchwork_8700_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_8700_full, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://patchwork.freedesktop.org/api/1.0/series/41773/revisions/1/mbox/ > > == Possible new issues == > > Here are the unknown changes that may have been introduced in > Patchwork_8700_full: > > === IGT changes === > > Possible regressions > > igt@gem_wait@wait-vebox: > shard-apl: PASS -> FAIL Unconnected to this patch, so pushed. Thanks for the fix up, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, April 17, 2018 3:32 PM
> To: Srinivas, Vidya ; Saarinen, Jani
> ; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
>
> Op 17-04-18 om 11:42 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Tuesday, April 17, 2018 3:04 PM
> >> To: Srinivas, Vidya ; Saarinen, Jani
> >> ; intel-gfx@lists.freedesktop.org
> >> Cc: Kamath, Sunil
> >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >> for
> >> NV12
> >>
> >> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
> -Original Message-
> From: Srinivas, Vidya
> Sent: Tuesday, April 17, 2018 1:32 PM
> To: 'Maarten Lankhorst' ;
> Saarinen, Jani ;
> intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil
> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> for
> NV12
>
>
>
> > -Original Message-
> > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> > Sent: Tuesday, April 17, 2018 1:21 PM
> > To: Srinivas, Vidya ; Saarinen, Jani
> > ; intel-gfx@lists.freedesktop.org
> > Cc: Kamath, Sunil
> > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> > for
> > NV12
> >
> > Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> >>> -Original Message-
> >>> From: Maarten Lankhorst
> >>> [mailto:maarten.lankho...@linux.intel.com]
> >>> Sent: Tuesday, April 17, 2018 12:55 PM
> >>> To: Saarinen, Jani ; Srinivas, Vidya
> >>> ;
> >>> intel-gfx-try...@lists.freedesktop.org;
> >>> intel- g...@lists.freedesktop.org
> >>> Cc: Kamath, Sunil
> >>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>> adjustments for
> >>> NV12
> >>>
> >>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> Lets move this to intel-gfx to get more eyes on it.
>
> > -Original Message-
> > From: Srinivas, Vidya
> > Sent: tiistai 17. huhtikuuta 2018 5.47
> > To: Maarten Lankhorst ;
> > intel-gfx- try...@lists.freedesktop.org
> > Cc: Kamath, Sunil ; Saarinen, Jani
> >
> > Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> > adjustments for NV12
> >
> >
> >
> >> -Original Message-
> >> From: Maarten Lankhorst
> >> [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Monday, April 16, 2018 8:00 PM
> >> To: Srinivas, Vidya ; intel-gfx-
> >> try...@lists.freedesktop.org
> >> Cc: Kamath, Sunil ; Saarinen, Jani
> >>
> >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> >> adjustments for
> >> NV12
> >>
> >> Hmm, more thought about src adjustments...
> >>
> >> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> >>> We skip src trunction/adjustments for
> >>> NV12 case and handle the sizes directly.
> >>> Without this, pipe fifo underruns are seen on APL/KBL.
> >>>
> >>> v2: For NV12, making the src coordinates multiplier of 4
> >>>
> >>> Credits-to: Maarten Lankhorst
> >>>
> >>> Signed-off-by: Vidya Srinivas
> >>> ---
> >>> drivers/gpu/drm/i915/intel_display.c | 11 +++
> >>> drivers/gpu/drm/i915/intel_sprite.c | 15 +++
> >>> 2 files changed, 26 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>> b/drivers/gpu/drm/i915/intel_display.c
> >>> index bc83f10..f64708f 100644
> >>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>> @@ -12978,6 +12978,10 @@
> intel_check_primary_plane(struct
> >> intel_plane *plane,
> >>> bool can_position = false;
> >>> int ret;
> >>> uint32_t pixel_format = 0;
> >>> + struct drm_plane_state *plane_state = &state->base;
> >>> + struct drm_rect *src = &plane_state->src;
> >>> +
> >>> + *src = drm_plane_state_src(plane_state);
> >>>
> >>> if (INTEL_GEN(dev_priv) >= 9) {
> >>> /* use scaler when colorkey is not required */ @@ -
> > 13001,6
> >>> +13005,13 @@ intel_check_primary_plane(struct intel_plane
> > *plane,
> >>> if (!state->base.fb)
> >>> return 0;
> >>>
> >>> + if (pixel_format == DRM_FORMAT_NV12) {
> >>> + src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> >>> + src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> >>> + src->y1 = (((src->y1 >>
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
HI, > -Original Message- > From: Srinivas, Vidya > Sent: tiistai 17. huhtikuuta 2018 13.49 > To: Maarten Lankhorst ; Saarinen, Jani > ; intel-gfx@lists.freedesktop.org > Cc: Kamath, Sunil > Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12 > > > > > -Original Message- > > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] > > Sent: Tuesday, April 17, 2018 3:32 PM > > To: Srinivas, Vidya ; Saarinen, Jani > > ; intel-gfx@lists.freedesktop.org > > Cc: Kamath, Sunil > > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for > > NV12 > > > > Op 17-04-18 om 11:42 schreef Srinivas, Vidya: > > > > > >> -Original Message- > > >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] > > >> Sent: Tuesday, April 17, 2018 3:04 PM > > >> To: Srinivas, Vidya ; Saarinen, Jani > > >> ; intel-gfx@lists.freedesktop.org > > >> Cc: Kamath, Sunil > > >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments > > >> for > > >> NV12 > > >> > > >> Op 17-04-18 om 10:09 schreef Srinivas, Vidya: > > -Original Message- > > From: Srinivas, Vidya > > Sent: Tuesday, April 17, 2018 1:32 PM > > To: 'Maarten Lankhorst' ; > > Saarinen, Jani ; > > intel-gfx@lists.freedesktop.org > > Cc: Kamath, Sunil > > Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src > > adjustments for > > NV12 > > > > > > > > > -Original Message- > > > From: Maarten Lankhorst > > > [mailto:maarten.lankho...@linux.intel.com] > > > Sent: Tuesday, April 17, 2018 1:21 PM > > > To: Srinivas, Vidya ; Saarinen, Jani > > > ; intel-gfx@lists.freedesktop.org > > > Cc: Kamath, Sunil > > > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src > > > adjustments for > > > NV12 > > > > > > Op 17-04-18 om 09:38 schreef Srinivas, Vidya: > > >>> -Original Message- > > >>> From: Maarten Lankhorst > > >>> [mailto:maarten.lankho...@linux.intel.com] > > >>> Sent: Tuesday, April 17, 2018 12:55 PM > > >>> To: Saarinen, Jani ; Srinivas, Vidya > > >>> ; > > >>> intel-gfx-try...@lists.freedesktop.org; > > >>> intel- g...@lists.freedesktop.org > > >>> Cc: Kamath, Sunil > > >>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src > > >>> adjustments for > > >>> NV12 > > >>> > > >>> Op 17-04-18 om 08:03 schreef Saarinen, Jani: > > Lets move this to intel-gfx to get more eyes on it. > > > > > -Original Message- > > > From: Srinivas, Vidya > > > Sent: tiistai 17. huhtikuuta 2018 5.47 > > > To: Maarten Lankhorst ; > > > intel-gfx- try...@lists.freedesktop.org > > > Cc: Kamath, Sunil ; Saarinen, Jani > > > > > > Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src > > > adjustments for NV12 > > > > > > > > > > > >> -Original Message- > > >> From: Maarten Lankhorst > > >> [mailto:maarten.lankho...@linux.intel.com] > > >> Sent: Monday, April 16, 2018 8:00 PM > > >> To: Srinivas, Vidya ; intel-gfx- > > >> try...@lists.freedesktop.org > > >> Cc: Kamath, Sunil ; Saarinen, Jani > > >> > > >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src > > >> adjustments for > > >> NV12 > > >> > > >> Hmm, more thought about src adjustments... > > >> > > >> Op 13-04-18 om 07:22 schreef Vidya Srinivas: > > >>> We skip src trunction/adjustments for > > >>> NV12 case and handle the sizes directly. > > >>> Without this, pipe fifo underruns are seen on APL/KBL. > > >>> > > >>> v2: For NV12, making the src coordinates multiplier of 4 > > >>> > > >>> Credits-to: Maarten Lankhorst > > >>> > > >>> Signed-off-by: Vidya Srinivas > > >>> --- > > >>> drivers/gpu/drm/i915/intel_display.c | 11 +++ > > >>> drivers/gpu/drm/i915/intel_sprite.c | 15 > +++ > > >>> 2 files changed, 26 insertions(+) > > >>> > > >>> diff --git a/drivers/gpu/drm/i915/intel_display.c > > >>> b/drivers/gpu/drm/i915/intel_display.c > > >>> index bc83f10..f64708f 100644 > > >>> --- a/drivers/gpu/drm/i915/intel_display.c > > >>> +++ b/drivers/gpu/drm/i915/intel_display.c > > >>> @@ -12978,6 +12978,10 @@ > > intel_check_primary_plane(struct > > >> intel_plane *plane, > > >>> bool can_position = false; > > >>> int ret; > > >>> uint32_t pixel_format = 0; > > >>> + struct drm_plane_state *plane_state = &state- > >base; > > >>> + struct drm_rect *src = &plane_state->src; > > >>> + > > >>> + *src = drm_plane_state_src(plane
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for GMBUS changes (rev3)
== Series Details == Series: GMBUS changes (rev3) URL : https://patchwork.freedesktop.org/series/41632/ State : warning == Summary == $ dim checkpatch origin/drm-tip 16f60217eb21 drm/i915/gmbus: Increase the Bytes per Rd/Wr Op bcedea2a9483 drm/i915/gmbus: Enable burst read -:28: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible side-effects? #28: FILE: drivers/gpu/drm/i915/i915_drv.h:2554: +#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \ + IS_GEMINILAKE(dev_priv) || \ + IS_KABYLAKE(dev_priv)) -:42: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #42: FILE: drivers/gpu/drm/i915/i915_reg.h:2999: +#define GMBUS_BYTE_CNT_OVERRIDE (1<<6) ^ total: 0 errors, 0 warnings, 2 checks, 59 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for GMBUS changes (rev3)
== Series Details == Series: GMBUS changes (rev3) URL : https://patchwork.freedesktop.org/series/41632/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/gmbus: Increase the Bytes per Rd/Wr Op -O:drivers/gpu/drm/i915/intel_i2c.c:403:23: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_i2c.c:465:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:410:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:410:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:472:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:472:23: warning: expression using sizeof(void) Commit: drm/i915/gmbus: Enable burst read -O:drivers/gpu/drm/i915/intel_i2c.c:410:23: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_i2c.c:410:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:428:31: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:428:31: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/../i915_drv.h:3655:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3658:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add documentation to gen9_set_dc_state()
Add documentation to gen9_set_dc_state() on what enabling a given DC
state means and at what point HW/DMC actually enters/exits these states.
Cc: Jani Nikula
Cc: Daniel Vetter
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++
1 file changed, 23 insertions(+)
[ On IRC I stated that PSR entry would be prevented in a given DC state,
but looking more at it I haven't found any proof for this. So as I
understand the only connection between PSR and DC states is that if
DC5/6 is disabled power saving will be blocked, which would otherwise
be possible when PSR is active and the display pipe is off. ]
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 53ea564f971e..40a7955886d4 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private
*dev_priv)
dev_priv->csr.dc_state = val;
}
+/**
+ * gen9_set_dc_state - set target display C power state
+ * @dev_priv: i915 device instance
+ * @state: target DC power state
+ * - DC_STATE_DISABLE
+ * - DC_STATE_EN_UPTO_DC5
+ * - DC_STATE_EN_UPTO_DC6
+ * - DC_STATE_EN_DC9
+ *
+ * Signal to DMC firmware/HW the target DC power state passed in @state.
+ * DMC/HW can turn off individual display clocks and power rails when entering
+ * a deeper DC power state (higher in number) and turns these back when exiting
+ * that state to a shallower power state (lower in number). The HW will decide
+ * when to actually enter a given state on an on-demand basis, for instance
+ * depending on the active state of display pipes. The state of display
+ * registers backed by affected power rails are saved/restored as needed.
+ *
+ * Based on the above enabling a deeper DC power state is asynchronous wrt.
+ * enabling it. Disabling a deeper power state is synchronous: for instance
+ * setting %DC_STATE_DISABLE won't complete until all HW resources are turned
+ * back on and register state is restored. This is guaranteed by the MMIO write
+ * to DC_STATE_EN blocking until the state is restored.
+ */
static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t
state)
{
uint32_t val;
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for GMBUS changes (rev3)
== Series Details == Series: GMBUS changes (rev3) URL : https://patchwork.freedesktop.org/series/41632/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4059 -> Patchwork_8703 = == Summary - WARNING == Minor unknown changes coming with Patchwork_8703 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8703, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41632/revisions/3/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8703: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8703 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: PASS -> DMESG-WARN (fdo#105128) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-ivb-3520m: PASS -> DMESG-WARN (fdo#106084) +1 Possible fixes igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: fi-elk-e7500: INCOMPLETE (fdo#103989) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-ivb-3520m: DMESG-WARN (fdo#106084) -> PASS fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 == Participating hosts (36 -> 33) == Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4059 -> Patchwork_8703 CI_DRM_4059: c1645edc253f2b52a8c94565a75b479a6782e75f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4435: ddbe5a4d8bb1780ecf07f72e815062d3bce8ff71 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8703: bcedea2a9483baceeda55a73119ea1c49d4a1a0d @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4435: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Linux commits == bcedea2a9483 drm/i915/gmbus: Enable burst read 16f60217eb21 drm/i915/gmbus: Increase the Bytes per Rd/Wr Op == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8703/issues.html ___ 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: Remove skl dc6 enable/disable functions
== Series Details == Series: drm/i915: Remove skl dc6 enable/disable functions URL : https://patchwork.freedesktop.org/series/41803/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4059 -> Patchwork_8704 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/41803/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_8704 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-ivb-3520m: PASS -> DMESG-WARN (fdo#106084) fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) Possible fixes igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: FAIL (fdo#102575) -> PASS igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: fi-elk-e7500: INCOMPLETE (fdo#103989) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-ivb-3520m: DMESG-WARN (fdo#106084) -> PASS fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 == Participating hosts (36 -> 33) == Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4059 -> Patchwork_8704 CI_DRM_4059: c1645edc253f2b52a8c94565a75b479a6782e75f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4435: ddbe5a4d8bb1780ecf07f72e815062d3bce8ff71 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8704: cadfa04c6ef9b6d841f5115a415a34cb82f8af06 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4435: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Linux commits == cadfa04c6ef9 drm/i915: Remove skl dc6 enable/disable functions == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8704/issues.html ___ 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: Add documentation to gen9_set_dc_state()
== Series Details == Series: drm/i915: Add documentation to gen9_set_dc_state() URL : https://patchwork.freedesktop.org/series/41811/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4059 -> Patchwork_8705 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/41811/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_8705 that come from known issues: === IGT changes === Possible fixes igt@gem_exec_suspend@basic-s3: fi-ivb-3520m: DMESG-WARN (fdo#106084) -> PASS +1 igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: fi-elk-e7500: INCOMPLETE (fdo#103989) -> PASS fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 == Participating hosts (36 -> 32) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4059 -> Patchwork_8705 CI_DRM_4059: c1645edc253f2b52a8c94565a75b479a6782e75f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4435: ddbe5a4d8bb1780ecf07f72e815062d3bce8ff71 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8705: 0aa28a05f4e92e6d5d1dd2824b76b515782989a1 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4435: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Linux commits == 0aa28a05f4e9 drm/i915: Add documentation to gen9_set_dc_state() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8705/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 7/7] drm/i915: Allow clients to query own per-engine busyness
From: Tvrtko Ursulin
Some customers want to know how much of the GPU time are their clients
using in order to make dynamic load balancing decisions.
With the accounting infrastructure in place in the previous patch, we add
a new context param (I915_CONTEXT_GET_ENGINES_BUSY) which points to struct
drm_i915_context_engines_busy, followed by a variable number of structs
drm_i915_context_engine_busy.
Userspace needs to provide the number of attached structures in the
num_engines fields, as well as set args->size to byte size of the provided
buffer.
Attached drm_i915_context_engine_busy objects need to have the class and
instance of the engine which userspace wants to query busyness of
initialized.
Kernel will then report accumulated engine busyness as monotonically
increasing number of nano-seconds the engine spent executing jobs
belonging to this context.
v2:
* Use intel_context_engine_get_busy_time.
* Refactor to only use struct_mutex while initially enabling engine
stats.
v3:
* Fix stats enabling.
v4:
* Change uAPI to enable querying multiple engines at a time.
(Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Cc: gordon.ke...@intel.com
---
This version has been compile tested only until acceptable to
everyone.
---
drivers/gpu/drm/i915/i915_gem_context.c | 97 -
drivers/gpu/drm/i915/i915_gem_context.h | 1 +
include/uapi/drm/i915_drm.h | 21 +++
3 files changed, 116 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index e9b0940ce7f9..7cfec17b51cf 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -126,6 +126,9 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
for (i = 0; i < I915_NUM_ENGINES; i++) {
struct intel_context *ce = &ctx->engine[i];
+ if (ctx->i915->engine[i] && ce->stats.enabled)
+ intel_disable_engine_stats(ctx->i915->engine[i]);
+
if (!ce->state)
continue;
@@ -730,11 +733,95 @@ int i915_gem_context_destroy_ioctl(struct drm_device
*dev, void *data,
return 0;
}
+static int
+get_engines_busy(struct drm_i915_private *i915,
+struct i915_gem_context *ctx,
+struct drm_i915_gem_context_param *args)
+{
+ struct drm_i915_context_engine_busy __user *busy_user;
+ struct drm_i915_context_engines_busy engines;
+ struct drm_i915_context_engine_busy busy;
+ bool mutex = false;
+ unsigned int i;
+ int ret = 0;
+
+ if (args->size < sizeof(engines))
+ return -EINVAL;
+
+ if (copy_from_user(&engines, u64_to_user_ptr(args->value),
+ sizeof(engines)))
+ return -EFAULT;
+
+ if (engines.pad || engines.mbz)
+ return -EINVAL;
+
+ if (engines.num_engines == 0 || engines.num_engines > I915_NUM_ENGINES)
+ return -EINVAL;
+
+ if (!access_ok(VERIFY_WRITE, args->value,
+ sizeof(engines) + engines.num_engines * sizeof(busy)))
+ return -EFAULT;
+
+ busy_user = (struct drm_i915_context_engine_busy __user *)
+ ((char __user *)args->value + sizeof(engines));
+
+ for (i = 0; i < engines.num_engines; i++, busy_user++) {
+ struct intel_engine_cs *engine;
+ struct intel_context *ce;
+
+ __copy_from_user(busy_user, &busy, sizeof(busy));
+
+ if (busy.mbz || busy.flags || busy.busy) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ engine = intel_engine_lookup_user(i915,
+ busy.class, busy.instance);
+ if (!engine) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ /* Enable stats on first query. */
+ ce = &ctx->engine[engine->id];
+ if (!READ_ONCE(ce->stats.enabled)) {
+ /* Grab mutex if need to enable engine stats. */
+ if (!mutex) {
+ ret = i915_mutex_lock_interruptible(&i915->drm);
+ if (!ret)
+ break;
+ mutex = true;
+ }
+
+ if (!ce->stats.enabled) {
+ ret = intel_enable_engine_stats(engine);
+ if (!ret)
+ goto out;
+ ce->stats.enabled = true;
+ }
+ }
+
+ busy.busy =
+ ktime_to_ns(intel_context_engine_get_busy_time(ctx,
+ engine));
+
[Intel-gfx] [RFC 4/7] drm/i915: Update client name on context create
From: Tvrtko Ursulin
Some clients have the DRM fd passed to them over a socket by the X server.
Grab the real client and pid when they create their first context and
update the exposed data for more useful enumeration.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 8
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
drivers/gpu/drm/i915/i915_gem_context.c | 16 +---
3 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ff2ad9719b1e..456dc495e017 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3195,6 +3195,14 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
void i915_gem_object_unpin_from_display_plane(struct i915_vma *vma);
int i915_gem_object_attach_phys(struct drm_i915_gem_object *obj,
int align);
+
+int
+i915_gem_add_client(struct drm_i915_private *i915,
+ struct drm_i915_file_private *file_priv,
+ struct task_struct *task,
+ unsigned int serial);
+void i915_gem_remove_client(struct drm_i915_file_private *file_priv);
+
int i915_gem_open(struct drm_i915_private *i915, struct drm_file *file);
void i915_gem_release(struct drm_device *dev, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 421e6c9e95f4..4c20545e3539 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5728,7 +5728,7 @@ show_client_pid(struct device *kdev, struct
device_attribute *attr, char *buf)
return snprintf(buf, PAGE_SIZE, "%u", file_priv->client.pid);
}
-static int
+int
i915_gem_add_client(struct drm_i915_private *i915,
struct drm_i915_file_private *file_priv,
struct task_struct *task,
@@ -5786,7 +5786,7 @@ i915_gem_add_client(struct drm_i915_private *i915,
return ret;
}
-static void i915_gem_remove_client(struct drm_i915_file_private *file_priv)
+void i915_gem_remove_client(struct drm_i915_file_private *file_priv)
{
sysfs_remove_file(file_priv->client.root,
(struct attribute *)&file_priv->client.attr.pid);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 85627fa4565b..e9b0940ce7f9 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -653,9 +653,10 @@ static bool client_is_banned(struct drm_i915_file_private
*file_priv)
int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
+ struct drm_i915_file_private *file_priv = file->driver_priv;
+ pid_t pid = pid_nr(get_task_pid(current, PIDTYPE_PID));
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_i915_gem_context_create *args = data;
- struct drm_i915_file_private *file_priv = file->driver_priv;
struct i915_gem_context *ctx;
int ret;
@@ -667,8 +668,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
void *data,
if (client_is_banned(file_priv)) {
DRM_DEBUG("client %s[%d] banned from creating ctx\n",
- current->comm,
- pid_nr(get_task_pid(current, PIDTYPE_PID)));
+ current->comm, pid);
return -EIO;
}
@@ -677,6 +677,16 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
void *data,
if (ret)
return ret;
+ if (file_priv->client.pid != pid) {
+ i915_gem_remove_client(file_priv);
+ ret = i915_gem_add_client(dev_priv, file_priv, current,
+ file_priv->client.id);
+ if (ret) {
+ mutex_unlock(&dev->struct_mutex);
+ return ret;
+ }
+ }
+
ctx = i915_gem_create_context(dev_priv, file_priv);
mutex_unlock(&dev->struct_mutex);
if (IS_ERR(ctx))
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 6/7] drm/i915: Add sysfs toggle to enable per-client engine stats
From: Tvrtko Ursulin
By default we are not collecting any per-engine and per-context
statistcs.
Add a new sysfs toggle to enable this facility:
$ echo 1 >/sys/class/drm/card0/clients/enable_stats
v2: Rebase.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 4 +++
drivers/gpu/drm/i915/i915_sysfs.c | 72 +++
2 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f83b8dcac16b..aa82df864dd4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2136,6 +2136,10 @@ struct drm_i915_private {
struct i915_drm_clients {
struct kobject *root;
atomic_t serial;
+ struct {
+ bool enabled;
+ struct device_attribute attr;
+ } stats;
} clients;
/*
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index d809259456ef..70115072d56f 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -576,9 +576,67 @@ static void i915_setup_error_capture(struct device *kdev)
{}
static void i915_teardown_error_capture(struct device *kdev) {}
#endif
+static ssize_t
+show_client_stats(struct device *kdev, struct device_attribute *attr, char
*buf)
+{
+ struct drm_i915_private *i915 =
+ container_of(attr, struct drm_i915_private, clients.stats.attr);
+
+ return snprintf(buf, PAGE_SIZE, "%u\n", i915->clients.stats.enabled);
+}
+
+static ssize_t
+store_client_stats(struct device *kdev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct drm_i915_private *i915 =
+ container_of(attr, struct drm_i915_private, clients.stats.attr);
+ bool disable = false;
+ bool enable = false;
+ bool val = false;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ int ret;
+
+/* Use RCS as proxy for all engines. */
+ if (!intel_engine_supports_stats(i915->engine[RCS]))
+ return -EINVAL;
+
+ ret = kstrtobool(buf, &val);
+ if (ret)
+ return ret;
+
+ ret = i915_mutex_lock_interruptible(&i915->drm);
+ if (ret)
+ return ret;
+
+ if (val && !i915->clients.stats.enabled)
+ enable = true;
+ else if (!val && i915->clients.stats.enabled)
+ disable = true;
+
+ if (!enable && !disable)
+ goto out;
+
+ for_each_engine(engine, i915, id) {
+ if (enable)
+ WARN_ON_ONCE(intel_enable_engine_stats(engine));
+ else if (disable)
+ intel_disable_engine_stats(engine);
+ }
+
+ i915->clients.stats.enabled = val;
+
+out:
+ mutex_unlock(&i915->drm.struct_mutex);
+
+ return count;
+}
+
void i915_setup_sysfs(struct drm_i915_private *dev_priv)
{
struct device *kdev = dev_priv->drm.primary->kdev;
+ struct device_attribute *attr;
int ret;
dev_priv->clients.root =
@@ -586,6 +644,17 @@ void i915_setup_sysfs(struct drm_i915_private *dev_priv)
if (!dev_priv->clients.root)
DRM_ERROR("Per-client sysfs setup failed\n");
+ attr = &dev_priv->clients.stats.attr;
+ attr->attr.name = "enable_stats";
+ attr->attr.mode = 0664;
+ attr->show = show_client_stats;
+ attr->store = store_client_stats;
+
+ ret = sysfs_create_file(dev_priv->clients.root,
+ (struct attribute *)attr);
+ if (ret)
+ DRM_ERROR("Per-client sysfs setup failed! (%d)\n", ret);
+
#ifdef CONFIG_PM
if (HAS_RC6(dev_priv)) {
ret = sysfs_merge_group(&kdev->kobj,
@@ -647,6 +716,9 @@ void i915_teardown_sysfs(struct drm_i915_private *dev_priv)
sysfs_unmerge_group(&kdev->kobj, &rc6p_attr_group);
#endif
+ sysfs_remove_file(dev_priv->clients.root,
+ (struct attribute *)&dev_priv->clients.stats.attr);
+
if (dev_priv->clients.root)
kobject_put(dev_priv->clients.root);
}
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 3/7] drm/i915: Expose list of clients in sysfs
From: Tvrtko Ursulin
Expose a list of clients with open file handles in sysfs.
This will be a basis for a top-like utility showing per-client and per-
engine GPU load.
Currently we only expose each client's pid and name under opaque numbered
directories in /sys/class/drm/card0/clients/.
For instance:
/sys/class/drm/card0/clients/3/name: Xorg
/sys/class/drm/card0/clients/3/pid: 5664
v2:
Chris Wilson:
* Enclose new members into dedicated structs.
* Protect against failed sysfs registration.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 19 +++
drivers/gpu/drm/i915/i915_gem.c | 117 +++---
drivers/gpu/drm/i915/i915_sysfs.c | 8 +++
3 files changed, 137 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 649c0f2f3bae..ff2ad9719b1e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -347,6 +347,20 @@ struct drm_i915_file_private {
*/
#define I915_MAX_CLIENT_CONTEXT_BANS 3
atomic_t context_bans;
+
+ struct i915_drm_client {
+ unsigned int id;
+
+ pid_t pid;
+ char *name;
+
+ struct kobject *root;
+
+ struct {
+ struct device_attribute pid;
+ struct device_attribute name;
+ } attr;
+ } client;
};
/* Interface history:
@@ -2111,6 +2125,11 @@ struct drm_i915_private {
struct i915_pmu pmu;
+ struct i915_drm_clients {
+ struct kobject *root;
+ atomic_t serial;
+ } clients;
+
/*
* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
* will be rejected. Instead look for a better place.
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 062a9c743607..421e6c9e95f4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5708,6 +5708,94 @@ int i915_gem_freeze_late(struct drm_i915_private
*dev_priv)
return 0;
}
+static ssize_t
+show_client_name(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+ struct drm_i915_file_private *file_priv =
+ container_of(attr, struct drm_i915_file_private,
+client.attr.name);
+
+ return snprintf(buf, PAGE_SIZE, "%s", file_priv->client.name);
+}
+
+static ssize_t
+show_client_pid(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+ struct drm_i915_file_private *file_priv =
+ container_of(attr, struct drm_i915_file_private,
+client.attr.pid);
+
+ return snprintf(buf, PAGE_SIZE, "%u", file_priv->client.pid);
+}
+
+static int
+i915_gem_add_client(struct drm_i915_private *i915,
+ struct drm_i915_file_private *file_priv,
+ struct task_struct *task,
+ unsigned int serial)
+{
+ int ret = -ENOMEM;
+ struct device_attribute *attr;
+ char id[32];
+
+ if (!i915->clients.root)
+ goto err_name;
+
+ file_priv->client.name = kstrdup(task->comm, GFP_KERNEL);
+ if (!file_priv->client.name)
+ goto err_name;
+
+ snprintf(id, sizeof(id), "%u", serial);
+ file_priv->client.root = kobject_create_and_add(id,
+ i915->clients.root);
+ if (!file_priv->client.root)
+ goto err_client;
+
+ attr = &file_priv->client.attr.name;
+ attr->attr.name = "name";
+ attr->attr.mode = 0444;
+ attr->show = show_client_name;
+
+ ret = sysfs_create_file(file_priv->client.root,
+ (struct attribute *)attr);
+ if (ret)
+ goto err_attr_name;
+
+ attr = &file_priv->client.attr.pid;
+ attr->attr.name = "pid";
+ attr->attr.mode = 0444;
+ attr->show = show_client_pid;
+
+ ret = sysfs_create_file(file_priv->client.root,
+ (struct attribute *)attr);
+ if (ret)
+ goto err_attr_pid;
+
+ file_priv->client.pid = pid_nr(get_task_pid(task, PIDTYPE_PID));
+
+ return 0;
+
+err_attr_pid:
+ sysfs_remove_file(file_priv->client.root,
+ (struct attribute *)&file_priv->client.attr.name);
+err_attr_name:
+ kobject_put(file_priv->client.root);
+err_client:
+ kfree(file_priv->client.name);
+err_name:
+ return ret;
+}
+
+static void i915_gem_remove_client(struct drm_i915_file_private *file_priv)
+{
+ sysfs_remove_file(file_priv->client.root,
+ (struct attribute *)&file_priv->client.attr.pid);
+ sysfs_remove_file(file_priv->client.root,
+ (struct attribute *)&file_priv->client.attr.name);
+ kobject_put(file_priv->client.root);
+ kfree(file_priv->client.name);
+}
[Intel-gfx] [RFC 5/7] drm/i915: Expose per-engine client busyness
From: Tvrtko Ursulin
Expose per-client and per-engine busyness under the previously added sysfs
client root.
The new files are one per-engine instance and located under the 'busy'
directory.
Each contains a monotonically increasing nano-second resolution times each
client's jobs were executing on the GPU.
$ cat /sys/class/drm/card0/clients/5/busy/rcs0
32516602
This data can serve as an interface to implement a top like utility for
GPU jobs. For instance I have prototyped a tool in IGT which produces
periodic output like:
neverball[ 6011]: rcs0: 41.01% bcs0: 0.00% vcs0: 0.00% vecs0: 0.00%
Xorg[ 5664]: rcs0: 31.16% bcs0: 0.00% vcs0: 0.00% vecs0: 0.00%
xfwm4[ 5727]: rcs0: 0.00% bcs0: 0.00% vcs0: 0.00% vecs0: 0.00%
This tools can also be extended to use the i915 PMU and show overall engine
busyness, and engine loads using the queue depth metric.
v2: Use intel_context_engine_get_busy_time.
v3: New directory structure.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 8
drivers/gpu/drm/i915/i915_gem.c | 81 +++--
2 files changed, 86 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 456dc495e017..f83b8dcac16b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -317,6 +317,12 @@ struct drm_i915_private;
struct i915_mm_struct;
struct i915_mmu_object;
+struct i915_engine_busy_attribute {
+ struct device_attribute attr;
+ struct drm_i915_file_private *file_priv;
+ struct intel_engine_cs *engine;
+};
+
struct drm_i915_file_private {
struct drm_i915_private *dev_priv;
struct drm_file *file;
@@ -355,10 +361,12 @@ struct drm_i915_file_private {
char *name;
struct kobject *root;
+ struct kobject *busy_root;
struct {
struct device_attribute pid;
struct device_attribute name;
+ struct i915_engine_busy_attribute
busy[I915_NUM_ENGINES];
} attr;
} client;
};
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4c20545e3539..6a550fb110fb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5728,6 +5728,38 @@ show_client_pid(struct device *kdev, struct
device_attribute *attr, char *buf)
return snprintf(buf, PAGE_SIZE, "%u", file_priv->client.pid);
}
+struct busy_ctx {
+ struct intel_engine_cs *engine;
+ u64 total;
+};
+
+static int busy_add(int _id, void *p, void *data)
+{
+ struct i915_gem_context *ctx = p;
+ struct busy_ctx *bc = data;
+
+ bc->total +=
+ ktime_to_ns(intel_context_engine_get_busy_time(ctx,
+ bc->engine));
+
+ return 0;
+}
+
+static ssize_t
+show_client_busy(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+ struct i915_engine_busy_attribute *i915_attr =
+ container_of(attr, typeof(*i915_attr), attr);
+ struct drm_i915_file_private *file_priv = i915_attr->file_priv;
+ struct busy_ctx bc = { .engine = i915_attr->engine };
+
+ rcu_read_lock();
+ idr_for_each(&file_priv->context_idr, busy_add, &bc);
+ rcu_read_unlock();
+
+ return snprintf(buf, PAGE_SIZE, "%llu\n", bc.total);
+}
+
int
i915_gem_add_client(struct drm_i915_private *i915,
struct drm_i915_file_private *file_priv,
@@ -5735,8 +5767,10 @@ i915_gem_add_client(struct drm_i915_private *i915,
unsigned int serial)
{
int ret = -ENOMEM;
+ struct intel_engine_cs *engine;
struct device_attribute *attr;
- char id[32];
+ enum intel_engine_id id, id2;
+ char idstr[32];
if (!i915->clients.root)
goto err_name;
@@ -5745,8 +5779,8 @@ i915_gem_add_client(struct drm_i915_private *i915,
if (!file_priv->client.name)
goto err_name;
- snprintf(id, sizeof(id), "%u", serial);
- file_priv->client.root = kobject_create_and_add(id,
+ snprintf(idstr, sizeof(idstr), "%u", serial);
+ file_priv->client.root = kobject_create_and_add(idstr,
i915->clients.root);
if (!file_priv->client.root)
goto err_client;
@@ -5771,10 +5805,41 @@ i915_gem_add_client(struct drm_i915_private *i915,
if (ret)
goto err_attr_pid;
+ file_priv->client.busy_root =
+ kobject_create_and_add("busy", file_priv->client.root);
+ if (!file_priv->client.busy_root)
+ goto err_busy_root;
+
+ for_each_engine(engine, i915, id) {
+ file_priv->client.attr.busy[id].file_priv = file_priv;
+ file_priv->client.attr.busy[id].engine
[Intel-gfx] [RFC v4 0/7] Per-context and per-client engine busyness
From: Tvrtko Ursulin Another re-post of my earlier, now slightly updated work, to expose a DRM client hierarchy in sysfs in order to enable a top like tool: intel-gpu-top - load avg 40.80, 27.11, 1.50; 882/ 950 MHz;0% RC6; 13.26 Watts; 261903 irqs/s IMC reads: 5543 MiB/s IMC writes: 236 MiB/s ENGINE BUSYQD MI_SEMA MI_WAIT Render/3D/060.47% |███▍ | 28 0 1 0% 0% Blitter/092.70% |█▌ | 0 0 1 0% 0% Video/0 100.00% |███| 15 37 2 0% 0% Video/151.68% |█▊ | 0 0 1 0% 0% VideoEnhance/0 0.00% | | 0 0 0 0% 0% PIDNAME rcs0 bcs0 vcs0 vcs1 vecs0 21664gem_wsim |█▍ || ||█||▋|| | 21662 gem_latency | ||▎|| || || | 21662 gem_latency | || || || || | Hopefully the screen shot is self-explanatory. It shows overall GPU per-engine stats, plus per-client and per-engine busyness. In this version all review feedback has been incorporated and the context param query for DCG is back as the last patch. (DCG should only need patches 1-2 & 7). For the rest I kept the interface as sysfs in hope it would have the advantage of solving the access control one day. (Setting ownership on sysfs nodes to follow the DRM client? Still have to investigate this angle.) This time around I won't be sending the IGT patches since I am building it all on top of engine queue depths, and on top of the intel-gpu-top rewrite. Both are unmerged so sending it all just to show this would be a bit much. Tvrtko Ursulin (7): drm/i915: Use seqlock in engine stats drm/i915: Track per-context engine busyness drm/i915: Expose list of clients in sysfs drm/i915: Update client name on context create drm/i915: Expose per-engine client busyness drm/i915: Add sysfs toggle to enable per-client engine stats drm/i915: Allow clients to query own per-engine busyness drivers/gpu/drm/i915/i915_drv.h | 39 +++ drivers/gpu/drm/i915/i915_gem.c | 192 ++-- drivers/gpu/drm/i915/i915_gem_context.c | 121 +++- drivers/gpu/drm/i915/i915_gem_context.h | 8 ++ drivers/gpu/drm/i915/i915_sysfs.c | 80 + drivers/gpu/drm/i915/intel_engine_cs.c | 50 +++-- drivers/gpu/drm/i915/intel_lrc.c| 14 ++- drivers/gpu/drm/i915/intel_ringbuffer.h | 66 +-- include/uapi/drm/i915_drm.h | 21 9 files changed, 553 insertions(+), 38 deletions(-) -- 2.14.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 2/7] drm/i915: Track per-context engine busyness
From: Tvrtko Ursulin
Some customers want to know how much of the GPU time are their clients
using in order to make dynamic load balancing decisions.
With the hooks already in place which track the overall engine busyness,
we can extend that slightly to split that time between contexts.
v2: Fix accounting for tail updates.
v3: Rebase.
v4: Mark currently running contexts as active on stats enable.
v5: Include some headers to fix the build.
v6: Added fine grained lock.
v7: Convert to seqlock. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Cc: gordon.ke...@intel.com
---
drivers/gpu/drm/i915/i915_gem_context.c | 8 +
drivers/gpu/drm/i915/i915_gem_context.h | 7 +
drivers/gpu/drm/i915/intel_engine_cs.c | 31 +++
drivers/gpu/drm/i915/intel_lrc.c| 14 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 55 +
5 files changed, 104 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5cfac0255758..85627fa4565b 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -349,7 +349,9 @@ static struct i915_gem_context *
i915_gem_create_context(struct drm_i915_private *dev_priv,
struct drm_i915_file_private *file_priv)
{
+ struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
+ enum intel_engine_id id;
lockdep_assert_held(&dev_priv->drm.struct_mutex);
@@ -375,6 +377,12 @@ i915_gem_create_context(struct drm_i915_private *dev_priv,
ctx->desc_template = default_desc_template(dev_priv, ppgtt);
}
+ /* Initialize the context stats lock. */
+ for_each_engine(engine, dev_priv, id) {
+ if (intel_engine_supports_stats(engine))
+ seqlock_init(&ctx->engine[id].stats.lock);
+ }
+
trace_i915_context_create(ctx);
return ctx;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index 7854262ddfd9..159223c5fc5f 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include "i915_gem.h"
@@ -160,6 +161,12 @@ struct i915_gem_context {
u32 *lrc_reg_state;
u64 lrc_desc;
int pin_count;
+ struct {
+ seqlock_t lock;
+ bool active;
+ ktime_t start;
+ ktime_t total;
+ } stats;
} engine[I915_NUM_ENGINES];
/** ring_size: size for allocating the per-engine ring buffer */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index de61d3d1653d..e66166466d6d 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -2078,6 +2078,16 @@ int intel_enable_engine_stats(struct intel_engine_cs
*engine)
engine->stats.enabled_at = ktime_get();
+ /* Mark currently running context as active. */
+ if (port_isset(port)) {
+ struct i915_request *req = port_request(port);
+ struct intel_context *ce =
+ &req->ctx->engine[engine->id];
+
+ ce->stats.start = engine->stats.enabled_at;
+ ce->stats.active = true;
+ }
+
/* XXX submission method oblivious? */
while (num_ports-- && port_isset(port)) {
engine->stats.active++;
@@ -2151,6 +2161,27 @@ void intel_disable_engine_stats(struct intel_engine_cs
*engine)
write_sequnlock_irqrestore(&engine->stats.lock, flags);
}
+ktime_t intel_context_engine_get_busy_time(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine)
+{
+ struct intel_context *ce = &ctx->engine[engine->id];
+ unsigned int seq;
+ ktime_t total;
+
+ do {
+ seq = read_seqbegin(&ce->stats.lock);
+
+ total = ce->stats.total;
+
+ if (ce->stats.active)
+ total = ktime_add(total,
+ ktime_sub(ktime_get(),
+ ce->stats.start));
+ } while (read_seqretry(&ce->stats.lock, seq));
+
+ return total;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/mock_engine.c"
#include "selftests/intel_engine_cs.c"
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ddd14e30be6c..930fcf0b1e86 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -389,16 +389,18 @@ execlists_user_end(struct intel_engine_execlists
*execlists)
}
static inline void
-execl
[Intel-gfx] [PATCH 1/7] drm/i915: Use seqlock in engine stats
From: Tvrtko Ursulin
We can convert engine stats from a spinlock to seqlock to ensure interrupt
processing is never even a tiny bit delayed by parallel readers.
There is a smidgen bit more cost on the write lock side, and an extremely
unlikely chance that readers will have to retry a few times in face of
heavy interrupt load.Bbut it should be extremely unlikely given how
lightweight read side section is compared to the interrupt processing side,
and also compared to the rest of the code paths which can lead into it.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 19 ++-
drivers/gpu/drm/i915/intel_ringbuffer.h | 11 ++-
2 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index e4992c2e23a4..de61d3d1653d 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -306,7 +306,7 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
/* Nothing to do here, execute in order of dependencies */
engine->schedule = NULL;
- spin_lock_init(&engine->stats.lock);
+ seqlock_init(&engine->stats.lock);
ATOMIC_INIT_NOTIFIER_HEAD(&engine->context_status_notifier);
@@ -2065,7 +2065,7 @@ int intel_enable_engine_stats(struct intel_engine_cs
*engine)
return -ENODEV;
tasklet_disable(&execlists->tasklet);
- spin_lock_irqsave(&engine->stats.lock, flags);
+ write_seqlock_irqsave(&engine->stats.lock, flags);
if (unlikely(engine->stats.enabled == ~0)) {
err = -EBUSY;
@@ -2089,7 +2089,7 @@ int intel_enable_engine_stats(struct intel_engine_cs
*engine)
}
unlock:
- spin_unlock_irqrestore(&engine->stats.lock, flags);
+ write_sequnlock_irqrestore(&engine->stats.lock, flags);
tasklet_enable(&execlists->tasklet);
return err;
@@ -2118,12 +2118,13 @@ static ktime_t __intel_engine_get_busy_time(struct
intel_engine_cs *engine)
*/
ktime_t intel_engine_get_busy_time(struct intel_engine_cs *engine)
{
+ unsigned int seq;
ktime_t total;
- unsigned long flags;
- spin_lock_irqsave(&engine->stats.lock, flags);
- total = __intel_engine_get_busy_time(engine);
- spin_unlock_irqrestore(&engine->stats.lock, flags);
+ do {
+ seq = read_seqbegin(&engine->stats.lock);
+ total = __intel_engine_get_busy_time(engine);
+ } while (read_seqretry(&engine->stats.lock, seq));
return total;
}
@@ -2141,13 +2142,13 @@ void intel_disable_engine_stats(struct intel_engine_cs
*engine)
if (!intel_engine_supports_stats(engine))
return;
- spin_lock_irqsave(&engine->stats.lock, flags);
+ write_seqlock_irqsave(&engine->stats.lock, flags);
WARN_ON_ONCE(engine->stats.enabled == 0);
if (--engine->stats.enabled == 0) {
engine->stats.total = __intel_engine_get_busy_time(engine);
engine->stats.active = 0;
}
- spin_unlock_irqrestore(&engine->stats.lock, flags);
+ write_sequnlock_irqrestore(&engine->stats.lock, flags);
}
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index d50b31eb43a5..f24ea9826037 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -3,6 +3,7 @@
#define _INTEL_RINGBUFFER_H_
#include
+#include
#include "i915_gem_batch_pool.h"
#include "i915_gem_timeline.h"
@@ -610,7 +611,7 @@ struct intel_engine_cs {
/**
* @lock: Lock protecting the below fields.
*/
- spinlock_t lock;
+ seqlock_t lock;
/**
* @enabled: Reference count indicating number of listeners.
*/
@@ -1082,7 +1083,7 @@ static inline void intel_engine_context_in(struct
intel_engine_cs *engine)
if (READ_ONCE(engine->stats.enabled) == 0)
return;
- spin_lock_irqsave(&engine->stats.lock, flags);
+ write_seqlock_irqsave(&engine->stats.lock, flags);
if (engine->stats.enabled > 0) {
if (engine->stats.active++ == 0)
@@ -1090,7 +1091,7 @@ static inline void intel_engine_context_in(struct
intel_engine_cs *engine)
GEM_BUG_ON(engine->stats.active == 0);
}
- spin_unlock_irqrestore(&engine->stats.lock, flags);
+ write_sequnlock_irqrestore(&engine->stats.lock, flags);
}
static inline void intel_engine_context_out(struct intel_engine_cs *engine)
@@ -1100,7 +1101,7 @@ static inline void intel_engine_context_out(struct
intel_engine_cs *engine)
if (READ_ONCE(engine->stats.enabled) == 0)
return;
- spin_lock_irqsave(&engine->stats.lock, flags);
Re: [Intel-gfx] [RFC v4 0/7] Per-context and per-client engine busyness
Quoting Tvrtko Ursulin (2018-04-17 13:27:29) > From: Tvrtko Ursulin > > Another re-post of my earlier, now slightly updated work, to expose a DRM > client > hierarchy in sysfs in order to enable a top like tool: > > intel-gpu-top - load avg 40.80, 27.11, 1.50; 882/ 950 MHz;0% RC6; > 13.26 Watts; 261903 irqs/s > > IMC reads: 5543 MiB/s > IMC writes: 236 MiB/s > > ENGINE BUSYQD MI_SEMA MI_WAIT QD could do with more explanation, maybe like so? ENGINE BUSY E Q W MI_SEMA MI_WAIT > Render/3D/060.47% |███▍ | 28 0 1 0% 0% Render/Compute? Another visual break after QD? Render/Compute/060.47% |███▍ | 28 0 1 |0% 0% >Blitter/092.70% |█▌ | 0 0 1 0% 0% > Video/0 100.00% |███| 15 37 2 0% 0% > Video/151.68% |█▊ | 0 0 1 0% 0% > VideoEnhance/0 0.00% | | 0 0 0 0% 0% > > PIDNAME rcs0 bcs0 vcs0 vcs1 vecs0 > 21664gem_wsim |█▍ || ||█||▋|| | > 21662 gem_latency | ||▎|| || || | > 21662 gem_latency | || || || || | -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for GMBUS changes (rev3)
On Tue, 17 Apr 2018, Patchwork wrote: > == Series Details == > > Series: GMBUS changes (rev3) > URL : https://patchwork.freedesktop.org/series/41632/ > State : warning > > == Summary == > > $ dim checkpatch origin/drm-tip > 16f60217eb21 drm/i915/gmbus: Increase the Bytes per Rd/Wr Op > bcedea2a9483 drm/i915/gmbus: Enable burst read > -:28: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible > side-effects? > #28: FILE: drivers/gpu/drm/i915/i915_drv.h:2554: > +#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \ > + IS_GEMINILAKE(dev_priv) || \ > + IS_KABYLAKE(dev_priv)) > > -:42: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) > #42: FILE: drivers/gpu/drm/i915/i915_reg.h:2999: > +#define GMBUS_BYTE_CNT_OVERRIDE (1<<6) > ^ Both can be ignored. > > total: 0 errors, 0 warnings, 2 checks, 59 lines checked > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Use seqlock in engine stats
Quoting Tvrtko Ursulin (2018-04-17 13:27:30)
> From: Tvrtko Ursulin
>
> We can convert engine stats from a spinlock to seqlock to ensure interrupt
> processing is never even a tiny bit delayed by parallel readers.
>
> There is a smidgen bit more cost on the write lock side, and an extremely
> unlikely chance that readers will have to retry a few times in face of
> heavy interrupt load.Bbut it should be extremely unlikely given how
> lightweight read side section is compared to the interrupt processing side,
> and also compared to the rest of the code paths which can lead into it.
Also mention that readers are informative only, its the writers that are
doing the work/submission.
> Signed-off-by: Tvrtko Ursulin
> Suggested-by: Chris Wilson
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 19 ++-
> drivers/gpu/drm/i915/intel_ringbuffer.h | 11 ++-
> 2 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index e4992c2e23a4..de61d3d1653d 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -306,7 +306,7 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
> /* Nothing to do here, execute in order of dependencies */
> engine->schedule = NULL;
>
> - spin_lock_init(&engine->stats.lock);
> + seqlock_init(&engine->stats.lock);
>
> ATOMIC_INIT_NOTIFIER_HEAD(&engine->context_status_notifier);
>
> @@ -2065,7 +2065,7 @@ int intel_enable_engine_stats(struct intel_engine_cs
> *engine)
> return -ENODEV;
>
> tasklet_disable(&execlists->tasklet);
> - spin_lock_irqsave(&engine->stats.lock, flags);
> + write_seqlock_irqsave(&engine->stats.lock, flags);
>
> if (unlikely(engine->stats.enabled == ~0)) {
> err = -EBUSY;
> @@ -2089,7 +2089,7 @@ int intel_enable_engine_stats(struct intel_engine_cs
> *engine)
> }
>
> unlock:
> - spin_unlock_irqrestore(&engine->stats.lock, flags);
> + write_sequnlock_irqrestore(&engine->stats.lock, flags);
> tasklet_enable(&execlists->tasklet);
>
> return err;
> @@ -2118,12 +2118,13 @@ static ktime_t __intel_engine_get_busy_time(struct
> intel_engine_cs *engine)
> */
> ktime_t intel_engine_get_busy_time(struct intel_engine_cs *engine)
> {
> + unsigned int seq;
> ktime_t total;
> - unsigned long flags;
>
> - spin_lock_irqsave(&engine->stats.lock, flags);
> - total = __intel_engine_get_busy_time(engine);
> - spin_unlock_irqrestore(&engine->stats.lock, flags);
> + do {
> + seq = read_seqbegin(&engine->stats.lock);
> + total = __intel_engine_get_busy_time(engine);
> + } while (read_seqretry(&engine->stats.lock, seq));
>
> return total;
> }
> @@ -2141,13 +2142,13 @@ void intel_disable_engine_stats(struct
> intel_engine_cs *engine)
> if (!intel_engine_supports_stats(engine))
> return;
>
> - spin_lock_irqsave(&engine->stats.lock, flags);
> + write_seqlock_irqsave(&engine->stats.lock, flags);
> WARN_ON_ONCE(engine->stats.enabled == 0);
> if (--engine->stats.enabled == 0) {
> engine->stats.total = __intel_engine_get_busy_time(engine);
> engine->stats.active = 0;
> }
> - spin_unlock_irqrestore(&engine->stats.lock, flags);
> + write_sequnlock_irqrestore(&engine->stats.lock, flags);
> }
>
> #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index d50b31eb43a5..f24ea9826037 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -3,6 +3,7 @@
> #define _INTEL_RINGBUFFER_H_
>
> #include
> +#include
>
> #include "i915_gem_batch_pool.h"
> #include "i915_gem_timeline.h"
> @@ -610,7 +611,7 @@ struct intel_engine_cs {
> /**
> * @lock: Lock protecting the below fields.
> */
> - spinlock_t lock;
> + seqlock_t lock;
> /**
> * @enabled: Reference count indicating number of listeners.
> */
> @@ -1082,7 +1083,7 @@ static inline void intel_engine_context_in(struct
> intel_engine_cs *engine)
> if (READ_ONCE(engine->stats.enabled) == 0)
> return;
>
> - spin_lock_irqsave(&engine->stats.lock, flags);
> + write_seqlock_irqsave(&engine->stats.lock, flags);
>
> if (engine->stats.enabled > 0) {
> if (engine->stats.active++ == 0)
> @@ -1090,7 +1091,7 @@ static inline void intel_engine_context_in(struct
> intel_engine_cs *engine)
> GEM_BUG_ON(engine->stats.active == 0);
> }
>
> - spin_unlock_irqrestore(&engine-
Re: [Intel-gfx] [igt-dev] [RFC 2/7] drm/i915: Track per-context engine busyness
Quoting Tvrtko Ursulin (2018-04-17 13:27:31)
> From: Tvrtko Ursulin
>
> Some customers want to know how much of the GPU time are their clients
> using in order to make dynamic load balancing decisions.
>
> With the hooks already in place which track the overall engine busyness,
> we can extend that slightly to split that time between contexts.
>
> v2: Fix accounting for tail updates.
> v3: Rebase.
> v4: Mark currently running contexts as active on stats enable.
> v5: Include some headers to fix the build.
> v6: Added fine grained lock.
> v7: Convert to seqlock. (Chris Wilson)
>
> Signed-off-by: Tvrtko Ursulin
> Cc: gordon.ke...@intel.com
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 8 +
> drivers/gpu/drm/i915/i915_gem_context.h | 7 +
> drivers/gpu/drm/i915/intel_engine_cs.c | 31 +++
> drivers/gpu/drm/i915/intel_lrc.c| 14 ++---
> drivers/gpu/drm/i915/intel_ringbuffer.h | 55
> +
> 5 files changed, 104 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 5cfac0255758..85627fa4565b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -349,7 +349,9 @@ static struct i915_gem_context *
> i915_gem_create_context(struct drm_i915_private *dev_priv,
> struct drm_i915_file_private *file_priv)
> {
> + struct intel_engine_cs *engine;
> struct i915_gem_context *ctx;
> + enum intel_engine_id id;
>
> lockdep_assert_held(&dev_priv->drm.struct_mutex);
>
> @@ -375,6 +377,12 @@ i915_gem_create_context(struct drm_i915_private
> *dev_priv,
> ctx->desc_template = default_desc_template(dev_priv, ppgtt);
> }
>
> + /* Initialize the context stats lock. */
> + for_each_engine(engine, dev_priv, id) {
> + if (intel_engine_supports_stats(engine))
> + seqlock_init(&ctx->engine[id].stats.lock);
Keep it simple, always init the substruct.
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index de61d3d1653d..e66166466d6d 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -2078,6 +2078,16 @@ int intel_enable_engine_stats(struct intel_engine_cs
> *engine)
>
> engine->stats.enabled_at = ktime_get();
>
> + /* Mark currently running context as active. */
> + if (port_isset(port)) {
> + struct i915_request *req = port_request(port);
> + struct intel_context *ce =
> + &req->ctx->engine[engine->id];
Bleh, better break out the
struct i915_request {
struct intel_context *ce;
}
patch, as this is getting repetitive ;)
> +
> + ce->stats.start = engine->stats.enabled_at;
> + ce->stats.active = true;
> + }
> +
> /* XXX submission method oblivious? */
> while (num_ports-- && port_isset(port)) {
> engine->stats.active++;
> @@ -2151,6 +2161,27 @@ void intel_disable_engine_stats(struct intel_engine_cs
> *engine)
> write_sequnlock_irqrestore(&engine->stats.lock, flags);
> }
>
> +ktime_t intel_context_engine_get_busy_time(struct i915_gem_context *ctx,
> + struct intel_engine_cs *engine)
> +{
> + struct intel_context *ce = &ctx->engine[engine->id];
> + unsigned int seq;
> + ktime_t total;
> +
> + do {
> + seq = read_seqbegin(&ce->stats.lock);
> +
> + total = ce->stats.total;
> +
> + if (ce->stats.active)
> + total = ktime_add(total,
> + ktime_sub(ktime_get(),
> + ce->stats.start));
> + } while (read_seqretry(&ce->stats.lock, seq));
> +
> + return total;
> +}
> +
> #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> #include "selftests/mock_engine.c"
> #include "selftests/intel_engine_cs.c"
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index ddd14e30be6c..930fcf0b1e86 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -389,16 +389,18 @@ execlists_user_end(struct intel_engine_execlists
> *execlists)
> }
>
> static inline void
> -execlists_context_schedule_in(struct i915_request *rq)
> +execlists_context_schedule_in(struct i915_request *rq, unsigned int port)
> {
> execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
> - intel_engine_context_in(rq->engine);
> + intel_engine_context_in(rq->engine,
> + &rq->ctx->engine[rq->engine->id],
> +
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Per-context and per-client engine busyness (rev5)
== Series Details == Series: Per-context and per-client engine busyness (rev5) URL : https://patchwork.freedesktop.org/series/32645/ State : warning == Summary == $ dim checkpatch origin/drm-tip a367a6c9fd96 drm/i915: Use seqlock in engine stats 557e1f39ef83 drm/i915: Track per-context engine busyness 2faa04d0e6db drm/i915: Expose list of clients in sysfs -:93: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #93: FILE: drivers/gpu/drm/i915/i915_gem.c:5735: +i915_gem_add_client(struct drm_i915_private *i915, + struct drm_i915_file_private *file_priv, total: 0 errors, 0 warnings, 1 checks, 197 lines checked 0aa560d499c9 drm/i915: Update client name on context create -:24: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #24: FILE: drivers/gpu/drm/i915/i915_drv.h:3200: +i915_gem_add_client(struct drm_i915_private *i915, + struct drm_i915_file_private *file_priv, total: 0 errors, 0 warnings, 1 checks, 66 lines checked 83be78f1 drm/i915: Expose per-engine client busyness -:22: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #22: neverball[ 6011]: rcs0: 41.01% bcs0: 0.00% vcs0: 0.00% vecs0: 0.00% -:55: ERROR:CODE_INDENT: code indent should use tabs where possible #55: FILE: drivers/gpu/drm/i915/i915_drv.h:364: + ^I^Istruct kobject *busy_root;$ -:55: WARNING:SPACE_BEFORE_TAB: please, no space before tabs #55: FILE: drivers/gpu/drm/i915/i915_drv.h:364: + ^I^Istruct kobject *busy_root;$ -:55: WARNING:LEADING_SPACE: please, no spaces at the start of a line #55: FILE: drivers/gpu/drm/i915/i915_drv.h:364: + ^I^Istruct kobject *busy_root;$ -:148: ERROR:CODE_INDENT: code indent should use tabs where possible #148: FILE: drivers/gpu/drm/i915/i915_gem.c:5824: +^I^I^I^I(struct attribute *)attr);$ -:148: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #148: FILE: drivers/gpu/drm/i915/i915_gem.c:5824: + ret = sysfs_create_file(file_priv->client.busy_root, + (struct attribute *)attr); total: 2 errors, 3 warnings, 1 checks, 144 lines checked 163d3d9b5151 drm/i915: Add sysfs toggle to enable per-client engine stats 3f6953ea6afe drm/i915: Allow clients to query own per-engine busyness ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Per-context and per-client engine busyness (rev5)
== Series Details == Series: Per-context and per-client engine busyness (rev5) URL : https://patchwork.freedesktop.org/series/32645/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Use seqlock in engine stats Okay! Commit: drm/i915: Track per-context engine busyness Okay! Commit: drm/i915: Expose list of clients in sysfs -drivers/gpu/drm/i915/selftests/../i915_drv.h:2207:33: warning: constant 0xea00 is so big it is unsigned long -drivers/gpu/drm/i915/selftests/../i915_drv.h:3655:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:2226:33: warning: constant 0xea00 is so big it is unsigned long +drivers/gpu/drm/i915/selftests/../i915_drv.h:3674:16: warning: expression using sizeof(void) Commit: drm/i915: Update client name on context create -drivers/gpu/drm/i915/selftests/../i915_drv.h:3674:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3682:16: warning: expression using sizeof(void) Commit: drm/i915: Expose per-engine client busyness -drivers/gpu/drm/i915/selftests/../i915_drv.h:2226:33: warning: constant 0xea00 is so big it is unsigned long -drivers/gpu/drm/i915/selftests/../i915_drv.h:3682:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:2234:33: warning: constant 0xea00 is so big it is unsigned long +drivers/gpu/drm/i915/selftests/../i915_drv.h:3690:16: warning: expression using sizeof(void) Commit: drm/i915: Add sysfs toggle to enable per-client engine stats -drivers/gpu/drm/i915/selftests/../i915_drv.h:2234:33: warning: constant 0xea00 is so big it is unsigned long -drivers/gpu/drm/i915/selftests/../i915_drv.h:3690:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:2238:33: warning: constant 0xea00 is so big it is unsigned long +drivers/gpu/drm/i915/selftests/../i915_drv.h:3694:16: warning: expression using sizeof(void) Commit: drm/i915: Allow clients to query own per-engine busyness +drivers/gpu/drm/i915/i915_gem_context.c:767:14:expected void const volatile [noderef] * +drivers/gpu/drm/i915/i915_gem_context.c:767:14:got unsigned long long [unsigned] [usertype] value +drivers/gpu/drm/i915/i915_gem_context.c:767:14: warning: incorrect type in argument 1 (different base types) +drivers/gpu/drm/i915/i915_gem_context.c:778:34:expected void *to +drivers/gpu/drm/i915/i915_gem_context.c:778:34:got struct drm_i915_context_engine_busy [noderef] *[assigned] busy_user +drivers/gpu/drm/i915/i915_gem_context.c:778:34: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/i915/i915_gem_context.c:778:46:expected void const [noderef] *from +drivers/gpu/drm/i915/i915_gem_context.c:778:46:got struct drm_i915_context_engine_busy * +drivers/gpu/drm/i915/i915_gem_context.c:778:46: warning: incorrect type in argument 2 (different address spaces) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for GMBUS changes (rev3)
== Series Details == Series: GMBUS changes (rev3) URL : https://patchwork.freedesktop.org/series/41632/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4059_full -> Patchwork_8703_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8703_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8703_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41632/revisions/3/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8703_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-vebox: shard-kbl: PASS -> SKIP +1 igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-blt: shard-snb: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_8703_full that come from known issues: === IGT changes === Issues hit igt@gem_workarounds@suspend-resume-context: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_draw_crc@draw-method-rgb565-mmap-wc-xtiled: shard-kbl: PASS -> DMESG-WARN (fdo#103558, fdo#105602) +2 igt@kms_flip@2x-dpms-vs-vblank-race: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip@plain-flip-fb-recreate: shard-hsw: PASS -> FAIL (fdo#100368) Possible fixes igt@kms_flip@2x-flip-vs-expired-vblank: shard-hsw: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-apl: FAIL (fdo#102887, fdo#105363) -> PASS igt@kms_flip@modeset-vs-vblank-race: shard-hsw: FAIL (fdo#103060) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 == Participating hosts (6 -> 4) == Missing(2): shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4059 -> Patchwork_8703 CI_DRM_4059: c1645edc253f2b52a8c94565a75b479a6782e75f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4435: ddbe5a4d8bb1780ecf07f72e815062d3bce8ff71 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8703: bcedea2a9483baceeda55a73119ea1c49d4a1a0d @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4435: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8703/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Per-context and per-client engine busyness (rev5)
== Series Details == Series: Per-context and per-client engine busyness (rev5) URL : https://patchwork.freedesktop.org/series/32645/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4059 -> Patchwork_8706 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_8706 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8706, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/32645/revisions/5/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8706: === IGT changes === Possible regressions igt@gem_exec_suspend@basic-s4-devices: fi-skl-guc: PASS -> FAIL == Known issues == Here are the changes found in Patchwork_8706 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) igt@pm_rpm@basic-rte: fi-glk-1: PASS -> INCOMPLETE (fdo#103359, k.org#198133) Possible fixes igt@gem_exec_suspend@basic-s3: fi-ivb-3520m: DMESG-WARN (fdo#106084) -> PASS +1 igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: FAIL (fdo#102575) -> PASS igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: fi-elk-e7500: INCOMPLETE (fdo#103989) -> PASS fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (36 -> 33) == Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4059 -> Patchwork_8706 CI_DRM_4059: c1645edc253f2b52a8c94565a75b479a6782e75f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4435: ddbe5a4d8bb1780ecf07f72e815062d3bce8ff71 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8706: 3f6953ea6afeb5d0a630313a1284dceb6bdd0676 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4435: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Linux commits == 3f6953ea6afe drm/i915: Allow clients to query own per-engine busyness 163d3d9b5151 drm/i915: Add sysfs toggle to enable per-client engine stats 83be78f1 drm/i915: Expose per-engine client busyness 0aa560d499c9 drm/i915: Update client name on context create 2faa04d0e6db drm/i915: Expose list of clients in sysfs 557e1f39ef83 drm/i915: Track per-context engine busyness a367a6c9fd96 drm/i915: Use seqlock in engine stats == Kernel 32bit build == Warning: Kernel 32bit buildtest failed: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8706/build_32bit_failure.log == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8706/issues.html ___ 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: Remove skl dc6 enable/disable functions
== Series Details == Series: drm/i915: Remove skl dc6 enable/disable functions URL : https://patchwork.freedesktop.org/series/41803/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4059_full -> Patchwork_8704_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8704_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8704_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41803/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8704_full: === IGT changes === Warnings igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8704_full that come from known issues: === IGT changes === Issues hit igt@gem_workarounds@suspend-resume-context: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_flip@2x-modeset-vs-vblank-race: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip@2x-plain-flip-fb-recreate: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_flip@2x-flip-vs-expired-vblank: shard-hsw: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-apl: FAIL (fdo#102887, fdo#105363) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (6 -> 4) == Missing(2): shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4059 -> Patchwork_8704 CI_DRM_4059: c1645edc253f2b52a8c94565a75b479a6782e75f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4435: ddbe5a4d8bb1780ecf07f72e815062d3bce8ff71 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8704: cadfa04c6ef9b6d841f5115a415a34cb82f8af06 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4435: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8704/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 6/7] drm/i915: Add sysfs toggle to enable per-client engine stats
Quoting Tvrtko Ursulin (2018-04-17 13:27:35) > From: Tvrtko Ursulin > > By default we are not collecting any per-engine and per-context > statistcs. > > Add a new sysfs toggle to enable this facility: > > $ echo 1 >/sys/class/drm/card0/clients/enable_stats I have to ask, what would be the intersection with cgroup here? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC/CI PATCH] drm/i915/crc: make locking and source check more robust
It seems to me intel_pipe_crc source and skipped should be checked and
modified atomically. Skipped could concievably be changed when source
has already been disabled. Alas I can't think of a real world scenario
where this could impact CRCs in IGT.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_irq.c | 8 +++-
drivers/gpu/drm/i915/intel_pipe_crc.c | 5 -
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b03d18561b55..03fd1ecaf16a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1687,7 +1687,13 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
int head, tail;
spin_lock(&pipe_crc->lock);
- if (pipe_crc->source && !crtc->base.crc.opened) {
+ if (!pipe_crc->source) {
+ spin_unlock(&pipe_crc->lock);
+ DRM_DEBUG_KMS("ignoring crc irq while disabling\n");
+ return;
+ }
+
+ if (!crtc->base.crc.opened) {
if (!pipe_crc->entries) {
spin_unlock(&pipe_crc->lock);
DRM_DEBUG_KMS("spurious interrupt\n");
diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
b/drivers/gpu/drm/i915/intel_pipe_crc.c
index 4f367c16e9e5..94a6d3178a2d 100644
--- a/drivers/gpu/drm/i915/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
@@ -940,7 +940,11 @@ int intel_crtc_set_crc_source(struct drm_crtc *crtc, const
char *source_name,
if (ret != 0)
goto out;
+ spin_lock(&pipe_crc->lock);
pipe_crc->source = source;
+ pipe_crc->skipped = 0;
+ spin_unlock(&pipe_crc->lock);
+
I915_WRITE(PIPE_CRC_CTL(crtc->index), val);
POSTING_READ(PIPE_CRC_CTL(crtc->index));
@@ -954,7 +958,6 @@ int intel_crtc_set_crc_source(struct drm_crtc *crtc, const
char *source_name,
hsw_pipe_A_crc_wa(dev_priv, false);
}
- pipe_crc->skipped = 0;
*values_cnt = 5;
out:
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Call i915_perf_fini() on init_hw error unwind
Quoting Michal Wajdeczko (2018-04-14 16:59:13) > On Sat, 14 Apr 2018 11:12:33 +0200, Chris Wilson > wrote: > > > We have to cleanup after i915_perf_init(), even on the error path, as it > > passes a pointer into the module to the sysfs core. If we fail to > > unregister the sysctl table, we leave a dangling pointer which then may > > explode anytime later the sysctl table, we leave a dangling pointer > > which then may explode anytime later. > > no need to repeat, we're smart enough to get it after first time ;) Smarter than me for sure, I didn't even notice I hit '.' too late. Fixed up the commitmsg and old comment style, and pushed (and forgot to say I pushed). Thanks all for the review, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.
I have to ask, if this is all just to work around iowait triggering high frequencies for GPU bound applications, does it all just boil down to i915 incorrectly using iowait. Does this patch set perform better than diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 9ca9c24b4421..7e7c95411bcd 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1267,7 +1267,7 @@ long i915_request_wait(struct i915_request *rq, goto complete; } - timeout = io_schedule_timeout(timeout); + timeout = schedule_timeout(timeout); } while (1); GEM_BUG_ON(!intel_wait_has_seqno(&wait)); Quite clearly the general framework could prove useful in a broader range of situations, but does the above suffice? (And can be backported to stable.) -Chris ___ 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: Add documentation to gen9_set_dc_state()
== Series Details == Series: drm/i915: Add documentation to gen9_set_dc_state() URL : https://patchwork.freedesktop.org/series/41811/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4059_full -> Patchwork_8705_full = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/41811/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_8705_full that come from known issues: === IGT changes === Issues hit igt@gem_workarounds@suspend-resume-context: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-hsw: PASS -> FAIL (fdo#102887) igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_flip@2x-flip-vs-expired-vblank: shard-hsw: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-apl: FAIL (fdo#102887, fdo#105363) -> PASS igt@kms_flip@modeset-vs-vblank-race: shard-hsw: FAIL (fdo#103060) -> PASS fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (6 -> 4) == Missing(2): shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4059 -> Patchwork_8705 CI_DRM_4059: c1645edc253f2b52a8c94565a75b479a6782e75f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4435: ddbe5a4d8bb1780ecf07f72e815062d3bce8ff71 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8705: 0aa28a05f4e92e6d5d1dd2824b76b515782989a1 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4435: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8705/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake
Quoting Jani Nikula (2018-04-17 12:02:52) > On Mon, 16 Apr 2018, "Srivatsa, Anusha" wrote: > >>-Original Message- > >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >>Sent: Wednesday, April 11, 2018 5:27 AM > >>To: Ian W MORRISON > >>Cc: Vivi, Rodrigo ; Srivatsa, Anusha > >>; Wajdeczko, Michal > >>; Greg KH ; > >>airl...@linux.ie; joonas.lahti...@linux.intel.com; > >>linux-ker...@vger.kernel.org; > >>sta...@vger.kernel.org; intel-gfx@lists.freedesktop.org; dri- > >>de...@lists.freedesktop.org > >>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for > >>Geminilake > >> > >>On Wed, 11 Apr 2018, Ian W MORRISON wrote: > >>> > >>> > > NAK on indiscriminate Cc: stable. There are zero guarantees that > older kernels will work with whatever firmware you throw at them. > > >>> > >>> I included 'Cc: stable' so the patch would get added to the v4.16 and > >>> v4.15 kernels which I have tested with the patch. I found that earlier > >>> kernels didn't support the 'linux-firmware' package required to get > >>> wifi working on Intel's new Gemini Lake NUC. > >> > >>You realize that this patch should have nothing to do with wifi? > >> > >>Rodrigo, Anusha, if you think Cc: stable is appropriate, please indicate > >>the specific > >>versions of stable it is appropriate for. > > > > Hi Jani, > > > > The stable kernel version is 4.12 and beyond. > > It is appropriate to add the CC: stable in my opinion > > Who tested the firmware with v4.12 and later? We only have the CI > results against *current* drm-tip. We don't even know about v4.16. > > I'm not going to ack and take responsibility for the stable backports > unless someone actually comes forward with credible Tested-bys. And even then, some distros will be surprised of the new MODULE_FIRMWARE and will need to update the linux-firmware package, too. Regards, Joonas > > BR, > Jani. > > > > > > Anusha > >>BR, > >>Jani. > >> > >>> > > PS. How is this a "RESEND"? I haven't seen this before. > > >>> > >>> It is a 'RESEND' for that very reason. I initially sent the patch to > >>> the same people as a similar patch > >>> (https://patchwork.kernel.org/patch/10143637/) however after realising > >>> this omitted required addresses I added them and resent the patch. > >>> > >>> Best regards, > >>> Ian > >> > >>-- > >>Jani Nikula, Intel Open Source Technology Center > > -- > Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/3] drm/i915: Move the priotree struct to its own headers
Over time the priotree has grown from a sorted list to a more
complicated structure for propagating constraints along the dependency
chain to try and resolve priority inversion. Start to segregate this
information from the rest of the request/fence tracking.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.h | 39 +---
drivers/gpu/drm/i915/i915_scheduler.h | 52 +++
2 files changed, 53 insertions(+), 38 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_scheduler.h
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 7d6eb82eeb91..e6f7c5f4ec7f 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -28,6 +28,7 @@
#include
#include "i915_gem.h"
+#include "i915_scheduler.h"
#include "i915_sw_fence.h"
#include
@@ -48,44 +49,6 @@ struct intel_signal_node {
struct list_head link;
};
-struct i915_dependency {
- struct i915_priotree *signaler;
- struct list_head signal_link;
- struct list_head wait_link;
- struct list_head dfs_link;
- unsigned long flags;
-#define I915_DEPENDENCY_ALLOC BIT(0)
-};
-
-/*
- * "People assume that time is a strict progression of cause to effect, but
- * actually, from a nonlinear, non-subjective viewpoint, it's more like a big
- * ball of wibbly-wobbly, timey-wimey ... stuff." -The Doctor, 2015
- *
- * Requests exist in a complex web of interdependencies. Each request
- * has to wait for some other request to complete before it is ready to be run
- * (e.g. we have to wait until the pixels have been rendering into a texture
- * before we can copy from it). We track the readiness of a request in terms
- * of fences, but we also need to keep the dependency tree for the lifetime
- * of the request (beyond the life of an individual fence). We use the tree
- * at various points to reorder the requests whilst keeping the requests
- * in order with respect to their various dependencies.
- */
-struct i915_priotree {
- struct list_head signalers_list; /* those before us, we depend upon */
- struct list_head waiters_list; /* those after us, they depend upon us */
- struct list_head link;
- int priority;
-};
-
-enum {
- I915_PRIORITY_MIN = I915_CONTEXT_MIN_USER_PRIORITY - 1,
- I915_PRIORITY_NORMAL = I915_CONTEXT_DEFAULT_PRIORITY,
- I915_PRIORITY_MAX = I915_CONTEXT_MAX_USER_PRIORITY + 1,
-
- I915_PRIORITY_INVALID = INT_MIN
-};
-
struct i915_capture_list {
struct i915_capture_list *next;
struct i915_vma *vma;
diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
b/drivers/gpu/drm/i915/i915_scheduler.h
new file mode 100644
index ..bd588f06ce23
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_scheduler.h
@@ -0,0 +1,52 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#ifndef _I915_SCHEDULER_H_
+#define _I915_SCHEDULER_H_
+
+#include
+
+#include
+
+enum {
+ I915_PRIORITY_MIN = I915_CONTEXT_MIN_USER_PRIORITY - 1,
+ I915_PRIORITY_NORMAL = I915_CONTEXT_DEFAULT_PRIORITY,
+ I915_PRIORITY_MAX = I915_CONTEXT_MAX_USER_PRIORITY + 1,
+
+ I915_PRIORITY_INVALID = INT_MIN
+};
+
+/*
+ * "People assume that time is a strict progression of cause to effect, but
+ * actually, from a nonlinear, non-subjective viewpoint, it's more like a big
+ * ball of wibbly-wobbly, timey-wimey ... stuff." -The Doctor, 2015
+ *
+ * Requests exist in a complex web of interdependencies. Each request
+ * has to wait for some other request to complete before it is ready to be run
+ * (e.g. we have to wait until the pixels have been rendering into a texture
+ * before we can copy from it). We track the readiness of a request in terms
+ * of fences, but we also need to keep the dependency tree for the lifetime
+ * of the request (beyond the life of an individual fence). We use the tree
+ * at various points to reorder the requests whilst keeping the requests
+ * in order with respect to their various dependencies.
+ */
+struct i915_priotree {
+ struct list_head signalers_list; /* those before us, we depend upon */
+ struct list_head waiters_list; /* those after us, they depend upon us */
+ struct list_head link;
+ int priority;
+};
+
+struct i915_dependency {
+ struct i915_priotree *signaler;
+ struct list_head signal_link;
+ struct list_head wait_link;
+ struct list_head dfs_link;
+ unsigned long flags;
+#define I915_DEPENDENCY_ALLOC BIT(0)
+};
+
+#endif /* _I915_SCHEDULER_H_ */
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm/i915: Rename priotree to sched
Having moved the priotree struct into i915_scheduler.h, identify it as
the scheduling element and rebrand into i915_sched. This becomes more
useful as we start attaching more information we require to propagate
through the scheduler.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/i915_request.c | 44 ++--
drivers/gpu/drm/i915/i915_request.h | 6 +-
drivers/gpu/drm/i915/i915_scheduler.h | 4 +-
drivers/gpu/drm/i915/intel_engine_cs.c | 4 +-
drivers/gpu/drm/i915/intel_guc_submission.c | 8 +--
drivers/gpu/drm/i915/intel_lrc.c| 77 +++--
7 files changed, 73 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index effaf982b19b..6b5b9b3ded02 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1278,7 +1278,7 @@ static void record_request(struct i915_request *request,
struct drm_i915_error_request *erq)
{
erq->context = request->ctx->hw_id;
- erq->priority = request->priotree.priority;
+ erq->priority = request->sched.priority;
erq->ban_score = atomic_read(&request->ctx->ban_score);
erq->seqno = request->global_seqno;
erq->jiffies = request->emitted_jiffies;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 9ca9c24b4421..0939c120b82c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -125,10 +125,10 @@ i915_dependency_free(struct drm_i915_private *i915,
}
static void
-__i915_priotree_add_dependency(struct i915_priotree *pt,
- struct i915_priotree *signal,
- struct i915_dependency *dep,
- unsigned long flags)
+__i915_sched_add_dependency(struct i915_sched *pt,
+ struct i915_sched *signal,
+ struct i915_dependency *dep,
+ unsigned long flags)
{
INIT_LIST_HEAD(&dep->dfs_link);
list_add(&dep->wait_link, &signal->waiters_list);
@@ -138,9 +138,9 @@ __i915_priotree_add_dependency(struct i915_priotree *pt,
}
static int
-i915_priotree_add_dependency(struct drm_i915_private *i915,
-struct i915_priotree *pt,
-struct i915_priotree *signal)
+i915_sched_add_dependency(struct drm_i915_private *i915,
+ struct i915_sched *pt,
+ struct i915_sched *signal)
{
struct i915_dependency *dep;
@@ -148,12 +148,12 @@ i915_priotree_add_dependency(struct drm_i915_private
*i915,
if (!dep)
return -ENOMEM;
- __i915_priotree_add_dependency(pt, signal, dep, I915_DEPENDENCY_ALLOC);
+ __i915_sched_add_dependency(pt, signal, dep, I915_DEPENDENCY_ALLOC);
return 0;
}
static void
-i915_priotree_fini(struct drm_i915_private *i915, struct i915_priotree *pt)
+i915_sched_fini(struct drm_i915_private *i915, struct i915_sched *pt)
{
struct i915_dependency *dep, *next;
@@ -166,7 +166,7 @@ i915_priotree_fini(struct drm_i915_private *i915, struct
i915_priotree *pt)
* so we may be called out-of-order.
*/
list_for_each_entry_safe(dep, next, &pt->signalers_list, signal_link) {
- GEM_BUG_ON(!i915_priotree_signaled(dep->signaler));
+ GEM_BUG_ON(!i915_sched_signaled(dep->signaler));
GEM_BUG_ON(!list_empty(&dep->dfs_link));
list_del(&dep->wait_link);
@@ -186,7 +186,7 @@ i915_priotree_fini(struct drm_i915_private *i915, struct
i915_priotree *pt)
}
static void
-i915_priotree_init(struct i915_priotree *pt)
+i915_sched_init(struct i915_sched *pt)
{
INIT_LIST_HEAD(&pt->signalers_list);
INIT_LIST_HEAD(&pt->waiters_list);
@@ -422,7 +422,7 @@ static void i915_request_retire(struct i915_request
*request)
}
spin_unlock_irq(&request->lock);
- i915_priotree_fini(request->i915, &request->priotree);
+ i915_sched_fini(request->i915, &request->sched);
i915_request_put(request);
}
@@ -725,7 +725,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
i915_sw_fence_init(&i915_request_get(rq)->submit, submit_notify);
init_waitqueue_head(&rq->execute);
- i915_priotree_init(&rq->priotree);
+ i915_sched_init(&rq->sched);
INIT_LIST_HEAD(&rq->active_list);
rq->i915 = i915;
@@ -777,8 +777,8 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
/* Make sure we didn't add ourselves to external state before freeing */
GEM_BUG_ON(!list_empty(&rq->active_list));
- GEM_BUG_ON(!list_empty(&rq->priotree.signalers_list));
- GEM_BUG_ON(!list_empty(&rq->pri
[Intel-gfx] [PATCH] drm/i915/selftests: Don't use -ETIMEDOUT from inside a test
-ETIMEDOUT is reserved in the selftests for use by igt_timeout, and the
errno is magically handled by the test runner to break from inside the
test loop without propagating back to userspace as a failure. So convert
the -ETIMEDOUT from wait_var_event_timeout() into another errno.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
index 46580026c7fc..0a12e81a45dd 100644
--- a/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
@@ -416,6 +416,7 @@ static int igt_wakeup(void *arg)
if (err) {
pr_err("Timed out waiting for %d remaining waiters\n",
atomic_read(&done));
+ err = -ENXIO; /* -ETIMEDOUT is reserved */
break;
}
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] drm/i915: Pack params to engine->schedule() into a struct
Today we only want to pass along the priority to engine->schedule(), but
in the future we want to have much more control over the various aspects
of the GPU during a context's execution, for example controlling the
frequency allowed. As we need an ever growing number of parameters for
scheduling, move those into a struct for convenience.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/scheduler.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/i915_gem.c | 18 +
drivers/gpu/drm/i915/i915_gem_context.c | 8
drivers/gpu/drm/i915/i915_gem_context.h | 13 +---
drivers/gpu/drm/i915/i915_gpu_error.c | 8
drivers/gpu/drm/i915/i915_gpu_error.h | 5 +++--
drivers/gpu/drm/i915/i915_request.c | 4 ++--
drivers/gpu/drm/i915/i915_request.h | 1 +
drivers/gpu/drm/i915/i915_scheduler.h | 17 +++-
drivers/gpu/drm/i915/intel_display.c | 4 +++-
drivers/gpu/drm/i915/intel_engine_cs.c| 18 ++---
drivers/gpu/drm/i915/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c | 20 ++-
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +++-
.../gpu/drm/i915/selftests/intel_hangcheck.c | 4 ++--
drivers/gpu/drm/i915/selftests/intel_lrc.c| 8 +---
17 files changed, 84 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 638abe84857c..f3d21849b0cb 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -1135,7 +1135,7 @@ int intel_vgpu_setup_submission(struct intel_vgpu *vgpu)
return PTR_ERR(s->shadow_ctx);
if (HAS_LOGICAL_RING_PREEMPTION(vgpu->gvt->dev_priv))
- s->shadow_ctx->priority = INT_MAX;
+ s->shadow_ctx->sched.priority = INT_MAX;
bitmap_zero(s->shadow_ctx_desc_updated, I915_NUM_ENGINES);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8e8667d9b084..028691108125 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -75,6 +75,7 @@
#include "i915_gem_timeline.h"
#include "i915_gpu_error.h"
#include "i915_request.h"
+#include "i915_scheduler.h"
#include "i915_vma.h"
#include "intel_gvt.h"
@@ -3158,7 +3159,7 @@ int i915_gem_object_wait(struct drm_i915_gem_object *obj,
struct intel_rps_client *rps);
int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
unsigned int flags,
- int priority);
+ const struct i915_sched_attr *attr);
#define I915_PRIORITY_DISPLAY I915_PRIORITY_MAX
int __must_check
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4c9d2a6f7d28..795ca83aed7a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -564,7 +564,8 @@ i915_gem_object_wait_reservation(struct reservation_object
*resv,
return timeout;
}
-static void __fence_set_priority(struct dma_fence *fence, int prio)
+static void __fence_set_priority(struct dma_fence *fence,
+const struct i915_sched_attr *attr)
{
struct i915_request *rq;
struct intel_engine_cs *engine;
@@ -577,11 +578,12 @@ static void __fence_set_priority(struct dma_fence *fence,
int prio)
rcu_read_lock();
if (engine->schedule)
- engine->schedule(rq, prio);
+ engine->schedule(rq, attr);
rcu_read_unlock();
}
-static void fence_set_priority(struct dma_fence *fence, int prio)
+static void fence_set_priority(struct dma_fence *fence,
+ const struct i915_sched_attr *attr)
{
/* Recurse once into a fence-array */
if (dma_fence_is_array(fence)) {
@@ -589,16 +591,16 @@ static void fence_set_priority(struct dma_fence *fence,
int prio)
int i;
for (i = 0; i < array->num_fences; i++)
- __fence_set_priority(array->fences[i], prio);
+ __fence_set_priority(array->fences[i], attr);
} else {
- __fence_set_priority(fence, prio);
+ __fence_set_priority(fence, attr);
}
}
int
i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
unsigned int flags,
- int prio)
+ const struct i915_sched_attr *attr)
{
struct dma_fence *excl;
@@ -613,7 +615,7 @@ i915_gem_object_wait_priority(struct drm_i915_gem_object
*obj,
return ret;
for (i = 0; i < count; i++) {
- fence_set_priority(shared[i], prio);
+ fence_set_priority(shared[i], att
Re: [Intel-gfx] [Freedreno] [PATCH 01/10] include: Move ascii85 functions from i915 to linux/ascii85.h
On Mon, Apr 16, 2018 at 10:52:59AM -0700, Eric Anholt wrote: > Chris Wilson writes: > > > Quoting Jordan Crouse (2018-04-05 23:06:53) > >> On Thu, Apr 05, 2018 at 04:00:47PM -0600, Jordan Crouse wrote: > >> > The i915 DRM driver very cleverly used ascii85 encoding for their > >> > GPU state file. Move the encode functions to a general header file to > >> > support other drivers that might be interested in the same > >> > functionality. > >> > >> In a previous version of this patch, Chris asked what tree I wanted this > >> applied > >> to, and the answer is: I'm not sure? I'm hoping that Rob will be cool with > >> picking the rest up for msm-next for 4.18 but I'm okay with putting this > >> particular patch wherever it is easiest for the maintainers. > > > > We are a bit late to sneak it into the 4.17 drm base via i915. I don't > > anticipate any problems (for i915) with this patch going in through > > msm-next, so happy to have it land there and percolate back to i915 3 > > months later. > > I'd love to have it in drm-misc-next, so I can build a similar hang dump > interface for vc5. But most importantly, I'd like to have it somewhere > soon. I'll fix the bot error and push it up again today. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] gpu: drm: i915: Change return type to vm_fault_t
On Tue, 17 Apr 2018, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> Reference id -> 1c8f422059ae ("mm: change return type to
> vm_fault_t")
>
> Signed-off-by: Souptick Joarder
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 ++-
> drivers/gpu/drm/i915/i915_gem.c | 15 ---
> 2 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a42deeb..95b0d50 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -51,6 +51,7 @@
> #include
> #include
> #include
> +#include
>
> #include "i915_params.h"
> #include "i915_reg.h"
> @@ -3363,7 +3364,7 @@ int i915_gem_wait_for_idle(struct drm_i915_private
> *dev_priv,
> unsigned int flags);
> int __must_check i915_gem_suspend(struct drm_i915_private *dev_priv);
> void i915_gem_resume(struct drm_i915_private *dev_priv);
> -int i915_gem_fault(struct vm_fault *vmf);
> +vm_fault_t i915_gem_fault(struct vm_fault *vmf);
> int i915_gem_object_wait(struct drm_i915_gem_object *obj,
>unsigned int flags,
>long timeout,
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index dd89abd..bdac690 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1882,7 +1882,7 @@ int i915_gem_mmap_gtt_version(void)
> * The current feature set supported by i915_gem_fault() and thus GTT mmaps
> * is exposed via I915_PARAM_MMAP_GTT_VERSION (see
> i915_gem_mmap_gtt_version).
> */
> -int i915_gem_fault(struct vm_fault *vmf)
> +vm_fault_t i915_gem_fault(struct vm_fault *vmf)
> {
> #define MIN_CHUNK_PAGES ((1 << 20) >> PAGE_SHIFT) /* 1 MiB */
> struct vm_area_struct *area = vmf->vma;
> @@ -1895,6 +1895,7 @@ int i915_gem_fault(struct vm_fault *vmf)
> pgoff_t page_offset;
> unsigned int flags;
> int ret;
> + vm_fault_t retval;
What's the point of changing the name? An unnecessary change.
BR,
Jani.
>
> /* We don't use vmf->pgoff since that has the fake offset */
> page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
> @@ -2000,7 +2001,7 @@ int i915_gem_fault(struct vm_fault *vmf)
>* and so needs to be reported.
>*/
> if (!i915_terminally_wedged(&dev_priv->gpu_error)) {
> - ret = VM_FAULT_SIGBUS;
> + retval = VM_FAULT_SIGBUS;
> break;
> }
> case -EAGAIN:
> @@ -2017,21 +2018,21 @@ int i915_gem_fault(struct vm_fault *vmf)
>* EBUSY is ok: this just means that another thread
>* already did the job.
>*/
> - ret = VM_FAULT_NOPAGE;
> + retval = VM_FAULT_NOPAGE;
> break;
> case -ENOMEM:
> - ret = VM_FAULT_OOM;
> + retval = VM_FAULT_OOM;
> break;
> case -ENOSPC:
> case -EFAULT:
> - ret = VM_FAULT_SIGBUS;
> + retval = VM_FAULT_SIGBUS;
> break;
> default:
> WARN_ONCE(ret, "unhandled error in i915_gem_fault: %i\n", ret);
> - ret = VM_FAULT_SIGBUS;
> + retval = VM_FAULT_SIGBUS;
> break;
> }
> - return ret;
> + return retval;
> }
>
> static void __i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
> --
> 1.9.1
>
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.
On Tue, 2018-04-17 at 15:03 +0100, Chris Wilson wrote: > I have to ask, if this is all just to work around iowait triggering > high > frequencies for GPU bound applications, does it all just boil down to > i915 incorrectly using iowait. Does this patch set perform better > than > > diff --git a/drivers/gpu/drm/i915/i915_request.c > b/drivers/gpu/drm/i915/i915_request.c > index 9ca9c24b4421..7e7c95411bcd 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -1267,7 +1267,7 @@ long i915_request_wait(struct i915_request *rq, > goto complete; > } > > - timeout = io_schedule_timeout(timeout); > + timeout = schedule_timeout(timeout); > } while (1); > > GEM_BUG_ON(!intel_wait_has_seqno(&wait)); > > Quite clearly the general framework could prove useful in a broader > range of situations, but does the above suffice? (And can be > backported > to stable.) Definitely a very good test to do. Thanks, Srinivas > -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/crc: make locking and source check more robust
== Series Details == Series: drm/i915/crc: make locking and source check more robust URL : https://patchwork.freedesktop.org/series/41821/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4059 -> Patchwork_8707 = == Summary - WARNING == Minor unknown changes coming with Patchwork_8707 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8707, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41821/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8707: === IGT changes === Warnings igt@core_auth@basic-auth: fi-kbl-r: PASS -> NOTRUN +257 igt@drv_getparams_basic@basic-subslice-total: fi-snb-2600:PASS -> NOTRUN +244 igt@drv_hangman@error-state-basic: fi-elk-e7500: PASS -> NOTRUN +181 igt@gem_busy@basic-busy-default: fi-glk-j4005: PASS -> NOTRUN +255 igt@gem_close_race@basic-process: fi-ivb-3770:PASS -> NOTRUN +251 igt@gem_ctx_param@basic: fi-gdg-551: SKIP -> NOTRUN +107 igt@gem_exec_basic@basic-bsd1: fi-cfl-u: SKIP -> NOTRUN +25 igt@gem_exec_basic@basic-vebox: fi-ivb-3770:SKIP -> NOTRUN +32 igt@gem_exec_basic@gtt-bsd: fi-bwr-2160:SKIP -> NOTRUN +104 igt@gem_exec_basic@gtt-bsd2: fi-kbl-7500u: SKIP -> NOTRUN +23 fi-cnl-y3: SKIP -> NOTRUN +25 igt@gem_exec_basic@readonly-bsd: fi-pnv-d510:SKIP -> NOTRUN +63 igt@gem_exec_basic@readonly-bsd1: fi-snb-2520m: SKIP -> NOTRUN +39 igt@gem_exec_flush@basic-batch-kernel-default-cmd: fi-bxt-dsi: SKIP -> NOTRUN +29 igt@gem_exec_flush@basic-batch-kernel-default-wb: fi-kbl-7567u: PASS -> NOTRUN +264 igt@gem_exec_flush@basic-uc-rw-default: fi-byt-j1900: PASS -> NOTRUN +249 igt@gem_exec_gttfill@basic: fi-skl-gvtdvm: SKIP -> NOTRUN +22 igt@gem_exec_reloc@basic-cpu-active: fi-bsw-n3050: PASS -> NOTRUN +238 igt@gem_exec_reloc@basic-write-cpu-noreloc: fi-skl-6770hq: PASS -> NOTRUN +264 igt@gem_exec_reloc@basic-write-gtt-noreloc: fi-ivb-3520m: PASS -> NOTRUN +253 igt@gem_exec_store@basic-bsd1: fi-kbl-r: SKIP -> NOTRUN +26 igt@gem_exec_store@basic-bsd2: fi-hsw-4770:SKIP -> NOTRUN +26 igt@gem_flink_basic@basic: fi-gdg-551: PASS -> NOTRUN +175 igt@gem_mmap@basic-small-bo: fi-skl-gvtdvm: PASS -> NOTRUN +261 igt@gem_mmap_gtt@basic-read: fi-cnl-y3: PASS -> NOTRUN +258 igt@gem_mmap_gtt@basic-read-write-distinct: fi-hsw-4770:PASS -> NOTRUN +257 igt@gem_mmap_gtt@basic-small-bo: fi-kbl-7500u: PASS -> NOTRUN +259 igt@gem_mmap_gtt@basic-wc: fi-pnv-d510:PASS -> NOTRUN +219 igt@gem_mmap_gtt@basic-write: fi-cfl-8700k: PASS -> NOTRUN +256 igt@gem_mmap_gtt@basic-write-gtt: fi-blb-e6850: PASS -> NOTRUN +219 igt@gem_ringfill@basic-default-fd: fi-elk-e7500: SKIP -> NOTRUN +46 igt@gem_sync@basic-store-all: fi-byt-n2820: PASS -> NOTRUN +245 igt@gem_wait@basic-await-all: fi-glk-1: PASS -> NOTRUN +256 igt@gem_workarounds@basic-read: fi-snb-2600:SKIP -> NOTRUN +39 igt@gvt_basic@invalid-placeholder-test: fi-skl-6260u: SKIP -> NOTRUN +19 igt@kms_addfb_basic@addfb25-bad-modifier: fi-bdw-gvtdvm: PASS -> NOTRUN +260 igt@kms_addfb_basic@too-high: fi-bwr-2160:PASS -> NOTRUN +179 igt@kms_addfb_basic@unused-modifier: fi-bdw-5557u: PASS -> NOTRUN +263 igt@kms_chamelium@common-hpd-after-suspend: fi-ivb-3520m: SKIP -> NOTRUN +28 igt@kms_chamelium@dp-crc-fast: fi-skl-guc: SKIP -> NOTRUN +27 igt@kms_chamelium@dp-edid-read: fi-skl-6770hq: SKIP -> NOTRUN +19 fi-byt-n2820: SKIP -> NOTRUN +38 igt@kms_chamelium@dp-hpd-fast: fi-ilk-650: SKIP -> NOTRUN +59 igt@kms_chamelium@hdmi-crc-fast: fi-cfl-s3: SKIP -> NOTRUN +25 fi-bsw-n3050: SKIP -> NOTRUN +45 fi-byt-j1900: SKIP -> NOTRUN +34 igt@kms_chamelium@hdmi-edid-read: fi-glk-1: SKIP -> NOTRUN +27 fi-blb-e6850: SKIP -> NOTRUN +63 igt@kms_chamelium@vga-edid-read: fi-cfl-8700k: SKIP -> NOTRUN +27 fi-skl-6600u: SKIP -> NOTRUN +26 igt@kms_flip@basic-flip-vs-dpms: fi-ilk-650: PASS -> NOTRUN +224 igt@kms_flip@basic-plain-flip: fi-bxt-j4205: PASS -> NOTRUN +255 igt@kms_
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers
== Series Details == Series: series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers URL : https://patchwork.freedesktop.org/series/41827/ State : warning == Summary == $ dim checkpatch origin/drm-tip 22ae52c5d491 drm/i915: Move the priotree struct to its own headers -:71: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #71: new file mode 100644 -:76: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #76: FILE: drivers/gpu/drm/i915/i915_scheduler.h:1: +/* total: 0 errors, 2 warnings, 0 checks, 103 lines checked 6e113aaa4db4 drm/i915: Rename priotree to sched f3776d9abfc3 drm/i915: Pack params to engine->schedule() into a struct ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers
== Series Details == Series: series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers URL : https://patchwork.freedesktop.org/series/41827/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Move the priotree struct to its own headers Okay! Commit: drm/i915: Rename priotree to sched Okay! Commit: drm/i915: Pack params to engine->schedule() into a struct -drivers/gpu/drm/i915/selftests/../i915_drv.h:2207:33: warning: constant 0xea00 is so big it is unsigned long -drivers/gpu/drm/i915/selftests/../i915_drv.h:3655:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:2208:33: warning: constant 0xea00 is so big it is unsigned long +drivers/gpu/drm/i915/selftests/../i915_drv.h:3656:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers
== Series Details == Series: series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers URL : https://patchwork.freedesktop.org/series/41827/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4059 -> Patchwork_8708 = == Summary - WARNING == Minor unknown changes coming with Patchwork_8708 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8708, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41827/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8708: === IGT changes === Warnings igt@core_auth@basic-auth: fi-kbl-r: PASS -> NOTRUN +257 igt@drv_getparams_basic@basic-subslice-total: fi-snb-2600:PASS -> NOTRUN +244 igt@drv_hangman@error-state-basic: fi-elk-e7500: PASS -> NOTRUN +181 igt@gem_busy@basic-busy-default: fi-glk-j4005: PASS -> NOTRUN +255 igt@gem_close_race@basic-process: fi-ivb-3770:PASS -> NOTRUN +251 igt@gem_ctx_param@basic: fi-gdg-551: SKIP -> NOTRUN +107 igt@gem_exec_basic@basic-bsd1: fi-cfl-u: SKIP -> NOTRUN +25 igt@gem_exec_basic@basic-vebox: fi-ivb-3770:SKIP -> NOTRUN +32 igt@gem_exec_basic@gtt-bsd: fi-bwr-2160:SKIP -> NOTRUN +104 igt@gem_exec_basic@gtt-bsd2: fi-kbl-7500u: SKIP -> NOTRUN +23 fi-cnl-y3: SKIP -> NOTRUN +25 igt@gem_exec_basic@readonly-bsd: fi-pnv-d510:SKIP -> NOTRUN +63 igt@gem_exec_basic@readonly-bsd1: fi-snb-2520m: SKIP -> NOTRUN +39 igt@gem_exec_flush@basic-batch-kernel-default-cmd: fi-bxt-dsi: SKIP -> NOTRUN +29 igt@gem_exec_flush@basic-batch-kernel-default-wb: fi-kbl-7567u: PASS -> NOTRUN +264 igt@gem_exec_flush@basic-uc-rw-default: fi-byt-j1900: PASS -> NOTRUN +249 igt@gem_exec_gttfill@basic: fi-skl-gvtdvm: SKIP -> NOTRUN +22 igt@gem_exec_reloc@basic-cpu-active: fi-bsw-n3050: PASS -> NOTRUN +238 igt@gem_exec_reloc@basic-write-cpu-noreloc: fi-skl-6770hq: PASS -> NOTRUN +264 igt@gem_exec_reloc@basic-write-gtt-noreloc: fi-ivb-3520m: PASS -> NOTRUN +253 igt@gem_exec_store@basic-bsd1: fi-kbl-r: SKIP -> NOTRUN +26 igt@gem_exec_store@basic-bsd2: fi-hsw-4770:SKIP -> NOTRUN +26 igt@gem_flink_basic@basic: fi-gdg-551: PASS -> NOTRUN +175 igt@gem_mmap@basic-small-bo: fi-skl-gvtdvm: PASS -> NOTRUN +261 igt@gem_mmap_gtt@basic-read: fi-cnl-y3: PASS -> NOTRUN +258 igt@gem_mmap_gtt@basic-read-write-distinct: fi-hsw-4770:PASS -> NOTRUN +257 igt@gem_mmap_gtt@basic-small-bo: fi-kbl-7500u: PASS -> NOTRUN +259 igt@gem_mmap_gtt@basic-wc: fi-pnv-d510:PASS -> NOTRUN +219 igt@gem_mmap_gtt@basic-write: fi-cfl-8700k: PASS -> NOTRUN +256 igt@gem_mmap_gtt@basic-write-gtt: fi-blb-e6850: PASS -> NOTRUN +219 igt@gem_ringfill@basic-default-fd: fi-elk-e7500: SKIP -> NOTRUN +46 igt@gem_sync@basic-store-all: fi-byt-n2820: PASS -> NOTRUN +245 igt@gem_wait@basic-await-all: fi-glk-1: PASS -> NOTRUN +256 igt@gem_workarounds@basic-read: fi-snb-2600:SKIP -> NOTRUN +39 igt@gvt_basic@invalid-placeholder-test: fi-skl-6260u: SKIP -> NOTRUN +19 igt@kms_addfb_basic@addfb25-bad-modifier: fi-bdw-gvtdvm: PASS -> NOTRUN +260 igt@kms_addfb_basic@too-high: fi-bwr-2160:PASS -> NOTRUN +179 igt@kms_addfb_basic@unused-modifier: fi-bdw-5557u: PASS -> NOTRUN +263 igt@kms_chamelium@common-hpd-after-suspend: fi-ivb-3520m: SKIP -> NOTRUN +28 igt@kms_chamelium@dp-crc-fast: fi-skl-guc: SKIP -> NOTRUN +27 igt@kms_chamelium@dp-edid-read: fi-skl-6770hq: SKIP -> NOTRUN +19 fi-byt-n2820: SKIP -> NOTRUN +38 igt@kms_chamelium@dp-hpd-fast: fi-ilk-650: SKIP -> NOTRUN +59 igt@kms_chamelium@hdmi-crc-fast: fi-cfl-s3: SKIP -> NOTRUN +25 fi-bsw-n3050: SKIP -> NOTRUN +45 fi-byt-j1900: SKIP -> NOTRUN +34 igt@kms_chamelium@hdmi-edid-read: fi-glk-1: SKIP -> NOTRUN +27 fi-blb-e6850: SKIP -> NOTRUN +63 igt@kms_chamelium@vga-edid-read: fi-cfl-8700k: SKIP -> NOTRUN +27 fi-skl-6600u: SKIP -> NOTRUN +26 igt@kms_flip@basic-flip-vs-dpms: fi-ilk-650: PASS -> NOTRUN +224 igt@kms_flip@basic-plain-flip: fi-bxt-j4205: PASS
Re: [Intel-gfx] [PATCH v7 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
On 4/16/2018 3:09 PM, Oscar Mateo wrote:
On 04/16/2018 02:22 PM, Yunwei Zhang wrote:
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any
MMIO
read into Slice/Subslice specific registers, MCR packet control
register(0xFDC) needs to be programmed to point to any enabled
slice/subslice pair. Otherwise, incorrect value will be returned.
However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all
cases
across slice/subslice. There are rare occasions such as INSTDONE that
this
value will be dependent on slice/subslice combo, in such cases, we
need to
program 0xFDC and recover this after. This is already covered by
read_subslice_reg.
Also, 0xFDC will lose its information after TDR/engine reset/power state
change.
References: HSD#1405586840, BSID#0575
v2:
- use fls() instead of find_last_bit() (Chris)
- added INTEL_SSEU to extract sseu from device info. (Chris)
v3:
- rebase on latest tip
v5:
- Added references (Mika)
- Change the ordered of passing arguments and etc. (Ursulin)
v7:
- Rebased.
Cc: Oscar Mateo
Cc: Michel Thierry
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Signed-off-by: Yunwei Zhang
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_engine_cs.c | 30
+++---
drivers/gpu/drm/i915/intel_workarounds.c | 12
3 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 8e8667d..43498a47 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2725,6 +2725,8 @@ int vlv_force_gfx_clock(struct drm_i915_private
*dev_priv, bool on);
int intel_engines_init_mmio(struct drm_i915_private *dev_priv);
int intel_engines_init(struct drm_i915_private *dev_priv);
+u32 calculate_mcr(struct drm_i915_private *dev_priv, u32 mcr);
+
As a global function, this could use a better prefix (intel_something_)
Or, alternatively, make it local and store the calculation somewhere.
Good suggestion, do you think intel_device_info will be a good place to
store, it is deduced from that structure after all? Or should I put it
in drm_i915_private?
/* intel_hotplug.c */
void intel_hpd_irq_handler(struct drm_i915_private *dev_priv,
u32 pin_mask, u32 long_mask);
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 1a83707..3b6bc5e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -799,6 +799,18 @@ const char *i915_cache_level_str(struct
drm_i915_private *i915, int type)
}
}
+u32 calculate_mcr(struct drm_i915_private *dev_priv, u32 mcr)
+{
+ const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
+ u32 slice = fls(sseu->slice_mask);
+ u32 subslice = fls(sseu->subslice_mask[slice]);
+
+ mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
+ mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
+
+ return mcr;
+}
+
static inline uint32_t
read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
int subslice, i915_reg_t reg)
@@ -831,18 +843,30 @@ read_subslice_reg(struct drm_i915_private
*dev_priv, int slice,
intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
+
/*
* The HW expects the slice and sublice selectors to be reset to 0
- * after reading out the registers.
+ * before GEN10 or to a enabled s/ss post GEN10 after reading
out the
+ * registers.
*/
- WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
+ WARN_ON_ONCE(INTEL_GEN(dev_priv) < 10 &&
+ (mcr & mcr_slice_subslice_mask));
Advantage of storing the calculation: you can assert here for the
expected value, independently of the platform.
mcr &= ~mcr_slice_subslice_mask;
mcr |= mcr_slice_subslice_select;
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
ret = I915_READ_FW(reg);
- mcr &= ~mcr_slice_subslice_mask;
+ /*
+ * WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
+ * expects mcr to be programed to a enabled slice/subslice pair
+ * before any MMIO read into slice/subslice register
+ */
+ if (INTEL_GEN(dev_priv) < 10)
+ mcr &= ~mcr_slice_subslice_mask;
+ else
+ mcr = calculate_mcr(dev_priv, mcr);
Another advantage: no branching here either.
+
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
intel_uncore_forcewake_put__locked(dev_priv, fw_domains);
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index ec9d340..8a2354e 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -645,8 +645,20 @@ static void
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Don't use -ETIMEDOUT from inside a test
== Series Details == Series: drm/i915/selftests: Don't use -ETIMEDOUT from inside a test URL : https://patchwork.freedesktop.org/series/41828/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4059 -> Patchwork_8709 = == Summary - WARNING == Minor unknown changes coming with Patchwork_8709 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8709, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41828/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8709: === IGT changes === Warnings igt@core_auth@basic-auth: fi-kbl-r: PASS -> NOTRUN +257 igt@drv_getparams_basic@basic-subslice-total: fi-snb-2600:PASS -> NOTRUN +244 igt@drv_hangman@error-state-basic: fi-elk-e7500: PASS -> NOTRUN +181 igt@gem_busy@basic-busy-default: fi-glk-j4005: PASS -> NOTRUN +255 igt@gem_close_race@basic-process: fi-ivb-3770:PASS -> NOTRUN +251 igt@gem_ctx_param@basic: fi-gdg-551: SKIP -> NOTRUN +107 igt@gem_exec_basic@basic-bsd1: fi-cfl-u: SKIP -> NOTRUN +25 igt@gem_exec_basic@basic-vebox: fi-ivb-3770:SKIP -> NOTRUN +32 igt@gem_exec_basic@gtt-bsd: fi-bwr-2160:SKIP -> NOTRUN +104 igt@gem_exec_basic@gtt-bsd2: fi-kbl-7500u: SKIP -> NOTRUN +23 fi-cnl-y3: SKIP -> NOTRUN +25 igt@gem_exec_basic@readonly-bsd: fi-pnv-d510:SKIP -> NOTRUN +63 igt@gem_exec_basic@readonly-bsd1: fi-snb-2520m: SKIP -> NOTRUN +39 igt@gem_exec_flush@basic-batch-kernel-default-cmd: fi-bxt-dsi: SKIP -> NOTRUN +29 igt@gem_exec_flush@basic-batch-kernel-default-wb: fi-kbl-7567u: PASS -> NOTRUN +264 igt@gem_exec_flush@basic-uc-rw-default: fi-byt-j1900: PASS -> NOTRUN +249 igt@gem_exec_gttfill@basic: fi-skl-gvtdvm: SKIP -> NOTRUN +22 igt@gem_exec_reloc@basic-cpu-active: fi-bsw-n3050: PASS -> NOTRUN +238 igt@gem_exec_reloc@basic-write-cpu-noreloc: fi-skl-6770hq: PASS -> NOTRUN +264 igt@gem_exec_reloc@basic-write-gtt-noreloc: fi-ivb-3520m: PASS -> NOTRUN +253 igt@gem_exec_store@basic-bsd1: fi-kbl-r: SKIP -> NOTRUN +26 igt@gem_exec_store@basic-bsd2: fi-hsw-4770:SKIP -> NOTRUN +26 igt@gem_flink_basic@basic: fi-gdg-551: PASS -> NOTRUN +175 igt@gem_mmap@basic-small-bo: fi-skl-gvtdvm: PASS -> NOTRUN +261 igt@gem_mmap_gtt@basic-read: fi-cnl-y3: PASS -> NOTRUN +258 igt@gem_mmap_gtt@basic-read-write-distinct: fi-hsw-4770:PASS -> NOTRUN +257 igt@gem_mmap_gtt@basic-small-bo: fi-kbl-7500u: PASS -> NOTRUN +259 igt@gem_mmap_gtt@basic-wc: fi-pnv-d510:PASS -> NOTRUN +219 igt@gem_mmap_gtt@basic-write: fi-cfl-8700k: PASS -> NOTRUN +256 igt@gem_mmap_gtt@basic-write-gtt: fi-blb-e6850: PASS -> NOTRUN +219 igt@gem_ringfill@basic-default-fd: fi-elk-e7500: SKIP -> NOTRUN +46 igt@gem_sync@basic-store-all: fi-byt-n2820: PASS -> NOTRUN +245 igt@gem_wait@basic-await-all: fi-glk-1: PASS -> NOTRUN +256 igt@gem_workarounds@basic-read: fi-snb-2600:SKIP -> NOTRUN +39 igt@gvt_basic@invalid-placeholder-test: fi-skl-6260u: SKIP -> NOTRUN +19 igt@kms_addfb_basic@addfb25-bad-modifier: fi-bdw-gvtdvm: PASS -> NOTRUN +260 igt@kms_addfb_basic@too-high: fi-bwr-2160:PASS -> NOTRUN +179 igt@kms_addfb_basic@unused-modifier: fi-bdw-5557u: PASS -> NOTRUN +263 igt@kms_chamelium@common-hpd-after-suspend: fi-ivb-3520m: SKIP -> NOTRUN +28 igt@kms_chamelium@dp-crc-fast: fi-skl-guc: SKIP -> NOTRUN +27 igt@kms_chamelium@dp-edid-read: fi-skl-6770hq: SKIP -> NOTRUN +19 fi-byt-n2820: SKIP -> NOTRUN +38 igt@kms_chamelium@dp-hpd-fast: fi-ilk-650: SKIP -> NOTRUN +59 igt@kms_chamelium@hdmi-crc-fast: fi-cfl-s3: SKIP -> NOTRUN +25 fi-bsw-n3050: SKIP -> NOTRUN +45 fi-byt-j1900: SKIP -> NOTRUN +34 igt@kms_chamelium@hdmi-edid-read: fi-glk-1: SKIP -> NOTRUN +27 fi-blb-e6850: SKIP -> NOTRUN +63 igt@kms_chamelium@vga-edid-read: fi-cfl-8700k: SKIP -> NOTRUN +27 fi-skl-6600u: SKIP -> NOTRUN +26 igt@kms_flip@basic-flip-vs-dpms: fi-ilk-650: PASS -> NOTRUN +224 igt@kms_flip@basic-plain-flip: fi-bxt-j4205: PASS -> NOTRUN +255 igt@
Re: [Intel-gfx] [PATCH] gpu: drm: i915: Change return type to vm_fault_t
On Tue, Apr 17, 2018 at 09:14:32PM +0530, Souptick Joarder wrote:
> Not exactly. The plan for these patches is to introduce new vm_fault_t type
> in vm_operations_struct fault handlers. It's now available in 4.17-rc1. We
> will
> push all the required drivers/filesystem changes through different maintainers
> to linus tree. Once everything is converted into vm_fault_t type then Changing
> it from a signed to an unsigned int causes GCC to warn about an assignment
> from an incompatible type -- int foo(void) is incompatible with
> unsigned int foo(void).
>
> Please refer 1c8f422059ae ("mm: change return type to vm_fault_t") in
> 4.17-rc1.
I think this patch would be clearer if you did
- int ret;
+ int err;
+ vm_fault_t ret;
Then it would be clearer to the maintainer that you're splitting apart the
VM_FAULT and errno codes.
Sorry for not catching this during initial review.
> On Tue, Apr 17, 2018 at 8:59 PM, Jani Nikula
> wrote:
> > On Tue, 17 Apr 2018, Souptick Joarder wrote:
> >> Use new return type vm_fault_t for fault handler. For
> >> now, this is just documenting that the function returns
> >> a VM_FAULT value rather than an errno. Once all instances
> >> are converted, vm_fault_t will become a distinct type.
> >>
> >> Reference id -> 1c8f422059ae ("mm: change return type to
> >> vm_fault_t")
> >>
> >> Signed-off-by: Souptick Joarder
> >> ---
> >> drivers/gpu/drm/i915/i915_drv.h | 3 ++-
> >> drivers/gpu/drm/i915/i915_gem.c | 15 ---
> >> 2 files changed, 10 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index a42deeb..95b0d50 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -51,6 +51,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #include "i915_params.h"
> >> #include "i915_reg.h"
> >> @@ -3363,7 +3364,7 @@ int i915_gem_wait_for_idle(struct drm_i915_private
> >> *dev_priv,
> >> unsigned int flags);
> >> int __must_check i915_gem_suspend(struct drm_i915_private *dev_priv);
> >> void i915_gem_resume(struct drm_i915_private *dev_priv);
> >> -int i915_gem_fault(struct vm_fault *vmf);
> >> +vm_fault_t i915_gem_fault(struct vm_fault *vmf);
> >> int i915_gem_object_wait(struct drm_i915_gem_object *obj,
> >>unsigned int flags,
> >>long timeout,
> >> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >> b/drivers/gpu/drm/i915/i915_gem.c
> >> index dd89abd..bdac690 100644
> >> --- a/drivers/gpu/drm/i915/i915_gem.c
> >> +++ b/drivers/gpu/drm/i915/i915_gem.c
> >> @@ -1882,7 +1882,7 @@ int i915_gem_mmap_gtt_version(void)
> >> * The current feature set supported by i915_gem_fault() and thus GTT
> >> mmaps
> >> * is exposed via I915_PARAM_MMAP_GTT_VERSION (see
> >> i915_gem_mmap_gtt_version).
> >> */
> >> -int i915_gem_fault(struct vm_fault *vmf)
> >> +vm_fault_t i915_gem_fault(struct vm_fault *vmf)
> >> {
> >> #define MIN_CHUNK_PAGES ((1 << 20) >> PAGE_SHIFT) /* 1 MiB */
> >> struct vm_area_struct *area = vmf->vma;
> >> @@ -1895,6 +1895,7 @@ int i915_gem_fault(struct vm_fault *vmf)
> >> pgoff_t page_offset;
> >> unsigned int flags;
> >> int ret;
> >> + vm_fault_t retval;
> >
> > What's the point of changing the name? An unnecessary change.
> >
> > BR,
> > Jani.
> >
> >>
> >> /* We don't use vmf->pgoff since that has the fake offset */
> >> page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
> >> @@ -2000,7 +2001,7 @@ int i915_gem_fault(struct vm_fault *vmf)
> >>* and so needs to be reported.
> >>*/
> >> if (!i915_terminally_wedged(&dev_priv->gpu_error)) {
> >> - ret = VM_FAULT_SIGBUS;
> >> + retval = VM_FAULT_SIGBUS;
> >> break;
> >> }
> >> case -EAGAIN:
> >> @@ -2017,21 +2018,21 @@ int i915_gem_fault(struct vm_fault *vmf)
> >>* EBUSY is ok: this just means that another thread
> >>* already did the job.
> >>*/
> >> - ret = VM_FAULT_NOPAGE;
> >> + retval = VM_FAULT_NOPAGE;
> >> break;
> >> case -ENOMEM:
> >> - ret = VM_FAULT_OOM;
> >> + retval = VM_FAULT_OOM;
> >> break;
> >> case -ENOSPC:
> >> case -EFAULT:
> >> - ret = VM_FAULT_SIGBUS;
> >> + retval = VM_FAULT_SIGBUS;
> >> break;
> >> default:
> >> WARN_ONCE(ret, "unhandled error in i915_gem_fault: %i\n",
> >> ret);
> >> - ret = VM_FAULT_SIGBUS;
> >> + retval = VM_FAULT_SIGBUS;
> >> break;
> >> }
> >> - return ret;
> >> + return retval;
> >> }
> >>
> >> static void __i915_gem_object_release_mmap(struct drm_i915_gem_object
> >> *obj)
> >> --
> >> 1.9.
Re: [Intel-gfx] [PATCH] gpu: drm: i915: Change return type to vm_fault_t
On Tue, Apr 17, 2018 at 5:29 PM, Jani Nikula
wrote:
> On Tue, 17 Apr 2018, Souptick Joarder wrote:
>> Use new return type vm_fault_t for fault handler. For
>> now, this is just documenting that the function returns
>> a VM_FAULT value rather than an errno. Once all instances
>> are converted, vm_fault_t will become a distinct type.
>>
>> Reference id -> 1c8f422059ae ("mm: change return type to
>> vm_fault_t")
>>
>> Signed-off-by: Souptick Joarder
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>> drivers/gpu/drm/i915/i915_gem.c | 15 ---
>> 2 files changed, 10 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index a42deeb..95b0d50 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -51,6 +51,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "i915_params.h"
>> #include "i915_reg.h"
>> @@ -3363,7 +3364,7 @@ int i915_gem_wait_for_idle(struct drm_i915_private
>> *dev_priv,
>> unsigned int flags);
>> int __must_check i915_gem_suspend(struct drm_i915_private *dev_priv);
>> void i915_gem_resume(struct drm_i915_private *dev_priv);
>> -int i915_gem_fault(struct vm_fault *vmf);
>> +vm_fault_t i915_gem_fault(struct vm_fault *vmf);
>> int i915_gem_object_wait(struct drm_i915_gem_object *obj,
>>unsigned int flags,
>>long timeout,
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index dd89abd..bdac690 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -1882,7 +1882,7 @@ int i915_gem_mmap_gtt_version(void)
>> * The current feature set supported by i915_gem_fault() and thus GTT mmaps
>> * is exposed via I915_PARAM_MMAP_GTT_VERSION (see
>> i915_gem_mmap_gtt_version).
>> */
>> -int i915_gem_fault(struct vm_fault *vmf)
>> +vm_fault_t i915_gem_fault(struct vm_fault *vmf)
>> {
>> #define MIN_CHUNK_PAGES ((1 << 20) >> PAGE_SHIFT) /* 1 MiB */
>> struct vm_area_struct *area = vmf->vma;
>> @@ -1895,6 +1895,7 @@ int i915_gem_fault(struct vm_fault *vmf)
>> pgoff_t page_offset;
>> unsigned int flags;
>> int ret;
>> + vm_fault_t retval;
>
> What's the point of changing the name? An unnecessary change.
int ret;
already exists and is used. You can't also have a vm_fault_t ret; on
top of that :-)
-Daniel
>
> BR,
> Jani.
>
>>
>> /* We don't use vmf->pgoff since that has the fake offset */
>> page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
>> @@ -2000,7 +2001,7 @@ int i915_gem_fault(struct vm_fault *vmf)
>>* and so needs to be reported.
>>*/
>> if (!i915_terminally_wedged(&dev_priv->gpu_error)) {
>> - ret = VM_FAULT_SIGBUS;
>> + retval = VM_FAULT_SIGBUS;
>> break;
>> }
>> case -EAGAIN:
>> @@ -2017,21 +2018,21 @@ int i915_gem_fault(struct vm_fault *vmf)
>>* EBUSY is ok: this just means that another thread
>>* already did the job.
>>*/
>> - ret = VM_FAULT_NOPAGE;
>> + retval = VM_FAULT_NOPAGE;
>> break;
>> case -ENOMEM:
>> - ret = VM_FAULT_OOM;
>> + retval = VM_FAULT_OOM;
>> break;
>> case -ENOSPC:
>> case -EFAULT:
>> - ret = VM_FAULT_SIGBUS;
>> + retval = VM_FAULT_SIGBUS;
>> break;
>> default:
>> WARN_ONCE(ret, "unhandled error in i915_gem_fault: %i\n", ret);
>> - ret = VM_FAULT_SIGBUS;
>> + retval = VM_FAULT_SIGBUS;
>> break;
>> }
>> - return ret;
>> + return retval;
>> }
>>
>> static void __i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
>> --
>> 1.9.1
>>
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> 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
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/crc: make locking and source check more robust
== Series Details ==
Series: drm/i915/crc: make locking and source check more robust
URL : https://patchwork.freedesktop.org/series/41821/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4059_full -> Patchwork_8707_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_8707_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_8707_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/41821/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in
Patchwork_8707_full:
=== IGT changes ===
Warnings
igt@gem_busy@extended-parallel-bsd1:
shard-hsw: SKIP -> NOTRUN +890
igt@gem_exec_params@dr1-dirt:
shard-kbl: PASS -> NOTRUN +1940
igt@gem_pread@stolen-uncached:
shard-kbl: SKIP -> NOTRUN +700
igt@gem_pwrite@display:
shard-snb: PASS -> NOTRUN +1377
igt@kms_chv_cursor_fail@pipe-b-256x256-top-edge:
shard-hsw: PASS -> NOTRUN +1783
igt@kms_rotation_crc@sprite-rotation-90-pos-100-0:
shard-apl: PASS -> NOTRUN +1834
igt@perf_pmu@busy-start-vcs1:
shard-snb: SKIP -> NOTRUN +1298
igt@prime_vgem@sync-bsd1:
shard-apl: SKIP -> NOTRUN +835
== Known issues ==
Here are the changes found in Patchwork_8707_full that come from known issues:
=== IGT changes ===
Possible fixes
igt@drv_selftest@mock_breadcrumbs:
shard-hsw: DMESG-FAIL (fdo#106085) -> NOTRUN
shard-snb: DMESG-FAIL (fdo#106085) -> NOTRUN
shard-apl: DMESG-FAIL (fdo#106085) -> NOTRUN
shard-kbl: DMESG-FAIL (fdo#106085) -> NOTRUN
igt@drv_selftest@mock_scatterlist:
shard-hsw: DMESG-WARN (fdo#103667) -> NOTRUN
shard-kbl: DMESG-WARN (fdo#103667) -> NOTRUN
shard-snb: DMESG-WARN (fdo#103667) -> NOTRUN
shard-apl: DMESG-WARN (fdo#103667) -> NOTRUN
igt@gem_ctx_isolation@vcs0-s3:
shard-kbl: INCOMPLETE (fdo#103665) -> NOTRUN
igt@gem_exec_schedule@pi-ringfull-blt:
shard-apl: FAIL (fdo#103158) -> NOTRUN +3
igt@gem_exec_schedule@pi-ringfull-bsd1:
shard-kbl: FAIL (fdo#103158) -> NOTRUN +4
igt@kms_flip@2x-flip-vs-expired-vblank:
shard-hsw: FAIL (fdo#102887) -> NOTRUN
igt@kms_flip@flip-vs-expired-vblank-interruptible:
shard-apl: FAIL (fdo#105363, fdo#102887) -> NOTRUN
igt@kms_flip@modeset-vs-vblank-race:
shard-hsw: FAIL (fdo#103060) -> NOTRUN
igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
shard-snb: FAIL (fdo#103167) -> NOTRUN
igt@kms_setmode@basic:
shard-apl: FAIL (fdo#99912) -> NOTRUN
shard-hsw: FAIL (fdo#99912) -> NOTRUN
shard-snb: FAIL (fdo#99912) -> NOTRUN
igt@kms_sysfs_edid_timing:
shard-hsw: WARN (fdo#100047) -> NOTRUN
shard-kbl: FAIL (fdo#100047) -> NOTRUN
igt@prime_vgem@coherency-gtt:
shard-apl: FAIL (fdo#100587) -> NOTRUN +1
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#100587 https://bugs.freedesktop.org/show_bug.cgi?id=100587
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
fdo#103667 https://bugs.freedesktop.org/show_bug.cgi?id=103667
fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
fdo#106085 https://bugs.freedesktop.org/show_bug.cgi?id=106085
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
== Participating hosts (6 -> 4) ==
Missing(2): shard-glk shard-glkb
== Build changes ==
* Linux: CI_DRM_4059 -> Patchwork_8707
CI_DRM_4059: c1645edc253f2b52a8c94565a75b479a6782e75f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4435: ddbe5a4d8bb1780ecf07f72e815062d3bce8ff71 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_8707: 5b95e15ae1993417806ff6b9e413f5c03429fcb0 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4435: e60d247eb359f044caf0c09904da14e39d7adca1 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8707/shards.html
___
Intel-gfx maili
[Intel-gfx] [PATCH] drm/i915/selftests: Fix error checking for wait_var_timeout
The old wait_on_atomic_t used a custom callback to perform the
schedule(), which used my return semantics of reporting an error code on
timeout. wait_var_event_timeout() uses the schedule() return semantics
of reporting the remaining jiffies (1 if it timed out with 0 jiffies
remaining!) and 0 on failure. This semantic mismatch lead to us falsely
claiming a time out occurred.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106085
Fixes: d224985a5e31 ("sched/wait, drivers/drm: Convert wait_on_atomic_t() usage
to the new wait_var_event() API")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
index 46580026c7fc..d6926e7820e5 100644
--- a/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
@@ -412,10 +412,11 @@ static int igt_wakeup(void *arg)
* that they are ready for the next test. We wait until all
* threads are complete and waiting for us (i.e. not a seqno).
*/
- err = wait_var_event_timeout(&done, !atomic_read(&done), 10 *
HZ);
- if (err) {
+ if (!wait_var_event_timeout(&done,
+ !atomic_read(&done), 10 * HZ)) {
pr_err("Timed out waiting for %d remaining waiters\n",
atomic_read(&done));
+ err = -ETIMEDOUT;
break;
}
--
2.17.0
___
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/3] drm/i915: Move the priotree struct to its own headers
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: Move the priotree struct to its
own headers
URL : https://patchwork.freedesktop.org/series/41827/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4059_full -> Patchwork_8708_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_8708_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_8708_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/41827/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in
Patchwork_8708_full:
=== IGT changes ===
Warnings
igt@gem_busy@extended-parallel-bsd1:
shard-hsw: SKIP -> NOTRUN +890
igt@gem_exec_params@dr1-dirt:
shard-kbl: PASS -> NOTRUN +1940
igt@gem_pread@stolen-uncached:
shard-kbl: SKIP -> NOTRUN +700
igt@gem_pwrite@display:
shard-snb: PASS -> NOTRUN +1377
igt@kms_chv_cursor_fail@pipe-b-256x256-top-edge:
shard-hsw: PASS -> NOTRUN +1783
igt@kms_rotation_crc@sprite-rotation-90-pos-100-0:
shard-apl: PASS -> NOTRUN +1834
igt@perf_pmu@busy-start-vcs1:
shard-snb: SKIP -> NOTRUN +1298
igt@prime_vgem@sync-bsd1:
shard-apl: SKIP -> NOTRUN +835
== Known issues ==
Here are the changes found in Patchwork_8708_full that come from known issues:
=== IGT changes ===
Possible fixes
igt@drv_selftest@mock_breadcrumbs:
shard-hsw: DMESG-FAIL (fdo#106085) -> NOTRUN
shard-snb: DMESG-FAIL (fdo#106085) -> NOTRUN
shard-apl: DMESG-FAIL (fdo#106085) -> NOTRUN
shard-kbl: DMESG-FAIL (fdo#106085) -> NOTRUN
igt@drv_selftest@mock_scatterlist:
shard-hsw: DMESG-WARN (fdo#103667) -> NOTRUN
shard-kbl: DMESG-WARN (fdo#103667) -> NOTRUN
shard-snb: DMESG-WARN (fdo#103667) -> NOTRUN
shard-apl: DMESG-WARN (fdo#103667) -> NOTRUN
igt@gem_ctx_isolation@vcs0-s3:
shard-kbl: INCOMPLETE (fdo#103665) -> NOTRUN
igt@gem_exec_schedule@pi-ringfull-blt:
shard-apl: FAIL (fdo#103158) -> NOTRUN +3
igt@gem_exec_schedule@pi-ringfull-bsd1:
shard-kbl: FAIL (fdo#103158) -> NOTRUN +4
igt@kms_flip@2x-flip-vs-expired-vblank:
shard-hsw: FAIL (fdo#102887) -> NOTRUN
igt@kms_flip@flip-vs-expired-vblank-interruptible:
shard-apl: FAIL (fdo#105363, fdo#102887) -> NOTRUN
igt@kms_flip@modeset-vs-vblank-race:
shard-hsw: FAIL (fdo#103060) -> NOTRUN
igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
shard-snb: FAIL (fdo#103167) -> NOTRUN
igt@kms_setmode@basic:
shard-apl: FAIL (fdo#99912) -> NOTRUN
shard-hsw: FAIL (fdo#99912) -> NOTRUN
shard-snb: FAIL (fdo#99912) -> NOTRUN
igt@kms_sysfs_edid_timing:
shard-hsw: WARN (fdo#100047) -> NOTRUN
shard-kbl: FAIL (fdo#100047) -> NOTRUN
igt@prime_vgem@coherency-gtt:
shard-apl: FAIL (fdo#100587) -> NOTRUN +1
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#100587 https://bugs.freedesktop.org/show_bug.cgi?id=100587
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
fdo#103667 https://bugs.freedesktop.org/show_bug.cgi?id=103667
fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
fdo#106085 https://bugs.freedesktop.org/show_bug.cgi?id=106085
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
== Participating hosts (6 -> 4) ==
Missing(2): shard-glk shard-glkb
== Build changes ==
* Linux: CI_DRM_4059 -> Patchwork_8708
CI_DRM_4059: c1645edc253f2b52a8c94565a75b479a6782e75f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4435: ddbe5a4d8bb1780ecf07f72e815062d3bce8ff71 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_8708: f3776d9abfc3a5a073cc6531119697128be256e5 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4435: e60d247eb359f044caf0c09904da14e39d7adca1 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8708/shards.html
__
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Don't use -ETIMEDOUT from inside a test
== Series Details ==
Series: drm/i915/selftests: Don't use -ETIMEDOUT from inside a test
URL : https://patchwork.freedesktop.org/series/41828/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4059_full -> Patchwork_8709_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_8709_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_8709_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/41828/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in
Patchwork_8709_full:
=== IGT changes ===
Warnings
igt@gem_busy@extended-parallel-bsd1:
shard-hsw: SKIP -> NOTRUN +890
igt@gem_pwrite@display:
shard-snb: PASS -> NOTRUN +1377
igt@kms_chv_cursor_fail@pipe-b-256x256-top-edge:
shard-hsw: PASS -> NOTRUN +1783
igt@kms_rotation_crc@sprite-rotation-90-pos-100-0:
shard-apl: PASS -> NOTRUN +1834
igt@perf_pmu@busy-start-vcs1:
shard-snb: SKIP -> NOTRUN +1298
igt@prime_vgem@sync-bsd1:
shard-apl: SKIP -> NOTRUN +835
== Known issues ==
Here are the changes found in Patchwork_8709_full that come from known issues:
=== IGT changes ===
Possible fixes
igt@drv_selftest@mock_breadcrumbs:
shard-hsw: DMESG-FAIL (fdo#106085) -> NOTRUN
shard-snb: DMESG-FAIL (fdo#106085) -> NOTRUN
shard-apl: DMESG-FAIL (fdo#106085) -> NOTRUN
igt@drv_selftest@mock_scatterlist:
shard-hsw: DMESG-WARN (fdo#103667) -> NOTRUN
shard-snb: DMESG-WARN (fdo#103667) -> NOTRUN
shard-apl: DMESG-WARN (fdo#103667) -> NOTRUN
igt@gem_exec_schedule@pi-ringfull-blt:
shard-apl: FAIL (fdo#103158) -> NOTRUN +3
igt@kms_flip@2x-flip-vs-expired-vblank:
shard-hsw: FAIL (fdo#102887) -> NOTRUN
igt@kms_flip@flip-vs-expired-vblank-interruptible:
shard-apl: FAIL (fdo#105363, fdo#102887) -> NOTRUN
igt@kms_flip@modeset-vs-vblank-race:
shard-hsw: FAIL (fdo#103060) -> NOTRUN
igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
shard-snb: FAIL (fdo#103167) -> NOTRUN
igt@kms_setmode@basic:
shard-apl: FAIL (fdo#99912) -> NOTRUN
shard-hsw: FAIL (fdo#99912) -> NOTRUN
shard-snb: FAIL (fdo#99912) -> NOTRUN
igt@kms_sysfs_edid_timing:
shard-hsw: WARN (fdo#100047) -> NOTRUN
igt@prime_vgem@coherency-gtt:
shard-apl: FAIL (fdo#100587) -> NOTRUN +1
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#100587 https://bugs.freedesktop.org/show_bug.cgi?id=100587
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103667 https://bugs.freedesktop.org/show_bug.cgi?id=103667
fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
fdo#106085 https://bugs.freedesktop.org/show_bug.cgi?id=106085
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
== Participating hosts (6 -> 3) ==
Missing(3): shard-glk shard-glkb shard-kbl
== Build changes ==
* Linux: CI_DRM_4059 -> Patchwork_8709
CI_DRM_4059: c1645edc253f2b52a8c94565a75b479a6782e75f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4435: ddbe5a4d8bb1780ecf07f72e815062d3bce8ff71 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_8709: 3bc6d966ff0c39e28bc38aabe8ab5ea8890d74b1 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4435: e60d247eb359f044caf0c09904da14e39d7adca1 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8709/shards.html
___
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/selftests: Fix error checking for wait_var_timeout
== Series Details == Series: drm/i915/selftests: Fix error checking for wait_var_timeout URL : https://patchwork.freedesktop.org/series/41835/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4059 -> Patchwork_8710 = == Summary - WARNING == Minor unknown changes coming with Patchwork_8710 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8710, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41835/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8710: === IGT changes === Warnings igt@core_auth@basic-auth: fi-kbl-r: PASS -> NOTRUN +257 igt@drv_getparams_basic@basic-subslice-total: fi-snb-2600:PASS -> NOTRUN +244 igt@drv_hangman@error-state-basic: fi-elk-e7500: PASS -> NOTRUN +181 igt@gem_busy@basic-busy-default: fi-glk-j4005: PASS -> NOTRUN +255 igt@gem_close_race@basic-process: fi-ivb-3770:PASS -> NOTRUN +251 igt@gem_ctx_param@basic: fi-gdg-551: SKIP -> NOTRUN +107 igt@gem_exec_basic@basic-bsd1: fi-cfl-u: SKIP -> NOTRUN +25 igt@gem_exec_basic@basic-vebox: fi-ivb-3770:SKIP -> NOTRUN +32 igt@gem_exec_basic@gtt-bsd: fi-bwr-2160:SKIP -> NOTRUN +104 igt@gem_exec_basic@gtt-bsd2: fi-kbl-7500u: SKIP -> NOTRUN +23 fi-cnl-y3: SKIP -> NOTRUN +25 igt@gem_exec_basic@readonly-bsd: fi-pnv-d510:SKIP -> NOTRUN +63 igt@gem_exec_basic@readonly-bsd1: fi-snb-2520m: SKIP -> NOTRUN +39 igt@gem_exec_flush@basic-batch-kernel-default-cmd: fi-bxt-dsi: SKIP -> NOTRUN +29 igt@gem_exec_flush@basic-batch-kernel-default-wb: fi-kbl-7567u: PASS -> NOTRUN +264 igt@gem_exec_flush@basic-uc-rw-default: fi-byt-j1900: PASS -> NOTRUN +249 igt@gem_exec_gttfill@basic: fi-skl-gvtdvm: SKIP -> NOTRUN +22 igt@gem_exec_reloc@basic-cpu-active: fi-bsw-n3050: PASS -> NOTRUN +238 igt@gem_exec_reloc@basic-write-cpu-noreloc: fi-skl-6770hq: PASS -> NOTRUN +264 igt@gem_exec_reloc@basic-write-gtt-noreloc: fi-ivb-3520m: PASS -> NOTRUN +253 igt@gem_exec_store@basic-bsd1: fi-kbl-r: SKIP -> NOTRUN +26 igt@gem_exec_store@basic-bsd2: fi-hsw-4770:SKIP -> NOTRUN +26 igt@gem_flink_basic@basic: fi-gdg-551: PASS -> NOTRUN +175 igt@gem_mmap@basic-small-bo: fi-skl-gvtdvm: PASS -> NOTRUN +261 igt@gem_mmap_gtt@basic-read: fi-cnl-y3: PASS -> NOTRUN +258 igt@gem_mmap_gtt@basic-read-write-distinct: fi-hsw-4770:PASS -> NOTRUN +257 igt@gem_mmap_gtt@basic-small-bo: fi-kbl-7500u: PASS -> NOTRUN +259 igt@gem_mmap_gtt@basic-wc: fi-pnv-d510:PASS -> NOTRUN +219 igt@gem_mmap_gtt@basic-write: fi-cfl-8700k: PASS -> NOTRUN +256 igt@gem_mmap_gtt@basic-write-gtt: fi-blb-e6850: PASS -> NOTRUN +219 igt@gem_ringfill@basic-default-fd: fi-elk-e7500: SKIP -> NOTRUN +46 igt@gem_sync@basic-store-all: fi-byt-n2820: PASS -> NOTRUN +245 igt@gem_wait@basic-await-all: fi-glk-1: PASS -> NOTRUN +256 igt@gem_workarounds@basic-read: fi-snb-2600:SKIP -> NOTRUN +39 igt@gvt_basic@invalid-placeholder-test: fi-skl-6260u: SKIP -> NOTRUN +19 igt@kms_addfb_basic@addfb25-bad-modifier: fi-bdw-gvtdvm: PASS -> NOTRUN +260 igt@kms_addfb_basic@too-high: fi-bwr-2160:PASS -> NOTRUN +179 igt@kms_addfb_basic@unused-modifier: fi-bdw-5557u: PASS -> NOTRUN +263 igt@kms_chamelium@common-hpd-after-suspend: fi-ivb-3520m: SKIP -> NOTRUN +28 igt@kms_chamelium@dp-crc-fast: fi-skl-guc: SKIP -> NOTRUN +27 igt@kms_chamelium@dp-edid-read: fi-skl-6770hq: SKIP -> NOTRUN +19 fi-byt-n2820: SKIP -> NOTRUN +38 igt@kms_chamelium@dp-hpd-fast: fi-ilk-650: SKIP -> NOTRUN +59 igt@kms_chamelium@hdmi-crc-fast: fi-cfl-s3: SKIP -> NOTRUN +25 fi-bsw-n3050: SKIP -> NOTRUN +45 fi-byt-j1900: SKIP -> NOTRUN +34 igt@kms_chamelium@hdmi-edid-read: fi-glk-1: SKIP -> NOTRUN +27 fi-blb-e6850: SKIP -> NOTRUN +63 igt@kms_chamelium@vga-edid-read: fi-cfl-8700k: SKIP -> NOTRUN +27 fi-skl-6600u: SKIP -> NOTRUN +26 igt@kms_flip@basic-flip-vs-dpms: fi-ilk-650: PASS -> NOTRUN +224 igt@kms_flip@basic-plain-flip: fi-bxt-j4205: PASS -> NOTRUN +255 igt@
Re: [Intel-gfx] [PATCH v4] drm/i915: Enable edp psr error interrupts on hsw
On Mon, Apr 16, 2018 at 05:43:54PM -0700, Paulo Zanoni wrote:
> Em Qui, 2018-04-05 às 15:00 -0700, Dhinakaran Pandiyan escreveu:
> > From: Daniel Vetter
> >
> > The definitions for the error register should be valid on bdw/skl
> > too,
> > but there we haven't even enabled DE_MISC handling yet.
> >
> > Somewhat confusing the the moved register offset on bdw is only for
> > the _CTL/_AUX register, and that _IIR/IMR stayed where they have been
> > on bdw.
> >
> > v2: Fixes from Ville.
> >
> > v3: From DK
> > * Rebased on drm-tip
> > * Removed BDW IIR bit definition, looks like an unintentional change
> > that
> > should be in the following patch.
> >
> > v4: From DK
> > * Don't mask REG_WRITE.
> >
> > References: bspec/11974 [SRD Interrupt Bit Definition DevHSW]
> > Cc: Ville Syrjälä
> > Cc: Rodrigo Vivi
> > Cc: Daniel Vetter
> > Signed-off-by: Daniel Vetter
> > Signed-off-by: Dhinakaran Pandiyan
> > Reviewed-by: Jose Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 34
> > ++
> > drivers/gpu/drm/i915/i915_reg.h | 8
> > 2 files changed, 42 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 27aee25429b7..c2d3f30778ee 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2391,6 +2391,26 @@ static void ilk_display_irq_handler(struct
> > drm_i915_private *dev_priv,
> > ironlake_rps_change_irq_handler(dev_priv);
> > }
> >
> > +static void hsw_edp_psr_irq_handler(struct drm_i915_private
> > *dev_priv)
> > +{
> > + u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> > +
> > + if (edp_psr_iir & EDP_PSR_ERROR)
> > + DRM_DEBUG_KMS("PSR error\n");
> > +
> > + if (edp_psr_iir & EDP_PSR_PRE_ENTRY) {
> > + DRM_DEBUG_KMS("PSR prepare entry in 2 vblanks\n");
> > + I915_WRITE(EDP_PSR_IMR, EDP_PSR_PRE_ENTRY);
>
> Why are we masking it here? During these 2 vblanks it's possible that
> something will happen (e.g., frontbuffer writing, cursor moving, page
> flipping).
The masking was here to avoid seeing a big flood of entry interrupts.
> Are we guaranteed to get a POST_EXIT interrupt even if we
> give up entering PSR before it is actually entered?
No. The exit interrupt only happens if you actually reached PSR.
>
>
> > + }
> > +
> > + if (edp_psr_iir & EDP_PSR_POST_EXIT) {
> > + DRM_DEBUG_KMS("PSR exit completed\n");
> > + I915_WRITE(EDP_PSR_IMR, 0);
> > + }
> > +
> > + I915_WRITE(EDP_PSR_IIR, edp_psr_iir);
> > +}
> > +
> > static void ivb_display_irq_handler(struct drm_i915_private
> > *dev_priv,
> > u32 de_iir)
> > {
> > @@ -2403,6 +2423,9 @@ static void ivb_display_irq_handler(struct
> > drm_i915_private *dev_priv,
> > if (de_iir & DE_ERR_INT_IVB)
> > ivb_err_int_handler(dev_priv);
> >
> > + if (de_iir & DE_EDP_PSR_INT_HSW)
> > + hsw_edp_psr_irq_handler(dev_priv);
> > +
> > if (de_iir & DE_AUX_CHANNEL_A_IVB)
> > dp_aux_irq_handler(dev_priv);
> >
> > @@ -3260,6 +3283,11 @@ static void ironlake_irq_reset(struct
> > drm_device *dev)
> > if (IS_GEN7(dev_priv))
> > I915_WRITE(GEN7_ERR_INT, 0x);
> >
> > + if (IS_HASWELL(dev_priv)) {
> > + I915_WRITE(EDP_PSR_IMR, 0x);
> > + I915_WRITE(EDP_PSR_IIR, 0x);
> > + }
>
> We need another IIR write we do for the other platforms. This is not
> cargo cult (as mentioned in previous review emails), this is required
> since our hardware is able to store more than one IIR interrupt. Please
> do it like we do for the other interrupts.
I don't remember if the PSR IIR is double buffered or not. I would
assumeme it is. It is super easy to verify though if you want to be
sure:
1. unmask the interrupt
2. generate at least two interrupts
3. mask the interrupt
4. clear IIR
5. read IIR
6. clear IIR
7. read IIR
Step 5 should still show the IIR bit set if the IIR is double buffered.
And step 7 it should show it to be clear.
--
Ville Syrjälä
Intel
___
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/selftests: Fix error checking for wait_var_timeout
== Series Details ==
Series: drm/i915/selftests: Fix error checking for wait_var_timeout
URL : https://patchwork.freedesktop.org/series/41835/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4059_full -> Patchwork_8710_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_8710_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_8710_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/41835/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in
Patchwork_8710_full:
=== IGT changes ===
Warnings
igt@gem_busy@extended-parallel-bsd1:
shard-hsw: SKIP -> NOTRUN +890
igt@gem_exec_params@dr1-dirt:
shard-kbl: PASS -> NOTRUN +1940
igt@gem_pread@stolen-uncached:
shard-kbl: SKIP -> NOTRUN +700
igt@gem_pwrite@display:
shard-snb: PASS -> NOTRUN +1377
igt@kms_chv_cursor_fail@pipe-b-256x256-top-edge:
shard-hsw: PASS -> NOTRUN +1783
igt@kms_rotation_crc@sprite-rotation-90-pos-100-0:
shard-apl: PASS -> NOTRUN +1834
igt@perf_pmu@busy-start-vcs1:
shard-snb: SKIP -> NOTRUN +1298
igt@prime_vgem@sync-bsd1:
shard-apl: SKIP -> NOTRUN +835
== Known issues ==
Here are the changes found in Patchwork_8710_full that come from known issues:
=== IGT changes ===
Possible fixes
igt@drv_selftest@mock_breadcrumbs:
shard-hsw: DMESG-FAIL (fdo#106085) -> NOTRUN
shard-snb: DMESG-FAIL (fdo#106085) -> NOTRUN
shard-apl: DMESG-FAIL (fdo#106085) -> NOTRUN
shard-kbl: DMESG-FAIL (fdo#106085) -> NOTRUN
igt@drv_selftest@mock_scatterlist:
shard-hsw: DMESG-WARN (fdo#103667) -> NOTRUN
shard-kbl: DMESG-WARN (fdo#103667) -> NOTRUN
shard-snb: DMESG-WARN (fdo#103667) -> NOTRUN
shard-apl: DMESG-WARN (fdo#103667) -> NOTRUN
igt@gem_ctx_isolation@vcs0-s3:
shard-kbl: INCOMPLETE (fdo#103665) -> NOTRUN
igt@gem_exec_schedule@pi-ringfull-blt:
shard-apl: FAIL (fdo#103158) -> NOTRUN +3
igt@gem_exec_schedule@pi-ringfull-bsd1:
shard-kbl: FAIL (fdo#103158) -> NOTRUN +4
igt@kms_flip@2x-flip-vs-expired-vblank:
shard-hsw: FAIL (fdo#102887) -> NOTRUN
igt@kms_flip@flip-vs-expired-vblank-interruptible:
shard-apl: FAIL (fdo#105363, fdo#102887) -> NOTRUN
igt@kms_flip@modeset-vs-vblank-race:
shard-hsw: FAIL (fdo#103060) -> NOTRUN
igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
shard-snb: FAIL (fdo#103167) -> NOTRUN
igt@kms_setmode@basic:
shard-apl: FAIL (fdo#99912) -> NOTRUN
shard-hsw: FAIL (fdo#99912) -> NOTRUN
shard-snb: FAIL (fdo#99912) -> NOTRUN
igt@kms_sysfs_edid_timing:
shard-hsw: WARN (fdo#100047) -> NOTRUN
shard-kbl: FAIL (fdo#100047) -> NOTRUN
igt@prime_vgem@coherency-gtt:
shard-apl: FAIL (fdo#100587) -> NOTRUN +1
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#100587 https://bugs.freedesktop.org/show_bug.cgi?id=100587
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
fdo#103667 https://bugs.freedesktop.org/show_bug.cgi?id=103667
fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
fdo#106085 https://bugs.freedesktop.org/show_bug.cgi?id=106085
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
== Participating hosts (6 -> 4) ==
Missing(2): shard-glk shard-glkb
== Build changes ==
* Linux: CI_DRM_4059 -> Patchwork_8710
CI_DRM_4059: c1645edc253f2b52a8c94565a75b479a6782e75f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4435: ddbe5a4d8bb1780ecf07f72e815062d3bce8ff71 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_8710: 31ed4f77481f05424db6032698f73ee08b0b3f3b @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4435: e60d247eb359f044caf0c09904da14e39d7adca1 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8710/shards.html
___
Intel-gfx m
Re: [Intel-gfx] [PATCH v10 10/11] drm: Add aspect ratio parsing in DRM layer
On Tue, Apr 17, 2018 at 10:45:07AM +0530, Nautiyal, Ankit K wrote:
>
> On 4/6/2018 11:14 PM, Ville Syrjälä wrote:
> > On Fri, Apr 06, 2018 at 10:55:14PM +0530, Nautiyal, Ankit K wrote:
> >> This patch is causing failure of IGT test kms_3d. The kms_3d test
> >> expects the no. of 3d modes to be 13.
> >>
> >> (The test has hard-coded value for expected no. of 3d modes as 13)
> >>
> >> But due to the addition of "matching aspect_ratio" in drm_mode_equal in
> >> this patch, the total no. of
> >>
> >> modes in the connector modelist is increased by 2, resulting in failure
> >> of assertion 'mode_count==13'.
> > If kms_3d isn't setting the aspect ratio cap how is it affected by these
> > changes?
> In drm_mode.c, the drm_mode_connector_list_update() uses drm_mode_equal,
> to remove duplicate modes in connector_modes from the
> connector->probe_modes.
> Earlier, it wasn't matching for aspect-ratio and was discarding two of
> the modes with aspect ratio,
> as duplicates of other modes in the list.
>
> Later, when we are pruning the modes in drm_mode_get_connector, the
> logic there assumes,
> that the modes are in a sorted order so that we just match with the last
> valid mode for uniqueness.
> This isn't the case with the spoofed edid in kms_3d.
> Earlier, I was thinking if we should change the no. of expected modes in
> kms_3d,
> but that's not correct approach.
>
> So finally, The pruning logic needs to be changed, to do away with any
> assumption and check
> all the modes in the list for duplicates. This however will take more
> time to remove duplicates.
>
> Any other suggestions on this?
What are all the modes this EDID gives us? The order in which the
modes are listed in the EDID should not be relevant as we sort
the mode list ourselves, and thus similar modes should appear back to
back on the list. So I don't really understand how we fail to
discard these two modes.
>
> Regards
> -Ankit
>
> >
> >> Perhaps this need to be handled in the test.
> >>
> >> -Regards,
> >>
> >> Ankit
> >>
> >>
> >> On 4/6/2018 10:34 PM, Nautiyal, Ankit K wrote:
> >>> From: "Sharma, Shashank"
> >>>
> >>> Current DRM layer functions don't parse aspect ratio information
> >>> while converting a user mode->kernel mode or vice versa. This
> >>> causes modeset to pick mode with wrong aspect ratio, eventually
> >>> causing failures in HDMI compliance test cases, due to wrong VIC.
> >>>
> >>> This patch adds aspect ratio information in DRM's mode conversion
> >>> and mode comparision functions, to make sure kernel picks mode
> >>> with right aspect ratio (as per the VIC).
> >>>
> >>> Background:
> >>> This patch was once reviewed and merged, and later reverted due to
> >>> lack of DRM cap protection. This is a re-spin of this patch, this
> >>> time with DRM cap protection, to avoid aspect ratio information, when
> >>> the client doesn't request for it.
> >>>
> >>> Review link: https://pw-emeril.freedesktop.org/patch/104068/
> >>> Background discussion: https://patchwork.kernel.org/patch/9379057/
> >>>
> >>> Signed-off-by: Shashank Sharma
> >>> Signed-off-by: Lin, Jia
> >>> Signed-off-by: Akashdeep Sharma
> >>> Reviewed-by: Jim Bride (V2)
> >>> Reviewed-by: Jose Abreu (V4)
> >>>
> >>> Cc: Ville Syrjala
> >>> Cc: Jim Bride
> >>> Cc: Jose Abreu
> >>> Cc: Ankit Nautiyal
> >>>
> >>> V3: modified the aspect-ratio check in drm_mode_equal as per new flags
> >>> provided by Ville. https://patchwork.freedesktop.org/patch/188043/
> >>> V4: rebase
> >>> V5: rebase
> >>> V6: As recommended by Ville, avoided matching of aspect-ratio in
> >>> drm_fb_helper, while trying to find a common mode among connectors
> >>> for the target clone mode.
> >>> V7: rebase
> >>> V8: rebase
> >>> V9: rebase
> >>> V10: rebase
> >>> ---
> >>>drivers/gpu/drm/drm_fb_helper.c | 12 ++--
> >>>drivers/gpu/drm/drm_modes.c | 35
> >>> ++-
> >>>2 files changed, 44 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> >>> b/drivers/gpu/drm/drm_fb_helper.c
> >>> index 0646b10..2ee1eaa 100644
> >>> --- a/drivers/gpu/drm/drm_fb_helper.c
> >>> +++ b/drivers/gpu/drm/drm_fb_helper.c
> >>> @@ -2183,7 +2183,11 @@ static bool drm_target_cloned(struct drm_fb_helper
> >>> *fb_helper,
> >>> for (j = 0; j < i; j++) {
> >>> if (!enabled[j])
> >>> continue;
> >>> - if (!drm_mode_equal(modes[j], modes[i]))
> >>> + if (!drm_mode_match(modes[j], modes[i],
> >>> + DRM_MODE_MATCH_TIMINGS |
> >>> + DRM_MODE_MATCH_CLOCK |
> >>> + DRM_MODE_MATCH_FLAGS |
> >>> + DRM_MODE_MATCH_3D_FLAGS))
> >>> can_clone = false;
> >>> }
> >>> }
> >>> @@ -2203,7 +2207,11 @@ stat
Re: [Intel-gfx] [PATCH] drm/i915: Fix LSPCON TMDS output buffer enabling from low-power state
On Mon, Apr 16, 2018 at 06:53:09PM +0300, Imre Deak wrote:
> LSPCON adapters in low-power state may ignore the first I2C write during
> TMDS output buffer enabling, resulting in a blank screen even with an
> otherwise enabled pipe. Fix this by reading back and validating the
> written value a few times.
>
> The problem was noticed on GLK machines with an onboard LSPCON adapter
> after entering/exiting DC5 power state. Doing an I2C read of the adapter
> ID as the first transaction - instead of the I2C write to enable the
> TMDS buffers - returns the correct value. Based on this we assume that
> the transaction itself is sent properly, it's only the adapter that is
> not ready for some reason to accept this first write after waking from
> low-power state. In my case the second I2C write attempt always
> succeeded.
Yeah, I guess this is an OK approach. Probably not much point in
optimizing the non-LSPCON case since this is modeset stuff,
although we do have the adaptor type passed in so we could if we
wanted to.
Reviewed-by: Ville Syrjälä
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105854
> Cc: Clinton Taylor
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/drm_dp_dual_mode_helper.c | 39
> +--
> 1 file changed, 32 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> index 02a50929af67..e7f4fe2848a5 100644
> --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> @@ -350,19 +350,44 @@ int drm_dp_dual_mode_set_tmds_output(enum
> drm_dp_dual_mode_type type,
> {
> uint8_t tmds_oen = enable ? 0 : DP_DUAL_MODE_TMDS_DISABLE;
> ssize_t ret;
> + int retry;
>
> if (type < DRM_DP_DUAL_MODE_TYPE2_DVI)
> return 0;
>
> - ret = drm_dp_dual_mode_write(adapter, DP_DUAL_MODE_TMDS_OEN,
> - &tmds_oen, sizeof(tmds_oen));
> - if (ret) {
> - DRM_DEBUG_KMS("Failed to %s TMDS output buffers\n",
> - enable ? "enable" : "disable");
> - return ret;
> + /*
> + * LSPCON adapters in low-power state may ignore the first write, so
> + * read back and verify the written value a few times.
> + */
> + for (retry = 0; retry < 3; retry++) {
> + uint8_t tmp;
> +
> + ret = drm_dp_dual_mode_write(adapter, DP_DUAL_MODE_TMDS_OEN,
> + &tmds_oen, sizeof(tmds_oen));
> + if (ret) {
> + DRM_DEBUG_KMS("Failed to %s TMDS output buffers (%d
> attempts)\n",
> + enable ? "enable" : "disable",
> + retry + 1);
> + return ret;
> + }
> +
> + ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_TMDS_OEN,
> + &tmp, sizeof(tmp));
> + if (ret) {
> + DRM_DEBUG_KMS("I2C read failed during TMDS output
> buffer %s (%d attempts)\n",
> + enable ? "enabling" : "disabling",
> + retry + 1);
> + return ret;
> + }
> +
> + if (tmp == tmds_oen)
> + return 0;
> }
>
> - return 0;
> + DRM_DEBUG_KMS("I2C write value mismatch during TMDS output buffer %s\n",
> + enable ? "enabling" : "disabling");
> +
> + return -EIO;
> }
> EXPORT_SYMBOL(drm_dp_dual_mode_set_tmds_output);
>
> --
> 2.13.2
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/audio: Fix audio detection issue on GLK
On 4/17/2018 12:18 AM, Gaurav K Singh wrote: On Geminilake, sometimes audio card is not getting detected after reboot. This is a spurious issue happening on Geminilake. HW codec and HD audio controller link was going out of sync for which there was a fix in i915 driver but was not getting invoked for GLK. Extending this fix to GLK as well. Tested by Du,Wenkai on GLK board. Bspec: 21829 v2: Instead of checking GEN9_BC, BXT and GLK macros, use IS_GEN9 macro Signed-off-by: Gaurav K Singh Reviewed-by: Jani Nikula Reviewed-by: Abhay Kumar --- drivers/gpu/drm/i915/intel_audio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c index 656f6c931341..3ea566f99450 100644 --- a/drivers/gpu/drm/i915/intel_audio.c +++ b/drivers/gpu/drm/i915/intel_audio.c @@ -729,7 +729,7 @@ static void i915_audio_component_codec_wake_override(struct device *kdev, struct drm_i915_private *dev_priv = kdev_to_i915(kdev); u32 tmp; - if (!IS_GEN9_BC(dev_priv) && !IS_BROXTON(dev_priv)) + if (!IS_GEN9(dev_priv)) return; i915_audio_component_get_power(kdev); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
On Tue, Apr 17, 2018 at 02:25:32PM +0530, Ramalingam C wrote:
> >From Gen9 onwards Bspec says HW supports Max Bytes per single RD/WR op is
> 511Bytes instead of previous 256Bytes used in SW.
>
> This change allows the max bytes per op upto 511Bytes from Gen9 onwards.
>
> v2:
> No Change.
> v3:
> Inline function for max_xfer_size and renaming of the macro.[Jani]
>
> Cc: Jani Nikula
> Cc: Chris Wilson
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_i2c.c | 11 +--
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 475cac07d3e6..be6114a0e8ab 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3013,6 +3013,7 @@ enum i915_power_well_id {
> #define GMBUS_CYCLE_STOP (4<<25)
> #define GMBUS_BYTE_COUNT_SHIFT 16
> #define GMBUS_BYTE_COUNT_MAX 256U
> +#define GEN9_GMBUS_BYTE_COUNT_MAX 511U
> #define GMBUS_SLAVE_INDEX_SHIFT 8
> #define GMBUS_SLAVE_ADDR_SHIFT 1
> #define GMBUS_SLAVE_READ (1<<0)
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index e6875509bcd9..4367827d7661 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -361,6 +361,13 @@ gmbus_wait_idle(struct drm_i915_private *dev_priv)
> return ret;
> }
>
> +static inline
> +unsigned int gmbus_max_xfer_size(struct drm_i915_private *dev_priv)
> +{
> + return (INTEL_GEN(dev_priv) >= 9) ? GEN9_GMBUS_BYTE_COUNT_MAX :
> + GMBUS_BYTE_COUNT_MAX;
Hmm. You sure about this 256 limit on older HW? The spec does sort of
say that 0-256 is the valid range, but the SPT+ docs still have that
same text, and the register has always had 9 bits for byte count. I
don't see any statements saying that they changed this in any way for
SPT. It only talks about >511 bytes needing the special treatment.
If we do this the I think you should just drop the defines and put the
raw numbers into this function. The extra indirection just makes life
harder. Also pointless parens around the GEN>9 check.
> +}
> +
> static int
> gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
> unsigned short addr, u8 *buf, unsigned int len,
> @@ -400,7 +407,7 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct
> i2c_msg *msg,
> int ret;
>
> do {
> - len = min(rx_size, GMBUS_BYTE_COUNT_MAX);
> + len = min(rx_size, gmbus_max_xfer_size(dev_priv));
>
> ret = gmbus_xfer_read_chunk(dev_priv, msg->addr,
> buf, len, gmbus1_index);
> @@ -462,7 +469,7 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv,
> struct i2c_msg *msg,
> int ret;
>
> do {
> - len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
> + len = min(tx_size, gmbus_max_xfer_size(dev_priv));
>
> ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len,
>gmbus1_index);
> --
> 2.7.4
--
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/audio: Fix audio detection issue on GLK
On Geminilake, sometimes audio card is not getting detected after reboot. This is a spurious issue happening on Geminilake. HW codec and HD audio controller link was going out of sync for which there was a fix in i915 driver but was not getting invoked for GLK. Extending this fix to GLK as well. Tested by Du,Wenkai on GLK board. Bspec: 21829 v2: Instead of checking GEN9_BC, BXT and GLK macros, use IS_GEN9 macro (Jani N) Signed-off-by: Gaurav K Singh Reviewed-by: Abhay Kumar --- drivers/gpu/drm/i915/intel_audio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c index 656f6c931341..3ea566f99450 100644 --- a/drivers/gpu/drm/i915/intel_audio.c +++ b/drivers/gpu/drm/i915/intel_audio.c @@ -729,7 +729,7 @@ static void i915_audio_component_codec_wake_override(struct device *kdev, struct drm_i915_private *dev_priv = kdev_to_i915(kdev); u32 tmp; - if (!IS_GEN9_BC(dev_priv) && !IS_BROXTON(dev_priv)) + if (!IS_GEN9(dev_priv)) return; i915_audio_component_get_power(kdev); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/audio: Fix audio detection issue on GLK
On 4/17/2018 11:22 AM, Gaurav K Singh wrote: On Geminilake, sometimes audio card is not getting detected after reboot. This is a spurious issue happening on Geminilake. HW codec and HD audio controller link was going out of sync for which there was a fix in i915 driver but was not getting invoked for GLK. Extending this fix to GLK as well. Tested by Du,Wenkai on GLK board. Bspec: 21829 v2: Instead of checking GEN9_BC, BXT and GLK macros, use IS_GEN9 macro (Jani N) Signed-off-by: Gaurav K Singh Reviewed-by: Abhay Kumar Reviewed-by: Wenkai Du Tested-by: Wenkai Du Regards, Wenkai --- drivers/gpu/drm/i915/intel_audio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c index 656f6c931341..3ea566f99450 100644 --- a/drivers/gpu/drm/i915/intel_audio.c +++ b/drivers/gpu/drm/i915/intel_audio.c @@ -729,7 +729,7 @@ static void i915_audio_component_codec_wake_override(struct device *kdev, struct drm_i915_private *dev_priv = kdev_to_i915(kdev); u32 tmp; - if (!IS_GEN9_BC(dev_priv) && !IS_BROXTON(dev_priv)) + if (!IS_GEN9(dev_priv)) return; i915_audio_component_get_power(kdev); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/audio: Fix audio detection issue on GLK (rev3)
== Series Details == Series: drm/i915/audio: Fix audio detection issue on GLK (rev3) URL : https://patchwork.freedesktop.org/series/41334/ State : warning == Summary == $ dim checkpatch origin/drm-tip 31e1d7550f3b drm/i915/audio: Fix audio detection issue on GLK -:16: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #16: v2: Instead of checking GEN9_BC, BXT and GLK macros, use IS_GEN9 macro (Jani N) total: 0 errors, 1 warnings, 0 checks, 8 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/gmbus: Enable burst read
On Tue, Apr 17, 2018 at 02:25:33PM +0530, Ramalingam C wrote:
> Support for Burst read in HW is added for HDCP2.2 compliance
> requirement.
>
> This patch enables the burst read for all the gmbus read of more than
> 511Bytes, on capable platforms.
>
> v2:
> Extra line is removed.
> v3:
> Macro is added for detecting the BURST_READ Support [Jani]
> Runtime detection of the need for burst_read [Jani]
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_i2c.c | 22 --
> 3 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5373b171bb96..9cddcaa3efb2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2548,6 +2548,9 @@ intel_info(const struct drm_i915_private *dev_priv)
> */
> #define HAS_AUX_IRQ(dev_priv) true
> #define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
> +#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \
> + IS_GEMINILAKE(dev_priv) || \
> + IS_KABYLAKE(dev_priv))
Spec says "Not available until KBLPCH-H A0, SPT-LP D1, SPT-H E1"
Not quite sure if those two statements are equivalenet or not.
>
> /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
> * rows, which changed the alignment requirements and fence programming.
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index be6114a0e8ab..8b4e6363c7d2 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2984,6 +2984,7 @@ enum i915_power_well_id {
> #define GMBUS_RATE_400KHZ (2<<8) /* reserved on Pineview */
> #define GMBUS_RATE_1MHZ(3<<8) /* reserved on Pineview */
> #define GMBUS_HOLD_EXT (1<<7) /* 300ns hold time, rsvd on Pineview */
> +#define GMBUS_BYTE_CNT_OVERRIDE (1<<6)
> #define GMBUS_PIN_DISABLED 0
> #define GMBUS_PIN_SSC 1
> #define GMBUS_PIN_VGADDC 2
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index 4367827d7661..cb260f667cfa 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -373,10 +373,21 @@ gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
> unsigned short addr, u8 *buf, unsigned int len,
> u32 gmbus1_index)
> {
> + unsigned int bytes_af_override = 0, size = len;
whatis af?
> + bool burst_read = len > gmbus_max_xfer_size(dev_priv);
> +
> + if (burst_read) {
> + bytes_af_override = (len % 256) + 256;
The spec has a special case for 512 for some reason. Would be nice to
find out why it's there, and why there is no special case listed for
other larger multiples of 256.
No need for () around the %.
> + size = bytes_af_override;
Why two variables for the same thing?
> +
> + I915_WRITE_FW(GMBUS0, (I915_READ_FW(GMBUS0) |
> + GMBUS_BYTE_CNT_OVERRIDE));
useless parens
We could probably avoid the rmw by passing in the gmbus0
value from the caller.
> + }
> +
> I915_WRITE_FW(GMBUS1,
> gmbus1_index |
> GMBUS_CYCLE_WAIT |
> - (len << GMBUS_BYTE_COUNT_SHIFT) |
> + (size << GMBUS_BYTE_COUNT_SHIFT) |
> (addr << GMBUS_SLAVE_ADDR_SHIFT) |
> GMBUS_SLAVE_READ | GMBUS_SW_RDY);
> while (len) {
> @@ -392,6 +403,10 @@ gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
> *buf++ = val & 0xff;
> val >>= 8;
> } while (--len && ++loop < 4);
> +
> + if (burst_read && len == (bytes_af_override - 4))
more useless parens
> + I915_WRITE_FW(GMBUS0, (I915_READ_FW(GMBUS0) &
> + ~GMBUS_BYTE_CNT_OVERRIDE));
and some more
> }
>
> return 0;
> @@ -407,7 +422,10 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv,
> struct i2c_msg *msg,
> int ret;
>
> do {
> - len = min(rx_size, gmbus_max_xfer_size(dev_priv));
> + if (HAS_GMBUS_BURST_READ(dev_priv))
> + len = rx_size;
> + else
> + len = min(rx_size, gmbus_max_xfer_size(dev_priv));
>
> ret = gmbus_xfer_read_chunk(dev_priv, msg->addr,
> buf, len, gmbus1_index);
> --
> 2.7.4
--
Ville Syrjälä
Intel
___
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/audio: Fix audio detection issue on GLK (rev3)
== Series Details == Series: drm/i915/audio: Fix audio detection issue on GLK (rev3) URL : https://patchwork.freedesktop.org/series/41334/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4059 -> Patchwork_8711 = == Summary - WARNING == Minor unknown changes coming with Patchwork_8711 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8711, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41334/revisions/3/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8711: === IGT changes === Warnings igt@core_auth@basic-auth: fi-kbl-r: PASS -> NOTRUN +257 igt@drv_getparams_basic@basic-subslice-total: fi-snb-2600:PASS -> NOTRUN +244 igt@drv_hangman@error-state-basic: fi-elk-e7500: PASS -> NOTRUN +181 igt@gem_busy@basic-busy-default: fi-glk-j4005: PASS -> NOTRUN +255 igt@gem_close_race@basic-process: fi-ivb-3770:PASS -> NOTRUN +251 igt@gem_ctx_param@basic: fi-gdg-551: SKIP -> NOTRUN +107 igt@gem_exec_basic@basic-bsd1: fi-cfl-u: SKIP -> NOTRUN +25 igt@gem_exec_basic@basic-vebox: fi-ivb-3770:SKIP -> NOTRUN +32 igt@gem_exec_basic@gtt-bsd: fi-bwr-2160:SKIP -> NOTRUN +104 igt@gem_exec_basic@gtt-bsd2: fi-kbl-7500u: SKIP -> NOTRUN +23 fi-cnl-y3: SKIP -> NOTRUN +25 igt@gem_exec_basic@readonly-bsd: fi-pnv-d510:SKIP -> NOTRUN +63 igt@gem_exec_basic@readonly-bsd1: fi-snb-2520m: SKIP -> NOTRUN +39 igt@gem_exec_flush@basic-batch-kernel-default-cmd: fi-bxt-dsi: SKIP -> NOTRUN +29 igt@gem_exec_flush@basic-batch-kernel-default-wb: fi-kbl-7567u: PASS -> NOTRUN +264 igt@gem_exec_flush@basic-uc-rw-default: fi-byt-j1900: PASS -> NOTRUN +249 igt@gem_exec_gttfill@basic: fi-skl-gvtdvm: SKIP -> NOTRUN +22 igt@gem_exec_reloc@basic-cpu-active: fi-bsw-n3050: PASS -> NOTRUN +238 igt@gem_exec_reloc@basic-write-cpu-noreloc: fi-skl-6770hq: PASS -> NOTRUN +264 igt@gem_exec_reloc@basic-write-gtt-noreloc: fi-ivb-3520m: PASS -> NOTRUN +253 igt@gem_exec_store@basic-bsd1: fi-kbl-r: SKIP -> NOTRUN +26 igt@gem_exec_store@basic-bsd2: fi-hsw-4770:SKIP -> NOTRUN +26 igt@gem_flink_basic@basic: fi-gdg-551: PASS -> NOTRUN +175 igt@gem_mmap@basic-small-bo: fi-skl-gvtdvm: PASS -> NOTRUN +261 igt@gem_mmap_gtt@basic-read: fi-cnl-y3: PASS -> NOTRUN +258 igt@gem_mmap_gtt@basic-read-write-distinct: fi-hsw-4770:PASS -> NOTRUN +257 igt@gem_mmap_gtt@basic-small-bo: fi-kbl-7500u: PASS -> NOTRUN +259 igt@gem_mmap_gtt@basic-wc: fi-pnv-d510:PASS -> NOTRUN +219 igt@gem_mmap_gtt@basic-write: fi-cfl-8700k: PASS -> NOTRUN +256 igt@gem_mmap_gtt@basic-write-gtt: fi-blb-e6850: PASS -> NOTRUN +219 igt@gem_ringfill@basic-default-fd: fi-elk-e7500: SKIP -> NOTRUN +46 igt@gem_sync@basic-store-all: fi-byt-n2820: PASS -> NOTRUN +245 igt@gem_wait@basic-await-all: fi-glk-1: PASS -> NOTRUN +256 igt@gem_workarounds@basic-read: fi-snb-2600:SKIP -> NOTRUN +39 igt@gvt_basic@invalid-placeholder-test: fi-skl-6260u: SKIP -> NOTRUN +19 igt@kms_addfb_basic@addfb25-bad-modifier: fi-bdw-gvtdvm: PASS -> NOTRUN +260 igt@kms_addfb_basic@too-high: fi-bwr-2160:PASS -> NOTRUN +179 igt@kms_addfb_basic@unused-modifier: fi-bdw-5557u: PASS -> NOTRUN +263 igt@kms_chamelium@common-hpd-after-suspend: fi-ivb-3520m: SKIP -> NOTRUN +28 igt@kms_chamelium@dp-crc-fast: fi-skl-guc: SKIP -> NOTRUN +27 igt@kms_chamelium@dp-edid-read: fi-skl-6770hq: SKIP -> NOTRUN +19 fi-byt-n2820: SKIP -> NOTRUN +38 igt@kms_chamelium@dp-hpd-fast: fi-ilk-650: SKIP -> NOTRUN +59 igt@kms_chamelium@hdmi-crc-fast: fi-cfl-s3: SKIP -> NOTRUN +25 fi-bsw-n3050: SKIP -> NOTRUN +45 fi-byt-j1900: SKIP -> NOTRUN +34 igt@kms_chamelium@hdmi-edid-read: fi-glk-1: SKIP -> NOTRUN +27 fi-blb-e6850: SKIP -> NOTRUN +63 igt@kms_chamelium@vga-edid-read: fi-cfl-8700k: SKIP -> NOTRUN +27 fi-skl-6600u: SKIP -> NOTRUN +26 igt@kms_flip@basic-flip-vs-dpms: fi-ilk-650: PASS -> NOTRUN +224 igt@kms_flip@basic-plain-flip: fi-bxt-j4205: PASS -> NOTRUN +255 igt@kms_
[Intel-gfx] [PATCH v3] drm/i915: set minimum CD clock to twice the BCLK.
In glk when device boots with only 1366x768 panel, HDA codec doesn't comeup. This result in no audio forever as cdclk is < 96Mhz. This change will ensure CD clock to be twice of BCLK. v2: - Address comment (Jani) - New design approach v3: - Typo fix on top of v1 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102937 Signed-off-by: Abhay Kumar --- drivers/gpu/drm/i915/intel_cdclk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c index dc7db8a2caf8..6e93af4a46ea 100644 --- a/drivers/gpu/drm/i915/intel_cdclk.c +++ b/drivers/gpu/drm/i915/intel_cdclk.c @@ -2143,7 +2143,7 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state) /* According to BSpec, "The CD clock frequency must be at least twice * the frequency of the Azalia BCLK." and BCLK is 96 MHz by default. */ - if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9) + if (INTEL_GEN(dev_priv) >= 9) min_cdclk = max(2 * 96000, min_cdclk); /* -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
