Re: [Intel-gfx] [PATCH 00/62] Broadwell kernel driver support
On Sat, Nov 02, 2013 at 09:06:58PM -0700, Ben Widawsky wrote: It is my honor and privilege to submit basic Broadwell support on behalf of Intel. The patch series includes support for Broadwell which should bring it up to feature parity with Haswell. As you'll note, the patches have received some revisions and review already. This is due to our new process (more on this below). We will be rolling out the new Broadwell goodness over time. Broadwell represents the next generation (GEN8) in Intel graphics processing hardware. Broadwell graphics bring some of the biggest changes we've seen on the execution and memory management side of the GPU. (There are equally large and exciting changes for the userspace drivers.) My request to reviewers is: I haven't touched these much at all since submitting to the internal mailing list. Most changes are due to rebase. Try to keep bikesheds to a minimum. We want to try to get this code in the 3.13 kernel, so we have a nice base to actually stabilize and improve features for the 3.14 release. Remember, we have that handy 'preliminary hardware support' to allow people to opt-in to this early enabling code. So I'm shooting for stable end-userable BDW code in 3.14. Note that the last few workarounds likely won't be needed, but I think we can include them until we know for sure otherwise. Aside from the usual set of things we need to update when simply enabling a new platform, What follows are some of the major changes from HSW-BDW: * There is no longer a forcewake write FIFO. *Most* writes must explicitly wake the GPU. * Interrupt registers have been completely reorganized. * PTEs format and cachability settings have changed to more resemble x86 PTEs, and PAT * Address space increases, and as such many commands require changing * Page table structures have changed for the Per Process GTT. The new structure more resembles traditional page tables with registers defining page directory base. The latter two changes were the real challenge in enabling the platform and getting things to actually work - though in hindsight, they seem so trivial :-) You may find these patches here: http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=broadwell I'll be posting patches for libdrm, and intel-gpu-tools in the next day or two. They are also ready to go, I just need to do a quick once over. At this point, feel free to stop reading. Also note that we've spent a decent amount of time refactoring the relevant areas in upstream, so now the massive changes for bdw mostly just plug in ... Anyway, review plan. Like Ben said this is still hidden behind the preliminary hw support knob. Also I want to get this all merged, final testing done and pull request sent by the end of the week. That way we can easily get it into 3.13 and that should also reduce the mess I currently have with the -internal branch. So - Please check register defines really through-roughly. - Check for erregious logic fumbles (e.g. in cleanup paths). - For everything else which can't be fixed quickly please just propose a FIXME comment. I've just grabbed a bunch of names from our team and then tried to not come up with a too bad split for reviewing: Mika: Patches 1-6 Chris: Patches 7-12 Paulo: Patches 13-17 Imre: Patches 18-23 Damien: Patches 24-29 Rodrigo: Patches 30-35 Ville: Patches 36-42 Ben: Patches 43-47 Jani: Patches 48-53 Jesse: Patches 54-58 Daniel: Patche 59-62 If the patches already has an r-b and hasn't been rebased like crazy since then you're lucky ;-) Please do the all the review on Mon/Tue so that I can spend Wed merging (and if needed, fixing up patches) and then we'll have 2 days or so for a bit of final integration testing. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 36/62] drm/i915/bdw: Broadwell also has the power down well
On Sat, Nov 02, 2013 at 09:07:34PM -0700, Ben Widawsky wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Just like Haswell, but with the small twist that the panel fitter for pipe A
is
now also in the always-on power well.
v2: Use the new HAS_POWER_WELL macro.
v3: Rebase on top of intel_using_power_well patches.
v4: This time actually update the PFIT check correctly so that the
pipe A pfit is in the always-on domain.
v5: Rebase on top of the VGA power domain addition.
v6: Rebase on top of the new power domain infrastructure. Also pimp the commit
message a bit while at it.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com (v1)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 6 +-
drivers/gpu/drm/i915/intel_pm.c | 5 +++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 64a3a8c..1a2e967 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -117,6 +117,10 @@ enum intel_display_power_domain {
#define HSW_ALWAYS_ON_POWER_DOMAINS (\
BIT(POWER_DOMAIN_PIPE_A) | \
BIT(POWER_DOMAIN_TRANSCODER_EDP))
+#define BDW_ALWAYS_ON_POWER_DOMAINS (\
+ BIT(POWER_DOMAIN_PIPE_A) | \
+ BIT(POWER_DOMAIN_TRANSCODER_EDP) | \
+ BIT(POWER_DOMAIN_PIPE_A_PANEL_FITTER))
enum hpd_pin {
HPD_NONE = 0,
@@ -1802,7 +1806,7 @@ struct drm_i915_file_private {
#define HAS_IPS(dev) (IS_ULT(dev))
#define HAS_DDI(dev) (INTEL_INFO(dev)-has_ddi)
-#define HAS_POWER_WELL(dev) (IS_HASWELL(dev))
+#define HAS_POWER_WELL(dev) (IS_HASWELL(dev) || IS_GEN8(dev))
IS_BROADWELL() please.
#define HAS_FPGA_DBG_UNCLAIMED(dev) (INTEL_INFO(dev)-has_fpga_dbg)
#define HAS_PSR(dev) (IS_HASWELL(dev))
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 81ec2c3..caf31b7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5524,7 +5524,9 @@ static bool is_always_on_power_domain(struct drm_device
*dev,
BUG_ON(BIT(domain) ~POWER_DOMAIN_MASK);
- if (IS_HASWELL(dev)) {
+ if (IS_GEN8(dev)) {
Here too.
+ always_on_domains = BDW_ALWAYS_ON_POWER_DOMAINS;
+ } else if (IS_HASWELL(dev)) {
always_on_domains = HSW_ALWAYS_ON_POWER_DOMAINS;
} else {
WARN_ON(1);
@@ -6010,4 +6012,3 @@ void intel_pm_init(struct drm_device *dev)
INIT_DELAYED_WORK(dev_priv-rps.delayed_resume_work,
intel_gen6_powersave_work);
}
-
--
1.8.4.2
___
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 38/62] drm/i915/bdw: get the correct LCPLL frequency on Broadwell
On Sat, Nov 02, 2013 at 09:07:36PM -0700, Ben Widawsky wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
v2: Rebased onto Paulo's MHz-kHz change.
v3: Rebased on top of the Haswell pc8+ adjustements.
Reviewed-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com (v1)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_ddi.c | 25 ++---
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 68b877d..d5995dd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5282,6 +5282,9 @@
#define LCPLL_PLL_LOCK (130)
#define LCPLL_CLK_FREQ_MASK (326)
#define LCPLL_CLK_FREQ_450 (026)
+#define LCPLL_CLK_FREQ_54O_BDW (126)
+#define LCPLL_CLK_FREQ_337_5_BDW(226)
+#define LCPLL_CLK_FREQ_675_BDW (326)
#define LCPLL_CD_CLOCK_DISABLE (125)
#define LCPLL_CD2X_CLOCK_DISABLE(123)
#define LCPLL_POWER_DOWN_ALLOW (122)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 31f4fe2..d464fd2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1156,18 +1156,29 @@ static void intel_disable_ddi(struct intel_encoder
*intel_encoder)
int intel_ddi_get_cdclk_freq(struct drm_i915_private *dev_priv)
{
+ struct drm_device *dev = dev_priv-dev;
uint32_t lcpll = I915_READ(LCPLL_CTL);
+ uint32_t freq = lcpll LCPLL_CLK_FREQ_MASK;
- if (lcpll LCPLL_CD_SOURCE_FCLK)
+ if (lcpll LCPLL_CD_SOURCE_FCLK) {
return 80;
I couldn't find this 800 MHz number anywhere, even in HSW docs. But
I guess it doesn't really matter since fclk shouldn't be selected
for normal operation.
- else if (I915_READ(HSW_FUSE_STRAP) HSW_CDCLK_LIMIT)
+ } else if (I915_READ(HSW_FUSE_STRAP) HSW_CDCLK_LIMIT) {
return 45;
I think this is actually incorrect for even HSW. The strap only tells
you what is allowed, but it doesn't affect the actual frequency. You
could still select the alternate frequencies, even though you shouldn't.
- else if ((lcpll LCPLL_CLK_FREQ_MASK) == LCPLL_CLK_FREQ_450)
+ } else if (freq == LCPLL_CLK_FREQ_450) {
return 45;
- else if (IS_ULT(dev_priv-dev))
- return 337500;
- else
- return 54;
+ } else if (IS_HASWELL(dev)) {
+ if (IS_ULT(dev))
+ return 338000;
+ else
+ return 54;
+ } else {
+ if (freq == LCPLL_CLK_FREQ_54O_BDW)
+ return 54;
+ else if (freq == LCPLL_CLK_FREQ_337_5_BDW)
+ return 338000;
337500
+ else
+ return 675000;
+ }
}
void intel_ddi_pll_init(struct drm_device *dev)
--
1.8.4.2
___
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 42/62] drm/i915/bdw: Implement WaSwitchSolVfFArbitrationPriority
On Sat, Nov 02, 2013 at 09:07:40PM -0700, Ben Widawsky wrote: GEN8 also needs this workaround. Not according to the w/a database. But the register description is the same for both HSW and BDW. Also for HSW, the w/a doesn't actually say whether we should set or clear the bit. the default is listed to be 0, so I guess we should set it, but then it's unclear why BDW wouldn't need the w/a. Once again a very poorly docuemnted w/a :( Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/intel_pm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index caf31b7..68dc363 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5192,6 +5192,9 @@ static void gen8_init_clock_gating(struct drm_device *dev) I915_WRITE(WM3_LP_ILK, 0); I915_WRITE(WM2_LP_ILK, 0); I915_WRITE(WM1_LP_ILK, 0); + + /* WaSwitchSolVfFArbitrationPriority */ + I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL); } static void haswell_init_clock_gating(struct drm_device *dev) -- 1.8.4.2 ___ 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 40/62] drm/i915/bdw: Broadwell has PIPEMISC
On Sat, Nov 02, 2013 at 09:07:38PM -0700, Ben Widawsky wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
And it inherits some bits from the previous TRANS_CONF (aka PIPE_CONF
on previous gens).
v2: Rebase on to of the pipe config bpp handling rework.
v3: Rebased on top of the pipe_config-dither refactoring.
v4: Drop the read-modify-write cycle for PIPEMISC, similarly to how we
now also build up PIPECONF completely ourselves - keeping around
random stuff set by the BIOS just isn't a good idea. I've checked BDW
BSpec and we already set all relevant bits.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com (v1)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 12
drivers/gpu/drm/i915/intel_display.c | 33 +++--
2 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d5995dd..4131223 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3224,6 +3224,18 @@
#define PIPEFRAMEPIXEL(pipe) _PIPE(pipe, _PIPEAFRAMEPIXEL, _PIPEBFRAMEPIXEL)
#define PIPESTAT(pipe) _PIPE(pipe, _PIPEASTAT, _PIPEBSTAT)
+#define _PIPE_MISC_A 0x70030
+#define _PIPE_MISC_B 0x71030
+#define PIPEMISC_DITHER_BPC_MASK (75)
+#define PIPEMISC_DITHER_8_BPC (05)
+#define PIPEMISC_DITHER_10_BPC (15)
+#define PIPEMISC_DITHER_6_BPC (25)
+#define PIPEMISC_DITHER_12_BPC (35)
+#define PIPEMISC_DITHER_ENABLE (14)
+#define PIPEMISC_DITHER_TYPE_MASK (32)
+#define PIPEMISC_DITHER_TYPE_SP(02)
+#define PIPEMISC(pipe) _PIPE(pipe, _PIPE_MISC_A, _PIPE_MISC_B)
+
#define VLV_DPFLIPSTAT (VLV_DISPLAY_BASE +
0x70028)
#define PIPEB_LINE_COMPARE_INT_EN (129)
#define PIPEB_HLINE_INT_EN (128)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7729c88..134ae66 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5772,14 +5772,16 @@ static void intel_set_pipe_csc(struct drm_crtc *crtc)
static void haswell_set_pipeconf(struct drm_crtc *crtc)
{
- struct drm_i915_private *dev_priv = crtc-dev-dev_private;
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum pipe pipe = intel_crtc-pipe;
enum transcoder cpu_transcoder = intel_crtc-config.cpu_transcoder;
uint32_t val;
val = 0;
- if (intel_crtc-config.dither)
+ if (IS_HASWELL(dev) intel_crtc-config.dither)
val |= (PIPECONF_DITHER_EN | PIPECONF_DITHER_TYPE_SP);
if (intel_crtc-config.adjusted_mode.flags DRM_MODE_FLAG_INTERLACE)
@@ -5792,6 +5794,33 @@ static void haswell_set_pipeconf(struct drm_crtc *crtc)
I915_WRITE(GAMMA_MODE(intel_crtc-pipe), GAMMA_MODE_MODE_8BIT);
POSTING_READ(GAMMA_MODE(intel_crtc-pipe));
+
+ if (IS_BROADWELL(dev)) {
+ val = 0;
+
+ switch (intel_crtc-config.pipe_bpp) {
+ case 18:
+ val |= PIPEMISC_DITHER_6_BPC;
+ break;
+ case 24:
+ val |= PIPEMISC_DITHER_8_BPC;
+ break;
+ case 30:
+ val |= PIPEMISC_DITHER_10_BPC;
+ break;
+ case 36:
+ val |= PIPEMISC_DITHER_12_BPC;
+ break;
+ default:
+ /* Case prevented by pipe_config_set_bpp. */
+ BUG();
+ }
+
+ if (intel_crtc-config.dither)
+ val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
+
+ I915_WRITE(PIPEMISC(pipe), val);
+ }
}
static bool ironlake_compute_clocks(struct drm_crtc *crtc,
--
1.8.4.2
___
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 37/62] drm/i915/bdw: pretend we have LPT LP on Broadwell
On Sat, Nov 02, 2013 at 09:07:35PM -0700, Ben Widawsky wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The platforms we currently have all have LPT LP on them. As such, we
have no way to identify the new WPT PCH that will ship with Broadwell.
NOTE: For all purposes relevant to the driver that this point, LPT and
WPT are equivalent. Therefore there should be no need to actually change
this for some time.
v2: Don't assign dev_priv-num_pch_pll any more.
v3: Rebase on top of the PCH detection changes for virtualized
enviroments.
v4 (Ben): Wrote commit message
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com (v1)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
I would have probably placed the hack to the if (!pch) block in the
end, but since it's a hack anyway I guess it's good enough.
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
drivers/gpu/drm/i915/i915_drv.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c86d44b..590d999 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -453,6 +453,12 @@ void intel_detect_pch(struct drm_device *dev)
DRM_DEBUG_KMS(Found LynxPoint LP PCH\n);
WARN_ON(!IS_HASWELL(dev));
WARN_ON(!IS_ULT(dev));
+ } else if (IS_BROADWELL(dev)) {
+ dev_priv-pch_type = PCH_LPT;
+ dev_priv-pch_id =
+ INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
+ DRM_DEBUG_KMS(This is Broadwell, assuming
+ LynxPoint LP PCH\n);
} else {
goto check_next;
}
--
1.8.4.2
___
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 39/62] drm/i915/bdw: on Broadwell, the panel fitter is on the pipe
On Sat, Nov 02, 2013 at 09:07:37PM -0700, Ben Widawsky wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
So you can use the panel fitter while the power well is disabled and
you also don't need to set the pipe bit.
v2: Rebased on top of Jesse's pfit refactor, which moved pfit state
into the pipe_config.
v3: Rebase on top of the latest Haswell/panel fitter rework, which
neatly resolves a FIXME we have in this patch here:
v4: Rebase on top of the new power domain framework.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com (v1)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index d464fd2..db848a9 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -756,7 +756,8 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc
*crtc)
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
struct drm_encoder *encoder = intel_encoder-base;
- struct drm_i915_private *dev_priv = crtc-dev-dev_private;
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
enum pipe pipe = intel_crtc-pipe;
enum transcoder cpu_transcoder = intel_crtc-config.cpu_transcoder;
enum port port = intel_ddi_get_encoder_port(intel_encoder);
@@ -792,10 +793,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc
*crtc)
if (cpu_transcoder == TRANSCODER_EDP) {
switch (pipe) {
case PIPE_A:
- /* Can only use the always-on power well for eDP when
- * not using the panel fitter, and when not using motion
- * blur mitigation (which we don't support). */
- if (intel_crtc-config.pch_pfit.enabled)
+ /* On Haswell, can only use the always-on power well for
+ * eDP when not using the panel fitter, and when not
+ * using motion blur mitigation (which we don't
+ * support). */
+ if (IS_HASWELL(dev)
intel_crtc-config.pch_pfit.enabled)
temp |= TRANS_DDI_EDP_INPUT_A_ONOFF;
else
temp |= TRANS_DDI_EDP_INPUT_A_ON;
--
1.8.4.2
___
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 36/62] drm/i915/bdw: Broadwell also has the power down well
On Sun, Nov 03, 2013 at 01:05:11PM +0200, Ville Syrjälä wrote:
On Sat, Nov 02, 2013 at 09:07:34PM -0700, Ben Widawsky wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Just like Haswell, but with the small twist that the panel fitter for pipe
A is
now also in the always-on power well.
v2: Use the new HAS_POWER_WELL macro.
v3: Rebase on top of intel_using_power_well patches.
v4: This time actually update the PFIT check correctly so that the
pipe A pfit is in the always-on domain.
v5: Rebase on top of the VGA power domain addition.
v6: Rebase on top of the new power domain infrastructure. Also pimp the
commit
message a bit while at it.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com (v1)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 6 +-
drivers/gpu/drm/i915/intel_pm.c | 5 +++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 64a3a8c..1a2e967 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -117,6 +117,10 @@ enum intel_display_power_domain {
#define HSW_ALWAYS_ON_POWER_DOMAINS ( \
BIT(POWER_DOMAIN_PIPE_A) | \
BIT(POWER_DOMAIN_TRANSCODER_EDP))
+#define BDW_ALWAYS_ON_POWER_DOMAINS ( \
+ BIT(POWER_DOMAIN_PIPE_A) | \
+ BIT(POWER_DOMAIN_TRANSCODER_EDP) | \
+ BIT(POWER_DOMAIN_PIPE_A_PANEL_FITTER))
enum hpd_pin {
HPD_NONE = 0,
@@ -1802,7 +1806,7 @@ struct drm_i915_file_private {
#define HAS_IPS(dev) (IS_ULT(dev))
#define HAS_DDI(dev) (INTEL_INFO(dev)-has_ddi)
-#define HAS_POWER_WELL(dev)(IS_HASWELL(dev))
+#define HAS_POWER_WELL(dev)(IS_HASWELL(dev) || IS_GEN8(dev))
IS_BROADWELL() please.
Yeah, that's an artifact of how the patches have been merged. I've moved
the IS_BROADWELL macro up in the series, but didn't fix all the patches.
R-b if I bikeshed this while applying?
-Daniel
#define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)-has_fpga_dbg)
#define HAS_PSR(dev) (IS_HASWELL(dev))
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 81ec2c3..caf31b7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5524,7 +5524,9 @@ static bool is_always_on_power_domain(struct
drm_device *dev,
BUG_ON(BIT(domain) ~POWER_DOMAIN_MASK);
- if (IS_HASWELL(dev)) {
+ if (IS_GEN8(dev)) {
Here too.
+ always_on_domains = BDW_ALWAYS_ON_POWER_DOMAINS;
+ } else if (IS_HASWELL(dev)) {
always_on_domains = HSW_ALWAYS_ON_POWER_DOMAINS;
} else {
WARN_ON(1);
@@ -6010,4 +6012,3 @@ void intel_pm_init(struct drm_device *dev)
INIT_DELAYED_WORK(dev_priv-rps.delayed_resume_work,
intel_gen6_powersave_work);
}
-
--
1.8.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 36/62] drm/i915/bdw: Broadwell also has the power down well
On Sun, Nov 03, 2013 at 12:24:13PM +0100, Daniel Vetter wrote:
On Sun, Nov 03, 2013 at 01:05:11PM +0200, Ville Syrjälä wrote:
On Sat, Nov 02, 2013 at 09:07:34PM -0700, Ben Widawsky wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Just like Haswell, but with the small twist that the panel fitter for
pipe A is
now also in the always-on power well.
v2: Use the new HAS_POWER_WELL macro.
v3: Rebase on top of intel_using_power_well patches.
v4: This time actually update the PFIT check correctly so that the
pipe A pfit is in the always-on domain.
v5: Rebase on top of the VGA power domain addition.
v6: Rebase on top of the new power domain infrastructure. Also pimp the
commit
message a bit while at it.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com (v1)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 6 +-
drivers/gpu/drm/i915/intel_pm.c | 5 +++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 64a3a8c..1a2e967 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -117,6 +117,10 @@ enum intel_display_power_domain {
#define HSW_ALWAYS_ON_POWER_DOMAINS (\
BIT(POWER_DOMAIN_PIPE_A) | \
BIT(POWER_DOMAIN_TRANSCODER_EDP))
+#define BDW_ALWAYS_ON_POWER_DOMAINS (\
+ BIT(POWER_DOMAIN_PIPE_A) | \
+ BIT(POWER_DOMAIN_TRANSCODER_EDP) | \
+ BIT(POWER_DOMAIN_PIPE_A_PANEL_FITTER))
enum hpd_pin {
HPD_NONE = 0,
@@ -1802,7 +1806,7 @@ struct drm_i915_file_private {
#define HAS_IPS(dev) (IS_ULT(dev))
#define HAS_DDI(dev) (INTEL_INFO(dev)-has_ddi)
-#define HAS_POWER_WELL(dev) (IS_HASWELL(dev))
+#define HAS_POWER_WELL(dev) (IS_HASWELL(dev) || IS_GEN8(dev))
IS_BROADWELL() please.
Yeah, that's an artifact of how the patches have been merged. I've moved
the IS_BROADWELL macro up in the series, but didn't fix all the patches.
R-b if I bikeshed this while applying?
Yep.
-Daniel
#define HAS_FPGA_DBG_UNCLAIMED(dev) (INTEL_INFO(dev)-has_fpga_dbg)
#define HAS_PSR(dev) (IS_HASWELL(dev))
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 81ec2c3..caf31b7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5524,7 +5524,9 @@ static bool is_always_on_power_domain(struct
drm_device *dev,
BUG_ON(BIT(domain) ~POWER_DOMAIN_MASK);
- if (IS_HASWELL(dev)) {
+ if (IS_GEN8(dev)) {
Here too.
+ always_on_domains = BDW_ALWAYS_ON_POWER_DOMAINS;
+ } else if (IS_HASWELL(dev)) {
always_on_domains = HSW_ALWAYS_ON_POWER_DOMAINS;
} else {
WARN_ON(1);
@@ -6010,4 +6012,3 @@ void intel_pm_init(struct drm_device *dev)
INIT_DELAYED_WORK(dev_priv-rps.delayed_resume_work,
intel_gen6_powersave_work);
}
-
--
1.8.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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
[Intel-gfx] [PATCH 63/62] drm/i915/bdw: Enable trickle feed on Broadwell
From: Ville Syrjälä ville.syrj...@linux.intel.com Like on HSW, trickle feed should always be enabled on BDW. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- Not sure this applies directly, I just put it together on top of -nightly. Thus it's not even compile tested. drivers/gpu/drm/i915/intel_display.c | 2 +- drivers/gpu/drm/i915/intel_sprite.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f34252d..4539550 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2156,7 +2156,7 @@ static int ironlake_update_plane(struct drm_crtc *crtc, else dspcntr = ~DISPPLANE_TILED; - if (IS_HASWELL(dev)) + if (IS_HASWELL(dev) || IS_BROADWELL(dev)) dspcntr = ~DISPPLANE_TRICKLE_FEED_DISABLE; else dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE; diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 8afaad6..2bcee75 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -260,7 +260,7 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, if (obj-tiling_mode != I915_TILING_NONE) sprctl |= SPRITE_TILED; - if (IS_HASWELL(dev)) + if (IS_HASWELL(dev) || IS_BROADWELL(dev)) sprctl = ~SPRITE_TRICKLE_FEED_DISABLE; else sprctl |= SPRITE_TRICKLE_FEED_DISABLE; -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] sna: buffer overrun
I ran into a regression in xf86-video-intel master. X would spin for several seconds and eventually I'd see a message like: [ 170.724] kgem_bo_write: failed to write 3600 bytes into BO handle=175: 14 in Xorg.0.log Bisected it down to the following commit: commit 4f41bf3de059c4e0a03fb161fb2e78d94be69e3f Author: Chris Wilson ch...@chris-wilson.co.uk Date: Tue Oct 29 09:56:10 2013 + sna: Try harder to complete writes Expunge our caches if we fail to write into a bo (presuming that allocation failure is the likely fixable cause). Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk It's obviously trying really really hard to write into that bo now ;). But failing eventually anyway. So I started digging deeper. The pwrite is failing with EFAULT. Some kernel debugging revealed that the fault happens when copying data from user space. Adding some debugging printf's shows that pwrite.data_ptr = 0x1cc19d9831f0 pwrite.size = 3648 and that the fault happens at address 0x1cc19d984000. This is the same 3600 byte buffer from the message. Obviously pwrite is reading beyond the end of the buffer, running into the next page, which isn't there. Now I'm seeing this on OpenBSD. I'm guessing this is actually a malloc()'ed buffer. And on OpenBSD malloc() is extremely nasty. It tries to align the allocated space such that the end lies right at the end of a page and inserts a guard page. It does this to catch buffer overruns like this. You're much less likely to hit something like this on Linux, unless you're using a special debug malloc library. This problem was introduced with the following commit: commit 95f4da647a4055545b09cae0834df0fa2127a458 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Wed Nov 30 11:59:31 2011 + sna: Align pwrite to transfer whole cachelines Daniel claims that this is will be faster, or will be once he has completed rewriting pwrite! Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk I fear that optimization simply isn't safe. ___ 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: - Tons more improvement to the display CRC code. It works now on all platforms supported by the i915 driver. Also there's an auto target now for platforms where some ports require a special CRC tap point. - More power domain infrastructure work from Imre. - Fixed locking for CRC capturing (Damien). - A pile of smaller improvements and fixes all over. Happy testing! Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Patch for crashing intel server
Hi Chris, I got a black screen while using your patch. /sys/kernel/debug/dri/0/i915_gem_objects contents are shown below. The first time is while the video is running; the second after stopping it. AFAICS, there is no difference between them. However, after starting a new video, there is a difference in active objects; not sure if it is related (I don't really know what any of it means). That is the third one. Thanks, Bas root@star:/sys/kernel/debug/dri/0# cat i915_gem_objects 220 objects, 36782080 bytes 131 [131] objects, 34430976 [34430976] bytes in gtt 0 [0] active objects, 0 [0] bytes 131 [131] inactive objects, 34430976 [34430976] bytes 49 unbound objects, 638976 bytes 1 purgeable objects, 4096 bytes 6 pinned mappable objects, 15884288 bytes 118 fault mappable objects, 27901952 bytes 536870912 [268435456] gtt total Xorg: 217 objects, 36642816 bytes (0 active, 30703616 inactive, 5922816 unbound) root@star:/sys/kernel/debug/dri/0# cat i915_gem_objects 220 objects, 36782080 bytes 131 [131] objects, 34430976 [34430976] bytes in gtt 0 [0] active objects, 0 [0] bytes 131 [131] inactive objects, 34430976 [34430976] bytes 49 unbound objects, 638976 bytes 1 purgeable objects, 4096 bytes 6 pinned mappable objects, 15884288 bytes 118 fault mappable objects, 27901952 bytes 536870912 [268435456] gtt total Xorg: 217 objects, 36642816 bytes (0 active, 30703616 inactive, 5922816 unbound) root@star:/sys/kernel/debug/dri/0# cat i915_gem_objects 220 objects, 36782080 bytes 131 [131] objects, 34430976 [34430976] bytes in gtt 2 [2] active objects, 32768 [32768] bytes 129 [129] inactive objects, 34398208 [34398208] bytes 49 unbound objects, 638976 bytes 1 purgeable objects, 4096 bytes 6 pinned mappable objects, 15884288 bytes 118 fault mappable objects, 27901952 bytes 536870912 [268435456] gtt total Xorg: 217 objects, 36642816 bytes (32768 active, 30670848 inactive, 5922816 unbound) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] More questions and patches for 835GM/ns2501 DVO
Hi Daniel, dear intel experts, again trying to get the old Fujitsu laptop to work. The problem with the latest drm-nightly built is that the system again locks up - if the bios is configured to show an image only on the internal display and nothing on the external VGA. If the bios is configured to shared video, booting works fine. This seems to be related to the problem that, apparently, the bios seems to prefer to connect the internal display to pipe B and not pipe A, and hence during bootstrap just configuring the dpll for pipe A is not enough. That being said, the following modifications for ns2501 will fix this: struct ns2501_priv need to get a new field int pll_b. In enable_dvo(), the setting for the dpll_b needs to be saved, too, and installed, too: I915_WRITE(_DPLL_A, 0xd082); I915_WRITE(_DPLL_B, 0xd082); It is absolutely unnecessary to overwrite the DVOC register, this is configured fine. In restore_dvo(), the dpll_b configuration needs to be restored as well. The DVOC register need not to be touched. In fact, the current enable_dvo() has a bug in so far as it saves the wrong register. However, what is more stunning is how this bug is triggered. Actually, intel_display.c computes the dpll register value correctly (as it seems), but __intel_set_mode() (around line 9356) is a bit strange: First, it disables the crtcs, then sets the mode, and the enables the crtcs. Unfortunately, this cannot work with with the ns2501 since a disabled PLL will block any communication with with the DVO. I tried to move the enable call above the intel_crtc_mode_set(), but this did not work either. I do not know enough about the inner workings of intel_display.c to fix this properly, but the problem seems to be exactly that: An incorrectly configured DPLL disables the communication with the DVO, hence the need for the workaround. Last, a question: All I can get with the current intel driver is a shared display between the internal and external display. Is there any way (through xrandr) to get two different configurations such that the external monitor is using one configuration feed through pipe A, and the internal display is feed through pipe B with another configuration? And finally: As the internal display is only a 6 bit display, is there a way to enable dithering on the 835GM to avoid the banding artifacts? Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] More questions and patches for 835GM/ns2501 DVO
On Sun, Nov 03, 2013 at 05:55:37PM +0100, Thomas Richter wrote: Hi Daniel, dear intel experts, again trying to get the old Fujitsu laptop to work. The problem with the latest drm-nightly built is that the system again locks up - if the bios is configured to show an image only on the internal display and nothing on the external VGA. If the bios is configured to shared video, booting works fine. This seems to be related to the problem that, apparently, the bios seems to prefer to connect the internal display to pipe B and not pipe A, and hence during bootstrap just configuring the dpll for pipe A is not enough. That being said, the following modifications for ns2501 will fix this: struct ns2501_priv need to get a new field int pll_b. In enable_dvo(), the setting for the dpll_b needs to be saved, too, and installed, too: I915_WRITE(_DPLL_A, 0xd082); I915_WRITE(_DPLL_B, 0xd082); It is absolutely unnecessary to overwrite the DVOC register, this is configured fine. In restore_dvo(), the dpll_b configuration needs to be restored as well. The DVOC register need not to be touched. In fact, the current enable_dvo() has a bug in so far as it saves the wrong register. However, what is more stunning is how this bug is triggered. Actually, intel_display.c computes the dpll register value correctly (as it seems), but __intel_set_mode() (around line 9356) is a bit strange: First, it disables the crtcs, then sets the mode, and the enables the crtcs. Unfortunately, this cannot work with with the ns2501 since a disabled PLL will block any communication with with the DVO. I tried to move the enable call above the intel_crtc_mode_set(), but this did not work either. I do not know enough about the inner workings of intel_display.c to fix this properly, but the problem seems to be exactly that: An incorrectly configured DPLL disables the communication with the DVO, hence the need for the workaround. Have you tried my patch to reorder the dvo sequence a bit? That /should/ get all these things right: http://www.spinics.net/lists/intel-gfx/msg34349.html Last, a question: All I can get with the current intel driver is a shared display between the internal and external display. Is there any way (through xrandr) to get two different configurations such that the external monitor is using one configuration feed through pipe A, and the internal display is feed through pipe B with another configuration? --above/below should achieve that, presuming there's not a different bug somewhere that prevents this from working correctly. And finally: As the internal display is only a 6 bit display, is there a way to enable dithering on the 835GM to avoid the banding artifacts? Iirc we always send 8bit data over the dvo bus, so any dithering should be done in the dvo encoder. The built-in lvds encoder on i855gm and later has it's own dithering settting, and otherwise I'm not aware of any that would apply to gen2 graphics. Also: If you're running sna, have you checked that you indeed run X at 32bit depth? The default since a while is 15 bits. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] More questions and patches for 835GM/ns2501 DVO
On Sun, Nov 03, 2013 at 06:12:08PM +0100, Daniel Vetter wrote: On Sun, Nov 03, 2013 at 05:55:37PM +0100, Thomas Richter wrote: Hi Daniel, dear intel experts, again trying to get the old Fujitsu laptop to work. The problem with the latest drm-nightly built is that the system again locks up - if the bios is configured to show an image only on the internal display and nothing on the external VGA. If the bios is configured to shared video, booting works fine. This seems to be related to the problem that, apparently, the bios seems to prefer to connect the internal display to pipe B and not pipe A, and hence during bootstrap just configuring the dpll for pipe A is not enough. That being said, the following modifications for ns2501 will fix this: struct ns2501_priv need to get a new field int pll_b. In enable_dvo(), the setting for the dpll_b needs to be saved, too, and installed, too: I915_WRITE(_DPLL_A, 0xd082); I915_WRITE(_DPLL_B, 0xd082); It is absolutely unnecessary to overwrite the DVOC register, this is configured fine. In restore_dvo(), the dpll_b configuration needs to be restored as well. The DVOC register need not to be touched. In fact, the current enable_dvo() has a bug in so far as it saves the wrong register. However, what is more stunning is how this bug is triggered. Actually, intel_display.c computes the dpll register value correctly (as it seems), but __intel_set_mode() (around line 9356) is a bit strange: First, it disables the crtcs, then sets the mode, and the enables the crtcs. Unfortunately, this cannot work with with the ns2501 since a disabled PLL will block any communication with with the DVO. I tried to move the enable call above the intel_crtc_mode_set(), but this did not work either. I do not know enough about the inner workings of intel_display.c to fix this properly, but the problem seems to be exactly that: An incorrectly configured DPLL disables the communication with the DVO, hence the need for the workaround. Have you tried my patch to reorder the dvo sequence a bit? That /should/ get all these things right: http://www.spinics.net/lists/intel-gfx/msg34349.html There's also a follow-up patch for you to test: http://www.spinics.net/lists/intel-gfx/msg34350.html That would prove that the first patch does indeed work. Note that patch 1 in this series is already merged. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 42/62] drm/i915/bdw: Implement WaSwitchSolVfFArbitrationPriority
On Sun, Nov 03, 2013 at 01:07:58PM +0200, Ville Syrjälä wrote: On Sat, Nov 02, 2013 at 09:07:40PM -0700, Ben Widawsky wrote: GEN8 also needs this workaround. Not according to the w/a database. But the register description is the same for both HSW and BDW. Also for HSW, the w/a doesn't actually say whether we should set or clear the bit. the default is listed to be 0, so I guess we should set it, but then it's unclear why BDW wouldn't need the w/a. Once again a very poorly docuemnted w/a :( Just an FYI: all workarounds for Broadwell came from the bspec, as the workaround database did not exist for Broadwell at that time. Also, I was informally told not to trust the workaround database yet. [snip] -- Ben Widawsky, 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] More questions and patches for 835GM/ns2501 DVO
On 03.11.2013 18:13, Daniel Vetter wrote: Have you tried my patch to reorder the dvo sequence a bit? That /should/ get all these things right: http://www.spinics.net/lists/intel-gfx/msg34349.html There's also a follow-up patch for you to test: http://www.spinics.net/lists/intel-gfx/msg34350.html That would prove that the first patch does indeed work. Note that patch 1 in this series is already merged. Thanks, I tried. Actually, this worked fairly (but not perfectly) well. I no longer get a stuck DVO as I did before, i.e. the re-enable logic is not triggered anymore. However, I do get (occasionally) a kernel-oops: [ cut here ] WARNING: CPU: 0 PID: 2311 at drivers/gpu/drm/i915/intel_display.c:1098 assert_cursor.constprop.68+0xba/0xc0 [i915]() cursor on pipe A assertion failure (expected off, current on) Modules linked in: cpufreq_stats binfmt_misc michael_mic arc4 ecb lib80211_crypt_tkip lib80211_crypt_ccmp fuse nfsd exportfs nfs_acl nfs lockd fscache sunrpc loop firewire_sbp2 hostap_cs hostap snd_intel8x0 snd_ac97_codec ac97_bus lib80211 snd_pcm i915 snd_page_alloc snd_seq snd_seq_device snd_timer psmouse snd pcmcia apanel input_polldev soundcore yenta_socket pcmcia_rsrc pcmcia_core lpc_ich i2c_i801 mfd_core pcspkr i2c_algo_bit rng_core serio_raw evdev drm_kms_helper drm fujitsu_laptop led_class intel_agp intel_gtt agpgart i2c_core video ac button hid_generic usbhid hid sg sr_mod cdrom firewire_ohci firewire_core crc_itu_t 8139too 8139cp mii uhci_hcd usbcore usb_common CPU: 0 PID: 2311 Comm: Xorg Tainted: GW3.12.0-rc7+ #13 Hardware name: FUJITSU SIEMENS LIFEBOOK S Series/FJNB159, BIOS Version 1.06 07/02/2002 c12f8c44 c1033def f8ad3990 f6adfab0 0907 f8ad25d8 044a f8a81ffa f8a81ffa f5ca8000 0041 f5ca8000 c1033eb3 0009 f6adfa98 f8ad3990 f6adfab0 f8a81ffa f8ad25d8 044a f8ad3990 0041 f8adb9a0 Call Trace: [c12f8c44] ? dump_stack+0xa/0x13 [c1033def] ? warn_slowpath_common+0x7f/0xb0 [f8a81ffa] ? assert_cursor.constprop.68+0xba/0xc0 [i915] [f8a81ffa] ? assert_cursor.constprop.68+0xba/0xc0 [i915] [c1033eb3] ? warn_slowpath_fmt+0x33/0x40 [f8a81ffa] ? assert_cursor.constprop.68+0xba/0xc0 [i915] [f8a83b90] ? intel_disable_pipe+0x30/0xb0 [i915] [f8a8491a] ? i9xx_crtc_disable+0xca/0x2f0 [i915] [f8a8b25e] ? __intel_set_mode+0x7ae/0x13b0 [i915] [f8a8e1f3] ? intel_set_mode+0x23/0x40 [i915] [f8a8e9bc] ? intel_crtc_set_config+0x7ac/0x9d0 [i915] [f802fe33] ? drm_mode_set_config_internal+0x43/0xb0 [drm] [f81386a5] ? drm_fb_helper_set_par+0x45/0xac [drm_kms_helper] [c11a7976] ? fb_set_var+0x1a6/0x420 [c10eec6e] ? __find_get_block+0x9e/0x160 [c11b56e0] ? fbcon_blank+0x290/0x2d0 [c1203848] ? do_unblank_screen+0x98/0x1b0 [c1201acd] ? notify_update+0x1d/0x30 [c11faa12] ? complete_change_console+0x52/0xe0 [c11fbba4] ? vt_ioctl+0x1104/0x1220 [f802a1d0] ? drm_setmaster_ioctl+0xe0/0xe0 [drm] [c11faaa0] ? complete_change_console+0xe0/0xe0 [c11f17da] ? tty_ioctl+0x21a/0x9a0 [c10adb12] ? do_wp_page.isra.92+0x2a2/0x650 [c10af428] ? handle_mm_fault+0x318/0x610 [c11f15c0] ? no_tty+0x20/0x20 [c10d66ac] ? do_vfs_ioctl+0x7c/0x550 [c102d221] ? __do_page_fault+0x1b1/0x490 [c10c7d17] ? vfs_write+0x137/0x1b0 [c10d6bc6] ? SyS_ioctl+0x46/0x80 [c12fc19e] ? sysenter_do_call+0x12/0x26 ---[ end trace 85d231d1072e932a ]--- If this happens, I get a black screen with only a cursor on it. Switching to the console and back restores the screen. I will try how the patch performs with an external monitor on. BTW, there is a second issue related to this laptop: The vertical position of the boot console is sometimes off, and sometimes it is not visible at all. Sometimes it is too high (the first line is above the first line of the monitor) or too low (the first line is somewhere in the middle of the screen). Seems to me that some of the registers should only be written to at the vertical blank? Thanks, however! This is so far definitely an improvement. Will report back with the two-monitor setup. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] More questions and patches for 835GM/ns2501 DVO
On 03.11.2013 18:13, Daniel Vetter wrote: Have you tried my patch to reorder the dvo sequence a bit? That /should/ get all these things right: http://www.spinics.net/lists/intel-gfx/msg34349.html There's also a follow-up patch for you to test: http://www.spinics.net/lists/intel-gfx/msg34350.html That would prove that the first patch does indeed work. Note that patch 1 in this series is already merged. Sorry, but using an external monitor is still not working correctly. When booting with an external monitor connected, I either get no image at all (bios = internal) or flickering on the external monitor and nothing internally (bios = shared). When connecting the external monitor after X has started, I can get a working image on the monitor, but not on the internal panel. The DVO locks up again. If I configure the internal panel, then reconfigure the VGA, I get a stable image. If I try to change the internal panel dimensions then, I get a flickering external screen. The DVO is locked up in either case. I get the following when switching internally from 800x600 to 1024x768 (just as an example): /* snip */ Nov 3 20:12:20 tyleet kernel: [ 1399.497881] [drm:drm_mode_setcrtc], [CRTC:4] Nov 3 20:12:20 tyleet kernel: [ 1399.497890] [drm:drm_framebuffer_reference], FB ID: 39 Nov 3 20:12:20 tyleet kernel: [ 1399.497907] [drm:drm_mode_setcrtc], [CONNECTOR:8:DVI-I-1] Nov 3 20:12:20 tyleet kernel: [ 1399.497916] [drm:intel_crtc_set_config], [CRTC:4] [FB:39] #connectors=1 (x y) (0 0) Nov 3 20:12:20 tyleet kernel: [ 1399.497928] [drm:intel_set_config_compute_mode_changes], modes are different, full mode set Nov 3 20:12:20 tyleet kernel: [ 1399.497935] [drm:drm_mode_debug_printmodeline], Modeline 16: 0 4 800 840 968 1056 600 601 605 628 0x0 0x5 Nov 3 20:12:20 tyleet kernel: [ 1399.497948] [drm:drm_mode_debug_printmodeline], Modeline 16: 0 65000 1024 1048 1184 1344 768 771 777 806 0x0 0xa Nov 3 20:12:20 tyleet kernel: [ 1399.497960] [drm:intel_set_config_compute_mode_changes], computed changes for [CRTC:4], mode_changed=1, fb_changed=0 Nov 3 20:12:20 tyleet kernel: [ 1399.497970] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:VGA-1] to [CRTC:3] Nov 3 20:12:20 tyleet kernel: [ 1399.497978] [drm:intel_modeset_stage_output_state], [CONNECTOR:8:DVI-I-1] to [CRTC:4] Nov 3 20:12:20 tyleet kernel: [ 1399.497991] [drm:intel_modeset_affected_pipes], set mode pipe masks: modeset: 2, prepare: 2, disable: 0 Nov 3 20:12:20 tyleet kernel: [ 1399.498008] [drm:connected_sink_compute_bpp], [CONNECTOR:8:DVI-I-1] checking for sink bpp constrains Nov 3 20:12:20 tyleet kernel: [ 1399.498020] [drm:intel_modeset_pipe_config], plane bpp: 24, pipe bpp: 24, dithering: 0 Nov 3 20:12:20 tyleet kernel: [ 1399.498028] [drm:intel_dump_pipe_config], [CRTC:4][modeset] config for pipe B Nov 3 20:12:20 tyleet kernel: [ 1399.498036] [drm:intel_dump_pipe_config], cpu_transcoder: B Nov 3 20:12:20 tyleet kernel: [ 1399.498042] [drm:intel_dump_pipe_config], pipe bpp: 24, dithering: 0 Nov 3 20:12:20 tyleet kernel: [ 1399.498049] [drm:intel_dump_pipe_config], fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0 Nov 3 20:12:20 tyleet kernel: [ 1399.498058] [drm:intel_dump_pipe_config], dp: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0 Nov 3 20:12:20 tyleet kernel: [ 1399.498066] [drm:intel_dump_pipe_config], requested mode: Nov 3 20:12:20 tyleet kernel: [ 1399.498072] [drm:drm_mode_debug_printmodeline], Modeline 0: 0 65000 1024 1048 1184 1344 768 771 777 806 0x0 0xa Nov 3 20:12:20 tyleet kernel: [ 1399.498084] [drm:intel_dump_pipe_config], adjusted mode: Nov 3 20:12:20 tyleet kernel: [ 1399.498090] [drm:drm_mode_debug_printmodeline], Modeline 0: 0 65000 1024 1048 1184 1344 768 771 777 806 0x0 0xa Nov 3 20:12:20 tyleet kernel: [ 1399.498102] [drm:intel_dump_crtc_timings], crtc timings: 65000 1024 1048 1184 1344 768 771 777 806, type: 0x0 flags: 0xa Nov 3 20:12:20 tyleet kernel: [ 1399.498112] [drm:intel_dump_pipe_config], port clock: 65000 Nov 3 20:12:20 tyleet kernel: [ 1399.498118] [drm:intel_dump_pipe_config], pipe src size: 1024x768 Nov 3 20:12:20 tyleet kernel: [ 1399.498125] [drm:intel_dump_pipe_config], gmch pfit: control: 0x, ratios: 0x, lvds border: 0x Nov 3 20:12:20 tyleet kernel: [ 1399.498132] [drm:intel_dump_pipe_config], pch pfit: pos: 0x, size: 0x, disabled Nov 3 20:12:20 tyleet kernel: [ 1399.498140] [drm:intel_dump_pipe_config], ips: 0 Nov 3 20:12:20 tyleet kernel: [ 1399.498145] [drm:intel_dump_pipe_config], double wide: 0 Nov 3 20:12:20 tyleet kernel: [ 1399.498158] [drm:ns2501_dpms], ns2501_dpms: Trying set the dpms of the DVO to 0 Nov 3 20:12:20 tyleet kernel: [ 1399.498438] [drm:ns2501_writeb], Unable to write register 0x08 to i915 gmbus dpb:56 Nov 3 20:12:20 tyleet kernel: [ 1399.498703] [drm:ns2501_writeb], Unable to write register 0x34 to i915 gmbus dpb:56 Nov 3
Re: [Intel-gfx] sna: buffer overrun
On Sun, Nov 03, 2013 at 01:22:52PM +0100, Mark Kettenis wrote:
I ran into a regression in xf86-video-intel master. X would spin
for several seconds and eventually I'd see a message like:
[ 170.724] kgem_bo_write: failed to write 3600 bytes into BO handle=175: 14
in Xorg.0.log
Bisected it down to the following commit:
commit 4f41bf3de059c4e0a03fb161fb2e78d94be69e3f
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Tue Oct 29 09:56:10 2013 +
sna: Try harder to complete writes
Expunge our caches if we fail to write into a bo (presuming that
allocation failure is the likely fixable cause).
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
It's obviously trying really really hard to write into that bo now ;).
But failing eventually anyway. So I started digging deeper. The
pwrite is failing with EFAULT. Some kernel debugging revealed that
the fault happens when copying data from user space. Adding some
debugging printf's shows that
pwrite.data_ptr = 0x1cc19d9831f0
pwrite.size = 3648
and that the fault happens at address 0x1cc19d984000. This is the
same 3600 byte buffer from the message. Obviously pwrite is reading
beyond the end of the buffer, running into the next page, which isn't
there.
Now I'm seeing this on OpenBSD. I'm guessing this is actually a
malloc()'ed buffer. And on OpenBSD malloc() is extremely nasty. It
tries to align the allocated space such that the end lies right at the
end of a page and inserts a guard page. It does this to catch buffer
overruns like this. You're much less likely to hit something like
this on Linux, unless you're using a special debug malloc library.
This problem was introduced with the following commit:
commit 95f4da647a4055545b09cae0834df0fa2127a458
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Wed Nov 30 11:59:31 2011 +
sna: Align pwrite to transfer whole cachelines
Daniel claims that this is will be faster, or will be once he has
completed rewriting pwrite!
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
I fear that optimization simply isn't safe.
It was. All the local allocations are page-aligned, the issue are the
couple of places where we upload from other buffers.
diff --git a/src/sna/kgem.c b/src/sna/kgem.c
index 264a379..1217367 100644
--- a/src/sna/kgem.c
+++ b/src/sna/kgem.c
@@ -482,7 +482,7 @@ bool kgem_bo_write(struct kgem *kgem, struct kgem_bo *bo,
assert(length = bytes(bo));
retry:
- if (gem_write(kgem-fd, bo-handle, 0, length, data)) {
+ if (__gem_write(kgem-fd, bo-handle, 0, length, data)) {
int err = errno;
assert(err != EINVAL);
-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] More questions and patches for 835GM/ns2501 DVO
On Sun, Nov 3, 2013 at 8:00 PM, Thomas Richter t...@math.tu-berlin.de wrote: On 03.11.2013 18:13, Daniel Vetter wrote: Have you tried my patch to reorder the dvo sequence a bit? That /should/ get all these things right: http://www.spinics.net/lists/intel-gfx/msg34349.html There's also a follow-up patch for you to test: http://www.spinics.net/lists/intel-gfx/msg34350.html That would prove that the first patch does indeed work. Note that patch 1 in this series is already merged. Thanks, I tried. Actually, this worked fairly (but not perfectly) well. I no longer get a stuck DVO as I did before, i.e. the re-enable logic is not triggered anymore. However, I do get (occasionally) a kernel-oops: That's just a warning, not an oops ... [ cut here ] WARNING: CPU: 0 PID: 2311 at drivers/gpu/drm/i915/intel_display.c:1098 assert_cursor.constprop.68+0xba/0xc0 [i915]() cursor on pipe A assertion failure (expected off, current on) Modules linked in: cpufreq_stats binfmt_misc michael_mic arc4 ecb lib80211_crypt_tkip lib80211_crypt_ccmp fuse nfsd exportfs nfs_acl nfs lockd fscache sunrpc loop firewire_sbp2 hostap_cs hostap snd_intel8x0 snd_ac97_codec ac97_bus lib80211 snd_pcm i915 snd_page_alloc snd_seq snd_seq_device snd_timer psmouse snd pcmcia apanel input_polldev soundcore yenta_socket pcmcia_rsrc pcmcia_core lpc_ich i2c_i801 mfd_core pcspkr i2c_algo_bit rng_core serio_raw evdev drm_kms_helper drm fujitsu_laptop led_class intel_agp intel_gtt agpgart i2c_core video ac button hid_generic usbhid hid sg sr_mod cdrom firewire_ohci firewire_core crc_itu_t 8139too 8139cp mii uhci_hcd usbcore usb_common CPU: 0 PID: 2311 Comm: Xorg Tainted: GW3.12.0-rc7+ #13 Hardware name: FUJITSU SIEMENS LIFEBOOK S Series/FJNB159, BIOS Version 1.06 07/02/2002 c12f8c44 c1033def f8ad3990 f6adfab0 0907 f8ad25d8 044a f8a81ffa f8a81ffa f5ca8000 0041 f5ca8000 c1033eb3 0009 f6adfa98 f8ad3990 f6adfab0 f8a81ffa f8ad25d8 044a f8ad3990 0041 f8adb9a0 Call Trace: [c12f8c44] ? dump_stack+0xa/0x13 [c1033def] ? warn_slowpath_common+0x7f/0xb0 [f8a81ffa] ? assert_cursor.constprop.68+0xba/0xc0 [i915] [f8a81ffa] ? assert_cursor.constprop.68+0xba/0xc0 [i915] [c1033eb3] ? warn_slowpath_fmt+0x33/0x40 [f8a81ffa] ? assert_cursor.constprop.68+0xba/0xc0 [i915] [f8a83b90] ? intel_disable_pipe+0x30/0xb0 [i915] [f8a8491a] ? i9xx_crtc_disable+0xca/0x2f0 [i915] [f8a8b25e] ? __intel_set_mode+0x7ae/0x13b0 [i915] [f8a8e1f3] ? intel_set_mode+0x23/0x40 [i915] [f8a8e9bc] ? intel_crtc_set_config+0x7ac/0x9d0 [i915] [f802fe33] ? drm_mode_set_config_internal+0x43/0xb0 [drm] [f81386a5] ? drm_fb_helper_set_par+0x45/0xac [drm_kms_helper] [c11a7976] ? fb_set_var+0x1a6/0x420 [c10eec6e] ? __find_get_block+0x9e/0x160 [c11b56e0] ? fbcon_blank+0x290/0x2d0 [c1203848] ? do_unblank_screen+0x98/0x1b0 [c1201acd] ? notify_update+0x1d/0x30 [c11faa12] ? complete_change_console+0x52/0xe0 [c11fbba4] ? vt_ioctl+0x1104/0x1220 [f802a1d0] ? drm_setmaster_ioctl+0xe0/0xe0 [drm] [c11faaa0] ? complete_change_console+0xe0/0xe0 [c11f17da] ? tty_ioctl+0x21a/0x9a0 [c10adb12] ? do_wp_page.isra.92+0x2a2/0x650 [c10af428] ? handle_mm_fault+0x318/0x610 [c11f15c0] ? no_tty+0x20/0x20 [c10d66ac] ? do_vfs_ioctl+0x7c/0x550 [c102d221] ? __do_page_fault+0x1b1/0x490 [c10c7d17] ? vfs_write+0x137/0x1b0 [c10d6bc6] ? SyS_ioctl+0x46/0x80 [c12fc19e] ? sysenter_do_call+0x12/0x26 ---[ end trace 85d231d1072e932a ]--- If this happens, I get a black screen with only a cursor on it. Switching to the console and back restores the screen. Hm, that would mean that the cursor is somehow stuck in the enabled state, despite that we've tried to disabled it very hard. Can you please try out the below patch? If this doesn't work please take not of the different WARNINGs you're hitting and whether it's always the same one with the same calltrace or something different. I think for now we should try to get the single monitor case working - I have a few theories for the dual-screen issues, but there's not much point working on them if the simple case doesn't work yet. Also I think I'll merge the two patches if they don't make things worse for you, imo it's the right approach and at least conceptually should be able to avoid all these retry loops. Thanks, Daniel diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f34252d134b6..04d2699f51b4 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7123,7 +7123,9 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32 base) intel_crtc-cursor_visible = visible; } /* and commit changes on next vblank */ + POSTING_READ(CURCNTR(pipe)); I915_WRITE(CURBASE(pipe), base); + POSTING_READ(CURBASE(pipe)); } static void ivb_update_cursor(struct drm_crtc *crtc, u32 base) @@ -7152,7 +7154,9 @@
Re: [Intel-gfx] [PATCH 04/62] drm/i915/bdw: Add device IDs
On Sat, Nov 02, 2013 at 09:07:02PM -0700, Ben Widawsky wrote:
@@ -367,7 +385,9 @@ static const struct intel_device_info
intel_haswell_m_info = {
INTEL_HSW_D_IDS(intel_haswell_d_info), \
INTEL_HSW_M_IDS(intel_haswell_m_info), \
INTEL_VLV_M_IDS(intel_valleyview_m_info), \
- INTEL_VLV_D_IDS(intel_valleyview_d_info)
+ INTEL_VLV_D_IDS(intel_valleyview_d_info), \
+ INTEL_BDW_PCI_IDS_M(intel_broadwell_m_info), \
+ INTEL_BDW_PCI_IDS_D(intel_broadwell_d_info)
Inconsistent naming scheme post Jesse-rebase.
static const struct pci_device_id pciidlist[] = {/* aka */
INTEL_PCI_IDS,
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 8a10f5c..d35bc0b 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -208,4 +208,31 @@
#define INTEL_VLV_D_IDS(info) \
INTEL_VGA_DEVICE(0x0155, info)
+#define _INTEL_BDW_PCI_ID_M(gt, id, info) \
+ INTEL_VGA_DEVICEgt) - 1) 4) | (id), info)
+#define _INTEL_BDW_PCI_ID_D(gt, id, info) \
+ INTEL_VGA_DEVICEgt) - 1) 4) | (id), info)
+
+#define INTEL_BDW_PCI_ID_M(gt, info) \
+ _INTEL_BDW_PCI_ID_M(gt, 0x1606, info), /* ULT */ \
+ _INTEL_BDW_PCI_ID_M(gt, 0x160B, info), /* Iris */ \
+ _INTEL_BDW_PCI_ID_M(gt, 0x160E, info) /* ULX */
+
+#define INTEL_BDW_PCI_ID_D(gt, info) \
+ _INTEL_BDW_PCI_ID_M(gt, 0x160A, info), /* Server */ \
+ _INTEL_BDW_PCI_ID_M(gt, 0x160D, info) /* Workstation */
+
+#define INTEL_BDW_PCI_IDS_M(info) \
+ INTEL_BDW_PCI_ID_M(1, info), \
+ INTEL_BDW_PCI_ID_M(2, info), \
+ INTEL_BDW_PCI_ID_M(3, info), \
+ INTEL_VGA_DEVICE(0x0BD0, info) /* Simulator GT1 */
+
+#define INTEL_BDW_PCI_IDS_D(info) \
+ INTEL_BDW_PCI_ID_D(1, info), \
+ INTEL_BDW_PCI_ID_D(2, info), \
+ INTEL_BDW_PCI_ID_D(3, info), \
+ INTEL_VGA_DEVICE(0x0BD1, info), /* Simulator GT2 */ \
+ INTEL_VGA_DEVICE(0x0BD2, info) /*/Simulator GT3 */
I thought we weren't adding internal simulator ids upstream?
-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] sna: buffer overrun
Date: Sun, 3 Nov 2013 19:43:48 +
From: Chris Wilson ch...@chris-wilson.co.uk
On Sun, Nov 03, 2013 at 01:22:52PM +0100, Mark Kettenis wrote:
I ran into a regression in xf86-video-intel master. X would spin
for several seconds and eventually I'd see a message like:
[ 170.724] kgem_bo_write: failed to write 3600 bytes into BO handle=175:
14
in Xorg.0.log
Bisected it down to the following commit:
commit 4f41bf3de059c4e0a03fb161fb2e78d94be69e3f
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Tue Oct 29 09:56:10 2013 +
sna: Try harder to complete writes
Expunge our caches if we fail to write into a bo (presuming that
allocation failure is the likely fixable cause).
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
It's obviously trying really really hard to write into that bo now ;).
But failing eventually anyway. So I started digging deeper. The
pwrite is failing with EFAULT. Some kernel debugging revealed that
the fault happens when copying data from user space. Adding some
debugging printf's shows that
pwrite.data_ptr = 0x1cc19d9831f0
pwrite.size = 3648
and that the fault happens at address 0x1cc19d984000. This is the
same 3600 byte buffer from the message. Obviously pwrite is reading
beyond the end of the buffer, running into the next page, which isn't
there.
Now I'm seeing this on OpenBSD. I'm guessing this is actually a
malloc()'ed buffer. And on OpenBSD malloc() is extremely nasty. It
tries to align the allocated space such that the end lies right at the
end of a page and inserts a guard page. It does this to catch buffer
overruns like this. You're much less likely to hit something like
this on Linux, unless you're using a special debug malloc library.
This problem was introduced with the following commit:
commit 95f4da647a4055545b09cae0834df0fa2127a458
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Wed Nov 30 11:59:31 2011 +
sna: Align pwrite to transfer whole cachelines
Daniel claims that this is will be faster, or will be once he has
completed rewriting pwrite!
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
I fear that optimization simply isn't safe.
It was. All the local allocations are page-aligned, the issue are the
couple of places where we upload from other buffers.
diff --git a/src/sna/kgem.c b/src/sna/kgem.c
index 264a379..1217367 100644
--- a/src/sna/kgem.c
+++ b/src/sna/kgem.c
@@ -482,7 +482,7 @@ bool kgem_bo_write(struct kgem *kgem, struct kgem_bo *bo,
assert(length = bytes(bo));
retry:
- if (gem_write(kgem-fd, bo-handle, 0, length, data)) {
+ if (__gem_write(kgem-fd, bo-handle, 0, length, data)) {
int err = errno;
assert(err != EINVAL);
Fixed it the same way here, and things seem stable enough. So I guess
that's a:
Tested-by: Mark Kettenis kette...@openbsd.org
Reviewed-by: Mark Kettenis kette...@openbsd.org
Thanks,
Mark
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] More questions and patches for 835GM/ns2501 DVO
On 03.11.2013 22:18, Daniel Vetter wrote: Hm, that would mean that the cursor is somehow stuck in the enabled state, despite that we've tried to disabled it very hard. Can you please try out the below patch? If this doesn't work please take not of the different WARNINGs you're hitting and whether it's always the same one with the same calltrace or something different. I think for now we should try to get the single monitor case working - I have a few theories for the dual-screen issues, but there's not much point working on them if the simple case doesn't work yet. Also I think I'll merge the two patches if they don't make things worse for you, imo it's the right approach and at least conceptually should be able to avoid all these retry loops. Thanks for the patches. Tried quite a bit, and haven't seen the warning yet. Looks like the one-monitor case works quite fine now, except that the boot console is vertically off, which is just annoying though not problematic. I also tried a lot with the two-monitor case and again went deeply into the DPLL setup logic. The differences I observed before are simply due to the initial resolution (800x600), in the final resolution, the DPLL settings are actually correct. What I get there is: --- Configuration found for regular display 1024x768: Nov 3 23:33:30 tyleet kernel: [9.122481] [drm:i9xx_find_best_dpll], clock.m1 = 21 Nov 3 23:33:30 tyleet kernel: [9.122483] [drm:i9xx_find_best_dpll], clock.m2 = 13 Nov 3 23:33:30 tyleet kernel: [9.122485] [drm:i9xx_find_best_dpll], clock.n = 4 Nov 3 23:33:30 tyleet kernel: [9.122488] [drm:i9xx_find_best_dpll], clock.p1 = 4 for 800x600: Nov 3 23:38:41 tyleet kernel: [ 368.725507] [drm:i9xx_find_best_dpll], clock.m1 = 19 Nov 3 23:38:41 tyleet kernel: [ 368.725514] [drm:i9xx_find_best_dpll], clock.m2 = 13 Nov 3 23:38:41 tyleet kernel: [ 368.725521] [drm:i9xx_find_best_dpll], clock.n = 4 Nov 3 23:38:41 tyleet kernel: [ 368.725528] [drm:i9xx_find_best_dpll], clock.p1 = 6 640 x 480: Nov 3 23:40:05 tyleet kernel: [ 452.965855] [drm:i9xx_find_best_dpll], clock.m1 = 20 Nov 3 23:40:05 tyleet kernel: [ 452.965862] [drm:i9xx_find_best_dpll], clock.m2 = 14 Nov 3 23:40:05 tyleet kernel: [ 452.965869] [drm:i9xx_find_best_dpll], clock.n = 3 Nov 3 23:40:05 tyleet kernel: [ 452.965876] [drm:i9xx_find_best_dpll], clock.p1 = 12 And even in the two-monitor case, the DPLL for DPLL_B is setup correctly. Thus, *that* does not seem the cause of the problem. What is different is the DVO setting: bit differences: In the two-monitor case, the internal DVOC register is 0xd000409c, in the one-monitor case it is: 0x90004084 Differences are: DVO bit 30 should be 0 is 1. DVO_PIPE_B_SELECTenabled DVO bit 4 should be 0 is 1. DVO_VSYNC_ACTIVE_HIGH DVO bit 3 should be 0 is 1. DVO_HSYNC_ACTIVE_HIGH Now, the bit 30 is clear, though I wonder why the sync signal is inverted. Anyhow, something else makes we wonder. The DVO-reactivation code *does* work (the DVO-settings do not block, though the DVO blocks afterwards), and the code is just: I915_WRITE(_DPLL_A, 0xd082); I915_WRITE(_DPLL_B, 0xd082); Thus, while the DPLL_B register is just overwritten by the same value, though DPLL_A changes. The fact that this actually unlocks the DVO means to me that actually bit 30 of the DVOC register *does not* work to re-assign the DVO to pipe B. The way how the system behaves is rather consistent with the hypothesis that the DVO is still assigned to pipe A Is there any other bit or setting that controls which DVO goes to which pipe? It looks like the pipe output control does not work correctly. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] 16bpp and 8bpp uxa output broken...
Hi Daniel, dear intel experts, just another note: I just switched the default depth from 24 to 16 bit by adding a DefaultDepth into the screen section of X11. Strangely enough, that gives much *less* banding than the 24bpp output Anyhow, 16bpp breaks the gdm login, and 8bpp breaks almost everything. Strangely, if I switch from uxa to sna, gdm is fine and the graphics is much smoother (less banding) than with 24bpp output. Greetings, Thomas P.S.: Strangely enough, with the 24bpp output, I can clearly count 64 distinct grey levels corresponding to the 6bpp panel (I assume), with 16bpp output, I get a somewhat more irregular banding (probably because green has one bit more), though the desktop background is very smooth. The same image, when viewed by eog, shows banding. Thus, I suppose, that the desktop renderer applies some kind of dithering while eog does not. Wierd. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/62] [v6] drm/i915/bdw: Add device IDs
v2: Squash in drm/i915/bdw: Add BDW to the HAS_DDI check as
suggested by Damien.
v3: Squash in VEBOX enabling from Zhao Yakui yakui.z...@intel.com
v4: Rebase on top of Jesse's patch to extract all pci ids to
include/drm/i915_pciids.h.
v4: Replace Halo by its marketing moniker Iris. Requested by Ben.
v5: Switch from info-has*ring to info-ring_mask.
v6: Add 0x16X2 variant (which is newer than this patch)
Rename to use new naming scheme (Chris)
Remove Simulator PCI ids. These snuck in during rebase (Chris)
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.c | 22 +-
include/drm/i915_pciids.h | 25 +
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 770c9f8..50891cb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -336,6 +336,24 @@ static const struct intel_device_info intel_haswell_m_info
= {
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
};
+static const struct intel_device_info intel_broadwell_d_info = {
+ .is_preliminary = 1,
+ .gen = 8,
+ .need_gfx_hws = 1, .has_hotplug = 1,
+ .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .has_llc = 1,
+ .has_ddi = 1,
+};
+
+static const struct intel_device_info intel_broadwell_m_info = {
+ .is_preliminary = 1,
+ .gen = 8, .is_mobile = 1,
+ .need_gfx_hws = 1, .has_hotplug = 1,
+ .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .has_llc = 1,
+ .has_ddi = 1,
+};
+
/*
* Make sure any device matches here are from most specific to most
* general. For example, since the Quanta match is based on the subsystem
@@ -367,7 +385,9 @@ static const struct intel_device_info intel_haswell_m_info
= {
INTEL_HSW_D_IDS(intel_haswell_d_info), \
INTEL_HSW_M_IDS(intel_haswell_m_info), \
INTEL_VLV_M_IDS(intel_valleyview_m_info), \
- INTEL_VLV_D_IDS(intel_valleyview_d_info)
+ INTEL_VLV_D_IDS(intel_valleyview_d_info), \
+ INTEL_BDW_M_IDS(intel_broadwell_m_info), \
+ INTEL_BDW_D_IDS(intel_broadwell_d_info)
static const struct pci_device_id pciidlist[] = { /* aka */
INTEL_PCI_IDS,
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 8a10f5c..ba630c8 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -208,4 +208,29 @@
#define INTEL_VLV_D_IDS(info) \
INTEL_VGA_DEVICE(0x0155, info)
+#define _INTEL_BDW_M(gt, id, info) \
+ INTEL_VGA_DEVICEgt) - 1) 4) | (id), info)
+#define _INTEL_BDW_D(gt, id, info) \
+ INTEL_VGA_DEVICEgt) - 1) 4) | (id), info)
+
+#define _INTEL_BDW_M(gt, info) \
+ _INTEL_BDW_M(gt, 0x1602, info), /* ULT */ \
+ _INTEL_BDW_M(gt, 0x1606, info), /* ULT */ \
+ _INTEL_BDW_M(gt, 0x160B, info), /* Iris */ \
+ _INTEL_BDW_M(gt, 0x160E, info) /* ULX */
+
+#define _INTEL_BDW_D(gt, info) \
+ _INTEL_BDW_M(gt, 0x160A, info), /* Server */ \
+ _INTEL_BDW_M(gt, 0x160D, info) /* Workstation */
+
+#define INTEL_BDW_M_IDS(info) \
+ _INTEL_BDW_M(1, info), \
+ _INTEL_BDW_M(2, info), \
+ _INTEL_BDW_M(3, info)
+
+#define INTEL_BDW_D_IDS(info) \
+ _INTEL_BDW_D(1, info), \
+ _INTEL_BDW_D(2, info), \
+ _INTEL_BDW_D(3, info)
+
#endif /* _I915_PCIIDS_H */
--
1.8.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/62] drm/i915/bdw: Add device IDs
On Sun, Nov 03, 2013 at 09:58:00PM +, Chris Wilson wrote:
On Sat, Nov 02, 2013 at 09:07:02PM -0700, Ben Widawsky wrote:
@@ -367,7 +385,9 @@ static const struct intel_device_info
intel_haswell_m_info = {
INTEL_HSW_D_IDS(intel_haswell_d_info), \
INTEL_HSW_M_IDS(intel_haswell_m_info), \
INTEL_VLV_M_IDS(intel_valleyview_m_info), \
- INTEL_VLV_D_IDS(intel_valleyview_d_info)
+ INTEL_VLV_D_IDS(intel_valleyview_d_info), \
+ INTEL_BDW_PCI_IDS_M(intel_broadwell_m_info), \
+ INTEL_BDW_PCI_IDS_D(intel_broadwell_d_info)
Inconsistent naming scheme post Jesse-rebase.
static const struct pci_device_id pciidlist[] = { /* aka */
INTEL_PCI_IDS,
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 8a10f5c..d35bc0b 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -208,4 +208,31 @@
#define INTEL_VLV_D_IDS(info) \
INTEL_VGA_DEVICE(0x0155, info)
+#define _INTEL_BDW_PCI_ID_M(gt, id, info) \
+ INTEL_VGA_DEVICEgt) - 1) 4) | (id), info)
+#define _INTEL_BDW_PCI_ID_D(gt, id, info) \
+ INTEL_VGA_DEVICEgt) - 1) 4) | (id), info)
+
+#define INTEL_BDW_PCI_ID_M(gt, info) \
+ _INTEL_BDW_PCI_ID_M(gt, 0x1606, info), /* ULT */ \
+ _INTEL_BDW_PCI_ID_M(gt, 0x160B, info), /* Iris */ \
+ _INTEL_BDW_PCI_ID_M(gt, 0x160E, info) /* ULX */
+
+#define INTEL_BDW_PCI_ID_D(gt, info) \
+ _INTEL_BDW_PCI_ID_M(gt, 0x160A, info), /* Server */ \
+ _INTEL_BDW_PCI_ID_M(gt, 0x160D, info) /* Workstation */
Tsk tsk - you missed this one.
+
+#define INTEL_BDW_PCI_IDS_M(info) \
+ INTEL_BDW_PCI_ID_M(1, info), \
+ INTEL_BDW_PCI_ID_M(2, info), \
+ INTEL_BDW_PCI_ID_M(3, info), \
+ INTEL_VGA_DEVICE(0x0BD0, info) /* Simulator GT1 */
+
+#define INTEL_BDW_PCI_IDS_D(info) \
+ INTEL_BDW_PCI_ID_D(1, info), \
+ INTEL_BDW_PCI_ID_D(2, info), \
+ INTEL_BDW_PCI_ID_D(3, info), \
+ INTEL_VGA_DEVICE(0x0BD1, info), /* Simulator GT2 */ \
+ INTEL_VGA_DEVICE(0x0BD2, info) /*/Simulator GT3 */
I thought we weren't adding internal simulator ids upstream?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/62] [v7] drm/i915/bdw: Add device IDs
v2: Squash in drm/i915/bdw: Add BDW to the HAS_DDI check as
suggested by Damien.
v3: Squash in VEBOX enabling from Zhao Yakui yakui.z...@intel.com
v4: Rebase on top of Jesse's patch to extract all pci ids to
include/drm/i915_pciids.h.
v4: Replace Halo by its marketing moniker Iris. Requested by Ben.
v5: Switch from info-has*ring to info-ring_mask.
v6: Add 0x16X2 variant (which is newer than this patch)
Rename to use new naming scheme (Chris)
Remove Simulator PCI ids. These snuck in during rebase (Chris)
v7: Fix poor sed job from v6
Make the desktop variants use the desktop macro (Rebase error). Notice
that this makes no functional difference - it's just confusing.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.c | 22 +-
include/drm/i915_pciids.h | 25 +
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 770c9f8..50891cb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -336,6 +336,24 @@ static const struct intel_device_info intel_haswell_m_info
= {
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
};
+static const struct intel_device_info intel_broadwell_d_info = {
+ .is_preliminary = 1,
+ .gen = 8,
+ .need_gfx_hws = 1, .has_hotplug = 1,
+ .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .has_llc = 1,
+ .has_ddi = 1,
+};
+
+static const struct intel_device_info intel_broadwell_m_info = {
+ .is_preliminary = 1,
+ .gen = 8, .is_mobile = 1,
+ .need_gfx_hws = 1, .has_hotplug = 1,
+ .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .has_llc = 1,
+ .has_ddi = 1,
+};
+
/*
* Make sure any device matches here are from most specific to most
* general. For example, since the Quanta match is based on the subsystem
@@ -367,7 +385,9 @@ static const struct intel_device_info intel_haswell_m_info
= {
INTEL_HSW_D_IDS(intel_haswell_d_info), \
INTEL_HSW_M_IDS(intel_haswell_m_info), \
INTEL_VLV_M_IDS(intel_valleyview_m_info), \
- INTEL_VLV_D_IDS(intel_valleyview_d_info)
+ INTEL_VLV_D_IDS(intel_valleyview_d_info), \
+ INTEL_BDW_M_IDS(intel_broadwell_m_info), \
+ INTEL_BDW_D_IDS(intel_broadwell_d_info)
static const struct pci_device_id pciidlist[] = { /* aka */
INTEL_PCI_IDS,
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 8a10f5c..940ece4 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -208,4 +208,29 @@
#define INTEL_VLV_D_IDS(info) \
INTEL_VGA_DEVICE(0x0155, info)
+#define _INTEL_BDW_M(gt, id, info) \
+ INTEL_VGA_DEVICEgt) - 1) 4) | (id), info)
+#define _INTEL_BDW_D(gt, id, info) \
+ INTEL_VGA_DEVICEgt) - 1) 4) | (id), info)
+
+#define _INTEL_BDW_M_IDS(gt, info) \
+ _INTEL_BDW_M(gt, 0x1602, info), /* ULT */ \
+ _INTEL_BDW_M(gt, 0x1606, info), /* ULT */ \
+ _INTEL_BDW_M(gt, 0x160B, info), /* Iris */ \
+ _INTEL_BDW_M(gt, 0x160E, info) /* ULX */
+
+#define _INTEL_BDW_D_IDS(gt, info) \
+ _INTEL_BDW_D(gt, 0x160A, info), /* Server */ \
+ _INTEL_BDW_D(gt, 0x160D, info) /* Workstation */
+
+#define INTEL_BDW_M_IDS(info) \
+ _INTEL_BDW_M_IDS(1, info), \
+ _INTEL_BDW_M_IDS(2, info), \
+ _INTEL_BDW_M_IDS(3, info)
+
+#define INTEL_BDW_D_IDS(info) \
+ _INTEL_BDW_D_IDS(1, info), \
+ _INTEL_BDW_D_IDS(2, info), \
+ _INTEL_BDW_D_IDS(3, info)
+
#endif /* _I915_PCIIDS_H */
--
1.8.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/62] [v5] drm/i915/bdw: support GMS and GGMS changes
All the BARs have the ability to grow.
v2: Pulled out the simulator workaround to a separate patch.
Rebased.
v3: Rebase onto latest vlv patches from Jesse.
v4: Rebased on top of the early stolen quirk patch from Jesse.
v5: Use the new macro names.
s/INTEL_BDW_PCI_IDS_D/INTEL_BDW_D_IDS
s/INTEL_BDW_PCI_IDS_M/INTEL_BDW_M_IDS
It's Jesse's fault for not following the convention I originally set.
Cc: Ingo Molnar mi...@kernel.org
Cc: H. Peter Anvin h...@zytor.com
Cc: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
arch/x86/kernel/early-quirks.c | 12
drivers/gpu/drm/i915/i915_gem_gtt.c | 29 ++---
include/drm/i915_drm.h | 4
3 files changed, 42 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index b3cd3eb..96f958d 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -313,6 +313,16 @@ static size_t __init gen6_stolen_size(int num, int slot,
int func)
return gmch_ctrl 25; /* 32 MB units */
}
+static inline size_t gen8_stolen_size(int num, int slot, int func)
+{
+ u16 gmch_ctrl;
+
+ gmch_ctrl = read_pci_config_16(num, slot, func, SNB_GMCH_CTRL);
+ gmch_ctrl = BDW_GMCH_GMS_SHIFT;
+ gmch_ctrl = BDW_GMCH_GMS_MASK;
+ return gmch_ctrl 25; /* 32 MB units */
+}
+
typedef size_t (*stolen_size_fn)(int num, int slot, int func);
static struct pci_device_id intel_stolen_ids[] __initdata = {
@@ -336,6 +346,8 @@ static struct pci_device_id intel_stolen_ids[] __initdata =
{
INTEL_IVB_D_IDS(gen6_stolen_size),
INTEL_HSW_D_IDS(gen6_stolen_size),
INTEL_HSW_M_IDS(gen6_stolen_size),
+ INTEL_BDW_M_IDS(gen8_stolen_size),
+ INTEL_BDW_D_IDS(gen8_stolen_size)
};
static void __init intel_graphics_stolen(int num, int slot, int func)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 77b3c74..19016b7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -869,6 +869,15 @@ static inline unsigned int gen6_get_total_gtt_size(u16
snb_gmch_ctl)
return snb_gmch_ctl 20;
}
+static inline unsigned int gen8_get_total_gtt_size(u16 bdw_gmch_ctl)
+{
+ bdw_gmch_ctl = BDW_GMCH_GGMS_SHIFT;
+ bdw_gmch_ctl = BDW_GMCH_GGMS_MASK;
+ if (bdw_gmch_ctl)
+ bdw_gmch_ctl = 1 bdw_gmch_ctl;
+ return bdw_gmch_ctl 20;
+}
+
static inline size_t gen6_get_stolen_size(u16 snb_gmch_ctl)
{
snb_gmch_ctl = SNB_GMCH_GMS_SHIFT;
@@ -876,6 +885,13 @@ static inline size_t gen6_get_stolen_size(u16 snb_gmch_ctl)
return snb_gmch_ctl 25; /* 32 MB units */
}
+static inline size_t gen8_get_stolen_size(u16 bdw_gmch_ctl)
+{
+ bdw_gmch_ctl = BDW_GMCH_GMS_SHIFT;
+ bdw_gmch_ctl = BDW_GMCH_GMS_MASK;
+ return bdw_gmch_ctl 25; /* 32 MB units */
+}
+
static int gen6_gmch_probe(struct drm_device *dev,
size_t *gtt_total,
size_t *stolen,
@@ -903,10 +919,16 @@ static int gen6_gmch_probe(struct drm_device *dev,
if (!pci_set_dma_mask(dev-pdev, DMA_BIT_MASK(40)))
pci_set_consistent_dma_mask(dev-pdev, DMA_BIT_MASK(40));
pci_read_config_word(dev-pdev, SNB_GMCH_CTRL, snb_gmch_ctl);
- gtt_size = gen6_get_total_gtt_size(snb_gmch_ctl);
- *stolen = gen6_get_stolen_size(snb_gmch_ctl);
- *gtt_total = (gtt_size / sizeof(gen6_gtt_pte_t)) PAGE_SHIFT;
+ if (IS_GEN8(dev)) {
+ gtt_size = gen8_get_total_gtt_size(snb_gmch_ctl);
+ *gtt_total = (gtt_size / 8) PAGE_SHIFT;
+ *stolen = gen8_get_stolen_size(snb_gmch_ctl);
+ } else {
+ gtt_size = gen6_get_total_gtt_size(snb_gmch_ctl);
+ *gtt_total = (gtt_size / sizeof(gen6_gtt_pte_t)) PAGE_SHIFT;
+ *stolen = gen6_get_stolen_size(snb_gmch_ctl);
+ }
/* For Modern GENs the PTEs and register space are split in the BAR */
gtt_bus_addr = pci_resource_start(dev-pdev, 0) +
@@ -916,6 +938,7 @@ static int gen6_gmch_probe(struct drm_device *dev,
if (!dev_priv-gtt.gsm) {
DRM_ERROR(Failed to map the gtt page table\n);
return -ENOMEM;
+
}
ret = setup_scratch_page(dev);
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 3abfa6e..97d5497 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -49,6 +49,10 @@ extern bool i915_gpu_turbo_disable(void);
#defineSNB_GMCH_GGMS_MASK 0x3
#defineSNB_GMCH_GMS_SHIFT 3 /* Graphics Mode Select */
#defineSNB_GMCH_GMS_MASK0x1f
+#defineBDW_GMCH_GGMS_SHIFT 6
+#defineBDW_GMCH_GGMS_MASK 0x3
+#defineBDW_GMCH_GMS_SHIFT 8
+#defineBDW_GMCH_GMS_MASK0xff
#define I830_GMCH_CTRL 0x52
--
1.8.4.2
[Intel-gfx] [PATCH] drm/i915: flush cursors harder
Apparently they need the same treatment as primary planes. This fixes modesetting failures because of stuck cursors (!) on Thomas' i830M machine. I've figured while at it I'll also roll it out for the ivb 3 pipe version of this function. I didn't do this for i845/i865 since Bspec says the update mechanism works differently, and there's some additional rules about what can be updated in which order. Tested-by: Thomas Richter t...@math.tu-berlin.de Cc: sta...@vger.kernel.org Cc: Thomas Richter t...@math.tu-berlin.de Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/intel_display.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f34252d134b6..04d2699f51b4 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7123,7 +7123,9 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32 base) intel_crtc-cursor_visible = visible; } /* and commit changes on next vblank */ + POSTING_READ(CURCNTR(pipe)); I915_WRITE(CURBASE(pipe), base); + POSTING_READ(CURBASE(pipe)); } static void ivb_update_cursor(struct drm_crtc *crtc, u32 base) @@ -7152,7 +7154,9 @@ static void ivb_update_cursor(struct drm_crtc *crtc, u32 base) intel_crtc-cursor_visible = visible; } /* and commit changes on next vblank */ + POSTING_READ(CURCNTR_IVB(pipe)); I915_WRITE(CURBASE_IVB(pipe), base); + POSTING_READ(CURBASE_IVB(pipe)); } /* If no-part of the cursor is visible on the framebuffer, then the GPU may hang... */ -- 1.8.4.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] More questions and patches for 835GM/ns2501 DVO
On Mon, Nov 4, 2013 at 12:09 AM, Thomas Richter t...@math.tu-berlin.de wrote: On 03.11.2013 22:18, Daniel Vetter wrote: Hm, that would mean that the cursor is somehow stuck in the enabled state, despite that we've tried to disabled it very hard. Can you please try out the below patch? If this doesn't work please take not of the different WARNINGs you're hitting and whether it's always the same one with the same calltrace or something different. I think for now we should try to get the single monitor case working - I have a few theories for the dual-screen issues, but there's not much point working on them if the simple case doesn't work yet. Also I think I'll merge the two patches if they don't make things worse for you, imo it's the right approach and at least conceptually should be able to avoid all these retry loops. Thanks for the patches. Tried quite a bit, and haven't seen the warning yet. Looks like the one-monitor case works quite fine now, except that the boot console is vertically off, which is just annoying though not problematic. Awesome. I'll try to merge these patches with cc: stable. I also tried a lot with the two-monitor case and again went deeply into the DPLL setup logic. The differences I observed before are simply due to the initial resolution (800x600), in the final resolution, the DPLL settings are actually correct. What I get there is: I suspect that due to the pipe A quirk logic we actually get the setup sequence for the DPLLs completely wrong. This will require a bit more magic to make it work correctly ... But I have some ideas. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 16bpp and 8bpp uxa output broken...
On Mon, Nov 4, 2013 at 12:56 AM, Thomas Richter t...@math.tu-berlin.de wrote: just another note: I just switched the default depth from 24 to 16 bit by adding a DefaultDepth into the screen section of X11. Strangely enough, that gives much *less* banding than the 24bpp output That just means we dither down in sw/hw to 16 bit, instead of rendering at 24 and then doing no dithering at all. Anyhow, 16bpp breaks the gdm login, and 8bpp breaks almost everything. Strangely, if I switch from uxa to sna, gdm is fine and the graphics is much smoother (less banding) than with 24bpp output. Iirc SNA enables all the neat hw dithering options. It also works correctly at 16 bit, although you'll run into trouble with qt/kde stuff and with opengl apps. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
