[Intel-gfx] [PATCH 1/2] tests/kms_sink_crc_basic: skip properly
Not running the test is not failing.
Signed-off-by: Daniel Vetter
---
tests/kms_sink_crc_basic.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tests/kms_sink_crc_basic.c b/tests/kms_sink_crc_basic.c
index 924aadaca610..4be115c2d51c 100644
--- a/tests/kms_sink_crc_basic.c
+++ b/tests/kms_sink_crc_basic.c
@@ -178,8 +178,7 @@ static void run_test(data_t *data)
return;
}
- fprintf(stderr, "no eDP with CRC support found\n");
- igt_fail(1);
+ igt_skip("no eDP with CRC support found\n");
}
igt_simple_main
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] tests/kms_sink_crc_basic: Use igt_assert
Less verbose code makes for clearer test logic.
Signed-off-by: Daniel Vetter
---
tests/kms_sink_crc_basic.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/tests/kms_sink_crc_basic.c b/tests/kms_sink_crc_basic.c
index 4be115c2d51c..087b79db4b36 100644
--- a/tests/kms_sink_crc_basic.c
+++ b/tests/kms_sink_crc_basic.c
@@ -134,28 +134,19 @@ static void basic_sink_crc_check(data_t *data, uint32_t
connector_id)
/* get reference crc for black color */
get_crc(ref_crc_black);
- if (strcmp(ref_crc_black, ref_crc_white) == 0) {
- fprintf(stderr, "CRC Black should differ from CRC White\n");
- igt_fail(1);
- }
+ igt_assert(strcmp(ref_crc_black, ref_crc_white) != 0);
/*Go White again*/
connector_set_mode(data, &connector, &connector.config.default_mode,
WHITE);
get_crc(crc_check);
- if (strcmp(crc_check, ref_crc_white) != 0) {
- fprintf(stderr, "CRC check for white differ from reference\n");
- igt_fail(1);
- }
+ igt_assert(strcmp(crc_check, ref_crc_white) == 0);
/* Go Black again */
connector_set_mode(data, &connector, &connector.config.default_mode,
BLACK);
get_crc(crc_check);
- if (strcmp(crc_check, ref_crc_black) != 0) {
- fprintf(stderr, "CRC check for black differ from reference\n");
- igt_fail(1);
- }
+ igt_assert(strcmp(crc_check, ref_crc_black) == 0);
kmstest_free_connector_config(&connector.config);
}
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Add support for Generic MIPI panel driver
On 5/21/2014 2:25 AM, Damien Lespiau wrote: On Tue, May 20, 2014 at 09:46:01PM +0530, Shobhit Kumar wrote: - UI is a period, so is homogeneous to time (s), but ui_num being in s^-1 and ui_den a constant, ui_num/ui_den looks like a frequency. Or could it be that UI = ui_den / ui_num? would be confusing, but the code below would make more sense. In which case could we have UI = ui_num / ui_den? I just kept ui_num and ui_den separately to take care of precision loss, but I see how it is adding to confusion. Actually it is ui_den / ui_num and we have all computations as 1/UI so it works. I think I will compute UI directly as UI = (NS_KHZ_RATIO * 1000) /bitrate and divide by 1000 wherever we use to maintain precision. Sounds ok ? I think just exchanging the two variable names (ui_num and ui_den) should be less work for you and should be enough. It's really just about having ui_num being the UI numerator so the reader is not too surprised Yeah. Will fix this + /* B044 */ + intel_dsi->hs_to_lp_count = + CEIL_DIV( + 4 * tlpx_ui + prepare_cnt * 2 + + exit_zero_cnt * 2 + 10, + 8); The previous was before I tried to look at the spec too closely. Mind explaining why we don't look at the HS to LP switch count? ie why HS to LP switch cound is always smaller than the LP to HS one? Because LP to HS uses exit_zero_count which is generally higher than clk_zero_count. So just directly used LP to HS which amounts to saying that switching from HS to LP takes lesser time than switching from LP to HS. I can/should add code to compute max of the two. This could go to a separate task if you don't have time right now, Most likely I can do this as well. Will push the updated patch by sometime tomorrow. Regards Shobhit ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/vlv: assert and de-assert sideband reset at boot and resume v3
On Thu, May 22, 2014 at 09:51:22AM +0300, Imre Deak wrote: > On Wed, 2014-05-21 at 21:43 +0300, Ville Syrjälä wrote: > > On Wed, May 21, 2014 at 11:11:15AM -0700, Jesse Barnes wrote: > > > And to answer more specifically... > > > > > > On Wed, 21 May 2014 20:54:03 +0300 > > > Ville Syrjälä wrote: > > > > > > > > + __vlv_set_power_well(dev_priv, > > > > > PUNIT_POWER_WELL_DPIO_CMN_BC, > > > > > + false); > > > > > + __vlv_set_power_well(dev_priv, > > > > > PUNIT_POWER_WELL_DPIO_CMN_BC, > > > > > + true); > > > > > > > > Hmm. I wonder how the power well hack in intel_uncore_sanitize() ties in > > > > with this. We should definitely rip that out regardless. > > > > > > Yeah we can rip that out. That's just an ungate, and it assumes the > > > BIOS has already done the reset toggle for us. > > > > Well I'm assumign the system may boot/resume with the wells powered > > down. And we definitely don't have the cri/ref clocks set up at this > > point. So if they're needed to complete the resets the PHY may get stuck > > or something. Also it just ungates everything at once, if the wells need > > some ordering in bringup we have just messed things up here. > > I agree, there doesn't seem to be anything that needs those power wells > until the power domain init code runs. I can send a patch for this after > some testing. > > > > > Another thing I'm wodering is did the BIOS/hw really power on the > > > > common lane, or did we do that outselves? If the latter, then I wonder > > > > if we simply do that too early. Or more precisely do we need to make > > > > sure the cri clock and/or refclock are enabled before we power on the > > > > common lane? > > > > > > Depends on the platform. It looks like the right thing happens at boot > > > time on most machines (i.e. the BIOS does a full toggle which causes a > > > reset), but on suspend/resume it's up to us. And of course on machines > > > without video init at boot time, we need to do it ourselves as well. > > > > > > I don't think the cri or refclk is required at this point, at least not > > > if the docs we have are correct (the PHY reset is supposed to be the > > > very first thing). > > > > The timing diagrams do show some kind of relationship between the > > cri/ref clocks and the reset signals getting deasserted. > > Under "4.3 Clock Signal List" there is a hint about this saying that the > cri and pll1 ref clocks are needed for the init time calibration of the > whole PHY. The calibration is started by CMN reset, which should occur > after all the needed lanes are powered on. But this matches what we do > already now, except that toggling of the CMN reset signal is not > guaranteed if it was already deasserted by the BIOS. This would be fixed > by Jesse's v1 patch (but not v2). My main issue with Jesse's patch is that it may fix the resume time problem. But things should still fail in the exact same way if we power gate the TX lanes and then try to bring them back. So it should fail by simply disabling and re-enabling one port while keeping the common lane powered up eg. by having the other port enabled all the time. And we don't assert cmnreset when powergating the cmnlane, so that too may mess up the cmn lane power up since cmnreset is now deasserted before sidereset. So even if we power down the common lane as well, things may go bad. > > > > > And third is that do we need to enable the TX wells before the CMN > > > > well? Currently we do the opposite which could also explain why this > > > > CMN well toggle fixes things. > > > > > > I don't think that matters, but we should ask the PHY guys. The lack > > > of symmetry between the gate and ungate bothers me too. > > > > My theory here is that the cmn and/or side reset needs to propagate to > > the data lanes to propery initialize them. If the lanes are powered down > > when the reset occurs things go bad. > > I agree that the CMN reset should happen after all the lanes are powered > on, but this is what we do already now, except guaranteeing that it > toggles. It's not clear what triggers the side reset signal, I assume > Punit deasserts it after powering on the CMN lane. Also not clear if > this really needs to happen after powering on the TX lanes. > > > And looks like the "Dynamic Power Gating" section in the phy cspec > > pretty much says as much. That is you need to fully reset the entire > > phy if you want to ungate even one of the blocks. > > What does full reset mean? In my opinion toggling the CMN reset line is > enough, but I guess you suggest that we also need to power off/on the > CMN lane first. It would be good if Jesse could try if toggling CMN > reset alone is enough to get rid of the problem he saw. IIRC the docs said sidereset needs to be reasserted too. And AFAICS the only way to do that is by toggling the power to the common lane. > > > So based on that I think pretty muc
[Intel-gfx] [PATCH] drm/i915: Only discard backing storage on releasing the last ref
Before purging our pages (as opposed to copying back the contents from
the GPU), make sure that there is not an exposed CPU mmapping through
which the user can inspect the results.
Regression from
commit 5537252b6b6d71fb1a8ed7395a8e5babf91953fd
Author: Chris Wilson
Date: Tue Mar 25 13:23:06 2014 +
drm/i915: Invalidate our pages under memory pressure
Testcase: igt/gem_mmap/new-object
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79005
Signed-off-by: Chris Wilson
Tested-by: Guo Jinxian
---
drivers/gpu/drm/i915/i915_gem.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9cb7c1908279..31b9a04bd543 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4668,6 +4668,30 @@ struct drm_i915_gem_object *i915_gem_alloc_object(struct
drm_device *dev,
return obj;
}
+static bool discard_backing_storage(struct drm_i915_gem_object *obj)
+{
+ /* If we are the last user of the backing storage (be it shmemfs
+* pages or stolen etc), we know that the pages are going to be
+* immediately released. In this case, we can then skip copying
+* back the contents from the GPU.
+*/
+
+ if (obj->madv != I915_MADV_WILLNEED)
+ return false;
+
+ if (obj->base.filp == NULL)
+ return true;
+
+ /* At first glance, this looks racy, but then again so would be
+* userspace racing mmap against close. However, the first external
+* reference to the filp can only be obtained through the
+* i915_gem_mmap_ioctl() which safeguards us against the user
+* acquiring such a reference whilst we are in the middle of
+* freeing the object.
+*/
+ return atomic_long_read(&obj->base.filp->f_count) == 1;
+}
+
void i915_gem_free_object(struct drm_gem_object *gem_obj)
{
struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
@@ -4705,7 +4729,7 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
if (WARN_ON(obj->pages_pin_count))
obj->pages_pin_count = 0;
- if (obj->madv != __I915_MADV_PURGED)
+ if (discard_backing_storage(obj))
obj->madv = I915_MADV_DONTNEED;
i915_gem_object_put_pages(obj);
i915_gem_object_free_mmap_offset(obj);
--
2.0.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Only discard backing storage on releasing the last ref
On Thu, May 22, 2014 at 09:16:52AM +0100, Chris Wilson wrote:
> Before purging our pages (as opposed to copying back the contents from
> the GPU), make sure that there is not an exposed CPU mmapping through
> which the user can inspect the results.
>
> Regression from
>
> commit 5537252b6b6d71fb1a8ed7395a8e5babf91953fd
> Author: Chris Wilson
> Date: Tue Mar 25 13:23:06 2014 +
>
> drm/i915: Invalidate our pages under memory pressure
>
> Testcase: igt/gem_mmap/new-object
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79005
> Signed-off-by: Chris Wilson
> Tested-by: Guo Jinxian
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_gem.c | 26 +-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 9cb7c1908279..31b9a04bd543 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4668,6 +4668,30 @@ struct drm_i915_gem_object
> *i915_gem_alloc_object(struct drm_device *dev,
> return obj;
> }
>
> +static bool discard_backing_storage(struct drm_i915_gem_object *obj)
> +{
> + /* If we are the last user of the backing storage (be it shmemfs
> + * pages or stolen etc), we know that the pages are going to be
> + * immediately released. In this case, we can then skip copying
> + * back the contents from the GPU.
> + */
> +
> + if (obj->madv != I915_MADV_WILLNEED)
> + return false;
> +
> + if (obj->base.filp == NULL)
> + return true;
> +
> + /* At first glance, this looks racy, but then again so would be
> + * userspace racing mmap against close. However, the first external
> + * reference to the filp can only be obtained through the
> + * i915_gem_mmap_ioctl() which safeguards us against the user
> + * acquiring such a reference whilst we are in the middle of
> + * freeing the object.
> + */
> + return atomic_long_read(&obj->base.filp->f_count) == 1;
> +}
> +
> void i915_gem_free_object(struct drm_gem_object *gem_obj)
> {
> struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
> @@ -4705,7 +4729,7 @@ void i915_gem_free_object(struct drm_gem_object
> *gem_obj)
>
> if (WARN_ON(obj->pages_pin_count))
> obj->pages_pin_count = 0;
> - if (obj->madv != __I915_MADV_PURGED)
> + if (discard_backing_storage(obj))
> obj->madv = I915_MADV_DONTNEED;
> i915_gem_object_put_pages(obj);
> i915_gem_object_free_mmap_offset(obj);
> --
> 2.0.0.rc2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/5] drm/i915: Fix mmio vs. CS flip race on ILK+
Reviewed the code. Everything looks good, so
Reviewed-by: Sourab Gupta
On Wed, May 21, 2014 at 6:09 AM, Rodrigo Vivi wrote:
> needs a small rebase but everything looks good for me so
> Reviewed-by: Rodrigo Vivi
>
>
> On Tue, Apr 15, 2014 at 11:41 AM, wrote:
>
>> From: Ville Syrjälä
>>
>> Starting from ILK, mmio flips also cause a flip done interrupt to be
>> signalled. This means if we first do a set_base and follow it
>> immediately with the CS flip, we might mistake the flip done interrupt
>> caused by the set_base as the flip done interrupt caused by the CS
>> flip.
>>
>> The hardware has a flip counter which increments every time a mmio or
>> CS flip is issued. It basically counts the number of DSPSURF register
>> writes. This means we can sample the counter before we put the CS
>> flip into the ring, and then when we get a flip done interrupt we can
>> check whether the CS flip has actually performed the surface address
>> update, or if the interrupt was caused by a previous but yet
>> unfinished mmio flip.
>>
>> Even with the flip counter we still have a race condition of the CS flip
>> base address update happens after the mmio flip done interrupt was
>> raised but not yet processed by the driver. When the interrupt is
>> eventually processed, the flip counter will already indicate that the
>> CS flip has been executed, but it would not actually complete until the
>> next start of vblank. We can use the DSPSURFLIVE register to check
>> whether the hardware is actually scanning out of the buffer we expect,
>> or if we managed hit this race window.
>>
>> This covers all the cases where the CS flip actually changes the base
>> address. If the base address remains unchanged, we might still complete
>> the CS flip before it has actually completed. But since the address
>> didn't change anyway, the premature flip completion can't result in
>> userspace overwriting data that's still being scanned out.
>>
>> CTG already has the flip counter and DSPSURFLIVE registers, and
>> although the flip done interrupt is still limited to CS flips alone,
>> the code now also checks the flip counter on CTG as well.
>>
>> v2: s/dspsurf/gtt_offset/ (Chris)
>>
>> Testcase: igt/kms_mmio_vs_cs_flip/setcrtc_vs_cs_flip
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73027
>> Signed-off-by: Ville Syrjälä
>> ---
>> drivers/gpu/drm/i915/i915_reg.h | 1 +
>> drivers/gpu/drm/i915/intel_display.c | 73
>>
>> drivers/gpu/drm/i915/intel_drv.h | 2 +
>> 3 files changed, 69 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 8f84555..c28169c 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -3638,6 +3638,7 @@ enum punit_power_well {
>> #define _PIPEA_FRMCOUNT_GM45 0x70040
>> #define _PIPEA_FLIPCOUNT_GM45 0x70044
>> #define PIPE_FRMCOUNT_GM45(pipe) _PIPE2(pipe, _PIPEA_FRMCOUNT_GM45)
>> +#define PIPE_FLIPCOUNT_GM45(pipe) _PIPE2(pipe, _PIPEA_FLIPCOUNT_GM45)
>>
>> /* Cursor A & B regs */
>> #define _CURACNTR (dev_priv->info.display_mmio_offset +
>> 0x70080)
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 1390ab5..32c6c16 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -8577,6 +8577,48 @@ void intel_finish_page_flip_plane(struct
>> drm_device *dev, int plane)
>> do_intel_finish_page_flip(dev, crtc);
>> }
>>
>> +/* Is 'a' after or equal to 'b'? */
>> +static bool flip_count_after_eq(u32 a, u32 b)
>> +{
>> + return !((a - b) & 0x8000);
>> +}
>> +
>> +static bool page_flip_finished(struct intel_crtc *crtc)
>> +{
>> + struct drm_device *dev = crtc->base.dev;
>> + struct drm_i915_private *dev_priv = dev->dev_private;
>> +
>> + /*
>> +* The relevant registers doen't exist on pre-ctg.
>> +* As the flip done interrupt doesn't trigger for mmio
>> +* flips on gmch platforms, a flip count check isn't
>> +* really needed there. But since ctg has the registers,
>> +* include it in the check anyway.
>> +*/
>> + if (INTEL_INFO(dev)->gen < 5 && !IS_G4X(dev))
>> + return true;
>> +
>> + /*
>> +* A DSPSURFLIVE check isn't enough in case the mmio and CS flips
>> +* used the same base address. In that case the mmio flip might
>> +* have completed, but the CS hasn't even executed the flip yet.
>> +*
>> +* A flip count check isn't enough as the CS might have updated
>> +* the base address just after start of vblank, but before we
>> +* managed to process the interrupt. This means we'd complete the
>> +* CS flip too soon.
>> +*
>> +* Combining both checks should get us a good enough result. It
>> may
>> +* still happen that the CS flip has been executed,
[Intel-gfx] [PATCH] drm/i915: Hold CRTC lock whilst freezing the planes
Daniel keeps on ramping up the warning level of the DRM and our display
core to make it complain whenever the locking rules are not followed.
This caught
commit 24576d23976746cb52e7700c4cadbf4bc1bc3472
Author: Jesse Barnes
Date: Tue Mar 26 09:25:45 2013 -0700
drm/i915: enable VT switchless resume v3
introducing an unlocked access to the CRTC whilst disabling it for
suspend.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78114
Signed-off-by: Chris Wilson
Cc: Jesse Barnes
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 591762c26af4..8450569ff42c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -532,8 +532,11 @@ static int i915_drm_freeze(struct drm_device *dev)
* for _thaw.
*/
mutex_lock(&dev->mode_config.mutex);
- for_each_crtc(dev, crtc)
+ for_each_crtc(dev, crtc) {
+ mutex_lock(&crtc->mutex);
dev_priv->display.crtc_disable(crtc);
+ mutex_unlock(&crtc->mutex);
+ }
mutex_unlock(&dev->mode_config.mutex);
intel_modeset_suspend_hw(dev);
--
2.0.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Hold CRTC lock whilst freezing the planes
On Thu, May 22, 2014 at 09:44:40AM +0100, Chris Wilson wrote:
> Daniel keeps on ramping up the warning level of the DRM and our display
> core to make it complain whenever the locking rules are not followed.
> This caught
>
> commit 24576d23976746cb52e7700c4cadbf4bc1bc3472
> Author: Jesse Barnes
> Date: Tue Mar 26 09:25:45 2013 -0700
>
> drm/i915: enable VT switchless resume v3
>
> introducing an unlocked access to the CRTC whilst disabling it for
> suspend.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78114
> Signed-off-by: Chris Wilson
> Cc: Jesse Barnes
> Reviewed-by: Daniel Vetter
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 591762c26af4..8450569ff42c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -532,8 +532,11 @@ static int i915_drm_freeze(struct drm_device *dev)
>* for _thaw.
>*/
> mutex_lock(&dev->mode_config.mutex);
> - for_each_crtc(dev, crtc)
> + for_each_crtc(dev, crtc) {
> + mutex_lock(&crtc->mutex);
> dev_priv->display.crtc_disable(crtc);
> + mutex_unlock(&crtc->mutex);
> + }
> mutex_unlock(&dev->mode_config.mutex);
>
> intel_modeset_suspend_hw(dev);
> --
> 2.0.0.rc2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] tests/drv_hangman: Convert test from shell script to c
On Wed, May 21, 2014 at 03:40:15PM +, Mateo Lozano, Oscar wrote: > > -Original Message- > > From: Mika Kuoppala [mailto:mika.kuopp...@linux.intel.com] > > Sent: Tuesday, May 20, 2014 12:56 PM > > To: intel-gfx@lists.freedesktop.org > > Cc: Mateo Lozano, Oscar > > Subject: [PATCH 1/2] tests/drv_hangman: Convert test from shell script to c > > > > Mixing script and standlone tests didn't mix well with the strict > > i915_ring_stop > > flags handling. Also squash drv_missed_irq_hang to the new test. > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78322 > > Suggested-by: Daniel Vetter > > Signed-off-by: Mika Kuoppala > > --- > > tests/Makefile.sources|3 +- > > tests/drv_hangman | 70 - > > tests/drv_hangman.c | 357 > > + > > tests/drv_missed_irq_hang | 70 - > > I am missing a tests/.gitignore entry > Other than that: Reviewed-by: Oscar Mateo The nop batch isn't good enough to reliably provoke a stall for the gpu. Without that the missed irq test won't work. The script uses some pretty expensive blitter workload (gem_exec_blt). Since patch 1 fixes a regresssion I think we should just take out those subtests and keep the missed_irq script for now so that we can push this series. -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 http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/crtc: Add property for aspect ratio
Added a property to enable user space to set aspect ratio.
This patch contains declaration of the property and code to create the
property.
Signed-off-by: Vandana Kannan
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_crtc.c | 31 +++
include/drm/drm_crtc.h | 2 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 37a3e07..84d359e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -139,6 +139,12 @@ static const struct drm_prop_enum_list
drm_scaling_mode_enum_list[] =
{ DRM_MODE_SCALE_ASPECT, "Full aspect" },
};
+static const struct drm_prop_enum_list drm_aspect_ratio_enum_list[] = {
+ { HDMI_PICTURE_ASPECT_NONE, "Automatic" },
+ { HDMI_PICTURE_ASPECT_4_3, "4:3" },
+ { HDMI_PICTURE_ASPECT_16_9, "16:9" },
+};
+
/*
* Non-global properties, but "required" for certain connectors.
*/
@@ -1344,6 +1350,31 @@ int drm_mode_create_scaling_mode_property(struct
drm_device *dev)
EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
/**
+ * drm_mode_create_aspect_ratio_property - create aspect ratio property
+ * @dev: DRM device
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ */
+int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
+{
+ struct drm_property *aspect_ratio;
+
+ if (dev->mode_config.aspect_ratio_property)
+ return 0;
+
+ aspect_ratio =
+ drm_property_create_enum(dev, 0, "aspect ratio",
+ drm_aspect_ratio_enum_list,
+ ARRAY_SIZE(drm_aspect_ratio_enum_list));
+
+ dev->mode_config.aspect_ratio_property = aspect_ratio;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
+
+/**
* drm_mode_create_dirty_property - create dirty property
* @dev: DRM device
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5c1c31c..1149617 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -801,6 +801,7 @@ struct drm_mode_config {
/* Optional properties */
struct drm_property *scaling_mode_property;
+ struct drm_property *aspect_ratio_property;
struct drm_property *dirty_info_property;
/* dumb ioctl parameters */
@@ -971,6 +972,7 @@ extern int drm_mode_create_dvi_i_properties(struct
drm_device *dev);
extern int drm_mode_create_tv_properties(struct drm_device *dev, int
num_formats,
char *formats[]);
extern int drm_mode_create_scaling_mode_property(struct drm_device *dev);
+extern int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
extern int drm_mode_create_dirty_info_property(struct drm_device *dev);
extern const char *drm_get_encoder_name(const struct drm_encoder *encoder);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/edid: Check for user aspect ratio input
In case user has specified an input for aspect ratio through the property, then the user space value for PAR would take preference over the value from CEA mode list. Signed-off-by: Vandana Kannan Cc: dri-de...@lists.freedesktop.org --- drivers/gpu/drm/drm_edid.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 7a4fd2e..05db619 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -3657,8 +3657,13 @@ drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame, frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE; - /* Populate picture aspect ratio from CEA mode list */ - if (frame->video_code > 0) + /* Populate picture aspect ratio from either CEA mode list or +* user input + */ + if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 || + mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9) + frame->picture_aspect = mode->picture_aspect_ratio; + else if (frame->video_code > 0) frame->picture_aspect = drm_get_cea_aspect_ratio( frame->video_code); -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Add aspect ratio property for HDMI
Create and attach the drm property to set aspect ratio. If there is no user
specified value, then PAR_NONE/Automatic option is set by default. User can
select aspect ratio 4:3 or 16:9. The aspect ratio selected by user would
come into effect with a mode set.
Signed-off-by: Vandana Kannan
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 31 +++
3 files changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 13495a4..8dc5f59 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2691,6 +2691,11 @@ int vlv_freq_opcode(struct drm_i915_private *dev_priv,
int val);
#define INTEL_BROADCAST_RGB_FULL 1
#define INTEL_BROADCAST_RGB_LIMITED 2
+/* Aspect ratio property */
+#define INTEL_ASPECT_RATIO_AUTO 0
+#define INTEL_ASPECT_RATIO_4_3 1
+#define INTEL_ASPECT_RATIO_16_9 2
+
static inline uint32_t i915_vgacntrl_reg(struct drm_device *dev)
{
if (HAS_PCH_SPLIT(dev))
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 287b89e..f9f19b6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -488,6 +488,7 @@ struct intel_hdmi {
bool has_audio;
enum hdmi_force_audio force_audio;
bool rgb_quant_range_selectable;
+ enum hdmi_picture_aspect aspect_ratio;
void (*write_infoframe)(struct drm_encoder *encoder,
enum hdmi_infoframe_type type,
const void *frame, ssize_t len);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 171d0dd..2c6aa76 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -367,6 +367,9 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder
*encoder,
union hdmi_infoframe frame;
int ret;
+ /* Set user selected PAR to incoming mode's member */
+ adjusted_mode->picture_aspect_ratio = intel_hdmi->aspect_ratio;
+
ret = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
adjusted_mode);
if (ret < 0) {
@@ -1124,6 +1127,23 @@ intel_hdmi_set_property(struct drm_connector *connector,
goto done;
}
+ if (property == connector->dev->mode_config.aspect_ratio_property) {
+ switch (val) {
+ case INTEL_ASPECT_RATIO_AUTO:
+ intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+ break;
+ case INTEL_ASPECT_RATIO_4_3:
+ intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_4_3;
+ break;
+ case INTEL_ASPECT_RATIO_16_9:
+ intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_16_9;
+ break;
+ default:
+ return -EINVAL;
+ }
+ goto done;
+ }
+
return -EINVAL;
done:
@@ -1416,11 +1436,22 @@ static const struct drm_encoder_funcs
intel_hdmi_enc_funcs = {
};
static void
+intel_attach_aspect_ratio_property(struct drm_connector *connector)
+{
+ drm_mode_create_aspect_ratio_property(connector->dev);
+ drm_object_attach_property(&connector->base,
+ connector->dev->mode_config.aspect_ratio_property,
+ HDMI_PICTURE_ASPECT_NONE);
+}
+
+static void
intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector
*connector)
{
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_hdmi->color_range_auto = true;
+ intel_attach_aspect_ratio_property(connector);
+ intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
}
void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Change Mipi register definitions
Re-define MIPI register definitions in such a way that most of
the existing DSI code can be re-used for future platforms. Register
definitions are re-written using MMIO offset variable, so that without
changing the existing sequence, same code can be generically applied.
V3: Addressing review comments by Damien and Ville, added follwing changes:
1. Replaced _PIPE with _TRANSCODER call, no branching added.
2. Removed all the un-necessary formatting changes from previous patch.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 344 ++-
1 file changed, 196 insertions(+), 148 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c12a858..38de0e9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5659,7 +5659,8 @@ enum punit_power_well {
#define _MIPIA_PORT_CTRL (VLV_DISPLAY_BASE + 0x61190)
#define _MIPIB_PORT_CTRL (VLV_DISPLAY_BASE + 0x61700)
-#define MIPI_PORT_CTRL(pipe) _PIPE(pipe, _MIPIA_PORT_CTRL,
_MIPIB_PORT_CTRL)
+#define MIPI_PORT_CTRL(tc) _TRANSCODER(tc, \
+ _MIPIA_PORT_CTRL, _MIPIB_PORT_CTRL)
#define DPI_ENABLE(1 << 31) /* A + B */
#define MIPIA_MIPI4DPHY_DELAY_COUNT_SHIFT 27
#define MIPIA_MIPI4DPHY_DELAY_COUNT_MASK (0xf << 27)
@@ -5701,18 +5702,20 @@ enum punit_power_well {
#define _MIPIA_TEARING_CTRL(VLV_DISPLAY_BASE + 0x61194)
#define _MIPIB_TEARING_CTRL(VLV_DISPLAY_BASE + 0x61704)
-#define MIPI_TEARING_CTRL(pipe)_PIPE(pipe,
_MIPIA_TEARING_CTRL, _MIPIB_TEARING_CTRL)
+#define MIPI_TEARING_CTRL(tc) _TRANSCODER(tc, \
+ _MIPIA_TEARING_CTRL, _MIPIB_TEARING_CTRL)
#define TEARING_EFFECT_DELAY_SHIFT0
#define TEARING_EFFECT_DELAY_MASK (0x << 0)
/* XXX: all bits reserved */
-#define _MIPIA_AUTOPWG (VLV_DISPLAY_BASE + 0x611a0)
+#define _MIPIA_AUTOPWG (dev_priv->mipi_mmio_base + 0x611a0)
/* MIPI DSI Controller and D-PHY registers */
-#define _MIPIA_DEVICE_READY(VLV_DISPLAY_BASE + 0xb000)
-#define _MIPIB_DEVICE_READY(VLV_DISPLAY_BASE + 0xb800)
-#define MIPI_DEVICE_READY(pipe)_PIPE(pipe,
_MIPIA_DEVICE_READY, _MIPIB_DEVICE_READY)
+#define _MIPIA_DEVICE_READY(dev_priv->mipi_mmio_base + 0xb000)
+#define _MIPIB_DEVICE_READY(dev_priv->mipi_mmio_base + 0xb800)
+#define MIPI_DEVICE_READY(tc) _TRANSCODER(tc, \
+ _MIPIA_DEVICE_READY, _MIPIB_DEVICE_READY)
#define BUS_POSSESSION(1 << 3) /* set
to give bus to receiver */
#define ULPS_STATE_MASK (3 << 1)
#define ULPS_STATE_ENTER (2 << 1)
@@ -5720,12 +5723,14 @@ enum punit_power_well {
#define ULPS_STATE_NORMAL_OPERATION (0 << 1)
#define DEVICE_READY (1 << 0)
-#define _MIPIA_INTR_STAT (VLV_DISPLAY_BASE + 0xb004)
-#define _MIPIB_INTR_STAT (VLV_DISPLAY_BASE + 0xb804)
-#define MIPI_INTR_STAT(pipe) _PIPE(pipe, _MIPIA_INTR_STAT,
_MIPIB_INTR_STAT)
-#define _MIPIA_INTR_EN (VLV_DISPLAY_BASE + 0xb008)
-#define _MIPIB_INTR_EN (VLV_DISPLAY_BASE + 0xb808)
-#define MIPI_INTR_EN(pipe) _PIPE(pipe, _MIPIA_INTR_EN,
_MIPIB_INTR_EN)
+#define _MIPIA_INTR_STAT (dev_priv->mipi_mmio_base + 0xb004)
+#define _MIPIB_INTR_STAT (dev_priv->mipi_mmio_base + 0xb804)
+#define MIPI_INTR_STAT(tc) _TRANSCODER(tc, \
+ _MIPIA_INTR_STAT, _MIPIB_INTR_STAT)
+#define _MIPIA_INTR_EN (dev_priv->mipi_mmio_base + 0xb008)
+#define _MIPIB_INTR_EN (dev_priv->mipi_mmio_base + 0xb808)
+#define MIPI_INTR_EN(tc) _TRANSCODER(tc, \
+ _MIPIA_INTR_EN, _MIPIB_INTR_EN)
#define TEARING_EFFECT(1 << 31)
#define SPL_PKT_SENT_INTERRUPT(1 << 30)
#define GEN_READ_DATA_AVAIL (1 << 29)
@@ -5759,9 +5764,10 @@ enum punit_power_well {
#define RXSOT_SYNC_ERROR (1 << 1)
#define RXSOT_ERROR (1 << 0)
-#define _MIPIA_DSI_FUNC_PRG(VLV_DISPLAY_BASE + 0xb00c)
-#define _MIPIB_DSI_FUNC_PRG(VLV_DISPLAY_BASE + 0xb80c)
-#define MIPI_DSI_FUNC_PRG(pipe)_PIPE(pipe,
_MIPIA_DSI_FUNC_PRG, _MIPIB_DSI_FUNC_PRG)
+#define _MIPIA_DSI_FUNC_PRG(dev_priv->mipi_mmio_base +
Re: [Intel-gfx] [PATCH 1/3] drm/crtc: Add property for aspect ratio
On Thu, May 22, 2014 at 04:50:48PM +0530, Vandana Kannan wrote:
> Added a property to enable user space to set aspect ratio.
> This patch contains declaration of the property and code to create the
> property.
>
> Signed-off-by: Vandana Kannan
> Cc: dri-de...@lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_crtc.c | 31 +++
> include/drm/drm_crtc.h | 2 ++
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 37a3e07..84d359e 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -139,6 +139,12 @@ static const struct drm_prop_enum_list
> drm_scaling_mode_enum_list[] =
> { DRM_MODE_SCALE_ASPECT, "Full aspect" },
> };
>
> +static const struct drm_prop_enum_list drm_aspect_ratio_enum_list[] = {
> + { HDMI_PICTURE_ASPECT_NONE, "Automatic" },
> + { HDMI_PICTURE_ASPECT_4_3, "4:3" },
> + { HDMI_PICTURE_ASPECT_16_9, "16:9" },
> +};
This seems like it should be either an HDMI specific property, since it
uses values defined by HDMI/CEA. Alternatively we could introduce some
new generic enumeration and translate that to the HDMI/CEA equivalent in
the AVI infoframe helpers.
Doing so would allow us to add aspect ratios different from what HDMI or
CEA define.
> /*
> * Non-global properties, but "required" for certain connectors.
> */
> @@ -1344,6 +1350,31 @@ int drm_mode_create_scaling_mode_property(struct
> drm_device *dev)
> EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>
> /**
> + * drm_mode_create_aspect_ratio_property - create aspect ratio property
> + * @dev: DRM device
> + *
> + * Called by a driver the first time it's needed, must be attached to desired
> + * connectors.
> + */
> +int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
> +{
> + struct drm_property *aspect_ratio;
> +
> + if (dev->mode_config.aspect_ratio_property)
> + return 0;
> +
> + aspect_ratio =
> + drm_property_create_enum(dev, 0, "aspect ratio",
> + drm_aspect_ratio_enum_list,
> + ARRAY_SIZE(drm_aspect_ratio_enum_list));
> +
> + dev->mode_config.aspect_ratio_property = aspect_ratio;
I don't think you need the temporary aspect_ratio variable here. Can't
you directly assign the new property to .aspect_ratio_property?
Thierry
pgpDMJHEuIyyG.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/edid: Check for user aspect ratio input
On Thu, May 22, 2014 at 04:50:49PM +0530, Vandana Kannan wrote: > In case user has specified an input for aspect ratio through the property, > then the user space value for PAR would take preference over the value from > CEA mode list. > > Signed-off-by: Vandana Kannan > Cc: dri-de...@lists.freedesktop.org > --- > drivers/gpu/drm/drm_edid.c | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 7a4fd2e..05db619 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -3657,8 +3657,13 @@ drm_hdmi_avi_infoframe_from_display_mode(struct > hdmi_avi_infoframe *frame, > > frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE; > > - /* Populate picture aspect ratio from CEA mode list */ > - if (frame->video_code > 0) > + /* Populate picture aspect ratio from either CEA mode list or > + * user input > + */ This comment is mangled, it should look like this: /* * Populate... */ And perhaps to clarify that user input takes precedence over CEA you could list it first in the comment, like so for example: /* * Populate picture aspect ratio from either user input (if specified) * or from the CEA mode. */ Also can you please resend patch 3/3 to dri-de...@lists.freedesktop.org as well so we can see how this is used in a driver? Thierry pgpjyCBAFY3xk.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: remove user GTT mappings early during runtime suspend
On 07/05/2014 17:57, Imre Deak wrote:
Currently user space can access GEM buffers mapped to GTT through
existing mappings concurrently while the platform specific suspend
handlers are running. Since these handlers may change the HW state in a
way that would break such accesses, remove the mappings before calling
the handlers. Spotted by Ville.
Also Chris pointed out that the lists that i915_gem_release_all_mmaps()
walks through need dev->struct_mutex, so take this lock. There is a
potential deadlock against a concurrent RPM resume, resolve this by
aborting and rescheduling the suspend (Daniel).
v2:
- take struct_mutex around i915_gem_release_all_mmaps() (Chris, Daniel)
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4024e16..0c9858c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -36,6 +36,7 @@
#include
#include
+#include
#include
static struct drm_driver driver;
@@ -1315,6 +1316,30 @@ static int intel_runtime_suspend(struct device *device)
DRM_DEBUG_KMS("Suspending device\n");
/*
+* We could deadlock here in case another thread holding struct_mutex
+* calls RPM suspend concurrently, since the RPM suspend will wait
+* first for this RPM suspend to finish. In this case the concurrent
+* RPM resume will be followed by its RPM suspend counterpart. Still
+* for consistency return -EAGAIN, which will reschedule this suspend.
+*/
+ if (!mutex_trylock(&dev->struct_mutex)) {
+ DRM_DEBUG_KMS("device lock contention, deffering suspend\n");
+ /*
+* Bump the expiration timestamp, otherwise the suspend won't
+* be rescheduled.
+*/
+ pm_runtime_mark_last_busy(device);
+
+ return -EAGAIN;
+ }
+ /*
+* We are safe here against re-faults, since the fault handler takes
+* an RPM reference.
+*/
+ i915_gem_release_all_mmaps(dev_priv);
+ mutex_unlock(&dev->struct_mutex);
+
+ /*
* rps.work can't be rearmed here, since we get here only after making
* sure the GPU is idle and the RPS freq is set to the minimum. See
* intel_mark_idle().
@@ -1340,8 +1365,6 @@ static int intel_runtime_suspend(struct device *device)
return ret;
}
- i915_gem_release_all_mmaps(dev_priv);
-
del_timer_sync(&dev_priv->gpu_error.hangcheck_timer);
dev_priv->pm.suspended = true;
Looks good to me.
Reviewed-by: Robert Beckett
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Add null state batch to active list
On Wed, May 21, 2014 at 07:01:06PM +0300, Mika Kuoppala wrote:
> From: Mika Kuoppala
>
> for proper refcounting to take place as we use
> i915_add_request() for it.
>
> i915_add_request() also takes the context for the request
> from ring->last_context so move the null state batch
> submission after the ring context has been set.
>
> v2: we need to check for correct ring now (Ville Syrjälä)
> v3: no need to expose i915_gem_move_object_to_active (Chris Wilson)
> v4: cargoculted vma/active/inactive error handling removed (Chris Wilson)
>
> Cc: Ville Syrjälä
> Cc: Chris Wilson
> Cc: Damien Lespiau
> Signed-off-by: Mika Kuoppala
> Signed-off-by: Daniel Vetter
Ok, merged instead of v3 with Chris' irc r-b.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 16
> drivers/gpu/drm/i915/i915_gem_render_state.c |8 ++--
> 2 files changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index f220c94..6a2d847a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -700,21 +700,21 @@ static int do_switch(struct intel_ring_buffer *ring,
> /* obj is kept alive until the next request by its active ref */
> i915_gem_object_ggtt_unpin(from->obj);
> i915_gem_context_unreference(from);
> - } else {
> - if (to->is_initialized == false) {
> - ret = i915_gem_render_state_init(ring);
> - if (ret)
> - DRM_ERROR("init render state: %d\n", ret);
> - }
> }
>
> - to->is_initialized = true;
> -
> done:
> i915_gem_context_reference(to);
> ring->last_context = to;
> to->last_ring = ring;
>
> + if (ring->id == RCS && !to->is_initialized && from == NULL) {
> + ret = i915_gem_render_state_init(ring);
> + if (ret)
> + DRM_ERROR("init render state: %d\n", ret);
> + }
> +
> + to->is_initialized = true;
> +
> return 0;
>
> unpin_out:
> diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
> b/drivers/gpu/drm/i915/i915_gem_render_state.c
> index 392aa7b..cfbf6fc 100644
> --- a/drivers/gpu/drm/i915/i915_gem_render_state.c
> +++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
> @@ -164,9 +164,11 @@ int i915_gem_render_state_init(struct intel_ring_buffer
> *ring)
> const int gen = INTEL_INFO(ring->dev)->gen;
> struct i915_render_state *so;
> const struct intel_renderstate_rodata *rodata;
> - u32 seqno;
> int ret;
>
> + if (WARN_ON(ring->id != RCS))
> + return -ENOENT;
> +
> rodata = render_state_get_rodata(ring->dev, gen);
> if (rodata == NULL)
> return 0;
> @@ -186,8 +188,10 @@ int i915_gem_render_state_init(struct intel_ring_buffer
> *ring)
> if (ret)
> goto out;
>
> - ret = i915_add_request(ring, &seqno);
> + i915_vma_move_to_active(i915_gem_obj_to_ggtt(so->obj), ring);
>
> + ret = __i915_add_request(ring, NULL, so->obj, NULL);
> + /* __i915_add_request moves object to inactive if it fails */
> out:
> render_state_free(so);
> return ret;
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/crtc: Add property for aspect ratio
On Thu, May 22, 2014 at 04:50:48PM +0530, Vandana Kannan wrote:
> Added a property to enable user space to set aspect ratio.
> This patch contains declaration of the property and code to create the
> property.
>
> Signed-off-by: Vandana Kannan
> Cc: dri-de...@lists.freedesktop.org
Documentation update is missing. Also for such patch series I recommend to
post the entire patch series to dri-devel and intel-gfx. Otherwise people
on dri-devel don't see how the new code is used and so can't really review
it properly.
-Daniel
> ---
> drivers/gpu/drm/drm_crtc.c | 31 +++
> include/drm/drm_crtc.h | 2 ++
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 37a3e07..84d359e 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -139,6 +139,12 @@ static const struct drm_prop_enum_list
> drm_scaling_mode_enum_list[] =
> { DRM_MODE_SCALE_ASPECT, "Full aspect" },
> };
>
> +static const struct drm_prop_enum_list drm_aspect_ratio_enum_list[] = {
> + { HDMI_PICTURE_ASPECT_NONE, "Automatic" },
> + { HDMI_PICTURE_ASPECT_4_3, "4:3" },
> + { HDMI_PICTURE_ASPECT_16_9, "16:9" },
> +};
> +
> /*
> * Non-global properties, but "required" for certain connectors.
> */
> @@ -1344,6 +1350,31 @@ int drm_mode_create_scaling_mode_property(struct
> drm_device *dev)
> EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>
> /**
> + * drm_mode_create_aspect_ratio_property - create aspect ratio property
> + * @dev: DRM device
> + *
> + * Called by a driver the first time it's needed, must be attached to desired
> + * connectors.
> + */
> +int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
> +{
> + struct drm_property *aspect_ratio;
> +
> + if (dev->mode_config.aspect_ratio_property)
> + return 0;
> +
> + aspect_ratio =
> + drm_property_create_enum(dev, 0, "aspect ratio",
> + drm_aspect_ratio_enum_list,
> + ARRAY_SIZE(drm_aspect_ratio_enum_list));
> +
> + dev->mode_config.aspect_ratio_property = aspect_ratio;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
> +
> +/**
> * drm_mode_create_dirty_property - create dirty property
> * @dev: DRM device
> *
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 5c1c31c..1149617 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -801,6 +801,7 @@ struct drm_mode_config {
>
> /* Optional properties */
> struct drm_property *scaling_mode_property;
> + struct drm_property *aspect_ratio_property;
> struct drm_property *dirty_info_property;
>
> /* dumb ioctl parameters */
> @@ -971,6 +972,7 @@ extern int drm_mode_create_dvi_i_properties(struct
> drm_device *dev);
> extern int drm_mode_create_tv_properties(struct drm_device *dev, int
> num_formats,
>char *formats[]);
> extern int drm_mode_create_scaling_mode_property(struct drm_device *dev);
> +extern int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
> extern int drm_mode_create_dirty_info_property(struct drm_device *dev);
> extern const char *drm_get_encoder_name(const struct drm_encoder *encoder);
>
> --
> 1.9.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: fix possible RPM ref leaking during RPS disabling
On 13/05/2014 14:54, Daniel Vetter wrote: On Tue, May 13, 2014 at 04:46:10PM +0300, Imre Deak wrote: On Mon, 2014-05-12 at 19:51 +0200, Daniel Vetter wrote: On Mon, May 12, 2014 at 06:35:04PM +0300, Imre Deak wrote: In commit c6df39b5ea6342323a42edfbeeca0a28c643d7ae Author: Imre Deak Date: Mon Apr 14 20:24:29 2014 +0300 drm/i915: get a runtime PM ref for the deferred GT powersave enabling I added an RPM get-ref when enabling RPS from a deferred work, but forgot to add the corresponding put-ref when canceling the work. This may leave RPM disabled. Signed-off-by: Imre Deak Could we intentionally hit this by e.g. racing a suspend/resume against runtime pm? E.g. 1. disable all outputs, make sure we've entered runtime pm 2. set runtime autosuspend delay to 0 3. suspend/resume 4. autosuspend (hopefully, my understanding is a bit unclear) ->Boom Would look nice as an igt subtest if it works ;-) Yep, works consistently as expected both before and after the fix. I pushed the new subtest, please add here: Testcase: igt/pm_pc8/system-suspend Now I'm confused: I expected this to blow up without your fix here, and not work with or without it?! Please unconfuse ... -Daniel Im not sure what you are expecting to go boom. It is pretty difficult to get a race between suspend/resume and runtime pm. During system suspend, the pm core grabs a runtime ref without resume callbacks, and releases it on the resume. (see https://www.kernel.org/doc/Documentation/power/runtime_pm.txt part 6). Also, as i915_drm_freeze does a runtime pm get, at step 3, it will cause a runtime resume before doing the system suspend. On the system resume, it will do a runtime pm put, which will cause a runtime suspend due to autosuspend delay being 0, and so step 4, autosuspend will occur. This should all work fine (assuming the patch is applied to handle any refcounting between back to back resume->suspend which cancels the enable before it is executed). It all looks fine to me. Reviewed-by: Robert Beckett ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 3/9] drm/i915: Make sprite updates atomic
On Tue, Apr 29, 2014 at 01:35:46PM +0300, ville.syrj...@linux.intel.com wrote:
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 96ae78d..d8b540b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -401,6 +401,8 @@ struct intel_crtc {
> /* watermarks currently being used */
> struct intel_pipe_wm active;
> } wm;
> +
> + wait_queue_head_t vbl_wait;
> };
A bit late, but found something: Why can't we use dev->vblank[crtc].queue
here? We reuse all the vblank infrastructure already ...
If you want pretty just add a tiny helper function
wait_queue_head_t *drm_crtc_vblank_waitqueue(struct drm_crtc *crtc)
{
return &dev->vblank[drm_crtc_index(crtc)].queue;
}
somewhere.
I feel guilty here since I've killed Akash's patch over adding a new
vblank wait queue and let yours slip through ;-) Can you please take care
of this?
Thanks, 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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/6] Execlists prep-work
From: Oscar Mateo These patches contain refactoring and preparatory work for Execlists [1]. [1http://lists.freedesktop.org/archives/intel-gfx/2014-May/044847.html] http://lists.freedesktop.org/archives/intel-gfx/2014-May/044847.html Oscar Mateo (6): drm/i915: s/intel_ring_buffer/intel_engine_cs drm/i915: Split the ringbuffers from the rings (1/3) drm/i915: Split the ringbuffers from the rings (2/3) drm/i915: Split the ringbuffers from the rings (3/3) drm/i915: s/i915_hw_context/intel_context drm/i915: Kill private_default_ctx off drivers/gpu/drm/i915/i915_cmd_parser.c | 24 +- drivers/gpu/drm/i915/i915_debugfs.c | 29 +-- drivers/gpu/drm/i915/i915_dma.c | 33 +-- drivers/gpu/drm/i915/i915_drv.h | 55 +++-- drivers/gpu/drm/i915/i915_gem.c | 62 +++--- drivers/gpu/drm/i915/i915_gem_context.c | 64 +++--- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 24 +- drivers/gpu/drm/i915/i915_gem_gtt.c | 18 +- drivers/gpu/drm/i915/i915_gem_gtt.h | 4 +- drivers/gpu/drm/i915/i915_gem_render_state.c | 2 +- drivers/gpu/drm/i915/i915_gpu_error.c| 12 +- drivers/gpu/drm/i915/i915_irq.c | 36 +-- drivers/gpu/drm/i915/i915_sysfs.c| 2 +- drivers/gpu/drm/i915/i915_trace.h| 26 +-- drivers/gpu/drm/i915/intel_display.c | 18 +- drivers/gpu/drm/i915/intel_drv.h | 4 +- drivers/gpu/drm/i915/intel_overlay.c | 12 +- drivers/gpu/drm/i915/intel_pm.c | 10 +- drivers/gpu/drm/i915/intel_ringbuffer.c | 318 +++ drivers/gpu/drm/i915/intel_ringbuffer.h | 127 ++- drivers/gpu/drm/i915/intel_uncore.c | 2 +- 21 files changed, 465 insertions(+), 417 deletions(-) -- 1.9.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/i915: Split the ringbuffers from the rings (2/3)
From: Oscar Mateo
This refactoring has been performed using the following Coccinelle
semantic script:
@@
struct intel_engine_cs r;
@@
(
- (r).obj
+ r.buffer->obj
|
- (r).virtual_start
+ r.buffer->virtual_start
|
- (r).head
+ r.buffer->head
|
- (r).tail
+ r.buffer->tail
|
- (r).space
+ r.buffer->space
|
- (r).size
+ r.buffer->size
|
- (r).effective_size
+ r.buffer->effective_size
|
- (r).last_retired_head
+ r.buffer->last_retired_head
)
@@
struct intel_engine_cs *r;
@@
(
- (r)->obj
+ r->buffer->obj
|
- (r)->virtual_start
+ r->buffer->virtual_start
|
- (r)->head
+ r->buffer->head
|
- (r)->tail
+ r->buffer->tail
|
- (r)->space
+ r->buffer->space
|
- (r)->size
+ r->buffer->size
|
- (r)->effective_size
+ r->buffer->effective_size
|
- (r)->last_retired_head
+ r->buffer->last_retired_head
)
@@
expression E;
@@
(
- LP_RING(E)->obj
+ LP_RING(E)->buffer->obj
|
- LP_RING(E)->virtual_start
+ LP_RING(E)->buffer->virtual_start
|
- LP_RING(E)->head
+ LP_RING(E)->buffer->head
|
- LP_RING(E)->tail
+ LP_RING(E)->buffer->tail
|
- LP_RING(E)->space
+ LP_RING(E)->buffer->space
|
- LP_RING(E)->size
+ LP_RING(E)->buffer->size
|
- LP_RING(E)->effective_size
+ LP_RING(E)->buffer->effective_size
|
- LP_RING(E)->last_retired_head
+ LP_RING(E)->buffer->last_retired_head
)
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_dma.c | 22 +++
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 6 +-
drivers/gpu/drm/i915/i915_irq.c | 8 +--
drivers/gpu/drm/i915/intel_ringbuffer.c | 102
drivers/gpu/drm/i915/intel_ringbuffer.h | 27 ++---
6 files changed, 75 insertions(+), 92 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index d5d4ed2..40a0176 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -64,7 +64,7 @@
* has access to the ring.
*/
#define RING_LOCK_TEST_WITH_RETURN(dev, file) do { \
- if (LP_RING(dev->dev_private)->obj == NULL) \
+ if (LP_RING(dev->dev_private)->buffer->obj == NULL)
\
LOCK_TEST_WITH_RETURN(dev, file); \
} while (0)
@@ -149,17 +149,17 @@ void i915_kernel_lost_context(struct drm_device * dev)
if (drm_core_check_feature(dev, DRIVER_MODESET))
return;
- ring->head = I915_READ_HEAD(ring) & HEAD_ADDR;
- ring->tail = I915_READ_TAIL(ring) & TAIL_ADDR;
- ring->space = ring->head - (ring->tail + I915_RING_FREE_SPACE);
- if (ring->space < 0)
- ring->space += ring->size;
+ ring->buffer->head = I915_READ_HEAD(ring) & HEAD_ADDR;
+ ring->buffer->tail = I915_READ_TAIL(ring) & TAIL_ADDR;
+ ring->buffer->space = ring->buffer->head - (ring->buffer->tail +
I915_RING_FREE_SPACE);
+ if (ring->buffer->space < 0)
+ ring->buffer->space += ring->buffer->size;
if (!dev->primary->master)
return;
master_priv = dev->primary->master->driver_priv;
- if (ring->head == ring->tail && master_priv->sarea_priv)
+ if (ring->buffer->head == ring->buffer->tail && master_priv->sarea_priv)
master_priv->sarea_priv->perf_boxes |= I915_BOX_RING_EMPTY;
}
@@ -202,7 +202,7 @@ static int i915_initialize(struct drm_device * dev,
drm_i915_init_t * init)
}
if (init->ring_size != 0) {
- if (LP_RING(dev_priv)->obj != NULL) {
+ if (LP_RING(dev_priv)->buffer->obj != NULL) {
i915_dma_cleanup(dev);
DRM_ERROR("Client tried to initialize ringbuffer in "
"GEM mode\n");
@@ -239,7 +239,7 @@ static int i915_dma_resume(struct drm_device * dev)
DRM_DEBUG_DRIVER("%s\n", __func__);
- if (ring->virtual_start == NULL) {
+ if (ring->buffer->virtual_start == NULL) {
DRM_ERROR("can not ioremap virtual address for"
" ring buffer\n");
return -ENOMEM;
@@ -361,7 +361,7 @@ static int i915_emit_cmds(struct drm_device * dev, int
*buffer, int dwords)
struct drm_i915_private *dev_priv = dev->dev_private;
int i, ret;
- if ((dwords+1) * sizeof(int) >= LP_RING(dev_priv)->size - 8)
+ if ((dwords+1) * sizeof(int) >= LP_RING(dev_priv)->buffer->size - 8)
return -EINVAL;
for (i = 0; i < dwords;) {
@@ -824,7 +824,7 @@ static int i915_irq_emit(struct drm_device *dev, void *data,
if (drm_core_check_feature(dev, DRIVER_MODESET))
[Intel-gfx] [PATCH 6/6] drm/i915: Kill private_default_ctx off
From: Oscar Mateo
It's barely alive now anyway, so give it the "coup de grâce".
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_debugfs.c | 7 ---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem_context.c | 14 --
3 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4f0f697..333dd12 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1858,6 +1858,10 @@ static int per_file_ctx(int id, void *ptr, void *data)
struct seq_file *m = data;
struct i915_hw_ppgtt *ppgtt = ctx_to_ppgtt(ctx);
+ if (i915_gem_context_is_default(ctx))
+ seq_puts(m, " default context:\n");
+ else
+ seq_printf(m, " context %d:\n", ctx->id);
ppgtt->debug_dump(ppgtt, m);
return 0;
@@ -1917,12 +1921,9 @@ static void gen6_ppgtt_info(struct seq_file *m, struct
drm_device *dev)
list_for_each_entry_reverse(file, &dev->filelist, lhead) {
struct drm_i915_file_private *file_priv = file->driver_priv;
- struct i915_hw_ppgtt *pvt_ppgtt;
- pvt_ppgtt = ctx_to_ppgtt(file_priv->private_default_ctx);
seq_printf(m, "proc: %s\n",
get_pid_task(file->pid, PIDTYPE_PID)->comm);
- seq_puts(m, " default context:\n");
idr_for_each(&file_priv->context_idr, per_file_ctx, m);
}
seq_printf(m, "ECOCHK: 0x%08x\n", I915_READ(GAM_ECOCHK));
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b9ab950..daa94c5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1765,7 +1765,6 @@ struct drm_i915_file_private {
} mm;
struct idr context_idr;
- struct intel_context *private_default_ctx;
atomic_t rps_wait_boost;
struct intel_engine_cs *bsd_ring;
};
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 2100f6e..3ffe308 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -497,10 +497,6 @@ static int context_idr_cleanup(int id, void *p, void *data)
{
struct intel_context *ctx = p;
- /* Ignore the default context because close will handle it */
- if (i915_gem_context_is_default(ctx))
- return 0;
-
i915_gem_context_unreference(ctx);
return 0;
}
@@ -508,17 +504,17 @@ static int context_idr_cleanup(int id, void *p, void
*data)
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file)
{
struct drm_i915_file_private *file_priv = file->driver_priv;
+ struct intel_context *ctx;
idr_init(&file_priv->context_idr);
mutex_lock(&dev->struct_mutex);
- file_priv->private_default_ctx =
- i915_gem_create_context(dev, file_priv, USES_FULL_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, file_priv, USES_FULL_PPGTT(dev));
mutex_unlock(&dev->struct_mutex);
- if (IS_ERR(file_priv->private_default_ctx)) {
+ if (IS_ERR(ctx)) {
idr_destroy(&file_priv->context_idr);
- return PTR_ERR(file_priv->private_default_ctx);
+ return PTR_ERR(ctx);
}
return 0;
@@ -530,8 +526,6 @@ void i915_gem_context_close(struct drm_device *dev, struct
drm_file *file)
idr_for_each(&file_priv->context_idr, context_idr_cleanup, NULL);
idr_destroy(&file_priv->context_idr);
-
- i915_gem_context_unreference(file_priv->private_default_ctx);
}
struct intel_context *
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915: Split the ringbuffers from the rings (1/3)
From: Oscar Mateo
As advanced by the previous patch, the ringbuffers and the engine
command streamers belong in different structs. This is so because,
while they used to be tightly coupled together, the new Logical
Ring Contexts (LRC for short) have a ringbuffer each.
In legacy code, we will use the buffer* pointer inside each ring
to get to the pertaining ringbuffer (the actual switch will be
done in the next patch). In the new Execlists code, this pointer
will be NULL and we will use instead the one inside the context
instead.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 53 -
drivers/gpu/drm/i915/intel_ringbuffer.h | 24 ++-
2 files changed, 68 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 748041a..9b406e42 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1422,8 +1422,16 @@ err_unref:
static int intel_init_ring_buffer(struct drm_device *dev,
struct intel_engine_cs *ring)
{
+ struct intel_ringbuffer *ringbuf = ring->buffer;
int ret;
+ if (ringbuf == NULL) {
+ ringbuf = kzalloc(sizeof(*ringbuf), GFP_KERNEL);
+ if (!ringbuf)
+ return -ENOMEM;
+ ring->buffer = ringbuf;
+ }
+
ring->dev = dev;
INIT_LIST_HEAD(&ring->active_list);
INIT_LIST_HEAD(&ring->request_list);
@@ -1435,18 +1443,18 @@ static int intel_init_ring_buffer(struct drm_device
*dev,
if (I915_NEED_GFX_HWS(dev)) {
ret = init_status_page(ring);
if (ret)
- return ret;
+ goto error;
} else {
BUG_ON(ring->id != RCS);
ret = init_phys_status_page(ring);
if (ret)
- return ret;
+ goto error;
}
ret = allocate_ring_buffer(ring);
if (ret) {
DRM_ERROR("Failed to allocate ringbuffer %s: %d\n", ring->name,
ret);
- return ret;
+ goto error;
}
/* Workaround an erratum on the i830 which causes a hang if
@@ -1459,9 +1467,18 @@ static int intel_init_ring_buffer(struct drm_device *dev,
ret = i915_cmd_parser_init_ring(ring);
if (ret)
- return ret;
+ goto error;
+
+ ret = ring->init(ring);
+ if (ret)
+ goto error;
+
+ return 0;
- return ring->init(ring);
+error:
+ kfree(ringbuf);
+ ring->buffer = NULL;
+ return ret;
}
void intel_cleanup_ring_buffer(struct intel_engine_cs *ring)
@@ -1488,6 +1505,9 @@ void intel_cleanup_ring_buffer(struct intel_engine_cs
*ring)
cleanup_status_page(ring);
i915_cmd_parser_fini_ring(ring);
+
+ kfree(ring->buffer);
+ ring->buffer = NULL;
}
static int intel_ring_wait_request(struct intel_engine_cs *ring, int n)
@@ -2022,15 +2042,24 @@ int intel_render_ring_init_dri(struct drm_device *dev,
u64 start, u32 size)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *ring = &dev_priv->ring[RCS];
+ struct intel_ringbuffer *ringbuf = ring->buffer;
int ret;
+ if (ringbuf == NULL) {
+ ringbuf = kzalloc(sizeof(*ringbuf), GFP_KERNEL);
+ if (!ringbuf)
+ return -ENOMEM;
+ ring->buffer = ringbuf;
+ }
+
ring->name = "render ring";
ring->id = RCS;
ring->mmio_base = RENDER_RING_BASE;
if (INTEL_INFO(dev)->gen >= 6) {
/* non-kms not supported on gen6+ */
- return -ENODEV;
+ ret = -ENODEV;
+ goto err_ringbuf;
}
/* Note: gem is not supported on gen5/ilk without kms (the corresponding
@@ -2074,16 +2103,24 @@ int intel_render_ring_init_dri(struct drm_device *dev,
u64 start, u32 size)
if (ring->virtual_start == NULL) {
DRM_ERROR("can not ioremap virtual address for"
" ring buffer\n");
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err_ringbuf;
}
if (!I915_NEED_GFX_HWS(dev)) {
ret = init_phys_status_page(ring);
if (ret)
- return ret;
+ goto err_vstart;
}
return 0;
+
+err_vstart:
+ iounmap(ring->virtual_start);
+err_ringbuf:
+ kfree(ringbuf);
+ ring->buffer = NULL;
+ return ret;
}
int intel_init_bsd_ring_buffer(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 7027473..a0ac668 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/i
[Intel-gfx] [PATCH 4/6] drm/i915: Split the ringbuffers from the rings (3/3)
From: Oscar Mateo
Manual cleanup after the previous Coccinelle script.
Yes, I could write another Coccinelle script to do this but I
don't want labor-replacing robots making an honest programmer's
work obsolete (also, I'm lazy).
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_dma.c | 13 ++--
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 109 +---
drivers/gpu/drm/i915/intel_ringbuffer.h | 8 ++-
4 files changed, 72 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 40a0176..b9159ad 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -141,6 +141,7 @@ void i915_kernel_lost_context(struct drm_device * dev)
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_master_private *master_priv;
struct intel_engine_cs *ring = LP_RING(dev_priv);
+ struct intel_ringbuffer *ringbuf = ring->buffer;
/*
* We should never lose context on the ring with modesetting
@@ -149,17 +150,17 @@ void i915_kernel_lost_context(struct drm_device * dev)
if (drm_core_check_feature(dev, DRIVER_MODESET))
return;
- ring->buffer->head = I915_READ_HEAD(ring) & HEAD_ADDR;
- ring->buffer->tail = I915_READ_TAIL(ring) & TAIL_ADDR;
- ring->buffer->space = ring->buffer->head - (ring->buffer->tail +
I915_RING_FREE_SPACE);
- if (ring->buffer->space < 0)
- ring->buffer->space += ring->buffer->size;
+ ringbuf->head = I915_READ_HEAD(ring) & HEAD_ADDR;
+ ringbuf->tail = I915_READ_TAIL(ring) & TAIL_ADDR;
+ ringbuf->space = ringbuf->head - (ringbuf->tail + I915_RING_FREE_SPACE);
+ if (ringbuf->space < 0)
+ ringbuf->space += ringbuf->size;
if (!dev->primary->master)
return;
master_priv = dev->primary->master->driver_priv;
- if (ring->buffer->head == ring->buffer->tail && master_priv->sarea_priv)
+ if (ringbuf->head == ringbuf->tail && master_priv->sarea_priv)
master_priv->sarea_priv->perf_boxes |= I915_BOX_RING_EMPTY;
}
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 0fa9c89..7a13a02 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1150,7 +1150,7 @@ static void ironlake_rps_change_irq_handler(struct
drm_device *dev)
static void notify_ring(struct drm_device *dev,
struct intel_engine_cs *ring)
{
- if (ring->buffer->obj == NULL)
+ if (!intel_ring_initialized(ring))
return;
trace_i915_gem_request_complete(ring);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 70f1b88..3379722 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -50,7 +50,8 @@ static inline int __ring_space(int head, int tail, int size)
static inline int ring_space(struct intel_engine_cs *ring)
{
- return __ring_space(ring->buffer->head & HEAD_ADDR, ring->buffer->tail,
ring->buffer->size);
+ struct intel_ringbuffer *ringbuf = ring->buffer;
+ return __ring_space(ringbuf->head & HEAD_ADDR, ringbuf->tail,
ringbuf->size);
}
static bool intel_ring_stopped(struct intel_engine_cs *ring)
@@ -61,10 +62,11 @@ static bool intel_ring_stopped(struct intel_engine_cs *ring)
void __intel_ring_advance(struct intel_engine_cs *ring)
{
- ring->buffer->tail &= ring->buffer->size - 1;
+ struct intel_ringbuffer *ringbuf = ring->buffer;
+ ringbuf->tail &= ringbuf->size - 1;
if (intel_ring_stopped(ring))
return;
- ring->write_tail(ring, ring->buffer->tail);
+ ring->write_tail(ring, ringbuf->tail);
}
static int
@@ -481,7 +483,8 @@ static int init_ring_common(struct intel_engine_cs *ring)
{
struct drm_device *dev = ring->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_i915_gem_object *obj = ring->buffer->obj;
+ struct intel_ringbuffer *ringbuf = ring->buffer;
+ struct drm_i915_gem_object *obj = ringbuf->obj;
int ret = 0;
gen6_gt_force_wake_get(dev_priv, FORCEWAKE_ALL);
@@ -520,7 +523,7 @@ static int init_ring_common(struct intel_engine_cs *ring)
* register values. */
I915_WRITE_START(ring, i915_gem_obj_ggtt_offset(obj));
I915_WRITE_CTL(ring,
- ((ring->buffer->size - PAGE_SIZE) & RING_NR_PAGES)
+ ((ringbuf->size - PAGE_SIZE) & RING_NR_PAGES)
| RING_VALID);
/* If the head is still not zero, the ring is dead */
@@ -540,10 +543,10 @@ static int init_ring_common(struct intel_engine_cs *ring)
if (!drm_core_check_feature(ring->dev, DRIVER_MODESET))
i915_kernel_lost_context(rin
[Intel-gfx] [PATCH 5/6] drm/i915: s/i915_hw_context/intel_context
From: Oscar Mateo
Up until now, contexts had one (and only one) backing object that was
used by the hardware to save/restore render ring contexts (via the
MI_SET_CONTEXT command). Other rings did not have or need this, so
our i915_hw_context struct had a 1:1 relationship with a a real HW
context.
With Logical Ring Contexts and Execlists, this is not possible anymore:
all rings need a backing object, and it cannot be reused. To prepare
for that, rename our contexts to the more generic term intel_context.
No functional changes.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_debugfs.c| 6 ++---
drivers/gpu/drm/i915/i915_drv.h| 16 ++---
drivers/gpu/drm/i915/i915_gem.c| 4 ++--
drivers/gpu/drm/i915/i915_gem_context.c| 38 +++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h| 2 +-
drivers/gpu/drm/i915/i915_sysfs.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.h| 4 ++--
drivers/gpu/drm/i915/intel_uncore.c| 2 +-
9 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 833fdd2..4f0f697 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -172,7 +172,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object
*obj)
seq_printf(m, " (%s)", obj->ring->name);
}
-static void describe_ctx(struct seq_file *m, struct i915_hw_context *ctx)
+static void describe_ctx(struct seq_file *m, struct intel_context *ctx)
{
seq_putc(m, ctx->is_initialized ? 'I' : 'i');
seq_putc(m, ctx->remap_slice ? 'R' : 'r');
@@ -1718,7 +1718,7 @@ static int i915_context_status(struct seq_file *m, void
*unused)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *ring;
- struct i915_hw_context *ctx;
+ struct intel_context *ctx;
int ret, i;
ret = mutex_lock_interruptible(&dev->mode_config.mutex);
@@ -1854,7 +1854,7 @@ static int i915_swizzle_info(struct seq_file *m, void
*data)
static int per_file_ctx(int id, void *ptr, void *data)
{
- struct i915_hw_context *ctx = ptr;
+ struct intel_context *ctx = ptr;
struct seq_file *m = data;
struct i915_hw_ppgtt *ppgtt = ctx_to_ppgtt(ctx);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2199a73..b9ab950 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -587,7 +587,7 @@ struct i915_ctx_hang_stats {
/* This must match up with the value previously used for execbuf2.rsvd1. */
#define DEFAULT_CONTEXT_ID 0
-struct i915_hw_context {
+struct intel_context {
struct kref ref;
int id;
bool is_initialized;
@@ -1738,7 +1738,7 @@ struct drm_i915_gem_request {
u32 tail;
/** Context related to this request */
- struct i915_hw_context *ctx;
+ struct intel_context *ctx;
/** Batch buffer related to this request if any */
struct drm_i915_gem_object *batch_obj;
@@ -1765,7 +1765,7 @@ struct drm_i915_file_private {
} mm;
struct idr context_idr;
- struct i915_hw_context *private_default_ctx;
+ struct intel_context *private_default_ctx;
atomic_t rps_wait_boost;
struct intel_engine_cs *bsd_ring;
};
@@ -2383,21 +2383,21 @@ int i915_gem_context_open(struct drm_device *dev,
struct drm_file *file);
int i915_gem_context_enable(struct drm_i915_private *dev_priv);
void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
int i915_switch_context(struct intel_engine_cs *ring,
- struct i915_hw_context *to);
-struct i915_hw_context *
+ struct intel_context *to);
+struct intel_context *
i915_gem_context_get(struct drm_i915_file_private *file_priv, u32 id);
void i915_gem_context_free(struct kref *ctx_ref);
-static inline void i915_gem_context_reference(struct i915_hw_context *ctx)
+static inline void i915_gem_context_reference(struct intel_context *ctx)
{
kref_get(&ctx->ref);
}
-static inline void i915_gem_context_unreference(struct i915_hw_context *ctx)
+static inline void i915_gem_context_unreference(struct intel_context *ctx)
{
kref_put(&ctx->ref, i915_gem_context_free);
}
-static inline bool i915_gem_context_is_default(const struct i915_hw_context *c)
+static inline bool i915_gem_context_is_default(const struct intel_context *c)
{
return c->id == DEFAULT_CONTEXT_ID;
}
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 677e950..891fb4e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2422,7 +2422,7 @@ i915_gem_request_remove_from_client(struct
drm_i915_gem_request *request)
}
static bool i
Re: [Intel-gfx] [PATCH v8 3/9] drm/i915: Make sprite updates atomic
On Thu, May 22, 2014 at 03:03:56PM +0200, Daniel Vetter wrote:
> On Tue, Apr 29, 2014 at 01:35:46PM +0300, ville.syrj...@linux.intel.com wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 96ae78d..d8b540b 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -401,6 +401,8 @@ struct intel_crtc {
> > /* watermarks currently being used */
> > struct intel_pipe_wm active;
> > } wm;
> > +
> > + wait_queue_head_t vbl_wait;
> > };
>
> A bit late, but found something: Why can't we use dev->vblank[crtc].queue
> here? We reuse all the vblank infrastructure already ...
>
> If you want pretty just add a tiny helper function
>
> wait_queue_head_t *drm_crtc_vblank_waitqueue(struct drm_crtc *crtc)
> {
> return &dev->vblank[drm_crtc_index(crtc)].queue;
> }
>
> somewhere.
>
> I feel guilty here since I've killed Akash's patch over adding a new
> vblank wait queue and let yours slip through ;-) Can you please take care
> of this?
Can do.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Add null state batch to active list
"Volkin, Bradley D" writes:
> On Wed, May 21, 2014 at 07:02:56AM -0700, Mika Kuoppala wrote:
>> +if (ring->id == RCS && !to->is_initialized && from == NULL) {
>> +ret = i915_gem_render_state_init(ring);
>> +if (ret)
>> +DRM_ERROR("init render state: %d\n", ret);
>> +}
>
> Apologies if this has already been discussed, but why do we have the
> 'from == NULL' check? Shouldn't we initialize all uninitialized RCS
> contexts? Otherwise I thought we'll inherit whatever state 'from' left
> behind.
>
> The hw state should be valid in either case (and so I expect would fix
> the rc6 issue either way), it's just the difference between initializing
> every context to a specific valid state or initializing every context to
> _some_ valid state. The commit message on the first render state patch
> seemed to indicate the former while the implementation looks like the
> latter. Just want to understand which we intended.
It seems that the intentions changed and I forgot to update the
commit message. For now this is just to push some state and hoping
that we can get in/out from rc6 without symptomps.
The idea that we would restore/initialize to a specific (golden) state for
each new context makes me think that we would get rid of some transient
bugs we are seeing. As how I understand things are now, app might
inherit some parts from previous ctx and then have lacking
initialization by itself and then see a hang..sometimes.
I guess the main opponent here is the performance implications.
And I lack the experience from user/application side to estimate the impact.
I hope that other devs with more experience on this topic will join
the discussion.
Thanks,
-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Imre Deak > Sent: Thursday, May 22, 2014 1:08 AM > > On Wed, 2014-05-21 at 18:05 +0200, Daniel Vetter wrote: > > On Wed, May 21, 2014 at 5:56 PM, Babu, Ramesh > wrote: > > >> On Tue, May 20, 2014 at 05:29:07PM +0300, Imre Deak wrote: > > >> > On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote: > > >> > > This RFC is based on previous discussion to set up a generic > > >> > > communication channel between display and audio driver and an > > >> > > internal design of Intel MCG/VPG HDMI audio driver. It's still > > >> > > an initial draft and your advice would be appreciated to > > >> > > improve the design. > > >> > > > > >> > > The basic idea is to create a new avsink module and let both > > >> > > drm and alsa depend on it. > > >> > > This new module provides a framework and APIs for > > >> > > synchronization between the display and audio driver. > > >> > > > > >> > > 1. Display/Audio Client > > >> > > > > >> > > The avsink core provides APIs to create, register and lookup a > > >> > > display/audio client. > > >> > > A specific display driver (eg. i915) or audio driver (eg. > > >> > > HD-Audio > > >> > > driver) can create a client, add some resources objects (shared > > >> > > power wells, display outputs, and audio inputs, register ops) > > >> > > to the client, and then register this client to avisink core. > > >> > > The peer driver can look up a registered client by a name or type, or > both. > > >> > > If a client gives a valid peer client name on registration, > > >> > > avsink core will bind the two clients as peer for each other. > > >> > > And we expect a display client and an audio client to be peers > > >> > > for each other in a system. > > >> > > > >> > One problem we have at the moment is the order of calling the > > >> > system suspend/resume handlers of the display driver wrt. that of > > >> > the audio driver. Since the power well control is part of the > > >> > display HW block, we need to run the display driver's resume > > >> > handler first, initialize the HW, and only then let the audio > > >> > driver's resume handler run. For similar reasons we have to call > > >> > the audio suspend handler first and only then the display driver > > >> > resume handler. Currently we solve this using the display > > >> > driver's late/early suspend/resume hooks, but we'd need a more robust > solution. > > >> > > > >> > This seems to be a similar issue to the load time ordering > > >> > problem that you describe later. Having a real device for avsync > > >> > that would be a child of the display device would solve the > > >> > ordering issue in both cases. I admit I haven't looked into it if > > >> > this is feasible, but I would like to see some solution to this as > > >> > part of the > plan. > > >> > > >> If we are able create and mandate that HDMI display controller is > > >> parent and audio is child device, then this wouldn't be an issue > > >> and PM frameowrk will ensure parent is suspended last. > > >> > > > If there is a scenario where HDMI audio has to active but display > > > has to go to low power, then > parent-child device is not optimal. > > > There needs to be a mechanism to turn on/off individual hw blocks > > > within the controller. > > > > Our gfx runtime pm code is a _lot_ better than that. We track each > > power domain individually and enable/disable them only when need. > > armsoc drivers could do the same or make sure that the avsink device > > is a child of the right block. Of course if your driver only has > > binary runtime pm and fires up everything then we have a problem. But > > imo that's a problem with that driver, not with making avsink real > > devices as children of something. > > I would also add that at least in case of Haswell, there is really a hard > dependency between the display device and the HDMI audio > functionality: The power well required by HDMI is controlled via the > PWR_WELL_CTL2 register which is in turn part of the display power domain. > This domain is turned off when the display device is in D3 state, so to turn > on > audio we really have to first put the display device into D0 state. Since the > PM > framework doesn't provide any way to reorder the initialization of devices, we > can only depend on the device parent -> child relationship to achieve the > above correct init order. > > --Imre So for Haswell, how about create a device for the 'power well' and make this power device be a child of the display device? And by any means (e.g. further extract the device as a power object and expose to audio driver), the audio driver can finally trigger pm_runtime_get/put_sync() on this power device to solve the power dependency on audio side, and the parent->child relationship will assure the order on drm side. I feel it's a natural way for HD-Audio driver, which already binds to the HD-A controller. And for MCG HDMI a
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Implement WaVcpClkGateDisableForMediaReset:ctg, elk
On Tue, May 20, 2014 at 11:46:45AM -0700, Jesse Barnes wrote:
> On Mon, 19 May 2014 19:23:27 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Apparently we need to disable VCP unit clock gating around media reset
> > on g4x.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 4
> > drivers/gpu/drm/i915/intel_uncore.c | 36
> > +++-
> > 2 files changed, 39 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 6522af4..543f23c 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1724,6 +1724,10 @@ enum punit_power_well {
> > #define VF_UNIT_CLOCK_GATE_DISABLE (1 << 9)
> > #define GS_UNIT_CLOCK_GATE_DISABLE (1 << 7)
> > #define CL_UNIT_CLOCK_GATE_DISABLE (1 << 6)
> > +
> > +#define VDECCLK_GATE_D 0x620C /* g4x only */
> > +#define VCP_UNIT_CLOCK_GATE_DISABLE (1 << 4)
> > +
> > #define RAMCLK_GATE_D 0x6210 /* CRL only */
> > #define DEUC 0x6214 /* CRL only */
> >
> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> > b/drivers/gpu/drm/i915/intel_uncore.c
> > index cd0d6e2..67385a9 100644
> > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > @@ -990,6 +990,36 @@ static int i965_do_reset(struct drm_device *dev)
> > return 0;
> > }
> >
> > +static int g4x_do_reset(struct drm_device *dev)
> > +{
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > + int ret;
> > +
> > + pci_write_config_byte(dev->pdev, I965_GDRST,
> > + GRDOM_RENDER | GRDOM_RESET_ENABLE);
> > + ret = wait_for(i965_reset_complete(dev), 500);
> > + if (ret)
> > + return ret;
> > +
> > + /* WaVcpClkGateDisableForMediaReset:ctg,elk */
> > + I915_WRITE(VDECCLK_GATE_D, I915_READ(VDECCLK_GATE_D) |
> > VCP_UNIT_CLOCK_GATE_DISABLE);
> > + POSTING_READ(VDECCLK_GATE_D);
> > +
> > + pci_write_config_byte(dev->pdev, I965_GDRST,
> > + GRDOM_MEDIA | GRDOM_RESET_ENABLE);
> > + ret = wait_for(i965_reset_complete(dev), 500);
> > + if (ret)
> > + return ret;
> > +
> > + /* WaVcpClkGateDisableForMediaReset:ctg,elk */
> > + I915_WRITE(VDECCLK_GATE_D, I915_READ(VDECCLK_GATE_D) &
> > ~VCP_UNIT_CLOCK_GATE_DISABLE);
> > + POSTING_READ(VDECCLK_GATE_D);
> > +
> > + pci_write_config_byte(dev->pdev, I965_GDRST, 0);
> > +
> > + return 0;
> > +}
> > +
> > static int ironlake_do_reset(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > @@ -1042,7 +1072,11 @@ int intel_gpu_reset(struct drm_device *dev)
> > case 7:
> > case 6: return gen6_do_reset(dev);
> > case 5: return ironlake_do_reset(dev);
> > - case 4: return i965_do_reset(dev);
> > + case 4:
> > + if (IS_G4X(dev))
> > + return g4x_do_reset(dev);
> > + else
> > + return i965_do_reset(dev);
> > default: return -ENODEV;
> > }
> > }
>
> Given how the reset flow stuff works this seems sensible, but I
> couldn't find it in the docs I have. Shouldn't do any harm at the very
> worst...
>
> Acked-by: Jesse Barnes
I want the g4x/i965 split, so also merged this one here ;-)
-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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/3] Replace Blitter ring based flips with MMIO flips
From: Sourab Gupta This patch series replaces Blitter ring based flips with MMIO based flips. This is useful for Media power well residency optimization. These may be enabled on architectures where Render and Blitter engines reside in different power wells. The blitter ring is currently being used just for command streamer based flip calls. For pure 3D workloads, with MMIO flips, there will be no use of blitter ring and this will ensure the 100% residency for Media well. Sourab Gupta (3): drm/i915: Replaced Blitter ring based flips with MMIO flips drm/i915: Default to mmio flips on VLV drm/i915: Fix mmio page flip vs mmio set base race drivers/gpu/drm/i915/i915_dma.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 6 ++ drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/i915_irq.c | 3 + drivers/gpu/drm/i915/i915_params.c | 5 ++ drivers/gpu/drm/i915/intel_display.c | 135 +++ drivers/gpu/drm/i915/intel_drv.h | 6 ++ 7 files changed, 157 insertions(+), 1 deletion(-) -- 1.8.5.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 1/3] drm/i915: Replaced Blitter ring based flips with MMIO flips
From: Sourab Gupta
Using MMIO based flips on Gen5+. The MMIO flips are useful for the Media power
well residency optimization. These maybe enabled on architectures where
Render and Blitter engines reside in different power wells.
The blitter ring is currently being used just for command streamer based
flip calls. For pure 3D workloads in such cases, with MMIO flips, there will
be no use of blitter ring and this will ensure the 100% residency for Media
well.
v2: The MMIO flips now use the interrupt driven mechanism for issuing the
flips when target seqno is reached. (Incorporating Ville's idea)
v3: Rebasing on latest code. Code restructuring after incorporating
Damien's comments
v4: Addressing Ville's review comments
-general cleanup
-updating only base addr instead of calling update_primary_plane
-extending patch for gen5+ platforms
v5: Addressed Ville's review comments
-Making mmio flip vs cs flip selection based on module parameter
-Adding check for DRIVER_MODESET feature in notify_ring before calling
notify mmio flip.
-Other changes mostly in function arguments
v6: -Having a seperate function to check condition for using mmio flips (Ville)
-propogating error code from i915_gem_check_olr (Ville)
v7: -Adding __must_check with i915_gem_check_olr (Chris)
-Renaming mmio_flip_data to mmio_flip (Chris)
-Rebasing on latest nightly
Signed-off-by: Sourab Gupta
Signed-off-by: Akash Goel
---
drivers/gpu/drm/i915/i915_dma.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 7 ++
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 3 +
drivers/gpu/drm/i915/i915_params.c | 4 ++
drivers/gpu/drm/i915/intel_display.c | 133 +++
drivers/gpu/drm/i915/intel_drv.h | 6 ++
7 files changed, 155 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 20df7c72..266c9a6 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1571,6 +1571,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
spin_lock_init(&dev_priv->backlight_lock);
spin_lock_init(&dev_priv->uncore.lock);
spin_lock_init(&dev_priv->mm.object_stat_lock);
+ spin_lock_init(&dev_priv->mmio_flip_lock);
mutex_init(&dev_priv->dpio_lock);
mutex_init(&dev_priv->modeset_restore_lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 13495a4..ced6e58 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1366,6 +1366,9 @@ struct drm_i915_private {
/* protects the irq masks */
spinlock_t irq_lock;
+ /* protects the mmio flip data */
+ spinlock_t mmio_flip_lock;
+
bool display_irqs_enabled;
/* To control wakeup latency, e.g. for irq-driven dp aux transfers. */
@@ -2036,6 +2039,7 @@ struct i915_params {
bool reset;
bool disable_display;
bool disable_vtd_wa;
+ bool use_mmio_flip;
};
extern struct i915_params i915 __read_mostly;
@@ -2230,6 +2234,7 @@ bool i915_gem_retire_requests(struct drm_device *dev);
void i915_gem_retire_requests_ring(struct intel_ring_buffer *ring);
int __must_check i915_gem_check_wedge(struct i915_gpu_error *error,
bool interruptible);
+int __must_check i915_gem_check_olr(struct intel_ring_buffer *ring, u32 seqno);
static inline bool i915_reset_in_progress(struct i915_gpu_error *error)
{
return unlikely(atomic_read(&error->reset_counter)
@@ -2598,6 +2603,8 @@ int i915_reg_read_ioctl(struct drm_device *dev, void
*data,
int i915_get_reset_stats_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+void intel_notify_mmio_flip(struct intel_ring_buffer *ring);
+
/* overlay */
extern struct intel_overlay_error_state
*intel_overlay_capture_error_state(struct drm_device *dev);
extern void intel_overlay_print_error_state(struct drm_i915_error_state_buf *e,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f2713b9..bc6fe4e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1096,7 +1096,7 @@ i915_gem_check_wedge(struct i915_gpu_error *error,
* Compare seqno against outstanding lazy request. Emit a request if they are
* equal.
*/
-static int
+__must_check int
i915_gem_check_olr(struct intel_ring_buffer *ring, u32 seqno)
{
int ret;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2043276..f244b23 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1155,6 +1155,9 @@ static void notify_ring(struct drm_device *dev,
trace_i915_gem_request_complete(ring);
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ intel_notify_mmio_flip(ring);
+
wake_u
[Intel-gfx] [PATCH 3/3] drm/i915: Fix mmio page flip vs mmio set base race
From: Sourab Gupta
This patch fixes the race condition between flip done interrupt
from set base and mmio based page flip.
This patch is dependent on
http://lists.freedesktop.org/archives/intel-gfx/2014-April/043761.html
Also, for the details of the race condition please refer to the mentioned
patch.
Signed-off-by: Sourab Gupta
Signed-off-by: Akash Goel
---
drivers/gpu/drm/i915/intel_display.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b3e7fc6..0099c56 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9221,8 +9221,8 @@ static void intel_do_mmio_flip(struct intel_crtc
*intel_crtc)
intel_mark_page_flip_active(intel_crtc);
- I915_WRITE(DSPSURF(intel_crtc->plane), i915_gem_obj_ggtt_offset(obj) +
- intel_crtc->dspaddr_offset);
+ I915_WRITE(DSPSURF(intel_crtc->plane),
+ intel_crtc->unpin_work->gtt_offset);
POSTING_READ(DSPSURF(intel_crtc->plane));
}
@@ -9296,6 +9296,10 @@ static int intel_queue_mmio_flip(struct drm_device *dev,
goto err_unpin;
}
+ intel_crtc->unpin_work->gtt_offset =
+ i915_gem_obj_ggtt_offset(obj) +
+ intel_crtc->dspaddr_offset;
+
ret = intel_postpone_flip(obj);
if (ret < 0) {
goto err_unpin;
--
1.8.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Default to mmio flips on VLV
From: Sourab Gupta
This patch is for using mmio flips by default on VLV.
The module parameter controlling use of MMIO flips allows us to
control the default behaviour, which is set true for VLV and false
elsewhere.
Signed-off-by: Sourab Gupta
---
drivers/gpu/drm/i915/i915_params.c | 5 +++--
drivers/gpu/drm/i915/intel_display.c | 12
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index e0d44df..a99accc 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -48,7 +48,7 @@ struct i915_params i915 __read_mostly = {
.disable_display = 0,
.enable_cmd_parser = 1,
.disable_vtd_wa = 0,
- .use_mmio_flip = 0,
+ .use_mmio_flip = -1,
};
module_param_named(modeset, i915.modeset, int, 0400);
@@ -159,4 +159,5 @@ MODULE_PARM_DESC(enable_cmd_parser,
"Enable command parsing (1=enabled [default], 0=disabled)");
module_param_named(use_mmio_flip, i915.use_mmio_flip, bool, 0600);
-MODULE_PARM_DESC(use_mmio_flip, "use MMIO flips (default: false)");
+MODULE_PARM_DESC(use_mmio_flip, "use MMIO page flips "
+ "(default: -1 (use per-chip default))");
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a29552d..b3e7fc6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9193,6 +9193,18 @@ static bool intel_use_mmio_flip(struct drm_device *dev)
if (i915.use_mmio_flip == 0)
return false;
+ /* On Valleyview, use MMIO flips by default, for Media Power Well
+* residency optimization. The other alternative of having Render
+* ring based flip calls is not being used, as the performance(FPS)
+* of certain 3D Apps gets severly affected.
+*/
+ if (i915.use_mmio_flip == -1) {
+ if (IS_VALLEYVIEW(dev))
+ return true;
+ else
+ return false;
+ }
+
if (INTEL_INFO(dev)->gen >= 5)
return true;
else
--
1.8.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 00/16] drm/i915: Two part watermark update for ILK+, part 2
From: Ville Syrjälä Here's a rebased and slightly polished version of the two part watermark update series. Several patches already got merged, so we're down to 16 now. Also the drm vblank series got merged as did the atomic sprite series, so there's nothing else blocking this stuff anymore. Previouse version was here: http://lists.freedesktop.org/archives/intel-gfx/2014-March/041302.html Ville Syrjälä (16): drm/i915: Keep vblank interrupts enabled while enabling/disabling planes drm/i915: Leave interrupts enabled while disabling crtcs during suspend drm/i915: Check hw vs. sw watermark state after programming drm/i915: Refactor ilk_validate_pipe_wm() drm/i915: Refactor ilk_update_wm drm/i915: Add dev_priv->wm.mutex drm/i915: Add vblank based delayed watermark update mechanism drm/i915: Split watermark programming into pre and post steps drm/i915: Actually perform the watermark update in two phases drm/i915: Wait for watermark updates to finish before disabling a pipe drm/i915: Refactor get_other_active_crtc() drm/i915: Disable LP1+ watermarks while changing the number of active pipes drm/i915: Keep track of who disabled LP1+ watermarks drm/i915: Prefer the 5/6 DDB split when primary is disabled drm/i915: Add a workaround for sprite only <-> primary only switching drm/i915: Don't disable LP1+ watermarks for every frame when scaled drivers/gpu/drm/i915/i915_drv.c | 3 +- drivers/gpu/drm/i915/i915_drv.h | 39 +- drivers/gpu/drm/i915/i915_irq.c | 12 +- drivers/gpu/drm/i915/intel_display.c | 152 ++-- drivers/gpu/drm/i915/intel_drv.h | 82 +++- drivers/gpu/drm/i915/intel_pm.c | 733 ++- drivers/gpu/drm/i915/intel_sprite.c | 119 -- 7 files changed, 964 insertions(+), 176 deletions(-) -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/16] drm/i915: Leave interrupts enabled while disabling crtcs during suspend
From: Ville Syrjälä The new watermaek update mechanism requires interrupts to work correctly. Because of this we need interrupts while disabling crtcs during suspend. So move the irq disable to happen a bit later. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index c83c83b..5fc49a9 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -525,7 +525,6 @@ static int i915_drm_freeze(struct drm_device *dev) cancel_delayed_work_sync(&dev_priv->rps.delayed_resume_work); - drm_irq_uninstall(dev); dev_priv->enable_hotplug_processing = false; /* * Disable CRTCs directly since we want to preserve sw state @@ -539,6 +538,8 @@ static int i915_drm_freeze(struct drm_device *dev) } mutex_unlock(&dev->mode_config.mutex); + drm_irq_uninstall(dev); + intel_modeset_suspend_hw(dev); } -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/16] drm/i915: Check hw vs. sw watermark state after programming
From: Ville Syrjälä
Make sure we programmed the watermarks correctly, by reading out the
hardware state again after programming and comparing it with the
state we supposedly programmed into hardware. Dump the watermark
registers after a mismatch, very much like we for the pipe config.
The only difference is that we don't dump the entire watermark
software tracking state since that's spread around a bit.
Reviewed-by: Paulo Zanoni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 117
1 file changed, 83 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bd9568e..5b54bf6 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2575,15 +2575,84 @@ static bool _ilk_disable_lp_wm(struct drm_i915_private
*dev_priv,
return changed;
}
+static void _ilk_pipe_wm_get_hw_state(struct drm_device *dev,
+ enum pipe pipe,
+ struct ilk_wm_values *hw)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ static const unsigned int wm0_pipe_reg[] = {
+ [PIPE_A] = WM0_PIPEA_ILK,
+ [PIPE_B] = WM0_PIPEB_ILK,
+ [PIPE_C] = WM0_PIPEC_IVB,
+ };
+
+ hw->wm_pipe[pipe] = I915_READ(wm0_pipe_reg[pipe]);
+
+ if (IS_HASWELL(dev) || IS_BROADWELL(dev))
+ hw->wm_linetime[pipe] = I915_READ(PIPE_WM_LINETIME(pipe));
+}
+
+static void _ilk_wm_get_hw_state(struct drm_device *dev,
+struct ilk_wm_values *hw)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ enum pipe pipe;
+
+ for_each_pipe(pipe)
+ _ilk_pipe_wm_get_hw_state(dev, pipe, hw);
+
+ hw->wm_lp[0] = I915_READ(WM1_LP_ILK);
+ hw->wm_lp[1] = I915_READ(WM2_LP_ILK);
+ hw->wm_lp[2] = I915_READ(WM3_LP_ILK);
+
+ hw->wm_lp_spr[0] = I915_READ(WM1S_LP_ILK);
+ if (INTEL_INFO(dev)->gen >= 7) {
+ hw->wm_lp_spr[1] = I915_READ(WM2S_LP_IVB);
+ hw->wm_lp_spr[2] = I915_READ(WM3S_LP_IVB);
+ }
+
+ if (IS_HASWELL(dev) || IS_BROADWELL(dev))
+ hw->partitioning = (I915_READ(WM_MISC) &
WM_MISC_DATA_PARTITION_5_6) ?
+ INTEL_DDB_PART_5_6 : INTEL_DDB_PART_1_2;
+ else if (IS_IVYBRIDGE(dev))
+ hw->partitioning = (I915_READ(DISP_ARB_CTL2) &
DISP_DATA_PARTITION_5_6) ?
+ INTEL_DDB_PART_5_6 : INTEL_DDB_PART_1_2;
+
+ hw->enable_fbc_wm =
+ !(I915_READ(DISP_ARB_CTL) & DISP_FBC_WM_DIS);
+}
+
+static void ilk_dump_wm_values(const struct ilk_wm_values *hw,
+ const char *context)
+{
+ DRM_DEBUG_KMS("%s watermark values\n", context);
+ DRM_DEBUG_KMS("WM_PIPE_A = 0x%08x\n", hw->wm_pipe[PIPE_A]);
+ DRM_DEBUG_KMS("WM_PIPE_B = 0x%08x\n", hw->wm_pipe[PIPE_B]);
+ DRM_DEBUG_KMS("WM_PIPE_C = 0x%08x\n", hw->wm_pipe[PIPE_C]);
+ DRM_DEBUG_KMS("WM_LP_1 = 0x%08x\n", hw->wm_lp[0]);
+ DRM_DEBUG_KMS("WM_LP_2 = 0x%08x\n", hw->wm_lp[1]);
+ DRM_DEBUG_KMS("WM_LP_3 = 0x%08x\n", hw->wm_lp[2]);
+ DRM_DEBUG_KMS("WM_LP_SPR_1 = 0x%08x\n", hw->wm_lp_spr[0]);
+ DRM_DEBUG_KMS("WM_LP_SPR_2 = 0x%08x\n", hw->wm_lp_spr[1]);
+ DRM_DEBUG_KMS("WM_LP_SPR_3 = 0x%08x\n", hw->wm_lp_spr[2]);
+ DRM_DEBUG_KMS("WM_LINETIME_A = 0x%08x\n", hw->wm_linetime[PIPE_A]);
+ DRM_DEBUG_KMS("WM_LINETIME_B = 0x%08x\n", hw->wm_linetime[PIPE_B]);
+ DRM_DEBUG_KMS("WM_LINETIME_C = 0x%08x\n", hw->wm_linetime[PIPE_C]);
+ DRM_DEBUG_KMS("enable FBC watermark = %d\n", hw->enable_fbc_wm);
+ DRM_DEBUG_KMS("DDB partitioning = %s\n",
+ hw->partitioning == INTEL_DDB_PART_1_2 ? "1/2" : "5/6");
+}
+
/*
* The spec says we shouldn't write when we don't need, because every write
* causes WMs to be re-evaluated, expending some power.
*/
static void ilk_write_wm_values(struct drm_i915_private *dev_priv,
- struct ilk_wm_values *results)
+ const struct ilk_wm_values *results)
{
struct drm_device *dev = dev_priv->dev;
struct ilk_wm_values *previous = &dev_priv->wm.hw;
+ struct ilk_wm_values hw = {};
unsigned int dirty;
uint32_t val;
@@ -2653,6 +2722,14 @@ static void ilk_write_wm_values(struct drm_i915_private
*dev_priv,
I915_WRITE(WM3_LP_ILK, results->wm_lp[2]);
dev_priv->wm.hw = *results;
+
+ _ilk_wm_get_hw_state(dev, &hw);
+
+ if (memcmp(results, &hw, sizeof(hw))) {
+ WARN(1, "watermark state doesn't match!\n");
+ ilk_dump_wm_values(&hw, "[hw state]");
+ ilk_dump_wm_values(results, "[sw state]");
+ }
}
static bool ilk_disable_lp_wm(struct drm_device *dev)
@@ -2734,23 +2811,14 @@ static void ilk_update_sp
[Intel-gfx] [PATCH 04/16] drm/i915: Refactor ilk_validate_pipe_wm()
From: Ville Syrjälä
Pull the LP0 validate out from intel_compute_pipe_wm() into a separate
function. We will have further need for such a function to validate
both the final watermarks and the intermediate watermarks we will be
using while the plane(s) transition between different configurations.
Reviewed-by: Paulo Zanoni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5b54bf6..55ce660 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -,6 +,24 @@ static void ilk_compute_wm_config(struct drm_device *dev,
}
}
+static bool ilk_validate_pipe_wm(struct drm_device *dev,
+struct intel_pipe_wm *pipe_wm)
+{
+ /* LP0 watermark maximums depend on this pipe alone */
+ const struct intel_wm_config config = {
+ .num_pipes_active = 1,
+ .sprites_enabled = pipe_wm->sprites_enabled,
+ .sprites_scaled = pipe_wm->sprites_scaled,
+ };
+ struct ilk_wm_maximums max;
+
+ /* LP0 watermarks always use 1/2 DDB partitioning */
+ ilk_compute_wm_maximums(dev, 0, &config, INTEL_DDB_PART_1_2, &max);
+
+ /* At least LP0 must be valid */
+ return ilk_validate_wm_level(0, &max, &pipe_wm->wm[0]);
+}
+
/* Compute new watermarks for the pipe */
static bool intel_compute_pipe_wm(struct drm_crtc *crtc,
const struct ilk_pipe_wm_parameters *params,
@@ -2230,12 +2248,6 @@ static bool intel_compute_pipe_wm(struct drm_crtc *crtc,
struct drm_device *dev = crtc->dev;
const struct drm_i915_private *dev_priv = dev->dev_private;
int level, max_level = ilk_wm_max_level(dev);
- /* LP0 watermark maximums depend on this pipe alone */
- struct intel_wm_config config = {
- .num_pipes_active = 1,
- .sprites_enabled = params->spr.enabled,
- .sprites_scaled = params->spr.scaled,
- };
struct ilk_wm_maximums max;
pipe_wm->pipe_enabled = params->active;
@@ -2255,11 +2267,7 @@ static bool intel_compute_pipe_wm(struct drm_crtc *crtc,
if (IS_HASWELL(dev) || IS_BROADWELL(dev))
pipe_wm->linetime = hsw_compute_linetime_wm(dev, crtc);
- /* LP0 watermarks always use 1/2 DDB partitioning */
- ilk_compute_wm_maximums(dev, 0, &config, INTEL_DDB_PART_1_2, &max);
-
- /* At least LP0 must be valid */
- if (!ilk_validate_wm_level(0, &max, &pipe_wm->wm[0]))
+ if (!ilk_validate_pipe_wm(dev, pipe_wm))
return false;
ilk_compute_wm_reg_maximums(dev, 1, &max);
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 01/16] drm/i915: Keep vblank interrupts enabled while enabling/disabling planes
From: Ville Syrjälä Because of the upcoming vblank interrupt driven watermark update mechanism we will have use for vblank interrupts during plane enabling/disabling. So don't call drm_vblank_off() until planes are off, and call drm_vblank_on() just before we start to enable the planes. v2: Pimp commit message (Paulo) Reviewed-by: Paulo Zanoni Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 019e9e1..a11bd78 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3885,6 +3885,8 @@ static void intel_crtc_enable_planes(struct drm_crtc *crtc) int pipe = intel_crtc->pipe; int plane = intel_crtc->plane; + drm_vblank_on(dev, pipe); + intel_enable_primary_hw_plane(dev_priv, plane, pipe); intel_enable_planes(crtc); /* The fixup needs to happen before cursor is enabled */ @@ -3910,7 +3912,6 @@ static void intel_crtc_disable_planes(struct drm_crtc *crtc) int plane = intel_crtc->plane; intel_crtc_wait_for_pending_flips(crtc); - drm_crtc_vblank_off(crtc); if (dev_priv->fbc.plane == plane) intel_disable_fbc(dev); @@ -3921,6 +3922,8 @@ static void intel_crtc_disable_planes(struct drm_crtc *crtc) intel_crtc_update_cursor(crtc, false); intel_disable_planes(crtc); intel_disable_primary_hw_plane(dev_priv, plane, pipe); + + drm_vblank_off(dev, pipe); } static void ironlake_crtc_enable(struct drm_crtc *crtc) @@ -3999,8 +4002,6 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc) cpt_verify_modeset(dev, intel_crtc->pipe); intel_crtc_enable_planes(crtc); - - drm_crtc_vblank_on(crtc); } /* IPS only exists on ULT machines and is tied to pipe A. */ @@ -4114,8 +4115,6 @@ static void haswell_crtc_enable(struct drm_crtc *crtc) * to change the workaround. */ haswell_mode_set_planes_workaround(intel_crtc); intel_crtc_enable_planes(crtc); - - drm_crtc_vblank_on(crtc); } static void ironlake_pfit_disable(struct intel_crtc *crtc) @@ -4625,8 +4624,6 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc) intel_crtc_enable_planes(crtc); - drm_crtc_vblank_on(crtc); - /* Underruns don't raise interrupts, so check manually. */ i9xx_check_fifo_underruns(dev); } @@ -4719,8 +4716,6 @@ static void i9xx_crtc_enable(struct drm_crtc *crtc) if (IS_GEN2(dev)) intel_set_cpu_fifo_underrun_reporting(dev, pipe, true); - drm_crtc_vblank_on(crtc); - /* Underruns don't raise interrupts, so check manually. */ i9xx_check_fifo_underruns(dev); } -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 05/16] drm/i915: Refactor ilk_update_wm
From: Ville Syrjälä
Split ilk_update_wm() into two parts; one doing the programming
and the other the calculations.
v2: Fix typo in commit message
Reviewed-by: Paulo Zanoni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 38 ++
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 55ce660..2185553 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2747,27 +2747,14 @@ static bool ilk_disable_lp_wm(struct drm_device *dev)
return _ilk_disable_lp_wm(dev_priv, WM_DIRTY_LP_ALL);
}
-static void ilk_update_wm(struct drm_crtc *crtc)
+static void ilk_program_watermarks(struct drm_device *dev)
{
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_pipe_wm lp_wm_1_2 = {}, lp_wm_5_6 = {}, *best_lp_wm;
struct ilk_wm_maximums max;
- struct ilk_pipe_wm_parameters params = {};
+ struct intel_wm_config config = {};
struct ilk_wm_values results = {};
enum intel_ddb_partitioning partitioning;
- struct intel_pipe_wm pipe_wm = {};
- struct intel_pipe_wm lp_wm_1_2 = {}, lp_wm_5_6 = {}, *best_lp_wm;
- struct intel_wm_config config = {};
-
- ilk_compute_wm_parameters(crtc, ¶ms);
-
- intel_compute_pipe_wm(crtc, ¶ms, &pipe_wm);
-
- if (!memcmp(&intel_crtc->wm.active, &pipe_wm, sizeof(pipe_wm)))
- return;
-
- intel_crtc->wm.active = pipe_wm;
ilk_compute_wm_config(dev, &config);
@@ -2793,6 +2780,25 @@ static void ilk_update_wm(struct drm_crtc *crtc)
ilk_write_wm_values(dev_priv, &results);
}
+static void ilk_update_wm(struct drm_crtc *crtc)
+{
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct drm_device *dev = crtc->dev;
+ struct ilk_pipe_wm_parameters params = {};
+ struct intel_pipe_wm pipe_wm = {};
+
+ ilk_compute_wm_parameters(crtc, ¶ms);
+
+ intel_compute_pipe_wm(crtc, ¶ms, &pipe_wm);
+
+ if (!memcmp(&intel_crtc->wm.active, &pipe_wm, sizeof(pipe_wm)))
+ return;
+
+ intel_crtc->wm.active = pipe_wm;
+
+ ilk_program_watermarks(dev);
+}
+
static void ilk_update_sprite_wm(struct drm_plane *plane,
struct drm_crtc *crtc,
uint32_t sprite_width, int pixel_size,
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 07/16] drm/i915: Add vblank based delayed watermark update mechanism
From: Ville Syrjälä
Add a mechanism by which you can queue up watermark update to happen
after the vblank counter has reached a certain value. The vblank
interrupt handler will schedule a work which will do the actual
watermark programming in process context.
v2: Rebase and s/intel_crtc/crtc/
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_irq.c | 12 ++-
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 27 +++
drivers/gpu/drm/i915/intel_pm.c | 144 +++
5 files changed, 183 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a2302a7..c90d5ac 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1541,6 +1541,8 @@ struct drm_i915_private {
* state as well as the actual hardware registers
*/
struct mutex mutex;
+
+ struct work_struct work;
} wm;
struct i915_runtime_pm pm;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 304f86a..c680020 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2067,8 +2067,10 @@ static void ilk_display_irq_handler(struct drm_device
*dev, u32 de_iir)
DRM_ERROR("Poison interrupt\n");
for_each_pipe(pipe) {
- if (de_iir & DE_PIPE_VBLANK(pipe))
+ if (de_iir & DE_PIPE_VBLANK(pipe)) {
intel_pipe_handle_vblank(dev, pipe);
+ ilk_update_pipe_wm(dev, pipe);
+ }
if (de_iir & DE_PIPE_FIFO_UNDERRUN(pipe))
if (intel_set_cpu_fifo_underrun_reporting(dev, pipe,
false))
@@ -2117,8 +2119,10 @@ static void ivb_display_irq_handler(struct drm_device
*dev, u32 de_iir)
intel_opregion_asle_intr(dev);
for_each_pipe(pipe) {
- if (de_iir & (DE_PIPE_VBLANK_IVB(pipe)))
+ if (de_iir & (DE_PIPE_VBLANK_IVB(pipe))) {
intel_pipe_handle_vblank(dev, pipe);
+ ilk_update_pipe_wm(dev, pipe);
+ }
/* plane/pipes map 1:1 on ilk+ */
if (de_iir & DE_PLANE_FLIP_DONE_IVB(pipe)) {
@@ -2260,8 +2264,10 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
continue;
pipe_iir = I915_READ(GEN8_DE_PIPE_IIR(pipe));
- if (pipe_iir & GEN8_PIPE_VBLANK)
+ if (pipe_iir & GEN8_PIPE_VBLANK) {
intel_pipe_handle_vblank(dev, pipe);
+ ilk_update_pipe_wm(dev, pipe);
+ }
if (pipe_iir & GEN8_PIPE_PRIMARY_FLIP_DONE) {
intel_prepare_page_flip(dev, pipe);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a11bd78..408b238 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10961,6 +10961,7 @@ static void intel_crtc_init(struct drm_device *dev, int
pipe)
intel_crtc->plane = !pipe;
}
+ spin_lock_init(&intel_crtc->wm.lock);
init_waitqueue_head(&intel_crtc->vbl_wait);
BUG_ON(pipe >= ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) ||
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d75cc2b..72f01b1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -409,6 +409,32 @@ struct intel_crtc {
* protected by dev_priv->wm.mutex
*/
struct intel_pipe_wm active;
+ /*
+* watermarks queued for next vblank
+* protected by dev_priv->wm.mutex
+*/
+ struct intel_pipe_wm pending;
+
+ /*
+* the vblank count after which we can switch over to 'pending'
+* protected by intel_crtc->wm.lock
+*/
+ u32 pending_vbl_count;
+ /*
+* indicates that 'pending' contains changed watermarks
+* protected by intel_crtc->wm.lock
+*/
+ bool dirty;
+ /*
+* watermark update has a vblank reference?
+* protected by intel_crtc->wm.lock
+*/
+ bool vblank;
+
+ /*
+* protects some intel_crtc->wm state
+*/
+ spinlock_t lock;
} wm;
wait_queue_head_t vbl_wait;
@@ -974,6 +1000,7 @@ void intel_runtime_pm_put(struct drm_i915_private
*dev_priv);
void intel_init_runtime_pm(struct drm_i915_private *dev_priv);
void intel_fini_runtime_pm(struct drm_i915_private *dev_priv);
void ilk_wm_get_hw_state(struct drm_device *d
[Intel-gfx] [PATCH v2 08/16] drm/i915: Split watermark programming into pre and post steps
From: Ville Syrjälä
We need to perform watermark programming before and after changing the
plane configuration. Add two new vfuncs to do that. The pre phase is
supposed to switch over to the intermediate watermarks which are
computed so that they can deal with both the old and new plane
configurations. The post phase will arm the vblank based update
systems to switch over to the optimal target watermarks after the
plane configuration has for sure changed.
v2: Pass around intel_crtc and s/intel_crtc/crtc/
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 5 +++
drivers/gpu/drm/i915/intel_drv.h | 11 +
drivers/gpu/drm/i915/intel_pm.c | 88
3 files changed, 104 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c90d5ac..d4f8ae8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -407,6 +407,7 @@ struct intel_plane_config;
struct intel_crtc;
struct intel_limit;
struct dpll;
+struct intel_crtc_wm_config;
struct drm_i915_display_funcs {
bool (*fbc_enabled)(struct drm_device *dev);
@@ -437,6 +438,10 @@ struct drm_i915_display_funcs {
struct drm_crtc *crtc,
uint32_t sprite_width, int pixel_size,
bool enable, bool scaled);
+ void (*program_wm_pre)(struct intel_crtc *crtc,
+ const struct intel_crtc_wm_config *config);
+ void (*program_wm_post)(struct intel_crtc *crtc,
+ const struct intel_crtc_wm_config *config);
void (*modeset_global_resources)(struct drm_device *dev);
/* Returns the active state of the crtc, and if the crtc is active,
* fills out the pipe-config with the hw state. */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 72f01b1..4b59be3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -358,6 +358,13 @@ struct intel_pipe_wm {
bool sprites_scaled;
};
+struct intel_crtc_wm_config {
+ /* target watermarks for the pipe */
+ struct intel_pipe_wm target;
+ /* intermediate watermarks for pending/active->target transition */
+ struct intel_pipe_wm intm;
+};
+
struct intel_crtc {
struct drm_crtc base;
enum pipe pipe;
@@ -1001,6 +1008,10 @@ void intel_init_runtime_pm(struct drm_i915_private
*dev_priv);
void intel_fini_runtime_pm(struct drm_i915_private *dev_priv);
void ilk_wm_get_hw_state(struct drm_device *dev);
void ilk_update_pipe_wm(struct drm_device *dev, enum pipe pipe);
+void intel_program_watermarks_pre(struct intel_crtc *crtc,
+ const struct intel_crtc_wm_config *config);
+void intel_program_watermarks_post(struct intel_crtc *crtc,
+ const struct intel_crtc_wm_config *config);
/* intel_sdvo.c */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6fc6416..ccf920a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2950,6 +2950,20 @@ void ilk_update_pipe_wm(struct drm_device *dev, enum
pipe pipe)
spin_unlock(&crtc->wm.lock);
}
+static void ilk_wm_cancel(struct intel_crtc *crtc)
+{
+ struct drm_device *dev = crtc->base.dev;
+
+ assert_spin_locked(&crtc->wm.lock);
+
+ crtc->wm.dirty = false;
+
+ if (crtc->wm.vblank) {
+ drm_vblank_put(dev, crtc->pipe);
+ crtc->wm.vblank = false;
+ }
+}
+
static void ilk_update_sprite_wm(struct drm_plane *plane,
struct drm_crtc *crtc,
uint32_t sprite_width, int pixel_size,
@@ -3084,6 +3098,24 @@ void intel_update_sprite_watermarks(struct drm_plane
*plane,
pixel_size, enabled, scaled);
}
+void intel_program_watermarks_pre(struct intel_crtc *crtc,
+ const struct intel_crtc_wm_config *config)
+{
+ struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
+
+ if (dev_priv->display.program_wm_pre)
+ dev_priv->display.program_wm_pre(crtc, config);
+}
+
+void intel_program_watermarks_post(struct intel_crtc *crtc,
+ const struct intel_crtc_wm_config *config)
+{
+ struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
+
+ if (dev_priv->display.program_wm_post)
+ dev_priv->display.program_wm_post(crtc, config);
+}
+
static struct drm_i915_gem_object *
intel_alloc_context_page(struct drm_device *dev)
{
@@ -6522,6 +6554,60 @@ void intel_fini_runtime_pm(struct drm_i915_private
*dev_priv)
pm_runtime_disable(device);
}
+static void ilk_program_wm_pre(struct intel_crtc *crtc,
+ const struct intel_c
[Intel-gfx] [PATCH 06/16] drm/i915: Add dev_priv->wm.mutex
From: Ville Syrjälä
Add a mutex to protect most of the watermark state. Will be useful when
we start to update watermarks asynchronously from plane updates, or
when we get finer grained locking for planes.
Reviewed-by: Paulo Zanoni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 11 ++-
drivers/gpu/drm/i915/intel_drv.h | 5 -
drivers/gpu/drm/i915/intel_pm.c | 21 +++--
3 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 459b02a..a2302a7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1530,8 +1530,17 @@ struct drm_i915_private {
/* cursor */
uint16_t cur_latency[5];
- /* current hardware state */
+ /*
+* current hardware state
+* protected by dev_priv->wm.mutex
+*/
struct ilk_wm_values hw;
+
+ /*
+* protects some dev_priv->wm and intel_crtc->wm
+* state as well as the actual hardware registers
+*/
+ struct mutex mutex;
} wm;
struct i915_runtime_pm pm;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d7c52b2..d75cc2b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -404,7 +404,10 @@ struct intel_crtc {
/* per-pipe watermark state */
struct {
- /* watermarks currently being used */
+ /*
+* watermarks currently being used
+* protected by dev_priv->wm.mutex
+*/
struct intel_pipe_wm active;
} wm;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2185553..2a63418 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2743,8 +2743,13 @@ static void ilk_write_wm_values(struct drm_i915_private
*dev_priv,
static bool ilk_disable_lp_wm(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ bool changed;
+
+ mutex_lock(&dev_priv->wm.mutex);
+ changed = _ilk_disable_lp_wm(dev_priv, WM_DIRTY_LP_ALL);
+ mutex_unlock(&dev_priv->wm.mutex);
- return _ilk_disable_lp_wm(dev_priv, WM_DIRTY_LP_ALL);
+ return changed;
}
static void ilk_program_watermarks(struct drm_device *dev)
@@ -2784,6 +2789,7 @@ static void ilk_update_wm(struct drm_crtc *crtc)
{
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
struct ilk_pipe_wm_parameters params = {};
struct intel_pipe_wm pipe_wm = {};
@@ -2791,12 +2797,17 @@ static void ilk_update_wm(struct drm_crtc *crtc)
intel_compute_pipe_wm(crtc, ¶ms, &pipe_wm);
+ mutex_lock(&dev_priv->wm.mutex);
+
if (!memcmp(&intel_crtc->wm.active, &pipe_wm, sizeof(pipe_wm)))
- return;
+ goto unlock;
intel_crtc->wm.active = pipe_wm;
ilk_program_watermarks(dev);
+
+ unlock:
+ mutex_unlock(&dev_priv->wm.mutex);
}
static void ilk_update_sprite_wm(struct drm_plane *plane,
@@ -2868,10 +2879,14 @@ void ilk_wm_get_hw_state(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_crtc *crtc;
+ mutex_lock(&dev_priv->wm.mutex);
+
_ilk_wm_get_hw_state(dev, &dev_priv->wm.hw);
for_each_crtc(dev, crtc)
_ilk_pipe_wm_hw_to_sw(crtc);
+
+ mutex_unlock(&dev_priv->wm.mutex);
}
/**
@@ -6369,6 +6384,8 @@ void intel_init_pm(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ mutex_init(&dev_priv->wm.mutex);
+
if (HAS_FBC(dev)) {
if (INTEL_INFO(dev)->gen >= 7) {
dev_priv->display.fbc_enabled = ironlake_fbc_enabled;
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 09/16] drm/i915: Actually perform the watermark update in two phases
From: Ville Syrjälä
Switch the code over to using the two phase watermark update. The steps
generally follow this pattern:
1. Calculate new plane parameters for changed planes
2. Calculate new target and intermediate watermarks
3. Check that both the target and intermediate watermarks are valid
4. Program the hardware with the intermediate watermarks
5. Program the plane registers
6. Arm the vblank watermark update machinery for the next vblank
7. Program the hardware with the target watermarks (after vblank)
v2: Rebased, pass intel_crtc around, s/intel_crtc/crtc/
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 14 ++-
drivers/gpu/drm/i915/intel_display.c | 58 -
drivers/gpu/drm/i915/intel_drv.h | 35 --
drivers/gpu/drm/i915/intel_pm.c | 229 +++
drivers/gpu/drm/i915/intel_sprite.c | 119 --
5 files changed, 347 insertions(+), 108 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d4f8ae8..5b1404e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -405,9 +405,12 @@ struct intel_connector;
struct intel_crtc_config;
struct intel_plane_config;
struct intel_crtc;
+struct intel_plane;
struct intel_limit;
struct dpll;
struct intel_crtc_wm_config;
+struct intel_plane_wm_parameters;
+struct intel_crtc_wm_config;
struct drm_i915_display_funcs {
bool (*fbc_enabled)(struct drm_device *dev);
@@ -434,10 +437,13 @@ struct drm_i915_display_funcs {
struct dpll *match_clock,
struct dpll *best_clock);
void (*update_wm)(struct drm_crtc *crtc);
- void (*update_sprite_wm)(struct drm_plane *plane,
-struct drm_crtc *crtc,
-uint32_t sprite_width, int pixel_size,
-bool enable, bool scaled);
+ int (*update_primary_wm)(struct intel_crtc *crtc,
+struct intel_crtc_wm_config *config);
+ int (*update_cursor_wm)(struct intel_crtc *crtc,
+ struct intel_crtc_wm_config *config);
+ int (*update_sprite_wm)(struct intel_plane *plane,
+ struct intel_crtc *crtc,
+ struct intel_crtc_wm_config *config);
void (*program_wm_pre)(struct intel_crtc *crtc,
const struct intel_crtc_wm_config *config);
void (*program_wm_post)(struct intel_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 408b238..5bf1633 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2078,6 +2078,19 @@ void intel_flush_primary_plane(struct drm_i915_private
*dev_priv,
POSTING_READ(reg);
}
+static void update_pri_params(struct intel_crtc *crtc,
+ struct intel_plane_wm_parameters *params,
+ bool primary_enabled)
+{
+ if (!crtc->active || !primary_enabled)
+ return;
+
+ params->horiz_pixels = crtc->config.pipe_src_w;
+ params->bytes_per_pixel =
+ drm_format_plane_cpp(crtc->base.primary->fb->pixel_format, 0);
+ params->enabled = true;
+}
+
/**
* intel_enable_primary_hw_plane - enable the primary plane on a given pipe
* @dev_priv: i915 private structure
@@ -2091,6 +2104,8 @@ static void intel_enable_primary_hw_plane(struct
drm_i915_private *dev_priv,
{
struct intel_crtc *intel_crtc =
to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
+ struct intel_crtc_wm_config config = {};
+ int ret;
int reg;
u32 val;
@@ -2100,14 +2115,24 @@ static void intel_enable_primary_hw_plane(struct
drm_i915_private *dev_priv,
if (intel_crtc->primary_enabled)
return;
+ update_pri_params(intel_crtc, &config.pri, true);
+
+ ret = intel_update_primary_watermarks(intel_crtc, &config);
+ WARN(ret, "primary watermarks invalid\n");
+
intel_crtc->primary_enabled = true;
reg = DSPCNTR(plane);
val = I915_READ(reg);
WARN_ON(val & DISPLAY_PLANE_ENABLE);
+ intel_crtc->pri_wm = config.pri;
+ intel_program_watermarks_pre(intel_crtc, &config);
+
I915_WRITE(reg, val | DISPLAY_PLANE_ENABLE);
intel_flush_primary_plane(dev_priv, plane);
+
+ intel_program_watermarks_post(intel_crtc, &config);
}
/**
@@ -2123,20 +2148,32 @@ static void intel_disable_primary_hw_plane(struct
drm_i915_private *dev_priv,
{
struct intel_crtc *intel_crtc =
to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
+ struct intel_crtc_wm_config config = {};
+ int ret;
int reg;
u32 val;
if (!intel_crtc->primary_enabled)
return;
+ update_pri_
[Intel-gfx] [PATCH v2 10/16] drm/i915: Wait for watermark updates to finish before disabling a pipe
From: Ville Syrjälä
After we've disabled the planes, it seems like a good idea wait for
the vblank driven watermark updates to finish before we turn off the
vblank interrupts and eventually the entire pipe.
v2: Rebase and s/intel_crtc/crtc/
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 32
4 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5b1404e..1fe0cac 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1554,6 +1554,7 @@ struct drm_i915_private {
struct mutex mutex;
struct work_struct work;
+ wait_queue_head_t wait;
} wm;
struct i915_runtime_pm pm;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5bf1633..ca362db 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3960,6 +3960,8 @@ static void intel_crtc_disable_planes(struct drm_crtc
*crtc)
intel_disable_planes(crtc);
intel_disable_primary_hw_plane(dev_priv, plane, pipe);
+ ilk_wm_synchronize(intel_crtc);
+
drm_vblank_off(dev, pipe);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1ec4379..5ad7ad5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1021,6 +1021,7 @@ void intel_program_watermarks_pre(struct intel_crtc *crtc,
const struct intel_crtc_wm_config *config);
void intel_program_watermarks_post(struct intel_crtc *crtc,
const struct intel_crtc_wm_config *config);
+void ilk_wm_synchronize(struct intel_crtc *crtc);
/* intel_sdvo.c */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 13366b7..1c072cd 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2812,6 +2812,7 @@ static bool ilk_pending_watermarks_ready(struct
intel_crtc *crtc)
static bool ilk_refresh_pending_watermarks(struct drm_device *dev)
{
+ struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *crtc;
bool changed = false;
@@ -2833,6 +2834,9 @@ static bool ilk_refresh_pending_watermarks(struct
drm_device *dev)
changed = true;
}
+ if (changed)
+ wake_up_all(&dev_priv->wm.wait);
+
return changed;
}
@@ -3029,6 +3033,33 @@ static void ilk_wm_cancel(struct intel_crtc *crtc)
}
}
+void ilk_wm_synchronize(struct intel_crtc *crtc)
+{
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ enum pipe pipe = crtc->pipe;
+ unsigned long timeout = msecs_to_jiffies(100);
+
+ wait_event_timeout(dev_priv->wm.wait, !crtc->wm.dirty, timeout);
+
+ mutex_lock(&dev_priv->wm.mutex);
+
+ spin_lock_irq(&crtc->wm.lock);
+
+ WARN(crtc->wm.dirty, "pipe %c watermark updates failed to complete\n",
+pipe_name(pipe));
+
+ /* clean up if something is left behind */
+ ilk_wm_cancel(crtc);
+
+ spin_unlock_irq(&crtc->wm.lock);
+
+ /* pending update (if any) got cancelled */
+ crtc->wm.pending = crtc->wm.active;
+
+ mutex_unlock(&dev_priv->wm.mutex);
+}
+
static int ilk_update_primary_wm(struct intel_crtc *crtc,
struct intel_crtc_wm_config *config)
{
@@ -6736,6 +6767,7 @@ void intel_init_pm(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
mutex_init(&dev_priv->wm.mutex);
+ init_waitqueue_head(&dev_priv->wm.wait);
INIT_WORK(&dev_priv->wm.work, ilk_watermark_work);
if (HAS_FBC(dev)) {
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/16] drm/i915: Refactor get_other_active_crtc()
From: Ville Syrjälä
Pull the code to locate the other active crtc out from
haswell_mode_set_planes_workaround() into a separate function.
This will have another use later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ca362db..bccf414 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3965,6 +3965,26 @@ static void intel_crtc_disable_planes(struct drm_crtc
*crtc)
drm_vblank_off(dev, pipe);
}
+static struct intel_crtc *get_other_active_crtc(struct intel_crtc *crtc)
+{
+ struct drm_device *dev = crtc->base.dev;
+ struct intel_crtc *crtc_it, *other_active_crtc = NULL;
+
+ /* We want to get the other_active_crtc only if there's only 1 other
+* active crtc. */
+ for_each_intel_crtc(dev, crtc_it) {
+ if (!crtc_it->active || crtc_it == crtc)
+ continue;
+
+ if (other_active_crtc)
+ return NULL;
+
+ other_active_crtc = crtc_it;
+ }
+
+ return other_active_crtc;
+}
+
static void ironlake_crtc_enable(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
@@ -4057,19 +4077,8 @@ static bool hsw_crtc_supports_ips(struct intel_crtc
*crtc)
static void haswell_mode_set_planes_workaround(struct intel_crtc *crtc)
{
struct drm_device *dev = crtc->base.dev;
- struct intel_crtc *crtc_it, *other_active_crtc = NULL;
-
- /* We want to get the other_active_crtc only if there's only 1 other
-* active crtc. */
- for_each_intel_crtc(dev, crtc_it) {
- if (!crtc_it->active || crtc_it == crtc)
- continue;
+ struct intel_crtc *other_active_crtc = get_other_active_crtc(crtc);
- if (other_active_crtc)
- return;
-
- other_active_crtc = crtc_it;
- }
if (!other_active_crtc)
return;
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/16] drm/i915: Disable LP1+ watermarks while changing the number of active pipes
From: Ville Syrjälä
When we switch between one active pipe and multiple active pipes, the
display FIFO gets repartitioned. Disable the LP1+ waterwarks while that
is happening to make sure we don't get any glitches on other active
pipes while doing a modeset on another other pipe.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 45 ++
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_pm.c | 47
3 files changed, 89 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bccf414..311c0f0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3985,6 +3985,27 @@ static struct intel_crtc *get_other_active_crtc(struct
intel_crtc *crtc)
return other_active_crtc;
}
+static void ilk_prepare_for_num_pipes_change(struct intel_crtc *crtc)
+{
+ struct drm_device *dev = crtc->base.dev;
+ struct intel_crtc *other_active_crtc = get_other_active_crtc(crtc);
+
+ /*
+* If we change between one pipe and multiple pipes,
+* make sure the other active pipe is prepared
+* for having its FIFO resized. We do that by making
+* sure the pipe isn't using LP1+ watermarks when
+* the second pipe gets enabled or disabled.
+*/
+ if (!other_active_crtc)
+ return;
+
+ ilk_wm_synchronize(other_active_crtc);
+
+ if (ilk_disable_lp_wm(dev))
+ intel_wait_for_vblank(dev, other_active_crtc->pipe);
+}
+
static void ironlake_crtc_enable(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
@@ -4023,6 +4044,9 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
intel_crtc->active = true;
+ /* Make sure other pipes are prepared for FIFO resizing */
+ ilk_prepare_for_num_pipes_change(intel_crtc);
+
intel_set_cpu_fifo_underrun_reporting(dev, pipe, true);
intel_set_pch_fifo_underrun_reporting(dev, pipe, true);
@@ -4123,6 +4147,9 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
intel_crtc->active = true;
+ /* Make sure other pipes are prepared for FIFO resizing */
+ ilk_prepare_for_num_pipes_change(intel_crtc);
+
intel_set_cpu_fifo_underrun_reporting(dev, pipe, true);
if (intel_crtc->config.has_pch_encoder)
intel_set_pch_fifo_underrun_reporting(dev, TRANSCODER_A, true);
@@ -4192,6 +4219,9 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
intel_crtc_disable_planes(crtc);
+ /* Make sure other pipes are prepared for FIFO resizing */
+ ilk_prepare_for_num_pipes_change(intel_crtc);
+
for_each_encoder_on_crtc(dev, crtc, encoder)
encoder->disable(encoder);
@@ -4235,6 +4265,12 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
intel_crtc->active = false;
+ /*
+* Potentially let some other pipe use the
+* full FIFO, and re-enable LP1+ watermarks.
+*/
+ ilk_wm_pipe_post_disable(intel_crtc);
+
mutex_lock(&dev->struct_mutex);
intel_update_fbc(dev);
intel_edp_psr_update(dev);
@@ -4255,6 +4291,9 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
intel_crtc_disable_planes(crtc);
+ /* Make sure other pipes are prepared for FIFO resizing */
+ ilk_prepare_for_num_pipes_change(intel_crtc);
+
for_each_encoder_on_crtc(dev, crtc, encoder) {
intel_opregion_notify_encoder(encoder, false);
encoder->disable(encoder);
@@ -4282,6 +4321,12 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
intel_crtc->active = false;
+ /*
+* Potentially let some other pipe use the
+* full FIFO, and re-enable LP1+ watermarks.
+*/
+ ilk_wm_pipe_post_disable(intel_crtc);
+
mutex_lock(&dev->struct_mutex);
intel_update_fbc(dev);
intel_edp_psr_update(dev);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5ad7ad5..98f878f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1022,6 +1022,8 @@ void intel_program_watermarks_pre(struct intel_crtc *crtc,
void intel_program_watermarks_post(struct intel_crtc *crtc,
const struct intel_crtc_wm_config *config);
void ilk_wm_synchronize(struct intel_crtc *crtc);
+void ilk_wm_pipe_post_disable(struct intel_crtc *crtc);
+bool ilk_disable_lp_wm(struct drm_device *dev);
/* intel_sdvo.c */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1c072cd..18ea8b1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2765,7 +2765,7 @@ static void ilk_write_wm_values(struct drm_i915_private
*dev_priv,
}
}
-static bool il
[Intel-gfx] [PATCH v2 13/16] drm/i915: Keep track of who disabled LP1+ watermarks
From: Ville Syrjälä
Currently ilk_disable_lp_wm() just disabled LP1+ watermarks directly.
However there's nothing preventing someone else from re-enabling them
immediately. To make sure sure LP1+ watermarks stay disabled for the
intended period, keep track which pipes require the LP1+ watermarks
to be disabled.
v2: Rebase and s/intel_crtc/crtc/
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 22 ++
4 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1fe0cac..02ffbfc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1548,6 +1548,12 @@ struct drm_i915_private {
struct ilk_wm_values hw;
/*
+* bitmask of pipes that have requested
+* LP1+ watermarks to be disabled.
+*/
+ unsigned int lp_disabled;
+
+ /*
* protects some dev_priv->wm and intel_crtc->wm
* state as well as the actual hardware registers
*/
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 311c0f0..879c649 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4002,7 +4002,7 @@ static void ilk_prepare_for_num_pipes_change(struct
intel_crtc *crtc)
ilk_wm_synchronize(other_active_crtc);
- if (ilk_disable_lp_wm(dev))
+ if (ilk_disable_lp_wm(crtc))
intel_wait_for_vblank(dev, other_active_crtc->pipe);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 98f878f..2a3ad60 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1023,7 +1023,7 @@ void intel_program_watermarks_post(struct intel_crtc
*crtc,
const struct intel_crtc_wm_config *config);
void ilk_wm_synchronize(struct intel_crtc *crtc);
void ilk_wm_pipe_post_disable(struct intel_crtc *crtc);
-bool ilk_disable_lp_wm(struct drm_device *dev);
+bool ilk_disable_lp_wm(struct intel_crtc *crtc);
/* intel_sdvo.c */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 18ea8b1..17f1769 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2428,6 +2428,7 @@ static void ilk_compute_wm_results(struct drm_device *dev,
enum intel_ddb_partitioning partitioning,
struct ilk_wm_values *results)
{
+ struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc;
int level, wm_lp;
@@ -2451,7 +2452,7 @@ static void ilk_compute_wm_results(struct drm_device *dev,
(r->pri_val << WM1_LP_SR_SHIFT) |
r->cur_val;
- if (r->enable)
+ if (r->enable && !dev_priv->wm.lp_disabled)
results->wm_lp[wm_lp - 1] |= WM1_LP_SR_EN;
if (INTEL_INFO(dev)->gen >= 8)
@@ -2765,13 +2766,18 @@ static void ilk_write_wm_values(struct drm_i915_private
*dev_priv,
}
}
-bool ilk_disable_lp_wm(struct drm_device *dev)
+bool ilk_disable_lp_wm(struct intel_crtc *crtc)
{
+ struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
bool changed;
mutex_lock(&dev_priv->wm.mutex);
+
+ dev_priv->wm.lp_disabled |= 1 << crtc->pipe;
+
changed = _ilk_disable_lp_wm(dev_priv, WM_DIRTY_LP_ALL);
+
mutex_unlock(&dev_priv->wm.mutex);
return changed;
@@ -2889,15 +2895,20 @@ static void ilk_setup_pending_watermarks(struct
intel_crtc *crtc,
u32 vbl_count)
{
struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
enum pipe pipe = crtc->pipe;
WARN(!crtc->active, "pipe %c should be enabled\n",
pipe_name(pipe));
/* do the watermarks actually need changing? */
- if (!memcmp(&crtc->wm.pending, pipe_wm, sizeof(*pipe_wm)))
+ if (!(dev_priv->wm.lp_disabled & (1 << pipe)) &&
+ !memcmp(&crtc->wm.pending, pipe_wm, sizeof(*pipe_wm)))
return;
+ /* allow LP1+ watermarks again */
+ dev_priv->wm.lp_disabled &= ~(1 << pipe);
+
crtc->wm.pending = *pipe_wm;
spin_lock_irq(&crtc->wm.lock);
@@ -3092,6 +3103,9 @@ void ilk_wm_pipe_post_disable(struct intel_crtc *crtc)
/* pending update (if any) got cancelled */
crtc->wm.pending = crtc->wm.active;
+ /* allow LP1+ watermarks again */
+ dev_priv->wm.lp_disabled &= ~(1 << crtc->pipe);
+
ilk_update_waterm
[Intel-gfx] [PATCH 15/16] drm/i915: Add a workaround for sprite only <-> primary only switching
From: Ville Syrjälä ILK and IVB don't like switching between sprite only and primary only configurations when LP1+ watermarks have been enabled in the recent past. Like WaCxSRDisabledForSpriteScaling we can avoid the flash by disabling LP1+ watermarks for one frame before the critical plane reconfiguration. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 66af79d..ea1f990 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3175,9 +3175,18 @@ static int ilk_update_sprite_wm(struct intel_plane *plane, * when scaling is disabled. * * WaCxSRDisabledForSpriteScaling:ivb +* +* We also seem to need something similar when switching between +* primary only and sprite only configurations. Otherwise the screen +* flashes black. No underrun reported though. */ if (IS_IVYBRIDGE(dev) && config->spr.scaled && ilk_disable_lp_wm(crtc)) intel_wait_for_vblank(dev, plane->pipe); + else if (config->pri.enabled != config->spr.enabled && +config->pri.enabled != params.pri.enabled && +config->spr.enabled != params.spr.enabled && +ilk_disable_lp_wm(crtc)) + intel_wait_for_vblank(dev, plane->pipe); params.pri = config->pri; params.spr = config->spr; -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/16] drm/i915: Don't disable LP1+ watermarks for every frame when scaled
From: Ville Syrjälä If we mark the LP1+ watermarks as disabled every time sprite scaling is enabled, we end doing pointless work applying watermarks even though nothing has changed. This is an artifact of the way dev_priv->wm.lp_disabled affects the operation of ilk_setup_pending_watermarks(). If the current pipe is included in dev_priv->wm.lp_disabled, ilk_setup_pending_watermarks() will not check if the watermarks actually changed since it will assume it will need to disable LP1+ watermarks anyway. A quick fix is to just check if sprite scaling was enabled for the previous plane update, and if so, we know that LP1+ watermarks must already be disabled. It might be better in long run to attempt to change the way the LP1+ disable tracking integrates with the rest of the watermark update mechanism. But this seems like a simple enough solution for now. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index ea1f990..0365ea6 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3180,7 +3180,8 @@ static int ilk_update_sprite_wm(struct intel_plane *plane, * primary only and sprite only configurations. Otherwise the screen * flashes black. No underrun reported though. */ - if (IS_IVYBRIDGE(dev) && config->spr.scaled && ilk_disable_lp_wm(crtc)) + if (IS_IVYBRIDGE(dev) && !params.spr.scaled && + config->spr.scaled && ilk_disable_lp_wm(crtc)) intel_wait_for_vblank(dev, plane->pipe); else if (config->pri.enabled != config->spr.enabled && config->pri.enabled != params.pri.enabled && -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/16] drm/i915: Prefer the 5/6 DDB split when primary is disabled
From: Ville Syrjälä
When the primary plane is disabled, pick the 5/6 DDB split to give the
sprite as much FIFO space as possible.
The normal heuristic of just looking at the highest valid WM level won't
necessarily pick the optimal split since both splits might have the same
number of levels enabled.
Preferring the 5/6 split won't actually affect the watermarks here, but
it does give more FIFO space to the sprite leading to potentially longer
periods spent in LP1+ states since the FIFO takes longer to drain.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 27 ++-
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2a3ad60..4575017 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -354,6 +354,7 @@ struct intel_pipe_wm {
uint32_t linetime;
bool fbc_wm_enabled;
bool pipe_enabled;
+ bool primary_enabled;
bool sprites_enabled;
bool sprites_scaled;
};
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 17f1769..66af79d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1736,6 +1736,7 @@ struct ilk_wm_maximums {
/* used in computing the new watermarks state */
struct intel_wm_config {
unsigned int num_pipes_active;
+ bool primary_enabled;
bool sprites_enabled;
bool sprites_scaled;
};
@@ -2212,6 +2213,7 @@ static void ilk_compute_wm_config(struct drm_device *dev,
if (!wm->pipe_enabled)
continue;
+ config->primary_enabled |= wm->primary_enabled;
config->sprites_enabled |= wm->sprites_enabled;
config->sprites_scaled |= wm->sprites_scaled;
config->num_pipes_active++;
@@ -2224,6 +2226,7 @@ static bool ilk_validate_pipe_wm(struct drm_device *dev,
/* LP0 watermark maximums depend on this pipe alone */
const struct intel_wm_config config = {
.num_pipes_active = 1,
+ .primary_enabled = pipe_wm->primary_enabled,
.sprites_enabled = pipe_wm->sprites_enabled,
.sprites_scaled = pipe_wm->sprites_scaled,
};
@@ -2247,6 +2250,7 @@ static bool intel_compute_pipe_wm(struct drm_crtc *crtc,
struct ilk_wm_maximums max;
pipe_wm->pipe_enabled = params->active;
+ pipe_wm->primary_enabled = params->pri.enabled;
pipe_wm->sprites_enabled = params->spr.enabled;
pipe_wm->sprites_scaled = params->spr.scaled;
@@ -2299,6 +2303,7 @@ static void ilk_wm_merge_intermediate(struct drm_device
*dev,
int level, max_level = ilk_wm_max_level(dev);
a->pipe_enabled |= b->pipe_enabled;
+ a->primary_enabled |= b->primary_enabled;
a->sprites_enabled |= b->sprites_enabled;
a->sprites_scaled |= b->sprites_scaled;
@@ -2491,11 +2496,21 @@ static void ilk_compute_wm_results(struct drm_device
*dev,
}
}
-/* Find the result with the highest level enabled. Check for enable_fbc_wm in
- * case both are at the same level. Prefer r1 in case they're the same. */
+/*
+ * Find the result with the highest level enabled.
+ * When the max level for each result is the same, pick r2
+ * when the primary plane is disabled, otherwise prefer the
+ * result which has FBC WM enabled. All else being equal, pick
+ * r1.
+ *
+ * FIXME should ideally calculate the FIFO drain time for each
+ * plane, and determine which split has the chance to keep
+ * the memory asleep for longest.
+ */
static struct intel_pipe_wm *ilk_find_best_result(struct drm_device *dev,
struct intel_pipe_wm *r1,
- struct intel_pipe_wm *r2)
+ struct intel_pipe_wm *r2,
+ bool primary_enabled)
{
int level, max_level = ilk_wm_max_level(dev);
int level1 = 0, level2 = 0;
@@ -2508,7 +2523,8 @@ static struct intel_pipe_wm *ilk_find_best_result(struct
drm_device *dev,
}
if (level1 == level2) {
- if (r2->fbc_wm_enabled && !r1->fbc_wm_enabled)
+ if (!primary_enabled ||
+ (r2->fbc_wm_enabled && !r1->fbc_wm_enabled))
return r2;
else
return r1;
@@ -2866,7 +2882,8 @@ static void ilk_program_watermarks(struct drm_device *dev)
ilk_compute_wm_maximums(dev, 1, &config, INTEL_DDB_PART_5_6,
&max);
ilk_wm_merge(dev, &config, &max, &lp_wm_5_6);
- best_lp_wm = ilk_find_best_result(dev, &lp_wm_1_2, &lp_wm_5_6);
+ best_lp_wm = ilk_find_best_result(dev, &lp_wm_1_2, &lp_wm_5_6,
+
Re: [Intel-gfx] [alsa-devel] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
> -Original Message- > From: Vetter, Daniel > Sent: Tuesday, May 20, 2014 11:08 PM > > On 20/05/2014 16:57, Thierry Reding wrote: > > On Tue, May 20, 2014 at 04:45:56PM +0200, Daniel Vetter wrote: > >> >On Tue, May 20, 2014 at 4:29 PM, Imre Deak > wrote: > >>> > >On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote: > > >>This RFC is based on previous discussion to set up a generic > > >>communication channel between display and audio driver and an > > >>internal design of Intel MCG/VPG HDMI audio driver. It's still > > >>an initial draft and your advice would be appreciated to > > >>improve the design. > > >> > > >>The basic idea is to create a new avsink module and let both > > >>drm and alsa depend on it. > > >>This new module provides a framework and APIs for > > >>synchronization between the display and audio driver. > > >> > > >>1. Display/Audio Client > > >> > > >>The avsink core provides APIs to create, register and lookup a > > >>display/audio client. > > >>A specific display driver (eg. i915) or audio driver (eg. > > >>HD-Audio > > >>driver) can create a client, add some resources objects (shared > > >>power wells, display outputs, and audio inputs, register ops) > > >>to the client, and then register this client to avisink core. > > >>The peer driver can look up a registered client by a name or > > >>type, or both. If a client gives a valid peer client name on > > >>registration, avsink core will bind the two clients as peer for > > >>each other. And we expect a display client and an audio client > > >>to be peers for each other in a system. > >>> > > > >>> > >One problem we have at the moment is the order of calling the > >>> > >system suspend/resume handlers of the display driver wrt. that of > >>> > >the audio driver. Since the power well control is part of the > >>> > >display HW block, we need to run the display driver's resume > >>> > >handler first, initialize the HW, and only then let the audio > >>> > >driver's resume handler run. For similar reasons we have to call > >>> > >the audio suspend handler first and only then the display driver > >>> > >resume handler. Currently we solve this using the display > >>> > >driver's late/early suspend/resume hooks, but we'd need a more robust > solution. > >>> > > > >>> > >This seems to be a similar issue to the load time ordering > >>> > >problem that you describe later. Having a real device for avsync > >>> > >that would be a child of the display device would solve the > >>> > >ordering issue in both cases. I admit I haven't looked into it if > >>> > >this is feasible, but I would like to see some solution to this as > >>> > >part of > the plan. > >> > > >> >Yeah, this is a big reason why I want real devices - we have piles > >> >of infrastructure to solve these ordering issues as soon as there's > >> >a struct device around. If we don't use that, we need to reinvent > >> >all those wheels ourselves. > > To make the driver core's magic work I think you'd need to find a way > > to reparent the audio device under the display device. Presumably they > > come from two different parts of the device tree (two different PCI > > devices I would guess for Intel, two different platform devices on > > SoCs). Changing the parent after a device has been registered doesn't > > work as far as I know. But even assuming that would work, I have > > trouble imagining what the implications would be on the rest of the driver > model. > > > > I faced similar problems with the Tegra DRM driver, and the only way I > > can see to make this kind of interaction between devices work is by > > tacking on an extra layer outside the core driver model. > That's why we need a new avsink device which is a proper child of the gfx > device, and the audio driver needs to use the componentized device > framework so that the suspend/resume ordering works correctly. Or at least > that's been my idea, might be we have some small gaps here and there. > -Daniel Hi Daniel, Would you please share more info about your idea? - What would be an avsink device represent here? E.g. on Intel platforms, will the whole display device have a child avsink device or multiple avsink devices for each DDI port? - And for the relationship between audio driver and the avsink device, which would be the master and which would be the component? In addition, the component framework does not touch PM now. And introducing PM to the component framework seems not easy since there can be potential conflict caused by parent-child relationship of the involved devices. Thanks Mengdong ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Kill intel_crtc->vbl_wait
From: Ville Syrjälä
Share the waitqueue that drm_irq uses when performing the vblank evade
trick for atomic pipe updates.
Suggested-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 25 ++---
drivers/gpu/drm/i915/intel_display.c | 2 --
drivers/gpu/drm/i915/intel_drv.h | 2 --
drivers/gpu/drm/i915/intel_sprite.c | 5 +++--
4 files changed, 9 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 304f86a..5905a9d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1724,19 +1724,6 @@ static void gen6_rps_irq_handler(struct drm_i915_private
*dev_priv, u32 pm_iir)
}
}
-static bool intel_pipe_handle_vblank(struct drm_device *dev, enum pipe pipe)
-{
- struct intel_crtc *crtc;
-
- if (!drm_handle_vblank(dev, pipe))
- return false;
-
- crtc = to_intel_crtc(intel_get_crtc_for_pipe(dev, pipe));
- wake_up(&crtc->vbl_wait);
-
- return true;
-}
-
static void valleyview_pipestat_irq_handler(struct drm_device *dev, u32 iir)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -1791,7 +1778,7 @@ static void valleyview_pipestat_irq_handler(struct
drm_device *dev, u32 iir)
for_each_pipe(pipe) {
if (pipe_stats[pipe] & PIPE_START_VBLANK_INTERRUPT_STATUS)
- intel_pipe_handle_vblank(dev, pipe);
+ drm_handle_vblank(dev, pipe);
if (pipe_stats[pipe] & PLANE_FLIP_DONE_INT_STATUS_VLV) {
intel_prepare_page_flip(dev, pipe);
@@ -2068,7 +2055,7 @@ static void ilk_display_irq_handler(struct drm_device
*dev, u32 de_iir)
for_each_pipe(pipe) {
if (de_iir & DE_PIPE_VBLANK(pipe))
- intel_pipe_handle_vblank(dev, pipe);
+ drm_handle_vblank(dev, pipe);
if (de_iir & DE_PIPE_FIFO_UNDERRUN(pipe))
if (intel_set_cpu_fifo_underrun_reporting(dev, pipe,
false))
@@ -2118,7 +2105,7 @@ static void ivb_display_irq_handler(struct drm_device
*dev, u32 de_iir)
for_each_pipe(pipe) {
if (de_iir & (DE_PIPE_VBLANK_IVB(pipe)))
- intel_pipe_handle_vblank(dev, pipe);
+ drm_handle_vblank(dev, pipe);
/* plane/pipes map 1:1 on ilk+ */
if (de_iir & DE_PLANE_FLIP_DONE_IVB(pipe)) {
@@ -2261,7 +2248,7 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
pipe_iir = I915_READ(GEN8_DE_PIPE_IIR(pipe));
if (pipe_iir & GEN8_PIPE_VBLANK)
- intel_pipe_handle_vblank(dev, pipe);
+ drm_handle_vblank(dev, pipe);
if (pipe_iir & GEN8_PIPE_PRIMARY_FLIP_DONE) {
intel_prepare_page_flip(dev, pipe);
@@ -3731,7 +3718,7 @@ static bool i8xx_handle_vblank(struct drm_device *dev,
struct drm_i915_private *dev_priv = dev->dev_private;
u16 flip_pending = DISPLAY_PLANE_FLIP_PENDING(plane);
- if (!intel_pipe_handle_vblank(dev, pipe))
+ if (!drm_handle_vblank(dev, pipe))
return false;
if ((iir & flip_pending) == 0)
@@ -3916,7 +3903,7 @@ static bool i915_handle_vblank(struct drm_device *dev,
struct drm_i915_private *dev_priv = dev->dev_private;
u32 flip_pending = DISPLAY_PLANE_FLIP_PENDING(plane);
- if (!intel_pipe_handle_vblank(dev, pipe))
+ if (!drm_handle_vblank(dev, pipe))
return false;
if ((iir & flip_pending) == 0)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 019e9e1..aab638c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10966,8 +10966,6 @@ static void intel_crtc_init(struct drm_device *dev, int
pipe)
intel_crtc->plane = !pipe;
}
- init_waitqueue_head(&intel_crtc->vbl_wait);
-
BUG_ON(pipe >= ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) ||
dev_priv->plane_to_crtc_mapping[intel_crtc->plane] != NULL);
dev_priv->plane_to_crtc_mapping[intel_crtc->plane] = &intel_crtc->base;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d7c52b2..0071138 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -408,8 +408,6 @@ struct intel_crtc {
struct intel_pipe_wm active;
} wm;
- wait_queue_head_t vbl_wait;
-
int scanline_offset;
};
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index d6acd6b..7cd6a4f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -53,6 +53,7 @@ static bool intel_pipe_update_start(struct intel_crtc *crtc,
uint32_t *start_vbl
enum pipe
[Intel-gfx] [PATCH 1/2] drm: Add drm_crtc_vblank_waitqueue()
From: Ville Syrjälä
Add a small static inline helper to grab the vblank wait queue based on
the drm_crtc.
Suggested-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
include/drm/drmP.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 76ccaab..c294560 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1378,6 +1378,10 @@ extern int drm_calc_vbltimestamp_from_scanoutpos(struct
drm_device *dev,
extern void drm_calc_timestamping_constants(struct drm_crtc *crtc,
const struct drm_display_mode
*mode);
+static inline wait_queue_head_t *drm_crtc_vblank_waitqueue(struct drm_crtc
*crtc)
+{
+ return &crtc->dev->vblank[drm_crtc_index(crtc)].queue;
+}
/* Modesetting support */
extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] tests/kms_pipe_crc_basic: Add gpu hang tests
Currently pipe CRC support is broken after gpu hangs. This tests for
this bug.
Signed-off-by: Daniel Vetter
---
tests/kms_pipe_crc_basic.c | 60 --
1 file changed, 58 insertions(+), 2 deletions(-)
diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c
index eedb3f399e45..9eec4e6f75e5 100644
--- a/tests/kms_pipe_crc_basic.c
+++ b/tests/kms_pipe_crc_basic.c
@@ -31,6 +31,7 @@
#include "igt_debugfs.h"
#include "igt_kms.h"
#include "igt_aux.h"
+#include "ioctl_wrappers.h"
typedef struct {
int drm_fd;
@@ -38,6 +39,55 @@ typedef struct {
struct igt_fb fb;
} data_t;
+static uint64_t submit_batch(int fd, unsigned ring_id)
+{
+ const uint32_t batch[] = { MI_NOOP,
+ MI_BATCH_BUFFER_END };
+ struct drm_i915_gem_execbuffer2 execbuf;
+ struct drm_i915_gem_exec_object2 exec;
+ uint64_t presumed_offset;
+
+ gem_require_ring(fd, ring_id);
+
+ exec.handle = gem_create(fd, 4096);
+ gem_write(fd, exec.handle, 0, batch, sizeof(batch));
+ exec.relocation_count = 0;
+ exec.relocs_ptr = 0;
+ exec.alignment = 0;
+ exec.offset = 0;
+ exec.flags = 0;
+ exec.rsvd1 = 0;
+ exec.rsvd2 = 0;
+
+ execbuf.buffers_ptr = (uintptr_t)&exec;
+ execbuf.buffer_count = 1;
+ execbuf.batch_start_offset = 0;
+ execbuf.batch_len = sizeof(batch);
+ execbuf.cliprects_ptr = 0;
+ execbuf.num_cliprects = 0;
+ execbuf.DR1 = 0;
+ execbuf.DR4 = 0;
+ execbuf.flags = ring_id;
+ i915_execbuffer2_set_context_id(execbuf, 0);
+ execbuf.rsvd2 = 0;
+
+ gem_execbuf(fd, &execbuf);
+ gem_sync(fd, exec.handle);
+ presumed_offset = exec.offset;
+
+ igt_set_stop_rings(igt_to_stop_ring_flag(ring_id));
+
+ gem_execbuf(fd, &execbuf);
+ gem_sync(fd, exec.handle);
+
+ igt_assert(igt_get_stop_rings() == STOP_RING_NONE);
+ igt_assert(presumed_offset == exec.offset);
+
+ gem_close(fd, exec.handle);
+
+ return exec.offset;
+}
+
static void test_bad_command(data_t *data, const char *cmd)
{
FILE *ctl;
@@ -127,10 +177,10 @@ static void test_read_crc(data_t *data, int pipe,
unsigned flags)
}
+data_t data = {0, };
+
igt_main
{
- data_t data = {0, };
-
igt_skip_on_simulation();
igt_fixture {
@@ -167,6 +217,12 @@ igt_main
test_read_crc(&data, i, 0);
}
+
+ igt_subtest_f("hang-read-crc-pipe-%c", 'A'+i) {
+ submit_batch(data.drm_fd, I915_EXEC_RENDER);
+
+ test_read_crc(&data, i, 0);
+ }
}
igt_fixture {
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] tests/kms_pipe_crc_basic: Add suspend tests
Currently broken ...
Signed-off-by: Daniel Vetter
---
tests/kms_pipe_crc_basic.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c
index 282c7f68150a..eedb3f399e45 100644
--- a/tests/kms_pipe_crc_basic.c
+++ b/tests/kms_pipe_crc_basic.c
@@ -30,6 +30,7 @@
#include "drmtest.h"
#include "igt_debugfs.h"
#include "igt_kms.h"
+#include "igt_aux.h"
typedef struct {
int drm_fd;
@@ -160,6 +161,12 @@ igt_main
igt_subtest_f("read-crc-pipe-%c-frame-sequence", 'A'+i)
test_read_crc(&data, i, TEST_SEQUENCE);
+
+ igt_subtest_f("suspend-read-crc-pipe-%c", 'A'+i) {
+ igt_system_suspend_autoresume();
+
+ test_read_crc(&data, i, 0);
+ }
}
igt_fixture {
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/vlv: assert and de-assert sideband reset at boot and resume v3
On Thu, 22 May 2014 09:51:22 +0300 Imre Deak wrote: > On Wed, 2014-05-21 at 21:43 +0300, Ville Syrjälä wrote: > > On Wed, May 21, 2014 at 11:11:15AM -0700, Jesse Barnes wrote: > > > And to answer more specifically... > > > > > > On Wed, 21 May 2014 20:54:03 +0300 > > > Ville Syrjälä wrote: > > > > > > > > + __vlv_set_power_well(dev_priv, > > > > > PUNIT_POWER_WELL_DPIO_CMN_BC, > > > > > + false); > > > > > + __vlv_set_power_well(dev_priv, > > > > > PUNIT_POWER_WELL_DPIO_CMN_BC, > > > > > + true); > > > > > > > > Hmm. I wonder how the power well hack in intel_uncore_sanitize() ties in > > > > with this. We should definitely rip that out regardless. > > > > > > Yeah we can rip that out. That's just an ungate, and it assumes the > > > BIOS has already done the reset toggle for us. > > > > Well I'm assumign the system may boot/resume with the wells powered > > down. And we definitely don't have the cri/ref clocks set up at this > > point. So if they're needed to complete the resets the PHY may get stuck > > or something. Also it just ungates everything at once, if the wells need > > some ordering in bringup we have just messed things up here. > > I agree, there doesn't seem to be anything that needs those power wells > until the power domain init code runs. I can send a patch for this after > some testing. > > > > > Another thing I'm wodering is did the BIOS/hw really power on the > > > > common lane, or did we do that outselves? If the latter, then I wonder > > > > if we simply do that too early. Or more precisely do we need to make > > > > sure the cri clock and/or refclock are enabled before we power on the > > > > common lane? > > > > > > Depends on the platform. It looks like the right thing happens at boot > > > time on most machines (i.e. the BIOS does a full toggle which causes a > > > reset), but on suspend/resume it's up to us. And of course on machines > > > without video init at boot time, we need to do it ourselves as well. > > > > > > I don't think the cri or refclk is required at this point, at least not > > > if the docs we have are correct (the PHY reset is supposed to be the > > > very first thing). > > > > The timing diagrams do show some kind of relationship between the > > cri/ref clocks and the reset signals getting deasserted. > > Under "4.3 Clock Signal List" there is a hint about this saying that the > cri and pll1 ref clocks are needed for the init time calibration of the > whole PHY. The calibration is started by CMN reset, which should occur > after all the needed lanes are powered on. But this matches what we do > already now, except that toggling of the CMN reset signal is not > guaranteed if it was already deasserted by the BIOS. This would be fixed > by Jesse's v1 patch (but not v2). I guess the earlier sequence docs aren't clear on this, but it makes sense. > What does full reset mean? In my opinion toggling the CMN reset line is > enough, but I guess you suggest that we also need to power off/on the > CMN lane first. It would be good if Jesse could try if toggling CMN > reset alone is enough to get rid of the problem he saw. Well, that's the problem. I don't have access to the failing machines anymore, and we only ever had one that was reliably failing, so this is a really tough one to verify. The only one that was actually tested was the one I sent out at the very beginning. > > Also I think currently we power gate the TX blocks > > whenever the port gets disabled. If we want to keep doing that, we need > > to adjust valleyview_modeset_global_resources() to fully reset the phy > > whenever previously power down wells need to be brought up. The > > alternative would be to model the entire PHY as a single power well, > > which would definitely be the simpler option. > > Yes this is correct and it needs fixing. I took it for granted that we > can turn on/off parts of the PHY independently from the rest of it, but > now it looks like it's not possible on VLV. (As I understand it's > possible on CHV.) I planned to come up with some fix after figuring out > how things would work with fastboot, where based on this constraint we > also have to avoid disabling/enabling any PHY lanes during booting. > Currently we enable all the lanes at that time. I guess we could just > leave the PHY configuration as-is until we read out the HW configuration > and then leave the PHY config unchanged if there are active DP/HDMI/VGA > outputs and disable the whole PHY otherwise. Yeah if the display is already active we should assume we don't have to perform a full reset. -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Hold CRTC lock whilst freezing the planes
On Thu, 22 May 2014 09:44:40 +0100
Chris Wilson wrote:
> Daniel keeps on ramping up the warning level of the DRM and our display
> core to make it complain whenever the locking rules are not followed.
> This caught
>
> commit 24576d23976746cb52e7700c4cadbf4bc1bc3472
> Author: Jesse Barnes
> Date: Tue Mar 26 09:25:45 2013 -0700
>
> drm/i915: enable VT switchless resume v3
>
> introducing an unlocked access to the CRTC whilst disabling it for
> suspend.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78114
> Signed-off-by: Chris Wilson
> Cc: Jesse Barnes
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 591762c26af4..8450569ff42c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -532,8 +532,11 @@ static int i915_drm_freeze(struct drm_device *dev)
>* for _thaw.
>*/
> mutex_lock(&dev->mode_config.mutex);
> - for_each_crtc(dev, crtc)
> + for_each_crtc(dev, crtc) {
> + mutex_lock(&crtc->mutex);
> dev_priv->display.crtc_disable(crtc);
> + mutex_unlock(&crtc->mutex);
> + }
> mutex_unlock(&dev->mode_config.mutex);
>
> intel_modeset_suspend_hw(dev);
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC][PATCH] drm/i915: Don't promote UC to WT automagically
From: Ville Syrjälä
If the object is already UC leave it as UC instead of automagically
promoting it to WT in i915_gem_object_pin_to_display_plane() when
the hardware is WT capable.
Supposedly the user wanted UC for a reason, so let's respect that.
Signed-off-by: Ville Syrjälä
---
Just something that caught my eye while browsing the code. Can't really tell
how useful this would be.
drivers/gpu/drm/i915/i915_gem.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 87d0aac..3251b53 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3823,6 +3823,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
struct intel_ring_buffer *pipelined)
{
u32 old_read_domains, old_write_domain;
+ unsigned int cache_level;
bool was_pin_display;
int ret;
@@ -3847,8 +3848,12 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
* of uncaching, which would allow us to flush all the LLC-cached data
* with that bit in the PTE to main memory with just one PIPE_CONTROL.
*/
- ret = i915_gem_object_set_cache_level(obj,
- HAS_WT(obj->base.dev) ?
I915_CACHE_WT : I915_CACHE_NONE);
+ if (HAS_WT(obj->base.dev) && obj->cache_level != I915_CACHE_NONE)
+ cache_level = I915_CACHE_WT;
+ else
+ cache_level = I915_CACHE_NONE;
+
+ ret = i915_gem_object_set_cache_level(obj, cache_level);
if (ret)
goto err_unpin_display;
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Kill intel_crtc->vbl_wait
On Thu, May 22, 2014 at 06:39:33PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Share the waitqueue that drm_irq uses when performing the vblank evade
> trick for atomic pipe updates.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 25 ++---
> drivers/gpu/drm/i915/intel_display.c | 2 --
> drivers/gpu/drm/i915/intel_drv.h | 2 --
> drivers/gpu/drm/i915/intel_sprite.c | 5 +++--
> 4 files changed, 9 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 304f86a..5905a9d 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1724,19 +1724,6 @@ static void gen6_rps_irq_handler(struct
> drm_i915_private *dev_priv, u32 pm_iir)
> }
> }
>
> -static bool intel_pipe_handle_vblank(struct drm_device *dev, enum pipe pipe)
> -{
> - struct intel_crtc *crtc;
> -
> - if (!drm_handle_vblank(dev, pipe))
> - return false;
> -
> - crtc = to_intel_crtc(intel_get_crtc_for_pipe(dev, pipe));
> - wake_up(&crtc->vbl_wait);
> -
> - return true;
> -}
Can we keep this bare wrapper? It is quite useful for hooking in vblank
checks - i.e. saves me having to reinrtoduce it.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: Add fifo underrun reporting state to debugfs
On platforms with shared interrupt enable bits (which are shared even with the pipe CRC logic) there's some tricky corner cases. Add information to make debugging those easier. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_debugfs.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 16bbdc7243df..4a79d3fe35be 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2356,6 +2356,10 @@ static int i915_display_info(struct seq_file *m, void *unused) x, y, crtc->cursor_addr, yesno(active)); } + + seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n", + yesno(!crtc->cpu_fifo_underrun_disabled), + yesno(!crtc->pch_fifo_underrun_disabled)); } seq_printf(m, "\n"); -- 1.8.4.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: Fix up fifo underrun tracking, take N
So apparently this is tricky.
We need to consider:
- We start out with all the hw enabling bits disabled, both the
individual fifo underrun interrupts and the shared display error
interrupts masked. Otherwise if the bios config is broken we'll blow
up with a NULL deref in our interrupt handler since the crtc
structures aren't set up yet at driver load time.
- On gmch we need to mask fifo underruns on the sw side, so always
need to set that in sanitize_crtc for those platforms.
- On other platforms we try to set the sw tracking so that it reflects
the real state. But since a few platforms have shared bits we must
_not_ disable fifo underrun reporting. Otherwise we'll never enable
the shared error interrupt.
This is the state before out patch, but unfortunately this is not good
enough. But after a suspend resume operation this is broken:
1. We don't enable the hw interrupts since the same code runs on
resume as on driver load.
2. The fifo underrun state adjustments we do in sanitize_crtc doesn't
fire on resume since (except for hilarious firmware) all pipes are off
at that point. But they also don't hurt since the subsequent crtc
enabling due to force_restore will enable fifo underruns.
Which means when we enable fifo underrun reporting we notice that the
per-crtc state is already correct and short-circuit everthing out. And
the interrupt doesn't get enabled.
A similar problem would happen if the bios doesn't light up anything
when the driver loads. Which is exactly what happens when we reload
the driver since our unload functions disables all outputs.
Now we can't just rip out the short-circuit logic and unconditionally
update the fifo underrun reporting interrupt masking: We have some
checks for shared error interrupts to catch issues that happened when
the shared error interrupt was disabled.
The right fix is to push down this logic so that we can always update
the hardware state, but only check for missed fifo underruns on a real
enabled->disabled transition and ignore them when we're already
disabled.
On platforms with shared error interrupt the pipe CRC interrupts are
grouped together with the fifo underrun reporting this fixes pipe CRC
support after suspend and driver reloads.
Testcase: igt/kms_pipe_crc_basic/suspend-*
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 44 ++---
1 file changed, 19 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 304f86a3162c..4d44f09eb833 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -335,7 +335,8 @@ void i9xx_check_fifo_underruns(struct drm_device *dev)
}
static void i9xx_set_fifo_underrun_reporting(struct drm_device *dev,
-enum pipe pipe, bool enable)
+enum pipe pipe,
+bool enable, bool old)
{
struct drm_i915_private *dev_priv = dev->dev_private;
u32 reg = PIPESTAT(pipe);
@@ -347,7 +348,7 @@ static void i9xx_set_fifo_underrun_reporting(struct
drm_device *dev,
I915_WRITE(reg, pipestat | PIPE_FIFO_UNDERRUN_STATUS);
POSTING_READ(reg);
} else {
- if (pipestat & PIPE_FIFO_UNDERRUN_STATUS)
+ if (old && pipestat & PIPE_FIFO_UNDERRUN_STATUS)
DRM_ERROR("pipe %c underrun\n", pipe_name(pipe));
}
}
@@ -366,7 +367,8 @@ static void ironlake_set_fifo_underrun_reporting(struct
drm_device *dev,
}
static void ivybridge_set_fifo_underrun_reporting(struct drm_device *dev,
- enum pipe pipe, bool enable)
+ enum pipe pipe,
+ bool enable, bool old)
{
struct drm_i915_private *dev_priv = dev->dev_private;
if (enable) {
@@ -379,7 +381,8 @@ static void ivybridge_set_fifo_underrun_reporting(struct
drm_device *dev,
} else {
ironlake_disable_display_irq(dev_priv, DE_ERR_INT_IVB);
- if (I915_READ(GEN7_ERR_INT) & ERR_INT_FIFO_UNDERRUN(pipe)) {
+ if (old &&
+ I915_READ(GEN7_ERR_INT) & ERR_INT_FIFO_UNDERRUN(pipe)) {
DRM_ERROR("uncleared fifo underrun on pipe %c\n",
pipe_name(pipe));
}
@@ -444,7 +447,7 @@ static void ibx_set_fifo_underrun_reporting(struct
drm_device *dev,
static void cpt_set_fifo_underrun_reporting(struct drm_device *dev,
enum transcoder pch_transcoder,
- bool enable)
+ bool enable, bool old)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -459,7 +462,8 @@ static void cpt_set_fifo_underrun_repo
[Intel-gfx] [PATCH 3/5] drm/i915: Disable gpu reset on i965g/gm
Ville figured out that it needs a full display reset since apparently
a lot more goes down than just the GT. Until that's address it's
better to just diable gpu reset.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_uncore.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 67385a9aa98c..8eb294074e89 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -967,6 +967,9 @@ static int i965_do_reset(struct drm_device *dev)
{
int ret;
+ /* FIXME: i965g/gm need a display save/restore for gpu reset. */
+ return -ENODEV;
+
/*
* Set the domains we want to reset (GRDOM/bits 2 and 3) as
* well as the reset bit (GR/bit 0). Setting the GR bit
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Improve irq handling after gpu resets
Currently we do a full re-init of all interrupts after a gpu hang.
Which is pretty bad since we don't restore the interrupts we've
enabled at runtime correctly. Even with that addressed it's rather
horribly race.
But on g4x and later we only reset the gt and not the entire gpu.
Which means we only need to reset the GT interrupt bits. Which has the
nice benefit that vblank waits, pipe CRC interrupts and everything
else display related just keeps on working.
The downside is that gt interrupt handling (i.e. ring->get/put_irq) is
still racy. But as long as the gpu hang reliably wakes all waters and
we have a short time where the refcount drops to 0 we'll recover. So
not that bad really.
Testcase: igt/kms_flip/vblank-vs-hang
Testcase: igt/kms_pipe_crc_basic/hang-*
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 17 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_irq.c | 35 +++
3 files changed, 37 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c83c83b74bf4..69a75bb7ad83 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -811,17 +811,18 @@ int i915_reset(struct drm_device *dev)
}
/*
-* FIXME: This is horribly race against concurrent pageflip and
-* vblank wait ioctls since they can observe dev->irqs_disabled
-* being false when they shouldn't be able to.
+* FIXME: This races pretty badly against concurrent holders of
+* ring interrupts. This is possible since we've started to drop
+* dev->struct_mutex in select places when waiting for the gpu.
*/
- drm_irq_uninstall(dev);
- drm_irq_install(dev, dev->pdev->irq);
+ intel_gt_irq_reinit(dev);
- /* rps/rc6 re-init is necessary to restore state lost after the
-* reset and the re-install of drm irq. Skip for ironlake per
+ /*
+* rps/rc6 re-init is necessary to restore state lost after the
+* reset and the re-install of gt irqs. Skip for ironlake per
* previous concerns that it doesn't respond well to some forms
-* of re-init after reset. */
+* of re-init after reset.
+*/
if (INTEL_INFO(dev)->gen > 5)
intel_reset_gt_powersave(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 459b02ad1ef3..61792c4050e7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2078,6 +2078,7 @@ void gen6_set_pm_mask(struct drm_i915_private *dev_priv,
u32 pm_iir,
int new_delay);
extern void intel_irq_init(struct drm_device *dev);
extern void intel_hpd_init(struct drm_device *dev);
+extern void intel_gt_irq_reinit(struct drm_device *dev);
extern void intel_uncore_sanitize(struct drm_device *dev);
extern void intel_uncore_early_sanitize(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3cd659b47dd2..6dba645a81fa 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3140,6 +3140,14 @@ static void valleyview_irq_preinstall(struct drm_device
*dev)
POSTING_READ(VLV_IER);
}
+static void gen8_gt_irq_reset(struct drm_i915_private *dev_priv)
+{
+ GEN8_IRQ_RESET_NDX(GT, 0);
+ GEN8_IRQ_RESET_NDX(GT, 1);
+ GEN8_IRQ_RESET_NDX(GT, 2);
+ GEN8_IRQ_RESET_NDX(GT, 3);
+}
+
static void gen8_irq_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3148,10 +3156,7 @@ static void gen8_irq_reset(struct drm_device *dev)
I915_WRITE(GEN8_MASTER_IRQ, 0);
POSTING_READ(GEN8_MASTER_IRQ);
- GEN8_IRQ_RESET_NDX(GT, 0);
- GEN8_IRQ_RESET_NDX(GT, 1);
- GEN8_IRQ_RESET_NDX(GT, 2);
- GEN8_IRQ_RESET_NDX(GT, 3);
+ gen8_gt_irq_reset(dev_priv);
for_each_pipe(pipe)
GEN8_IRQ_RESET_NDX(DE_PIPE, pipe);
@@ -3171,10 +3176,7 @@ static void cherryview_irq_preinstall(struct drm_device
*dev)
I915_WRITE(GEN8_MASTER_IRQ, 0);
POSTING_READ(GEN8_MASTER_IRQ);
- GEN8_IRQ_RESET_NDX(GT, 0);
- GEN8_IRQ_RESET_NDX(GT, 1);
- GEN8_IRQ_RESET_NDX(GT, 2);
- GEN8_IRQ_RESET_NDX(GT, 3);
+ gen8_gt_irq_reset(dev_priv);
GEN5_IRQ_RESET(GEN8_PCU_);
@@ -4436,6 +4438,23 @@ void intel_hpd_init(struct drm_device *dev)
spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
}
+void intel_gt_irq_reinit(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ spin_lock_irq(&dev_priv->irq_lock);
+ if (INTEL_INFO(dev)->gen >
[Intel-gfx] [PATCH 4/5] drm/i915: Inline ilk/gen8_irq_reset
No point in having this indirection.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4d44f09eb833..3cd659b47dd2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3111,11 +3111,6 @@ static void ironlake_irq_reset(struct drm_device *dev)
ibx_irq_reset(dev);
}
-static void ironlake_irq_preinstall(struct drm_device *dev)
-{
- ironlake_irq_reset(dev);
-}
-
static void valleyview_irq_preinstall(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3168,11 +3163,6 @@ static void gen8_irq_reset(struct drm_device *dev)
ibx_irq_reset(dev);
}
-static void gen8_irq_preinstall(struct drm_device *dev)
-{
- gen8_irq_reset(dev);
-}
-
static void cherryview_irq_preinstall(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -4381,7 +4371,7 @@ void intel_irq_init(struct drm_device *dev)
dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
} else if (IS_GEN8(dev)) {
dev->driver->irq_handler = gen8_irq_handler;
- dev->driver->irq_preinstall = gen8_irq_preinstall;
+ dev->driver->irq_preinstall = gen8_irq_reset;
dev->driver->irq_postinstall = gen8_irq_postinstall;
dev->driver->irq_uninstall = gen8_irq_uninstall;
dev->driver->enable_vblank = gen8_enable_vblank;
@@ -4389,7 +4379,7 @@ void intel_irq_init(struct drm_device *dev)
dev_priv->display.hpd_irq_setup = ibx_hpd_irq_setup;
} else if (HAS_PCH_SPLIT(dev)) {
dev->driver->irq_handler = ironlake_irq_handler;
- dev->driver->irq_preinstall = ironlake_irq_preinstall;
+ dev->driver->irq_preinstall = ironlake_irq_reset;
dev->driver->irq_postinstall = ironlake_irq_postinstall;
dev->driver->irq_uninstall = ironlake_irq_uninstall;
dev->driver->enable_vblank = ironlake_enable_vblank;
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915: Kill intel_crtc->vbl_wait
From: Ville Syrjälä
Share the waitqueue that drm_irq uses when performing the vblank evade
trick for atomic pipe updates.
v2: Keep intel_pipe_handle_vblank() (Chris)
Suggested-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 5 -
drivers/gpu/drm/i915/intel_display.c | 2 --
drivers/gpu/drm/i915/intel_drv.h | 2 --
drivers/gpu/drm/i915/intel_sprite.c | 5 +++--
4 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 304f86a..bc4cdbd 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1726,14 +1726,9 @@ static void gen6_rps_irq_handler(struct drm_i915_private
*dev_priv, u32 pm_iir)
static bool intel_pipe_handle_vblank(struct drm_device *dev, enum pipe pipe)
{
- struct intel_crtc *crtc;
-
if (!drm_handle_vblank(dev, pipe))
return false;
- crtc = to_intel_crtc(intel_get_crtc_for_pipe(dev, pipe));
- wake_up(&crtc->vbl_wait);
-
return true;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 019e9e1..aab638c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10966,8 +10966,6 @@ static void intel_crtc_init(struct drm_device *dev, int
pipe)
intel_crtc->plane = !pipe;
}
- init_waitqueue_head(&intel_crtc->vbl_wait);
-
BUG_ON(pipe >= ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) ||
dev_priv->plane_to_crtc_mapping[intel_crtc->plane] != NULL);
dev_priv->plane_to_crtc_mapping[intel_crtc->plane] = &intel_crtc->base;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d7c52b2..0071138 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -408,8 +408,6 @@ struct intel_crtc {
struct intel_pipe_wm active;
} wm;
- wait_queue_head_t vbl_wait;
-
int scanline_offset;
};
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index d6acd6b..7cd6a4f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -53,6 +53,7 @@ static bool intel_pipe_update_start(struct intel_crtc *crtc,
uint32_t *start_vbl
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);
DEFINE_WAIT(wait);
WARN_ON(!mutex_is_locked(&crtc->base.mutex));
@@ -81,7 +82,7 @@ static bool intel_pipe_update_start(struct intel_crtc *crtc,
uint32_t *start_vbl
* other CPUs can see the task state update by the time we
* read the scanline.
*/
- prepare_to_wait(&crtc->vbl_wait, &wait, TASK_UNINTERRUPTIBLE);
+ prepare_to_wait(wq, &wait, TASK_UNINTERRUPTIBLE);
scanline = intel_get_crtc_scanline(crtc);
if (scanline < min || scanline > max)
@@ -100,7 +101,7 @@ static bool intel_pipe_update_start(struct intel_crtc
*crtc, uint32_t *start_vbl
local_irq_disable();
}
- finish_wait(&crtc->vbl_wait, &wait);
+ finish_wait(wq, &wait);
drm_vblank_put(dev, pipe);
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: manual merge of the dma-buf tree with the drm-intel tree
On 20 May 2014 12:25, Stephen Rothwell wrote:
> Hi Sumit,
>
> Today's linux-next merge of the dma-buf tree got a conflict in
> drivers/gpu/drm/i915/i915_gem_dmabuf.c between commit 5cc9ed4b9a7a
> ("drm/i915: Introduce mapping of user pages into video memory (userptr)
> ioctl") from the drm-intel tree and commit 8dfb1f0f8103 ("dma-buf: use
> reservation objects") from the dma-buf tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
Hi Stephen!
This seems good, thanks!
Best regards,
~Sumit.
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index 580aa42443ed,817ec444c976..
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@@ -229,15 -233,8 +229,16 @@@ static const struct dma_buf_ops i915_dm
> struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
> struct drm_gem_object *gem_obj, int
> flags)
> {
> + struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
> +
> + if (obj->ops->dmabuf_export) {
> + int ret = obj->ops->dmabuf_export(obj);
> + if (ret)
> + return ERR_PTR(ret);
> + }
> +
> - return dma_buf_export(gem_obj, &i915_dmabuf_ops, gem_obj->size,
> flags);
> + return dma_buf_export(gem_obj, &i915_dmabuf_ops, gem_obj->size, flags,
> + NULL);
> }
>
> static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Kill intel_crtc->vbl_wait
On Thu, May 22, 2014 at 04:49:03PM +0100, Chris Wilson wrote:
> On Thu, May 22, 2014 at 06:39:33PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Share the waitqueue that drm_irq uses when performing the vblank evade
> > trick for atomic pipe updates.
> >
> > Suggested-by: Daniel Vetter
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 25 ++---
> > drivers/gpu/drm/i915/intel_display.c | 2 --
> > drivers/gpu/drm/i915/intel_drv.h | 2 --
> > drivers/gpu/drm/i915/intel_sprite.c | 5 +++--
> > 4 files changed, 9 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 304f86a..5905a9d 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -1724,19 +1724,6 @@ static void gen6_rps_irq_handler(struct
> > drm_i915_private *dev_priv, u32 pm_iir)
> > }
> > }
> >
> > -static bool intel_pipe_handle_vblank(struct drm_device *dev, enum pipe
> > pipe)
> > -{
> > - struct intel_crtc *crtc;
> > -
> > - if (!drm_handle_vblank(dev, pipe))
> > - return false;
> > -
> > - crtc = to_intel_crtc(intel_get_crtc_for_pipe(dev, pipe));
> > - wake_up(&crtc->vbl_wait);
> > -
> > - return true;
> > -}
>
> Can we keep this bare wrapper? It is quite useful for hooking in vblank
> checks - i.e. saves me having to reinrtoduce it.
Just smash them into drm_handle_vblank?
-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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm: Add drm_crtc_vblank_waitqueue()
On Thu, May 22, 2014 at 06:39:32PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add a small static inline helper to grab the vblank wait queue based on
> the drm_crtc.
Maybe add that this is useful for drivers to do internal vblank waits
using wait event.
> Suggested-by: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> ---
> include/drm/drmP.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 76ccaab..c294560 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1378,6 +1378,10 @@ extern int
> drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
> extern void drm_calc_timestamping_constants(struct drm_crtc *crtc,
> const struct drm_display_mode
> *mode);
>
> +static inline wait_queue_head_t *drm_crtc_vblank_waitqueue(struct drm_crtc
> *crtc)
Kerneldoc + pulling into the drm_irq docs missing. I guess we need to do
an include directive which exactly names this function ... No other way
with the drm header mess :(
-Daniel
> +{
> + return &crtc->dev->vblank[drm_crtc_index(crtc)].queue;
> +}
>
> /* Modesetting support */
> extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
> --
> 1.8.5.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm: Add drm_crtc_vblank_waitqueue()
From: Ville Syrjälä
Add a small static inline helper to grab the vblank wait queue based on
the drm_crtc.
This is useful for drivers to do internal vblank waits using
wait_event() & co.
v2: Pimp commit message (Daniel)
Add kernel doc (Daniel)
Suggested-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
Documentation/DocBook/drm.tmpl | 1 +
include/drm/drmP.h | 11 +++
2 files changed, 12 insertions(+)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 9574bf2..527a3f9 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2522,6 +2522,7 @@ void (*disable_vblank) (struct drm_device *dev, int
crtc);
Vertical Blanking and Interrupt Handling Functions
Reference
!Edrivers/gpu/drm/drm_irq.c
+!Iinclude/drm/drmP.h drm_crtc_vblank_waitqueue
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 76ccaab..48dc3e5 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1378,6 +1378,17 @@ extern int drm_calc_vbltimestamp_from_scanoutpos(struct
drm_device *dev,
extern void drm_calc_timestamping_constants(struct drm_crtc *crtc,
const struct drm_display_mode
*mode);
+/**
+ * drm_crtc_vblank_waitqueue - get vblank waitqueue for the CRTC
+ * @crtc: which CRTC's vblank waitqueue to retrieve
+ *
+ * This function returns a pointer to the vblank waitqueue for the CRTC.
+ * Drivers can use this to implement vblank waits using wait_event() & co.
+ */
+static inline wait_queue_head_t *drm_crtc_vblank_waitqueue(struct drm_crtc
*crtc)
+{
+ return &crtc->dev->vblank[drm_crtc_index(crtc)].queue;
+}
/* Modesetting support */
extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] kms_cursor_crc: Move igt_pipe_crc_{new, free} to init
If a subtest fails, cleanup_crtc() never gets called. Currently that
also causes igt_pipe_crc_free() to never be called, leading all
subsequent subtests to also fail with -EBUSY at igt_pipe_crc_new().
Move the calls to igt_pipe_crc_{new,free} into igt_main so that
we don't need to worry about closing and reopening the CRC
filedescriptor for each subtest.
Signed-off-by: Matt Roper
---
tests/kms_cursor_crc.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c
index 06625ee..1b90baa 100644
--- a/tests/kms_cursor_crc.c
+++ b/tests/kms_cursor_crc.c
@@ -39,11 +39,14 @@
#define DRM_CAP_CURSOR_HEIGHT 0x9
#endif
+#define MAX_PIPES 3
+
typedef struct {
int drm_fd;
igt_display_t display;
struct igt_fb primary_fb;
struct igt_fb fb;
+ igt_pipe_crc_t *pipe_crcs[MAX_PIPES];
} data_t;
typedef struct {
@@ -251,12 +254,6 @@ static bool prepare_crtc(test_data_t *test_data,
igt_output_t *output,
igt_display_commit(display);
- /* create the pipe_crc object for this pipe */
- if (test_data->pipe_crc)
- igt_pipe_crc_free(test_data->pipe_crc);
-
- test_data->pipe_crc = igt_pipe_crc_new(test_data->pipe,
- INTEL_PIPE_CRC_SOURCE_AUTO);
if (!test_data->pipe_crc) {
igt_info("auto crc not supported on this connector with pipe
%i\n",
test_data->pipe);
@@ -289,7 +286,6 @@ static void cleanup_crtc(test_data_t *test_data,
igt_output_t *output)
igt_display_t *display = &data->display;
igt_plane_t *primary;
- igt_pipe_crc_free(test_data->pipe_crc);
test_data->pipe_crc = NULL;
igt_remove_fb(data->drm_fd, &data->primary_fb);
@@ -315,6 +311,7 @@ static void run_test(data_t *data, void
(*testfunc)(test_data_t *), int cursor_w
test_data.output = output;
for (p = 0; p < igt_display_get_n_pipes(display); p++) {
test_data.pipe = p;
+ test_data.pipe_crc = data->pipe_crcs[p];
if (!prepare_crtc(&test_data, output, cursor_w,
cursor_h))
continue;
@@ -385,6 +382,7 @@ igt_main
uint64_t cursor_width = 64, cursor_height = 64;
data_t data = {};
int ret;
+ int p;
igt_skip_on_simulation();
@@ -405,11 +403,20 @@ igt_main
igt_require_pipe_crc();
igt_display_init(&data.display, data.drm_fd);
+
+ for (p = 0; p < igt_display_get_n_pipes(&data.display); p++)
+ data.pipe_crcs[p] = igt_pipe_crc_new(p,
+
INTEL_PIPE_CRC_SOURCE_AUTO);
}
run_test_generic(&data, cursor_width);
igt_fixture {
+ for (p = 0; p < igt_display_get_n_pipes(&data.display); p++) {
+ if (data.pipe_crcs[p])
+ igt_pipe_crc_free(data.pipe_crcs[p]);
+ }
+
igt_display_fini(&data.display);
}
}
--
1.8.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Improve irq handling after gpu resets
On Thu, May 22, 2014 at 05:56:35PM +0200, Daniel Vetter wrote:
> Currently we do a full re-init of all interrupts after a gpu hang.
> Which is pretty bad since we don't restore the interrupts we've
> enabled at runtime correctly. Even with that addressed it's rather
> horribly race.
>
> But on g4x and later we only reset the gt and not the entire gpu.
> Which means we only need to reset the GT interrupt bits. Which has the
> nice benefit that vblank waits, pipe CRC interrupts and everything
> else display related just keeps on working.
>
> The downside is that gt interrupt handling (i.e. ring->get/put_irq) is
> still racy. But as long as the gpu hang reliably wakes all waters and
> we have a short time where the refcount drops to 0 we'll recover. So
> not that bad really.
A quick test on IVB tells me that GTIMR and GEN6_PMIMR survive the full
gt reset. But the ring IMRs do get clobbered. So could we just skip the
entire irq reset here?
>
> Testcase: igt/kms_flip/vblank-vs-hang
> Testcase: igt/kms_pipe_crc_basic/hang-*
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.c | 17 +
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_irq.c | 35 +++
> 3 files changed, 37 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index c83c83b74bf4..69a75bb7ad83 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -811,17 +811,18 @@ int i915_reset(struct drm_device *dev)
> }
>
> /*
> - * FIXME: This is horribly race against concurrent pageflip and
> - * vblank wait ioctls since they can observe dev->irqs_disabled
> - * being false when they shouldn't be able to.
> + * FIXME: This races pretty badly against concurrent holders of
> + * ring interrupts. This is possible since we've started to drop
> + * dev->struct_mutex in select places when waiting for the gpu.
>*/
> - drm_irq_uninstall(dev);
> - drm_irq_install(dev, dev->pdev->irq);
> + intel_gt_irq_reinit(dev);
>
> - /* rps/rc6 re-init is necessary to restore state lost after the
> - * reset and the re-install of drm irq. Skip for ironlake per
> + /*
> + * rps/rc6 re-init is necessary to restore state lost after the
> + * reset and the re-install of gt irqs. Skip for ironlake per
>* previous concerns that it doesn't respond well to some forms
> - * of re-init after reset. */
> + * of re-init after reset.
> + */
> if (INTEL_INFO(dev)->gen > 5)
> intel_reset_gt_powersave(dev);
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 459b02ad1ef3..61792c4050e7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2078,6 +2078,7 @@ void gen6_set_pm_mask(struct drm_i915_private
> *dev_priv, u32 pm_iir,
> int new_delay);
> extern void intel_irq_init(struct drm_device *dev);
> extern void intel_hpd_init(struct drm_device *dev);
> +extern void intel_gt_irq_reinit(struct drm_device *dev);
>
> extern void intel_uncore_sanitize(struct drm_device *dev);
> extern void intel_uncore_early_sanitize(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 3cd659b47dd2..6dba645a81fa 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3140,6 +3140,14 @@ static void valleyview_irq_preinstall(struct
> drm_device *dev)
> POSTING_READ(VLV_IER);
> }
>
> +static void gen8_gt_irq_reset(struct drm_i915_private *dev_priv)
> +{
> + GEN8_IRQ_RESET_NDX(GT, 0);
> + GEN8_IRQ_RESET_NDX(GT, 1);
> + GEN8_IRQ_RESET_NDX(GT, 2);
> + GEN8_IRQ_RESET_NDX(GT, 3);
> +}
> +
> static void gen8_irq_reset(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -3148,10 +3156,7 @@ static void gen8_irq_reset(struct drm_device *dev)
> I915_WRITE(GEN8_MASTER_IRQ, 0);
> POSTING_READ(GEN8_MASTER_IRQ);
>
> - GEN8_IRQ_RESET_NDX(GT, 0);
> - GEN8_IRQ_RESET_NDX(GT, 1);
> - GEN8_IRQ_RESET_NDX(GT, 2);
> - GEN8_IRQ_RESET_NDX(GT, 3);
> + gen8_gt_irq_reset(dev_priv);
>
> for_each_pipe(pipe)
> GEN8_IRQ_RESET_NDX(DE_PIPE, pipe);
> @@ -3171,10 +3176,7 @@ static void cherryview_irq_preinstall(struct
> drm_device *dev)
> I915_WRITE(GEN8_MASTER_IRQ, 0);
> POSTING_READ(GEN8_MASTER_IRQ);
>
> - GEN8_IRQ_RESET_NDX(GT, 0);
> - GEN8_IRQ_RESET_NDX(GT, 1);
> - GEN8_IRQ_RESET_NDX(GT, 2);
> - GEN8_IRQ_RESET_NDX(GT, 3);
> + gen8_gt_irq_reset(dev_priv);
>
>
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Fix up fifo underrun tracking, take N
On Thu, May 22, 2014 at 05:56:32PM +0200, Daniel Vetter wrote:
> So apparently this is tricky.
>
> We need to consider:
> - We start out with all the hw enabling bits disabled, both the
> individual fifo underrun interrupts and the shared display error
> interrupts masked. Otherwise if the bios config is broken we'll blow
> up with a NULL deref in our interrupt handler since the crtc
> structures aren't set up yet at driver load time.
> - On gmch we need to mask fifo underruns on the sw side, so always
> need to set that in sanitize_crtc for those platforms.
> - On other platforms we try to set the sw tracking so that it reflects
> the real state. But since a few platforms have shared bits we must
> _not_ disable fifo underrun reporting. Otherwise we'll never enable
> the shared error interrupt.
>
> This is the state before out patch, but unfortunately this is not good
> enough. But after a suspend resume operation this is broken:
> 1. We don't enable the hw interrupts since the same code runs on
> resume as on driver load.
> 2. The fifo underrun state adjustments we do in sanitize_crtc doesn't
> fire on resume since (except for hilarious firmware) all pipes are off
> at that point. But they also don't hurt since the subsequent crtc
> enabling due to force_restore will enable fifo underruns.
>
> Which means when we enable fifo underrun reporting we notice that the
> per-crtc state is already correct and short-circuit everthing out. And
> the interrupt doesn't get enabled.
>
> A similar problem would happen if the bios doesn't light up anything
> when the driver loads. Which is exactly what happens when we reload
> the driver since our unload functions disables all outputs.
>
> Now we can't just rip out the short-circuit logic and unconditionally
> update the fifo underrun reporting interrupt masking: We have some
> checks for shared error interrupts to catch issues that happened when
> the shared error interrupt was disabled.
Hmm. Do we have cases where we do enabled->enabled "transition"?
Because in that case we would now clear the register without
reporting if there was an underrun in the register.
>
> The right fix is to push down this logic so that we can always update
> the hardware state, but only check for missed fifo underruns on a real
> enabled->disabled transition and ignore them when we're already
> disabled.
>
> On platforms with shared error interrupt the pipe CRC interrupts are
> grouped together with the fifo underrun reporting this fixes pipe CRC
> support after suspend and driver reloads.
>
> Testcase: igt/kms_pipe_crc_basic/suspend-*
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_irq.c | 44
> ++---
> 1 file changed, 19 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 304f86a3162c..4d44f09eb833 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -335,7 +335,8 @@ void i9xx_check_fifo_underruns(struct drm_device *dev)
> }
>
> static void i9xx_set_fifo_underrun_reporting(struct drm_device *dev,
> - enum pipe pipe, bool enable)
> + enum pipe pipe,
> + bool enable, bool old)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> u32 reg = PIPESTAT(pipe);
> @@ -347,7 +348,7 @@ static void i9xx_set_fifo_underrun_reporting(struct
> drm_device *dev,
> I915_WRITE(reg, pipestat | PIPE_FIFO_UNDERRUN_STATUS);
> POSTING_READ(reg);
> } else {
> - if (pipestat & PIPE_FIFO_UNDERRUN_STATUS)
> + if (old && pipestat & PIPE_FIFO_UNDERRUN_STATUS)
> DRM_ERROR("pipe %c underrun\n", pipe_name(pipe));
> }
> }
> @@ -366,7 +367,8 @@ static void ironlake_set_fifo_underrun_reporting(struct
> drm_device *dev,
> }
>
> static void ivybridge_set_fifo_underrun_reporting(struct drm_device *dev,
> - enum pipe pipe, bool enable)
> + enum pipe pipe,
> + bool enable, bool old)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> if (enable) {
> @@ -379,7 +381,8 @@ static void ivybridge_set_fifo_underrun_reporting(struct
> drm_device *dev,
> } else {
> ironlake_disable_display_irq(dev_priv, DE_ERR_INT_IVB);
>
> - if (I915_READ(GEN7_ERR_INT) & ERR_INT_FIFO_UNDERRUN(pipe)) {
> + if (old &&
> + I915_READ(GEN7_ERR_INT) & ERR_INT_FIFO_UNDERRUN(pipe)) {
> DRM_ERROR("uncleared fifo underrun on pipe %c\n",
> pipe_name(pipe));
> }
> @@ -444,7 +447,7 @@ static void ibx_set_fifo_underrun_reporting(struct
> drm_device *dev,
Re: [Intel-gfx] [PATCH i-g-t] kms_cursor_crc: Move igt_pipe_crc_{new, free} to init
On Thu, May 22, 2014 at 09:47:39AM -0700, Matt Roper wrote:
> If a subtest fails, cleanup_crtc() never gets called. Currently that
> also causes igt_pipe_crc_free() to never be called, leading all
> subsequent subtests to also fail with -EBUSY at igt_pipe_crc_new().
> Move the calls to igt_pipe_crc_{new,free} into igt_main so that
> we don't need to worry about closing and reopening the CRC
> filedescriptor for each subtest.
IIRC we can't call them at init because when you call igt_pipe_crc_new()
the pipe->port mapping has to be properly set up so that the auto crc
source will know what to do.
The subtest failure case is the reason why at the start of every subtest
we call igt_pipe_crc_free() before calling igt_pipe_crc_new(). Are you
saying that's not working as intended?
>
> Signed-off-by: Matt Roper
> ---
> tests/kms_cursor_crc.c | 21 ++---
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c
> index 06625ee..1b90baa 100644
> --- a/tests/kms_cursor_crc.c
> +++ b/tests/kms_cursor_crc.c
> @@ -39,11 +39,14 @@
> #define DRM_CAP_CURSOR_HEIGHT 0x9
> #endif
>
> +#define MAX_PIPES 3
> +
> typedef struct {
> int drm_fd;
> igt_display_t display;
> struct igt_fb primary_fb;
> struct igt_fb fb;
> + igt_pipe_crc_t *pipe_crcs[MAX_PIPES];
> } data_t;
>
> typedef struct {
> @@ -251,12 +254,6 @@ static bool prepare_crtc(test_data_t *test_data,
> igt_output_t *output,
>
> igt_display_commit(display);
>
> - /* create the pipe_crc object for this pipe */
> - if (test_data->pipe_crc)
> - igt_pipe_crc_free(test_data->pipe_crc);
> -
> - test_data->pipe_crc = igt_pipe_crc_new(test_data->pipe,
> -INTEL_PIPE_CRC_SOURCE_AUTO);
> if (!test_data->pipe_crc) {
> igt_info("auto crc not supported on this connector with pipe
> %i\n",
>test_data->pipe);
> @@ -289,7 +286,6 @@ static void cleanup_crtc(test_data_t *test_data,
> igt_output_t *output)
> igt_display_t *display = &data->display;
> igt_plane_t *primary;
>
> - igt_pipe_crc_free(test_data->pipe_crc);
> test_data->pipe_crc = NULL;
>
> igt_remove_fb(data->drm_fd, &data->primary_fb);
> @@ -315,6 +311,7 @@ static void run_test(data_t *data, void
> (*testfunc)(test_data_t *), int cursor_w
> test_data.output = output;
> for (p = 0; p < igt_display_get_n_pipes(display); p++) {
> test_data.pipe = p;
> + test_data.pipe_crc = data->pipe_crcs[p];
>
> if (!prepare_crtc(&test_data, output, cursor_w,
> cursor_h))
> continue;
> @@ -385,6 +382,7 @@ igt_main
> uint64_t cursor_width = 64, cursor_height = 64;
> data_t data = {};
> int ret;
> + int p;
>
> igt_skip_on_simulation();
>
> @@ -405,11 +403,20 @@ igt_main
> igt_require_pipe_crc();
>
> igt_display_init(&data.display, data.drm_fd);
> +
> + for (p = 0; p < igt_display_get_n_pipes(&data.display); p++)
> + data.pipe_crcs[p] = igt_pipe_crc_new(p,
> +
> INTEL_PIPE_CRC_SOURCE_AUTO);
> }
>
> run_test_generic(&data, cursor_width);
>
> igt_fixture {
> + for (p = 0; p < igt_display_get_n_pipes(&data.display); p++) {
> + if (data.pipe_crcs[p])
> + igt_pipe_crc_free(data.pipe_crcs[p]);
> + }
> +
> igt_display_fini(&data.display);
> }
> }
> --
> 1.8.5.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Add fifo underrun reporting state to debugfs
On Thu, May 22, 2014 at 05:56:31PM +0200, Daniel Vetter wrote: > On platforms with shared interrupt enable bits (which are shared even > with the pipe CRC logic) there's some tricky corner cases. Add > information to make debugging those easier. > > Signed-off-by: Daniel Vetter For patches 1,3,4: Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/i915_debugfs.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index 16bbdc7243df..4a79d3fe35be 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -2356,6 +2356,10 @@ static int i915_display_info(struct seq_file *m, void > *unused) > x, y, crtc->cursor_addr, > yesno(active)); > } > + > + seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n", > +yesno(!crtc->cpu_fifo_underrun_disabled), > +yesno(!crtc->pch_fifo_underrun_disabled)); > } > > seq_printf(m, "\n"); > -- > 1.8.4.rc3 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] kms_cursor_crc: Move igt_pipe_crc_{new, free} to init
On Thu, May 22, 2014 at 08:01:09PM +0300, Ville Syrjälä wrote:
> On Thu, May 22, 2014 at 09:47:39AM -0700, Matt Roper wrote:
> > If a subtest fails, cleanup_crtc() never gets called. Currently that
> > also causes igt_pipe_crc_free() to never be called, leading all
> > subsequent subtests to also fail with -EBUSY at igt_pipe_crc_new().
> > Move the calls to igt_pipe_crc_{new,free} into igt_main so that
> > we don't need to worry about closing and reopening the CRC
> > filedescriptor for each subtest.
>
> IIRC we can't call them at init because when you call igt_pipe_crc_new()
> the pipe->port mapping has to be properly set up so that the auto crc
> source will know what to do.
>
> The subtest failure case is the reason why at the start of every subtest
> we call igt_pipe_crc_free() before calling igt_pipe_crc_new(). Are you
> saying that's not working as intended?
Right, you're working on a fresh test_data structure for each call of
run_test(), so you've already lost the test_data->pipe_crc pointer that
you're trying to check for NULL there.
I guess the right fix is to move the pipe_crc pointer up into data_t
rather than test_data_t?
Matt
>
> >
> > Signed-off-by: Matt Roper
> > ---
> > tests/kms_cursor_crc.c | 21 ++---
> > 1 file changed, 14 insertions(+), 7 deletions(-)
> >
> > diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c
> > index 06625ee..1b90baa 100644
> > --- a/tests/kms_cursor_crc.c
> > +++ b/tests/kms_cursor_crc.c
> > @@ -39,11 +39,14 @@
> > #define DRM_CAP_CURSOR_HEIGHT 0x9
> > #endif
> >
> > +#define MAX_PIPES 3
> > +
> > typedef struct {
> > int drm_fd;
> > igt_display_t display;
> > struct igt_fb primary_fb;
> > struct igt_fb fb;
> > + igt_pipe_crc_t *pipe_crcs[MAX_PIPES];
> > } data_t;
> >
> > typedef struct {
> > @@ -251,12 +254,6 @@ static bool prepare_crtc(test_data_t *test_data,
> > igt_output_t *output,
> >
> > igt_display_commit(display);
> >
> > - /* create the pipe_crc object for this pipe */
> > - if (test_data->pipe_crc)
> > - igt_pipe_crc_free(test_data->pipe_crc);
> > -
> > - test_data->pipe_crc = igt_pipe_crc_new(test_data->pipe,
> > - INTEL_PIPE_CRC_SOURCE_AUTO);
> > if (!test_data->pipe_crc) {
> > igt_info("auto crc not supported on this connector with pipe
> > %i\n",
> > test_data->pipe);
> > @@ -289,7 +286,6 @@ static void cleanup_crtc(test_data_t *test_data,
> > igt_output_t *output)
> > igt_display_t *display = &data->display;
> > igt_plane_t *primary;
> >
> > - igt_pipe_crc_free(test_data->pipe_crc);
> > test_data->pipe_crc = NULL;
> >
> > igt_remove_fb(data->drm_fd, &data->primary_fb);
> > @@ -315,6 +311,7 @@ static void run_test(data_t *data, void
> > (*testfunc)(test_data_t *), int cursor_w
> > test_data.output = output;
> > for (p = 0; p < igt_display_get_n_pipes(display); p++) {
> > test_data.pipe = p;
> > + test_data.pipe_crc = data->pipe_crcs[p];
> >
> > if (!prepare_crtc(&test_data, output, cursor_w,
> > cursor_h))
> > continue;
> > @@ -385,6 +382,7 @@ igt_main
> > uint64_t cursor_width = 64, cursor_height = 64;
> > data_t data = {};
> > int ret;
> > + int p;
> >
> > igt_skip_on_simulation();
> >
> > @@ -405,11 +403,20 @@ igt_main
> > igt_require_pipe_crc();
> >
> > igt_display_init(&data.display, data.drm_fd);
> > +
> > + for (p = 0; p < igt_display_get_n_pipes(&data.display); p++)
> > + data.pipe_crcs[p] = igt_pipe_crc_new(p,
> > +
> > INTEL_PIPE_CRC_SOURCE_AUTO);
> > }
> >
> > run_test_generic(&data, cursor_width);
> >
> > igt_fixture {
> > + for (p = 0; p < igt_display_get_n_pipes(&data.display); p++) {
> > + if (data.pipe_crcs[p])
> > + igt_pipe_crc_free(data.pipe_crcs[p]);
> > + }
> > +
> > igt_display_fini(&data.display);
> > }
> > }
> > --
> > 1.8.5.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel OTC
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Improve irq handling after gpu resets
On Thu, May 22, 2014 at 07:51:45PM +0300, Ville Syrjälä wrote: > On Thu, May 22, 2014 at 05:56:35PM +0200, Daniel Vetter wrote: > > Currently we do a full re-init of all interrupts after a gpu hang. > > Which is pretty bad since we don't restore the interrupts we've > > enabled at runtime correctly. Even with that addressed it's rather > > horribly race. > > > > But on g4x and later we only reset the gt and not the entire gpu. > > Which means we only need to reset the GT interrupt bits. Which has the > > nice benefit that vblank waits, pipe CRC interrupts and everything > > else display related just keeps on working. > > > > The downside is that gt interrupt handling (i.e. ring->get/put_irq) is > > still racy. But as long as the gpu hang reliably wakes all waters and > > we have a short time where the refcount drops to 0 we'll recover. So > > not that bad really. > > A quick test on IVB tells me that GTIMR and GEN6_PMIMR survive the full > gt reset. But the ring IMRs do get clobbered. So could we just skip the > entire irq reset here? Same on ILK. GTIMR survives both render and media resets. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] kms_cursor_crc: Move igt_pipe_crc_{new, free} to init
On Thu, May 22, 2014 at 10:06:37AM -0700, Matt Roper wrote:
> On Thu, May 22, 2014 at 08:01:09PM +0300, Ville Syrjälä wrote:
> > On Thu, May 22, 2014 at 09:47:39AM -0700, Matt Roper wrote:
> > > If a subtest fails, cleanup_crtc() never gets called. Currently that
> > > also causes igt_pipe_crc_free() to never be called, leading all
> > > subsequent subtests to also fail with -EBUSY at igt_pipe_crc_new().
> > > Move the calls to igt_pipe_crc_{new,free} into igt_main so that
> > > we don't need to worry about closing and reopening the CRC
> > > filedescriptor for each subtest.
> >
> > IIRC we can't call them at init because when you call igt_pipe_crc_new()
> > the pipe->port mapping has to be properly set up so that the auto crc
> > source will know what to do.
> >
> > The subtest failure case is the reason why at the start of every subtest
> > we call igt_pipe_crc_free() before calling igt_pipe_crc_new(). Are you
> > saying that's not working as intended?
>
> Right, you're working on a fresh test_data structure for each call of
> run_test(), so you've already lost the test_data->pipe_crc pointer that
> you're trying to check for NULL there.
>
> I guess the right fix is to move the pipe_crc pointer up into data_t
> rather than test_data_t?
I guess just kill test_data_t and shovel everything into data_t. I don't
remember why the test_data_t came to be there, but I don't think it
serves any purpose anymore.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] kms_cursor_crc: Combine data_t and test_data_t
If a subtest fails, cleanup_crtc() never gets called and then the
test_data_t structure for the test is lost, including the CRC file
descriptor that we never got a chance to release; this causes all
subsequent tests to fail with -EBUSY at igt_pipe_crc_new().
The split between permanent data_t and temporary test_data_t doesn't
seem to serve a purpose, so just combine the fields from both into
data_t. This will prevent us from losing the CRC filedescriptor so that
we can properly close and reopen it after a failed test.
Signed-off-by: Matt Roper
---
tests/kms_cursor_crc.c | 206 +++--
1 file changed, 97 insertions(+), 109 deletions(-)
diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c
index 06625ee..92d9a3c 100644
--- a/tests/kms_cursor_crc.c
+++ b/tests/kms_cursor_crc.c
@@ -44,10 +44,6 @@ typedef struct {
igt_display_t display;
struct igt_fb primary_fb;
struct igt_fb fb;
-} data_t;
-
-typedef struct {
- data_t *data;
igt_output_t *output;
enum pipe pipe;
igt_crc_t ref_crc;
@@ -55,7 +51,7 @@ typedef struct {
int screenw, screenh;
int curw, curh; /* cursor size */
igt_pipe_crc_t *pipe_crc;
-} test_data_t;
+} data_t;
static void draw_cursor(cairo_t *cr, int x, int y, int w)
{
@@ -71,11 +67,10 @@ static void draw_cursor(cairo_t *cr, int x, int y, int w)
igt_paint_color_alpha(cr, x + w, y + w, w, w, 0.5, 0.5, 0.5, 1.0);
}
-static void cursor_enable(test_data_t *test_data)
+static void cursor_enable(data_t *data)
{
- data_t *data = test_data->data;
igt_display_t *display = &data->display;
- igt_output_t *output = test_data->output;
+ igt_output_t *output = data->output;
igt_plane_t *cursor;
cursor = igt_output_get_plane(output, IGT_PLANE_CURSOR);
@@ -83,11 +78,10 @@ static void cursor_enable(test_data_t *test_data)
igt_display_commit(display);
}
-static void cursor_disable(test_data_t *test_data)
+static void cursor_disable(data_t *data)
{
- data_t *data = test_data->data;
igt_display_t *display = &data->display;
- igt_output_t *output = test_data->output;
+ igt_output_t *output = data->output;
igt_plane_t *cursor;
cursor = igt_output_get_plane(output, IGT_PLANE_CURSOR);
@@ -96,11 +90,10 @@ static void cursor_disable(test_data_t *test_data)
}
-static void do_single_test(test_data_t *test_data, int x, int y)
+static void do_single_test(data_t *data, int x, int y)
{
- data_t *data = test_data->data;
igt_display_t *display = &data->display;
- igt_pipe_crc_t *pipe_crc = test_data->pipe_crc;
+ igt_pipe_crc_t *pipe_crc = data->pipe_crc;
igt_crc_t crc, ref_crc;
igt_plane_t *cursor;
cairo_t *cr = igt_get_cairo_ctx(data->drm_fd, &data->primary_fb);
@@ -108,93 +101,93 @@ static void do_single_test(test_data_t *test_data, int x,
int y)
igt_info("."); fflush(stdout);
/* Hardware test */
- igt_paint_test_pattern(cr, test_data->screenw, test_data->screenh);
- cursor_enable(test_data);
- cursor = igt_output_get_plane(test_data->output, IGT_PLANE_CURSOR);
+ igt_paint_test_pattern(cr, data->screenw, data->screenh);
+ cursor_enable(data);
+ cursor = igt_output_get_plane(data->output, IGT_PLANE_CURSOR);
igt_plane_set_position(cursor, x, y);
igt_display_commit(display);
- igt_wait_for_vblank(data->drm_fd, test_data->pipe);
+ igt_wait_for_vblank(data->drm_fd, data->pipe);
igt_pipe_crc_collect_crc(pipe_crc, &crc);
- cursor_disable(test_data);
+ cursor_disable(data);
/* Now render the same in software and collect crc */
- draw_cursor(cr, x, y, test_data->curw);
+ draw_cursor(cr, x, y, data->curw);
igt_display_commit(display);
- igt_wait_for_vblank(data->drm_fd, test_data->pipe);
+ igt_wait_for_vblank(data->drm_fd, data->pipe);
igt_pipe_crc_collect_crc(pipe_crc, &ref_crc);
/* Clear screen afterwards */
- igt_paint_color(cr, 0, 0, test_data->screenw, test_data->screenh,
- 0.0, 0.0, 0.0);
+ igt_paint_color(cr, 0, 0, data->screenw, data->screenh,
+ 0.0, 0.0, 0.0);
igt_assert(igt_crc_equal(&crc, &ref_crc));
}
-static void do_test(test_data_t *test_data,
+static void do_test(data_t *data,
int left, int right, int top, int bottom)
{
- do_single_test(test_data, left, top);
- do_single_test(test_data, right, top);
- do_single_test(test_data, right, bottom);
- do_single_test(test_data, left, bottom);
+ do_single_test(data, left, top);
+ do_single_test(data, right, top);
+ do_single_test(data, right, bottom);
+ do_single_test(data, left, bottom);
}
-static void test_crc_onscreen(test_data_t *test_data)
+static void test_crc_onscreen(data_t *d
Re: [Intel-gfx] [PATCH 01/11] drm/i915: move psr_setup_done to psr struct
2014-05-15 21:13 GMT-03:00 Rodrigo Vivi :
> v2: Avoid more than one setup. Removing initialization
> and trusting allocation. (By Paulo Zanoni).
> v3: rebase.
>
> Cc: Paulo Zanoni
> Signed-off-by: Rodrigo Vivi
I guess the commit message needs a little explanation, such as:
"Because our driver assumes only one panel is PSR capable, and we
already have other PSR information on dev_priv instead of intel_dp. If
we ever support multiple PSR panels, we'll have to move struct
i915_psr to intel_dp anyway."
I've seen this patch so many times on this list that I really think we
could merge it before the others :)
With the message above amended, or some other message: Reviewed-by:
Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_dp.c | 6 ++
> drivers/gpu/drm/i915/intel_drv.h | 1 -
> 3 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1a9b4b3..d6fba46 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -640,6 +640,7 @@ struct i915_drrs {
> struct i915_psr {
> bool sink_support;
> bool source_ok;
> + bool setup_done;
> };
>
> enum intel_pch {
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 66891c9..34e8f7a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1657,7 +1657,7 @@ static void intel_edp_psr_setup(struct intel_dp
> *intel_dp)
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct edp_vsc_psr psr_vsc;
>
> - if (intel_dp->psr_setup_done)
> + if (dev_priv->psr.setup_done)
> return;
>
> /* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
> @@ -1672,7 +1672,7 @@ static void intel_edp_psr_setup(struct intel_dp
> *intel_dp)
> I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
>EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
>
> - intel_dp->psr_setup_done = true;
> + dev_priv->psr.setup_done = true;
> }
>
> static void intel_edp_psr_enable_sink(struct intel_dp *intel_dp)
> @@ -4199,8 +4199,6 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
>
> intel_dp_aux_init(intel_dp, intel_connector);
>
> - intel_dp->psr_setup_done = false;
> -
> if (!intel_edp_init_connector(intel_dp, intel_connector, &power_seq))
> {
> drm_dp_aux_unregister_i2c_bus(&intel_dp->aux);
> if (is_edp(intel_dp)) {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index acfc5c8..e72d45a 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -527,7 +527,6 @@ struct intel_dp {
> unsigned long last_power_cycle;
> unsigned long last_power_on;
> unsigned long last_backlight_off;
> - bool psr_setup_done;
> bool use_tps3;
> struct intel_connector *attached_connector;
>
> --
> 1.9.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 39/66] drm/i915: Check hw state in assert_can_disable_lcpll
2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> All the other checks also check hw state, so checking our software
> refcounts for the plls looks a bit odd.
As I mentioned before, this contradicts your own previous review of
the patch that added this code. In addition, you said many times that
we should do SW checks instead of HW checks when possible.
What should be looking odd here is that we check registers directly
for the other stuff, instead of looking at some struct :)
> Also this will simplify the
> conversion over to the shared dpll framework, which itself has massive
> amounts of checks to make sure that we never leave a display pll
> enabled when we shouldn't.
What you wrote above is a nice reason to check the new shared DPLL
structs instead of the registers directly: it has tons of WARNs, so
it's unlikely the structs will be wrong.
>
> So after that conversion we should stil have a good enough coverage of
> asserts for entering pc8/runtime pm on hsw/bdw.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 1513d9fceebe..22b3d74f9ecc 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6926,7 +6926,6 @@ static bool ironlake_get_pipe_config(struct intel_crtc
> *crtc,
> static void assert_can_disable_lcpll(struct drm_i915_private *dev_priv)
> {
> struct drm_device *dev = dev_priv->dev;
> - struct intel_ddi_plls *plls = &dev_priv->ddi_plls;
> struct intel_crtc *crtc;
>
> list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head)
> @@ -6934,9 +6933,9 @@ static void assert_can_disable_lcpll(struct
> drm_i915_private *dev_priv)
> pipe_name(crtc->pipe));
>
> WARN(I915_READ(HSW_PWR_WELL_DRIVER), "Power well on\n");
> - WARN(plls->spll_refcount, "SPLL enabled\n");
> - WARN(plls->wrpll1_refcount, "WRPLL1 enabled\n");
> - WARN(plls->wrpll2_refcount, "WRPLL2 enabled\n");
> + WARN(I915_READ(SPLL_CTL) & SPLL_PLL_ENABLE, "SPLL enabled\n");
> + WARN(I915_READ(WRPLL_CTL1) & WRPLL_PLL_ENABLE, "WRPLL1 enabled\n");
> + WARN(I915_READ(WRPLL_CTL2) & WRPLL_PLL_ENABLE, "WRPLL2 enabled\n");
> WARN(I915_READ(PCH_PP_STATUS) & PP_ON, "Panel power on\n");
> WARN(I915_READ(BLC_PWM_CPU_CTL2) & BLM_PWM_ENABLE,
> "CPU PWM1 enabled\n");
> --
> 1.8.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 41/66] drm/i915: Clean up WRPLL/SPLL #defines
2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> Luckily the bit definitions match, but it's still confusing
> to use one when handling the other. So sprinkle some OCD over
> the #defines to make them match and use the right version in
> each place.
>
> Maybe we should unify these definitions completely, but that
> can always be done sometime in the future.
I agree that using SPLL definitions on WRPLL code was very confusing.
But I think I still prefer the longer field names, since they are more
meaningful. If "select" is too big, we could at least use "sel".
With or without that: Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_reg.h | 7 ---
> drivers/gpu/drm/i915/intel_ddi.c | 12 ++--
> 2 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8f845556503e..64d40f22e708 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5505,9 +5505,10 @@ enum punit_power_well {
> #define WRPLL_CTL1 0x46040
> #define WRPLL_CTL2 0x46060
> #define WRPLL_PLL_ENABLE (1<<31)
> -#define WRPLL_PLL_SELECT_SSC (0x01<<28)
> -#define WRPLL_PLL_SELECT_NON_SSC (0x02<<28)
> -#define WRPLL_PLL_SELECT_LCPLL_2700 (0x03<<28)
> +#define WRPLL_PLL_SSC (1<<28)
> +#define WRPLL_PLL_NON_SSC (2<<28)
> +#define WRPLL_PLL_LCPLL (3<<28)
> +#define WRPLL_PLL_REF_MASK(3<<28)
> /* WRPLL divider programming */
> #define WRPLL_DIVIDER_REFERENCE(x)((x)<<0)
> #define WRPLL_DIVIDER_REF_MASK(0xff)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 16ec6aee3df7..09ae104d9c2b 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -588,9 +588,9 @@ static int intel_ddi_calc_wrpll_link(struct
> drm_i915_private *dev_priv,
> u32 wrpll;
>
> wrpll = I915_READ(reg);
> - switch (wrpll & SPLL_PLL_REF_MASK) {
> - case SPLL_PLL_SSC:
> - case SPLL_PLL_NON_SSC:
> + switch (wrpll & WRPLL_PLL_REF_MASK) {
> + case WRPLL_PLL_SSC:
> + case WRPLL_PLL_NON_SSC:
> /*
> * We could calculate spread here, but our checking
> * code only cares about 5% accuracy, and spread is a max of
> @@ -598,7 +598,7 @@ static int intel_ddi_calc_wrpll_link(struct
> drm_i915_private *dev_priv,
> */
> refclk = 135;
> break;
> - case SPLL_PLL_LCPLL:
> + case WRPLL_PLL_LCPLL:
> refclk = LC_FREQ;
> break;
> default:
> @@ -780,7 +780,7 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
>
> intel_ddi_calculate_wrpll(clock * 1000, &r2, &n2, &p);
>
> - val = WRPLL_PLL_ENABLE | WRPLL_PLL_SELECT_LCPLL_2700 |
> + val = WRPLL_PLL_ENABLE | WRPLL_PLL_LCPLL |
> WRPLL_DIVIDER_REFERENCE(r2) |
> WRPLL_DIVIDER_FEEDBACK(n2) |
> WRPLL_DIVIDER_POST(p);
>
> @@ -879,7 +879,7 @@ void intel_ddi_pll_enable(struct intel_crtc *crtc)
>
> intel_ddi_calculate_wrpll(clock * 1000, &r2, &n2, &p);
>
> - new_val = WRPLL_PLL_ENABLE | WRPLL_PLL_SELECT_LCPLL_2700 |
> + new_val = WRPLL_PLL_ENABLE | WRPLL_PLL_LCPLL |
> WRPLL_DIVIDER_REFERENCE(r2) |
> WRPLL_DIVIDER_FEEDBACK(n2) | WRPLL_DIVIDER_POST(p);
>
> --
> 1.8.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 42/66] drm/i915: Make intel_wait_for_pipe_off static
2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> Noticed while reading around.
That's because you killed the intel_tv.c caller in patch 06/66.
Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h | 1 -
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 22b3d74f9ecc..713563faeafd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -854,7 +854,7 @@ static bool pipe_dsl_stopped(struct drm_device *dev, enum
> pipe pipe)
> * ends up stopping at the start of the next frame).
> *
> */
> -void intel_wait_for_pipe_off(struct drm_device *dev, int pipe)
> +static void intel_wait_for_pipe_off(struct drm_device *dev, int pipe)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> enum transcoder cpu_transcoder =
> intel_pipe_to_cpu_transcoder(dev_priv,
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index c85f5e5ddc7c..2be0b104fbec 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -719,7 +719,6 @@ int intel_get_pipe_from_crtc_id(struct drm_device *dev,
> void *data,
> enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private
> *dev_priv,
> enum pipe pipe);
> void intel_wait_for_vblank(struct drm_device *dev, int pipe);
> -void intel_wait_for_pipe_off(struct drm_device *dev, int pipe);
> 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);
> --
> 1.8.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 40/66] drm/i915: Remove spll_refcount for hsw
2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> SPLL would be a reference clock we could potentially share,
> especially if we want to use the SSC mode. But currently we
> don't, so let's rip out this complexity for a simpler conversion
> to the new display pll framework.
I'm really not a fan of this patch, I think it goes in the opposite
way of where we want to be. We already talked a few times about adding
sharing support, and I even recently considered adding a
"i915.edp_use_ssc" module option and ask some bug reporters to test
them. Also, adding the SPLL support will be another way to prove that
your "shared DPLL" code is flexible enough to handle the all the
possibilities generated by the creative minds of the HW developers.
Can you please include SPLL in your conversion?
Thanks,
Paulo
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 -
> drivers/gpu/drm/i915/intel_ddi.c | 41
> +---
> 2 files changed, 13 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e6c16068010f..b6eac92e0a22 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -221,7 +221,6 @@ void intel_link_compute_m_n(int bpp, int nlanes,
> struct intel_link_m_n *m_n);
>
> struct intel_ddi_plls {
> - int spll_refcount;
> int wrpll1_refcount;
> int wrpll2_refcount;
> };
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 271ce19ee880..16ec6aee3df7 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -394,14 +394,11 @@ void intel_ddi_put_crtc_pll(struct drm_crtc *crtc)
>
> switch (intel_crtc->ddi_pll_sel) {
> case PORT_CLK_SEL_SPLL:
> - plls->spll_refcount--;
> - if (plls->spll_refcount == 0) {
> - DRM_DEBUG_KMS("Disabling SPLL\n");
> - val = I915_READ(SPLL_CTL);
> - WARN_ON(!(val & SPLL_PLL_ENABLE));
> - I915_WRITE(SPLL_CTL, val & ~SPLL_PLL_ENABLE);
> - POSTING_READ(SPLL_CTL);
> - }
> + DRM_DEBUG_KMS("Disabling SPLL\n");
> + val = I915_READ(SPLL_CTL);
> + WARN_ON(!(val & SPLL_PLL_ENABLE));
> + I915_WRITE(SPLL_CTL, val & ~SPLL_PLL_ENABLE);
> + POSTING_READ(SPLL_CTL);
> break;
> case PORT_CLK_SEL_WRPLL1:
> plls->wrpll1_refcount--;
> @@ -425,7 +422,6 @@ void intel_ddi_put_crtc_pll(struct drm_crtc *crtc)
> break;
> }
>
> - WARN(plls->spll_refcount < 0, "Invalid SPLL refcount\n");
> WARN(plls->wrpll1_refcount < 0, "Invalid WRPLL1 refcount\n");
> WARN(plls->wrpll2_refcount < 0, "Invalid WRPLL2 refcount\n");
>
> @@ -821,16 +817,9 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
> }
>
> } else if (type == INTEL_OUTPUT_ANALOG) {
> - if (plls->spll_refcount == 0) {
> - DRM_DEBUG_KMS("Using SPLL on pipe %c\n",
> - pipe_name(pipe));
> - plls->spll_refcount++;
> - intel_crtc->ddi_pll_sel = PORT_CLK_SEL_SPLL;
> - } else {
> - DRM_ERROR("SPLL already in use\n");
> - return false;
> - }
> -
> + DRM_DEBUG_KMS("Using SPLL on pipe %c\n",
> + pipe_name(pipe));
> + intel_crtc->ddi_pll_sel = PORT_CLK_SEL_SPLL;
> } else {
> WARN(1, "Invalid DDI encoder type %d\n", type);
> return false;
> @@ -869,13 +858,13 @@ void intel_ddi_pll_enable(struct intel_crtc *crtc)
> return;
>
> case PORT_CLK_SEL_SPLL:
> - pll_name = "SPLL";
> - reg = SPLL_CTL;
> - refcount = plls->spll_refcount;
> new_val = SPLL_PLL_ENABLE | SPLL_PLL_FREQ_1350MHz |
> SPLL_PLL_SSC;
> - break;
> -
> + WARN(I915_READ(SPLL_CTL) & enable_bit, "SPLL already
> enabled\n");
> + I915_WRITE(SPLL_CTL, new_val);
> + POSTING_READ(SPLL_CTL);
> + udelay(20);
> + return;
> case PORT_CLK_SEL_WRPLL1:
> case PORT_CLK_SEL_WRPLL2:
> if (crtc->ddi_pll_sel == PORT_CLK_SEL_WRPLL1) {
> @@ -1186,7 +1175,6 @@ void intel_ddi_setup_hw_pll_state(struct drm_device
> *dev)
> enum pipe pipe;
> struct intel_crtc *intel_crtc;
>
> - dev_priv->ddi_plls.spll_refcount = 0;
> dev_priv->ddi_plls.wrpll1_refcount = 0;
> dev_priv->ddi_plls.wrpll2_refcount = 0;
>
> @@ -1203,9 +1191,6 @@ void intel_ddi_setup_hw_pll_state(struct drm_device
> *dev)
>
Re: [Intel-gfx] [PATCH 43/66] drm/i915: Disable pipe before ports on ilk
2014-04-24 18:55 GMT-03:00 Daniel Vetter : > The modeset sequence docs are very clear that we should disable the > pipe before we switch off any ports, for both pch ports and the cpu > edp port. > > In practice it doesn't seem to matter too much since for non-DP pch > ports it only matters that the pch transcoder is still on. And for cpu > edp ports it either doesn't seem to matter or we're quick enough. > > But for DP pch ports we have a regular stream of bug reports where the > cpu pipe seems to be stuck and won't turn off. This change should > address this. > > This should also help with using a nuclear pageflip atomically switch > off all planes, since it moves that ahead of any other disabling > action. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=62251 > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52061 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54687 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67462 > Signed-off-by: Daniel Vetter This patch doesn't make us spec-compliant either. For example, the spec says we need to disable audio, backlight and the panel power *before* we disable the pipe. This is done by intel_disable_dp on IVB, which is, today, at the correct order. After this patch, we will be doing all this *after* we disable the pipe, which is not what the spec says we should do. Also, we have ->disable and ->post_disable for a reason, and it kinda looks like you're making ILK's ->disable do what ->post_disable should be doing. It seems what we should do if we want to be correct is to mode stuff from ->disable to ->post_disable. > --- > drivers/gpu/drm/i915/intel_display.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 713563faeafd..82ad84eefc8d 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -3924,14 +3924,14 @@ static void ironlake_crtc_disable(struct drm_crtc > *crtc) > > ilk_crtc_disable_planes(crtc); > > - for_each_encoder_on_crtc(dev, crtc, encoder) > - encoder->disable(encoder); > - > if (intel_crtc->config.has_pch_encoder) > intel_set_pch_fifo_underrun_reporting(dev, pipe, false); > > intel_disable_pipe(dev_priv, pipe); > > + for_each_encoder_on_crtc(dev, crtc, encoder) > + encoder->disable(encoder); > + > ironlake_pfit_disable(intel_crtc); > > for_each_encoder_on_crtc(dev, crtc, encoder) > -- > 1.8.1.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 39/66] drm/i915: Check hw state in assert_can_disable_lcpll
On Thu, May 22, 2014 at 03:10:37PM -0300, Paulo Zanoni wrote:
> 2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> > All the other checks also check hw state, so checking our software
> > refcounts for the plls looks a bit odd.
>
> As I mentioned before, this contradicts your own previous review of
> the patch that added this code. In addition, you said many times that
> we should do SW checks instead of HW checks when possible.
>
> What should be looking odd here is that we check registers directly
> for the other stuff, instead of looking at some struct :)
>
> > Also this will simplify the
> > conversion over to the shared dpll framework, which itself has massive
> > amounts of checks to make sure that we never leave a display pll
> > enabled when we shouldn't.
>
> What you wrote above is a nice reason to check the new shared DPLL
> structs instead of the registers directly: it has tons of WARNs, so
> it's unlikely the structs will be wrong.
If I've done this correctly this should happen a few patches later on. If
not I can throw a new patch on top. I'll check this.
-Daniel
>
> >
> > So after that conversion we should stil have a good enough coverage of
> > asserts for entering pc8/runtime pm on hsw/bdw.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 7 +++
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 1513d9fceebe..22b3d74f9ecc 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6926,7 +6926,6 @@ static bool ironlake_get_pipe_config(struct
> > intel_crtc *crtc,
> > static void assert_can_disable_lcpll(struct drm_i915_private *dev_priv)
> > {
> > struct drm_device *dev = dev_priv->dev;
> > - struct intel_ddi_plls *plls = &dev_priv->ddi_plls;
> > struct intel_crtc *crtc;
> >
> > list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head)
> > @@ -6934,9 +6933,9 @@ static void assert_can_disable_lcpll(struct
> > drm_i915_private *dev_priv)
> > pipe_name(crtc->pipe));
> >
> > WARN(I915_READ(HSW_PWR_WELL_DRIVER), "Power well on\n");
> > - WARN(plls->spll_refcount, "SPLL enabled\n");
> > - WARN(plls->wrpll1_refcount, "WRPLL1 enabled\n");
> > - WARN(plls->wrpll2_refcount, "WRPLL2 enabled\n");
> > + WARN(I915_READ(SPLL_CTL) & SPLL_PLL_ENABLE, "SPLL enabled\n");
> > + WARN(I915_READ(WRPLL_CTL1) & WRPLL_PLL_ENABLE, "WRPLL1 enabled\n");
> > + WARN(I915_READ(WRPLL_CTL2) & WRPLL_PLL_ENABLE, "WRPLL2 enabled\n");
> > WARN(I915_READ(PCH_PP_STATUS) & PP_ON, "Panel power on\n");
> > WARN(I915_READ(BLC_PWM_CPU_CTL2) & BLM_PWM_ENABLE,
> > "CPU PWM1 enabled\n");
> > --
> > 1.8.1.4
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Paulo Zanoni
--
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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Kill intel_crtc->vbl_wait
On Thu, May 22, 2014 at 06:05:34PM +0200, Daniel Vetter wrote:
> On Thu, May 22, 2014 at 04:49:03PM +0100, Chris Wilson wrote:
> > On Thu, May 22, 2014 at 06:39:33PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Share the waitqueue that drm_irq uses when performing the vblank evade
> > > trick for atomic pipe updates.
> > >
> > > Suggested-by: Daniel Vetter
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/i915_irq.c | 25 ++---
> > > drivers/gpu/drm/i915/intel_display.c | 2 --
> > > drivers/gpu/drm/i915/intel_drv.h | 2 --
> > > drivers/gpu/drm/i915/intel_sprite.c | 5 +++--
> > > 4 files changed, 9 insertions(+), 25 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index 304f86a..5905a9d 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -1724,19 +1724,6 @@ static void gen6_rps_irq_handler(struct
> > > drm_i915_private *dev_priv, u32 pm_iir)
> > > }
> > > }
> > >
> > > -static bool intel_pipe_handle_vblank(struct drm_device *dev, enum pipe
> > > pipe)
> > > -{
> > > - struct intel_crtc *crtc;
> > > -
> > > - if (!drm_handle_vblank(dev, pipe))
> > > - return false;
> > > -
> > > - crtc = to_intel_crtc(intel_get_crtc_for_pipe(dev, pipe));
> > > - wake_up(&crtc->vbl_wait);
> > > -
> > > - return true;
> > > -}
> >
> > Can we keep this bare wrapper? It is quite useful for hooking in vblank
> > checks - i.e. saves me having to reinrtoduce it.
>
> Just smash them into drm_handle_vblank?
The ones I have in mind the pageflip stall checks and gpu-boost for
missed pageflips, i.e. driver specific.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 44/66] drm/i915: Pass port explicitly to intel_ddi_get_hw_state
2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> Well, the newly created intel_ddi_get_port_state.
>
> In general intel_ddi.c has way too intimate knowledge with everyone
> else as exemplified with all the encoder/connector noodling and the
> massive exported function list.
>
> As a first step explictly pass around the port, first in the encoder
> callback.
I don't really see the benefit of this patch, and the sentences above
don't really help me. Can you please clarify?
Anyway, the patch is correct, so: Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_crt.c | 8 +++-
> drivers/gpu/drm/i915/intel_ddi.c | 13 ++---
> drivers/gpu/drm/i915/intel_drv.h | 3 ++-
> 3 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 22d8347f7838..f34d1df88918 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -137,6 +137,12 @@ static void hsw_crt_get_config(struct intel_encoder
> *encoder,
> pipe_config->adjusted_mode.flags |= intel_crt_get_flags(encoder);
> }
>
> +static bool hsw_crt_get_hw_state(struct intel_encoder *encoder,
> +enum pipe *pipe)
> +{
> + return intel_ddi_get_port_state(encoder, pipe, PORT_E);
> +}
> +
> /* Note: The caller is required to filter out dpms modes not supported by the
> * platform. */
> static void intel_crt_set_dpms(struct intel_encoder *encoder, int mode)
> @@ -858,7 +864,7 @@ void intel_crt_init(struct drm_device *dev)
> crt->base.hpd_pin = HPD_CRT;
> if (HAS_DDI(dev)) {
> crt->base.get_config = hsw_crt_get_config;
> - crt->base.get_hw_state = intel_ddi_get_hw_state;
> + crt->base.get_hw_state = hsw_crt_get_hw_state;
> } else {
> crt->base.get_config = intel_crt_get_config;
> crt->base.get_hw_state = intel_crt_get_hw_state;
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 09ae104d9c2b..ace43c6a6fa4 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1082,12 +1082,11 @@ bool intel_ddi_connector_get_hw_state(struct
> intel_connector *intel_connector)
> }
> }
>
> -bool intel_ddi_get_hw_state(struct intel_encoder *encoder,
> - enum pipe *pipe)
> +bool intel_ddi_get_port_state(struct intel_encoder *encoder,
> + enum pipe *pipe, enum port port)
> {
> struct drm_device *dev = encoder->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> - enum port port = intel_ddi_get_encoder_port(encoder);
> enum intel_display_power_domain power_domain;
> u32 tmp;
> int i;
> @@ -1135,6 +1134,14 @@ bool intel_ddi_get_hw_state(struct intel_encoder
> *encoder,
> return false;
> }
>
> +static bool intel_ddi_get_hw_state(struct intel_encoder *encoder,
> + enum pipe *pipe)
> +{
> + enum port port = intel_ddi_get_encoder_port(encoder);
> +
> + return intel_ddi_get_port_state(encoder, pipe, port);
> +}
> +
> static uint32_t intel_ddi_get_crtc_pll(struct drm_i915_private *dev_priv,
>enum pipe pipe)
> {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 2be0b104fbec..ba727b11014a 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -671,7 +671,8 @@ void intel_prepare_ddi(struct drm_device *dev);
> void hsw_fdi_link_train(struct drm_crtc *crtc);
> void intel_ddi_init(struct drm_device *dev, enum port port);
> enum port intel_ddi_get_encoder_port(struct intel_encoder *intel_encoder);
> -bool intel_ddi_get_hw_state(struct intel_encoder *encoder, enum pipe *pipe);
> +bool intel_ddi_get_port_state(struct intel_encoder *encoder, enum pipe *pipe,
> + enum port port);
> int intel_ddi_get_cdclk_freq(struct drm_i915_private *dev_priv);
> void intel_ddi_pll_init(struct drm_device *dev);
> void intel_ddi_enable_transcoder_func(struct drm_crtc *crtc);
> --
> 1.8.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 40/66] drm/i915: Remove spll_refcount for hsw
On Thu, May 22, 2014 at 03:41:25PM -0300, Paulo Zanoni wrote: > 2014-04-24 18:55 GMT-03:00 Daniel Vetter : > > SPLL would be a reference clock we could potentially share, > > especially if we want to use the SSC mode. But currently we > > don't, so let's rip out this complexity for a simpler conversion > > to the new display pll framework. > > I'm really not a fan of this patch, I think it goes in the opposite > way of where we want to be. We already talked a few times about adding > sharing support, and I even recently considered adding a > "i915.edp_use_ssc" module option and ask some bug reporters to test > them. Also, adding the SPLL support will be another way to prove that > your "shared DPLL" code is flexible enough to handle the all the > possibilities generated by the creative minds of the HW developers. > Can you please include SPLL in your conversion? Until we actually know that we need it I don't see a reason to do it. And for a quick debug patch you can always just disable vga on bdw and simply use the spll for edp without any sharing logic. But if you wonder who we should integrate SPLL sharing into this framework it's straightforward: - Add a possible_dpll_mask to the pipe_config, and pre-fill it in the encoder->compute_config masks. - Add spll state the the dpll_hw_state structure, pre-fill that in the encoder->compute_config hooks (might as well do it right) - add checks for the possible_dpll_mask in the get_shared_dpll function Bonus point: We can ditch the ibx special case. Or you go even simpler: If we need edp SSC _and_ possible VGA we only let the SPLL run at 2.7GHz. Then add a 2nd shared_spll to dev_priv which uses the shared dpll functions and all that logic (might need to frob the interfaces a bit) but outside of the selection logic (since we always have the same configuration). Will be a bit more messy since we need to special-case hw state readout code and a few other places. Cheers, 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 http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: fix possible RPM ref leaking during RPS disabling
On Thu, May 22, 2014 at 01:56:17PM +0100, Robert Beckett wrote: > On 13/05/2014 14:54, Daniel Vetter wrote: > >On Tue, May 13, 2014 at 04:46:10PM +0300, Imre Deak wrote: > >>On Mon, 2014-05-12 at 19:51 +0200, Daniel Vetter wrote: > >>>On Mon, May 12, 2014 at 06:35:04PM +0300, Imre Deak wrote: > In > > commit c6df39b5ea6342323a42edfbeeca0a28c643d7ae > Author: Imre Deak > Date: Mon Apr 14 20:24:29 2014 +0300 > > drm/i915: get a runtime PM ref for the deferred GT powersave enabling > > I added an RPM get-ref when enabling RPS from a deferred work, but forgot > to add the corresponding put-ref when canceling the work. This may leave > RPM disabled. > > Signed-off-by: Imre Deak > >>> > >>>Could we intentionally hit this by e.g. racing a suspend/resume against > >>>runtime pm? E.g. > >>>1. disable all outputs, make sure we've entered runtime pm > >>>2. set runtime autosuspend delay to 0 > >>>3. suspend/resume > >>>4. autosuspend (hopefully, my understanding is a bit unclear) > >>> > >>>->Boom > >>> > >>>Would look nice as an igt subtest if it works ;-) > >> > >>Yep, works consistently as expected both before and after the fix. I > >>pushed the new subtest, please add here: > >>Testcase: igt/pm_pc8/system-suspend > > > >Now I'm confused: I expected this to blow up without your fix here, and > >not work with or without it?! Please unconfuse ... > >-Daniel > > > Im not sure what you are expecting to go boom. > It is pretty difficult to get a race between suspend/resume and runtime pm. > During system suspend, the pm core grabs a runtime ref without resume > callbacks, and releases it on the resume. (see > https://www.kernel.org/doc/Documentation/power/runtime_pm.txt part 6). > > Also, as i915_drm_freeze does a runtime pm get, at step 3, it will cause a > runtime resume before doing the system suspend. On the system resume, it > will do a runtime pm put, which will cause a runtime suspend due to > autosuspend delay being 0, and so step 4, autosuspend will occur. This > should all work fine (assuming the patch is applied to handle any > refcounting between back to back resume->suspend which cancels the enable > before it is executed). Rest assured that Imre's igt goes indeed boom. We run the rps stuff delayed which makes the race possible, as long as you autosuspend quickly enough. You might want to run the testcase to confirm that ;-) And thanks a lot for mentioning your concerns, this kind of information and questions are exactly what I expect from patch reviewers. I will augment the commit message a bit to make it clear how stuff blows up. > It all looks fine to me. > > Reviewed-by: Robert Beckett Thanks, Daniel > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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 http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
On Thu, May 22, 2014 at 02:59:56PM +, Lin, Mengdong wrote: > > -Original Message- > > From: Vetter, Daniel > > Sent: Tuesday, May 20, 2014 11:08 PM > > > > On 20/05/2014 16:57, Thierry Reding wrote: > > > On Tue, May 20, 2014 at 04:45:56PM +0200, Daniel Vetter wrote: > > >> >On Tue, May 20, 2014 at 4:29 PM, Imre Deak > > wrote: > > >>> > >On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote: > > > >>This RFC is based on previous discussion to set up a generic > > > >>communication channel between display and audio driver and an > > > >>internal design of Intel MCG/VPG HDMI audio driver. It's still > > > >>an initial draft and your advice would be appreciated to > > > >>improve the design. > > > >> > > > >>The basic idea is to create a new avsink module and let both > > > >>drm and alsa depend on it. > > > >>This new module provides a framework and APIs for > > > >>synchronization between the display and audio driver. > > > >> > > > >>1. Display/Audio Client > > > >> > > > >>The avsink core provides APIs to create, register and lookup a > > > >>display/audio client. > > > >>A specific display driver (eg. i915) or audio driver (eg. > > > >>HD-Audio > > > >>driver) can create a client, add some resources objects (shared > > > >>power wells, display outputs, and audio inputs, register ops) > > > >>to the client, and then register this client to avisink core. > > > >>The peer driver can look up a registered client by a name or > > > >>type, or both. If a client gives a valid peer client name on > > > >>registration, avsink core will bind the two clients as peer for > > > >>each other. And we expect a display client and an audio client > > > >>to be peers for each other in a system. > > >>> > > > > >>> > >One problem we have at the moment is the order of calling the > > >>> > >system suspend/resume handlers of the display driver wrt. that of > > >>> > >the audio driver. Since the power well control is part of the > > >>> > >display HW block, we need to run the display driver's resume > > >>> > >handler first, initialize the HW, and only then let the audio > > >>> > >driver's resume handler run. For similar reasons we have to call > > >>> > >the audio suspend handler first and only then the display driver > > >>> > >resume handler. Currently we solve this using the display > > >>> > >driver's late/early suspend/resume hooks, but we'd need a more robust > > solution. > > >>> > > > > >>> > >This seems to be a similar issue to the load time ordering > > >>> > >problem that you describe later. Having a real device for avsync > > >>> > >that would be a child of the display device would solve the > > >>> > >ordering issue in both cases. I admit I haven't looked into it if > > >>> > >this is feasible, but I would like to see some solution to this as > > >>> > >part of > > the plan. > > >> > > > >> >Yeah, this is a big reason why I want real devices - we have piles > > >> >of infrastructure to solve these ordering issues as soon as there's > > >> >a struct device around. If we don't use that, we need to reinvent > > >> >all those wheels ourselves. > > > To make the driver core's magic work I think you'd need to find a way > > > to reparent the audio device under the display device. Presumably they > > > come from two different parts of the device tree (two different PCI > > > devices I would guess for Intel, two different platform devices on > > > SoCs). Changing the parent after a device has been registered doesn't > > > work as far as I know. But even assuming that would work, I have > > > trouble imagining what the implications would be on the rest of the driver > > model. > > > > > > I faced similar problems with the Tegra DRM driver, and the only way I > > > can see to make this kind of interaction between devices work is by > > > tacking on an extra layer outside the core driver model. > > > That's why we need a new avsink device which is a proper child of the gfx > > device, and the audio driver needs to use the componentized device > > framework so that the suspend/resume ordering works correctly. Or at least > > that's been my idea, might be we have some small gaps here and there. > > -Daniel > > Hi Daniel, > > Would you please share more info about your idea? > > - What would be an avsink device represent here? > E.g. on Intel platforms, will the whole display device have a child > avsink device or multiple avsink devices for each DDI port? My idea would be to have one for each output pipe (i.e. the link between audio and gfx), not one per ddi. Gfx driver would then let audio know when a screen is connected and which one (e.g. exact model serial from edid). This is somewhat important for dp mst where there's no longer a fixed relationship between audio pin and screen > > - And for the relationship between audio driver and the avsink device, > which would be the m
Re: [Intel-gfx] [PATCH 39/66] drm/i915: Check hw state in assert_can_disable_lcpll
On Thu, May 22, 2014 at 9:26 PM, Daniel Vetter wrote: > On Thu, May 22, 2014 at 03:10:37PM -0300, Paulo Zanoni wrote: >> 2014-04-24 18:55 GMT-03:00 Daniel Vetter : >> > All the other checks also check hw state, so checking our software >> > refcounts for the plls looks a bit odd. >> >> As I mentioned before, this contradicts your own previous review of >> the patch that added this code. In addition, you said many times that >> we should do SW checks instead of HW checks when possible. >> >> What should be looking odd here is that we check registers directly >> for the other stuff, instead of looking at some struct :) >> >> > Also this will simplify the >> > conversion over to the shared dpll framework, which itself has massive >> > amounts of checks to make sure that we never leave a display pll >> > enabled when we shouldn't. >> >> What you wrote above is a nice reason to check the new shared DPLL >> structs instead of the registers directly: it has tons of WARNs, so >> it's unlikely the structs will be wrong. > > If I've done this correctly this should happen a few patches later on. If > not I can throw a new patch on top. I'll check this. Ah, actually we don't need it any more, the new stuff is much better ;-) assert_can_disable_lcpll checks crtc->active for all pipes. And the modeset state checker makes sure that the refcounts perfectly match the crtcs, i.e. wrpll_refcount = \sum crtc->active. This is how we check the sw side of things. Adding yet another sw check here feels like too much overkill.y -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 http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Fix up fifo underrun tracking, take N
On Thu, May 22, 2014 at 07:55:52PM +0300, Ville Syrjälä wrote:
> On Thu, May 22, 2014 at 05:56:32PM +0200, Daniel Vetter wrote:
> > So apparently this is tricky.
> >
> > We need to consider:
> > - We start out with all the hw enabling bits disabled, both the
> > individual fifo underrun interrupts and the shared display error
> > interrupts masked. Otherwise if the bios config is broken we'll blow
> > up with a NULL deref in our interrupt handler since the crtc
> > structures aren't set up yet at driver load time.
> > - On gmch we need to mask fifo underruns on the sw side, so always
> > need to set that in sanitize_crtc for those platforms.
> > - On other platforms we try to set the sw tracking so that it reflects
> > the real state. But since a few platforms have shared bits we must
> > _not_ disable fifo underrun reporting. Otherwise we'll never enable
> > the shared error interrupt.
> >
> > This is the state before out patch, but unfortunately this is not good
> > enough. But after a suspend resume operation this is broken:
> > 1. We don't enable the hw interrupts since the same code runs on
> > resume as on driver load.
> > 2. The fifo underrun state adjustments we do in sanitize_crtc doesn't
> > fire on resume since (except for hilarious firmware) all pipes are off
> > at that point. But they also don't hurt since the subsequent crtc
> > enabling due to force_restore will enable fifo underruns.
> >
> > Which means when we enable fifo underrun reporting we notice that the
> > per-crtc state is already correct and short-circuit everthing out. And
> > the interrupt doesn't get enabled.
> >
> > A similar problem would happen if the bios doesn't light up anything
> > when the driver loads. Which is exactly what happens when we reload
> > the driver since our unload functions disables all outputs.
> >
> > Now we can't just rip out the short-circuit logic and unconditionally
> > update the fifo underrun reporting interrupt masking: We have some
> > checks for shared error interrupts to catch issues that happened when
> > the shared error interrupt was disabled.
>
> Hmm. Do we have cases where we do enabled->enabled "transition"?
> Because in that case we would now clear the register without
> reporting if there was an underrun in the register.
We definitely have disabled->disabled transtions, which is what we need to
filter out. Since it means we have either untrusted watermarks or hit and
underrun.
For enabled->enabled I think that can happen in crtc_enable - we
unconditionally enable underrun reporting againg to clear out old fail (or
firmware setups). But we don't always disable it when disabling the crtc
since some platforms/ports don't underrun when disabled.
This also only matters when we've had an underrun with a shared error
interrupt somewhere. Which is the case where the old code is broken
anyway, so I'm not sure how much we should care really.
Also the current code only checks for missed fifo underruns on disabling,
so even if there is a notch of a leak here it's definitely not something
this patch will regress.
-Daniel
>
> >
> > The right fix is to push down this logic so that we can always update
> > the hardware state, but only check for missed fifo underruns on a real
> > enabled->disabled transition and ignore them when we're already
> > disabled.
> >
> > On platforms with shared error interrupt the pipe CRC interrupts are
> > grouped together with the fifo underrun reporting this fixes pipe CRC
> > support after suspend and driver reloads.
> >
> > Testcase: igt/kms_pipe_crc_basic/suspend-*
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 44
> > ++---
> > 1 file changed, 19 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 304f86a3162c..4d44f09eb833 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -335,7 +335,8 @@ void i9xx_check_fifo_underruns(struct drm_device *dev)
> > }
> >
> > static void i9xx_set_fifo_underrun_reporting(struct drm_device *dev,
> > -enum pipe pipe, bool enable)
> > +enum pipe pipe,
> > +bool enable, bool old)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > u32 reg = PIPESTAT(pipe);
> > @@ -347,7 +348,7 @@ static void i9xx_set_fifo_underrun_reporting(struct
> > drm_device *dev,
> > I915_WRITE(reg, pipestat | PIPE_FIFO_UNDERRUN_STATUS);
> > POSTING_READ(reg);
> > } else {
> > - if (pipestat & PIPE_FIFO_UNDERRUN_STATUS)
> > + if (old && pipestat & PIPE_FIFO_UNDERRUN_STATUS)
> > DRM_ERROR("pipe %c underrun\n", pipe_name(pipe));
> > }
> > }
> > @@ -366,7 +367,8 @@ static void ironlake_set_fifo_underrun_reporting(struct
> >
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Improve irq handling after gpu resets
On Thu, May 22, 2014 at 07:51:45PM +0300, Ville Syrjälä wrote:
> On Thu, May 22, 2014 at 05:56:35PM +0200, Daniel Vetter wrote:
> > Currently we do a full re-init of all interrupts after a gpu hang.
> > Which is pretty bad since we don't restore the interrupts we've
> > enabled at runtime correctly. Even with that addressed it's rather
> > horribly race.
> >
> > But on g4x and later we only reset the gt and not the entire gpu.
> > Which means we only need to reset the GT interrupt bits. Which has the
> > nice benefit that vblank waits, pipe CRC interrupts and everything
> > else display related just keeps on working.
> >
> > The downside is that gt interrupt handling (i.e. ring->get/put_irq) is
> > still racy. But as long as the gpu hang reliably wakes all waters and
> > we have a short time where the refcount drops to 0 we'll recover. So
> > not that bad really.
>
> A quick test on IVB tells me that GTIMR and GEN6_PMIMR survive the full
> gt reset. But the ring IMRs do get clobbered. So could we just skip the
> entire irq reset here?
Hm ... And things still neatly work afterwards?
I guess the FIXME we need to keep since clobbering the per-ring registers
through the reset is still racy. But we'd only need to restore the bits
correctly.
I'll respin.
-Daniel
>
> >
> > Testcase: igt/kms_flip/vblank-vs-hang
> > Testcase: igt/kms_pipe_crc_basic/hang-*
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 17 +
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/i915_irq.c | 35 +++
> > 3 files changed, 37 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index c83c83b74bf4..69a75bb7ad83 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -811,17 +811,18 @@ int i915_reset(struct drm_device *dev)
> > }
> >
> > /*
> > -* FIXME: This is horribly race against concurrent pageflip and
> > -* vblank wait ioctls since they can observe dev->irqs_disabled
> > -* being false when they shouldn't be able to.
> > +* FIXME: This races pretty badly against concurrent holders of
> > +* ring interrupts. This is possible since we've started to drop
> > +* dev->struct_mutex in select places when waiting for the gpu.
> > */
> > - drm_irq_uninstall(dev);
> > - drm_irq_install(dev, dev->pdev->irq);
> > + intel_gt_irq_reinit(dev);
> >
> > - /* rps/rc6 re-init is necessary to restore state lost after the
> > -* reset and the re-install of drm irq. Skip for ironlake per
> > + /*
> > +* rps/rc6 re-init is necessary to restore state lost after the
> > +* reset and the re-install of gt irqs. Skip for ironlake per
> > * previous concerns that it doesn't respond well to some forms
> > -* of re-init after reset. */
> > +* of re-init after reset.
> > +*/
> > if (INTEL_INFO(dev)->gen > 5)
> > intel_reset_gt_powersave(dev);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 459b02ad1ef3..61792c4050e7 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2078,6 +2078,7 @@ void gen6_set_pm_mask(struct drm_i915_private
> > *dev_priv, u32 pm_iir,
> > int new_delay);
> > extern void intel_irq_init(struct drm_device *dev);
> > extern void intel_hpd_init(struct drm_device *dev);
> > +extern void intel_gt_irq_reinit(struct drm_device *dev);
> >
> > extern void intel_uncore_sanitize(struct drm_device *dev);
> > extern void intel_uncore_early_sanitize(struct drm_device *dev);
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 3cd659b47dd2..6dba645a81fa 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -3140,6 +3140,14 @@ static void valleyview_irq_preinstall(struct
> > drm_device *dev)
> > POSTING_READ(VLV_IER);
> > }
> >
> > +static void gen8_gt_irq_reset(struct drm_i915_private *dev_priv)
> > +{
> > + GEN8_IRQ_RESET_NDX(GT, 0);
> > + GEN8_IRQ_RESET_NDX(GT, 1);
> > + GEN8_IRQ_RESET_NDX(GT, 2);
> > + GEN8_IRQ_RESET_NDX(GT, 3);
> > +}
> > +
> > static void gen8_irq_reset(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > @@ -3148,10 +3156,7 @@ static void gen8_irq_reset(struct drm_device *dev)
> > I915_WRITE(GEN8_MASTER_IRQ, 0);
> > POSTING_READ(GEN8_MASTER_IRQ);
> >
> > - GEN8_IRQ_RESET_NDX(GT, 0);
> > - GEN8_IRQ_RESET_NDX(GT, 1);
> > - GEN8_IRQ_RESET_NDX(GT, 2);
> > - GEN8_IRQ_RESET_NDX(GT, 3);
> > + gen8_gt_irq_reset(dev_priv);
>
Re: [Intel-gfx] [PATCH 45/66] drm/i915: Unexport intel_ddi_connector_get_hw_state
2014-04-24 18:55 GMT-03:00 Daniel Vetter :
> The connector->get_hw_state function is actually platform dependent.
> So move it out of the shared connector init functions. This allows us
> to drop another intel_ddi.c export.
>
> Signed-off-by: Daniel Vetter
The nice thing about the current code is that intel_ddi_init(),
intel_hdmi_init() and intel_dp_init() only init encoder-specific data,
and the xx_connector_init() functions only init connector-specific
data. This patch will break this abstraction. I think the cost of
breaking the organization just to unexport a function is not worth it.
Also, see below:
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 10 +++---
> drivers/gpu/drm/i915/intel_dp.c | 5 +
> drivers/gpu/drm/i915/intel_drv.h | 1 -
> drivers/gpu/drm/i915/intel_hdmi.c | 5 +
> 4 files changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ace43c6a6fa4..afa1e87c54cc 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1037,7 +1037,7 @@ void intel_ddi_disable_transcoder_func(struct
> drm_i915_private *dev_priv,
> I915_WRITE(reg, val);
> }
>
> -bool intel_ddi_connector_get_hw_state(struct intel_connector
> *intel_connector)
> +static bool intel_ddi_connector_get_hw_state(struct intel_connector
> *intel_connector)
> {
> struct drm_device *dev = intel_connector->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -1689,13 +1689,17 @@ void intel_ddi_init(struct drm_device *dev, enum port
> port)
> intel_encoder->cloneable = 0;
> intel_encoder->hot_plug = intel_ddi_hot_plug;
>
> - if (init_dp)
> + if (init_dp) {
> dp_connector = intel_ddi_init_dp_connector(intel_dig_port);
> + dp_connector->get_hw_state = intel_ddi_connector_get_hw_state;
This can segfault.
> + }
>
> /* In theory we don't need the encoder->type check, but leave it just
> in
> * case we have some really bad VBTs... */
> - if (intel_encoder->type != INTEL_OUTPUT_EDP && init_hdmi)
> + if (intel_encoder->type != INTEL_OUTPUT_EDP && init_hdmi) {
> hdmi_connector =
> intel_ddi_init_hdmi_connector(intel_dig_port);
> + hdmi_connector->get_hw_state =
> intel_ddi_connector_get_hw_state;
> + }
>
> if (!dp_connector && !hdmi_connector) {
> drm_encoder_cleanup(encoder);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 5746fe22dde3..ca94be9554f4 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3931,10 +3931,6 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
> intel_connector_attach_encoder(intel_connector, intel_encoder);
> drm_sysfs_connector_add(connector);
>
> - if (HAS_DDI(dev))
> - intel_connector->get_hw_state =
> intel_ddi_connector_get_hw_state;
> - else
> - intel_connector->get_hw_state = intel_connector_get_hw_state;
> intel_connector->unregister = intel_dp_connector_unregister;
>
> /* Set up the hotplug pin. */
> @@ -4043,4 +4039,5 @@ intel_dp_init(struct drm_device *dev, int output_reg,
> enum port port)
> kfree(intel_dig_port);
> kfree(intel_connector);
> }
> + intel_connector->get_hw_state = intel_connector_get_hw_state;
This can also segfault.
> }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index ba727b11014a..1c093e71db7d 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -686,7 +686,6 @@ void intel_ddi_pll_enable(struct intel_crtc *crtc);
> void intel_ddi_put_crtc_pll(struct drm_crtc *crtc);
> void intel_ddi_set_pipe_settings(struct drm_crtc *crtc);
> void intel_ddi_prepare_link_retrain(struct drm_encoder *encoder);
> -bool intel_ddi_connector_get_hw_state(struct intel_connector
> *intel_connector);
> void intel_ddi_fdi_disable(struct drm_crtc *crtc);
> void intel_ddi_get_config(struct intel_encoder *encoder,
> struct intel_crtc_config *pipe_config);
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index ced93bd33f80..b748bb39347c 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1328,10 +1328,6 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> intel_hdmi->set_infoframes = cpt_set_infoframes;
> }
>
> - if (HAS_DDI(dev))
> - intel_connector->get_hw_state =
> intel_ddi_connector_get_hw_state;
> - else
> - intel_connector->get_hw_state = intel_connector_get_hw_state;
> intel_connector->unregister = intel_connector_unregister;
>
> intel_hdmi_add_pro
[Intel-gfx] Screen extremely dim on Dell Latitude D630 after upgrading to Linux kernel-3.14
After upgrading to linux Kernel-3.14, the screen on my Dell Latitude D630 was nearly unreadably dim. When I Boot the 3.13 kernel, my screen is bright. I opened a Bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1094066 and others have chimed in that they have the same problem. I bisected the kernel, and found the following commit is responsible for this problem: b35684b8fa94e04f55fd38bf672b737741d2f9e2 is the first bad commit commit b35684b8fa94e04f55fd38bf672b737741d2f9e2 Author: Jani Nikula mailto:jani.nik...@intel.com>> Date: Thu Nov 14 12:13:41 2013 +0200 drm/i915: do full backlight setup at enable time We should now have all the information we need to do a full initialization of the backlight registers. v2: Keep QUIRK_NO_PCH_PWM_ENABLE for now (Imre). Signed-off-by: Jani Nikula mailto:jani.nik...@intel.com>> Reviewed-by: Imre Deak mailto:imre.d...@intel.com>> Signed-off-by: Daniel Vetter mailto:daniel.vet...@ffwll.ch>> :04 04 0aae5515ca62ff1bfd2e1c2769e30c58b016ffeb 01c2f8cd145f8cf29730908d52e7e89b787a059e M drivers I can find my way around the kernel, but haven't hit this area before. Any help is appreciated. Marc Milgram ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Improve irq handling after gpu resets
Currently we do a full re-init of all interrupts after a gpu hang. Which is pretty bad since we don't restore the interrupts we've enabled at runtime correctly. Even with that addressed it's rather horribly race. But on g4x and later we only reset the gt and not the entire gpu. Which means we only need to reset the GT interrupt bits. Which has the nice benefit that vblank waits, pipe CRC interrupts and everything else display related just keeps on working. The downside is that gt interrupt handling (i.e. ring->get/put_irq) is still racy. But as long as the gpu hang reliably wakes all waters and we have a short time where the refcount drops to 0 we'll recover. So not that bad really. v2: Ville noticed that GTIMR and PMIMR don't get cleared, only the subordinate per-ring registers. So let's rip out all the interrupt dancing. The FIXME comment is still required though since the ring irq handling happens at the per-ring interrupt mask registers, too. Testcase: igt/kms_flip/vblank-vs-hang Testcase: igt/kms_pipe_crc_basic/hang-* Cc: Ville Syrjälä Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_drv.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index c83c83b74bf4..7ae906c811bb 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -811,17 +811,17 @@ int i915_reset(struct drm_device *dev) } /* -* FIXME: This is horribly race against concurrent pageflip and -* vblank wait ioctls since they can observe dev->irqs_disabled -* being false when they shouldn't be able to. +* FIXME: This races pretty badly against concurrent holders of +* ring interrupts. This is possible since we've started to drop +* dev->struct_mutex in select places when waiting for the gpu. */ - drm_irq_uninstall(dev); - drm_irq_install(dev, dev->pdev->irq); - /* rps/rc6 re-init is necessary to restore state lost after the -* reset and the re-install of drm irq. Skip for ironlake per + /* +* rps/rc6 re-init is necessary to restore state lost after the +* reset and the re-install of gt irqs. Skip for ironlake per * previous concerns that it doesn't respond well to some forms -* of re-init after reset. */ +* of re-init after reset. +*/ if (INTEL_INFO(dev)->gen > 5) intel_reset_gt_powersave(dev); -- 1.8.4.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Extract gen8_gt_irq_reset
Fallout from an intermediate patch revision that I deemed worth saving.
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3cd659b47dd2..e73d9ab90070 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3140,6 +3140,14 @@ static void valleyview_irq_preinstall(struct drm_device
*dev)
POSTING_READ(VLV_IER);
}
+static void gen8_gt_irq_reset(struct drm_i915_private *dev_priv)
+{
+ GEN8_IRQ_RESET_NDX(GT, 0);
+ GEN8_IRQ_RESET_NDX(GT, 1);
+ GEN8_IRQ_RESET_NDX(GT, 2);
+ GEN8_IRQ_RESET_NDX(GT, 3);
+}
+
static void gen8_irq_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3148,10 +3156,7 @@ static void gen8_irq_reset(struct drm_device *dev)
I915_WRITE(GEN8_MASTER_IRQ, 0);
POSTING_READ(GEN8_MASTER_IRQ);
- GEN8_IRQ_RESET_NDX(GT, 0);
- GEN8_IRQ_RESET_NDX(GT, 1);
- GEN8_IRQ_RESET_NDX(GT, 2);
- GEN8_IRQ_RESET_NDX(GT, 3);
+ gen8_gt_irq_reset(dev_priv);
for_each_pipe(pipe)
GEN8_IRQ_RESET_NDX(DE_PIPE, pipe);
@@ -3171,10 +3176,7 @@ static void cherryview_irq_preinstall(struct drm_device
*dev)
I915_WRITE(GEN8_MASTER_IRQ, 0);
POSTING_READ(GEN8_MASTER_IRQ);
- GEN8_IRQ_RESET_NDX(GT, 0);
- GEN8_IRQ_RESET_NDX(GT, 1);
- GEN8_IRQ_RESET_NDX(GT, 2);
- GEN8_IRQ_RESET_NDX(GT, 3);
+ gen8_gt_irq_reset(dev_priv);
GEN5_IRQ_RESET(GEN8_PCU_);
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Kill intel_crtc->vbl_wait
On Thu, May 22, 2014 at 08:30:23PM +0100, Chris Wilson wrote:
> On Thu, May 22, 2014 at 06:05:34PM +0200, Daniel Vetter wrote:
> > On Thu, May 22, 2014 at 04:49:03PM +0100, Chris Wilson wrote:
> > > On Thu, May 22, 2014 at 06:39:33PM +0300, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > Share the waitqueue that drm_irq uses when performing the vblank evade
> > > > trick for atomic pipe updates.
> > > >
> > > > Suggested-by: Daniel Vetter
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > drivers/gpu/drm/i915/i915_irq.c | 25 ++---
> > > > drivers/gpu/drm/i915/intel_display.c | 2 --
> > > > drivers/gpu/drm/i915/intel_drv.h | 2 --
> > > > drivers/gpu/drm/i915/intel_sprite.c | 5 +++--
> > > > 4 files changed, 9 insertions(+), 25 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > index 304f86a..5905a9d 100644
> > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > @@ -1724,19 +1724,6 @@ static void gen6_rps_irq_handler(struct
> > > > drm_i915_private *dev_priv, u32 pm_iir)
> > > > }
> > > > }
> > > >
> > > > -static bool intel_pipe_handle_vblank(struct drm_device *dev, enum pipe
> > > > pipe)
> > > > -{
> > > > - struct intel_crtc *crtc;
> > > > -
> > > > - if (!drm_handle_vblank(dev, pipe))
> > > > - return false;
> > > > -
> > > > - crtc = to_intel_crtc(intel_get_crtc_for_pipe(dev, pipe));
> > > > - wake_up(&crtc->vbl_wait);
> > > > -
> > > > - return true;
> > > > -}
> > >
> > > Can we keep this bare wrapper? It is quite useful for hooking in vblank
> > > checks - i.e. saves me having to reinrtoduce it.
> >
> > Just smash them into drm_handle_vblank?
>
> The ones I have in mind the pageflip stall checks and gpu-boost for
> missed pageflips, i.e. driver specific.
Hm yeah, the pageflip stall check should be in the vblank handler. And
yeah boosting harder in the vblank handler if an outstanding pageflip
hasn't been completed yet also makes sense. I'll augment Ville's patch v2
with these reasons and merge that one.
-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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
