[Intel-gfx] [Regression report] Weekly regression report WW49
There was no new regressions this week Previous Regressions: +---+---+++ | BugId | Summary | Created on | Bisect | +---+---+++ | 72782 | [945GM bisected] screen blank on S3 resume on | 2013-12-17 | Yes| | 81537 | [snb dp regression] dp retry forever due to s | 2014-07-19 | No | | 84855 | [ILK regression]igt kms_rotation_crc/sprite-r | 2014-10-10 | No | | 84974 | [VLV eDP-LVDS bisected] powerdomains: Screen | 2014-10-14 | Yes| | 87131 | [PNV regression] igt/gem_exec_lut_handle take | 2014-12-09 | No | | 87480 | [SNB/IVB/HSW/BYT bisected]igt/kms_force_conne | 2014-12-19 | Yes| | 87662 | [ALL 3.18 Bisected] DVI --rotation inverted c | 2014-12-24 | Yes| | 87725 | [BDW Bisected] OglBatch7 performance reduced | 2014-12-26 | Yes| | 87726 | [BDW Bisected] OglDrvCtx performance reduced | 2014-12-26 | Yes| | 88012 | [bisected BYT] complete freeze after: drm/i91 | 2015-01-04 | Yes| | 88124 | i915: regression: after DP connected monitor | 2015-01-06 | No | | 88439 | [BDW Bisected]igt/gem_reloc_vs_gpu/forked-fau | 2015-01-15 | Yes| | 89334 | [945 regression] 4.0-rc1 kernel GPU hang: ec | 2015-02-26 | No | | 89629 | [i965 regression]igt/kms_rotation_crc/sprite- | 2015-03-18 | No | | 89632 | [i965 regression]igt/kms_universal_plane/univ | 2015-03-18 | No | | 89728 | [HSW/BDW/BSW/SKL bisected] igt/pm_rps/ subcas | 2015-03-23 | Yes| | 89872 | [ HSW Bisected ] VGA was white screen when re | 2015-04-02 | Yes| | 90112 | [BSW bisected] OglGSCloth/Lightsmark/CS/ Port | 2015-04-20 | Yes| | 90134 | [BSW Bisected]GFXBench3_gl_driver/GFXBench3_g | 2015-04-22 | Yes| | 90368 | [SNB BSW SKL] bisected igt/kms_3d has hardcod | 2015-05-08 | Yes| | 90732 | [BDW/BSW Bisected]igt/gem_reloc_vs_gpu/forked | 2015-05-29 | Yes| | 90808 | [BDW Bisected]igt/gem_ctx_param_basic/invalid | 2015-06-02 | Yes| | 90994 | [BDW regression] pm_rpm subtests fail and giv | 2015-06-16 | No | | 91378 | [hsw dp regression] 06ea66b6 (5.4GHz link clo | 2015-07-17 | No | | 91592 | [pnv regression] OOPS on boot | 2015-08-09 | No | | 91844 | [HSW Regression] intel_do_flush_locked failed | 2015-09-02 | No | | 91952 | [Bisected Regression] Blank screen from boot | 2015-09-10 | Yes| | 91959 | [865g 3.19 regression] Desktop image is disto | 2015-09-10 | No | | 91974 | [bisected] unrecoverable black screen after k | 2015-09-11 | Yes| | 92050 | [regression]/bug introduced by commit [0e572f | 2015-09-19 | No | | 92083 | [regression] [git pull] drm for 4.3 | 2015-09-23 | No | | 92096 | regression/bug introduced by commit [0e572fe7 | 2015-09-24 | No | | 92174 | PROBLEM: Intel VGA output busticated on 4.3-r | 2015-09-29 | No | | 92237 | Horrible noise (audio) via DisplayPort [regre | 2015-10-02 | No | | 92324 | [Intel-gfx] [PATCH] fixup! drm/i915/skl: Elim | 2015-10-07 | Yes| | 92355 | [SKL Regression] igt/kms_fbc_crc cause DUT cr | 2015-10-09 | No | | 92414 | [Intel-gfx] As of kernel 4.3-rc1 system will | 2015-10-10 | Yes| | 92502 | [SKL] [Regression] igt/kms_flip/2x-flip-vs-ex | 2015-10-16 | No | | 92575 | [4.2 regression] Massive graphics corruption | 2015-10-21 | No | | 92655 | [i915] LVDS screen half garbled. unable to bi | 2015-10-23 | Yes| | 92718 | [REGRESSION] 4.3.0-rc7 - Multiple identical k | 2015-10-29 | No | | 92972 | Black screen on Intel NUC hardware (i915) pos | 2015-11-16 | No | | 93120 | [SNB BAT IGT regression] WARN_ON(was_visible) | 2015-11-26 | No | | 93122 | [SNB BAT IGT regression] pm_rpm started skipp | 2015-11-26 | No | +---+---+++ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] igt/pm_rps: Add checks for freq = idle (RPn) in specific cases.
On Fri, 4 Dec 2015 22:58:50 +0200
Imre Deak wrote:
> On Fri, 2015-12-04 at 10:37 -0800, Bob Paauwe wrote:
> > On Fri, 4 Dec 2015 17:22:11 +0200
> > Imre Deak wrote:
> > [...]
> > > > With the BIOS setting corrected, the driver started disabling the
> > > > down
> > > > interrupts once the freq dropped to min or just below because of
> > > > the min
> > > > vs. idle difference. I have a patch for this that I'll send
> > > > shortly.
> > >
> > > Hm, that's not necessarily a problem. To reach the idle frequency
> > > we
> > > don't depend on the up/down interrupts. The idle frequency gets set
> > > explicitly from intel_mark_idle(), so if you don't reach the idle
> > > freq
> > > then this function doesn't get called for some reason. Or as I said
> > > earlier we just don't wait enough in do_load_gpu() or idle_check()
> > > in
> > > the test, so we read out cur-freq before intel_mark_idle() would
> > > get
> > > called.
> >
> > Maybe because I'm just testing from a console environment, but if I
> > change the min freq. via sysfs I don't get any type of call to drop
> > back to idle. Possibly because I'm not generating any GPU load so it
> > never re-triggers an idle gpu? I've waited quite a while and have
> > bumped up the time in idle_check(). Waiting for minutes doesn't seem
> > reasonable.
> >
> > Should intel_mark_idle() get called periodically, even if the rings
> > are
> > empty?
> >
> > >
> > > > The remaining issue seems to be some type of timing issue. I've
> > > > had
> > > > to
> > > > add a 35000us sleep between updating the interrupt enable
> > > > register
> > > > (0xA168) and the posting read of freq. register (0xA008),
> > > > otherwise
> > > > it
> > > > acts like the change to the interrupt enable register never
> > > > happened.
> > > > None of the documentation I have indicates that this is needed.
> > >
> > > What happens exactly? The frequency gets stuck above min-freq and
> > > you
> > > never get a down interrupt? Not sure how this could happen, but
> > > there
> > > is an interesting comment in intel_rps_limits() about this
> > > scenario.
> >
> > Basically if I set the min freq. through sysfs, it flows through all
> > the set threshold, create the interrupt mask code but the system
> > behaves as if the new threshold limits or interrupts were not
> > changed.
> >
> > So say RPn = 100, min = 100, current = 100
> > - echo 383 > /sys/class/drm/card0/gt_min_freq_mhz (midpoint freq)
> >
> > gt_cur_freq_mhz will report 383 now and I don't see any interrupts.
> >
> > If I add the delay, then right after I set the min to 383, I'll start
> > seeing the down threshold interrupts and it will lower the freq back
> > down to RPn (100) after two or three interrupts occur.
> >
> > So I don't think this has anything to with RC6 and missing
> > interrupts that the comment refers to.
> >
> > It took me a while to track this down because I was using a bunch of
> > printk's to trace the flow and values. With the printk's it was
> > working but when I removed them, it stopped working. So it was about
> > 3
> > or 4 printk's worth of delay that was needed. But I really wonder if
> > there's something else that should be checked vs. just delaying.
>
> Ok, so for both of the above observations: If you write the min-freq
> value via sysfs, it will result in cur-freq raised and "getting stuck"
> at min-freq if cur-freq was below the new min value. This is a bit
> strange since as we already established normally cur-freq should always
> drop to idle-freq if the GPU is idle regardless of min-freq. AFAIR the
> sysfs entry works in this way, since setting the frequency also changes
> the interrupt mask and what we really need is this latter thing. To get
> back to the normal drop-to-idle-freq policy again you need to submit
> some GPU work after setting the sysfs entry.
So we want the policy to be that we'll only drop below min to idle when
the GPU transitions from not idle to idle. Without that transition,
we'll stay at the user specified min.
> It's done already in most
> of the places in pm_rps, except for few. The following should fix up
> those:
>
> diff --git a/tests/pm_rps.c b/tests/pm_rps.c
> index 74f08f4..ad06ef0 100644
> --- a/tests/pm_rps.c
> +++ b/tests/pm_rps.c
> @@ -388,10 +388,14 @@ static void min_max_config(void (*check)(void),
> bool load_gpu)
>
> igt_debug("\nIncrease min to midpoint...\n");
> writeval(stuff[MIN].filp, fmid);
> + if (load_gpu)
> + do_load_gpu();
> check();
>
> igt_debug("\nIncrease min to RP0...\n");
> writeval(stuff[MIN].filp, origfreqs[RP0]);
> + if (load_gpu)
> + do_load_gpu();
> check();
>
> igt_debug("\nIncrease min above RP0 (invalid)...\n");
> @@ -416,6 +420,8 @@ static void min_max_config(void (*check)(void),
> bool load_gpu)
>
> igt_debug("\nDecrease min below RPn (invalid)...\n");
> writeval_inval(stuff[MIN].filp, 0);
> + if (load_gpu)
> +
Re: [Intel-gfx] [PATCH 2/2] igt/pm_rps: Add checks for freq = idle (RPn) in specific cases.
On Fri, 2015-12-04 at 10:37 -0800, Bob Paauwe wrote:
> On Fri, 4 Dec 2015 17:22:11 +0200
> Imre Deak wrote:
> [...]
> > > With the BIOS setting corrected, the driver started disabling the
> > > down
> > > interrupts once the freq dropped to min or just below because of
> > > the min
> > > vs. idle difference. I have a patch for this that I'll send
> > > shortly.
> >
> > Hm, that's not necessarily a problem. To reach the idle frequency
> > we
> > don't depend on the up/down interrupts. The idle frequency gets set
> > explicitly from intel_mark_idle(), so if you don't reach the idle
> > freq
> > then this function doesn't get called for some reason. Or as I said
> > earlier we just don't wait enough in do_load_gpu() or idle_check()
> > in
> > the test, so we read out cur-freq before intel_mark_idle() would
> > get
> > called.
>
> Maybe because I'm just testing from a console environment, but if I
> change the min freq. via sysfs I don't get any type of call to drop
> back to idle. Possibly because I'm not generating any GPU load so it
> never re-triggers an idle gpu? I've waited quite a while and have
> bumped up the time in idle_check(). Waiting for minutes doesn't seem
> reasonable.
>
> Should intel_mark_idle() get called periodically, even if the rings
> are
> empty?
>
> >
> > > The remaining issue seems to be some type of timing issue. I've
> > > had
> > > to
> > > add a 35000us sleep between updating the interrupt enable
> > > register
> > > (0xA168) and the posting read of freq. register (0xA008),
> > > otherwise
> > > it
> > > acts like the change to the interrupt enable register never
> > > happened.
> > > None of the documentation I have indicates that this is needed.
> >
> > What happens exactly? The frequency gets stuck above min-freq and
> > you
> > never get a down interrupt? Not sure how this could happen, but
> > there
> > is an interesting comment in intel_rps_limits() about this
> > scenario.
>
> Basically if I set the min freq. through sysfs, it flows through all
> the set threshold, create the interrupt mask code but the system
> behaves as if the new threshold limits or interrupts were not
> changed.
>
> So say RPn = 100, min = 100, current = 100
> - echo 383 > /sys/class/drm/card0/gt_min_freq_mhz (midpoint freq)
>
> gt_cur_freq_mhz will report 383 now and I don't see any interrupts.
>
> If I add the delay, then right after I set the min to 383, I'll start
> seeing the down threshold interrupts and it will lower the freq back
> down to RPn (100) after two or three interrupts occur.
>
> So I don't think this has anything to with RC6 and missing
> interrupts that the comment refers to.
>
> It took me a while to track this down because I was using a bunch of
> printk's to trace the flow and values. With the printk's it was
> working but when I removed them, it stopped working. So it was about
> 3
> or 4 printk's worth of delay that was needed. But I really wonder if
> there's something else that should be checked vs. just delaying.
Ok, so for both of the above observations: If you write the min-freq
value via sysfs, it will result in cur-freq raised and "getting stuck"
at min-freq if cur-freq was below the new min value. This is a bit
strange since as we already established normally cur-freq should always
drop to idle-freq if the GPU is idle regardless of min-freq. AFAIR the
sysfs entry works in this way, since setting the frequency also changes
the interrupt mask and what we really need is this latter thing. To get
back to the normal drop-to-idle-freq policy again you need to submit
some GPU work after setting the sysfs entry. It's done already in most
of the places in pm_rps, except for few. The following should fix up
those:
diff --git a/tests/pm_rps.c b/tests/pm_rps.c
index 74f08f4..ad06ef0 100644
--- a/tests/pm_rps.c
+++ b/tests/pm_rps.c
@@ -388,10 +388,14 @@ static void min_max_config(void (*check)(void),
bool load_gpu)
igt_debug("\nIncrease min to midpoint...\n");
writeval(stuff[MIN].filp, fmid);
+ if (load_gpu)
+ do_load_gpu();
check();
igt_debug("\nIncrease min to RP0...\n");
writeval(stuff[MIN].filp, origfreqs[RP0]);
+ if (load_gpu)
+ do_load_gpu();
check();
igt_debug("\nIncrease min above RP0 (invalid)...\n");
@@ -416,6 +420,8 @@ static void min_max_config(void (*check)(void),
bool load_gpu)
igt_debug("\nDecrease min below RPn (invalid)...\n");
writeval_inval(stuff[MIN].filp, 0);
+ if (load_gpu)
+ do_load_gpu();
check();
igt_debug("\nDecrease max to midpoint...\n");
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 10/10] drm/i915: Leave FDI running after failed link training on LPT-H
From: Ville Syrjälä
Currently we disable some parts of FDI setup after a failed link
training. But despite that we continue with the modeset as if everything
is fine. This results in tons of noise from the state checker, and
it means we're not following the proper modeset sequence for the rest of
crtc enabling, nor for crtc disabling.
Ideally we should abort the modeset and follow the proper disable
sequence to shut off everything we enabled so far, but that would
require a big rework of the modeset code. So instead just leave FDI
up and running in its untrained state, and log an error. This is
what we do on older platforms too.
v2: Fix a typo in the commit message
Signed-off-by: Ville Syrjälä
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 7f618cf5289c..5d20c64d8566 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -675,15 +675,16 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
temp = I915_READ(DP_TP_STATUS(PORT_E));
if (temp & DP_TP_STATUS_AUTOTRAIN_DONE) {
DRM_DEBUG_KMS("FDI link training done on step %d\n", i);
+ break;
+ }
- /* Enable normal pixel sending for FDI */
- I915_WRITE(DP_TP_CTL(PORT_E),
- DP_TP_CTL_FDI_AUTOTRAIN |
- DP_TP_CTL_LINK_TRAIN_NORMAL |
- DP_TP_CTL_ENHANCED_FRAME_ENABLE |
- DP_TP_CTL_ENABLE);
-
- return;
+ /*
+* Leave things enabled even if we failed to train FDI.
+* Results in less fireworks from the state checker.
+*/
+ if (i == ARRAY_SIZE(hsw_ddi_translations_fdi) * 2 - 1) {
+ DRM_ERROR("FDI link training failed!\n");
+ break;
}
temp = I915_READ(DDI_BUF_CTL(PORT_E));
@@ -712,7 +713,12 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
POSTING_READ(FDI_RX_MISC(PIPE_A));
}
- DRM_ERROR("FDI link training failed!\n");
+ /* Enable normal pixel sending for FDI */
+ I915_WRITE(DP_TP_CTL(PORT_E),
+ DP_TP_CTL_FDI_AUTOTRAIN |
+ DP_TP_CTL_LINK_TRAIN_NORMAL |
+ DP_TP_CTL_ENHANCED_FRAME_ENABLE |
+ DP_TP_CTL_ENABLE);
}
void intel_ddi_init_dp_buf_reg(struct intel_encoder *encoder)
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 09/10] drm/i915: Disable LPT-H VGA dotclock during crtc disable
From: Ville Syrjälä
Currently we leave the LPT-H VGA dotclock running after turning
the pipe/fdi/port/etc. Properly disable the VGA dotclock as
specified in the modeset sequence.
v2: Fix commit message typo (Paulo)
Signed-off-by: Ville Syrjälä
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a92753c1ffe3..796378352125 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5178,6 +5178,7 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
if (intel_crtc->config->has_pch_encoder) {
lpt_disable_pch_transcoder(dev_priv);
+ lpt_disable_iclkip(dev_priv);
intel_ddi_fdi_disable(crtc);
intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 08/10] drm/i915: Refactor LPT-H VGA dotclock disabling
From: Ville Syrjälä
Extract the LPT-H VGA dotclock disable to a separate function in
anticipation of further use.
While at it move the sb_lock locking inwards when enabling the VGA
dotclock, as it's only needed to protect the sideband accesses.
v2: Keep the PIXCLK_GATE_GATE name for 0 (Paulo)
Signed-off-by: Ville Syrjälä
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 42ed799390e5..a92753c1ffe3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3940,6 +3940,21 @@ static int intel_crtc_wait_for_pending_flips(struct
drm_crtc *crtc)
return 0;
}
+static void lpt_disable_iclkip(struct drm_i915_private *dev_priv)
+{
+ u32 temp;
+
+ I915_WRITE(PIXCLK_GATE, PIXCLK_GATE_GATE);
+
+ mutex_lock(&dev_priv->sb_lock);
+
+ temp = intel_sbi_read(dev_priv, SBI_SSCCTL6, SBI_ICLK);
+ temp |= SBI_SSCCTL_DISABLE;
+ intel_sbi_write(dev_priv, SBI_SSCCTL6, temp, SBI_ICLK);
+
+ mutex_unlock(&dev_priv->sb_lock);
+}
+
/* Program iCLKIP clock to the desired frequency */
static void lpt_program_iclkip(struct drm_crtc *crtc)
{
@@ -3949,18 +3964,7 @@ static void lpt_program_iclkip(struct drm_crtc *crtc)
u32 divsel, phaseinc, auxdiv, phasedir = 0;
u32 temp;
- mutex_lock(&dev_priv->sb_lock);
-
- /* It is necessary to ungate the pixclk gate prior to programming
-* the divisors, and gate it back when it is done.
-*/
- I915_WRITE(PIXCLK_GATE, PIXCLK_GATE_GATE);
-
- /* Disable SSCCTL */
- intel_sbi_write(dev_priv, SBI_SSCCTL6,
- intel_sbi_read(dev_priv, SBI_SSCCTL6, SBI_ICLK) |
- SBI_SSCCTL_DISABLE,
- SBI_ICLK);
+ lpt_disable_iclkip(dev_priv);
/* 20MHz is a corner case which is out of range for the 7-bit divisor */
if (clock == 2) {
@@ -4000,6 +4004,8 @@ static void lpt_program_iclkip(struct drm_crtc *crtc)
phasedir,
phaseinc);
+ mutex_lock(&dev_priv->sb_lock);
+
/* Program SSCDIVINTPHASE6 */
temp = intel_sbi_read(dev_priv, SBI_SSCDIVINTPHASE6, SBI_ICLK);
temp &= ~SBI_SSCDIVINTPHASE_DIVSEL_MASK;
@@ -4021,12 +4027,12 @@ static void lpt_program_iclkip(struct drm_crtc *crtc)
temp &= ~SBI_SSCCTL_DISABLE;
intel_sbi_write(dev_priv, SBI_SSCCTL6, temp, SBI_ICLK);
+ mutex_unlock(&dev_priv->sb_lock);
+
/* Wait for initialization time */
udelay(24);
I915_WRITE(PIXCLK_GATE, PIXCLK_GATE_UNGATE);
-
- mutex_unlock(&dev_priv->sb_lock);
}
static void ironlake_pch_transcoder_set_timings(struct intel_crtc *crtc,
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 07/10] drm/i915: Disable FDI after the CRT port on LPT-H
From: Ville Syrjälä
Bspec modeset sequence tells us to disable the PCH transcoder and
FDI after the CRT port on LPT-H, so let's do that. And the CRT port
should be disabled after the pipe, as we do on other PCH platforms
too since
commit 1ea56e269e13 ("drm/i915: Disable CRT port after pipe on PCH platforms")
commit 00490c22b1b5 ("drm/i915: Consider SPLL as another shared pll, v2.")
moved the SPLL disaable from the .post_disable() hook to some upper
laeve code, so we can just move the CRT port disabling into the
.post_disable() hook. If we still had the non-shared SPLL, it would have
needed to be moved into the .post_pll_disable() hook.
v2: Actually move the CRT port disable to the .post_disable() hook,
and amend the commit message with more details (Paulo)
Cc: Paulo Zanoni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_crt.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 11 +--
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 12008af797bd..cef359958c73 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -844,7 +844,7 @@ void intel_crt_init(struct drm_device *dev)
crt->adpa_reg = adpa_reg;
crt->base.compute_config = intel_crt_compute_config;
- if (HAS_PCH_SPLIT(dev) && !HAS_DDI(dev)) {
+ if (HAS_PCH_SPLIT(dev)) {
crt->base.disable = pch_disable_crt;
crt->base.post_disable = pch_post_disable_crt;
} else {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3391ab0ca752..42ed799390e5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5166,18 +5166,17 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
if (!intel_crtc->config->has_dsi_encoder)
intel_ddi_disable_pipe_clock(intel_crtc);
- if (intel_crtc->config->has_pch_encoder) {
- lpt_disable_pch_transcoder(dev_priv);
- intel_ddi_fdi_disable(crtc);
- }
-
for_each_encoder_on_crtc(dev, crtc, encoder)
if (encoder->post_disable)
encoder->post_disable(encoder);
- if (intel_crtc->config->has_pch_encoder)
+ if (intel_crtc->config->has_pch_encoder) {
+ lpt_disable_pch_transcoder(dev_priv);
+ intel_ddi_fdi_disable(crtc);
+
intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
true);
+ }
intel_fbc_disable_crtc(intel_crtc);
}
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 06/10] drm/i915: Round to closest when computing the VGA dotclock for LPT-H
From: Ville Syrjälä Bspec says we should round to closest when computing the LPT-H VGA dotclock, so let's do that. v2: Fix typo in commit message (Paulo) Signed-off-by: Ville Syrjälä Reviewed-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 3811bcb73229..3391ab0ca752 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3978,7 +3978,7 @@ static void lpt_program_iclkip(struct drm_crtc *crtc) u32 iclk_pi_range = 64; u32 desired_divisor, msb_divisor_value, pi_value; - desired_divisor = (iclk_virtual_root_freq / clock); + desired_divisor = DIV_ROUND_CLOSEST(iclk_virtual_root_freq, clock); msb_divisor_value = desired_divisor / iclk_pi_range; pi_value = desired_divisor % iclk_pi_range; -- 2.4.10 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 05/10] drm/i915: Disable CLKOUT_DP bending on LPT/WPT as needed
From: Ville Syrjälä
When we want to use SPLL for FDI we want SSC, which means we have to
disable clock bending for the PCH SSC reference (bend and spread are
mutually exclusive). So let's turn off bending when we want spread.
In case the BIOS enabled clock bending for some reason we'll just turn
it off and enable the spread mode instead.
Not sure what happens if the BIOS is actually using the bend source for
HDMI at this time, but I suppose it should be no worse than what already
happens when we simply turn on the spread.
We don't currently use the bend source for anything, and only use the
PCH SSC reference for the SPLL to drive FDI (always with spread).
v2: Fix the %5 vs %10 fumble for SSCDITHPHASE (Paulo)
Add 'WARN_ON(steps % 5 != 0)' sanity check (Paulo)
Fix typos in commit message (Paulo)
Cc: Paulo Zanoni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 67 ++--
2 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1dae5ac3e0b1..d0ea877011c1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7327,6 +7327,7 @@ enum skl_disp_power_wells {
#define SBI_READY (0x0<<0)
/* SBI offsets */
+#define SBI_SSCDIVINTPHASE0x0200
#define SBI_SSCDIVINTPHASE6 0x0600
#define SBI_SSCDIVINTPHASE_DIVSEL_MASK ((0x7f)<<1)
#define SBI_SSCDIVINTPHASE_DIVSEL(x) ((x)<<1)
@@ -7334,6 +7335,7 @@ enum skl_disp_power_wells {
#define SBI_SSCDIVINTPHASE_INCVAL(x) ((x)<<8)
#define SBI_SSCDIVINTPHASE_DIR(x)((x)<<15)
#define SBI_SSCDIVINTPHASE_PROPAGATE (1<<0)
+#define SBI_SSCDITHPHASE 0x0204
#define SBI_SSCCTL0x020c
#define SBI_SSCCTL6 0x060C
#define SBI_SSCCTL_PATHALT (1<<3)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 61000ff524f1..3811bcb73229 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8564,6 +8564,67 @@ static void lpt_disable_clkout_dp(struct drm_device *dev)
mutex_unlock(&dev_priv->sb_lock);
}
+#define BEND_IDX(steps) ((50 + (steps)) / 5)
+
+static const uint16_t sscdivintphase[] = {
+ [BEND_IDX( 50)] = 0x3B23,
+ [BEND_IDX( 45)] = 0x3B23,
+ [BEND_IDX( 40)] = 0x3C23,
+ [BEND_IDX( 35)] = 0x3C23,
+ [BEND_IDX( 30)] = 0x3D23,
+ [BEND_IDX( 25)] = 0x3D23,
+ [BEND_IDX( 20)] = 0x3E23,
+ [BEND_IDX( 15)] = 0x3E23,
+ [BEND_IDX( 10)] = 0x3F23,
+ [BEND_IDX( 5)] = 0x3F23,
+ [BEND_IDX( 0)] = 0x0025,
+ [BEND_IDX( -5)] = 0x0025,
+ [BEND_IDX(-10)] = 0x0125,
+ [BEND_IDX(-15)] = 0x0125,
+ [BEND_IDX(-20)] = 0x0225,
+ [BEND_IDX(-25)] = 0x0225,
+ [BEND_IDX(-30)] = 0x0325,
+ [BEND_IDX(-35)] = 0x0325,
+ [BEND_IDX(-40)] = 0x0425,
+ [BEND_IDX(-45)] = 0x0425,
+ [BEND_IDX(-50)] = 0x0525,
+};
+
+/*
+ * Bend CLKOUT_DP
+ * steps -50 to 50 inclusive, in steps of 5
+ * < 0 slow down the clock, > 0 speed up the clock, 0 == no bend (135MHz)
+ * change in clock period = -(steps / 10) * 5.787 ps
+ */
+static void lpt_bend_clkout_dp(struct drm_i915_private *dev_priv, int steps)
+{
+ uint32_t tmp;
+ int idx = BEND_IDX(steps);
+
+ if (WARN_ON(steps % 5 != 0))
+ return;
+
+ if (WARN_ON(idx >= ARRAY_SIZE(sscdivintphase)))
+ return;
+
+ mutex_lock(&dev_priv->sb_lock);
+
+ if (steps % 10 != 0)
+ tmp = 0xAAAB;
+ else
+ tmp = 0x;
+ intel_sbi_write(dev_priv, SBI_SSCDITHPHASE, tmp, SBI_ICLK);
+
+ tmp = intel_sbi_read(dev_priv, SBI_SSCDIVINTPHASE, SBI_ICLK);
+ tmp &= 0x;
+ tmp |= sscdivintphase[idx];
+ intel_sbi_write(dev_priv, SBI_SSCDIVINTPHASE, tmp, SBI_ICLK);
+
+ mutex_unlock(&dev_priv->sb_lock);
+}
+
+#undef BEND_IDX
+
static void lpt_init_pch_refclk(struct drm_device *dev)
{
struct intel_encoder *encoder;
@@ -8579,10 +8640,12 @@ static void lpt_init_pch_refclk(struct drm_device *dev)
}
}
- if (has_vga)
+ if (has_vga) {
+ lpt_bend_clkout_dp(to_i915(dev), 0);
lpt_enable_clkout_dp(dev, true, true);
- else
+ } else {
lpt_disable_clkout_dp(dev);
+ }
}
/*
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: Add SKL GT4 PCI IDs
On Fri, Dec 04, 2015 at 07:00:36PM +, Damien Lespiau wrote: > On Fri, Nov 06, 2015 at 02:11:16PM +0200, Mika Kuoppala wrote: > > From: Mika Kuoppala > > > > Add Skylake Intel Graphics GT4 PCI IDs > > > > v2: Rebase > > > > Signed-off-by: Mika Kuoppala > > --- > > Reviewed-by: Damien Lespiau And picked up for dinq. Thanks! I do wonder if it's a canditate for stable though. user land drivers will lag behind... -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: Add SKL GT4 PCI IDs
On Fri, Nov 06, 2015 at 02:11:16PM +0200, Mika Kuoppala wrote:
> From: Mika Kuoppala
>
> Add Skylake Intel Graphics GT4 PCI IDs
>
> v2: Rebase
>
> Signed-off-by: Mika Kuoppala
> ---
Reviewed-by: Damien Lespiau
> drivers/gpu/drm/i915/i915_drv.c | 1 +
> include/drm/i915_pciids.h | 13 ++---
> 2 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9f55209..59810b6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -465,6 +465,7 @@ static const struct pci_device_id pciidlist[] = {
> INTEL_SKL_GT1_IDS(&intel_skylake_info),
> INTEL_SKL_GT2_IDS(&intel_skylake_info),
> INTEL_SKL_GT3_IDS(&intel_skylake_gt3_info),
> + INTEL_SKL_GT4_IDS(&intel_skylake_gt3_info),
> INTEL_BXT_IDS(&intel_broxton_info),
> INTEL_KBL_GT1_IDS(&intel_kabylake_info),
> INTEL_KBL_GT2_IDS(&intel_kabylake_info),
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index f1a113e..f970209 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -279,12 +279,19 @@
> #define INTEL_SKL_GT3_IDS(info) \
> INTEL_VGA_DEVICE(0x1926, info), /* ULT GT3 */ \
> INTEL_VGA_DEVICE(0x192B, info), /* Halo GT3 */ \
> - INTEL_VGA_DEVICE(0x192A, info) /* SRV GT3 */ \
> + INTEL_VGA_DEVICE(0x192A, info) /* SRV GT3 */
>
> -#define INTEL_SKL_IDS(info) \
> +#define INTEL_SKL_GT4_IDS(info) \
> + INTEL_VGA_DEVICE(0x1932, info), /* DT GT4 */ \
> + INTEL_VGA_DEVICE(0x193B, info), /* Halo GT4 */ \
> + INTEL_VGA_DEVICE(0x193D, info), /* WKS GT4 */ \
> + INTEL_VGA_DEVICE(0x193A, info) /* SRV GT4 */
> +
> +#define INTEL_SKL_IDS(info) \
> INTEL_SKL_GT1_IDS(info), \
> INTEL_SKL_GT2_IDS(info), \
> - INTEL_SKL_GT3_IDS(info)
> + INTEL_SKL_GT3_IDS(info), \
> + INTEL_SKL_GT4_IDS(info)
>
> #define INTEL_BXT_IDS(info) \
> INTEL_VGA_DEVICE(0x0A84, info), \
> --
> 2.5.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] igt/pm_rps: Add checks for freq = idle (RPn) in specific cases.
On Fri, 4 Dec 2015 17:22:11 +0200 Imre Deak wrote: > On to, 2015-12-03 at 16:43 -0800, Bob Paauwe wrote: > > On Tue, 1 Dec 2015 19:43:05 +0200 > > Imre Deak wrote: > > > > > On ti, 2015-12-01 at 09:22 -0800, Bob Paauwe wrote: > > > > On Tue, 1 Dec 2015 15:56:55 +0200 > > > > Imre Deak wrote: > > > > > > > > > On ma, 2015-11-30 at 16:23 -0800, Bob Paauwe wrote: > > > > > > Now that the frequency can drop below the user specified > > > > > > minimum > > > > > > when > > > > > > the gpu is idle, add some checking to verify that it really > > > > > > does > > > > > > drop > > > > > > down to the RPn frequency in specific cases. > > > > > > > > > > > > To do this, modify the main test flow to take two 'check' > > > > > > routines > > > > > > instead of one. When running the config-min-max-idle subtest > > > > > > make > > > > > > use of the second check routine to verify that the frequency > > > > > > drops > > > > > > to RPn instead of simply <= user min frequency. For all > > > > > > other > > > > > > subtests, use the original check routines for both checks. > > > > > > > > > > > > Signed-off-by: Bob Paauwe > > > > > > > > > > I don't see the point. The frequency should always drop to the > > > > > idle > > > > > frequency if the GPU is idle, it's not enough that it's below > > > > > MIN- > > > > > freq. > > > > > So why do we need separate CUR-freq<=MIN-freq and CUR- > > > > > freq==idle- > > > > > freq > > > > > checks? > > > > > > > > I started from the premise that it should always drop to idle but > > > > that's just not the case. > > > > > > It is the correct premise and if it doesn't hold then there is a > > > real > > > bug either in the testcase or the kernel which needs to be > > > addressed > > > differently. I haven't found anything concrete but one suspect is > > > the > > > logic that waits for the GPU idle condition, maybe the timeout > > > value idle_check() or the hard-coded duration in do_load_gpu() is > > > incorrect. In any case let's not paper over this issue, the very > > > reason > > > we have test cases is to uncover such bugs. > > > > > > > The min_max_config() function is used for > > > > both the idle and loaded subtests. If you try to check for > > > > freq=idle > > > > when doing the loaded subtest it will fail since it never goes > > > > idle. > > > > Even in the idle subtest there are cases where it doesn't drop > > > > down > > > > to > > > > idle. > > > > > > The only place we should check for freq==idle is in idle_check() > > > and > > > that one is not called during the loaded subtest, it wouldn't even > > > make > > > sense to do so. So I'm not sure how this subtest fails for you. > > > > > > > I suppose I could duplicate min_max_config and have a > > > > min_max_config_idle() and min_max_conifg_not_idle() for use by > > > > the > > > > different subtests. > > > > > > The point of the "check" argument of min_max_config() is to > > > distinguish > > > between the idle and loaded cases. The check functions passed in > > > know > > > already if they can expect the frequency to reach the idle > > > frequency > > > or not. > > > > > > > The real problem is that the test was not designed to handle the > > > > case > > > > where the freq could drop below min and probably needs to be > > > > re-designed. I've been trying to find a quick fix vs. a complete > > > > overhaul as this isn't really a priority for me. > > > > > > I think we only need your first patch and if there is any failure > > > after > > > that we have to root cause that and fix it properly. > > > > > > --Imre > > > > You're right. I'm working with BXT and it seems like it's got some > > unique issues with RPS. I just sent a new patch based on the first > > one > > but with the changes you suggested to check for ==idle instead of > > <=min. > > > > Maybe you have some insights into what I'm seeing with BXT? The first > > problem I had was that I would see threshold up interrupts but not any > > threshold down interrupts. The missing down interrupts was related to > > the BIOS setting. I had runtime PM disabled so it seems strange that I > > was getting the up interrupts. > > Yes, I saw this too. I wonder if we could check this somehow and not > enable RPS if BIOS hasn't set things up properly. Sagar has a patch > that checks the RC6 setup [1]; that's not exactly RPS, but since they > are setup at the same place I think we could use that for now for RPS > too. I'll take a look at that patch and see if I can do something like that for RPS. Thanks. > > > With the BIOS setting corrected, the driver started disabling the down > > interrupts once the freq dropped to min or just below because of the min > > vs. idle difference. I have a patch for this that I'll send shortly. > > Hm, that's not necessarily a problem. To reach the idle frequency we > don't depend on the up/down interrupts. The idle frequency gets set > explicitly from intel_mark_idle(), so if you don't reach the idle
[Intel-gfx] [PATCH i-g-t v2 2/2] tests/kms_force_connector_basic: Add prune-stale-modes subtest
From: Ville Syrjälä
Add a new subtest that makes sure old stale modes get pruned from the
connector's mode list when the EDID changes.
v2: s/drmModeGetConnector/drmModeGetConnectorCurrent/ since
kmstest_force_edid() already takes care of doing the heavier
call for us (Daniel)
Signed-off-by: Ville Syrjälä
---
lib/igt_kms.c | 40 +++
lib/igt_kms.h | 1 +
tests/kms_force_connector_basic.c | 40 +++
3 files changed, 81 insertions(+)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index da49f5676641..5d5a95c20106 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -111,6 +111,46 @@ const unsigned char* igt_kms_get_base_edid(void)
return base_edid;
}
+#define VFREQ 60
+#define CLOCK 101000
+#define HACTIVE 1400
+#define HBLANK 160
+#define VACTIVE 1050
+#define VBLANK 30
+#define HOFFSET 48
+#define HPULSE 32
+#define VOFFSET 3
+#define VPULSE 4
+
+#define HSIZE 52
+#define VSIZE 30
+
+#define EDID_NAME alt_edid
+#include "igt_edid_template.h"
+
+/**
+ * igt_kms_get_alt_edid:
+ *
+ * Get an alternate edid block, which includes the following modes:
+ *
+ * - 1400x1050 60Hz
+ * - 1920x1080 60Hz
+ * - 1280x720 60Hz
+ * - 1024x768 60Hz
+ * - 800x600 60Hz
+ * - 640x480 60Hz
+ *
+ * This can be extended with further features using functions such as
+ * #kmstest_edid_add_3d.
+ *
+ * Returns: an alternate edid block
+ */
+const unsigned char* igt_kms_get_alt_edid(void)
+{
+ update_edid_csum(alt_edid);
+
+ return alt_edid;
+}
/**
* SECTION:igt_kms
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 965c47c1c7f4..94f315fe13e2 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -286,6 +286,7 @@ void igt_reset_connectors(void);
#define EDID_LENGTH 128
const unsigned char* igt_kms_get_base_edid(void);
+const unsigned char* igt_kms_get_alt_edid(void);
#endif /* __IGT_KMS_H__ */
diff --git a/tests/kms_force_connector_basic.c
b/tests/kms_force_connector_basic.c
index 637f625a852f..bd80caeffd82 100644
--- a/tests/kms_force_connector_basic.c
+++ b/tests/kms_force_connector_basic.c
@@ -178,6 +178,46 @@ int main(int argc, char **argv)
}
+ igt_subtest("prune-stale-modes") {
+ int i;
+
+ kmstest_force_connector(drm_fd, vga_connector,
+ FORCE_CONNECTOR_ON);
+
+ /* test pruning of stale modes */
+ kmstest_force_edid(drm_fd, vga_connector,
+ igt_kms_get_alt_edid(), EDID_LENGTH);
+ temp = drmModeGetConnectorCurrent(drm_fd,
+ vga_connector->connector_id);
+
+ for (i = 0; i < temp->count_modes; i++) {
+ if (temp->modes[i].hdisplay == 1400 &&
+ temp->modes[i].vdisplay == 1050)
+ break;
+ }
+ igt_assert_f(i != temp->count_modes, "1400x1050 not on mode
list\n");
+
+ drmModeFreeConnector(temp);
+
+ kmstest_force_edid(drm_fd, vga_connector,
+ igt_kms_get_base_edid(), EDID_LENGTH);
+ temp = drmModeGetConnectorCurrent(drm_fd,
+ vga_connector->connector_id);
+
+ for (i = 0; i < temp->count_modes; i++) {
+ if (temp->modes[i].hdisplay == 1400 &&
+ temp->modes[i].vdisplay == 1050)
+ break;
+ }
+ igt_assert_f(i == temp->count_modes, "1400x1050 not pruned from
mode list\n");
+
+ drmModeFreeConnector(temp);
+
+ kmstest_force_edid(drm_fd, vga_connector, NULL, 0);
+ kmstest_force_connector(drm_fd, vga_connector,
+ FORCE_CONNECTOR_UNSPECIFIED);
+ }
+
igt_fixture {
drmModeFreeConnector(vga_connector);
close(drm_fd);
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Clean up device info structure definitions
Beginning with gen7, newer devices repetitively redefine values
for the device info structure members. This patch simplifies the
structure definitions by grouping member value definitions into the
existing GEN7_FEATURES #define and into the new VLV_FEATURES and
HSW_FEATURES #defines.
Specifically, GEN_DEFAULT_PIPEOFFSETS and IVB_CURSOR_OFFSETS are
added to GEN7_FEATURES and subsequent IVB definitions are simplified.
VLV_FEATURES is defined to differentiate and simplify the
gen7 low power (LP) devices.
HSW_FEATURES is defined and used to simplify all HSW+ devices
except for LP.
v2: Use VLV_FEATURES for the gen7 low power devices. (Jani)
v3: Include HSW_FEATURES definition in intel_skylake_gt3_info. (Chris)
v4: Fix commit message.
Cc: Rodrigo Vivi
Signed-off-by: Wayne Boyer
---
drivers/gpu/drm/i915/i915_drv.c | 138 +++-
1 file changed, 36 insertions(+), 102 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 90faa8e..46ac664 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -226,125 +226,87 @@ static const struct intel_device_info
intel_sandybridge_m_info = {
#define GEN7_FEATURES \
.gen = 7, .num_pipes = 3, \
.need_gfx_hws = 1, .has_hotplug = 1, \
.has_fbc = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
- .has_llc = 1
+ .has_llc = 1, \
+ GEN_DEFAULT_PIPEOFFSETS, \
+ IVB_CURSOR_OFFSETS
static const struct intel_device_info intel_ivybridge_d_info = {
GEN7_FEATURES,
.is_ivybridge = 1,
- GEN_DEFAULT_PIPEOFFSETS,
- IVB_CURSOR_OFFSETS,
};
static const struct intel_device_info intel_ivybridge_m_info = {
GEN7_FEATURES,
.is_ivybridge = 1,
.is_mobile = 1,
- GEN_DEFAULT_PIPEOFFSETS,
- IVB_CURSOR_OFFSETS,
};
static const struct intel_device_info intel_ivybridge_q_info = {
GEN7_FEATURES,
.is_ivybridge = 1,
.num_pipes = 0, /* legal, last one wins */
- GEN_DEFAULT_PIPEOFFSETS,
- IVB_CURSOR_OFFSETS,
};
+#define VLV_FEATURES \
+ .gen = 7, .num_pipes = 2, \
+ .need_gfx_hws = 1, .has_hotplug = 1, \
+ .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
+ .display_mmio_offset = VLV_DISPLAY_BASE, \
+ GEN_DEFAULT_PIPEOFFSETS, \
+ CURSOR_OFFSETS
+
static const struct intel_device_info intel_valleyview_m_info = {
- GEN7_FEATURES,
- .is_mobile = 1,
- .num_pipes = 2,
+ VLV_FEATURES,
.is_valleyview = 1,
- .display_mmio_offset = VLV_DISPLAY_BASE,
- .has_fbc = 0, /* legal, last one wins */
- .has_llc = 0, /* legal, last one wins */
- GEN_DEFAULT_PIPEOFFSETS,
- CURSOR_OFFSETS,
+ .is_mobile = 1,
};
static const struct intel_device_info intel_valleyview_d_info = {
- GEN7_FEATURES,
- .num_pipes = 2,
+ VLV_FEATURES,
.is_valleyview = 1,
- .display_mmio_offset = VLV_DISPLAY_BASE,
- .has_fbc = 0, /* legal, last one wins */
- .has_llc = 0, /* legal, last one wins */
- GEN_DEFAULT_PIPEOFFSETS,
- CURSOR_OFFSETS,
};
+#define HSW_FEATURES \
+ GEN7_FEATURES, \
+ .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING, \
+ .has_ddi = 1, \
+ .has_fpga_dbg = 1
+
static const struct intel_device_info intel_haswell_d_info = {
- GEN7_FEATURES,
+ HSW_FEATURES,
.is_haswell = 1,
- .has_ddi = 1,
- .has_fpga_dbg = 1,
- .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
- GEN_DEFAULT_PIPEOFFSETS,
- IVB_CURSOR_OFFSETS,
};
static const struct intel_device_info intel_haswell_m_info = {
- GEN7_FEATURES,
+ HSW_FEATURES,
.is_haswell = 1,
.is_mobile = 1,
- .has_ddi = 1,
- .has_fpga_dbg = 1,
- .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
- GEN_DEFAULT_PIPEOFFSETS,
- IVB_CURSOR_OFFSETS,
};
static const struct intel_device_info intel_broadwell_d_info = {
- .gen = 8, .num_pipes = 3,
- .need_gfx_hws = 1, .has_hotplug = 1,
- .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
- .has_llc = 1,
- .has_ddi = 1,
- .has_fpga_dbg = 1,
- .has_fbc = 1,
- GEN_DEFAULT_PIPEOFFSETS,
- IVB_CURSOR_OFFSETS,
+ HSW_FEATURES,
+ .gen = 8,
};
static const struct intel_device_info intel_broadwell_m_info = {
- .gen = 8, .is_mobile = 1, .num_pipes = 3,
- .need_gfx_hws = 1, .has_hotplug = 1,
- .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
- .has_llc = 1,
- .has_ddi = 1,
- .has_fpga_dbg = 1,
- .has_fbc = 1,
- GEN_DEFAULT_PIPEOFFSETS,
- IVB_CURSOR_OFFSETS,
+ HSW_FEATURES,
+ .gen = 8, .is_mobile = 1,
};
static const struct intel_device_info intel_broadwell_gt3d_info = {
- .gen = 8, .num_pipes = 3,
Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid writing relocs with addresses in non-canonical form
On Fri, 2015-12-04 at 17:18 +0100, Daniel Vetter wrote: > On Fri, Dec 04, 2015 at 04:20:43PM +0100, Michał Winiarski wrote: > > According to bspec, some parts of HW expect the addresses to be in > > a canonical form, where bits [63:48] == [47]. Let's convert > > addresses to > > canonical form prior to relocating and return converted offsets to > > userspace. > > > > v2: Whitespace fixup, gen8_canonical_addr description (Chris, > > Ville) > > > > Cc: Chris Wilson > > Cc: Michel Thierry > > Cc: Ville Syrjälä > > Signed-off-by: Michał Winiarski > > Can we igt this? Maybe with softpin or whatever ... For cpu address > space > negative addresses are for the kernel, but I think on the gpu we can > do > them. Yup - would definitely be useful, I can add something to one of the existing reloc tests, but without softpin it's tricky to cover this in a reliable way (not to mention corner cases). -Michał > -Daniel > > > --- > > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +--- > > drivers/gpu/drm/i915/i915_gem_gtt.h| 12 > > 2 files changed, 17 insertions(+), 3 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Clean up device info structure definitions
Beginning with gen7, newer devices repetitively redefine values
for the device info structure members. This patch simplifies the
structure definitions by grouping member value definitions into the
existing GEN7_FEATURES #define and into the new GEN7_LP_FEATURES
and HSW_FEATURES #defines.
Specifically, GEN_DEFAULT_PIPEOFFSETS and IVB_CURSOR_OFFSETS are
added to GEN7_FEATURES and subsequent IVB definitions are simplified.
VLV_FEATURES is defined to differentiate and simplify the
gen7 low power (LP) devices.
HSW_FEATURES is defined and used to simplify all HSW+ devices
except for LP.
v2: Use VLV_FEATURES for the gen7 low power devices. (Jani)
v3: Include HSW_FEATURES definition in intel_skylake_gt3_info. (Chris)
Cc: Rodrigo Vivi
Signed-off-by: Wayne Boyer
---
drivers/gpu/drm/i915/i915_drv.c | 138 +++-
1 file changed, 36 insertions(+), 102 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 90faa8e..46ac664 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -226,125 +226,87 @@ static const struct intel_device_info
intel_sandybridge_m_info = {
#define GEN7_FEATURES \
.gen = 7, .num_pipes = 3, \
.need_gfx_hws = 1, .has_hotplug = 1, \
.has_fbc = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
- .has_llc = 1
+ .has_llc = 1, \
+ GEN_DEFAULT_PIPEOFFSETS, \
+ IVB_CURSOR_OFFSETS
static const struct intel_device_info intel_ivybridge_d_info = {
GEN7_FEATURES,
.is_ivybridge = 1,
- GEN_DEFAULT_PIPEOFFSETS,
- IVB_CURSOR_OFFSETS,
};
static const struct intel_device_info intel_ivybridge_m_info = {
GEN7_FEATURES,
.is_ivybridge = 1,
.is_mobile = 1,
- GEN_DEFAULT_PIPEOFFSETS,
- IVB_CURSOR_OFFSETS,
};
static const struct intel_device_info intel_ivybridge_q_info = {
GEN7_FEATURES,
.is_ivybridge = 1,
.num_pipes = 0, /* legal, last one wins */
- GEN_DEFAULT_PIPEOFFSETS,
- IVB_CURSOR_OFFSETS,
};
+#define VLV_FEATURES \
+ .gen = 7, .num_pipes = 2, \
+ .need_gfx_hws = 1, .has_hotplug = 1, \
+ .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
+ .display_mmio_offset = VLV_DISPLAY_BASE, \
+ GEN_DEFAULT_PIPEOFFSETS, \
+ CURSOR_OFFSETS
+
static const struct intel_device_info intel_valleyview_m_info = {
- GEN7_FEATURES,
- .is_mobile = 1,
- .num_pipes = 2,
+ VLV_FEATURES,
.is_valleyview = 1,
- .display_mmio_offset = VLV_DISPLAY_BASE,
- .has_fbc = 0, /* legal, last one wins */
- .has_llc = 0, /* legal, last one wins */
- GEN_DEFAULT_PIPEOFFSETS,
- CURSOR_OFFSETS,
+ .is_mobile = 1,
};
static const struct intel_device_info intel_valleyview_d_info = {
- GEN7_FEATURES,
- .num_pipes = 2,
+ VLV_FEATURES,
.is_valleyview = 1,
- .display_mmio_offset = VLV_DISPLAY_BASE,
- .has_fbc = 0, /* legal, last one wins */
- .has_llc = 0, /* legal, last one wins */
- GEN_DEFAULT_PIPEOFFSETS,
- CURSOR_OFFSETS,
};
+#define HSW_FEATURES \
+ GEN7_FEATURES, \
+ .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING, \
+ .has_ddi = 1, \
+ .has_fpga_dbg = 1
+
static const struct intel_device_info intel_haswell_d_info = {
- GEN7_FEATURES,
+ HSW_FEATURES,
.is_haswell = 1,
- .has_ddi = 1,
- .has_fpga_dbg = 1,
- .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
- GEN_DEFAULT_PIPEOFFSETS,
- IVB_CURSOR_OFFSETS,
};
static const struct intel_device_info intel_haswell_m_info = {
- GEN7_FEATURES,
+ HSW_FEATURES,
.is_haswell = 1,
.is_mobile = 1,
- .has_ddi = 1,
- .has_fpga_dbg = 1,
- .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
- GEN_DEFAULT_PIPEOFFSETS,
- IVB_CURSOR_OFFSETS,
};
static const struct intel_device_info intel_broadwell_d_info = {
- .gen = 8, .num_pipes = 3,
- .need_gfx_hws = 1, .has_hotplug = 1,
- .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
- .has_llc = 1,
- .has_ddi = 1,
- .has_fpga_dbg = 1,
- .has_fbc = 1,
- GEN_DEFAULT_PIPEOFFSETS,
- IVB_CURSOR_OFFSETS,
+ HSW_FEATURES,
+ .gen = 8,
};
static const struct intel_device_info intel_broadwell_m_info = {
- .gen = 8, .is_mobile = 1, .num_pipes = 3,
- .need_gfx_hws = 1, .has_hotplug = 1,
- .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
- .has_llc = 1,
- .has_ddi = 1,
- .has_fpga_dbg = 1,
- .has_fbc = 1,
- GEN_DEFAULT_PIPEOFFSETS,
- IVB_CURSOR_OFFSETS,
+ HSW_FEATURES,
+ .gen = 8, .is_mobile = 1,
};
static const struct intel_device_info intel_broadwell_gt3d_info = {
- .gen = 8, .num_pipes = 3,
- .need_gfx_hw
Re: [Intel-gfx] [PATCH] Always mark GEM objects as dirty when written by the CPU
On 04/12/15 09:57, Daniel Vetter wrote: On Tue, Dec 01, 2015 at 01:21:07PM +, Dave Gordon wrote: On 01/12/15 13:04, Chris Wilson wrote: On Tue, Dec 01, 2015 at 12:42:02PM +, Dave Gordon wrote: In various places, one or more pages of a GEM object are mapped into CPU address space and updated. In each such case, the object should be marked dirty, to ensure that the modifications are not discarded if the object is evicted under memory pressure. This is similar to commit commit 51bc140431e233284660b1d22c47dec9ecdb521e Author: Chris Wilson Date: Mon Aug 31 15:10:39 2015 +0100 drm/i915: Always mark the object as dirty when used by the GPU in which Chris ensured that updates by the GPU were not lost due to eviction, but this patch applies instead to the multiple places where object content is updated by the host CPU. Apart from that commit was to mask userspace bugs, here we are under control of when the pages are marked and have chosen a different per-page interface for CPU writes as opposed to per-object. -Chris The pattern get_pages(); kmap(get_page()) write kunmap() occurs often enough that it might be worth providing a common function to do that and mark only the specific page dirty (other cases touch the whole object, so for those we can just set the obj->dirty flag and let put_pages() take care of propagating that to all the individual pages). But can we be sure that all the functions touched by this patch will operate only on regular (default) GEM objects (i.e. not phys, stolen, etc) 'cos some of those don't support per-page tracking. What about objects with no backing store -- can/should we mark those as dirty (which would prevent eviction)? I thought our special objects do clear obj->dirty on put_pages? Can you please elaborate on your concern? While we discuss all this: A patch at the end to document dirty (maybe even as a first stab at kerneldoc for i915_drm_gem_buffer_object) would be awesome. -Daniel In general, obj->dirty means that (some or) all the pages of the object (may) have been modified since last time the object was read from backing store, and that the modified data should be written back rather than discarded. Code that works only on default (gtt) GEM objects may be able to optimise writebacks by marking individual pages dirty, rather than the object as a whole. But not every GEM object has backing store, and even among those that do, some do not support per-page dirty tracking. These are the GEM objects we may want to consider: 1. Default (gtt) object * Discontiguous, lives in page cache while pinned during use * Backed by shmfs (swap) * put_pages() transfers dirty status from object to each page before release * shmfs ensures that dirty unpinned pages are written out before deallocation * Could optimise by marking individual pages at point of use, rather than marking whole object and then pushing to all pages during put_pages() 2. Phys GEM object * Lives in physically-contiguous system memory, pinned during use * Backed by shmfs * if obj->dirty, put_pages() *copies* all pages back to shmfs via page cache RMW * No per-page tracking, cannot optimise 3. Stolen GEM object * Lives in (physically-contiguous) stolen memory, always pinned * No backing store! * obj->dirty is irrelevant (ignored) * put_pages() only called at end-of-life * No per-page tracking (not meaningful anyway) 4. Userptr GEM object * Discontiguous, lives in page cache while pinned during use * Backed by user process memory (which may then map to some arbitrary file mapping?) * put_pages() transfers dirty status from object to each page before release * dirty pages are still resident in user space, can be swapped out when not pinned * Could optimise by marking individual pages at point of use, rather than marking whole object and then pushing to all pages during put_pages() Are there any more? Given this diversity, it may be worth adding a dirty_page() vfunc, so that for those situations where a single page is dirtied AND the object type supports per-page tracking, we can take advantage of this to reduce copying. For objects that don't support per-page tracking, the implementation would just set obj->dirty. For example: void (*dirty_page)(obj, pageno); possibly with the additional semantic that pageno == -1 means 'dirty the whole object'. A convenient further facility would be: struct page *i915_gem_object_get_dirty_page(obj, pageno); which is just like i915_gem_object_get_page() but with the additional effect of marking the returned page dirty (by calling the above vfunc). [Aside: can we call set_page_dirty() on a non-shmfs-backed page?]. This means that in all the places where I added 'obj->dirty = 1' after a kunmap() call, we would instead just change the earlier get_page() to get_dirty_p
Re: [Intel-gfx] [PATCH] drm/i915: Separate cherryview from valleyview
On Fri, Dec 04, 2015 at 05:14:19PM +, Vivi, Rodrigo wrote: > On Fri, 2015-12-04 at 19:04 +0200, Ville Syrjälä wrote: > > On Fri, Dec 04, 2015 at 05:51:56PM +0100, Daniel Vetter wrote: > > > On Fri, Dec 04, 2015 at 04:15:27PM +, Vivi, Rodrigo wrote: > > > > On Fri, 2015-12-04 at 16:05 +0100, Daniel Vetter wrote: > > > > > On Wed, Dec 02, 2015 at 02:30:28PM +0200, Jani Nikula wrote: > > > > > > On Wed, 02 Dec 2015, Ville Syrjälä < > > > > > > ville.syrj...@linux.intel.com> > > > > > > wrote: > > > > > > > On Tue, Dec 01, 2015 at 05:11:40PM -0800, Wayne Boyer > > > > > > > wrote: > > > > > > > > The cherryview device shares many characteristics with > > > > > > > > the > > > > > > > > valleyview > > > > > > > > device. When support was added to the driver for > > > > > > > > cherryview, > > > > > > > > the > > > > > > > > corresponding device info structure included > > > > > > > > .is_valleyview = > > > > > > > > 1. > > > > > > > > This is not correct and leads to some confusion. > > > > > > > > > > > > > > > > This patch changes .is_valleyview to .is_cherryview in > > > > > > > > the > > > > > > > > cherryview > > > > > > > > device info structure and defines the > > > > > > > > HAS_GEN7_LP_FEATURES > > > > > > > > macro. > > > > > > > > Then where appropriate, instances of IS_VALLEYVIEW are > > > > > > > > replaced > > > > > > > > with > > > > > > > > HAS_GEN7_LP_FEATURES to test for either a valleyview or a > > > > > > > > cherryview > > > > > > > > device. > > > > > > > > > > > > > > I don't like the name of the macro. Most of the shared bits > > > > > > > are > > > > > > > display > > > > > > > related, so we could have something like HAS_VLV_DISPLAY. > > > > > > > For the > > > > > > > rest, > > > > > > > I think we could just test IS_VLV||IS_CHV explicitly. > > > > > > > Unless > > > > > > > someone > > > > > > > can come up with a better name that covers everything? > > > > > > > > > > > > Definitely NAK on HAS_GEN7_LP_FEATURES. > > > > > > > > > > > > HAS_VLV_DISPLAY would be a subset of HAS_GMCH_DISPLAY, which > > > > > > I > > > > > > guess > > > > > > wouldn't be that bad... unless someone starts using that for > > > > > > a > > > > > > VLV||CHV > > > > > > shorthand in non-display code. > > > > > > > > > > > > I think I might just go for the verbose (IS_VALLEYVIEW || > > > > > > IS_CHERRYVIEW) > > > > > > all around. Especially since we've been brainwashed with the > > > > > > old > > > > > > vlv is > > > > > > both vlv and chv code. > > > > > > > > > > HAS_GMCH_DISPLAY is what I've generally used, since usually you > > > > > have > > > > > a > > > > > INTEL_INFO()->gen >= 5 test already somewhere. If we want to > > > > > make > > > > > this > > > > > more explicit the proper name for vlv is BAYTRAIL, and for > > > > > truely byt > > > > > specific stuff we've named things byt_. So what about Defining > > > > > an > > > > > IS_BAYTRAIL instead for the cases where it's not vlv || chv. > > > > > > > > Baytrail is the platform name with the Valleyview graphics. Than > > > > we > > > > would have Cherry Trail and/or Braswell for Cherryview graphics > > > > and > > > > Apollo Lake for Broxton. So I would vote to stay with Valleyview, > > > > Cherryview and Broxton only. > > > > > > > > > > > > > > And what's the benefit of all this churn? > > > > > > > > Organize and prepare the code for future platforms. > > > > Avoid more confusion like we had on IS_SKYLAKE x IS_KABYLAKE. > > > > Make things more easy and clear if we decide to add .is_atom_lp > > > > on > > > > these platforms definition. > > > > > > .is_atom_lp is imo the more sensible change to do, since it > > > includes bxt. > > > > BXT vs. VLV/CHV have practically nothing in common in the driver, > > so I wouldn't go there. > > this was exactly the point where HAS_GEN7_LP_FEATURES appeared, Which is confusing since since CHV is gen8. And all the features that are shared have nothing to do with the GT block which is what the gen numbers identify. -- 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 2/3] drm/i915: Correct the Ref clock value for BXT
On Fri, Dec 04, 2015 at 04:25:19PM +, Deepak, M wrote:
>
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Friday, December 4, 2015 9:52 PM
> > To: Ville Syrjälä
> > Cc: Deepak, M ; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915: Correct the Ref clock value
> > for
> > BXT
> >
> > On Fri, Dec 04, 2015 at 11:55:56AM +0200, Ville Syrjälä wrote:
> > > On Fri, Dec 04, 2015 at 07:47:38PM +0530, Deepak M wrote:
> > > > The reference clock for BXT is 19.2 MHz not 19.5 MHz, updating the
> > > > correct value here.
> > > >
> > > > Signed-off-by: Deepak M
> > > > ---
> > > > drivers/gpu/drm/i915/i915_reg.h | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > b/drivers/gpu/drm/i915/i915_reg.h index 8bd2699..009f474 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -7676,7 +7676,7 @@ enum skl_disp_power_wells {
> > > > #define BXT_DSI_PLL_RATIO_MAX 0x7D
> > > > #define BXT_DSI_PLL_RATIO_MIN 0x22
> > > > #define BXT_DSI_PLL_RATIO_MASK 0xFF
> > > > -#define BXT_REF_CLOCK_KHZ 19500
> > > > +#define BXT_REF_CLOCK_KHZ 19200
> > >
> > > No idea why we have this define in i915_reg.h. We don't have such
> > > defines for other platforms (also my fix CHV refclk to 19.2MHz patch
> > > never got reviewed by anyone either. Interedted?)
> >
> > Add link and I think Deepak is volunteered ;-)
> > >
> [Deepak, M] Please share the link, I can go through the patch :)
This is the whole series:
http://lists.freedesktop.org/archives/intel-gfx/2015-September/075097.html
Some of it might have bitrotted a bit, but nothing a rebase wouldn't
fix I think.
There's also this other patch dealing with dual-link (which I've never
tested due to lack of hardware):
http://lists.freedesktop.org/archives/intel-gfx/2015-September/075568.html
>
> > > Reviewed-by: Ville Syrjälä
> >
> > Queued for -next, thanks for the patch.
> > -Daniel
> > >
> > > >
> > > > #define BXT_DSI_PLL_ENABLE 0x46080
> > > > #define BXT_DSI_PLL_DO_ENABLE (1 << 31)
> > > > --
> > > > 1.9.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
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
--
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] drm/i915: Separate cherryview from valleyview
On Fri, 2015-12-04 at 19:04 +0200, Ville Syrjälä wrote: > On Fri, Dec 04, 2015 at 05:51:56PM +0100, Daniel Vetter wrote: > > On Fri, Dec 04, 2015 at 04:15:27PM +, Vivi, Rodrigo wrote: > > > On Fri, 2015-12-04 at 16:05 +0100, Daniel Vetter wrote: > > > > On Wed, Dec 02, 2015 at 02:30:28PM +0200, Jani Nikula wrote: > > > > > On Wed, 02 Dec 2015, Ville Syrjälä < > > > > > ville.syrj...@linux.intel.com> > > > > > wrote: > > > > > > On Tue, Dec 01, 2015 at 05:11:40PM -0800, Wayne Boyer > > > > > > wrote: > > > > > > > The cherryview device shares many characteristics with > > > > > > > the > > > > > > > valleyview > > > > > > > device. When support was added to the driver for > > > > > > > cherryview, > > > > > > > the > > > > > > > corresponding device info structure included > > > > > > > .is_valleyview = > > > > > > > 1. > > > > > > > This is not correct and leads to some confusion. > > > > > > > > > > > > > > This patch changes .is_valleyview to .is_cherryview in > > > > > > > the > > > > > > > cherryview > > > > > > > device info structure and defines the > > > > > > > HAS_GEN7_LP_FEATURES > > > > > > > macro. > > > > > > > Then where appropriate, instances of IS_VALLEYVIEW are > > > > > > > replaced > > > > > > > with > > > > > > > HAS_GEN7_LP_FEATURES to test for either a valleyview or a > > > > > > > cherryview > > > > > > > device. > > > > > > > > > > > > I don't like the name of the macro. Most of the shared bits > > > > > > are > > > > > > display > > > > > > related, so we could have something like HAS_VLV_DISPLAY. > > > > > > For the > > > > > > rest, > > > > > > I think we could just test IS_VLV||IS_CHV explicitly. > > > > > > Unless > > > > > > someone > > > > > > can come up with a better name that covers everything? > > > > > > > > > > Definitely NAK on HAS_GEN7_LP_FEATURES. > > > > > > > > > > HAS_VLV_DISPLAY would be a subset of HAS_GMCH_DISPLAY, which > > > > > I > > > > > guess > > > > > wouldn't be that bad... unless someone starts using that for > > > > > a > > > > > VLV||CHV > > > > > shorthand in non-display code. > > > > > > > > > > I think I might just go for the verbose (IS_VALLEYVIEW || > > > > > IS_CHERRYVIEW) > > > > > all around. Especially since we've been brainwashed with the > > > > > old > > > > > vlv is > > > > > both vlv and chv code. > > > > > > > > HAS_GMCH_DISPLAY is what I've generally used, since usually you > > > > have > > > > a > > > > INTEL_INFO()->gen >= 5 test already somewhere. If we want to > > > > make > > > > this > > > > more explicit the proper name for vlv is BAYTRAIL, and for > > > > truely byt > > > > specific stuff we've named things byt_. So what about Defining > > > > an > > > > IS_BAYTRAIL instead for the cases where it's not vlv || chv. > > > > > > Baytrail is the platform name with the Valleyview graphics. Than > > > we > > > would have Cherry Trail and/or Braswell for Cherryview graphics > > > and > > > Apollo Lake for Broxton. So I would vote to stay with Valleyview, > > > Cherryview and Broxton only. > > > > > > > > > > > And what's the benefit of all this churn? > > > > > > Organize and prepare the code for future platforms. > > > Avoid more confusion like we had on IS_SKYLAKE x IS_KABYLAKE. > > > Make things more easy and clear if we decide to add .is_atom_lp > > > on > > > these platforms definition. > > > > .is_atom_lp is imo the more sensible change to do, since it > > includes bxt. > > BXT vs. VLV/CHV have practically nothing in common in the driver, > so I wouldn't go there. this was exactly the point where HAS_GEN7_LP_FEATURES appeared, than for BXT+ would be HAS_GEN9_LP_FEATURES otherwises with .is_atom_lp for gen7 it would be ((gen == 7 || gen ==8) && .is_atom_lp); and for gen 9: (gen ==9 && .is_atom_lp) IS_GEN9_LP seems a good name, but IS_GEN7_LP doesn't so it was related to the FEATURES macros at platform definition... But yeah, maybe better just stay with full version (is_vlv || is_chv) for that and if makes sense for future platforms we add the .is_atom_lp later... > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 4/4] ALSA: hda - Move audio component accesses to hdac_i915.c
A couple of i915_audio_component ops have been added and accessed
directly from patch_hdmi.c. Ideally all these should be factored out
into hdac_i915.c.
This patch does it, adds two new helper functions for setting N/CTS
and fetching ELD bytes. One bonus is that the hackish widget vs port
mapping is also moved to hdac_i915.c, so that it can be fixed /
enhanced more cleanly.
Signed-off-by: Takashi Iwai
---
include/sound/hda_i915.h | 14 ++
sound/hda/hdac_i915.c | 66
sound/pci/hda/patch_hdmi.c | 69 +-
3 files changed, 106 insertions(+), 43 deletions(-)
diff --git a/include/sound/hda_i915.h b/include/sound/hda_i915.h
index 930b41e5acf4..fa341fcb5829 100644
--- a/include/sound/hda_i915.h
+++ b/include/sound/hda_i915.h
@@ -10,6 +10,9 @@
int snd_hdac_set_codec_wakeup(struct hdac_bus *bus, bool enable);
int snd_hdac_display_power(struct hdac_bus *bus, bool enable);
int snd_hdac_get_display_clk(struct hdac_bus *bus);
+int snd_hdac_sync_audio_rate(struct hdac_bus *bus, hda_nid_t nid, int rate);
+int snd_hdac_acomp_get_eld(struct hdac_bus *bus, hda_nid_t nid,
+ bool *audio_enabled, char *buffer, int max_bytes);
int snd_hdac_i915_init(struct hdac_bus *bus);
int snd_hdac_i915_exit(struct hdac_bus *bus);
int snd_hdac_i915_register_notifier(const struct
i915_audio_component_audio_ops *);
@@ -26,6 +29,17 @@ static inline int snd_hdac_get_display_clk(struct hdac_bus
*bus)
{
return 0;
}
+static inline int snd_hdac_sync_audio_rate(struct hdac_bus *bus, hda_nid_t nid,
+ int rate)
+{
+ return 0;
+}
+static inline int snd_hdac_acomp_get_eld(struct hdac_bus *bus, hda_nid_t nid,
+bool *audio_enabled, char *buffer,
+int max_bytes)
+{
+ return -ENODEV;
+}
static inline int snd_hdac_i915_init(struct hdac_bus *bus)
{
return -ENODEV;
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
index 8fef1b8d1fd8..c50177fb469f 100644
--- a/sound/hda/hdac_i915.c
+++ b/sound/hda/hdac_i915.c
@@ -118,6 +118,72 @@ int snd_hdac_get_display_clk(struct hdac_bus *bus)
}
EXPORT_SYMBOL_GPL(snd_hdac_get_display_clk);
+/* There is a fixed mapping between audio pin node and display port
+ * on current Intel platforms:
+ * Pin Widget 5 - PORT B (port = 1 in i915 driver)
+ * Pin Widget 6 - PORT C (port = 2 in i915 driver)
+ * Pin Widget 7 - PORT D (port = 3 in i915 driver)
+ */
+static int pin2port(hda_nid_t pin_nid)
+{
+ return pin_nid - 4;
+}
+
+/**
+ * snd_hdac_sync_audio_rate - Set N/CTS based on the sample rate
+ * @bus: HDA core bus
+ * @nid: the pin widget NID
+ * @rate: the sample rate to set
+ *
+ * This function is supposed to be used only by a HD-audio controller
+ * driver that needs the interaction with i915 graphics.
+ *
+ * This function sets N/CTS value based on the given sample rate.
+ * Returns zero for success, or a negative error code.
+ */
+int snd_hdac_sync_audio_rate(struct hdac_bus *bus, hda_nid_t nid, int rate)
+{
+ struct i915_audio_component *acomp = bus->audio_component;
+
+ if (!acomp || !acomp->ops || !acomp->ops->sync_audio_rate)
+ return -ENODEV;
+ return acomp->ops->sync_audio_rate(acomp->dev, pin2port(nid), rate);
+}
+EXPORT_SYMBOL_GPL(snd_hdac_sync_audio_rate);
+
+/**
+ * snd_hdac_acomp_get_eld - Get the audio state and ELD via component
+ * @bus: HDA core bus
+ * @nid: the pin widget NID
+ * @audio_enabled: the pointer to store the current audio state
+ * @buffer: the buffer pointer to store ELD bytes
+ * @max_bytes: the max bytes to be stored on @buffer
+ *
+ * This function is supposed to be used only by a HD-audio controller
+ * driver that needs the interaction with i915 graphics.
+ *
+ * This function queries the current state of the audio on the given
+ * digital port and fetches the ELD bytes onto the given buffer.
+ * It returns the number of bytes for the total ELD data, zero for
+ * invalid ELD, or a negative error code.
+ *
+ * The return size is the total bytes required for the whole ELD bytes,
+ * thus it may be over @max_bytes. If it's over @max_bytes, it implies
+ * that only a part of ELD bytes have been fetched.
+ */
+int snd_hdac_acomp_get_eld(struct hdac_bus *bus, hda_nid_t nid,
+ bool *audio_enabled, char *buffer, int max_bytes)
+{
+ struct i915_audio_component *acomp = bus->audio_component;
+
+ if (!acomp || !acomp->ops || !acomp->ops->get_eld)
+ return -ENODEV;
+
+ return acomp->ops->get_eld(acomp->dev, pin2port(nid), audio_enabled,
+ buffer, max_bytes);
+}
+EXPORT_SYMBOL_GPL(snd_hdac_acomp_get_eld);
+
static int hdac_component_master_bind(struct device *dev)
{
struct i915_audio_component *acomp = hdac_acomp;
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/h
[Intel-gfx] [PATCH v3 3/4] ALSA: hda - Use component ops for i915 HDMI/DP audio jack handling
Since we have a new audio component ops to fetch the current ELD and
state now, we can reduce the usage of unsol event of HDMI/DP pins.
The unsol event isn't only unreliable, but it also needs the power
up/down of the codec and link at each time, which is a significant
power and time loss.
In this patch, the jack creation and unsol/jack event handling are
modified to use the audio component for the dedicated Intel chips.
The jack handling got slightly more codes than a simple usage of
hda_jack layer since we need to deal directly with snd_jack object;
the hda_jack layer is basically designed for the pin sense read and
unsol events, both of which aren't used any longer in our case.
Signed-off-by: Takashi Iwai
---
v2->v3:
* Adapt the earlier applied preliminary patches
* Direct invocation of get_eld now instead of deferred call, as we
have no longer deadlocks
sound/pci/hda/patch_hdmi.c | 111 +++--
1 file changed, 97 insertions(+), 14 deletions(-)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 85342d261043..61f004a73590 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -83,6 +83,7 @@ struct hdmi_spec_per_pin {
struct mutex lock;
struct delayed_work work;
struct snd_kcontrol *eld_ctl;
+ struct snd_jack *acomp_jack; /* jack via audio component */
int repoll_count;
bool setup; /* the stream has been set up by prepare callback */
int channels; /* current number of channels */
@@ -1437,6 +1438,17 @@ static void intel_not_share_assigned_cvt(struct
hda_codec *codec,
}
}
+/* There is a fixed mapping between audio pin node and display port
+ * on current Intel platforms:
+ * Pin Widget 5 - PORT B (port = 1 in i915 driver)
+ * Pin Widget 6 - PORT C (port = 2 in i915 driver)
+ * Pin Widget 7 - PORT D (port = 3 in i915 driver)
+ */
+static int intel_pin2port(hda_nid_t pin_nid)
+{
+ return pin_nid - 4;
+}
+
/*
* HDA PCM callbacks
*/
@@ -1582,7 +1594,9 @@ static void update_eld(struct hda_codec *codec,
&per_pin->eld_ctl->id);
}
-static bool hdmi_present_sense(struct hdmi_spec_per_pin *per_pin, int repoll)
+/* update ELD and jack state via HD-audio verbs */
+static bool hdmi_present_sense_via_verbs(struct hdmi_spec_per_pin *per_pin,
+int repoll)
{
struct hda_jack_tbl *jack;
struct hda_codec *codec = per_pin->codec;
@@ -1642,6 +1656,56 @@ static bool hdmi_present_sense(struct hdmi_spec_per_pin
*per_pin, int repoll)
return ret;
}
+/* update ELD and jack state via audio component */
+static void sync_eld_via_acomp(struct hda_codec *codec,
+ struct hdmi_spec_per_pin *per_pin)
+{
+ struct i915_audio_component *acomp = codec->bus->core.audio_component;
+ struct hdmi_spec *spec = codec->spec;
+ struct hdmi_eld *eld = &spec->temp_eld;
+ int size;
+
+ if (acomp && acomp->ops && acomp->ops->get_eld) {
+ mutex_lock(&per_pin->lock);
+ size = acomp->ops->get_eld(acomp->dev,
+ intel_pin2port(per_pin->pin_nid),
+ &eld->monitor_present,
+ eld->eld_buffer,
+ ELD_MAX_SIZE);
+ if (size > 0) {
+ size = min(size, ELD_MAX_SIZE);
+ if (snd_hdmi_parse_eld(codec, &eld->info,
+ eld->eld_buffer, size) < 0)
+ size = -EINVAL;
+ }
+
+ if (size > 0) {
+ eld->eld_valid = true;
+ eld->eld_size = size;
+ } else {
+ eld->eld_valid = false;
+ eld->eld_size = 0;
+ }
+
+ update_eld(codec, per_pin, eld);
+ snd_jack_report(per_pin->acomp_jack,
+ eld->monitor_present ? SND_JACK_AVOUT : 0);
+ mutex_unlock(&per_pin->lock);
+ }
+}
+
+static bool hdmi_present_sense(struct hdmi_spec_per_pin *per_pin, int repoll)
+{
+ struct hda_codec *codec = per_pin->codec;
+
+ if (codec_has_acomp(codec)) {
+ sync_eld_via_acomp(codec, per_pin);
+ return false; /* don't call snd_hda_jack_report_sync() */
+ } else {
+ return hdmi_present_sense_via_verbs(per_pin, repoll);
+ }
+}
+
static void hdmi_repoll_eld(struct work_struct *work)
{
struct hdmi_spec_per_pin *per_pin =
@@ -1777,17 +1841,6 @@ static bool check_non_pcm_per_cvt(struct hda_codec
*codec, hda_nid_t cvt_nid)
return non_pcm;
}
-/* There is a fixed mapping between audio pin node and display port
- * on current Intel platforms:
- * Pin Widget 5 - PORT B (port = 1 in i91
[Intel-gfx] [PATCH v3 1/4] drm/i915: Add get_eld audio component
Implement a new i915_audio_component_ops, get_eld(). It's called by
the audio driver to fetch the current audio status and ELD of the
given HDMI/DP port. It returns the size of expected ELD bytes if it's
valid, zero if no valid ELD is found, or a negative error code. The
current state of audio on/off is stored in the given pointer, too.
Note that the returned size isn't limited to the given max bytes. If
the size is greater than the max bytes, it means that only a part of
ELD has been copied back.
For achieving this implementation, a new field audio_connector is
added to struct intel_digital_port. It points to the connector
assigned to the given digital port. It's set/reset at each audio
enable/disable call in intel_audio.c, and protected with av_mutex.
Signed-off-by: Takashi Iwai
---
v2->v3:
* Track drm_connector for easier ELD retrieval, remove superfluous
audio_enabled flag instead
* Back to av_mutex
* Rebase to drm-next, update get_eld documentation for new kernel doc
drivers/gpu/drm/i915/intel_audio.c | 42 ++
drivers/gpu/drm/i915/intel_drv.h | 2 ++
include/drm/i915_component.h | 14 +
3 files changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 9aa83e71b792..eeac9f763110 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -521,6 +521,10 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder)
dev_priv->display.audio_codec_enable(connector, intel_encoder,
adjusted_mode);
+ mutex_lock(&dev_priv->av_mutex);
+ intel_dig_port->audio_connector = connector;
+ mutex_unlock(&dev_priv->av_mutex);
+
if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
(int) port);
}
@@ -544,6 +548,10 @@ void intel_audio_codec_disable(struct intel_encoder
*intel_encoder)
if (dev_priv->display.audio_codec_disable)
dev_priv->display.audio_codec_disable(intel_encoder);
+ mutex_lock(&dev_priv->av_mutex);
+ intel_dig_port->audio_connector = NULL;
+ mutex_unlock(&dev_priv->av_mutex);
+
if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
(int) port);
}
@@ -703,6 +711,39 @@ static int i915_audio_component_sync_audio_rate(struct
device *dev,
return 0;
}
+static int i915_audio_component_get_eld(struct device *dev, int port,
+ bool *enabled,
+ unsigned char *buf, int max_bytes)
+{
+ struct drm_i915_private *dev_priv = dev_to_i915(dev);
+ struct drm_device *drm_dev = dev_priv->dev;
+ struct intel_encoder *intel_encoder;
+ struct intel_digital_port *intel_dig_port;
+ const u8 *eld;
+ int ret = -EINVAL;
+
+ mutex_lock(&dev_priv->av_mutex);
+ for_each_intel_encoder(drm_dev, intel_encoder) {
+ if (intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT &&
+ intel_encoder->type != INTEL_OUTPUT_HDMI)
+ continue;
+ intel_dig_port = enc_to_dig_port(&intel_encoder->base);
+ if (port == intel_dig_port->port) {
+ ret = 0;
+ *enabled = intel_dig_port->audio_connector != NULL;
+ if (!*enabled)
+ break;
+ eld = intel_dig_port->audio_connector->eld;
+ ret = drm_eld_size(eld);
+ memcpy(buf, eld, min(max_bytes, ret));
+ break;
+ }
+ }
+
+ mutex_unlock(&dev_priv->av_mutex);
+ return ret;
+}
+
static const struct i915_audio_component_ops i915_audio_component_ops = {
.owner = THIS_MODULE,
.get_power = i915_audio_component_get_power,
@@ -710,6 +751,7 @@ static const struct i915_audio_component_ops
i915_audio_component_ops = {
.codec_wake_override = i915_audio_component_codec_wake_override,
.get_cdclk_freq = i915_audio_component_get_cdclk_freq,
.sync_audio_rate = i915_audio_component_sync_audio_rate,
+ .get_eld= i915_audio_component_get_eld,
};
static int i915_audio_component_bind(struct device *i915_dev,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ab5c147fa9e9..fe58a5722b16 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -814,6 +814,8 @@ struct intel_digital_port {
struct intel_hdmi hdmi;
enum irqreturn (*hpd_pulse)(struct intel_digital_port *, bool);
bool release_cl2_override;
+ /* for communication with audio component; protected by av_m
[Intel-gfx] [PATCH v3 2/4] drm/i915: Add reverse mapping between port and intel_encoder
This patch adds a reverse mapping from a digital port number to
intel_encoder object containing the corresponding intel_digital_port.
It simplifies the query of the encoder a lot.
Signed-off-by: Takashi Iwai
---
v2->v3:
* Squashed previously two cleanup patches to a single patch
drivers/gpu/drm/i915/i915_drv.h| 2 ++
drivers/gpu/drm/i915/intel_audio.c | 39 +++---
drivers/gpu/drm/i915/intel_ddi.c | 1 +
drivers/gpu/drm/i915/intel_dp.c| 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
5 files changed, 17 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 15c6dc0b4f37..9dbc143cac27 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1944,6 +1944,8 @@ struct drm_i915_private {
/* perform PHY state sanity checks? */
bool chv_phy_assert[2];
+ struct intel_encoder *dig_port_map[I915_MAX_PORTS];
+
/*
* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
* will be rejected. Instead look for a better place.
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index eeac9f763110..05f08b445dd6 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -636,13 +636,11 @@ static int i915_audio_component_sync_audio_rate(struct
device *dev,
int port, int rate)
{
struct drm_i915_private *dev_priv = dev_to_i915(dev);
- struct drm_device *drm_dev = dev_priv->dev;
struct intel_encoder *intel_encoder;
- struct intel_digital_port *intel_dig_port;
struct intel_crtc *crtc;
struct drm_display_mode *mode;
struct i915_audio_component *acomp = dev_priv->audio_component;
- enum pipe pipe = -1;
+ enum pipe pipe = INVALID_PIPE;
u32 tmp;
int n;
@@ -655,21 +653,12 @@ static int i915_audio_component_sync_audio_rate(struct
device *dev,
mutex_lock(&dev_priv->av_mutex);
/* 1. get the pipe */
- for_each_intel_encoder(drm_dev, intel_encoder) {
- if (intel_encoder->type != INTEL_OUTPUT_HDMI)
- continue;
- intel_dig_port = enc_to_dig_port(&intel_encoder->base);
- if (port == intel_dig_port->port) {
- crtc = to_intel_crtc(intel_encoder->base.crtc);
- if (!crtc) {
- DRM_DEBUG_KMS("%s: crtc is NULL\n", __func__);
- continue;
- }
- pipe = crtc->pipe;
- break;
- }
+ intel_encoder = dev_priv->dig_port_map[port];
+ if (intel_encoder && intel_encoder->type == INTEL_OUTPUT_HDMI &&
+ intel_encoder->base.crtc) {
+ crtc = to_intel_crtc(intel_encoder->base.crtc);
+ pipe = crtc->pipe;
}
-
if (pipe == INVALID_PIPE) {
DRM_DEBUG_KMS("no pipe for the port %c\n", port_name(port));
mutex_unlock(&dev_priv->av_mutex);
@@ -716,27 +705,21 @@ static int i915_audio_component_get_eld(struct device
*dev, int port,
unsigned char *buf, int max_bytes)
{
struct drm_i915_private *dev_priv = dev_to_i915(dev);
- struct drm_device *drm_dev = dev_priv->dev;
struct intel_encoder *intel_encoder;
struct intel_digital_port *intel_dig_port;
const u8 *eld;
int ret = -EINVAL;
mutex_lock(&dev_priv->av_mutex);
- for_each_intel_encoder(drm_dev, intel_encoder) {
- if (intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT &&
- intel_encoder->type != INTEL_OUTPUT_HDMI)
- continue;
+ intel_encoder = dev_priv->dig_port_map[port];
+ if (intel_encoder) {
+ ret = 0;
intel_dig_port = enc_to_dig_port(&intel_encoder->base);
- if (port == intel_dig_port->port) {
- ret = 0;
- *enabled = intel_dig_port->audio_connector != NULL;
- if (!*enabled)
- break;
+ *enabled = intel_dig_port->audio_connector != NULL;
+ if (*enabled) {
eld = intel_dig_port->audio_connector->eld;
ret = drm_eld_size(eld);
memcpy(buf, eld, min(max_bytes, ret));
- break;
}
}
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 76ce7c2960b6..59deb0d85533 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3295,6 +3295,7 @@ void intel_ddi_init(struct drm_device *dev, enum port
port)
intel_encoder->get_config = intel_ddi_get_config;
intel
[Intel-gfx] [PATCH v3 0/4] Add get_eld audio component for i915/HD-audio
Hi, this is the third revision of the patchset to add get_eld op to audio component for communicating more directly between i915 and HD-audio. Currently, the HDMI/DP audio status and ELD are notified and obtained via the hardware-level communication over HD-audio unsolicited event and verbs although the graphics driver holds the exactly same information. As we already have a notification via audio component, this is another step forward; the audio driver fetches directly the audio status and ELD via the new component op. A few patches have been dropped from this patchset as they were already applied individually beforehand. Also, two cleanup patches for i915 were squashed into one patch. The current patchset is found in sound git tree test/hdmi-jack branch. thanks, Takashi === v2->v3: * Track drm_connector for easier ELD retrieval, remove superfluous audio_enabled flag instead * Back to av_mutex * Adapt the earlier applied preliminary patches * Direct invocation of get_eld now instead of deferred call, as we have no longer deadlocks * Rebase to drm-next, update get_eld documentation for new kernel doc v1->v2: * Use modeset lock for get_eld lock, drop av mutex * Return the expected size from get_eld, not the copied size * Add reverse map from a port number to the encoder * Deferred invocation of get_eld from the eld_notify in HDA side * A bit more code refactoring in HDA side * Move audio component accessors to hdac_i915.c Takashi Iwai (4): drm/i915: Add get_eld audio component drm/i915: Add reverse mapping between port and intel_encoder ALSA: hda - Use component ops for i915 HDMI/DP audio jack handling ALSA: hda - Move audio component accesses to hdac_i915.c drivers/gpu/drm/i915/i915_drv.h| 2 + drivers/gpu/drm/i915/intel_audio.c | 59 +++-- drivers/gpu/drm/i915/intel_ddi.c | 1 + drivers/gpu/drm/i915/intel_dp.c| 1 + drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_hdmi.c | 2 + include/drm/i915_component.h | 14 + include/sound/hda_i915.h | 14 + sound/hda/hdac_i915.c | 66 +++ sound/pci/hda/patch_hdmi.c | 104 ++--- 10 files changed, 229 insertions(+), 36 deletions(-) -- 2.6.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Separate cherryview from valleyview
On Fri, Dec 04, 2015 at 05:51:56PM +0100, Daniel Vetter wrote: > On Fri, Dec 04, 2015 at 04:15:27PM +, Vivi, Rodrigo wrote: > > On Fri, 2015-12-04 at 16:05 +0100, Daniel Vetter wrote: > > > On Wed, Dec 02, 2015 at 02:30:28PM +0200, Jani Nikula wrote: > > > > On Wed, 02 Dec 2015, Ville Syrjälä > > > > wrote: > > > > > On Tue, Dec 01, 2015 at 05:11:40PM -0800, Wayne Boyer wrote: > > > > > > The cherryview device shares many characteristics with the > > > > > > valleyview > > > > > > device. When support was added to the driver for cherryview, > > > > > > the > > > > > > corresponding device info structure included .is_valleyview = > > > > > > 1. > > > > > > This is not correct and leads to some confusion. > > > > > > > > > > > > This patch changes .is_valleyview to .is_cherryview in the > > > > > > cherryview > > > > > > device info structure and defines the HAS_GEN7_LP_FEATURES > > > > > > macro. > > > > > > Then where appropriate, instances of IS_VALLEYVIEW are replaced > > > > > > with > > > > > > HAS_GEN7_LP_FEATURES to test for either a valleyview or a > > > > > > cherryview > > > > > > device. > > > > > > > > > > I don't like the name of the macro. Most of the shared bits are > > > > > display > > > > > related, so we could have something like HAS_VLV_DISPLAY. For the > > > > > rest, > > > > > I think we could just test IS_VLV||IS_CHV explicitly. Unless > > > > > someone > > > > > can come up with a better name that covers everything? > > > > > > > > Definitely NAK on HAS_GEN7_LP_FEATURES. > > > > > > > > HAS_VLV_DISPLAY would be a subset of HAS_GMCH_DISPLAY, which I > > > > guess > > > > wouldn't be that bad... unless someone starts using that for a > > > > VLV||CHV > > > > shorthand in non-display code. > > > > > > > > I think I might just go for the verbose (IS_VALLEYVIEW || > > > > IS_CHERRYVIEW) > > > > all around. Especially since we've been brainwashed with the old > > > > vlv is > > > > both vlv and chv code. > > > > > > HAS_GMCH_DISPLAY is what I've generally used, since usually you have > > > a > > > INTEL_INFO()->gen >= 5 test already somewhere. If we want to make > > > this > > > more explicit the proper name for vlv is BAYTRAIL, and for truely byt > > > specific stuff we've named things byt_. So what about Defining an > > > IS_BAYTRAIL instead for the cases where it's not vlv || chv. > > > > Baytrail is the platform name with the Valleyview graphics. Than we > > would have Cherry Trail and/or Braswell for Cherryview graphics and > > Apollo Lake for Broxton. So I would vote to stay with Valleyview, > > Cherryview and Broxton only. > > > > > > > > And what's the benefit of all this churn? > > > > Organize and prepare the code for future platforms. > > Avoid more confusion like we had on IS_SKYLAKE x IS_KABYLAKE. > > Make things more easy and clear if we decide to add .is_atom_lp on > > these platforms definition. > > .is_atom_lp is imo the more sensible change to do, since it includes bxt. BXT vs. VLV/CHV have practically nothing in common in the driver, so I wouldn't go there. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Updated drm-intel-testing
Hi all, New -testing cycle with cool stuff: This is the "fix igt basic test set issues" edition. - more PSR fixes from Rodrigo, getting closer - tons of fifo underrun fixes from Ville - runtime pm fixes from Imre, Daniel Stone - fix SDE interrupt handling properly (Jani Nikula) - hsw/bdw fdi modeset sequence fixes (Ville) - "don't register bad VGA connectors and fall over" fixes (Ville) - more fbc fixes from Paulo - and a grand total of exactly one feature item: Implement dma-buf/fence based cross-driver sync in the i915 pageflip path (Alex Goins) Happy testing! Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 3/3] drm/i915: Use the ceil value for the additional clk divider
> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Friday, December 4, 2015 5:22 PM > To: Deepak, M > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 3/3] drm/i915: Use the ceil value for the > additional clk divider > > On Fri, Dec 04, 2015 at 07:47:39PM +0530, Deepak M wrote: > > Additional clock value divider should use the ceil value of the > > calulation to get the correct divider value. > > > > Signed-off-by: Deepak M > > --- > > drivers/gpu/drm/i915/intel_dsi_pll.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c > > b/drivers/gpu/drm/i915/intel_dsi_pll.c > > index cb3cf39..1322a71 100644 > > --- a/drivers/gpu/drm/i915/intel_dsi_pll.c > > +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c > > @@ -454,7 +454,7 @@ static void bxt_dsi_program_clocks(struct > drm_device *dev, enum port port) > > dsi_rate = (BXT_REF_CLOCK_KHZ * pll_ratio) / 2; > > > > /* Max possible output of clock is 39.5 MHz, program value -1 */ > > - divider = (dsi_rate / BXT_MAX_VAR_OUTPUT_KHZ) - 1; > > + divider = DIV_ROUND_UP(dsi_rate, BXT_MAX_VAR_OUTPUT_KHZ) - > 1; > > I can't find anything to support the 39.5 MHz claim above. I do know the tx > escape clock should be <=20Mhz, so with the /2 extra divider it seems we > should aim for <=40Mhz here. So yes, round up does make sense, but it > seems to me that BXT_MAX_VAR_OUTPUT_KHZ should be 40 MHz. > [Deepak, M] Yes, thought about it and me too feel that it should be 40 MHz. We locally have tried with 2 different MIPI panels with 39.5 Mhz and didn't see any issue. I will confirm with SV teams and will update the patch accordingly. Thanks for pointing it :) > > tmp |= BXT_MIPI_ESCLK_VAR_DIV(port, divider); > > > > /* > > -- > > 1.9.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] drm/i915: Enable PSR by default.
On Fri, 2015-12-04 at 17:54 +0100, Daniel Vetter wrote:
> On Fri, Dec 04, 2015 at 04:22:20PM +, Vivi, Rodrigo wrote:
> > On Fri, 2015-12-04 at 16:31 +0100, Daniel Vetter wrote:
> > > On Wed, Dec 02, 2015 at 08:08:30AM -0800, Rodrigo Vivi wrote:
> > > > With a reliable frontbuffer tracking and all instability corner
> > > > cases
> > > > solved let's re-enabled PSR by default on all supported
> > > > platforms.
> > > >
> > > > Signed-off-by: Rodrigo Vivi
> > >
> > > Hm, one thing we're missing here still I think is that right now
> > > there's
> > > not yet a BAT for psr.
> >
> > Yes, agree.
> >
> > > At least I didn't spot anything in the CI overview.
> > > Is there a super-basic PSR testcase (just checking that we go
> > > into
> > > psr
> > > self-refresh is imo good enough), similar to what we have with
> > > runtime PM?
> >
> > we had that in the past but in the end I removed. Maybe get it back
> > and
> > call basic. But also we could have few cases like page_flip,
> > mmap_gtt
> > and mmap_cpu as BAT as well. What do you think?
>
> BAT is already taking a while to run, and any modeset tests we add
> take
> away more time. I think just a basic one should be good enough for
> BAT.
> Imo BAT really should be just the "is this total crap?" test. We will
> still run full igt (at least that's my goal) on any patch that goes
> in,
> with the goal to run all the fast tests (less than 1 minute or so)
> pre-merge. In this glorious future BAT will only decide whether more
> tests
> should even be started.
Makes sense.
>
> > > Also I guess we need to get the dp aux series from you in first.
> >
> > Actually I believe the only required patch there is that one that
> > check
> > for message size. Would you accept split that patch from that
> > series
> > for now with a FIXME?
> > I promisse I won't give up on killing intel_dp_dpcd_read_wake ;)
>
> Makes sense I'd say.
Thanks!
>
> Cheers, Daniel
> >
> > > With BAT
> > > and outstanding series merged:
> > >
> > > Acked-by: Daniel Vetter
> > >
> > > Awesome work!
> > >
> > > Cheers, Daniel
> >
> > Thank you very much!
> > Rodrigo.
> >
> > > > ---
> > > > drivers/gpu/drm/i915/i915_params.c | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_params.c
> > > > b/drivers/gpu/drm/i915/i915_params.c
> > > > index 835d609..461c326 100644
> > > > --- a/drivers/gpu/drm/i915/i915_params.c
> > > > +++ b/drivers/gpu/drm/i915/i915_params.c
> > > > @@ -37,7 +37,7 @@ struct i915_params i915 __read_mostly = {
> > > > .enable_execlists = -1,
> > > > .enable_hangcheck = true,
> > > > .enable_ppgtt = -1,
> > > > - .enable_psr = 0,
> > > > + .enable_psr = 1,
> > > > .preliminary_hw_support =
> > > > IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
> > > > .disable_power_well = -1,
> > > > .enable_ips = 1,
> > > > @@ -126,7 +126,7 @@ MODULE_PARM_DESC(enable_execlists,
> > > > "(-1=auto [default], 0=disabled, 1=enabled)");
> > > >
> > > > module_param_named_unsafe(enable_psr, i915.enable_psr, int,
> > > > 0600);
> > > > -MODULE_PARM_DESC(enable_psr, "Enable PSR (default: false)");
> > > > +MODULE_PARM_DESC(enable_psr, "Enable PSR (default: true)");
> > > >
> > > > module_param_named_unsafe(preliminary_hw_support,
> > > > i915.preliminary_hw_support, int, 0600);
> > > > MODULE_PARM_DESC(preliminary_hw_support,
> > > > --
> > > > 2.4.3
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable PSR by default.
On Fri, Dec 04, 2015 at 04:22:20PM +, Vivi, Rodrigo wrote:
> On Fri, 2015-12-04 at 16:31 +0100, Daniel Vetter wrote:
> > On Wed, Dec 02, 2015 at 08:08:30AM -0800, Rodrigo Vivi wrote:
> > > With a reliable frontbuffer tracking and all instability corner
> > > cases
> > > solved let's re-enabled PSR by default on all supported platforms.
> > >
> > > Signed-off-by: Rodrigo Vivi
> >
> > Hm, one thing we're missing here still I think is that right now
> > there's
> > not yet a BAT for psr.
>
> Yes, agree.
>
> > At least I didn't spot anything in the CI overview.
> > Is there a super-basic PSR testcase (just checking that we go into
> > psr
> > self-refresh is imo good enough), similar to what we have with
> > runtime PM?
>
> we had that in the past but in the end I removed. Maybe get it back and
> call basic. But also we could have few cases like page_flip, mmap_gtt
> and mmap_cpu as BAT as well. What do you think?
BAT is already taking a while to run, and any modeset tests we add take
away more time. I think just a basic one should be good enough for BAT.
Imo BAT really should be just the "is this total crap?" test. We will
still run full igt (at least that's my goal) on any patch that goes in,
with the goal to run all the fast tests (less than 1 minute or so)
pre-merge. In this glorious future BAT will only decide whether more tests
should even be started.
> > Also I guess we need to get the dp aux series from you in first.
>
> Actually I believe the only required patch there is that one that check
> for message size. Would you accept split that patch from that series
> for now with a FIXME?
> I promisse I won't give up on killing intel_dp_dpcd_read_wake ;)
Makes sense I'd say.
Cheers, Daniel
>
> > With BAT
> > and outstanding series merged:
> >
> > Acked-by: Daniel Vetter
> >
> > Awesome work!
> >
> > Cheers, Daniel
>
> Thank you very much!
> Rodrigo.
>
> > > ---
> > > drivers/gpu/drm/i915/i915_params.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_params.c
> > > b/drivers/gpu/drm/i915/i915_params.c
> > > index 835d609..461c326 100644
> > > --- a/drivers/gpu/drm/i915/i915_params.c
> > > +++ b/drivers/gpu/drm/i915/i915_params.c
> > > @@ -37,7 +37,7 @@ struct i915_params i915 __read_mostly = {
> > > .enable_execlists = -1,
> > > .enable_hangcheck = true,
> > > .enable_ppgtt = -1,
> > > - .enable_psr = 0,
> > > + .enable_psr = 1,
> > > .preliminary_hw_support =
> > > IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
> > > .disable_power_well = -1,
> > > .enable_ips = 1,
> > > @@ -126,7 +126,7 @@ MODULE_PARM_DESC(enable_execlists,
> > > "(-1=auto [default], 0=disabled, 1=enabled)");
> > >
> > > module_param_named_unsafe(enable_psr, i915.enable_psr, int, 0600);
> > > -MODULE_PARM_DESC(enable_psr, "Enable PSR (default: false)");
> > > +MODULE_PARM_DESC(enable_psr, "Enable PSR (default: true)");
> > >
> > > module_param_named_unsafe(preliminary_hw_support,
> > > i915.preliminary_hw_support, int, 0600);
> > > MODULE_PARM_DESC(preliminary_hw_support,
> > > --
> > > 2.4.3
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Add get_eld audio component
On Fri, 04 Dec 2015 17:49:43 +0100, Daniel Vetter wrote: > > On Fri, Dec 04, 2015 at 05:27:12PM +0100, Takashi Iwai wrote: > > On Fri, 04 Dec 2015 17:20:15 +0100, > > Takashi Iwai wrote: > > > > > > On Fri, 04 Dec 2015 17:15:59 +0100, > > > Daniel Vetter wrote: > > > > > > > > On Fri, Dec 04, 2015 at 05:03:55PM +0100, Takashi Iwai wrote: > > > > > On Fri, 04 Dec 2015 16:54:32 +0100, > > > > > Daniel Vetter wrote: > > > > > > > > > > > > On Fri, Dec 04, 2015 at 04:15:24PM +0100, Takashi Iwai wrote: > > > > > > > diff --git a/include/drm/i915_component.h > > > > > > > b/include/drm/i915_component.h > > > > > > > index 30d89e0da2c6..058d39e8d57f 100644 > > > > > > > --- a/include/drm/i915_component.h > > > > > > > +++ b/include/drm/i915_component.h > > > > > > > @@ -38,6 +38,7 @@ > > > > > > > * @codec_wake_override: Enable/Disable generating the codec > > > > > > > wake signal > > > > > > > * @get_cdclk_freq: get the Core Display Clock in KHz > > > > > > > * @sync_audio_rate: set n/cts based on the sample rate > > > > > > > + * @get_eld: fill the audio state and ELD bytes for the given > > > > > > > port > > > > > > > > > > > > One more: You seem to still be on an old baseline, with switched to > > > > > > the > > > > > > new in-line comment layout. That allows you to spec the callback > > > > > > semantics > > > > > > in much more detail since it allows real paragraphs. > > > > > > > > > > Yes, I've been waiting for your (or Dave's) answer to my previous > > > > > question: which branch can I use as a solid base? > > > > > > > > Ooops sorry. drm-next is now open and has everything you need. > > > > > > > > git://people.freedesktop.org/~airlied/linux drm-next > > > > > > Thanks, I'll rebase on it. > > > > Hmm, this branch gives a compile warning: > > > > drivers/gpu/drm/i915/intel_display.c:5217:0: warning: > > "for_each_power_domain" redefined > > #define for_each_power_domain(domain, mask)\ > > ^ > > In file included from drivers/gpu/drm/i915/intel_drv.h:32:0, > > from drivers/gpu/drm/i915/intel_display.c:36: > > drivers/gpu/drm/i915/i915_drv.h:312:0: note: this is the location of the > > previous definition > > #define for_each_power_domain(domain, mask)\ > > ^ > > LD [M] drivers/gpu/drm/i915/i915.o > > Hilarious merge fail on my side, the patch to fix it up is queued in > drm-intel.git. I'll send a pull request for that to Dave end of next week > or so. Alright. Meanwhile I rebased the patchset, and it's enough for review, at least. I can rebase again at the final merge time to the fixed branch. thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Separate cherryview from valleyview
On Fri, Dec 04, 2015 at 04:15:27PM +, Vivi, Rodrigo wrote: > On Fri, 2015-12-04 at 16:05 +0100, Daniel Vetter wrote: > > On Wed, Dec 02, 2015 at 02:30:28PM +0200, Jani Nikula wrote: > > > On Wed, 02 Dec 2015, Ville Syrjälä > > > wrote: > > > > On Tue, Dec 01, 2015 at 05:11:40PM -0800, Wayne Boyer wrote: > > > > > The cherryview device shares many characteristics with the > > > > > valleyview > > > > > device. When support was added to the driver for cherryview, > > > > > the > > > > > corresponding device info structure included .is_valleyview = > > > > > 1. > > > > > This is not correct and leads to some confusion. > > > > > > > > > > This patch changes .is_valleyview to .is_cherryview in the > > > > > cherryview > > > > > device info structure and defines the HAS_GEN7_LP_FEATURES > > > > > macro. > > > > > Then where appropriate, instances of IS_VALLEYVIEW are replaced > > > > > with > > > > > HAS_GEN7_LP_FEATURES to test for either a valleyview or a > > > > > cherryview > > > > > device. > > > > > > > > I don't like the name of the macro. Most of the shared bits are > > > > display > > > > related, so we could have something like HAS_VLV_DISPLAY. For the > > > > rest, > > > > I think we could just test IS_VLV||IS_CHV explicitly. Unless > > > > someone > > > > can come up with a better name that covers everything? > > > > > > Definitely NAK on HAS_GEN7_LP_FEATURES. > > > > > > HAS_VLV_DISPLAY would be a subset of HAS_GMCH_DISPLAY, which I > > > guess > > > wouldn't be that bad... unless someone starts using that for a > > > VLV||CHV > > > shorthand in non-display code. > > > > > > I think I might just go for the verbose (IS_VALLEYVIEW || > > > IS_CHERRYVIEW) > > > all around. Especially since we've been brainwashed with the old > > > vlv is > > > both vlv and chv code. > > > > HAS_GMCH_DISPLAY is what I've generally used, since usually you have > > a > > INTEL_INFO()->gen >= 5 test already somewhere. If we want to make > > this > > more explicit the proper name for vlv is BAYTRAIL, and for truely byt > > specific stuff we've named things byt_. So what about Defining an > > IS_BAYTRAIL instead for the cases where it's not vlv || chv. > > Baytrail is the platform name with the Valleyview graphics. Than we > would have Cherry Trail and/or Braswell for Cherryview graphics and > Apollo Lake for Broxton. So I would vote to stay with Valleyview, > Cherryview and Broxton only. > > > > > And what's the benefit of all this churn? > > Organize and prepare the code for future platforms. > Avoid more confusion like we had on IS_SKYLAKE x IS_KABYLAKE. > Make things more easy and clear if we decide to add .is_atom_lp on > these platforms definition. .is_atom_lp is imo the more sensible change to do, since it includes bxt. What would that look like (maybe as patch series)? And if it's prep work for future platforms, the patch series should mention that (without mentioning the platform name/gen ofc). I usually know, but sometimes it's hard to guess ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 2/9] drm/i915: Add get_eld audio component
On Fri, Dec 04, 2015 at 05:27:12PM +0100, Takashi Iwai wrote: > On Fri, 04 Dec 2015 17:20:15 +0100, > Takashi Iwai wrote: > > > > On Fri, 04 Dec 2015 17:15:59 +0100, > > Daniel Vetter wrote: > > > > > > On Fri, Dec 04, 2015 at 05:03:55PM +0100, Takashi Iwai wrote: > > > > On Fri, 04 Dec 2015 16:54:32 +0100, > > > > Daniel Vetter wrote: > > > > > > > > > > On Fri, Dec 04, 2015 at 04:15:24PM +0100, Takashi Iwai wrote: > > > > > > diff --git a/include/drm/i915_component.h > > > > > > b/include/drm/i915_component.h > > > > > > index 30d89e0da2c6..058d39e8d57f 100644 > > > > > > --- a/include/drm/i915_component.h > > > > > > +++ b/include/drm/i915_component.h > > > > > > @@ -38,6 +38,7 @@ > > > > > > * @codec_wake_override: Enable/Disable generating the codec wake > > > > > > signal > > > > > > * @get_cdclk_freq: get the Core Display Clock in KHz > > > > > > * @sync_audio_rate: set n/cts based on the sample rate > > > > > > + * @get_eld: fill the audio state and ELD bytes for the given port > > > > > > > > > > One more: You seem to still be on an old baseline, with switched to > > > > > the > > > > > new in-line comment layout. That allows you to spec the callback > > > > > semantics > > > > > in much more detail since it allows real paragraphs. > > > > > > > > Yes, I've been waiting for your (or Dave's) answer to my previous > > > > question: which branch can I use as a solid base? > > > > > > Ooops sorry. drm-next is now open and has everything you need. > > > > > > git://people.freedesktop.org/~airlied/linux drm-next > > > > Thanks, I'll rebase on it. > > Hmm, this branch gives a compile warning: > > drivers/gpu/drm/i915/intel_display.c:5217:0: warning: "for_each_power_domain" > redefined > #define for_each_power_domain(domain, mask)\ > ^ > In file included from drivers/gpu/drm/i915/intel_drv.h:32:0, > from drivers/gpu/drm/i915/intel_display.c:36: > drivers/gpu/drm/i915/i915_drv.h:312:0: note: this is the location of the > previous definition > #define for_each_power_domain(domain, mask)\ > ^ > LD [M] drivers/gpu/drm/i915/i915.o Hilarious merge fail on my side, the patch to fix it up is queued in drm-intel.git. I'll send a pull request for that to Dave end of next week or so. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Revert "drm/i915: Extend LRC pinning to cover GPU context writeback"
This reverts commit 6d65ba943a2d1e4292a07ca7ddb6c5138b9efa5d.
Mika Kuoppala traced down a use-after-free crash in module unload to
this commit, because ring->last_context is leaked beyond when the
context gets destroyed. Mika submitted a quick fix to patch that up in
the context destruction code, but that's too much of a hack.
The right fix is instead for the ring to hold a full reference onto
it's last context, like we do for legacy contexts.
Since this is causing a regression in BAT it gets reverted before we
can close this.
Cc: Nick Hoath
Cc: Daniel Vetter
Cc: David Gordon
Cc: Chris Wilson
Cc: Alex Dai
Cc: Mika Kuoppala
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 7 +-
drivers/gpu/drm/i915/intel_lrc.c | 136 +++
drivers/gpu/drm/i915/intel_lrc.h | 1 -
4 files changed, 27 insertions(+), 118 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f95f36767649..5e276f5d61da 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -884,7 +884,6 @@ struct intel_context {
struct {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
- bool dirty;
int pin_count;
} engine[I915_NUM_RINGS];
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ef4dbe3d442d..a531cb83295c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1354,9 +1354,6 @@ static void i915_gem_request_retire(struct
drm_i915_gem_request *request)
{
trace_i915_gem_request_retire(request);
- if (i915.enable_execlists)
- intel_lr_context_complete_check(request);
-
/* We know the GPU must have read the request to have
* sent us the seqno + interrupt, so use the position
* of tail of the request to update the last known position
@@ -2767,6 +2764,10 @@ static void i915_gem_reset_ring_cleanup(struct
drm_i915_private *dev_priv,
struct drm_i915_gem_request,
execlist_link);
list_del(&submit_req->execlist_link);
+
+ if (submit_req->ctx != ring->default_context)
+ intel_lr_context_unpin(submit_req);
+
i915_gem_request_unreference(submit_req);
}
spin_unlock_irq(&ring->execlist_lock);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c3504a09340c..4ebafab53f30 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -571,6 +571,9 @@ static int execlists_context_queue(struct
drm_i915_gem_request *request)
struct drm_i915_gem_request *cursor;
int num_elements = 0;
+ if (request->ctx != ring->default_context)
+ intel_lr_context_pin(request);
+
i915_gem_request_reference(request);
spin_lock_irq(&ring->execlist_lock);
@@ -734,13 +737,6 @@ intel_logical_ring_advance_and_submit(struct
drm_i915_gem_request *request)
if (intel_ring_stopped(ring))
return;
- if (request->ctx != ring->default_context) {
- if (!request->ctx->engine[ring->id].dirty) {
- intel_lr_context_pin(request);
- request->ctx->engine[ring->id].dirty = true;
- }
- }
-
if (dev_priv->guc.execbuf_client)
i915_guc_submit(dev_priv->guc.execbuf_client, request);
else
@@ -967,6 +963,12 @@ void intel_execlists_retire_requests(struct
intel_engine_cs *ring)
spin_unlock_irq(&ring->execlist_lock);
list_for_each_entry_safe(req, tmp, &retired_list, execlist_link) {
+ struct intel_context *ctx = req->ctx;
+ struct drm_i915_gem_object *ctx_obj =
+ ctx->engine[ring->id].state;
+
+ if (ctx_obj && (ctx != ring->default_context))
+ intel_lr_context_unpin(req);
list_del(&req->execlist_link);
i915_gem_request_unreference(req);
}
@@ -1061,39 +1063,21 @@ reset_pin_count:
return ret;
}
-static void __intel_lr_context_unpin(struct intel_engine_cs *ring,
- struct intel_context *ctx)
+void intel_lr_context_unpin(struct drm_i915_gem_request *rq)
{
- struct drm_i915_gem_object *ctx_obj = ctx->engine[ring->id].state;
- struct intel_ringbuffer *ringbuf = ctx->engine[ring->id].ringbuf;
+ struct intel_engine_cs *ring = rq->ring;
+ struct drm_i915_gem_object *ctx_obj = rq->ctx->engine[ring->id].state;
+ struct intel_ringbuffer *ringbuf = rq->ringbuf;
+
if (ctx_obj) {
WARN_ON(!mutex_is_locked(&ring->dev->struct_mutex));
- i
Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Add get_eld audio component
On Fri, 04 Dec 2015 17:20:15 +0100, Takashi Iwai wrote: > > On Fri, 04 Dec 2015 17:15:59 +0100, > Daniel Vetter wrote: > > > > On Fri, Dec 04, 2015 at 05:03:55PM +0100, Takashi Iwai wrote: > > > On Fri, 04 Dec 2015 16:54:32 +0100, > > > Daniel Vetter wrote: > > > > > > > > On Fri, Dec 04, 2015 at 04:15:24PM +0100, Takashi Iwai wrote: > > > > > diff --git a/include/drm/i915_component.h > > > > > b/include/drm/i915_component.h > > > > > index 30d89e0da2c6..058d39e8d57f 100644 > > > > > --- a/include/drm/i915_component.h > > > > > +++ b/include/drm/i915_component.h > > > > > @@ -38,6 +38,7 @@ > > > > > * @codec_wake_override: Enable/Disable generating the codec wake > > > > > signal > > > > > * @get_cdclk_freq: get the Core Display Clock in KHz > > > > > * @sync_audio_rate: set n/cts based on the sample rate > > > > > + * @get_eld: fill the audio state and ELD bytes for the given port > > > > > > > > One more: You seem to still be on an old baseline, with switched to the > > > > new in-line comment layout. That allows you to spec the callback > > > > semantics > > > > in much more detail since it allows real paragraphs. > > > > > > Yes, I've been waiting for your (or Dave's) answer to my previous > > > question: which branch can I use as a solid base? > > > > Ooops sorry. drm-next is now open and has everything you need. > > > > git://people.freedesktop.org/~airlied/linux drm-next > > Thanks, I'll rebase on it. Hmm, this branch gives a compile warning: drivers/gpu/drm/i915/intel_display.c:5217:0: warning: "for_each_power_domain" redefined #define for_each_power_domain(domain, mask)\ ^ In file included from drivers/gpu/drm/i915/intel_drv.h:32:0, from drivers/gpu/drm/i915/intel_display.c:36: drivers/gpu/drm/i915/i915_drv.h:312:0: note: this is the location of the previous definition #define for_each_power_domain(domain, mask)\ ^ LD [M] drivers/gpu/drm/i915/i915.o Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Take care of ring->last_context on ctx destroy
On Fri, Dec 04, 2015 at 05:52:43PM +0200, Mika Kuoppala wrote: > If the context being destroyed have been last in the ring, > the ring->last_context will be left dangling. > > Later, the unpinning will happen for last_context, and as it > was already freed, we corrupt memory by doing so. > > This regression introduced in > commit 6d65ba943a2d1e4292a07ca7ddb6c5138b9efa5d > Author: Nick Hoath > Date: Tue Dec 1 14:48:57 2015 + > > drm/i915: Extend LRC pinning to cover GPU context writeback > > Fix this by clearing the ring->last_context if it is the > context being destroyed. > > Cc: Nick Hoath > Cc: Daniel Vetter > Cc: David Gordon > Cc: Chris Wilson > Cc: Alex Dai > Signed-off-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/intel_lrc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > b/drivers/gpu/drm/i915/intel_lrc.c > index c3504a0..5c26fde 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.c > +++ b/drivers/gpu/drm/i915/intel_lrc.c > @@ -2432,6 +2432,9 @@ intel_lr_context_clean_ring(struct intel_context *ctx, > } > } > > + if (ring->last_context == ctx) > + ring->last_context = NULL; This should be plainly impossible. ring->last_context better have a reference on it, and if that's not the case we need to fix that. Nick, can you please take a look into this asap? It's causing a BAT regression so meanwhile I'll revert your patch. Thanks, Daniel > + > WARN_ON(ctx->engine[ring->id].pin_count); > intel_ringbuffer_free(ringbuf); > drm_gem_object_unreference(&ctx_obj->base); > -- > 2.5.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Correct the Ref clock value for BXT
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Friday, December 4, 2015 9:52 PM
> To: Ville Syrjälä
> Cc: Deepak, M ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915: Correct the Ref clock value for
> BXT
>
> On Fri, Dec 04, 2015 at 11:55:56AM +0200, Ville Syrjälä wrote:
> > On Fri, Dec 04, 2015 at 07:47:38PM +0530, Deepak M wrote:
> > > The reference clock for BXT is 19.2 MHz not 19.5 MHz, updating the
> > > correct value here.
> > >
> > > Signed-off-by: Deepak M
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h index 8bd2699..009f474 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -7676,7 +7676,7 @@ enum skl_disp_power_wells {
> > > #define BXT_DSI_PLL_RATIO_MAX0x7D
> > > #define BXT_DSI_PLL_RATIO_MIN0x22
> > > #define BXT_DSI_PLL_RATIO_MASK 0xFF
> > > -#define BXT_REF_CLOCK_KHZ19500
> > > +#define BXT_REF_CLOCK_KHZ19200
> >
> > No idea why we have this define in i915_reg.h. We don't have such
> > defines for other platforms (also my fix CHV refclk to 19.2MHz patch
> > never got reviewed by anyone either. Interedted?)
>
> Add link and I think Deepak is volunteered ;-)
> >
[Deepak, M] Please share the link, I can go through the patch :)
> > Reviewed-by: Ville Syrjälä
>
> Queued for -next, thanks for the patch.
> -Daniel
> >
> > >
> > > #define BXT_DSI_PLL_ENABLE 0x46080
> > > #define BXT_DSI_PLL_DO_ENABLE (1 << 31)
> > > --
> > > 1.9.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
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> 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] drm/i915: Avoid writing relocs with addresses in non-canonical form
On Fri, Dec 04, 2015 at 04:20:43PM +0100, Michał Winiarski wrote:
> According to bspec, some parts of HW expect the addresses to be in
> a canonical form, where bits [63:48] == [47]. Let's convert addresses to
> canonical form prior to relocating and return converted offsets to
> userspace.
>
> v2: Whitespace fixup, gen8_canonical_addr description (Chris, Ville)
>
> Cc: Chris Wilson
> Cc: Michel Thierry
> Cc: Ville Syrjälä
> Signed-off-by: Michał Winiarski
Can we igt this? Maybe with softpin or whatever ... For cpu address space
negative addresses are for the kernel, but I think on the gpu we can do
them.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +---
> drivers/gpu/drm/i915/i915_gem_gtt.h| 12
> 2 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index a4c243c..ceffef9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -395,7 +395,7 @@ i915_gem_execbuffer_relocate_entry(struct
> drm_i915_gem_object *obj,
> target_i915_obj = target_vma->obj;
> target_obj = &target_vma->obj->base;
>
> - target_offset = target_vma->node.start;
> + target_offset = gen8_canonical_addr(target_vma->node.start);
>
> /* Sandybridge PPGTT errata: We need a global gtt mapping for MI and
>* pipe_control writes because the gpu doesn't properly redirect them
> @@ -583,6 +583,7 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> struct drm_i915_gem_object *obj = vma->obj;
> struct drm_i915_gem_exec_object2 *entry = vma->exec_entry;
> uint64_t flags;
> + uint64_t offset;
> int ret;
>
> flags = PIN_USER;
> @@ -623,8 +624,9 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> entry->flags |= __EXEC_OBJECT_HAS_FENCE;
> }
>
> - if (entry->offset != vma->node.start) {
> - entry->offset = vma->node.start;
> + offset = gen8_canonical_addr(vma->node.start);
> + if (entry->offset != offset) {
> + entry->offset = offset;
> *need_reloc = true;
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index 877c32c..4ea9dab 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -507,6 +507,18 @@ static inline size_t gen8_pte_count(uint64_t address,
> uint64_t length)
> return i915_pte_count(address, length, GEN8_PDE_SHIFT);
> }
>
> +/* Used to convert any address to canonical form.
> + * Starting from gen8, some commands (e.g. STATE_BASE_ADDRESS,
> + * MI_LOAD_REGISTER_MEM and others, see Broadwell PRM Vol2a) expect the
> + * addresses to be in a canonical form:
> + * "GraphicsAddress[63:48] are ignored by the HW and assumed to be in correct
> + * canonical form [63:48] == [47]."
> + */
> +static inline uint64_t gen8_canonical_addr(uint64_t address)
> +{
> + return ((int64_t)address << 16) >> 16;
> +}
> +
> static inline dma_addr_t
> i915_page_dir_dma_addr(const struct i915_hw_ppgtt *ppgtt, const unsigned n)
> {
> --
> 2.5.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Restore skl_gt3 device info
On Fri, Dec 04, 2015 at 03:46:29PM +, Damien Lespiau wrote: > On Fri, Dec 04, 2015 at 04:19:49PM +0100, Daniel Vetter wrote: > > This was broken in > > > > commit 6a8beeffed3b2d33151150e3a03696e697f16d46 > > Author: Wayne Boyer > > Date: Wed Dec 2 13:28:14 2015 -0800 > > > > drm/i915: Clean up device info structure definitions > > > > and I didn't spot this while reviewing. We really need that CI farm up > > asap! > > We had a BAT run on this one: > > http://patchwork.freedesktop.org/series/1360/ > > But no SKL GT3 coverage. Also, what seems to be flaky tests. Hm, still too much trouble with CRC based testcases ... That's not good, given how much we rely on that stuff working for validating KMS features. But at least it's improving I think. -Daneil -- Daniel Vetter Software Engineer, Intel Corporation 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/3] drm/i915: Correct the Ref clock value for BXT
On Fri, Dec 04, 2015 at 11:55:56AM +0200, Ville Syrjälä wrote:
> On Fri, Dec 04, 2015 at 07:47:38PM +0530, Deepak M wrote:
> > The reference clock for BXT is 19.2 MHz not 19.5 MHz, updating the
> > correct value here.
> >
> > Signed-off-by: Deepak M
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 8bd2699..009f474 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7676,7 +7676,7 @@ enum skl_disp_power_wells {
> > #define BXT_DSI_PLL_RATIO_MAX 0x7D
> > #define BXT_DSI_PLL_RATIO_MIN 0x22
> > #define BXT_DSI_PLL_RATIO_MASK 0xFF
> > -#define BXT_REF_CLOCK_KHZ 19500
> > +#define BXT_REF_CLOCK_KHZ 19200
>
> No idea why we have this define in i915_reg.h. We don't have such
> defines for other platforms (also my fix CHV refclk to 19.2MHz patch
> never got reviewed by anyone either. Interedted?)
Add link and I think Deepak is volunteered ;-)
>
> Reviewed-by: Ville Syrjälä
Queued for -next, thanks for the patch.
-Daniel
>
> >
> > #define BXT_DSI_PLL_ENABLE 0x46080
> > #define BXT_DSI_PLL_DO_ENABLE (1 << 31)
> > --
> > 1.9.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
--
Daniel Vetter
Software Engineer, Intel Corporation
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] drm/i915: Enable PSR by default.
On Fri, 2015-12-04 at 16:31 +0100, Daniel Vetter wrote:
> On Wed, Dec 02, 2015 at 08:08:30AM -0800, Rodrigo Vivi wrote:
> > With a reliable frontbuffer tracking and all instability corner
> > cases
> > solved let's re-enabled PSR by default on all supported platforms.
> >
> > Signed-off-by: Rodrigo Vivi
>
> Hm, one thing we're missing here still I think is that right now
> there's
> not yet a BAT for psr.
Yes, agree.
> At least I didn't spot anything in the CI overview.
> Is there a super-basic PSR testcase (just checking that we go into
> psr
> self-refresh is imo good enough), similar to what we have with
> runtime PM?
we had that in the past but in the end I removed. Maybe get it back and
call basic. But also we could have few cases like page_flip, mmap_gtt
and mmap_cpu as BAT as well. What do you think?
>
> Also I guess we need to get the dp aux series from you in first.
Actually I believe the only required patch there is that one that check
for message size. Would you accept split that patch from that series
for now with a FIXME?
I promisse I won't give up on killing intel_dp_dpcd_read_wake ;)
> With BAT
> and outstanding series merged:
>
> Acked-by: Daniel Vetter
>
> Awesome work!
>
> Cheers, Daniel
Thank you very much!
Rodrigo.
> > ---
> > drivers/gpu/drm/i915/i915_params.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_params.c
> > b/drivers/gpu/drm/i915/i915_params.c
> > index 835d609..461c326 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -37,7 +37,7 @@ struct i915_params i915 __read_mostly = {
> > .enable_execlists = -1,
> > .enable_hangcheck = true,
> > .enable_ppgtt = -1,
> > - .enable_psr = 0,
> > + .enable_psr = 1,
> > .preliminary_hw_support =
> > IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
> > .disable_power_well = -1,
> > .enable_ips = 1,
> > @@ -126,7 +126,7 @@ MODULE_PARM_DESC(enable_execlists,
> > "(-1=auto [default], 0=disabled, 1=enabled)");
> >
> > module_param_named_unsafe(enable_psr, i915.enable_psr, int, 0600);
> > -MODULE_PARM_DESC(enable_psr, "Enable PSR (default: false)");
> > +MODULE_PARM_DESC(enable_psr, "Enable PSR (default: true)");
> >
> > module_param_named_unsafe(preliminary_hw_support,
> > i915.preliminary_hw_support, int, 0600);
> > MODULE_PARM_DESC(preliminary_hw_support,
> > --
> > 2.4.3
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/kms_force_connector_basic: Add prune-stale-modes subtest
On Fri, Dec 04, 2015 at 04:08:30PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add a new subtest that makes sure old stale modes get pruned from the
> connector's mode list when the EDID changes.
>
> Signed-off-by: Ville Syrjälä
> ---
> lib/igt_kms.c | 40
> +++
> lib/igt_kms.h | 1 +
> tests/kms_force_connector_basic.c | 40
> +++
> 3 files changed, 81 insertions(+)
>
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index da49f5676641..5d5a95c20106 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -111,6 +111,46 @@ const unsigned char* igt_kms_get_base_edid(void)
> return base_edid;
> }
>
> +#define VFREQ 60
> +#define CLOCK 101000
> +#define HACTIVE 1400
> +#define HBLANK 160
> +#define VACTIVE 1050
> +#define VBLANK 30
> +#define HOFFSET 48
> +#define HPULSE 32
> +#define VOFFSET 3
> +#define VPULSE 4
> +
> +#define HSIZE 52
> +#define VSIZE 30
> +
> +#define EDID_NAME alt_edid
> +#include "igt_edid_template.h"
> +
> +/**
> + * igt_kms_get_alt_edid:
> + *
> + * Get an alternate edid block, which includes the following modes:
> + *
> + * - 1400x1050 60Hz
> + * - 1920x1080 60Hz
> + * - 1280x720 60Hz
> + * - 1024x768 60Hz
> + * - 800x600 60Hz
> + * - 640x480 60Hz
> + *
> + * This can be extended with further features using functions such as
> + * #kmstest_edid_add_3d.
> + *
> + * Returns: an alternate edid block
> + */
> +const unsigned char* igt_kms_get_alt_edid(void)
> +{
> + update_edid_csum(alt_edid);
> +
> + return alt_edid;
> +}
>
> /**
> * SECTION:igt_kms
> diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> index 965c47c1c7f4..94f315fe13e2 100644
> --- a/lib/igt_kms.h
> +++ b/lib/igt_kms.h
> @@ -286,6 +286,7 @@ void igt_reset_connectors(void);
>
> #define EDID_LENGTH 128
> const unsigned char* igt_kms_get_base_edid(void);
> +const unsigned char* igt_kms_get_alt_edid(void);
>
>
> #endif /* __IGT_KMS_H__ */
> diff --git a/tests/kms_force_connector_basic.c
> b/tests/kms_force_connector_basic.c
> index 637f625a852f..f1b2da32dddc 100644
> --- a/tests/kms_force_connector_basic.c
> +++ b/tests/kms_force_connector_basic.c
> @@ -178,6 +178,46 @@ int main(int argc, char **argv)
>
> }
>
> + igt_subtest("prune-stale-modes") {
> + int i;
> +
> + kmstest_force_connector(drm_fd, vga_connector,
> + FORCE_CONNECTOR_ON);
> +
> + /* test pruning of stale modes */
> + kmstest_force_edid(drm_fd, vga_connector,
> +igt_kms_get_alt_edid(), EDID_LENGTH);
> + temp = drmModeGetConnector(drm_fd,
GetConnectorCurrent everywhere please. The helper library inserts a full
GetConnector including probing where needed, no need to blow through a few
msec here again ...
Cheers, Daniel
> +vga_connector->connector_id);
> +
> + for (i = 0; i < temp->count_modes; i++) {
> + if (temp->modes[i].hdisplay == 1400 &&
> + temp->modes[i].vdisplay == 1050)
> + break;
> + }
> + igt_assert_f(i != temp->count_modes, "1400x1050 not on mode
> list\n");
> +
> + drmModeFreeConnector(temp);
> +
> + kmstest_force_edid(drm_fd, vga_connector,
> +igt_kms_get_base_edid(), EDID_LENGTH);
> + temp = drmModeGetConnector(drm_fd,
> +vga_connector->connector_id);
> +
> + for (i = 0; i < temp->count_modes; i++) {
> + if (temp->modes[i].hdisplay == 1400 &&
> + temp->modes[i].vdisplay == 1050)
> + break;
> + }
> + igt_assert_f(i == temp->count_modes, "1400x1050 not pruned from
> mode list\n");
> +
> + drmModeFreeConnector(temp);
> +
> + kmstest_force_edid(drm_fd, vga_connector, NULL, 0);
> + kmstest_force_connector(drm_fd, vga_connector,
> + FORCE_CONNECTOR_UNSPECIFIED);
> + }
> +
> igt_fixture {
> drmModeFreeConnector(vga_connector);
> close(drm_fd);
> --
> 2.4.10
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Add get_eld audio component
On Fri, 04 Dec 2015 17:15:59 +0100, Daniel Vetter wrote: > > On Fri, Dec 04, 2015 at 05:03:55PM +0100, Takashi Iwai wrote: > > On Fri, 04 Dec 2015 16:54:32 +0100, > > Daniel Vetter wrote: > > > > > > On Fri, Dec 04, 2015 at 04:15:24PM +0100, Takashi Iwai wrote: > > > > diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h > > > > index 30d89e0da2c6..058d39e8d57f 100644 > > > > --- a/include/drm/i915_component.h > > > > +++ b/include/drm/i915_component.h > > > > @@ -38,6 +38,7 @@ > > > > * @codec_wake_override: Enable/Disable generating the codec wake > > > > signal > > > > * @get_cdclk_freq: get the Core Display Clock in KHz > > > > * @sync_audio_rate: set n/cts based on the sample rate > > > > + * @get_eld: fill the audio state and ELD bytes for the given port > > > > > > One more: You seem to still be on an old baseline, with switched to the > > > new in-line comment layout. That allows you to spec the callback semantics > > > in much more detail since it allows real paragraphs. > > > > Yes, I've been waiting for your (or Dave's) answer to my previous > > question: which branch can I use as a solid base? > > Ooops sorry. drm-next is now open and has everything you need. > > git://people.freedesktop.org/~airlied/linux drm-next Thanks, I'll rebase on it. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Add get_eld audio component
On Fri, Dec 04, 2015 at 05:03:55PM +0100, Takashi Iwai wrote: > On Fri, 04 Dec 2015 16:54:32 +0100, > Daniel Vetter wrote: > > > > On Fri, Dec 04, 2015 at 04:15:24PM +0100, Takashi Iwai wrote: > > > diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h > > > index 30d89e0da2c6..058d39e8d57f 100644 > > > --- a/include/drm/i915_component.h > > > +++ b/include/drm/i915_component.h > > > @@ -38,6 +38,7 @@ > > > * @codec_wake_override: Enable/Disable generating the codec wake signal > > > * @get_cdclk_freq: get the Core Display Clock in KHz > > > * @sync_audio_rate: set n/cts based on the sample rate > > > + * @get_eld: fill the audio state and ELD bytes for the given port > > > > One more: You seem to still be on an old baseline, with switched to the > > new in-line comment layout. That allows you to spec the callback semantics > > in much more detail since it allows real paragraphs. > > Yes, I've been waiting for your (or Dave's) answer to my previous > question: which branch can I use as a solid base? Ooops sorry. drm-next is now open and has everything you need. git://people.freedesktop.org/~airlied/linux drm-next Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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] drm/i915: Separate cherryview from valleyview
On Fri, 2015-12-04 at 16:05 +0100, Daniel Vetter wrote:
> On Wed, Dec 02, 2015 at 02:30:28PM +0200, Jani Nikula wrote:
> > On Wed, 02 Dec 2015, Ville Syrjälä
> > wrote:
> > > On Tue, Dec 01, 2015 at 05:11:40PM -0800, Wayne Boyer wrote:
> > > > The cherryview device shares many characteristics with the
> > > > valleyview
> > > > device. When support was added to the driver for cherryview,
> > > > the
> > > > corresponding device info structure included .is_valleyview =
> > > > 1.
> > > > This is not correct and leads to some confusion.
> > > >
> > > > This patch changes .is_valleyview to .is_cherryview in the
> > > > cherryview
> > > > device info structure and defines the HAS_GEN7_LP_FEATURES
> > > > macro.
> > > > Then where appropriate, instances of IS_VALLEYVIEW are replaced
> > > > with
> > > > HAS_GEN7_LP_FEATURES to test for either a valleyview or a
> > > > cherryview
> > > > device.
> > >
> > > I don't like the name of the macro. Most of the shared bits are
> > > display
> > > related, so we could have something like HAS_VLV_DISPLAY. For the
> > > rest,
> > > I think we could just test IS_VLV||IS_CHV explicitly. Unless
> > > someone
> > > can come up with a better name that covers everything?
> >
> > Definitely NAK on HAS_GEN7_LP_FEATURES.
> >
> > HAS_VLV_DISPLAY would be a subset of HAS_GMCH_DISPLAY, which I
> > guess
> > wouldn't be that bad... unless someone starts using that for a
> > VLV||CHV
> > shorthand in non-display code.
> >
> > I think I might just go for the verbose (IS_VALLEYVIEW ||
> > IS_CHERRYVIEW)
> > all around. Especially since we've been brainwashed with the old
> > vlv is
> > both vlv and chv code.
>
> HAS_GMCH_DISPLAY is what I've generally used, since usually you have
> a
> INTEL_INFO()->gen >= 5 test already somewhere. If we want to make
> this
> more explicit the proper name for vlv is BAYTRAIL, and for truely byt
> specific stuff we've named things byt_. So what about Defining an
> IS_BAYTRAIL instead for the cases where it's not vlv || chv.
Baytrail is the platform name with the Valleyview graphics. Than we
would have Cherry Trail and/or Braswell for Cherryview graphics and
Apollo Lake for Broxton. So I would vote to stay with Valleyview,
Cherryview and Broxton only.
>
> And what's the benefit of all this churn?
Organize and prepare the code for future platforms.
Avoid more confusion like we had on IS_SKYLAKE x IS_KABYLAKE.
Make things more easy and clear if we decide to add .is_atom_lp on
these platforms definition.
> -Daniel
>
> >
> > BR,
> > Jani.
> >
> > >
> > > >
> > > > Cc: Rodrigo Vivi
> > > > Signed-off-by: Wayne Boyer
> > > > ---
> > > > drivers/gpu/drm/i915/i915_debugfs.c | 14 -
> > > > drivers/gpu/drm/i915/i915_dma.c | 8 ++---
> > > > drivers/gpu/drm/i915/i915_drv.c | 10 +++---
> > > > drivers/gpu/drm/i915/i915_drv.h | 19
> > > > drivers/gpu/drm/i915/i915_gem.c | 4 +--
> > > > drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
> > > > drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
> > > > drivers/gpu/drm/i915/i915_gpu_error.c | 6 ++--
> > > > drivers/gpu/drm/i915/i915_irq.c | 8 ++---
> > > > drivers/gpu/drm/i915/i915_suspend.c | 4 +--
> > > > drivers/gpu/drm/i915/i915_sysfs.c | 10 +++---
> > > > drivers/gpu/drm/i915/intel_audio.c | 6 ++--
> > > > drivers/gpu/drm/i915/intel_crt.c| 4 +--
> > > > drivers/gpu/drm/i915/intel_display.c| 54 -
> > > >
> > > > drivers/gpu/drm/i915/intel_dp.c | 38 +++--
> > > > --
> > > > drivers/gpu/drm/i915/intel_dsi.c| 13
> > > > drivers/gpu/drm/i915/intel_dsi_pll.c| 6 ++--
> > > > drivers/gpu/drm/i915/intel_hdmi.c | 4 +--
> > > > drivers/gpu/drm/i915/intel_hotplug.c| 2 +-
> > > > drivers/gpu/drm/i915/intel_i2c.c| 2 +-
> > > > drivers/gpu/drm/i915/intel_panel.c | 2 +-
> > > > drivers/gpu/drm/i915/intel_pm.c | 8 ++---
> > > > drivers/gpu/drm/i915/intel_psr.c| 4 +--
> > > > drivers/gpu/drm/i915/intel_sprite.c | 4 +--
> > > > drivers/gpu/drm/i915/intel_uncore.c | 6 ++--
> > > > 25 files changed, 123 insertions(+), 117 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > index bfd57fb..a2d50da 100644
> > > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > @@ -862,7 +862,7 @@ static int i915_interrupt_info(struct
> > > > seq_file *m, void *data)
> > > >I915_READ(GEN8_PCU_IIR));
> > > > seq_printf(m, "PCU interrupt enable:\t%08x\n",
> > > >I915_READ(GEN8_PCU_IER));
> > > > - } else if (IS_VALLEYVIEW(dev)) {
> > > > + } else if (HAS_GEN7_LP_FEATURES(dev)) {
> > >
> > > We alredy test for CHV earlier, so this should remain as is.
> > >
[Intel-gfx] [PATCH] drm: Move encoder->save/restore into nouveau
Nouveau is the only user, and atomic drivers should do state
save/restoring differently. So move it into noveau.
Saves me typing some kerneldoc, too ;-)
v2: Move misplaced hunk into earlier nouveau patch.
Cc: Ilia Mirkin
Cc: Ben Skeggs
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/dispnv04/dac.c| 7 +++
drivers/gpu/drm/nouveau/dispnv04/dfp.c| 7 +++
drivers/gpu/drm/nouveau/dispnv04/disp.c | 32 ---
drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 5 +++--
drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 5 +++--
drivers/gpu/drm/nouveau/nouveau_encoder.h | 3 +++
include/drm/drm_modeset_helper_vtables.h | 4
7 files changed, 27 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dac.c
b/drivers/gpu/drm/nouveau/dispnv04/dac.c
index 78cb033bc015..6c442def403d 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dac.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dac.c
@@ -504,8 +504,6 @@ static void nv04_dac_destroy(struct drm_encoder *encoder)
static const struct drm_encoder_helper_funcs nv04_dac_helper_funcs = {
.dpms = nv04_dac_dpms,
- .save = nv04_dac_save,
- .restore = nv04_dac_restore,
.mode_fixup = nv04_dac_mode_fixup,
.prepare = nv04_dac_prepare,
.commit = nv04_dac_commit,
@@ -515,8 +513,6 @@ static const struct drm_encoder_helper_funcs
nv04_dac_helper_funcs = {
static const struct drm_encoder_helper_funcs nv17_dac_helper_funcs = {
.dpms = nv04_dac_dpms,
- .save = nv04_dac_save,
- .restore = nv04_dac_restore,
.mode_fixup = nv04_dac_mode_fixup,
.prepare = nv04_dac_prepare,
.commit = nv04_dac_commit,
@@ -545,6 +541,9 @@ nv04_dac_create(struct drm_connector *connector, struct
dcb_output *entry)
nv_encoder->dcb = entry;
nv_encoder->or = ffs(entry->or) - 1;
+ nv_encoder->enc_save = nv04_dac_save;
+ nv_encoder->enc_restore = nv04_dac_restore;
+
if (nv_gf4_disp_arch(dev))
helper = &nv17_dac_helper_funcs;
else
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
index 429ab5e3025a..4c5fb89d74db 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
@@ -652,8 +652,6 @@ static void nv04_tmds_slave_init(struct drm_encoder
*encoder)
static const struct drm_encoder_helper_funcs nv04_lvds_helper_funcs = {
.dpms = nv04_lvds_dpms,
- .save = nv04_dfp_save,
- .restore = nv04_dfp_restore,
.mode_fixup = nv04_dfp_mode_fixup,
.prepare = nv04_dfp_prepare,
.commit = nv04_dfp_commit,
@@ -663,8 +661,6 @@ static const struct drm_encoder_helper_funcs
nv04_lvds_helper_funcs = {
static const struct drm_encoder_helper_funcs nv04_tmds_helper_funcs = {
.dpms = nv04_tmds_dpms,
- .save = nv04_dfp_save,
- .restore = nv04_dfp_restore,
.mode_fixup = nv04_dfp_mode_fixup,
.prepare = nv04_dfp_prepare,
.commit = nv04_dfp_commit,
@@ -701,6 +697,9 @@ nv04_dfp_create(struct drm_connector *connector, struct
dcb_output *entry)
if (!nv_encoder)
return -ENOMEM;
+ nv_encoder->enc_save = nv04_dfp_save;
+ nv_encoder->enc_restore = nv04_dfp_restore;
+
encoder = to_drm_encoder(nv_encoder);
nv_encoder->dcb = entry;
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 59242ff767ea..b4a6bc433ef5 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -39,6 +39,7 @@ nv04_display_create(struct drm_device *dev)
struct dcb_table *dcb = &drm->vbios.dcb;
struct drm_connector *connector, *ct;
struct drm_encoder *encoder;
+ struct nouveau_encoder *nv_encoder;
struct nouveau_crtc *crtc;
struct nv04_display *disp;
int i, ret;
@@ -110,11 +111,8 @@ nv04_display_create(struct drm_device *dev)
list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head)
crtc->save(&crtc->base);
- list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
- const struct drm_encoder_helper_funcs *func =
encoder->helper_private;
-
- func->save(encoder);
- }
+ list_for_each_entry(nv_encoder, &dev->mode_config.encoder_list,
base.base.head)
+ nv_encoder->enc_save(&nv_encoder->base.base);
nouveau_overlay_init(dev);
@@ -126,7 +124,7 @@ nv04_display_destroy(struct drm_device *dev)
{
struct nv04_display *disp = nv04_display(dev);
struct nouveau_drm *drm = nouveau_drm(dev);
- struct drm_encoder *encoder;
+ struct nouveau_encoder *encoder;
struct drm_crtc *crtc;
struct nouveau_crtc *nv_crtc;
@@ -140,11 +138,8 @@ nv04_display_destroy(struct drm_device *dev)
}
/* Restore state */
- list_for_each_entry(encoder
[Intel-gfx] [PATCH] drm/nouveau: Use private save/restore hooks for CRTCs
I want to remove the core ones since with atomic drivers system
suspend/resume is solved much differently. And there's only 2 drivers
(gma500 besides nouveau) really using them.
v2: Fixup bugs Ilia spotted.
Cc: Ben Skeggs
Cc: Ilia Mirkin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 5 +++--
drivers/gpu/drm/nouveau/dispnv04/disp.c | 11 ++-
drivers/gpu/drm/nouveau/nouveau_crtc.h | 3 +++
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index dab24066fa21..bb9e9cb14b9d 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -1081,8 +1081,6 @@ nouveau_crtc_set_config(struct drm_mode_set *set)
}
static const struct drm_crtc_funcs nv04_crtc_funcs = {
- .save = nv_crtc_save,
- .restore = nv_crtc_restore,
.cursor_set = nv04_crtc_cursor_set,
.cursor_move = nv04_crtc_cursor_move,
.gamma_set = nv_crtc_gamma_set,
@@ -1123,6 +1121,9 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num)
nv_crtc->index = crtc_num;
nv_crtc->last_dpms = NV_DPMS_CLEARED;
+ nv_crtc->save = nv_crtc_save;
+ nv_crtc->restore = nv_crtc_restore;
+
drm_crtc_init(dev, &nv_crtc->base, &nv04_crtc_funcs);
drm_crtc_helper_add(&nv_crtc->base, &nv04_crtc_helper_funcs);
drm_mode_crtc_set_gamma_size(&nv_crtc->base, 256);
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 9e650081c357..59242ff767ea 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -39,7 +39,7 @@ nv04_display_create(struct drm_device *dev)
struct dcb_table *dcb = &drm->vbios.dcb;
struct drm_connector *connector, *ct;
struct drm_encoder *encoder;
- struct drm_crtc *crtc;
+ struct nouveau_crtc *crtc;
struct nv04_display *disp;
int i, ret;
@@ -107,8 +107,8 @@ nv04_display_create(struct drm_device *dev)
}
/* Save previous state */
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
- crtc->funcs->save(crtc);
+ list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head)
+ crtc->save(&crtc->base);
list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
const struct drm_encoder_helper_funcs *func =
encoder->helper_private;
@@ -128,6 +128,7 @@ nv04_display_destroy(struct drm_device *dev)
struct nouveau_drm *drm = nouveau_drm(dev);
struct drm_encoder *encoder;
struct drm_crtc *crtc;
+ struct nouveau_crtc *nv_crtc;
/* Turn every CRTC off. */
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
@@ -145,8 +146,8 @@ nv04_display_destroy(struct drm_device *dev)
func->restore(encoder);
}
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
- crtc->funcs->restore(crtc);
+ list_for_each_entry(nv_crtc, &dev->mode_config.crtc_list, base.head)
+ nv_crtc->restore(&nv_crtc->base);
nouveau_hw_save_vga_fonts(dev, 0);
diff --git a/drivers/gpu/drm/nouveau/nouveau_crtc.h
b/drivers/gpu/drm/nouveau/nouveau_crtc.h
index f19cb1c5fc5a..863f10b8d818 100644
--- a/drivers/gpu/drm/nouveau/nouveau_crtc.h
+++ b/drivers/gpu/drm/nouveau/nouveau_crtc.h
@@ -73,6 +73,9 @@ struct nouveau_crtc {
int (*set_dither)(struct nouveau_crtc *crtc, bool update);
int (*set_scale)(struct nouveau_crtc *crtc, bool update);
int (*set_color_vibrance)(struct nouveau_crtc *crtc, bool update);
+
+ void (*save)(struct drm_crtc *crtc);
+ void (*restore)(struct drm_crtc *crtc);
};
static inline struct nouveau_crtc *nouveau_crtc(struct drm_crtc *crtc)
--
2.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible i915 regression with 4.4-rc
On Fri, 04 Dec 2015 17:02:52 +0100,
Daniel Vetter wrote:
>
> On Fri, Dec 04, 2015 at 11:40:59AM +0200, Ville Syrjälä wrote:
> > On Fri, Dec 04, 2015 at 10:49:48AM +0200, Jani Nikula wrote:
> > > On Thu, 03 Dec 2015, Ville Syrjälä wrote:
> > > > On Thu, Dec 03, 2015 at 09:00:55PM +0100, Takashi Iwai wrote:
> > > >> Hi,
> > > >>
> > > >> I've experienced a few graphics issues recently, and I tend to believe
> > > >> that it has happened since 4.4-rc. Namely, after some long time usage
> > > >> on my HSW laptop (two or three days), the mouse cursor vanished
> > > >> suddenly. It kept pointing but just became invisible. Also, after
> > > >> some S3 cycles, some glyphs on a console or on Firefox became
> > > >> invisible, too. The windows and graphics were shown well, and X core
> > > >> fonts were still shown properly, too. Switching to VT1 and back
> > > >> didn't change the situation.
> > > >
> > > > I think I have a fix for this *very* annoying problem. I'v been cursing
> > > > on irc for weeks about it, until I finally got off my arse and debugged
> > > > it.
> > > >
> > > > I pushed out my my cursor branch:
> > > > git://github.com/vsyrjala/linux.git disappearing_cursor_fix
> > > >
> > > > It has lots of other junk too, but it should be just there two that fix
> > > > it:
> > > > 59f65fa270fb ("drm/i915: Kill intel_crtc->cursor_bo")
> > > > 25651a198d17 ("drm/i915: Drop the broken curcor base==0 special casing")
> > > >
> > > > Unfortunatleey I've managed to keep myself busy on other stuff, so
> > > > didn't
> > > > send them out yet. Maybe tomorrow...
> > >
> > > So I've hit this too, albeit very rarely, on a Haswell running Debian
> > > stable with the stock v3.16 kernel. Haven't seen it on any other
> > > machine. It's really too rare to even debug or verify a fix. Is it
> > > possible we just happened to make an old bug occur more frequently now?
> >
> > The potential for it has definitely been there for a long time.
>
> Oh dear, let's have fun and look at some awful history.
>
> commit e568af1c626031925465a5caaab7cca1303d55c7
> Author: Daniel Vetter
> Date: Wed Mar 26 20:08:20 2014 +0100
>
> drm/i915: Undo gtt scratch pte unmapping again
>
> Which essentially reverted
>
> commit 828c79087cec61eaf4c76bb32c222fbe35ac3930
> Author: Ben Widawsky
> Date: Wed Oct 16 09:21:30 2013 -0700
>
> drm/i915: Disable GGTT PTEs on GEN6+ suspend
>
> Once the machine gets to a certain point in the suspend process, we
> expect the GPU to be idle. If it is not, we might corrupt memory.
> Empirically (with an early version of this patch) we have seen this is
> not the case. We cannot currently explain why the latent GPU writes
> occur.
>
> In the technical sense, this patch is a workaround in that we have an
> issue we can't explain, and the patch indirectly solves the issue.
> However, it's really better than a workaround because we understand why
> it works, and it really should be a safe thing to do in all cases.
>
> The noticeable effect other than the debug messages would be an increase
> in the suspend time. I have not measure how expensive it actually is.
>
> I think it would be good to spend further time to root cause why we're
> seeing these latent writes, but it shouldn't preclude preventing the
> fallout.
>
> NOTE: It should be safe (and makes some sense IMO) to also keep the
> VALID bit unset on resume when we clear_range(). I've opted not to do
> this as properly clearing those bits at some later point would be extra
> work.
>
> v2: Fix bugzilla link
>
> Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=65496
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59321
> Tested-by: Takashi Iwai
> Tested-by: Paulo Zanoni
> Signed-off-by: Ben Widawsky
> Tested-By: Todd Previte
> Cc: sta...@vger.kernel.org
> Signed-off-by: Daniel Vetter
>
> This was a regression in a regression right before I ragequit the entire
> bug handling deal because no one cared any more and management was all
> "why is this important".
>
> Would be interesting if these issues magically disapper when changing that
> back again. Doesn't mean that we're any closer to figuring out what's
> corrupting what exactly here, but at least we'd have a reason to digg out
> this old sob story of mine.
Hm, but this revert was also fairly ago, and I don't remember of the
similar breakage until 4.4-rc. Might be just a (bad) luck, though.
(And no surprise, I was already in the party above! Everyone must
have smoked badly there.)
thanks,
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Disable shrinker for non-swapped backed objects
On Fri, Dec 04, 2015 at 03:58:54PM +, Chris Wilson wrote: > If the system has no available swap pages, we cannot make forward > progress in the shrinker by releasing active pages, only by releasing > purgeable pages which are immediately reaped. Take total_swap_pages into > account when counting up available objects to be shrunk and subsequently > shrinking them. By doing so, we avoid unbinding objects that cannot be > shrunk and so wasting CPU cycles flushing those objects from the GPU to > the system and then immediately back again (as they will more than > likely be reused shortly after). > > Based on a patch by Akash Goel. > > v2: frontswap registers extra swap pages available for the system, so it > is already include in the count of available swap pages. > > v3: Use get_nr_swap_pages() to query the currently available amount of > swap space. This should also stop us from shrinking the GPU buffers if > we ever run out of swap space. Though at that point, we would expect the > oom-notifier to be running and failing miserably... > > Reported-by: Akash Goel > Signed-off-by: Chris Wilson > Cc: linux...@kvack.org > Cc: Akash Goel > Cc: sourab.gu...@intel.com Acked-by: Johannes Weiner ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] mm: Export nr_swap_pages
On Fri, Dec 04, 2015 at 03:58:53PM +, Chris Wilson wrote: > Some modules, like i915.ko, use swappable objects and may try to swap > them out under memory pressure (via the shrinker). Before doing so, they > want to check using get_nr_swap_pages() to see if any swap space is > available as otherwise they will waste time purging the object from the > device without recovering any memory for the system. This requires the > nr_swap_pages counter to be exported to the modules. > > Signed-off-by: Chris Wilson > Cc: "Goel, Akash" > Cc: Johannes Weiner > Cc: linux...@kvack.org Acked-by: Johannes Weiner ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/28] drm/nouveau: Use private save/restore hooks
On Fri, Dec 04, 2015 at 09:31:01AM -0500, Ilia Mirkin wrote:
> On Fri, Dec 4, 2015 at 3:45 AM, Daniel Vetter wrote:
> > I want to remove the core ones since with atomic drivers system
> > suspend/resume is solved much differently. And there's only 2 drivers
> > (gma500 besides nouveau) really using them.
> >
> > Cc: Ben Skeggs
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 5 +++--
> > drivers/gpu/drm/nouveau/dispnv04/disp.c | 11 ++-
> > drivers/gpu/drm/nouveau/nouveau_crtc.h | 3 +++
> > 3 files changed, 12 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> > b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> > index dab24066fa21..bb9e9cb14b9d 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> > @@ -1081,8 +1081,6 @@ nouveau_crtc_set_config(struct drm_mode_set *set)
> > }
> >
> > static const struct drm_crtc_funcs nv04_crtc_funcs = {
> > - .save = nv_crtc_save,
> > - .restore = nv_crtc_restore,
> > .cursor_set = nv04_crtc_cursor_set,
> > .cursor_move = nv04_crtc_cursor_move,
> > .gamma_set = nv_crtc_gamma_set,
> > @@ -1123,6 +1121,9 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num)
> > nv_crtc->index = crtc_num;
> > nv_crtc->last_dpms = NV_DPMS_CLEARED;
> >
> > + nv_crtc->save = nv_crtc_save;
> > + nv_crtc->restore = nv_crtc_restore;
> > +
> > drm_crtc_init(dev, &nv_crtc->base, &nv04_crtc_funcs);
> > drm_crtc_helper_add(&nv_crtc->base, &nv04_crtc_helper_funcs);
> > drm_mode_crtc_set_gamma_size(&nv_crtc->base, 256);
> > diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> > b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> > index 9e650081c357..ebd9430e0628 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> > @@ -39,7 +39,7 @@ nv04_display_create(struct drm_device *dev)
> > struct dcb_table *dcb = &drm->vbios.dcb;
> > struct drm_connector *connector, *ct;
> > struct drm_encoder *encoder;
> > - struct drm_crtc *crtc;
> > + struct nouveau_crtc *crtc;
> > struct nv04_display *disp;
> > int i, ret;
> >
> > @@ -107,8 +107,8 @@ nv04_display_create(struct drm_device *dev)
> > }
> >
> > /* Save previous state */
> > - list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
> > - crtc->funcs->save(crtc);
> > + list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head)
> > + crtc->save(crtc);
>
> Won't this warn about incompatible types? (function wants drm_crtc,
> but you're giving it nouveau_crtc)?
Because I misapplied a hunk and it's in the next nouveau patch ;-)
>
> >
> > list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
> > const struct drm_encoder_helper_funcs *func =
> > encoder->helper_private;
> > @@ -128,6 +128,7 @@ nv04_display_destroy(struct drm_device *dev)
> > struct nouveau_drm *drm = nouveau_drm(dev);
> > struct drm_encoder *encoder;
> > struct drm_crtc *crtc;
> > + struct nouveau_crtc *nv_crtc;
> >
> > /* Turn every CRTC off. */
> > list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> > @@ -145,8 +146,8 @@ nv04_display_destroy(struct drm_device *dev)
> > func->restore(encoder);
> > }
> >
> > - list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
> > - crtc->funcs->restore(crtc);
> > + list_for_each_entry(nv_crtc, &dev->mode_config.crtc_list, base.head)
> > + nv_crtc->restore(crtc);
>
> Why is this OK? Don't you want to use nv_crtc here as the function argument?
Total bullocks and embarrassing. Will resend both.
-Daniel
>
> >
> > nouveau_hw_save_vga_fonts(dev, 0);
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_crtc.h
> > b/drivers/gpu/drm/nouveau/nouveau_crtc.h
> > index f19cb1c5fc5a..863f10b8d818 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_crtc.h
> > +++ b/drivers/gpu/drm/nouveau/nouveau_crtc.h
> > @@ -73,6 +73,9 @@ struct nouveau_crtc {
> > int (*set_dither)(struct nouveau_crtc *crtc, bool update);
> > int (*set_scale)(struct nouveau_crtc *crtc, bool update);
> > int (*set_color_vibrance)(struct nouveau_crtc *crtc, bool update);
> > +
> > + void (*save)(struct drm_crtc *crtc);
> > + void (*restore)(struct drm_crtc *crtc);
> > };
> >
> > static inline struct nouveau_crtc *nouveau_crtc(struct drm_crtc *crtc)
> > --
> > 2.5.1
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel
[Intel-gfx] [PATCH v5] drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping
A long time ago (before 3.14) we relied on a permanent pinning of the
ifbdev to lock the fb in place inside the GGTT. However, the
introduction of stealing the BIOS framebuffer and reusing its address in
the GGTT for the fbdev has muddied waters and we use an inherited fb.
However, the inherited fb is only pinned whilst it is active and we no
longer have an explicit pin for the info->system_base mmapping used by
the fbdev. The result is that after some aperture pressure the fbdev may
be evicted, but we continue to write the fbcon into the same GGTT
address - overwriting anything else that may be put into that offset.
The effect is most pronounced across suspend/resume as
intel_fbdev_set_suspend() does a full clear over the whole scanout.
v2: Only unpin the intel_fb is we allocate it. If we inherit the fb from
the BIOS, we do not own the pinned vma (except for the reference we add
in this patch for our access via info->screen_base).
v3: Finish balancing the vma pinning for the normal !preallocated case.
v4: Try to simplify the pinning even further.
v5: Leak the VMA (cleaned up by object-free) to avoid complicated error paths.
Signed-off-by: Chris Wilson
Cc: "Goel, Akash"
Cc: Daniel Vetter
Cc: Jesse Barnes
Cc: Lukas Wunner
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_fbdev.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 7ccde58f8c98..bea75cafc623 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -163,13 +163,6 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
goto out;
}
- /* Flush everything out, we'll be doing GTT only from now on */
- ret = intel_pin_and_fence_fb_obj(NULL, fb, NULL);
- if (ret) {
- DRM_ERROR("failed to pin obj: %d\n", ret);
- goto out;
- }
-
mutex_unlock(&dev->struct_mutex);
ifbdev->fb = to_intel_framebuffer(fb);
@@ -225,6 +218,14 @@ static int intelfb_create(struct drm_fb_helper *helper,
mutex_lock(&dev->struct_mutex);
+ /* Pin the GGTT vma for our access via info->screen_base.
+* This also validates that any existing fb inherited from the
+* BIOS is suitable for own access.
+*/
+ ret = intel_pin_and_fence_fb_obj(NULL, &ifbdev->fb->base, NULL);
+ if (ret)
+ goto out_unlock;
+
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
DRM_ERROR("Failed to allocate fb_info\n");
@@ -287,6 +288,7 @@ out_destroy_fbi:
drm_fb_helper_release_fbi(helper);
out_unpin:
i915_gem_object_ggtt_unpin(obj);
+out_unlock:
mutex_unlock(&dev->struct_mutex);
return ret;
}
@@ -524,6 +526,10 @@ static const struct drm_fb_helper_funcs
intel_fb_helper_funcs = {
static void intel_fbdev_destroy(struct drm_device *dev,
struct intel_fbdev *ifbdev)
{
+ /* We rely on the object-free to release the VMA pinning for
+* the info->screen_base mmaping. Leaking the VMA is simpler than
+* trying to rectify all the possible error paths leading here.
+*/
drm_fb_helper_unregister_fbi(&ifbdev->helper);
drm_fb_helper_release_fbi(&ifbdev->helper);
--
2.6.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Add get_eld audio component
On Fri, 04 Dec 2015 16:54:32 +0100, Daniel Vetter wrote: > > On Fri, Dec 04, 2015 at 04:15:24PM +0100, Takashi Iwai wrote: > > diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h > > index 30d89e0da2c6..058d39e8d57f 100644 > > --- a/include/drm/i915_component.h > > +++ b/include/drm/i915_component.h > > @@ -38,6 +38,7 @@ > > * @codec_wake_override: Enable/Disable generating the codec wake signal > > * @get_cdclk_freq: get the Core Display Clock in KHz > > * @sync_audio_rate: set n/cts based on the sample rate > > + * @get_eld: fill the audio state and ELD bytes for the given port > > One more: You seem to still be on an old baseline, with switched to the > new in-line comment layout. That allows you to spec the callback semantics > in much more detail since it allows real paragraphs. Yes, I've been waiting for your (or Dave's) answer to my previous question: which branch can I use as a solid base? Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Add get_eld audio component
On Fri, 04 Dec 2015 16:53:02 +0100,
Daniel Vetter wrote:
>
> On Fri, Dec 04, 2015 at 04:15:24PM +0100, Takashi Iwai wrote:
> > On Fri, 04 Dec 2015 16:00:46 +0100,
> > Daniel Vetter wrote:
> > >
> > > On Fri, Dec 04, 2015 at 11:49:46AM +0100, Takashi Iwai wrote:
> > > > On Fri, 04 Dec 2015 11:21:02 +0100,
> > > > Daniel Vetter wrote:
> > > > >
> > > > > On Tue, Dec 01, 2015 at 05:09:51PM +0100, Takashi Iwai wrote:
> > > > > > Implement a new i915_audio_component_ops, get_eld(). It's called by
> > > > > > the audio driver to fetch the current audio status and ELD of the
> > > > > > given HDMI/DP port. It returns the size of expected ELD bytes if
> > > > > > it's
> > > > > > valid, zero if no valid ELD is found, or a negative error code. The
> > > > > > current state of audio on/off is stored in the given pointer, too.
> > > > > >
> > > > > > Note that the returned size isn't limited to the given max bytes.
> > > > > > If
> > > > > > the size is greater than the max bytes, it means that only a part of
> > > > > > ELD has been copied back.
> > > > > >
> > > > > > A big warning about the usage of this callback is: you must not call
> > > > > > it from eld_notify. The eld_notify itself is called in the modeset
> > > > > > lock, and it leads to a deadlock since get_eld takes the modeset
> > > > > > lock,
> > > > > > too. You need to call get_eld in a work, for example, in such a
> > > > > > case.
> > > > > > We'll see the actual implementation in the later patch in
> > > > > > sound/pci/hda/patch_hdmi.c.
> > > > > >
> > > > > > For achieving this implementation, a new field audio_enabled is
> > > > > > added
> > > > > > to struct intel_digital_port. This is set/reset at each audio
> > > > > > enable/disable call in intel_audio.c. It's protected with the
> > > > > > modeset
> > > > > > lock as well.
> > > > > >
> > > > > > Signed-off-by: Takashi Iwai
> > > > > > ---
> > > > > > v1->v2:
> > > > > > * Use modeset lock for get_eld lock, drop av mutex
> > > > > > * Return the expected size from get_eld, not the copied size
> > > > > >
> > > > > > drivers/gpu/drm/i915/intel_audio.c | 40
> > > > > > ++
> > > > > > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > > > > > include/drm/i915_component.h | 6 ++
> > > > > > 3 files changed, 47 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > > > > > b/drivers/gpu/drm/i915/intel_audio.c
> > > > > > index 0c38cc6c82ae..1965a61769ea 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > > > > @@ -521,6 +521,7 @@ void intel_audio_codec_enable(struct
> > > > > > intel_encoder *intel_encoder)
> > > > > >
> > > > > > connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode)
> > > > > > / 2;
> > > > > >
> > > > > > + intel_dig_port->audio_enabled = true;
> > > > > > if (dev_priv->display.audio_codec_enable)
> > > > > > dev_priv->display.audio_codec_enable(connector,
> > > > > > intel_encoder,
> > > > > > adjusted_mode);
> > > > > > @@ -545,6 +546,7 @@ void intel_audio_codec_disable(struct
> > > > > > intel_encoder *intel_encoder)
> > > > > > struct intel_digital_port *intel_dig_port =
> > > > > > enc_to_dig_port(encoder);
> > > > > > enum port port = intel_dig_port->port;
> > > > > >
> > > > > > + intel_dig_port->audio_enabled = false;
> > > > > > if (dev_priv->display.audio_codec_disable)
> > > > > > dev_priv->display.audio_codec_disable(intel_encoder);
> > > > > >
> > > > > > @@ -702,6 +704,43 @@ static int
> > > > > > i915_audio_component_sync_audio_rate(struct device *dev,
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > +static int i915_audio_component_get_eld(struct device *dev, int
> > > > > > port,
> > > > > > + bool *enabled,
> > > > > > + unsigned char *buf, int
> > > > > > max_bytes)
> > > > > > +{
> > > > > > + struct drm_i915_private *dev_priv = dev_to_i915(dev);
> > > > > > + struct drm_device *drm_dev = dev_priv->dev;
> > > > > > + struct intel_encoder *intel_encoder;
> > > > > > + struct intel_digital_port *intel_dig_port;
> > > > > > + struct drm_connector *connector;
> > > > > > + unsigned char *eld;
> > > > > > + int ret = -EINVAL;
> > > > > > +
> > > > > > + drm_modeset_lock_all(drm_dev);
> > > > >
> > > > > This is super expensive and shouldn't ever be used in new code. So
> > > > > either
> > > > > just the connection_mutex or resurrect the av_mutex and just cache
> > > > > what
> > > > > you need under that.
> > > >
> > > > OK, I need to make it harder, then.
> > > >
> > > > > Tbh I prefer the separate lock + cache for such
> > > > > specific things since it completely avoids spreading and entangling
> > > > > locking contexts. We use the same design to get modeset
Re: [Intel-gfx] Possible i915 regression with 4.4-rc
On Fri, Dec 04, 2015 at 11:40:59AM +0200, Ville Syrjälä wrote:
> On Fri, Dec 04, 2015 at 10:49:48AM +0200, Jani Nikula wrote:
> > On Thu, 03 Dec 2015, Ville Syrjälä wrote:
> > > On Thu, Dec 03, 2015 at 09:00:55PM +0100, Takashi Iwai wrote:
> > >> Hi,
> > >>
> > >> I've experienced a few graphics issues recently, and I tend to believe
> > >> that it has happened since 4.4-rc. Namely, after some long time usage
> > >> on my HSW laptop (two or three days), the mouse cursor vanished
> > >> suddenly. It kept pointing but just became invisible. Also, after
> > >> some S3 cycles, some glyphs on a console or on Firefox became
> > >> invisible, too. The windows and graphics were shown well, and X core
> > >> fonts were still shown properly, too. Switching to VT1 and back
> > >> didn't change the situation.
> > >
> > > I think I have a fix for this *very* annoying problem. I'v been cursing
> > > on irc for weeks about it, until I finally got off my arse and debugged
> > > it.
> > >
> > > I pushed out my my cursor branch:
> > > git://github.com/vsyrjala/linux.git disappearing_cursor_fix
> > >
> > > It has lots of other junk too, but it should be just there two that fix
> > > it:
> > > 59f65fa270fb ("drm/i915: Kill intel_crtc->cursor_bo")
> > > 25651a198d17 ("drm/i915: Drop the broken curcor base==0 special casing")
> > >
> > > Unfortunatleey I've managed to keep myself busy on other stuff, so didn't
> > > send them out yet. Maybe tomorrow...
> >
> > So I've hit this too, albeit very rarely, on a Haswell running Debian
> > stable with the stock v3.16 kernel. Haven't seen it on any other
> > machine. It's really too rare to even debug or verify a fix. Is it
> > possible we just happened to make an old bug occur more frequently now?
>
> The potential for it has definitely been there for a long time.
Oh dear, let's have fun and look at some awful history.
commit e568af1c626031925465a5caaab7cca1303d55c7
Author: Daniel Vetter
Date: Wed Mar 26 20:08:20 2014 +0100
drm/i915: Undo gtt scratch pte unmapping again
Which essentially reverted
commit 828c79087cec61eaf4c76bb32c222fbe35ac3930
Author: Ben Widawsky
Date: Wed Oct 16 09:21:30 2013 -0700
drm/i915: Disable GGTT PTEs on GEN6+ suspend
Once the machine gets to a certain point in the suspend process, we
expect the GPU to be idle. If it is not, we might corrupt memory.
Empirically (with an early version of this patch) we have seen this is
not the case. We cannot currently explain why the latent GPU writes
occur.
In the technical sense, this patch is a workaround in that we have an
issue we can't explain, and the patch indirectly solves the issue.
However, it's really better than a workaround because we understand why
it works, and it really should be a safe thing to do in all cases.
The noticeable effect other than the debug messages would be an increase
in the suspend time. I have not measure how expensive it actually is.
I think it would be good to spend further time to root cause why we're
seeing these latent writes, but it shouldn't preclude preventing the
fallout.
NOTE: It should be safe (and makes some sense IMO) to also keep the
VALID bit unset on resume when we clear_range(). I've opted not to do
this as properly clearing those bits at some later point would be extra
work.
v2: Fix bugzilla link
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=65496
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59321
Tested-by: Takashi Iwai
Tested-by: Paulo Zanoni
Signed-off-by: Ben Widawsky
Tested-By: Todd Previte
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter
This was a regression in a regression right before I ragequit the entire
bug handling deal because no one cared any more and management was all
"why is this important".
Would be interesting if these issues magically disapper when changing that
back again. Doesn't mean that we're any closer to figuring out what's
corrupting what exactly here, but at least we'd have a reason to digg out
this old sob story of mine.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
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 2/2] drm/i915: Disable shrinker for non-swapped backed objects
If the system has no available swap pages, we cannot make forward
progress in the shrinker by releasing active pages, only by releasing
purgeable pages which are immediately reaped. Take total_swap_pages into
account when counting up available objects to be shrunk and subsequently
shrinking them. By doing so, we avoid unbinding objects that cannot be
shrunk and so wasting CPU cycles flushing those objects from the GPU to
the system and then immediately back again (as they will more than
likely be reused shortly after).
Based on a patch by Akash Goel.
v2: frontswap registers extra swap pages available for the system, so it
is already include in the count of available swap pages.
v3: Use get_nr_swap_pages() to query the currently available amount of
swap space. This should also stop us from shrinking the GPU buffers if
we ever run out of swap space. Though at that point, we would expect the
oom-notifier to be running and failing miserably...
Reported-by: Akash Goel
Signed-off-by: Chris Wilson
Cc: linux...@kvack.org
Cc: Akash Goel
Cc: sourab.gu...@intel.com
---
drivers/gpu/drm/i915/i915_gem_shrinker.c | 60 +++-
1 file changed, 44 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index f7df54a8ee2b..16da9c1422cc 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -47,6 +47,46 @@ static bool mutex_is_locked_by(struct mutex *mutex, struct
task_struct *task)
#endif
}
+static int num_vma_bound(struct drm_i915_gem_object *obj)
+{
+ struct i915_vma *vma;
+ int count = 0;
+
+ list_for_each_entry(vma, &obj->vma_list, vma_link) {
+ if (drm_mm_node_allocated(&vma->node))
+ count++;
+ if (vma->pin_count)
+ count++;
+ }
+
+ return count;
+}
+
+static bool swap_available(void)
+{
+ return get_nr_swap_pages() > 0;
+}
+
+static bool can_release_pages(struct drm_i915_gem_object *obj)
+{
+ /* Only report true if by unbinding the object and putting its pages
+* we can actually make forward progress towards freeing physical
+* pages.
+*
+* If the pages are pinned for any other reason than being bound
+* to the GPU, simply unbinding from the GPU is not going to succeed
+* in releasing our pin count on the pages themselves.
+*/
+ if (obj->pages_pin_count != num_vma_bound(obj))
+ return false;
+
+ /* We can only return physical pages to the system if we can either
+* discard the contents (because the user has marked them as being
+* purgeable) or if we can move their contents out to swap.
+*/
+ return swap_available() || obj->madv == I915_MADV_DONTNEED;
+}
+
/**
* i915_gem_shrink - Shrink buffer object caches
* @dev_priv: i915 device
@@ -129,6 +169,9 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
if ((flags & I915_SHRINK_ACTIVE) == 0 && obj->active)
continue;
+ if (!can_release_pages(obj))
+ continue;
+
drm_gem_object_reference(&obj->base);
/* For the unbound phase, this should be a no-op! */
@@ -188,21 +231,6 @@ static bool i915_gem_shrinker_lock(struct drm_device *dev,
bool *unlock)
return true;
}
-static int num_vma_bound(struct drm_i915_gem_object *obj)
-{
- struct i915_vma *vma;
- int count = 0;
-
- list_for_each_entry(vma, &obj->vma_list, vma_link) {
- if (drm_mm_node_allocated(&vma->node))
- count++;
- if (vma->pin_count)
- count++;
- }
-
- return count;
-}
-
static unsigned long
i915_gem_shrinker_count(struct shrinker *shrinker, struct shrink_control *sc)
{
@@ -222,7 +250,7 @@ i915_gem_shrinker_count(struct shrinker *shrinker, struct
shrink_control *sc)
count += obj->base.size >> PAGE_SHIFT;
list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list) {
- if (!obj->active && obj->pages_pin_count == num_vma_bound(obj))
+ if (!obj->active && can_release_pages(obj))
count += obj->base.size >> PAGE_SHIFT;
}
--
2.6.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] mm: Export nr_swap_pages
Some modules, like i915.ko, use swappable objects and may try to swap them out under memory pressure (via the shrinker). Before doing so, they want to check using get_nr_swap_pages() to see if any swap space is available as otherwise they will waste time purging the object from the device without recovering any memory for the system. This requires the nr_swap_pages counter to be exported to the modules. Signed-off-by: Chris Wilson Cc: "Goel, Akash" Cc: Johannes Weiner Cc: linux...@kvack.org --- mm/swapfile.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/mm/swapfile.c b/mm/swapfile.c index 58877312cf6b..2d259fdb2347 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -48,6 +48,12 @@ static sector_t map_swap_entry(swp_entry_t, struct block_device**); DEFINE_SPINLOCK(swap_lock); static unsigned int nr_swapfiles; atomic_long_t nr_swap_pages; +/* + * Some modules use swappable objects and may try to swap them out under + * memory pressure (via the shrinker). Before doing so, they may wish to + * check to see if any swap space is available. + */ +EXPORT_SYMBOL_GPL(nr_swap_pages); /* protected with swap_lock. reading in vm_swap_full() doesn't need lock */ long total_swap_pages; static int least_priority; -- 2.6.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible i915 regression with 4.4-rc
On Fri, Dec 04, 2015 at 10:44:17AM +0200, Jani Nikula wrote: > On Thu, 03 Dec 2015, Chris Wilson wrote: > > On Thu, Dec 03, 2015 at 11:25:48PM +0200, Ville Syrjälä wrote: > >> I think we had some bug with not properly pinning the fbdev buffer which > >> could explain things getting corrupted. Chris had a fix I think, but I'm > >> not sure if that went anywhere. Chris? > > > > Jani keeps refusing it :) > > Which one? Was I being a boring pedant, requiring it gets review or > compiles or something...? :p It had review, but didnt really compile iirc. Chris, can you pls kick that can a bit more? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 2/9] drm/i915: Add get_eld audio component
On Fri, Dec 04, 2015 at 04:15:24PM +0100, Takashi Iwai wrote:
> diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> index 30d89e0da2c6..058d39e8d57f 100644
> --- a/include/drm/i915_component.h
> +++ b/include/drm/i915_component.h
> @@ -38,6 +38,7 @@
> * @codec_wake_override: Enable/Disable generating the codec wake signal
> * @get_cdclk_freq: get the Core Display Clock in KHz
> * @sync_audio_rate: set n/cts based on the sample rate
> + * @get_eld: fill the audio state and ELD bytes for the given port
One more: You seem to still be on an old baseline, with switched to the
new in-line comment layout. That allows you to spec the callback semantics
in much more detail since it allows real paragraphs.
-Daniel
> */
> struct i915_audio_component_ops {
> struct module *owner;
> @@ -46,6 +47,8 @@ struct i915_audio_component_ops {
> void (*codec_wake_override)(struct device *, bool enable);
> int (*get_cdclk_freq)(struct device *);
> int (*sync_audio_rate)(struct device *, int port, int rate);
> + int (*get_eld)(struct device *, int port, bool *enabled,
> +unsigned char *buf, int max_bytes);
> };
>
> struct i915_audio_component_audio_ops {
> --
> 2.6.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
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 2/9] drm/i915: Add get_eld audio component
On Fri, Dec 04, 2015 at 04:15:24PM +0100, Takashi Iwai wrote:
> On Fri, 04 Dec 2015 16:00:46 +0100,
> Daniel Vetter wrote:
> >
> > On Fri, Dec 04, 2015 at 11:49:46AM +0100, Takashi Iwai wrote:
> > > On Fri, 04 Dec 2015 11:21:02 +0100,
> > > Daniel Vetter wrote:
> > > >
> > > > On Tue, Dec 01, 2015 at 05:09:51PM +0100, Takashi Iwai wrote:
> > > > > Implement a new i915_audio_component_ops, get_eld(). It's called by
> > > > > the audio driver to fetch the current audio status and ELD of the
> > > > > given HDMI/DP port. It returns the size of expected ELD bytes if it's
> > > > > valid, zero if no valid ELD is found, or a negative error code. The
> > > > > current state of audio on/off is stored in the given pointer, too.
> > > > >
> > > > > Note that the returned size isn't limited to the given max bytes. If
> > > > > the size is greater than the max bytes, it means that only a part of
> > > > > ELD has been copied back.
> > > > >
> > > > > A big warning about the usage of this callback is: you must not call
> > > > > it from eld_notify. The eld_notify itself is called in the modeset
> > > > > lock, and it leads to a deadlock since get_eld takes the modeset lock,
> > > > > too. You need to call get_eld in a work, for example, in such a case.
> > > > > We'll see the actual implementation in the later patch in
> > > > > sound/pci/hda/patch_hdmi.c.
> > > > >
> > > > > For achieving this implementation, a new field audio_enabled is added
> > > > > to struct intel_digital_port. This is set/reset at each audio
> > > > > enable/disable call in intel_audio.c. It's protected with the modeset
> > > > > lock as well.
> > > > >
> > > > > Signed-off-by: Takashi Iwai
> > > > > ---
> > > > > v1->v2:
> > > > > * Use modeset lock for get_eld lock, drop av mutex
> > > > > * Return the expected size from get_eld, not the copied size
> > > > >
> > > > > drivers/gpu/drm/i915/intel_audio.c | 40
> > > > > ++
> > > > > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > > > > include/drm/i915_component.h | 6 ++
> > > > > 3 files changed, 47 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > > > > b/drivers/gpu/drm/i915/intel_audio.c
> > > > > index 0c38cc6c82ae..1965a61769ea 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > > > @@ -521,6 +521,7 @@ void intel_audio_codec_enable(struct
> > > > > intel_encoder *intel_encoder)
> > > > >
> > > > > connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode)
> > > > > / 2;
> > > > >
> > > > > + intel_dig_port->audio_enabled = true;
> > > > > if (dev_priv->display.audio_codec_enable)
> > > > > dev_priv->display.audio_codec_enable(connector,
> > > > > intel_encoder,
> > > > >adjusted_mode);
> > > > > @@ -545,6 +546,7 @@ void intel_audio_codec_disable(struct
> > > > > intel_encoder *intel_encoder)
> > > > > struct intel_digital_port *intel_dig_port =
> > > > > enc_to_dig_port(encoder);
> > > > > enum port port = intel_dig_port->port;
> > > > >
> > > > > + intel_dig_port->audio_enabled = false;
> > > > > if (dev_priv->display.audio_codec_disable)
> > > > > dev_priv->display.audio_codec_disable(intel_encoder);
> > > > >
> > > > > @@ -702,6 +704,43 @@ static int
> > > > > i915_audio_component_sync_audio_rate(struct device *dev,
> > > > > return 0;
> > > > > }
> > > > >
> > > > > +static int i915_audio_component_get_eld(struct device *dev, int port,
> > > > > + bool *enabled,
> > > > > + unsigned char *buf, int
> > > > > max_bytes)
> > > > > +{
> > > > > + struct drm_i915_private *dev_priv = dev_to_i915(dev);
> > > > > + struct drm_device *drm_dev = dev_priv->dev;
> > > > > + struct intel_encoder *intel_encoder;
> > > > > + struct intel_digital_port *intel_dig_port;
> > > > > + struct drm_connector *connector;
> > > > > + unsigned char *eld;
> > > > > + int ret = -EINVAL;
> > > > > +
> > > > > + drm_modeset_lock_all(drm_dev);
> > > >
> > > > This is super expensive and shouldn't ever be used in new code. So
> > > > either
> > > > just the connection_mutex or resurrect the av_mutex and just cache what
> > > > you need under that.
> > >
> > > OK, I need to make it harder, then.
> > >
> > > > Tbh I prefer the separate lock + cache for such
> > > > specific things since it completely avoids spreading and entangling
> > > > locking contexts. We use the same design to get modeset information into
> > > > the PSR tracking, FBC tracking and other code which sits between KMS and
> > > > other subsystems.
> > >
> > > I didn't want to be involved with the modeset lock, but it has to be.
> > > This function calls drm_select_eld() and it requires both
> > > mode_config.mutex and connection_mutex.
[Intel-gfx] [PATCH] drm/i915: Take care of ring->last_context on ctx destroy
If the context being destroyed have been last in the ring, the ring->last_context will be left dangling. Later, the unpinning will happen for last_context, and as it was already freed, we corrupt memory by doing so. This regression introduced in commit 6d65ba943a2d1e4292a07ca7ddb6c5138b9efa5d Author: Nick Hoath Date: Tue Dec 1 14:48:57 2015 + drm/i915: Extend LRC pinning to cover GPU context writeback Fix this by clearing the ring->last_context if it is the context being destroyed. Cc: Nick Hoath Cc: Daniel Vetter Cc: David Gordon Cc: Chris Wilson Cc: Alex Dai Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_lrc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index c3504a0..5c26fde 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -2432,6 +2432,9 @@ intel_lr_context_clean_ring(struct intel_context *ctx, } } + if (ring->last_context == ctx) + ring->last_context = NULL; + WARN_ON(ctx->engine[ring->id].pin_count); intel_ringbuffer_free(ringbuf); drm_gem_object_unreference(&ctx_obj->base); -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Restore skl_gt3 device info
On Fri, Dec 04, 2015 at 04:19:49PM +0100, Daniel Vetter wrote: > This was broken in > > commit 6a8beeffed3b2d33151150e3a03696e697f16d46 > Author: Wayne Boyer > Date: Wed Dec 2 13:28:14 2015 -0800 > > drm/i915: Clean up device info structure definitions > > and I didn't spot this while reviewing. We really need that CI farm up > asap! We had a BAT run on this one: http://patchwork.freedesktop.org/series/1360/ But no SKL GT3 coverage. Also, what seems to be flaky tests. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests: add exit value constants for shell script tests
On Thu, Dec 03, 2015 at 11:30:53AM +, Thomas Wood wrote:
> Signed-off-by: Thomas Wood
Yeah that's nicer. I fixed up patch 2 to use the correct exit code and
push the entire series. Thanks for the feedback!
Cheers, Daniel
> ---
> tests/check_drm_clients | 2 +-
> tests/debugfs_emon_crash | 2 +-
> tests/drm_lib.sh | 22 ++
> tests/drv_debugfs_reader | 2 +-
> tests/drv_missed_irq_hang | 14 +++---
> tests/drv_module_reload_basic | 8
> tests/kms_sysfs_edid_timing | 4 ++--
> tests/sysfs_l3_parity | 6 +++---
> tests/test_rte_check | 2 +-
> tests/tools_test | 2 +-
> 10 files changed, 35 insertions(+), 29 deletions(-)
>
> diff --git a/tests/check_drm_clients b/tests/check_drm_clients
> index eb12416..2a891b8 100755
> --- a/tests/check_drm_clients
> +++ b/tests/check_drm_clients
> @@ -3,4 +3,4 @@
> SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
> . $SOURCE_DIR/drm_lib.sh
>
> -exit 0
> +exit $IGT_EXIT_SUCCESS
> diff --git a/tests/debugfs_emon_crash b/tests/debugfs_emon_crash
> index 809bfab..1dbfcb2 100755
> --- a/tests/debugfs_emon_crash
> +++ b/tests/debugfs_emon_crash
> @@ -13,4 +13,4 @@ done
>
> # If we got here, we haven't crashed
>
> -exit 0
> +exit $IGT_EXIT_SUCCESS
> diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh
> index c50664c..d2c6420 100755
> --- a/tests/drm_lib.sh
> +++ b/tests/drm_lib.sh
> @@ -1,20 +1,26 @@
> #!/bin/sh
>
> +IGT_EXIT_TIMEOUT=78
> +IGT_EXIT_SKIP=77
> +IGT_EXIT_SUCCESS=0
> +IGT_EXIT_INVALID=79
> +IGT_EXIT_FAILURE=99
> +
> # hacked-up long option parsing
> for arg in $@ ; do
> case $arg in
> --list-subtests)
> - exit 79
> + exit $IGT_EXIT_INVALID
> ;;
> --run-subtest)
> - exit 79
> + exit $IGT_EXIT_INVALID
> ;;
> --debug)
> IGT_LOG_LEVEL=debug
> ;;
> --help-description)
> echo $IGT_TEST_DESCRIPTION
> - exit 0
> + exit $IGT_EXIT_SUCCESS
> ;;
> --help)
> echo "Usage: `basename $0` [OPTIONS]"
> @@ -23,18 +29,18 @@ for arg in $@ ; do
> echo " --debug"
> echo " --help-description"
> echo " --help"
> - exit 0
> + exit $IGT_EXIT_SUCCESS
> ;;
> esac
> done
>
> die() {
> echo "$@"
> - exit 1
> + exit $IGT_EXIT_FAILURE
> }
>
> do_or_die() {
> - $@ > /dev/null 2>&1 || (echo "FAIL: $@ ($?)" && exit -1)
> + $@ > /dev/null 2>&1 || (echo "FAIL: $@ ($?)" && exit $IGT_EXIT_FAILURE)
> }
>
> if [ -d /debug/dri ] ; then
> @@ -63,7 +69,7 @@ if [ `cat $i915_dfs_path/clients | wc -l` -gt "2" ] ; then
> die "ERROR: other drm clients running"
> fi
>
> -whoami | grep -q root || ( echo ERROR: not running as root; exit 1 )
> +whoami | grep -q root || ( echo ERROR: not running as root; exit
> $IGT_EXIT_FAILURE )
>
> i915_sfs_path=
> if [ -d /sys/class/drm ] ; then
> @@ -76,7 +82,7 @@ fi
>
> function drmtest_skip_on_simulation()
> {
> - [ -n "$INTEL_SIMULATION" ] && exit 77
> + [ -n "$INTEL_SIMULATION" ] && exit $IGT_EXIT_SKIP
> }
>
> drmtest_skip_on_simulation
> diff --git a/tests/drv_debugfs_reader b/tests/drv_debugfs_reader
> index 9e2845e..6ea4e64 100755
> --- a/tests/drv_debugfs_reader
> +++ b/tests/drv_debugfs_reader
> @@ -6,4 +6,4 @@ SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
> # read everything we can
> cat $i915_dfs_path/* > /dev/null 2>&1
>
> -exit 0
> +exit $IGT_EXIT_SUCCESS
> diff --git a/tests/drv_missed_irq_hang b/tests/drv_missed_irq_hang
> index 6e8cfc2..8083fe5 100755
> --- a/tests/drv_missed_irq_hang
> +++ b/tests/drv_missed_irq_hang
> @@ -19,20 +19,20 @@ function blt_wait {
> function check_for_missed_irq {
> if test `cat i915_ring_missed_irq` = 0x; then
> echo "missed interrupts undetected"
> - exit 1
> + exit $IGT_EXIT_FAILURE
> fi
> }
>
> function check_for_hang {
> if cat i915_error_state | grep -v "no error state collected" >
> /dev/null ; then
> echo "gpu hang reported"
> - exit 2
> + exit $IGT_EXIT_FAILURE
> fi
> }
>
> if [ ! -f i915_ring_missed_irq ] ; then
> echo "kernel doesn't support interrupt masking"
> - exit 77
> + exit $IGT_EXIT_SKIP
> fi
>
> # clear error state first
> @@ -43,7 +43,7 @@ echo 0xf > i915_ring_test_irq
> echo "Interrupts masked"
> if test `cat i915_ring_test_irq` != 0x000f; then
> echo "Failed to set interrupt mask"
> - exit 3
> + exit $IGT_EXIT_FAILURE
> fi
>
> blt_wait
> @@ -57,7 +57,7 @@ echo 0 > i915_ring_test_irq
>
Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid writing relocs with addresses in non-canonical form
On Fri, Dec 04, 2015 at 04:20:43PM +0100, Michał Winiarski wrote:
> According to bspec, some parts of HW expect the addresses to be in
> a canonical form, where bits [63:48] == [47]. Let's convert addresses to
> canonical form prior to relocating and return converted offsets to
> userspace.
>
> v2: Whitespace fixup, gen8_canonical_addr description (Chris, Ville)
>
> Cc: Chris Wilson
> Cc: Michel Thierry
> Cc: Ville Syrjälä
> Signed-off-by: Michał Winiarski
There is a hole! Inside the actual relocation fixup you need
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index a4c243cec4aa..6d1a2d20337b 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -249,6 +249,12 @@ static inline int use_cpu_reloc(struct drm_i915_gem_object
*obj)
obj->cache_level != I915_CACHE_NONE);
}
+static uint64_t relocation_target(struct drm_i915_gem_relocation_entry *reloc,
+ uint64_t target_offset)
+{
+ return gen8_cannonical_address((int)reloc->delta + target_offset);
+}
+
static int
relocate_entry_cpu(struct drm_i915_gem_object *obj,
struct drm_i915_gem_relocation_entry *reloc,
@@ -256,7 +262,7 @@ relocate_entry_cpu(struct drm_i915_gem_object *obj,
{
struct drm_device *dev = obj->base.dev;
uint32_t page_offset = offset_in_page(reloc->offset);
- uint64_t delta = reloc->delta + target_offset;
+ uint64_t delta = relocation_target(reloc, target_get);
char *vaddr;
int ret;
@@ -292,7 +298,7 @@ relocate_entry_gtt(struct drm_i915_gem_object *obj,
{
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- uint64_t delta = reloc->delta + target_offset;
+ uint64_t delta = relocation_target(reloc, target_get);
uint64_t offset;
void __iomem *reloc_page;
int ret;
@@ -347,7 +353,7 @@ relocate_entry_clflush(struct drm_i915_gem_object *obj,
{
struct drm_device *dev = obj->base.dev;
uint32_t page_offset = offset_in_page(reloc->offset);
- uint64_t delta = (int)reloc->delta + target_offset;
+ uint64_t delta = relocation_target(reloc, target_get);
char *vaddr;
int ret;
Otherwise we may cross the 1<<47 boundary without swapping into cannonical
form.
-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] drm/i915: Enable PSR by default.
On Wed, Dec 02, 2015 at 08:08:30AM -0800, Rodrigo Vivi wrote:
> With a reliable frontbuffer tracking and all instability corner cases
> solved let's re-enabled PSR by default on all supported platforms.
>
> Signed-off-by: Rodrigo Vivi
Hm, one thing we're missing here still I think is that right now there's
not yet a BAT for psr. At least I didn't spot anything in the CI overview.
Is there a super-basic PSR testcase (just checking that we go into psr
self-refresh is imo good enough), similar to what we have with runtime PM?
Also I guess we need to get the dp aux series from you in first. With BAT
and outstanding series merged:
Acked-by: Daniel Vetter
Awesome work!
Cheers, Daniel
> ---
> drivers/gpu/drm/i915/i915_params.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 835d609..461c326 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -37,7 +37,7 @@ struct i915_params i915 __read_mostly = {
> .enable_execlists = -1,
> .enable_hangcheck = true,
> .enable_ppgtt = -1,
> - .enable_psr = 0,
> + .enable_psr = 1,
> .preliminary_hw_support =
> IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
> .disable_power_well = -1,
> .enable_ips = 1,
> @@ -126,7 +126,7 @@ MODULE_PARM_DESC(enable_execlists,
> "(-1=auto [default], 0=disabled, 1=enabled)");
>
> module_param_named_unsafe(enable_psr, i915.enable_psr, int, 0600);
> -MODULE_PARM_DESC(enable_psr, "Enable PSR (default: false)");
> +MODULE_PARM_DESC(enable_psr, "Enable PSR (default: true)");
>
> module_param_named_unsafe(preliminary_hw_support,
> i915.preliminary_hw_support, int, 0600);
> MODULE_PARM_DESC(preliminary_hw_support,
> --
> 2.4.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt 2/2] kms_frontbuffer_tracking: standardize the used FB sizes
On Wed, Dec 02, 2015 at 10:47:01AM -0200, Paulo Zanoni wrote:
> We want to make sure that both tiled and untiled buffers have the same
> size for the same width/height/format. This will allow better control
> over the failure paths exercised by our tests: when we try to flip
> from tiled to untiled, we'll be sure that we won't execute the error
> path that checks for buffer sizes.
>
> v2: Use the new igt_calc_fb_size() instead of implementing our own
> size calculation (Daniel).
>
> Signed-off-by: Paulo Zanoni
> ---
> tests/kms_frontbuffer_tracking.c | 51
> ++--
> 1 file changed, 34 insertions(+), 17 deletions(-)
>
> diff --git a/tests/kms_frontbuffer_tracking.c
> b/tests/kms_frontbuffer_tracking.c
> index 81703ec..3db95d2 100644
> --- a/tests/kms_frontbuffer_tracking.c
> +++ b/tests/kms_frontbuffer_tracking.c
> @@ -479,10 +479,28 @@ static bool init_modeset_cached_params(void)
> return true;
> }
>
> +static int format_get_bpp(uint32_t format)
Ah, missed one: igt_drm_format_to_bpp please, and if it doesn't cover them all
we
need to fix that asap.
-Daniel
> +{
> + switch (format) {
> + case DRM_FORMAT_RGB565:
> + return 16;
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ARGB2101010:
> + case DRM_FORMAT_XRGB2101010:
> + return 32;
> + default:
> + igt_assert(false);
> + }
> +}
> +
> static void create_fb(enum pixel_format pformat, int width, int height,
> uint64_t tiling, int plane, struct igt_fb *fb)
> {
> uint32_t format;
> + unsigned int size, stride;
> + int bpp;
> + uint64_t tiling_for_size;
>
> switch (pformat) {
> case FORMAT_RGB888:
> @@ -512,7 +530,21 @@ static void create_fb(enum pixel_format pformat, int
> width, int height,
> igt_assert(false);
> }
>
> - igt_create_fb(drm.fd, width, height, format, tiling, fb);
> + /* We want all frontbuffers with the same width/height/format to have
> + * the same size regardless of tiling since we want to properly exercise
> + * the Kernel's specific tiling-checking code paths without accidentally
> + * hitting size-checking ones first. */
> + bpp = format_get_bpp(format);
> + if (plane == PLANE_CUR)
> + tiling_for_size = LOCAL_DRM_FORMAT_MOD_NONE;
> + else
> + tiling_for_size = LOCAL_I915_FORMAT_MOD_X_TILED;
> +
> + igt_calc_fb_size(drm.fd, width, height, bpp, tiling_for_size, &size,
> + &stride);
> +
> + igt_create_fb_with_bo_size(drm.fd, width, height, format, tiling, fb,
> +size, stride);
> }
>
> static uint32_t pick_color(struct igt_fb *fb, enum color ecolor)
> @@ -1094,21 +1126,6 @@ static void *busy_thread_func(void *data)
> pthread_exit(0);
> }
>
> -static int fb_get_bpp(struct igt_fb *fb)
> -{
> - switch (fb->drm_format) {
> - case DRM_FORMAT_RGB565:
> - return 16;
> - case DRM_FORMAT_XRGB:
> - case DRM_FORMAT_ARGB:
> - case DRM_FORMAT_ARGB2101010:
> - case DRM_FORMAT_XRGB2101010:
> - return 32;
> - default:
> - igt_assert(false);
> - }
> -}
> -
> static void start_busy_thread(struct igt_fb *fb)
> {
> int rc;
> @@ -1121,7 +1138,7 @@ static void start_busy_thread(struct igt_fb *fb)
> busy_thread.width = fb->width;
> busy_thread.height = fb->height;
> busy_thread.color = pick_color(fb, COLOR_PRIM_BG);
> - busy_thread.bpp = fb_get_bpp(fb);
> + busy_thread.bpp = format_get_bpp(fb->drm_format);
>
> rc = pthread_create(&busy_thread.thread, NULL, busy_thread_func, NULL);
> igt_assert_eq(rc, 0);
> --
> 2.6.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt 2/2] kms_frontbuffer_tracking: standardize the used FB sizes
On Wed, Dec 02, 2015 at 10:47:01AM -0200, Paulo Zanoni wrote:
> We want to make sure that both tiled and untiled buffers have the same
> size for the same width/height/format. This will allow better control
> over the failure paths exercised by our tests: when we try to flip
> from tiled to untiled, we'll be sure that we won't execute the error
> path that checks for buffer sizes.
>
> v2: Use the new igt_calc_fb_size() instead of implementing our own
> size calculation (Daniel).
>
> Signed-off-by: Paulo Zanoni
Yeah, this is what I had in mind, looks great. On the series:
Reviewed-by: Daniel Vetter
> ---
> tests/kms_frontbuffer_tracking.c | 51
> ++--
> 1 file changed, 34 insertions(+), 17 deletions(-)
>
> diff --git a/tests/kms_frontbuffer_tracking.c
> b/tests/kms_frontbuffer_tracking.c
> index 81703ec..3db95d2 100644
> --- a/tests/kms_frontbuffer_tracking.c
> +++ b/tests/kms_frontbuffer_tracking.c
> @@ -479,10 +479,28 @@ static bool init_modeset_cached_params(void)
> return true;
> }
>
> +static int format_get_bpp(uint32_t format)
> +{
> + switch (format) {
> + case DRM_FORMAT_RGB565:
> + return 16;
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ARGB2101010:
> + case DRM_FORMAT_XRGB2101010:
> + return 32;
> + default:
> + igt_assert(false);
> + }
> +}
> +
> static void create_fb(enum pixel_format pformat, int width, int height,
> uint64_t tiling, int plane, struct igt_fb *fb)
> {
> uint32_t format;
> + unsigned int size, stride;
> + int bpp;
> + uint64_t tiling_for_size;
>
> switch (pformat) {
> case FORMAT_RGB888:
> @@ -512,7 +530,21 @@ static void create_fb(enum pixel_format pformat, int
> width, int height,
> igt_assert(false);
> }
>
> - igt_create_fb(drm.fd, width, height, format, tiling, fb);
> + /* We want all frontbuffers with the same width/height/format to have
> + * the same size regardless of tiling since we want to properly exercise
> + * the Kernel's specific tiling-checking code paths without accidentally
> + * hitting size-checking ones first. */
> + bpp = format_get_bpp(format);
> + if (plane == PLANE_CUR)
> + tiling_for_size = LOCAL_DRM_FORMAT_MOD_NONE;
> + else
> + tiling_for_size = LOCAL_I915_FORMAT_MOD_X_TILED;
> +
> + igt_calc_fb_size(drm.fd, width, height, bpp, tiling_for_size, &size,
> + &stride);
> +
> + igt_create_fb_with_bo_size(drm.fd, width, height, format, tiling, fb,
> +size, stride);
> }
>
> static uint32_t pick_color(struct igt_fb *fb, enum color ecolor)
> @@ -1094,21 +1126,6 @@ static void *busy_thread_func(void *data)
> pthread_exit(0);
> }
>
> -static int fb_get_bpp(struct igt_fb *fb)
> -{
> - switch (fb->drm_format) {
> - case DRM_FORMAT_RGB565:
> - return 16;
> - case DRM_FORMAT_XRGB:
> - case DRM_FORMAT_ARGB:
> - case DRM_FORMAT_ARGB2101010:
> - case DRM_FORMAT_XRGB2101010:
> - return 32;
> - default:
> - igt_assert(false);
> - }
> -}
> -
> static void start_busy_thread(struct igt_fb *fb)
> {
> int rc;
> @@ -1121,7 +1138,7 @@ static void start_busy_thread(struct igt_fb *fb)
> busy_thread.width = fb->width;
> busy_thread.height = fb->height;
> busy_thread.color = pick_color(fb, COLOR_PRIM_BG);
> - busy_thread.bpp = fb_get_bpp(fb);
> + busy_thread.bpp = format_get_bpp(fb->drm_format);
>
> rc = pthread_create(&busy_thread.thread, NULL, busy_thread_func, NULL);
> igt_assert_eq(rc, 0);
> --
> 2.6.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] igt/pm_rps: Add checks for freq = idle (RPn) in specific cases.
On to, 2015-12-03 at 16:43 -0800, Bob Paauwe wrote: > On Tue, 1 Dec 2015 19:43:05 +0200 > Imre Deak wrote: > > > On ti, 2015-12-01 at 09:22 -0800, Bob Paauwe wrote: > > > On Tue, 1 Dec 2015 15:56:55 +0200 > > > Imre Deak wrote: > > > > > > > On ma, 2015-11-30 at 16:23 -0800, Bob Paauwe wrote: > > > > > Now that the frequency can drop below the user specified > > > > > minimum > > > > > when > > > > > the gpu is idle, add some checking to verify that it really > > > > > does > > > > > drop > > > > > down to the RPn frequency in specific cases. > > > > > > > > > > To do this, modify the main test flow to take two 'check' > > > > > routines > > > > > instead of one. When running the config-min-max-idle subtest > > > > > make > > > > > use of the second check routine to verify that the frequency > > > > > drops > > > > > to RPn instead of simply <= user min frequency. For all > > > > > other > > > > > subtests, use the original check routines for both checks. > > > > > > > > > > Signed-off-by: Bob Paauwe > > > > > > > > I don't see the point. The frequency should always drop to the > > > > idle > > > > frequency if the GPU is idle, it's not enough that it's below > > > > MIN- > > > > freq. > > > > So why do we need separate CUR-freq<=MIN-freq and CUR- > > > > freq==idle- > > > > freq > > > > checks? > > > > > > I started from the premise that it should always drop to idle but > > > that's just not the case. > > > > It is the correct premise and if it doesn't hold then there is a > > real > > bug either in the testcase or the kernel which needs to be > > addressed > > differently. I haven't found anything concrete but one suspect is > > the > > logic that waits for the GPU idle condition, maybe the timeout > > value idle_check() or the hard-coded duration in do_load_gpu() is > > incorrect. In any case let's not paper over this issue, the very > > reason > > we have test cases is to uncover such bugs. > > > > > The min_max_config() function is used for > > > both the idle and loaded subtests. If you try to check for > > > freq=idle > > > when doing the loaded subtest it will fail since it never goes > > > idle. > > > Even in the idle subtest there are cases where it doesn't drop > > > down > > > to > > > idle. > > > > The only place we should check for freq==idle is in idle_check() > > and > > that one is not called during the loaded subtest, it wouldn't even > > make > > sense to do so. So I'm not sure how this subtest fails for you. > > > > > I suppose I could duplicate min_max_config and have a > > > min_max_config_idle() and min_max_conifg_not_idle() for use by > > > the > > > different subtests. > > > > The point of the "check" argument of min_max_config() is to > > distinguish > > between the idle and loaded cases. The check functions passed in > > know > > already if they can expect the frequency to reach the idle > > frequency > > or not. > > > > > The real problem is that the test was not designed to handle the > > > case > > > where the freq could drop below min and probably needs to be > > > re-designed. I've been trying to find a quick fix vs. a complete > > > overhaul as this isn't really a priority for me. > > > > I think we only need your first patch and if there is any failure > > after > > that we have to root cause that and fix it properly. > > > > --Imre > > You're right. I'm working with BXT and it seems like it's got some > unique issues with RPS. I just sent a new patch based on the first > one > but with the changes you suggested to check for ==idle instead of > <=min. > > Maybe you have some insights into what I'm seeing with BXT? The first > problem I had was that I would see threshold up interrupts but not any > threshold down interrupts. The missing down interrupts was related to > the BIOS setting. I had runtime PM disabled so it seems strange that I > was getting the up interrupts. Yes, I saw this too. I wonder if we could check this somehow and not enable RPS if BIOS hasn't set things up properly. Sagar has a patch that checks the RC6 setup [1]; that's not exactly RPS, but since they are setup at the same place I think we could use that for now for RPS too. > With the BIOS setting corrected, the driver started disabling the down > interrupts once the freq dropped to min or just below because of the min > vs. idle difference. I have a patch for this that I'll send shortly. Hm, that's not necessarily a problem. To reach the idle frequency we don't depend on the up/down interrupts. The idle frequency gets set explicitly from intel_mark_idle(), so if you don't reach the idle freq then this function doesn't get called for some reason. Or as I said earlier we just don't wait enough in do_load_gpu() or idle_check() in the test, so we read out cur-freq before intel_mark_idle() would get called. > The remaining issue seems to be some type of timing issue. I've had > to > add a 35000us sleep between updating the interrupt enable register > (0xA168) and the
[Intel-gfx] [PATCH v2] drm/i915: Avoid writing relocs with addresses in non-canonical form
According to bspec, some parts of HW expect the addresses to be in
a canonical form, where bits [63:48] == [47]. Let's convert addresses to
canonical form prior to relocating and return converted offsets to
userspace.
v2: Whitespace fixup, gen8_canonical_addr description (Chris, Ville)
Cc: Chris Wilson
Cc: Michel Thierry
Cc: Ville Syrjälä
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +---
drivers/gpu/drm/i915/i915_gem_gtt.h| 12
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index a4c243c..ceffef9 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -395,7 +395,7 @@ i915_gem_execbuffer_relocate_entry(struct
drm_i915_gem_object *obj,
target_i915_obj = target_vma->obj;
target_obj = &target_vma->obj->base;
- target_offset = target_vma->node.start;
+ target_offset = gen8_canonical_addr(target_vma->node.start);
/* Sandybridge PPGTT errata: We need a global gtt mapping for MI and
* pipe_control writes because the gpu doesn't properly redirect them
@@ -583,6 +583,7 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
struct drm_i915_gem_object *obj = vma->obj;
struct drm_i915_gem_exec_object2 *entry = vma->exec_entry;
uint64_t flags;
+ uint64_t offset;
int ret;
flags = PIN_USER;
@@ -623,8 +624,9 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
entry->flags |= __EXEC_OBJECT_HAS_FENCE;
}
- if (entry->offset != vma->node.start) {
- entry->offset = vma->node.start;
+ offset = gen8_canonical_addr(vma->node.start);
+ if (entry->offset != offset) {
+ entry->offset = offset;
*need_reloc = true;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 877c32c..4ea9dab 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -507,6 +507,18 @@ static inline size_t gen8_pte_count(uint64_t address,
uint64_t length)
return i915_pte_count(address, length, GEN8_PDE_SHIFT);
}
+/* Used to convert any address to canonical form.
+ * Starting from gen8, some commands (e.g. STATE_BASE_ADDRESS,
+ * MI_LOAD_REGISTER_MEM and others, see Broadwell PRM Vol2a) expect the
+ * addresses to be in a canonical form:
+ * "GraphicsAddress[63:48] are ignored by the HW and assumed to be in correct
+ * canonical form [63:48] == [47]."
+ */
+static inline uint64_t gen8_canonical_addr(uint64_t address)
+{
+ return ((int64_t)address << 16) >> 16;
+}
+
static inline dma_addr_t
i915_page_dir_dma_addr(const struct i915_hw_ppgtt *ppgtt, const unsigned n)
{
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Restore skl_gt3 device info
This was broken in
commit 6a8beeffed3b2d33151150e3a03696e697f16d46
Author: Wayne Boyer
Date: Wed Dec 2 13:28:14 2015 -0800
drm/i915: Clean up device info structure definitions
and I didn't spot this while reviewing. We really need that CI farm up
asap!
Reported-by: Chris Wilson
Cc: Chris Wilson
Cc: Wayne Boyer
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d2d7e2461fa6..46ac66484dc7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -324,6 +324,7 @@ static const struct intel_device_info intel_skylake_info = {
};
static const struct intel_device_info intel_skylake_gt3_info = {
+ HSW_FEATURES,
.is_skylake = 1,
.gen = 9,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
--
2.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Separate cherryview from valleyview
On Fri, Dec 04, 2015 at 04:05:54PM +0100, Daniel Vetter wrote:
> On Wed, Dec 02, 2015 at 02:30:28PM +0200, Jani Nikula wrote:
> > On Wed, 02 Dec 2015, Ville Syrjälä wrote:
> > > On Tue, Dec 01, 2015 at 05:11:40PM -0800, Wayne Boyer wrote:
> > >> The cherryview device shares many characteristics with the valleyview
> > >> device. When support was added to the driver for cherryview, the
> > >> corresponding device info structure included .is_valleyview = 1.
> > >> This is not correct and leads to some confusion.
> > >>
> > >> This patch changes .is_valleyview to .is_cherryview in the cherryview
> > >> device info structure and defines the HAS_GEN7_LP_FEATURES macro.
> > >> Then where appropriate, instances of IS_VALLEYVIEW are replaced with
> > >> HAS_GEN7_LP_FEATURES to test for either a valleyview or a cherryview
> > >> device.
> > >
> > > I don't like the name of the macro. Most of the shared bits are display
> > > related, so we could have something like HAS_VLV_DISPLAY. For the rest,
> > > I think we could just test IS_VLV||IS_CHV explicitly. Unless someone
> > > can come up with a better name that covers everything?
> >
> > Definitely NAK on HAS_GEN7_LP_FEATURES.
> >
> > HAS_VLV_DISPLAY would be a subset of HAS_GMCH_DISPLAY, which I guess
> > wouldn't be that bad... unless someone starts using that for a VLV||CHV
> > shorthand in non-display code.
> >
> > I think I might just go for the verbose (IS_VALLEYVIEW || IS_CHERRYVIEW)
> > all around. Especially since we've been brainwashed with the old vlv is
> > both vlv and chv code.
>
> HAS_GMCH_DISPLAY is what I've generally used, since usually you have a
> INTEL_INFO()->gen >= 5 test already somewhere. If we want to make this
> more explicit the proper name for vlv is BAYTRAIL,
No it isn't. Let's not propagate that madness into the driver.
> and for truely byt
> specific stuff we've named things byt_. So what about Defining an
> IS_BAYTRAIL instead for the cases where it's not vlv || chv.
>
> And what's the benefit of all this churn?
> -Daniel
>
> >
> > BR,
> > Jani.
> >
> > >
> > >>
> > >> Cc: Rodrigo Vivi
> > >> Signed-off-by: Wayne Boyer
> > >> ---
> > >> drivers/gpu/drm/i915/i915_debugfs.c | 14 -
> > >> drivers/gpu/drm/i915/i915_dma.c | 8 ++---
> > >> drivers/gpu/drm/i915/i915_drv.c | 10 +++---
> > >> drivers/gpu/drm/i915/i915_drv.h | 19
> > >> drivers/gpu/drm/i915/i915_gem.c | 4 +--
> > >> drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
> > >> drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
> > >> drivers/gpu/drm/i915/i915_gpu_error.c | 6 ++--
> > >> drivers/gpu/drm/i915/i915_irq.c | 8 ++---
> > >> drivers/gpu/drm/i915/i915_suspend.c | 4 +--
> > >> drivers/gpu/drm/i915/i915_sysfs.c | 10 +++---
> > >> drivers/gpu/drm/i915/intel_audio.c | 6 ++--
> > >> drivers/gpu/drm/i915/intel_crt.c| 4 +--
> > >> drivers/gpu/drm/i915/intel_display.c| 54
> > >> -
> > >> drivers/gpu/drm/i915/intel_dp.c | 38 +++
> > >> drivers/gpu/drm/i915/intel_dsi.c| 13
> > >> drivers/gpu/drm/i915/intel_dsi_pll.c| 6 ++--
> > >> drivers/gpu/drm/i915/intel_hdmi.c | 4 +--
> > >> drivers/gpu/drm/i915/intel_hotplug.c| 2 +-
> > >> drivers/gpu/drm/i915/intel_i2c.c| 2 +-
> > >> drivers/gpu/drm/i915/intel_panel.c | 2 +-
> > >> drivers/gpu/drm/i915/intel_pm.c | 8 ++---
> > >> drivers/gpu/drm/i915/intel_psr.c| 4 +--
> > >> drivers/gpu/drm/i915/intel_sprite.c | 4 +--
> > >> drivers/gpu/drm/i915/intel_uncore.c | 6 ++--
> > >> 25 files changed, 123 insertions(+), 117 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > >> b/drivers/gpu/drm/i915/i915_debugfs.c
> > >> index bfd57fb..a2d50da 100644
> > >> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > >> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > >> @@ -862,7 +862,7 @@ static int i915_interrupt_info(struct seq_file *m,
> > >> void *data)
> > >> I915_READ(GEN8_PCU_IIR));
> > >> seq_printf(m, "PCU interrupt enable:\t%08x\n",
> > >> I915_READ(GEN8_PCU_IER));
> > >> -} else if (IS_VALLEYVIEW(dev)) {
> > >> +} else if (HAS_GEN7_LP_FEATURES(dev)) {
> > >
> > > We alredy test for CHV earlier, so this should remain as is.
> > >
> > >> seq_printf(m, "Display IER:\t%08x\n",
> > >> I915_READ(VLV_IER));
> > >> seq_printf(m, "Display IIR:\t%08x\n",
> > >> @@ -1284,7 +1284,7 @@ static int i915_frequency_info(struct seq_file *m,
> > >> void *unused)
> > >> seq_printf(m,
> > >> "efficient (RPe) frequency: %d MHz\n",
> > >> intel_gpu_freq(dev_priv,
> > >> dev_priv->rps.efficient_freq));
> > >> -} else if (IS_VALLEYVIEW(dev)) {
> >
Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Add get_eld audio component
On Fri, 04 Dec 2015 16:00:46 +0100,
Daniel Vetter wrote:
>
> On Fri, Dec 04, 2015 at 11:49:46AM +0100, Takashi Iwai wrote:
> > On Fri, 04 Dec 2015 11:21:02 +0100,
> > Daniel Vetter wrote:
> > >
> > > On Tue, Dec 01, 2015 at 05:09:51PM +0100, Takashi Iwai wrote:
> > > > Implement a new i915_audio_component_ops, get_eld(). It's called by
> > > > the audio driver to fetch the current audio status and ELD of the
> > > > given HDMI/DP port. It returns the size of expected ELD bytes if it's
> > > > valid, zero if no valid ELD is found, or a negative error code. The
> > > > current state of audio on/off is stored in the given pointer, too.
> > > >
> > > > Note that the returned size isn't limited to the given max bytes. If
> > > > the size is greater than the max bytes, it means that only a part of
> > > > ELD has been copied back.
> > > >
> > > > A big warning about the usage of this callback is: you must not call
> > > > it from eld_notify. The eld_notify itself is called in the modeset
> > > > lock, and it leads to a deadlock since get_eld takes the modeset lock,
> > > > too. You need to call get_eld in a work, for example, in such a case.
> > > > We'll see the actual implementation in the later patch in
> > > > sound/pci/hda/patch_hdmi.c.
> > > >
> > > > For achieving this implementation, a new field audio_enabled is added
> > > > to struct intel_digital_port. This is set/reset at each audio
> > > > enable/disable call in intel_audio.c. It's protected with the modeset
> > > > lock as well.
> > > >
> > > > Signed-off-by: Takashi Iwai
> > > > ---
> > > > v1->v2:
> > > > * Use modeset lock for get_eld lock, drop av mutex
> > > > * Return the expected size from get_eld, not the copied size
> > > >
> > > > drivers/gpu/drm/i915/intel_audio.c | 40
> > > > ++
> > > > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > > > include/drm/i915_component.h | 6 ++
> > > > 3 files changed, 47 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > > > b/drivers/gpu/drm/i915/intel_audio.c
> > > > index 0c38cc6c82ae..1965a61769ea 100644
> > > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > > @@ -521,6 +521,7 @@ void intel_audio_codec_enable(struct intel_encoder
> > > > *intel_encoder)
> > > >
> > > > connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode)
> > > > / 2;
> > > >
> > > > + intel_dig_port->audio_enabled = true;
> > > > if (dev_priv->display.audio_codec_enable)
> > > > dev_priv->display.audio_codec_enable(connector,
> > > > intel_encoder,
> > > > adjusted_mode);
> > > > @@ -545,6 +546,7 @@ void intel_audio_codec_disable(struct intel_encoder
> > > > *intel_encoder)
> > > > struct intel_digital_port *intel_dig_port =
> > > > enc_to_dig_port(encoder);
> > > > enum port port = intel_dig_port->port;
> > > >
> > > > + intel_dig_port->audio_enabled = false;
> > > > if (dev_priv->display.audio_codec_disable)
> > > > dev_priv->display.audio_codec_disable(intel_encoder);
> > > >
> > > > @@ -702,6 +704,43 @@ static int
> > > > i915_audio_component_sync_audio_rate(struct device *dev,
> > > > return 0;
> > > > }
> > > >
> > > > +static int i915_audio_component_get_eld(struct device *dev, int port,
> > > > + bool *enabled,
> > > > + unsigned char *buf, int
> > > > max_bytes)
> > > > +{
> > > > + struct drm_i915_private *dev_priv = dev_to_i915(dev);
> > > > + struct drm_device *drm_dev = dev_priv->dev;
> > > > + struct intel_encoder *intel_encoder;
> > > > + struct intel_digital_port *intel_dig_port;
> > > > + struct drm_connector *connector;
> > > > + unsigned char *eld;
> > > > + int ret = -EINVAL;
> > > > +
> > > > + drm_modeset_lock_all(drm_dev);
> > >
> > > This is super expensive and shouldn't ever be used in new code. So either
> > > just the connection_mutex or resurrect the av_mutex and just cache what
> > > you need under that.
> >
> > OK, I need to make it harder, then.
> >
> > > Tbh I prefer the separate lock + cache for such
> > > specific things since it completely avoids spreading and entangling
> > > locking contexts. We use the same design to get modeset information into
> > > the PSR tracking, FBC tracking and other code which sits between KMS and
> > > other subsystems.
> >
> > I didn't want to be involved with the modeset lock, but it has to be.
> > This function calls drm_select_eld() and it requires both
> > mode_config.mutex and connection_mutex.
> >
> > (snip)
> > > > struct i915_audio_component_audio_ops {
> > > > @@ -55,6 +58,9 @@ struct i915_audio_component_audio_ops {
> > > > * pin sense and/or ELD information has changed.
> > > > * @audio_ptr:
Re: [Intel-gfx] [PATCH] drm/i915: Fix RPS pointer passed from wait_ioctl to i915_wait_request
On Thu, Dec 03, 2015 at 09:25:37PM +, Chris Wilson wrote: > On Wed, Dec 02, 2015 at 09:13:46AM +, Chris Wilson wrote: > > In commit 2e1b873072dfe3bbcc158a9c21acde1ab0d36c55 [v4.2] > > Author: Chris Wilson > > Date: Mon Apr 27 13:41:22 2015 +0100 > > > > drm/i915: Convert RPS tracking to a intel_rps_client struct > > > > we converted the __i915_wait_request() to take a new intel_rps_client > > struct (rather than having to pass fake drm_i915_file_private structs). > > However, due to use of passing a void pointer, I didn't spot one > > callsite in wait-ioctl was passing the wrong pointer. > > > > Signed-off-by: Chris Wilson > > Cc: Daniel Vetter > > Cc: sta...@vger.kernel.org > > Fwiw, the impact of this bug is zero. Along the rps path, we always > first call list_empty(rps) which when we pass in the wrong pointer > always evaluates to false and we return early and never chase the > invalid pointers. > > The user visible impact is then wait-ioctl doesn't get the same > waitboosting as the other interfaces (set-domain, throttle), which is a > performance concern for the *very* few users of the wait interface. > There is also a libdrm_intel patch to use the wait-ioctl for > drm_intel_bo_wait_rendering() if anyone feels inclined to review > libdrm_intel patches. I added this to the commit message and figured it's not 100% justified for -fixes. So applied to dinq. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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] drm/i915: Clean up device info structure definitions
On Fri, Dec 04, 2015 at 11:24:39AM +0100, Daniel Vetter wrote:
> On Wed, Dec 02, 2015 at 01:28:14PM -0800, Wayne Boyer wrote:
> > Beginning with gen7, newer devices repetitively redefine values
> > for the device info structure members. This patch simplifies the
> > structure definitions by grouping member value definitions into the
> > existing GEN7_FEATURES #define and into the new GEN7_LP_FEATURES
> > and HSW_FEATURES #defines.
> >
> > Specifically, GEN_DEFAULT_PIPEOFFSETS and IVB_CURSOR_OFFSETS are
> > added to GEN7_FEATURES and subsequent IVB definitions are simplified.
> >
> > VLV_FEATURES is defined to differentiate and simplify the
> > gen7 low power (LP) devices.
> >
> > HSW_FEATURES is defined and used to simplify all HSW+ devices
> > except for LP.
> >
> > v2: Use VLV_FEATURES for the gen7 low power devices. (Jani)
> >
> > Cc: Rodrigo Vivi
> > Signed-off-by: Wayne Boyer
>
> Queued for -next, thanks for the patch.
>
> > static const struct intel_device_info intel_skylake_info = {
> > + HSW_FEATURES,
> > .is_skylake = 1,
> > - .gen = 9, .num_pipes = 3,
> > - .need_gfx_hws = 1, .has_hotplug = 1,
> > - .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
> > - .has_llc = 1,
> > - .has_ddi = 1,
> > - .has_fpga_dbg = 1,
> > - .has_fbc = 1,
> > - GEN_DEFAULT_PIPEOFFSETS,
> > - IVB_CURSOR_OFFSETS,
> > + .gen = 9,
> > };
> >
> > static const struct intel_device_info intel_skylake_gt3_info = {
> > .is_skylake = 1,
> > - .gen = 9, .num_pipes = 3,
> > - .need_gfx_hws = 1, .has_hotplug = 1,
> > + .gen = 9,
> > .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
> > - .has_llc = 1,
> > - .has_ddi = 1,
> > - .has_fpga_dbg = 1,
> > - .has_fbc = 1,
> > - GEN_DEFAULT_PIPEOFFSETS,
> > - IVB_CURSOR_OFFSETS,
> > };
Ooops.
-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 v2 4/9] drm/i915: Add reverse mapping between port and intel_encoder
On Fri, 04 Dec 2015 16:02:29 +0100, Daniel Vetter wrote: > > On Fri, Dec 04, 2015 at 03:40:03PM +0100, Takashi Iwai wrote: > > On Tue, 01 Dec 2015 17:09:53 +0100, > > Takashi Iwai wrote: > > > > > > This patch adds a reverse mapping from a digital port number to > > > intel_encoder object containing the corresponding intel_digital_port. > > > It simplifies the query of the encoder a lot. > > > > While this is good for a code reduction, I guess it's better to leave > > away for now, as there will be more changes there for MST support. > > It may put yet another loop, and the mapping implemented here might > > not be the best way. So I'm going to drop this from the next > > patchset. > > > > If anyone still thinks this is worth to include, let me know. I'll > > re-add this. > > Yeah I think this looks good. Fixing up conflicts with MST shouldn't be > that much trouble really. Alright, resurrected from ash. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix mode_get() for Broxton
On Wed, Dec 02, 2015 at 11:09:34AM +0200, Ville Syrjälä wrote:
> On Wed, Dec 02, 2015 at 12:13:27PM +0530, Vandana Kannan wrote:
> > Making changes in intel_crtc_mode_get() to get correct values for crtc
> > clock,
> > vdisplay, hdisplay, vtotal.
>
> Why? It's not used except potentially during for DVO/LVDS init on
> old platforms.
Yeah, if we touch this we better rework it to read out the pipe config
instead of more duplicated code. But since it's for dvo/lvds only it can
quietly die of old age imo ;-)
-Daniel
>
> > 1. intel_crtc_mode_get() gets clock using i9xx_crtc_clock_get() which wil
> > not
> > work for hsw, skl, bxt.
> > 2. For BXT DSI, hdisplay, vdisplay, vtotal registers are different. In the
> > current implementation, these value will be incorrect, thus impacting DPST.
> >
> > Signed-off-by: Vandana Kannan
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 66
> > +---
> > 1 file changed, 62 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 0743337..974977b 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -34,6 +34,7 @@
> > #include
> > #include
> > #include "intel_drv.h"
> > +#include "intel_dsi.h"
> > #include
> > #include "i915_drv.h"
> > #include "i915_trace.h"
> > @@ -116,6 +117,15 @@ static void skylake_pfit_enable(struct intel_crtc
> > *crtc);
> > static void ironlake_pfit_disable(struct intel_crtc *crtc, bool force);
> > static void ironlake_pfit_enable(struct intel_crtc *crtc);
> > static void intel_modeset_setup_hw_state(struct drm_device *dev);
> > +static void bxt_get_ddi_pll(struct drm_i915_private *dev_priv,
> > + enum port port,
> > + struct intel_crtc_state *pipe_config);
> > +static void skylake_get_ddi_pll(struct drm_i915_private *dev_priv,
> > + enum port port,
> > + struct intel_crtc_state *pipe_config);
> > +static void haswell_get_ddi_pll(struct drm_i915_private *dev_priv,
> > + enum port port,
> > + struct intel_crtc_state *pipe_config);
> >
> > typedef struct {
> > int min, max;
> > @@ -10698,6 +10708,33 @@ static void ironlake_pch_clock_get(struct
> > intel_crtc *crtc,
> > &pipe_config->fdi_m_n);
> > }
> >
> > +static void haswell_crtc_clock_get(struct intel_crtc *crtc,
> > + struct intel_crtc_state *pipe_config)
> > +{
> > + struct drm_device *dev = crtc->base.dev;
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > + struct intel_encoder *encoder = NULL;
> > + enum port port;
> > + bool is_dsi = intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI);
> > +
> > + for_each_encoder_on_crtc(dev, &crtc->base, encoder) {
> > + port = intel_ddi_get_encoder_port(encoder);
> > + if (IS_BROXTON(dev) && is_dsi) {
> > + pipe_config->port_clock = bxt_get_dsi_pclk(encoder,
> > + pipe_config->pipe_bpp);
> > + break;
> > + }
> > + if (IS_SKYLAKE(dev))
> > + skylake_get_ddi_pll(dev_priv, port, pipe_config);
> > + else if (IS_BROXTON(dev))
> > + bxt_get_ddi_pll(dev_priv, port, pipe_config);
> > + else
> > + haswell_get_ddi_pll(dev_priv, port, pipe_config);
> > +
> > + intel_ddi_clock_get(encoder, pipe_config);
> > + }
> > +}
> > +
> > /** Returns the currently programmed mode of the given pipe. */
> > struct drm_display_mode *intel_crtc_mode_get(struct drm_device *dev,
> > struct drm_crtc *crtc)
> > @@ -10712,6 +10749,7 @@ struct drm_display_mode *intel_crtc_mode_get(struct
> > drm_device *dev,
> > int vtot = I915_READ(VTOTAL(cpu_transcoder));
> > int vsync = I915_READ(VSYNC(cpu_transcoder));
> > enum pipe pipe = intel_crtc->pipe;
> > + bool is_dsi = intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DSI);
> >
> > mode = kzalloc(sizeof(*mode), GFP_KERNEL);
> > if (!mode)
> > @@ -10729,17 +10767,37 @@ struct drm_display_mode
> > *intel_crtc_mode_get(struct drm_device *dev,
> > pipe_config.dpll_hw_state.dpll = I915_READ(DPLL(pipe));
> > pipe_config.dpll_hw_state.fp0 = I915_READ(FP0(pipe));
> > pipe_config.dpll_hw_state.fp1 = I915_READ(FP1(pipe));
> > - i9xx_crtc_clock_get(intel_crtc, &pipe_config);
> > + if (HAS_DDI(dev) || INTEL_INFO(dev)->gen >= 9) {
> > + haswell_crtc_clock_get(intel_crtc, &pipe_config);
> > + } else {
> > + i9xx_crtc_clock_get(intel_crtc, &pipe_config);
> > + }
> >
> > mode->clock = pipe_config.port_clock / pipe_config.pixel_multiplier;
> > - mode->hdisplay = (htot & 0x) + 1;
> > mode->htotal = ((htot & 0x) >> 16) + 1;
> > mode->hsync_start = (hsync & 0x) + 1;
> > mode->hsync_end = ((hsync & 0x)
Re: [Intel-gfx] [PATCH] drm/i915: Separate cherryview from valleyview
On Wed, Dec 02, 2015 at 02:30:28PM +0200, Jani Nikula wrote:
> On Wed, 02 Dec 2015, Ville Syrjälä wrote:
> > On Tue, Dec 01, 2015 at 05:11:40PM -0800, Wayne Boyer wrote:
> >> The cherryview device shares many characteristics with the valleyview
> >> device. When support was added to the driver for cherryview, the
> >> corresponding device info structure included .is_valleyview = 1.
> >> This is not correct and leads to some confusion.
> >>
> >> This patch changes .is_valleyview to .is_cherryview in the cherryview
> >> device info structure and defines the HAS_GEN7_LP_FEATURES macro.
> >> Then where appropriate, instances of IS_VALLEYVIEW are replaced with
> >> HAS_GEN7_LP_FEATURES to test for either a valleyview or a cherryview
> >> device.
> >
> > I don't like the name of the macro. Most of the shared bits are display
> > related, so we could have something like HAS_VLV_DISPLAY. For the rest,
> > I think we could just test IS_VLV||IS_CHV explicitly. Unless someone
> > can come up with a better name that covers everything?
>
> Definitely NAK on HAS_GEN7_LP_FEATURES.
>
> HAS_VLV_DISPLAY would be a subset of HAS_GMCH_DISPLAY, which I guess
> wouldn't be that bad... unless someone starts using that for a VLV||CHV
> shorthand in non-display code.
>
> I think I might just go for the verbose (IS_VALLEYVIEW || IS_CHERRYVIEW)
> all around. Especially since we've been brainwashed with the old vlv is
> both vlv and chv code.
HAS_GMCH_DISPLAY is what I've generally used, since usually you have a
INTEL_INFO()->gen >= 5 test already somewhere. If we want to make this
more explicit the proper name for vlv is BAYTRAIL, and for truely byt
specific stuff we've named things byt_. So what about Defining an
IS_BAYTRAIL instead for the cases where it's not vlv || chv.
And what's the benefit of all this churn?
-Daniel
>
> BR,
> Jani.
>
> >
> >>
> >> Cc: Rodrigo Vivi
> >> Signed-off-by: Wayne Boyer
> >> ---
> >> drivers/gpu/drm/i915/i915_debugfs.c | 14 -
> >> drivers/gpu/drm/i915/i915_dma.c | 8 ++---
> >> drivers/gpu/drm/i915/i915_drv.c | 10 +++---
> >> drivers/gpu/drm/i915/i915_drv.h | 19
> >> drivers/gpu/drm/i915/i915_gem.c | 4 +--
> >> drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
> >> drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
> >> drivers/gpu/drm/i915/i915_gpu_error.c | 6 ++--
> >> drivers/gpu/drm/i915/i915_irq.c | 8 ++---
> >> drivers/gpu/drm/i915/i915_suspend.c | 4 +--
> >> drivers/gpu/drm/i915/i915_sysfs.c | 10 +++---
> >> drivers/gpu/drm/i915/intel_audio.c | 6 ++--
> >> drivers/gpu/drm/i915/intel_crt.c| 4 +--
> >> drivers/gpu/drm/i915/intel_display.c| 54
> >> -
> >> drivers/gpu/drm/i915/intel_dp.c | 38 +++
> >> drivers/gpu/drm/i915/intel_dsi.c| 13
> >> drivers/gpu/drm/i915/intel_dsi_pll.c| 6 ++--
> >> drivers/gpu/drm/i915/intel_hdmi.c | 4 +--
> >> drivers/gpu/drm/i915/intel_hotplug.c| 2 +-
> >> drivers/gpu/drm/i915/intel_i2c.c| 2 +-
> >> drivers/gpu/drm/i915/intel_panel.c | 2 +-
> >> drivers/gpu/drm/i915/intel_pm.c | 8 ++---
> >> drivers/gpu/drm/i915/intel_psr.c| 4 +--
> >> drivers/gpu/drm/i915/intel_sprite.c | 4 +--
> >> drivers/gpu/drm/i915/intel_uncore.c | 6 ++--
> >> 25 files changed, 123 insertions(+), 117 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> >> b/drivers/gpu/drm/i915/i915_debugfs.c
> >> index bfd57fb..a2d50da 100644
> >> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> >> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >> @@ -862,7 +862,7 @@ static int i915_interrupt_info(struct seq_file *m,
> >> void *data)
> >> I915_READ(GEN8_PCU_IIR));
> >>seq_printf(m, "PCU interrupt enable:\t%08x\n",
> >> I915_READ(GEN8_PCU_IER));
> >> - } else if (IS_VALLEYVIEW(dev)) {
> >> + } else if (HAS_GEN7_LP_FEATURES(dev)) {
> >
> > We alredy test for CHV earlier, so this should remain as is.
> >
> >>seq_printf(m, "Display IER:\t%08x\n",
> >> I915_READ(VLV_IER));
> >>seq_printf(m, "Display IIR:\t%08x\n",
> >> @@ -1284,7 +1284,7 @@ static int i915_frequency_info(struct seq_file *m,
> >> void *unused)
> >>seq_printf(m,
> >> "efficient (RPe) frequency: %d MHz\n",
> >> intel_gpu_freq(dev_priv,
> >> dev_priv->rps.efficient_freq));
> >> - } else if (IS_VALLEYVIEW(dev)) {
> >> + } else if (HAS_GEN7_LP_FEATURES(dev)) {
> >
> > And for this you would also need to change the earlier condition in the
> > previous 'else if' branch. But I think it would be clearner to hoist
> > the VLV/CHV code to sit before the gen6+ code, and then the gen6+
> > condition can be simplified significantly.
> >
> >>u32 freq_sts;
> >>
> >>mutex_lock(&dev_priv->rps.hw_lo
Re: [Intel-gfx] [PATCH v2 4/9] drm/i915: Add reverse mapping between port and intel_encoder
On Fri, Dec 04, 2015 at 03:40:03PM +0100, Takashi Iwai wrote:
> On Tue, 01 Dec 2015 17:09:53 +0100,
> Takashi Iwai wrote:
> >
> > This patch adds a reverse mapping from a digital port number to
> > intel_encoder object containing the corresponding intel_digital_port.
> > It simplifies the query of the encoder a lot.
>
> While this is good for a code reduction, I guess it's better to leave
> away for now, as there will be more changes there for MST support.
> It may put yet another loop, and the mapping implemented here might
> not be the best way. So I'm going to drop this from the next
> patchset.
>
> If anyone still thinks this is worth to include, let me know. I'll
> re-add this.
Yeah I think this looks good. Fixing up conflicts with MST shouldn't be
that much trouble really.
-Daniel
>
>
> thanks,
>
> Takashi
>
> >
> > Signed-off-by: Takashi Iwai
> > ---
> > drivers/gpu/drm/i915/i915_drv.h| 2 ++
> > drivers/gpu/drm/i915/intel_audio.c | 22 ++
> > drivers/gpu/drm/i915/intel_ddi.c | 1 +
> > drivers/gpu/drm/i915/intel_dp.c| 1 +
> > drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
> > 5 files changed, 8 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 95bb27de774f..3483d8125eac 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1955,6 +1955,8 @@ struct drm_i915_private {
> > /* perform PHY state sanity checks? */
> > bool chv_phy_assert[2];
> >
> > + struct intel_encoder *dig_port_map[I915_MAX_PORTS];
> > +
> > /*
> > * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
> > * will be rejected. Instead look for a better place.
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 19958bdb9bd0..67ee99f00ddd 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -630,28 +630,10 @@ static int i915_audio_component_get_cdclk_freq(struct
> > device *dev)
> > return ret;
> > }
> >
> > -static struct intel_encoder *audio_port_to_encoder(struct drm_device
> > *drm_dev,
> > - int port)
> > -{
> > - struct intel_encoder *intel_encoder;
> > - struct intel_digital_port *intel_dig_port;
> > -
> > - for_each_intel_encoder(drm_dev, intel_encoder) {
> > - if (intel_encoder->type != INTEL_OUTPUT_HDMI &&
> > - intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT)
> > - continue;
> > - intel_dig_port = enc_to_dig_port(&intel_encoder->base);
> > - if (port == intel_dig_port->port)
> > - return intel_encoder;
> > - }
> > - return NULL;
> > -}
> > -
> > static int i915_audio_component_sync_audio_rate(struct device *dev,
> > int port, int rate)
> > {
> > struct drm_i915_private *dev_priv = dev_to_i915(dev);
> > - struct drm_device *drm_dev = dev_priv->dev;
> > struct intel_encoder *intel_encoder;
> > struct intel_crtc *crtc;
> > struct drm_display_mode *mode;
> > @@ -668,7 +650,7 @@ static int i915_audio_component_sync_audio_rate(struct
> > device *dev,
> >
> > mutex_lock(&dev_priv->av_mutex);
> > /* 1. get the pipe */
> > - intel_encoder = audio_port_to_encoder(drm_dev, port);
> > + intel_encoder = dev_priv->dig_port_map[port];
> > if (!intel_encoder || intel_encoder->type != INTEL_OUTPUT_HDMI) {
> > DRM_DEBUG_KMS("no pipe for the port %c\n", port_name(port));
> > mutex_unlock(&dev_priv->av_mutex);
> > @@ -725,7 +707,7 @@ static int i915_audio_component_get_eld(struct device
> > *dev, int port,
> > int ret = -EINVAL;
> >
> > drm_modeset_lock_all(drm_dev);
> > - intel_encoder = audio_port_to_encoder(drm_dev, port);
> > + intel_encoder = dev_priv->dig_port_map[port];
> > if (intel_encoder) {
> > ret = 0;
> > intel_dig_port = enc_to_dig_port(&intel_encoder->base);
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index a6752a61d99f..6770110a4075 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -3285,6 +3285,7 @@ void intel_ddi_init(struct drm_device *dev, enum port
> > port)
> > intel_encoder->get_config = intel_ddi_get_config;
> >
> > intel_dig_port->port = port;
> > + dev_priv->dig_port_map[port] = intel_encoder;
> > intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) &
> > (DDI_BUF_PORT_REVERSAL |
> >DDI_A_4_LANES);
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 09bdd94ca3ba..1c02c6466f30 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@
Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Add get_eld audio component
On Fri, Dec 04, 2015 at 11:49:46AM +0100, Takashi Iwai wrote:
> On Fri, 04 Dec 2015 11:21:02 +0100,
> Daniel Vetter wrote:
> >
> > On Tue, Dec 01, 2015 at 05:09:51PM +0100, Takashi Iwai wrote:
> > > Implement a new i915_audio_component_ops, get_eld(). It's called by
> > > the audio driver to fetch the current audio status and ELD of the
> > > given HDMI/DP port. It returns the size of expected ELD bytes if it's
> > > valid, zero if no valid ELD is found, or a negative error code. The
> > > current state of audio on/off is stored in the given pointer, too.
> > >
> > > Note that the returned size isn't limited to the given max bytes. If
> > > the size is greater than the max bytes, it means that only a part of
> > > ELD has been copied back.
> > >
> > > A big warning about the usage of this callback is: you must not call
> > > it from eld_notify. The eld_notify itself is called in the modeset
> > > lock, and it leads to a deadlock since get_eld takes the modeset lock,
> > > too. You need to call get_eld in a work, for example, in such a case.
> > > We'll see the actual implementation in the later patch in
> > > sound/pci/hda/patch_hdmi.c.
> > >
> > > For achieving this implementation, a new field audio_enabled is added
> > > to struct intel_digital_port. This is set/reset at each audio
> > > enable/disable call in intel_audio.c. It's protected with the modeset
> > > lock as well.
> > >
> > > Signed-off-by: Takashi Iwai
> > > ---
> > > v1->v2:
> > > * Use modeset lock for get_eld lock, drop av mutex
> > > * Return the expected size from get_eld, not the copied size
> > >
> > > drivers/gpu/drm/i915/intel_audio.c | 40
> > > ++
> > > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > > include/drm/i915_component.h | 6 ++
> > > 3 files changed, 47 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > > b/drivers/gpu/drm/i915/intel_audio.c
> > > index 0c38cc6c82ae..1965a61769ea 100644
> > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > @@ -521,6 +521,7 @@ void intel_audio_codec_enable(struct intel_encoder
> > > *intel_encoder)
> > >
> > > connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
> > >
> > > + intel_dig_port->audio_enabled = true;
> > > if (dev_priv->display.audio_codec_enable)
> > > dev_priv->display.audio_codec_enable(connector, intel_encoder,
> > >adjusted_mode);
> > > @@ -545,6 +546,7 @@ void intel_audio_codec_disable(struct intel_encoder
> > > *intel_encoder)
> > > struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> > > enum port port = intel_dig_port->port;
> > >
> > > + intel_dig_port->audio_enabled = false;
> > > if (dev_priv->display.audio_codec_disable)
> > > dev_priv->display.audio_codec_disable(intel_encoder);
> > >
> > > @@ -702,6 +704,43 @@ static int
> > > i915_audio_component_sync_audio_rate(struct device *dev,
> > > return 0;
> > > }
> > >
> > > +static int i915_audio_component_get_eld(struct device *dev, int port,
> > > + bool *enabled,
> > > + unsigned char *buf, int max_bytes)
> > > +{
> > > + struct drm_i915_private *dev_priv = dev_to_i915(dev);
> > > + struct drm_device *drm_dev = dev_priv->dev;
> > > + struct intel_encoder *intel_encoder;
> > > + struct intel_digital_port *intel_dig_port;
> > > + struct drm_connector *connector;
> > > + unsigned char *eld;
> > > + int ret = -EINVAL;
> > > +
> > > + drm_modeset_lock_all(drm_dev);
> >
> > This is super expensive and shouldn't ever be used in new code. So either
> > just the connection_mutex or resurrect the av_mutex and just cache what
> > you need under that.
>
> OK, I need to make it harder, then.
>
> > Tbh I prefer the separate lock + cache for such
> > specific things since it completely avoids spreading and entangling
> > locking contexts. We use the same design to get modeset information into
> > the PSR tracking, FBC tracking and other code which sits between KMS and
> > other subsystems.
>
> I didn't want to be involved with the modeset lock, but it has to be.
> This function calls drm_select_eld() and it requires both
> mode_config.mutex and connection_mutex.
>
> (snip)
> > > struct i915_audio_component_audio_ops {
> > > @@ -55,6 +58,9 @@ struct i915_audio_component_audio_ops {
> > >* pin sense and/or ELD information has changed.
> > >* @audio_ptr: HDA driver object
> > >* @port: Which port has changed (PORTA / PORTB / PORTC etc)
> > > + *
> > > + * Note that you can't call i915_audio_component_ops.get_eld directly
> > > + * from the notifier callback as it may lead to deadlocks.
> >
> > With av_mutex we don't even need that note here ;-)
>
> So here is the problem. av_mutex itself doesn't suffice for
> drm_select_eld(), and taking the modeset lock leads to a de
Re: [Intel-gfx] [PATCH v2 1/9] drm/i915: Remove superfluous NULL check
On Fri, Dec 04, 2015 at 02:12:14PM +0100, Takashi Iwai wrote:
> On Fri, 04 Dec 2015 14:07:03 +0100,
> Ville Syrjälä wrote:
> >
> > On Fri, Dec 04, 2015 at 01:54:56PM +0100, Takashi Iwai wrote:
> > > On Fri, 04 Dec 2015 13:16:46 +0100,
> > > Ville Syrjälä wrote:
> > > >
> > > > On Tue, Dec 01, 2015 at 05:09:50PM +0100, Takashi Iwai wrote:
> > > > > to_intel_crtc() always returns a non-NULL pointer.
> > > >
> > > > Eh? to_intel_crtc(NULL) should return NULL or we might have tons of
> > > > breakage on our hands. Or maybe the atomic work has gotten rid of that
> > > > assumption, but at least we used to depend on that heavily.
> > >
> > > Well, to_intel_crtc() has been always container_of() since the very
> > > beginning of universe:
> > >
> > > commit 79e539453b34e35f39299a899d263b0a1f1670bd
> > > Author: Jesse Barnes
> > > Date: Fri Nov 7 14:24:08 2008 -0800
> > >
> > > DRM: i915: add mode setting support
> > >
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > >
> > > +#define to_intel_crtc(x) container_of(x, struct intel_crtc, base)
> > >
> >
> > Yes, but
> > struct intel_crtc {
> > struct drm_crtc base;
> > ...
> > }
> >
> > So offsetof(struct intel_crtc, base)==0 and NULL-0 is still NULL.
> >
> > I once suggested that someone should add a compile time assert to
> > make sure this always holds for us, but no one took the bait.
>
> Argh, only from the usage of container_of(), no one expects this
> implicit assumption :-< Indeed intel code has lots of these silent
> rules, e.g. calling kfree() for the base class object.
>
> Daniel, could you please take my patch back?
Oops. Patch reverted, sorry for the mess.
-Daniel
>
>
> thanks,
>
> Takashi
>
> >
> > >
> > >
> > > Takashi
> > >
> > > >
> > > > >
> > > > > Signed-off-by: Takashi Iwai
> > > > > ---
> > > > > drivers/gpu/drm/i915/intel_audio.c | 4
> > > > > 1 file changed, 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > > > > b/drivers/gpu/drm/i915/intel_audio.c
> > > > > index 4dccd9b003a1..0c38cc6c82ae 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > > > @@ -656,10 +656,6 @@ static int
> > > > > i915_audio_component_sync_audio_rate(struct device *dev,
> > > > > intel_dig_port = enc_to_dig_port(&intel_encoder->base);
> > > > > if (port == intel_dig_port->port) {
> > > > > crtc = to_intel_crtc(intel_encoder->base.crtc);
> > > > > - if (!crtc) {
> > > > > - DRM_DEBUG_KMS("%s: crtc is NULL\n",
> > > > > __func__);
> > > > > - continue;
> > > > > - }
> > > > > pipe = crtc->pipe;
> > > > > break;
> > > > > }
> > > > > --
> > > > > 2.6.3
> > > >
> > > > --
> > > > Ville Syrjälä
> > > > Intel OTC
> > > >
> >
> > --
> > Ville Syrjälä
> > Intel OTC
> >
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/28] drm/nouveau: Use private save/restore hooks
On Fri, Dec 4, 2015 at 3:45 AM, Daniel Vetter wrote:
> I want to remove the core ones since with atomic drivers system
> suspend/resume is solved much differently. And there's only 2 drivers
> (gma500 besides nouveau) really using them.
>
> Cc: Ben Skeggs
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 5 +++--
> drivers/gpu/drm/nouveau/dispnv04/disp.c | 11 ++-
> drivers/gpu/drm/nouveau/nouveau_crtc.h | 3 +++
> 3 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index dab24066fa21..bb9e9cb14b9d 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -1081,8 +1081,6 @@ nouveau_crtc_set_config(struct drm_mode_set *set)
> }
>
> static const struct drm_crtc_funcs nv04_crtc_funcs = {
> - .save = nv_crtc_save,
> - .restore = nv_crtc_restore,
> .cursor_set = nv04_crtc_cursor_set,
> .cursor_move = nv04_crtc_cursor_move,
> .gamma_set = nv_crtc_gamma_set,
> @@ -1123,6 +1121,9 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num)
> nv_crtc->index = crtc_num;
> nv_crtc->last_dpms = NV_DPMS_CLEARED;
>
> + nv_crtc->save = nv_crtc_save;
> + nv_crtc->restore = nv_crtc_restore;
> +
> drm_crtc_init(dev, &nv_crtc->base, &nv04_crtc_funcs);
> drm_crtc_helper_add(&nv_crtc->base, &nv04_crtc_helper_funcs);
> drm_mode_crtc_set_gamma_size(&nv_crtc->base, 256);
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> index 9e650081c357..ebd9430e0628 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> @@ -39,7 +39,7 @@ nv04_display_create(struct drm_device *dev)
> struct dcb_table *dcb = &drm->vbios.dcb;
> struct drm_connector *connector, *ct;
> struct drm_encoder *encoder;
> - struct drm_crtc *crtc;
> + struct nouveau_crtc *crtc;
> struct nv04_display *disp;
> int i, ret;
>
> @@ -107,8 +107,8 @@ nv04_display_create(struct drm_device *dev)
> }
>
> /* Save previous state */
> - list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
> - crtc->funcs->save(crtc);
> + list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head)
> + crtc->save(crtc);
Won't this warn about incompatible types? (function wants drm_crtc,
but you're giving it nouveau_crtc)?
>
> list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
> const struct drm_encoder_helper_funcs *func =
> encoder->helper_private;
> @@ -128,6 +128,7 @@ nv04_display_destroy(struct drm_device *dev)
> struct nouveau_drm *drm = nouveau_drm(dev);
> struct drm_encoder *encoder;
> struct drm_crtc *crtc;
> + struct nouveau_crtc *nv_crtc;
>
> /* Turn every CRTC off. */
> list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> @@ -145,8 +146,8 @@ nv04_display_destroy(struct drm_device *dev)
> func->restore(encoder);
> }
>
> - list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
> - crtc->funcs->restore(crtc);
> + list_for_each_entry(nv_crtc, &dev->mode_config.crtc_list, base.head)
> + nv_crtc->restore(crtc);
Why is this OK? Don't you want to use nv_crtc here as the function argument?
>
> nouveau_hw_save_vga_fonts(dev, 0);
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_crtc.h
> b/drivers/gpu/drm/nouveau/nouveau_crtc.h
> index f19cb1c5fc5a..863f10b8d818 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_crtc.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_crtc.h
> @@ -73,6 +73,9 @@ struct nouveau_crtc {
> int (*set_dither)(struct nouveau_crtc *crtc, bool update);
> int (*set_scale)(struct nouveau_crtc *crtc, bool update);
> int (*set_color_vibrance)(struct nouveau_crtc *crtc, bool update);
> +
> + void (*save)(struct drm_crtc *crtc);
> + void (*restore)(struct drm_crtc *crtc);
> };
>
> static inline struct nouveau_crtc *nouveau_crtc(struct drm_crtc *crtc)
> --
> 2.5.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/9] drm/i915: Add reverse mapping between port and intel_encoder
On Tue, 01 Dec 2015 17:09:53 +0100,
Takashi Iwai wrote:
>
> This patch adds a reverse mapping from a digital port number to
> intel_encoder object containing the corresponding intel_digital_port.
> It simplifies the query of the encoder a lot.
While this is good for a code reduction, I guess it's better to leave
away for now, as there will be more changes there for MST support.
It may put yet another loop, and the mapping implemented here might
not be the best way. So I'm going to drop this from the next
patchset.
If anyone still thinks this is worth to include, let me know. I'll
re-add this.
thanks,
Takashi
>
> Signed-off-by: Takashi Iwai
> ---
> drivers/gpu/drm/i915/i915_drv.h| 2 ++
> drivers/gpu/drm/i915/intel_audio.c | 22 ++
> drivers/gpu/drm/i915/intel_ddi.c | 1 +
> drivers/gpu/drm/i915/intel_dp.c| 1 +
> drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
> 5 files changed, 8 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 95bb27de774f..3483d8125eac 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1955,6 +1955,8 @@ struct drm_i915_private {
> /* perform PHY state sanity checks? */
> bool chv_phy_assert[2];
>
> + struct intel_encoder *dig_port_map[I915_MAX_PORTS];
> +
> /*
>* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
>* will be rejected. Instead look for a better place.
> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> index 19958bdb9bd0..67ee99f00ddd 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -630,28 +630,10 @@ static int i915_audio_component_get_cdclk_freq(struct
> device *dev)
> return ret;
> }
>
> -static struct intel_encoder *audio_port_to_encoder(struct drm_device
> *drm_dev,
> -int port)
> -{
> - struct intel_encoder *intel_encoder;
> - struct intel_digital_port *intel_dig_port;
> -
> - for_each_intel_encoder(drm_dev, intel_encoder) {
> - if (intel_encoder->type != INTEL_OUTPUT_HDMI &&
> - intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT)
> - continue;
> - intel_dig_port = enc_to_dig_port(&intel_encoder->base);
> - if (port == intel_dig_port->port)
> - return intel_encoder;
> - }
> - return NULL;
> -}
> -
> static int i915_audio_component_sync_audio_rate(struct device *dev,
> int port, int rate)
> {
> struct drm_i915_private *dev_priv = dev_to_i915(dev);
> - struct drm_device *drm_dev = dev_priv->dev;
> struct intel_encoder *intel_encoder;
> struct intel_crtc *crtc;
> struct drm_display_mode *mode;
> @@ -668,7 +650,7 @@ static int i915_audio_component_sync_audio_rate(struct
> device *dev,
>
> mutex_lock(&dev_priv->av_mutex);
> /* 1. get the pipe */
> - intel_encoder = audio_port_to_encoder(drm_dev, port);
> + intel_encoder = dev_priv->dig_port_map[port];
> if (!intel_encoder || intel_encoder->type != INTEL_OUTPUT_HDMI) {
> DRM_DEBUG_KMS("no pipe for the port %c\n", port_name(port));
> mutex_unlock(&dev_priv->av_mutex);
> @@ -725,7 +707,7 @@ static int i915_audio_component_get_eld(struct device
> *dev, int port,
> int ret = -EINVAL;
>
> drm_modeset_lock_all(drm_dev);
> - intel_encoder = audio_port_to_encoder(drm_dev, port);
> + intel_encoder = dev_priv->dig_port_map[port];
> if (intel_encoder) {
> ret = 0;
> intel_dig_port = enc_to_dig_port(&intel_encoder->base);
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index a6752a61d99f..6770110a4075 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3285,6 +3285,7 @@ void intel_ddi_init(struct drm_device *dev, enum port
> port)
> intel_encoder->get_config = intel_ddi_get_config;
>
> intel_dig_port->port = port;
> + dev_priv->dig_port_map[port] = intel_encoder;
> intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) &
> (DDI_BUF_PORT_REVERSAL |
> DDI_A_4_LANES);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 09bdd94ca3ba..1c02c6466f30 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -6201,6 +6201,7 @@ intel_dp_init(struct drm_device *dev, int output_reg,
> enum port port)
> }
>
> intel_dig_port->port = port;
> + dev_priv->dig_port_map[port] = intel_encoder;
> intel_dig_port->dp.output_reg = output_reg;
>
> intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
> diff --git a/driv
[Intel-gfx] GMA 4500M[HD] video decode viability
I have an opportunity to pick up a system that has an Intel Atom N280 (1.66 GHz) with an Intel GL40 chipset in it. The seller has listed that GPU in that as being a GMA 4500M but I have also seen reference to that particular system having a GMA 4500MHD. I'm considering this system for an HTPC so GPU video processing/decoding is the most important factor. I already run a couple of similar Atom/Nvidia ION based systems and am extremely happy with them in terms of being able to play even HD 1080[ip] content very smoothly with VDPAU. I'm wondering how this GMA 4500M[HD] system will compare. It'd probably need need VAAPI but I'm not sure if this GPU has any VAAPI support. Is the GMA 4500M (or MHD) up to the task I am looking at it for or should I just not even bothering looking at it any further, regardless of whether it's an M or an MHD? Cheers, b. signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] igt/pm_rps: current freq < user specified min is not a fail (v3)
On to, 2015-12-03 at 16:28 -0800, Bob Paauwe wrote:
> Since commit
>
> commit aed242ff7ebb697e4dff912bd4dc7ec7192f7581
> Author: Chris Wilson
> Date: Wed Mar 18 09:48:21 2015 +
>
> drm/i915: Relax RPS contraints to allows setting minfreq on
> idle
>
> it is now possible that the current frequency will drop be the user
> specified minimum frequency to the "idle" or RPn frequency. Update
> the
> pm_rps tests to reflect that droping below the user specified
> minimum
> is no longer considered a failure.
>
> v2: Add check RPn <= current freq. (Me)
> v3: Use RPn instead of MIN frequency in idle check (Imre)
> Signed-off-by: Bob Paauwe
Thanks, looks ok to me:
Reviewed-by: Imre Deak
I can also push this to IGT.
> ---
> tests/pm_rps.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tests/pm_rps.c b/tests/pm_rps.c
> index 74f08f4..9d054fd 100644
> --- a/tests/pm_rps.c
> +++ b/tests/pm_rps.c
> @@ -146,7 +146,7 @@ static void checkit(const int *freqs)
> {
> igt_assert_lte(freqs[MIN], freqs[MAX]);
> igt_assert_lte(freqs[CUR], freqs[MAX]);
> - igt_assert_lte(freqs[MIN], freqs[CUR]);
> + igt_assert_lte(freqs[RPn], freqs[CUR]);
> igt_assert_lte(freqs[RPn], freqs[MIN]);
> igt_assert_lte(freqs[MAX], freqs[RP0]);
> igt_assert_lte(freqs[RP1], freqs[RP0]);
> @@ -472,14 +472,14 @@ static void idle_check(void)
> read_freqs(freqs);
> dump(freqs);
> checkit(freqs);
> - if (freqs[CUR] == freqs[MIN])
> + if (freqs[CUR] == freqs[RPn])
> break;
> usleep(1000 * IDLE_WAIT_TIMESTEP_MSEC);
> wait += IDLE_WAIT_TIMESTEP_MSEC;
> } while (wait < IDLE_WAIT_TIMEOUT_MSEC);
>
> - igt_assert_eq(freqs[CUR], freqs[MIN]);
> - igt_debug("Required %d msec to reach cur=min\n", wait);
> + igt_assert_eq(freqs[CUR], freqs[RPn]);
> + igt_debug("Required %d msec to reach cur=idle\n", wait);
> }
>
> #define LOADED_WAIT_TIMESTEP_MSEC 100
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] lib/kms: Turn the based_edid into a template
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
lib/Makefile.sources| 1 +
lib/igt_edid_template.h | 74
lib/igt_kms.c | 90 +++--
3 files changed, 95 insertions(+), 70 deletions(-)
create mode 100644 lib/igt_edid_template.h
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index cb20f030cbec..4999868052b1 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -11,6 +11,7 @@ libintel_tools_la_SOURCES = \
igt_debugfs.h \
igt_aux.c \
igt_aux.h \
+ igt_edid_template.h \
igt_gt.c\
igt_gt.h\
igt_stats.c \
diff --git a/lib/igt_edid_template.h b/lib/igt_edid_template.h
new file mode 100644
index ..de421e080a88
--- /dev/null
+++ b/lib/igt_edid_template.h
@@ -0,0 +1,74 @@
+#define GAMMA(x) (((x) * 100) - 100)
+
+#define MANUFACTURER_ID(a, b, c) (a - '@') << 2 | (b - '@') >> 3, \
+(b - '@') << 5 | (c - '@')
+
+
+#define ab(x, y) ((x) & 0xff), ((y) & 0xff), (((x) & 0xf00) >> 4) | (((y) &
0xf00) >> 8)
+#define op(ho, hp, vo, vp) ((ho) & 0xff), ((hp) & 0xff), \
+ (((vo) & 0xf) << 4) | ((vp) & 0xf), \
+ (((ho) & 0x300) >> 2) | (((hp) & 0x300) >> 4) \
+ | (((vo) & 0x30) >> 2) | ((vp) & 0x30 >> 4)
+
+static unsigned char EDID_NAME[EDID_LENGTH] = {
+ 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, /* header */
+ MANUFACTURER_ID('I', 'G', 'T'),
+ /* product code, serial number, week and year of manufacture */
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x01, 0x03, /* edid version (1.3) */
+ /* basic display parameters */
+ /* digital display, maximum horizontal image size, maximum vertical
+* image size, gamma, features: RGB 4:4:4, native pixel format and
+* refresh rate in descriptor 1 */
+ 0x80, HSIZE, VSIZE, GAMMA(2.20), 0x02,
+ /* chromaticity coordinates */
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ /* established timings: 640x480 60Hz, 800x600 60Hz, 1024x768 60Hz */
+ 0x21, 0x08, 0x00,
+ /* standard timings */
+ 0xd1, 0xc0, /* 1920x1080 60Hz */
+ 0x81, 0xc0, /* 1280x720 60Hz */
+ 0x61, 0x40, /* 1024x768 60Hz */
+ 0x45, 0x40, /* 800x600 60Hz */
+ 0x31, 0x40, /* 640x480 60Hz */
+ 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
+ /* descriptor 1 (preferred timing) */
+ (CLOCK / 10) & 0x00ff, ((CLOCK / 10) & 0xff00) >> 8,
+ ab(HACTIVE, HBLANK), ab(VACTIVE, VBLANK),
+ op(HOFFSET, HPULSE, VOFFSET, VPULSE),
+ ab(HSIZE * 10, VSIZE * 10),
+ 0x00, 0x00, 0x00,
+ /* descriptor 2 (monitor range limits) */
+ 0x00, 0x00, 0x00, 0xfd, 0x00,
+ VFREQ - 1, VFREQ + 1, /* minimum, maximum vertical field rate */
+ (CLOCK / (HACTIVE + HBLANK)) - 1, /* minimum horizontal line rate */
+ (CLOCK / (HACTIVE + HBLANK)) + 1, /* maximum horizontal line rate */
+ (CLOCK / 1) + 1, /* maximum pixel clock rate */
+ 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
+ /* descriptor 3 (name descriptor) */
+ 0x00, 0x00, 0x00, 0xfc, 0x00, 'I', 'G', 'T', 0x0a,
+ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
+ /* descriptor 4 */
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ /* extensions, checksum */
+ 0x00, 0x00
+};
+
+#undef EDID_NAME
+#undef VFREQ
+#undef CLOCK
+#undef HACTIVE
+#undef HBLANK
+#undef VACTIVE
+#undef VBLANK
+#undef HOFFSET
+#undef HPULSE
+#undef VOFFSET
+#undef VPULSE
+#undef HSIZE
+#undef VSIZE
+#undef GAMMA
+#undef MANUFACTURER_ID
+#undef ab
+#undef op
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index fd4f05e81f3d..da49f5676641 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -53,6 +53,23 @@
#define MAX_CONNECTORS 32
static char *forced_connectors[MAX_CONNECTORS + 1];
+static void update_edid_csum(unsigned char *edid)
+{
+ int i, sum = 0;
+ struct tm *tm;
+ time_t t;
+
+ /* year of manufacture */
+ t = time(NULL);
+ tm = localtime(&t);
+ edid[17] = tm->tm_year - 90;
+
+ /* calculate checksum */
+ for (i = 0; i < 127; i++) {
+ sum = sum + edid[i];
+ }
+ edid[127] = 256 - sum;
+}
#define VFREQ 60
#define CLOCK 148500
@@ -68,62 +85,8 @@ static char *forced_connectors[MAX_CONNECTORS + 1];
#define HSIZE 52
#define VSIZE 30
-#define GAMMA(x) (x * 100) - 100
-
-#define MANUFACTURER_ID(a, b, c) (a - '@') << 2 | (b - '@') >> 3, \
-(b - '@') << 5 | (c - '@')
-
-
-#define ab(x, y) (x & 0xff), (y & 0xff), ((x & 0xf00) >> 4) | ((y & 0xf00) >>
8)
-#define op(ho, hp, vo, vp) (ho & 0xff), (hp & 0xff), \
- ((vo &
[Intel-gfx] [PATCH i-g-t 2/2] tests/kms_force_connector_basic: Add prune-stale-modes subtest
From: Ville Syrjälä
Add a new subtest that makes sure old stale modes get pruned from the
connector's mode list when the EDID changes.
Signed-off-by: Ville Syrjälä
---
lib/igt_kms.c | 40 +++
lib/igt_kms.h | 1 +
tests/kms_force_connector_basic.c | 40 +++
3 files changed, 81 insertions(+)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index da49f5676641..5d5a95c20106 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -111,6 +111,46 @@ const unsigned char* igt_kms_get_base_edid(void)
return base_edid;
}
+#define VFREQ 60
+#define CLOCK 101000
+#define HACTIVE 1400
+#define HBLANK 160
+#define VACTIVE 1050
+#define VBLANK 30
+#define HOFFSET 48
+#define HPULSE 32
+#define VOFFSET 3
+#define VPULSE 4
+
+#define HSIZE 52
+#define VSIZE 30
+
+#define EDID_NAME alt_edid
+#include "igt_edid_template.h"
+
+/**
+ * igt_kms_get_alt_edid:
+ *
+ * Get an alternate edid block, which includes the following modes:
+ *
+ * - 1400x1050 60Hz
+ * - 1920x1080 60Hz
+ * - 1280x720 60Hz
+ * - 1024x768 60Hz
+ * - 800x600 60Hz
+ * - 640x480 60Hz
+ *
+ * This can be extended with further features using functions such as
+ * #kmstest_edid_add_3d.
+ *
+ * Returns: an alternate edid block
+ */
+const unsigned char* igt_kms_get_alt_edid(void)
+{
+ update_edid_csum(alt_edid);
+
+ return alt_edid;
+}
/**
* SECTION:igt_kms
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 965c47c1c7f4..94f315fe13e2 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -286,6 +286,7 @@ void igt_reset_connectors(void);
#define EDID_LENGTH 128
const unsigned char* igt_kms_get_base_edid(void);
+const unsigned char* igt_kms_get_alt_edid(void);
#endif /* __IGT_KMS_H__ */
diff --git a/tests/kms_force_connector_basic.c
b/tests/kms_force_connector_basic.c
index 637f625a852f..f1b2da32dddc 100644
--- a/tests/kms_force_connector_basic.c
+++ b/tests/kms_force_connector_basic.c
@@ -178,6 +178,46 @@ int main(int argc, char **argv)
}
+ igt_subtest("prune-stale-modes") {
+ int i;
+
+ kmstest_force_connector(drm_fd, vga_connector,
+ FORCE_CONNECTOR_ON);
+
+ /* test pruning of stale modes */
+ kmstest_force_edid(drm_fd, vga_connector,
+ igt_kms_get_alt_edid(), EDID_LENGTH);
+ temp = drmModeGetConnector(drm_fd,
+ vga_connector->connector_id);
+
+ for (i = 0; i < temp->count_modes; i++) {
+ if (temp->modes[i].hdisplay == 1400 &&
+ temp->modes[i].vdisplay == 1050)
+ break;
+ }
+ igt_assert_f(i != temp->count_modes, "1400x1050 not on mode
list\n");
+
+ drmModeFreeConnector(temp);
+
+ kmstest_force_edid(drm_fd, vga_connector,
+ igt_kms_get_base_edid(), EDID_LENGTH);
+ temp = drmModeGetConnector(drm_fd,
+ vga_connector->connector_id);
+
+ for (i = 0; i < temp->count_modes; i++) {
+ if (temp->modes[i].hdisplay == 1400 &&
+ temp->modes[i].vdisplay == 1050)
+ break;
+ }
+ igt_assert_f(i == temp->count_modes, "1400x1050 not pruned from
mode list\n");
+
+ drmModeFreeConnector(temp);
+
+ kmstest_force_edid(drm_fd, vga_connector, NULL, 0);
+ kmstest_force_connector(drm_fd, vga_connector,
+ FORCE_CONNECTOR_UNSPECIFIED);
+ }
+
igt_fixture {
drmModeFreeConnector(vga_connector);
close(drm_fd);
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/9] drm/i915: Remove superfluous NULL check
On Fri, 04 Dec 2015 14:07:03 +0100,
Ville Syrjälä wrote:
>
> On Fri, Dec 04, 2015 at 01:54:56PM +0100, Takashi Iwai wrote:
> > On Fri, 04 Dec 2015 13:16:46 +0100,
> > Ville Syrjälä wrote:
> > >
> > > On Tue, Dec 01, 2015 at 05:09:50PM +0100, Takashi Iwai wrote:
> > > > to_intel_crtc() always returns a non-NULL pointer.
> > >
> > > Eh? to_intel_crtc(NULL) should return NULL or we might have tons of
> > > breakage on our hands. Or maybe the atomic work has gotten rid of that
> > > assumption, but at least we used to depend on that heavily.
> >
> > Well, to_intel_crtc() has been always container_of() since the very
> > beginning of universe:
> >
> > commit 79e539453b34e35f39299a899d263b0a1f1670bd
> > Author: Jesse Barnes
> > Date: Fri Nov 7 14:24:08 2008 -0800
> >
> > DRM: i915: add mode setting support
> >
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> >
> > +#define to_intel_crtc(x) container_of(x, struct intel_crtc, base)
> >
>
> Yes, but
> struct intel_crtc {
> struct drm_crtc base;
> ...
> }
>
> So offsetof(struct intel_crtc, base)==0 and NULL-0 is still NULL.
>
> I once suggested that someone should add a compile time assert to
> make sure this always holds for us, but no one took the bait.
Argh, only from the usage of container_of(), no one expects this
implicit assumption :-< Indeed intel code has lots of these silent
rules, e.g. calling kfree() for the base class object.
Daniel, could you please take my patch back?
thanks,
Takashi
>
> >
> >
> > Takashi
> >
> > >
> > > >
> > > > Signed-off-by: Takashi Iwai
> > > > ---
> > > > drivers/gpu/drm/i915/intel_audio.c | 4
> > > > 1 file changed, 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > > > b/drivers/gpu/drm/i915/intel_audio.c
> > > > index 4dccd9b003a1..0c38cc6c82ae 100644
> > > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > > @@ -656,10 +656,6 @@ static int
> > > > i915_audio_component_sync_audio_rate(struct device *dev,
> > > > intel_dig_port = enc_to_dig_port(&intel_encoder->base);
> > > > if (port == intel_dig_port->port) {
> > > > crtc = to_intel_crtc(intel_encoder->base.crtc);
> > > > - if (!crtc) {
> > > > - DRM_DEBUG_KMS("%s: crtc is NULL\n",
> > > > __func__);
> > > > - continue;
> > > > - }
> > > > pipe = crtc->pipe;
> > > > break;
> > > > }
> > > > --
> > > > 2.6.3
> > >
> > > --
> > > Ville Syrjälä
> > > Intel OTC
> > >
>
> --
> 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 v2 1/9] drm/i915: Remove superfluous NULL check
On Fri, Dec 04, 2015 at 01:54:56PM +0100, Takashi Iwai wrote:
> On Fri, 04 Dec 2015 13:16:46 +0100,
> Ville Syrjälä wrote:
> >
> > On Tue, Dec 01, 2015 at 05:09:50PM +0100, Takashi Iwai wrote:
> > > to_intel_crtc() always returns a non-NULL pointer.
> >
> > Eh? to_intel_crtc(NULL) should return NULL or we might have tons of
> > breakage on our hands. Or maybe the atomic work has gotten rid of that
> > assumption, but at least we used to depend on that heavily.
>
> Well, to_intel_crtc() has been always container_of() since the very
> beginning of universe:
>
> commit 79e539453b34e35f39299a899d263b0a1f1670bd
> Author: Jesse Barnes
> Date: Fri Nov 7 14:24:08 2008 -0800
>
> DRM: i915: add mode setting support
>
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_drv.h
>
> +#define to_intel_crtc(x) container_of(x, struct intel_crtc, base)
>
Yes, but
struct intel_crtc {
struct drm_crtc base;
...
}
So offsetof(struct intel_crtc, base)==0 and NULL-0 is still NULL.
I once suggested that someone should add a compile time assert to
make sure this always holds for us, but no one took the bait.
>
>
> Takashi
>
> >
> > >
> > > Signed-off-by: Takashi Iwai
> > > ---
> > > drivers/gpu/drm/i915/intel_audio.c | 4
> > > 1 file changed, 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > > b/drivers/gpu/drm/i915/intel_audio.c
> > > index 4dccd9b003a1..0c38cc6c82ae 100644
> > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > @@ -656,10 +656,6 @@ static int
> > > i915_audio_component_sync_audio_rate(struct device *dev,
> > > intel_dig_port = enc_to_dig_port(&intel_encoder->base);
> > > if (port == intel_dig_port->port) {
> > > crtc = to_intel_crtc(intel_encoder->base.crtc);
> > > - if (!crtc) {
> > > - DRM_DEBUG_KMS("%s: crtc is NULL\n", __func__);
> > > - continue;
> > > - }
> > > pipe = crtc->pipe;
> > > break;
> > > }
> > > --
> > > 2.6.3
> >
> > --
> > Ville Syrjälä
> > Intel OTC
> >
--
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] drm/i915: Enable GSE interrupt on BDW+
On Fri, 04 Dec 2015, Daniel Vetter wrote:
> On Wed, Dec 02, 2015 at 12:17:10AM +0200, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> We've never actually enabled or unmasked the GSE interrupt on BDW+,
>> even though the interrupt handler was always prepared for it.
>> Let's enable it and see what happens.
>>
>> Credit to Mark Kettenis who fixed this in the OpenBSD fork of the
>> driver. He reports that it fixed the "ACPI _BCM/_BCQ-based
>> brightness mechanism on a MacBookPro12,1 and a 3rd gen Lenovo X1
>> Carbon" for them.
>>
>> References:
>> http://lists.freedesktop.org/archives/intel-gfx/2015-December/081799.html
>> Reported-by: Mark Kettenis
>> Cc: Mark Kettenis
>> Cc: Jani Nikula
>> Signed-off-by: Ville Syrjälä
>
> Oh dear, there probably goes all our backlight fun. And how did we miss
> that DE_MISC wasn't enabled for this long ... but there's indeed nothing
> else interesting in there. Imo -fixes, and cc: stable as soon as someone
> confirms it fixes something on our end too.
I think this hasn't been such a big issue for us because we've mostly
moved on to native backlight, which is not affected.
Aaron, do you have any Broadwell ACPI backlight bugs open that might be
fixed by this?
BR,
Jani.
>
> Reviewed-by: Daniel Vetter
>
> And big kudos to Mark!
>
> Cheers, Daniel
>
>> ---
>> drivers/gpu/drm/i915/i915_irq.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index e88d692583a5..ccdac24039e8 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -3655,6 +3655,7 @@ static void gen8_de_irq_postinstall(struct
>> drm_i915_private *dev_priv)
>> uint32_t de_pipe_enables;
>> u32 de_port_masked = GEN8_AUX_CHANNEL_A;
>> u32 de_port_enables;
>> +u32 de_misc_masked = GEN8_DE_MISC_GSE;
>> enum pipe pipe;
>>
>> if (INTEL_INFO(dev_priv)->gen >= 9) {
>> @@ -3690,6 +3691,7 @@ static void gen8_de_irq_postinstall(struct
>> drm_i915_private *dev_priv)
>>de_pipe_enables);
>>
>> GEN5_IRQ_INIT(GEN8_DE_PORT_, ~de_port_masked, de_port_enables);
>> +GEN5_IRQ_INIT(GEN8_DE_MISC_, ~de_misc_masked, de_misc_masked);
>> }
>>
>> static int gen8_irq_postinstall(struct drm_device *dev)
>> --
>> 2.4.10
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, 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 v2 1/9] drm/i915: Remove superfluous NULL check
On Fri, 04 Dec 2015 13:16:46 +0100,
Ville Syrjälä wrote:
>
> On Tue, Dec 01, 2015 at 05:09:50PM +0100, Takashi Iwai wrote:
> > to_intel_crtc() always returns a non-NULL pointer.
>
> Eh? to_intel_crtc(NULL) should return NULL or we might have tons of
> breakage on our hands. Or maybe the atomic work has gotten rid of that
> assumption, but at least we used to depend on that heavily.
Well, to_intel_crtc() has been always container_of() since the very
beginning of universe:
commit 79e539453b34e35f39299a899d263b0a1f1670bd
Author: Jesse Barnes
Date: Fri Nov 7 14:24:08 2008 -0800
DRM: i915: add mode setting support
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_drv.h
+#define to_intel_crtc(x) container_of(x, struct intel_crtc, base)
Takashi
>
> >
> > Signed-off-by: Takashi Iwai
> > ---
> > drivers/gpu/drm/i915/intel_audio.c | 4
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 4dccd9b003a1..0c38cc6c82ae 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -656,10 +656,6 @@ static int i915_audio_component_sync_audio_rate(struct
> > device *dev,
> > intel_dig_port = enc_to_dig_port(&intel_encoder->base);
> > if (port == intel_dig_port->port) {
> > crtc = to_intel_crtc(intel_encoder->base.crtc);
> > - if (!crtc) {
> > - DRM_DEBUG_KMS("%s: crtc is NULL\n", __func__);
> > - continue;
> > - }
> > pipe = crtc->pipe;
> > break;
> > }
> > --
> > 2.6.3
>
> --
> 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 v2 2/9] drm/i915: Add get_eld audio component
On Fri, 04 Dec 2015 13:10:01 +0100,
Ville Syrjälä wrote:
>
> On Fri, Dec 04, 2015 at 11:49:46AM +0100, Takashi Iwai wrote:
> > On Fri, 04 Dec 2015 11:21:02 +0100,
> > Daniel Vetter wrote:
> > >
> > > On Tue, Dec 01, 2015 at 05:09:51PM +0100, Takashi Iwai wrote:
> > > > Implement a new i915_audio_component_ops, get_eld(). It's called by
> > > > the audio driver to fetch the current audio status and ELD of the
> > > > given HDMI/DP port. It returns the size of expected ELD bytes if it's
> > > > valid, zero if no valid ELD is found, or a negative error code. The
> > > > current state of audio on/off is stored in the given pointer, too.
> > > >
> > > > Note that the returned size isn't limited to the given max bytes. If
> > > > the size is greater than the max bytes, it means that only a part of
> > > > ELD has been copied back.
> > > >
> > > > A big warning about the usage of this callback is: you must not call
> > > > it from eld_notify. The eld_notify itself is called in the modeset
> > > > lock, and it leads to a deadlock since get_eld takes the modeset lock,
> > > > too. You need to call get_eld in a work, for example, in such a case.
> > > > We'll see the actual implementation in the later patch in
> > > > sound/pci/hda/patch_hdmi.c.
> > > >
> > > > For achieving this implementation, a new field audio_enabled is added
> > > > to struct intel_digital_port. This is set/reset at each audio
> > > > enable/disable call in intel_audio.c. It's protected with the modeset
> > > > lock as well.
> > > >
> > > > Signed-off-by: Takashi Iwai
> > > > ---
> > > > v1->v2:
> > > > * Use modeset lock for get_eld lock, drop av mutex
> > > > * Return the expected size from get_eld, not the copied size
> > > >
> > > > drivers/gpu/drm/i915/intel_audio.c | 40
> > > > ++
> > > > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > > > include/drm/i915_component.h | 6 ++
> > > > 3 files changed, 47 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > > > b/drivers/gpu/drm/i915/intel_audio.c
> > > > index 0c38cc6c82ae..1965a61769ea 100644
> > > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > > @@ -521,6 +521,7 @@ void intel_audio_codec_enable(struct intel_encoder
> > > > *intel_encoder)
> > > >
> > > > connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode)
> > > > / 2;
> > > >
> > > > + intel_dig_port->audio_enabled = true;
> > > > if (dev_priv->display.audio_codec_enable)
> > > > dev_priv->display.audio_codec_enable(connector,
> > > > intel_encoder,
> > > > adjusted_mode);
> > > > @@ -545,6 +546,7 @@ void intel_audio_codec_disable(struct intel_encoder
> > > > *intel_encoder)
> > > > struct intel_digital_port *intel_dig_port =
> > > > enc_to_dig_port(encoder);
> > > > enum port port = intel_dig_port->port;
> > > >
> > > > + intel_dig_port->audio_enabled = false;
> > > > if (dev_priv->display.audio_codec_disable)
> > > > dev_priv->display.audio_codec_disable(intel_encoder);
> > > >
> > > > @@ -702,6 +704,43 @@ static int
> > > > i915_audio_component_sync_audio_rate(struct device *dev,
> > > > return 0;
> > > > }
> > > >
> > > > +static int i915_audio_component_get_eld(struct device *dev, int port,
> > > > + bool *enabled,
> > > > + unsigned char *buf, int
> > > > max_bytes)
> > > > +{
> > > > + struct drm_i915_private *dev_priv = dev_to_i915(dev);
> > > > + struct drm_device *drm_dev = dev_priv->dev;
> > > > + struct intel_encoder *intel_encoder;
> > > > + struct intel_digital_port *intel_dig_port;
> > > > + struct drm_connector *connector;
> > > > + unsigned char *eld;
> > > > + int ret = -EINVAL;
> > > > +
> > > > + drm_modeset_lock_all(drm_dev);
> > >
> > > This is super expensive and shouldn't ever be used in new code. So either
> > > just the connection_mutex or resurrect the av_mutex and just cache what
> > > you need under that.
> >
> > OK, I need to make it harder, then.
> >
> > > Tbh I prefer the separate lock + cache for such
> > > specific things since it completely avoids spreading and entangling
> > > locking contexts. We use the same design to get modeset information into
> > > the PSR tracking, FBC tracking and other code which sits between KMS and
> > > other subsystems.
> >
> > I didn't want to be involved with the modeset lock, but it has to be.
> > This function calls drm_select_eld() and it requires both
> > mode_config.mutex and connection_mutex.
>
> drm_select_eld() would seem pointless to me if we cached the
> required information somewhere. But we'd still need to actually
> get the eld, and that means either caching it again somewhere,
> or perhaps it would be better to mov
Re: [Intel-gfx] Possible i915 regression with 4.4-rc
On Fri, Dec 04, 2015 at 12:16:40PM +, Chris Wilson wrote:
> On Fri, Dec 04, 2015 at 12:06:59PM +, Chris Wilson wrote:
> > > Could also be down to certain objects getting their contents
> > > discarded when evicted (due to not being marked dirty), for which I
> > > posted a fix "Always mark GEM objects as dirty when written by the
> > > CPU" a few days ago?
> >
> > Grasping at straws?
>
> On reflection, rather than the object->dirty patch, you want
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem
> _gtt.c
> index 1f7e6b9df45d..033df035a066 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -346,6 +346,7 @@ static void cleanup_page_dma(struct drm_device *dev,
> struct
> i915_page_dma *p)
>
> static void *kmap_page_dma(struct i915_page_dma *p)
> {
> + set_page_dirty(p->page);
> return kmap_atomic(p->page);
> }
Or not? These pages are not swappable and remain allocated, so I would
expect the hibernation process to also make a copy of them and restore
them. Besides we would get outright GPU hangs and massive memory
corruption if the PTE were absent.
-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 v2 1/9] drm/i915: Remove superfluous NULL check
On Tue, Dec 01, 2015 at 05:09:50PM +0100, Takashi Iwai wrote:
> to_intel_crtc() always returns a non-NULL pointer.
Eh? to_intel_crtc(NULL) should return NULL or we might have tons of
breakage on our hands. Or maybe the atomic work has gotten rid of that
assumption, but at least we used to depend on that heavily.
>
> Signed-off-by: Takashi Iwai
> ---
> drivers/gpu/drm/i915/intel_audio.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> index 4dccd9b003a1..0c38cc6c82ae 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -656,10 +656,6 @@ static int i915_audio_component_sync_audio_rate(struct
> device *dev,
> intel_dig_port = enc_to_dig_port(&intel_encoder->base);
> if (port == intel_dig_port->port) {
> crtc = to_intel_crtc(intel_encoder->base.crtc);
> - if (!crtc) {
> - DRM_DEBUG_KMS("%s: crtc is NULL\n", __func__);
> - continue;
> - }
> pipe = crtc->pipe;
> break;
> }
> --
> 2.6.3
--
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] Possible i915 regression with 4.4-rc
On Fri, Dec 04, 2015 at 12:06:59PM +, Chris Wilson wrote:
> > Could also be down to certain objects getting their contents
> > discarded when evicted (due to not being marked dirty), for which I
> > posted a fix "Always mark GEM objects as dirty when written by the
> > CPU" a few days ago?
>
> Grasping at straws?
On reflection, rather than the object->dirty patch, you want
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem
_gtt.c
index 1f7e6b9df45d..033df035a066 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -346,6 +346,7 @@ static void cleanup_page_dma(struct drm_device *dev, struct
i915_page_dma *p)
static void *kmap_page_dma(struct i915_page_dma *p)
{
+ set_page_dirty(p->page);
return kmap_atomic(p->page);
}
-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 v2 2/9] drm/i915: Add get_eld audio component
On Fri, Dec 04, 2015 at 11:49:46AM +0100, Takashi Iwai wrote:
> On Fri, 04 Dec 2015 11:21:02 +0100,
> Daniel Vetter wrote:
> >
> > On Tue, Dec 01, 2015 at 05:09:51PM +0100, Takashi Iwai wrote:
> > > Implement a new i915_audio_component_ops, get_eld(). It's called by
> > > the audio driver to fetch the current audio status and ELD of the
> > > given HDMI/DP port. It returns the size of expected ELD bytes if it's
> > > valid, zero if no valid ELD is found, or a negative error code. The
> > > current state of audio on/off is stored in the given pointer, too.
> > >
> > > Note that the returned size isn't limited to the given max bytes. If
> > > the size is greater than the max bytes, it means that only a part of
> > > ELD has been copied back.
> > >
> > > A big warning about the usage of this callback is: you must not call
> > > it from eld_notify. The eld_notify itself is called in the modeset
> > > lock, and it leads to a deadlock since get_eld takes the modeset lock,
> > > too. You need to call get_eld in a work, for example, in such a case.
> > > We'll see the actual implementation in the later patch in
> > > sound/pci/hda/patch_hdmi.c.
> > >
> > > For achieving this implementation, a new field audio_enabled is added
> > > to struct intel_digital_port. This is set/reset at each audio
> > > enable/disable call in intel_audio.c. It's protected with the modeset
> > > lock as well.
> > >
> > > Signed-off-by: Takashi Iwai
> > > ---
> > > v1->v2:
> > > * Use modeset lock for get_eld lock, drop av mutex
> > > * Return the expected size from get_eld, not the copied size
> > >
> > > drivers/gpu/drm/i915/intel_audio.c | 40
> > > ++
> > > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > > include/drm/i915_component.h | 6 ++
> > > 3 files changed, 47 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > > b/drivers/gpu/drm/i915/intel_audio.c
> > > index 0c38cc6c82ae..1965a61769ea 100644
> > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > @@ -521,6 +521,7 @@ void intel_audio_codec_enable(struct intel_encoder
> > > *intel_encoder)
> > >
> > > connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
> > >
> > > + intel_dig_port->audio_enabled = true;
> > > if (dev_priv->display.audio_codec_enable)
> > > dev_priv->display.audio_codec_enable(connector, intel_encoder,
> > >adjusted_mode);
> > > @@ -545,6 +546,7 @@ void intel_audio_codec_disable(struct intel_encoder
> > > *intel_encoder)
> > > struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> > > enum port port = intel_dig_port->port;
> > >
> > > + intel_dig_port->audio_enabled = false;
> > > if (dev_priv->display.audio_codec_disable)
> > > dev_priv->display.audio_codec_disable(intel_encoder);
> > >
> > > @@ -702,6 +704,43 @@ static int
> > > i915_audio_component_sync_audio_rate(struct device *dev,
> > > return 0;
> > > }
> > >
> > > +static int i915_audio_component_get_eld(struct device *dev, int port,
> > > + bool *enabled,
> > > + unsigned char *buf, int max_bytes)
> > > +{
> > > + struct drm_i915_private *dev_priv = dev_to_i915(dev);
> > > + struct drm_device *drm_dev = dev_priv->dev;
> > > + struct intel_encoder *intel_encoder;
> > > + struct intel_digital_port *intel_dig_port;
> > > + struct drm_connector *connector;
> > > + unsigned char *eld;
> > > + int ret = -EINVAL;
> > > +
> > > + drm_modeset_lock_all(drm_dev);
> >
> > This is super expensive and shouldn't ever be used in new code. So either
> > just the connection_mutex or resurrect the av_mutex and just cache what
> > you need under that.
>
> OK, I need to make it harder, then.
>
> > Tbh I prefer the separate lock + cache for such
> > specific things since it completely avoids spreading and entangling
> > locking contexts. We use the same design to get modeset information into
> > the PSR tracking, FBC tracking and other code which sits between KMS and
> > other subsystems.
>
> I didn't want to be involved with the modeset lock, but it has to be.
> This function calls drm_select_eld() and it requires both
> mode_config.mutex and connection_mutex.
drm_select_eld() would seem pointless to me if we cached the
required information somewhere. But we'd still need to actually
get the eld, and that means either caching it again somewhere,
or perhaps it would be better to move the drm_edid_to_eld() call to
happen at modeset audio enable time protected by the av_mutex?
That way connector->eld contents would remain constant as long
as we have a mode set.
--
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] Possible i915 regression with 4.4-rc
On Fri, Dec 04, 2015 at 12:00:08PM +, Dave Gordon wrote:
> On 03/12/15 21:35, Chris Wilson wrote:
> >On Thu, Dec 03, 2015 at 11:25:48PM +0200, Ville Syrjälä wrote:
> >>On Thu, Dec 03, 2015 at 10:08:05PM +0100, Takashi Iwai wrote:
> >>>On Thu, 03 Dec 2015 21:33:29 +0100,
> >>>Ville Syrjälä wrote:
>
> On Thu, Dec 03, 2015 at 09:00:55PM +0100, Takashi Iwai wrote:
> >Hi,
> >
> >I've experienced a few graphics issues recently, and I tend to believe
> >that it has happened since 4.4-rc. Namely, after some long time usage
> >on my HSW laptop (two or three days), the mouse cursor vanished
> >suddenly. It kept pointing but just became invisible. Also, after
> >some S3 cycles, some glyphs on a console or on Firefox became
> >invisible, too. The windows and graphics were shown well, and X core
> >fonts were still shown properly, too. Switching to VT1 and back
> >didn't change the situation.
>
> I think I have a fix for this *very* annoying problem. I'v been cursing
> on irc for weeks about it, until I finally got off my arse and debugged
> it.
>
> I pushed out my my cursor branch:
> git://github.com/vsyrjala/linux.git disappearing_cursor_fix
>
> It has lots of other junk too, but it should be just there two that fix
> it:
> 59f65fa270fb ("drm/i915: Kill intel_crtc->cursor_bo")
> 25651a198d17 ("drm/i915: Drop the broken curcor base==0 special casing")
>
> Unfortunatleey I've managed to keep myself busy on other stuff, so didn't
> send them out yet. Maybe tomorrow...
> >>>
> >>>Great, I'll try them out now. But these look like fixing only the
> >>>cursor issue. Would they cover also the missing glyphs I experienced?
> >>
> >>No. That's either userland, or some object/context/etc. getting corrupted
> >>I think. I've had something like that occasionally too after some number of
> >>suspend cycles, and usually fbcon is dead at that point too (just get a
> >>black screen on VT switch).
> >>
> >>I think we had some bug with not properly pinning the fbdev buffer which
> >>could explain things getting corrupted. Chris had a fix I think, but I'm
> >>not sure if that went anywhere. Chris?
> >
> >Jani keeps refusing it :). But it's not the issue with the missing
> >glyphs. The missing glyphs is the kernel dropping rendering, or that
> >rendering not being flushed out to memory across the suspend as it is just
> >texture corruption. The glyph cache only slowly changes, so corruption
> >tends to be visible for some time. An alternative explanation would be
> >that GPU state is not restored upon resume that only (visibly) effects
> >glyph rendering (and portions thereof). Lost rendering is a simpler
> >explanation.
> >-Chris
>
> Could also be down to certain objects getting their contents
> discarded when evicted (due to not being marked dirty), for which I
> posted a fix "Always mark GEM objects as dirty when written by the
> CPU" a few days ago?
Grasping at straws?
-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] drm/i915: Avoid writing relocs with addresses in non-canonical form
On Fri, Dec 04, 2015 at 12:33:44PM +0100, Michał Winiarski wrote:
> According to bspec, some parts of HW expect the addresses to be in
> a canonical form, where bits [63:48] == [47]. Let's convert addresses to
> canonical form prior to relocating and return converted offsets to
> userspace.
>
> Cc: Chris Wilson
> Cc: Michel Thierry
> Signed-off-by: Michał Winiarski
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 9 ++---
> drivers/gpu/drm/i915/i915_gem_gtt.h| 5 +
> 2 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index a4c243c..9f27be9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -395,7 +395,7 @@ i915_gem_execbuffer_relocate_entry(struct
> drm_i915_gem_object *obj,
> target_i915_obj = target_vma->obj;
> target_obj = &target_vma->obj->base;
>
> - target_offset = target_vma->node.start;
> + target_offset = gen8_canonical_addr(target_vma->node.start);
Ok, this keeps userspace in sync as well as writing the cannonical
addreses to hardware.
> /* Sandybridge PPGTT errata: We need a global gtt mapping for MI and
>* pipe_control writes because the gpu doesn't properly redirect them
> @@ -583,6 +583,7 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> struct drm_i915_gem_object *obj = vma->obj;
> struct drm_i915_gem_exec_object2 *entry = vma->exec_entry;
> uint64_t flags;
> + uint64_t offset;
> int ret;
>
> flags = PIN_USER;
> @@ -623,8 +624,10 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> entry->flags |= __EXEC_OBJECT_HAS_FENCE;
> }
>
> - if (entry->offset != vma->node.start) {
> - entry->offset = vma->node.start;
> + offset = gen8_canonical_addr(vma->node.start);
> +
Kill the extra line.
> + if (entry->offset != offset) {
> + entry->offset = offset;
> *need_reloc = true;
And this copies back the cannonical address to userspace. Ok, the
userspace side looks correct (the presumed_offset and execobject.offsets
will be updated to store the cannonical address).
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index 877c32c..65e8f88 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -507,6 +507,11 @@ static inline size_t gen8_pte_count(uint64_t address,
> uint64_t length)
> return i915_pte_count(address, length, GEN8_PDE_SHIFT);
> }
>
> +static inline uint64_t gen8_canonical_addr(uint64_t address)
> +{
You need the bspec reference here as well.
Looks good to me, with just a quick explanation here as to what we are
doing and why.
-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] Possible i915 regression with 4.4-rc
On 03/12/15 21:35, Chris Wilson wrote:
On Thu, Dec 03, 2015 at 11:25:48PM +0200, Ville Syrjälä wrote:
On Thu, Dec 03, 2015 at 10:08:05PM +0100, Takashi Iwai wrote:
On Thu, 03 Dec 2015 21:33:29 +0100,
Ville Syrjälä wrote:
On Thu, Dec 03, 2015 at 09:00:55PM +0100, Takashi Iwai wrote:
Hi,
I've experienced a few graphics issues recently, and I tend to believe
that it has happened since 4.4-rc. Namely, after some long time usage
on my HSW laptop (two or three days), the mouse cursor vanished
suddenly. It kept pointing but just became invisible. Also, after
some S3 cycles, some glyphs on a console or on Firefox became
invisible, too. The windows and graphics were shown well, and X core
fonts were still shown properly, too. Switching to VT1 and back
didn't change the situation.
I think I have a fix for this *very* annoying problem. I'v been cursing
on irc for weeks about it, until I finally got off my arse and debugged
it.
I pushed out my my cursor branch:
git://github.com/vsyrjala/linux.git disappearing_cursor_fix
It has lots of other junk too, but it should be just there two that fix it:
59f65fa270fb ("drm/i915: Kill intel_crtc->cursor_bo")
25651a198d17 ("drm/i915: Drop the broken curcor base==0 special casing")
Unfortunatleey I've managed to keep myself busy on other stuff, so didn't
send them out yet. Maybe tomorrow...
Great, I'll try them out now. But these look like fixing only the
cursor issue. Would they cover also the missing glyphs I experienced?
No. That's either userland, or some object/context/etc. getting corrupted
I think. I've had something like that occasionally too after some number of
suspend cycles, and usually fbcon is dead at that point too (just get a
black screen on VT switch).
I think we had some bug with not properly pinning the fbdev buffer which
could explain things getting corrupted. Chris had a fix I think, but I'm
not sure if that went anywhere. Chris?
Jani keeps refusing it :). But it's not the issue with the missing
glyphs. The missing glyphs is the kernel dropping rendering, or that
rendering not being flushed out to memory across the suspend as it is just
texture corruption. The glyph cache only slowly changes, so corruption
tends to be visible for some time. An alternative explanation would be
that GPU state is not restored upon resume that only (visibly) effects
glyph rendering (and portions thereof). Lost rendering is a simpler
explanation.
-Chris
Could also be down to certain objects getting their contents discarded
when evicted (due to not being marked dirty), for which I posted a fix
"Always mark GEM objects as dirty when written by the CPU" a few days ago?
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/10] drm/i915: Leave FDI running after failed link training on LPT-H
On Fri, Dec 04, 2015 at 11:09:11AM +0100, Daniel Vetter wrote:
> On Tue, Dec 01, 2015 at 03:08:41PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Currently we disable some parts of FDI setup after a failed link
> > training. But despite that we continue with the modeset as if everything
> > is fine. This results in tons of noise from the state checker, and
> > it means we're not following the proper modeset sequence for the rest of
> > crtc enabling, nor for crtc disabling.
> >
> > Ideally we should abort the modeset and follow the proper disable
> > suquenced to shut off everything we enabled so far, but that would
> > require a big rework of the modeset code. So instead just leave FDI
> > up and running in its untrained state, and log an error. This is
> > what we do on older platforms too.
>
> No, ideally we should light the pipe up and tell userspace through some
> uevent that something bad has happened.
That's not ideal from the hardware POV, and it's rather against the spec
even. But this patch does exactly that.
> Especially with async commits
> failing to light up the pipe looks to userspace like the kernel just
> randomly disabled it. And that usually results in random crashes when the
> next flip or vblank wait fails and everything comes crashing down. And
> even if we wouldn't -EINVAL these userspace would still have a problem
> since the flip or vblank it wants to wait for simply never happens and
> then it's just stalled.
>
> We've had tons of problems with this in the past, and therefore removed
> all the in-kernel sources for shutting down a pipe. E.g. DP re-training
> also forces the pipe to on again, even if it fails.
>
> Yup dp mst is an exception and I need to fix it eventually.
>
> Cheers, Daniel
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 24 +++-
> > 1 file changed, 15 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 76ce7c2960b6..b312a47a0654 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -675,15 +675,16 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
> > temp = I915_READ(DP_TP_STATUS(PORT_E));
> > if (temp & DP_TP_STATUS_AUTOTRAIN_DONE) {
> > DRM_DEBUG_KMS("FDI link training done on step %d\n", i);
> > + break;
> > + }
> >
> > - /* Enable normal pixel sending for FDI */
> > - I915_WRITE(DP_TP_CTL(PORT_E),
> > - DP_TP_CTL_FDI_AUTOTRAIN |
> > - DP_TP_CTL_LINK_TRAIN_NORMAL |
> > - DP_TP_CTL_ENHANCED_FRAME_ENABLE |
> > - DP_TP_CTL_ENABLE);
> > -
> > - return;
> > + /*
> > +* Leave things enabled even if we failed to train FDI.
> > +* Results in less fireworks from the state checker.
> > +*/
> > + if (i == ARRAY_SIZE(hsw_ddi_translations_fdi) * 2 - 1) {
> > + DRM_ERROR("FDI link training failed!\n");
> > + break;
> > }
> >
> > temp = I915_READ(DDI_BUF_CTL(PORT_E));
> > @@ -712,7 +713,12 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
> > POSTING_READ(FDI_RX_MISC(PIPE_A));
> > }
> >
> > - DRM_ERROR("FDI link training failed!\n");
> > + /* Enable normal pixel sending for FDI */
> > + I915_WRITE(DP_TP_CTL(PORT_E),
> > + DP_TP_CTL_FDI_AUTOTRAIN |
> > + DP_TP_CTL_LINK_TRAIN_NORMAL |
> > + DP_TP_CTL_ENHANCED_FRAME_ENABLE |
> > + DP_TP_CTL_ENABLE);
> > }
> >
> > void intel_ddi_init_dp_buf_reg(struct intel_encoder *encoder)
> > --
> > 2.4.10
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
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] drm/i915: Avoid writing relocs with addresses in non-canonical form
On Fri, Dec 04, 2015 at 12:33:44PM +0100, Michał Winiarski wrote:
> According to bspec, some parts of HW expect the addresses to be in
> a canonical form, where bits [63:48] == [47]. Let's convert addresses to
> canonical form prior to relocating and return converted offsets to
> userspace.
>
> Cc: Chris Wilson
> Cc: Michel Thierry
> Signed-off-by: Michał Winiarski
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 9 ++---
> drivers/gpu/drm/i915/i915_gem_gtt.h| 5 +
> 2 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index a4c243c..9f27be9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -395,7 +395,7 @@ i915_gem_execbuffer_relocate_entry(struct
> drm_i915_gem_object *obj,
> target_i915_obj = target_vma->obj;
> target_obj = &target_vma->obj->base;
>
> - target_offset = target_vma->node.start;
> + target_offset = gen8_canonical_addr(target_vma->node.start);
>
> /* Sandybridge PPGTT errata: We need a global gtt mapping for MI and
>* pipe_control writes because the gpu doesn't properly redirect them
> @@ -583,6 +583,7 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> struct drm_i915_gem_object *obj = vma->obj;
> struct drm_i915_gem_exec_object2 *entry = vma->exec_entry;
> uint64_t flags;
> + uint64_t offset;
> int ret;
>
> flags = PIN_USER;
> @@ -623,8 +624,10 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> entry->flags |= __EXEC_OBJECT_HAS_FENCE;
> }
>
> - if (entry->offset != vma->node.start) {
> - entry->offset = vma->node.start;
> + offset = gen8_canonical_addr(vma->node.start);
> +
> + if (entry->offset != offset) {
> + entry->offset = offset;
> *need_reloc = true;
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index 877c32c..65e8f88 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -507,6 +507,11 @@ static inline size_t gen8_pte_count(uint64_t address,
> uint64_t length)
> return i915_pte_count(address, length, GEN8_PDE_SHIFT);
> }
>
> +static inline uint64_t gen8_canonical_addr(uint64_t address)
> +{
> + return ((int64_t)address << 16) >> 16;
> +}
This could really use a comment explaining what it's doing and why.
Just lifting the first sentence of your commit message into a comment
would seem to be enough.
> +
> static inline dma_addr_t
> i915_page_dir_dma_addr(const struct i915_hw_ppgtt *ppgtt, const unsigned n)
> {
> --
> 2.5.0
>
> ___
> 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
