Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/guc: Release GuC interrupts in i915_guc_submission_disable

2017-03-14 Thread Kamble, Sagar A



On 3/13/2017 3:17 PM, Chris Wilson wrote:

On Mon, Mar 13, 2017 at 10:28:34AM +0530, Kamble, Sagar A wrote:


On 3/12/2017 6:29 PM, Chris Wilson wrote:

On Sat, Mar 11, 2017 at 04:17:34AM -, Patchwork wrote:

== Series Details ==

Series: series starting with [1/3] drm/i915/guc: Release GuC interrupts in 
i915_guc_submission_disable
URL   : https://patchwork.freedesktop.org/series/21090/
State : success

== Summary ==

Series 21090v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/21090/revisions/1/mbox/

Test kms_pipe_crc_basic:
 Subgroup hang-read-crc-pipe-b:
 dmesg-warn -> PASS   (fi-byt-j1900)

Applied, thanks for the quick fix. It is looking much neater now as well
:)
-Chris

Thanks Chris.
I feel unmasking of ARAT_EXPIRED is hard coding the behavior with GuC.
Ideally rps enabling should happen post GuC load in reset path like in load 
time flow.

The catch though is that we don't go through a rps disable sequence
point across reset. We might be able to do an explict disable/enable
pair now.


Yes.




That way instead of hard coding interrupts to be kept as ARAT_EXPIRED we will 
be able to derive from bits unmasked by GuC in PMINTRMSK.
So before GuC load, we should be resetting RPS interrupts (making PMINRMSK=~0u) 
and then derive interrupts to be kept unmasked by Host.
And then enable RPS. Current state is fine as we know GuC isn't using other PM 
interrupts. (might use some of those in SLPC)

But the set of bits used by guc will be fixed depending on what mode we
are in, and should already be setup by time we reset. You just have a
slightly more elaborate guc interrupts enable/disable sequence, I don't
see that as making anything simpler or more elegant yet - but anticipate
enlightenment.
-Chris


Agree that bits used will be fixed and no need to dynamically determine.
Other bits if needed will be configured by GuC SLPC and in that case Host
RPS flows will not update the registers. So the current implementation looks 
fine.

Thanks
Sagar


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/guc: Release GuC interrupts in i915_guc_submission_disable

2017-03-13 Thread Chris Wilson
On Mon, Mar 13, 2017 at 10:28:34AM +0530, Kamble, Sagar A wrote:
> 
> 
> On 3/12/2017 6:29 PM, Chris Wilson wrote:
> >On Sat, Mar 11, 2017 at 04:17:34AM -, Patchwork wrote:
> >>== Series Details ==
> >>
> >>Series: series starting with [1/3] drm/i915/guc: Release GuC interrupts in 
> >>i915_guc_submission_disable
> >>URL   : https://patchwork.freedesktop.org/series/21090/
> >>State : success
> >>
> >>== Summary ==
> >>
> >>Series 21090v1 Series without cover letter
> >>https://patchwork.freedesktop.org/api/1.0/series/21090/revisions/1/mbox/
> >>
> >>Test kms_pipe_crc_basic:
> >> Subgroup hang-read-crc-pipe-b:
> >> dmesg-warn -> PASS   (fi-byt-j1900)
> >Applied, thanks for the quick fix. It is looking much neater now as well
> >:)
> >-Chris
> 
> Thanks Chris.
> I feel unmasking of ARAT_EXPIRED is hard coding the behavior with GuC.
> Ideally rps enabling should happen post GuC load in reset path like in load 
> time flow.

The catch though is that we don't go through a rps disable sequence
point across reset. We might be able to do an explict disable/enable
pair now.

> That way instead of hard coding interrupts to be kept as ARAT_EXPIRED we will 
> be able to derive from bits unmasked by GuC in PMINTRMSK.
> So before GuC load, we should be resetting RPS interrupts (making 
> PMINRMSK=~0u) and then derive interrupts to be kept unmasked by Host.
> And then enable RPS. Current state is fine as we know GuC isn't using other 
> PM interrupts. (might use some of those in SLPC)

But the set of bits used by guc will be fixed depending on what mode we
are in, and should already be setup by time we reset. You just have a
slightly more elaborate guc interrupts enable/disable sequence, I don't
see that as making anything simpler or more elegant yet - but anticipate
enlightenment.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/guc: Release GuC interrupts in i915_guc_submission_disable

2017-03-12 Thread Kamble, Sagar A



On 3/12/2017 6:29 PM, Chris Wilson wrote:

On Sat, Mar 11, 2017 at 04:17:34AM -, Patchwork wrote:

== Series Details ==

Series: series starting with [1/3] drm/i915/guc: Release GuC interrupts in 
i915_guc_submission_disable
URL   : https://patchwork.freedesktop.org/series/21090/
State : success

== Summary ==

Series 21090v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/21090/revisions/1/mbox/

Test kms_pipe_crc_basic:
 Subgroup hang-read-crc-pipe-b:
 dmesg-warn -> PASS   (fi-byt-j1900)

Applied, thanks for the quick fix. It is looking much neater now as well
:)
-Chris


Thanks Chris.
I feel unmasking of ARAT_EXPIRED is hard coding the behavior with GuC.
Ideally rps enabling should happen post GuC load in reset path like in load 
time flow.
That way instead of hard coding interrupts to be kept as ARAT_EXPIRED we will 
be able to derive from bits unmasked by GuC in PMINTRMSK.
So before GuC load, we should be resetting RPS interrupts (making PMINRMSK=~0u) 
and then derive interrupts to be kept unmasked by Host.
And then enable RPS. Current state is fine as we know GuC isn't using other PM 
interrupts. (might use some of those in SLPC)





___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/guc: Release GuC interrupts in i915_guc_submission_disable

2017-03-12 Thread Chris Wilson
On Sat, Mar 11, 2017 at 04:17:34AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [1/3] drm/i915/guc: Release GuC interrupts in 
> i915_guc_submission_disable
> URL   : https://patchwork.freedesktop.org/series/21090/
> State : success
> 
> == Summary ==
> 
> Series 21090v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/21090/revisions/1/mbox/
> 
> Test kms_pipe_crc_basic:
> Subgroup hang-read-crc-pipe-b:
> dmesg-warn -> PASS   (fi-byt-j1900)

Applied, thanks for the quick fix. It is looking much neater now as well
:)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/guc: Release GuC interrupts in i915_guc_submission_disable

2017-03-10 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915/guc: Release GuC interrupts in 
i915_guc_submission_disable
URL   : https://patchwork.freedesktop.org/series/21090/
State : success

== Summary ==

Series 21090v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/21090/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 463s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 608s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 527s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 575s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 503s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 502s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 436s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 430s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 444s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 511s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 492s
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time: 474s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 486s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 589s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 491s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 542s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 549s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 423s

2095bbc9d234d71fa44fd9181597431e2653058c drm-tip: 2017y-03m-10d-15h-03m-17s UTC 
integration manifest
a8a184e drm/i915/guc: Update rps.pm_intrmsk_mbz in 
guc_interrupts_capture/release
d9379c9 drm/i915: s/pm_intr_keep/pm_intrmsk_mbz
c417696 drm/i915/guc: Release GuC interrupts in i915_guc_submission_disable

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4142/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx