Re: [Intel-gfx] force DP lane count on Broadwell platform
On Wed, 18 May 2016, "Sanchez, AdolfoX" wrote: > 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? You should probably look at intel_ddi_init() in intel_ddi.c, and set intel_dig_port->max_lanes to 2. Then it should limit the source to two lanes wherever it's needed. Of course, I should ask you why you need this; maybe you should be asking a different question. ;) BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] FreeBSD i915 driver update
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&beyond 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
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.
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(&wait_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
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 doesn't fix anything when a user
Re: [Intel-gfx] [PATCH 01/21] drm/i915: Fix BXT min_pixclk after state readout
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
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
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
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
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
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
== 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)
== 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
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
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
== 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
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, -1000)) +
[Intel-gfx] [PATCH 5/7] drm/i915: Introduce wait_until_reg
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
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
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(&dev_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
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
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
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
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
== 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
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(&dev_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( > + &req->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(&head_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( > + &ctx->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) > +enum { > + CONTEXT_SCHEDULE_IN = 0, > + CONTEXT_SCHEDULE_OUT
Re: [Intel-gfx] FreeBSD i915 driver update
> 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&beyond 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
== 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
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&id=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
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
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.
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(&wait_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
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(&dev_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
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
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
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.
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
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(&dev_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(&dev_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
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
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 >> +++ b/drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c >> @@ -0,0 +1,157 @@ >> +/* >> + * Copyright © 2016 Intel Corporation >> + * >> + * Permission is hereby granted, free of charge, to any person obtaining a >>
[Intel-gfx] [PATCH 2/4] drm/i915: Set softmin frequency when going from idle to busy
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(&dev_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
[Intel-gfx] [PATCH i-g-t] tests/pm_rps: Add handling of idle frequency exposed via sysfs
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
Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [v4,1/2] drm/i915: refactor i915_gem_object_pin_map()
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 4/4] drm/i915: Extract common get/set frequency limits functions
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(&dev_priv->rps.delayed_resume_work); - - ret = mutex_lock_interruptible(&dev_priv->rps.hw_lock); - if (ret) - return ret; - - *val = intel_gpu_freq(dev_priv, dev_priv->rps.max_freq_softlimit); - mutex_unlock(&dev_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(&dev_priv->rps.delayed_resume_work); - DRM_DEBUG_DRIVER("Manually setting max freq to %llu\n", val); - ret = mutex_lock_interruptible(&dev_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(&dev_priv->rps.hw_lock); - return -EINVAL; - } - - dev_priv->rps.max_freq_softlimit = val; - - intel_set_rps(dev_priv, val); - - mutex_unlock(&dev_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(&dev_priv->rps.delayed_resume_work); - - ret = mutex_lock_interruptible(&dev_priv->rps.hw_lock); - if (ret) - return ret; - - *val = intel_gpu_freq(dev_priv, dev_priv->rps.min_freq_softlimit); - mutex_unlock(&dev_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(&dev_priv->rps.delayed_resume_work); - DRM_DEBUG_DRIVER("Manually setting min freq to %llu\n", val); - ret = mutex_lock_interruptible(&dev_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(&dev_priv->rps.hw_lock); - return -EINVAL; - } - - dev_priv->rps.min_freq_softlimit = val; - - intel_set_rps(dev_priv, val); - - mutex_unlock(&dev_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(&dev_priv->rps.delayed_resume_work); - - ret = mutex_lock_interruptible(&dev_priv->rps.hw_lock); - if (ret) - return ret; - - *val = intel_gpu_freq(dev_priv, dev_priv->rps.idle_freq); - mutex_unlock(&dev
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub
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
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(&dev_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(&dev_priv->rps.delayed_resume_work); + + ret = mutex_lock_interruptible(&dev_priv->rps.hw_lock); + if (ret) + return ret; + + *val = intel_gpu_freq(dev_priv, dev_priv->rps.idle_freq); + mutex_unlock(&dev_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(&dev_priv->rps.delayed_resume_work); + + DRM_DEBUG_DRIVER("Manually setting idle freq to %llu\n", val); + + ret = mutex_lock_interruptible(&dev_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(&dev_priv->rps.hw_lock); + return -EINVAL; + } + + dev_priv->rps.idle_freq = val; + + intel_set_rps(dev_priv, val); + + mutex_unlock(&dev_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", &i915_wedged_fops}, {"i915_max_freq", &i915_max_freq_fops}, {"i915_min_freq", &i915_min_freq_fops}, + {"i915_idle_freq", &i915_idle_freq_fops}, {"i915_cache_sharing", &i915_cache_sharing_fops}, {"i915_ring_stop", &i915_ring_stop_fops}, {"i915_ring_missed_irq", &i915_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(&dev_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(&dev_priv->rps.delayed_resume_work); + + mutex_lock(&dev_priv->rps.hw_lock); + ret = intel_gpu_freq(dev_priv, dev_priv->rps.idle_freq); + mutex_unlock(&dev_priv->rps.hw_lock); + + return snprintf(buf, PAGE_SI
[Intel-gfx] [PATCH 1/4] drm/i915: Early exit from rps worker if GPU is idle
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(&dev_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(&dev_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)
== 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
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 i915_hw_ppgtt *ppgtt) { + struct drm_i915_private *dev_pri
Re: [Intel-gfx] [PATCH] drm/i915: Update kerneldoc for intel_dpll_mgr.c
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 &dev_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(&dev_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
Re: [Intel-gfx] [PATCH 0/6] Move dpio access out of intel_display.c
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()
== 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.
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
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 driver is that when the render side > > > > > > > > died > > > > >
[Intel-gfx] [PATCH] drm/i915: Update kerneldoc for intel_dpll_mgr.c
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 &dev_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(&dev_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 @crtc_state. + */ struct intel_shared
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915: refactor i915_gem_object_pin_map()
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, &sg_iter, sgt->nents, 0) + pages[i++] = sg_page_iter_page(&sg_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, &sg_iter, -obj->pages->nents, 0) - pages[n++] = sg_page_iter_page(&sg_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.
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(&to_i915(dev)->gpu_error); - if (intel_crtc->reset_counter != reset_counter) - return false; - return !list_empty_careful(&to_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(&dev_priv->gpu_error); schedule_work(&work->mmio_work); mutex_unlock(&dev->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.
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(&plane_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(&old_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.
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(&crtc->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 = &crtc->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(&crtc->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.
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.
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(&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 = &dev_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(&primary->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.
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(&work->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(&work->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(&dev->event_lock); - work = crtc->flip_work; - if (work == NULL) { + if (list_empty(&crtc->flip_work)) { seq_printf(m, "No flip due on pipe %c (plane %c)\n", pipe, plane); } else { - u32 pending; - u32 addr; - - pending = atomic_read(&work->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_vbla
[Intel-gfx] [PATCH v2 12/21] drm/i915: Remove cs based page flip support.
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(&work->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(&work->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 (de_iir & (DE_PIPE_VBLA
[Intel-gfx] [PATCH v2 04/21] drm/i915: Remove intel_prepare_page_flip, v3.
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(&work->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 535f20ab2870..d6e90fa888cf 100644 --- a/driv
[Intel-gfx] [PATCH v2 06/21] drm/i915: Unify unpin_work and mmio_work into flip_work, v2.
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(&dev->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(&crtc->base)); + intel_crtc_get_vblank_counter(crtc)); seq_printf(m, "%d prepares\n", atomic_read(&work->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 +4185,7 @@ static boo
[Intel-gfx] [PATCH v2 08/21] drm/i915: Allow mmio updates on all platforms, v2.
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; + struct drm_device *dev = crtc->base.dev
[Intel-gfx] [PATCH v2 13/21] drm/i915: Remove use_mmio_flip kernel parameter.
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.
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(&work->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) - drm_framebuffer
[Intel-gfx] [PATCH v2 17/21] drm/i915: Prepare connectors for nonblocking checks.
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(&work->mmio_work); cancel_work_sync(&work->unpin_work); - kfree(work); + intel_free_flip_work(work); spin_lock_irq(&dev->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(&work->mmio_work); - if (!work->can_async_unpin) + if (!work->can_async_unpin && + (work->new_crtc_state->update_pipe || +needs_modeset(&work->new_crtc_state->base))) { /* This must be called before work is unpinned for serialization. */ intel_modeset_verify_crtc(crtc, &work->old_crtc_state->base, &work->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(&work->head)) { spin_lock_irq(&dev->event_lock); WARN(list_empty(&work->head) != work->can_async_unpin, @@ -10906,7 +10935,7 @@ static void intel_unpin_work_fn(struct work_struct *__work) if (!WARN_ON(atomic_read(&intel_crtc->unpin_work_count) == 0)) atomic_dec(&intel_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
[Intel-gfx] [PATCH v2 19/21] Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor updates"
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(&intel_crtc->unpin_work_count) >= 2) - flush_workqueue(dev_priv->wq); + if (atomic_read(&intel_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 00/21] Rework page flip, remove cs flips, async unpin and unified pageflip.
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 14/21] drm/i915: Remove queue_flip pointer.
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(&dev->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 | - MI_DISPLAY_FLIP_PLANE(intel_crtc->plane)); - intel_ring_emi
[Intel-gfx] [PATCH v2 21/21] drm/i915: Allow async update of pageflips.
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(&crtc_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) &dev_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(&crtc_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(&plane->base, crtc_state, new_plane_state); + if (new_plane_state->visible) + plane->update_plane(&plane->base, crtc_state, new_plane_state); + else + plane->disable_plane(&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"
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.
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.
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(&state->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(&crtc->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(&pipe_config->base) || -!old_primary_state->visible)) - intel_post_enable_primary(&crtc->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(&crtc_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 free i
[Intel-gfx] [PATCH v2 02/21] drm/i915: Remove stallcheck special handling, v3.
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(&work->pending) < INTEL_FLIP_COMPLETE) { + pending = atomic_read(&work->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(&crtc->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(&work->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(&dev->event_lock, flags); work = intel_crtc->unpin_work; - /* Ensure we don't miss a work->pending update ... */ - smp_rmb(); + if (work && atomic_read(&work->pending) >= INTEL_FLIP_COMPLETE) { + /* ensure that the unpin work is consistent wrt ->pending. */ + smp_rmb(); - if (work == NULL || atomic_read(&work->pending) < INTEL_FLIP_COMPLETE) { - spin_unlock_irqrestore(&dev->event_lock, flags); - return; + page_flip_completed(intel_crtc); } - page_flip_completed(intel_crtc); - spin_unlock_irqrestore(&dev->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(&work->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_mark_page_flip_active(in
[Intel-gfx] [PATCH v2 01/21] drm/core: Add drm_accurate_vblank_count, v5.
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, &t_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(&dev->vblank_time_lock, flags); + + drm_update_vblank_count(dev, pipe, 0); + vblank = drm_vblank_count(dev, pipe); + + spin_unlock_irqrestore(&dev->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
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()
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, &sg_iter, sgt->nents, 0) +pages[i++] = sg_page_iter_page(&sg_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, &sg_iter, - obj->pages->nents, 0) -pages[n++] = sg_page_iter_page(&sg_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
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 > > > > > > > get the bug report out". I don't see a justification of that >
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub
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 driver is that when the render side > > > > > > > > died > > > > > > >
[Intel-gfx] [PATCH v4 2/2] drm/i915: optimise i915_gem_object_map() for small objects
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, &sg_iter, sgt->nents, 0) pages[i++] = sg_page_iter_page(&sg_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()
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, &sg_iter, sgt->nents, 0) + pages[i++] = sg_page_iter_page(&sg_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, &sg_iter, -obj->pages->nents, 0) - pages[n++] = sg_page_iter_page(&sg_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
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 > > > > > > > get the bug report out". I don't see a justification of that > >
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub
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. If Intel is happy with > > > > > continued > > > > > CI test failur
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub
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 > > > > > > > get the bug report out". I don't see a justification of that >
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub
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 probes. If Intel is happy with > > > > > continued > > > > > CI test fai
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/hda: Add audio component stub
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. > > > But > > > things will fail atm even in the normal case when audio i
Re: [Intel-gfx] [PATCH 0/6] Move dpio access out of intel_display.c
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}
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
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 patch 2, > not > sure about that). Patch 1 here looks like a workaround
[Intel-gfx] [PATCH i-g-t] autotools/: Keep gem_concurrent_blit in tests/ and put gem_conccurent_all in EXTRAS.
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
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
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
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, &ctx); > > + /* > + * 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
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
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 1/2] drm/i915:bxt: Enable Pooled EU support
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. 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. regards Arun -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 #define INTEL_PCH_CPT_DEVICE_ID_TYPE 0x
Re: [Intel-gfx] [PATCH i-g-t v2] tests: Separate tests with lots of subtests
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