Re: [Intel-gfx] FreeBSD i915 driver update

[randyf]

On Tue, 17 May 2016, Daniel Vetter wrote:


Our ultimate goal is to align closely with the Linux graphics
development community and collaborate with Intel, ATI, and others on
keeping FreeBSD up to date in their product development efforts.


The focus and priority of the i915 driver is obviously Linux, but I
don't see us rejecting patches that help FreeBSD if the patches
generally make sense and don't interfere with the main priority.


What I don't really like is the old approach of trying to abstract away
differences between Linux and *BSD in drmP.h with some screaming macros.
Given the imbalance of manpower between Linux and *BSD I think the best
(and probably only really) approach is to have linux compat types and
wrapper functions for everything. Which seems to be the new plan.

If there's stuff needed above that I think we need to look at in on
a case-by-case basis and figure out what makes sense. For me the crucial
bit isn't so much whether we need to make changes in upstream linux or
not, but whether there's a benefit for usptream too. If bug reports and
bugfixes flow back to linux, then I'm all for it. If it's a one-way street
then frankly I don't care ;-)



  FWIW, this is the approach I have taken with Solaris.  It's probably 
only a 90-95% solution at this time, but that's a hellavalot less work 
than it previously was (though requiring one hellavalot of initial work 
:^P ).



  Cheers!

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

[Intel-gfx] force DP lane count on Broadwell platform

[Sanchez, AdolfoX]

Hello

What PRM registers should be modified to force the source lanes to report 2 
lanes maximum?
Is it enough to modify the registers DP_TP_CTL and DDI_BUF_CTL, or should any 
other register be modified?

Best Regards,
Adolfo Sanchez.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v5 7/7] kms_flip: Change __wait_for_vblank to use helper function.

[Marius Vlad]

On Tue, May 17, 2016 at 10:48:02AM -0400, Robert Foss wrote:
> 
> 
> On 2016-05-17 06:32 AM, Marius Vlad wrote:
> >On Mon, May 16, 2016 at 09:38:32AM -0400, robert.f...@collabora.com wrote:
> >>From: Robert Foss 
> >>
> >>Change __wait_for_vblank() to use kmstest_get_vbl_flag() helper function.
> >>
> >>Signed-off-by: Robert Foss 
> >>---
> >>  tests/kms_flip.c | 8 
> >>  1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >>diff --git a/tests/kms_flip.c b/tests/kms_flip.c
> >>index eda2fcc..0ecca07 100644
> >>--- a/tests/kms_flip.c
> >>+++ b/tests/kms_flip.c
> >>@@ -481,15 +481,15 @@ static int __wait_for_vblank(unsigned int flags, int 
> >>crtc_idx,
> >>  {
> >>drmVBlank wait_vbl;
> >>int ret;
> >>-   unsigned crtc_idx_mask;
> >>+   uint32_t pipe_id_flag;
> >>bool event = !(flags & TEST_VBLANK_BLOCK);
> >>
> >>memset(_vbl, 0, sizeof(wait_vbl));
> >>
> >>-   crtc_idx_mask = crtc_idx << DRM_VBLANK_HIGH_CRTC_SHIFT;
> >>-   igt_assert(!(crtc_idx_mask & ~DRM_VBLANK_HIGH_CRTC_MASK));
> >If crtc_idx is 1 (pipe B), crtc_idx_mask = (1 << DRM_VBLANK_HIGH_CRTC_SHIFT) 
> >= 2.
> >>+   pipe_id_flag = kmstest_get_vbl_flag(crtc_idx);
> >>+   igt_assert(!(pipe_id_flag & ~DRM_VBLANK_HIGH_CRTC_MASK));
> >If crtc_idx is 1 (pipe B), kmstest_get_vbl_flag(crtc_idx) = 
> >DRM_VBLANK_SECONDARY = 0x2000
> >
> >And the assertion fails as !(0x2000 & ~0x003e) = 0.
> >
> >Should kmstest_get_vbl_flag() always return pipe_id << 1?
> 
> From re-reading the pipe id parsing code in drm_irq.c drm_wait_vblank()
> it would seem to me that the assertion is incorrect, specifically for the
> case of _DRM_VBLANK_SECONDARY.
> 
> Supplying the flag _DRM_VBLANK_SECONDARY and setting the high crtc id field
> to 1 fboth seem to be valid ways to communicate the same thing.
Indeed.
> 
>   flags = vblwait->request.type & _DRM_VBLANK_FLAGS_MASK;
>   high_pipe = (vblwait->request.type &_DRM_VBLANK_HIGH_CRTC_MASK);
>   if (high_pipe)
>   pipe = high_pipe >> _DRM_VBLANK_HIGH_CRTC_SHIFT;
>   else
>   pipe = flags & _DRM_VBLANK_SECONDARY ? 1 : 0;
> 
> 
> Maybe adding correct and more thorough assertion to kmstest_get_vbl_flag()
> and removing the failing assertion is the way forward.
Sounds reasonable to me, though I assume that the assertion had/has
some point in determining that you have a valid crtc_idx.
> 
> >
> >>
> >>-   wait_vbl.request.type = crtc_idx_mask;
> >>+   wait_vbl.request.type = pipe_id_flag;
> >>if (flags & TEST_VBLANK_ABSOLUTE)
> >>wait_vbl.request.type |= DRM_VBLANK_ABSOLUTE;
> >>else
> >>--
> >>2.7.4
> >>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub

[Daniel Vetter]

On Tue, May 17, 2016 at 08:19:32PM +0200, Takashi Iwai wrote:
> On Tue, 17 May 2016 18:23:40 +0200,
> Daniel Vetter wrote:
> > 
> > On Tue, May 17, 2016 at 6:18 PM, Daniel Vetter  wrote:
> > > On Tue, May 17, 2016 at 3:20 PM, Takashi Iwai  wrote:
> > >>> Ok, I looked at patch 3, and that indeed would lead to trouble without
> > >>> patch 1. But the real trouble is the unconditional wait_completion in
> > >>> there - blocking for another driver to complete loading from a driver 
> > >>> load
> > >>> function is a no-go. The correct way to do this is to bail out with
> > >>> EPROBE_DEFER if not all the parts are available there. Also, throw out
> > >>> that request_module.
> > >>>
> > >>> By bailing out with EPROBE_DEFER you avoid deadlocks, and the driver 
> > >>> core
> > >>> also knows what's going on. Which is incidentally what's used to
> > >>> implicitly order suspend/resume. Driver core will restart your probe as
> > >>> soon as some new devices/drivers have registers (assuming that hopefully
> > >>> then you're unblocking), but if you're unlucky your driver can go 
> > >>> through
> > >>> that loop a few times.
> > >>>
> > >>> But that was just a very quick look, we definitely shouldn't need any
> > >>> wait_completion in driver load to handle cross-module depencies.
> > >>
> > >> Yeah, I admit that wait_completion() is hackish.  OTOH, EPROBE_DEFER
> > >> doesn't work in the case of HD-audio because we want to give up
> > >> binding and continue without i915 but only with onboard audio, instead
> > >> of endlessly reprobing for the never-appearing component.  The i915
> > >> binding is no hard dependency; i.e. it isn't (always) mandatory, and
> > >> EPROBE_DEFER can't handle such a fallback, AFAIK.
> > >>
> > >> If there is a good way to deal with it, please let me know.  I'd love
> > >> to rewrite to a cleaner way.
> > >
> > > The only way to deal with that is to split the driver into two, and
> > > hotplug them individually. Fundamentally any approach where you need
> > > to know whether i915 shows up or not and act accordingly is just plain
> > > flawed, there's no way around it. That's also why EPROBE_DEFER doesn't
> > > bother dealing with it.
> > >
> > > Imo if you have the sound side of hdmi/dp audio, then just
> > > EPROBE_DEFER until i915 is loaded (assuming it's not disabled through
> > > nomodeset or Kconfig). If it's not there then continue without it (and
> > > without hdmi/dp audio ofc). Trying to be clever just means we need to
> > > hand roll things all over the place all the time. We have some code on
> > > earlier platforms for runtime clock adjustements (on ironlake) in
> > > i915.ko, and I really don't want that kind of hacks any more.
> > 
> > In case you don't believe me that your hack is broken: I often boot
> > with i915 blacklisted, so that I can set up netconsole and other
> > instrumenting and then load it again with modeset. Until that's done
> > snd-hda will be stuck in that wait_completion.
> 
> Yes, but it has a fallback after some long timeout.  Then at least
> user would see if binding failure happens and going without HDMI/DP.
> 
> > You really can't ever
> > know when userspace or the user decides to finally load the driver,
> > and the only reasonable thing to do is to defer until everything you
> > need is there. Except of course when the user told you it's not going
> > to show up through nomodeset or Kconfig knobs, but that's kinda the
> > exception.
> > 
> > Imo the best course forward would be:
> > - Implement EPROBE_DEFER correctly in snd-hda (i.e. no
> > wait_completion, no deferred work or anything like that, just return
> > -EPROBE_DEFER when i915 isn't there yet).
> 
> We actually don't need EPROBE_DEFER, either.  The component master
> bind would take care of that already.  I used wait_for_completion()
> just because I didn't want the hda-i915 binder API function.  If it
> takes the function to be continued, master binder can call it after
> binding with i915 properly.

Well component does a deferred probe internally afaik.

> > - Add a bail-out option if CONFIG_DRM_I915 isn't enabled to snd-hda.
> 
> You can forget about Kconfig.  It's already handled.  No relevant code
> will be executed when CONFIG_DRM_I915 isn't set.
> 
> > - Add a runtime bail-out for nomodeset/vgacon_text_force() to snd-hda.
> 
> Yes, that's an easy part.
> 
> > That should cover everyone's debug needs, while giving us a clean
> > architecture moving forward. Thoughts?
> 
> But this doesn't cover all cases.  As you mentioned,  what if user
> would blacklist i915, or set i915.modeset=0?  In my patch, HD-audio
> tries to continue at least some timeout.

My opinion is that you can't decide correctly. Either the timeout is too
long, and you have users complaining that audio doesn't work because the
driver doesn't complete loading. Or it's too short, and you break
EDEFER_PROBING. I guess if you want you can code up a timeout in snd-hda,
but since patch 1 

Re: [Intel-gfx] [PATCH 01/21] drm/i915: Fix BXT min_pixclk after state readout

[Imre Deak]

On Tue, 2016-05-17 at 21:21 +0300, Ville Syrjälä wrote:
> On Tue, May 17, 2016 at 09:09:15PM +0300, Imre Deak wrote:
> > On Fri, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä 
> > > 
> > > commit 4e5ca60fd35a ("drm/i915: Use ilk_max_pixel_rate() for BXT
> > > cdclk calculation")
> > > tried to change BXT to use ilk_max_pixel_rate() to compute the
> > > pipe pixel rate. I failed to notice that there was another place
> > > in the state readout code that needs the same treatment. So let's
> > > change that one too.
> > > 
> > > Should probably just change things to always compuyte the pipe
> > > pixel
> > > rates, instead of just doing on platforms that can change cdclk
> > > dynamically. But for now let's just move BXT fully over to the
> > > side that uses ilk_pipe_pixel_rate().
> > > 
> > > Cc: Jani Nikula 
> > > Fixes: 4e5ca60fd35a ("drm/i915: Use ilk_max_pixel_rate() for BXT
> > > cdclk calculation")
> > > Signed-off-by: Ville Syrjälä 
> > 
> > Reviewed-by: Imre Deak 
> > 
> > Btw, there is also skl_pipe_pixel_rate() that needs the same
> > change.
> 
> Oh dear. Just how many of these things do we need? I'll send a patch
> to just
> nuke the skl version.

Ohm, I guess I was wrong. For WM we only need to adjust for pipe
scaling not plane scaling if I read the spec correctly. But removing
duplicate helpers if possible doesn't hurt in any case.

> > 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 14 ++
> > >  1 file changed, 6 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index c5f0a6f30879..cc9a8b42fbc6 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -15748,18 +15748,16 @@ static void
> > > intel_modeset_readout_hw_state(struct drm_device *dev)
> > >   if (crtc_state->base.active) {
> > >   dev_priv->active_crtcs |= 1 << crtc-
> > > >pipe;
> > >  
> > > - if (IS_BROADWELL(dev_priv)) {
> > > + if (IS_BROXTON(dev_priv) ||
> > > IS_BROADWELL(dev_priv))
> > >   pixclk =
> > > ilk_pipe_pixel_rate(crtc_state);
> > > -
> > > - /* pixel rate mustn't exceed 95%
> > > of cdclk with IPS on BDW */
> > > - if (crtc_state->ips_enabled)
> > > - pixclk =
> > > DIV_ROUND_UP(pixclk * 100, 95);
> > > - } else if (IS_VALLEYVIEW(dev_priv) ||
> > > -    IS_CHERRYVIEW(dev_priv) ||
> > > -    IS_BROXTON(dev_priv))
> > > + else if (IS_VALLEYVIEW(dev_priv) ||
> > > IS_CHERRYVIEW(dev_priv))
> > >   pixclk = crtc_state-
> > > >base.adjusted_mode.crtc_clock;
> > >   else
> > >   WARN_ON(dev_priv-
> > > >display.modeset_calc_cdclk);
> > > +
> > > + /* pixel rate mustn't exceed 95% of
> > > cdclk with IPS on BDW */
> > > + if (IS_BROADWELL(dev_priv) &&
> > > crtc_state->ips_enabled)
> > > + pixclk = DIV_ROUND_UP(pixclk *
> > > 100, 95);
> > >   }
> > >  
> > >   dev_priv->min_pixclk[crtc->pipe] = pixclk;
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/21] drm/i915: Fix BXT min_pixclk after state readout

[Ville Syrjälä]

On Tue, May 17, 2016 at 09:09:15PM +0300, Imre Deak wrote:
> On Fri, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > commit 4e5ca60fd35a ("drm/i915: Use ilk_max_pixel_rate() for BXT cdclk 
> > calculation")
> > tried to change BXT to use ilk_max_pixel_rate() to compute the
> > pipe pixel rate. I failed to notice that there was another place
> > in the state readout code that needs the same treatment. So let's
> > change that one too.
> > 
> > Should probably just change things to always compuyte the pipe pixel
> > rates, instead of just doing on platforms that can change cdclk
> > dynamically. But for now let's just move BXT fully over to the
> > side that uses ilk_pipe_pixel_rate().
> > 
> > Cc: Jani Nikula 
> > Fixes: 4e5ca60fd35a ("drm/i915: Use ilk_max_pixel_rate() for BXT cdclk 
> > calculation")
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Imre Deak 
> 
> Btw, there is also skl_pipe_pixel_rate() that needs the same change.

Oh dear. Just how many of these things do we need? I'll send a patch to just
nuke the skl version.

> 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 14 ++
> >  1 file changed, 6 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index c5f0a6f30879..cc9a8b42fbc6 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15748,18 +15748,16 @@ static void intel_modeset_readout_hw_state(struct 
> > drm_device *dev)
> >     if (crtc_state->base.active) {
> >     dev_priv->active_crtcs |= 1 << crtc->pipe;
> >  
> > -   if (IS_BROADWELL(dev_priv)) {
> > +   if (IS_BROXTON(dev_priv) || IS_BROADWELL(dev_priv))
> >     pixclk = ilk_pipe_pixel_rate(crtc_state);
> > -
> > -   /* pixel rate mustn't exceed 95% of cdclk with 
> > IPS on BDW */
> > -   if (crtc_state->ips_enabled)
> > -   pixclk = DIV_ROUND_UP(pixclk * 100, 95);
> > -   } else if (IS_VALLEYVIEW(dev_priv) ||
> > -      IS_CHERRYVIEW(dev_priv) ||
> > -      IS_BROXTON(dev_priv))
> > +   else if (IS_VALLEYVIEW(dev_priv) || 
> > IS_CHERRYVIEW(dev_priv))
> >     pixclk = 
> > crtc_state->base.adjusted_mode.crtc_clock;
> >     else
> >     WARN_ON(dev_priv->display.modeset_calc_cdclk);
> > +
> > +   /* pixel rate mustn't exceed 95% of cdclk with IPS on 
> > BDW */
> > +   if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
> > +   pixclk = DIV_ROUND_UP(pixclk * 100, 95);
> >     }
> >  
> >     dev_priv->min_pixclk[crtc->pipe] = pixclk;

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub

[Takashi Iwai]

On Tue, 17 May 2016 18:23:40 +0200,
Daniel Vetter wrote:
> 
> On Tue, May 17, 2016 at 6:18 PM, Daniel Vetter  wrote:
> > On Tue, May 17, 2016 at 3:20 PM, Takashi Iwai  wrote:
> >>> Ok, I looked at patch 3, and that indeed would lead to trouble without
> >>> patch 1. But the real trouble is the unconditional wait_completion in
> >>> there - blocking for another driver to complete loading from a driver load
> >>> function is a no-go. The correct way to do this is to bail out with
> >>> EPROBE_DEFER if not all the parts are available there. Also, throw out
> >>> that request_module.
> >>>
> >>> By bailing out with EPROBE_DEFER you avoid deadlocks, and the driver core
> >>> also knows what's going on. Which is incidentally what's used to
> >>> implicitly order suspend/resume. Driver core will restart your probe as
> >>> soon as some new devices/drivers have registers (assuming that hopefully
> >>> then you're unblocking), but if you're unlucky your driver can go through
> >>> that loop a few times.
> >>>
> >>> But that was just a very quick look, we definitely shouldn't need any
> >>> wait_completion in driver load to handle cross-module depencies.
> >>
> >> Yeah, I admit that wait_completion() is hackish.  OTOH, EPROBE_DEFER
> >> doesn't work in the case of HD-audio because we want to give up
> >> binding and continue without i915 but only with onboard audio, instead
> >> of endlessly reprobing for the never-appearing component.  The i915
> >> binding is no hard dependency; i.e. it isn't (always) mandatory, and
> >> EPROBE_DEFER can't handle such a fallback, AFAIK.
> >>
> >> If there is a good way to deal with it, please let me know.  I'd love
> >> to rewrite to a cleaner way.
> >
> > The only way to deal with that is to split the driver into two, and
> > hotplug them individually. Fundamentally any approach where you need
> > to know whether i915 shows up or not and act accordingly is just plain
> > flawed, there's no way around it. That's also why EPROBE_DEFER doesn't
> > bother dealing with it.
> >
> > Imo if you have the sound side of hdmi/dp audio, then just
> > EPROBE_DEFER until i915 is loaded (assuming it's not disabled through
> > nomodeset or Kconfig). If it's not there then continue without it (and
> > without hdmi/dp audio ofc). Trying to be clever just means we need to
> > hand roll things all over the place all the time. We have some code on
> > earlier platforms for runtime clock adjustements (on ironlake) in
> > i915.ko, and I really don't want that kind of hacks any more.
> 
> In case you don't believe me that your hack is broken: I often boot
> with i915 blacklisted, so that I can set up netconsole and other
> instrumenting and then load it again with modeset. Until that's done
> snd-hda will be stuck in that wait_completion.

Yes, but it has a fallback after some long timeout.  Then at least
user would see if binding failure happens and going without HDMI/DP.

> You really can't ever
> know when userspace or the user decides to finally load the driver,
> and the only reasonable thing to do is to defer until everything you
> need is there. Except of course when the user told you it's not going
> to show up through nomodeset or Kconfig knobs, but that's kinda the
> exception.
> 
> Imo the best course forward would be:
> - Implement EPROBE_DEFER correctly in snd-hda (i.e. no
> wait_completion, no deferred work or anything like that, just return
> -EPROBE_DEFER when i915 isn't there yet).

We actually don't need EPROBE_DEFER, either.  The component master
bind would take care of that already.  I used wait_for_completion()
just because I didn't want the hda-i915 binder API function.  If it
takes the function to be continued, master binder can call it after
binding with i915 properly.

> - Add a bail-out option if CONFIG_DRM_I915 isn't enabled to snd-hda.

You can forget about Kconfig.  It's already handled.  No relevant code
will be executed when CONFIG_DRM_I915 isn't set.

> - Add a runtime bail-out for nomodeset/vgacon_text_force() to snd-hda.

Yes, that's an easy part.

> That should cover everyone's debug needs, while giving us a clean
> architecture moving forward. Thoughts?

But this doesn't cover all cases.  As you mentioned,  what if user
would blacklist i915, or set i915.modeset=0?  In my patch, HD-audio
tries to continue at least some timeout.


thanks,

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

Re: [Intel-gfx] [PATCH 01/21] drm/i915: Fix BXT min_pixclk after state readout

[Imre Deak]

On Fri, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> commit 4e5ca60fd35a ("drm/i915: Use ilk_max_pixel_rate() for BXT cdclk 
> calculation")
> tried to change BXT to use ilk_max_pixel_rate() to compute the
> pipe pixel rate. I failed to notice that there was another place
> in the state readout code that needs the same treatment. So let's
> change that one too.
> 
> Should probably just change things to always compuyte the pipe pixel
> rates, instead of just doing on platforms that can change cdclk
> dynamically. But for now let's just move BXT fully over to the
> side that uses ilk_pipe_pixel_rate().
> 
> Cc: Jani Nikula 
> Fixes: 4e5ca60fd35a ("drm/i915: Use ilk_max_pixel_rate() for BXT cdclk 
> calculation")
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

Btw, there is also skl_pipe_pixel_rate() that needs the same change.

> ---
>  drivers/gpu/drm/i915/intel_display.c | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index c5f0a6f30879..cc9a8b42fbc6 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15748,18 +15748,16 @@ static void intel_modeset_readout_hw_state(struct 
> drm_device *dev)
>   if (crtc_state->base.active) {
>   dev_priv->active_crtcs |= 1 << crtc->pipe;
>  
> - if (IS_BROADWELL(dev_priv)) {
> + if (IS_BROXTON(dev_priv) || IS_BROADWELL(dev_priv))
>   pixclk = ilk_pipe_pixel_rate(crtc_state);
> -
> - /* pixel rate mustn't exceed 95% of cdclk with 
> IPS on BDW */
> - if (crtc_state->ips_enabled)
> - pixclk = DIV_ROUND_UP(pixclk * 100, 95);
> - } else if (IS_VALLEYVIEW(dev_priv) ||
> -    IS_CHERRYVIEW(dev_priv) ||
> -    IS_BROXTON(dev_priv))
> + else if (IS_VALLEYVIEW(dev_priv) || 
> IS_CHERRYVIEW(dev_priv))
>   pixclk = 
> crtc_state->base.adjusted_mode.crtc_clock;
>   else
>   WARN_ON(dev_priv->display.modeset_calc_cdclk);
> +
> + /* pixel rate mustn't exceed 95% of cdclk with IPS on 
> BDW */
> + if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
> + pixclk = DIV_ROUND_UP(pixclk * 100, 95);
>   }
>  
>   dev_priv->min_pixclk[crtc->pipe] = pixclk;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub

[Takashi Iwai]

On Tue, 17 May 2016 18:18:27 +0200,
Daniel Vetter wrote:
> 
> On Tue, May 17, 2016 at 3:20 PM, Takashi Iwai  wrote:
> >> Ok, I looked at patch 3, and that indeed would lead to trouble without
> >> patch 1. But the real trouble is the unconditional wait_completion in
> >> there - blocking for another driver to complete loading from a driver load
> >> function is a no-go. The correct way to do this is to bail out with
> >> EPROBE_DEFER if not all the parts are available there. Also, throw out
> >> that request_module.
> >>
> >> By bailing out with EPROBE_DEFER you avoid deadlocks, and the driver core
> >> also knows what's going on. Which is incidentally what's used to
> >> implicitly order suspend/resume. Driver core will restart your probe as
> >> soon as some new devices/drivers have registers (assuming that hopefully
> >> then you're unblocking), but if you're unlucky your driver can go through
> >> that loop a few times.
> >>
> >> But that was just a very quick look, we definitely shouldn't need any
> >> wait_completion in driver load to handle cross-module depencies.
> >
> > Yeah, I admit that wait_completion() is hackish.  OTOH, EPROBE_DEFER
> > doesn't work in the case of HD-audio because we want to give up
> > binding and continue without i915 but only with onboard audio, instead
> > of endlessly reprobing for the never-appearing component.  The i915
> > binding is no hard dependency; i.e. it isn't (always) mandatory, and
> > EPROBE_DEFER can't handle such a fallback, AFAIK.
> >
> > If there is a good way to deal with it, please let me know.  I'd love
> > to rewrite to a cleaner way.
> 
> The only way to deal with that is to split the driver into two, and
> hotplug them individually. Fundamentally any approach where you need
> to know whether i915 shows up or not and act accordingly is just plain
> flawed, there's no way around it. That's also why EPROBE_DEFER doesn't
> bother dealing with it.
> 
> Imo if you have the sound side of hdmi/dp audio, then just
> EPROBE_DEFER until i915 is loaded (assuming it's not disabled through
> nomodeset or Kconfig).

One of the problems that make things complicated is: we don't know
whether there is HDMI/DP codec present before probing on the bus.
SKL has a common HD-audio bus, and it might be that there is no i915
HDMI codec on it but only the onboard analog codec.  However, for
probing the HDMI codec itself, i915 has to be initialized beforehand.

So, your assumption "if you have the sound side of hdmi/dp audio":
this can't be known before i915 is loaded and the HDMI/DP audio is
probed.  It's a kind of chicken and egg problem.

Yes, we can know at least whether i915 graphics is present on PCI bus,
and we already check it for Nvidia/AMD hybrid systems.  But it doesn't
give a chance to know whether i915 gfx is available at all (nomodeset
or whatever disablement).  This is why the whole this patchset was
invented.

The rest -- how to bind things -- is a matter of implementation
details.  Once when we have a material, we can write more elegantly.

But, if there is no disablement notification, EPROBE_DEFER can't work
well with the fallback mechanism.

> If it's not there then continue without it (and
> without hdmi/dp audio ofc). Trying to be clever just means we need to
> hand roll things all over the place all the time. We have some code on
> earlier platforms for runtime clock adjustements (on ironlake) in
> i915.ko, and I really don't want that kind of hacks any more.

Yes, I know of the pains.  A better implementation is always welcome,
and I'm not willing to stick with my current patches.


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

[Intel-gfx] [PULL] topic/drm-misc

[Daniel Vetter]

Hi Dave,

Ok as promised heres the patches to do some function interface refactoring
across the tree. I've double check and run gcc on x86 and arm, but please
also check that nothing crept in meanwhile before pushing out the merge.

Otherwise a few more misc patches, plus the 2 duct-tape patches for dp mst
backporting from Lyude.

Note that I spotted one tegra patch in-flight which will conflict, I asked
for that to be rebased already.

Cheers, Daniel


The following changes since commit 99ee87295017e36abb6925e6139ca303cb55aee7:

  Merge tag 'topic/drm-misc-2016-05-13' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2016-05-17 07:06:14 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-05-17

for you to fetch changes up to 255f0e7c418ad95a4baeda017ae6182ba9b3c423:

  drm/fb_helper: Fix references to dev->mode_config.num_connector (2016-05-17 
15:44:41 +0200)


Chris Wilson (1):
  drm: Remove unused drm_device from drm_gem_object_lookup()

Dan Carpenter (1):
  drm/exynos/hdmi: add a missing tab

Daniel Vetter (3):
  drm: Drop crtc argument from __drm_atomic_helper_crtc_destroy_state
  drm: Drop plane argument from __drm_atomic_helper_plane_destroy_state
  drm: Drop connector argument from 
__drm_atomic_helper_connector_destroy_state

Gerd Hoffmann (1):
  qxl: catch qxlfb_create_pinned_object failures

Lyude (2):
  drm/i915/fbdev: Fix num_connector references in intel_fb_initial_config()
  drm/fb_helper: Fix references to dev->mode_config.num_connector

Noralf Trønnes (2):
  drm/fb-cma-helper: Use const for drm_framebuffer_funcs argument
  drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()

 drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  3 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 10 +++
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  |  2 +-
 drivers/gpu/drm/armada/armada_crtc.c   |  2 +-
 drivers/gpu/drm/armada/armada_fb.c |  2 +-
 drivers/gpu/drm/armada/armada_gem.c|  6 ++---
 drivers/gpu/drm/armada/armada_gem.h|  4 +--
 drivers/gpu/drm/ast/ast_main.c |  4 +--
 drivers/gpu/drm/ast/ast_mode.c |  2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |  2 +-
 drivers/gpu/drm/bochs/bochs_mm.c   |  4 +--
 drivers/gpu/drm/cirrus/cirrus_main.c   |  4 +--
 drivers/gpu/drm/drm_atomic_helper.c| 25 +++--
 drivers/gpu/drm/drm_fb_cma_helper.c| 37 +++---
 drivers/gpu/drm/drm_fb_helper.c|  5 ++--
 drivers/gpu/drm/drm_gem.c  | 14 +++---
 drivers/gpu/drm/drm_gem_cma_helper.c   |  2 +-
 drivers/gpu/drm/drm_prime.c|  2 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c  |  8 +++---
 drivers/gpu/drm/exynos/exynos_drm_fb.c |  3 +--
 drivers/gpu/drm/exynos/exynos_drm_gem.c| 10 +++
 drivers/gpu/drm/exynos/exynos_drm_plane.c  |  2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   |  2 +-
 drivers/gpu/drm/gma500/framebuffer.c   |  2 +-
 drivers/gpu/drm/gma500/gem.c   |  2 +-
 drivers/gpu/drm/gma500/gma_display.c   |  2 +-
 drivers/gpu/drm/i915/i915_gem.c| 22 +++
 drivers/gpu/drm/i915/i915_gem_tiling.c |  4 +--
 drivers/gpu/drm/i915/intel_display.c   |  7 +++--
 drivers/gpu/drm/i915/intel_fbdev.c |  6 ++---
 drivers/gpu/drm/i915/intel_overlay.c   |  2 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c|  2 +-
 drivers/gpu/drm/mediatek/mtk_drm_plane.c   |  2 +-
 drivers/gpu/drm/mgag200/mgag200_cursor.c   |  2 +-
 drivers/gpu/drm/mgag200/mgag200_main.c |  4 +--
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c   |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c   |  2 +-
 drivers/gpu/drm/msm/msm_drv.c  |  6 ++---
 drivers/gpu/drm/msm/msm_fb.c   |  3 +--
 drivers/gpu/drm/msm/msm_gem.c  |  2 +-
 drivers/gpu/drm/nouveau/dispnv04/crtc.c|  2 +-
 drivers/gpu/drm/nouveau/nouveau_display.c  |  4 +--
 drivers/gpu/drm/nouveau/nouveau_gem.c  |  8 +++---
 drivers/gpu/drm/nouveau/nv50_display.c |  2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c |  6 ++---
 drivers/gpu/drm/omapdrm/omap_drv.h |  4 +--
 drivers/gpu/drm/omapdrm/omap_fb.c  |  2 +-
 drivers/gpu/drm/omapdrm/omap_gem.c |  2 +-
 drivers/gpu/drm/omapdrm/omap_plane.c   |  2 +-
 drivers/gpu/drm/qxl/qxl_display.c  |  6 +++--
 drivers/gpu/drm/qxl/qxl_dumb.c |  2 +-
 

[Intel-gfx] ✗ Ro.CI.BAT: failure for wait_for and wait_until_reg

[Patchwork]

== Series Details ==

Series: wait_for and wait_until_reg
URL   : https://patchwork.freedesktop.org/series/7305/
State : failure

== Summary ==

Series 7305v1 wait_for and wait_until_reg
http://patchwork.freedesktop.org/api/1.0/series/7305/revisions/1/mbox

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (ro-hsw-i7-4770r)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-c:
pass   -> DMESG-WARN (ro-ivb-i7-3770)

fi-bdw-i7-5557u  total:219  pass:206  dwarn:0   dfail:0   fail:0   skip:13 
fi-bsw-n3050 total:218  pass:174  dwarn:0   dfail:0   fail:2   skip:42 
fi-hsw-i7-4770k  total:219  pass:198  dwarn:0   dfail:0   fail:0   skip:21 
fi-hsw-i7-4770r  total:219  pass:193  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-y total:219  pass:190  dwarn:2   dfail:0   fail:2   skip:25 
fi-skl-i7-6700k  total:219  pass:191  dwarn:0   dfail:0   fail:0   skip:28 
ro-bdw-i5-5250u  total:219  pass:181  dwarn:0   dfail:0   fail:0   skip:38 
ro-bdw-i7-5557U  total:219  pass:206  dwarn:0   dfail:0   fail:0   skip:13 
ro-bdw-i7-5600u  total:219  pass:187  dwarn:0   dfail:0   fail:0   skip:32 
ro-byt-n2820 total:218  pass:174  dwarn:0   dfail:0   fail:3   skip:41 
ro-hsw-i3-4010u  total:218  pass:193  dwarn:0   dfail:0   fail:0   skip:25 
ro-hsw-i7-4770r  total:219  pass:193  dwarn:0   dfail:0   fail:1   skip:25 
ro-ilk-i7-620lm  total:219  pass:151  dwarn:0   dfail:0   fail:1   skip:67 
ro-ilk1-i5-650   total:214  pass:151  dwarn:0   dfail:0   fail:2   skip:61 
ro-ivb-i7-3770   total:219  pass:182  dwarn:1   dfail:0   fail:0   skip:36 
ro-ivb2-i7-3770  total:219  pass:187  dwarn:0   dfail:0   fail:0   skip:32 
ro-skl-i7-6700hq total:214  pass:189  dwarn:0   dfail:0   fail:0   skip:25 
ro-snb-i7-2620M  total:219  pass:177  dwarn:0   dfail:0   fail:1   skip:41 
fi-byt-n2820 failed to connect after reboot
fi-snb-i7-2600 failed to connect after reboot
ro-bsw-n3050 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_924/

68c6a6d drm-intel-nightly: 2016y-05m-17d-13h-59m-27s UTC integration manifest
bfe366e drm/i915/debug: Warn when waiting on condition timeouts
eda7126 drm/i915: Use wait_until_reg macros
6064898 drm/i915: Introduce wait_until_reg
6a87001 drm/i915: Take longer naps in wait_for
2bc34cd drm/i915: Spin opportunistically in wait_for
003241f drm/i915: Use milliseconds in _wait_for macro
c98838e drm/i915: Remove the wait_for_us macro

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

[Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [1/4,v3] drm/i915: Early exit from rps worker if GPU is idle (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [1/4,v3] drm/i915: Early exit from rps worker if 
GPU is idle (rev3)
URL   : https://patchwork.freedesktop.org/series/7297/
State : success

== Summary ==

Series 7297v3 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7297/revisions/3/mbox

Test drv_hangman:
Subgroup error-state-basic:
fail   -> PASS   (ro-ilk1-i5-650)

fi-bdw-i7-5557u  total:219  pass:206  dwarn:0   dfail:0   fail:0   skip:13 
fi-bsw-n3050 total:218  pass:174  dwarn:0   dfail:0   fail:2   skip:42 
fi-hsw-i7-4770k  total:219  pass:198  dwarn:0   dfail:0   fail:0   skip:21 
fi-hsw-i7-4770r  total:219  pass:193  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-y total:219  pass:191  dwarn:1   dfail:0   fail:2   skip:25 
fi-skl-i7-6700k  total:219  pass:191  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-i7-2600   total:219  pass:176  dwarn:0   dfail:0   fail:0   skip:43 
ro-bdw-i5-5250u  total:219  pass:181  dwarn:0   dfail:0   fail:0   skip:38 
ro-bdw-i7-5557U  total:219  pass:206  dwarn:0   dfail:0   fail:0   skip:13 
ro-bdw-i7-5600u  total:219  pass:187  dwarn:0   dfail:0   fail:0   skip:32 
ro-bsw-n3050 total:219  pass:175  dwarn:0   dfail:0   fail:2   skip:42 
ro-byt-n2820 total:218  pass:174  dwarn:0   dfail:0   fail:3   skip:41 
ro-hsw-i3-4010u  total:218  pass:193  dwarn:0   dfail:0   fail:0   skip:25 
ro-hsw-i7-4770r  total:219  pass:194  dwarn:0   dfail:0   fail:0   skip:25 
ro-ilk-i7-620lm  total:219  pass:151  dwarn:0   dfail:0   fail:1   skip:67 
ro-ilk1-i5-650   total:214  pass:152  dwarn:0   dfail:0   fail:1   skip:61 
ro-ivb-i7-3770   total:219  pass:183  dwarn:0   dfail:0   fail:0   skip:36 
ro-ivb2-i7-3770  total:219  pass:187  dwarn:0   dfail:0   fail:0   skip:32 
ro-skl-i7-6700hq total:214  pass:189  dwarn:0   dfail:0   fail:0   skip:25 
ro-snb-i7-2620M  total:219  pass:177  dwarn:0   dfail:0   fail:1   skip:41 
fi-byt-n2820 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_923/

68c6a6d drm-intel-nightly: 2016y-05m-17d-13h-59m-27s UTC integration manifest
972b6ae drm/i915: Extract common get/set frequency limits functions
0f781e4 drm/i915: Allow controlling idle frequency from userspace
7b787cb drm/i915: Set softmin frequency when going from idle to busy
228aa30 drm/i915: Early exit from rps worker if GPU is idle

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

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub

[Daniel Vetter]

On Tue, May 17, 2016 at 6:18 PM, Daniel Vetter  wrote:
> On Tue, May 17, 2016 at 3:20 PM, Takashi Iwai  wrote:
>>> Ok, I looked at patch 3, and that indeed would lead to trouble without
>>> patch 1. But the real trouble is the unconditional wait_completion in
>>> there - blocking for another driver to complete loading from a driver load
>>> function is a no-go. The correct way to do this is to bail out with
>>> EPROBE_DEFER if not all the parts are available there. Also, throw out
>>> that request_module.
>>>
>>> By bailing out with EPROBE_DEFER you avoid deadlocks, and the driver core
>>> also knows what's going on. Which is incidentally what's used to
>>> implicitly order suspend/resume. Driver core will restart your probe as
>>> soon as some new devices/drivers have registers (assuming that hopefully
>>> then you're unblocking), but if you're unlucky your driver can go through
>>> that loop a few times.
>>>
>>> But that was just a very quick look, we definitely shouldn't need any
>>> wait_completion in driver load to handle cross-module depencies.
>>
>> Yeah, I admit that wait_completion() is hackish.  OTOH, EPROBE_DEFER
>> doesn't work in the case of HD-audio because we want to give up
>> binding and continue without i915 but only with onboard audio, instead
>> of endlessly reprobing for the never-appearing component.  The i915
>> binding is no hard dependency; i.e. it isn't (always) mandatory, and
>> EPROBE_DEFER can't handle such a fallback, AFAIK.
>>
>> If there is a good way to deal with it, please let me know.  I'd love
>> to rewrite to a cleaner way.
>
> The only way to deal with that is to split the driver into two, and
> hotplug them individually. Fundamentally any approach where you need
> to know whether i915 shows up or not and act accordingly is just plain
> flawed, there's no way around it. That's also why EPROBE_DEFER doesn't
> bother dealing with it.
>
> Imo if you have the sound side of hdmi/dp audio, then just
> EPROBE_DEFER until i915 is loaded (assuming it's not disabled through
> nomodeset or Kconfig). If it's not there then continue without it (and
> without hdmi/dp audio ofc). Trying to be clever just means we need to
> hand roll things all over the place all the time. We have some code on
> earlier platforms for runtime clock adjustements (on ironlake) in
> i915.ko, and I really don't want that kind of hacks any more.

In case you don't believe me that your hack is broken: I often boot
with i915 blacklisted, so that I can set up netconsole and other
instrumenting and then load it again with modeset. Until that's done
snd-hda will be stuck in that wait_completion. You really can't ever
know when userspace or the user decides to finally load the driver,
and the only reasonable thing to do is to defer until everything you
need is there. Except of course when the user told you it's not going
to show up through nomodeset or Kconfig knobs, but that's kinda the
exception.

Imo the best course forward would be:
- Implement EPROBE_DEFER correctly in snd-hda (i.e. no
wait_completion, no deferred work or anything like that, just return
-EPROBE_DEFER when i915 isn't there yet).
- Add a bail-out option if CONFIG_DRM_I915 isn't enabled to snd-hda.
- Add a runtime bail-out for nomodeset/vgacon_text_force() to snd-hda.

That should cover everyone's debug needs, while giving us a clean
architecture moving forward. Thoughts?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub

[Daniel Vetter]

On Tue, May 17, 2016 at 3:20 PM, Takashi Iwai  wrote:
>> Ok, I looked at patch 3, and that indeed would lead to trouble without
>> patch 1. But the real trouble is the unconditional wait_completion in
>> there - blocking for another driver to complete loading from a driver load
>> function is a no-go. The correct way to do this is to bail out with
>> EPROBE_DEFER if not all the parts are available there. Also, throw out
>> that request_module.
>>
>> By bailing out with EPROBE_DEFER you avoid deadlocks, and the driver core
>> also knows what's going on. Which is incidentally what's used to
>> implicitly order suspend/resume. Driver core will restart your probe as
>> soon as some new devices/drivers have registers (assuming that hopefully
>> then you're unblocking), but if you're unlucky your driver can go through
>> that loop a few times.
>>
>> But that was just a very quick look, we definitely shouldn't need any
>> wait_completion in driver load to handle cross-module depencies.
>
> Yeah, I admit that wait_completion() is hackish.  OTOH, EPROBE_DEFER
> doesn't work in the case of HD-audio because we want to give up
> binding and continue without i915 but only with onboard audio, instead
> of endlessly reprobing for the never-appearing component.  The i915
> binding is no hard dependency; i.e. it isn't (always) mandatory, and
> EPROBE_DEFER can't handle such a fallback, AFAIK.
>
> If there is a good way to deal with it, please let me know.  I'd love
> to rewrite to a cleaner way.

The only way to deal with that is to split the driver into two, and
hotplug them individually. Fundamentally any approach where you need
to know whether i915 shows up or not and act accordingly is just plain
flawed, there's no way around it. That's also why EPROBE_DEFER doesn't
bother dealing with it.

Imo if you have the sound side of hdmi/dp audio, then just
EPROBE_DEFER until i915 is loaded (assuming it's not disabled through
nomodeset or Kconfig). If it's not there then continue without it (and
without hdmi/dp audio ofc). Trying to be clever just means we need to
hand roll things all over the place all the time. We have some code on
earlier platforms for runtime clock adjustements (on ironlake) in
i915.ko, and I really don't want that kind of hacks any more.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/bxt: reserve space for RC6 in the the GuC WOPCM

[Patchwork]

== Series Details ==

Series: drm/i915/bxt: reserve space for RC6 in the the GuC WOPCM
URL   : https://patchwork.freedesktop.org/series/7300/
State : failure

== Summary ==

Series 7300v1 drm/i915/bxt: reserve space for RC6 in the the GuC WOPCM
http://patchwork.freedesktop.org/api/1.0/series/7300/revisions/1/mbox

Test drv_hangman:
Subgroup error-state-basic:
pass   -> INCOMPLETE (fi-snb-i7-2600)
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
pass   -> FAIL   (fi-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-hsw-i7-4770k)
Test kms_sink_crc_basic:
skip   -> PASS   (ro-skl-i7-6700hq)

fi-bsw-n3050 total:218  pass:174  dwarn:0   dfail:0   fail:2   skip:42 
fi-byt-n2820 total:218  pass:174  dwarn:0   dfail:0   fail:3   skip:41 
fi-hsw-i7-4770k  total:206  pass:186  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-i7-4770r  total:219  pass:193  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-y total:219  pass:191  dwarn:1   dfail:0   fail:2   skip:25 
fi-skl-i7-6700k  total:219  pass:191  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-i7-2600   total:37   pass:27   dwarn:0   dfail:0   fail:0   skip:9  
ro-bdw-i5-5250u  total:219  pass:181  dwarn:0   dfail:0   fail:0   skip:38 
ro-bdw-i7-5557U  total:219  pass:206  dwarn:0   dfail:0   fail:0   skip:13 
ro-bdw-i7-5600u  total:219  pass:187  dwarn:0   dfail:0   fail:0   skip:32 
ro-bsw-n3050 total:219  pass:175  dwarn:0   dfail:0   fail:2   skip:42 
ro-byt-n2820 total:218  pass:174  dwarn:0   dfail:0   fail:3   skip:41 
ro-hsw-i3-4010u  total:218  pass:193  dwarn:0   dfail:0   fail:0   skip:25 
ro-hsw-i7-4770r  total:219  pass:194  dwarn:0   dfail:0   fail:0   skip:25 
ro-ilk-i7-620lm  total:219  pass:151  dwarn:0   dfail:0   fail:1   skip:67 
ro-ilk1-i5-650   total:214  pass:151  dwarn:0   dfail:0   fail:2   skip:61 
ro-ivb-i7-3770   total:219  pass:183  dwarn:0   dfail:0   fail:0   skip:36 
ro-ivb2-i7-3770  total:219  pass:187  dwarn:0   dfail:0   fail:0   skip:32 
ro-skl-i7-6700hq total:214  pass:190  dwarn:0   dfail:0   fail:0   skip:24 
ro-snb-i7-2620M  total:219  pass:177  dwarn:0   dfail:0   fail:1   skip:41 

Results at /archive/results/CI_IGT_test/RO_Patchwork_922/

68c6a6d drm-intel-nightly: 2016y-05m-17d-13h-59m-27s UTC integration manifest
0c07ab7 drm/i915/bxt: reserve space for RC6 in the the GuC WOPCM

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

[Intel-gfx] [PATCH 6/7] drm/i915: Use wait_until_reg macros

[Mika Kuoppala]

Use wait_until_reg instead of generic wait_for macro on
the relevant callsites.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.c | 19 ++---
 drivers/gpu/drm/i915/i915_reg.h |  2 +-
 drivers/gpu/drm/i915/intel_crt.c| 15 +++--
 drivers/gpu/drm/i915/intel_ddi.c|  8 ---
 drivers/gpu/drm/i915/intel_display.c| 38 +++--
 drivers/gpu/drm/i915/intel_dp.c |  6 ++
 drivers/gpu/drm/i915/intel_dp_mst.c |  3 +--
 drivers/gpu/drm/i915/intel_dpll_mgr.c   |  2 +-
 drivers/gpu/drm/i915/intel_dsi.c| 19 +++--
 drivers/gpu/drm/i915/intel_dsi_pll.c|  5 ++---
 drivers/gpu/drm/i915/intel_fbc.c|  3 +--
 drivers/gpu/drm/i915/intel_lrc.c|  3 ++-
 drivers/gpu/drm/i915/intel_lvds.c   |  4 ++--
 drivers/gpu/drm/i915/intel_pm.c |  6 ++
 drivers/gpu/drm/i915/intel_psr.c| 19 +
 drivers/gpu/drm/i915/intel_ringbuffer.c | 12 +--
 drivers/gpu/drm/i915/intel_runtime_pm.c | 25 --
 drivers/gpu/drm/i915/intel_sideband.c   | 20 -
 drivers/gpu/drm/i915/intel_uncore.c |  6 ++
 19 files changed, 100 insertions(+), 115 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index dba03c026151..4bd40ef3c9b8 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1357,8 +1357,6 @@ int vlv_force_gfx_clock(struct drm_i915_private 
*dev_priv, bool force_on)
u32 val;
int err;
 
-#define COND (I915_READ(VLV_GTLC_SURVIVABILITY_REG) & VLV_GFX_CLK_STATUS_BIT)
-
val = I915_READ(VLV_GTLC_SURVIVABILITY_REG);
val &= ~VLV_GFX_CLK_FORCE_ON_BIT;
if (force_on)
@@ -1368,13 +1366,13 @@ int vlv_force_gfx_clock(struct drm_i915_private 
*dev_priv, bool force_on)
if (!force_on)
return 0;
 
-   err = wait_for(COND, 20);
+   err = wait_until_reg_set(VLV_GTLC_SURVIVABILITY_REG,
+VLV_GFX_CLK_STATUS_BIT, 20);
if (err)
DRM_ERROR("timeout waiting for GFX clock force-on (%08x)\n",
  I915_READ(VLV_GTLC_SURVIVABILITY_REG));
 
return err;
-#undef COND
 }
 
 static int vlv_allow_gt_wake(struct drm_i915_private *dev_priv, bool allow)
@@ -1389,13 +1387,12 @@ static int vlv_allow_gt_wake(struct drm_i915_private 
*dev_priv, bool allow)
I915_WRITE(VLV_GTLC_WAKE_CTRL, val);
POSTING_READ(VLV_GTLC_WAKE_CTRL);
 
-#define COND (!!(I915_READ(VLV_GTLC_PW_STATUS) & VLV_GTLC_ALLOWWAKEACK) == \
- allow)
-   err = wait_for(COND, 1);
+   err = wait_until_reg(VLV_GTLC_PW_STATUS,
+VLV_GTLC_ALLOWWAKEACK, allow, 1);
if (err)
DRM_ERROR("timeout disabling GT waking\n");
+
return err;
-#undef COND
 }
 
 static int vlv_wait_for_gt_wells(struct drm_i915_private *dev_priv,
@@ -1407,9 +1404,6 @@ static int vlv_wait_for_gt_wells(struct drm_i915_private 
*dev_priv,
 
mask = VLV_GTLC_PW_MEDIA_STATUS_MASK | VLV_GTLC_PW_RENDER_STATUS_MASK;
val = wait_for_on ? mask : 0;
-#define COND ((I915_READ(VLV_GTLC_PW_STATUS) & mask) == val)
-   if (COND)
-   return 0;
 
DRM_DEBUG_KMS("waiting for GT wells to go %s (%08x)\n",
  onoff(wait_for_on),
@@ -1419,13 +1413,12 @@ static int vlv_wait_for_gt_wells(struct 
drm_i915_private *dev_priv,
 * RC6 transitioning can be delayed up to 2 msec (see
 * valleyview_enable_rps), use 3 msec for safety.
 */
-   err = wait_for(COND, 3);
+   err = wait_until_reg(VLV_GTLC_PW_STATUS, mask, val, 3);
if (err)
DRM_ERROR("timeout waiting for GT wells to go %s\n",
  onoff(wait_for_on));
 
return err;
-#undef COND
 }
 
 static void vlv_check_no_gt_access(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 86fbf723eca7..5355d5272ad1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -,7 +,7 @@ enum skl_disp_power_wells {
 #define IVB_FBC_RT_BASE_MMIO(0x7020)
 
 #define IPS_CTL_MMIO(0x43408)
-#define   IPS_ENABLE   (1 << 31)
+#define   IPS_ENABLE   (1ULL << 31)
 
 #define MSG_FBC_REND_STATE _MMIO(0x50380)
 #define   FBC_REND_NUKE(1<<2)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 3fbb6fc66451..c1c619505393 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -301,8 +301,8 @@ static bool intel_ironlake_crt_detect_hotplug(struct 
drm_connector *connector)
 
I915_WRITE(crt->adpa_reg, adpa);
 
-   if (wait_for((I915_READ(crt->adpa_reg) & 
ADPA_CRT_HOTPLUG_FORCE_TRIGGER) == 0,
-

[Intel-gfx] [PATCH 5/7] drm/i915: Introduce wait_until_reg

[Mika Kuoppala]

The most common usage pattern for wait_for() macro is to wait for some
register value. Instead of bloating all callsites, encapsulate this
complex wait_for macro into a helper function.

v2: s/for/until, macro readability (Chris)

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.h | 25 +
 drivers/gpu/drm/i915/intel_uncore.c |  9 +
 2 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 72f0b02a8372..ccf6747894b1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2873,6 +2873,31 @@ static inline bool intel_vgpu_active(struct 
drm_i915_private *dev_priv)
return dev_priv->vgpu.active;
 }
 
+int intel_wait_until_register(struct drm_i915_private *dev_priv,
+ i915_reg_t reg,
+ u32 mask,
+ u32 value,
+ unsigned long timeout_ms);
+
+#define wait_until_reg(reg, mask, value, timeout_ms) ({ \
+   if (__builtin_constant_p(timeout_ms)) \
+   BUILD_BUG_ON((timeout_ms) > 6); \
+   intel_wait_until_register(dev_priv, \
+ (reg), (mask), (value), (timeout_ms)); \
+   })
+
+#define wait_until_reg_set(reg, v, timeout_ms) ({ \
+   if (__builtin_constant_p(v)) \
+   BUILD_BUG_ON_NOT_POWER_OF_2((u32)(v)); \
+   wait_until_reg(reg, v, v, timeout_ms); \
+   })
+
+#define wait_until_reg_clr(reg, v, timeout_ms) ({ \
+   if (__builtin_constant_p((u32)(v))) \
+   BUILD_BUG_ON_NOT_POWER_OF_2((u32)(v)); \
+   wait_until_reg(reg, v, 0, timeout_ms); \
+   })
+
 void
 i915_enable_pipestat(struct drm_i915_private *dev_priv, enum pipe pipe,
 u32 status_mask);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 385114bca924..e217997a9fa0 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1860,3 +1860,12 @@ intel_uncore_forcewake_for_reg(struct drm_i915_private 
*dev_priv,
 
return fw_domains;
 }
+
+int intel_wait_until_register(struct drm_i915_private *dev_priv,
+ i915_reg_t reg,
+ u32 mask,
+ u32 value,
+ unsigned long timeout_ms)
+{
+   return wait_for((I915_READ(reg) & mask) == value, timeout_ms);
+}
-- 
2.5.0

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

[Intel-gfx] [PATCH 7/7] drm/i915/debug: Warn when waiting on condition timeouts

[Mika Kuoppala]

Warn if we timeout on waiting register or other condition.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.h | 25 -
 drivers/gpu/drm/i915/intel_drv.h| 10 +-
 drivers/gpu/drm/i915/intel_uncore.c | 10 +-
 3 files changed, 34 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ccf6747894b1..3d03a17a8b7c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2873,11 +2873,26 @@ static inline bool intel_vgpu_active(struct 
drm_i915_private *dev_priv)
return dev_priv->vgpu.active;
 }
 
-int intel_wait_until_register(struct drm_i915_private *dev_priv,
- i915_reg_t reg,
- u32 mask,
- u32 value,
- unsigned long timeout_ms);
+int __intel_wait_until_register(struct drm_i915_private *dev_priv,
+   i915_reg_t reg,
+   u32 mask,
+   u32 value,
+   unsigned long timeout_ms);
+
+#if defined(CONFIG_DRM_I915_DEBUG)
+#define intel_wait_until_register(dev_priv, reg, mask, value, timeout_ms) ({ \
+   int __ret; \
+   WARN_ON(__ret = __intel_wait_until_register((dev_priv), \
+   (reg), (mask), \
+   (value), \
+   (timeout_ms))); \
+   __ret; \
+   })
+#else
+#define intel_wait_until_register(dev_priv, reg, mask, value, timeout_ms) \
+   __intel_wait_until_register((dev_priv), \
+   (reg), (mask), (value), timeout_ms);
+#endif
 
 #define wait_until_reg(reg, mask, value, timeout_ms) ({ \
if (__builtin_constant_p(timeout_ms)) \
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1b03461e75e4..917b649f84b6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -80,7 +80,15 @@
ret__;  \
 })
 
-#define wait_for(COND, MS)  __wait_for_ms((COND), (MS), 5)
+#if defined(CONFIG_DRM_I915_DEBUG)
+#define wait_for(COND, MS)  ({ \
+   int r__; \
+   WARN_ON(r__ = __wait_for_ms((COND), (MS), 5)); \
+   r__;\
+   })
+#else
+#define wait_for(COND, MS) __wait_for_ms((COND), (MS), 5)
+#endif
 
 /* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
 #if defined(CONFIG_DRM_I915_DEBUG) && defined(CONFIG_PREEMPT_COUNT)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index f72420e00621..def601ba93d4 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1859,11 +1859,11 @@ intel_uncore_forcewake_for_reg(struct drm_i915_private 
*dev_priv,
return fw_domains;
 }
 
-int intel_wait_until_register(struct drm_i915_private *dev_priv,
- i915_reg_t reg,
- u32 mask,
- u32 value,
- unsigned long timeout_ms)
+int __intel_wait_until_register(struct drm_i915_private *dev_priv,
+   i915_reg_t reg,
+   u32 mask,
+   u32 value,
+   unsigned long timeout_ms)
 {
return wait_for((I915_READ(reg) & mask) == value, timeout_ms);
 }
-- 
2.5.0

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

[Intel-gfx] [PATCH 1/7] drm/i915: Remove the wait_for_us macro

[Mika Kuoppala]

We use jiffies based resolution for timeout detection. So
the promise that in the event of timeout, we would return in the 1us
resolution is false. And with quite large margin.

Remove the wait_for_us macro to prevent further broken promises
and convert the 3 callsites. The wait time will grow to 1ms but
this will be amended somewhat when wait_for gets enhanced with
adaptive backoff.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
 drivers/gpu/drm/i915/intel_display.c | 8 
 drivers/gpu/drm/i915/intel_drv.h | 1 -
 3 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index c454744dda0b..a62c60c6fb0b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1826,8 +1826,8 @@ static void broxton_phy_init(struct drm_i915_private 
*dev_priv,
 * HW team confirmed that the time to reach phypowergood status is
 * anywhere between 50 us and 100us.
 */
-   if (wait_for_us(((I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
-   (PHY_RESERVED | PHY_POWER_GOOD)) == PHY_POWER_GOOD), 100)) {
+   if (wait_for(((I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
+   (PHY_RESERVED | PHY_POWER_GOOD)) == PHY_POWER_GOOD), 1)) {
DRM_ERROR("timeout during PHY%d power on\n", phy);
}
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4777087326f6..05d4a2b365f8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9619,8 +9619,8 @@ static void broadwell_set_cdclk(struct drm_device *dev, 
int cdclk)
val |= LCPLL_CD_SOURCE_FCLK;
I915_WRITE(LCPLL_CTL, val);
 
-   if (wait_for_us(I915_READ(LCPLL_CTL) &
-   LCPLL_CD_SOURCE_FCLK_DONE, 1))
+   if (wait_for(I915_READ(LCPLL_CTL) &
+LCPLL_CD_SOURCE_FCLK_DONE, 1))
DRM_ERROR("Switching to FCLK failed\n");
 
val = I915_READ(LCPLL_CTL);
@@ -9654,8 +9654,8 @@ static void broadwell_set_cdclk(struct drm_device *dev, 
int cdclk)
val &= ~LCPLL_CD_SOURCE_FCLK;
I915_WRITE(LCPLL_CTL, val);
 
-   if (wait_for_us((I915_READ(LCPLL_CTL) &
-   LCPLL_CD_SOURCE_FCLK_DONE) == 0, 1))
+   if (wait_for((I915_READ(LCPLL_CTL) &
+ LCPLL_CD_SOURCE_FCLK_DONE) == 0, 1))
DRM_ERROR("Switching back to LCPLL failed\n");
 
mutex_lock(_priv->rps.hw_lock);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3536292babe0..0fc8579e7b2e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -69,7 +69,6 @@
 })
 
 #define wait_for(COND, MS) _wait_for((COND), (MS) * 1000, 1000)
-#define wait_for_us(COND, US)  _wait_for((COND), (US), 1)
 
 /* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
 #if defined(CONFIG_DRM_I915_DEBUG) && defined(CONFIG_PREEMPT_COUNT)
-- 
2.5.0

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

[Intel-gfx] [PATCH 4/7] drm/i915: Take longer naps in wait_for

[Mika Kuoppala]

If the condition we are after doesn't happen, start to sleep
longer and longer periods to save power. But never sleep more than 1/5th
of the timeout value. Convert few remaining callsites to use this generic
macro instead of letting them specifying their own sleeping periods.
This results in only one generic wait_for across all callsites so
we can remove the macro specifying the sleep period.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_dp.c  |  4 ++--
 drivers/gpu/drm/i915/intel_drv.h | 15 ++-
 drivers/gpu/drm/i915/intel_psr.c |  6 +++---
 3 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a32617469816..b14761f585e9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1699,8 +1699,8 @@ static void wait_panel_status(struct intel_dp *intel_dp,
I915_READ(pp_stat_reg),
I915_READ(pp_ctrl_reg));
 
-   if (_wait_for_ms((I915_READ(pp_stat_reg) & mask) == value,
-5 * MSEC_PER_SEC, 10 * USEC_PER_MSEC))
+   if (wait_for((I915_READ(pp_stat_reg) & mask) == value,
+5 * MSEC_PER_SEC))
DRM_ERROR("Panel status timeout: status %08x control %08x\n",
I915_READ(pp_stat_reg),
I915_READ(pp_ctrl_reg));
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c225605c727c..1b03461e75e4 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -50,7 +50,7 @@
  * drm_can_sleep() can be removed and in_atomic()/!in_atomic() asserts
  * added.
  */
-#define __wait_for_ms(COND, TIMEOUT_MS, SLEEP_US, SPIN_COUNT) ({   \
+#define __wait_for_ms(COND, TIMEOUT_MS, SPIN_COUNT) ({ \
const unsigned long timeout__ = \
jiffies + msecs_to_jiffies(TIMEOUT_MS) + 1; \
unsigned int c__ = 0;   \
@@ -64,9 +64,15 @@
}   \
\
if (++c__ > (SPIN_COUNT) && \
-   (SLEEP_US) &&   \
+   (TIMEOUT_MS) && \
drm_can_sleep()) {  \
-   usleep_range((SLEEP_US), (SLEEP_US) * 2);   \
+   /* Limit max nap to 1/4 of timeout */   \
+   unsigned int s__ =  \
+   clamp_val(c__ * 2 * USEC_PER_MSEC,  \
+   TIMEOUT_MS * 250,   \
+ MAX_UDELAY_MS);   \
+   \
+   usleep_range(s__ >> 1, s__);\
} else {\
cpu_relax();\
}   \
@@ -74,8 +80,7 @@
ret__;  \
 })
 
-#define wait_for(COND, MS)  __wait_for_ms((COND), (MS), 1 * USEC_PER_MSEC, 5)
-#define _wait_for_ms(COND, MS, US)  __wait_for_ms((COND), (MS), (US), 5)
+#define wait_for(COND, MS)  __wait_for_ms((COND), (MS), 5)
 
 /* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
 #if defined(CONFIG_DRM_I915_DEBUG) && defined(CONFIG_PREEMPT_COUNT)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 0ceb2026835e..912312b79eda 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -506,9 +506,9 @@ static void hsw_psr_disable(struct intel_dp *intel_dp)
   I915_READ(EDP_PSR_CTL) & ~EDP_PSR_ENABLE);
 
/* Wait till PSR is idle */
-   if (_wait_for_ms((I915_READ(EDP_PSR_STATUS_CTL) &
- EDP_PSR_STATUS_STATE_MASK) == 0,
-2 * MSEC_PER_SEC, 10 * USEC_PER_MSEC))
+   if (wait_for((I915_READ(EDP_PSR_STATUS_CTL) &
+ EDP_PSR_STATUS_STATE_MASK) == 0,
+2 * MSEC_PER_SEC))
DRM_ERROR("Timed out waiting for PSR Idle State\n");
 
dev_priv->psr.active = false;
-- 
2.5.0

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

[Intel-gfx] [PATCH 2/7] drm/i915: Use milliseconds in _wait_for macro

[Mika Kuoppala]

Promising 1us accuracy where we timeout using jiffies is
misleading. Convert the _wait_for macro to use milliseconds
and convert the 2 callsites.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_dp.c  |  4 ++--
 drivers/gpu/drm/i915/intel_drv.h | 13 +++--
 drivers/gpu/drm/i915/intel_psr.c |  6 +++---
 3 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 36330026ceff..a32617469816 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1699,8 +1699,8 @@ static void wait_panel_status(struct intel_dp *intel_dp,
I915_READ(pp_stat_reg),
I915_READ(pp_ctrl_reg));
 
-   if (_wait_for((I915_READ(pp_stat_reg) & mask) == value,
- 5 * USEC_PER_SEC, 10 * USEC_PER_MSEC))
+   if (_wait_for_ms((I915_READ(pp_stat_reg) & mask) == value,
+5 * MSEC_PER_SEC, 10 * USEC_PER_MSEC))
DRM_ERROR("Panel status timeout: status %08x control %08x\n",
I915_READ(pp_stat_reg),
I915_READ(pp_ctrl_reg));
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0fc8579e7b2e..488141929a7a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,7 +39,7 @@
 #include 
 
 /**
- * _wait_for - magic (register) wait macro
+ * _wait_for_ms - magic (register) wait macro
  *
  * Does the right thing for modeset paths when run under kdgb or similar atomic
  * contexts. Note that it's important that we check the condition again after
@@ -50,8 +50,9 @@
  * drm_can_sleep() can be removed and in_atomic()/!in_atomic() asserts
  * added.
  */
-#define _wait_for(COND, US, W) ({ \
-   unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
+#define _wait_for_ms(COND, TIMEOUT_MS, SLEEP_US) ({ \
+   const unsigned long timeout__ = \
+   jiffies + msecs_to_jiffies(TIMEOUT_MS) + 1; \
int ret__ = 0;  \
while (!(COND)) {   \
if (time_after(jiffies, timeout__)) {   \
@@ -59,8 +60,8 @@
ret__ = -ETIMEDOUT; \
break;  \
}   \
-   if ((W) && drm_can_sleep()) {   \
-   usleep_range((W), (W)*2);   \
+   if ((SLEEP_US) && drm_can_sleep()) {\
+   usleep_range((SLEEP_US), (SLEEP_US) * 2);   \
} else {\
cpu_relax();\
}   \
@@ -68,7 +69,7 @@
ret__;  \
 })
 
-#define wait_for(COND, MS) _wait_for((COND), (MS) * 1000, 1000)
+#define wait_for(COND, MS)  _wait_for_ms((COND), (MS), 1 * USEC_PER_MSEC)
 
 /* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
 #if defined(CONFIG_DRM_I915_DEBUG) && defined(CONFIG_PREEMPT_COUNT)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c3abae4bc596..0ceb2026835e 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -506,9 +506,9 @@ static void hsw_psr_disable(struct intel_dp *intel_dp)
   I915_READ(EDP_PSR_CTL) & ~EDP_PSR_ENABLE);
 
/* Wait till PSR is idle */
-   if (_wait_for((I915_READ(EDP_PSR_STATUS_CTL) &
-  EDP_PSR_STATUS_STATE_MASK) == 0,
-  2 * USEC_PER_SEC, 10 * USEC_PER_MSEC))
+   if (_wait_for_ms((I915_READ(EDP_PSR_STATUS_CTL) &
+ EDP_PSR_STATUS_STATE_MASK) == 0,
+2 * MSEC_PER_SEC, 10 * USEC_PER_MSEC))
DRM_ERROR("Timed out waiting for PSR Idle State\n");
 
dev_priv->psr.active = false;
-- 
2.5.0

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

[Intel-gfx] [PATCH 3/7] drm/i915: Spin opportunistically in wait_for

[Mika Kuoppala]

Usually the condition we are after appears within very short time.
Spin few times before going into sleep. With this approximately
half of the wait_for in init path will take the fast path without
sleeping.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_drv.h | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 488141929a7a..c225605c727c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,7 +39,7 @@
 #include 
 
 /**
- * _wait_for_ms - magic (register) wait macro
+ * __wait_for_ms - magic (register) wait macro
  *
  * Does the right thing for modeset paths when run under kdgb or similar atomic
  * contexts. Note that it's important that we check the condition again after
@@ -50,17 +50,22 @@
  * drm_can_sleep() can be removed and in_atomic()/!in_atomic() asserts
  * added.
  */
-#define _wait_for_ms(COND, TIMEOUT_MS, SLEEP_US) ({ \
+#define __wait_for_ms(COND, TIMEOUT_MS, SLEEP_US, SPIN_COUNT) ({   \
const unsigned long timeout__ = \
jiffies + msecs_to_jiffies(TIMEOUT_MS) + 1; \
+   unsigned int c__ = 0;   \
int ret__ = 0;  \
+   \
while (!(COND)) {   \
if (time_after(jiffies, timeout__)) {   \
if (!(COND))\
ret__ = -ETIMEDOUT; \
break;  \
}   \
-   if ((SLEEP_US) && drm_can_sleep()) {\
+   \
+   if (++c__ > (SPIN_COUNT) && \
+   (SLEEP_US) &&   \
+   drm_can_sleep()) {  \
usleep_range((SLEEP_US), (SLEEP_US) * 2);   \
} else {\
cpu_relax();\
@@ -69,7 +74,8 @@
ret__;  \
 })
 
-#define wait_for(COND, MS)  _wait_for_ms((COND), (MS), 1 * USEC_PER_MSEC)
+#define wait_for(COND, MS)  __wait_for_ms((COND), (MS), 1 * USEC_PER_MSEC, 5)
+#define _wait_for_ms(COND, MS, US)  __wait_for_ms((COND), (MS), (US), 5)
 
 /* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
 #if defined(CONFIG_DRM_I915_DEBUG) && defined(CONFIG_PREEMPT_COUNT)
-- 
2.5.0

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

[Intel-gfx] [PATCH 0/7] wait_for and wait_until_reg

[Mika Kuoppala]

I resurrected this series as there was irc discussion about wait_for
and it shortcomings. I have wait_until_reg conversions also 
as individual patches per file if that makes things easier to digest.

If we decide to go this route,

text   data bss dec hex filename
1166505   24385 920 1191810  122f82 drivers/gpu/drm/i915/i915.ko.nightly
1155137   24385 920 1180442  12031a drivers/gpu/drm/i915/i915.ko

we save 11368 bytes.

Mika Kuoppala (7):
  drm/i915: Remove the wait_for_us macro
  drm/i915: Use milliseconds in _wait_for macro
  drm/i915: Spin opportunistically in wait_for
  drm/i915: Take longer naps in wait_for
  drm/i915: Introduce wait_until_reg
  drm/i915: Use wait_until_reg macros
  drm/i915/debug: Warn when waiting on condition timeouts

 drivers/gpu/drm/i915/i915_drv.c | 19 +---
 drivers/gpu/drm/i915/i915_drv.h | 40 +
 drivers/gpu/drm/i915/i915_reg.h |  2 +-
 drivers/gpu/drm/i915/intel_crt.c| 15 +++--
 drivers/gpu/drm/i915/intel_ddi.c|  8 ---
 drivers/gpu/drm/i915/intel_display.c| 38 ++-
 drivers/gpu/drm/i915/intel_dp.c |  6 ++---
 drivers/gpu/drm/i915/intel_dp_mst.c |  3 +--
 drivers/gpu/drm/i915/intel_dpll_mgr.c   |  2 +-
 drivers/gpu/drm/i915/intel_drv.h| 33 +--
 drivers/gpu/drm/i915/intel_dsi.c| 19 +++-
 drivers/gpu/drm/i915/intel_dsi_pll.c|  5 ++---
 drivers/gpu/drm/i915/intel_fbc.c|  3 +--
 drivers/gpu/drm/i915/intel_lrc.c|  3 ++-
 drivers/gpu/drm/i915/intel_lvds.c   |  4 ++--
 drivers/gpu/drm/i915/intel_pm.c |  6 ++---
 drivers/gpu/drm/i915/intel_psr.c| 19 
 drivers/gpu/drm/i915/intel_ringbuffer.c | 12 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 25 -
 drivers/gpu/drm/i915/intel_sideband.c   | 20 -
 drivers/gpu/drm/i915/intel_uncore.c | 15 +
 21 files changed, 175 insertions(+), 122 deletions(-)

-- 
2.5.0

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Add ppgtt->kunmap_page_dma vfunc

[Patchwork]

== Series Details ==

Series: drm/i915: Add ppgtt->kunmap_page_dma vfunc
URL   : https://patchwork.freedesktop.org/series/7296/
State : failure

== Summary ==

Series 7296v1 drm/i915: Add ppgtt->kunmap_page_dma vfunc
http://patchwork.freedesktop.org/api/1.0/series/7296/revisions/1/mbox

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
pass   -> FAIL   (fi-byt-n2820)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (ro-hsw-i7-4770r)
pass   -> FAIL   (ro-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (ro-ivb2-i7-3770)

fi-bdw-i7-5557u  total:219  pass:206  dwarn:0   dfail:0   fail:0   skip:13 
fi-bsw-n3050 total:218  pass:174  dwarn:0   dfail:0   fail:2   skip:42 
fi-byt-n2820 total:218  pass:174  dwarn:0   dfail:0   fail:3   skip:41 
fi-hsw-i7-4770k  total:219  pass:198  dwarn:0   dfail:0   fail:0   skip:21 
fi-hsw-i7-4770r  total:219  pass:193  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-y total:219  pass:191  dwarn:1   dfail:0   fail:2   skip:25 
fi-skl-i7-6700k  total:219  pass:191  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-i7-2600   total:219  pass:176  dwarn:0   dfail:0   fail:0   skip:43 
ro-bdw-i5-5250u  total:219  pass:181  dwarn:0   dfail:0   fail:0   skip:38 
ro-bdw-i7-5557U  total:219  pass:206  dwarn:0   dfail:0   fail:0   skip:13 
ro-bdw-i7-5600u  total:219  pass:187  dwarn:0   dfail:0   fail:0   skip:32 
ro-bsw-n3050 total:219  pass:175  dwarn:0   dfail:0   fail:2   skip:42 
ro-byt-n2820 total:218  pass:173  dwarn:0   dfail:0   fail:4   skip:41 
ro-hsw-i3-4010u  total:218  pass:193  dwarn:0   dfail:0   fail:0   skip:25 
ro-hsw-i7-4770r  total:219  pass:193  dwarn:0   dfail:0   fail:1   skip:25 
ro-ilk-i7-620lm  total:219  pass:151  dwarn:0   dfail:0   fail:1   skip:67 
ro-ilk1-i5-650   total:214  pass:151  dwarn:0   dfail:0   fail:2   skip:61 
ro-ivb-i7-3770   total:219  pass:183  dwarn:0   dfail:0   fail:0   skip:36 
ro-ivb2-i7-3770  total:219  pass:186  dwarn:1   dfail:0   fail:0   skip:32 
ro-skl-i7-6700hq total:214  pass:189  dwarn:0   dfail:0   fail:0   skip:25 
ro-snb-i7-2620M  total:219  pass:177  dwarn:0   dfail:0   fail:1   skip:41 

Results at /archive/results/CI_IGT_test/RO_Patchwork_921/

68c6a6d drm-intel-nightly: 2016y-05m-17d-13h-59m-27s UTC integration manifest
3ca83ec drm/i915: Add ppgtt->kunmap_page_dma vfunc

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

Re: [Intel-gfx] [PATCH 7/9] drm/i915: Introduce execlist context status change notification

[Wang, Zhi A]

Yes. Sure will do that. :) Thanks for the comments. How about other patches? :)

-Original Message-
From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] 
Sent: Tuesday, May 17, 2016 1:52 PM
To: Wang, Zhi A ; intel-gfx@lists.freedesktop.org; 
joonas.lahti...@linux.intel.com; ch...@chris-wilson.co.uk; Tian, Kevin 
; Lv, Zhiyuan 
Subject: Re: [PATCH 7/9] drm/i915: Introduce execlist context status change 
notification


Hi,

On 17/05/16 09:19, Zhi Wang wrote:
> This patch introduces an approach to track the execlist context status 
> change.
>
> GVT-g uses GVT context as the "shadow context". The content inside GVT 
> context will be copied back to guest after the context is idle. So 
> GVT-g has to know the status of the execlist context.
>
> This function is configurable in the context creation service. 
> Currently, Only GVT-g will create the "status-change-notification" 
> enabled GEM context.
>
> v5:
>
> - Only compile this feature when CONFIG_DRM_I915_GVT is 
> enabled.(Tvrtko)
>
> Signed-off-by: Zhi Wang 
> ---
>   drivers/gpu/drm/i915/i915_drv.h  |  6 ++
>   drivers/gpu/drm/i915/intel_lrc.c | 30 ++
>   drivers/gpu/drm/i915/intel_lrc.h |  7 +++
>   3 files changed, 43 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> b/drivers/gpu/drm/i915/i915_drv.h index 91f69e5..9688006 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -882,9 +882,15 @@ struct intel_context {
>   u64 lrc_desc;
>   uint32_t *lrc_reg_state;
>   bool initialised;
> +#if IS_ENABLED(CONFIG_DRM_I915_GVT)
> + struct atomic_notifier_head status_notifier_head; #endif
>   } engine[I915_NUM_ENGINES];
>   u32 ring_buffer_size;
>   bool use_48bit_addressing_mode;
> +#if IS_ENABLED(CONFIG_DRM_I915_GVT)
> + bool enable_status_change_notification;
> +#endif
>
>   struct list_head link;
>   };
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index d97623f..9069836 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -415,6 +415,20 @@ static void execlists_submit_requests(struct 
> drm_i915_gem_request *rq0,
>   spin_unlock_irq(_priv->uncore.lock);
>   }
>
> +#if IS_ENABLED(CONFIG_DRM_I915_GVT)
> +static inline void execlists_context_status_change(
> + struct drm_i915_gem_request *req,
> + unsigned long status)
> +{
> + if (!req->ctx->enable_status_change_notification)
> + return;
> +
> + atomic_notifier_call_chain(
> + >ctx->engine[req->engine->id].status_notifier_head,
> + status, req);
> +}

I recommend the usual:

#else
static inline void execlists_context_status_change(
struct drm_i915_gem_request *req,
unsigned long status)
{
}

And then you don't have to have many #ifdefs scattered around.

> +#endif
> +
>   static void execlists_context_unqueue(struct intel_engine_cs *engine)
>   {
>   struct drm_i915_gem_request *req0 = NULL, *req1 = NULL; @@ -450,6 
> +464,13 @@ static void execlists_context_unqueue(struct intel_engine_cs 
> *engine)
>   if (unlikely(!req0))
>   return;
>
> +#if IS_ENABLED(CONFIG_DRM_I915_GVT)
> + execlists_context_status_change(req0, CONTEXT_SCHEDULE_IN);
> +
> + if (req1)
> + execlists_context_status_change(req1, CONTEXT_SCHEDULE_IN); 
> #endif
> +
>   if (req0->elsp_submitted & engine->idle_lite_restore_wa) {
>   /*
>* WaIdleLiteRestore: make sure we never cause a lite restore 
> @@ 
> -488,6 +509,10 @@ execlists_check_remove_request(struct intel_engine_cs 
> *engine, u32 ctx_id)
>   if (--head_req->elsp_submitted > 0)
>   return 0;
>
> +#if IS_ENABLED(CONFIG_DRM_I915_GVT)
> + execlists_context_status_change(head_req, CONTEXT_SCHEDULE_OUT); 
> +#endif
> +
>   list_del(_req->execlist_link);
>   i915_gem_request_unreference(head_req);
>
> @@ -2534,6 +2559,11 @@ static int execlists_context_deferred_alloc(struct 
> intel_context *ctx,
>   ctx->engine[engine->id].state = ctx_obj;
>   ctx->engine[engine->id].initialised = engine->init_context == NULL;
>
> +#if IS_ENABLED(CONFIG_DRM_I915_GVT)
> + if (ctx->enable_status_change_notification)
> + ATOMIC_INIT_NOTIFIER_HEAD(
> + >engine[engine->id].status_notifier_head);
> +#endif
>   return 0;
>
>   error_ringbuf:
> diff --git a/drivers/gpu/drm/i915/intel_lrc.h 
> b/drivers/gpu/drm/i915/intel_lrc.h
> index 1afba03..99f84c9 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.h
> +++ b/drivers/gpu/drm/i915/intel_lrc.h
> @@ -57,6 +57,13 @@
>   #define GEN8_CSB_READ_PTR(csb_status) \
>   (((csb_status) & GEN8_CSB_READ_PTR_MASK) >> 8)
>
> +#if IS_ENABLED(CONFIG_DRM_I915_GVT)
> 

Re: [Intel-gfx] FreeBSD i915 driver update

[K. Macy]

> What I don't really like is the old approach of trying to abstract away
> differences between Linux and *BSD in drmP.h with some screaming macros.
> Given the imbalance of manpower between Linux and *BSD I think the best
> (and probably only really) approach is to have linux compat types and
> wrapper functions for everything. Which seems to be the new plan.

Correct.

> If there's stuff needed above that I think we need to look at in on
> a case-by-case basis and figure out what makes sense. For me the crucial
> bit isn't so much whether we need to make changes in upstream linux or
> not, but whether there's a benefit for usptream too. If bug reports and
> bugfixes flow back to linux, then I'm all for it. If it's a one-way street
> then frankly I don't care ;-)

I apologize for a being a bit slow to parse your statements. What is
upstream and what is downstream? If upstream is Linux and downstream
Linux users then I actually do have some areas I'd like engage on like
figuring out if userptr as it stands couldn't provide a better failure
mode. However, I'd like to think that upstream is Intel and downstream
is Intel customers and that the predominant focus on Linux is an
artifact of cost / benefit. If the latter is the case then any changes
that don't interfere with your primary focus but still support your
broader customer base should be considered desirable.

Either way, now that we're in sync with upstream I do hope that we can
contribute to general driver discussions to the extent that our
limited resources permit.


>> Good luck with your efforts!
>
> Yeah, would be great to have *BSD tracking upstream closely again, wish
> you the best with that!


Thanks.

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Update kerneldoc for intel_dpll_mgr.c

[Patchwork]

== Series Details ==

Series: drm/i915: Update kerneldoc for intel_dpll_mgr.c
URL   : https://patchwork.freedesktop.org/series/7294/
State : failure

== Summary ==

Series 7294v1 drm/i915: Update kerneldoc for intel_dpll_mgr.c
http://patchwork.freedesktop.org/api/1.0/series/7294/revisions/1/mbox

Test drv_hangman:
Subgroup error-state-basic:
fail   -> PASS   (ro-ilk1-i5-650)
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
pass   -> FAIL   (fi-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-c:
pass   -> DMESG-WARN (ro-ivb2-i7-3770)

fi-bdw-i7-5557u  total:219  pass:206  dwarn:0   dfail:0   fail:0   skip:13 
fi-bsw-n3050 total:218  pass:174  dwarn:0   dfail:0   fail:2   skip:42 
fi-byt-n2820 total:218  pass:174  dwarn:0   dfail:0   fail:3   skip:41 
fi-hsw-i7-4770r  total:219  pass:193  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-y total:219  pass:191  dwarn:1   dfail:0   fail:2   skip:25 
fi-skl-i7-6700k  total:219  pass:191  dwarn:0   dfail:0   fail:0   skip:28 
ro-bdw-i5-5250u  total:219  pass:181  dwarn:0   dfail:0   fail:0   skip:38 
ro-bdw-i7-5557U  total:219  pass:206  dwarn:0   dfail:0   fail:0   skip:13 
ro-bdw-i7-5600u  total:219  pass:187  dwarn:0   dfail:0   fail:0   skip:32 
ro-bsw-n3050 total:219  pass:175  dwarn:0   dfail:0   fail:2   skip:42 
ro-byt-n2820 total:218  pass:174  dwarn:0   dfail:0   fail:3   skip:41 
ro-hsw-i3-4010u  total:218  pass:193  dwarn:0   dfail:0   fail:0   skip:25 
ro-hsw-i7-4770r  total:219  pass:194  dwarn:0   dfail:0   fail:0   skip:25 
ro-ilk-i7-620lm  total:219  pass:151  dwarn:0   dfail:0   fail:1   skip:67 
ro-ilk1-i5-650   total:214  pass:152  dwarn:0   dfail:0   fail:1   skip:61 
ro-ivb-i7-3770   total:219  pass:183  dwarn:0   dfail:0   fail:0   skip:36 
ro-ivb2-i7-3770  total:219  pass:186  dwarn:1   dfail:0   fail:0   skip:32 
ro-skl-i7-6700hq total:214  pass:189  dwarn:0   dfail:0   fail:0   skip:25 
ro-snb-i7-2620M  total:219  pass:177  dwarn:0   dfail:0   fail:1   skip:41 

Results at /archive/results/CI_IGT_test/RO_Patchwork_920/

68c6a6d drm-intel-nightly: 2016y-05m-17d-13h-59m-27s UTC integration manifest
7f06795 drm/i915: Update kerneldoc for intel_dpll_mgr.c

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

Re: [Intel-gfx] [PATCH 1/4 v3] drm/i915: Early exit from rps worker if GPU is idle

[Chris Wilson]

On Tue, May 17, 2016 at 04:40:38PM +0200, Michał Winiarski wrote:
> This allows us to avoid the situation where worker is increasing the GPU
> frequency after we've switched to idle.
> 
> v2: Do not access ->mm.busy under ->irq_lock
> v3: Really do not access ->mm.busy under ->irq_lock

This is backwards. The rps worker should not be running when the device
is idle. The code tries to do that currently but fails, so I think this
as papering over the bug.

Fixing this means we can remove the DISABLE_RPM_WAKEREF_ASSERTS. The
patch I've previously sent does
https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=tasklet=1c0ace26e80188e53a18977e5ef90ab8a801027c
-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] [PATCH v2 1/3] drm/i915/hda: Add audio component stub

[Takashi Iwai]

On Tue, 17 May 2016 15:59:17 +0200,
Daniel Vetter wrote:
> 
> On Tue, May 17, 2016 at 03:57:30PM +0200, Takashi Iwai wrote:
> > On Tue, 17 May 2016 14:53:40 +0200,
> > Takashi Iwai wrote:
> > > 
> > > On Tue, 17 May 2016 14:39:26 +0200,
> > > Daniel Vetter wrote:
> > > > 
> > > > And if we _really_ want this to work at runtime too, then we need a
> > > > system-wide nomodeset option that snd-hda can look up and act 
> > > > accordingly.
> > > 
> > > Yes, this would be one option.
> > 
> > And I noticed that this can be easily added to patch 3, just like i915
> > driver does:
> > 
> > diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
> > index c9af022676c2..c48a014be7b4 100644
> > --- a/sound/hda/hdac_i915.c
> > +++ b/sound/hda/hdac_i915.c
> > @@ -361,6 +361,11 @@ int snd_hdac_i915_init(struct hdac_bus *bus)
> > if (WARN_ON(hdac_acomp))
> > return -EBUSY;
> >  
> > +#ifdef CONFIG_VGA_CONSOLE
> > +   if (vgacon_text_force())
> > +   return -ENODEV;
> > +#endif
> 
> There's a dummy vgacon_text_force now, so you don't even need the #ifdef.

Good to know!


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

[Intel-gfx] [Regression report] Weekly regression report WW20

[jairo . daniel . miramontes . caton]

There was no new regressions this week.


Previous regressions
+---+---+++
| BugId | Summary   | Created on | Bisect |
+---+---+++
| 90112 | [BSW bisected] OglGSCloth/Lightsmark/CS/ Port | 2015-04-20 | Yes|
| 94590 | [KBL] igt/kms_fbcon_fbt/psr-suspend regressio | 2016-03-17 | No |
| 93263 | 945GM regression since 4.3| 2015-12-05 | No |
| 72782 | [945GM bisected] screen blank on S3 resume on | 2013-12-17 | Yes|
| 92414 | [Intel-gfx] As of kernel 4.3-rc1 system will  | 2015-10-10 | Yes|
| 92050 | [regression]/bug introduced by commit [0e572f | 2015-09-19 | No |
| 93802 | [IVB bisected] switching to tty1 causes fifo  | 2016-01-20 | Yes|
| 95197 | [i915] regression in 4.6-rc5: GPU HANG: ecode | 2016-04-28 | No |
| 94587 | [KBL] igt/kms_plane/plane-panning-bottom-righ | 2016-03-17 | No |
| 89629 | [i965 regression]igt/kms_rotation_crc/sprite- | 2015-03-18 | No |
| 89728 | [HSW/BDW/BYT bisected] igt / pm_rps / reset f | 2015-03-23 | Yes|
| 92502 | [SKL] [Regression] igt/kms_flip/2x-flip-vs-ex | 2015-10-16 | No |
| 84855 | [ILK regression]igt kms_rotation_crc/sprite-r | 2014-10-10 | No |
| 87131 | [PNV regression] igt/gem_exec_lut_handle take | 2014-12-09 | No |
| 87726 | [BDW Bisected] OglDrvCtx performance reduced  | 2014-12-26 | Yes|
| 91974 | [bisected] unrecoverable black screen after k | 2015-09-11 | Yes|
| 94430 | [HSW+nvidia] regression: display becomes "dis | 2016-03-07 | No |
| 93971 | video framerate performance regression with U | 2016-02-02 | No |
| 92575 | [4.2 regression] Massive graphics corruption  | 2015-10-21 | No |
| 89872 | [ HSW Bisected ] VGA was white screen when re | 2015-04-02 | Yes|
| 91959 | [865g Linux regression] GPU hang and disabled | 2015-09-10 | No |
| 95097 | [hdmi regression ilk] no signal to TV | 2016-04-24 | No |
| 89334 | [945 regression] 4.0-rc1 kernel GPU hang:  ec | 2015-02-26 | No |
| 94748 | Black screen on Skylake (mouse position relat | 2016-03-29 | No |
| 92972 | Black screen on Intel NUC hardware (i915) pos | 2015-11-16 | No |
| 87725 | [BDW Bisected] OglBatch7 performance reduced  | 2014-12-26 | Yes|
| 94676 | Possible kernel regression for gen3 and earli | 2016-03-23 | No |
| 94416 | [KBL HSW] [Regression] kms_frontbuffer_tracki | 2016-03-06 | No |
| 94337 | Linux 4.5 regression: FIFO underruns on Skyla | 2016-02-29 | No |
| 90368 | [SNB BSW SKL BXT KBL] bisected igt/kms_3d has | 2015-05-08 | Yes|
| 94588 | [KBL/BSW/BXT] igt/gem_reloc_overflow regressi | 2016-03-17 | No |
| 90732 | [BDW/BSW Bisected]igt/gem_reloc_vs_gpu/forked | 2015-05-29 | Yes|
| 90134 | [BSW Bisected]GFXBench3_gl_driver/GFXBench3_g | 2015-04-22 | Yes|
| 93782 | [i9xx TV][BISECT] vblank wait timeout on crtc | 2016-01-19 | Yes|
| 89632 | [i965 regression]igt/kms_universal_plane/univ | 2015-03-18 | No |
| 88439 | [BDW Bisected]igt/gem_reloc_vs_gpu/forked-fau | 2015-01-15 | Yes|
| 92237 | [SNB]Horrible noise (audio) via DisplayPort [ | 2015-10-02 | No |
| 93122 | [SNB BAT IGT regression] pm_rpm started skipp | 2015-11-26 | No |
| 93393 | Regression for Skylake modesetting in kernel  | 2015-12-16 | No |
+---+---+++

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

Re: [Intel-gfx] [PATCH i-g-t v5 7/7] kms_flip: Change __wait_for_vblank to use helper function.

[Robert Foss]

On 2016-05-17 06:32 AM, Marius Vlad wrote:

On Mon, May 16, 2016 at 09:38:32AM -0400, robert.f...@collabora.com wrote:

From: Robert Foss 

Change __wait_for_vblank() to use kmstest_get_vbl_flag() helper function.

Signed-off-by: Robert Foss 
---
  tests/kms_flip.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index eda2fcc..0ecca07 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -481,15 +481,15 @@ static int __wait_for_vblank(unsigned int flags, int 
crtc_idx,
  {
drmVBlank wait_vbl;
int ret;
-   unsigned crtc_idx_mask;
+   uint32_t pipe_id_flag;
bool event = !(flags & TEST_VBLANK_BLOCK);

memset(_vbl, 0, sizeof(wait_vbl));

-   crtc_idx_mask = crtc_idx << DRM_VBLANK_HIGH_CRTC_SHIFT;
-   igt_assert(!(crtc_idx_mask & ~DRM_VBLANK_HIGH_CRTC_MASK));

If crtc_idx is 1 (pipe B), crtc_idx_mask = (1 << DRM_VBLANK_HIGH_CRTC_SHIFT) = 
2.

+   pipe_id_flag = kmstest_get_vbl_flag(crtc_idx);
+   igt_assert(!(pipe_id_flag & ~DRM_VBLANK_HIGH_CRTC_MASK));

If crtc_idx is 1 (pipe B), kmstest_get_vbl_flag(crtc_idx) = 
DRM_VBLANK_SECONDARY = 0x2000

And the assertion fails as !(0x2000 & ~0x003e) = 0.

Should kmstest_get_vbl_flag() always return pipe_id << 1?


From re-reading the pipe id parsing code in drm_irq.c drm_wait_vblank()
it would seem to me that the assertion is incorrect, specifically for 
the case of _DRM_VBLANK_SECONDARY.


Supplying the flag _DRM_VBLANK_SECONDARY and setting the high crtc id 
field to 1 fboth seem to be valid ways to communicate the same thing.


flags = vblwait->request.type & _DRM_VBLANK_FLAGS_MASK;
high_pipe = (vblwait->request.type &_DRM_VBLANK_HIGH_CRTC_MASK);
if (high_pipe)
pipe = high_pipe >> _DRM_VBLANK_HIGH_CRTC_SHIFT;
else
pipe = flags & _DRM_VBLANK_SECONDARY ? 1 : 0;


Maybe adding correct and more thorough assertion to 
kmstest_get_vbl_flag() and removing the failing assertion is the way 
forward.






-   wait_vbl.request.type = crtc_idx_mask;
+   wait_vbl.request.type = pipe_id_flag;
if (flags & TEST_VBLANK_ABSOLUTE)
wait_vbl.request.type |= DRM_VBLANK_ABSOLUTE;
else
--
2.7.4


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

[Intel-gfx] [PATCH 1/4 v3] drm/i915: Early exit from rps worker if GPU is idle

[Michał Winiarski]

This allows us to avoid the situation where worker is increasing the GPU
frequency after we've switched to idle.

v2: Do not access ->mm.busy under ->irq_lock
v3: Really do not access ->mm.busy under ->irq_lock

References: https://bugs.freedesktop.org/show_bug.cgi?id=89728
Cc: Chris Wilson 
Cc: Imre Deak 
Cc: Daniel Vetter 
Signed-off-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_irq.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f0d9414..03af766 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1089,6 +1089,9 @@ static void gen6_pm_rps_work(struct work_struct *work)
int new_delay, adj, min, max;
u32 pm_iir;
 
+   if (!dev_priv->mm.busy)
+   return;
+
spin_lock_irq(_priv->irq_lock);
/* Speed up work cancelation during disabling rps interrupts. */
if (!dev_priv->rps.interrupts_enabled) {
-- 
2.8.0

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

[Intel-gfx] [PATCH 1/4 v2] drm/i915: Early exit from rps worker if GPU is idle

[Michał Winiarski]

This allows us to avoid the situation where worker is increasing the GPU
frequency after we've switched to idle.

v2: Do not access ->mm.busy under ->irq_lock

References: https://bugs.freedesktop.org/show_bug.cgi?id=89728
Cc: Chris Wilson 
Cc: Imre Deak 
Cc: Daniel Vetter 
Signed-off-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_irq.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f0d9414..0344f4a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1096,6 +1096,9 @@ static void gen6_pm_rps_work(struct work_struct *work)
return;
}
 
+   if (!dev_priv->mm.busy)
+   return;
+
/*
 * The RPS work is synced during runtime suspend, we don't require a
 * wakeref. TODO: instead of disabling the asserts make sure that we
-- 
2.8.0

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

[Intel-gfx] [PATCH v2] drm/i915/bxt: reserve space for RC6 in the the GuC WOPCM

[Dave Gordon]

From: Peter Antoine 

This patch resizes the GuC WOPCM (specifically on BXT)
so that the GuC and RC6 memory spaces do not overlap.

v2:
Made calculation of WOPCM size into a separate function,
so that it's consistent between the firmware size-check
and the register-programming operations [Dave Gordon].

Issue: https://jira01.devtools.intel.com/browse/VIZ-6638
Signed-off-by: Peter Antoine 
Signed-off-by: Dave Gordon 
Reviewed-by: Nick Hoath 
Tested-by: Nick Hoath 
---
 drivers/gpu/drm/i915/i915_guc_reg.h |  6 +++---
 drivers/gpu/drm/i915/intel_guc_loader.c | 17 +
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h
index 80786d9..cf5a65b 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -67,11 +67,11 @@
 #define   GUC_WOPCM_OFFSET_VALUE 0x8   /* 512KB */
 #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4)
 
+/* Defines WOPCM space available to GuC firmware */
 #define GUC_WOPCM_SIZE _MMIO(0xc050)
-#define   GUC_WOPCM_SIZE_VALUE   (0x80 << 12)  /* 512KB */
-
 /* GuC addresses below GUC_WOPCM_TOP don't map through the GTT */
-#defineGUC_WOPCM_TOP   (GUC_WOPCM_SIZE_VALUE)
+#define   GUC_WOPCM_TOP  (0x80 << 12)  /* 512KB */
+#define   BXT_GUC_WOPCM_RC6_RESERVED (0x10 << 12)  /* 64KB  */
 
 #define GEN8_GT_PM_CONFIG  _MMIO(0x138140)
 #define GEN9LP_GT_PM_CONFIG_MMIO(0x138140)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 23345e1..34405de 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -284,6 +284,17 @@ static int guc_ucode_xfer_dma(struct drm_i915_private 
*dev_priv)
return ret;
 }
 
+static u32 guc_wopcm_size(struct drm_i915_private *dev_priv)
+{
+   u32 wopcm_size = GUC_WOPCM_TOP;
+
+   /* On BXT, the top of WOPCM is reserved for RC6 context */
+   if (IS_BROXTON(dev_priv))
+   wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
+
+   return wopcm_size;
+}
+
 /*
  * Load the GuC firmware blob into the MinuteIA.
  */
@@ -311,7 +322,7 @@ static int guc_ucode_xfer(struct drm_i915_private *dev_priv)
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
 
/* init WOPCM */
-   I915_WRITE(GUC_WOPCM_SIZE, GUC_WOPCM_SIZE_VALUE);
+   I915_WRITE(GUC_WOPCM_SIZE, guc_wopcm_size(dev_priv));
I915_WRITE(DMA_GUC_WOPCM_OFFSET, GUC_WOPCM_OFFSET_VALUE);
 
/* Enable MIA caching. GuC clock gating is disabled. */
@@ -555,9 +566,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* Header and uCode will be loaded to WOPCM. Size of the two. */
size = guc_fw->header_size + guc_fw->ucode_size;
-
-   /* Top 32k of WOPCM is reserved (8K stack + 24k RC6 context). */
-   if (size > GUC_WOPCM_SIZE_VALUE - 0x8000) {
+   if (size > guc_wopcm_size(dev->dev_private)) {
DRM_ERROR("Firmware is too large to fit in WOPCM\n");
goto fail;
}
-- 
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 1/3] drm/i915/hda: Add audio component stub

[Daniel Vetter]

On Tue, May 17, 2016 at 03:57:30PM +0200, Takashi Iwai wrote:
> On Tue, 17 May 2016 14:53:40 +0200,
> Takashi Iwai wrote:
> > 
> > On Tue, 17 May 2016 14:39:26 +0200,
> > Daniel Vetter wrote:
> > > 
> > > And if we _really_ want this to work at runtime too, then we need a
> > > system-wide nomodeset option that snd-hda can look up and act accordingly.
> > 
> > Yes, this would be one option.
> 
> And I noticed that this can be easily added to patch 3, just like i915
> driver does:
> 
> diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
> index c9af022676c2..c48a014be7b4 100644
> --- a/sound/hda/hdac_i915.c
> +++ b/sound/hda/hdac_i915.c
> @@ -361,6 +361,11 @@ int snd_hdac_i915_init(struct hdac_bus *bus)
>   if (WARN_ON(hdac_acomp))
>   return -EBUSY;
>  
> +#ifdef CONFIG_VGA_CONSOLE
> + if (vgacon_text_force())
> + return -ENODEV;
> +#endif

There's a dummy vgacon_text_force now, so you don't even need the #ifdef.
-Daniel

> +
>   if (!i915_gfx_present())
>   return -ENODEV;
>  
> 
> It's hackish, but should work practically enough...
> 
> 
> Takashi

-- 
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 i-g-t] autotools/: Keep gem_concurrent_blit in tests/ and put gem_conccurent_all in EXTRAS.

[Marius Vlad]

Ping?

On Tue, May 17, 2016 at 03:22:20PM +0200, Daniel Vetter wrote:
> On Tue, May 17, 2016 at 03:12:46PM +0300, Marius Vlad wrote:
> > An attempt to have piglit not taking too much time when listing tests,
> > but also keep tests/gem_concurrent_blit into list of tests.
> > 
> > This was added in a633ad03c6 (tests: Separate tests with lots of subtests) 
> > and
> > tried to be fixed c785a89ee (autotools/: Allow building
> > tests/gem_concurrent_{all, blit}) but without addressing the
> > comments of the reviewer. While at it, remove tests-lists-full.txt as it not
> > needed anymore.
> > 
> > https://lists.freedesktop.org/archives/intel-gfx/2016-April/092795.html
> > 
> > Signed-off-by: Marius Vlad 
> 
> Ack on both I think. Maybe ping Chris about this too, but I think he
> should be happy with gem_concurrent_blit back in the igt game.
> -Daniel
> 
> > ---
> >  tests/Makefile.am  | 15 +--
> >  tests/Makefile.sources | 17 ++---
> >  2 files changed, 7 insertions(+), 25 deletions(-)
> > 
> > diff --git a/tests/Makefile.am b/tests/Makefile.am
> > index c2c2025..359d911 100644
> > --- a/tests/Makefile.am
> > +++ b/tests/Makefile.am
> > @@ -14,11 +14,6 @@ test-list.txt: Makefile.sources
> > @echo ${single_kernel_tests} ${multi_kernel_tests} >> $@
> > @echo END TESTLIST >> $@
> >  
> > -test-list-full.txt: Makefile.sources
> > -   @echo TESTLIST > $@
> > -   @echo ${single_kernel_tests} ${multi_kernel_tests} 
> > ${extra_multi_kernel_tests} >> $@
> > -   @echo END TESTLIST >> $@
> > -
> >  
> >  noinst_PROGRAMS = \
> > $(HANG) \
> > @@ -28,9 +23,9 @@ noinst_PROGRAMS = \
> >  pkglibexec_PROGRAMS = \
> > gem_alive \
> > gem_stress \
> > +   gem_concurrent_all \
> > $(TESTS_progs) \
> > $(TESTS_progs_M) \
> > -   $(TESTS_progs_XM) \
> > $(NULL)
> >  
> >  dist_pkglibexec_SCRIPTS = \
> > @@ -45,14 +40,14 @@ dist_pkgdata_DATA = \
> >  
> >  all-local: .gitignore
> >  .gitignore: Makefile.sources
> > -   @echo "$(pkglibexec_PROGRAMS) $(HANG) test-list.txt test-list-full.txt 
> > .gitignore" | sed 's/\s\+/\n/g' | sort > $@
> > +   @echo "$(pkglibexec_PROGRAMS) $(HANG) test-list.txt .gitignore" | sed 
> > 's/\s\+/\n/g' | sort > $@
> >  
> > -pkgdata_DATA = test-list.txt test-list-full.txt
> > +pkgdata_DATA = test-list.txt
> >  
> > -EXTRA_PROGRAMS = $(HANG)
> > +EXTRA_PROGRAMS = $(HANG) gem_concurrent_all
> >  EXTRA_DIST = $(common_files)
> >  
> > -CLEANFILES = $(EXTRA_PROGRAMS) test-list.txt test-list-full.txt .gitignore
> > +CLEANFILES = $(EXTRA_PROGRAMS) test-list.txt .gitignore
> >  
> >  AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) $(DEBUG_CFLAGS)\
> > -I$(srcdir)/.. \
> > diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> > index 7b5f316..22dbaca 100644
> > --- a/tests/Makefile.sources
> > +++ b/tests/Makefile.sources
> > @@ -22,6 +22,7 @@ TESTS_progs_M = \
> > gem_close_race \
> > gem_create \
> > gem_cs_tlb \
> > +   gem_concurrent_blit \
> > gem_ctx_bad_exec \
> > gem_ctx_exec \
> > gem_ctx_param \
> > @@ -118,11 +119,6 @@ TESTS_progs_M = \
> > template \
> > $(NULL)
> >  
> > -TESTS_progs_XM = \
> > -gem_concurrent_blit \
> > -gem_concurrent_all \
> > -$(NULL)
> > -
> >  TESTS_progs = \
> > core_auth \
> > core_getclient \
> > @@ -226,14 +222,6 @@ multi_kernel_tests = \
> > $(NULL)
> >  
> >  
> > -# This target contains testcases with lots of subtests.
> > -# It was split from multi_kernel_tests because of the overhead of listing 
> > all
> > -# the subtests in piglit
> > -extra_multi_kernel_tests = \
> > -   $(TESTS_progs_XM) \
> > -   $(NULL)
> > -
> > -
> >  # This target is for simple testcase which don't expose any subtest.
> >  #
> >  # Your testcase should probably use igt_simple_main, but none of the other 
> > magic
> > @@ -251,8 +239,7 @@ kernel_tests = \
> >  kernel_tests_full = \
> >  $(single_kernel_tests) \
> >  $(multi_kernel_tests) \
> > -   $(extra_multi_kernel_tests) \
> > -   $(NULL)
> > +$(NULL)
> >  
> >  # Test that exercise specific asserts in the test framework library and are
> >  # hence expected to fail.
> > -- 
> > 2.8.0.rc3
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch


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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Early exit from rps worker if GPU is idle

[Daniel Vetter]

On Tue, May 17, 2016 at 03:53:03PM +0200, Michał Winiarski wrote:
> This allows us to avoid the situation where worker is increasing the GPU
> frequency after we've switched to idle.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=89728
> Cc: Chris Wilson 
> Cc: Imre Deak 
> Signed-off-by: Michał Winiarski 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index f0d9414..bb5b557 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1091,7 +1091,7 @@ static void gen6_pm_rps_work(struct work_struct *work)
>  
>   spin_lock_irq(_priv->irq_lock);
>   /* Speed up work cancelation during disabling rps interrupts. */
> - if (!dev_priv->rps.interrupts_enabled) {
> + if (!dev_priv->rps.interrupts_enabled || !dev_priv->mm.busy) {

And ->mm.busy is really protected by ->irq_lock? You're sure?
-Daniel

>   spin_unlock_irq(_priv->irq_lock);
>   return;
>   }
> -- 
> 2.8.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/6] Move dpio access out of intel_display.c

[Daniel Vetter]

On Tue, May 17, 2016 at 04:30:41PM +0300, Ander Conselvan De Oliveira wrote:
> On Tue, 2016-05-17 at 14:26 +0200, Daniel Vetter wrote:
> > On Fri, May 13, 2016 at 05:14:57PM +0300, Ander Conselvan de Oliveira wrote:
> > > 
> > > Hi,
> > > 
> > > This series moves all of the calls to vlv_dpio_{read,write} to
> > > intel_dpio_phy.c. I think it simplifies the surrounding code a bit.
> > You still owe us all the kerneldoc for the intel_dpll_mgr.c extraction.
> 
> https://patchwork.freedesktop.org/series/7294/
> 
> >  I think better to complete one extraction before starting the next one,
> > resulting in an even bigger mess than what we had before.
> 
> This is actually part of the same thing. These are prep patches for moving
> VLV/CHV into the dpll infrastructure. But fair enough.
> 
> 
> But I have to disagree this would create an even bigger mess. There is so much
> code in intel_display.c that most static functions there are the equivalent of
> an undocumented non-static function elsewhere. And since they are in the same
> pile of 400+ functions, it is not obvious the documentation is missing. So I'd
> claim splitting code out of intel_display.c, even if without documentation, is
> an improvement.

The problem is that we've done this for some of the atomic work and
fumbled the job, so now there's also a bunch of non-static functions that
should be static but can't because they ended up split across .c files. It
is possible to make it worse ;-)

> With the current rules we transfer the burden of writing documentation from 
> the
> person that made intel_display.c longer to the one trying to make it smaller.
> Maybe we should have an exception that everything in intel_display.c needs
> kerneldoc?

See above, I think writing docs is a crucial step of making things
actually more orthogonal, instead of just smearing it across more source
files. And from my quick review of the dpll doc patch I think we
can/should do better - at least if you don't look at kerneldoc as just a
typing exercise, but as an opportunity to really review everything.

And yes there's a problem with shifting the work, but I think the correct
fix for that is by volunteering the offenders who make intel_display.c
bigger to help out with cleaning up. Not by making it easier on those that
clean up, since that doesn't fix the source of the problem.

And I tried to help out in the past with a few ideas around extracting the
crtc platform support code, but those all died in bikesheds :(
-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 2/3] drm/i915: Add DCS control for Panel PWM

[Jani Nikula]

On Tue, 26 Apr 2016, "Adebisi, YetundeX"  wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Tuesday, April 26, 2016 2:14 PM
>> To: intel-gfx@lists.freedesktop.org
>> Cc: Nikula, Jani; Vetter, Daniel; Adebisi, YetundeX; Deepak, M
>> Subject: [PATCH 2/3] drm/i915: Add DCS control for Panel PWM
>> 
>> If the source of the backlight PWM is from the
>> panel then the PWM can be controlled by DCS
>> command, this patch adds the support to
>> enable/disbale panel PWM, control backlight level
>> etc...
>> 
>> v2: Moving the CABC bkl functions to new file.(Jani)
>> 
>> v3: Rebase
>> 
>> v4: Rebase
>> 
>> v5: Use mipi_dsi_dcs_write() instead of mipi_dsi_dcs_write_buffer() (Jani)
>> Move DCS macro`s to include/video/mipi_display.h (Jani)
>> 
>> v6: Rename the file to intel_dsi_panel_pwm.c
>> Removing the CABC operations
>> 
>> v7 by Jani: renames, rebases, etc.
>> 
>> v8 by Jani: s/INTEL_BACKLIGHT_CABC/INTEL_BACKLIGHT_DSI_DCS/
>> 
>> v9 by Jani: rename init function to intel_dsi_dcs_init_backlight_funcs
>> 
>> Cc: Jani Nikula 
>> Cc: Daniel Vetter 
>> Cc: Yetunde Adebisi 
>> Signed-off-by: Deepak M 
>> Signed-off-by: Jani Nikula 
>
> Reviewed-by: Yetunde Adebisi 

Pushed both to drm-intel-next-queued, thanks for the review.

BR,
Jani.



>> ---
>>  drivers/gpu/drm/i915/Makefile  |   1 +
>>  drivers/gpu/drm/i915/intel_drv.h   |   2 +
>>  drivers/gpu/drm/i915/intel_dsi.c   |  19 ++-
>>  drivers/gpu/drm/i915/intel_dsi.h   |   3 +
>>  drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c | 157
>> +
>>  drivers/gpu/drm/i915/intel_panel.c |   4 +
>>  6 files changed, 184 insertions(+), 2 deletions(-)
>>  create mode 100644 drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c
>> 
>> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>> index 723c50251127..b5ec800f953e 100644
>> --- a/drivers/gpu/drm/i915/Makefile
>> +++ b/drivers/gpu/drm/i915/Makefile
>> @@ -86,6 +86,7 @@ i915-y += dvo_ch7017.o \
>>intel_dp_mst.o \
>>intel_dp.o \
>>intel_dsi.o \
>> +  intel_dsi_dcs_backlight.o \
>>intel_dsi_panel_vbt.o \
>>intel_dsi_pll.o \
>>intel_dvo.o \
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index cb89a35a6755..d65dfbb8cf7d 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -1346,6 +1346,8 @@ void intel_dp_mst_encoder_cleanup(struct
>> intel_digital_port *intel_dig_port);
>>  /* intel_dsi.c */
>>  void intel_dsi_init(struct drm_device *dev);
>> 
>> +/* intel_dsi_dcs_backlight.c */
>> +int intel_dsi_dcs_init_backlight_funcs(struct intel_connector
>> *intel_connector);
>> 
>>  /* intel_dvo.c */
>>  void intel_dvo_init(struct drm_device *dev);
>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
>> b/drivers/gpu/drm/i915/intel_dsi.c
>> index 2b22bb9bb86f..2209f9fe6c4b 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>> @@ -1364,10 +1364,25 @@ void intel_dsi_init(struct drm_device *dev)
>>  else
>>  intel_encoder->crtc_mask = BIT(PIPE_B);
>> 
>> -if (dev_priv->vbt.dsi.config->dual_link)
>> +if (dev_priv->vbt.dsi.config->dual_link) {
>>  intel_dsi->ports = BIT(PORT_A) | BIT(PORT_C);
>> -else
>> +
>> +switch (dev_priv->vbt.dsi.config->dl_dcs_backlight_ports) {
>> +case DL_DCS_PORT_A:
>> +intel_dsi->dcs_backlight_ports = BIT(PORT_A);
>> +break;
>> +case DL_DCS_PORT_C:
>> +intel_dsi->dcs_backlight_ports = BIT(PORT_C);
>> +break;
>> +default:
>> +case DL_DCS_PORT_A_AND_C:
>> +intel_dsi->dcs_backlight_ports = BIT(PORT_A) |
>> BIT(PORT_C);
>> +break;
>> +}
>> +} else {
>>  intel_dsi->ports = BIT(port);
>> +intel_dsi->dcs_backlight_ports = BIT(port);
>> +}
>> 
>>  /* Create a DSI host (and a device) for each port. */
>>  for_each_dsi_port(port, intel_dsi->ports) {
>> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
>> b/drivers/gpu/drm/i915/intel_dsi.h
>> index 61a6957fc6c2..b00fb3fbb0b1 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi.h
>> +++ b/drivers/gpu/drm/i915/intel_dsi.h
>> @@ -78,6 +78,9 @@ struct intel_dsi {
>> 
>>  u8 escape_clk_div;
>>  u8 dual_link;
>> +
>> +u16 dcs_backlight_ports;
>> +
>>  u8 pixel_overlap;
>>  u32 port_bits;
>>  u32 bw_timer;
>> diff --git a/drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c
>> b/drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c
>> new file mode 100644
>> index ..7f9bbffa7f8c
>> --- /dev/null
>> +++ 

[Intel-gfx] [PATCH 2/4] drm/i915: Set softmin frequency when going from idle to busy

[Michał Winiarski]

If the GPU load is low enough, it's possible that we'll be stuck at idle
frequency rather than transition into softmin frequency requested by
userspace.
Let's transition into softmin as soon as we're going from idle to busy.

References: https://bugs.freedesktop.org/show_bug.cgi?id=89728
Cc: Chris Wilson 
Cc: Imre Deak 
Signed-off-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/intel_pm.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index adb6463..287a885 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4698,6 +4698,11 @@ void gen6_rps_busy(struct drm_i915_private *dev_priv)
 {
mutex_lock(_priv->rps.hw_lock);
if (dev_priv->rps.enabled) {
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+   valleyview_set_rps(dev_priv, 
dev_priv->rps.min_freq_softlimit);
+   else
+   gen6_set_rps(dev_priv, 
dev_priv->rps.min_freq_softlimit);
+
if (dev_priv->pm_rps_events & (GEN6_PM_RP_DOWN_EI_EXPIRED | 
GEN6_PM_RP_UP_EI_EXPIRED))
gen6_rps_reset_ei(dev_priv);
I915_WRITE(GEN6_PMINTRMSK,
-- 
2.8.0

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

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [v4,1/2] drm/i915: refactor i915_gem_object_pin_map()

[Dave Gordon]

On 17/05/16 14:23, Patchwork wrote:

== Series Details ==

Series: series starting with [v4,1/2] drm/i915: refactor 
i915_gem_object_pin_map()
URL   : https://patchwork.freedesktop.org/series/7292/
State : failure

== Summary ==

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

Test drv_hangman:
 Subgroup error-state-basic:
 pass   -> FAIL   (ro-ilk1-i5-650)


https://bugs.freedesktop.org/show_bug.cgi?id=94305

Seems to only happen on that one machine?

.Dave.


fi-bdw-i7-5557u  total:219  pass:206  dwarn:0   dfail:0   fail:0   skip:13
fi-bsw-n3050 total:218  pass:174  dwarn:0   dfail:0   fail:2   skip:42
fi-byt-n2820 total:218  pass:175  dwarn:0   dfail:0   fail:2   skip:41
fi-hsw-i7-4770k  total:219  pass:198  dwarn:0   dfail:0   fail:0   skip:21
fi-hsw-i7-4770r  total:219  pass:193  dwarn:0   dfail:0   fail:0   skip:26
fi-kbl-y total:219  pass:191  dwarn:1   dfail:0   fail:2   skip:25
fi-skl-i7-6700k  total:219  pass:191  dwarn:0   dfail:0   fail:0   skip:28
ro-bdw-i5-5250u  total:219  pass:181  dwarn:0   dfail:0   fail:0   skip:38
ro-bdw-i7-5557U  total:219  pass:206  dwarn:0   dfail:0   fail:0   skip:13
ro-bdw-i7-5600u  total:219  pass:187  dwarn:0   dfail:0   fail:0   skip:32
ro-byt-n2820 total:218  pass:175  dwarn:0   dfail:0   fail:2   skip:41
ro-hsw-i3-4010u  total:218  pass:193  dwarn:0   dfail:0   fail:0   skip:25
ro-hsw-i7-4770r  total:219  pass:194  dwarn:0   dfail:0   fail:0   skip:25
ro-ilk-i7-620lm  total:219  pass:151  dwarn:0   dfail:0   fail:1   skip:67
ro-ilk1-i5-650   total:214  pass:151  dwarn:0   dfail:0   fail:2   skip:61
ro-ivb-i7-3770   total:219  pass:183  dwarn:0   dfail:0   fail:0   skip:36
ro-ivb2-i7-3770  total:219  pass:187  dwarn:0   dfail:0   fail:0   skip:32
ro-skl-i7-6700hq total:214  pass:189  dwarn:0   dfail:0   fail:0   skip:25
ro-snb-i7-2620M  total:219  pass:177  dwarn:0   dfail:0   fail:1   skip:41
fi-snb-i7-2600 failed to connect after reboot
ro-bsw-n3050 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_918/

0d84413 drm-intel-nightly: 2016y-05m-17d-10h-26m-35s UTC integration manifest
cfa6373 drm/i915: optimise i915_gem_object_map() for small objects
1864abb drm/i915: refactor i915_gem_object_pin_map()


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

[Intel-gfx] [PATCH i-g-t] tests/pm_rps: Add handling of idle frequency exposed via sysfs

[Michał Winiarski]

Signed-off-by: Michał Winiarski 
---
 tests/pm_rps.c | 36 
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/tests/pm_rps.c b/tests/pm_rps.c
index c3d4417..a0e6655 100644
--- a/tests/pm_rps.c
+++ b/tests/pm_rps.c
@@ -45,6 +45,7 @@ static int drm_fd;
 static const char sysfs_base_path[] = "/sys/class/drm/card%d/gt_%s_freq_mhz";
 enum {
CUR,
+   IDL,
MIN,
MAX,
RP0,
@@ -60,7 +61,7 @@ struct junk {
const char *mode;
FILE *filp;
 } stuff[] = {
-   { "cur", "r", NULL }, { "min", "rb+", NULL }, { "max", "rb+", NULL }, { 
"RP0", "r", NULL }, { "RP1", "r", NULL }, { "RPn", "r", NULL }, { NULL, NULL, 
NULL }
+   { "cur", "r", NULL }, {"idl", "rb+", NULL }, { "min", "rb+", NULL }, { 
"max", "rb+", NULL }, { "RP0", "r", NULL }, { "RP1", "r", NULL }, { "RPn", "r", 
NULL }, { NULL, NULL, NULL }
 };
 
 static int readval(FILE *filp)
@@ -145,6 +146,7 @@ static int do_writeval(FILE *filp, int val, int lerrno, 
bool readback_check)
 static void checkit(const int *freqs)
 {
igt_assert_lte(freqs[MIN], freqs[MAX]);
+   igt_assert_lte(freqs[IDL], freqs[MIN]);
igt_assert_lte(freqs[CUR], freqs[MAX]);
igt_assert_lte(freqs[RPn], freqs[CUR]);
igt_assert_lte(freqs[RPn], freqs[MIN]);
@@ -160,6 +162,7 @@ static void matchit(const int *freqs1, const int *freqs2)
igt_assert_eq(freqs1[CUR], freqs2[CUR]);
igt_assert_eq(freqs1[MIN], freqs2[MIN]);
igt_assert_eq(freqs1[MAX], freqs2[MAX]);
+   igt_assert_eq(freqs1[IDL], freqs2[IDL]);
igt_assert_eq(freqs1[RP0], freqs2[RP0]);
igt_assert_eq(freqs1[RP1], freqs2[RP1]);
igt_assert_eq(freqs1[RPn], freqs2[RPn]);
@@ -379,19 +382,44 @@ static void min_max_config(void (*check)(void), bool 
load_gpu)
do_load_gpu();
check();
 
-   igt_debug("\nSet min=RPn and max=RP0...\n");
+   igt_debug("\nSet idle=RPn, min=RPn and max=RP0...\n");
+   writeval(stuff[IDL].filp, origfreqs[RPn]);
writeval(stuff[MIN].filp, origfreqs[RPn]);
writeval(stuff[MAX].filp, origfreqs[RP0]);
if (load_gpu)
do_load_gpu();
check();
 
+   igt_debug("\nIncrease idle above min (invalid)...\n");
+   writeval_inval(stuff[IDL].filp, origfreqs[RPn] + 100);
+   if (load_gpu)
+   do_load_gpu();
+   check();
+
igt_debug("\nIncrease min to midpoint...\n");
writeval(stuff[MIN].filp, fmid);
if (load_gpu)
do_load_gpu();
check();
 
+   igt_debug("\nIncrease idle to midpoint...\n");
+   writeval(stuff[IDL].filp, fmid);
+   if (load_gpu)
+   do_load_gpu();
+   check();
+
+   igt_debug("\nDecrease min below idle (invalid)...\n");
+   writeval_inval(stuff[MIN].filp, fmid - 100);
+   if (load_gpu)
+   do_load_gpu();
+   check();
+
+   igt_debug("\nDecrease idle to RPn...\n");
+   writeval(stuff[IDL].filp, origfreqs[RPn]);
+   if (load_gpu)
+   do_load_gpu();
+   check();
+
igt_debug("\nIncrease min to RP0...\n");
writeval(stuff[MIN].filp, origfreqs[RP0]);
if (load_gpu)
@@ -476,13 +504,13 @@ static void idle_check(void)
read_freqs(freqs);
dump(freqs);
checkit(freqs);
-   if (freqs[CUR] == freqs[RPn])
+   if (freqs[CUR] == freqs[IDL])
break;
usleep(1000 * IDLE_WAIT_TIMESTEP_MSEC);
wait += IDLE_WAIT_TIMESTEP_MSEC;
} while (wait < IDLE_WAIT_TIMEOUT_MSEC);
 
-   igt_assert_eq(freqs[CUR], freqs[RPn]);
+   igt_assert_eq(freqs[CUR], freqs[IDL]);
igt_debug("Required %d msec to reach cur=idle\n", wait);
 }
 
-- 
2.8.0

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

[Intel-gfx] [PATCH 4/4] drm/i915: Extract common get/set frequency limits functions

[Michał Winiarski]

No functional changes other than using regular mutex_lock instead of
interruptible one for debugfs.

Cc: Chris Wilson 
Signed-off-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 116 ++
 drivers/gpu/drm/i915/i915_drv.h |  10 +++
 drivers/gpu/drm/i915/i915_sysfs.c   | 123 
 drivers/gpu/drm/i915/intel_pm.c |  86 +
 4 files changed, 115 insertions(+), 220 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6988213..4bdc0c5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4939,19 +4939,11 @@ i915_max_freq_get(void *data, u64 *val)
 {
struct drm_device *dev = data;
struct drm_i915_private *dev_priv = dev->dev_private;
-   int ret;
 
if (INTEL_INFO(dev)->gen < 6)
return -ENODEV;
 
-   flush_delayed_work(_priv->rps.delayed_resume_work);
-
-   ret = mutex_lock_interruptible(_priv->rps.hw_lock);
-   if (ret)
-   return ret;
-
-   *val = intel_gpu_freq(dev_priv, dev_priv->rps.max_freq_softlimit);
-   mutex_unlock(_priv->rps.hw_lock);
+   *val = intel_gpu_freq_limit_get(dev_priv, MAX_FREQ);
 
return 0;
 }
@@ -4961,40 +4953,13 @@ i915_max_freq_set(void *data, u64 val)
 {
struct drm_device *dev = data;
struct drm_i915_private *dev_priv = dev->dev_private;
-   u32 hw_max, hw_min;
-   int ret;
 
if (INTEL_INFO(dev)->gen < 6)
return -ENODEV;
 
-   flush_delayed_work(_priv->rps.delayed_resume_work);
-
DRM_DEBUG_DRIVER("Manually setting max freq to %llu\n", val);
 
-   ret = mutex_lock_interruptible(_priv->rps.hw_lock);
-   if (ret)
-   return ret;
-
-   /*
-* Turbo will still be enabled, but won't go above the set value.
-*/
-   val = intel_freq_opcode(dev_priv, val);
-
-   hw_max = dev_priv->rps.max_freq;
-   hw_min = dev_priv->rps.min_freq;
-
-   if (val < hw_min || val > hw_max || val < 
dev_priv->rps.min_freq_softlimit) {
-   mutex_unlock(_priv->rps.hw_lock);
-   return -EINVAL;
-   }
-
-   dev_priv->rps.max_freq_softlimit = val;
-
-   intel_set_rps(dev_priv, val);
-
-   mutex_unlock(_priv->rps.hw_lock);
-
-   return 0;
+   return intel_gpu_freq_limit_set(dev_priv, MAX_FREQ, val);
 }
 
 DEFINE_SIMPLE_ATTRIBUTE(i915_max_freq_fops,
@@ -5006,19 +4971,11 @@ i915_min_freq_get(void *data, u64 *val)
 {
struct drm_device *dev = data;
struct drm_i915_private *dev_priv = dev->dev_private;
-   int ret;
 
if (INTEL_INFO(dev)->gen < 6)
return -ENODEV;
 
-   flush_delayed_work(_priv->rps.delayed_resume_work);
-
-   ret = mutex_lock_interruptible(_priv->rps.hw_lock);
-   if (ret)
-   return ret;
-
-   *val = intel_gpu_freq(dev_priv, dev_priv->rps.min_freq_softlimit);
-   mutex_unlock(_priv->rps.hw_lock);
+   *val = intel_gpu_freq_limit_get(dev_priv, MIN_FREQ);
 
return 0;
 }
@@ -5028,42 +4985,13 @@ i915_min_freq_set(void *data, u64 val)
 {
struct drm_device *dev = data;
struct drm_i915_private *dev_priv = dev->dev_private;
-   u32 hw_max, hw_min;
-   int ret;
 
if (INTEL_INFO(dev)->gen < 6)
return -ENODEV;
 
-   flush_delayed_work(_priv->rps.delayed_resume_work);
-
DRM_DEBUG_DRIVER("Manually setting min freq to %llu\n", val);
 
-   ret = mutex_lock_interruptible(_priv->rps.hw_lock);
-   if (ret)
-   return ret;
-
-   /*
-* Turbo will still be enabled, but won't go below the set value.
-*/
-   val = intel_freq_opcode(dev_priv, val);
-
-   hw_max = dev_priv->rps.max_freq;
-   hw_min = dev_priv->rps.min_freq;
-
-   if (val < hw_min || val > hw_max ||
-   val > dev_priv->rps.max_freq_softlimit ||
-   val < dev_priv->rps.idle_freq) {
-   mutex_unlock(_priv->rps.hw_lock);
-   return -EINVAL;
-   }
-
-   dev_priv->rps.min_freq_softlimit = val;
-
-   intel_set_rps(dev_priv, val);
-
-   mutex_unlock(_priv->rps.hw_lock);
-
-   return 0;
+   return intel_gpu_freq_limit_set(dev_priv, MIN_FREQ, val);
 }
 
 DEFINE_SIMPLE_ATTRIBUTE(i915_min_freq_fops,
@@ -5075,19 +5003,11 @@ i915_idle_freq_get(void *data, u64 *val)
 {
struct drm_device *dev = data;
struct drm_i915_private *dev_priv = dev->dev_private;
-   int ret;
 
if (INTEL_INFO(dev)->gen < 6)
return -ENODEV;
 
-   flush_delayed_work(_priv->rps.delayed_resume_work);
-
-   ret = mutex_lock_interruptible(_priv->rps.hw_lock);
-   if (ret)
-   return ret;
-
-   *val = intel_gpu_freq(dev_priv, dev_priv->rps.idle_freq);
-   

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub

[Takashi Iwai]

On Tue, 17 May 2016 14:53:40 +0200,
Takashi Iwai wrote:
> 
> On Tue, 17 May 2016 14:39:26 +0200,
> Daniel Vetter wrote:
> > 
> > And if we _really_ want this to work at runtime too, then we need a
> > system-wide nomodeset option that snd-hda can look up and act accordingly.
> 
> Yes, this would be one option.

And I noticed that this can be easily added to patch 3, just like i915
driver does:

diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
index c9af022676c2..c48a014be7b4 100644
--- a/sound/hda/hdac_i915.c
+++ b/sound/hda/hdac_i915.c
@@ -361,6 +361,11 @@ int snd_hdac_i915_init(struct hdac_bus *bus)
if (WARN_ON(hdac_acomp))
return -EBUSY;
 
+#ifdef CONFIG_VGA_CONSOLE
+   if (vgacon_text_force())
+   return -ENODEV;
+#endif
+
if (!i915_gfx_present())
return -ENODEV;
 

It's hackish, but should work practically enough...


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

[Intel-gfx] [PATCH 3/4] drm/i915: Allow controlling idle frequency from userspace

[Michał Winiarski]

Since commit aed242ff7ebb697e4dff912bd4dc7ec7192f7581
Author: Chris Wilson 
Date:   Wed Mar 18 09:48:21 2015 +

drm/i915: Relax RPS contraints to allows setting minfreq on idle

When we idle, we set the GPU frequency to the hardware minimum (not user
minimum).

Let's add sysfs/debugfs knobs allowing userspace to control idle
frequency, similar to softmin/softmax frequency.

Cc: Chris Wilson 
Signed-off-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 69 -
 drivers/gpu/drm/i915/i915_sysfs.c   | 69 -
 drivers/gpu/drm/i915/intel_pm.c | 20 ++-
 3 files changed, 148 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 24f4105..6988213 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -5050,7 +5050,9 @@ i915_min_freq_set(void *data, u64 val)
hw_max = dev_priv->rps.max_freq;
hw_min = dev_priv->rps.min_freq;
 
-   if (val < hw_min || val > hw_max || val > 
dev_priv->rps.max_freq_softlimit) {
+   if (val < hw_min || val > hw_max ||
+   val > dev_priv->rps.max_freq_softlimit ||
+   val < dev_priv->rps.idle_freq) {
mutex_unlock(_priv->rps.hw_lock);
return -EINVAL;
}
@@ -5069,6 +5071,70 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_min_freq_fops,
"%llu\n");
 
 static int
+i915_idle_freq_get(void *data, u64 *val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   int ret;
+
+   if (INTEL_INFO(dev)->gen < 6)
+   return -ENODEV;
+
+   flush_delayed_work(_priv->rps.delayed_resume_work);
+
+   ret = mutex_lock_interruptible(_priv->rps.hw_lock);
+   if (ret)
+   return ret;
+
+   *val = intel_gpu_freq(dev_priv, dev_priv->rps.idle_freq);
+   mutex_unlock(_priv->rps.hw_lock);
+
+   return 0;
+}
+
+static int
+i915_idle_freq_set(void *data, u64 val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 hw_max, hw_min;
+   int ret;
+
+   if (INTEL_INFO(dev)->gen < 6)
+   return -ENODEV;
+
+   flush_delayed_work(_priv->rps.delayed_resume_work);
+
+   DRM_DEBUG_DRIVER("Manually setting idle freq to %llu\n", val);
+
+   ret = mutex_lock_interruptible(_priv->rps.hw_lock);
+   if (ret)
+   return ret;
+
+   val = intel_freq_opcode(dev_priv, val);
+
+   hw_max = dev_priv->rps.max_freq;
+   hw_min = dev_priv->rps.min_freq;
+
+   if (val < hw_min || val > hw_max || val > 
dev_priv->rps.min_freq_softlimit) {
+   mutex_unlock(_priv->rps.hw_lock);
+   return -EINVAL;
+   }
+
+   dev_priv->rps.idle_freq = val;
+
+   intel_set_rps(dev_priv, val);
+
+   mutex_unlock(_priv->rps.hw_lock);
+
+   return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_idle_freq_fops,
+   i915_idle_freq_get, i915_idle_freq_set,
+   "%llu\n");
+
+static int
 i915_cache_sharing_get(void *data, u64 *val)
 {
struct drm_device *dev = data;
@@ -5436,6 +5502,7 @@ static const struct i915_debugfs_files {
{"i915_wedged", _wedged_fops},
{"i915_max_freq", _max_freq_fops},
{"i915_min_freq", _min_freq_fops},
+   {"i915_idle_freq", _idle_freq_fops},
{"i915_cache_sharing", _cache_sharing_fops},
{"i915_ring_stop", _ring_stop_fops},
{"i915_ring_missed_irq", _ring_missed_irq_fops},
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 37b6444..1c6930a 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -445,7 +445,8 @@ static ssize_t gt_min_freq_mhz_store(struct device *kdev,
 
if (val < dev_priv->rps.min_freq ||
val > dev_priv->rps.max_freq ||
-   val > dev_priv->rps.max_freq_softlimit) {
+   val > dev_priv->rps.max_freq_softlimit ||
+   val < dev_priv->rps.idle_freq) {
mutex_unlock(_priv->rps.hw_lock);
intel_runtime_pm_put(dev_priv);
return -EINVAL;
@@ -470,10 +471,74 @@ static ssize_t gt_min_freq_mhz_store(struct device *kdev,
 
 }
 
+static ssize_t gt_idle_freq_mhz_show(struct device *kdev, struct 
device_attribute *attr, char *buf)
+{
+   struct drm_minor *minor = dev_to_drm_minor(kdev);
+   struct drm_device *dev = minor->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   int ret;
+
+   flush_delayed_work(_priv->rps.delayed_resume_work);
+
+   mutex_lock(_priv->rps.hw_lock);
+   ret = intel_gpu_freq(dev_priv, dev_priv->rps.idle_freq);
+   mutex_unlock(_priv->rps.hw_lock);
+
+   return snprintf(buf, 

[Intel-gfx] [PATCH 1/4] drm/i915: Early exit from rps worker if GPU is idle

[Michał Winiarski]

This allows us to avoid the situation where worker is increasing the GPU
frequency after we've switched to idle.

References: https://bugs.freedesktop.org/show_bug.cgi?id=89728
Cc: Chris Wilson 
Cc: Imre Deak 
Signed-off-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f0d9414..bb5b557 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1091,7 +1091,7 @@ static void gen6_pm_rps_work(struct work_struct *work)
 
spin_lock_irq(_priv->irq_lock);
/* Speed up work cancelation during disabling rps interrupts. */
-   if (!dev_priv->rps.interrupts_enabled) {
+   if (!dev_priv->rps.interrupts_enabled || !dev_priv->mm.busy) {
spin_unlock_irq(_priv->irq_lock);
return;
}
-- 
2.8.0

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for Rework page flip, remove cs flips, async unpin and unified pageflip. (rev5)

[Patchwork]

== Series Details ==

Series: Rework page flip, remove cs flips, async unpin and unified pageflip. 
(rev5)
URL   : https://patchwork.freedesktop.org/series/5913/
State : failure

== Summary ==

Series 5913v5 Rework page flip, remove cs flips, async unpin and unified 
pageflip.
http://patchwork.freedesktop.org/api/1.0/series/5913/revisions/5/mbox

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
pass   -> FAIL   (ro-byt-n2820)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> FAIL   (ro-bdw-i7-5600u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-hsw-i7-4770k)

fi-bdw-i7-5557u  total:219  pass:206  dwarn:0   dfail:0   fail:0   skip:13 
fi-bsw-n3050 total:218  pass:174  dwarn:0   dfail:0   fail:2   skip:42 
fi-byt-n2820 total:218  pass:175  dwarn:0   dfail:0   fail:2   skip:41 
fi-hsw-i7-4770k  total:200  pass:180  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-i7-4770r  total:219  pass:193  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-y total:219  pass:191  dwarn:1   dfail:0   fail:2   skip:25 
fi-skl-i7-6700k  total:219  pass:191  dwarn:0   dfail:0   fail:0   skip:28 
ro-bdw-i5-5250u  total:219  pass:181  dwarn:0   dfail:0   fail:0   skip:38 
ro-bdw-i7-5557U  total:219  pass:206  dwarn:0   dfail:0   fail:0   skip:13 
ro-bdw-i7-5600u  total:219  pass:186  dwarn:0   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:219  pass:175  dwarn:0   dfail:0   fail:2   skip:42 
ro-byt-n2820 total:218  pass:174  dwarn:0   dfail:0   fail:3   skip:41 
ro-hsw-i3-4010u  total:218  pass:193  dwarn:0   dfail:0   fail:0   skip:25 
ro-hsw-i7-4770r  total:219  pass:194  dwarn:0   dfail:0   fail:0   skip:25 
ro-ilk-i7-620lm  total:219  pass:151  dwarn:0   dfail:0   fail:1   skip:67 
ro-ilk1-i5-650   total:214  pass:152  dwarn:0   dfail:0   fail:1   skip:61 
ro-ivb-i7-3770   total:219  pass:183  dwarn:0   dfail:0   fail:0   skip:36 
ro-ivb2-i7-3770  total:219  pass:187  dwarn:0   dfail:0   fail:0   skip:32 
ro-skl-i7-6700hq total:214  pass:189  dwarn:0   dfail:0   fail:0   skip:25 
ro-snb-i7-2620M  total:219  pass:177  dwarn:0   dfail:0   fail:1   skip:41 

Results at /archive/results/CI_IGT_test/RO_Patchwork_919/

0d84413 drm-intel-nightly: 2016y-05m-17d-10h-26m-35s UTC integration manifest
a2c72a3 drm/i915: Allow async update of pageflips.
d157ac1 drm/i915: Check for unpin correctness.
ca08d55 Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor 
updates"
420aec4 drm/i915: Make unpin async.
e271bea drm/i915: Prepare connectors for nonblocking checks.
134d35f drm/i915: Pass atomic states to fbc update functions.
9f9c8ed drm/i915: Remove reset_counter from intel_crtc.
189586e drm/i915: Remove queue_flip pointer.
c8686e1 drm/i915: Remove use_mmio_flip kernel parameter.
5f348d1 drm/i915: Remove cs based page flip support.
5c0c00b drm/i915: Rework intel_crtc_page_flip to be almost atomic, v3.
3b9206a drm/i915: Add the exclusive fence to plane_state.
c5cba85 drm/i915: Convert flip_work to a list.
083d29c drm/i915: Allow mmio updates on all platforms, v2.
dfb532f Revert "drm/i915: Avoid stalling on pending flips for legacy cursor 
updates"
09836b7 drm/i915: Unify unpin_work and mmio_work into flip_work, v2.
e751c30 drm/i915: Add support for detecting vblanks when hw frame counter is 
unavailable.
1f80e9d drm/i915: Remove intel_prepare_page_flip, v3.
8a54888 drm/i915: Remove intel_finish_page_flip_plane.
688db04 drm/i915: Remove stallcheck special handling, v3.
5f42382 drm/core: Add drm_accurate_vblank_count, v5.

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

[Intel-gfx] [PATCH] drm/i915: Add ppgtt->kunmap_page_dma vfunc

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Rather than asking itself "am I a Broadwell, am I a Cherryview,
or am I neither of the two" on on low level page table operations,
like inserting and clearing PTEs; add a new vfunc kunmap_page_dma
and set it to appropriate flavour at ppgtt init time.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 51 +++--
 drivers/gpu/drm/i915/i915_gem_gtt.h |  1 +
 2 files changed, 33 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7eab619a3eb2..dc7e128d7483 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -361,29 +361,30 @@ static void *kmap_page_dma(struct i915_page_dma *p)
return kmap_atomic(p->page);
 }
 
+static void kunmap_page_dma(void *vaddr)
+{
+   kunmap_atomic(vaddr);
+}
+
 /* We use the flushing unmap only with ppgtt structures:
  * page directories, page tables and scratch pages.
  */
-static void kunmap_page_dma(struct drm_device *dev, void *vaddr)
+static void kunmap_page_dma_flush(void *vaddr)
 {
-   /* There are only few exceptions for gen >=6. chv and bxt.
-* And we are not sure about the latter so play safe for now.
-*/
-   if (IS_CHERRYVIEW(dev) || IS_BROXTON(dev))
-   drm_clflush_virt_range(vaddr, PAGE_SIZE);
+   drm_clflush_virt_range(vaddr, PAGE_SIZE);
 
kunmap_atomic(vaddr);
 }
 
 #define kmap_px(px) kmap_page_dma(px_base(px))
-#define kunmap_px(ppgtt, vaddr) kunmap_page_dma((ppgtt)->base.dev, (vaddr))
+#define kunmap_px(ppgtt, vaddr) (ppgtt)->kunmap_page_dma((vaddr))
 
 #define setup_px(dev, px) setup_page_dma((dev), px_base(px))
 #define cleanup_px(dev, px) cleanup_page_dma((dev), px_base(px))
-#define fill_px(dev, px, v) fill_page_dma((dev), px_base(px), (v))
-#define fill32_px(dev, px, v) fill_page_dma_32((dev), px_base(px), (v))
+#define fill_px(ppgtt, px, v) fill_page_dma((ppgtt), px_base(px), (v))
+#define fill32_px(ppgtt, px, v) fill_page_dma_32((ppgtt), px_base(px), (v))
 
-static void fill_page_dma(struct drm_device *dev, struct i915_page_dma *p,
+static void fill_page_dma(struct i915_hw_ppgtt *ppgtt, struct i915_page_dma *p,
  const uint64_t val)
 {
int i;
@@ -392,17 +393,17 @@ static void fill_page_dma(struct drm_device *dev, struct 
i915_page_dma *p,
for (i = 0; i < 512; i++)
vaddr[i] = val;
 
-   kunmap_page_dma(dev, vaddr);
+   ppgtt->kunmap_page_dma(vaddr);
 }
 
-static void fill_page_dma_32(struct drm_device *dev, struct i915_page_dma *p,
-const uint32_t val32)
+static void fill_page_dma_32(struct i915_hw_ppgtt *ppgtt,
+struct i915_page_dma *p, const uint32_t val32)
 {
uint64_t v = val32;
 
v = v << 32 | val32;
 
-   fill_page_dma(dev, p, v);
+   fill_page_dma(ppgtt, p, v);
 }
 
 static struct i915_page_scratch *alloc_scratch_page(struct drm_device *dev)
@@ -480,7 +481,7 @@ static void gen8_initialize_pt(struct i915_address_space 
*vm,
scratch_pte = gen8_pte_encode(px_dma(vm->scratch_page),
  I915_CACHE_LLC, true);
 
-   fill_px(vm->dev, pt, scratch_pte);
+   fill_px(i915_vm_to_ppgtt(vm), pt, scratch_pte);
 }
 
 static void gen6_initialize_pt(struct i915_address_space *vm,
@@ -493,7 +494,7 @@ static void gen6_initialize_pt(struct i915_address_space 
*vm,
scratch_pte = vm->pte_encode(px_dma(vm->scratch_page),
 I915_CACHE_LLC, true, 0);
 
-   fill32_px(vm->dev, pt, scratch_pte);
+   fill32_px(i915_vm_to_ppgtt(vm), pt, scratch_pte);
 }
 
 static struct i915_page_directory *alloc_pd(struct drm_device *dev)
@@ -540,7 +541,7 @@ static void gen8_initialize_pd(struct i915_address_space 
*vm,
 
scratch_pde = gen8_pde_encode(px_dma(vm->scratch_pt), I915_CACHE_LLC);
 
-   fill_px(vm->dev, pd, scratch_pde);
+   fill_px(i915_vm_to_ppgtt(vm), pd, scratch_pde);
 }
 
 static int __pdp_init(struct drm_device *dev,
@@ -621,7 +622,7 @@ static void gen8_initialize_pdp(struct i915_address_space 
*vm,
 
scratch_pdpe = gen8_pdpe_encode(px_dma(vm->scratch_pd), I915_CACHE_LLC);
 
-   fill_px(vm->dev, pdp, scratch_pdpe);
+   fill_px(i915_vm_to_ppgtt(vm), pdp, scratch_pdpe);
 }
 
 static void gen8_initialize_pml4(struct i915_address_space *vm,
@@ -632,7 +633,7 @@ static void gen8_initialize_pml4(struct i915_address_space 
*vm,
scratch_pml4e = gen8_pml4e_encode(px_dma(vm->scratch_pdp),
  I915_CACHE_LLC);
 
-   fill_px(vm->dev, pml4, scratch_pml4e);
+   fill_px(i915_vm_to_ppgtt(vm), pml4, scratch_pml4e);
 }
 
 static void
@@ -1512,8 +1513,17 @@ static int gen8_preallocate_top_level_pdps(struct 
i915_hw_ppgtt *ppgtt)
  */
 static int gen8_ppgtt_init(struct 

Re: [Intel-gfx] [PATCH] drm/i915: Update kerneldoc for intel_dpll_mgr.c

[Daniel Vetter]

On Tue, May 17, 2016 at 04:18:16PM +0300, Ander Conselvan de Oliveira wrote:
> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 68 
> ---

You also need to add a stanza to Documentation/DocBook/gpu.tmpl to
actually include this.

Would also be good to document struct intel_dpll and the vfunc stuff and
pull that into the same section in gpu.tmpl too.

>  1 file changed, 63 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index c283ba4..36566f8 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -23,6 +23,13 @@

A few sentences in a DOC: section about what this is supposed to do (also
pulled into gpu.tmpl) would be nice. Especially a short overview over the
expected calling sequence (in speudo-code, if you have asciidoc installed
that should work on top of drm-intel-nightly with topic/kerneldoc).

>  
>  #include "intel_drv.h"
>  
> +/** intel_get_shared_dpll_by_id - get a DPLL given its id

I think kernel-doc wants a newline after the /**

> + * @dev_priv: i915 device instance
> + * @id: pll id
> + *
> + * Returns:
> + * A pointer the DPLL with @id
> + */
>  struct intel_shared_dpll *
>  intel_get_shared_dpll_by_id(struct drm_i915_private *dev_priv,
>   enum intel_dpll_id id)
> @@ -30,6 +37,13 @@ intel_get_shared_dpll_by_id(struct drm_i915_private 
> *dev_priv,
>   return _priv->shared_dplls[id];
>  }
>  
> +/** intel_get_shared_dpll_id - get the id of a DPLL
> + * @dev_priv: i915 device instance
> + * @pll: the DPLL
> + *
> + * Returns:
> + * The id of @pll
> + */
>  enum intel_dpll_id
>  intel_get_shared_dpll_id(struct drm_i915_private *dev_priv,
>struct intel_shared_dpll *pll)
> @@ -41,6 +55,15 @@ intel_get_shared_dpll_id(struct drm_i915_private *dev_priv,
>   return (enum intel_dpll_id) (pll - dev_priv->shared_dplls);
>  }
>  
> +/** intel_shared_dpll_config_get - get a reference to a DPLL for a crtc
> + * @config: a intel_shared_dpll_config struct
> + * @pll: pll to get a reference to
> + * @crtc: crtc that references the pll
> + *
> + * This gets a reference to @pll for @crtc. Internally is sets the pll's
> + * crtc_mask. @config should be the pll configuration in an atomic state.
> + * A crtc can reference a pll only once.

Please add "The acquired reference should be dropped again with
intel_shared_dpll_config_put()." With that kerneldoc will add a
cross-reference.

Also I thought with atomic we don't need get/put anymore, and state
handling is tracked entirely through the atomic check/commit stuff? Also,
grep tells me that we could make this static, which avoids the need to add
kernel-doc and also resolves some of the confusion we have here. Maybe
even just inline _get()/_put() to avoid confusing name - these aren't
refcounted anymore, but tracking in atomic states.

> + */
>  void
>  intel_shared_dpll_config_get(struct intel_shared_dpll_config *config,
>struct intel_shared_dpll *pll,
> @@ -52,6 +75,14 @@ intel_shared_dpll_config_get(struct 
> intel_shared_dpll_config *config,
>   config[id].crtc_mask |= 1 << crtc->pipe;
>  }
>  
> +/** intel_shared_dpll_config_put - release a reference to a DPLL for a crtc
> + * @config: a intel_shared_dpll_config struct
> + * @pll: pll that is referenced by @crtc
> + * @crtc: crtc that references the pll
> + *
> + * This releases the reference to @pll for @crtc. Internally is sets the 
> pll's
> + * crtc_mask. @config should be the pll configuration in an atomic state.
> + */
>  void
>  intel_shared_dpll_config_put(struct intel_shared_dpll_config *config,
>struct intel_shared_dpll *pll,
> @@ -80,6 +111,9 @@ void assert_shared_dpll(struct drm_i915_private *dev_priv,
>   pll->name, onoff(state), onoff(cur_state));
>  }
>  
> +/** intel_prepare_shared_dpll - call a dpll's mode_set hook
> + * @crtc: crtc which has a shared dpll
> + */
>  void intel_prepare_shared_dpll(struct intel_crtc *crtc)
>  {
>   struct drm_device *dev = crtc->base.dev;
> @@ -102,12 +136,10 @@ void intel_prepare_shared_dpll(struct intel_crtc *crtc)
>  }
>  
>  /**
> - * intel_enable_shared_dpll - enable PCH PLL
> - * @dev_priv: i915 private structure
> - * @pipe: pipe PLL to enable
> + * intel_enable_shared_dpll - enable a crtc's shared DPLL
> + * @crtc: crtc which has a shared DPLL
>   *
> - * The PCH PLL needs to be enabled before the PCH transcoder, since it
> - * drives the transcoder clock.
> + * Enable the shared DPLL used by @crtc.
>   */
>  void intel_enable_shared_dpll(struct intel_crtc *crtc)
>  {
> @@ -148,6 +180,12 @@ out:
>   mutex_unlock(_priv->dpll_lock);
>  }
>  
> +/**
> + * intel_disable_shared_dpll - disable a crtc's shared DPLL
> + * @crtc: crtc which has a shared DPLL
> + *
> + * 

Re: [Intel-gfx] [PATCH 0/6] Move dpio access out of intel_display.c

[Ander Conselvan De Oliveira]

On Tue, 2016-05-17 at 14:26 +0200, Daniel Vetter wrote:
> On Fri, May 13, 2016 at 05:14:57PM +0300, Ander Conselvan de Oliveira wrote:
> > 
> > Hi,
> > 
> > This series moves all of the calls to vlv_dpio_{read,write} to
> > intel_dpio_phy.c. I think it simplifies the surrounding code a bit.
> You still owe us all the kerneldoc for the intel_dpll_mgr.c extraction.

https://patchwork.freedesktop.org/series/7294/

>  I think better to complete one extraction before starting the next one,
> resulting in an even bigger mess than what we had before.

This is actually part of the same thing. These are prep patches for moving
VLV/CHV into the dpll infrastructure. But fair enough.


But I have to disagree this would create an even bigger mess. There is so much
code in intel_display.c that most static functions there are the equivalent of
an undocumented non-static function elsewhere. And since they are in the same
pile of 400+ functions, it is not obvious the documentation is missing. So I'd
claim splitting code out of intel_display.c, even if without documentation, is
an improvement.

With the current rules we transfer the burden of writing documentation from the
person that made intel_display.c longer to the one trying to make it smaller.
Maybe we should have an exception that everything in intel_display.c needs
kerneldoc?

Ander


> -Daniel
> 
> > 
> > 
> > Thanks,
> > Ander
> > 
> > Ander Conselvan de Oliveira (6):
> >   drm/i915: Rename struct dpll to struct intel_dpll
> >   drm/i915: Move dpio code of VLV/CHV dpll enabling to intel_dpio_phy.c
> >   drm/i915: Merge vlv/chv _prepare_pll() with their enable counterpart
> >   drm/i915: Move VLV divider readout to intel_dpio_phy.c
> >   drm/i915: Move CHV divider readout to intel_dpio_phy.c
> >   drm/i915: Move toggling of CHV DPIO_DCLKP_EN to intel_dpio_phy.c
> > 
> >  drivers/gpu/drm/i915/i915_drv.h   |  14 +-
> >  drivers/gpu/drm/i915/intel_ddi.c  |   2 +-
> >  drivers/gpu/drm/i915/intel_display.c  | 395 ++-
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c   |   2 +-
> >  drivers/gpu/drm/i915/intel_dpio_phy.c | 260 ++
> >  drivers/gpu/drm/i915/intel_dpll_mgr.c |   2 +-
> >  drivers/gpu/drm/i915/intel_drv.h  |  10 +-
> >  drivers/gpu/drm/i915/intel_sdvo.c |   2 +-
> >  8 files changed, 350 insertions(+), 337 deletions(-)
> > 
> > -- 
> > 2.5.5
> > 
> > ___
> > 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] ✗ Ro.CI.BAT: failure for series starting with [v4,1/2] drm/i915: refactor i915_gem_object_pin_map()

[Patchwork]

== Series Details ==

Series: series starting with [v4,1/2] drm/i915: refactor 
i915_gem_object_pin_map()
URL   : https://patchwork.freedesktop.org/series/7292/
State : failure

== Summary ==

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

Test drv_hangman:
Subgroup error-state-basic:
pass   -> FAIL   (ro-ilk1-i5-650)

fi-bdw-i7-5557u  total:219  pass:206  dwarn:0   dfail:0   fail:0   skip:13 
fi-bsw-n3050 total:218  pass:174  dwarn:0   dfail:0   fail:2   skip:42 
fi-byt-n2820 total:218  pass:175  dwarn:0   dfail:0   fail:2   skip:41 
fi-hsw-i7-4770k  total:219  pass:198  dwarn:0   dfail:0   fail:0   skip:21 
fi-hsw-i7-4770r  total:219  pass:193  dwarn:0   dfail:0   fail:0   skip:26 
fi-kbl-y total:219  pass:191  dwarn:1   dfail:0   fail:2   skip:25 
fi-skl-i7-6700k  total:219  pass:191  dwarn:0   dfail:0   fail:0   skip:28 
ro-bdw-i5-5250u  total:219  pass:181  dwarn:0   dfail:0   fail:0   skip:38 
ro-bdw-i7-5557U  total:219  pass:206  dwarn:0   dfail:0   fail:0   skip:13 
ro-bdw-i7-5600u  total:219  pass:187  dwarn:0   dfail:0   fail:0   skip:32 
ro-byt-n2820 total:218  pass:175  dwarn:0   dfail:0   fail:2   skip:41 
ro-hsw-i3-4010u  total:218  pass:193  dwarn:0   dfail:0   fail:0   skip:25 
ro-hsw-i7-4770r  total:219  pass:194  dwarn:0   dfail:0   fail:0   skip:25 
ro-ilk-i7-620lm  total:219  pass:151  dwarn:0   dfail:0   fail:1   skip:67 
ro-ilk1-i5-650   total:214  pass:151  dwarn:0   dfail:0   fail:2   skip:61 
ro-ivb-i7-3770   total:219  pass:183  dwarn:0   dfail:0   fail:0   skip:36 
ro-ivb2-i7-3770  total:219  pass:187  dwarn:0   dfail:0   fail:0   skip:32 
ro-skl-i7-6700hq total:214  pass:189  dwarn:0   dfail:0   fail:0   skip:25 
ro-snb-i7-2620M  total:219  pass:177  dwarn:0   dfail:0   fail:1   skip:41 
fi-snb-i7-2600 failed to connect after reboot
ro-bsw-n3050 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_918/

0d84413 drm-intel-nightly: 2016y-05m-17d-10h-26m-35s UTC integration manifest
cfa6373 drm/i915: optimise i915_gem_object_map() for small objects
1864abb drm/i915: refactor i915_gem_object_pin_map()

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

Re: [Intel-gfx] [PATCH i-g-t] autotools/: Keep gem_concurrent_blit in tests/ and put gem_conccurent_all in EXTRAS.

[Daniel Vetter]

On Tue, May 17, 2016 at 03:12:46PM +0300, Marius Vlad wrote:
> An attempt to have piglit not taking too much time when listing tests,
> but also keep tests/gem_concurrent_blit into list of tests.
> 
> This was added in a633ad03c6 (tests: Separate tests with lots of subtests) and
> tried to be fixed c785a89ee (autotools/: Allow building
> tests/gem_concurrent_{all, blit}) but without addressing the
> comments of the reviewer. While at it, remove tests-lists-full.txt as it not
> needed anymore.
> 
> https://lists.freedesktop.org/archives/intel-gfx/2016-April/092795.html
> 
> Signed-off-by: Marius Vlad 

Ack on both I think. Maybe ping Chris about this too, but I think he
should be happy with gem_concurrent_blit back in the igt game.
-Daniel

> ---
>  tests/Makefile.am  | 15 +--
>  tests/Makefile.sources | 17 ++---
>  2 files changed, 7 insertions(+), 25 deletions(-)
> 
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index c2c2025..359d911 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -14,11 +14,6 @@ test-list.txt: Makefile.sources
>   @echo ${single_kernel_tests} ${multi_kernel_tests} >> $@
>   @echo END TESTLIST >> $@
>  
> -test-list-full.txt: Makefile.sources
> - @echo TESTLIST > $@
> - @echo ${single_kernel_tests} ${multi_kernel_tests} 
> ${extra_multi_kernel_tests} >> $@
> - @echo END TESTLIST >> $@
> -
>  
>  noinst_PROGRAMS = \
>   $(HANG) \
> @@ -28,9 +23,9 @@ noinst_PROGRAMS = \
>  pkglibexec_PROGRAMS = \
>   gem_alive \
>   gem_stress \
> + gem_concurrent_all \
>   $(TESTS_progs) \
>   $(TESTS_progs_M) \
> - $(TESTS_progs_XM) \
>   $(NULL)
>  
>  dist_pkglibexec_SCRIPTS = \
> @@ -45,14 +40,14 @@ dist_pkgdata_DATA = \
>  
>  all-local: .gitignore
>  .gitignore: Makefile.sources
> - @echo "$(pkglibexec_PROGRAMS) $(HANG) test-list.txt test-list-full.txt 
> .gitignore" | sed 's/\s\+/\n/g' | sort > $@
> + @echo "$(pkglibexec_PROGRAMS) $(HANG) test-list.txt .gitignore" | sed 
> 's/\s\+/\n/g' | sort > $@
>  
> -pkgdata_DATA = test-list.txt test-list-full.txt
> +pkgdata_DATA = test-list.txt
>  
> -EXTRA_PROGRAMS = $(HANG)
> +EXTRA_PROGRAMS = $(HANG) gem_concurrent_all
>  EXTRA_DIST = $(common_files)
>  
> -CLEANFILES = $(EXTRA_PROGRAMS) test-list.txt test-list-full.txt .gitignore
> +CLEANFILES = $(EXTRA_PROGRAMS) test-list.txt .gitignore
>  
>  AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) $(DEBUG_CFLAGS)\
>   -I$(srcdir)/.. \
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 7b5f316..22dbaca 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -22,6 +22,7 @@ TESTS_progs_M = \
>   gem_close_race \
>   gem_create \
>   gem_cs_tlb \
> + gem_concurrent_blit \
>   gem_ctx_bad_exec \
>   gem_ctx_exec \
>   gem_ctx_param \
> @@ -118,11 +119,6 @@ TESTS_progs_M = \
>   template \
>   $(NULL)
>  
> -TESTS_progs_XM = \
> -gem_concurrent_blit \
> -gem_concurrent_all \
> -$(NULL)
> -
>  TESTS_progs = \
>   core_auth \
>   core_getclient \
> @@ -226,14 +222,6 @@ multi_kernel_tests = \
>   $(NULL)
>  
>  
> -# This target contains testcases with lots of subtests.
> -# It was split from multi_kernel_tests because of the overhead of listing all
> -# the subtests in piglit
> -extra_multi_kernel_tests = \
> - $(TESTS_progs_XM) \
> - $(NULL)
> -
> -
>  # This target is for simple testcase which don't expose any subtest.
>  #
>  # Your testcase should probably use igt_simple_main, but none of the other 
> magic
> @@ -251,8 +239,7 @@ kernel_tests = \
>  kernel_tests_full = \
>  $(single_kernel_tests) \
>  $(multi_kernel_tests) \
> - $(extra_multi_kernel_tests) \
> - $(NULL)
> +$(NULL)
>  
>  # Test that exercise specific asserts in the test framework library and are
>  # hence expected to fail.
> -- 
> 2.8.0.rc3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub

[Takashi Iwai]

On Tue, 17 May 2016 14:56:16 +0200,
Daniel Vetter wrote:
> 
> On Tue, May 17, 2016 at 02:47:44PM +0200, Takashi Iwai wrote:
> > On Tue, 17 May 2016 14:34:21 +0200,
> > Daniel Vetter wrote:
> > > 
> > > On Tue, May 17, 2016 at 03:11:02PM +0300, Imre Deak wrote:
> > > > On ti, 2016-05-17 at 13:10 +0200, Daniel Vetter wrote:
> > > > > On Tue, May 17, 2016 at 01:22:52PM +0300, Imre Deak wrote:
> > > > > > On ti, 2016-05-17 at 11:59 +0200, Takashi Iwai wrote:
> > > > > > > On Tue, 17 May 2016 11:42:17 +0200,
> > > > > > > Daniel Vetter wrote:
> > > > > > > > 
> > > > > > > > On Tue, May 17, 2016 at 09:37:12AM +0200, Takashi Iwai wrote:
> > > > > > > > > On Tue, 17 May 2016 09:20:48 +0200,
> > > > > > > > > Daniel Vetter wrote:
> > > > > > > > > > 
> > > > > > > > > > On Thu, May 12, 2016 at 09:06:53PM +0300, Imre Deak wrote:
> > > > > > > > > > > User may pass nomodeset or i915.modeset=0 option to
> > > > > > > > > > > disable i915 KMS
> > > > > > > > > > > explicitly.  Although this itself works fine, it breaks
> > > > > > > > > > > the weak
> > > > > > > > > > > dependency the HD-audio driver requires, and it's the
> > > > > > > > > > > reason the
> > > > > > > > > > > delayed component binding isn't implemented in HD-
> > > > > > > > > > > audio.  Since i915
> > > > > > > > > > > doesn't notify its disablement, HD-audio would be blocked
> > > > > > > > > > > unnecessarily endlessly, waiting for the bind with i915.
> > > > > > > > > > > 
> > > > > > > > > > > This patch introduces a stub audio component binding when
> > > > > > > > > > > i915 driver
> > > > > > > > > > > is loaded with KMS off like the boot options above.  Then
> > > > > > > > > > > i915 driver
> > > > > > > > > > > still registers the slave component but with the new
> > > > > > > > > > > "disabled" ops
> > > > > > > > > > > flag, so that the master component (HD-audio) can know
> > > > > > > > > > > clearly the
> > > > > > > > > > > slave state.
> > > > > > > > > > > 
> > > > > > > > > > > v2:
> > > > > > > > > > > - Fail the probe in case component registration fails,
> > > > > > > > > > > instead of
> > > > > > > > > > >   suppressing the error. (Ville)
> > > > > > > > > > > - Register the component only for the real PCI device
> > > > > > > > > > > function.
> > > > > > > > > > > 
> > > > > > > > > > > CC: Ville Syrjälä 
> > > > > > > > > > > Signed-off-by: Imre Deak 
> > > > > > > > > > > Signed-off-by: Takashi Iwai 
> > > > > > > > > > 
> > > > > > > > > > We don't support not running with modesetting. Why do we
> > > > > > > > > > suddenly care?
> > > > > > > > > 
> > > > > > > > > This is needed for the patch 2 and 3.  Right now we have no
> > > > > > > > > blocking
> > > > > > > > > or deferred component binding, so far, in HD-audio
> > > > > > > > > side.  This caused
> > > > > > > > > problems when async module probe was done.
> > > > > > > > > 
> > > > > > > > > So, the patch 3 implements the blocking behavior of HD-audio
> > > > > > > > > side.  It
> > > > > > > > > would lead to another regression when i915 doesn't notify its
> > > > > > > > > disabled
> > > > > > > > > state by this patch.  Otherwise the HD-audio driver will be
> > > > > > > > > blocked
> > > > > > > > > endlessly of unnecessarily long.
> > > > > > > > > 
> > > > > > > > > > Same for users creating a .config that fails to boot or
> > > > > > > > > > work ...
> > > > > > > > > 
> > > > > > > > > The config isn't cared much, but the problem is about the
> > > > > > > > > runtime boot
> > > > > > > > > option.
> > > > > > > > > 
> > > > > > > > > > If HDA needs to coporate with gfx to get things done, then
> > > > > > > > > > imo we should
> > > > > > > > > > just require that i915.ko is there.
> > > > > > > > > 
> > > > > > > > > Other way round: we do already require i915 in HD-audio
> > > > > > > > > side.  But in
> > > > > > > > > this case, we do *not* want to require i915 when it's
> > > > > > > > > disabled in
> > > > > > > > > runtime. 
> > > > > > > > 
> > > > > > > > That's what I mean: If you boot with i915.nomodeset you're
> > > > > > > > explicitly fine
> > > > > > > > with a somewhat non-useable system - that option is for
> > > > > > > > debugging only
> > > > > > > > really. If that means audio also doesn't work, then I think
> > > > > > > > that's ok.
> > > > > > > 
> > > > > > > It's not only "it doesn't work".  The module load gets stuck.  So
> > > > > > > we
> > > > > > > need some notification for the blocked component binding.
> > > > > > > 
> > > > > > > > Adding complexity for this case (which means more error paths
> > > > > > > > we don't
> > > > > > > > ever test and hence _will_ break) seems over the top.
> > > > > > > > 
> > > > > > > > I'm quite opposed to adding error handling for every condition
> > > > > > > > in general
> > > > > > > > because the combinatorial testing madness just can't be
> > > > > > > > handled. The one
> > > > > > > > exception in the i915.ko 

[Intel-gfx] [PATCH] drm/i915: Update kerneldoc for intel_dpll_mgr.c

[Ander Conselvan de Oliveira]

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 68 ---
 1 file changed, 63 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index c283ba4..36566f8 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -23,6 +23,13 @@
 
 #include "intel_drv.h"
 
+/** intel_get_shared_dpll_by_id - get a DPLL given its id
+ * @dev_priv: i915 device instance
+ * @id: pll id
+ *
+ * Returns:
+ * A pointer the DPLL with @id
+ */
 struct intel_shared_dpll *
 intel_get_shared_dpll_by_id(struct drm_i915_private *dev_priv,
enum intel_dpll_id id)
@@ -30,6 +37,13 @@ intel_get_shared_dpll_by_id(struct drm_i915_private 
*dev_priv,
return _priv->shared_dplls[id];
 }
 
+/** intel_get_shared_dpll_id - get the id of a DPLL
+ * @dev_priv: i915 device instance
+ * @pll: the DPLL
+ *
+ * Returns:
+ * The id of @pll
+ */
 enum intel_dpll_id
 intel_get_shared_dpll_id(struct drm_i915_private *dev_priv,
 struct intel_shared_dpll *pll)
@@ -41,6 +55,15 @@ intel_get_shared_dpll_id(struct drm_i915_private *dev_priv,
return (enum intel_dpll_id) (pll - dev_priv->shared_dplls);
 }
 
+/** intel_shared_dpll_config_get - get a reference to a DPLL for a crtc
+ * @config: a intel_shared_dpll_config struct
+ * @pll: pll to get a reference to
+ * @crtc: crtc that references the pll
+ *
+ * This gets a reference to @pll for @crtc. Internally is sets the pll's
+ * crtc_mask. @config should be the pll configuration in an atomic state.
+ * A crtc can reference a pll only once.
+ */
 void
 intel_shared_dpll_config_get(struct intel_shared_dpll_config *config,
 struct intel_shared_dpll *pll,
@@ -52,6 +75,14 @@ intel_shared_dpll_config_get(struct intel_shared_dpll_config 
*config,
config[id].crtc_mask |= 1 << crtc->pipe;
 }
 
+/** intel_shared_dpll_config_put - release a reference to a DPLL for a crtc
+ * @config: a intel_shared_dpll_config struct
+ * @pll: pll that is referenced by @crtc
+ * @crtc: crtc that references the pll
+ *
+ * This releases the reference to @pll for @crtc. Internally is sets the pll's
+ * crtc_mask. @config should be the pll configuration in an atomic state.
+ */
 void
 intel_shared_dpll_config_put(struct intel_shared_dpll_config *config,
 struct intel_shared_dpll *pll,
@@ -80,6 +111,9 @@ void assert_shared_dpll(struct drm_i915_private *dev_priv,
pll->name, onoff(state), onoff(cur_state));
 }
 
+/** intel_prepare_shared_dpll - call a dpll's mode_set hook
+ * @crtc: crtc which has a shared dpll
+ */
 void intel_prepare_shared_dpll(struct intel_crtc *crtc)
 {
struct drm_device *dev = crtc->base.dev;
@@ -102,12 +136,10 @@ void intel_prepare_shared_dpll(struct intel_crtc *crtc)
 }
 
 /**
- * intel_enable_shared_dpll - enable PCH PLL
- * @dev_priv: i915 private structure
- * @pipe: pipe PLL to enable
+ * intel_enable_shared_dpll - enable a crtc's shared DPLL
+ * @crtc: crtc which has a shared DPLL
  *
- * The PCH PLL needs to be enabled before the PCH transcoder, since it
- * drives the transcoder clock.
+ * Enable the shared DPLL used by @crtc.
  */
 void intel_enable_shared_dpll(struct intel_crtc *crtc)
 {
@@ -148,6 +180,12 @@ out:
mutex_unlock(_priv->dpll_lock);
 }
 
+/**
+ * intel_disable_shared_dpll - disable a crtc's shared DPLL
+ * @crtc: crtc which has a shared DPLL
+ *
+ * Disable the shared DPLL used by @crtc.
+ */
 void intel_disable_shared_dpll(struct intel_crtc *crtc)
 {
struct drm_device *dev = crtc->base.dev;
@@ -250,6 +288,11 @@ intel_reference_shared_dpll(struct intel_shared_dpll *pll,
intel_shared_dpll_config_get(shared_dpll, pll, crtc);
 }
 
+/** intel_shared_dpll_commit - make atomic state DPLL configuration effective
+ * @state: atomic state
+ *
+ * Makes the DPLL configuration in @state effective.
+ */
 void intel_shared_dpll_commit(struct drm_atomic_state *state)
 {
struct drm_i915_private *dev_priv = to_i915(state->dev);
@@ -1725,6 +1768,11 @@ static const struct intel_dpll_mgr bxt_pll_mgr = {
.get_dpll = bxt_get_dpll,
 };
 
+/** intel_shared_dpll_init - Initialize shared DPLLs
+ * @dev: drm device
+ *
+ * Initialize shared DPLLs for @dev.
+ */
 void intel_shared_dpll_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -1768,6 +1816,16 @@ void intel_shared_dpll_init(struct drm_device *dev)
intel_ddi_pll_init(dev);
 }
 
+/** intel_get_shared_dpll - get a shared DPLL for crtc and encoder combination
+ * @crtc: crtc
+ * @crtc_state: atomic state for @crtc
+ * @encoder: encoder
+ *
+ * Find an appropriate DPLL for the given crtc and encoder combination.
+ *
+ * Returns:
+ * A shared DPLL to be used by @crtc and @encoder with the given 

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915: refactor i915_gem_object_pin_map()

[Tvrtko Ursulin]

On 17/05/16 13:51, Dave Gordon wrote:

The recently-added i915_gem_object_pin_map() can be further optimised
for "small" objects. To facilitate this, and simplify the error paths
before adding the new code, this patch pulls out the "mapping" part of
the operation (involving local allocations which must be undone before
return) into its own subfunction.

The next patch will then insert the new optimisation into the middle of
the now-separated subfunction.

This reorganisation will probably not affect the generated code, as the
compiler will most likely inline it anyway, but it makes the logical
structure a bit clearer and easier to modify.

v2:
 Restructure loop-over-pages & error check [Chris Wilson]

v3:
 Add page count to debug messages [Chris Wilson]
 Convert WARN_ON() to GEM_BUG_ON()

v4:
 Drop the DEBUG messages [Tvrtko Ursulin]

Signed-off-by: Dave Gordon 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem.c | 54 +
  1 file changed, 33 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 24cab88..82a1bc4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2398,6 +2398,38 @@ static void i915_gem_object_free_mmap_offset(struct 
drm_i915_gem_object *obj)
return 0;
  }

+/* The 'mapping' part of i915_gem_object_pin_map() below */
+static void *i915_gem_object_map(const struct drm_i915_gem_object *obj)
+{
+   unsigned long n_pages = obj->base.size >> PAGE_SHIFT;
+   struct sg_table *sgt = obj->pages;
+   struct sg_page_iter sg_iter;
+   struct page **pages;
+   unsigned long i = 0;
+   void *addr;
+
+   /* A single page can always be kmapped */
+   if (n_pages == 1)
+   return kmap(sg_page(sgt->sgl));
+
+   pages = drm_malloc_gfp(n_pages, sizeof(*pages), GFP_TEMPORARY);
+   if (pages == NULL)
+   return NULL;
+
+   for_each_sg_page(sgt->sgl, _iter, sgt->nents, 0)
+   pages[i++] = sg_page_iter_page(_iter);
+
+   /* Check that we have the expected number of pages */
+   GEM_BUG_ON(i != n_pages);
+
+   addr = vmap(pages, n_pages, 0, PAGE_KERNEL);
+
+   drm_free_large(pages);
+
+   return addr;
+}
+
+/* get, pin, and map the pages of the object into kernel space */
  void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj)
  {
int ret;
@@ -2411,27 +2443,7 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object 
*obj)
i915_gem_object_pin_pages(obj);

if (obj->mapping == NULL) {
-   struct page **pages;
-
-   pages = NULL;
-   if (obj->base.size == PAGE_SIZE)
-   obj->mapping = kmap(sg_page(obj->pages->sgl));
-   else
-   pages = drm_malloc_gfp(obj->base.size >> PAGE_SHIFT,
-  sizeof(*pages),
-  GFP_TEMPORARY);
-   if (pages != NULL) {
-   struct sg_page_iter sg_iter;
-   int n;
-
-   n = 0;
-   for_each_sg_page(obj->pages->sgl, _iter,
-obj->pages->nents, 0)
-   pages[n++] = sg_page_iter_page(_iter);
-
-   obj->mapping = vmap(pages, n, 0, PAGE_KERNEL);
-   drm_free_large(pages);
-   }
+   obj->mapping = i915_gem_object_map(obj);
if (obj->mapping == NULL) {
i915_gem_object_unpin_pages(obj);
return ERR_PTR(-ENOMEM);



Reviewed-by: Tvrtko Ursulin 

Regards,

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

[Intel-gfx] [PATCH v2 15/21] drm/i915: Remove reset_counter from intel_crtc.

[Maarten Lankhorst]

With the removal of cs-based flips all mmio waits will
finish without requiring the reset counter, because the
waits will complete during gpu reset.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 9 -
 drivers/gpu/drm/i915/intel_drv.h | 3 ---
 2 files changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d96f6a86d6f6..db8c6d905007 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3179,14 +3179,6 @@ void intel_finish_reset(struct drm_i915_private 
*dev_priv)
 
 static bool intel_crtc_has_pending_flip(struct drm_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   unsigned reset_counter;
-
-   reset_counter = i915_reset_counter(_i915(dev)->gpu_error);
-   if (intel_crtc->reset_counter != reset_counter)
-   return false;
-
return !list_empty_careful(_intel_crtc(crtc)->flip_work);
 }
 
@@ -11179,7 +11171,6 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
 
intel_fbc_pre_update(intel_crtc);
 
-   intel_crtc->reset_counter = i915_reset_counter(_priv->gpu_error);
schedule_work(>mmio_work);
 
mutex_unlock(>struct_mutex);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c538d821a728..11dae90b7168 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -659,9 +659,6 @@ struct intel_crtc {
 
struct intel_crtc_state *config;
 
-   /* reset counter value when the last flip was submitted */
-   unsigned int reset_counter;
-
/* Access to these should be protected by dev_priv->irq_lock. */
bool cpu_fifo_underrun_disabled;
bool pch_fifo_underrun_disabled;
-- 
2.5.5

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

[Intel-gfx] [PATCH v2 10/21] drm/i915: Add the exclusive fence to plane_state.

[Maarten Lankhorst]

Set plane_state->base.fence to the dma_buf exclusive fence,
and add a wait to the mmio function. This will make it easier
to unify plane updates later on.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  1 +
 drivers/gpu/drm/i915/intel_display.c  | 54 +++
 2 files changed, 42 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 7de7721f65bc..2ab45f16fa65 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -102,6 +102,7 @@ intel_plane_destroy_state(struct drm_plane *plane,
  struct drm_plane_state *state)
 {
WARN_ON(state && to_intel_plane_state(state)->wait_req);
+   WARN_ON(state && state->fence);
drm_atomic_helper_plane_destroy_state(plane, state);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ece259de6ff2..b7888ad331bb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13358,6 +13358,15 @@ static int intel_atomic_prepare_commit(struct 
drm_device *dev,
struct intel_plane_state *intel_plane_state =
to_intel_plane_state(plane_state);
 
+   if (plane_state->fence) {
+   long lret = fence_wait(plane_state->fence, 
true);
+
+   if (lret < 0) {
+   ret = lret;
+   break;
+   }
+   }
+
if (!intel_plane_state->wait_req)
continue;
 
@@ -13683,6 +13692,33 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.atomic_destroy_state = intel_crtc_destroy_state,
 };
 
+static struct fence *intel_get_excl_fence(struct drm_i915_gem_object *obj)
+{
+   struct reservation_object *resv;
+
+
+   if (!obj->base.dma_buf)
+   return NULL;
+
+   resv = obj->base.dma_buf->resv;
+
+   /* For framebuffer backed by dmabuf, wait for fence */
+   while (1) {
+   struct fence *fence_excl, *ret = NULL;
+
+   rcu_read_lock();
+
+   fence_excl = rcu_dereference(resv->fence_excl);
+   if (fence_excl)
+   ret = fence_get_rcu(fence_excl);
+
+   rcu_read_unlock();
+
+   if (ret == fence_excl)
+   return ret;
+   }
+}
+
 /**
  * intel_prepare_plane_fb - Prepare fb for usage on plane
  * @plane: drm plane to prepare for
@@ -13735,19 +13771,6 @@ intel_prepare_plane_fb(struct drm_plane *plane,
}
}
 
-   /* For framebuffer backed by dmabuf, wait for fence */
-   if (obj && obj->base.dma_buf) {
-   long lret;
-
-   lret = 
reservation_object_wait_timeout_rcu(obj->base.dma_buf->resv,
-  false, true,
-  
MAX_SCHEDULE_TIMEOUT);
-   if (lret == -ERESTARTSYS)
-   return lret;
-
-   WARN(lret < 0, "waiting returns %li\n", lret);
-   }
-
if (!obj) {
ret = 0;
} else if (plane->type == DRM_PLANE_TYPE_CURSOR &&
@@ -13767,6 +13790,8 @@ intel_prepare_plane_fb(struct drm_plane *plane,
 
i915_gem_request_assign(_state->wait_req,
obj->last_write_req);
+
+   plane_state->base.fence = intel_get_excl_fence(obj);
}
 
i915_gem_track_fb(old_obj, obj, intel_plane->frontbuffer_bit);
@@ -13809,6 +13834,9 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
i915_gem_track_fb(old_obj, obj, intel_plane->frontbuffer_bit);
 
i915_gem_request_assign(_intel_state->wait_req, NULL);
+
+   fence_put(old_intel_state->base.fence);
+   old_intel_state->base.fence = NULL;
 }
 
 int
-- 
2.5.5

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

[Intel-gfx] [PATCH v2 05/21] drm/i915: Add support for detecting vblanks when hw frame counter is unavailable.

[Maarten Lankhorst]

This uses the newly created drm_accurate_vblank_count_and_time to accurately
get a vblank count when the hw counter is unavailable.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 10 ++
 drivers/gpu/drm/i915/intel_drv.h |  3 +++
 drivers/gpu/drm/i915/intel_sprite.c  |  8 ++--
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d6e90fa888cf..316913414f85 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13415,6 +13415,16 @@ static int intel_atomic_prepare_commit(struct 
drm_device *dev,
return ret;
 }
 
+u32 intel_crtc_get_vblank_counter(struct intel_crtc *crtc)
+{
+   struct drm_device *dev = crtc->base.dev;
+
+   if (!dev->max_vblank_count)
+   return drm_accurate_vblank_count(>base);
+
+   return dev->driver->get_vblank_counter(dev, crtc->pipe);
+}
+
 static void intel_atomic_wait_for_vblanks(struct drm_device *dev,
  struct drm_i915_private *dev_priv,
  unsigned crtc_mask)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e2d732af74bb..6a2f546be903 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1178,6 +1178,9 @@ intel_wait_for_vblank_if_active(struct drm_device *dev, 
int pipe)
if (crtc->active)
intel_wait_for_vblank(dev, pipe);
 }
+
+u32 intel_crtc_get_vblank_counter(struct intel_crtc *crtc);
+
 int ironlake_get_lanes_required(int target_clock, int link_bw, int bpp);
 void vlv_wait_port_ready(struct drm_i915_private *dev_priv,
 struct intel_digital_port *dport,
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 57eef129c597..728b924ce82f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -80,9 +80,7 @@ static int usecs_to_scanlines(const struct drm_display_mode 
*adjusted_mode,
  */
 void intel_pipe_update_start(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->base.dev;
const struct drm_display_mode *adjusted_mode = 
>config->base.adjusted_mode;
-   enum pipe pipe = crtc->pipe;
long timeout = msecs_to_jiffies_timeout(1);
int scanline, min, max, vblank_start;
wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(>base);
@@ -139,8 +137,7 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
 
crtc->debug.scanline_start = scanline;
crtc->debug.start_vbl_time = ktime_get();
-   crtc->debug.start_vbl_count =
-   dev->driver->get_vblank_counter(dev, pipe);
+   crtc->debug.start_vbl_count = intel_crtc_get_vblank_counter(crtc);
 
trace_i915_pipe_update_vblank_evaded(crtc);
 }
@@ -156,10 +153,9 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
  */
 void intel_pipe_update_end(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->base.dev;
enum pipe pipe = crtc->pipe;
int scanline_end = intel_get_crtc_scanline(crtc);
-   u32 end_vbl_count = dev->driver->get_vblank_counter(dev, pipe);
+   u32 end_vbl_count = intel_crtc_get_vblank_counter(crtc);
ktime_t end_vbl_time = ktime_get();
 
trace_i915_pipe_update_end(crtc, end_vbl_count, scanline_end);
-- 
2.5.5

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

[Intel-gfx] [PATCH v2 03/21] drm/i915: Remove intel_finish_page_flip_plane.

[Maarten Lankhorst]

This function is duplicated with intel_finish_page_flip,
and is only ever used from planes that could use the
other function anyway.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_irq.c  |  6 +++---
 drivers/gpu/drm/i915/intel_display.c | 18 --
 drivers/gpu/drm/i915/intel_drv.h |  1 -
 3 files changed, 7 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f0d941455bed..920a5e4abb70 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2164,7 +2164,7 @@ static void ilk_display_irq_handler(struct 
drm_i915_private *dev_priv,
/* plane/pipes map 1:1 on ilk+ */
if (de_iir & DE_PLANE_FLIP_DONE(pipe)) {
intel_prepare_page_flip(dev_priv, pipe);
-   intel_finish_page_flip_plane(dev_priv, pipe);
+   intel_finish_page_flip(dev_priv, pipe);
}
}
 
@@ -2211,7 +2211,7 @@ static void ivb_display_irq_handler(struct 
drm_i915_private *dev_priv,
/* plane/pipes map 1:1 on ilk+ */
if (de_iir & DE_PLANE_FLIP_DONE_IVB(pipe)) {
intel_prepare_page_flip(dev_priv, pipe);
-   intel_finish_page_flip_plane(dev_priv, pipe);
+   intel_finish_page_flip(dev_priv, pipe);
}
}
 
@@ -2419,7 +2419,7 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
 
if (flip_done) {
intel_prepare_page_flip(dev_priv, pipe);
-   intel_finish_page_flip_plane(dev_priv, pipe);
+   intel_finish_page_flip(dev_priv, pipe);
}
 
if (iir & GEN8_PIPE_CDCLK_CRC_DONE)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3bcab21e67d3..535f20ab2870 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3110,14 +3110,11 @@ intel_pipe_set_base_atomic(struct drm_crtc *crtc, 
struct drm_framebuffer *fb,
 
 static void intel_complete_page_flips(struct drm_i915_private *dev_priv)
 {
-   struct drm_crtc *crtc;
-
-   for_each_crtc(dev_priv->dev, crtc) {
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   enum plane plane = intel_crtc->plane;
+   struct intel_crtc *crtc;
 
-   intel_prepare_page_flip(dev_priv, plane);
-   intel_finish_page_flip_plane(dev_priv, plane);
+   for_each_intel_crtc(dev_priv->dev, crtc) {
+   intel_prepare_page_flip(dev_priv, crtc->plane);
+   intel_finish_page_flip(dev_priv, crtc->pipe);
}
 }
 
@@ -10905,13 +10902,6 @@ void intel_finish_page_flip(struct drm_i915_private 
*dev_priv, int pipe)
do_intel_finish_page_flip(dev_priv, crtc);
 }
 
-void intel_finish_page_flip_plane(struct drm_i915_private *dev_priv, int plane)
-{
-   struct drm_crtc *crtc = dev_priv->plane_to_crtc_mapping[plane];
-
-   do_intel_finish_page_flip(dev_priv, crtc);
-}
-
 /* Is 'a' after or equal to 'b'? */
 static bool g4x_flip_count_after_eq(u32 a, u32 b)
 {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f19e755bb16f..d3081aafac8d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1201,7 +1201,6 @@ __intel_framebuffer_create(struct drm_device *dev,
   struct drm_i915_gem_object *obj);
 void intel_prepare_page_flip(struct drm_i915_private *dev_priv, int plane);
 void intel_finish_page_flip(struct drm_i915_private *dev_priv, int pipe);
-void intel_finish_page_flip_plane(struct drm_i915_private *dev_priv, int 
plane);
 void intel_check_page_flip(struct drm_i915_private *dev_priv, int pipe);
 int intel_prepare_plane_fb(struct drm_plane *plane,
   const struct drm_plane_state *new_state);
-- 
2.5.5

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

[Intel-gfx] [PATCH v2 16/21] drm/i915: Pass atomic states to fbc update functions.

[Maarten Lankhorst]

This is required to let fbc updates run async. It has a lot of
checks whether certain locks are taken, which can be removed when
the relevant states are passed in as pointers.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c |  8 +---
 drivers/gpu/drm/i915/intel_drv.h |  8 ++--
 drivers/gpu/drm/i915/intel_fbc.c | 39 +---
 3 files changed, 29 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index db8c6d905007..15ab4a6f1556 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4589,7 +4589,7 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state)
struct intel_plane_state *old_primary_state =
to_intel_plane_state(old_pri_state);
 
-   intel_fbc_pre_update(crtc);
+   intel_fbc_pre_update(crtc, pipe_config, primary_state);
 
if (old_primary_state->visible &&
(modeset || !primary_state->visible))
@@ -11169,7 +11169,9 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
if (obj->base.dma_buf)
work->old_plane_state[0]->base.fence = 
intel_get_excl_fence(obj);
 
-   intel_fbc_pre_update(intel_crtc);
+   intel_fbc_pre_update(intel_crtc,
+to_intel_crtc_state(new_crtc_state),
+to_intel_plane_state(new_state));
 
schedule_work(>mmio_work);
 
@@ -13128,7 +13130,7 @@ static int intel_atomic_commit(struct drm_device *dev,
 
if (crtc->state->active &&
drm_atomic_get_existing_plane_state(state, crtc->primary))
-   intel_fbc_enable(intel_crtc);
+   intel_fbc_enable(intel_crtc, pipe_config, 
to_intel_plane_state(crtc->primary->state));
 
if (crtc->state->active &&
(crtc->state->planes_changed || update_pipe))
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 11dae90b7168..b2900d659dff 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1418,11 +1418,15 @@ static inline void intel_fbdev_restore_mode(struct 
drm_device *dev)
 void intel_fbc_choose_crtc(struct drm_i915_private *dev_priv,
   struct drm_atomic_state *state);
 bool intel_fbc_is_active(struct drm_i915_private *dev_priv);
-void intel_fbc_pre_update(struct intel_crtc *crtc);
+void intel_fbc_pre_update(struct intel_crtc *crtc,
+ struct intel_crtc_state *crtc_state,
+ struct intel_plane_state *plane_state);
 void intel_fbc_post_update(struct intel_crtc *crtc);
 void intel_fbc_init(struct drm_i915_private *dev_priv);
 void intel_fbc_init_pipe_state(struct drm_i915_private *dev_priv);
-void intel_fbc_enable(struct intel_crtc *crtc);
+void intel_fbc_enable(struct intel_crtc *crtc,
+ struct intel_crtc_state *crtc_state,
+ struct intel_plane_state *plane_state);
 void intel_fbc_disable(struct intel_crtc *crtc);
 void intel_fbc_global_disable(struct drm_i915_private *dev_priv);
 void intel_fbc_invalidate(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 0dea5fbcd8aa..d2b0269b2fe4 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -480,10 +480,10 @@ static void intel_fbc_deactivate(struct drm_i915_private 
*dev_priv)
intel_fbc_hw_deactivate(dev_priv);
 }
 
-static bool multiple_pipes_ok(struct intel_crtc *crtc)
+static bool multiple_pipes_ok(struct intel_crtc *crtc,
+ struct intel_plane_state *plane_state)
 {
-   struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
-   struct drm_plane *primary = crtc->base.primary;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_fbc *fbc = _priv->fbc;
enum pipe pipe = crtc->pipe;
 
@@ -491,9 +491,7 @@ static bool multiple_pipes_ok(struct intel_crtc *crtc)
if (!no_fbc_on_multiple_pipes(dev_priv))
return true;
 
-   WARN_ON(!drm_modeset_is_locked(>mutex));
-
-   if (to_intel_plane_state(primary->state)->visible)
+   if (plane_state->visible)
fbc->visible_pipes_mask |= (1 << pipe);
else
fbc->visible_pipes_mask &= ~(1 << pipe);
@@ -708,21 +706,16 @@ static bool intel_fbc_hw_tracking_covers_screen(struct 
intel_crtc *crtc)
return effective_w <= max_w && effective_h <= max_h;
 }
 
-static void intel_fbc_update_state_cache(struct intel_crtc *crtc)
+static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
+struct intel_crtc_state *crtc_state,
+  

[Intel-gfx] [PATCH v2 09/21] drm/i915: Convert flip_work to a list.

[Maarten Lankhorst]

This will be required to allow more than 1 update in the future.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  90 +++--
 drivers/gpu/drm/i915/i915_drv.h  |   2 +-
 drivers/gpu/drm/i915/intel_display.c | 146 +--
 drivers/gpu/drm/i915/intel_drv.h |   4 +-
 4 files changed, 142 insertions(+), 100 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0a4bedb96d65..220ec15e9864 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -592,6 +592,53 @@ static int i915_gem_gtt_info(struct seq_file *m, void 
*data)
return 0;
 }
 
+static void i915_dump_pageflip(struct seq_file *m,
+  struct drm_i915_private *dev_priv,
+  struct intel_crtc *crtc,
+  struct intel_flip_work *work)
+{
+   const char pipe = pipe_name(crtc->pipe);
+   const char plane = plane_name(crtc->plane);
+   u32 pending;
+   u32 addr;
+
+   pending = atomic_read(>pending);
+   if (pending) {
+   seq_printf(m, "Flip ioctl preparing on pipe %c (plane %c)\n",
+  pipe, plane);
+   } else {
+   seq_printf(m, "Flip pending (waiting for vsync) on pipe %c 
(plane %c)\n",
+  pipe, plane);
+   }
+   if (work->flip_queued_req) {
+   struct intel_engine_cs *engine = 
i915_gem_request_get_engine(work->flip_queued_req);
+
+   seq_printf(m, "Flip queued on %s at seqno %x, next seqno %x 
[current breadcrumb %x], completed? %d\n",
+  engine->name,
+  i915_gem_request_get_seqno(work->flip_queued_req),
+  dev_priv->next_seqno,
+  engine->get_seqno(engine),
+  i915_gem_request_completed(work->flip_queued_req, 
true));
+   } else
+   seq_printf(m, "Flip not associated with any ring\n");
+   seq_printf(m, "Flip queued on frame %d, (was ready on frame %d), now 
%d\n",
+  work->flip_queued_vblank,
+  work->flip_ready_vblank,
+  intel_crtc_get_vblank_counter(crtc));
+   seq_printf(m, "%d prepares\n", atomic_read(>pending));
+
+   if (INTEL_INFO(dev_priv)->gen >= 4)
+   addr = I915_HI_DISPBASE(I915_READ(DSPSURF(crtc->plane)));
+   else
+   addr = I915_READ(DSPADDR(crtc->plane));
+   seq_printf(m, "Current scanout address 0x%08x\n", addr);
+
+   if (work->pending_flip_obj) {
+   seq_printf(m, "New framebuffer address 0x%08lx\n", 
(long)work->gtt_offset);
+   seq_printf(m, "MMIO update completed? %d\n",  addr == 
work->gtt_offset);
+   }
+}
+
 static int i915_gem_pageflip_info(struct seq_file *m, void *data)
 {
struct drm_info_node *node = m->private;
@@ -610,48 +657,13 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
void *data)
struct intel_flip_work *work;
 
spin_lock_irq(>event_lock);
-   work = crtc->flip_work;
-   if (work == NULL) {
+   if (list_empty(>flip_work)) {
seq_printf(m, "No flip due on pipe %c (plane %c)\n",
   pipe, plane);
} else {
-   u32 pending;
-   u32 addr;
-
-   pending = atomic_read(>pending);
-   if (pending) {
-   seq_printf(m, "Flip ioctl preparing on pipe %c 
(plane %c)\n",
-  pipe, plane);
-   } else {
-   seq_printf(m, "Flip pending (waiting for vsync) 
on pipe %c (plane %c)\n",
-  pipe, plane);
-   }
-   if (work->flip_queued_req) {
-   struct intel_engine_cs *engine = 
i915_gem_request_get_engine(work->flip_queued_req);
-
-   seq_printf(m, "Flip queued on %s at seqno %x, 
next seqno %x [current breadcrumb %x], completed? %d\n",
-  engine->name,
-  
i915_gem_request_get_seqno(work->flip_queued_req),
-  dev_priv->next_seqno,
-  engine->get_seqno(engine),
-  
i915_gem_request_completed(work->flip_queued_req, true));
-   } else
-   seq_printf(m, "Flip not associated with any 
ring\n");
-   seq_printf(m, "Flip queued on frame %d, (was ready on 
frame %d), now %d\n",
-  

[Intel-gfx] [PATCH v2 12/21] drm/i915: Remove cs based page flip support.

[Maarten Lankhorst]

With mmio flips now available on all platforms it's time to remove
support for cs flips.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  19 +-
 drivers/gpu/drm/i915/i915_irq.c  | 120 ++-
 drivers/gpu/drm/i915/intel_display.c | 392 +--
 drivers/gpu/drm/i915/intel_drv.h |   9 +-
 4 files changed, 33 insertions(+), 507 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6bce4fd8aaf4..4c6b48dbd6e2 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -599,7 +599,6 @@ static void i915_dump_pageflip(struct seq_file *m,
 {
const char pipe = pipe_name(crtc->pipe);
u32 pending;
-   u32 addr;
int i;
 
pending = atomic_read(>pending);
@@ -611,7 +610,6 @@ static void i915_dump_pageflip(struct seq_file *m,
   pipe, plane_name(crtc->plane));
}
 
-
for (i = 0; i < work->num_planes; i++) {
struct intel_plane_state *old_plane_state = 
work->old_plane_state[i];
struct drm_plane *plane = old_plane_state->base.plane;
@@ -635,22 +633,9 @@ static void i915_dump_pageflip(struct seq_file *m,
   i915_gem_request_completed(req, true));
}
 
-   seq_printf(m, "Flip queued on frame %d, (was ready on frame %d), now 
%d\n",
-  work->flip_queued_vblank,
-  work->flip_ready_vblank,
+   seq_printf(m, "Flip queued on frame %d, now %d\n",
+  pending ? work->flip_queued_vblank : -1,
   intel_crtc_get_vblank_counter(crtc));
-   seq_printf(m, "%d prepares\n", atomic_read(>pending));
-
-   if (INTEL_INFO(dev_priv)->gen >= 4)
-   addr = I915_HI_DISPBASE(I915_READ(DSPSURF(crtc->plane)));
-   else
-   addr = I915_READ(DSPADDR(crtc->plane));
-   seq_printf(m, "Current scanout address 0x%08x\n", addr);
-
-   if (work->flip_queued_req) {
-   seq_printf(m, "New framebuffer address 0x%08lx\n", 
(long)work->gtt_offset);
-   seq_printf(m, "MMIO update completed? %d\n",  addr == 
work->gtt_offset);
-   }
 }
 
 static int i915_gem_pageflip_info(struct seq_file *m, void *data)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3242a37fb304..5513c4cb02e0 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -136,6 +136,12 @@ static const u32 hpd_bxt[HPD_NUM_PINS] = {
POSTING_READ(type##IIR); \
 } while (0)
 
+static void
+intel_finish_page_flip_cs(struct drm_i915_private *dev_priv, unsigned pipe)
+{
+   DRM_DEBUG_KMS("Finished page flip\n");
+}
+
 /*
  * We should clear IMR at preinstall/uninstall, and just check at postinstall.
  */
@@ -1631,16 +1637,11 @@ static void gen6_rps_irq_handler(struct 
drm_i915_private *dev_priv, u32 pm_iir)
}
 }
 
-static bool intel_pipe_handle_vblank(struct drm_i915_private *dev_priv,
+static void intel_pipe_handle_vblank(struct drm_i915_private *dev_priv,
 enum pipe pipe)
 {
-   bool ret;
-
-   ret = drm_handle_vblank(dev_priv->dev, pipe);
-   if (ret)
+   if (drm_handle_vblank(dev_priv->dev, pipe))
intel_finish_page_flip_mmio(dev_priv, pipe);
-
-   return ret;
 }
 
 static void valleyview_pipestat_irq_ack(struct drm_i915_private *dev_priv,
@@ -1707,9 +1708,8 @@ static void valleyview_pipestat_irq_handler(struct 
drm_i915_private *dev_priv,
enum pipe pipe;
 
for_each_pipe(dev_priv, pipe) {
-   if (pipe_stats[pipe] & PIPE_START_VBLANK_INTERRUPT_STATUS &&
-   intel_pipe_handle_vblank(dev_priv, pipe))
-   intel_check_page_flip(dev_priv, pipe);
+   if (pipe_stats[pipe] & PIPE_START_VBLANK_INTERRUPT_STATUS)
+   intel_pipe_handle_vblank(dev_priv, pipe);
 
if (pipe_stats[pipe] & PLANE_FLIP_DONE_INT_STATUS_VLV)
intel_finish_page_flip_cs(dev_priv, pipe);
@@ -2155,9 +2155,8 @@ static void ilk_display_irq_handler(struct 
drm_i915_private *dev_priv,
DRM_ERROR("Poison interrupt\n");
 
for_each_pipe(dev_priv, pipe) {
-   if (de_iir & DE_PIPE_VBLANK(pipe) &&
-   intel_pipe_handle_vblank(dev_priv, pipe))
-   intel_check_page_flip(dev_priv, pipe);
+   if (de_iir & DE_PIPE_VBLANK(pipe))
+   intel_pipe_handle_vblank(dev_priv, pipe);
 
if (de_iir & DE_PIPE_FIFO_UNDERRUN(pipe))
intel_cpu_fifo_underrun_irq_handler(dev_priv, pipe);
@@ -2206,9 +2205,8 @@ static void ivb_display_irq_handler(struct 
drm_i915_private *dev_priv,
intel_opregion_asle_intr(dev_priv);
 
for_each_pipe(dev_priv, pipe) {
-   if 

[Intel-gfx] [PATCH v2 08/21] drm/i915: Allow mmio updates on all platforms, v2.

[Maarten Lankhorst]

With intel_pipe_update begin/end we ensure that the mmio updates
don't run during vblank interrupt, using the hw counter we can
be sure that when current vblank count != vblank count at the time
of pipe_update_end the mmio update is complete.

This allows us to use mmio updates on all platforms, using the
update_plane call.

With Chris Wilson's patch to skip waiting for vblanks for
legacy_cursor_update this potentially leaves a small race
condition, in which update_plane can be called with a freed
crtc_state. Because of this commit acf4e84d61673
("drm/i915: Avoid stalling on pending flips for legacy cursor updates")
is temporarily reverted.

Changes since v1:
- Split out the flip_work rename.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 99 +++-
 drivers/gpu/drm/i915/intel_drv.h |  1 -
 2 files changed, 7 insertions(+), 93 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 6526bb5a7afb..6d2af42a86c1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11269,9 +11269,6 @@ static bool use_mmio_flip(struct intel_engine_cs 
*engine,
if (engine == NULL)
return true;
 
-   if (INTEL_GEN(engine->i915) < 5)
-   return false;
-
if (i915.use_mmio_flip < 0)
return false;
else if (i915.use_mmio_flip > 0)
@@ -11286,92 +11283,15 @@ static bool use_mmio_flip(struct intel_engine_cs 
*engine,
return engine != 
i915_gem_request_get_engine(obj->last_write_req);
 }
 
-static void skl_do_mmio_flip(struct intel_crtc *intel_crtc,
-unsigned int rotation,
-struct intel_flip_work *work)
-{
-   struct drm_device *dev = intel_crtc->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   struct drm_framebuffer *fb = intel_crtc->base.primary->fb;
-   const enum pipe pipe = intel_crtc->pipe;
-   u32 ctl, stride, tile_height;
-
-   ctl = I915_READ(PLANE_CTL(pipe, 0));
-   ctl &= ~PLANE_CTL_TILED_MASK;
-   switch (fb->modifier[0]) {
-   case DRM_FORMAT_MOD_NONE:
-   break;
-   case I915_FORMAT_MOD_X_TILED:
-   ctl |= PLANE_CTL_TILED_X;
-   break;
-   case I915_FORMAT_MOD_Y_TILED:
-   ctl |= PLANE_CTL_TILED_Y;
-   break;
-   case I915_FORMAT_MOD_Yf_TILED:
-   ctl |= PLANE_CTL_TILED_YF;
-   break;
-   default:
-   MISSING_CASE(fb->modifier[0]);
-   }
-
-   /*
-* The stride is either expressed as a multiple of 64 bytes chunks for
-* linear buffers or in number of tiles for tiled buffers.
-*/
-   if (intel_rotation_90_or_270(rotation)) {
-   /* stride = Surface height in tiles */
-   tile_height = intel_tile_height(dev_priv, fb->modifier[0], 0);
-   stride = DIV_ROUND_UP(fb->height, tile_height);
-   } else {
-   stride = fb->pitches[0] /
-   intel_fb_stride_alignment(dev_priv, fb->modifier[0],
- fb->pixel_format);
-   }
-
-   /*
-* Both PLANE_CTL and PLANE_STRIDE are not updated on vblank but on
-* PLANE_SURF updates, the update is then guaranteed to be atomic.
-*/
-   I915_WRITE(PLANE_CTL(pipe, 0), ctl);
-   I915_WRITE(PLANE_STRIDE(pipe, 0), stride);
-
-   I915_WRITE(PLANE_SURF(pipe, 0), work->gtt_offset);
-   POSTING_READ(PLANE_SURF(pipe, 0));
-}
-
-static void ilk_do_mmio_flip(struct intel_crtc *intel_crtc,
-struct intel_flip_work *work)
-{
-   struct drm_device *dev = intel_crtc->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_framebuffer *intel_fb =
-   to_intel_framebuffer(intel_crtc->base.primary->fb);
-   struct drm_i915_gem_object *obj = intel_fb->obj;
-   i915_reg_t reg = DSPCNTR(intel_crtc->plane);
-   u32 dspcntr;
-
-   dspcntr = I915_READ(reg);
-
-   if (obj->tiling_mode != I915_TILING_NONE)
-   dspcntr |= DISPPLANE_TILED;
-   else
-   dspcntr &= ~DISPPLANE_TILED;
-
-   I915_WRITE(reg, dspcntr);
-
-   I915_WRITE(DSPSURF(intel_crtc->plane), work->gtt_offset);
-   POSTING_READ(DSPSURF(intel_crtc->plane));
-}
-
 static void intel_mmio_flip_work_func(struct work_struct *w)
 {
struct intel_flip_work *work =
container_of(w, struct intel_flip_work, mmio_work);
struct intel_crtc *crtc = to_intel_crtc(work->crtc);
-   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   struct intel_framebuffer *intel_fb =
-   to_intel_framebuffer(crtc->base.primary->fb);
-   struct drm_i915_gem_object *obj = intel_fb->obj;
+   

[Intel-gfx] [PATCH v2 13/21] drm/i915: Remove use_mmio_flip kernel parameter.

[Maarten Lankhorst]

With the removal of cs flips this is always force enabled.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_params.c | 5 -
 drivers/gpu/drm/i915/i915_params.h | 1 -
 drivers/gpu/drm/i915/intel_lrc.c   | 4 +---
 3 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 383c076919ed..cd74fb8e9387 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -49,7 +49,6 @@ struct i915_params i915 __read_mostly = {
.invert_brightness = 0,
.disable_display = 0,
.enable_cmd_parser = 1,
-   .use_mmio_flip = 0,
.mmio_debug = 0,
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
@@ -174,10 +173,6 @@ module_param_named_unsafe(enable_cmd_parser, 
i915.enable_cmd_parser, int, 0600);
 MODULE_PARM_DESC(enable_cmd_parser,
 "Enable command parsing (1=enabled [default], 0=disabled)");
 
-module_param_named_unsafe(use_mmio_flip, i915.use_mmio_flip, int, 0600);
-MODULE_PARM_DESC(use_mmio_flip,
-"use MMIO flips (-1=never, 0=driver discretion [default], 
1=always)");
-
 module_param_named(mmio_debug, i915.mmio_debug, int, 0600);
 MODULE_PARM_DESC(mmio_debug,
"Enable the MMIO debug code for the first N failures (default: off). "
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 65e73dd7d970..dd0d0bbcc05b 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -46,7 +46,6 @@ struct i915_params {
int invert_brightness;
int enable_cmd_parser;
int guc_log_level;
-   int use_mmio_flip;
int mmio_debug;
int edp_vswing;
unsigned int inject_load_failure;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index db10c961e0f4..affca6d5ce7e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -260,9 +260,7 @@ int intel_sanitize_enable_execlists(struct drm_i915_private 
*dev_priv, int enabl
if (enable_execlists == 0)
return 0;
 
-   if (HAS_LOGICAL_RING_CONTEXTS(dev_priv) &&
-   USES_PPGTT(dev_priv) &&
-   i915.use_mmio_flip >= 0)
+   if (HAS_LOGICAL_RING_CONTEXTS(dev_priv) && USES_PPGTT(dev_priv))
return 1;
 
return 0;
-- 
2.5.5

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

[Intel-gfx] [PATCH v2 11/21] drm/i915: Rework intel_crtc_page_flip to be almost atomic, v3.

[Maarten Lankhorst]

Create a work structure that will be used for all changes. This will
be used later on in the atomic commit function.

Changes since v1:
- Free old_crtc_state from unpin_work_fn properly.
Changes since v2:
- Add hunk for calling hw state verifier.
- Add missing support for color spaces.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  36 +-
 drivers/gpu/drm/i915/intel_display.c | 672 +--
 drivers/gpu/drm/i915/intel_drv.h |  13 +-
 3 files changed, 441 insertions(+), 280 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 220ec15e9864..6bce4fd8aaf4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -598,29 +598,43 @@ static void i915_dump_pageflip(struct seq_file *m,
   struct intel_flip_work *work)
 {
const char pipe = pipe_name(crtc->pipe);
-   const char plane = plane_name(crtc->plane);
u32 pending;
u32 addr;
+   int i;
 
pending = atomic_read(>pending);
if (pending) {
seq_printf(m, "Flip ioctl preparing on pipe %c (plane %c)\n",
-  pipe, plane);
+  pipe, plane_name(crtc->plane));
} else {
seq_printf(m, "Flip pending (waiting for vsync) on pipe %c 
(plane %c)\n",
-  pipe, plane);
+  pipe, plane_name(crtc->plane));
}
-   if (work->flip_queued_req) {
-   struct intel_engine_cs *engine = 
i915_gem_request_get_engine(work->flip_queued_req);
 
-   seq_printf(m, "Flip queued on %s at seqno %x, next seqno %x 
[current breadcrumb %x], completed? %d\n",
+
+   for (i = 0; i < work->num_planes; i++) {
+   struct intel_plane_state *old_plane_state = 
work->old_plane_state[i];
+   struct drm_plane *plane = old_plane_state->base.plane;
+   struct drm_i915_gem_request *req = old_plane_state->wait_req;
+   struct intel_engine_cs *engine;
+
+   seq_printf(m, "[PLANE:%i] part of flip.\n", plane->base.id);
+
+   if (!req) {
+   seq_printf(m, "Plane not associated with any engine\n");
+   continue;
+   }
+
+   engine = i915_gem_request_get_engine(req);
+
+   seq_printf(m, "Plane blocked on %s at seqno %x, next seqno %x 
[current breadcrumb %x], completed? %d\n",
   engine->name,
-  i915_gem_request_get_seqno(work->flip_queued_req),
+  i915_gem_request_get_seqno(req),
   dev_priv->next_seqno,
   engine->get_seqno(engine),
-  i915_gem_request_completed(work->flip_queued_req, 
true));
-   } else
-   seq_printf(m, "Flip not associated with any ring\n");
+  i915_gem_request_completed(req, true));
+   }
+
seq_printf(m, "Flip queued on frame %d, (was ready on frame %d), now 
%d\n",
   work->flip_queued_vblank,
   work->flip_ready_vblank,
@@ -633,7 +647,7 @@ static void i915_dump_pageflip(struct seq_file *m,
addr = I915_READ(DSPADDR(crtc->plane));
seq_printf(m, "Current scanout address 0x%08x\n", addr);
 
-   if (work->pending_flip_obj) {
+   if (work->flip_queued_req) {
seq_printf(m, "New framebuffer address 0x%08lx\n", 
(long)work->gtt_offset);
seq_printf(m, "MMIO update completed? %d\n",  addr == 
work->gtt_offset);
}
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b7888ad331bb..b8b12177f1f0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -50,7 +50,7 @@
 
 static bool is_mmio_work(struct intel_flip_work *work)
 {
-   return work->mmio_work.func;
+   return !work->flip_queued_req;
 }
 
 /* Primary plane formats for gen <= 3 */
@@ -123,6 +123,9 @@ static void ironlake_pfit_enable(struct intel_crtc *crtc);
 static void intel_modeset_setup_hw_state(struct drm_device *dev);
 static void intel_pre_disable_primary_noatomic(struct drm_crtc *crtc);
 static int ilk_max_pixel_rate(struct drm_atomic_state *state);
+static void intel_modeset_verify_crtc(struct drm_crtc *crtc,
+ struct drm_crtc_state *old_state,
+ struct drm_crtc_state *new_state);
 
 struct intel_limit {
struct {
@@ -2527,20 +2530,6 @@ out_unref_obj:
return false;
 }
 
-/* Update plane->state->fb to match plane->fb after driver-internal updates */
-static void
-update_state_fb(struct drm_plane *plane)
-{
-   if (plane->fb == plane->state->fb)
-   return;
-
-   if (plane->state->fb)
- 

[Intel-gfx] [PATCH v2 17/21] drm/i915: Prepare connectors for nonblocking checks.

[Maarten Lankhorst]

intel_unpin_work may not take the list lock because it requires the 
connector_mutex.
To prevent taking locks we add an array of old and new state. The old state to 
free,
the new state to commit and verify.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 53 ++--
 drivers/gpu/drm/i915/intel_drv.h |  4 +++
 2 files changed, 43 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 15ab4a6f1556..69abc808a2c4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6249,9 +6249,10 @@ void intel_encoder_destroy(struct drm_encoder *encoder)
 
 /* Cross check the actual hw state with our own modeset state tracking (and 
it's
  * internal consistency). */
-static void intel_connector_verify_state(struct intel_connector *connector)
+static void intel_connector_verify_state(struct intel_connector *connector,
+struct drm_connector_state *conn_state)
 {
-   struct drm_crtc *crtc = connector->base.state->crtc;
+   struct drm_crtc *crtc = conn_state->crtc;
 
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
  connector->base.base.id,
@@ -6259,7 +6260,6 @@ static void intel_connector_verify_state(struct 
intel_connector *connector)
 
if (connector->get_hw_state(connector)) {
struct intel_encoder *encoder = connector->encoder;
-   struct drm_connector_state *conn_state = connector->base.state;
 
I915_STATE_WARN(!crtc,
 "connector enabled without attached crtc\n");
@@ -6281,7 +6281,7 @@ static void intel_connector_verify_state(struct 
intel_connector *connector)
} else {
I915_STATE_WARN(crtc && crtc->state->active,
"attached crtc is active, but connector isn't\n");
-   I915_STATE_WARN(!crtc && connector->base.state->best_encoder,
+   I915_STATE_WARN(!crtc && conn_state->best_encoder,
"best encoder set without crtc!\n");
}
 }
@@ -10776,6 +10776,14 @@ void intel_mark_idle(struct drm_i915_private *dev_priv)
intel_runtime_pm_put(dev_priv);
 }
 
+static void
+intel_free_flip_work(struct intel_flip_work *work)
+{
+   kfree(work->old_connector_state);
+   kfree(work->new_connector_state);
+   kfree(work);
+}
+
 static void intel_crtc_destroy(struct drm_crtc *crtc)
 {
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -10791,7 +10799,7 @@ static void intel_crtc_destroy(struct drm_crtc *crtc)
 
cancel_work_sync(>mmio_work);
cancel_work_sync(>unpin_work);
-   kfree(work);
+   intel_free_flip_work(work);
 
spin_lock_irq(>event_lock);
}
@@ -10856,11 +10864,32 @@ static void intel_unpin_work_fn(struct work_struct 
*__work)
/* Make sure mmio work is completely finished before freeing all state 
here. */
flush_work(>mmio_work);
 
-   if (!work->can_async_unpin)
+   if (!work->can_async_unpin &&
+   (work->new_crtc_state->update_pipe ||
+needs_modeset(>new_crtc_state->base))) {
/* This must be called before work is unpinned for 
serialization. */
intel_modeset_verify_crtc(crtc, >old_crtc_state->base,
  >new_crtc_state->base);
 
+   for (i = 0; i < work->num_new_connectors; i++) {
+   struct drm_connector_state *conn_state =
+   work->new_connector_state[i];
+   struct drm_connector *con = conn_state->connector;
+
+   intel_connector_verify_state(to_intel_connector(con),
+conn_state);
+   }
+   }
+
+   for (i = 0; i < work->num_old_connectors; i++) {
+   struct drm_connector_state *old_con_state =
+   work->old_connector_state[i];
+   struct drm_connector *con =
+   old_con_state->connector;
+
+   con->funcs->atomic_destroy_state(con, old_con_state);
+   }
+
if (!work->can_async_unpin || !list_empty(>head)) {
spin_lock_irq(>event_lock);
WARN(list_empty(>head) != work->can_async_unpin,
@@ -10906,7 +10935,7 @@ static void intel_unpin_work_fn(struct work_struct 
*__work)
if (!WARN_ON(atomic_read(_crtc->unpin_work_count) == 0))
atomic_dec(_crtc->unpin_work_count);
 
-   kfree(work);
+   intel_free_flip_work(work);
 }
 
 
@@ -11197,7 +11226,7 @@ cleanup:
if (new_crtc_state)
intel_crtc_destroy_state(crtc, new_crtc_state);
 
-   kfree(work);
+   intel_free_flip_work(work);
return ret;
 }
 
@@ -12319,7 +12348,8 @@ 

[Intel-gfx] [PATCH v2 04/21] drm/i915: Remove intel_prepare_page_flip, v3.

[Maarten Lankhorst]

Instead of calling prepare_flip right before calling finish_page_flip
do everything from prepare_page_flip in finish_page_flip.

Putting prepare and finish page_flip in a single step removes the need
for INTEL_FLIP_COMPLETE, so it can be removed. This simplifies the code
slightly.

Changes since v1:
- Invert if case to simplify code.
- Add missing barrier.
- Reword commit message.
Changes since v2:
- intel_page_flip_plane is removed.
- work->pending is turned into a bool.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  5 +--
 drivers/gpu/drm/i915/i915_irq.c  | 18 ++---
 drivers/gpu/drm/i915/intel_display.c | 72 +++-
 drivers/gpu/drm/i915/intel_drv.h |  4 --
 4 files changed, 26 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index f23b119a365d..6bff6b4daf99 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -619,12 +619,9 @@ static int i915_gem_pageflip_info(struct seq_file *m, void 
*data)
u32 addr;
 
pending = atomic_read(>pending);
-   if (pending == INTEL_FLIP_INACTIVE) {
+   if (pending) {
seq_printf(m, "Flip ioctl preparing on pipe %c 
(plane %c)\n",
   pipe, plane);
-   } else if (pending >= INTEL_FLIP_COMPLETE) {
-   seq_printf(m, "Flip queued on pipe %c (plane 
%c)\n",
-  pipe, plane);
} else {
seq_printf(m, "Flip pending (waiting for vsync) 
on pipe %c (plane %c)\n",
   pipe, plane);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 920a5e4abb70..148741646fb0 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1705,10 +1705,8 @@ static void valleyview_pipestat_irq_handler(struct 
drm_i915_private *dev_priv,
intel_pipe_handle_vblank(dev_priv, pipe))
intel_check_page_flip(dev_priv, pipe);
 
-   if (pipe_stats[pipe] & PLANE_FLIP_DONE_INT_STATUS_VLV) {
-   intel_prepare_page_flip(dev_priv, pipe);
+   if (pipe_stats[pipe] & PLANE_FLIP_DONE_INT_STATUS_VLV)
intel_finish_page_flip(dev_priv, pipe);
-   }
 
if (pipe_stats[pipe] & PIPE_CRC_DONE_INTERRUPT_STATUS)
i9xx_pipe_crc_irq_handler(dev_priv, pipe);
@@ -2162,10 +2160,8 @@ static void ilk_display_irq_handler(struct 
drm_i915_private *dev_priv,
i9xx_pipe_crc_irq_handler(dev_priv, pipe);
 
/* plane/pipes map 1:1 on ilk+ */
-   if (de_iir & DE_PLANE_FLIP_DONE(pipe)) {
-   intel_prepare_page_flip(dev_priv, pipe);
+   if (de_iir & DE_PLANE_FLIP_DONE(pipe))
intel_finish_page_flip(dev_priv, pipe);
-   }
}
 
/* check event from PCH */
@@ -2209,10 +2205,8 @@ static void ivb_display_irq_handler(struct 
drm_i915_private *dev_priv,
intel_check_page_flip(dev_priv, pipe);
 
/* plane/pipes map 1:1 on ilk+ */
-   if (de_iir & DE_PLANE_FLIP_DONE_IVB(pipe)) {
-   intel_prepare_page_flip(dev_priv, pipe);
+   if (de_iir & DE_PLANE_FLIP_DONE_IVB(pipe))
intel_finish_page_flip(dev_priv, pipe);
-   }
}
 
/* check event from PCH */
@@ -2417,10 +2411,8 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
else
flip_done &= GEN8_PIPE_PRIMARY_FLIP_DONE;
 
-   if (flip_done) {
-   intel_prepare_page_flip(dev_priv, pipe);
+   if (flip_done)
intel_finish_page_flip(dev_priv, pipe);
-   }
 
if (iir & GEN8_PIPE_CDCLK_CRC_DONE)
hsw_pipe_crc_irq_handler(dev_priv, pipe);
@@ -3998,7 +3990,6 @@ static bool i8xx_handle_vblank(struct drm_i915_private 
*dev_priv,
if (I915_READ16(ISR) & flip_pending)
goto check_page_flip;
 
-   intel_prepare_page_flip(dev_priv, plane);
intel_finish_page_flip(dev_priv, pipe);
return true;
 
@@ -4188,7 +4179,6 @@ static bool i915_handle_vblank(struct drm_i915_private 
*dev_priv,
if (I915_READ(ISR) & flip_pending)
goto check_page_flip;
 
-   intel_prepare_page_flip(dev_priv, plane);
intel_finish_page_flip(dev_priv, pipe);
return true;
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 

[Intel-gfx] [PATCH v2 06/21] drm/i915: Unify unpin_work and mmio_work into flip_work, v2.

[Maarten Lankhorst]

Rename intel_unpin_work to intel_flip_work and use it for mmio flips
and unpinning. Use flip_queued_req to hold the wait request in the
mmio case, and the vblank counter from intel_crtc_get_vblank_counter.

MMIO flips get their own path through intel_finish_page_flip_mmio,
handled on vblank. CS page flips go through *_cs.

Changes since v1:
- Clean up destinction between MMIO and CS flips.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |   6 +-
 drivers/gpu/drm/i915/i915_irq.c  |  20 ++-
 drivers/gpu/drm/i915/intel_display.c | 282 +++
 drivers/gpu/drm/i915/intel_drv.h |  22 ++-
 drivers/gpu/drm/i915/intel_sprite.c  |   8 +-
 5 files changed, 185 insertions(+), 153 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6bff6b4daf99..0a4bedb96d65 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -607,10 +607,10 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
void *data)
for_each_intel_crtc(dev, crtc) {
const char pipe = pipe_name(crtc->pipe);
const char plane = plane_name(crtc->plane);
-   struct intel_unpin_work *work;
+   struct intel_flip_work *work;
 
spin_lock_irq(>event_lock);
-   work = crtc->unpin_work;
+   work = crtc->flip_work;
if (work == NULL) {
seq_printf(m, "No flip due on pipe %c (plane %c)\n",
   pipe, plane);
@@ -640,7 +640,7 @@ static int i915_gem_pageflip_info(struct seq_file *m, void 
*data)
seq_printf(m, "Flip queued on frame %d, (was ready on 
frame %d), now %d\n",
   work->flip_queued_vblank,
   work->flip_ready_vblank,
-  drm_crtc_vblank_count(>base));
+  intel_crtc_get_vblank_counter(crtc));
seq_printf(m, "%d prepares\n", 
atomic_read(>pending));
 
if (INTEL_INFO(dev)->gen >= 4)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 148741646fb0..3242a37fb304 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1634,7 +1634,13 @@ static void gen6_rps_irq_handler(struct drm_i915_private 
*dev_priv, u32 pm_iir)
 static bool intel_pipe_handle_vblank(struct drm_i915_private *dev_priv,
 enum pipe pipe)
 {
-   return drm_handle_vblank(dev_priv->dev, pipe);
+   bool ret;
+
+   ret = drm_handle_vblank(dev_priv->dev, pipe);
+   if (ret)
+   intel_finish_page_flip_mmio(dev_priv, pipe);
+
+   return ret;
 }
 
 static void valleyview_pipestat_irq_ack(struct drm_i915_private *dev_priv,
@@ -1706,7 +1712,7 @@ static void valleyview_pipestat_irq_handler(struct 
drm_i915_private *dev_priv,
intel_check_page_flip(dev_priv, pipe);
 
if (pipe_stats[pipe] & PLANE_FLIP_DONE_INT_STATUS_VLV)
-   intel_finish_page_flip(dev_priv, pipe);
+   intel_finish_page_flip_cs(dev_priv, pipe);
 
if (pipe_stats[pipe] & PIPE_CRC_DONE_INTERRUPT_STATUS)
i9xx_pipe_crc_irq_handler(dev_priv, pipe);
@@ -2161,7 +2167,7 @@ static void ilk_display_irq_handler(struct 
drm_i915_private *dev_priv,
 
/* plane/pipes map 1:1 on ilk+ */
if (de_iir & DE_PLANE_FLIP_DONE(pipe))
-   intel_finish_page_flip(dev_priv, pipe);
+   intel_finish_page_flip_cs(dev_priv, pipe);
}
 
/* check event from PCH */
@@ -2206,7 +2212,7 @@ static void ivb_display_irq_handler(struct 
drm_i915_private *dev_priv,
 
/* plane/pipes map 1:1 on ilk+ */
if (de_iir & DE_PLANE_FLIP_DONE_IVB(pipe))
-   intel_finish_page_flip(dev_priv, pipe);
+   intel_finish_page_flip_cs(dev_priv, pipe);
}
 
/* check event from PCH */
@@ -2412,7 +2418,7 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
flip_done &= GEN8_PIPE_PRIMARY_FLIP_DONE;
 
if (flip_done)
-   intel_finish_page_flip(dev_priv, pipe);
+   intel_finish_page_flip_cs(dev_priv, pipe);
 
if (iir & GEN8_PIPE_CDCLK_CRC_DONE)
hsw_pipe_crc_irq_handler(dev_priv, pipe);
@@ -3990,7 +3996,7 @@ static bool i8xx_handle_vblank(struct drm_i915_private 
*dev_priv,
if (I915_READ16(ISR) & flip_pending)
goto check_page_flip;
 
-   intel_finish_page_flip(dev_priv, pipe);
+   intel_finish_page_flip_cs(dev_priv, pipe);
return true;
 
 check_page_flip:
@@ -4179,7 

[Intel-gfx] [PATCH v2 14/21] drm/i915: Remove queue_flip pointer.

[Maarten Lankhorst]

With the removal of cs support this is no longer reachable.
Can be revived if needed.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.h  |   5 -
 drivers/gpu/drm/i915/intel_display.c | 259 ---
 2 files changed, 264 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 26c0525fc546..ea35a432bb68 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -618,11 +618,6 @@ struct drm_i915_display_funcs {
void (*audio_codec_disable)(struct intel_encoder *encoder);
void (*fdi_link_train)(struct drm_crtc *crtc);
void (*init_clock_gating)(struct drm_device *dev);
-   int (*queue_flip)(struct drm_device *dev, struct drm_crtc *crtc,
- struct drm_framebuffer *fb,
- struct drm_i915_gem_object *obj,
- struct drm_i915_gem_request *req,
- uint64_t gtt_offset);
void (*hpd_irq_setup)(struct drm_i915_private *dev_priv);
/* clock updates for mode set */
/* cursor updates */
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 19a382445306..d96f6a86d6f6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10964,237 +10964,6 @@ void intel_finish_page_flip_mmio(struct 
drm_i915_private *dev_priv, int pipe)
spin_unlock_irqrestore(>event_lock, flags);
 }
 
-static int intel_gen2_queue_flip(struct drm_device *dev,
-struct drm_crtc *crtc,
-struct drm_framebuffer *fb,
-struct drm_i915_gem_object *obj,
-struct drm_i915_gem_request *req,
-uint64_t gtt_offset)
-{
-   struct intel_engine_cs *engine = req->engine;
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   u32 flip_mask;
-   int ret;
-
-   ret = intel_ring_begin(req, 6);
-   if (ret)
-   return ret;
-
-   /* Can't queue multiple flips, so wait for the previous
-* one to finish before executing the next.
-*/
-   if (intel_crtc->plane)
-   flip_mask = MI_WAIT_FOR_PLANE_B_FLIP;
-   else
-   flip_mask = MI_WAIT_FOR_PLANE_A_FLIP;
-   intel_ring_emit(engine, MI_WAIT_FOR_EVENT | flip_mask);
-   intel_ring_emit(engine, MI_NOOP);
-   intel_ring_emit(engine, MI_DISPLAY_FLIP |
-   MI_DISPLAY_FLIP_PLANE(intel_crtc->plane));
-   intel_ring_emit(engine, fb->pitches[0]);
-   intel_ring_emit(engine, gtt_offset);
-   intel_ring_emit(engine, 0); /* aux display base address, unused */
-
-   return 0;
-}
-
-static int intel_gen3_queue_flip(struct drm_device *dev,
-struct drm_crtc *crtc,
-struct drm_framebuffer *fb,
-struct drm_i915_gem_object *obj,
-struct drm_i915_gem_request *req,
-uint64_t gtt_offset)
-{
-   struct intel_engine_cs *engine = req->engine;
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   u32 flip_mask;
-   int ret;
-
-   ret = intel_ring_begin(req, 6);
-   if (ret)
-   return ret;
-
-   if (intel_crtc->plane)
-   flip_mask = MI_WAIT_FOR_PLANE_B_FLIP;
-   else
-   flip_mask = MI_WAIT_FOR_PLANE_A_FLIP;
-   intel_ring_emit(engine, MI_WAIT_FOR_EVENT | flip_mask);
-   intel_ring_emit(engine, MI_NOOP);
-   intel_ring_emit(engine, MI_DISPLAY_FLIP_I915 |
-   MI_DISPLAY_FLIP_PLANE(intel_crtc->plane));
-   intel_ring_emit(engine, fb->pitches[0]);
-   intel_ring_emit(engine, gtt_offset);
-   intel_ring_emit(engine, MI_NOOP);
-
-   return 0;
-}
-
-static int intel_gen4_queue_flip(struct drm_device *dev,
-struct drm_crtc *crtc,
-struct drm_framebuffer *fb,
-struct drm_i915_gem_object *obj,
-struct drm_i915_gem_request *req,
-uint64_t gtt_offset)
-{
-   struct intel_engine_cs *engine = req->engine;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   uint32_t pf, pipesrc;
-   int ret;
-
-   ret = intel_ring_begin(req, 4);
-   if (ret)
-   return ret;
-
-   /* i965+ uses the linear or tiled offsets from the
-* Display Registers (which do not change across a page-flip)
-* so we need only reprogram the base address.
-*/
-   intel_ring_emit(engine, MI_DISPLAY_FLIP |
-   

[Intel-gfx] [PATCH v2 00/21] Rework page flip, remove cs flips, async unpin and unified pageflip.

[Maarten Lankhorst]

Connector lifetime patches forced a rethinking for handling connectors.
Instead of flushing modesets from the connector destroy function this
meant destroying the connector state inside the unpin_work function,
similar to the other states destroyed there. This is only done if the
state is actually needed.

Some minor updates have been done to clean up the mmio page flip
completion, they're now separated from cs flip completion.

Convert flip_work to a list has been reworked to incorporate the
feedback. It should now probably work with multiple flips without
waiting, but is currently only used for unpinning legacy cursor
updates.

Maarten Lankhorst (21):
  drm/core: Add drm_accurate_vblank_count, v5.
  drm/i915: Remove stallcheck special handling, v3.
  drm/i915: Remove intel_finish_page_flip_plane.
  drm/i915: Remove intel_prepare_page_flip, v3.
  drm/i915: Add support for detecting vblanks when hw frame counter is
unavailable.
  drm/i915: Unify unpin_work and mmio_work into flip_work, v2.
  Revert "drm/i915: Avoid stalling on pending flips for legacy cursor
updates"
  drm/i915: Allow mmio updates on all platforms, v2.
  drm/i915: Convert flip_work to a list.
  drm/i915: Add the exclusive fence to plane_state.
  drm/i915: Rework intel_crtc_page_flip to be almost atomic, v3.
  drm/i915: Remove cs based page flip support.
  drm/i915: Remove use_mmio_flip kernel parameter.
  drm/i915: Remove queue_flip pointer.
  drm/i915: Remove reset_counter from intel_crtc.
  drm/i915: Pass atomic states to fbc update functions.
  drm/i915: Prepare connectors for nonblocking checks.
  drm/i915: Make unpin async.
  Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor
updates"
  drm/i915: Check for unpin correctness.
  drm/i915: Allow async update of pageflips.

 drivers/gpu/drm/drm_irq.c |   31 +
 drivers/gpu/drm/i915/i915_debugfs.c   |   93 +-
 drivers/gpu/drm/i915/i915_drv.h   |5 -
 drivers/gpu/drm/i915/i915_irq.c   |  142 +--
 drivers/gpu/drm/i915/i915_params.c|5 -
 drivers/gpu/drm/i915/i915_params.h|1 -
 drivers/gpu/drm/i915/intel_atomic.c   |   11 +
 drivers/gpu/drm/i915/intel_atomic_plane.c |1 +
 drivers/gpu/drm/i915/intel_display.c  | 1725 +
 drivers/gpu/drm/i915/intel_drv.h  |   68 +-
 drivers/gpu/drm/i915/intel_fbc.c  |   39 +-
 drivers/gpu/drm/i915/intel_lrc.c  |4 +-
 drivers/gpu/drm/i915/intel_sprite.c   |   16 +-
 include/drm/drmP.h|1 +
 14 files changed, 742 insertions(+), 1400 deletions(-)

-- 
2.5.5

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

[Intel-gfx] [PATCH v2 19/21] Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor updates"

[Maarten Lankhorst]

This reapplies commit acf4e84d6167317ff21be5c03e1ea76ea5783701.
With async unpin this should no longer break.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 16d8e24d..9236407e9b13 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12930,12 +12930,14 @@ static int intel_atomic_prepare_commit(struct 
drm_device *dev,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_flip_work *work;
 
-   ret = intel_crtc_wait_for_pending_flips(crtc);
-   if (ret)
-   return ret;
+   if (!state->legacy_cursor_update) {
+   ret = intel_crtc_wait_for_pending_flips(crtc);
+   if (ret)
+   return ret;
 
-   if (atomic_read(_crtc->unpin_work_count) >= 2)
-   flush_workqueue(dev_priv->wq);
+   if (atomic_read(_crtc->unpin_work_count) >= 2)
+   flush_workqueue(dev_priv->wq);
+   }
 
/* test if we need to update something */
if (!needs_work(crtc_state))
-- 
2.5.5

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

[Intel-gfx] [PATCH v2 21/21] drm/i915: Allow async update of pageflips.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 350 +--
 1 file changed, 84 insertions(+), 266 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 330a6397f07c..79759cdfada3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -108,8 +108,6 @@ static void vlv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config);
 static void chv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config);
-static void intel_begin_crtc_commit(struct drm_crtc *, struct drm_crtc_state 
*);
-static void intel_finish_crtc_commit(struct drm_crtc *, struct drm_crtc_state 
*);
 static void skl_init_scalers(struct drm_device *dev, struct intel_crtc 
*intel_crtc,
struct intel_crtc_state *crtc_state);
 static void skylake_pfit_enable(struct intel_crtc *crtc);
@@ -10981,7 +10979,7 @@ static void intel_mmio_flip_work_func(struct 
work_struct *w)
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_request *req;
-   int i;
+   int i, ret;
 
if (!needs_modeset(_state->base) && crtc_state->update_pipe) {
work->put_power_domains =
@@ -11003,7 +11001,14 @@ static void intel_mmio_flip_work_func(struct 
work_struct *w)
_priv->rps.mmioflips));
}
 
-   intel_frontbuffer_flip_prepare(dev, crtc_state->fb_bits);
+   ret = drm_crtc_vblank_get(crtc);
+   I915_STATE_WARN(ret < 0, "enabling vblank failed with %i\n", ret);
+
+   if (work->num_planes &&
+   work->old_plane_state[0]->base.plane == crtc->primary)
+   intel_fbc_enable(intel_crtc, work->new_crtc_state, 
work->new_plane_state[0]);
+
+   intel_frontbuffer_flip_prepare(dev, work->fb_bits);
 
intel_pipe_update_start(intel_crtc);
if (!needs_modeset(_state->base)) {
@@ -11022,206 +11027,15 @@ static void intel_mmio_flip_work_func(struct 
work_struct *w)
struct intel_plane_state *new_plane_state = 
work->new_plane_state[i];
struct intel_plane *plane = 
to_intel_plane(new_plane_state->base.plane);
 
-   plane->update_plane(>base, crtc_state, new_plane_state);
+   if (new_plane_state->visible)
+   plane->update_plane(>base, crtc_state, 
new_plane_state);
+   else
+   plane->disable_plane(>base, crtc);
}
 
intel_pipe_update_end(intel_crtc, work);
 }
 
-static struct fence *intel_get_excl_fence(struct drm_i915_gem_object *obj)
-{
-   struct reservation_object *resv;
-
-
-   if (!obj->base.dma_buf)
-   return NULL;
-
-   resv = obj->base.dma_buf->resv;
-
-   /* For framebuffer backed by dmabuf, wait for fence */
-   while (1) {
-   struct fence *fence_excl, *ret = NULL;
-
-   rcu_read_lock();
-
-   fence_excl = rcu_dereference(resv->fence_excl);
-   if (fence_excl)
-   ret = fence_get_rcu(fence_excl);
-
-   rcu_read_unlock();
-
-   if (ret == fence_excl)
-   return ret;
-   }
-}
-
-static int intel_crtc_page_flip(struct drm_crtc *crtc,
-   struct drm_framebuffer *fb,
-   struct drm_pending_vblank_event *event,
-   uint32_t page_flip_flags)
-{
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   struct drm_plane_state *old_state, *new_state = NULL;
-   struct drm_crtc_state *new_crtc_state = NULL;
-   struct drm_framebuffer *old_fb = crtc->primary->state->fb;
-   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct drm_plane *primary = crtc->primary;
-   struct intel_flip_work *work;
-   int ret;
-
-   old_state = crtc->primary->state;
-
-   if (!crtc->state->active)
-   return -EINVAL;
-
-   /*
-* drm_mode_page_flip_ioctl() should already catch this, but double
-* check to be safe.  In the future we may enable pageflipping from
-* a disabled primary plane.
-*/
-   if (WARN_ON(intel_fb_obj(old_fb) == NULL))
-   return -EBUSY;
-
-   /* Can't change pixel format via MI display flips. */
-   if (fb->pixel_format != old_fb->pixel_format)
-   return -EINVAL;
-
-   /*
-* TILEOFF/LINOFF registers can't be changed via MI display flips.
-* Note that pitch changes could also affect these register.
-*/
-   if (INTEL_INFO(dev)->gen > 3 &&
-   (fb->offsets[0] != 

[Intel-gfx] [PATCH v2 07/21] Revert "drm/i915: Avoid stalling on pending flips for legacy cursor updates"

[Maarten Lankhorst]

This reverts commit acf4e84d6167317ff21be5c03e1ea76ea5783701.
Unfortunately this breaks the next commit with a use-after-free, so
temporarily revert until we can apply a solution.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d349a8118a56..6526bb5a7afb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13397,9 +13397,6 @@ static int intel_atomic_prepare_commit(struct 
drm_device *dev,
}
 
for_each_crtc_in_state(state, crtc, crtc_state, i) {
-   if (state->legacy_cursor_update)
-   continue;
-
ret = intel_crtc_wait_for_pending_flips(crtc);
if (ret)
return ret;
-- 
2.5.5

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

[Intel-gfx] [PATCH v2 20/21] drm/i915: Check for unpin correctness.

[Maarten Lankhorst]

If planes are added to the state after the call to
drm_atomic_helper_check_planes planes_changed may not be set
and we will not unpin the old framebuffer. This results in a
pin leak long after the framebuffer is destroyed, so to find
this add some checks when it happens.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9236407e9b13..330a6397f07c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13373,11 +13373,20 @@ intel_prepare_plane_fb(struct drm_plane *plane,
struct intel_plane *intel_plane = to_intel_plane(plane);
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->state->fb);
+   struct drm_crtc *crtc = new_state->crtc ?: plane->state->crtc;
int ret = 0;
 
if (!obj && !old_obj)
return 0;
 
+   if (WARN_ON(!new_state->state) || WARN_ON(!crtc) ||
+   
WARN_ON(!to_intel_atomic_state(new_state->state)->work[to_intel_crtc(crtc)->pipe]))
 {
+   if (WARN_ON(old_obj != obj))
+   return -EINVAL;
+
+   return 0;
+   }
+
if (old_obj) {
struct drm_crtc_state *crtc_state =
drm_atomic_get_existing_crtc_state(new_state->state, 
plane->state->crtc);
-- 
2.5.5

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

[Intel-gfx] [PATCH v2 18/21] drm/i915: Make unpin async.

[Maarten Lankhorst]

All of intel_post_plane_update is handled there now, so move it over.
This is run after the hw state checker because it can't handle checking
crtc's separately yet.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_atomic.c  |  11 ++
 drivers/gpu/drm/i915/intel_display.c | 344 ++-
 drivers/gpu/drm/i915/intel_drv.h |   5 +-
 3 files changed, 228 insertions(+), 132 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 50ff90aea721..b4927f6bbeac 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -311,6 +311,17 @@ intel_atomic_state_alloc(struct drm_device *dev)
 void intel_atomic_state_clear(struct drm_atomic_state *s)
 {
struct intel_atomic_state *state = to_intel_atomic_state(s);
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(state->work); i++) {
+   struct intel_flip_work *work = state->work[i];
+
+   if (work)
+   intel_free_flip_work(work);
+
+   state->work[i] = NULL;
+   }
+
drm_atomic_state_default_clear(>base);
state->dpll_set = state->modeset = false;
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 69abc808a2c4..16d8e24d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4537,39 +4537,6 @@ intel_pre_disable_primary_noatomic(struct drm_crtc *crtc)
}
 }
 
-static void intel_post_plane_update(struct intel_crtc_state *old_crtc_state)
-{
-   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
-   struct drm_atomic_state *old_state = old_crtc_state->base.state;
-   struct intel_crtc_state *pipe_config =
-   to_intel_crtc_state(crtc->base.state);
-   struct drm_device *dev = crtc->base.dev;
-   struct drm_plane *primary = crtc->base.primary;
-   struct drm_plane_state *old_pri_state =
-   drm_atomic_get_existing_plane_state(old_state, primary);
-
-   intel_frontbuffer_flip(dev, pipe_config->fb_bits);
-
-   crtc->wm.cxsr_allowed = true;
-
-   if (pipe_config->update_wm_post && pipe_config->base.active)
-   intel_update_watermarks(>base);
-
-   if (old_pri_state) {
-   struct intel_plane_state *primary_state =
-   to_intel_plane_state(primary->state);
-   struct intel_plane_state *old_primary_state =
-   to_intel_plane_state(old_pri_state);
-
-   intel_fbc_post_update(crtc);
-
-   if (primary_state->visible &&
-   (needs_modeset(_config->base) ||
-!old_primary_state->visible))
-   intel_post_enable_primary(>base);
-   }
-}
-
 static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
@@ -5179,18 +5146,21 @@ modeset_get_crtc_power_domains(struct drm_crtc *crtc,
struct drm_i915_private *dev_priv = crtc->dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum intel_display_power_domain domain;
-   unsigned long domains, new_domains, old_domains;
+   unsigned long domains, new_domains, old_domains, ms_domain = 0;
 
old_domains = intel_crtc->enabled_power_domains;
intel_crtc->enabled_power_domains = new_domains =
get_crtc_power_domains(crtc, crtc_state);
 
-   domains = new_domains & ~old_domains;
+   if (needs_modeset(_state->base))
+   ms_domain = BIT(POWER_DOMAIN_MODESET);
+
+   domains = (new_domains & ~old_domains) | ms_domain;
 
for_each_power_domain(domain, domains)
intel_display_power_get(dev_priv, domain);
 
-   return old_domains & ~new_domains;
+   return (old_domains & ~new_domains) | ms_domain;
 }
 
 static void modeset_put_power_domains(struct drm_i915_private *dev_priv,
@@ -6236,6 +6206,12 @@ int intel_display_suspend(struct drm_device *dev)
DRM_ERROR("Suspending crtc's failed with %i\n", ret);
else
dev_priv->modeset_restore_state = state;
+
+   /*
+* Make sure all unpin_work completes before returning.
+*/
+   flush_workqueue(dev_priv->wq);
+
return ret;
 }
 
@@ -10776,8 +10752,7 @@ void intel_mark_idle(struct drm_i915_private *dev_priv)
intel_runtime_pm_put(dev_priv);
 }
 
-static void
-intel_free_flip_work(struct intel_flip_work *work)
+void intel_free_flip_work(struct intel_flip_work *work)
 {
kfree(work->old_connector_state);
kfree(work->new_connector_state);
@@ -10852,9 +10827,13 @@ static void intel_unpin_work_fn(struct work_struct 
*__work)
 * that work->new_crtc_state contains valid memory during unpin
 * because intel_atomic_commit may 

[Intel-gfx] [PATCH v2 02/21] drm/i915: Remove stallcheck special handling, v3.

[Maarten Lankhorst]

Both intel_unpin_work.pending and intel_unpin_work.enable_stall_check
were used to see if work should be enabled. By only using pending
some special cases are gone, and access to unpin_work can be simplified.

A flip could previously be queued before
stallcheck was active. With the addition of the pending member
enable_stall_check became obsolete and can thus be removed.

Use this to only access work members untilintel_mark_page_flip_active
is called, or intel_queue_mmio_flip is used. This will prevent
use-after-free, and makes it easier to verify accesses.

Changes since v1:
- Reword commit message.
- Do not access unpin_work after intel_mark_page_flip_active.
- Add the right memory barriers.
Changes since v2:
- atomic_read() needs a full smp_rmb.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 11 +++---
 drivers/gpu/drm/i915/intel_display.c | 71 ++--
 drivers/gpu/drm/i915/intel_drv.h |  1 -
 3 files changed, 34 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 24f4105b910f..f23b119a365d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -615,9 +615,14 @@ static int i915_gem_pageflip_info(struct seq_file *m, void 
*data)
seq_printf(m, "No flip due on pipe %c (plane %c)\n",
   pipe, plane);
} else {
+   u32 pending;
u32 addr;
 
-   if (atomic_read(>pending) < INTEL_FLIP_COMPLETE) {
+   pending = atomic_read(>pending);
+   if (pending == INTEL_FLIP_INACTIVE) {
+   seq_printf(m, "Flip ioctl preparing on pipe %c 
(plane %c)\n",
+  pipe, plane);
+   } else if (pending >= INTEL_FLIP_COMPLETE) {
seq_printf(m, "Flip queued on pipe %c (plane 
%c)\n",
   pipe, plane);
} else {
@@ -639,10 +644,6 @@ static int i915_gem_pageflip_info(struct seq_file *m, void 
*data)
   work->flip_queued_vblank,
   work->flip_ready_vblank,
   drm_crtc_vblank_count(>base));
-   if (work->enable_stall_check)
-   seq_puts(m, "Stall check enabled, ");
-   else
-   seq_puts(m, "Stall check waiting for page flip 
ioctl, ");
seq_printf(m, "%d prepares\n", 
atomic_read(>pending));
 
if (INTEL_INFO(dev)->gen >= 4)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4777087326f6..3bcab21e67d3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3813,8 +3813,6 @@ static void page_flip_completed(struct intel_crtc 
*intel_crtc)
struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
struct intel_unpin_work *work = intel_crtc->unpin_work;
 
-   /* ensure that the unpin work is consistent wrt ->pending. */
-   smp_rmb();
intel_crtc->unpin_work = NULL;
 
if (work->event)
@@ -10890,16 +10888,13 @@ static void do_intel_finish_page_flip(struct 
drm_i915_private *dev_priv,
spin_lock_irqsave(>event_lock, flags);
work = intel_crtc->unpin_work;
 
-   /* Ensure we don't miss a work->pending update ... */
-   smp_rmb();
+   if (work && atomic_read(>pending) >= INTEL_FLIP_COMPLETE) {
+   /* ensure that the unpin work is consistent wrt ->pending. */
+   smp_rmb();
 
-   if (work == NULL || atomic_read(>pending) < INTEL_FLIP_COMPLETE) {
-   spin_unlock_irqrestore(>event_lock, flags);
-   return;
+   page_flip_completed(intel_crtc);
}
 
-   page_flip_completed(intel_crtc);
-
spin_unlock_irqrestore(>event_lock, flags);
 }
 
@@ -10995,10 +10990,8 @@ void intel_prepare_page_flip(struct drm_i915_private 
*dev_priv, int plane)
 static inline void intel_mark_page_flip_active(struct intel_unpin_work *work)
 {
/* Ensure that the work item is consistent when activating it ... */
-   smp_wmb();
+   smp_mb__before_atomic();
atomic_set(>pending, INTEL_FLIP_PENDING);
-   /* and that it is marked active as soon as the irq could fire. */
-   smp_wmb();
 }
 
 static int intel_gen2_queue_flip(struct drm_device *dev,
@@ -11032,7 +11025,6 @@ static int intel_gen2_queue_flip(struct drm_device *dev,
intel_ring_emit(engine, intel_crtc->unpin_work->gtt_offset);
intel_ring_emit(engine, 0); /* aux display base address, unused */
 
-   

[Intel-gfx] [PATCH v2 01/21] drm/core: Add drm_accurate_vblank_count, v5.

[Maarten Lankhorst]

This function is useful for gen2 intel devices which have no frame
counter, but need a way to determine the current vblank count without
racing with the vblank interrupt handler.

intel_pipe_update_start checks if no vblank interrupt will occur
during vblank evasion, but cannot check whether the vblank handler has
run to completion. This function uses the timestamps to determine
when the last vblank has happened, and interpolates from there.

Changes since v1:
- Take vblank_time_lock and don't use drm_vblank_count_and_time.
Changes since v2:
- Don't return time of last vblank.
Changes since v3:
- Change pipe to unsigned int. (Ville)
- Remove unused documentation for tv_ret. (kbuild)
Changes since v4:
- Add warning to docs when the function is useful.
- Add a WARN_ON when get_vblank_timestamp is unavailable.
- Use drm_vblank_count.

Cc: Mario Kleiner 
Cc: Ville Syrjälä 
Signed-off-by: Maarten Lankhorst 
Reviewed-by: Ville Syrjälä  #v4
Acked-by: David Airlie  #irc, v4
---
 drivers/gpu/drm/drm_irq.c | 31 +++
 include/drm/drmP.h|  1 +
 2 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3c1a6f18e71c..d3124b67f4a5 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -303,6 +303,37 @@ static void drm_update_vblank_count(struct drm_device 
*dev, unsigned int pipe,
store_vblank(dev, pipe, diff, _vblank, cur_vblank);
 }
 
+/**
+ * drm_accurate_vblank_count - retrieve the master vblank counter
+ * @crtc: which counter to retrieve
+ *
+ * This function is similar to @drm_crtc_vblank_count but this
+ * function interpolates to handle a race with vblank irq's.
+ *
+ * This is mostly useful for hardware that can obtain the scanout
+ * position, but doesn't have a frame counter.
+ */
+u32 drm_accurate_vblank_count(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   unsigned int pipe = drm_crtc_index(crtc);
+   u32 vblank;
+   unsigned long flags;
+
+   WARN(!dev->driver->get_vblank_timestamp,
+"This function requires support for accurate vblank timestamps.");
+
+   spin_lock_irqsave(>vblank_time_lock, flags);
+
+   drm_update_vblank_count(dev, pipe, 0);
+   vblank = drm_vblank_count(dev, pipe);
+
+   spin_unlock_irqrestore(>vblank_time_lock, flags);
+
+   return vblank;
+}
+EXPORT_SYMBOL(drm_accurate_vblank_count);
+
 /*
  * Disable vblank irq's on crtc, make sure that last vblank count
  * of hardware and corresponding consistent software vblank counter
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 360b2a74e1ef..ed890384b938 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1002,6 +1002,7 @@ extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
 extern void drm_crtc_vblank_reset(struct drm_crtc *crtc);
 extern void drm_crtc_vblank_on(struct drm_crtc *crtc);
 extern void drm_vblank_cleanup(struct drm_device *dev);
+extern u32 drm_accurate_vblank_count(struct drm_crtc *crtc);
 extern u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int pipe);
 
 extern int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
-- 
2.5.5

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

Re: [Intel-gfx] [PATCH i-g-t] tests: Add kms_rmfb testcase

[Maarten Lankhorst]

Op 17-05-16 om 12:48 schreef Daniel Vetter:
> On Fri, May 13, 2016 at 12:46:12PM +0200, Maarten Lankhorst wrote:
>> This allows us to test that RMFB works as intended by the original abi.
>> We create a framebuffer and try to remove the framebuffer from a crtc
>> using fd closing or rmfb ioctl.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
>> index b73f48d95568..c223c363e3e8 100644
>> --- a/tests/Makefile.sources
>> +++ b/tests/Makefile.sources
>> @@ -97,6 +97,7 @@ TESTS_progs_M = \
>>  kms_plane \
>>  kms_psr_sink_crc \
>>  kms_render \
>> +kms_rmfb \
>>  kms_rotation_crc \
>>  kms_setmode \
>>  kms_universal_plane \
>> diff --git a/tests/kms_rmfb.c b/tests/kms_rmfb.c
>> new file mode 100644
>> index ..a3fde9f43788
>> --- /dev/null
>> +++ b/tests/kms_rmfb.c
>> @@ -0,0 +1,180 @@
>> +/*
>> + * Copyright © 2016 Intel Corporation
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the 
>> "Software"),
>> + * to deal in the Software without restriction, including without limitation
>> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
>> + * and/or sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice (including the next
>> + * paragraph) shall be included in all copies or substantial portions of the
>> + * Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
>> OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
>> OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
>> DEALINGS
>> + * IN THE SOFTWARE.
>> + */
>> +
>> +#include "igt.h"
>> +#include "drmtest.h"
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#ifndef DRM_CAP_CURSOR_WIDTH
>> +#define DRM_CAP_CURSOR_WIDTH 0x8
>> +#endif
>> +#ifndef DRM_CAP_CURSOR_HEIGHT
>> +#define DRM_CAP_CURSOR_HEIGHT 0x9
>> +#endif
>> +
>> +struct rmfb_data {
>> +int drm_fd;
>> +igt_display_t display;
>> +};
>> +
>> +/*
>> + * 1. Set primary plane to a known fb.
>> + * 2. Make sure getcrtc returns the correct fb id.
>> + * 3. Call rmfb on the fb.
>> + * 4. Make sure getcrtc returns 0 fb id.
> I think a 2nd functional test we want to do at step 4) is to make a vblank
> wait call and assert that it fails. Just to make sure that the kernel did
> indeed shut down everything. We can only do that for the rmfb case though,
> since when we close the last drm fd fbcon make take over and light stuff
> up again.
>
> Perhaps also add a vblank ioctl call to step 2 as a sanity check - just
> ask for the current vblank count to avoid stalling.
In case of atomic we may choose to leave the CRTC enabled for faster switching. 
I don't think we should check if vblank fails..

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: refactor i915_gem_object_pin_map()

[Dave Gordon]

On 17/05/16 10:22, Tvrtko Ursulin wrote:


On 16/05/16 16:19, Dave Gordon wrote:

The recently-added i915_gem_object_pin_map() can be further optimised
for "small" objects. To facilitate this, and simplify the error paths
before adding the new code, this patch pulls out the "mapping" part of
the operation (involving local allocations which must be undone before
return) into its own subfunction.

The next patch will then insert the new optimisation into the middle of
the now-separated subfunction.

This reorganisation will probably not affect the generated code, as the
compiler will most likely inline it anyway, but it makes the logical
structure a bit clearer and easier to modify.

v2:
 Restructure loop-over-pages & error check (Chris Wilson)

v3:
 Add page count to debug messages (Chris Wilson)
 Convert WARN_ON() to GEM_BUG_ON()

Signed-off-by: Dave Gordon 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem.c | 59
++---
  1 file changed, 38 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index aff386e..bbec429 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2398,6 +2398,43 @@ static void
i915_gem_object_free_mmap_offset(struct drm_i915_gem_object *obj)
  return 0;
  }

+/* The 'mapping' part of i915_gem_object_pin_map() below */
+static void *i915_gem_object_map(const struct drm_i915_gem_object *obj)
+{
+unsigned long n_pages = obj->base.size >> PAGE_SHIFT;
+struct sg_table *sgt = obj->pages;
+struct sg_page_iter sg_iter;
+struct page **pages;
+unsigned long i = 0;
+void *addr = NULL;


Looks like this does not need to be initialized?


OK. BTW the compiler didn't actually generate any code for this :)


+
+/* A single page can always be kmapped */
+if (n_pages == 1)
+return kmap(sg_page(sgt->sgl));
+
+pages = drm_malloc_gfp(n_pages, sizeof(*pages), GFP_TEMPORARY);
+if (pages == NULL) {
+DRM_DEBUG_DRIVER("Failed to get space for %lu pointers\n",
+ n_pages);


Not terribly important but I think this is too low level functions to
have debug logging. It will not add a lot of useful information, no call
stack etc. And the callers are probably handling failures already and
they would propagate somewhere from where it is already reported.


+return NULL;
+}
+
+for_each_sg_page(sgt->sgl, _iter, sgt->nents, 0)
+pages[i++] = sg_page_iter_page(_iter);
+
+/* Check that we have the expected number of pages */
+GEM_BUG_ON(i != n_pages);
+
+addr = vmap(pages, n_pages, 0, PAGE_KERNEL);
+if (addr == NULL)
+DRM_DEBUG_DRIVER("Failed to vmap %lu pages\n", n_pages);


Same here. I mean, the only potential argument could be that this will
tell the real reason which is otherwise lost in the NULL return code,
but I am not sure it is worth it since it is so unlikely it would happen.


OK, debugging removed, new version posted.

.Dave.


+
+drm_free_large(pages);
+
+return addr;
+}
+
+/* get, pin, and map the pages of the object into kernel space */
  void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj)
  {
  int ret;
@@ -2411,27 +2448,7 @@ void *i915_gem_object_pin_map(struct
drm_i915_gem_object *obj)
  i915_gem_object_pin_pages(obj);

  if (obj->mapping == NULL) {
-struct page **pages;
-
-pages = NULL;
-if (obj->base.size == PAGE_SIZE)
-obj->mapping = kmap(sg_page(obj->pages->sgl));
-else
-pages = drm_malloc_gfp(obj->base.size >> PAGE_SHIFT,
-   sizeof(*pages),
-   GFP_TEMPORARY);
-if (pages != NULL) {
-struct sg_page_iter sg_iter;
-int n;
-
-n = 0;
-for_each_sg_page(obj->pages->sgl, _iter,
- obj->pages->nents, 0)
-pages[n++] = sg_page_iter_page(_iter);
-
-obj->mapping = vmap(pages, n, 0, PAGE_KERNEL);
-drm_free_large(pages);
-}
+obj->mapping = i915_gem_object_map(obj);
  if (obj->mapping == NULL) {
  i915_gem_object_unpin_pages(obj);
  return ERR_PTR(-ENOMEM);



Otherwise looks fine to me.

Regards,
Tvrtko


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

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub

[Daniel Vetter]

On Tue, May 17, 2016 at 02:47:44PM +0200, Takashi Iwai wrote:
> On Tue, 17 May 2016 14:34:21 +0200,
> Daniel Vetter wrote:
> > 
> > On Tue, May 17, 2016 at 03:11:02PM +0300, Imre Deak wrote:
> > > On ti, 2016-05-17 at 13:10 +0200, Daniel Vetter wrote:
> > > > On Tue, May 17, 2016 at 01:22:52PM +0300, Imre Deak wrote:
> > > > > On ti, 2016-05-17 at 11:59 +0200, Takashi Iwai wrote:
> > > > > > On Tue, 17 May 2016 11:42:17 +0200,
> > > > > > Daniel Vetter wrote:
> > > > > > > 
> > > > > > > On Tue, May 17, 2016 at 09:37:12AM +0200, Takashi Iwai wrote:
> > > > > > > > On Tue, 17 May 2016 09:20:48 +0200,
> > > > > > > > Daniel Vetter wrote:
> > > > > > > > > 
> > > > > > > > > On Thu, May 12, 2016 at 09:06:53PM +0300, Imre Deak wrote:
> > > > > > > > > > User may pass nomodeset or i915.modeset=0 option to
> > > > > > > > > > disable i915 KMS
> > > > > > > > > > explicitly.  Although this itself works fine, it breaks
> > > > > > > > > > the weak
> > > > > > > > > > dependency the HD-audio driver requires, and it's the
> > > > > > > > > > reason the
> > > > > > > > > > delayed component binding isn't implemented in HD-
> > > > > > > > > > audio.  Since i915
> > > > > > > > > > doesn't notify its disablement, HD-audio would be blocked
> > > > > > > > > > unnecessarily endlessly, waiting for the bind with i915.
> > > > > > > > > > 
> > > > > > > > > > This patch introduces a stub audio component binding when
> > > > > > > > > > i915 driver
> > > > > > > > > > is loaded with KMS off like the boot options above.  Then
> > > > > > > > > > i915 driver
> > > > > > > > > > still registers the slave component but with the new
> > > > > > > > > > "disabled" ops
> > > > > > > > > > flag, so that the master component (HD-audio) can know
> > > > > > > > > > clearly the
> > > > > > > > > > slave state.
> > > > > > > > > > 
> > > > > > > > > > v2:
> > > > > > > > > > - Fail the probe in case component registration fails,
> > > > > > > > > > instead of
> > > > > > > > > >   suppressing the error. (Ville)
> > > > > > > > > > - Register the component only for the real PCI device
> > > > > > > > > > function.
> > > > > > > > > > 
> > > > > > > > > > CC: Ville Syrjälä 
> > > > > > > > > > Signed-off-by: Imre Deak 
> > > > > > > > > > Signed-off-by: Takashi Iwai 
> > > > > > > > > 
> > > > > > > > > We don't support not running with modesetting. Why do we
> > > > > > > > > suddenly care?
> > > > > > > > 
> > > > > > > > This is needed for the patch 2 and 3.  Right now we have no
> > > > > > > > blocking
> > > > > > > > or deferred component binding, so far, in HD-audio
> > > > > > > > side.  This caused
> > > > > > > > problems when async module probe was done.
> > > > > > > > 
> > > > > > > > So, the patch 3 implements the blocking behavior of HD-audio
> > > > > > > > side.  It
> > > > > > > > would lead to another regression when i915 doesn't notify its
> > > > > > > > disabled
> > > > > > > > state by this patch.  Otherwise the HD-audio driver will be
> > > > > > > > blocked
> > > > > > > > endlessly of unnecessarily long.
> > > > > > > > 
> > > > > > > > > Same for users creating a .config that fails to boot or
> > > > > > > > > work ...
> > > > > > > > 
> > > > > > > > The config isn't cared much, but the problem is about the
> > > > > > > > runtime boot
> > > > > > > > option.
> > > > > > > > 
> > > > > > > > > If HDA needs to coporate with gfx to get things done, then
> > > > > > > > > imo we should
> > > > > > > > > just require that i915.ko is there.
> > > > > > > > 
> > > > > > > > Other way round: we do already require i915 in HD-audio
> > > > > > > > side.  But in
> > > > > > > > this case, we do *not* want to require i915 when it's
> > > > > > > > disabled in
> > > > > > > > runtime. 
> > > > > > > 
> > > > > > > That's what I mean: If you boot with i915.nomodeset you're
> > > > > > > explicitly fine
> > > > > > > with a somewhat non-useable system - that option is for
> > > > > > > debugging only
> > > > > > > really. If that means audio also doesn't work, then I think
> > > > > > > that's ok.
> > > > > > 
> > > > > > It's not only "it doesn't work".  The module load gets stuck.  So
> > > > > > we
> > > > > > need some notification for the blocked component binding.
> > > > > > 
> > > > > > > Adding complexity for this case (which means more error paths
> > > > > > > we don't
> > > > > > > ever test and hence _will_ break) seems over the top.
> > > > > > > 
> > > > > > > I'm quite opposed to adding error handling for every condition
> > > > > > > in general
> > > > > > > because the combinatorial testing madness just can't be
> > > > > > > handled. The one
> > > > > > > exception in the i915.ko driver is that when the render side
> > > > > > > died
> > > > > > > (terminal gpu hang) we'll try our best to keep the display
> > > > > > > alive. But
> > > > > > > that's it, and the justification for that is "we want users to
> > > > > > > be able to
> > > > 

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub

[Takashi Iwai]

On Tue, 17 May 2016 14:39:26 +0200,
Daniel Vetter wrote:
> 
> On Tue, May 17, 2016 at 02:37:49PM +0200, Daniel Vetter wrote:
> > On Tue, May 17, 2016 at 02:34:21PM +0200, Daniel Vetter wrote:
> > > On Tue, May 17, 2016 at 03:11:02PM +0300, Imre Deak wrote:
> > > > On ti, 2016-05-17 at 13:10 +0200, Daniel Vetter wrote:
> > > > > On Tue, May 17, 2016 at 01:22:52PM +0300, Imre Deak wrote:
> > > > > > On ti, 2016-05-17 at 11:59 +0200, Takashi Iwai wrote:
> > > > > > > On Tue, 17 May 2016 11:42:17 +0200,
> > > > > > > Daniel Vetter wrote:
> > > > > > > > 
> > > > > > > > On Tue, May 17, 2016 at 09:37:12AM +0200, Takashi Iwai wrote:
> > > > > > > > > On Tue, 17 May 2016 09:20:48 +0200,
> > > > > > > > > Daniel Vetter wrote:
> > > > > > > > > > 
> > > > > > > > > > On Thu, May 12, 2016 at 09:06:53PM +0300, Imre Deak wrote:
> > > > > > > > > > > User may pass nomodeset or i915.modeset=0 option to
> > > > > > > > > > > disable i915 KMS
> > > > > > > > > > > explicitly.  Although this itself works fine, it breaks
> > > > > > > > > > > the weak
> > > > > > > > > > > dependency the HD-audio driver requires, and it's the
> > > > > > > > > > > reason the
> > > > > > > > > > > delayed component binding isn't implemented in HD-
> > > > > > > > > > > audio.  Since i915
> > > > > > > > > > > doesn't notify its disablement, HD-audio would be blocked
> > > > > > > > > > > unnecessarily endlessly, waiting for the bind with i915.
> > > > > > > > > > > 
> > > > > > > > > > > This patch introduces a stub audio component binding when
> > > > > > > > > > > i915 driver
> > > > > > > > > > > is loaded with KMS off like the boot options above.  Then
> > > > > > > > > > > i915 driver
> > > > > > > > > > > still registers the slave component but with the new
> > > > > > > > > > > "disabled" ops
> > > > > > > > > > > flag, so that the master component (HD-audio) can know
> > > > > > > > > > > clearly the
> > > > > > > > > > > slave state.
> > > > > > > > > > > 
> > > > > > > > > > > v2:
> > > > > > > > > > > - Fail the probe in case component registration fails,
> > > > > > > > > > > instead of
> > > > > > > > > > >   suppressing the error. (Ville)
> > > > > > > > > > > - Register the component only for the real PCI device
> > > > > > > > > > > function.
> > > > > > > > > > > 
> > > > > > > > > > > CC: Ville Syrjälä 
> > > > > > > > > > > Signed-off-by: Imre Deak 
> > > > > > > > > > > Signed-off-by: Takashi Iwai 
> > > > > > > > > > 
> > > > > > > > > > We don't support not running with modesetting. Why do we
> > > > > > > > > > suddenly care?
> > > > > > > > > 
> > > > > > > > > This is needed for the patch 2 and 3.  Right now we have no
> > > > > > > > > blocking
> > > > > > > > > or deferred component binding, so far, in HD-audio
> > > > > > > > > side.  This caused
> > > > > > > > > problems when async module probe was done.
> > > > > > > > > 
> > > > > > > > > So, the patch 3 implements the blocking behavior of HD-audio
> > > > > > > > > side.  It
> > > > > > > > > would lead to another regression when i915 doesn't notify its
> > > > > > > > > disabled
> > > > > > > > > state by this patch.  Otherwise the HD-audio driver will be
> > > > > > > > > blocked
> > > > > > > > > endlessly of unnecessarily long.
> > > > > > > > > 
> > > > > > > > > > Same for users creating a .config that fails to boot or
> > > > > > > > > > work ...
> > > > > > > > > 
> > > > > > > > > The config isn't cared much, but the problem is about the
> > > > > > > > > runtime boot
> > > > > > > > > option.
> > > > > > > > > 
> > > > > > > > > > If HDA needs to coporate with gfx to get things done, then
> > > > > > > > > > imo we should
> > > > > > > > > > just require that i915.ko is there.
> > > > > > > > > 
> > > > > > > > > Other way round: we do already require i915 in HD-audio
> > > > > > > > > side.  But in
> > > > > > > > > this case, we do *not* want to require i915 when it's
> > > > > > > > > disabled in
> > > > > > > > > runtime. 
> > > > > > > > 
> > > > > > > > That's what I mean: If you boot with i915.nomodeset you're
> > > > > > > > explicitly fine
> > > > > > > > with a somewhat non-useable system - that option is for
> > > > > > > > debugging only
> > > > > > > > really. If that means audio also doesn't work, then I think
> > > > > > > > that's ok.
> > > > > > > 
> > > > > > > It's not only "it doesn't work".  The module load gets stuck.  So
> > > > > > > we
> > > > > > > need some notification for the blocked component binding.
> > > > > > > 
> > > > > > > > Adding complexity for this case (which means more error paths
> > > > > > > > we don't
> > > > > > > > ever test and hence _will_ break) seems over the top.
> > > > > > > > 
> > > > > > > > I'm quite opposed to adding error handling for every condition
> > > > > > > > in general
> > > > > > > > because the combinatorial testing madness just can't be
> > > > > > > > handled. The one
> > > > > > > > exception in the i915.ko 

[Intel-gfx] [PATCH v4 2/2] drm/i915: optimise i915_gem_object_map() for small objects

[Dave Gordon]

We're using this function for ringbuffers and other "small" objects, so
it's worth avoiding an extra malloc()/free() cycle if the page array is
small enough to put on the stack. Here we've chosen an arbitrary cutoff
of 32 (4k) pages, which is big enough for a ringbuffer (4 pages) or a
context image (currently up to 22 pages).

v2:
change name of local array [Chris Wilson]

Signed-off-by: Dave Gordon 
Reviewed-by: Tvrtko Ursulin 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 82a1bc4..dda7fe6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2404,7 +2404,8 @@ static void *i915_gem_object_map(const struct 
drm_i915_gem_object *obj)
unsigned long n_pages = obj->base.size >> PAGE_SHIFT;
struct sg_table *sgt = obj->pages;
struct sg_page_iter sg_iter;
-   struct page **pages;
+   struct page *stack_pages[32];
+   struct page **pages = stack_pages;
unsigned long i = 0;
void *addr;
 
@@ -2412,9 +2413,12 @@ static void *i915_gem_object_map(const struct 
drm_i915_gem_object *obj)
if (n_pages == 1)
return kmap(sg_page(sgt->sgl));
 
-   pages = drm_malloc_gfp(n_pages, sizeof(*pages), GFP_TEMPORARY);
-   if (pages == NULL)
-   return NULL;
+   if (n_pages > ARRAY_SIZE(stack_pages)) {
+   /* Too big for stack -- allocate temporary array instead */
+   pages = drm_malloc_gfp(n_pages, sizeof(*pages), GFP_TEMPORARY);
+   if (pages == NULL)
+   return NULL;
+   }
 
for_each_sg_page(sgt->sgl, _iter, sgt->nents, 0)
pages[i++] = sg_page_iter_page(_iter);
@@ -2424,7 +2428,8 @@ static void *i915_gem_object_map(const struct 
drm_i915_gem_object *obj)
 
addr = vmap(pages, n_pages, 0, PAGE_KERNEL);
 
-   drm_free_large(pages);
+   if (pages != stack_pages)
+   drm_free_large(pages);
 
return addr;
 }
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 1/2] drm/i915: refactor i915_gem_object_pin_map()

[Dave Gordon]

The recently-added i915_gem_object_pin_map() can be further optimised
for "small" objects. To facilitate this, and simplify the error paths
before adding the new code, this patch pulls out the "mapping" part of
the operation (involving local allocations which must be undone before
return) into its own subfunction.

The next patch will then insert the new optimisation into the middle of
the now-separated subfunction.

This reorganisation will probably not affect the generated code, as the
compiler will most likely inline it anyway, but it makes the logical
structure a bit clearer and easier to modify.

v2:
Restructure loop-over-pages & error check [Chris Wilson]

v3:
Add page count to debug messages [Chris Wilson]
Convert WARN_ON() to GEM_BUG_ON()

v4:
Drop the DEBUG messages [Tvrtko Ursulin]

Signed-off-by: Dave Gordon 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 54 +
 1 file changed, 33 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 24cab88..82a1bc4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2398,6 +2398,38 @@ static void i915_gem_object_free_mmap_offset(struct 
drm_i915_gem_object *obj)
return 0;
 }
 
+/* The 'mapping' part of i915_gem_object_pin_map() below */
+static void *i915_gem_object_map(const struct drm_i915_gem_object *obj)
+{
+   unsigned long n_pages = obj->base.size >> PAGE_SHIFT;
+   struct sg_table *sgt = obj->pages;
+   struct sg_page_iter sg_iter;
+   struct page **pages;
+   unsigned long i = 0;
+   void *addr;
+
+   /* A single page can always be kmapped */
+   if (n_pages == 1)
+   return kmap(sg_page(sgt->sgl));
+
+   pages = drm_malloc_gfp(n_pages, sizeof(*pages), GFP_TEMPORARY);
+   if (pages == NULL)
+   return NULL;
+
+   for_each_sg_page(sgt->sgl, _iter, sgt->nents, 0)
+   pages[i++] = sg_page_iter_page(_iter);
+
+   /* Check that we have the expected number of pages */
+   GEM_BUG_ON(i != n_pages);
+
+   addr = vmap(pages, n_pages, 0, PAGE_KERNEL);
+
+   drm_free_large(pages);
+
+   return addr;
+}
+
+/* get, pin, and map the pages of the object into kernel space */
 void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj)
 {
int ret;
@@ -2411,27 +2443,7 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object 
*obj)
i915_gem_object_pin_pages(obj);
 
if (obj->mapping == NULL) {
-   struct page **pages;
-
-   pages = NULL;
-   if (obj->base.size == PAGE_SIZE)
-   obj->mapping = kmap(sg_page(obj->pages->sgl));
-   else
-   pages = drm_malloc_gfp(obj->base.size >> PAGE_SHIFT,
-  sizeof(*pages),
-  GFP_TEMPORARY);
-   if (pages != NULL) {
-   struct sg_page_iter sg_iter;
-   int n;
-
-   n = 0;
-   for_each_sg_page(obj->pages->sgl, _iter,
-obj->pages->nents, 0)
-   pages[n++] = sg_page_iter_page(_iter);
-
-   obj->mapping = vmap(pages, n, 0, PAGE_KERNEL);
-   drm_free_large(pages);
-   }
+   obj->mapping = i915_gem_object_map(obj);
if (obj->mapping == NULL) {
i915_gem_object_unpin_pages(obj);
return ERR_PTR(-ENOMEM);
-- 
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 1/3] drm/i915/hda: Add audio component stub

[Takashi Iwai]

On Tue, 17 May 2016 14:37:49 +0200,
Daniel Vetter wrote:
> 
> On Tue, May 17, 2016 at 02:34:21PM +0200, Daniel Vetter wrote:
> > On Tue, May 17, 2016 at 03:11:02PM +0300, Imre Deak wrote:
> > > On ti, 2016-05-17 at 13:10 +0200, Daniel Vetter wrote:
> > > > On Tue, May 17, 2016 at 01:22:52PM +0300, Imre Deak wrote:
> > > > > On ti, 2016-05-17 at 11:59 +0200, Takashi Iwai wrote:
> > > > > > On Tue, 17 May 2016 11:42:17 +0200,
> > > > > > Daniel Vetter wrote:
> > > > > > > 
> > > > > > > On Tue, May 17, 2016 at 09:37:12AM +0200, Takashi Iwai wrote:
> > > > > > > > On Tue, 17 May 2016 09:20:48 +0200,
> > > > > > > > Daniel Vetter wrote:
> > > > > > > > > 
> > > > > > > > > On Thu, May 12, 2016 at 09:06:53PM +0300, Imre Deak wrote:
> > > > > > > > > > User may pass nomodeset or i915.modeset=0 option to
> > > > > > > > > > disable i915 KMS
> > > > > > > > > > explicitly.  Although this itself works fine, it breaks
> > > > > > > > > > the weak
> > > > > > > > > > dependency the HD-audio driver requires, and it's the
> > > > > > > > > > reason the
> > > > > > > > > > delayed component binding isn't implemented in HD-
> > > > > > > > > > audio.  Since i915
> > > > > > > > > > doesn't notify its disablement, HD-audio would be blocked
> > > > > > > > > > unnecessarily endlessly, waiting for the bind with i915.
> > > > > > > > > > 
> > > > > > > > > > This patch introduces a stub audio component binding when
> > > > > > > > > > i915 driver
> > > > > > > > > > is loaded with KMS off like the boot options above.  Then
> > > > > > > > > > i915 driver
> > > > > > > > > > still registers the slave component but with the new
> > > > > > > > > > "disabled" ops
> > > > > > > > > > flag, so that the master component (HD-audio) can know
> > > > > > > > > > clearly the
> > > > > > > > > > slave state.
> > > > > > > > > > 
> > > > > > > > > > v2:
> > > > > > > > > > - Fail the probe in case component registration fails,
> > > > > > > > > > instead of
> > > > > > > > > >   suppressing the error. (Ville)
> > > > > > > > > > - Register the component only for the real PCI device
> > > > > > > > > > function.
> > > > > > > > > > 
> > > > > > > > > > CC: Ville Syrjälä 
> > > > > > > > > > Signed-off-by: Imre Deak 
> > > > > > > > > > Signed-off-by: Takashi Iwai 
> > > > > > > > > 
> > > > > > > > > We don't support not running with modesetting. Why do we
> > > > > > > > > suddenly care?
> > > > > > > > 
> > > > > > > > This is needed for the patch 2 and 3.  Right now we have no
> > > > > > > > blocking
> > > > > > > > or deferred component binding, so far, in HD-audio
> > > > > > > > side.  This caused
> > > > > > > > problems when async module probe was done.
> > > > > > > > 
> > > > > > > > So, the patch 3 implements the blocking behavior of HD-audio
> > > > > > > > side.  It
> > > > > > > > would lead to another regression when i915 doesn't notify its
> > > > > > > > disabled
> > > > > > > > state by this patch.  Otherwise the HD-audio driver will be
> > > > > > > > blocked
> > > > > > > > endlessly of unnecessarily long.
> > > > > > > > 
> > > > > > > > > Same for users creating a .config that fails to boot or
> > > > > > > > > work ...
> > > > > > > > 
> > > > > > > > The config isn't cared much, but the problem is about the
> > > > > > > > runtime boot
> > > > > > > > option.
> > > > > > > > 
> > > > > > > > > If HDA needs to coporate with gfx to get things done, then
> > > > > > > > > imo we should
> > > > > > > > > just require that i915.ko is there.
> > > > > > > > 
> > > > > > > > Other way round: we do already require i915 in HD-audio
> > > > > > > > side.  But in
> > > > > > > > this case, we do *not* want to require i915 when it's
> > > > > > > > disabled in
> > > > > > > > runtime. 
> > > > > > > 
> > > > > > > That's what I mean: If you boot with i915.nomodeset you're
> > > > > > > explicitly fine
> > > > > > > with a somewhat non-useable system - that option is for
> > > > > > > debugging only
> > > > > > > really. If that means audio also doesn't work, then I think
> > > > > > > that's ok.
> > > > > > 
> > > > > > It's not only "it doesn't work".  The module load gets stuck.  So
> > > > > > we
> > > > > > need some notification for the blocked component binding.
> > > > > > 
> > > > > > > Adding complexity for this case (which means more error paths
> > > > > > > we don't
> > > > > > > ever test and hence _will_ break) seems over the top.
> > > > > > > 
> > > > > > > I'm quite opposed to adding error handling for every condition
> > > > > > > in general
> > > > > > > because the combinatorial testing madness just can't be
> > > > > > > handled. The one
> > > > > > > exception in the i915.ko driver is that when the render side
> > > > > > > died
> > > > > > > (terminal gpu hang) we'll try our best to keep the display
> > > > > > > alive. But
> > > > > > > that's it, and the justification for that is "we want users to
> > > > > > > be able to
> > > > > > 

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub

[Takashi Iwai]

On Tue, 17 May 2016 14:34:21 +0200,
Daniel Vetter wrote:
> 
> On Tue, May 17, 2016 at 03:11:02PM +0300, Imre Deak wrote:
> > On ti, 2016-05-17 at 13:10 +0200, Daniel Vetter wrote:
> > > On Tue, May 17, 2016 at 01:22:52PM +0300, Imre Deak wrote:
> > > > On ti, 2016-05-17 at 11:59 +0200, Takashi Iwai wrote:
> > > > > On Tue, 17 May 2016 11:42:17 +0200,
> > > > > Daniel Vetter wrote:
> > > > > > 
> > > > > > On Tue, May 17, 2016 at 09:37:12AM +0200, Takashi Iwai wrote:
> > > > > > > On Tue, 17 May 2016 09:20:48 +0200,
> > > > > > > Daniel Vetter wrote:
> > > > > > > > 
> > > > > > > > On Thu, May 12, 2016 at 09:06:53PM +0300, Imre Deak wrote:
> > > > > > > > > User may pass nomodeset or i915.modeset=0 option to
> > > > > > > > > disable i915 KMS
> > > > > > > > > explicitly.  Although this itself works fine, it breaks
> > > > > > > > > the weak
> > > > > > > > > dependency the HD-audio driver requires, and it's the
> > > > > > > > > reason the
> > > > > > > > > delayed component binding isn't implemented in HD-
> > > > > > > > > audio.  Since i915
> > > > > > > > > doesn't notify its disablement, HD-audio would be blocked
> > > > > > > > > unnecessarily endlessly, waiting for the bind with i915.
> > > > > > > > > 
> > > > > > > > > This patch introduces a stub audio component binding when
> > > > > > > > > i915 driver
> > > > > > > > > is loaded with KMS off like the boot options above.  Then
> > > > > > > > > i915 driver
> > > > > > > > > still registers the slave component but with the new
> > > > > > > > > "disabled" ops
> > > > > > > > > flag, so that the master component (HD-audio) can know
> > > > > > > > > clearly the
> > > > > > > > > slave state.
> > > > > > > > > 
> > > > > > > > > v2:
> > > > > > > > > - Fail the probe in case component registration fails,
> > > > > > > > > instead of
> > > > > > > > >   suppressing the error. (Ville)
> > > > > > > > > - Register the component only for the real PCI device
> > > > > > > > > function.
> > > > > > > > > 
> > > > > > > > > CC: Ville Syrjälä 
> > > > > > > > > Signed-off-by: Imre Deak 
> > > > > > > > > Signed-off-by: Takashi Iwai 
> > > > > > > > 
> > > > > > > > We don't support not running with modesetting. Why do we
> > > > > > > > suddenly care?
> > > > > > > 
> > > > > > > This is needed for the patch 2 and 3.  Right now we have no
> > > > > > > blocking
> > > > > > > or deferred component binding, so far, in HD-audio
> > > > > > > side.  This caused
> > > > > > > problems when async module probe was done.
> > > > > > > 
> > > > > > > So, the patch 3 implements the blocking behavior of HD-audio
> > > > > > > side.  It
> > > > > > > would lead to another regression when i915 doesn't notify its
> > > > > > > disabled
> > > > > > > state by this patch.  Otherwise the HD-audio driver will be
> > > > > > > blocked
> > > > > > > endlessly of unnecessarily long.
> > > > > > > 
> > > > > > > > Same for users creating a .config that fails to boot or
> > > > > > > > work ...
> > > > > > > 
> > > > > > > The config isn't cared much, but the problem is about the
> > > > > > > runtime boot
> > > > > > > option.
> > > > > > > 
> > > > > > > > If HDA needs to coporate with gfx to get things done, then
> > > > > > > > imo we should
> > > > > > > > just require that i915.ko is there.
> > > > > > > 
> > > > > > > Other way round: we do already require i915 in HD-audio
> > > > > > > side.  But in
> > > > > > > this case, we do *not* want to require i915 when it's
> > > > > > > disabled in
> > > > > > > runtime. 
> > > > > > 
> > > > > > That's what I mean: If you boot with i915.nomodeset you're
> > > > > > explicitly fine
> > > > > > with a somewhat non-useable system - that option is for
> > > > > > debugging only
> > > > > > really. If that means audio also doesn't work, then I think
> > > > > > that's ok.
> > > > > 
> > > > > It's not only "it doesn't work".  The module load gets stuck.  So
> > > > > we
> > > > > need some notification for the blocked component binding.
> > > > > 
> > > > > > Adding complexity for this case (which means more error paths
> > > > > > we don't
> > > > > > ever test and hence _will_ break) seems over the top.
> > > > > > 
> > > > > > I'm quite opposed to adding error handling for every condition
> > > > > > in general
> > > > > > because the combinatorial testing madness just can't be
> > > > > > handled. The one
> > > > > > exception in the i915.ko driver is that when the render side
> > > > > > died
> > > > > > (terminal gpu hang) we'll try our best to keep the display
> > > > > > alive. But
> > > > > > that's it, and the justification for that is "we want users to
> > > > > > be able to
> > > > > > get the bug report out". I don't see a justification of that
> > > > > > magnitude for
> > > > > > this feature here at all.
> > > > > 
> > > > > Well, actually the patchset was proposed just because Intel CI
> > > > > tests
> > > > > failed due to async module probes.  

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub

[Daniel Vetter]

On Tue, May 17, 2016 at 02:37:49PM +0200, Daniel Vetter wrote:
> On Tue, May 17, 2016 at 02:34:21PM +0200, Daniel Vetter wrote:
> > On Tue, May 17, 2016 at 03:11:02PM +0300, Imre Deak wrote:
> > > On ti, 2016-05-17 at 13:10 +0200, Daniel Vetter wrote:
> > > > On Tue, May 17, 2016 at 01:22:52PM +0300, Imre Deak wrote:
> > > > > On ti, 2016-05-17 at 11:59 +0200, Takashi Iwai wrote:
> > > > > > On Tue, 17 May 2016 11:42:17 +0200,
> > > > > > Daniel Vetter wrote:
> > > > > > > 
> > > > > > > On Tue, May 17, 2016 at 09:37:12AM +0200, Takashi Iwai wrote:
> > > > > > > > On Tue, 17 May 2016 09:20:48 +0200,
> > > > > > > > Daniel Vetter wrote:
> > > > > > > > > 
> > > > > > > > > On Thu, May 12, 2016 at 09:06:53PM +0300, Imre Deak wrote:
> > > > > > > > > > User may pass nomodeset or i915.modeset=0 option to
> > > > > > > > > > disable i915 KMS
> > > > > > > > > > explicitly.  Although this itself works fine, it breaks
> > > > > > > > > > the weak
> > > > > > > > > > dependency the HD-audio driver requires, and it's the
> > > > > > > > > > reason the
> > > > > > > > > > delayed component binding isn't implemented in HD-
> > > > > > > > > > audio.  Since i915
> > > > > > > > > > doesn't notify its disablement, HD-audio would be blocked
> > > > > > > > > > unnecessarily endlessly, waiting for the bind with i915.
> > > > > > > > > > 
> > > > > > > > > > This patch introduces a stub audio component binding when
> > > > > > > > > > i915 driver
> > > > > > > > > > is loaded with KMS off like the boot options above.  Then
> > > > > > > > > > i915 driver
> > > > > > > > > > still registers the slave component but with the new
> > > > > > > > > > "disabled" ops
> > > > > > > > > > flag, so that the master component (HD-audio) can know
> > > > > > > > > > clearly the
> > > > > > > > > > slave state.
> > > > > > > > > > 
> > > > > > > > > > v2:
> > > > > > > > > > - Fail the probe in case component registration fails,
> > > > > > > > > > instead of
> > > > > > > > > >   suppressing the error. (Ville)
> > > > > > > > > > - Register the component only for the real PCI device
> > > > > > > > > > function.
> > > > > > > > > > 
> > > > > > > > > > CC: Ville Syrjälä 
> > > > > > > > > > Signed-off-by: Imre Deak 
> > > > > > > > > > Signed-off-by: Takashi Iwai 
> > > > > > > > > 
> > > > > > > > > We don't support not running with modesetting. Why do we
> > > > > > > > > suddenly care?
> > > > > > > > 
> > > > > > > > This is needed for the patch 2 and 3.  Right now we have no
> > > > > > > > blocking
> > > > > > > > or deferred component binding, so far, in HD-audio
> > > > > > > > side.  This caused
> > > > > > > > problems when async module probe was done.
> > > > > > > > 
> > > > > > > > So, the patch 3 implements the blocking behavior of HD-audio
> > > > > > > > side.  It
> > > > > > > > would lead to another regression when i915 doesn't notify its
> > > > > > > > disabled
> > > > > > > > state by this patch.  Otherwise the HD-audio driver will be
> > > > > > > > blocked
> > > > > > > > endlessly of unnecessarily long.
> > > > > > > > 
> > > > > > > > > Same for users creating a .config that fails to boot or
> > > > > > > > > work ...
> > > > > > > > 
> > > > > > > > The config isn't cared much, but the problem is about the
> > > > > > > > runtime boot
> > > > > > > > option.
> > > > > > > > 
> > > > > > > > > If HDA needs to coporate with gfx to get things done, then
> > > > > > > > > imo we should
> > > > > > > > > just require that i915.ko is there.
> > > > > > > > 
> > > > > > > > Other way round: we do already require i915 in HD-audio
> > > > > > > > side.  But in
> > > > > > > > this case, we do *not* want to require i915 when it's
> > > > > > > > disabled in
> > > > > > > > runtime. 
> > > > > > > 
> > > > > > > That's what I mean: If you boot with i915.nomodeset you're
> > > > > > > explicitly fine
> > > > > > > with a somewhat non-useable system - that option is for
> > > > > > > debugging only
> > > > > > > really. If that means audio also doesn't work, then I think
> > > > > > > that's ok.
> > > > > > 
> > > > > > It's not only "it doesn't work".  The module load gets stuck.  So
> > > > > > we
> > > > > > need some notification for the blocked component binding.
> > > > > > 
> > > > > > > Adding complexity for this case (which means more error paths
> > > > > > > we don't
> > > > > > > ever test and hence _will_ break) seems over the top.
> > > > > > > 
> > > > > > > I'm quite opposed to adding error handling for every condition
> > > > > > > in general
> > > > > > > because the combinatorial testing madness just can't be
> > > > > > > handled. The one
> > > > > > > exception in the i915.ko driver is that when the render side
> > > > > > > died
> > > > > > > (terminal gpu hang) we'll try our best to keep the display
> > > > > > > alive. But
> > > > > > > that's it, and the justification for that is "we want users to
> > > > > > > be able to
> > > > 

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub

[Daniel Vetter]

On Tue, May 17, 2016 at 02:34:21PM +0200, Daniel Vetter wrote:
> On Tue, May 17, 2016 at 03:11:02PM +0300, Imre Deak wrote:
> > On ti, 2016-05-17 at 13:10 +0200, Daniel Vetter wrote:
> > > On Tue, May 17, 2016 at 01:22:52PM +0300, Imre Deak wrote:
> > > > On ti, 2016-05-17 at 11:59 +0200, Takashi Iwai wrote:
> > > > > On Tue, 17 May 2016 11:42:17 +0200,
> > > > > Daniel Vetter wrote:
> > > > > > 
> > > > > > On Tue, May 17, 2016 at 09:37:12AM +0200, Takashi Iwai wrote:
> > > > > > > On Tue, 17 May 2016 09:20:48 +0200,
> > > > > > > Daniel Vetter wrote:
> > > > > > > > 
> > > > > > > > On Thu, May 12, 2016 at 09:06:53PM +0300, Imre Deak wrote:
> > > > > > > > > User may pass nomodeset or i915.modeset=0 option to
> > > > > > > > > disable i915 KMS
> > > > > > > > > explicitly.  Although this itself works fine, it breaks
> > > > > > > > > the weak
> > > > > > > > > dependency the HD-audio driver requires, and it's the
> > > > > > > > > reason the
> > > > > > > > > delayed component binding isn't implemented in HD-
> > > > > > > > > audio.  Since i915
> > > > > > > > > doesn't notify its disablement, HD-audio would be blocked
> > > > > > > > > unnecessarily endlessly, waiting for the bind with i915.
> > > > > > > > > 
> > > > > > > > > This patch introduces a stub audio component binding when
> > > > > > > > > i915 driver
> > > > > > > > > is loaded with KMS off like the boot options above.  Then
> > > > > > > > > i915 driver
> > > > > > > > > still registers the slave component but with the new
> > > > > > > > > "disabled" ops
> > > > > > > > > flag, so that the master component (HD-audio) can know
> > > > > > > > > clearly the
> > > > > > > > > slave state.
> > > > > > > > > 
> > > > > > > > > v2:
> > > > > > > > > - Fail the probe in case component registration fails,
> > > > > > > > > instead of
> > > > > > > > >   suppressing the error. (Ville)
> > > > > > > > > - Register the component only for the real PCI device
> > > > > > > > > function.
> > > > > > > > > 
> > > > > > > > > CC: Ville Syrjälä 
> > > > > > > > > Signed-off-by: Imre Deak 
> > > > > > > > > Signed-off-by: Takashi Iwai 
> > > > > > > > 
> > > > > > > > We don't support not running with modesetting. Why do we
> > > > > > > > suddenly care?
> > > > > > > 
> > > > > > > This is needed for the patch 2 and 3.  Right now we have no
> > > > > > > blocking
> > > > > > > or deferred component binding, so far, in HD-audio
> > > > > > > side.  This caused
> > > > > > > problems when async module probe was done.
> > > > > > > 
> > > > > > > So, the patch 3 implements the blocking behavior of HD-audio
> > > > > > > side.  It
> > > > > > > would lead to another regression when i915 doesn't notify its
> > > > > > > disabled
> > > > > > > state by this patch.  Otherwise the HD-audio driver will be
> > > > > > > blocked
> > > > > > > endlessly of unnecessarily long.
> > > > > > > 
> > > > > > > > Same for users creating a .config that fails to boot or
> > > > > > > > work ...
> > > > > > > 
> > > > > > > The config isn't cared much, but the problem is about the
> > > > > > > runtime boot
> > > > > > > option.
> > > > > > > 
> > > > > > > > If HDA needs to coporate with gfx to get things done, then
> > > > > > > > imo we should
> > > > > > > > just require that i915.ko is there.
> > > > > > > 
> > > > > > > Other way round: we do already require i915 in HD-audio
> > > > > > > side.  But in
> > > > > > > this case, we do *not* want to require i915 when it's
> > > > > > > disabled in
> > > > > > > runtime. 
> > > > > > 
> > > > > > That's what I mean: If you boot with i915.nomodeset you're
> > > > > > explicitly fine
> > > > > > with a somewhat non-useable system - that option is for
> > > > > > debugging only
> > > > > > really. If that means audio also doesn't work, then I think
> > > > > > that's ok.
> > > > > 
> > > > > It's not only "it doesn't work".  The module load gets stuck.  So
> > > > > we
> > > > > need some notification for the blocked component binding.
> > > > > 
> > > > > > Adding complexity for this case (which means more error paths
> > > > > > we don't
> > > > > > ever test and hence _will_ break) seems over the top.
> > > > > > 
> > > > > > I'm quite opposed to adding error handling for every condition
> > > > > > in general
> > > > > > because the combinatorial testing madness just can't be
> > > > > > handled. The one
> > > > > > exception in the i915.ko driver is that when the render side
> > > > > > died
> > > > > > (terminal gpu hang) we'll try our best to keep the display
> > > > > > alive. But
> > > > > > that's it, and the justification for that is "we want users to
> > > > > > be able to
> > > > > > get the bug report out". I don't see a justification of that
> > > > > > magnitude for
> > > > > > this feature here at all.
> > > > > 
> > > > > Well, actually the patchset was proposed just because Intel CI
> > > > > tests
> > > > > failed due to async module 

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub

[Daniel Vetter]

On Tue, May 17, 2016 at 03:11:02PM +0300, Imre Deak wrote:
> On ti, 2016-05-17 at 13:10 +0200, Daniel Vetter wrote:
> > On Tue, May 17, 2016 at 01:22:52PM +0300, Imre Deak wrote:
> > > On ti, 2016-05-17 at 11:59 +0200, Takashi Iwai wrote:
> > > > On Tue, 17 May 2016 11:42:17 +0200,
> > > > Daniel Vetter wrote:
> > > > > 
> > > > > On Tue, May 17, 2016 at 09:37:12AM +0200, Takashi Iwai wrote:
> > > > > > On Tue, 17 May 2016 09:20:48 +0200,
> > > > > > Daniel Vetter wrote:
> > > > > > > 
> > > > > > > On Thu, May 12, 2016 at 09:06:53PM +0300, Imre Deak wrote:
> > > > > > > > User may pass nomodeset or i915.modeset=0 option to
> > > > > > > > disable i915 KMS
> > > > > > > > explicitly.  Although this itself works fine, it breaks
> > > > > > > > the weak
> > > > > > > > dependency the HD-audio driver requires, and it's the
> > > > > > > > reason the
> > > > > > > > delayed component binding isn't implemented in HD-
> > > > > > > > audio.  Since i915
> > > > > > > > doesn't notify its disablement, HD-audio would be blocked
> > > > > > > > unnecessarily endlessly, waiting for the bind with i915.
> > > > > > > > 
> > > > > > > > This patch introduces a stub audio component binding when
> > > > > > > > i915 driver
> > > > > > > > is loaded with KMS off like the boot options above.  Then
> > > > > > > > i915 driver
> > > > > > > > still registers the slave component but with the new
> > > > > > > > "disabled" ops
> > > > > > > > flag, so that the master component (HD-audio) can know
> > > > > > > > clearly the
> > > > > > > > slave state.
> > > > > > > > 
> > > > > > > > v2:
> > > > > > > > - Fail the probe in case component registration fails,
> > > > > > > > instead of
> > > > > > > >   suppressing the error. (Ville)
> > > > > > > > - Register the component only for the real PCI device
> > > > > > > > function.
> > > > > > > > 
> > > > > > > > CC: Ville Syrjälä 
> > > > > > > > Signed-off-by: Imre Deak 
> > > > > > > > Signed-off-by: Takashi Iwai 
> > > > > > > 
> > > > > > > We don't support not running with modesetting. Why do we
> > > > > > > suddenly care?
> > > > > > 
> > > > > > This is needed for the patch 2 and 3.  Right now we have no
> > > > > > blocking
> > > > > > or deferred component binding, so far, in HD-audio
> > > > > > side.  This caused
> > > > > > problems when async module probe was done.
> > > > > > 
> > > > > > So, the patch 3 implements the blocking behavior of HD-audio
> > > > > > side.  It
> > > > > > would lead to another regression when i915 doesn't notify its
> > > > > > disabled
> > > > > > state by this patch.  Otherwise the HD-audio driver will be
> > > > > > blocked
> > > > > > endlessly of unnecessarily long.
> > > > > > 
> > > > > > > Same for users creating a .config that fails to boot or
> > > > > > > work ...
> > > > > > 
> > > > > > The config isn't cared much, but the problem is about the
> > > > > > runtime boot
> > > > > > option.
> > > > > > 
> > > > > > > If HDA needs to coporate with gfx to get things done, then
> > > > > > > imo we should
> > > > > > > just require that i915.ko is there.
> > > > > > 
> > > > > > Other way round: we do already require i915 in HD-audio
> > > > > > side.  But in
> > > > > > this case, we do *not* want to require i915 when it's
> > > > > > disabled in
> > > > > > runtime. 
> > > > > 
> > > > > That's what I mean: If you boot with i915.nomodeset you're
> > > > > explicitly fine
> > > > > with a somewhat non-useable system - that option is for
> > > > > debugging only
> > > > > really. If that means audio also doesn't work, then I think
> > > > > that's ok.
> > > > 
> > > > It's not only "it doesn't work".  The module load gets stuck.  So
> > > > we
> > > > need some notification for the blocked component binding.
> > > > 
> > > > > Adding complexity for this case (which means more error paths
> > > > > we don't
> > > > > ever test and hence _will_ break) seems over the top.
> > > > > 
> > > > > I'm quite opposed to adding error handling for every condition
> > > > > in general
> > > > > because the combinatorial testing madness just can't be
> > > > > handled. The one
> > > > > exception in the i915.ko driver is that when the render side
> > > > > died
> > > > > (terminal gpu hang) we'll try our best to keep the display
> > > > > alive. But
> > > > > that's it, and the justification for that is "we want users to
> > > > > be able to
> > > > > get the bug report out". I don't see a justification of that
> > > > > magnitude for
> > > > > this feature here at all.
> > > > 
> > > > Well, actually the patchset was proposed just because Intel CI
> > > > tests
> > > > failed due to async module probes.  If Intel is happy with
> > > > continued
> > > > CI test failures, I'm also happy with the current situation ;)
> > > 
> > > It's not only due to those particular failures. That was caused by
> > > a
> > > kmod bug and as such would be good to not depend on that mechanism.
> > > 

Re: [Intel-gfx] [PATCH 0/6] Move dpio access out of intel_display.c

[Daniel Vetter]

On Fri, May 13, 2016 at 05:14:57PM +0300, Ander Conselvan de Oliveira wrote:
> Hi,
> 
> This series moves all of the calls to vlv_dpio_{read,write} to
> intel_dpio_phy.c. I think it simplifies the surrounding code a bit.

You still owe us all the kerneldoc for the intel_dpll_mgr.c extraction. I
think better to complete one extraction before starting the next one,
resulting in an even bigger mess than what we had before.
-Daniel

> 
> Thanks,
> Ander
> 
> Ander Conselvan de Oliveira (6):
>   drm/i915: Rename struct dpll to struct intel_dpll
>   drm/i915: Move dpio code of VLV/CHV dpll enabling to intel_dpio_phy.c
>   drm/i915: Merge vlv/chv _prepare_pll() with their enable counterpart
>   drm/i915: Move VLV divider readout to intel_dpio_phy.c
>   drm/i915: Move CHV divider readout to intel_dpio_phy.c
>   drm/i915: Move toggling of CHV DPIO_DCLKP_EN to intel_dpio_phy.c
> 
>  drivers/gpu/drm/i915/i915_drv.h   |  14 +-
>  drivers/gpu/drm/i915/intel_ddi.c  |   2 +-
>  drivers/gpu/drm/i915/intel_display.c  | 395 
> ++
>  drivers/gpu/drm/i915/intel_dp.c   |   2 +-
>  drivers/gpu/drm/i915/intel_dpio_phy.c | 260 ++
>  drivers/gpu/drm/i915/intel_dpll_mgr.c |   2 +-
>  drivers/gpu/drm/i915/intel_drv.h  |  10 +-
>  drivers/gpu/drm/i915/intel_sdvo.c |   2 +-
>  8 files changed, 350 insertions(+), 337 deletions(-)
> 
> -- 
> 2.5.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v2] autotools/: Allow building tests/gem_concurrent_{all, blit}

[Gabriel Feceoru]

On 17.05.2016 13:02, Daniel Vetter wrote:

On Mon, May 16, 2016 at 06:09:27PM +0300, Marius Vlad wrote:

Trivial. Pushed.

On Mon, May 16, 2016 at 01:36:48PM +0300, Marius Vlad wrote:

Introduced by a633ad03c6 (tests: Separate tests with lots of subtests).

v2: Fix commit typo (Jani Nikula).

Signed-off-by: Marius Vlad 


Also review from my side on the offending original commit was ignored -
imo gem_concurrent_all should just be put into EXTRA, and
gem_concurrent_blit should be kept in the normal igt set of testcases.

Dropping gem_concurrent_blit from the list of tests means we have a
massive gap in coverage. If that one still has too many subtests we need
to filter them harder, but that's a different problem.


gem_concurrent_all can still be tested, using test-list-full.txt instead.
Now, piglit igt profile has hardcoded "test-list.txt" (plus 
"single-tests.txt" and "multi-tests.txt" - which I guess are history).
We can specify which test list to use with a change in piglit (by 
redefining IGT_TEST_ROOT or another var).
Alternatively test-list.txt can be replaced with test-list-full.txt (or 
symlink).


Regards,
Gabriel.



Also pls run $ make distcheck before pushing stuf ...
-Daniel


---
  tests/Makefile.am | 1 +
  1 file changed, 1 insertion(+)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 32b9115..c2c2025 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -30,6 +30,7 @@ pkglibexec_PROGRAMS = \
gem_stress \
$(TESTS_progs) \
$(TESTS_progs_M) \
+   $(TESTS_progs_XM) \
$(NULL)

  dist_pkglibexec_SCRIPTS = \
--
2.8.0.rc3

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





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




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

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub

[Imre Deak]

On ti, 2016-05-17 at 13:10 +0200, Daniel Vetter wrote:
> On Tue, May 17, 2016 at 01:22:52PM +0300, Imre Deak wrote:
> > On ti, 2016-05-17 at 11:59 +0200, Takashi Iwai wrote:
> > > On Tue, 17 May 2016 11:42:17 +0200,
> > > Daniel Vetter wrote:
> > > > 
> > > > On Tue, May 17, 2016 at 09:37:12AM +0200, Takashi Iwai wrote:
> > > > > On Tue, 17 May 2016 09:20:48 +0200,
> > > > > Daniel Vetter wrote:
> > > > > > 
> > > > > > On Thu, May 12, 2016 at 09:06:53PM +0300, Imre Deak wrote:
> > > > > > > User may pass nomodeset or i915.modeset=0 option to
> > > > > > > disable i915 KMS
> > > > > > > explicitly.  Although this itself works fine, it breaks
> > > > > > > the weak
> > > > > > > dependency the HD-audio driver requires, and it's the
> > > > > > > reason the
> > > > > > > delayed component binding isn't implemented in HD-
> > > > > > > audio.  Since i915
> > > > > > > doesn't notify its disablement, HD-audio would be blocked
> > > > > > > unnecessarily endlessly, waiting for the bind with i915.
> > > > > > > 
> > > > > > > This patch introduces a stub audio component binding when
> > > > > > > i915 driver
> > > > > > > is loaded with KMS off like the boot options above.  Then
> > > > > > > i915 driver
> > > > > > > still registers the slave component but with the new
> > > > > > > "disabled" ops
> > > > > > > flag, so that the master component (HD-audio) can know
> > > > > > > clearly the
> > > > > > > slave state.
> > > > > > > 
> > > > > > > v2:
> > > > > > > - Fail the probe in case component registration fails,
> > > > > > > instead of
> > > > > > >   suppressing the error. (Ville)
> > > > > > > - Register the component only for the real PCI device
> > > > > > > function.
> > > > > > > 
> > > > > > > CC: Ville Syrjälä 
> > > > > > > Signed-off-by: Imre Deak 
> > > > > > > Signed-off-by: Takashi Iwai 
> > > > > > 
> > > > > > We don't support not running with modesetting. Why do we
> > > > > > suddenly care?
> > > > > 
> > > > > This is needed for the patch 2 and 3.  Right now we have no
> > > > > blocking
> > > > > or deferred component binding, so far, in HD-audio
> > > > > side.  This caused
> > > > > problems when async module probe was done.
> > > > > 
> > > > > So, the patch 3 implements the blocking behavior of HD-audio
> > > > > side.  It
> > > > > would lead to another regression when i915 doesn't notify its
> > > > > disabled
> > > > > state by this patch.  Otherwise the HD-audio driver will be
> > > > > blocked
> > > > > endlessly of unnecessarily long.
> > > > > 
> > > > > > Same for users creating a .config that fails to boot or
> > > > > > work ...
> > > > > 
> > > > > The config isn't cared much, but the problem is about the
> > > > > runtime boot
> > > > > option.
> > > > > 
> > > > > > If HDA needs to coporate with gfx to get things done, then
> > > > > > imo we should
> > > > > > just require that i915.ko is there.
> > > > > 
> > > > > Other way round: we do already require i915 in HD-audio
> > > > > side.  But in
> > > > > this case, we do *not* want to require i915 when it's
> > > > > disabled in
> > > > > runtime. 
> > > > 
> > > > That's what I mean: If you boot with i915.nomodeset you're
> > > > explicitly fine
> > > > with a somewhat non-useable system - that option is for
> > > > debugging only
> > > > really. If that means audio also doesn't work, then I think
> > > > that's ok.
> > > 
> > > It's not only "it doesn't work".  The module load gets stuck.  So
> > > we
> > > need some notification for the blocked component binding.
> > > 
> > > > Adding complexity for this case (which means more error paths
> > > > we don't
> > > > ever test and hence _will_ break) seems over the top.
> > > > 
> > > > I'm quite opposed to adding error handling for every condition
> > > > in general
> > > > because the combinatorial testing madness just can't be
> > > > handled. The one
> > > > exception in the i915.ko driver is that when the render side
> > > > died
> > > > (terminal gpu hang) we'll try our best to keep the display
> > > > alive. But
> > > > that's it, and the justification for that is "we want users to
> > > > be able to
> > > > get the bug report out". I don't see a justification of that
> > > > magnitude for
> > > > this feature here at all.
> > > 
> > > Well, actually the patchset was proposed just because Intel CI
> > > tests
> > > failed due to async module probes.  If Intel is happy with
> > > continued
> > > CI test failures, I'm also happy with the current situation ;)
> > 
> > It's not only due to those particular failures. That was caused by
> > a
> > kmod bug and as such would be good to not depend on that mechanism.
> > But
> > things will fail atm even in the normal case when audio is built-in 
> > and
> > i915 is a module. This patchset would solve that too.
> 
> I'm not against patch 3 from this series, which seems to be the
> bugfix we
> want. I'm against the kludge in patch 1 here only (and maybe 

[Intel-gfx] [PATCH i-g-t] autotools/: Keep gem_concurrent_blit in tests/ and put gem_conccurent_all in EXTRAS.

[Marius Vlad]

An attempt to have piglit not taking too much time when listing tests,
but also keep tests/gem_concurrent_blit into list of tests.

This was added in a633ad03c6 (tests: Separate tests with lots of subtests) and
tried to be fixed c785a89ee (autotools/: Allow building
tests/gem_concurrent_{all, blit}) but without addressing the
comments of the reviewer. While at it, remove tests-lists-full.txt as it not
needed anymore.

https://lists.freedesktop.org/archives/intel-gfx/2016-April/092795.html

Signed-off-by: Marius Vlad 
---
 tests/Makefile.am  | 15 +--
 tests/Makefile.sources | 17 ++---
 2 files changed, 7 insertions(+), 25 deletions(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index c2c2025..359d911 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -14,11 +14,6 @@ test-list.txt: Makefile.sources
@echo ${single_kernel_tests} ${multi_kernel_tests} >> $@
@echo END TESTLIST >> $@
 
-test-list-full.txt: Makefile.sources
-   @echo TESTLIST > $@
-   @echo ${single_kernel_tests} ${multi_kernel_tests} 
${extra_multi_kernel_tests} >> $@
-   @echo END TESTLIST >> $@
-
 
 noinst_PROGRAMS = \
$(HANG) \
@@ -28,9 +23,9 @@ noinst_PROGRAMS = \
 pkglibexec_PROGRAMS = \
gem_alive \
gem_stress \
+   gem_concurrent_all \
$(TESTS_progs) \
$(TESTS_progs_M) \
-   $(TESTS_progs_XM) \
$(NULL)
 
 dist_pkglibexec_SCRIPTS = \
@@ -45,14 +40,14 @@ dist_pkgdata_DATA = \
 
 all-local: .gitignore
 .gitignore: Makefile.sources
-   @echo "$(pkglibexec_PROGRAMS) $(HANG) test-list.txt test-list-full.txt 
.gitignore" | sed 's/\s\+/\n/g' | sort > $@
+   @echo "$(pkglibexec_PROGRAMS) $(HANG) test-list.txt .gitignore" | sed 
's/\s\+/\n/g' | sort > $@
 
-pkgdata_DATA = test-list.txt test-list-full.txt
+pkgdata_DATA = test-list.txt
 
-EXTRA_PROGRAMS = $(HANG)
+EXTRA_PROGRAMS = $(HANG) gem_concurrent_all
 EXTRA_DIST = $(common_files)
 
-CLEANFILES = $(EXTRA_PROGRAMS) test-list.txt test-list-full.txt .gitignore
+CLEANFILES = $(EXTRA_PROGRAMS) test-list.txt .gitignore
 
 AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) $(DEBUG_CFLAGS)\
-I$(srcdir)/.. \
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 7b5f316..22dbaca 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -22,6 +22,7 @@ TESTS_progs_M = \
gem_close_race \
gem_create \
gem_cs_tlb \
+   gem_concurrent_blit \
gem_ctx_bad_exec \
gem_ctx_exec \
gem_ctx_param \
@@ -118,11 +119,6 @@ TESTS_progs_M = \
template \
$(NULL)
 
-TESTS_progs_XM = \
-gem_concurrent_blit \
-gem_concurrent_all \
-$(NULL)
-
 TESTS_progs = \
core_auth \
core_getclient \
@@ -226,14 +222,6 @@ multi_kernel_tests = \
$(NULL)
 
 
-# This target contains testcases with lots of subtests.
-# It was split from multi_kernel_tests because of the overhead of listing all
-# the subtests in piglit
-extra_multi_kernel_tests = \
-   $(TESTS_progs_XM) \
-   $(NULL)
-
-
 # This target is for simple testcase which don't expose any subtest.
 #
 # Your testcase should probably use igt_simple_main, but none of the other 
magic
@@ -251,8 +239,7 @@ kernel_tests = \
 kernel_tests_full = \
 $(single_kernel_tests) \
 $(multi_kernel_tests) \
-   $(extra_multi_kernel_tests) \
-   $(NULL)
+$(NULL)
 
 # Test that exercise specific asserts in the test framework library and are
 # hence expected to fail.
-- 
2.8.0.rc3

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

[Intel-gfx] [PATCH i-g-t] tests: Moved gem_concurrent_blit back to the normal set

[Gabriel Feceoru]

Repairing the damage I caused not reading properly Daniel's comment in:
https://patchwork.freedesktop.org/patch/81600/

Leaving gem_concurrent_all only in the EXTRA set

Cc: Daniel Vetter 
Cc: Marius Vlad 
Signed-off-by: Gabriel Feceoru 
---
 tests/Makefile.sources | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 7b5f316..81d0a55 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -20,6 +20,7 @@ TESTS_progs_M = \
gem_busy \
gem_caching \
gem_close_race \
+   gem_concurrent_blit \
gem_create \
gem_cs_tlb \
gem_ctx_bad_exec \
@@ -119,7 +120,6 @@ TESTS_progs_M = \
$(NULL)
 
 TESTS_progs_XM = \
-gem_concurrent_blit \
 gem_concurrent_all \
 $(NULL)
 
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 4/4] drm/atomic: Verify connector->funcs != NULL when clearing states

[Daniel Vetter]

On Thu, May 12, 2016 at 10:57:01AM -0400, Lyude wrote:
> Unfortunately since we don't have Dave's connector refcounting patch
> here yet, it's very possible that drm_atomic_state_default_clear() could
> get called by intel_display_resume() when
> intel_dp_mst_destroy_connector() isn't completely finished destroying an
> mst connector, but has already finished setting connector->funcs to
> NULL. As such, we need to treat the connector like it's already been
> destroyed and just skip it, otherwise we'll end up dereferencing a NULL
> pointer.
> 
> This fix is only required for 4.6 and below. David Airlie's patchseries
> for 4.7 to add connector reference counting provides a more proper fix
> for this.
> 
> Upstream fix: b164d31f50b2923a7a92c2a40cb46973a6ba8c36
> Cc: sta...@vger.kernel.org
> Signed-off-by: Lyude 

Not fixing the race at all, bug if it helps a few users in real-world
cases while the real bugfix trickles down into shipping kernels (it'll be
in 4.7 but just way too big for backporting) I'm ok with this.

Reviewed-by: Daniel Vetter  (but for stable
kernels only)
> ---
>  drivers/gpu/drm/drm_atomic.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 8ee1db8..d3a5b5c 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -139,7 +139,7 @@ void drm_atomic_state_default_clear(struct 
> drm_atomic_state *state)
>   for (i = 0; i < state->num_connector; i++) {
>   struct drm_connector *connector = state->connectors[i];
>  
> - if (!connector)
> + if (!connector || !connector->funcs)
>   continue;
>  
>   /*
> @@ -150,6 +150,7 @@ void drm_atomic_state_default_clear(struct 
> drm_atomic_state *state)
>* case by setting all connector pointers to NULL.
>*/
>   state->connector_states[i]->connector = NULL;
> +
>   connector->funcs->atomic_destroy_state(NULL,
>  
> state->connector_states[i]);
>   state->connectors[i] = NULL;
> -- 
> 2.5.5
> 

-- 
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 3/4] drm/i915: Discard previous atomic state on resume if connectors change

[Daniel Vetter]

On Thu, May 12, 2016 at 05:47:39PM -0400, Lyude wrote:
> If an MST device is disconnected while the machine is suspended, the
> number of connectors will change as well after we call
> intel_dp_mst_resume(). This means that any previous atomic state we had
> before suspending is no longer valid, since it'll still be pointing to
> missing connectors. We need to check for this before committing the
> state, otherwise we'll kernel panic on resume whenever if any MST
> display was disconnected before we started resuming:
> 
> BUG: unable to handle kernel NULL pointer dereference at 0008
> IP: [] drm_atomic_helper_check_modeset+0x29f/0xb40 
> [drm_kms_helper]
> Call Trace:
>  [] intel_atomic_check+0x34/0x1180 [i915]
>  [] ? mark_held_locks+0x6f/0xa0
>  [] ? trace_hardirqs_on_caller+0x129/0x1b0
>  [] drm_atomic_check_only+0x192/0x620 [drm]
>  [] ? pci_pm_thaw+0x21/0x90
>  [] drm_atomic_commit+0x17/0x60 [drm]
>  [] intel_display_resume+0xbd/0x160 [i915]
>  [] ? pci_pm_thaw+0x90/0x90
>  [] i915_drm_resume+0xd8/0x160 [i915]
>  [] i915_pm_resume+0x25/0x30 [i915]
>  [] pci_pm_resume+0x64/0xa0
>  [] dpm_run_callback+0x90/0x190
>  [] device_resume+0xd5/0x1f0
>  [] async_resume+0x1d/0x50
>  [] async_run_entry_fn+0x48/0x150
>  [] process_one_work+0x1e9/0x5c0
>  [] ? process_one_work+0x166/0x5c0
>  [] worker_thread+0x48/0x4e0
>  [] ? process_one_work+0x5c0/0x5c0
>  [] kthread+0xe4/0x100
>  [] ret_from_fork+0x22/0x50
>  [] ? kthread_create_on_node+0x200/0x200
> 
> Changes since v1:
>   - Move drm_atomic_state_free() call down so we're holding the
> appropriate locks when destroying the atomic state
> Changes since v2:
>   - Check that state != NULL before we start accessing it's members
> 
> This fix is only required for 4.6 and below. David Airlie's patchseries
> for 4.7 to add connector reference counting provides a more proper fix
> for this.
> 
> Upstream fix: b164d31f50b2923a7a92c2a40cb46973a6ba8c36
> Cc: sta...@vger.kernel.org
> Signed-off-by: Lyude 

Same caveat: This is for stable only as a duct-tape, the real fix is too
big for backporting from 4.7.

Reviewed-by: Daniel Vetter  (for stable kernels
only)
> ---
>  drivers/gpu/drm/i915/intel_display.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 182f849..e49a313 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15959,6 +15959,18 @@ void intel_display_resume(struct drm_device *dev)
>  retry:
>   ret = drm_modeset_lock_all_ctx(dev, );
>  
> + /*
> +  * With MST, the number of connectors can change between suspend and
> +  * resume, which means that the state we want to restore might now be
> +  * impossible to use since it'll be pointing to non-existant
> +  * connectors.
> +  */
> + if (ret == 0 && state &&
> + state->num_connector != dev->mode_config.num_connector) {
> + drm_atomic_state_free(state);
> + state = NULL;
> + }
> +
>   if (ret == 0 && !setup) {
>   setup = true;
>  
> -- 
> 2.5.5
> 

-- 
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 1/2] drm/i915:bxt: Enable Pooled EU support

[Daniel Vetter]

On Tue, May 17, 2016 at 05:01:56PM +0530, Arun Siluvery wrote:
> On 17/05/2016 16:43, Daniel Vetter wrote:
> >On Tue, May 17, 2016 at 04:32:49PM +0530, Arun Siluvery wrote:
> >>On 17/05/2016 15:34, Daniel Vetter wrote:
> >>>On Thu, May 12, 2016 at 10:37:14AM +0100, Arun Siluvery wrote:
> This mode allows to assign EUs to pools which can process work 
> collectively.
> The command to enable this mode should be issued as part of context 
> initialization.
> 
> The pooled mode is global, once enabled it has to stay the same across all
> contexts until HW reset hence this is sent in auxiliary golden context 
> batch.
> Thanks to Mika for the preliminary review and comments.
> 
> v2: explain why this is enabled in golden context, use feature flag while
> enabling the support (Chris)
> 
> v3: Pooled EU support announced in userspace before enabling in kernel,
> to simplify include all changes in the same patch.
> 
> User space clients need to know when the pooled EU feature is present
> and enabled on the hardware so that they can adapt work submissions.
> Create a new device info flag for this purpose, and create a new GETPARAM
> entry to allow user space to query its setting.
> 
> Set has_pooled_eu to true in the Broxton static device info - Broxton
> supports the feature in hardware and the driver will enable it by
> default.
> 
> Opensource users for this feature are mesa, libva and beignet.
> >>>
> >>>Link to those patches would be great. At least I haven't seen anything fly
> >>>by for mesa or libva, might have missed it though. Note that the patches
> >>>must be fully reviewed an ready for merging by respective userspace
> >>>upstream, before we can land the kernel side.
> >>
> >>Initially beignet is trying to use it and they are adding support to it. I
> >>will share links once they send them to the list, reviewed and ready to be
> >>merged.
> >
> >Then please don't say you have the userspace when it doesn't exist yet.
> 
> Hi Daniel,
> 
> I never claimed userspace exists for this feature, only mentioned who are
> the users and clearly stated in cover letter that Beignet team is currently
> adding userspace and libdrm support, sorry if I gave that impression.

Sorry for missing that, I just spotted the one line in the patch here and
assumed it's all there already.

> >The other question: Will existing userspace fall over if we enable this in
> >the kernel, or is it purely opt-in? Would be good to clarify in the commit
> >message.
> Yes it is an opt-in, userspace queries its availability and configures
> itself. We do have one WA affecting few revisions where it needs to be
> enabled (explained in cover letter). I will add a note to the commit msg as
> well.

For the places where we must enable it, might be good to just merge that
without the userspace flag. That way we don't block the wa on the
userspace/ABI question. Then just add the patch with the getparam later on
when we have the userspace reviewed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] lib/igt_kms: move gtk-doc comments next to the definition

[Jani Nikula]

Now that we have actual functions for kms_test_*_str since

commit 2d432fc5773df17f04283f4780dab161dd2e1c85
Author: Jani Nikula 
Date:   Wed May 11 12:42:06 2016 +0300

lib/igt_aux: define actual functions for kmstest_*_str

move also the gtk-doc comments next to the definitions, for consistency.

Acked-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
---
 lib/igt_aux.c | 18 ++
 lib/igt_kms.h | 20 
 2 files changed, 18 insertions(+), 20 deletions(-)

diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 6c3eb1f42fab..27b74aec8461 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -942,6 +942,12 @@ static const struct type_name encoder_type_names[] = {
{}
 };
 
+/**
+ * kmstest_encoder_type_str:
+ * @type: DRM_MODE_ENCODER_* enumeration value
+ *
+ * Returns: A string representing the drm encoder @type.
+ */
 const char *kmstest_encoder_type_str(int type)
 {
return find_type_name(encoder_type_names, type);
@@ -954,6 +960,12 @@ static const struct type_name connector_status_names[] = {
{}
 };
 
+/**
+ * kmstest_connector_status_str:
+ * @status: DRM_MODE_* connector status value
+ *
+ * Returns: A string representing the drm connector status @status.
+ */
 const char *kmstest_connector_status_str(int status)
 {
return find_type_name(connector_status_names, status);
@@ -980,6 +992,12 @@ static const struct type_name connector_type_names[] = {
{}
 };
 
+/**
+ * kmstest_connector_type_str:
+ * @type: DRM_MODE_CONNECTOR_* enumeration value
+ *
+ * Returns: A string representing the drm connector @type.
+ */
 const char *kmstest_connector_type_str(int type)
 {
return find_type_name(connector_type_names, type);
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 5c8340171ab6..7aad8c8c2153 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -77,28 +77,8 @@ enum port {
  */
 #define kmstest_port_name(port) ((port) + 'A')
 
-/**
- * kmstest_encoder_type_str:
- * @type: DRM_MODE_ENCODER_* enumeration value
- *
- * Returns: A string representing the drm encoder @type.
- */
 const char *kmstest_encoder_type_str(int type);
-
-/**
- * kmstest_connector_status_str:
- * @status: DRM_MODE_* connector status value
- *
- * Returns: A string representing the drm connector status @status.
- */
 const char *kmstest_connector_status_str(int status);
-
-/**
- * kmstest_connector_type_str:
- * @type: DRM_MODE_CONNECTOR_* enumeration value
- *
- * Returns: A string representing the drm connector @type.
- */
 const char *kmstest_connector_type_str(int type);
 
 void kmstest_dump_mode(drmModeModeInfo *mode);
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH i-g-t v2] tests: Separate tests with lots of subtests

[Gabriel Feceoru]

On 17.05.2016 12:59, Daniel Vetter wrote:

On Wed, Apr 20, 2016 at 05:21:58PM +0300, Gabriel Feceoru wrote:

Currently, when trying to run i-g-t tests with piglit, it takes up
to 20s until the first test is executed.
The main reason is that gem_concurrent_all has ~500k subtests,
overkilling piglit.

This patch separates gem_concurrent_* tests from the rest of the tests,
creating two files test-list.txt and test-list-full.txt.
The piglit can now enumerate the i-g-t tests within a decent few seconds.
The second list could be used when trying to execute specific these tests.

v2: Rebased

Signed-off-by: Gabriel Feceoru 


You didn't take my review into account but still just pushed this patch.
Please fix up.


My apologies, I didn't ignore it but didn't read it carefully.

Regards,
Gabriel



Also I think we should keep gem_concurrent_blit in the normal set of
testcases.
-Daniel


---
  tests/Makefile.am  | 12 +---
  tests/Makefile.sources | 22 --
  2 files changed, 29 insertions(+), 5 deletions(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 771e9ee..0ed2a07 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -14,6 +14,12 @@ test-list.txt: Makefile.sources
@echo ${single_kernel_tests} ${multi_kernel_tests} >> $@
@echo END TESTLIST >> $@

+test-list-full.txt: Makefile.sources
+   @echo TESTLIST > $@
+   @echo ${single_kernel_tests} ${multi_kernel_tests} 
${extra_multi_kernel_tests} >> $@
+   @echo END TESTLIST >> $@
+
+
  noinst_PROGRAMS = \
$(HANG) \
$(TESTS_testsuite) \
@@ -38,14 +44,14 @@ dist_pkgdata_DATA = \

  all-local: .gitignore
  .gitignore: Makefile.sources
-   @echo "$(pkglibexec_PROGRAMS) $(HANG) test-list.txt .gitignore" | sed 
's/\s\+/\n/g' | sort > $@
+   @echo "$(pkglibexec_PROGRAMS) $(HANG) test-list.txt test-list-full.txt 
.gitignore" | sed 's/\s\+/\n/g' | sort > $@

-pkgdata_DATA = test-list.txt
+pkgdata_DATA = test-list.txt test-list-full.txt

  EXTRA_PROGRAMS = $(HANG)
  EXTRA_DIST = $(common_files)

-CLEANFILES = $(EXTRA_PROGRAMS) test-list.txt .gitignore
+CLEANFILES = $(EXTRA_PROGRAMS) test-list.txt test-list-full.txt .gitignore

  AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) $(DEBUG_CFLAGS)\
-I$(srcdir)/.. \
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 41eca0d..abcf325 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -20,8 +20,6 @@ TESTS_progs_M = \
gem_busy \
gem_caching \
gem_close_race \
-   gem_concurrent_blit \
-   gem_concurrent_all \
gem_create \
gem_cs_tlb \
gem_ctx_bad_exec \
@@ -117,6 +115,11 @@ TESTS_progs_M = \
template \
$(NULL)

+TESTS_progs_XM = \
+gem_concurrent_blit \
+gem_concurrent_all \
+$(NULL)
+
  TESTS_progs = \
core_auth \
core_getclient \
@@ -219,6 +222,15 @@ multi_kernel_tests = \
$(TESTS_scripts_M) \
$(NULL)

+
+# This target contains testcases with lots of subtests.
+# It was split from multi_kernel_tests because of the overhead of listing all
+# the subtests in piglit
+extra_multi_kernel_tests = \
+   $(TESTS_progs_XM) \
+   $(NULL)
+
+
  # This target is for simple testcase which don't expose any subtest.
  #
  # Your testcase should probably use igt_simple_main, but none of the other 
magic
@@ -233,6 +245,12 @@ kernel_tests = \
$(multi_kernel_tests) \
$(NULL)

+kernel_tests_full = \
+$(single_kernel_tests) \
+$(multi_kernel_tests) \
+   $(extra_multi_kernel_tests) \
+   $(NULL)
+
  # Test that exercise specific asserts in the test framework library and are
  # hence expected to fail.
  XFAIL_TESTS = \
--
1.9.1

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



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

Re: [Intel-gfx] [PATCHv5 5/5] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

[Ander Conselvan De Oliveira]

On Mon, 2016-05-16 at 11:56 +0530, Durgadoss R wrote:
> To support USB type C alternate DP mode, the display driver needs to
> know the number of lanes required by the DP panel as well as number
> of lanes that can be supported by the type-C cable. Sometimes, the
> type-C cable may limit the bandwidth even if Panel can support
> more lanes. To address these scenarios, the display driver will
> start link training with max lanes, and if that fails, the driver
> falls back to x2 lanes; and repeats this procedure for all
> bandwidth/lane configurations.
> 
> * Since link training is done before modeset only the port
>   (and not pipe/planes) and its associated PLLs are enabled.
> * On DP hotplug: Directly start link training on the DP encoder.
> * On Connected boot scenarios: When booted with an LFP and a DP,
>   typically, BIOS brings up DP. In these cases, we disable the
>   crtc and then do upfront link training; and bring it back up.
> * All local changes made for upfront link training are reset
>   to their previous values once it is done; so that the
>   subsequent modeset is not aware of these changes.
> 
> Changes since v4:
> * Removed usage of crtc_state in upfront link training;
>   Hence no need to find free crtc to do upfront now.
> * Re-enable crtc if it was disabled for upfront.
> * Use separate variables to track max lane count
>   and link rate found by upfront, without modifying
>   the original DPCD read from panel.
> Changes since v3:
> * Fixed a return value on BXT check
> * Reworked on top of bxt_ddi_pll_select split from Ander
> * Renamed from ddi_upfront to bxt_upfront since the
>   upfront logic includes BXT specific functions for now.
> Changes since v2:
> * Rebased on top of latest dpll_mgr.c code and
>   latest HPD related clean ups.
> * Corrected return values from upfront (Ander)
> * Corrected atomic locking for upfront in intel_dp.c (Ville)
> Changes since v1:
> *  all pll related functions inside ddi.c
> 
> Signed-off-by: Durgadoss R 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c |  58 +
>  drivers/gpu/drm/i915/intel_dp.c  | 183 +-
> -
>  drivers/gpu/drm/i915/intel_drv.h |  12 +++
>  3 files changed, 247 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 7e6331a..3ccd1c7 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2330,6 +2330,64 @@ intel_ddi_init_hdmi_connector(struct intel_digital_port
> *intel_dig_port)
>   return connector;
>  }
>  
> +int intel_bxt_upfront_link_train(struct intel_dp *intel_dp,
> + int clock, uint8_t lane_count)
> +{
> + struct intel_connector *connector = intel_dp->attached_connector;
> + struct intel_encoder *encoder = connector->encoder;
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_shared_dpll *pll;
> + struct intel_shared_dpll_config tmp_pll_config;
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + enum intel_dpll_id dpll_id = (enum intel_dpll_id)dig_port->port;
> +
> + mutex_lock(_priv->dpll_lock);
> + /*
> +  * FIXME: Works only for BXT.
> +  * Select the required PLL. This works for platforms where
> +  * there is no shared DPLL.
> +  */
> + pll = _priv->shared_dplls[dpll_id];
> + if (WARN_ON(pll->active_mask)) {
> + DRM_ERROR("Shared DPLL already in use. active_mask:%x\n",
> pll->active_mask);
> + mutex_unlock(_priv->dpll_lock);
> + return -EINVAL;
> + }
> +
> + tmp_pll_config = pll->config;
> +
> + DRM_DEBUG_KMS("Upfront link train start : link_clock:%d lanes:%d\n",
> + clock, lane_count);
> + do {
> + if (!bxt_ddi_dp_set_dpll_hw_state(clock, 
> >config.hw_state)) {
> + DRM_ERROR("Could not setup DPLL\n");
> + goto exit_pll;
> + }
> +
> + /* Enable PLL followed by port */
> + pll->funcs.enable(dev_priv, pll);
> + intel_ddi_pre_enable_dp(encoder, clock, lane_count, pll);
> +
> + if (intel_dp->train_set_valid)
> + intel_dp_set_upfront_params(intel_dp, clock,
> lane_count);
> +
> + /* Disable port followed by PLL for next retry/clean up */
> + intel_ddi_post_disable(encoder);
> + pll->funcs.disable(dev_priv, pll);
> +
> + } while (!intel_dp->train_set_valid &&
> + intel_dp_get_link_retry_params(intel_dp, ,
> _count));

What I had in mind is that this loop would still be in the generic DP code.
Something like the following in intel_dp_upfront_link_train():

for (done = false, lane_count = 4; lane_count >= 1 && !done; lane_count >> 1) {

/* maybe use intel_dp_common_rates() here */
for (link_rate = HBR2; link_rate 

Re: [Intel-gfx] [PATCH 1/2] drm/i915:bxt: Enable Pooled EU support

[Daniel Vetter]

On Tue, May 17, 2016 at 04:32:49PM +0530, Arun Siluvery wrote:
> On 17/05/2016 15:34, Daniel Vetter wrote:
> >On Thu, May 12, 2016 at 10:37:14AM +0100, Arun Siluvery wrote:
> >>This mode allows to assign EUs to pools which can process work collectively.
> >>The command to enable this mode should be issued as part of context 
> >>initialization.
> >>
> >>The pooled mode is global, once enabled it has to stay the same across all
> >>contexts until HW reset hence this is sent in auxiliary golden context 
> >>batch.
> >>Thanks to Mika for the preliminary review and comments.
> >>
> >>v2: explain why this is enabled in golden context, use feature flag while
> >>enabling the support (Chris)
> >>
> >>v3: Pooled EU support announced in userspace before enabling in kernel,
> >>to simplify include all changes in the same patch.
> >>
> >>User space clients need to know when the pooled EU feature is present
> >>and enabled on the hardware so that they can adapt work submissions.
> >>Create a new device info flag for this purpose, and create a new GETPARAM
> >>entry to allow user space to query its setting.
> >>
> >>Set has_pooled_eu to true in the Broxton static device info - Broxton
> >>supports the feature in hardware and the driver will enable it by
> >>default.
> >>
> >>Opensource users for this feature are mesa, libva and beignet.
> >
> >Link to those patches would be great. At least I haven't seen anything fly
> >by for mesa or libva, might have missed it though. Note that the patches
> >must be fully reviewed an ready for merging by respective userspace
> >upstream, before we can land the kernel side.
> 
> Initially beignet is trying to use it and they are adding support to it. I
> will share links once they send them to the list, reviewed and ready to be
> merged.

Then please don't say you have the userspace when it doesn't exist yet.

The other question: Will existing userspace fall over if we enable this in
the kernel, or is it purely opt-in? Would be good to clarify in the commit
message.
-Daniel
> 
> regards
> Arun
> 
> >-Daniel
> >
> >>
> >>Reviewed-by: Chris Wilson 
> >>Cc: Winiarski, Michal 
> >>Cc: Zou, Nanhai 
> >>Cc: Yang, Rong R 
> >>Cc: Mika Kuoppala 
> >>Cc: Chris Wilson 
> >>Cc: Armin Reese 
> >>Cc: Tim Gore 
> >>Signed-off-by: Jeff McGee 
> >>Signed-off-by: Arun Siluvery 
> >>---
> >>  drivers/gpu/drm/i915/i915_dma.c  |  3 +++
> >>  drivers/gpu/drm/i915/i915_drv.c  |  1 +
> >>  drivers/gpu/drm/i915/i915_drv.h  |  5 -
> >>  drivers/gpu/drm/i915/i915_gem_render_state.c | 13 +
> >>  drivers/gpu/drm/i915/i915_reg.h  |  2 ++
> >>  include/uapi/drm/i915_drm.h  |  1 +
> >>  6 files changed, 24 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/i915_dma.c 
> >>b/drivers/gpu/drm/i915/i915_dma.c
> >>index 0eadeb6..5cd2ad4 100644
> >>--- a/drivers/gpu/drm/i915/i915_dma.c
> >>+++ b/drivers/gpu/drm/i915/i915_dma.c
> >>@@ -222,6 +222,9 @@ static int i915_getparam(struct drm_device *dev, void 
> >>*data,
> >>if (!value)
> >>return -ENODEV;
> >>break;
> >>+   case I915_PARAM_HAS_POOLED_EU:
> >>+   value = HAS_POOLED_EU(dev);
> >>+   break;
> >>case I915_PARAM_HAS_GPU_RESET:
> >>value = i915.enable_hangcheck && intel_has_gpu_reset(dev_priv);
> >>break;
> >>diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> >>b/drivers/gpu/drm/i915/i915_drv.c
> >>index 5ae7960..33e0fd0 100644
> >>--- a/drivers/gpu/drm/i915/i915_drv.c
> >>+++ b/drivers/gpu/drm/i915/i915_drv.c
> >>@@ -357,6 +357,7 @@ static const struct intel_device_info 
> >>intel_broxton_info = {
> >>.has_ddi = 1,
> >>.has_fpga_dbg = 1,
> >>.has_fbc = 1,
> >>+   .has_pooled_eu = 1,
> >>GEN_DEFAULT_PIPEOFFSETS,
> >>IVB_CURSOR_OFFSETS,
> >>BDW_COLORS,
> >>diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >>b/drivers/gpu/drm/i915/i915_drv.h
> >>index 7a0b513..5b2a7a3 100644
> >>--- a/drivers/gpu/drm/i915/i915_drv.h
> >>+++ b/drivers/gpu/drm/i915/i915_drv.h
> >>@@ -750,7 +750,8 @@ struct intel_csr {
> >>func(has_llc) sep \
> >>func(has_snoop) sep \
> >>func(has_ddi) sep \
> >>-   func(has_fpga_dbg)
> >>+   func(has_fpga_dbg) sep \
> >>+   func(has_pooled_eu)
> >>
> >>  #define DEFINE_FLAG(name) u8 name:1
> >>  #define SEP_SEMICOLON ;
> >>@@ -2736,6 +2737,8 @@ struct drm_i915_cmd_table {
> >> !IS_VALLEYVIEW(dev) && !IS_CHERRYVIEW(dev) && \
> >> !IS_BROXTON(dev))
> >>
> >>+#define HAS_POOLED_EU(dev) (INTEL_INFO(dev)->has_pooled_eu)
> >>+
> >>  #define INTEL_PCH_DEVICE_ID_MASK  0xff00
> >>  #define INTEL_PCH_IBX_DEVICE_ID_TYPE  0x3b00