[Intel-gfx] [PATCH 2/3] drm/i915: Generalize drain latency computation
Modify drain latency computation to use it for any plane. Same function can be
used for primary, cursor and sprite planes.
Signed-off-by: Gajanan Bhat gajanan.b...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 82 ++-
2 files changed, 47 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d2a220b..a1260a2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3877,6 +3877,7 @@ enum punit_power_well {
#define DDL_PLANE_PRECISION_64 (17)
#define DDL_PLANE_PRECISION_32 (07)
#define DDL_PLANE_SHIFT0
+#define DRAIN_LATENCY_MAX 0x7f
/* FIFO watermark sizes etc */
#define G4X_FIFO_LINE_SIZE 64
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 90df1e8..f3a3e90 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1268,33 +1268,21 @@ static bool g4x_compute_srwm(struct drm_device *dev,
display, cursor);
}
-static bool vlv_compute_drain_latency(struct drm_device *dev,
-int plane,
-int *plane_prec_mult,
-int *plane_dl,
-int *cursor_prec_mult,
-int *cursor_dl)
+static bool vlv_compute_drain_latency(struct drm_crtc *crtc,
+ int pixel_size,
+ int *prec_mult,
+ int *drain_latency)
{
- struct drm_crtc *crtc;
- int clock, pixel_size;
int entries;
+ int clock = to_intel_crtc(crtc)-config.adjusted_mode.crtc_clock;
- crtc = intel_get_crtc_for_plane(dev, plane);
- if (!intel_crtc_active(crtc))
+ if (clock == 0 || pixel_size == 0)
return false;
- clock = to_intel_crtc(crtc)-config.adjusted_mode.crtc_clock;
- pixel_size = crtc-primary-fb-bits_per_pixel / 8; /* BPP */
-
- entries = (clock / 1000) * pixel_size;
- *plane_prec_mult = (entries 128) ?
- DRAIN_LATENCY_PRECISION_64 : DRAIN_LATENCY_PRECISION_32;
- *plane_dl = (64 * (*plane_prec_mult) * 4) / entries;
-
- entries = (clock / 1000) * 4; /* BPP is always 4 for cursor */
- *cursor_prec_mult = (entries 128) ?
- DRAIN_LATENCY_PRECISION_64 : DRAIN_LATENCY_PRECISION_32;
- *cursor_dl = (64 * (*cursor_prec_mult) * 4) / entries;
+ entries = DIV_ROUND_UP(clock, 1000) * pixel_size;
+ *prec_mult = (entries 128) ? DRAIN_LATENCY_PRECISION_64 :
+ DRAIN_LATENCY_PRECISION_32;
+ *drain_latency = (64 * (*prec_mult) * 4) / entries;
return true;
}
@@ -1309,24 +1297,46 @@ static bool vlv_compute_drain_latency(struct drm_device
*dev,
static void vlv_update_drain_latency(struct drm_crtc *crtc)
{
- struct drm_device *dev = crtc-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_i915_private *dev_priv = crtc-dev-dev_private;
+ int pixel_size;
+ int drain_latency;
enum pipe pipe = to_intel_crtc(crtc)-pipe;
- int plane_prec, plane_dl;
- int cursor_prec, cursor_dl;
- int plane_prec_mult, cursor_prec_mult;
+ int plane_prec, prec_mult, plane_dl;
- if (vlv_compute_drain_latency(dev, pipe, plane_prec_mult, plane_dl,
- cursor_prec_mult, cursor_dl)) {
- cursor_prec = (cursor_prec_mult == DRAIN_LATENCY_PRECISION_64) ?
- DDL_CURSOR_PRECISION_64 : DDL_CURSOR_PRECISION_32;
- plane_prec = (plane_prec_mult == DRAIN_LATENCY_PRECISION_64) ?
- DDL_PLANE_PRECISION_64 : DDL_PLANE_PRECISION_32;
+ plane_dl = I915_READ(VLV_DDL(pipe)) ~DDL_PLANE_PRECISION_64
+ ~DRAIN_LATENCY_MAX ~DDL_CURSOR_PRECISION_64
+ ~(DRAIN_LATENCY_MAX DDL_CURSOR_SHIFT);
- I915_WRITE(VLV_DDL(pipe), cursor_prec |
- (cursor_dl DDL_CURSOR_SHIFT) |
- plane_prec | (plane_dl DDL_PLANE_SHIFT));
+ if (!intel_crtc_active(crtc)) {
+ I915_WRITE(VLV_DDL(pipe), plane_dl);
+ return;
}
+
+ /* Primary plane Drain Latency */
+ pixel_size = crtc-primary-fb-bits_per_pixel / 8; /* BPP */
+ if (vlv_compute_drain_latency(crtc, pixel_size, prec_mult,
drain_latency)) {
+ plane_prec = (prec_mult == DRAIN_LATENCY_PRECISION_64) ?
+ DDL_PLANE_PRECISION_64 :
+ DDL_PLANE_PRECISION_32;
+ plane_dl = plane_dl | plane_prec | drain_latency;
+ }
+
+ /*
[Intel-gfx] [PATCH 3/3] drm/i915: Add sprite watermark programming for VLV and CHV
Program DDL register as part sprite watermark programming for CHV and VLV.
Signed-off-by: Gajanan Bhat gajanan.b...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 44 +++
1 file changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f3a3e90..0f439f7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1405,6 +1405,48 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
intel_set_memory_cxsr(dev_priv, true);
}
+static void valleyview_update_sprite_wm(struct drm_plane *plane,
+ struct drm_crtc *crtc,
+ uint32_t sprite_width,
+ uint32_t sprite_height,
+ int pixel_size,
+ bool enabled, bool scaled)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int pipe = to_intel_plane(plane)-pipe;
+ int drain_latency;
+ int plane_prec;
+ int sprite_dl;
+ int prec_mult;
+
+ if (to_intel_plane(plane)-plane == 0)
+ sprite_dl = I915_READ(VLV_DDL(pipe))
~DDL_SPRITE0_PRECISION_64
+ ~(DRAIN_LATENCY_MAX DDL_SPRITE0_SHIFT);
+ else
+ sprite_dl = I915_READ(VLV_DDL(pipe))
~DDL_SPRITE1_PRECISION_64
+ ~(DRAIN_LATENCY_MAX DDL_SPRITE1_SHIFT);
+
+ if (enabled vlv_compute_drain_latency(crtc, pixel_size, prec_mult,
+drain_latency)) {
+ if (to_intel_plane(plane)-plane == 0) {
+ plane_prec = (prec_mult == DRAIN_LATENCY_PRECISION_64) ?
+ DDL_SPRITE0_PRECISION_64 :
+ DDL_SPRITE0_PRECISION_32;
+ sprite_dl = sprite_dl | plane_prec |
+ drain_latency DDL_SPRITE0_SHIFT;
+ } else {
+ plane_prec = (prec_mult == DRAIN_LATENCY_PRECISION_64) ?
+ DDL_SPRITE1_PRECISION_64 :
+ DDL_SPRITE1_PRECISION_32;
+ sprite_dl = sprite_dl | plane_prec |
+ drain_latency DDL_SPRITE1_SHIFT;
+ }
+ }
+
+ I915_WRITE(VLV_DDL(pipe), sprite_dl);
+}
+
static void g4x_update_wm(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc-dev;
@@ -6851,10 +6893,12 @@ void intel_init_pm(struct drm_device *dev)
dev_priv-display.init_clock_gating =
gen8_init_clock_gating;
} else if (IS_CHERRYVIEW(dev)) {
dev_priv-display.update_wm = valleyview_update_wm;
+ dev_priv-display.update_sprite_wm =
valleyview_update_sprite_wm;
dev_priv-display.init_clock_gating =
cherryview_init_clock_gating;
} else if (IS_VALLEYVIEW(dev)) {
dev_priv-display.update_wm = valleyview_update_wm;
+ dev_priv-display.update_sprite_wm =
valleyview_update_sprite_wm;
dev_priv-display.init_clock_gating =
valleyview_init_clock_gating;
} else if (IS_PINEVIEW(dev)) {
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Update DDL only for current CRTC
Instead of looping through all CRTCs, update DDL for current CRTC for which
watermark is being updated.
CHV is confirmed to have precision of 32/64 which is same as VLV.
Signed-off-by: Gajanan Bhat gajanan.b...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b881639..90df1e8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1307,24 +1307,17 @@ static bool vlv_compute_drain_latency(struct drm_device
*dev,
* latency value.
*/
-static void vlv_update_drain_latency(struct drm_device *dev)
+static void vlv_update_drain_latency(struct drm_crtc *crtc)
{
+ struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- enum pipe pipe;
-
- for_each_pipe(pipe) {
- int plane_prec, plane_dl;
- int cursor_prec, cursor_dl;
- int plane_prec_mult, cursor_prec_mult;
+ enum pipe pipe = to_intel_crtc(crtc)-pipe;
+ int plane_prec, plane_dl;
+ int cursor_prec, cursor_dl;
+ int plane_prec_mult, cursor_prec_mult;
- if (!vlv_compute_drain_latency(dev, pipe, plane_prec_mult,
plane_dl,
- cursor_prec_mult, cursor_dl))
- continue;
-
- /*
-* FIXME CHV spec still lists 16 and 32 as the precision
-* values. Need to figure out if spec is outdated or what.
-*/
+ if (vlv_compute_drain_latency(dev, pipe, plane_prec_mult, plane_dl,
+ cursor_prec_mult, cursor_dl)) {
cursor_prec = (cursor_prec_mult == DRAIN_LATENCY_PRECISION_64) ?
DDL_CURSOR_PRECISION_64 : DDL_CURSOR_PRECISION_32;
plane_prec = (plane_prec_mult == DRAIN_LATENCY_PRECISION_64) ?
@@ -1349,7 +1342,7 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
unsigned int enabled = 0;
bool cxsr_enabled;
- vlv_update_drain_latency(dev);
+ vlv_update_drain_latency(crtc);
if (g4x_compute_wm0(dev, PIPE_A,
valleyview_wm_info, latency_ns,
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] Update DDL code to support sprite watermarks
Hi, These patches depend on few patches from Ville and have been rebased on top of them. Those pathes also need review and merge. Following are Ville's patches: http://lists.freedesktop.org/archives/intel-gfx/2014-June/048150.html http://lists.freedesktop.org/archives/intel-gfx/2014-June/048152.html http://lists.freedesktop.org/archives/intel-gfx/2014-June/048153.html Gajanan Bhat (3): drm/i915: Update DDL only for current CRTC drm/i915: Generalize drain latency computation drm/i915: Add sprite watermark programming for VLV and CHV drivers/gpu/drm/i915/i915_reg.h |1 + drivers/gpu/drm/i915/intel_pm.c | 135 ++- 2 files changed, 92 insertions(+), 44 deletions(-) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Use genX_ prefix for gt irq enable/disable functions
Traditionally we use genX_ for GT/render stuff and the codenames for
display stuff. But the gt and pm interrupt handling functions on
gen5/6+ stuck out as exceptions, so convert them.
Looking at the diff this nicely realigns our ducks since almost all
the callers are already platform-specific functions following the
genX_ pattern.
Spotted while reviewing some internal rps patches.
No function change in this patch.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 24
drivers/gpu/drm/i915/intel_drv.h| 12 ++--
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 12 ++--
4 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7d61ca2a01df..dfe923a3cb92 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -182,12 +182,12 @@ static void ilk_update_gt_irq(struct drm_i915_private
*dev_priv,
POSTING_READ(GTIMR);
}
-void ilk_enable_gt_irq(struct drm_i915_private *dev_priv, uint32_t mask)
+void gen5_enable_gt_irq(struct drm_i915_private *dev_priv, uint32_t mask)
{
ilk_update_gt_irq(dev_priv, mask, mask);
}
-void ilk_disable_gt_irq(struct drm_i915_private *dev_priv, uint32_t mask)
+void gen5_disable_gt_irq(struct drm_i915_private *dev_priv, uint32_t mask)
{
ilk_update_gt_irq(dev_priv, mask, 0);
}
@@ -220,12 +220,12 @@ static void snb_update_pm_irq(struct drm_i915_private
*dev_priv,
}
}
-void snb_enable_pm_irq(struct drm_i915_private *dev_priv, uint32_t mask)
+void gen6_enable_pm_irq(struct drm_i915_private *dev_priv, uint32_t mask)
{
snb_update_pm_irq(dev_priv, mask, mask);
}
-void snb_disable_pm_irq(struct drm_i915_private *dev_priv, uint32_t mask)
+void gen6_disable_pm_irq(struct drm_i915_private *dev_priv, uint32_t mask)
{
snb_update_pm_irq(dev_priv, mask, 0);
}
@@ -278,12 +278,12 @@ static void bdw_update_pm_irq(struct drm_i915_private
*dev_priv,
}
}
-void bdw_enable_pm_irq(struct drm_i915_private *dev_priv, uint32_t mask)
+void gen8_enable_pm_irq(struct drm_i915_private *dev_priv, uint32_t mask)
{
bdw_update_pm_irq(dev_priv, mask, mask);
}
-void bdw_disable_pm_irq(struct drm_i915_private *dev_priv, uint32_t mask)
+void gen8_disable_pm_irq(struct drm_i915_private *dev_priv, uint32_t mask)
{
bdw_update_pm_irq(dev_priv, mask, 0);
}
@@ -1408,10 +1408,10 @@ static void gen6_pm_rps_work(struct work_struct *work)
pm_iir = dev_priv-rps.pm_iir;
dev_priv-rps.pm_iir = 0;
if (INTEL_INFO(dev_priv-dev)-gen = 8)
- bdw_enable_pm_irq(dev_priv, dev_priv-pm_rps_events);
+ gen8_enable_pm_irq(dev_priv, dev_priv-pm_rps_events);
else {
/* Make sure not to corrupt PMIMR state used by ringbuffer */
- snb_enable_pm_irq(dev_priv, dev_priv-pm_rps_events);
+ gen6_enable_pm_irq(dev_priv, dev_priv-pm_rps_events);
}
spin_unlock_irq(dev_priv-irq_lock);
@@ -1553,7 +1553,7 @@ static void ivybridge_parity_work(struct work_struct
*work)
out:
WARN_ON(dev_priv-l3_parity.which_slice);
spin_lock_irqsave(dev_priv-irq_lock, flags);
- ilk_enable_gt_irq(dev_priv, GT_PARITY_ERROR(dev_priv-dev));
+ gen5_enable_gt_irq(dev_priv, GT_PARITY_ERROR(dev_priv-dev));
spin_unlock_irqrestore(dev_priv-irq_lock, flags);
mutex_unlock(dev_priv-dev-struct_mutex);
@@ -1567,7 +1567,7 @@ static void ivybridge_parity_error_irq_handler(struct
drm_device *dev, u32 iir)
return;
spin_lock(dev_priv-irq_lock);
- ilk_disable_gt_irq(dev_priv, GT_PARITY_ERROR(dev));
+ gen5_disable_gt_irq(dev_priv, GT_PARITY_ERROR(dev));
spin_unlock(dev_priv-irq_lock);
iir = GT_PARITY_ERROR(dev);
@@ -1622,7 +1622,7 @@ static void gen8_rps_irq_handler(struct drm_i915_private
*dev_priv, u32 pm_iir)
spin_lock(dev_priv-irq_lock);
dev_priv-rps.pm_iir |= pm_iir dev_priv-pm_rps_events;
- bdw_disable_pm_irq(dev_priv, pm_iir dev_priv-pm_rps_events);
+ gen8_disable_pm_irq(dev_priv, pm_iir dev_priv-pm_rps_events);
spin_unlock(dev_priv-irq_lock);
queue_work(dev_priv-wq, dev_priv-rps.work);
@@ -1969,7 +1969,7 @@ static void gen6_rps_irq_handler(struct drm_i915_private
*dev_priv, u32 pm_iir)
if (pm_iir dev_priv-pm_rps_events) {
spin_lock(dev_priv-irq_lock);
dev_priv-rps.pm_iir |= pm_iir dev_priv-pm_rps_events;
- snb_disable_pm_irq(dev_priv, pm_iir dev_priv-pm_rps_events);
+ gen6_disable_pm_irq(dev_priv, pm_iir dev_priv-pm_rps_events);
spin_unlock(dev_priv-irq_lock);
queue_work(dev_priv-wq, dev_priv-rps.work);
diff --git a/drivers/gpu/drm/i915/intel_drv.h
Re: [Intel-gfx] [PATCH 11/11] drm/i915/bdw: Map unused PDPs to a scratch page
On Mon, 14 Jul 2014 05:18:44 -0700
Rodrigo Vivi rodrigo.v...@intel.com wrote:
From: Bob Beckett robert.beck...@intel.com
Create a scratch page for the two unused PDPs and set all the PTEs
for them to point to it.
This patch addresses a page fault, and subsequent hang in pipe
control flush. In these cases, the Main Graphic Arbiter Error
register [0x40A0] showed a TLB Page Fault error, and a high memory
address (higher than the size of our PPGTT) was reported in the
Fault TLB RD Data0 register (0x4B10).
PDP2 PDP3 were not set because, in theory, they aren't required
for our PPGTT size, but they should be mapped to a scratch page
anyway.
v2: Rebase on latest nightly.
Signed-off-by: Michel Thierry michel.thie...@intel.com (v1)
Signed-off-by: Dave Gordon david.s.gor...@intel.com (v2)
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
Just as an FYI, this patch is definitely needed (I confirmed with
design), and the same fix was in my 64b PPGTT series.
One thing which appears different with my fix, though I didn't check
closely, is I allocate an extra page per PDP. I can't remember exactly
why I did it, but I may have put it in the commit message.
I'd like to see this fix get merged (and I'd prefer we just merge 64b
series, but since that's unlikely...). CC'ing James who should pick
this up.
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 79
+
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 + 2 files changed, 65
insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c index 743512e..7743e4f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -364,6 +364,11 @@ static void gen8_ppgtt_free(const struct
i915_hw_ppgtt *ppgtt) kfree(ppgtt-gen8_pt_dma_addr[i]);
}
+ /* Unused PDPs are always assigned to scratch page */
+ for (i = ppgtt-num_pd_pages; i GEN8_LEGACY_PDPS; i++)
+ kfree(ppgtt-gen8_pt_dma_addr[i]);
+ __free_page(ppgtt-scratch_page);
+
__free_pages(ppgtt-pd_pages, get_order(ppgtt-num_pd_pages
PAGE_SHIFT)); }
@@ -388,6 +393,13 @@ static void gen8_ppgtt_unmap_pages(struct
i915_hw_ppgtt *ppgtt) PCI_DMA_BIDIRECTIONAL);
}
}
+
+ /* Unused PDPs are always assigned to scratch page */
+ for (i = ppgtt-num_pd_pages; i GEN8_LEGACY_PDPS; i++) {
+ if (ppgtt-pd_dma_addr[i])
+ pci_unmap_page(hwdev, ppgtt-pd_dma_addr[i],
+ PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
+ }
}
static void gen8_ppgtt_cleanup(struct i915_address_space *vm)
@@ -474,10 +486,21 @@ static int gen8_ppgtt_allocate_dma(struct
i915_hw_ppgtt *ppgtt) static int
gen8_ppgtt_allocate_page_directories(struct i915_hw_ppgtt *ppgtt,
const int max_pdp) {
- ppgtt-pd_pages = alloc_pages(GFP_KERNEL, get_order(max_pdp
PAGE_SHIFT));
- if (!ppgtt-pd_pages)
+ /* Scratch page for unmapped PDP's */
+ ppgtt-scratch_page = alloc_page(GFP_KERNEL);
+ if (!ppgtt-scratch_page)
return -ENOMEM;
+ /* Must allocate space for all 4 PDPs. HW has implemented
cache which
+ * pre-fetches entries; that pre-fetch can attempt access
for entries
+ * even if no resources are located in that range.
+ */
+ ppgtt-pd_pages = alloc_pages(GFP_KERNEL, GEN8_LEGACY_PDPS);
+ if (!ppgtt-pd_pages) {
+ __free_page(ppgtt-scratch_page);
+ return -ENOMEM;
+ }
+
ppgtt-num_pd_pages = 1 get_order(max_pdp PAGE_SHIFT);
BUG_ON(ppgtt-num_pd_pages GEN8_LEGACY_PDPS);
@@ -495,6 +518,7 @@ static int gen8_ppgtt_alloc(struct i915_hw_ppgtt
*ppgtt,
ret = gen8_ppgtt_allocate_page_tables(ppgtt, max_pdp);
if (ret) {
+ __free_page(ppgtt-scratch_page);
__free_pages(ppgtt-pd_pages, get_order(max_pdp
PAGE_SHIFT)); return ret;
}
@@ -529,18 +553,25 @@ static int
gen8_ppgtt_setup_page_directories(struct i915_hw_ppgtt *ppgtt,
static int gen8_ppgtt_setup_page_tables(struct i915_hw_ppgtt *ppgtt,
const int pd,
- const int pt)
+ const int pt,
+ const int max_pdp)
{
dma_addr_t pt_addr;
struct page *p;
int ret;
- p = ppgtt-gen8_pt_pages[pd][pt];
- pt_addr = pci_map_page(ppgtt-base.dev-pdev,
-p, 0, PAGE_SIZE,
PCI_DMA_BIDIRECTIONAL);
- ret = pci_dma_mapping_error(ppgtt-base.dev-pdev, pt_addr);
- if (ret)
- return ret;
+ /* Unused PDPs need to have their ptes pointing to the
+ * existing scratch page.
+ */
+ if (pd max_pdp) {
+ p = ppgtt-gen8_pt_pages[pd][pt];
+ pt_addr =
[Intel-gfx] [PATCH] drm/i915: Fix printing proper min/min/rpe values in debugfs
From: Deepak S deepa...@intel.com This was fumbled while trying to use the cached min/min/rpe values in the vlv debugfs code. This is a regression from commit 03af20458a57a50735b12c1e3c23abc7ff70c6fa Author: Ville Syrjälä ville.syrj...@linux.intel.com Date: Sat Jun 28 02:03:53 2014 +0300 drm/i915: Use the cached min/min/rpe values in the vlv debugfs code Change-Id: I0c6da333ae14d36a93582b281603fa24f1b95dcf Signed-off-by: Deepak S deepa...@intel.com --- drivers/gpu/drm/i915/i915_debugfs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index fc39610..5bc65af 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -1116,13 +1116,13 @@ static int i915_frequency_info(struct seq_file *m, void *unused) seq_printf(m, DDR freq: %d MHz\n, dev_priv-mem_freq); seq_printf(m, max GPU freq: %d MHz\n, - dev_priv-rps.max_freq); + vlv_gpu_freq(dev_priv, dev_priv-rps.max_freq)); seq_printf(m, min GPU freq: %d MHz\n, - dev_priv-rps.min_freq); + vlv_gpu_freq(dev_priv, dev_priv-rps.min_freq)); seq_printf(m, efficient (RPe) frequency: %d MHz\n, - dev_priv-rps.efficient_freq); + vlv_gpu_freq(dev_priv, dev_priv-rps.efficient_freq)); seq_printf(m, current GPU freq: %d MHz\n, vlv_gpu_freq(dev_priv, (freq_sts 8) 0xff)); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix printing proper min/min/rpe values in debugfs
From: Deepak S deepa...@linux.intel.com This was fumbled while trying to use the cached min/min/rpe values in the vlv debugfs code. This is a regression from commit 03af20458a57a50735b12c1e3c23abc7ff70c6fa Author: Ville Syrjälä ville.syrj...@linux.intel.com Date: Sat Jun 28 02:03:53 2014 +0300 drm/i915: Use the cached min/min/rpe values in the vlv debugfs code Signed-off-by: Deepak S deepa...@linux.intel.com --- drivers/gpu/drm/i915/i915_debugfs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index fc39610..5bc65af 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -1116,13 +1116,13 @@ static int i915_frequency_info(struct seq_file *m, void *unused) seq_printf(m, DDR freq: %d MHz\n, dev_priv-mem_freq); seq_printf(m, max GPU freq: %d MHz\n, - dev_priv-rps.max_freq); + vlv_gpu_freq(dev_priv, dev_priv-rps.max_freq)); seq_printf(m, min GPU freq: %d MHz\n, - dev_priv-rps.min_freq); + vlv_gpu_freq(dev_priv, dev_priv-rps.min_freq)); seq_printf(m, efficient (RPe) frequency: %d MHz\n, - dev_priv-rps.efficient_freq); + vlv_gpu_freq(dev_priv, dev_priv-rps.efficient_freq)); seq_printf(m, current GPU freq: %d MHz\n, vlv_gpu_freq(dev_priv, (freq_sts 8) 0xff)); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: BDW can also detect unclaimed registers
On Tue, Jul 15, 2014 at 12:20:01PM -0700, Rodrigo Vivi wrote:
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
On Fri, Jul 4, 2014 at 7:50 AM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
By the time I wrote this patch, it allowed me to catch some problems.
But due to patch reordering - in order to prevent fake regression
reports - this patch may be merged after the fixes of the problems
identified by this patch.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Merged all patches except patch 4 (the one that adds the module option).
Thanks.
-Daniel
---
drivers/gpu/drm/i915/i915_drv.c | 4
drivers/gpu/drm/i915/intel_uncore.c | 3 +++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 8a0cb0c..bdb223c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -303,6 +303,7 @@ static const struct intel_device_info
intel_broadwell_d_info = {
.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,
@@ -314,6 +315,7 @@ static const struct intel_device_info
intel_broadwell_m_info = {
.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,
@@ -325,6 +327,7 @@ static const struct intel_device_info
intel_broadwell_gt3d_info = {
.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,
@@ -336,6 +339,7 @@ static const struct intel_device_info
intel_broadwell_gt3m_info = {
.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,
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index de5402f..1fcf78b 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -788,6 +788,7 @@ static bool is_gen8_shadowed(struct drm_i915_private
*dev_priv, u32 reg)
static void \
gen8_write##x(struct drm_i915_private *dev_priv, off_t reg, u##x val,
bool trace) { \
REG_WRITE_HEADER; \
+ hsw_unclaimed_reg_debug(dev_priv, reg, false, true); \
if (reg 0x4 !is_gen8_shadowed(dev_priv, reg)) { \
if (dev_priv-uncore.forcewake_count == 0) \
dev_priv-uncore.funcs.force_wake_get(dev_priv, \
@@ -799,6 +800,8 @@ gen8_write##x(struct drm_i915_private *dev_priv, off_t
reg, u##x val, bool trace
} else { \
__raw_i915_write##x(dev_priv, reg, val); \
} \
+ hsw_unclaimed_reg_debug(dev_priv, reg, false, false); \
+ hsw_unclaimed_reg_detect(dev_priv); \
REG_WRITE_FOOTER; \
}
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [IGT 2/2] intel_bios_reader: Add support to dump MIPI Sequence block #53
Signed-off-by: Gaurav K Singh gaurav.k.si...@intel.com
---
tools/intel_bios.h| 26 +
tools/intel_bios_reader.c | 272 +
2 files changed, 298 insertions(+)
diff --git a/tools/intel_bios.h b/tools/intel_bios.h
index 752379a..aedc5fc 100644
--- a/tools/intel_bios.h
+++ b/tools/intel_bios.h
@@ -30,6 +30,7 @@
#include stdint.h
+
struct vbt_header {
char signature[20]; /** Always starts with 'VBT$' */
uint16_t version; /** decimal */
@@ -729,6 +730,31 @@ struct bdb_mipi_config {
struct mipi_pps_data pps[MAX_MIPI_CONFIGURATIONS];
} __attribute__ ((packed));
+/* variable number of these - max 6 */
+struct bdb_mipi_sequence {
+ uint8_t version;
+ uint8_t data[0];
+} __attribute__ ((packed));
+
+/* MIPI Sequnece Block definitions */
+enum MIPI_SEQ {
+ MIPI_SEQ_UNDEFINED = 0,
+ MIPI_SEQ_ASSERT_RESET,
+ MIPI_SEQ_INIT_OTP,
+ MIPI_SEQ_DISPLAY_ON,
+ MIPI_SEQ_DISPLAY_OFF,
+ MIPI_SEQ_DEASSERT_RESET,
+ MIPI_SEQ_MAX
+};
+
+enum MIPI_SEQ_ELEMENT {
+ MIPI_SEQ_ELEM_UNDEFINED = 0,
+ MIPI_SEQ_ELEM_SEND_PKT,
+ MIPI_SEQ_ELEM_DELAY,
+ MIPI_SEQ_ELEM_GPIO,
+ MIPI_SEQ_ELEM_MAX
+};
+
/*
* Driver-VBIOS interaction occurs through scratch bits in
* GR18 SWF*.
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 9f82481..4fa47a9 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -71,6 +71,15 @@ struct bdb_block {
void *data;
};
+static const char * const seq_name[] = {
+ UNDEFINED,
+ MIPI_SEQ_ASSERT_RESET,
+ MIPI_SEQ_INIT_OTP,
+ MIPI_SEQ_DISPLAY_ON,
+ MIPI_SEQ_DISPLAY_OFF,
+ MIPI_SEQ_DEASSERT_RESET,
+};
+
struct bdb_header *bdb;
struct bdb_lvds_lfp_data_ptrs *lvds_lfp_data_ptrs;
static int tv_present;
@@ -784,6 +793,263 @@ static void dump_mipi_config(const struct bdb_block
*block)
printf(\t\tPanel power cycle delay: %d\n,
pps-panel_power_cycle_delay);
}
+static uint8_t *mipi_dump_send_packet(uint8_t *data)
+{
+ uint8_t type, byte, count;
+ uint16_t len;
+
+ byte = *data++;
+ /* get packet type and increment the pointer */
+ type = *data++;
+
+ len = *((uint16_t *) data);
+ data += 2;
+ printf(\t\t SEND COMMAND: );
+ printf(0x%x 0x%x 0x%x, byte, type, len);
+ for (count = 0; count len; count++)
+ printf( 0x%x,*(data+count));
+ printf(\n);
+ data += len;
+ return data;
+}
+
+static uint8_t *mipi_dump_delay(uint8_t *data)
+{
+ printf(\t\t Delay : 0x%x 0x%x 0x%x 0x%x\n, data[0], data[1], data[2],
data[3]);
+ data += 4;
+ return data;
+}
+
+static uint8_t *mipi_dump_gpio(uint8_t *data)
+{
+ uint8_t gpio, action;
+
+ printf(\t\t GPIO value:);
+ gpio = *data++;
+
+ /* pull up/down */
+ action = *data++;
+ printf( 0x%x 0x%x\n, gpio, action);
+ return data;
+}
+
+typedef uint8_t * (*fn_mipi_elem_dump)(uint8_t *data);
+
+static const fn_mipi_elem_dump dump_elem[] = {
+ NULL, /* reserved */
+ mipi_dump_send_packet,
+ mipi_dump_delay,
+ mipi_dump_gpio,
+ NULL, /* status read; later */
+};
+
+static void dump_sequence(uint8_t *sequence)
+{
+ uint8_t *data = sequence;
+ fn_mipi_elem_dump mipi_elem_dump;
+ int index_no;
+
+ if (!sequence)
+ return;
+
+ printf(\tSequence Name: %s\n, seq_name[*data]);
+
+ /* go to the first element of the sequence */
+ data++;
+
+ /* parse each byte till we reach end of sequence byte - 0x00 */
+ while (1) {
+ index_no = *data;
+ mipi_elem_dump = dump_elem[index_no];
+ if (!mipi_elem_dump) {
+ printf(Error: Unsupported MIPI element, skipping
sequence execution\n);
+ return;
+ }
+ /* goto element payload */
+ data++;
+
+ /* execute the element specifc rotines */
+ data = mipi_elem_dump(data);
+
+ /*
+* After processing the element, data should point to
+* next element or end of sequence
+* check if have we reached end of sequence
+*/
+
+ if (*data == 0x00)
+ break;
+ }
+}
+
+static uint8_t *goto_next_sequence(uint8_t *data, int *size)
+{
+ uint16_t len;
+ int tmp = *size;
+
+ if (--tmp 0)
+ return NULL;
+
+ /* goto first element */
+ data++;
+ while (1) {
+ switch (*data) {
+ case MIPI_SEQ_ELEM_SEND_PKT:
+ /*
+* skip by this element payload size
+* skip elem id, command flag and data type
+*/
+ tmp -= 5;
[Intel-gfx] [IGT 1/2] intel_bios_reader: Add support to dump MIPI Configuration Block #52
Signed-off-by: Gaurav K Singh gaurav.k.si...@intel.com
---
tools/intel_bios.h| 132 +
tools/intel_bios_reader.c | 94
2 files changed, 226 insertions(+)
diff --git a/tools/intel_bios.h b/tools/intel_bios.h
index 832c580..752379a 100644
--- a/tools/intel_bios.h
+++ b/tools/intel_bios.h
@@ -85,6 +85,8 @@ struct bdb_header {
#define BDB_LVDS_LFP_DATA 42
#define BDB_LVDS_BACKLIGHT 43
#define BDB_LVDS_POWER 44
+#define BDB_MIPI_CONFIG 52
+#define BDB_MIPI_SEQUENCE 53
#define BDB_SKIP 254 /* VBIOS private block, ignore */
struct bdb_general_features {
@@ -597,6 +599,136 @@ struct bdb_edp {
uint16_t edp_t3_optimization;
} __attribute__ ((packed));
+
+/* Block 52 contains MiPi Panel info
+ * 6 such enteries will there. Index into correct
+ * entery is based on the panel_index in #40 LFP
+ */
+#define MAX_MIPI_CONFIGURATIONS6
+struct mipi_config {
+ uint16_t panel_id;
+
+ /* General Params */
+ uint32_t dithering:1;
+ uint32_t rsvd1:1;
+ uint32_t panel_type:1;
+ uint32_t panel_arch_type:2;
+ uint32_t cmd_mode:1;
+ uint32_t vtm:2;
+ uint32_t cabc:1;
+ uint32_t pwm_blc:1;
+
+ /* Bit 13:10
+* 000 - Reserved, 001 - RGB565, 002 - RGB666,
+* 011 - RGB666Loosely packed, 100 - RGB888,
+* others - rsvd
+*/
+ uint32_t videomode_color_format:4;
+
+ /* Bit 15:14
+* 0 - No rotation, 1 - 90 degree
+* 2 - 180 degree, 3 - 270 degree
+*/
+ uint32_t rotation:2;
+ uint32_t bta:1;
+ uint32_t rsvd2:15;
+
+ /* 2 byte Port Description */
+ uint16_t dual_link:2;
+ uint16_t lane_cnt:2;
+ uint16_t rsvd3:12;
+
+ /* 2 byte DSI COntroller params */
+ /* 0 - Using DSI PHY, 1 - TE usage */
+ uint16_t dsi_usage:1;
+ uint16_t rsvd4:15;
+
+ uint8_t rsvd5[5];
+ uint32_t dsi_ddr_clk;
+ uint32_t bridge_ref_clk;
+
+ uint8_t byte_clk_sel:2;
+ uint8_t rsvd6:6;
+
+ /* DPHY Flags */
+ uint16_t dphy_param_valid:1;
+ uint16_t eot_disabled:1;
+ uint16_t clk_stop:1;
+ uint16_t rsvd7:13;
+
+ uint32_t hs_tx_timeout;
+ uint32_t lp_rx_timeout;
+ uint32_t turn_around_timeout;
+ uint32_t device_reset_timer;
+ uint32_t master_init_timer;
+ uint32_t dbi_bw_timer;
+ uint32_t lp_byte_clk_val;
+
+ /* 4 byte Dphy Params */
+ uint32_t prepare_cnt:6;
+ uint32_t rsvd8:2;
+ uint32_t clk_zero_cnt:8;
+ uint32_t trail_cnt:5;
+ uint32_t rsvd9:3;
+ uint32_t exit_zero_cnt:6;
+ uint32_t rsvd10:2;
+
+ uint32_t clk_lane_switch_cnt;
+ uint32_t hl_switch_cnt;
+
+ uint32_t rsvd11[6];
+
+ /* timings based on dphy spec */
+ uint8_t tclk_miss;
+ uint8_t tclk_post;
+ uint8_t rsvd12;
+ uint8_t tclk_pre;
+ uint8_t tclk_prepare;
+ uint8_t tclk_settle;
+ uint8_t tclk_term_enable;
+ uint8_t tclk_trail;
+ uint16_t tclk_prepare_clkzero;
+ uint8_t rsvd13;
+ uint8_t td_term_enable;
+ uint8_t teot;
+ uint8_t ths_exit;
+ uint8_t ths_prepare;
+ uint16_t ths_prepare_hszero;
+ uint8_t rsvd14;
+ uint8_t ths_settle;
+ uint8_t ths_skip;
+ uint8_t ths_trail;
+ uint8_t tinit;
+ uint8_t tlpx;
+ uint8_t rsvd15[3];
+
+ /* GPIOs */
+ uint8_t panel_enable;
+ uint8_t bl_enable;
+ uint8_t pwm_enable;
+ uint8_t reset_r_n;
+ uint8_t pwr_down_r;
+ uint8_t stdby_r_n;
+
+} __attribute__ ((packed));
+
+/* Block 52 contains MiPi configuration block
+ * 6 * bdb_mipi_config, followed by 6 pps data
+ * block below
+ */
+struct mipi_pps_data {
+ uint16_t panel_on_delay;
+ uint16_t bl_enable_delay;
+ uint16_t bl_disable_delay;
+ uint16_t panel_off_delay;
+ uint16_t panel_power_cycle_delay;
+} __attribute__ ((packed));
+
+struct bdb_mipi_config {
+ struct mipi_config config[MAX_MIPI_CONFIGURATIONS];
+ struct mipi_pps_data pps[MAX_MIPI_CONFIGURATIONS];
+} __attribute__ ((packed));
+
/*
* Driver-VBIOS interaction occurs through scratch bits in
* GR18 SWF*.
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 173772b..9f82481 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -696,6 +696,94 @@ static void dump_sdvo_lvds_options(const struct bdb_block
*block)
printf(\tmisc[3]: %x\n, options-panel_misc_bits_4);
}
+static void dump_mipi_config(const struct bdb_block *block)
+{
+ struct bdb_mipi_config *start = block-data;
+ struct mipi_config *config;
+ struct mipi_pps_data *pps;
+
+ config = start-config[panel_type];
+ pps = start-pps[panel_type];
+
+ printf(\tGeneral Param\n);
+
Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
On Thu, Jul 03, 2014 at 11:27:40PM +0300, Michael S. Tsirkin wrote:
On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
On Thu, 3 Jul 2014 14:26:12 -0400
Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote:
On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
With this long thread I lost a bit context about the challenges
that exists. But let me try summarizing it here - which will
hopefully
get some consensus.
1). Fix IGD hardware to not use Southbridge magic addresses.
We can moan and moan but I doubt it is going to change.
There are two problems:
- Northbridge (i.e. MCH i.e. PCI host bridge) configuration space
addresses
Right. So in drivers/gpu/drm/i915/i915_dma.c:
1135 #define MCHBAR_I915 0x44
1136 #define MCHBAR_I965 0x48
1147 int reg = INTEL_INFO(dev)-gen = 4 ? MCHBAR_I965 :
MCHBAR_I915;
1152 if (INTEL_INFO(dev)-gen = 4)
1153 pci_read_config_dword(dev_priv-bridge_dev, reg
+ 4, temp_hi);
1154 pci_read_config_dword(dev_priv-bridge_dev, reg,
temp_lo);
1155 mchbar_addr = ((u64)temp_hi 32) | temp_lo;
and
1139 #define DEVEN_REG 0x54
1193 int mchbar_reg = INTEL_INFO(dev)-gen = 4 ? MCHBAR_I965
: MCHBAR_I915;
1202 if (IS_I915G(dev) || IS_I915GM(dev)) {
1203 pci_read_config_dword(dev_priv-bridge_dev,
DEVEN_REG, temp);
1204 enabled = !!(temp DEVEN_MCHBAR_EN);
1205 } else {
1206 pci_read_config_dword(dev_priv-bridge_dev,
mchbar_reg, temp);
1207 enabled = temp 1;
1208 }
- Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some
versions of
the driver identify it by class, some versions identify it by slot
(1f.0).
Right, So in drivers/gpu/drm/i915/i915_drv.c the giant
intel_detect_pch
which sets the pch_type based on :
432 if (pch-vendor == PCI_VENDOR_ID_INTEL) {
433 unsigned short id = pch-device
INTEL_PCH_DEVICE_ID_MASK;
434 dev_priv-pch_id = id;
435
436 if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE)
{
It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
The INTEL_PCH_DEVICE_ID_MASK is 0xff00
To solve the first, make a new machine type, PIIX4-based, and pass
through
the registers you need. The patch must document _exactly_ why the
registers
are safe to pass. If they are not reserved on PIIX4, the patch must
document what the same offsets mean on PIIX4, and why it's sensible
to
assume that firmware for virtual machine will not read/write them.
Bonus
point for also documenting the same for Q35.
OK. They look to be related to setting up an MBAR , but I don't
understand
why it is needed. Hopefully some of the i915 folks CC-ed here can
answer.
In particular, I think setting up MBAR should move out of i915 and
become
the bridge driver tweak on linux and windows.
That is an excellent idea.
However I am still curious to _why_ it has to be done in the first place.
The display part of the GPU is partly on the PCH, and it's possible to
mix match them a bit, so we have this detection code to figure things
out. In some cases, the PCH display portion may not even be present,
so we look for that too.
Practically speaking, we could probably assume specific CPU/PCH combos,
as I don't think they're generally mixed across generations, though SNB
and IVB did have compatible sockets, so there is the possibility of
mixing CPT and PPT PCHs, but those are register identical as far as the
graphics driver is concerned, so even that should be safe.
Beyond that, the other MCH data we need to look at is mirrored into the
GPU's
Re: [Intel-gfx] [PATCH 0/2] Optimization on intel HDMI detect and get_modes
On 4/11/2014 8:18 PM, Sharma, Shashank wrote: Ok, I will change the implementation. Regards Shashank -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Friday, April 11, 2014 7:53 PM To: Sharma, Shashank Cc: Daniel Vetter; C, Ramalingam; Wang, Quanxian; intel-gfx Subject: Re: [Intel-gfx] [PATCH 0/2] Optimization on intel HDMI detect and get_modes On Fri, Apr 11, 2014 at 01:23:43PM +, Sharma, Shashank wrote: Thanks for the comments, Actually, we are not using live_status at all. The check for gen6 is only for EDID caching. So if the HW is = gen6 cache_edid. Else do not cache EDID, so that we will not block any of the old HW, which might not be HPD capable. Oh, I've thought that this is incremental on top of something you already have. Does it sound ok now :) ? No. HPD is _NOT_ I repeat _NOT_ reliably. Not even on gen6+. live status simply reflects the hpd pin, if either doesn't work, then neither does the other one. Nacked-with-prejudice-by: Daniel Vetter daniel.vet...@ffwll.ch Again re-starting the thread on this. Discussed this with Daniel on IRC and want to put the design agreed here for any further comments if any - On detect call if no edid cached, then read full edid and cache. Assumption is that usermode will do the processing within 1s and we can just maintain this cache for 1s and clear. This will work also for panels which do not reliably assert HPD/Live status and also we get benefit of caching. This will still fail compliance where we should not read any thing on ddc if live status is not detected. So plan is to add a compliance mode by way of module param which will be by default off. This code path will rely on HPD and Live status. Regards Shobhit ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Rework GPU reset sequence to match driver load thaw
From: McAulay, Alistair alistair.mcau...@intel.com
This patch is to address Daniels concerns over different code during reset:
http://lists.freedesktop.org/archives/intel-gfx/2014-June/047758.html
The reason for aiming as hard as possible to use the exact same code for
driver load, gpu reset and runtime pm/system resume is that we've simply
seen too many bugs due to slight variations and unintended omissions.
Tested using igt drv_hangman.
Signed-off-by: McAulay, Alistair alistair.mcau...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 2 -
drivers/gpu/drm/i915/i915_gem_context.c | 42 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 67 +
drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +-
5 files changed, 14 insertions(+), 104 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ef047bc..b38e086 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2590,8 +2590,6 @@ void i915_gem_reset(struct drm_device *dev)
for_each_ring(ring, dev_priv, i)
i915_gem_reset_ring_cleanup(dev_priv, ring);
- i915_gem_context_reset(dev);
-
i915_gem_restore_fences(dev);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index de72a28..d96219f 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -372,42 +372,6 @@ err_destroy:
return ERR_PTR(ret);
}
-void i915_gem_context_reset(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev-dev_private;
- int i;
-
- /* Prevent the hardware from restoring the last context (which hung) on
-* the next switch */
- for (i = 0; i I915_NUM_RINGS; i++) {
- struct intel_engine_cs *ring = dev_priv-ring[i];
- struct intel_context *dctx = ring-default_context;
- struct intel_context *lctx = ring-last_context;
-
- /* Do a fake switch to the default context */
- if (lctx == dctx)
- continue;
-
- if (!lctx)
- continue;
-
- if (dctx-legacy_hw_ctx.rcs_state i == RCS) {
-
WARN_ON(i915_gem_obj_ggtt_pin(dctx-legacy_hw_ctx.rcs_state,
-
get_context_alignment(dev), 0));
- /* Fake a finish/inactive */
- dctx-legacy_hw_ctx.rcs_state-base.write_domain = 0;
- dctx-legacy_hw_ctx.rcs_state-active = 0;
- }
-
- if (lctx-legacy_hw_ctx.rcs_state i == RCS)
-
i915_gem_object_ggtt_unpin(lctx-legacy_hw_ctx.rcs_state);
-
- i915_gem_context_unreference(lctx);
- i915_gem_context_reference(dctx);
- ring-last_context = dctx;
- }
-}
-
int i915_gem_context_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -498,10 +462,6 @@ int i915_gem_context_enable(struct drm_i915_private
*dev_priv)
ppgtt-enable(ppgtt);
}
- /* FIXME: We should make this work, even in reset */
- if (i915_reset_in_progress(dev_priv-gpu_error))
- return 0;
-
BUG_ON(!dev_priv-ring[RCS].default_context);
for_each_ring(ring, dev_priv, i) {
@@ -645,7 +605,7 @@ static int do_switch(struct intel_engine_cs *ring,
from = ring-last_context;
if (USES_FULL_PPGTT(ring-dev)) {
- ret = ppgtt-switch_mm(ppgtt, ring, false);
+ ret = ppgtt-switch_mm(ppgtt, ring);
if (ret)
goto unpin_out;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 5188936..450c8a9 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -216,19 +216,12 @@ static gen6_gtt_pte_t iris_pte_encode(dma_addr_t addr,
/* Broadwell Page Directory Pointer Descriptors */
static int gen8_write_pdp(struct intel_engine_cs *ring, unsigned entry,
- uint64_t val, bool synchronous)
+ uint64_t val)
{
- struct drm_i915_private *dev_priv = ring-dev-dev_private;
int ret;
BUG_ON(entry = 4);
- if (synchronous) {
- I915_WRITE(GEN8_RING_PDP_UDW(ring, entry), val 32);
- I915_WRITE(GEN8_RING_PDP_LDW(ring, entry), (u32)val);
- return 0;
- }
-
ret = intel_ring_begin(ring, 6);
if (ret)
return ret;
@@ -245,8 +238,7 @@ static int gen8_write_pdp(struct intel_engine_cs *ring,
unsigned entry,
}
static int gen8_mm_switch(struct i915_hw_ppgtt *ppgtt,
- struct intel_engine_cs *ring,
- bool
[Intel-gfx] [RFC v2 0/3] drm/i915: Trace point callbacks for kernel validation
From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com The callbacks are useful for validation because they can be used to extract real-time information from the kernel. v2: duplicate the i915_gem_ring_dispatch trace instead of modifying the existing one. I plan to resubmit these patches together with an igt test and a kernel module that uses the callbacks (as requested), but before doing that I wanted to be sure that I've correctly addressed all the comments. Daniele Ceraolo Spurio (3): drm/i915: Add ppgtt init/release trace points drm/i915: duplicate i915_gem_ring_dispatch trace and add ctx parameter drm/i915: Trace point callbacks for validation drivers/gpu/drm/i915/i915_gem_context.c| 9 +++ drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 ++ drivers/gpu/drm/i915/i915_trace.h | 90 ++ 3 files changed, 104 insertions(+) -- 1.8.5.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v2 3/3] drm/i915: Trace point callbacks for validation
From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com These callbacks can be assigned to specific functions inside an external validation kernel module. This module can then extract run-time information to make sure everything is working as expected. Specifically, these two callbacks extract information about full PPGTT and batch dispatch. Signed-off-by: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com --- drivers/gpu/drm/i915/i915_gem_context.c| 3 +++ drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +++ drivers/gpu/drm/i915/i915_trace.h | 22 ++ 3 files changed, 28 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index 133da7b..9fc81a2 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -90,6 +90,9 @@ #include i915_drv.h #include i915_trace.h +i915_ppgtt_validation_callback_t ppgtt_validation_callback = NULL; +EXPORT_SYMBOL_GPL(ppgtt_validation_callback); + /* This is a HW constraint. The value below is the largest known requirement * I've seen in a spec to date, and that was a workaround for a non-shipping * part. It should be safe to decrease this, but it's more future proof as is. diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 6b0dd9f..e5daef10 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -33,6 +33,9 @@ #include intel_drv.h #include linux/dma_remapping.h +i915_gem_ring_dispatch_callback_t i915_gem_ring_dispatch_validation_callback = NULL; +EXPORT_SYMBOL_GPL(i915_gem_ring_dispatch_validation_callback); + #define __EXEC_OBJECT_HAS_PIN (131) #define __EXEC_OBJECT_HAS_FENCE (130) #define __EXEC_OBJECT_NEEDS_BIAS (128) diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h index d639d6c..a16e29c 100644 --- a/drivers/gpu/drm/i915/i915_trace.h +++ b/drivers/gpu/drm/i915/i915_trace.h @@ -15,6 +15,18 @@ #define TRACE_SYSTEM_STRING __stringify(TRACE_SYSTEM) #define TRACE_INCLUDE_FILE i915_trace +/* validation callbacks */ + +typedef void (*i915_ppgtt_validation_callback_t)(unsigned int action_code, +struct i915_hw_ppgtt *ppgtt); +extern i915_ppgtt_validation_callback_t ppgtt_validation_callback; + +typedef void (*i915_gem_ring_dispatch_callback_t)(struct intel_engine_cs *ring, + u32 seqno, + u32 flags, + struct intel_context *ctx); +extern i915_gem_ring_dispatch_callback_t i915_gem_ring_dispatch_validation_callback; + /* pipe updates */ TRACE_EVENT(i915_pipe_update_start, @@ -394,6 +406,10 @@ TRACE_EVENT(i915_gem_ring_dispatch_validation, __entry-flags = flags; __entry-vm = ctx-vm; i915_trace_irq_get(ring, seqno); + + if (i915_gem_ring_dispatch_validation_callback) + i915_gem_ring_dispatch_validation_callback(ring, + seqno, flags, ctx); ), TP_printk(dev=%u, ring=%u, seqno=%u, flags=%x, vm=%p, @@ -630,6 +646,9 @@ TRACE_EVENT(create_vm_for_ctx, __entry-vm = ppgtt-base; __entry-dev = ppgtt-base.dev-primary-index; __entry-pid = (unsigned int)task_pid_nr(current); + + if (ppgtt_validation_callback) + ppgtt_validation_callback(0, ppgtt); ), TP_printk(dev=%u, task_pid=%u, vm=%p, @@ -650,6 +669,9 @@ TRACE_EVENT(ppgtt_release, TP_fast_assign( __entry-vm = ppgtt-base; __entry-dev = ppgtt-base.dev-primary-index; + + if (ppgtt_validation_callback) + ppgtt_validation_callback(1, ppgtt); ), TP_printk(dev=%u, vm=%p, __entry-dev, __entry-vm) -- 1.8.5.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v2 2/3] drm/i915: duplicate i915_gem_ring_dispatch trace and add ctx parameter
From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com The context used to execute a batchbuffer is becoming increasingly important. Duplicating to avoid modifications to the original trace. Signed-off-by: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 ++ drivers/gpu/drm/i915/i915_trace.h | 27 +++ 2 files changed, 29 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 60998fc..6b0dd9f 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -1174,6 +1174,8 @@ legacy_ringbuffer_submission(struct drm_device *dev, struct drm_file *file, } trace_i915_gem_ring_dispatch(ring, intel_ring_get_seqno(ring), flags); + trace_i915_gem_ring_dispatch_validation(ring, + intel_ring_get_seqno(ring), flags, ctx); i915_gem_execbuffer_move_to_active(vmas, ring); i915_gem_execbuffer_retire_commands(dev, file, ring, batch_obj); diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h index 9be1421..d639d6c 100644 --- a/drivers/gpu/drm/i915/i915_trace.h +++ b/drivers/gpu/drm/i915/i915_trace.h @@ -374,6 +374,33 @@ TRACE_EVENT(i915_gem_ring_dispatch, __entry-dev, __entry-ring, __entry-seqno, __entry-flags) ); +TRACE_EVENT(i915_gem_ring_dispatch_validation, + TP_PROTO(struct intel_engine_cs *ring, u32 seqno, u32 flags, +struct intel_context *ctx), + TP_ARGS(ring, seqno, flags, ctx), + + TP_STRUCT__entry( +__field(u32, dev) +__field(u32, ring) +__field(u32, seqno) +__field(u32, flags) +__field(struct i915_address_space *, vm) +), + + TP_fast_assign( + __entry-dev = ring-dev-primary-index; + __entry-ring = ring-id; + __entry-seqno = seqno; + __entry-flags = flags; + __entry-vm = ctx-vm; + i915_trace_irq_get(ring, seqno); + ), + + TP_printk(dev=%u, ring=%u, seqno=%u, flags=%x, vm=%p, + __entry-dev, __entry-ring, __entry-seqno, + __entry-flags, __entry-vm) +); + TRACE_EVENT(i915_gem_ring_flush, TP_PROTO(struct intel_engine_cs *ring, u32 invalidate, u32 flush), TP_ARGS(ring, invalidate, flush), -- 1.8.5.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/1] Revert drm/i915: drop i915_ prefix from enable_rc6, enable_fbc, enable_ppgtt parameters
This reverts commit 3adee7a7976012a20f1d3b5a529a3c105e29fef1. After upgrading to v3.15, my laptop's battery started draining quite fast. Powertop pointed to the deep RC6 states not being used. The kernel param I had put to enable them had stopped working the way it used to; so I disagree with the 'not maintaing ABI' part of the param name change. However weird the names may be, they're in active use and changing them only causes pain for users. This also isn't advertised (marked deprecated, big warning shown, etc.), so just reverting now. CC: Daniel Vetter daniel.vet...@ffwll.ch CC: Jani Nikula jani.nik...@linux.intel.com CC: David Airlie airl...@linux.ie CC: sta...@vger.kernel.org # v3.15+ Signed-off-by: Amit Shah amit.s...@redhat.com --- drivers/gpu/drm/i915/i915_params.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index d05a2af..053981d 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -69,16 +69,16 @@ MODULE_PARM_DESC(semaphores, Use semaphores for inter-ring sync (default: -1 (use per-chip defaults))); -module_param_named(enable_rc6, i915.enable_rc6, int, 0400); -MODULE_PARM_DESC(enable_rc6, +module_param_named(i915_enable_rc6, i915.enable_rc6, int, 0400); +MODULE_PARM_DESC(i915_enable_rc6, Enable power-saving render C-state 6. Different stages can be selected via bitmask values (0 = disable; 1 = enable rc6; 2 = enable deep rc6; 4 = enable deepest rc6). For example, 3 would enable rc6 and deep rc6, and 7 would enable everything. default: -1 (use per-chip default)); -module_param_named(enable_fbc, i915.enable_fbc, int, 0600); -MODULE_PARM_DESC(enable_fbc, +module_param_named(i915_enable_fbc, i915.enable_fbc, int, 0600); +MODULE_PARM_DESC(i915_enable_fbc, Enable frame buffer compression for power savings (default: -1 (use per-chip default))); @@ -111,8 +111,8 @@ MODULE_PARM_DESC(enable_hangcheck, WARNING: Disabling this can cause system wide hangs. (default: true)); -module_param_named(enable_ppgtt, i915.enable_ppgtt, int, 0400); -MODULE_PARM_DESC(enable_ppgtt, +module_param_named(i915_enable_ppgtt, i915.enable_ppgtt, int, 0400); +MODULE_PARM_DESC(i915_enable_ppgtt, Override PPGTT usage. (-1=auto [default], 0=disabled, 1=aliasing, 2=full)); -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] Revert drm/i915: drop i915_ prefix from enable_rc6, enable_fbc, enable_ppgtt parameters
Sorry for the top post, I'm on the road.. In wondering if we couldn't just keep both the old an the new names and have them both point at the same variable? Remove the description for the old name, but keep it working? Linus On Jul 16, 2014 8:34 AM, Amit Shah amit.s...@redhat.com wrote: This reverts commit 3adee7a7976012a20f1d3b5a529a3c105e29fef1. After upgrading to v3.15, my laptop's battery started draining quite fast. Powertop pointed to the deep RC6 states not being used. The kernel param I had put to enable them had stopped working the way it used to; so I disagree with the 'not maintaing ABI' part of the param name change. However weird the names may be, they're in active use and changing them only causes pain for users. This also isn't advertised (marked deprecated, big warning shown, etc.), so just reverting now. CC: Daniel Vetter daniel.vet...@ffwll.ch CC: Jani Nikula jani.nik...@linux.intel.com CC: David Airlie airl...@linux.ie CC: sta...@vger.kernel.org # v3.15+ Signed-off-by: Amit Shah amit.s...@redhat.com --- drivers/gpu/drm/i915/i915_params.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index d05a2af..053981d 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -69,16 +69,16 @@ MODULE_PARM_DESC(semaphores, Use semaphores for inter-ring sync (default: -1 (use per-chip defaults))); -module_param_named(enable_rc6, i915.enable_rc6, int, 0400); -MODULE_PARM_DESC(enable_rc6, +module_param_named(i915_enable_rc6, i915.enable_rc6, int, 0400); +MODULE_PARM_DESC(i915_enable_rc6, Enable power-saving render C-state 6. Different stages can be selected via bitmask values (0 = disable; 1 = enable rc6; 2 = enable deep rc6; 4 = enable deepest rc6). For example, 3 would enable rc6 and deep rc6, and 7 would enable everything. default: -1 (use per-chip default)); -module_param_named(enable_fbc, i915.enable_fbc, int, 0600); -MODULE_PARM_DESC(enable_fbc, +module_param_named(i915_enable_fbc, i915.enable_fbc, int, 0600); +MODULE_PARM_DESC(i915_enable_fbc, Enable frame buffer compression for power savings (default: -1 (use per-chip default))); @@ -111,8 +111,8 @@ MODULE_PARM_DESC(enable_hangcheck, WARNING: Disabling this can cause system wide hangs. (default: true)); -module_param_named(enable_ppgtt, i915.enable_ppgtt, int, 0400); -MODULE_PARM_DESC(enable_ppgtt, +module_param_named(i915_enable_ppgtt, i915.enable_ppgtt, int, 0400); +MODULE_PARM_DESC(i915_enable_ppgtt, Override PPGTT usage. (-1=auto [default], 0=disabled, 1=aliasing, 2=full)); -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tests/pm_rpm: add dpms-mode-unset{, -non}-lpsp subtests
From: Paulo Zanoni paulo.r.zan...@intel.com
These tests currently trigger WARNs on our Kernel. Let's make sure we
fix the bug and it never comes back.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
tests/pm_rpm.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
index 323e072..1e63bc8 100644
--- a/tests/pm_rpm.c
+++ b/tests/pm_rpm.c
@@ -1390,6 +1390,23 @@ static void system_suspend_subtest(void)
igt_assert(wait_for_suspended());
}
+/* Enable a screen, activate DPMS, then do a modeset. At some point our driver
+ * produced WARNs on this case. */
+static void dpms_mode_unset_subtest(enum screen_type type)
+{
+ disable_all_screens(ms_data);
+ igt_assert(wait_for_suspended());
+
+ igt_require(enable_one_screen_with_type(ms_data, type));
+ igt_assert(wait_for_active());
+
+ disable_all_screens_dpms(ms_data);
+ igt_assert(wait_for_suspended());
+
+ disable_all_screens(ms_data);
+ igt_assert(wait_for_suspended());
+}
+
int main(int argc, char *argv[])
{
int rounds = 50;
@@ -1462,6 +1479,10 @@ int main(int argc, char *argv[])
debugfs_forcewake_user_subtest();
igt_subtest(sysfs-read)
sysfs_read_subtest();
+ igt_subtest(dpms-mode-unset-lpsp)
+ dpms_mode_unset_subtest(SCREEN_TYPE_LPSP);
+ igt_subtest(dpms-mode-unset-non-lpsp)
+ dpms_mode_unset_subtest(SCREEN_TYPE_NON_LPSP);
/* Modeset stress */
igt_subtest(modeset-lpsp-stress)
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: check the power wells on assert_{cursor, plane}
From: Paulo Zanoni paulo.r.zan...@intel.com
Since we merged runtime PM support for DPMS, it is possible that these
functions will be called when the power wells are disabled but a mode
is set, resulting in failed assertion and device suspended while
reading register WARNs.
To reproduce the bug: disable all screens using mode unset, do a
modeset on one screen, disable it using DPMS, then try to do a mode
unset on it again to see the WARNs.
Testcase: igt/rpm_rpm/dpms-mode-unset-lpsp
Testcase: igt/rpm_rpm/dpms-mode-unset-non-lpsp
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 54e3af9..7ad46e2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1216,7 +1216,9 @@ static void assert_cursor(struct drm_i915_private
*dev_priv,
struct drm_device *dev = dev_priv-dev;
bool cur_state;
- if (IS_845G(dev) || IS_I865G(dev))
+ if (!intel_display_power_enabled(dev_priv, POWER_DOMAIN_PIPE(pipe)))
+ cur_state = false;
+ else if (IS_845G(dev) || IS_I865G(dev))
cur_state = I915_READ(_CURACNTR) CURSOR_ENABLE;
else
cur_state = I915_READ(CURCNTR(pipe)) CURSOR_MODE;
@@ -1262,9 +1264,13 @@ static void assert_plane(struct drm_i915_private
*dev_priv,
u32 val;
bool cur_state;
- reg = DSPCNTR(plane);
- val = I915_READ(reg);
- cur_state = !!(val DISPLAY_PLANE_ENABLE);
+ if (!intel_display_power_enabled(dev_priv, POWER_DOMAIN_PIPE(plane))) {
+ cur_state = false;
+ } else {
+ reg = DSPCNTR(plane);
+ val = I915_READ(reg);
+ cur_state = !!(val DISPLAY_PLANE_ENABLE);
+ }
WARN(cur_state != state,
plane %c assertion failure (expected %s, current %s)\n,
plane_name(plane), state_string(state), state_string(cur_state));
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: BDW can also detect unclaimed registers
From: Paulo Zanoni paulo.r.zan...@intel.com
By the time I wrote this patch, it allowed me to catch some problems.
But due to patch reordering - in order to prevent fake regression
reports - this patch may be merged after the fixes of the problems
identified by this patch.
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 4
drivers/gpu/drm/i915/intel_uncore.c | 3 +++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5e4fefd..3315358 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -303,6 +303,7 @@ static const struct intel_device_info
intel_broadwell_d_info = {
.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,
@@ -314,6 +315,7 @@ static const struct intel_device_info
intel_broadwell_m_info = {
.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,
@@ -325,6 +327,7 @@ static const struct intel_device_info
intel_broadwell_gt3d_info = {
.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,
@@ -336,6 +339,7 @@ static const struct intel_device_info
intel_broadwell_gt3m_info = {
.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,
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 6fee122..e81bc3b 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -747,6 +747,7 @@ static bool is_gen8_shadowed(struct drm_i915_private
*dev_priv, u32 reg)
static void \
gen8_write##x(struct drm_i915_private *dev_priv, off_t reg, u##x val, bool
trace) { \
REG_WRITE_HEADER; \
+ hsw_unclaimed_reg_debug(dev_priv, reg, false, true); \
if (reg 0x4 !is_gen8_shadowed(dev_priv, reg)) { \
if (dev_priv-uncore.forcewake_count == 0) \
dev_priv-uncore.funcs.force_wake_get(dev_priv, \
@@ -758,6 +759,8 @@ gen8_write##x(struct drm_i915_private *dev_priv, off_t reg,
u##x val, bool trace
} else { \
__raw_i915_write##x(dev_priv, reg, val); \
} \
+ hsw_unclaimed_reg_debug(dev_priv, reg, false, false); \
+ hsw_unclaimed_reg_detect(dev_priv); \
REG_WRITE_FOOTER; \
}
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: reorganize the unclaimed register detection code
From: Paulo Zanoni paulo.r.zan...@intel.com
The current code only runs when we do an I915_WRITE operation. It
checks if the unclaimed register flag is set before we do the
operation, and then it checks it again after we do the operation. This
double check allows us to find out if the I915_WRITE operation in
question is the bad one, or if some previous code is the bad one. When
it finds a problem, our code uses DRM_ERROR to signal it.
The good thing about the current code is that it detects the problem,
so at least we can know we did something wrong. The problem is that
even though we find the problem, we don't really have much information
to actually debug it. So whenever I see one of these DRM_ERROR
messages on my systems, the first thing I do is apply a patch to
change the DRM_ERROR to a WARN and also check for unclaimed registers
on I915_READ operations. This local patch makes things even slower,
but it usually helps a lot in finding the bad code.
The first point here is that since the current code is only useful to
detect whether we have a problem or not, but it is not really good to
find the cause of the problem, I don't think we should be checking
both before and after every I915_WRITE operation: just doing the check
once should be enough for us to quickly detect problems. With this
change, the code that runs by default for every single user will only
do 1 read operation for every single I915_WRITE, instead of 2. This
patch does this change.
The second point is that the local patch I have should be upstream,
but since it makes things slower it should be disabled by default. So
I added the i915.mmio_debug option to enable it.
So after this patch, this is what will happen:
- By default, we will try to detect unclaimed registers once after
every I915_WRITE operation. Previously we tried twice for every
I915_WRITE.
- When we find an unclaimed register we will still print a DRM_ERROR
message, but we will now tell the user to try again with
i915.mmio_debug=1.
- When we use i915.mmio_debug=1 we will try to find unclaimed
registers both before and after every I915_READ and I915_WRITE
operation, and we will print stack traces in case we find them.
This should really help locating the exact point of the bad code
(or at least finding out that i915.ko is not the problem).
This commit also opens space for really-slow register debugging
operations on other platforms. In theory we can now add lots and lots
of debug code behind i915.mmio_debug, enable this option on our tests,
and catch more problems.
v2: - Remove not-so-useful comments (Daniel)
- Fix the param definition macros (Rodrigo)
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_params.c | 6 ++
drivers/gpu/drm/i915/intel_uncore.c | 27 ---
3 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 991b663..ca0a9dd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2135,6 +2135,7 @@ struct i915_params {
bool disable_display;
bool disable_vtd_wa;
int use_mmio_flip;
+ bool mmio_debug;
};
extern struct i915_params i915 __read_mostly;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index bbdee21..62ee830 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -49,6 +49,7 @@ struct i915_params i915 __read_mostly = {
.enable_cmd_parser = 1,
.disable_vtd_wa = 0,
.use_mmio_flip = 0,
+ .mmio_debug = 0,
};
module_param_named(modeset, i915.modeset, int, 0400);
@@ -161,3 +162,8 @@ MODULE_PARM_DESC(enable_cmd_parser,
module_param_named(use_mmio_flip, i915.use_mmio_flip, int, 0600);
MODULE_PARM_DESC(use_mmio_flip,
use MMIO flips (-1=never, 0=driver discretion [default],
1=always));
+
+module_param_named(mmio_debug, i915.mmio_debug, bool, 0600);
+MODULE_PARM_DESC(mmio_debug,
+ Enable the MMIO debug code (default: false). This may negatively
+ affect performance.);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index e0f0843..6fee122 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -514,20 +514,30 @@ ilk_dummy_write(struct drm_i915_private *dev_priv)
}
static void
-hsw_unclaimed_reg_clear(struct drm_i915_private *dev_priv, u32 reg)
+hsw_unclaimed_reg_debug(struct drm_i915_private *dev_priv, u32 reg, bool read,
+ bool before)
{
+ const char *op = read ? reading : writing to;
+ const char *when = before ? before : after;
+
+ if (!i915.mmio_debug)
+ return;
+
if (__raw_i915_read32(dev_priv, FPGA_DBG) FPGA_DBG_RM_NOCLAIM) {
-
Re: [Intel-gfx] [PATCH 1/4] drm/i915: don't warn if IRQs are disabled when shutting down display IRQs
2014-07-14 14:34 GMT-03:00 Daniel Vetter dan...@ffwll.ch: On Mon, Jul 14, 2014 at 11:56:57AM -0300, Paulo Zanoni wrote: 2014-07-07 18:53 GMT-03:00 Jesse Barnes jbar...@virtuousgeek.org: On Mon, 7 Jul 2014 18:48:47 -0300 Paulo Zanoni przan...@gmail.com wrote: (documenting what we discussed on IRC) 2014-06-20 13:29 GMT-03:00 Jesse Barnes jbar...@virtuousgeek.org: This was always the case on our suspend path, but it was recently exposed by the change to use our runtime IRQ disable routine rather than the full DRM IRQ disable. Keep the warning on the enable side, as that really would indicate a bug. While I understand the patch and think it's a reasonable thing to do, I feel the need to spend some time persuading you in replacing it with something that doesn't involve removing WARNs from our driver. While the driver is runtime suspended, no one should really be manipulating IRQs, even if they're disabling stuff that is already disabled: this reflects there's probably a problem somewhere. These WARNs are extremely helpful for the runtime PM feature because almost nobody actually uses runtime PM to notice any bugs with it, so the WARNs can make QA report bugs and bisect things for us. Also, it seems S3 suspend is currently a little disaster on our driver. Your 6 patches just solve some of the WARNs, not all of them. And last week I even solved another WARN on the S3 path. I just did some investigation, and the current bad commits are: 8abdc17941c71b37311bb93876ac83dce58160c8, e11aa362308f5de467ce355a2a2471321b15a35c and 85e90679335f56d162f4a0ff525573818e17ce44. If I just revert these 3 commits, S3 doesn't give me any WARNs. Instead of the change you proposed, can't we think of another solution that would maybe address all the 3 regressions we have? Since we're always submitting patches to change the order we do things at S3 suspend/resume, shouldn't we add something like dev_priv-suspending that could be used to avoid the strict ordering that is required during runtime? Hm I was running with those changes and didn't see additional warnings, so I'll have to look again. I agree we want sensible warnings in place, and maybe removing this one is too permissive, but I'd like to avoid a suspending flag if we can. Maybe we just need to bundle up our assertions and check all the relevant state after runtime suspend or S3 like we do for mode set state in various places. That would let us keep our warnings, but also save us from having them spread out in code paths that get used in many different contexts. I'm probably going to regret this, but since no one proposed a better patch and the bug is still there: Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com Not really eager to merge a patch soaking in preemptive regrets ... I'll punt on this for now. Possible solutions: 1 - Patch xxx_disable_vblank to do nothing in case dev_priv-pm.suspended 2 - Add a flag dev_priv-suspending and don't print those WARNs in case it is set. 3 - Merge Jesse's original patch 4 - Something else? I can implement any of the proposed solutions if needed... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/11] CHROMIUM: drm/i915: add backlight assertion funcs for PWM status
From: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Wayne Boyer wayne.bo...@intel.com
Change-Id: I0838b7c84f1913e1026ad98b8b2e79eb133d17e3
Reviewed-on: https://chromium-review.googlesource.com/192468
Reviewed-by: Stéphane Marchesin marc...@chromium.org
Reviewed-by: Aaron Durbin adur...@chromium.org
Tested-by: Wayne Boyer wayne.bo...@intel.com
Commit-Queue: Wayne Boyer wayne.bo...@intel.com
Conflicts:
drivers/gpu/drm/i915/intel_dp.c
---
drivers/gpu/drm/i915/intel_dp.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2adb727..90b24f6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -369,6 +369,21 @@ static int edp_notify_handler(struct notifier_block *this,
unsigned long code,
return 0;
}
+static void assert_pwm(struct drm_i915_private *dev_priv,
+ struct intel_connector *connector,
+ bool expected_state)
+{
+ bool state;
+
+ state = dev_priv-display.get_backlight(connector);
+
+ WARN(state != expected_state, pwm state failure, expected %d, found
+%d\n, expected_state, state);
+}
+
+#define assert_pwm_enabled(d, p) assert_pwm((d), (p), true)
+#define assert_pwm_disabled(d, p) assert_pwm((d), (p), false)
+
static bool edp_have_panel_power(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
@@ -1351,6 +1366,8 @@ void intel_edp_panel_off(struct intel_dp *intel_dp)
WARN(!intel_dp-want_panel_vdd, Need VDD to turn off panel\n);
+ assert_pwm_disabled(dev_priv, intel_dp-attached_connector);
+
pp = ironlake_get_pp_control(intel_dp);
/* We need to switch off panel power _and_ force vdd, for otherwise some
* panels get very unhappy and cease to work. */
@@ -1387,6 +1404,8 @@ void intel_edp_backlight_on(struct intel_dp *intel_dp)
intel_panel_enable_backlight(intel_dp-attached_connector);
+ assert_pwm_disabled(dev_priv, intel_dp-attached_connector);
+
/*
* If we enable the backlight right away following a panel power
* on, we may see slight flicker as the panel syncs with the eDP
@@ -1415,6 +1434,9 @@ void intel_edp_backlight_off(struct intel_dp *intel_dp)
DRM_DEBUG_KMS(\n);
pp = ironlake_get_pp_control(intel_dp);
+
+ assert_pwm_enabled(dev_priv, intel_dp-attached_connector);
+
pp = ~EDP_BLC_ENABLE;
pp_ctrl_reg = _pp_ctrl_reg(intel_dp);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/11] drm/i915: backlight scaling and timing changes from chromium.
From: Clint Taylor clinton.a.tay...@intel.com Upstreaming Chromium backlight related patches which including minimum duty cycle and 0..max_brightness scaling of the sysfs requested brightness level. Ben Widawsky (5): CHROMIUM: drm/i915/vlv: Initialize pipe B backlight to A's value CHROMIUM: drm/i915: Provide valleyview backlight fallback value CHROMIUM: drm/i915/vlv: Scale backlight to min duty ratio CHROMIUM: drm/i915/vlv: Check BLC enable for pwm invariant CHROMIUM: drm/i915/vlv: Prefer VBT to set PWM Jani Nikula (1): CHROMIUM: drm/i915: parse backlight modulation frequency from the BIOS VBT Jesse Barnes (4): CHROMIUM: drm/i915: add backlight assertion funcs for PWM status CHROMIUM: drm/i915: do not explicitly disable backlight in panel_off CHROMIUM: drm/i915: use backlight wrapper functions instead of direct calls CHROMIUM: drm/i915: change order of PWM enable vs BLC enable Kevin Strasser (1): CHROMIUM: drm/i915/vlv: Fix BLM_PWM_ENABLE check in pwm invariant drivers/gpu/drm/i915/i915_drv.h| 10 ++ drivers/gpu/drm/i915/intel_bios.c | 35 +++- drivers/gpu/drm/i915/intel_dp.c| 36 ++--- drivers/gpu/drm/i915/intel_drv.h |1 + drivers/gpu/drm/i915/intel_panel.c | 62 ++-- 5 files changed, 123 insertions(+), 21 deletions(-) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/11] CHROMIUM: drm/i915/vlv: Scale backlight to min duty ratio
From: Ben Widawsky benjamin.widaw...@intel.com
On VLV specifically, going too low runs the risk of getting the BLC_EN
signal out of sync, preventing resume from working correctly. Scale
/sys/class/backlight at this level to prevent userspace from doing this
on suspend.
This gets rid of the explicitly hardcoded value for a previous/similar
patch. Instead relies on the VBT to provide the value, and if VBT does
not provide one, then it uses a hardcoded 5% min duty cycle. This was
defined a couple patches ago for the same fallback on VLV.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Wayne Boyer wayne.bo...@intel.com
Change-Id: Ibbbc8ef1659d0f797d6a33d3727a45ad95d5
Reviewed-on: https://chromium-review.googlesource.com/196609
Reviewed-by: Aaron Durbin adur...@chromium.org
Tested-by: Wayne Boyer wayne.bo...@intel.com
Commit-Queue: Wayne Boyer wayne.bo...@intel.com
Conflicts:
drivers/gpu/drm/i915/intel_panel.c
---
drivers/gpu/drm/i915/intel_panel.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index b3327d0..02248a5 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -576,11 +576,22 @@ void intel_panel_set_backlight(struct intel_connector
*connector, u32 level,
WARN_ON(panel-backlight.max == 0);
- /* scale to hardware max, but be careful to not overflow */
- freq = panel-backlight.max;
- n = (u64)level * freq;
- do_div(n, max);
- level = n;
+ /* XXX: we probably want to do this for all platforms. */
+ if (IS_VALLEYVIEW(dev)) {
+ /* It's always safe to use vbt values for VLV since we fake them
+* if they don't actually exist. */
+ const int min_duty =
(dev_priv-vbt.backlight.min_duty_cycle_percentage *
+
__vlv_calculate_mod_freq(dev_priv-vbt.backlight.pwm_freq_hz, true)) / 100;
+ BUG_ON(min_duty == 0);
+ /* linear conversion to new range */
+#define FIXED_POINT_SCALE 1000
+ level = ((level * FIXED_POINT_SCALE / max) * (max - min_duty) /
FIXED_POINT_SCALE) + min_duty;
+#undef FIXED_POINT_SCALE
+ } else if (freq max)
+ /* scale to hardware, but be careful to not overflow */
+ level = level * freq / max;
+ else
+ level = freq / max * level;
panel-backlight.level = level;
if (panel-backlight.device)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/11] CHROMIUM: drm/i915/vlv: Prefer VBT to set PWM
From: Ben Widawsky benjamin.widaw...@intel.com
This patch enables the VBT to override the PWM left in the BLC register,
or correct for VBIOS which doesn't program the BLC, with a VBT entry.
It kills the long hardcoded VLV_DEFAULT_BACKLIGHT_MOD_FREQ
As of the last patch, we always will have a default VBT value provided
in intel_bios.c
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Wayne Boyer wayne.bo...@intel.com
Change-Id: I4116d5fa21706e9e9ac85e41c43f7443964a822b
Reviewed-on: https://chromium-review.googlesource.com/196608
Reviewed-by: Aaron Durbin adur...@chromium.org
Tested-by: Wayne Boyer wayne.bo...@intel.com
Commit-Queue: Wayne Boyer wayne.bo...@intel.com
Conflicts:
drivers/gpu/drm/i915/intel_panel.c
---
drivers/gpu/drm/i915/intel_bios.h | 16
drivers/gpu/drm/i915/intel_panel.c | 30 --
2 files changed, 20 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 62cd658..b986677 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -408,22 +408,6 @@ struct bdb_lfp_backlight_data {
u8 level[16];
} __packed;
-struct bdb_lfp_backlight_data_entry {
- u8 type:2;
- u8 active_low_pwm:1;
- u8 obsolete1:5;
- u16 pwm_freq_hz;
- u8 min_brightness;
- u8 obsolete2;
- u8 obsolete3;
-} __packed;
-
-struct bdb_lfp_backlight_data {
- u8 entry_size;
- struct bdb_lfp_backlight_data_entry data[16];
- u8 level[16];
-} __packed;
-
struct aimdb_header {
char signature[16];
char oem_device[20];
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 02248a5..5270a08 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -418,6 +418,14 @@ static u32 intel_panel_compute_brightness(struct
intel_connector *connector,
return val;
}
+static u16 __vlv_calculate_mod_freq(u16 hz, bool s0ix)
+{
+ if (!s0ix)
+ return 1 / (128 * hz);
+ else
+ return 2500 / (16 * hz);
+}
+
static u32 bdw_get_backlight(struct intel_connector *connector)
{
struct drm_device *dev = connector-base.dev;
@@ -567,7 +575,6 @@ void intel_panel_set_backlight(struct intel_connector
*connector, u32 level,
enum pipe pipe = intel_get_pipe_from_connector(connector);
u32 freq;
unsigned long flags;
- u64 n;
if (!panel-backlight.present || pipe == INVALID_PIPE)
return;
@@ -1093,21 +1100,24 @@ static int vlv_setup_backlight(struct intel_connector
*connector)
for_each_pipe(pipe) {
u32 duty = I915_READ(VLV_BLC_PWM_CTL(pipe))
BACKLIGHT_DUTY_CYCLE_MASK;
u32 freq = I915_READ(VLV_BLC_PWM_CTL(pipe))
~BACKLIGHT_DUTY_CYCLE_MASK;
+ u32 vbt_val =
__vlv_calculate_mod_freq(dev_priv-vbt.backlight.pwm_freq_hz, true);
if (freq) {
- /* Skip if the modulation freq is already set */
- continue;
- }
-
- if (WARN_ON(pipe == PIPE_A)) {
- /* Assume BLC for pipe A is the default. Therefore, A
-* must be non-zero. */
- freq = (VLV_DEFAULT_BACKLIGHT_MOD_FREQ 16);
+ if (vbt_val != freq 16) {
+ DRM_DEBUG_KMS(reg doesn't match VBT value 0x%x
!= 0x%x\n,
+ freq 16, vbt_val);
+ freq = vbt_val 16;
+ } else
+ continue;
+ } else if (WARN_ON(pipe == PIPE_A)) {
+ /* VLV will always have a vbt value, fake or other. */
+ BUG_ON(IS_VALLEYVIEW(dev) !vbt_val);
+ freq = vbt_val 16;
} else
freq = I915_READ(VLV_BLC_PWM_CTL(PIPE_A))
~BACKLIGHT_DUTY_CYCLE_MASK;
if (WARN_ON(freq == 0))
- freq = (VLV_DEFAULT_BACKLIGHT_MOD_FREQ 16);
+ freq = vbt_val 16;
I915_WRITE(VLV_BLC_PWM_CTL(pipe), freq | duty);
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/11] CHROMIUM: drm/i915: change order of PWM enable vs BLC enable
From: Jesse Barnes jbar...@virtuousgeek.org Needed for spec compliance Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Signed-off-by: Wayne Boyer wayne.bo...@intel.com Change-Id: Ib09f64bdc44108c13bbe5a6ab8ab2f536360f8d2 Reviewed-on: https://chromium-review.googlesource.com/192469 Reviewed-by: Stéphane Marchesin marc...@chromium.org Reviewed-by: Aaron Durbin adur...@chromium.org Tested-by: Wayne Boyer wayne.bo...@intel.com Commit-Queue: Wayne Boyer wayne.bo...@intel.com Conflicts: drivers/gpu/drm/i915/intel_dp.c --- drivers/gpu/drm/i915/intel_dp.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 4f0fc11..f9becf8 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1410,6 +1410,8 @@ void intel_edp_backlight_on(struct intel_dp *intel_dp) assert_pwm_disabled(dev_priv, intel_dp-attached_connector); + intel_panel_enable_backlight(intel_dp-attached_connector); + /* * If we enable the backlight right away following a panel power * on, we may see slight flicker as the panel syncs with the eDP @@ -1447,10 +1449,10 @@ void intel_edp_backlight_off(struct intel_dp *intel_dp) I915_WRITE(pp_ctrl_reg, pp); POSTING_READ(pp_ctrl_reg); - intel_dp-last_backlight_off = jiffies; - edp_wait_backlight_off(intel_dp); + intel_dp-last_backlight_off = jiffies; + msleep(intel_dp-backlight_off_delay); intel_panel_disable_backlight(intel_dp-attached_connector); } -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/11] CHROMIUM: drm/i915: do not explicitly disable backlight in panel_off
From: Jesse Barnes jbar...@virtuousgeek.org Per eDP spec, we must disable the backlight in order to power down the panel. However, in our code, we have always disabled the backlight before we try to turn off the panel. The assertions from the previous patch make sure this is the case. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Signed-off-by: Wayne Boyer wayne.bo...@intel.com Change-Id: I68ae4ee80cee40aa4745697ce7acf3883ffb721d Reviewed-on: https://chromium-review.googlesource.com/194250 Reviewed-by: Stéphane Marchesin marc...@chromium.org Reviewed-by: Aaron Durbin adur...@chromium.org Tested-by: Wayne Boyer wayne.bo...@intel.com Commit-Queue: Wayne Boyer wayne.bo...@intel.com Conflicts: drivers/gpu/drm/i915/intel_dp.c --- drivers/gpu/drm/i915/intel_dp.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 90b24f6..9242499 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1371,8 +1371,7 @@ void intel_edp_panel_off(struct intel_dp *intel_dp) pp = ironlake_get_pp_control(intel_dp); /* We need to switch off panel power _and_ force vdd, for otherwise some * panels get very unhappy and cease to work. */ - pp = ~(POWER_TARGET_ON | PANEL_POWER_RESET | EDP_FORCE_VDD | - EDP_BLC_ENABLE); + pp = ~(POWER_TARGET_ON | EDP_FORCE_VDD | PANEL_POWER_RESET); pp_ctrl_reg = _pp_ctrl_reg(intel_dp); -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/11] CHROMIUM: drm/i915: use backlight wrapper functions instead of direct calls
From: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Wayne Boyer wayne.bo...@intel.com
BUG=chrome-os-partner:25159
TEST=suspend/resume test on instrumented system shows correct signaling
on oscope.
Conflicts:
drivers/gpu/drm/i915/intel_dp.c
Change-Id: Id736d39da630cdfb045b293772f5594576660c12
Reviewed-on: https://chromium-review.googlesource.com/192472
Reviewed-by: Stéphane Marchesin marc...@chromium.org
Reviewed-by: Aaron Durbin adur...@chromium.org
Tested-by: Wayne Boyer wayne.bo...@intel.com
Commit-Queue: Wayne Boyer wayne.bo...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c|2 +-
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_panel.c |2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9242499..e036da4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -375,7 +375,7 @@ static void assert_pwm(struct drm_i915_private *dev_priv,
{
bool state;
- state = dev_priv-display.get_backlight(connector);
+ state = intel_panel_get_backlight(connector);
WARN(state != expected_state, pwm state failure, expected %d, found
%d\n, expected_state, state);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ea137f4..4ce4aca 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -954,6 +954,7 @@ void intel_gmch_panel_fitting(struct intel_crtc *crtc,
int fitting_mode);
void intel_panel_set_backlight(struct intel_connector *connector, u32 level,
u32 max);
+u32 intel_panel_get_backlight(struct intel_connector *connector);
int intel_panel_setup_backlight(struct drm_connector *connector);
void intel_panel_enable_backlight(struct intel_connector *connector);
void intel_panel_disable_backlight(struct intel_connector *connector);
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 12b02fe..40e0cb08 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -470,7 +470,7 @@ static u32 vlv_get_backlight(struct intel_connector
*connector)
return _vlv_get_backlight(dev, pipe);
}
-static u32 intel_panel_get_backlight(struct intel_connector *connector)
+u32 intel_panel_get_backlight(struct intel_connector *connector)
{
struct drm_device *dev = connector-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/11] CHROMIUM: drm/i915/vlv: Initialize pipe B backlight to A's value
From: Ben Widawsky benjamin.widaw...@intel.com
Not sure if this is needed or not. The code still falls back to a
potentially bad value if PIPE_A was not set.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Wayne Boyer wayne.bo...@intel.com
Change-Id: I54eb5d4d9fd93e86878c9fa1daec19bdb6b3bd0b
Reviewed-on: https://chromium-review.googlesource.com/196605
Reviewed-by: Aaron Durbin adur...@chromium.org
Tested-by: Wayne Boyer wayne.bo...@intel.com
Commit-Queue: Wayne Boyer wayne.bo...@intel.com
Conflicts:
drivers/gpu/drm/i915/intel_panel.c
---
drivers/gpu/drm/i915/intel_panel.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 40e0cb08..b3327d0 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1080,15 +1080,24 @@ static int vlv_setup_backlight(struct intel_connector
*connector)
u32 ctl, ctl2, val;
for_each_pipe(pipe) {
- u32 cur_val = I915_READ(VLV_BLC_PWM_CTL(pipe));
+ u32 duty = I915_READ(VLV_BLC_PWM_CTL(pipe))
BACKLIGHT_DUTY_CYCLE_MASK;
+ u32 freq = I915_READ(VLV_BLC_PWM_CTL(pipe))
~BACKLIGHT_DUTY_CYCLE_MASK;
- /* Skip if the modulation freq is already set */
- if (cur_val ~BACKLIGHT_DUTY_CYCLE_MASK)
+ if (freq) {
+ /* Skip if the modulation freq is already set */
continue;
+ }
+
+ if (WARN_ON(pipe == PIPE_A)) {
+ /* Assume BLC for pipe A is the default. Therefore, A
+* must be non-zero. */
+ freq = (VLV_DEFAULT_BACKLIGHT_MOD_FREQ 16);
+ } else
+ freq = I915_READ(VLV_BLC_PWM_CTL(PIPE_A))
~BACKLIGHT_DUTY_CYCLE_MASK;
- cur_val = BACKLIGHT_DUTY_CYCLE_MASK;
- I915_WRITE(VLV_BLC_PWM_CTL(pipe), (0xf42 16) |
- cur_val);
+ if (WARN_ON(freq == 0))
+ freq = (VLV_DEFAULT_BACKLIGHT_MOD_FREQ 16);
+ I915_WRITE(VLV_BLC_PWM_CTL(pipe), freq | duty);
}
ctl2 = I915_READ(VLV_BLC_PWM_CTL2(PIPE_A));
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/11] CHROMIUM: drm/i915: parse backlight modulation frequency from the BIOS VBT
From: Jani Nikula jani.nik...@intel.com
We don't actually do anything with the information yet, but parse and
log what's in the VBT.
Signed-off-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
(cherry picked from commit f00076d2fd3fe25b2e8c83921818914dee37ffef)
Signed-off-by: Wayne Boyer wayne.bo...@intel.com
Change-Id: Ia3eb119069dfdb109f9c49a6d27f8d13ad8ba80a
Reviewed-on: https://chromium-review.googlesource.com/196606
Reviewed-by: Aaron Durbin adur...@chromium.org
Tested-by: Wayne Boyer wayne.bo...@intel.com
Commit-Queue: Wayne Boyer wayne.bo...@intel.com
Conflicts:
drivers/gpu/drm/i915/i915_drv.h
drivers/gpu/drm/i915/intel_bios.c
---
drivers/gpu/drm/i915/intel_bios.h | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index b986677..62cd658 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -408,6 +408,22 @@ struct bdb_lfp_backlight_data {
u8 level[16];
} __packed;
+struct bdb_lfp_backlight_data_entry {
+ u8 type:2;
+ u8 active_low_pwm:1;
+ u8 obsolete1:5;
+ u16 pwm_freq_hz;
+ u8 min_brightness;
+ u8 obsolete2;
+ u8 obsolete3;
+} __packed;
+
+struct bdb_lfp_backlight_data {
+ u8 entry_size;
+ struct bdb_lfp_backlight_data_entry data[16];
+ u8 level[16];
+} __packed;
+
struct aimdb_header {
char signature[16];
char oem_device[20];
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/11] CHROMIUM: drm/i915/vlv: Fix BLM_PWM_ENABLE check in pwm invariant
From: Kevin Strasser kevin.stras...@intel.com Misplaced paren causing test to always fail. BUG=chrome-os-partner:27096,chrome-os-partner:28914 TEST=Manual: Check that the screen immediately goes black at minimum brightness. Change-Id: If9d813ab4ef8cfd9c90f2183f1bb674172bdffe9 Signed-off-by: Kevin Strasser kevin.stras...@intel.com Reviewed-on: https://chromium-review.googlesource.com/200809 Reviewed-by: Stéphane Marchesin marc...@chromium.org Reviewed-by: Aaron Durbin adur...@chromium.org --- drivers/gpu/drm/i915/intel_dp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index f9becf8..3382459 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -377,7 +377,7 @@ static void assert_pwm(struct drm_i915_private *dev_priv, bool state; if (IS_VALLEYVIEW(dev_priv-dev) - !(I915_READ(VLV_BLC_PWM_CTL2(pipe) BLM_PWM_ENABLE))) + !(I915_READ(VLV_BLC_PWM_CTL2(pipe)) BLM_PWM_ENABLE)) state = false; else state = (intel_panel_get_backlight(connector) != 0); -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/11] CHROMIUM: drm/i915: Provide valleyview backlight fallback value
From: Ben Widawsky benjamin.widaw...@intel.com
The fallback values for VLV reflect the Rambi3 panel values.
This patch introduces min_brightness member, which defined a part of VBT
that has some confusion. The field itself is a byte ranging from 0-255.
How this value is supposed to be used by the driver is unclear. Though
no code uses it yet, I've written a comment explaining that I intend to
use the number in there as an absolute value that represents the minimum
duty cycle ratio of the panel.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Wayne Boyer wayne.bo...@intel.com
BUG=chrome-os-partner:25159
TEST=suspend/resume test on instrumented system shows correct
signaling on oscope. Manual brightness checks.
Change-Id: I9f0d8d4fe2778c4768b06459b0a83293b1c6f023
Reviewed-on: https://chromium-review.googlesource.com/196607
Reviewed-by: Aaron Durbin adur...@chromium.org
Tested-by: Wayne Boyer wayne.bo...@intel.com
Commit-Queue: Wayne Boyer wayne.bo...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 10 ++
drivers/gpu/drm/i915/intel_bios.c | 35 ++-
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 90216bb..1962024 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1261,6 +1261,16 @@ struct intel_vbt_data {
u16 pwm_freq_hz;
bool present;
bool active_low_pwm;
+
+ /* NB: We expect this to be an absolute value (percentage)
+* indicating the minimum duty cycle. This value is provided by
+* the panel spec, and should be provided in some way/shape/form
+* from VBIOS. It's unclear as of this point whether or not
+* this is the proper way.
+*
+* Example, 5 = 5% = .05
+*/
+ u8 min_duty_cycle_percentage;
} backlight;
/* MIPI DSI */
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 827498e..557338a 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -309,6 +309,20 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
}
}
+#define VLV_DEFAULT_MIN_DUTY_CYCLE_RATIO 5
+static void fake_vlv_backlight(struct drm_i915_private *dev_priv)
+{
+ dev_priv-vbt.backlight.pwm_freq_hz = 200;
+ dev_priv-vbt.backlight.active_low_pwm = 0;
+ dev_priv-vbt.backlight.min_duty_cycle_percentage =
VLV_DEFAULT_MIN_DUTY_CYCLE_RATIO;
+
+ DRM_DEBUG_KMS(VBT backlight PWM modulation frequency %u Hz,
+ active %s, min brightness %u\n,
+ dev_priv-vbt.backlight.pwm_freq_hz,
+ dev_priv-vbt.backlight.active_low_pwm ? low : high,
+ dev_priv-vbt.backlight.min_duty_cycle_percentage);
+}
+
static void
parse_lfp_backlight(struct drm_i915_private *dev_priv, struct bdb_header *bdb)
{
@@ -316,8 +330,10 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
struct bdb_header *bdb)
const struct bdb_lfp_backlight_data_entry *entry;
backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);
- if (!backlight_data)
+ if (!backlight_data IS_VALLEYVIEW(dev_priv-dev)) {
+ fake_vlv_backlight(dev_priv);
return;
+ }
if (backlight_data-entry_size != sizeof(backlight_data-data[0])) {
DRM_DEBUG_KMS(Unsupported backlight data entry size %u\n,
@@ -336,6 +352,23 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
struct bdb_header *bdb)
dev_priv-vbt.backlight.pwm_freq_hz = entry-pwm_freq_hz;
dev_priv-vbt.backlight.active_low_pwm = entry-active_low_pwm;
+
+ /* NB: It's probably safe to do this for !VLV platforms too. */
+ if (IS_VALLEYVIEW(dev_priv-dev) !entry-min_brightness)
+ dev_priv-vbt.backlight.min_duty_cycle_percentage =
VLV_DEFAULT_MIN_DUTY_CYCLE_RATIO;
+ else if (entry-min_brightness) {
+ /* Scale min_duty_cycle_percentage down to an absolute value */
+ u32 scaled_bright = entry-min_brightness;
+ u32 abs_bright = scaled_bright * 100 / 255;
+ DRM_DEBUG_KMS(Scaling VBT brightness from %d down to absolute
%d\n,
+ scaled_bright, abs_bright);
+ dev_priv-vbt.backlight.min_duty_cycle_percentage = abs_bright;
+ }
+
+ /* All platforms should have a PWM */
+ if (WARN_ON(!dev_priv-vbt.backlight.pwm_freq_hz))
+ dev_priv-vbt.backlight.pwm_freq_hz = 200;
+
DRM_DEBUG_KMS(VBT backlight PWM modulation frequency %u Hz,
active %s, min brightness %u, level %u\n,
dev_priv-vbt.backlight.pwm_freq_hz,
--
1.7.9.5
___
Intel-gfx mailing
[Intel-gfx] [PATCH 08/11] CHROMIUM: drm/i915/vlv: Check BLC enable for pwm invariant
From: Ben Widawsky benjamin.widaw...@intel.com
The new assertion code mandates that backlight should be disabled.
Since we've just bent over backwards over the last few patches to make
sure we don't program a 0 into duty cycle, we need some additional
checks to see if the panel is on. This can easily be accomplished by
checking the enable bit in the adjacent control register.
Based off of a patch originally written by Jesse.
Cc: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Wayne Boyer wayne.bo...@intel.com
BUG=chrome-os-partner:25159
TEST=suspend/resume test on instrumented system shows correct
signaling on oscope. Manual brightness checks.
Change-Id: I0aed561451ab6432c7b4d358821347189eece966
Reviewed-on: https://chromium-review.googlesource.com/196620
Reviewed-by: Aaron Durbin adur...@chromium.org
Tested-by: Wayne Boyer wayne.bo...@intel.com
Commit-Queue: Wayne Boyer wayne.bo...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e036da4..4f0fc11 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -373,9 +373,14 @@ static void assert_pwm(struct drm_i915_private *dev_priv,
struct intel_connector *connector,
bool expected_state)
{
+ enum pipe pipe = intel_get_pipe_from_connector(connector);
bool state;
- state = intel_panel_get_backlight(connector);
+ if (IS_VALLEYVIEW(dev_priv-dev)
+ !(I915_READ(VLV_BLC_PWM_CTL2(pipe) BLM_PWM_ENABLE)))
+ state = false;
+ else
+ state = (intel_panel_get_backlight(connector) != 0);
WARN(state != expected_state, pwm state failure, expected %d, found
%d\n, expected_state, state);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
