Re: [Intel-gfx] [alsa-devel] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
> > > > > > Shall we move or cc this discussion on audio driver side to ALSA ML? > > > > Oops I thought I had cc'ed these patches to alsa-devel as well when I sent them. > > > > > I think we also need to decide how to manage PCM devices for DP MST. > > > Now the HD-A driver create a PCM device for each pin, and the substream > > > number is 1 for each PCM. Now with DP MST enabled, each pin can support > > > multiple streams (e.g. 3 on Intel HSW/BDW/SKL). > > > > > > There may be 2 options: > > > -#1: Let an HDMI codec specify number of substreams, same as the number > > > of device entries on a pin. We can specify 3 for HSW/BDW/SKL. Other > > > vendors can also specify a value according to actual HW capabilities. > > > > > > So for HSW, we have 3x3 subtreams totally. But we only have 3 convertors > > > (for 3 display pipelines), so we can open up to 3 substreams at the same > > > time. When the audio driver finds all 3 convertors are used when opening > > > a new substream, it will fail. > > > > One thing I noticed is the number of devices on a PIN is only updated when > > the MST device is plugged in so normally pins 5,6,7 have 0 devices, and when > > I plug in MST device, I get the 3 devices on port 6. So it seems dynamic > > enough at this point, though I guess it'll always be 0 or 3. > > > > > > - #2: Create PCM device dynamically. Only create a PCM devices for a device > > > entry which connects to monitor with audio support. When the monitor > > > is removed, the PCM device will be disconnected, closed and removed, > > > similar to the USB case. Do the driver really need dynamic PCM since display ports are dasiy chained and the locations within the dasiy chain are fixed ? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [git pull] drm tree for 4.2
On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie wrote: > > This is the main drm pull request for v4.2. It seems to work ok for me, but it causes quite a few new warnings on my Sony VAIO Pro laptop. It's (once more) a regular i5-4200U CPU (aka Haswell, aka 4th gen Intel Core i5) Most of them are in check_crtc_state(), and I currently have 18 of these in my log: [drm:check_crtc_state [i915]] *ERROR* mismatch in dpll_hw_state.wrpll (expected 0x90280202, found 0x) WARNING: CPU: 0 PID: 115 at drivers/gpu/drm/i915/intel_display.c:12319 check_crtc_state+0x8be/0xf60 [i915]() pipe state doesn't match! but there's a few others too: WARNING: CPU: 3 PID: 1871 at drivers/gpu/drm/i915/intel_display.c:1362 hsw_disable_ips+0x34/0x160 [i915]() plane A assertion failure (expected on, current off) WARNING: CPU: 3 PID: 1871 at drivers/gpu/drm/drm_irq.c:1162 drm_wait_one_vblank+0x148/0x1a0 [drm]() vblank not available on crtc 0, ret=-22 and the backtraces aren't all that interesting, but I'm attaching the cleaned-up dmesg, duplicate callchains and all. Linus out Description: Binary data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix IPS related flicker
We cannot let IPS enabled with no plane on the pipe:
BSpec: "IPS cannot be enabled until after at least one plane has
been enabled for at least one vertical blank." and "IPS must be
disabled while there is still at least one plane enabled on the
same pipe as IPS." This restriction apply to HSW and BDW.
However a shortcut path on update primary plane function
to make primary plane invisible by setting DSPCTRL to 0
was leting IPS enabled while there was no
other plane enabled on the pipe causing flickerings that we were
believing that it was caused by that other restriction where
ips cannot be used when pixel rate is greater than 95% of cdclok.
v2: Don't mess with Atomic path as pointed out by Ville.
v3: Rebase after a long time and atomic path changes.
Accept Ville suggestion of not check !fb
v4: Re-factore on dinq
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=85583
Cc: Paulo Zanoni
Cc: Jani Nikula
Cc: Daniel Vetter
Reviewed-by: Ville Syrjälä
Tested-by: Kenneth Graunke
---
drivers/gpu/drm/i915/intel_display.c | 16 +++-
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 01eaab8..f87704a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4766,6 +4766,9 @@ static void intel_pre_plane_update(struct intel_crtc
*crtc)
mutex_unlock(&dev->struct_mutex);
}
+ if (intel_crtc->atomic.disable_ips)
+ hsw_disable_ips(intel_crtc);
+
if (atomic->pre_disable_primary)
intel_pre_disable_primary(&crtc->base);
}
@@ -11616,8 +11619,19 @@ int intel_plane_atomic_calc_changes(struct
drm_crtc_state *crtc_state,
intel_crtc->atomic.pre_disable_primary = turn_off;
intel_crtc->atomic.post_enable_primary = turn_on;
- if (turn_off)
+ if (turn_off) {
+ /*
+* FIXME: Actually if we will still have any other
+* plane enabled on the pipe we could let IPS enabled
+* still, but for now lets consider that when we make
+* primary invisible by setting DSPCNTR to 0 on
+* update_primary_plane function IPS needs to be
+* disable.
+*/
+ intel_crtc->atomic.disable_ips = true;
+
intel_crtc->atomic.disable_fbc = true;
+ }
/*
* FBC does not work on some platforms for rotated
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e016d72..33cff9d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -498,6 +498,7 @@ struct intel_crtc_atomic_commit {
/* Sleepable operations to perform before commit */
bool wait_for_flips;
bool disable_fbc;
+ bool disable_ips;
bool pre_disable_primary;
bool update_wm;
unsigned disabled_planes;
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] i965/gen9: Pass alignment as function parameter in drm_intel_gem_bo_alloc_internal()
On Thu, Jun 25, 2015 at 12:17 PM, Ben Widawsky wrote: > On Thu, Jun 25, 2015 at 07:11:21PM +0100, Chris Wilson wrote: >> On Thu, Jun 25, 2015 at 11:01:44AM -0700, Ben Widawsky wrote: >> > On Wed, Jun 24, 2015 at 08:28:13AM +0100, Chris Wilson wrote: >> > > On Tue, Jun 23, 2015 at 04:44:52PM -0700, Anuj Phogat wrote: >> > > > On Mon, Jun 22, 2015 at 1:04 PM, Chris Wilson >> > > > wrote: >> > > > > On Mon, Jun 22, 2015 at 09:51:08PM +0200, Daniel Vetter wrote: >> > > > >> On Mon, Jun 22, 2015 at 11:47:02AM -0700, Anuj Phogat wrote: >> > > > >> > and use it to initialize the align variable in drm_intel_bo. >> > > > >> > >> > > > >> > In case of YF/YS tiled buffers libdrm need not know about the >> > > > >> > tiling >> > > > >> > format because these buffers don't have hardware support to be >> > > > >> > tiled >> > > > >> > or detiled through a fenced region. But, libdrm still need to know >> > > > >> > about buffer alignment restrictions because kernel uses it when >> > > > >> > resolving the relocation. >> > > > >> > >> > > > >> > Mesa uses drm_intel_gem_bo_alloc_for_render() to allocate Yf/Ys >> > > > >> > buffers. >> > > > >> > So, use the passed alignment value in this function. Note that we >> > > > >> > continue >> > > > >> > ignoring the alignment value passed to drm_intel_gem_bo_alloc() >> > > > >> > to follow >> > > > >> > the previous behavior. >> > > > >> > >> > > > >> > V2: Add a condition to avoid allocation from cache. (Ben) >> > > > >> >> > > > >> This will hurt badly since some programs love to cycle through >> > > > >> textures. >> > > > >> You can still allocate from the cache, you only need to update the >> > > > >> alignement constraint. The kernel will move the buffer on the next >> > > > >> execbuf >> > > > >> if it's misplaced. >> > > > > >> > > > > For llc, using fresh pages just puts memory and aperture pressure >> > > > > (plus >> > > > > a small amount of interface pressure) on the system by allocating >> > > > > more bo. >> > > > > >> > > > > For !llc, it is far better to move an object in the GTT to match a >> > > > > change in alignment than it is to allocate fresh pages (and >> > > > > deallocate >> > > > > stale pages). >> > > > Could you please explain this and point me to what you want to be >> > > > changed in this patch? >> > > >> > > You can reuse the cached bo if the alignment mismatches. You can >> > > experiment with searching for a better match, but it's unlikely to be >> > > useful (numbers talk here). >> > >> > There's no "better" match, there's only match or no match. It seems pretty >> > intuitive to me that trying to find a match would be better though, I'm >> > curious why you think it's unlikely. Even though we don't specifically get >> > the >> > alignment back from the kernel after the relocation, we can certainly use >> > the >> > presumed offset as a guess when trying to find a buffer in the cache. >> >> I was thinking in terms of cycles saved, the cost of walking the cache >> for an exact match vs returning the first available buffer + the cost of >> any relocation, and whether there would be a measurable difference. I >> would have thought two patches, do the naive search that doesn't require >> any changes to the cached allocation strategy then a second >> demonstrating the perf improvement from being a bit smarter in buffer >> reuse would have been your ideal anyway. >> -Chris > > That's exactly what I suggested Anuj do :-) Thanks for helping me to find the right fix. I'll send out an updated patch doing the naive search with passed alignment and a new patch adding up the alignment in aperture size. >> >> -- >> Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/10] drm/i915: Zero unused WM1 watermarks on VLV/CHV
On 06/24/2015 12:00 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä The hardware supposedly ignores the WM1 watermarks while the PND deadline mode is enabled, but clear out the register just in case. This is what the other OS does, and it does make register dumps look more consistent when we don't have partial WM1 values lingering in the registers (some WM1 watermarks already get zeroed when the actually used DSPFW registers get written). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index c8e7ef3..dc8a9c9 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -927,6 +927,12 @@ static void vlv_write_wm_values(struct intel_crtc *crtc, FW_WM(wm->pipe[PIPE_A].primary >> 8, PLANEA_HI)); } + /* zero (unused) WM1 watermarks */ + I915_WRITE(DSPFW4, 0); + I915_WRITE(DSPFW5, 0); + I915_WRITE(DSPFW6, 0); + I915_WRITE(DSPHOWM1, 0); + POSTING_READ(DSPFW1); } Reviewed-by: Clint Taylor Tested-by: Clint Taylor ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/10] drm/i915: Use the memory latency based WM computation on VLV too
On 06/24/2015 12:00 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
In order to get decnet memory self refresh residency on VLV, flip it
over to the new CHV way of doing things. VLV doesn't do PM5 or DDR DVFS
so it's a bit simpler.
I'm not sure the currently memory latency used for CHV is really
appropriate for VLV. Some further testing will probably be needed to
figure that out.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 223 +--
drivers/gpu/drm/i915/intel_sprite.c | 6 -
3 files changed, 6 insertions(+), 225 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1424320..d67b5f1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15476,7 +15476,7 @@ void intel_modeset_setup_hw_state(struct drm_device
*dev,
pll->on = false;
}
- if (IS_CHERRYVIEW(dev))
+ if (IS_VALLEYVIEW(dev))
vlv_wm_get_hw_state(dev);
else if (IS_GEN9(dev))
skl_wm_get_hw_state(dev);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ffdca62..c7c90ce 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -931,77 +931,6 @@ static void vlv_write_wm_values(struct intel_crtc *crtc,
#undef FW_WM_VLV
-static uint8_t vlv_compute_drain_latency(struct drm_crtc *crtc,
-struct drm_plane *plane)
-{
- struct drm_device *dev = crtc->dev;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- int entries, prec_mult, drain_latency, pixel_size;
- int clock = intel_crtc->config->base.adjusted_mode.crtc_clock;
- const int high_precision = IS_CHERRYVIEW(dev) ? 16 : 64;
-
- /*
-* FIXME the plane might have an fb
-* but be invisible (eg. due to clipping)
-*/
- if (!intel_crtc->active || !plane->state->fb)
- return 0;
-
- if (WARN(clock == 0, "Pixel clock is zero!\n"))
- return 0;
-
- pixel_size = drm_format_plane_cpp(plane->state->fb->pixel_format, 0);
-
- if (WARN(pixel_size == 0, "Pixel size is zero!\n"))
- return 0;
-
- entries = DIV_ROUND_UP(clock, 1000) * pixel_size;
-
- prec_mult = high_precision;
- drain_latency = 64 * prec_mult * 4 / entries;
-
- if (drain_latency > DRAIN_LATENCY_MASK) {
- prec_mult /= 2;
- drain_latency = 64 * prec_mult * 4 / entries;
- }
-
- if (drain_latency > DRAIN_LATENCY_MASK)
- drain_latency = DRAIN_LATENCY_MASK;
-
- return drain_latency | (prec_mult == high_precision ?
- DDL_PRECISION_HIGH : DDL_PRECISION_LOW);
-}
-
-static int vlv_compute_wm(struct intel_crtc *crtc,
- struct intel_plane *plane,
- int fifo_size)
-{
- int clock, entries, pixel_size;
-
- /*
-* FIXME the plane might have an fb
-* but be invisible (eg. due to clipping)
-*/
- if (!crtc->active || !plane->base.state->fb)
- return 0;
-
- pixel_size = drm_format_plane_cpp(plane->base.state->fb->pixel_format,
0);
- clock = crtc->config->base.adjusted_mode.crtc_clock;
-
- entries = DIV_ROUND_UP(clock, 1000) * pixel_size;
-
- /*
-* Set up the watermark such that we don't start issuing memory
-* requests until we are within PND's max deadline value (256us).
-* Idea being to be idle as long as possible while still taking
-* advatange of PND's deadline scheduling. The limit of 8
-* cachelines (used when the FIFO will anyway drain in less time
-* than 256us) should match what we would be done if trickle
-* feed were enabled.
-*/
- return fifo_size - clamp(DIV_ROUND_UP(256 * entries, 64), 0, fifo_size
- 8);
-}
-
enum vlv_wm_level {
VLV_WM_LEVEL_PM2,
VLV_WM_LEVEL_PM5,
@@ -1076,101 +1005,6 @@ static uint16_t vlv_compute_wm_level(struct intel_plane
*plane,
return min_t(int, wm, USHRT_MAX);
}
-static bool vlv_compute_sr_wm(struct drm_device *dev,
- struct vlv_wm_values *wm)
-{
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct drm_crtc *crtc;
- enum pipe pipe = INVALID_PIPE;
- int num_planes = 0;
- int fifo_size = 0;
- struct intel_plane *plane;
-
- wm->sr.cursor = wm->sr.plane = 0;
-
- crtc = single_enabled_crtc(dev);
- /* maxfifo not supported on pipe C */
- if (crtc && to_intel_crtc(crtc)->pipe != PIPE_C) {
- pipe = to_intel_crtc(crtc)->pipe;
- num_planes = !!wm->pipe[pipe].primary +
- !!wm->pipe[pipe].sprite[0] +
- !!wm->pipe[pipe].
Re: [Intel-gfx] [PATCH 09/10] drm/i915: Add debugfs knobs for VLVCHV memory latency values
On 06/24/2015 12:00 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Allow tweaking the VLV/CHV memory latencies thorugh sysfs, like we do
for ILK+.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c49fe2a..656bb0d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4180,8 +4180,15 @@ static const struct file_operations
i915_displayport_test_type_fops = {
static void wm_latency_show(struct seq_file *m, const uint16_t wm[8])
{
struct drm_device *dev = m->private;
- int num_levels = ilk_wm_max_level(dev) + 1;
int level;
+ int num_levels;
+
+ if (IS_CHERRYVIEW(dev))
+ num_levels = 3;
+ else if (IS_VALLEYVIEW(dev))
+ num_levels = 1;
+ else
+ num_levels = ilk_wm_max_level(dev) + 1;
drm_modeset_lock_all(dev);
@@ -4190,9 +4197,9 @@ static void wm_latency_show(struct seq_file *m, const
uint16_t wm[8])
/*
* - WM1+ latency values in 0.5us units
-* - latencies are in us on gen9
+* - latencies are in us on gen9/vlv/chv
*/
- if (INTEL_INFO(dev)->gen >= 9)
+ if (INTEL_INFO(dev)->gen >= 9 || IS_VALLEYVIEW(dev))
latency *= 10;
else if (level > 0)
latency *= 5;
@@ -4256,7 +4263,7 @@ static int pri_wm_latency_open(struct inode *inode,
struct file *file)
{
struct drm_device *dev = inode->i_private;
- if (HAS_GMCH_DISPLAY(dev))
+ if (INTEL_INFO(dev)->gen < 5)
return -ENODEV;
return single_open(file, pri_wm_latency_show, dev);
@@ -4288,11 +4295,18 @@ static ssize_t wm_latency_write(struct file *file,
const char __user *ubuf,
struct seq_file *m = file->private_data;
struct drm_device *dev = m->private;
uint16_t new[8] = { 0 };
- int num_levels = ilk_wm_max_level(dev) + 1;
+ int num_levels;
int level;
int ret;
char tmp[32];
+ if (IS_CHERRYVIEW(dev))
+ num_levels = 3;
+ else if (IS_VALLEYVIEW(dev))
+ num_levels = 1;
+ else
+ num_levels = ilk_wm_max_level(dev) + 1;
+
if (len >= sizeof(tmp))
return -EINVAL;
Reviewed-by: Clint Taylor
Tested-by: Clint Taylor
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/10] drm/i915: Try to make sure cxsr is disabled around plane enable/disable
On 06/24/2015 12:00 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
CxSR (or maxfifo on VLV/CHV) blocks somne changes to the plane control
register (enable bit at least, not quite sure about the rest). So in
order to have the plane enable/disable when we want we need to first
kick the hardware out of cxsr.
Unfortunateloy this requires some extra vblank waits. For the CxSR
enable after the plane update we should eventually use an async
vblank worker, but since we don't have that just do sync vblank
waits. For the disable case we have no choice but to do it
synchronously.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 36 +++-
drivers/gpu/drm/i915/intel_drv.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 11 ---
3 files changed, 38 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d67b5f1..19aedf9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4716,6 +4716,9 @@ static void intel_post_plane_update(struct intel_crtc
*crtc)
intel_frontbuffer_flip(dev, atomic->fb_bits);
+ if (atomic->disable_cxsr)
+ crtc->wm.cxsr_allowed = true;
+
if (crtc->atomic.update_wm_post)
intel_update_watermarks(&crtc->base);
@@ -4765,6 +4768,11 @@ static void intel_pre_plane_update(struct intel_crtc
*crtc)
if (atomic->pre_disable_primary)
intel_pre_disable_primary(&crtc->base);
+
+ if (atomic->disable_cxsr) {
+ crtc->wm.cxsr_allowed = false;
+ intel_set_memory_cxsr(dev_priv, false);
+ }
}
static void intel_crtc_disable_planes(struct drm_crtc *crtc, unsigned
plane_mask)
@@ -11646,12 +11654,26 @@ int intel_plane_atomic_calc_changes(struct
drm_crtc_state *crtc_state,
plane->base.id, was_visible, visible,
turn_off, turn_on, mode_changed);
- if (turn_on)
+ if (turn_on) {
intel_crtc->atomic.update_wm_pre = true;
- else if (turn_off)
+ /* must disable cxsr around plane enable/disable */
+ if (plane->type != DRM_PLANE_TYPE_CURSOR) {
+ intel_crtc->atomic.disable_cxsr = true;
+ /* to potentially re-enable cxsr */
+ intel_crtc->atomic.wait_vblank = true;
+ intel_crtc->atomic.update_wm_post = true;
+ }
+ } else if (turn_off) {
intel_crtc->atomic.update_wm_post = true;
- else if (intel_wm_need_update(plane, plane_state))
+ /* must disable cxsr around plane enable/disable */
+ if (plane->type != DRM_PLANE_TYPE_CURSOR) {
+ if (is_crtc_enabled)
+ intel_crtc->atomic.wait_vblank = true;
+ intel_crtc->atomic.disable_cxsr = true;
+ }
+ } else if (intel_wm_need_update(plane, plane_state)) {
intel_crtc->atomic.update_wm_pre = true;
+ }
if (visible)
intel_crtc->atomic.fb_bits |=
@@ -11808,8 +11830,8 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
if (pipe_config->quirks & PIPE_CONFIG_QUIRK_INITIAL_PLANES)
intel_crtc_check_initial_planes(crtc, crtc_state);
- if (mode_changed)
- intel_crtc->atomic.update_wm_post = !crtc_state->active;
+ if (mode_changed && !crtc_state->active)
+ intel_crtc->atomic.update_wm_post = true;
if (mode_changed && crtc_state->enable &&
dev_priv->display.crtc_compute_clock &&
@@ -13129,6 +13151,8 @@ static int __intel_set_mode(struct drm_atomic_state
*state)
if (!needs_modeset(crtc->state))
continue;
+ intel_pre_plane_update(intel_crtc);
+
any_ms = true;
intel_pre_plane_update(intel_crtc);
@@ -14089,6 +14113,8 @@ static void intel_crtc_init(struct drm_device *dev, int
pipe)
intel_crtc->cursor_cntl = ~0;
intel_crtc->cursor_size = ~0;
+ intel_crtc->wm.cxsr_allowed = true;
+
BUG_ON(pipe >= ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) ||
dev_priv->plane_to_crtc_mapping[intel_crtc->plane] != NULL);
dev_priv->plane_to_crtc_mapping[intel_crtc->plane] = &intel_crtc->base;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f26a680..4e8d13e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -507,6 +507,7 @@ struct intel_crtc_atomic_commit {
/* Sleepable operations to perform before commit */
bool wait_for_flips;
bool disable_fbc;
+ bool disable_cxsr;
bool pre_disable_primary;
bool update_wm_pre, update_wm_post;
unsigned disabled_pla
Re: [Intel-gfx] [PATCH 05/10] drm/i915: Compute display FIFO split dynamically for CHV
On 06/24/2015 12:00 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Consider which planes are active and compute the FIFO split based on the
relative data rates. Since we only consider the pipe src width rather
than the plane width when computing watermarks it seems best to do the
same when computing the FIFO split as well. This means the only thing we
actually have to consider for the FIFO splut is the bpp, and we can
ignore the rest.
I've just stuffed the logic into the watermark code for now. Eventually
it'll need to move into the atomic update for the crtc.
There's also one extra complication I've not yet considered; Some of the
DSPARB registers contain bits related to multiple pipes. The registers
are double buffered but apparently they update on the vblank of any
active pipe. So doing the FIFO reconfiguration properly when multiple
pipes are active is not going to be fun. But let's ignore that mess for
now.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 25 +-
drivers/gpu/drm/i915/intel_pm.c | 175 +---
2 files changed, 189 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b9f6b8c..fa6780f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4411,9 +4411,32 @@ enum skl_disp_power_wells {
#define DSPARB_BSTART_SHIFT 0
#define DSPARB_BEND_SHIFT 9 /* on 855 */
#define DSPARB_AEND_SHIFT 0
-
+#define DSPARB_SPRITEA_SHIFT_VLV 0
+#define DSPARB_SPRITEA_MASK_VLV (0xff << 0)
+#define DSPARB_SPRITEB_SHIFT_VLV 8
+#define DSPARB_SPRITEB_MASK_VLV (0xff << 8)
+#define DSPARB_SPRITEC_SHIFT_VLV 16
+#define DSPARB_SPRITEC_MASK_VLV (0xff << 16)
+#define DSPARB_SPRITED_SHIFT_VLV 24
+#define DSPARB_SPRITED_MASK_VLV (0xff << 24)
#define DSPARB2 (VLV_DISPLAY_BASE + 0x70060) /* vlv/chv
*/
+#define DSPARB_SPRITEA_HI_SHIFT_VLV 0
+#define DSPARB_SPRITEA_HI_MASK_VLV (0x1 << 0)
+#define DSPARB_SPRITEB_HI_SHIFT_VLV 4
+#define DSPARB_SPRITEB_HI_MASK_VLV (0x1 << 4)
+#define DSPARB_SPRITEC_HI_SHIFT_VLV 8
+#define DSPARB_SPRITEC_HI_MASK_VLV (0x1 << 8)
+#define DSPARB_SPRITED_HI_SHIFT_VLV 12
+#define DSPARB_SPRITED_HI_MASK_VLV (0x1 << 12)
+#define DSPARB_SPRITEE_HI_SHIFT_VLV 16
+#define DSPARB_SPRITEE_HI_MASK_VLV (0x1 << 16)
+#define DSPARB_SPRITEF_HI_SHIFT_VLV 20
+#define DSPARB_SPRITEF_HI_MASK_VLV (0x1 << 20)
#define DSPARB3 (VLV_DISPLAY_BASE + 0x7006c) /* chv */
+#define DSPARB_SPRITEE_SHIFT_VLV 0
+#define DSPARB_SPRITEE_MASK_VLV (0xff << 0)
+#define DSPARB_SPRITEF_SHIFT_VLV 8
+#define DSPARB_SPRITEF_MASK_VLV (0xff << 8)
/* pnv/gen4/g4x/vlv/chv */
#define DSPFW1(dev_priv->info.display_mmio_offset +
0x70034)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d046e5f..ffdca62 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1171,6 +1171,73 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
dev_priv->wm.vlv = wm;
}
+static void vlv_compute_fifo(struct intel_crtc *crtc)
+{
+ struct drm_device *dev = crtc->base.dev;
+ struct vlv_wm_state *wm_state = &crtc->wm_state;
+ struct intel_plane *plane;
+ unsigned int total_rate = 0;
+ const int fifo_size = 512 - 1;
+ int fifo_extra, fifo_left = fifo_size;
+
+ for_each_intel_plane_on_crtc(dev, crtc, plane) {
+ struct intel_plane_state *state =
+ to_intel_plane_state(plane->base.state);
+
+ if (plane->base.type == DRM_PLANE_TYPE_CURSOR)
+ continue;
+
+ if (state->visible) {
+ wm_state->num_active_planes++;
+ total_rate +=
drm_format_plane_cpp(state->base.fb->pixel_format, 0);
+ }
+ }
+
+ for_each_intel_plane_on_crtc(dev, crtc, plane) {
+ struct intel_plane_state *state =
+ to_intel_plane_state(plane->base.state);
+ unsigned int rate;
+
+ if (plane->base.type == DRM_PLANE_TYPE_CURSOR) {
+ plane->wm.fifo_size = 63;
+ continue;
+ }
+
+ if (!state->visible) {
+ plane->wm.fifo_size = 0;
+ continue;
+ }
+
+ rate = drm_format_plane_cpp(state->base.fb->pixel_format, 0);
+ plane->wm.fifo_size = fifo_size * rate / total_rate;
+ fifo_left -= plane->wm.fifo_size;
+ }
+
+ fifo_extra = DIV_ROUND_UP(fifo_left, wm_state->num_active_planes ?: 1);
+
+ /* spread the remainder evenly */
+ for_each_intel_plane_on_crtc(dev, crtc, plane) {
+ int plane_extra;
+
+
Re: [Intel-gfx] [PATCH 08/10] drm/i915: Don't do PM5/DDR DVFS with multiple pipes
On 06/24/2015 12:00 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Enabling PM5/DDR DVFS with multiple active pipes isn't a validated
configuration. It does seem to work most of the time at least, but
there is clearly an additional risk of underruns, so let's not play
with fire.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b65817d..c8e7ef3 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1327,6 +1327,9 @@ static void vlv_merge_wm(struct drm_device *dev,
if (num_active_crtcs != 1)
wm->cxsr = false;
+ if (num_active_crtcs > 1)
+ wm->level = VLV_WM_LEVEL_PM2;
+
for_each_intel_crtc(dev, crtc) {
struct vlv_wm_state *wm_state = &crtc->wm_state;
enum pipe pipe = crtc->pipe;
Reviewed-by: Clint Taylor
Tested-by: Clint Taylor
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/10] drm/i915: Read wm values from hardware at init on CHV
On 06/24/2015 12:00 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Read out the current watermark settings from the hardware at driver init
time. This will allow us to compare the newly calculated values against
the currrent ones and potentially avoid needless WM updates.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_display.c | 4 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_pm.c | 141 +++
4 files changed, 148 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c3b9fcf..514adcf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1515,6 +1515,8 @@ struct vlv_wm_values {
uint8_t sprite[2];
uint8_t primary;
} ddl[3];
+ uint8_t level;
+ bool cxsr;
};
struct skl_ddb_entry {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1a1c686..b15d57f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15474,7 +15474,9 @@ void intel_modeset_setup_hw_state(struct drm_device
*dev,
pll->on = false;
}
- if (IS_GEN9(dev))
+ if (IS_CHERRYVIEW(dev))
+ vlv_wm_get_hw_state(dev);
+ else if (IS_GEN9(dev))
skl_wm_get_hw_state(dev);
else if (HAS_PCH_SPLIT(dev))
ilk_wm_get_hw_state(dev);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fefaf01..3673a71 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -582,6 +582,7 @@ struct intel_plane_wm_parameters {
bool scaled;
u64 tiling;
unsigned int rotation;
+ uint16_t fifo_size;
};
struct intel_plane {
@@ -1380,6 +1381,7 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv,
unsigned long submitted);
void intel_queue_rps_boost_for_request(struct drm_device *dev,
struct drm_i915_gem_request *req);
+void vlv_wm_get_hw_state(struct drm_device *dev);
void ilk_wm_get_hw_state(struct drm_device *dev);
void skl_wm_get_hw_state(struct drm_device *dev);
void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9706275..e67548d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1006,6 +1006,14 @@ static int vlv_compute_wm(struct intel_crtc *crtc,
return fifo_size - clamp(DIV_ROUND_UP(256 * entries, 64), 0, fifo_size
- 8);
}
+enum vlv_wm_level {
+ VLV_WM_LEVEL_PM2,
+ VLV_WM_LEVEL_PM5,
+ VLV_WM_LEVEL_DDR_DVFS,
+ CHV_WM_NUM_LEVELS,
+ VLV_WM_NUM_LEVELS = 1,
+};
+
static bool vlv_compute_sr_wm(struct drm_device *dev,
struct vlv_wm_values *wm)
{
@@ -3689,6 +3697,139 @@ static void ilk_pipe_wm_get_hw_state(struct drm_crtc
*crtc)
}
}
+#define _FW_WM(value, plane) \
+ (((value) & DSPFW_ ## plane ## _MASK) >> DSPFW_ ## plane ## _SHIFT)
+#define _FW_WM_VLV(value, plane) \
+ (((value) & DSPFW_ ## plane ## _MASK_VLV) >> DSPFW_ ## plane ## _SHIFT)
+
+static void vlv_read_wm_values(struct drm_i915_private *dev_priv,
+ struct vlv_wm_values *wm)
+{
+ enum pipe pipe;
+ uint32_t tmp;
+
+ for_each_pipe(dev_priv, pipe) {
+ tmp = I915_READ(VLV_DDL(pipe));
+
+ wm->ddl[pipe].primary =
+ (tmp >> DDL_PLANE_SHIFT) & (DDL_PRECISION_HIGH |
DRAIN_LATENCY_MASK);
+ wm->ddl[pipe].cursor =
+ (tmp >> DDL_CURSOR_SHIFT) & (DDL_PRECISION_HIGH |
DRAIN_LATENCY_MASK);
+ wm->ddl[pipe].sprite[0] =
+ (tmp >> DDL_SPRITE_SHIFT(0)) & (DDL_PRECISION_HIGH |
DRAIN_LATENCY_MASK);
+ wm->ddl[pipe].sprite[1] =
+ (tmp >> DDL_SPRITE_SHIFT(1)) & (DDL_PRECISION_HIGH |
DRAIN_LATENCY_MASK);
+ }
+
+ tmp = I915_READ(DSPFW1);
+ wm->sr.plane = _FW_WM(tmp, SR);
+ wm->pipe[PIPE_B].cursor = _FW_WM(tmp, CURSORB);
+ wm->pipe[PIPE_B].primary = _FW_WM_VLV(tmp, PLANEB);
+ wm->pipe[PIPE_A].primary = _FW_WM_VLV(tmp, PLANEA);
+
+ tmp = I915_READ(DSPFW2);
+ wm->pipe[PIPE_A].sprite[1] = _FW_WM_VLV(tmp, SPRITEB);
+ wm->pipe[PIPE_A].cursor = _FW_WM(tmp, CURSORA);
+ wm->pipe[PIPE_A].sprite[0] = _FW_WM_VLV(tmp, SPRITEA);
+
+ tmp = I915_READ(DSPFW3);
+ wm->sr.cursor = _FW_WM(tmp, CURSOR_SR);
+
+ if (IS_CHERRYVIEW(dev_priv)) {
+ tmp = I915_READ(DSPFW7_CHV);
+ wm->pipe[PIPE_B].sprite[1] = _FW_WM_VLV(tmp, SPRITED);
+ wm->pipe[PIPE_B].sprite[0] = _FW_WM_VLV(tmp, SPRITEC);
+
+
Re: [Intel-gfx] [PATCH 02/10] drm/i915: Split atomic wm update to pre and post variants
On 06/24/2015 12:00 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Try to update the watermarks on the right side of the plane update. This
is just a temporary hack until we get the proper two part update into
place. However in the meantime this might have some chance of at least
working.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
drivers/gpu/drm/i915/intel_drv.h | 2 +-
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 29c584c..1a1c686 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4713,6 +4713,9 @@ static void intel_post_plane_update(struct intel_crtc
*crtc)
intel_frontbuffer_flip(dev, atomic->fb_bits);
+ if (crtc->atomic.update_wm_post)
+ intel_update_watermarks(&crtc->base);
+
if (atomic->update_fbc) {
mutex_lock(&dev->struct_mutex);
intel_fbc_update(dev);
@@ -11641,8 +11644,12 @@ int intel_plane_atomic_calc_changes(struct
drm_crtc_state *crtc_state,
plane->base.id, was_visible, visible,
turn_off, turn_on, mode_changed);
- if (intel_wm_need_update(plane, plane_state))
- intel_crtc->atomic.update_wm = true;
+ if (turn_on)
+ intel_crtc->atomic.update_wm_pre = true;
+ else if (turn_off)
+ intel_crtc->atomic.update_wm_post = true;
+ else if (intel_wm_need_update(plane, plane_state))
+ intel_crtc->atomic.update_wm_pre = true;
if (visible)
intel_crtc->atomic.fb_bits |=
@@ -11800,7 +11807,7 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
intel_crtc_check_initial_planes(crtc, crtc_state);
if (mode_changed)
- intel_crtc->atomic.update_wm = !crtc_state->active;
+ intel_crtc->atomic.update_wm_post = !crtc_state->active;
if (mode_changed && crtc_state->enable &&
dev_priv->display.crtc_compute_clock &&
@@ -13729,7 +13736,7 @@ static void intel_begin_crtc_commit(struct drm_crtc
*crtc)
if (!needs_modeset(crtc->state))
intel_pre_plane_update(intel_crtc);
- if (intel_crtc->atomic.update_wm)
+ if (intel_crtc->atomic.update_wm_pre)
intel_update_watermarks(crtc);
intel_runtime_pm_get(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index de2cc26..fefaf01 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -499,7 +499,7 @@ struct intel_crtc_atomic_commit {
bool wait_for_flips;
bool disable_fbc;
bool pre_disable_primary;
- bool update_wm;
+ bool update_wm_pre, update_wm_post;
unsigned disabled_planes;
/* Sleepable operations to perform after commit */
Reviewed-by: Clint Taylor
Tested-by: Clint Taylor
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/10] drm/i915: POSTING_READ() in intel_set_memory_cxsr()
On 06/24/2015 12:00 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
We want cxsr exit to happen ASAP, so toss in some POSTING_READ()s to
make sure things are really kicked off.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 32ff034..9706275 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -334,22 +334,27 @@ void intel_set_memory_cxsr(struct drm_i915_private
*dev_priv, bool enable)
if (IS_VALLEYVIEW(dev)) {
I915_WRITE(FW_BLC_SELF_VLV, enable ? FW_CSPWRDWNEN : 0);
+ POSTING_READ(FW_BLC_SELF_VLV);
if (IS_CHERRYVIEW(dev))
chv_set_memory_pm5(dev_priv, enable);
} else if (IS_G4X(dev) || IS_CRESTLINE(dev)) {
I915_WRITE(FW_BLC_SELF, enable ? FW_BLC_SELF_EN : 0);
+ POSTING_READ(FW_BLC_SELF);
} else if (IS_PINEVIEW(dev)) {
val = I915_READ(DSPFW3) & ~PINEVIEW_SELF_REFRESH_EN;
val |= enable ? PINEVIEW_SELF_REFRESH_EN : 0;
I915_WRITE(DSPFW3, val);
+ POSTING_READ(DSPFW3);
} else if (IS_I945G(dev) || IS_I945GM(dev)) {
val = enable ? _MASKED_BIT_ENABLE(FW_BLC_SELF_EN) :
_MASKED_BIT_DISABLE(FW_BLC_SELF_EN);
I915_WRITE(FW_BLC_SELF, val);
+ POSTING_READ(FW_BLC_SELF);
} else if (IS_I915GM(dev)) {
val = enable ? _MASKED_BIT_ENABLE(INSTPM_SELF_EN) :
_MASKED_BIT_DISABLE(INSTPM_SELF_EN);
I915_WRITE(INSTPM, val);
+ POSTING_READ(INSTPM);
} else {
return;
}
Reviewed-by: Clint Taylor
Tested-by: Clint Taylor
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/10] drm/i915: CHV DDR DVFS support and another watermark rewrite
On 06/26/2015 12:48 PM, Ville Syrjälä wrote:
On Fri, Jun 26, 2015 at 10:56:33AM -0700, Clint Taylor wrote:
On 06/24/2015 12:00 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Turns out the VLV/CHV system agent doesn't understand memory
latencies, so trying to rely on the PND deadline mechanism is not
going to fly especially when DDR DVFS is enabled. Currently we try to
avoid the problems by lying to the system agent about the deadlines
and setting the FIFO watermarks to 8 cachelines. This however leads to
bad memory self refresh residency.
So in order to satosfy everyone we'll just give up on the deadline
scheme and program the watermarks old school based on the worst case
memory latency.
I've modelled this a bit on the ILK+ approach where we compute multiple
sets of watermarks for each pipe (PM2,PM5,DDR DVFS) and when merge thet
appropriate one later with the watermarks from other pipes. There isn't
too much to merge actually since each pipe has a totally independent
FIFO (well apart from the mess with the partially shared DSPARB
registers), but still decopuling the pipes from each other seems like a
good idea.
Eventually we'll want to perform the watermark update in two phases
around the plane update to avoid underruns due to the single buffered
watermark registers. But that's still in limbo for ILK+ too, so I've not
gone that far yet for VLV/CHV either.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 28 +--
drivers/gpu/drm/i915/intel_display.c | 6 +-
drivers/gpu/drm/i915/intel_drv.h | 11 ++
drivers/gpu/drm/i915/intel_pm.c | 318
++-
4 files changed, 345 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 514adcf..37cc653 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -276,6 +276,12 @@ struct i915_hotplug {
&dev->mode_config.plane_list,\
base.head)
+#define for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) \
+ list_for_each_entry(intel_plane,\
+ &(dev)->mode_config.plane_list, \
+ base.head) \
+ if ((intel_plane)->pipe == (intel_crtc)->pipe)
+
#define for_each_intel_crtc(dev, intel_crtc) \
list_for_each_entry(intel_crtc, &dev->mode_config.crtc_list, base.head)
@@ -1498,18 +1504,20 @@ struct ilk_wm_values {
enum intel_ddb_partitioning partitioning;
};
-struct vlv_wm_values {
- struct {
- uint16_t primary;
- uint16_t sprite[2];
- uint8_t cursor;
- } pipe[3];
+struct vlv_pipe_wm {
+ uint16_t primary;
+ uint16_t sprite[2];
+ uint8_t cursor;
+};
- struct {
- uint16_t plane;
- uint8_t cursor;
- } sr;
+struct vlv_sr_wm {
+ uint16_t plane;
+ uint8_t cursor;
+};
+struct vlv_wm_values {
+ struct vlv_pipe_wm pipe[3];
+ struct vlv_sr_wm sr;
struct {
uint8_t cursor;
uint8_t sprite[2];
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b15d57f..1424320 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4690,8 +4690,11 @@ intel_pre_disable_primary(struct drm_crtc *crtc)
* event which is after the vblank start event, so we need to have a
* wait-for-vblank between disabling the plane and the pipe.
*/
- if (HAS_GMCH_DISPLAY(dev))
+ if (HAS_GMCH_DISPLAY(dev)) {
intel_set_memory_cxsr(dev_priv, false);
+ dev_priv->wm.vlv.cxsr = false;
+ intel_wait_for_vblank(dev, pipe);
+ }
/*
* FIXME IPS should be fine as long as one plane is
@@ -6005,7 +6008,6 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc)
intel_crtc_load_lut(crtc);
- intel_update_watermarks(crtc);
intel_enable_pipe(intel_crtc);
assert_vblank_disabled(crtc);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3673a71..f26a680 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -462,6 +462,15 @@ struct intel_crtc_state {
enum pipe hsw_workaround_pipe;
};
+struct vlv_wm_state {
+ struct vlv_pipe_wm wm[3];
+ struct vlv_sr_wm sr[3];
+ uint8_t num_active_planes;
+ uint8_t num_levels;
+ uint8_t level;
+ bool cxsr;
+};
+
struct intel_pipe_wm {
struct intel_wm_level wm[5];
uint32_t linetime;
@@ -564,6 +573,8 @@ struct intel_crtc {
/* scalers available on this crtc */
int num_scalers;
+
+ struct vlv_wm_state wm_state;
};
struct intel_plane_wm_para
Re: [Intel-gfx] [PATCH] drm/i915: Unconditionally do fb tracking invalidate in set_domain
2015-06-26 14:35 GMT-03:00 Chris Wilson : > On Fri, Jun 26, 2015 at 07:35:16PM +0200, Daniel Vetter wrote: >> We can't elide the fb tracking invalidate if the buffer is already in >> the right domain since that would lead to missed screen updates. I'm >> pretty sure I've written this already before but must have gotten lost >> unfortunately :( >> >> v2: Chris observed that all internal set_domain users already >> correctly do the fb invalidate on their own, hence we can move this >> just into the set_domain ioctl instead. >> >> v3: I screwed up setting the invalidate ORIGIN_* correctly (Chris). >> >> Cc: Chris Wilson >> Reported-by: Paulo Zanoni >> Cc: Paulo Zanoni >> Signed-off-by: Daniel Vetter > > Reviewed-by: Chris Wilson > -Chris If you run: sudo ./kms_frontbuffer_tracking --psr-only --1p-only --use-small-modes Without the patch, you get 9 failures: Subtest psr-1p-pri-sfb-multidraw-mmap-gtt: FAIL (10.979s) Subtest psr-1p-pri-sfb-multidraw-mmap-wc: FAIL (10.982s) Subtest psr-1p-pri-sfb-multidraw-pwrite: FAIL (9.448s) Subtest psr-1p-cur-sfb-multidraw-mmap-gtt: FAIL (11.208s) Subtest psr-1p-cur-sfb-multidraw-mmap-wc: FAIL (11.171s) Subtest psr-1p-cur-sfb-multidraw-pwrite: FAIL (8.966s) Subtest psr-1p-spr-sfb-multidraw-mmap-gtt: FAIL (11.536s) Subtest psr-1p-spr-sfb-multidraw-mmap-wc: FAIL (11.439s) Subtest psr-1p-spr-sfb-multidraw-pwrite: FAIL (10.043s) With this patch, you get 0 failures \o/. The "multidraw" subtest alternates between drawing types. So multidraw-mmap-gtt will alternate between mmap-gtt and mmap-cpu, then mmap-gtt and mmap-wc, then mmap-gtt and pwrite, then mmap-gtt and blt, then mmap-gtt and render. Tested-by: Paulo Zanoni > > -- > Chris Wilson, Intel Open Source Technology Centre > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/10] drm/i915: CHV DDR DVFS support and another watermark rewrite
On Fri, Jun 26, 2015 at 10:56:33AM -0700, Clint Taylor wrote:
> On 06/24/2015 12:00 PM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Turns out the VLV/CHV system agent doesn't understand memory
> > latencies, so trying to rely on the PND deadline mechanism is not
> > going to fly especially when DDR DVFS is enabled. Currently we try to
> > avoid the problems by lying to the system agent about the deadlines
> > and setting the FIFO watermarks to 8 cachelines. This however leads to
> > bad memory self refresh residency.
> >
> > So in order to satosfy everyone we'll just give up on the deadline
> > scheme and program the watermarks old school based on the worst case
> > memory latency.
> >
> > I've modelled this a bit on the ILK+ approach where we compute multiple
> > sets of watermarks for each pipe (PM2,PM5,DDR DVFS) and when merge thet
> > appropriate one later with the watermarks from other pipes. There isn't
> > too much to merge actually since each pipe has a totally independent
> > FIFO (well apart from the mess with the partially shared DSPARB
> > registers), but still decopuling the pipes from each other seems like a
> > good idea.
> >
> > Eventually we'll want to perform the watermark update in two phases
> > around the plane update to avoid underruns due to the single buffered
> > watermark registers. But that's still in limbo for ILK+ too, so I've not
> > gone that far yet for VLV/CHV either.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 28 +--
> > drivers/gpu/drm/i915/intel_display.c | 6 +-
> > drivers/gpu/drm/i915/intel_drv.h | 11 ++
> > drivers/gpu/drm/i915/intel_pm.c | 318
> > ++-
> > 4 files changed, 345 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 514adcf..37cc653 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -276,6 +276,12 @@ struct i915_hotplug {
> > &dev->mode_config.plane_list, \
> > base.head)
> >
> > +#define for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) \
> > + list_for_each_entry(intel_plane,\
> > + &(dev)->mode_config.plane_list, \
> > + base.head) \
> > + if ((intel_plane)->pipe == (intel_crtc)->pipe)
> > +
> > #define for_each_intel_crtc(dev, intel_crtc) \
> > list_for_each_entry(intel_crtc, &dev->mode_config.crtc_list, base.head)
> >
> > @@ -1498,18 +1504,20 @@ struct ilk_wm_values {
> > enum intel_ddb_partitioning partitioning;
> > };
> >
> > -struct vlv_wm_values {
> > - struct {
> > - uint16_t primary;
> > - uint16_t sprite[2];
> > - uint8_t cursor;
> > - } pipe[3];
> > +struct vlv_pipe_wm {
> > + uint16_t primary;
> > + uint16_t sprite[2];
> > + uint8_t cursor;
> > +};
> >
> > - struct {
> > - uint16_t plane;
> > - uint8_t cursor;
> > - } sr;
> > +struct vlv_sr_wm {
> > + uint16_t plane;
> > + uint8_t cursor;
> > +};
> >
> > +struct vlv_wm_values {
> > + struct vlv_pipe_wm pipe[3];
> > + struct vlv_sr_wm sr;
> > struct {
> > uint8_t cursor;
> > uint8_t sprite[2];
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index b15d57f..1424320 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -4690,8 +4690,11 @@ intel_pre_disable_primary(struct drm_crtc *crtc)
> > * event which is after the vblank start event, so we need to have a
> > * wait-for-vblank between disabling the plane and the pipe.
> > */
> > - if (HAS_GMCH_DISPLAY(dev))
> > + if (HAS_GMCH_DISPLAY(dev)) {
> > intel_set_memory_cxsr(dev_priv, false);
> > + dev_priv->wm.vlv.cxsr = false;
> > + intel_wait_for_vblank(dev, pipe);
> > + }
> >
> > /*
> > * FIXME IPS should be fine as long as one plane is
> > @@ -6005,7 +6008,6 @@ static void valleyview_crtc_enable(struct drm_crtc
> > *crtc)
> >
> > intel_crtc_load_lut(crtc);
> >
> > - intel_update_watermarks(crtc);
> > intel_enable_pipe(intel_crtc);
> >
> > assert_vblank_disabled(crtc);
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 3673a71..f26a680 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -462,6 +462,15 @@ struct intel_crtc_state {
> > enum pipe hsw_workaround_pipe;
> > };
> >
> > +struct vlv_wm_state {
> > + struct vlv_pipe_wm wm[3];
> > + struct vlv_sr_wm sr[3];
> > + uint8_t num_active_planes;
> > + uint8_t num_levels;
> > + uint8_t level;
> > + bool cxsr;
> > +};
> > +
> > struct intel_pipe_wm {
>
Re: [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
On Fri, 2015-06-26 at 11:50 +0100, Kaskinen, Tanu wrote: > On Tue, 2015-06-23 at 10:51 +0300, Tanu Kaskinen wrote: > > (Added pulseaudio-discuss to CC.) > > > > On Mon, 2015-06-22 at 17:44 +0200, Takashi Iwai wrote: > > > At Mon, 22 Jun 2015 15:21:16 +, > > > Kaskinen, Tanu wrote: > > > > > > > > On Mon, 2015-06-22 at 14:29 +0100, Liam Girdwood wrote: > > > > > Btw, the topology core now also dynamically > > > > > creates/removes mixer controls, can PA handle this atm ? > > > > > > > > No, PA checks the mixer controls only when loading a new card. > > > > Dynamically added controls are ignored. Dynamically removed controls > > > > just cause silent failure, at least when setting volume (I didn't check > > > > other use cases). That is, changing the volume appears to succeed, but > > > > nothing actually happens. > > > > > > Won't PA use ELD or other information? The corresponding controls to > > > HDMI/DP will be created / deleted dynamically together with a PCM > > > device, I suppose. > > > > Yes, PA uses ELD. If mixer controls become dynamic too, then that's > > another thing to implement. > > Liam, how does the userspace know when the new PCM is ready to use? It's generally ready when the PCM is created iirc. > If > new mixer controls are added too, it has to be defined which gets > created first: the PCM device or the mixer controls. I think it would be > best if the mixer controls get created first, and when the new PCM > device appears, it's immediately fully ready to be used. > I agree, adding mixers first make sense. Liam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reserve space improvements
On 25/06/15 19:38, Tomas Elf wrote:
> On 24/06/2015 18:03, john.c.harri...@intel.com wrote:
>> From: John Harrison
>>
>> An earlier patch was added to reserve space in the ring buffer for the
>> commands issued during 'add_request()'. The initial version was
>> pessimistic in the way it handled buffer wrapping and would cause
>> premature wraps and thus waste ring space.
>>
>> This patch updates the code to better handle the wrap case. It no
>> longer enforces that the space being asked for and the reserved space
>> are a single contiguous block. Instead, it allows the reserve to be on
>> the far end of a wrap operation. It still guarantees that the space is
>> available so when the wrap occurs, no wait will happen. Thus the wrap
>> cannot fail which is the whole point of the exercise.
>>
>> Also fixed a merge failure with some comments from the original patch.
>>
>> For: VIZ-5115
>> CC: Daniel Vetter
>> Signed-off-by: John Harrison
>> ---
>> drivers/gpu/drm/i915/intel_lrc.c| 54 +---
>> drivers/gpu/drm/i915/intel_ringbuffer.c | 73
>> +
>> drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +-
>> 3 files changed, 79 insertions(+), 52 deletions(-)
[snip]
>> @@ -748,31 +749,36 @@ static int logical_ring_wrap_buffer(struct
>> drm_i915_gem_request *req)
>> static int logical_ring_prepare(struct drm_i915_gem_request *req,
>> int bytes)
>> {
>> struct intel_ringbuffer *ringbuf = req->ringbuf;
>> -int ret;
>> -
>> -/*
>> - * Add on the reserved size to the request to make sure that after
>> - * the intended commands have been emitted, there is guaranteed to
>> - * still be enough free space to send them to the hardware.
>> - */
>> -if (!ringbuf->reserved_in_use)
>> -bytes += ringbuf->reserved_size;
>> +int ret, max_bytes;
>>
>
> It would be helpful if we could flesh out the flow through the
> ring_prepare functions and be more explicit about what is actually going
> on. Largely this is because there is a distinct lack of documentation
> for the entire ring buffer management code on top of a quite
> counter-intuitive legacy design, so this is not due to your changes.
> However, your changes make things even more complex and hard to
> understand. So I've suggested a few comments below. Feel free to reword
> or do whatever with them. It would be nice if we could be slightly more
> clear about what is going on here, though. The same comments apply to
> both legacy and execlist function implementations obviously.
It would be simpler to understand if the unnecessary complication of
unlikely(wait-for-space-and-wrap) followed by unlikely(wait-for-space)
were simplified into a single process of "precalculate space required,
allowing for wrapping where necessary; wait for that much space; finally
fill the tail of the ring if we determined that wrapping was necessary".
This change can be applied before any of the complications of "reserving
space". See
http://lists.freedesktop.org/archives/intel-gfx/2015-June/068545.html
Secondly, a simpler way to implement "reserved space" is just to have
the "calculate remaining space" function intel_ring_space() deduct the
amount-reserved-for-add-request from its result UNLESS the
"use-reserved-space" flag has been set. It already deducts
I915_RING_FREE_SPACE, which represents the h/w limitation of the minimum
space required between tail and head, so conditionally deducting the
extra amount would be easy; then all other code could continue to use
the value it returns when checking for enough space. Nothing else would
have to know about "reserved space" at all.
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/10] drm/i915: CHV DDR DVFS support and another watermark rewrite
On 06/24/2015 12:00 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Turns out the VLV/CHV system agent doesn't understand memory
latencies, so trying to rely on the PND deadline mechanism is not
going to fly especially when DDR DVFS is enabled. Currently we try to
avoid the problems by lying to the system agent about the deadlines
and setting the FIFO watermarks to 8 cachelines. This however leads to
bad memory self refresh residency.
So in order to satosfy everyone we'll just give up on the deadline
scheme and program the watermarks old school based on the worst case
memory latency.
I've modelled this a bit on the ILK+ approach where we compute multiple
sets of watermarks for each pipe (PM2,PM5,DDR DVFS) and when merge thet
appropriate one later with the watermarks from other pipes. There isn't
too much to merge actually since each pipe has a totally independent
FIFO (well apart from the mess with the partially shared DSPARB
registers), but still decopuling the pipes from each other seems like a
good idea.
Eventually we'll want to perform the watermark update in two phases
around the plane update to avoid underruns due to the single buffered
watermark registers. But that's still in limbo for ILK+ too, so I've not
gone that far yet for VLV/CHV either.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 28 +--
drivers/gpu/drm/i915/intel_display.c | 6 +-
drivers/gpu/drm/i915/intel_drv.h | 11 ++
drivers/gpu/drm/i915/intel_pm.c | 318 ++-
4 files changed, 345 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 514adcf..37cc653 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -276,6 +276,12 @@ struct i915_hotplug {
&dev->mode_config.plane_list,\
base.head)
+#define for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) \
+ list_for_each_entry(intel_plane,\
+ &(dev)->mode_config.plane_list, \
+ base.head) \
+ if ((intel_plane)->pipe == (intel_crtc)->pipe)
+
#define for_each_intel_crtc(dev, intel_crtc) \
list_for_each_entry(intel_crtc, &dev->mode_config.crtc_list, base.head)
@@ -1498,18 +1504,20 @@ struct ilk_wm_values {
enum intel_ddb_partitioning partitioning;
};
-struct vlv_wm_values {
- struct {
- uint16_t primary;
- uint16_t sprite[2];
- uint8_t cursor;
- } pipe[3];
+struct vlv_pipe_wm {
+ uint16_t primary;
+ uint16_t sprite[2];
+ uint8_t cursor;
+};
- struct {
- uint16_t plane;
- uint8_t cursor;
- } sr;
+struct vlv_sr_wm {
+ uint16_t plane;
+ uint8_t cursor;
+};
+struct vlv_wm_values {
+ struct vlv_pipe_wm pipe[3];
+ struct vlv_sr_wm sr;
struct {
uint8_t cursor;
uint8_t sprite[2];
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b15d57f..1424320 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4690,8 +4690,11 @@ intel_pre_disable_primary(struct drm_crtc *crtc)
* event which is after the vblank start event, so we need to have a
* wait-for-vblank between disabling the plane and the pipe.
*/
- if (HAS_GMCH_DISPLAY(dev))
+ if (HAS_GMCH_DISPLAY(dev)) {
intel_set_memory_cxsr(dev_priv, false);
+ dev_priv->wm.vlv.cxsr = false;
+ intel_wait_for_vblank(dev, pipe);
+ }
/*
* FIXME IPS should be fine as long as one plane is
@@ -6005,7 +6008,6 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc)
intel_crtc_load_lut(crtc);
- intel_update_watermarks(crtc);
intel_enable_pipe(intel_crtc);
assert_vblank_disabled(crtc);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3673a71..f26a680 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -462,6 +462,15 @@ struct intel_crtc_state {
enum pipe hsw_workaround_pipe;
};
+struct vlv_wm_state {
+ struct vlv_pipe_wm wm[3];
+ struct vlv_sr_wm sr[3];
+ uint8_t num_active_planes;
+ uint8_t num_levels;
+ uint8_t level;
+ bool cxsr;
+};
+
struct intel_pipe_wm {
struct intel_wm_level wm[5];
uint32_t linetime;
@@ -564,6 +573,8 @@ struct intel_crtc {
/* scalers available on this crtc */
int num_scalers;
+
+ struct vlv_wm_state wm_state;
};
struct intel_plane_wm_parameters {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e67548d..d046e5f 100644
---
Re: [Intel-gfx] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control
On Fri, Jun 26, 2015 at 06:31:37PM +0200, Daniel Vetter wrote: > On Fri, Jun 26, 2015 at 02:32:03PM +0530, Shobhit Kumar wrote: > > Hi, > > Next update of the series reviewed at > > https://lkml.org/lkml/2015/6/22/155 > > > > Major changes are few review comments from Varka and Ville being addressed. > > Also except > > for intel-gfx patches, all patches reviesion history is moved out of commit > > message. > > > > Hope this series finally finds its mark. > > > > Regards > > Shobhit > > > > Shobhit Kumar (7): > > gpiolib: Add support for removing registered consumer lookup table > > mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO > > signal > > mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC > > mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM > > pwm: crc: Add Crystalcove (CRC) PWM driver > > drm/i915: Use the CRC gpio for panel enable/disable > > drm/i915: Backlight control using CRC PMIC based PWM driver > > I think we have r-b/acks on all the patches now. Ok if I pull this in > through drm-intel.git for 4.3? Or should I make a topic branch with tag > and then send out pull requests to everyone? Or will each maintainer merge > on their own since it's all only coupled at runtime anyway? Any of these > would suit me. I forgot to mention that I had a build failure due to builtin_platform_driver() when I tried this (just changed it to module_platform_driver() to get past it). So I'm not sure if this now depends on some tree which isn't included in -nightly... -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/skl: Skip remaining dividers when deviation is 0
On Fri, Jun 26, 2015 at 06:34:29PM +0100, Damien Lespiau wrote: > We can't improve a 0 deviation, so when we find such a divider, skip the > remaining ones they won't be better. > > This short-circuit the search for 34 of the 373 test frequencies in the > corresponding i-g-t test (tools/skl_compute_wrpll) > > v2: Place the short-circuiting code in skl_compute_wrpll() (Paulo) > > (I'm sure nobody will notice the spurious removal of a blank line) > > Reviewed-by: Paulo Zanoni > Suggested-by: Paulo Zanoni > Signed-off-by: Damien Lespiau Queued for -next, thanks for the patch. -Daniel > --- > drivers/gpu/drm/i915/intel_ddi.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > b/drivers/gpu/drm/i915/intel_ddi.c > index f6b3ccc..42c1487 100644 > --- a/drivers/gpu/drm/i915/intel_ddi.c > +++ b/drivers/gpu/drm/i915/intel_ddi.c > @@ -1149,7 +1149,6 @@ static void skl_wrpll_try_divider(struct > skl_wrpll_context *ctx, > ctx->dco_freq = dco_freq; > ctx->p = divider; > } > - > } > > static void skl_wrpll_get_multipliers(unsigned int p, > @@ -1315,9 +1314,17 @@ skl_ddi_calculate_wrpll(int clock /* in Hz */, > dco_central_freq[dco], > dco_freq, > p); > + /* > + * Skip the remaining dividers if we're sure to > + * have found the definitive divider, we can't > + * improve a 0 deviation. > + */ > + if (ctx.min_deviation == 0) > + goto skip_remaining_dividers; > } > } > > +skip_remaining_dividers: > /* >* If a solution is found with an even divider, prefer >* this one. > -- > 2.1.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/13 v2] drm/i915/skl: Prefer even dividers for SKL DPLLs
On Fri, Jun 26, 2015 at 02:08:30PM -0300, Paulo Zanoni wrote:
> 2015-06-25 12:19 GMT-03:00 Damien Lespiau :
> > Currently, if an odd divider improves the deviation (minimizes it), we
> > take that divider. The recommendation is to prefer even dividers.
> >
> > v2: Move the check at the right place after having inverted the two for
> > loops in the previous patch.
> >
> > Signed-off-by: Damien Lespiau
>
> Reviewed-by: Paulo Zanoni
Last two patches merged, thanks.
-Daniel
>
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 6e964ef..f6b3ccc 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1317,6 +1317,13 @@ skl_ddi_calculate_wrpll(int clock /* in Hz */,
> > p);
> > }
> > }
> > +
> > + /*
> > +* If a solution is found with an even divider, prefer
> > +* this one.
> > +*/
> > + if (d == 0 && ctx.p)
> > + break;
> > }
> >
> > if (!ctx.p) {
> > --
> > 2.1.0
> >
>
>
>
> --
> Paulo Zanoni
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 09/18] drm/i915: Cloned mode check
On Fri, Jun 26, 2015 at 06:14:07PM +0100, Chris Wilson wrote: > On Fri, Jun 26, 2015 at 07:08:40PM +0200, Daniel Vetter wrote: > > On Fri, Jun 26, 2015 at 07:21:53PM +0530, Ramalingam C wrote: > > > If crtc is in clone mode, DRRS will be disabled. Because if the both > > > the displays are not sharing the same vrefresh, then userspace > > > activities based on vsync will go for toss. > > > > > > Clone mode will be rechecked on every restarting Idleness DRRS events. > > > > > > Signed-off-by: Ramalingam C > > > --- > > > drivers/gpu/drm/i915/intel_drrs.c | 36 > > > +++- > > > 1 file changed, 35 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_drrs.c > > > b/drivers/gpu/drm/i915/intel_drrs.c > > > index e5d8bcd..42b420d 100644 > > > --- a/drivers/gpu/drm/i915/intel_drrs.c > > > +++ b/drivers/gpu/drm/i915/intel_drrs.c > > > @@ -16,6 +16,7 @@ > > > > > > #include > > > #include > > > +#include > > > > > > #include "i915_drv.h" > > > #include "intel_drv.h" > > > @@ -85,6 +86,31 @@ int get_free_drrs_struct_index(struct drm_i915_private > > > *dev_priv) > > > return -EBUSY; > > > } > > > > > > +/* > > > + * TODO: This is identifying the multiple active crtcs at a time. > > > + * Here we assume that this is clone state and disable DRRS. > > > + * But need to implement a proper method to find the real cloned mode > > > + * state. DRRS need not be disabled incase of multiple crtcs with > > > + * different content. > > > + */ > > > > This is a pretty big hack. Why do you need it? fb tracking should keep any > > display in the high mode as long as there's activity, so as long as > > userspace flips both buffers for both pipes (which is should for cloned > > mode) they'll both be running at max. > > It's simpler than than: cloned mode == 1 pipe, 1 framebuffer, 1 pageflip. > > Does having a vblank_ref count as activity? There is a large body of > code (like OML_sync_control) that assumes a fixed refresh rate for an > output. (Though OML_sync_control is vague about multiple monitor setups > and ignore mode changed altogether.) Atm we don't yet count vblank refcounts as activity, but would definitely make tons of sense. Problem is that drm_irq.c is a mess, so for the meantime I think we have to live with tuning the idleness timer of DRRS such that for most timing critical apps it's long enough for them not to notice the tricks we're playing. And yeah fixing up drm_irq.c is somewhere on my list too - I want a proper driver entry point for modeset drivers, where we could intercept vblank waits and everything as we see fit. Last piece of modern drm that's still midlayered (well ignoring that most drivers don't have a demidlayered driver init yet). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Unconditionally do fb tracking invalidate in set_domain
On Fri, Jun 26, 2015 at 07:35:16PM +0200, Daniel Vetter wrote: > We can't elide the fb tracking invalidate if the buffer is already in > the right domain since that would lead to missed screen updates. I'm > pretty sure I've written this already before but must have gotten lost > unfortunately :( > > v2: Chris observed that all internal set_domain users already > correctly do the fb invalidate on their own, hence we can move this > just into the set_domain ioctl instead. > > v3: I screwed up setting the invalidate ORIGIN_* correctly (Chris). > > Cc: Chris Wilson > Reported-by: Paulo Zanoni > Cc: Paulo Zanoni > Signed-off-by: Daniel Vetter Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/skl: Skip remaining dividers when deviation is 0
We can't improve a 0 deviation, so when we find such a divider, skip the remaining ones they won't be better. This short-circuit the search for 34 of the 373 test frequencies in the corresponding i-g-t test (tools/skl_compute_wrpll) v2: Place the short-circuiting code in skl_compute_wrpll() (Paulo) (I'm sure nobody will notice the spurious removal of a blank line) Reviewed-by: Paulo Zanoni Suggested-by: Paulo Zanoni Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/intel_ddi.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index f6b3ccc..42c1487 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -1149,7 +1149,6 @@ static void skl_wrpll_try_divider(struct skl_wrpll_context *ctx, ctx->dco_freq = dco_freq; ctx->p = divider; } - } static void skl_wrpll_get_multipliers(unsigned int p, @@ -1315,9 +1314,17 @@ skl_ddi_calculate_wrpll(int clock /* in Hz */, dco_central_freq[dco], dco_freq, p); + /* +* Skip the remaining dividers if we're sure to +* have found the definitive divider, we can't +* improve a 0 deviation. +*/ + if (ctx.min_deviation == 0) + goto skip_remaining_dividers; } } +skip_remaining_dividers: /* * If a solution is found with an even divider, prefer * this one. -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Unconditionally do fb tracking invalidate in set_domain
We can't elide the fb tracking invalidate if the buffer is already in the right domain since that would lead to missed screen updates. I'm pretty sure I've written this already before but must have gotten lost unfortunately :( v2: Chris observed that all internal set_domain users already correctly do the fb invalidate on their own, hence we can move this just into the set_domain ioctl instead. v3: I screwed up setting the invalidate ORIGIN_* correctly (Chris). Cc: Chris Wilson Reported-by: Paulo Zanoni Cc: Paulo Zanoni Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_gem.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index f79ce9f22312..dbc93703e280 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1614,6 +1614,11 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void *data, else ret = i915_gem_object_set_to_cpu_domain(obj, write_domain != 0); + if (write_domain != 0) + intel_fb_obj_invalidate(obj, + write_domain == I915_GEM_DOMAIN_GTT ? + ORIGIN_GTT : ORIGIN_CPU); + unref: drm_gem_object_unreference(&obj->base); unlock: @@ -3982,9 +3987,6 @@ i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write) obj->dirty = 1; } - if (write) - intel_fb_obj_invalidate(obj, ORIGIN_GTT); - trace_i915_gem_object_change_domain(obj, old_read_domains, old_write_domain); @@ -4256,9 +4258,6 @@ i915_gem_object_set_to_cpu_domain(struct drm_i915_gem_object *obj, bool write) obj->base.write_domain = I915_GEM_DOMAIN_CPU; } - if (write) - intel_fb_obj_invalidate(obj, ORIGIN_CPU); - trace_i915_gem_object_change_domain(obj, old_read_domains, old_write_domain); -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/18] drm/i915/gtt: Fill scratch page
On 25/06/15 18:51, Chris Wilson wrote: > On Thu, Jun 25, 2015 at 06:35:14PM +0300, Mika Kuoppala wrote: >> During review of dynamic page tables series, I was able >> to hit a lite restore bug with execlists. I assume that >> due to incorrect pd, the batch run out of legit address space >> and into the scratch page area. The ACTHD was increasing >> due to scratch being all zeroes (MI_NOOPs). And as gen8 >> address space is quite large, the hangcheck happily waited >> for a long long time, keeping the process effectively stuck. >> >> According to Chris Wilson any modern gpu will grind to halt >> if it encounters commands of all ones. This seemed to do the >> trick and hang was declared promptly when the gpu wandered into >> the scratch land. >> >> v2: Use 0x00ff pattern (Chris) > > Thinking about this, could we add a scratch page checker to hangcheck? > Just check the first/last u64 perhaps? Or random offset_in_page? > -Chris I've suggested to Tomas that when running in 32-bit PPGTT mode, if ACTHD is >4G then it's definitely broken. Doesn't help much once PPGTT space expands to 48b though. .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Adding custom bugzilla fields
On Fri, Jun 26, 2015 at 06:23:39PM +0100, Chris Wilson wrote: > On Fri, Jun 26, 2015 at 07:05:20PM +0200, Daniel Vetter wrote: > > Maybe we need a bit more polish, but probably not worth it to spend too > > much time on the exact feature list. If we spot serious gaps we can always > > add more. And remove old ones which have gone out of favour (having that > > script handy somewhere would be good). > > That's the big one where just being strict about using summary keywords > pays off - flexibility. From pov, I like the summary keywords as that is > shown in the search window - so if custom fields are introduced, I want > them visible in the results list. Yeah visibility in search results was my big concern too. That's why I asked Ander to merge the 3 areas into one, since otherwise the search result page looks super wasteful. It can be shown by just adding more default fields. Flexibility is another one, but the problem we have with rotating different people through bug duty is that without a list we don't have that consistency - heck even QA engineers fail to be consistent with platform tags. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: In DBUF/WM calcs for 90/270, swap w & h
On Fri, Jun 26, 2015 at 06:53:49AM -0700, Chandra Konduru wrote:
> This patch swaps src width and height for dbuf/wm calculations
> when rotation is 90/270 as per hw requirements.
>
> Signed-off-by: Chandra Konduru
Do we have an igt which provokes underruns and hence can test this
automatically? Very tall/narrow buffers should do it I think.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_pm.c | 32
> 1 file changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ea3e435..767313b 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2913,6 +2913,8 @@ static void skl_compute_wm_pipe_parameters(struct
> drm_crtc *crtc,
> enum pipe pipe = intel_crtc->pipe;
> struct drm_plane *plane;
> struct drm_framebuffer *fb;
> + struct intel_plane_state *plane_state;
> + int src_w, src_h;
> int i = 1; /* Index for sprite planes start */
>
> p->active = intel_crtc->active;
> @@ -2921,6 +2923,7 @@ static void skl_compute_wm_pipe_parameters(struct
> drm_crtc *crtc,
> p->pixel_rate = skl_pipe_pixel_rate(intel_crtc->config);
>
> fb = crtc->primary->state->fb;
> + plane_state = to_intel_plane_state(crtc->primary->state);
> /* For planar: Bpp is for uv plane, y_Bpp is for y plane */
> if (fb) {
> p->plane[0].enabled = true;
> @@ -2935,8 +2938,22 @@ static void skl_compute_wm_pipe_parameters(struct
> drm_crtc *crtc,
> p->plane[0].y_bytes_per_pixel = 0;
> p->plane[0].tiling = DRM_FORMAT_MOD_NONE;
> }
> - p->plane[0].horiz_pixels = intel_crtc->config->pipe_src_w;
> - p->plane[0].vert_pixels = intel_crtc->config->pipe_src_h;
> +
> + if (drm_rect_width(&plane_state->src)) {
> + src_w = drm_rect_width(&plane_state->src) >> 16;
> + src_h = drm_rect_height(&plane_state->src) >> 16;
> + } else {
> + src_w = intel_crtc->config->pipe_src_w;
> + src_h = intel_crtc->config->pipe_src_h;
> + }
> +
> + if (intel_rotation_90_or_270(crtc->primary->state->rotation)) {
> + p->plane[0].horiz_pixels = src_h;
> + p->plane[0].vert_pixels = src_w;
> + } else {
> + p->plane[0].horiz_pixels = src_w;
> + p->plane[0].vert_pixels = src_h;
> + }
> p->plane[0].rotation = crtc->primary->state->rotation;
>
> fb = crtc->cursor->state->fb;
> @@ -3468,8 +3485,15 @@ skl_update_sprite_wm(struct drm_plane *plane, struct
> drm_crtc *crtc,
>
> intel_plane->wm.enabled = enabled;
> intel_plane->wm.scaled = scaled;
> - intel_plane->wm.horiz_pixels = sprite_width;
> - intel_plane->wm.vert_pixels = sprite_height;
> +
> + if (intel_rotation_90_or_270(plane->state->rotation)) {
> + intel_plane->wm.horiz_pixels = sprite_height;
> + intel_plane->wm.vert_pixels = sprite_width;
> + } else {
> + intel_plane->wm.horiz_pixels = sprite_width;
> + intel_plane->wm.vert_pixels = sprite_height;
> + }
> +
> intel_plane->wm.tiling = DRM_FORMAT_MOD_NONE;
>
> /* For planar: Bpp is for UV plane, y_Bpp is for Y plane */
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Adding custom bugzilla fields
On Fri, Jun 26, 2015 at 07:05:20PM +0200, Daniel Vetter wrote: > Maybe we need a bit more polish, but probably not worth it to spend too > much time on the exact feature list. If we spot serious gaps we can always > add more. And remove old ones which have gone out of favour (having that > script handy somewhere would be good). That's the big one where just being strict about using summary keywords pays off - flexibility. From pov, I like the summary keywords as that is shown in the search window - so if custom fields are introduced, I want them visible in the results list. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: Skip remaining dividers when deviation is 0
On Fri, Jun 26, 2015 at 02:18:39PM -0300, Paulo Zanoni wrote: > > @@ -1311,13 +1320,15 @@ skl_ddi_calculate_wrpll(int clock /* in Hz */, > > unsigned int p = dividers[d].list[i]; > > uint64_t dco_freq = p * afe_clock; > > > > - skl_wrpll_try_divider(&ctx, > > - dco_central_freq[dco], > > - dco_freq, > > - p); > > + if (skl_wrpll_try_divider(&ctx, > > + > > dco_central_freq[dco], > > + dco_freq, > > + p)) > > + goto skip_remaining_dividers; > > Bikeshed: instead of touching skl_wrpll_try_divider(), you could just: > > if (ctx.min_deviation == 0) goto skip_remaining_dividers; > > That would keep the logic of the optimization restricted to this > function. IMHO, much simpler. > > With or without changes: Reviewed-by: Paulo Zanoni I like that, v2 it is! -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Interrupt driven fences
On Fri, Jun 26, 2015 at 06:00:03PM +0100, John Harrison wrote: > On 26/06/2015 14:34, Chris Wilson wrote: > >On Fri, Jun 26, 2015 at 01:58:11PM +0100, john.c.harri...@intel.com wrote: > >>From: John Harrison > >> > >>The intended usage model for struct fence is that the signalled status > >>should be > >>set on demand rather than polled. That is, there should not be a need for a > >>'signaled' function to be called everytime the status is queried. Instead, > >>'something' should be done to enable a signal callback from the hardware > >>which > >>will update the state directly. In the case of requests, this is the seqno > >>update interrupt. The idea is that this callback will only be enabled on > >>demand > >>when something actually tries to wait on the fence. > >> > >>This change removes the polling test and replaces it with the callback > >>scheme. > >>Each fence is added to a 'please poke me' list at the start of > >>i915_add_request(). The interrupt handler then scans through the 'poke me' > >>list > >>when a new seqno pops out and signals any matching fence/request. The fence > >>is > >>then removed from the list so the entire request stack does not need to be > >>scanned every time. Note that the fence is added to the list before the > >>commands > >>to generate the seqno interrupt are added to the ring. Thus the sequence is > >>guaranteed to be race free if the interrupt is already enabled. > >> > >>One complication here is that the 'poke me' system requires holding a > >>reference > >>count on the request to guarantee that it won't be freed prematurely. > >>Unfortunately, it is unsafe to decrement the reference count from the > >>interrupt > >>handler because if that is the last reference, the clean up code gets run > >>and > >>the clean up code is not IRQ friendly. Hence, the request is added to a > >>'please > >>clean me' list that gets processed at retire time. Any request in this list > >>simply has its count decremented and is then removed from that list. > >> > >>Note that the interrupt is only enabled on demand (i.e. when > >>__wait_request() is > >>called). Thus there is still a potential race when enabling the interrupt > >>as the > >>request may already have completed. However, this is simply solved by > >>calling > >>the interrupt processing code immediately after enabling the interrupt and > >>thereby checking for already completed requests. > >> > >>Lastly, the ring clean up code has the possibility to cancel outstanding > >>requests (e.g. because TDR has reset the ring). These requests will never > >>get > >>signalled and so must be removed from the signal list manually. This is > >>done by > >>setting a 'cancelled' flag and then calling the regular notify/retire code > >>path > >>rather than attempting to duplicate the list manipulatation and clean up > >>code in > >>multiple places. This also avoid any race condition where the cancellation > >>request might occur after/during the completion interrupt actually arriving. > >-nightly nop: > >Time to exec x 1:15.000µs (ring=render) > >Time to exec x 1: 2.000µs (ring=blt) > >Time to exec x 131072:1.827µs (ring=render) > >Time to exec x 131072:1.555µs (ring=blt) > > > >rq tuning patches nop: > >Time to exec x 1: 12.200µs (ring=render) > >Time to exec x 1: 1.600µs (ring=blt) > >Time to exec x 131072: 1.516µs (ring=render) > >Time to exec x 131072: 0.812µs (ring=blt) > > > >interrupt driven nop: > >Time to exec x 1: 19.200µs (ring=render) > >Time to exec x 1: 5.200µs (ring=blt) > >Time to exec x 131072: 2.381µs (ring=render) > >Time to exec x 131072: 2.009µs (ring=blt) > > > >So the basic question that is left unanswered from last time is why > >would we want to slow down __i915_wait_request? And enabling IRQs still > >generates very high system load when processing the 30-40k IRQs per > >second found under some workloads. > >-Chris > > > As previously stated, the scheduler requires enabling interrupts for > each batch buffer as it needs to know when something more needs > sending to the hardware. Android requires enabling interrupts for > each batch buffer as it uses the sync framework to wait on batch > buffer completion asynchronously to the driver (i.e. without calling > __i915_wait_request or any other driver code). I presume much of the > slow down to wait_request itself is because it has to check for > missed interrupts. It should be possible to optimise that somewhat > although it was completely unnecessary in the original version as > you can't miss interrupts if they are always on. That discussion is missing from the changelog, which is where any discussion addressing review should be if not acted upon, and very much misses why we should be introducing regressions. > How do you get consistent results from gem_exec_nop? For the x1 > case, I see
Re: [Intel-gfx] [PATCH] drm/i915/skl: Skip remaining dividers when deviation is 0
2015-06-25 14:08 GMT-03:00 Damien Lespiau :
> We can't improve a 0 deviation, so when we find such a divider, skip the
> remaining ones they won't be better.
>
> This short-circuit the search for 34 of the 373 test frequencies in the
> corresponding i-g-t test (tools/skl_compute_wrpll)
>
> Suggested-by: Paulo Zanoni
> Signed-off-by: Damien Lespiau
> ---
> This patch has to be applied after patch 12 and 13 for the recent SKL DPLL
> series.
>
> drivers/gpu/drm/i915/intel_ddi.c | 21 -
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index f6b3ccc..45116d8 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1122,7 +1122,11 @@ static void skl_wrpll_context_init(struct
> skl_wrpll_context *ctx)
> #define SKL_DCO_MAX_PDEVIATION 100
> #define SKL_DCO_MAX_NDEVIATION 600
>
> -static void skl_wrpll_try_divider(struct skl_wrpll_context *ctx,
> +/*
> + * Returns true if we're sure to have found the definitive divider (ie
> + * deviation == 0).
> + */
> +static bool skl_wrpll_try_divider(struct skl_wrpll_context *ctx,
> uint64_t central_freq,
> uint64_t dco_freq,
> unsigned int divider)
> @@ -1141,6 +1145,10 @@ static void skl_wrpll_try_divider(struct
> skl_wrpll_context *ctx,
> ctx->dco_freq = dco_freq;
> ctx->p = divider;
> }
> +
> + /* we can't improve a 0 deviation */
> + if (deviation == 0)
> + return true;
Took me a while to understand why this was exactly here :)
> /* negative deviation */
> } else if (deviation < SKL_DCO_MAX_NDEVIATION &&
>deviation < ctx->min_deviation) {
> @@ -1150,6 +1158,7 @@ static void skl_wrpll_try_divider(struct
> skl_wrpll_context *ctx,
> ctx->p = divider;
> }
>
> + return false;
> }
>
> static void skl_wrpll_get_multipliers(unsigned int p,
> @@ -1311,13 +1320,15 @@ skl_ddi_calculate_wrpll(int clock /* in Hz */,
> unsigned int p = dividers[d].list[i];
> uint64_t dco_freq = p * afe_clock;
>
> - skl_wrpll_try_divider(&ctx,
> - dco_central_freq[dco],
> - dco_freq,
> - p);
> + if (skl_wrpll_try_divider(&ctx,
> +
> dco_central_freq[dco],
> + dco_freq,
> + p))
> + goto skip_remaining_dividers;
Bikeshed: instead of touching skl_wrpll_try_divider(), you could just:
if (ctx.min_deviation == 0) goto skip_remaining_dividers;
That would keep the logic of the optimization restricted to this
function. IMHO, much simpler.
With or without changes: Reviewed-by: Paulo Zanoni
> }
> }
>
> +skip_remaining_dividers:
> /*
> * If a solution is found with an even divider, prefer
> * this one.
> --
> 2.1.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 09/18] drm/i915: Cloned mode check
On Fri, Jun 26, 2015 at 07:08:40PM +0200, Daniel Vetter wrote: > On Fri, Jun 26, 2015 at 07:21:53PM +0530, Ramalingam C wrote: > > If crtc is in clone mode, DRRS will be disabled. Because if the both > > the displays are not sharing the same vrefresh, then userspace > > activities based on vsync will go for toss. > > > > Clone mode will be rechecked on every restarting Idleness DRRS events. > > > > Signed-off-by: Ramalingam C > > --- > > drivers/gpu/drm/i915/intel_drrs.c | 36 > > +++- > > 1 file changed, 35 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_drrs.c > > b/drivers/gpu/drm/i915/intel_drrs.c > > index e5d8bcd..42b420d 100644 > > --- a/drivers/gpu/drm/i915/intel_drrs.c > > +++ b/drivers/gpu/drm/i915/intel_drrs.c > > @@ -16,6 +16,7 @@ > > > > #include > > #include > > +#include > > > > #include "i915_drv.h" > > #include "intel_drv.h" > > @@ -85,6 +86,31 @@ int get_free_drrs_struct_index(struct drm_i915_private > > *dev_priv) > > return -EBUSY; > > } > > > > +/* > > + * TODO: This is identifying the multiple active crtcs at a time. > > + * Here we assume that this is clone state and disable DRRS. > > + * But need to implement a proper method to find the real cloned mode > > + * state. DRRS need not be disabled incase of multiple crtcs with > > + * different content. > > + */ > > This is a pretty big hack. Why do you need it? fb tracking should keep any > display in the high mode as long as there's activity, so as long as > userspace flips both buffers for both pipes (which is should for cloned > mode) they'll both be running at max. It's simpler than than: cloned mode == 1 pipe, 1 framebuffer, 1 pageflip. Does having a vblank_ref count as activity? There is a large body of code (like OML_sync_control) that assumes a fixed refresh rate for an output. (Though OML_sync_control is vague about multiple monitor setups and ignore mode changed altogether.) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 00/18] Generic DRRS implementation across the encoders
On Fri, Jun 26, 2015 at 07:21:44PM +0530, Ramalingam C wrote: > Display Refresh Rate Switching (DRRS) is a power conservation feature > which enables swtching between low and high refresh rates, > dynamically, based on the usage scenario to save power. > > This feature is applicable for internal panels. > > Indication that the panel supports DRRS is given by the panel EDID, which > would list multiple refresh rates for one resolution along with VBT fields > like drrs_min_vrefresh. > > DRRS is of 2 types - static and seamless. > Static needs full modeset. Which can be used in docking and undocking > scenarios. > Seamless DRRS involves changing RR without any visual effect to the user > and can be used during normal system usage. This is done by programming > certain registers. > > Support for static/seamless DRRS may be indicated in the VBT based on > inputs from the panel spec. > > We have implemented two DRRS use case scenrios : > 1. Idleness DRRS, 2. Media playback DRRS (Content's FPS based) > > Idleness DRRS:- > The implementation is based on frontbuffer tracking implementation. > When there is a disturbance on the screen triggered by user activity or a > periodic system activity, DRRS is disabled (RR is changed to high RR). > When there is no movement on screen, after a timeout, a switch > to low RR is made. > For integration with frontbuffer tracking code, > intel_drrs_invalidate() and intel_drrs_flush() are called. > > Media playback DRRS (Content's FPS based): > Based on the content's Frames Per Second, minimum required vrefresh > is called in userspace. If the panel supports the minimum required vrefresh > and if the DRRS is supported on the platform, userspace will make a modeset > request with same mode and FB but with different vrefresh. > Panel's vrefresh range will be exposed through connector's modelist and > connector property is created to expose the DRRS capability to the userspace. > > In DRRS state machine Media plyabck DRRS holds the highest priority. > Idleness DRRS is disabled as soon as Media playback DRRS is requested. > Idleness DRRS is reenabled when the userspace indicates the exit of Media > playback DRRS by requesting for highest vrefresh supported. > > NOTE: > 1. DRM documentation will be made once the RFC is closed along with IGT. > 2. Currently in RFC, platform support is developed only for VLV. >it will be extended to other platform once the design is approved. > 3. Basic design of DSI DRRS and Content based DRRS is functionally tested on >Android(VLV & CHT). I've made a few drive-by comments, but big picture comments repeated here: - Don't throw existing code away as in patch 1. When extending a feature/code, we'll refactor the existing stuff and keep it working all the time. Otherwise we invalidate all the previous testing, which throws out a lot of value. - Static DRRS and generalized seamless DRRS are imo separate features and we should split the patch series. seamless DRRS is already implemented using the fb tracking, maybe extended with some hints to userspace. Static DRRS otoh is just a modeset with a different clock (plus a better internal implementation to avoid flicker). So from that pov two completely different features, both in the implementation and the userspace ABI. - I guess we'll have a proper design discussion in internal mtgs about this too? Thanks, Daniel > > Ramalingam C (18): > drm/i915: Removing the eDP specific DRRS implementation > drm/i915: Generic DRRS state Machine > drm/i915: Addition of the drrs_min_vrefresh in VBT > drm/i915: Implementation of Generic DSI DRRS > drm/i915: Adjusting the pclk for dual link and burst mode > drm/i915: VLV dsi drrs support > drm/i915: Generic eDP DRRS implementation > drm/i915: VLV eDP DRRS methods > drm/i915: Cloned mode check > drm/i915: Initializing DRRS for all connectors > drm/i915: Updating the crtc modes in DRRS transitions > drm/i915: Redesigning dp_set_m_n to receive divider values > drm/i915: MEDIA_RR support in general DRRS state machine > drm/i915: MEDIA_RR support in eDP DRRS module > drm/i915: MEDIA_RR support in DSI DRRS module > drm/i915: Filtering media playback DRRS requests > drm/i915: Addition of downclock mode to connector modelist > drm/i915: Connector property for DRRS capability > > drivers/gpu/drm/i915/Makefile|3 + > drivers/gpu/drm/i915/i915_debugfs.c | 110 - > drivers/gpu/drm/i915/i915_drv.h | 91 +++- > drivers/gpu/drm/i915/i915_reg.h |4 + > drivers/gpu/drm/i915/intel_bios.c|3 + > drivers/gpu/drm/i915/intel_bios.h|9 +- > drivers/gpu/drm/i915/intel_ddi.c |2 - > drivers/gpu/drm/i915/intel_display.c | 57 ++- > drivers/gpu/drm/i915/intel_dp.c | 397 +--- > drivers/gpu/drm/i915/intel_drrs.c| 728 > ++ > drivers/gpu/drm/i915
Re: [Intel-gfx] [PATCH 12/13 v2] drm/i915/skl: Replace the HDMI DPLL divider computation algorithm
2015-06-25 12:15 GMT-03:00 Damien Lespiau :
> The HW validation team came back from further testing with a slightly
> changed constraint on the deviation between the DCO frequency and the
> central frequency. Instead of +-4%, it's now +1%/-6%.
>
> Unfortunately, the previous algorithm didn't quite cope with these new
> constraints, the reason being that it wasn't thorough enough looking at
> the possible divider candidates.
>
> The new algorithm looks at all dividers, which is definitely a hammer
> approach (we could reduce further the set of dividers to good ones as a
> follow up, at the cost of a bit more complicated code). But, at least,
> we can now satisfy the +1%/+6% rule for all the "Well known" HDMI
> frequencies of my test set (373 entries).
>
> On that subject, the new code is quite extensively tested in
> intel-gpu-tools (tools/skl_compute_wrpll).
>
> v2: Fix cycling between central frequencies and dividers (Paulo)
> Properly choose the minimal deviation between postive and negative
> candidates (Paulo).
>
> On the 373 test frequencies, v2 computes better dividers than v1 (ie
> more even dividers and lower deviation on average):
>
> v1: average deviation: 206.52
> v2: average deviation: 194.47
>
> Signed-off-by: Damien Lespiau
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 211
> +--
> 1 file changed, 137 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 31b29e8..6e964ef 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1104,6 +1104,103 @@ hsw_ddi_pll_select(struct intel_crtc *intel_crtc,
> return true;
> }
>
> +struct skl_wrpll_context {
> + uint64_t min_deviation; /* current minimal deviation */
> + uint64_t central_freq; /* chosen central freq */
> + uint64_t dco_freq; /* chosen dco freq */
> + unsigned int p; /* chosen divider */
> +};
> +
> +static void skl_wrpll_context_init(struct skl_wrpll_context *ctx)
> +{
> + memset(ctx, 0, sizeof(*ctx));
> +
> + ctx->min_deviation = U64_MAX;
> +}
> +
> +/* DCO freq must be within +1%/-6% of the DCO central freq */
> +#define SKL_DCO_MAX_PDEVIATION 100
> +#define SKL_DCO_MAX_NDEVIATION 600
> +
> +static void skl_wrpll_try_divider(struct skl_wrpll_context *ctx,
> + uint64_t central_freq,
> + uint64_t dco_freq,
> + unsigned int divider)
> +{
> + uint64_t deviation;
> +
> + deviation = div64_u64(1 * abs_diff(dco_freq, central_freq),
> + central_freq);
> +
> + /* positive deviation */
> + if (dco_freq >= central_freq) {
> + if (deviation < SKL_DCO_MAX_PDEVIATION &&
> + deviation < ctx->min_deviation) {
> + ctx->min_deviation = deviation;
> + ctx->central_freq = central_freq;
> + ctx->dco_freq = dco_freq;
> + ctx->p = divider;
> + }
> + /* negative deviation */
> + } else if (deviation < SKL_DCO_MAX_NDEVIATION &&
> + deviation < ctx->min_deviation) {
> + ctx->min_deviation = deviation;
> + ctx->central_freq = central_freq;
> + ctx->dco_freq = dco_freq;
> + ctx->p = divider;
> + }
> +
> +}
> +
> +static void skl_wrpll_get_multipliers(unsigned int p,
> + unsigned int *p0 /* out */,
> + unsigned int *p1 /* out */,
> + unsigned int *p2 /* out */)
> +{
> + /* even dividers */
> + if (p % 2 == 0) {
> + unsigned int half = p / 2;
> +
> + if (half == 1 || half == 2 || half == 3 || half == 5) {
> + *p0 = 2;
> + *p1 = 1;
> + *p2 = half;
> + } else if (half % 2 == 0) {
> + *p0 = 2;
> + *p1 = half / 2;
> + *p2 = 2;
> + } else if (half % 3 == 0) {
> + *p0 = 3;
> + *p1 = half / 3;
> + *p2 = 2;
> + } else if (half % 7 == 0) {
> + *p0 = 7;
> + *p1 = half / 7;
> + *p2 = 2;
> + }
> + } else if (p == 3 || p == 9) { /* 3, 5, 7, 9, 15, 21, 35 */
> + *p0 = 3;
> + *p1 = 1;
> + *p2 = p / 3;
> + } else if (p == 5 || p == 7) {
> + *p0 = p;
> + *p1 = 1;
> + *p2 = 1;
> + } else if (p == 15) {
> + *p0 = 3;
> + *p1 = 1;
> +
Re: [Intel-gfx] [RFC PATCH 10/18] drm/i915: Initializing DRRS for all connectors
On Fri, Jun 26, 2015 at 07:21:54PM +0530, Ramalingam C wrote: > For all the connectors drrs init is invoked. drrs_init will > initialize the drrs for those connectors that support DRRS. > > Signed-off-by: Ramalingam C > --- > drivers/gpu/drm/i915/intel_display.c |5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 3f48917..0e8467c 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -15021,6 +15021,7 @@ void intel_modeset_init(struct drm_device *dev) > int sprite, ret; > enum pipe pipe; > struct intel_crtc *crtc; > + struct intel_connector *connector; > > drm_mode_config_init(dev); > > @@ -15090,6 +15091,10 @@ void intel_modeset_init(struct drm_device *dev) > i915_disable_vga(dev); > intel_setup_outputs(dev); > > + list_for_each_entry(connector, &dev->mode_config.connector_list, > + base.head) > + intel_drrs_init(dev, connector, connector->panel.fixed_mode); We initialize all the panel stuff in respective encoder callbacks, this is a layering violation. If we need to share more panel init code then that's ok, but the call needs to be in the edp/dsi/lvds/whatever init functions. -Daniel > + > /* Just in case the BIOS is doing something questionable. */ > intel_fbc_disable(dev); > > -- > 1.7.9.5 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 11/18] drm/i915: Updating the crtc modes in DRRS transitions
On Fri, Jun 26, 2015 at 07:21:55PM +0530, Ramalingam C wrote:
> During the DRRS state transitions we are modifying the clock and
> hence the vrefresh rate.
>
> So we need to update the drm_crtc->mode and the adjusted
> mode in intel_crtc. So that watermark calculations will be as per the
> new modified clock.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_drrs.c | 14 ++
> drivers/gpu/drm/i915/intel_dsi_drrs.c | 14 +-
> 2 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drrs.c
> b/drivers/gpu/drm/i915/intel_drrs.c
> index 42b420d..2901832 100644
> --- a/drivers/gpu/drm/i915/intel_drrs.c
> +++ b/drivers/gpu/drm/i915/intel_drrs.c
> @@ -169,6 +169,20 @@ void intel_set_drrs_state(struct i915_drrs *drrs)
>* If it is non-DSI encoders.
>* As only DSI has SEAMLESS_DRRS_SUPPORT_SW.
>*/
> + /*
> + * TODO: Protect the access to the crtc mode with corresponding
> + * mutex in case of Idleness DRRS. As media playback update
> + * will happen under crtc modeset lock protection
> + */
> + drm_modeset_lock(&intel_crtc->base.mutex, NULL);
> + intel_crtc->base.mode.clock = target_mode->clock;
> + intel_crtc->base.mode.vrefresh = target_mode->vrefresh;
> + intel_crtc->config->base.adjusted_mode.clock =
> + target_mode->clock;
> + intel_crtc->config->base.adjusted_mode.vrefresh =
> + target_mode->vrefresh;
> + drm_modeset_unlock(&intel_crtc->base.mutex);
No. For video DRRS (i.e. changing the vrefresh rate to exactly what we
want to match media content) userspace needs to do a full modeset. Maarten
is working on infrastructure to avoid full modeset in some special mode
changes (to implement the fast pfit change from Jesse's original fastboot
work). And we can extend this to DRRS too.
For seamless&transparent DRRS we can still keep the current design with
effectively 2 dotclocks.
Also with atomic you can combine the clock change with the first video
frame which is double-awesome ;-)
-Daniel
> +
> drrs_state->current_rr_type = drrs_state->target_rr_type;
> DRM_INFO("Refresh Rate set to : %dHz\n", refresh_rate);
> }
> diff --git a/drivers/gpu/drm/i915/intel_dsi_drrs.c
> b/drivers/gpu/drm/i915/intel_dsi_drrs.c
> index eb0758a..d4bb70a 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_drrs.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_drrs.c
> @@ -46,6 +46,7 @@ static void intel_mipi_drrs_work_fn(struct work_struct
> *__work)
> struct i915_drrs *drrs = work->drrs;
> struct intel_encoder *intel_encoder = drrs->connector->encoder;
> struct intel_dsi *intel_dsi = enc_to_intel_dsi(&intel_encoder->base);
> + struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc);
> struct dsi_drrs *dsi_drrs = &intel_dsi->dsi_drrs;
> struct dsi_mnp *dsi_mnp;
> struct drm_display_mode *prev_mode = NULL;
> @@ -69,11 +70,22 @@ retry:
> /* PLL Programming is successful */
> mutex_lock(&drrs->drrs_mutex);
> drrs->drrs_state.current_rr_type = work->target_rr_type;
> +
> + drm_modeset_lock(&intel_crtc->base.mutex, NULL);
> + intel_crtc->base.mode.clock = work->target_mode->clock;
> + intel_crtc->base.mode.vrefresh = work->target_mode->vrefresh;
> + intel_crtc->config->base.adjusted_mode.clock =
> + work->target_mode->clock;
> + intel_crtc->config->base.adjusted_mode.vrefresh =
> + work->target_mode->vrefresh;
> + drm_modeset_unlock(&intel_crtc->base.mutex);
> +
> mutex_unlock(&drrs->drrs_mutex);
> +
> DRM_INFO("Refresh Rate set to : %dHz\n",
> work->target_mode->vrefresh);
>
> - /* TODO: Update crtc mode and drain ladency with watermark */
> + /* TODO: Update drain ladency with watermark */
>
> } else if (ret == -ETIMEDOUT && retry_cnt) {
>
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/13 v2] drm/i915/skl: Prefer even dividers for SKL DPLLs
2015-06-25 12:19 GMT-03:00 Damien Lespiau :
> Currently, if an odd divider improves the deviation (minimizes it), we
> take that divider. The recommendation is to prefer even dividers.
>
> v2: Move the check at the right place after having inverted the two for
> loops in the previous patch.
>
> Signed-off-by: Damien Lespiau
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 6e964ef..f6b3ccc 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1317,6 +1317,13 @@ skl_ddi_calculate_wrpll(int clock /* in Hz */,
> p);
> }
> }
> +
> + /*
> +* If a solution is found with an even divider, prefer
> +* this one.
> +*/
> + if (d == 0 && ctx.p)
> + break;
> }
>
> if (!ctx.p) {
> --
> 2.1.0
>
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 09/18] drm/i915: Cloned mode check
On Fri, Jun 26, 2015 at 07:21:53PM +0530, Ramalingam C wrote:
> If crtc is in clone mode, DRRS will be disabled. Because if the both
> the displays are not sharing the same vrefresh, then userspace
> activities based on vsync will go for toss.
>
> Clone mode will be rechecked on every restarting Idleness DRRS events.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_drrs.c | 36 +++-
> 1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drrs.c
> b/drivers/gpu/drm/i915/intel_drrs.c
> index e5d8bcd..42b420d 100644
> --- a/drivers/gpu/drm/i915/intel_drrs.c
> +++ b/drivers/gpu/drm/i915/intel_drrs.c
> @@ -16,6 +16,7 @@
>
> #include
> #include
> +#include
>
> #include "i915_drv.h"
> #include "intel_drv.h"
> @@ -85,6 +86,31 @@ int get_free_drrs_struct_index(struct drm_i915_private
> *dev_priv)
> return -EBUSY;
> }
>
> +/*
> + * TODO: This is identifying the multiple active crtcs at a time.
> + * Here we assume that this is clone state and disable DRRS.
> + * But need to implement a proper method to find the real cloned mode
> + * state. DRRS need not be disabled incase of multiple crtcs with
> + * different content.
> + */
This is a pretty big hack. Why do you need it? fb tracking should keep any
display in the high mode as long as there's activity, so as long as
userspace flips both buffers for both pipes (which is should for cloned
mode) they'll both be running at max.
And for non-cloned mode (e.g. video only on external TV) things will be
controlled independantly.
Smells a lot like trying to encode policy instead of making sure that the
resulting behaviour matches what we want. And I think it should already.
-Daniel
> +
> +bool is_cloned_mode_active(struct drm_device *dev)
> +{
> + struct drm_crtc *crtc = NULL, *tmp_crtc;
> +
> + list_for_each_entry(tmp_crtc, &dev->mode_config.crtc_list, head) {
> + if (crtc && intel_crtc_active(tmp_crtc)) {
> + DRM_DEBUG_KMS(
> + "more than one crtc active. Declared as clonec mode\n");
> + return true;
> + }
> +
> + if (intel_crtc_active(tmp_crtc))
> + crtc = tmp_crtc;
> + }
> + return false;
> +}
> +
> void intel_set_drrs_state(struct i915_drrs *drrs)
> {
> struct drrs_info *drrs_state;
> @@ -158,7 +184,10 @@ static void intel_idleness_drrs_work_fn(struct
> work_struct *__work)
>
> panel = &drrs->connector->panel;
>
> - /* TODO: If DRRS is not supported on clone mode act here */
> + /* Double check if the dual-display mode is active. */
> + if (drrs->is_clone)
> + return;
> +
> mutex_lock(&drrs->drrs_mutex);
> if (panel->target_mode != NULL)
> DRM_ERROR("FIXME: We shouldn't be here\n");
> @@ -192,6 +221,11 @@ static void intel_enable_idleness_drrs(struct i915_drrs
> *drrs)
>
> mutex_lock(&drrs->drrs_mutex);
>
> + drrs->is_clone = is_cloned_mode_active(drrs->connector->base.dev);
> +
> + if (drrs->is_clone)
> + return;
> +
> /* Capturing the deferred request for disable_drrs */
> if (drrs->drrs_state.type == SEAMLESS_DRRS_SUPPORT_SW &&
> drrs->encoder_ops->is_drrs_hr_state_pending) {
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Color management in DRM framework
Hi Shashank, I have been working on support for colorspace handling for V4L2 (video capture), basically the flip-side of the coin that you are working on. While both the V4L2 and DRM/KMS APIs are completely different, the part that does the matrix calculations can be shared between the two. I would prefer that to be something that lives in lib and can be used by both. I noticed that you use 16.16 fixed point for the primaries, which is a bit on the low side w.r.t. precision in my opinion. What is the precision used for the internal calculations? That was not immediately obvious to me from the code. In my implementation I've chosen to go with a fixed point 32.32 format. See an initial implementation here (search for fixp64_t): http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git/tree/include/media/v4l2-dv-timings.h?h=csc I don't have a div_fixp64 yet as I do not need it at the moment. But the 'Hacker's Delight' book has code for that as well, so that can be added. I didn't see any code for handling limited and full range quantization, but I suspect that's done elsewhere in DRM/KMS? Regards, Hans On 06/25/2015 06:19 PM, Sharma, Shashank wrote: > Gentle reminder for the review and comments. > > > > For those who prefer having the design available with the mail, I am > attaching a PDF copy of the design document with this mail. > > It would be great for us to hear from you guys, on this. > > > > Regards > > Shashank > > *From:*Sharma, Shashank > *Sent:* Monday, June 22, 2015 7:09 PM > *To:* robdcl...@gmail.com; alexander.deuc...@amd.com; bske...@redhat.com; > dri-de...@lists.freedesktop.org > *Cc:* Smith, Gary K; Barnes, Jesse; Lespiau, Damien; Roper, Matthew D; > Vetter, Daniel; Bhattacharjee, Susanta; Matheson, Annie J; Malladi, Kausal; > Mukherjee, Indranil; Kamath, Sunil; Pillai, Manikandan K; Palleti, Avinash > Reddy; R, Dhanya p > *Subject:* Color management in DRM framework > > > > Hi Rob, Alex, Ben, All J > > > > I am Shashank Sharma, from Linux display team Intel, Bangalore. > > We are planning to add a color management extension in the existing I915 > driver, for Intel HWs. > > Plan was to provide a color correction and enhancement interface for any > Linux based userspace, based on various HW capabilities. > > > > We are now thinking that if we can generalize this implementation, in such a > way that other drivers can also utilize this, this idea can act as an > extension to the DRM framework itself. > > Based on that thought, We have prepared a design for the same, and a rough > implementation based on this design. > > > > Would you all be kind enough to have a look at this design, and give us some > feedback, so that we can implement this in a way best suitable to most of the > drivers ? > > We have gone through few rounds of design discussions internally (design > contributors, reviewers in CC), and we all are moreover agree on the design > (few comments still in progress). > > > > *The highlights of the design:* > > 1. The color correction capabilities of a HW are being registered as a > DRM property of a CRTC / Plane (depending on a HW) > > 2. Properties will be of blob type. > > 3. New data structures will be added in DRM layer, to encoder and > decode color correction and enhancement data. > > 4. The color correction DRM properties would look like : > > a. Palette correction / programming based color properties (like gamma > correction). This can support various coefficients counts and correction > values, based on the underneath HW. > > b. Color transformation matrix based color correction (CSC, wide and > narrow gamut mapping) > > c. Plane level corrections like gamma correction, hue, saturation, > contrast and brightness. > > d. One blob type property to showcase the color correction capabilities > to the userspace, superset of all other color correction properties. > > 5. The driver’s init function can create the superset color property, > and show its color capabilities to the userspace. > > 6. Userspace can query the current color correction Or apply a new > color correction using a set/get property interface. > > > > Please find the detailed design, in this shared google document: > > https://docs.google.com/document/d/1jyfNSAStKHEpmIUZd_1Gd68cPuyiyr8wmJXThSDb_2w/ > > Please feel free to add more people in the design discussion, once we have > some basic agreement on the design, we will share the patches in dri-devel > level. > > > > Regards > > Shashank > > > > > > > > > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/vblank: WARN_ON nested use of drm_vblank_on/off
On 22 June 2015 at 14:02, Daniel Vetter wrote:
> We should never nest these since in theory kms drivers should know
> when a pipe is on/off and call the corresponding enable/disable
> functions for the vblank helper code only once. But for historical
> reasons (the shared-with-ums version of this code in modeset_pre/post
> needed to be able to cope with silly userspace that lost track of
> things) we still have this bit of "robustness" around.
>
> Enforce this with a WARN_ON, preparing to eventually rip out this
> special handling.
Hello,
just wanted to mention that this warning triggered on tegra124 and
that I find it a bit disruptive:
WARNING: CPU: 0 PID: 52 at drivers/gpu/drm/drm_irq.c:1323
drm_vblank_on+0x10c/0x130()
Modules linked in:
CPU: 0 PID: 52 Comm: kworker/0:1 Not tainted
4.1.0-next-20150625ccu-00024-gd8cbda3 #2295
Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
Workqueue: events output_poll_execute
[] (unwind_backtrace) from [] (show_stack+0x20/0x24)
[] (show_stack) from [] (dump_stack+0x8c/0x9c)
[] (dump_stack) from [] (warn_slowpath_common+0x94/0xc4)
[] (warn_slowpath_common) from []
(warn_slowpath_null+0x2c/0x34)
[] (warn_slowpath_null) from [] (drm_vblank_on+0x10c/0x130)
[] (drm_vblank_on) from [] (drm_crtc_vblank_on+0x28/0x2c)
[] (drm_crtc_vblank_on) from []
(tegra_crtc_commit+0x18/0x1c)
[] (tegra_crtc_commit) from []
(drm_atomic_helper_commit_modeset_enables+0xa0/0x198)
[] (drm_atomic_helper_commit_modeset_enables) from
[] (tegra_atomic_complete.isra.1+0x38/0x5c)
[] (tegra_atomic_complete.isra.1) from []
(tegra_atomic_commit+0x68/0x98)
[] (tegra_atomic_commit) from []
(drm_atomic_commit+0x54/0x74)
[] (drm_atomic_commit) from []
(drm_atomic_helper_set_config+0x1b4/0x414)
[] (drm_atomic_helper_set_config) from []
(drm_mode_set_config_internal+0x68/0xe4)
[] (drm_mode_set_config_internal) from []
(restore_fbdev_mode+0xe8/0x108)
[] (restore_fbdev_mode) from []
(drm_fb_helper_restore_fbdev_mode_unlocked+0x2c/0x68)
[] (drm_fb_helper_restore_fbdev_mode_unlocked) from
[] (drm_fb_helper_set_par+0x28/0x44)
[] (drm_fb_helper_set_par) from []
(drm_fb_helper_hotplug_event+0xcc/0x108)
[] (drm_fb_helper_hotplug_event) from []
(tegra_fb_output_poll_changed+0x28/0x2c)
[] (tegra_fb_output_poll_changed) from []
(drm_kms_helper_hotplug_event+0x34/0x38)
[] (drm_kms_helper_hotplug_event) from []
(output_poll_execute+0x158/0x198)
[] (output_poll_execute) from []
(process_one_work+0x154/0x48c)
[] (process_one_work) from [] (worker_thread+0x54/0x568)
[] (worker_thread) from [] (kthread+0xec/0x104)
[] (kthread) from [] (ret_from_fork+0x14/0x2c)
Regards,
Tomeu
> Cc: Yogesh Mohan Marimuthu
> Cc: Gaurav K Singh
> Cc: Michel Dänzer
> Cc: Ville Syrjälä
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_irq.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index f9cc68fbd2a3..3819465abe22 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1219,6 +1219,8 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
> vblank_disable_and_save(dev, crtc);
> wake_up(&vblank->queue);
>
> + WARN_ON(vblank->inmodeset);
> +
> /*
> * Prevent subsequent drm_vblank_get() from re-enabling
> * the vblank interrupt by bumping the refcount.
> @@ -1318,6 +1320,8 @@ void drm_vblank_on(struct drm_device *dev, int crtc)
> return;
>
> spin_lock_irqsave(&dev->vbl_lock, irqflags);
> + WARN_ON(!vblank->inmodeset);
> +
> /* Drop our private "prevent drm_vblank_get" refcount */
> if (vblank->inmodeset) {
> atomic_dec(&vblank->refcount);
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Adding custom bugzilla fields
On Fri, Jun 26, 2015 at 06:28:39PM +0300, Ander Conselvan De Oliveira wrote:
> Hi all,
>
> I've been looking into creating custom fields in Bugzilla to help sort
> our bugs in a more manageable way. I did some testing in a private
> installation and came up with this proposal. In a nut shell, we would
> add the following two fields:
>
> i915 platform: list of platforms affected by a bug;
> i915 features: list of features affected by a bug.
>
> Both would be multiple selection fields. The accepted values would be
> configured in the Bugzilla installation. The attached screenshots show
> how this would look like in the bug view and bug list views.
>
> My expectation is that using those fields we could have a clearer view
> of which areas and/or platforms require more attention. For example, I
> attached a screenshot of a sample report breaking down the bugs per
> feature and platform. That report requires Bugzilla 5.0 (which hasn't
> been released yet) since prior versions didn't support reports with
> multiple selection fields. However, it is also possible to script a
> similar report, as the attached python script does. The output looks
> something like this:
>
> FeatureALL ILK SNB BYT IVB HSW BDW BSW SKL
> display - atomic 001000100
> display - audio 000000000
> display - DP 001010100
> display - DP MST 000000000
> display - DSI000000000
> display - eDP000000000
> display - fastboot 000000000
Fastboot is very soonish no more (Maarten has patches to move it all into
normal modeset code). I'd drop it.
The other missing bit is all the plane stuff, color manager and similar.
Otoh this is new, so not clear yet what kind of bugs will be common. Imo
better to wait and then maybe add more categories.
> display - FBC000000000
> display - HDMI 000000000
> display - IPS000000000
> display - LVDS 000000000
> display - PSR000000000
> display - Other 000000000
> GEM - execlists 000000000
> GEM - PPGTT 000000000
> GEM - Other 100000100
GEM - gpu hang
blows up all the time. And we need a bucket to catch all the userspace
hangs which are reported against the kernel.
> power - RC6 000100000
> power - RCS 000000000
RPS is turbo stuff, and it's tightly coupled with rc6. Maybe instead just
power - GT
for all the GT related power saving features?
I'd also add
power - runtime PM
and
power - suspend/resume
here. Tons of stuff blows up here.
> power - Other000000000
>
>
> So I would like to hear what other people think about this. Specially,
> about what should be in the features field. The values can change
> overtime, but would be good to have a good list from the start. The
> values above are an incomplete list I threw together while looking at
> different open bugs.
Maybe we need a bit more polish, but probably not worth it to spend too
much time on the exact feature list. If we spot serious gaps we can always
add more. And remove old ones which have gone out of favour (having that
script handy somewhere would be good).
-Daniel
>
> Thanks,
> Ander
> import bugzilla
> import collections
>
> bugzilla_url = "http://192.168.100.244/bugzilla/xmlrpc.cgi";
>
> closed_states = ['RESOLVED', 'VERIFIED', 'CLOSED']
> open_states = ["REOPENED", "NEEDINFO", "NEW", "ASSIGNED"]
>
> def get_custom_fields_allowed_values(bz):
> fields = ['cf_i915_platform', 'cf_i915_features']
> r = bz._proxy.Bug.fields({'names': fields,
> 'include_fields': ['values']})
>
> list_of_raw_values = [f['values'] for f in r['fields']]
> values = [[v['name'] for v in f] for f in list_of_raw_values]
>
> assert len(values) == len(fields)
> return dict(zip(fields, values))
>
> def get_drm_intel_bugs(bz):
> query = bz.build_query(product="DRI", component="DRM/Intel",
> status=open_states)
> return bz.query(query)
>
> def split_bugs_per_field(bz, bugs, field):
> split = collections.OrderedDict()
>
> allowed_values = get_custom_fields_allowed_values(bz)
> for v in allowed_values[field]:
> split[v] = []
>
> for bug in bugs:
> if field in bug.
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Interrupt driven fences
On 26/06/2015 14:34, Chris Wilson wrote: On Fri, Jun 26, 2015 at 01:58:11PM +0100, john.c.harri...@intel.com wrote: From: John Harrison The intended usage model for struct fence is that the signalled status should be set on demand rather than polled. That is, there should not be a need for a 'signaled' function to be called everytime the status is queried. Instead, 'something' should be done to enable a signal callback from the hardware which will update the state directly. In the case of requests, this is the seqno update interrupt. The idea is that this callback will only be enabled on demand when something actually tries to wait on the fence. This change removes the polling test and replaces it with the callback scheme. Each fence is added to a 'please poke me' list at the start of i915_add_request(). The interrupt handler then scans through the 'poke me' list when a new seqno pops out and signals any matching fence/request. The fence is then removed from the list so the entire request stack does not need to be scanned every time. Note that the fence is added to the list before the commands to generate the seqno interrupt are added to the ring. Thus the sequence is guaranteed to be race free if the interrupt is already enabled. One complication here is that the 'poke me' system requires holding a reference count on the request to guarantee that it won't be freed prematurely. Unfortunately, it is unsafe to decrement the reference count from the interrupt handler because if that is the last reference, the clean up code gets run and the clean up code is not IRQ friendly. Hence, the request is added to a 'please clean me' list that gets processed at retire time. Any request in this list simply has its count decremented and is then removed from that list. Note that the interrupt is only enabled on demand (i.e. when __wait_request() is called). Thus there is still a potential race when enabling the interrupt as the request may already have completed. However, this is simply solved by calling the interrupt processing code immediately after enabling the interrupt and thereby checking for already completed requests. Lastly, the ring clean up code has the possibility to cancel outstanding requests (e.g. because TDR has reset the ring). These requests will never get signalled and so must be removed from the signal list manually. This is done by setting a 'cancelled' flag and then calling the regular notify/retire code path rather than attempting to duplicate the list manipulatation and clean up code in multiple places. This also avoid any race condition where the cancellation request might occur after/during the completion interrupt actually arriving. -nightly nop: Time to exec x 1:15.000µs (ring=render) Time to exec x 1: 2.000µs (ring=blt) Time to exec x 131072:1.827µs (ring=render) Time to exec x 131072:1.555µs (ring=blt) rq tuning patches nop: Time to exec x 1:12.200µs (ring=render) Time to exec x 1: 1.600µs (ring=blt) Time to exec x 131072:1.516µs (ring=render) Time to exec x 131072:0.812µs (ring=blt) interrupt driven nop: Time to exec x 1:19.200µs (ring=render) Time to exec x 1: 5.200µs (ring=blt) Time to exec x 131072:2.381µs (ring=render) Time to exec x 131072:2.009µs (ring=blt) So the basic question that is left unanswered from last time is why would we want to slow down __i915_wait_request? And enabling IRQs still generates very high system load when processing the 30-40k IRQs per second found under some workloads. -Chris As previously stated, the scheduler requires enabling interrupts for each batch buffer as it needs to know when something more needs sending to the hardware. Android requires enabling interrupts for each batch buffer as it uses the sync framework to wait on batch buffer completion asynchronously to the driver (i.e. without calling __i915_wait_request or any other driver code). I presume much of the slow down to wait_request itself is because it has to check for missed interrupts. It should be possible to optimise that somewhat although it was completely unnecessary in the original version as you can't miss interrupts if they are always on. How do you get consistent results from gem_exec_nop? For the x1 case, I see random variation from one run to the next of the order of 10us -> over 100us. And that is with a straight nightly build. John. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 4/6] drm/i915/gen8: Add WaFlushCoherentL3CacheLinesAtContextSwitch workaround
On Fri, Jun 26, 2015 at 05:45:08PM +0100, Dave Gordon wrote:
> On 16/06/15 21:38, Chris Wilson wrote:
> > On Tue, Jun 16, 2015 at 08:25:23PM +0100, Arun Siluvery wrote:
> >> + /* WaFlushCoherentL3CacheLinesAtContextSwitch:bdw */
> >> + if (IS_BROADWELL(ring->dev)) {
> >> + struct drm_i915_private *dev_priv = ring->dev->dev_private;
> >
> > dev_priv = to_i915(ring->dev);
> >
> >> +
> >> + cmd[index++] = MI_LOAD_REGISTER_IMM(1);
> >> + cmd[index++] = GEN8_L3SQCREG4;
> >> + cmd[index++] = I915_READ(GEN8_L3SQCREG4) |
> >> + GEN8_LQSC_FLUSH_COHERENT_LINES;
> >
> > Read the reg once, it is clearer that way.
> >
> >> +
> >> + cmd[index++] = GFX_OP_PIPE_CONTROL(6);
> >> + cmd[index++] = PIPE_CONTROL_CS_STALL |
> >> + PIPE_CONTROL_DC_FLUSH_ENABLE;
> >> + cmd[index++] = 0;
> >> + cmd[index++] = 0;
> >> + cmd[index++] = 0;
> >> + cmd[index++] = 0;
> >> +
> >> + cmd[index++] = MI_LOAD_REGISTER_IMM(1);
> >> + cmd[index++] = GEN8_L3SQCREG4;
> >> + cmd[index++] = I915_READ(GEN8_L3SQCREG4) &
> >> + ~GEN8_LQSC_FLUSH_COHERENT_LINES;
> > -Chris
>
> What Chris said. But also, is it even meaningful to read a h/w register
> now (when?) and use its value as the basis for future LRI instructions?
> How (and when) does this register get its initial value, and does it get
> changed at any other time? If the value we put in the register is a
> run-time constant, there's really no need to read it back even once.
True. To be generic, we need to do STORE_REG_MEM, LRI constant value,
then LOAD_REG_MEM. Hopefully, no userspace ever actually need to twiddle
that register and we can just load a constant value.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 01/18] drm/i915: Removing the eDP specific DRRS implementation
On Fri, Jun 26, 2015 at 07:21:45PM +0530, Ramalingam C wrote:
> EDP specific DRRS implementation is removed to implement a
> generic DRRS stack extentable accross the supportable encoders.
>
> Signed-off-by: Ramalingam C
Nack. You don't make something generic by first throwing out the existing
solution (and all the lessons learned implementing that).
Instead convert the edp DRRS implementation over to use generic
structures, step-by-step, and then once that's done it should be simply to
implement DRRS for other outputs.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 110 -
> drivers/gpu/drm/i915/i915_drv.h | 22 --
> drivers/gpu/drm/i915/intel_ddi.c |2 -
> drivers/gpu/drm/i915/intel_dp.c | 392
> --
> drivers/gpu/drm/i915/intel_drv.h |5 -
> drivers/gpu/drm/i915/intel_frontbuffer.c |2 -
> 6 files changed, 533 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index c49fe2a..7dbf170 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2962,115 +2962,6 @@ static int i915_ddb_info(struct seq_file *m, void
> *unused)
> return 0;
> }
>
> -static void drrs_status_per_crtc(struct seq_file *m,
> - struct drm_device *dev, struct intel_crtc *intel_crtc)
> -{
> - struct intel_encoder *intel_encoder;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct i915_drrs *drrs = &dev_priv->drrs;
> - int vrefresh = 0;
> -
> - for_each_encoder_on_crtc(dev, &intel_crtc->base, intel_encoder) {
> - /* Encoder connected on this CRTC */
> - switch (intel_encoder->type) {
> - case INTEL_OUTPUT_EDP:
> - seq_puts(m, "eDP:\n");
> - break;
> - case INTEL_OUTPUT_DSI:
> - seq_puts(m, "DSI:\n");
> - break;
> - case INTEL_OUTPUT_HDMI:
> - seq_puts(m, "HDMI:\n");
> - break;
> - case INTEL_OUTPUT_DISPLAYPORT:
> - seq_puts(m, "DP:\n");
> - break;
> - default:
> - seq_printf(m, "Other encoder (id=%d).\n",
> - intel_encoder->type);
> - return;
> - }
> - }
> -
> - if (dev_priv->vbt.drrs_type == STATIC_DRRS_SUPPORT)
> - seq_puts(m, "\tVBT: DRRS_type: Static");
> - else if (dev_priv->vbt.drrs_type == SEAMLESS_DRRS_SUPPORT)
> - seq_puts(m, "\tVBT: DRRS_type: Seamless");
> - else if (dev_priv->vbt.drrs_type == DRRS_NOT_SUPPORTED)
> - seq_puts(m, "\tVBT: DRRS_type: None");
> - else
> - seq_puts(m, "\tVBT: DRRS_type: FIXME: Unrecognized Value");
> -
> - seq_puts(m, "\n\n");
> -
> - if (to_intel_crtc_state(intel_crtc->base.state)->has_drrs) {
> - struct intel_panel *panel;
> -
> - mutex_lock(&drrs->mutex);
> - /* DRRS Supported */
> - seq_puts(m, "\tDRRS Supported: Yes\n");
> -
> - /* disable_drrs() will make drrs->dp NULL */
> - if (!drrs->dp) {
> - seq_puts(m, "Idleness DRRS: Disabled");
> - mutex_unlock(&drrs->mutex);
> - return;
> - }
> -
> - panel = &drrs->dp->attached_connector->panel;
> - seq_printf(m, "\t\tBusy_frontbuffer_bits: 0x%X",
> - drrs->busy_frontbuffer_bits);
> -
> - seq_puts(m, "\n\t\t");
> - if (drrs->refresh_rate_type == DRRS_HIGH_RR) {
> - seq_puts(m, "DRRS_State: DRRS_HIGH_RR\n");
> - vrefresh = panel->fixed_mode->vrefresh;
> - } else if (drrs->refresh_rate_type == DRRS_LOW_RR) {
> - seq_puts(m, "DRRS_State: DRRS_LOW_RR\n");
> - vrefresh = panel->downclock_mode->vrefresh;
> - } else {
> - seq_printf(m, "DRRS_State: Unknown(%d)\n",
> - drrs->refresh_rate_type);
> - mutex_unlock(&drrs->mutex);
> - return;
> - }
> - seq_printf(m, "\t\tVrefresh: %d", vrefresh);
> -
> - seq_puts(m, "\n\t\t");
> - mutex_unlock(&drrs->mutex);
> - } else {
> - /* DRRS not supported. Print the VBT parameter*/
> - seq_puts(m, "\tDRRS Supported : No");
> - }
> - seq_puts(m, "\n");
> -}
> -
> -static int i915_drrs_status(struct seq_file *m, void *unused)
> -{
> - struct drm_info_node *node = m->private;
> - struct drm_device *dev = node->minor->dev;
> - struct intel_crtc *intel_crtc;
> - int active_crtc_cnt = 0;
> -
> - for_each_intel_crtc(dev, intel_crtc)
[Intel-gfx] [PATCH igt v3] lib: Update intel_require_memory to handle +4GB cases
Changed size from u32 to u64 to support +4GB.
48-bit PPGTT test cases may need extra memory available.
v2: Use thousands separator (Chris)
v3: Moved igt_skip_on_simulation() to the start (Chris)
Include Chris' usage hint in the gtk-doc section (Daniel)
Cc: Daniel Vetter
Reviewed-by: Chris Wilson (v2)
Signed-off-by: Michel Thierry
---
lib/igt_aux.h | 2 +-
lib/intel_os.c | 34 +-
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index 9ea50de..139e5da 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -86,7 +86,7 @@ uint64_t intel_get_avail_ram_mb(void);
uint64_t intel_get_total_ram_mb(void);
uint64_t intel_get_total_swap_mb(void);
-void intel_require_memory(uint32_t count, uint32_t size, unsigned mode);
+void intel_require_memory(uint32_t count, uint64_t size, unsigned mode);
#define CHECK_RAM 0x1
#define CHECK_SWAP 0x2
diff --git a/lib/intel_os.c b/lib/intel_os.c
index f82847f..3e3b9ec 100644
--- a/lib/intel_os.c
+++ b/lib/intel_os.c
@@ -214,19 +214,45 @@ intel_get_total_swap_mb(void)
* also causes the test to be skipped automatically on simulation under the
* assumption that any test that needs to check for memory requirements is a
* thrashing test unsuitable for slow simulated systems.
+ *
+ * We use intel_require_memory() to detect tests that are designed to run with
+ * large working sets to stress boundaries such as aperture, and/or memory
+ * exhaustion. Functional tests that also require large working sets should be
+ * split into two, a small subtest to verify the operation with the absolute
+ * minimum working set, and the full subtest to verify the interesting corner
+ * cases. The former test doesn't require the memory check and so judicious
+ * use of intel_require_memory() helps segregate such functional tests from
+ * the broader tests, useful for slow verification systems such as the
+ * simulator.
+ *
+ * To recap, lay out behaviour tests like:
+ * |[
+ *igt_subtest("small") {
+ * run_test({.num_surfaces = 2 });
+ *}
+ *igt_subtest("full") {
+ * intel_require_memory(NUM_SURFACES, SURFACE_SIZE, CHECK_RAM);
+ * run_test({.num_surfaces = NUM_SURFACES});
+ *}
+ * ]|
+ * so that we have a simple check that is run anywhere and everywhere,
+ * useful to prove the test itself works as expected, and the full
+ * slow check that needs to be run on real hardware.
*/
-void intel_require_memory(uint32_t count, uint32_t size, unsigned mode)
+void intel_require_memory(uint32_t count, uint64_t size, unsigned mode)
{
/* rough estimate of how many bytes the kernel requires to track each object */
#define KERNEL_BO_OVERHEAD 512
uint64_t required, total;
+ igt_skip_on_simulation();
+
required = count;
required *= size + KERNEL_BO_OVERHEAD;
required = ALIGN(required, 4096);
- igt_debug("Checking %u surfaces of size %u bytes (total %'llu) against
%s%s\n",
- count, size, (long long)required,
+ igt_debug("Checking %u surfaces of size %'llu bytes (total %'llu)
against %s%s\n",
+ count, (long long)size, (long long)required,
mode & (CHECK_RAM | CHECK_SWAP) ? "RAM" : "",
mode & CHECK_SWAP ? " + swap": "");
@@ -242,8 +268,6 @@ void intel_require_memory(uint32_t count, uint32_t size,
unsigned mode)
(long long)required, (long long)total,
mode & (CHECK_RAM | CHECK_SWAP) ? "RAM" : "",
mode & CHECK_SWAP ? " + swap": "");
-
- igt_skip_on_simulation();
}
void
--
2.4.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 4/6] drm/i915/gen8: Add WaFlushCoherentL3CacheLinesAtContextSwitch workaround
On 16/06/15 21:38, Chris Wilson wrote:
> On Tue, Jun 16, 2015 at 08:25:23PM +0100, Arun Siluvery wrote:
>> +/* WaFlushCoherentL3CacheLinesAtContextSwitch:bdw */
>> +if (IS_BROADWELL(ring->dev)) {
>> +struct drm_i915_private *dev_priv = ring->dev->dev_private;
>
> dev_priv = to_i915(ring->dev);
>
>> +
>> +cmd[index++] = MI_LOAD_REGISTER_IMM(1);
>> +cmd[index++] = GEN8_L3SQCREG4;
>> +cmd[index++] = I915_READ(GEN8_L3SQCREG4) |
>> +GEN8_LQSC_FLUSH_COHERENT_LINES;
>
> Read the reg once, it is clearer that way.
>
>> +
>> +cmd[index++] = GFX_OP_PIPE_CONTROL(6);
>> +cmd[index++] = PIPE_CONTROL_CS_STALL |
>> +PIPE_CONTROL_DC_FLUSH_ENABLE;
>> +cmd[index++] = 0;
>> +cmd[index++] = 0;
>> +cmd[index++] = 0;
>> +cmd[index++] = 0;
>> +
>> +cmd[index++] = MI_LOAD_REGISTER_IMM(1);
>> +cmd[index++] = GEN8_L3SQCREG4;
>> +cmd[index++] = I915_READ(GEN8_L3SQCREG4) &
>> +~GEN8_LQSC_FLUSH_COHERENT_LINES;
> -Chris
What Chris said. But also, is it even meaningful to read a h/w register
now (when?) and use its value as the basis for future LRI instructions?
How (and when) does this register get its initial value, and does it get
changed at any other time? If the value we put in the register is a
run-time constant, there's really no need to read it back even once.
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/18] drm/i915/gtt: One instance of scratch page table/directory
On Fri, Jun 26, 2015 at 03:05:29PM +0300, Mika Kuoppala wrote:
> Daniel Vetter writes:
>
> > On Thu, Jun 25, 2015 at 06:35:18PM +0300, Mika Kuoppala wrote:
> >> +static int setup_scratch(struct i915_address_space *vm)
> >> +{
> >> + struct i915_address_space *ggtt_vm = &to_i915(vm->dev)->gtt.base;
> >> +
> >> + if (i915_is_ggtt(vm))
> >> + return setup_scratch_ggtt(vm);
> >> +
> >> + vm->scratch_page = ggtt_vm->scratch_page;
> >> + vm->scratch_pt = ggtt_vm->scratch_pt;
> >> + vm->scratch_pd = ggtt_vm->scratch_pd;
> >> +
> >> + return 0;
> >> +}
> >
> > The point of a ppgtt is full isolation, sharing the scratch page destroys
> > that. Hence nack. If you want a bit of polish, renaming initialize_pd/pt
> > to initialize_scratch_pd/pt would make sense though I think.
> > -Daniel
>
> We already have a shared scratch. This just makes the upper layer
> structures also shared as there is no point of having identical
> scratch pt and scratch pd pointing to the same scratch.
>
> Do we want per ppgtt scratch? I have patches for that also.
Summary of our irc discussion: Yes I think we want a per-ppgtt scratch,
and I even thought we once had such a thing. But didn't digg around in
history tbh.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/18] drm/i915/gtt: Switch gen8_free_page_tables params
On Thu, Jun 11, 2015 at 09:05:38PM +0300, Mika Kuoppala wrote:
> Michel Thierry writes:
>
> > After Mika's ppgtt cleanup series, all the other free functions have
> > drm_device as the first parameter, except this one.
> >
> > No functional changes.
> >
> > Signed-off-by: Michel Thierry
>
> Reviewed-by: Mika Kuoppala
First two patches merged, thanks.
-Daniel
>
> > ---
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index 8f79125..8314e59 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -766,7 +766,8 @@ static void gen8_ppgtt_insert_entries(struct
> > i915_address_space *vm,
> > kunmap_px(ppgtt, pt_vaddr);
> > }
> >
> > -static void gen8_free_page_tables(struct i915_page_directory *pd, struct
> > drm_device *dev)
> > +static void gen8_free_page_tables(struct drm_device *dev,
> > + struct i915_page_directory *pd)
> > {
> > int i;
> >
> > @@ -792,7 +793,8 @@ static void gen8_ppgtt_cleanup(struct
> > i915_address_space *vm)
> > if (WARN_ON(!ppgtt->pdp.page_directory[i]))
> > continue;
> >
> > - gen8_free_page_tables(ppgtt->pdp.page_directory[i],
> > ppgtt->base.dev);
> > + gen8_free_page_tables(ppgtt->base.dev,
> > + ppgtt->pdp.page_directory[i]);
> > free_pd(ppgtt->base.dev, ppgtt->pdp.page_directory[i]);
> > }
> >
> > --
> > 2.4.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control
On Fri, Jun 26, 2015 at 02:32:03PM +0530, Shobhit Kumar wrote: > Hi, > Next update of the series reviewed at > https://lkml.org/lkml/2015/6/22/155 > > Major changes are few review comments from Varka and Ville being addressed. > Also except > for intel-gfx patches, all patches reviesion history is moved out of commit > message. > > Hope this series finally finds its mark. > > Regards > Shobhit > > Shobhit Kumar (7): > gpiolib: Add support for removing registered consumer lookup table > mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO > signal > mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC > mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM > pwm: crc: Add Crystalcove (CRC) PWM driver > drm/i915: Use the CRC gpio for panel enable/disable > drm/i915: Backlight control using CRC PMIC based PWM driver I think we have r-b/acks on all the patches now. Ok if I pull this in through drm-intel.git for 4.3? Or should I make a topic branch with tag and then send out pull requests to everyone? Or will each maintainer merge on their own since it's all only coupled at runtime anyway? Any of these would suit me. Thanks, Daniel > > drivers/gpio/gpiolib.c | 13 > drivers/gpu/drm/i915/intel_bios.h | 7 ++ > drivers/gpu/drm/i915/intel_drv.h | 4 ++ > drivers/gpu/drm/i915/intel_dsi.c | 37 +- > drivers/gpu/drm/i915/intel_dsi.h | 3 + > drivers/gpu/drm/i915/intel_panel.c | 94 ++-- > drivers/mfd/intel_soc_pmic_core.c | 29 > drivers/mfd/intel_soc_pmic_crc.c | 3 + > drivers/pwm/Kconfig| 7 ++ > drivers/pwm/Makefile | 1 + > drivers/pwm/pwm-crc.c | 143 > + > include/linux/gpio/machine.h | 1 + > 12 files changed, 335 insertions(+), 7 deletions(-) > create mode 100644 drivers/pwm/pwm-crc.c > > -- > 1.9.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
On Mon, 2015-06-22 at 17:44 +0200, Takashi Iwai wrote: > At Mon, 22 Jun 2015 15:21:16 +, > Kaskinen, Tanu wrote: > > PulseAudio (mostly) doesn't use the hw:X devices directly. Instead, it > > uses logical names like "front", "hdmi", "iec958", etc. Speaking of HDMI > > specifically, PulseAudio uses devices from "hdmi:X,0" to "hdmi:X,7". > > With this new dynamic PCM system, do these logical names still work? > > Unfortunately, this doesn't work for HDA as is, because of the > terribly arcane secret. For keeping the compatibility with the old > config, there is a static mapping of the hdmi:x,y and hw:x,z. Yes, the mapping is like this: y = 0, z = 3 y = 1, z = 7 y = 2, z = 8 y = 3, z = 9 etc. Now I'm wondering if this is HDA specific (your wording suggests that it is)? For HDMI ELD information and jack detection support, PulseAudio has been assuming this particular mapping. If other drivers have been using a different mapping, then ELD and jack detection support has been and continues to be broken for other drivers in PA. -- Tanu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] scripts/kernel-doc: Adding cross-reference links to html documentation.
Functions, Structs and Parameters definitions on kernel documentation
are pure cosmetic, it only highlights the element.
To ease the navigation in the documentation we should use inside
those tags so readers can easily jump between methods directly.
This was discussed in 2014[1] and is implemented by getting a list
of from the DocBook XML to generate a database. Then it looks
for , and tags that matches the ones in
the database. As it only links existent references, no broken links are
added.
[1] - lists.freedesktop.org/archives/dri-devel/2014-August/065404.html
Signed-off-by: Danilo Cesar Lemes de Paula
Cc: Randy Dunlap
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: Jonathan Corbet
Cc: Herbert Xu
Cc: Stephan Mueller
Cc: Michal Marek
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: intel-gfx
Cc: dri-devel
---
To understand a bit more of what this patch is trying to acomplish you can find
two examples of the old and new htmldocs outputs:
OLD:
https://people.collabora.com/~danilo/intel/Documentation.old/DocBook/drm/API-drm-crtc-vblank-on.html
NEW:
https://people.collabora.com/~danilo/intel/Documentation.new/DocBook/drm/API-drm-crtc-vblank-on.html
Documentation/DocBook/Makefile | 34 +---
scripts/kernel-doc-xml-ref | 181 +
2 files changed, 202 insertions(+), 13 deletions(-)
create mode 100755 scripts/kernel-doc-xml-ref
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index b6a6a2e..8aea45a 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -64,8 +64,9 @@ installmandocs: mandocs
###
#External programs used
-KERNELDOC = $(srctree)/scripts/kernel-doc
-DOCPROC = $(objtree)/scripts/docproc
+KERNELDOCXMLREF = $(srctree)/scripts/kernel-doc-xml-ref
+KERNELDOC = $(srctree)/scripts/kernel-doc
+DOCPROC = $(objtree)/scripts/docproc
XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl
XMLTOFLAGS += --skip-validation
@@ -89,7 +90,7 @@ define rule_docproc
) > $(dir $@).$(notdir $@).cmd
endef
-%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE
+%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE
$(call if_changed_rule,docproc)
# Tell kbuild to always build the programs
@@ -139,8 +140,12 @@ quiet_cmd_db2html = HTML$@
cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
echo ' \
$(patsubst %.html,%,$(notdir $@))' > $@
+%.aux.xml: %.xml
+ @rm -rf $@
+ (cat $< | egrep "^
$<.db)
+ $(KERNELDOCXMLREF) -db $<.db $< > $@
-%.html:%.xml
+%.html:%.aux.xml
@(which xmlto > /dev/null 2>&1) || \
(echo "*** You need to install xmlto ***"; \
exit 1)
@@ -209,15 +214,18 @@ dochelp:
###
# Temporary files left by various tools
clean-files := $(DOCBOOKS) \
- $(patsubst %.xml, %.dvi, $(DOCBOOKS)) \
- $(patsubst %.xml, %.aux, $(DOCBOOKS)) \
- $(patsubst %.xml, %.tex, $(DOCBOOKS)) \
- $(patsubst %.xml, %.log, $(DOCBOOKS)) \
- $(patsubst %.xml, %.out, $(DOCBOOKS)) \
- $(patsubst %.xml, %.ps, $(DOCBOOKS)) \
- $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \
- $(patsubst %.xml, %.html, $(DOCBOOKS)) \
- $(patsubst %.xml, %.9,$(DOCBOOKS)) \
+ $(patsubst %.xml, %.dvi, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.aux, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.tex, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.log, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.out, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.ps, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.html,$(DOCBOOKS)) \
+ $(patsubst %.xml, %.9, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.aux.xml, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.xml.db, $(DOCBOOKS)) \
+ $(patsubst %.xml, %.xml, $(DOCBOOKS)) \
$(index)
clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man
diff --git a/scripts/kernel-doc-xml-ref b/scripts/kernel-doc-xml-ref
new file mode 100755
index 000..c61cdad
--- /dev/null
+++ b/scripts/kernel-doc-xml-ref
@@ -0,0 +1,181 @@
+#!/usr/bin/perl -w
+
+use strict;
+
+## Copyright (C) 2015 Intel Corporation ##
+###
+## This software falls under the GNU General Public License. ##
+## Please read the COPYING file for more information ##
+#
+#
+# This software reads a XML file and a list of valid interal
+# references to replace Docbook tags with links.
+#
+# usage:
+# kernel-doc-xml-ref -db filename
+# xml filename > outputfile
+
+# read arguments
+if ($#ARGV != 2) {
+ usage();
+}
+
+#Holds the database filename
+my $databasefile;
+my @database;
+
+#holds the inputfile
+my $inputfile;
+my $errors = 0;
+
+my %highlights = (
+ "(.*?)",
+ "\"\" . convert_function(\$1, \$lin
Re: [Intel-gfx] [PATCH libdrm] intel: Add EXEC_OBJECT_SUPPORTS_48BADDRESS flag.
On 23/06/15 13:21, Michel Thierry wrote:
> Gen8+ supports 48-bit virtual addresses, but some objects must always be
> allocated inside the 32-bit address range.
>
> In specific, any resource used with flat/heapless (0x-0xf000)
> General State Heap (GSH) or Intruction State Heap (ISH) must be in a
> 32-bit range, because the General State Offset and Instruction State Offset
> are limited to 32-bits.
>
> Provide a flag to set when the 4GB limit is not necessary in a given bo.
> 48-bit range will only be used when explicitly requested.
>
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Michel Thierry
> ---
> include/drm/i915_drm.h| 3 ++-
> intel/intel_bufmgr.c | 12
> intel/intel_bufmgr.h | 2 ++
> intel/intel_bufmgr_gem.c | 48
> +++
> intel/intel_bufmgr_priv.h | 11 +++
> 5 files changed, 71 insertions(+), 5 deletions(-)
>
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index ded43b1..d6fb99d 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -680,7 +680,8 @@ struct drm_i915_gem_exec_object2 {
> #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
> #define EXEC_OBJECT_NEEDS_GTT(1<<1)
> #define EXEC_OBJECT_WRITE(1<<2)
> -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
> +#define EXEC_OBJECT_SUPPORTS_48BADDRESS (1<<3)
Please change the name, so you don't concatenate the "B" of "48B" with
the "A" of "ADDRESS", making something which appears to relate to a "BAD
DRESS". .._48B_ADDRESS.. and corresponding lowercase variants would be
fine :)
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/lrc: Update PDPx registers with lri commands
Michel Thierry writes:
> A safer way to update the PDPx registers is sending lri commands, added
> in the ring before the batchbuffer start. Otherwise, the ctx must be idle
> before trying to change anything (but the ring-tail) in the ctx image. An
> example where the ctx won't be idle is lite-restore.
>
> This patch depends on 5b7e4c9ce ("drm/i915/gtt: Mark TLBS dirty for gen8+").
>
> v2: Combine lri writes (and save 8 commands). (Mika)
> v3: Rebase after ring/req changes, and removed references to deprecated
> patches.
>
> Cc: Dave Gordon
> Cc: Mika Kuoppala
> Signed-off-by: Michel Thierry
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 42
>
> 1 file changed, 42 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index d527b7b..e87d74c 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1379,6 +1379,34 @@ static int gen9_init_render_ring(struct
> intel_engine_cs *ring)
> return init_workarounds_ring(ring);
> }
>
> +static int intel_logical_ring_emit_pdps(struct drm_i915_gem_request *req)
> +{
> + struct i915_hw_ppgtt *ppgtt = req->ctx->ppgtt;
> + struct intel_engine_cs *ring = req->ring;
> + struct intel_ringbuffer *ringbuf = req->ringbuf;
> + const int num_lri_cmds = GEN8_LEGACY_PDPES * 2;
> + int i, ret;
> +
> + ret = intel_logical_ring_begin(req, num_lri_cmds * 2 + 2);
> + if (ret)
> + return ret;
> +
> + intel_logical_ring_emit(ringbuf, MI_LOAD_REGISTER_IMM(num_lri_cmds));
> + for (i = GEN8_LEGACY_PDPES - 1; i >= 0; i--) {
> + const dma_addr_t pd_daddr = i915_page_dir_dma_addr(ppgtt, i);
> +
> + intel_logical_ring_emit(ringbuf, GEN8_RING_PDP_UDW(ring, i));
> + intel_logical_ring_emit(ringbuf, upper_32_bits(pd_daddr));
> + intel_logical_ring_emit(ringbuf, GEN8_RING_PDP_LDW(ring, i));
> + intel_logical_ring_emit(ringbuf, lower_32_bits(pd_daddr));
> + }
> +
> + intel_logical_ring_emit(ringbuf, MI_NOOP);
> + intel_logical_ring_advance(ringbuf);
> +
> + return 0;
> +}
> +
> static int gen8_emit_bb_start(struct drm_i915_gem_request *req,
> u64 offset, unsigned dispatch_flags)
> {
> @@ -1386,6 +1414,20 @@ static int gen8_emit_bb_start(struct
> drm_i915_gem_request *req,
> bool ppgtt = !(dispatch_flags & I915_DISPATCH_SECURE);
> int ret;
>
> + /* Don't rely in hw updating PDPs, specially in lite-restore.
> + * Ideally, we should set Force PD Restore in ctx descriptor,
> + * but we can't. Force Restore would be a second option, but
> + * it is unsafe in case of lite-restore (because the ctx is
> + * not idle). */
> + if (req->ctx->ppgtt &&
> + (intel_ring_flag(req->ring) & req->ctx->ppgtt->pd_dirty_rings)) {
> + ret = intel_logical_ring_emit_pdps(req);
> + if (ret)
> + return ret;
> +
> + req->ctx->ppgtt->pd_dirty_rings &= ~intel_ring_flag(req->ring);
> + }
> +
> ret = intel_logical_ring_begin(req, 4);
> if (ret)
> return ret;
> --
> 2.4.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] sna: Correct misspelled cacheing->caching in comments
On 24/06/15 11:04, Chris Wilson wrote: > On Tue, Jun 23, 2015 at 07:45:42AM +0200, Sedat Dilek wrote: >> I have seen this typo once and added an entry to codespell's dictionary.txt >> file. >> >> $ diff -uprN /usr/share/codespell/dictionary.txt.orig >> /usr/share/codespell/dictionary.txt >> --- /usr/share/codespell/dictionary.txt.orig2015-06-09 >> 20:49:25.0 +0200 >> +++ /usr/share/codespell/dictionary.txt 2015-06-23 07:37:35.893689539 +0200 >> @@ -625,6 +625,7 @@ burried->buried >> busineses->business, businesses, >> busness->business >> bussiness->business >> +cacheing->caching >> caculater->calculator >> cacuses->caucuses >> cahracters->characters >> >> There some other places where this typo occurs: >> >> [ src/sna/kgem.c ] >> >> 298:static void assert_cacheing(struct kgem *kgem, struct kgem_bo *bo) >> 324:#define assert_cacheing(kgem, bo) >> 2455: assert_cacheing(kgem, bo); >> 2841: assert_cacheing(kgem, bo); >> >> It's up to Chris what to do with this. > > I just can't get past reading 'caching' as two hard Cs and so it feels > weird. That would be Italian. Cache (and "cachet") come from French "cacher" (to hide), so the "ch" is (almost) the same as in "chef" or "chauffeur". We could switch to using the Esperanto spelling, "kaŝi" and the corresponding hardware term "kaŝmemoro" :) .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] scripts/kernel-doc: Adding cross-reference links to html documentation.
On 06/24/2015 06:22 PM, Daniel Vetter wrote: > On Wed, Jun 24, 2015 at 04:10:24PM -0300, Danilo Cesar Lemes de Paula wrote: >> Functions, Structs and Parameters definitions on kernel documentation >> are pure cosmetic, it only highlights the element. >> >> To ease the navigation in the documentation we should use inside >> those tags so readers can easily jump between methods directly. >> >> This was discussed in 2014[1] and is implemented by getting a list >> of from the DocBook XML to generate a database. Then it looks >> for , and tags that matches the ones in >> the database. As it only links existent references, no broken links are >> added. >> >> [1] - lists.freedesktop.org/archives/dri-devel/2014-August/065404.html >> >> Signed-off-by: Danilo Cesar Lemes de Paula >> Cc: Randy Dunlap >> Cc: Daniel Vetter >> Cc: Laurent Pinchart >> Cc: linux-...@vger.kernel.org >> Cc: intel-gfx >> Cc: dri-devel >> --- >> To understand a bit more of what this patch is trying to acomplish you can >> find >> two examples of the old and new htmldocs outputs: >> OLD: >> https://people.collabora.com/~danilo/intel/Documentation.old/DocBook/drm/API-drm-crtc-vblank-on.html >> NEW: >> https://people.collabora.com/~danilo/intel/Documentation.new/DocBook/drm/API-drm-crtc-vblank-on.html > > Already discussed on irc With Danilo but here for the record: I really > like this since it massively improves the usefulness of the docbooks we > have. One small thing I noticed though while clicking a bit more through > the generated html: It also generates selflinks, i.e. drm_crtc_vblank_on > links to itself. That one is a bit confusing. Could we filter out > self-links somehow on the reference sections? Yes we could! I'm sending a reviewed patch in a few minutes. - Danilo Cesar > -Daniel > >> >> Documentation/DocBook/Makefile | 34 +--- >> scripts/kernel-doc-xml-ref | 176 >> + >> 2 files changed, 197 insertions(+), 13 deletions(-) >> create mode 100755 scripts/kernel-doc-xml-ref >> >> diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile >> index b6a6a2e..8aea45a 100644 >> --- a/Documentation/DocBook/Makefile >> +++ b/Documentation/DocBook/Makefile >> @@ -64,8 +64,9 @@ installmandocs: mandocs >> >> ### >> #External programs used >> -KERNELDOC = $(srctree)/scripts/kernel-doc >> -DOCPROC = $(objtree)/scripts/docproc >> +KERNELDOCXMLREF = $(srctree)/scripts/kernel-doc-xml-ref >> +KERNELDOC = $(srctree)/scripts/kernel-doc >> +DOCPROC = $(objtree)/scripts/docproc >> >> XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl >> XMLTOFLAGS += --skip-validation >> @@ -89,7 +90,7 @@ define rule_docproc >> ) > $(dir $@).$(notdir $@).cmd >> endef >> >> -%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE >> +%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE >> $(call if_changed_rule,docproc) >> >> # Tell kbuild to always build the programs >> @@ -139,8 +140,12 @@ quiet_cmd_db2html = HTML$@ >>cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< >> && \ >> echo ' \ >> $(patsubst %.html,%,$(notdir $@))' > $@ >> +%.aux.xml: %.xml >> +@rm -rf $@ >> +(cat $< | egrep "^ >> $<.db) >> +$(KERNELDOCXMLREF) -db $<.db $< > $@ >> >> -%.html: %.xml >> +%.html: %.aux.xml >> @(which xmlto > /dev/null 2>&1) || \ >> (echo "*** You need to install xmlto ***"; \ >>exit 1) >> @@ -209,15 +214,18 @@ dochelp: >> ### >> # Temporary files left by various tools >> clean-files := $(DOCBOOKS) \ >> -$(patsubst %.xml, %.dvi, $(DOCBOOKS)) \ >> -$(patsubst %.xml, %.aux, $(DOCBOOKS)) \ >> -$(patsubst %.xml, %.tex, $(DOCBOOKS)) \ >> -$(patsubst %.xml, %.log, $(DOCBOOKS)) \ >> -$(patsubst %.xml, %.out, $(DOCBOOKS)) \ >> -$(patsubst %.xml, %.ps, $(DOCBOOKS)) \ >> -$(patsubst %.xml, %.pdf, $(DOCBOOKS)) \ >> -$(patsubst %.xml, %.html, $(DOCBOOKS)) \ >> -$(patsubst %.xml, %.9,$(DOCBOOKS)) \ >> +$(patsubst %.xml, %.dvi, $(DOCBOOKS)) \ >> +$(patsubst %.xml, %.aux, $(DOCBOOKS)) \ >> +$(patsubst %.xml, %.tex, $(DOCBOOKS)) \ >> +$(patsubst %.xml, %.log, $(DOCBOOKS)) \ >> +$(patsubst %.xml, %.out, $(DOCBOOKS)) \ >> +$(patsubst %.xml, %.ps, $(DOCBOOKS)) \ >> +$(patsubst %.xml, %.pdf, $(DOCBOOKS)) \ >> +$(patsubst %.xml, %.html,$(DOCBOOKS)) \ >> +$(patsubst %.xml, %.9, $(DOCBOOKS)) \ >> +$(patsubst %.xml, %.aux.xml, $(DOCBOOKS)) \ >> +$(patsubst %.xml, %.xml.db, $(DOCBOOKS)) \ >> +$(patsubst %.xml, %.xml, $(DOCBOOKS)) \ >> $(index) >> >> clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man >> diff --git a/scripts/kernel-doc-xml-ref b/scripts/kernel-doc-xml-ref >> new file mode 100755 >> index 000..756e897 >> --- /dev/null >> +++ b/scripts/kernel-doc-xml-ref >> @@ -0,0 +1,176 @@ >> +#!/usr/bin/perl -w >> + >> +use stric
Re: [Intel-gfx] [PATCH resend 3/5] drm/i915: Enable resource streamer on Execlists
On 16/06/2015 11:39, Abdiel Janulgue wrote: GEN8 and above uses Execlists by default instead of the legacy ringbuffer for batch execution. This patch enables the resource streamer bits when required. Patch is based on the initial work by Minu Mathai This version also adds the required bits to enable GEN8 Resource Streamer context save and restore for Execlists. Cc: ville.syrj...@linux.intel.com Signed-off-by: Abdiel Janulgue --- drivers/gpu/drm/i915/intel_lrc.c | 8 ++-- drivers/gpu/drm/i915/intel_lrc.h | 1 + 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index fcb074b..b015e96 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1172,7 +1172,10 @@ static int gen8_emit_bb_start(struct intel_ringbuffer *ringbuf, return ret; /* FIXME(BDW): Address space and security selectors. */ - intel_logical_ring_emit(ringbuf, MI_BATCH_BUFFER_START_GEN8 | (ppgtt<<8)); + intel_logical_ring_emit(ringbuf, MI_BATCH_BUFFER_START_GEN8 | + (ppgtt<<8) | + (dispatch_flags & I915_DISPATCH_RS ? +MI_BATCH_RESOURCE_STREAMER : 0)); intel_logical_ring_emit(ringbuf, lower_32_bits(offset)); intel_logical_ring_emit(ringbuf, upper_32_bits(offset)); intel_logical_ring_emit(ringbuf, MI_NOOP); @@ -1726,7 +1729,8 @@ populate_lr_context(struct intel_context *ctx, struct drm_i915_gem_object *ctx_o reg_state[CTX_CONTEXT_CONTROL] = RING_CONTEXT_CONTROL(ring); reg_state[CTX_CONTEXT_CONTROL+1] = _MASKED_BIT_ENABLE(CTX_CTRL_INHIBIT_SYN_CTX_SWITCH | - CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT); + CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT | + CTX_CTRL_RS_CTX_ENABLE); reg_state[CTX_RING_HEAD] = RING_HEAD(ring->mmio_base); reg_state[CTX_RING_HEAD+1] = 0; reg_state[CTX_RING_TAIL] = RING_TAIL(ring->mmio_base); diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h index adb731e4..de6087a 100644 --- a/drivers/gpu/drm/i915/intel_lrc.h +++ b/drivers/gpu/drm/i915/intel_lrc.h @@ -32,6 +32,7 @@ #define RING_CONTEXT_CONTROL(ring)((ring)->mmio_base+0x244) #define CTX_CTRL_INHIBIT_SYN_CTX_SWITCH (1 << 3) #define CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT (1 << 0) +#define CTX_CTRL_RS_CTX_ENABLE(1 << 1) #define RING_CONTEXT_STATUS_BUF(ring) ((ring)->mmio_base+0x370) #define RING_CONTEXT_STATUS_PTR(ring) ((ring)->mmio_base+0x3a0) looks good to me, Reviewed-by: Arun Siluvery regards Arun ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 00/18] Generic DRRS implementation across the encoders
Display Refresh Rate Switching (DRRS) is a power conservation feature which enables swtching between low and high refresh rates, dynamically, based on the usage scenario to save power. This feature is applicable for internal panels. Indication that the panel supports DRRS is given by the panel EDID, which would list multiple refresh rates for one resolution along with VBT fields like drrs_min_vrefresh. DRRS is of 2 types - static and seamless. Static needs full modeset. Which can be used in docking and undocking scenarios. Seamless DRRS involves changing RR without any visual effect to the user and can be used during normal system usage. This is done by programming certain registers. Support for static/seamless DRRS may be indicated in the VBT based on inputs from the panel spec. We have implemented two DRRS use case scenrios : 1. Idleness DRRS, 2. Media playback DRRS (Content's FPS based) Idleness DRRS:- The implementation is based on frontbuffer tracking implementation. When there is a disturbance on the screen triggered by user activity or a periodic system activity, DRRS is disabled (RR is changed to high RR). When there is no movement on screen, after a timeout, a switch to low RR is made. For integration with frontbuffer tracking code, intel_drrs_invalidate() and intel_drrs_flush() are called. Media playback DRRS (Content's FPS based): Based on the content's Frames Per Second, minimum required vrefresh is called in userspace. If the panel supports the minimum required vrefresh and if the DRRS is supported on the platform, userspace will make a modeset request with same mode and FB but with different vrefresh. Panel's vrefresh range will be exposed through connector's modelist and connector property is created to expose the DRRS capability to the userspace. In DRRS state machine Media plyabck DRRS holds the highest priority. Idleness DRRS is disabled as soon as Media playback DRRS is requested. Idleness DRRS is reenabled when the userspace indicates the exit of Media playback DRRS by requesting for highest vrefresh supported. NOTE: 1. DRM documentation will be made once the RFC is closed along with IGT. 2. Currently in RFC, platform support is developed only for VLV. it will be extended to other platform once the design is approved. 3. Basic design of DSI DRRS and Content based DRRS is functionally tested on Android(VLV & CHT). Ramalingam C (18): drm/i915: Removing the eDP specific DRRS implementation drm/i915: Generic DRRS state Machine drm/i915: Addition of the drrs_min_vrefresh in VBT drm/i915: Implementation of Generic DSI DRRS drm/i915: Adjusting the pclk for dual link and burst mode drm/i915: VLV dsi drrs support drm/i915: Generic eDP DRRS implementation drm/i915: VLV eDP DRRS methods drm/i915: Cloned mode check drm/i915: Initializing DRRS for all connectors drm/i915: Updating the crtc modes in DRRS transitions drm/i915: Redesigning dp_set_m_n to receive divider values drm/i915: MEDIA_RR support in general DRRS state machine drm/i915: MEDIA_RR support in eDP DRRS module drm/i915: MEDIA_RR support in DSI DRRS module drm/i915: Filtering media playback DRRS requests drm/i915: Addition of downclock mode to connector modelist drm/i915: Connector property for DRRS capability drivers/gpu/drm/i915/Makefile|3 + drivers/gpu/drm/i915/i915_debugfs.c | 110 - drivers/gpu/drm/i915/i915_drv.h | 91 +++- drivers/gpu/drm/i915/i915_reg.h |4 + drivers/gpu/drm/i915/intel_bios.c|3 + drivers/gpu/drm/i915/intel_bios.h|9 +- drivers/gpu/drm/i915/intel_ddi.c |2 - drivers/gpu/drm/i915/intel_display.c | 57 ++- drivers/gpu/drm/i915/intel_dp.c | 397 +--- drivers/gpu/drm/i915/intel_drrs.c| 728 ++ drivers/gpu/drm/i915/intel_drrs.h| 38 ++ drivers/gpu/drm/i915/intel_drv.h | 45 +- drivers/gpu/drm/i915/intel_dsi.c | 29 +- drivers/gpu/drm/i915/intel_dsi.h |3 + drivers/gpu/drm/i915/intel_dsi_drrs.c| 415 + drivers/gpu/drm/i915/intel_dsi_drrs.h| 66 +++ drivers/gpu/drm/i915/intel_dsi_pll.c | 303 +++-- drivers/gpu/drm/i915/intel_edp_drrs.c| 196 drivers/gpu/drm/i915/intel_edp_drrs.h| 29 ++ drivers/gpu/drm/i915/intel_frontbuffer.c |4 +- drivers/gpu/drm/i915/intel_modes.c | 28 ++ 21 files changed, 1959 insertions(+), 601 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_drrs.c create mode 100644 drivers/gpu/drm/i915/intel_drrs.h create mode 100644 drivers/gpu/drm/i915/intel_dsi_drrs.c create mode 100644 drivers/gpu/drm/i915/intel_dsi_drrs.h create mode 100644 drivers/gpu/drm/i915/intel_edp_drrs.c create mode 100644 drivers/gpu/drm/i915/intel_edp_drrs.h -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@li
[Intel-gfx] [RFC PATCH 18/18] drm/i915: Connector property for DRRS capability
DRRS capability on each connector is exposed to userspace through
drm connector property.
In this change one drm property is created and attached with each
connector. And when DRRS is successfully initialized for a connector,
drrs connector property is set with appropriate value.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c|1 +
drivers/gpu/drm/i915/intel_drrs.c |5 +
drivers/gpu/drm/i915/intel_drv.h |6 ++
drivers/gpu/drm/i915/intel_dsi.c |8
drivers/gpu/drm/i915/intel_modes.c | 28
5 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9ded4d1..22001b6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5063,6 +5063,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
+ intel_attach_drrs_capability_property(connector);
intel_dp->color_range_auto = true;
if (is_edp(intel_dp)) {
diff --git a/drivers/gpu/drm/i915/intel_drrs.c
b/drivers/gpu/drm/i915/intel_drrs.c
index 9634254..89f2d39 100644
--- a/drivers/gpu/drm/i915/intel_drrs.c
+++ b/drivers/gpu/drm/i915/intel_drrs.c
@@ -684,6 +684,11 @@ int intel_drrs_init(struct drm_device *dev,
mutex_init(&drrs->drrs_mutex);
drrs->resume_idleness_detection = false;
drrs->drrs_state.current_rr_type = DRRS_HIGH_RR;
+
+ /* DRRS connector property */
+ drm_object_property_set_value(&intel_connector->base.base,
+ intel_connector->drrs_capability_property,
+ drrs->drrs_state.type);
DRM_INFO("SEAMLESS DRRS supported on this panel.\n");
return 0;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3a5cff8..97a5af8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -231,6 +231,9 @@ struct intel_connector {
void *port; /* store this opaque as its illegal to dereference it */
struct intel_dp *mst_port;
+
+ /* DRRS capability */
+ struct drm_property *drrs_capability_property;
};
typedef struct dpll {
@@ -1266,6 +1269,9 @@ int intel_ddc_get_modes(struct drm_connector *c, struct
i2c_adapter *adapter);
void intel_attach_force_audio_property(struct drm_connector *connector);
void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
+/* DRRS function */
+void intel_attach_drrs_capability_property(struct drm_connector *connector);
+
/* intel_overlay.c */
void intel_setup_overlay(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 503f3de..2efad4b 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -968,6 +968,13 @@ static void intel_dsi_encoder_destroy(struct drm_encoder
*encoder)
intel_encoder_destroy(encoder);
}
+static void
+intel_dsi_add_properties(struct intel_dsi *intel_dsi,
+ struct drm_connector *connector)
+{
+ intel_attach_drrs_capability_property(connector);
+}
+
static const struct drm_encoder_funcs intel_dsi_funcs = {
.destroy = intel_dsi_encoder_destroy,
};
@@ -1091,6 +1098,7 @@ void intel_dsi_init(struct drm_device *dev)
connector->interlace_allowed = false;
connector->doublescan_allowed = false;
+ intel_dsi_add_properties(intel_dsi, connector);
intel_connector_attach_encoder(intel_connector, intel_encoder);
drm_connector_register(connector);
diff --git a/drivers/gpu/drm/i915/intel_modes.c
b/drivers/gpu/drm/i915/intel_modes.c
index 0e860f3..f6c466c 100644
--- a/drivers/gpu/drm/i915/intel_modes.c
+++ b/drivers/gpu/drm/i915/intel_modes.c
@@ -126,3 +126,31 @@ intel_attach_broadcast_rgb_property(struct drm_connector
*connector)
drm_object_attach_property(&connector->base, prop, 0);
}
+
+static const struct drm_prop_enum_list drrs_capability_names[] = {
+ { DRRS_NOT_SUPPORTED, "Off" },
+ { STATIC_DRRS_SUPPORT, "Off-Static" },
+ { SEAMLESS_DRRS_SUPPORT, "Seamless-HW" },
+ { SEAMLESS_DRRS_SUPPORT_SW, "Seamless-SW" },
+};
+
+void intel_attach_drrs_capability_property(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct intel_connector *intel_connector = to_intel_connector(connector);
+ struct drm_property *prop;
+
+ prop = intel_connector->drrs_capability_property;
+ if (prop == NULL) {
+ prop = drm_property_create_enum(dev, 0,
+ "drrs_capability",
+ drrs_capability_names,
+ ARRAY_SIZE(drrs_capability_names));
+ if (prop == NULL) {
+
[Intel-gfx] [RFC PATCH 13/18] drm/i915: MEDIA_RR support in general DRRS state machine
Based on the minimum requirement of the vrefresh to support a
content's playback, we can place a drrs request from userspace
to kernel. For example 24FPS video content can be played at
48 vrefresh without any quality degradation.
This patch implements required changes in generic DRRS state machine.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_drv.h |7 ++
drivers/gpu/drm/i915/intel_drrs.c | 161 +++--
drivers/gpu/drm/i915/intel_drrs.h |5 +-
3 files changed, 166 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 677293d..dbdba44 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -948,10 +948,12 @@ enum drrs_support_type {
* Different DRRS States:
* DRRS_HIGH_RR: Refreshrate of Fixed mode. [Maximum Vrefresh]
* DRRS_LOW_RR : Refreshrate of Downclock mode. [Minimum vrefresh]
+ * DRRS_MEDIA_RR: Refreshrate of requested from userspace. [= Min]
*/
enum drrs_refresh_rate_type {
DRRS_HIGH_RR,
DRRS_LOW_RR,
+ DRRS_MEDIA_RR,
DRRS_MAX_RR,
};
@@ -983,6 +985,8 @@ struct drrs_encoder_ops {
void (*exit)(struct i915_drrs *);
void (*set_drrs_state)(struct i915_drrs *);
bool (*is_drrs_hr_state_pending)(struct i915_drrs *);
+ bool (*is_mp_drrs_req)(struct i915_drrs *,
+ struct drm_display_mode *);
};
struct i915_drrs {
@@ -992,6 +996,9 @@ struct i915_drrs {
/* Whether DRRS is supported on this Panel */
bool has_drrs;
+ /* Flag to resume the Idleness DRRS from Media Playback */
+ bool resume_idleness_detection;
+
/* Holds the DRRS state machine states */
struct drrs_info drrs_state;
diff --git a/drivers/gpu/drm/i915/intel_drrs.c
b/drivers/gpu/drm/i915/intel_drrs.c
index 2901832..7f66be4 100644
--- a/drivers/gpu/drm/i915/intel_drrs.c
+++ b/drivers/gpu/drm/i915/intel_drrs.c
@@ -111,6 +111,13 @@ bool is_cloned_mode_active(struct drm_device *dev)
return false;
}
+static inline bool
+is_media_playback_drrs_in_progress(struct drrs_info *drrs_state)
+{
+ return drrs_state->current_rr_type == DRRS_MEDIA_RR ||
+ drrs_state->target_rr_type == DRRS_MEDIA_RR;
+}
+
void intel_set_drrs_state(struct i915_drrs *drrs)
{
struct drrs_info *drrs_state;
@@ -157,7 +164,8 @@ void intel_set_drrs_state(struct i915_drrs *drrs)
return;
}
- if (drrs_state->target_rr_type == drrs_state->current_rr_type) {
+ if (drrs_state->target_rr_type == drrs_state->current_rr_type &&
+ drrs_state->current_rr_type != DRRS_MEDIA_RR) {
DRM_INFO("Requested for previously set RR. Ignoring\n");
return;
}
@@ -170,19 +178,24 @@ void intel_set_drrs_state(struct i915_drrs *drrs)
* As only DSI has SEAMLESS_DRRS_SUPPORT_SW.
*/
/*
-* TODO: Protect the access to the crtc mode with corresponding
+* Protect the access to the crtc mode with corresponding
* mutex in case of Idleness DRRS. As media playback update
* will happen under crtc modeset lock protection
*/
- drm_modeset_lock(&intel_crtc->base.mutex, NULL);
+ if (!is_media_playback_drrs_in_progress(drrs_state))
+ drm_modeset_lock(&intel_crtc->base.mutex, NULL);
intel_crtc->base.mode.clock = target_mode->clock;
intel_crtc->base.mode.vrefresh = target_mode->vrefresh;
intel_crtc->config->base.adjusted_mode.clock =
target_mode->clock;
intel_crtc->config->base.adjusted_mode.vrefresh =
target_mode->vrefresh;
- drm_modeset_unlock(&intel_crtc->base.mutex);
+ if (!is_media_playback_drrs_in_progress(drrs_state))
+ drm_modeset_unlock(&intel_crtc->base.mutex);
+ if (drrs_state->current_rr_type == DRRS_MEDIA_RR &&
+ drrs_state->target_rr_type == DRRS_HIGH_RR)
+ drrs->resume_idleness_detection = true;
drrs_state->current_rr_type = drrs_state->target_rr_type;
DRM_INFO("Refresh Rate set to : %dHz\n", refresh_rate);
}
@@ -203,6 +216,11 @@ static void intel_idleness_drrs_work_fn(struct work_struct
*__work)
return;
mutex_lock(&drrs->drrs_mutex);
+ if (is_media_playback_drrs_in_progress(&drrs->drrs_state)) {
+ mutex_unlock(&drrs->drrs_mutex);
+ return;
+ }
+
if (panel->target_mode != NULL)
DRM_ERROR("FIXME: We shouldn't be here\n");
@@ -229,7 +247,7 @@ static void intel_cancel_id
[Intel-gfx] [RFC PATCH 17/18] drm/i915: Addition of downclock mode to connector modelist
If DSI panel has the downclock mode supported, add that in the
connector's mode list.
This is needed by userspace apps to identify the range of vrefresh
rates supported by panel incase of the media playback DRRS.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dsi.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 98998e9..503f3de 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -912,23 +912,38 @@ static int intel_dsi_get_modes(struct drm_connector
*connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
struct drm_display_mode *mode;
+ int count = 0;
DRM_DEBUG_KMS("\n");
if (!intel_connector->panel.fixed_mode) {
DRM_DEBUG_KMS("no fixed mode\n");
- return 0;
+ return count;
}
mode = drm_mode_duplicate(connector->dev,
intel_connector->panel.fixed_mode);
if (!mode) {
DRM_DEBUG_KMS("drm_mode_duplicate failed\n");
- return 0;
+ return count;
}
drm_mode_probed_add(connector, mode);
- return 1;
+ count++;
+
+ if (intel_connector->panel.downclock_mode) {
+ mode = drm_mode_duplicate(connector->dev,
+ intel_connector->panel.downclock_mode);
+ if (!mode) {
+ DRM_DEBUG_KMS("drm_mode_duplicate failed\n");
+ return count;
+ }
+
+ drm_mode_probed_add(connector, mode);
+ count++;
+ }
+
+ return count;
}
static void intel_dsi_connector_destroy(struct drm_connector *connector)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 15/18] drm/i915: MEDIA_RR support in DSI DRRS module
Content based DRRS support is implemented in
DSI DRRS module also.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dsi_drrs.c | 60 +++--
1 file changed, 58 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_drrs.c
b/drivers/gpu/drm/i915/intel_dsi_drrs.c
index d4bb70a..4ff06b8 100644
--- a/drivers/gpu/drm/i915/intel_dsi_drrs.c
+++ b/drivers/gpu/drm/i915/intel_dsi_drrs.c
@@ -19,6 +19,7 @@
#include "intel_drv.h"
#include "intel_dsi.h"
+#include "intel_drrs.h"
/*
* VLV and CHV platform code
@@ -50,9 +51,19 @@ static void intel_mipi_drrs_work_fn(struct work_struct
*__work)
struct dsi_drrs *dsi_drrs = &intel_dsi->dsi_drrs;
struct dsi_mnp *dsi_mnp;
struct drm_display_mode *prev_mode = NULL;
+ bool resume_idleness_detection = false;
bool fallback_attempt = false;
int ret, retry_cnt = 3;
+ if (work->target_rr_type == DRRS_MEDIA_RR) {
+ ret = dsi_drrs->ops->mnp_calculate_for_mode(
+ intel_encoder, &dsi_drrs->mnp[DRRS_MEDIA_RR],
+ drrs->connector->panel.target_mode);
+ if (ret < 0) {
+ DRM_ERROR("mnp calculation failed\n");
+ goto out;
+ }
+ }
init:
dsi_mnp = &dsi_drrs->mnp[work->target_rr_type];
DRM_DEBUG("Refresh rate Type: %d-->%d\n",
@@ -60,6 +71,10 @@ init:
work->target_rr_type);
DRM_DEBUG("Target RR: %d\n", work->target_mode->vrefresh);
+ if (drrs->drrs_state.current_rr_type == DRRS_MEDIA_RR &&
+ work->target_rr_type == DRRS_HIGH_RR)
+ resume_idleness_detection = true;
+
retry:
if (!intel_crtc || !intel_crtc->active)
goto out;
@@ -87,6 +102,11 @@ retry:
/* TODO: Update drain ladency with watermark */
+ if (resume_idleness_detection) {
+ intel_disable_idleness_drrs(drrs);
+ intel_enable_idleness_drrs(drrs);
+ }
+
} else if (ret == -ETIMEDOUT && retry_cnt) {
/* Timed out. But still attempts are allowed */
@@ -111,10 +131,14 @@ retry:
work->target_rr_type = drrs->drrs_state.target_rr_type;
drm_mode_destroy(intel_encoder->base.dev, work->target_mode);
- if (work->target_rr_type == DRRS_HIGH_RR)
+ if (work->target_rr_type == DRRS_HIGH_RR) {
prev_mode = drrs->connector->panel.fixed_mode;
- else if (work->target_rr_type == DRRS_LOW_RR)
+ resume_idleness_detection = true;
+ } else if (work->target_rr_type == DRRS_LOW_RR) {
prev_mode = drrs->connector->panel.downclock_mode;
+ } else if (work->target_rr_type == DRRS_MEDIA_RR) {
+ prev_mode = drrs->connector->panel.target_mode;
+ }
work->target_mode = drm_mode_duplicate(intel_encoder->base.dev,
prev_mode);
@@ -137,6 +161,37 @@ out:
work->work_completed = true;
}
+/*
+ * As a part of Media playback request filtering
+ * we validate the incoming request wrt deferred works
+ * of MIPI PLL programming
+ */
+bool intel_dsi_is_mp_drrs_req(struct i915_drrs *drrs,
+ struct drm_display_mode *mode)
+{
+ struct intel_dsi *intel_dsi =
+ enc_to_intel_dsi(&drrs->connector->encoder->base);
+ struct dsi_drrs *dsi_drrs = &intel_dsi->dsi_drrs;
+ struct intel_mipi_drrs_work *work = dsi_drrs->mipi_drrs_work;
+ bool ret = false;
+
+ if (work_busy(&work->work.work)) {
+ if (work->target_mode->vrefresh != mode->vrefresh ||
+ drrs->drrs_state.current_rr_type != DRRS_MEDIA_RR)
+
+ /*
+* First condition: Deferred work is in place to change
+* the DRRS state. Hence this call is valid Media
+* playback DRRS request.
+*
+* Second Condition: Might be same as deffered work but
+* this is from media playback request. So honor it.
+*/
+ ret = true;
+ }
+ return ret;
+}
+
/* Whether DRRS_HR_STATE is pending in the dsi deferred work */
bool intel_dsi_is_drrs_hr_state_pending(struct i915_drrs *drrs)
{
@@ -350,6 +405,7 @@ struct drrs_encoder_ops drrs_dsi_ops = {
.exit = intel_dsi_drrs_exit,
.set_drrs_state = intel_dsi_set_drrs_state,
.is_drrs_hr_state_pending = intel_dsi_is_drrs_hr_state_pending,
+ .is_mp_drrs_req = intel_dsi_is_mp_drrs_req,
};
/* Call back Function for Intel_drrs module to get t
[Intel-gfx] [RFC PATCH 16/18] drm/i915: Filtering media playback DRRS requests
If the platform supports the media playback DRRS, Userspace can provide
a request for Media playback DRRS. This is done by placing the modeset
request with the same mode and FB but with different vrefresh.
This change implements the algorithm to identify the Media playback
DRRS requests from the normal modeset requests.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_display.c | 14 +
drivers/gpu/drm/i915/intel_drrs.c| 54 ++
drivers/gpu/drm/i915/intel_drrs.h|1 +
3 files changed, 69 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b36fde6..0335c09 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13295,6 +13295,20 @@ static int intel_crtc_set_config(struct drm_mode_set
*set)
dev = set->crtc->dev;
+ /* Identifying the Media Playback DRRS request */
+ if (is_media_playback_drrs_request(set)) {
+
+ /*
+* While requesting for Media Playback DRRS Userspace should
+* make sure that fb passed is same as that is in use.
+* Else at successful drrs request, we will hit a warn_on on
+* return path for fb mismatch
+*/
+ ret = intel_media_playback_drrs_configure(
+ to_intel_crtc(set->crtc), set->mode);
+ return ret;
+ }
+
state = drm_atomic_state_alloc(dev);
if (!state)
return -ENOMEM;
diff --git a/drivers/gpu/drm/i915/intel_drrs.c
b/drivers/gpu/drm/i915/intel_drrs.c
index 7f66be4..9634254 100644
--- a/drivers/gpu/drm/i915/intel_drrs.c
+++ b/drivers/gpu/drm/i915/intel_drrs.c
@@ -523,6 +523,60 @@ set_state:
return 0;
}
+/* Function to filter the Media playback DRRS request from the normal
+ * mode set */
+bool is_media_playback_drrs_request(struct drm_mode_set *set)
+{
+ struct drm_device *dev = set->crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(set->crtc);
+ struct i915_drrs *drrs;
+ struct intel_encoder *encoder;
+ struct drrs_info *drrs_state;
+ bool ret = false;
+ int index;
+
+ index = get_drrs_struct_index_for_crtc(dev_priv, intel_crtc);
+ if (index < 0)
+ return ret;
+
+ drrs = dev_priv->drrs[index];
+ if (!drrs || !drrs->has_drrs)
+ return ret;
+
+ /* Return if the current crtc mode's vrefresh is 0 */
+ if (!set->mode || !set->crtc->mode.vrefresh)
+ return ret;
+
+ /* Crtc should be active */
+ if (!intel_crtc->active)
+ return ret;
+
+ drrs_state = &drrs->drrs_state;
+ encoder = drrs->connector->encoder;
+
+ /* At present only DSI and eDP support DRRS */
+ if (encoder->type != INTEL_OUTPUT_EDP &&
+ encoder->type != INTEL_OUTPUT_DSI)
+ return ret;
+
+ DRM_DEBUG_KMS("mode_vr: %d, crtc_vr: %d, cur_rr_type: %d\n",
+ set->mode->vrefresh, set->crtc->mode.vrefresh,
+ drrs_state->current_rr_type);
+
+ if (drm_mode_equal_no_clocks_no_stereo(set->mode, &set->crtc->mode)) {
+ if (set->mode->vrefresh != set->crtc->mode.vrefresh)
+ ret = true;
+
+ if (drrs_state->type == SEAMLESS_DRRS_SUPPORT_SW &&
+ drrs->encoder_ops->is_mp_drrs_req)
+ if (drrs->encoder_ops->is_mp_drrs_req(drrs, set->mode))
+ ret = true;
+ }
+
+ return ret;
+}
+
/* Idleness detection logic is initialized */
int intel_drrs_idleness_detection_init(struct i915_drrs *drrs)
{
diff --git a/drivers/gpu/drm/i915/intel_drrs.h
b/drivers/gpu/drm/i915/intel_drrs.h
index 7f9985c0..72b4aeb 100644
--- a/drivers/gpu/drm/i915/intel_drrs.h
+++ b/drivers/gpu/drm/i915/intel_drrs.h
@@ -30,6 +30,7 @@ void intel_disable_idleness_drrs(struct i915_drrs *drrs);
void intel_enable_idleness_drrs(struct i915_drrs *drrs);
int intel_media_playback_drrs_configure(struct intel_crtc *crtc,
struct drm_display_mode *mode);
+bool is_media_playback_drrs_request(struct drm_mode_set *set);
int intel_drrs_init(struct drm_device *dev,
struct intel_connector *intel_connector,
struct drm_display_mode *fixed_mode);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 14/18] drm/i915: MEDIA_RR support in eDP DRRS module
Content based DRRS support is implemented in
eDP DRRS module also.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_drv.h |3 +++
drivers/gpu/drm/i915/intel_edp_drrs.c | 29 +
2 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b364a68..3a5cff8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -419,6 +419,9 @@ struct intel_crtc_state {
/* m2_n2 for eDP downclock */
struct intel_link_m_n dp_m2_n2;
+
+ /* m3_n3 for eDP Media playback DRRS */
+ struct intel_link_m_n dp_m3_n3;
bool has_drrs;
/*
diff --git a/drivers/gpu/drm/i915/intel_edp_drrs.c
b/drivers/gpu/drm/i915/intel_edp_drrs.c
index 8968e4c..173c281 100644
--- a/drivers/gpu/drm/i915/intel_edp_drrs.c
+++ b/drivers/gpu/drm/i915/intel_edp_drrs.c
@@ -45,6 +45,8 @@ static int vlv_edp_set_drrs_state(struct intel_encoder
*encoder,
struct drm_device *dev = encoder->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
+ struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
+ struct i915_drrs *drrs;
u32 reg, val;
if (!crtc)
@@ -53,6 +55,10 @@ static int vlv_edp_set_drrs_state(struct intel_encoder
*encoder,
reg = PIPECONF(crtc->config->cpu_transcoder);
val = I915_READ(reg);
+ drrs = dev_priv->drrs[get_drrs_struct_index_for_crtc(dev_priv, crtc)];
+ if (!drrs || !drrs->has_drrs)
+ return -EINVAL;
+
switch (target_rr_type) {
case DRRS_HIGH_RR:
if (IS_VALLEYVIEW(dev))
@@ -62,6 +68,29 @@ static int vlv_edp_set_drrs_state(struct intel_encoder
*encoder,
if (IS_VALLEYVIEW(dev))
val |= PIPECONF_EDP_RR_MODE_SWITCH_VLV;
break;
+ case DRRS_MEDIA_RR:
+ if (drrs->connector->panel.target_mode->vrefresh ==
+ drrs->connector->panel.fixed_mode->vrefresh) {
+ /* Exiting from MEDIA_RR */
+ if (IS_VALLEYVIEW(dev))
+ val &= ~PIPECONF_EDP_RR_MODE_SWITCH_VLV;
+
+ intel_dp_set_m_n(crtc, &crtc->config->dp_m_n,
+ &crtc->config->dp_m2_n2);
+ } else {
+ intel_link_compute_m_n(crtc->config->pipe_bpp,
+ intel_dp->lane_count,
+ drrs->connector->panel.target_mode->clock,
+ crtc->config->port_clock,
+ &crtc->config->dp_m3_n3);
+
+ if (IS_VALLEYVIEW(dev))
+ val |= PIPECONF_EDP_RR_MODE_SWITCH_VLV;
+
+ intel_dp_set_m_n(crtc, &crtc->config->dp_m_n,
+ &crtc->config->dp_m3_n3);
+ }
+ break;
default:
DRM_ERROR("invalid refresh rate type\n");
return -EINVAL;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 12/18] drm/i915: Redesigning dp_set_m_n to receive divider values
This will enable the called to decide the combination of divider
values that needs to be programmed.
First divider value will go into primary divider and the second divider
value will be taken for drrs divider register, if that is supported
on platform.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_display.c | 38 --
drivers/gpu/drm/i915/intel_drv.h | 23 ++--
2 files changed, 20 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0e8467c..b36fde6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4819,7 +4819,9 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
intel_prepare_shared_dpll(intel_crtc);
if (intel_crtc->config->has_dp_encoder)
- intel_dp_set_m_n(intel_crtc, M1_N1);
+ intel_dp_set_m_n(intel_crtc,
+ &intel_crtc->config->dp_m_n,
+ &intel_crtc->config->dp_m2_n2);
intel_set_pipe_timings(intel_crtc);
@@ -4896,7 +4898,9 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
intel_enable_shared_dpll(intel_crtc);
if (intel_crtc->config->has_dp_encoder)
- intel_dp_set_m_n(intel_crtc, M1_N1);
+ intel_dp_set_m_n(intel_crtc,
+ &intel_crtc->config->dp_m_n,
+ &intel_crtc->config->dp_m2_n2);
intel_set_pipe_timings(intel_crtc);
@@ -6036,7 +6040,9 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc)
}
if (intel_crtc->config->has_dp_encoder)
- intel_dp_set_m_n(intel_crtc, M1_N1);
+ intel_dp_set_m_n(intel_crtc,
+ &intel_crtc->config->dp_m_n,
+ &intel_crtc->config->dp_m2_n2);
intel_set_pipe_timings(intel_crtc);
@@ -6105,7 +6111,9 @@ static void i9xx_crtc_enable(struct drm_crtc *crtc)
i9xx_set_pll_dividers(intel_crtc);
if (intel_crtc->config->has_dp_encoder)
- intel_dp_set_m_n(intel_crtc, M1_N1);
+ intel_dp_set_m_n(intel_crtc,
+ &intel_crtc->config->dp_m_n,
+ &intel_crtc->config->dp_m2_n2);
intel_set_pipe_timings(intel_crtc);
@@ -7208,29 +7216,19 @@ static void intel_cpu_transcoder_set_m_n(struct
intel_crtc *crtc,
}
}
-void intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set m_n)
+void intel_dp_set_m_n(struct intel_crtc *crtc,
+ struct intel_link_m_n *m1_n1,
+ struct intel_link_m_n *m2_n2)
{
- struct intel_link_m_n *dp_m_n, *dp_m2_n2 = NULL;
-
- if (m_n == M1_N1) {
- dp_m_n = &crtc->config->dp_m_n;
- dp_m2_n2 = &crtc->config->dp_m2_n2;
- } else if (m_n == M2_N2) {
-
- /*
-* M2_N2 registers are not supported. Hence m2_n2 divider value
-* needs to be programmed into M1_N1.
-*/
- dp_m_n = &crtc->config->dp_m2_n2;
- } else {
+ if (!m1_n1) {
DRM_ERROR("Unsupported divider value\n");
return;
}
if (crtc->config->has_pch_encoder)
- intel_pch_transcoder_set_m_n(crtc, &crtc->config->dp_m_n);
+ intel_pch_transcoder_set_m_n(crtc, m1_n1);
else
- intel_cpu_transcoder_set_m_n(crtc, dp_m_n, dp_m2_n2);
+ intel_cpu_transcoder_set_m_n(crtc, m1_n1, m2_n2);
}
static void vlv_update_pll(struct intel_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d5354f3..b364a68 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -674,26 +674,6 @@ struct intel_hdmi {
struct intel_dp_mst_encoder;
#define DP_MAX_DOWNSTREAM_PORTS0x10
-/*
- * enum link_m_n_set:
- * When platform provides two set of M_N registers for dp, we can
- * program them and switch between them incase of DRRS.
- * But When only one such register is provided, we have to program the
- * required divider value on that registers itself based on the DRRS state.
- *
- * M1_N1 : Program dp_m_n on M1_N1 registers
- * dp_m2_n2 on M2_N2 registers (If supported)
- *
- * M2_N2 : Program dp_m2_n2 on M1_N1 registers
- * M2_N2 registers are not supported
- */
-
-enum link_m_n_set {
- /* Sets the m1_n1 and m2_n2 */
- M1_N1 = 0,
- M2_N2
-};
-
struct intel_dp {
uint32_t output_reg;
uint32_t aux_ch_ctl_reg;
@@ -1138,7 +1118,8 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv);
void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
void intel_dp_get_m_n(struc
[Intel-gfx] [RFC PATCH 07/18] drm/i915: Generic eDP DRRS implementation
This patch Implements the generic eDP DRRS functions and registers
them with Generic DRRS state machine.
Platform specific eDP DRRS functions will be implemented and
registered with this generic eDP DRRS implementation. Hence
extending the eDP DRRS to new platform is made simple.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/intel_dp.c |6 +++
drivers/gpu/drm/i915/intel_drrs.c |2 +
drivers/gpu/drm/i915/intel_drv.h |3 ++
drivers/gpu/drm/i915/intel_edp_drrs.c | 95 +
drivers/gpu/drm/i915/intel_edp_drrs.h | 29 ++
6 files changed, 136 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel_edp_drrs.c
create mode 100644 drivers/gpu/drm/i915/intel_edp_drrs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4f77fb2..9a3c43f 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -56,6 +56,7 @@ i915-y += intel_audio.o \
intel_psr.o \
intel_drrs.o \
intel_dsi_drrs.o \
+ intel_edp_drrs.o \
intel_sideband.o \
intel_sprite.o
i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 738e98e..9ded4d1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1483,6 +1483,12 @@ found:
pipe_config->port_clock,
&pipe_config->dp_m_n);
+ if (intel_connector->panel.downclock_mode)
+ intel_link_compute_m_n(bpp, lane_count,
+ intel_connector->panel.downclock_mode->clock,
+ pipe_config->port_clock,
+ &pipe_config->dp_m2_n2);
+
if (IS_SKYLAKE(dev) && is_edp(intel_dp))
skl_edp_set_pll_config(pipe_config, common_rates[clock]);
else if (IS_BROXTON(dev))
diff --git a/drivers/gpu/drm/i915/intel_drrs.c
b/drivers/gpu/drm/i915/intel_drrs.c
index 2a776d2..e5d8bcd 100644
--- a/drivers/gpu/drm/i915/intel_drrs.c
+++ b/drivers/gpu/drm/i915/intel_drrs.c
@@ -388,6 +388,8 @@ int intel_drrs_init(struct drm_device *dev,
if (intel_encoder->type == INTEL_OUTPUT_DSI) {
drrs->encoder_ops = get_intel_dsi_drrs_ops();
+ } else if (intel_encoder->type == INTEL_OUTPUT_EDP) {
+ drrs->encoder_ops = get_intel_edp_drrs_ops();
} else {
DRM_ERROR("DRRS: Unsupported Encoder\n");
ret = -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 726c31d..d5354f3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -38,6 +38,7 @@
#include
#include "intel_drrs.h"
+#include "intel_edp_drrs.h"
/**
* _wait_for - magic (register) wait macro
@@ -758,6 +759,8 @@ struct intel_dp {
unsigned long compliance_test_type;
unsigned long compliance_test_data;
bool compliance_test_active;
+
+ struct edp_drrs_platform_ops *drrs_ops;
};
struct intel_digital_port {
diff --git a/drivers/gpu/drm/i915/intel_edp_drrs.c
b/drivers/gpu/drm/i915/intel_edp_drrs.c
new file mode 100644
index 000..606271b
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_edp_drrs.c
@@ -0,0 +1,95 @@
+/*
+ * Copyright (C) 2015, Intel Corporation.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Authors:
+ * Ramalingam C
+ * Durgadoss R
+ */
+
+#include
+#include
+
+#include "i915_drv.h"
+
+void intel_edp_set_drrs_state(struct i915_drrs *drrs)
+{
+ struct intel_encoder *intel_encoder = drrs->connector->encoder;
+ struct intel_dp *intel_dp = enc_to_intel_dp(&intel_encoder->base);
+
+ intel_dp->drrs_ops->set_drrs_state(intel_encoder,
+ drrs->drrs_state.target_rr_type);
+}
+
+int intel_edp_drrs_init(struct i915_drrs *drrs,
+ struct drm_display_mode *fixed_mode)
+{
+ struct intel_encoder *intel_encoder = drrs->connector->encoder;
+ struct intel_dp *intel_dp = enc_to_intel_dp(&intel_encoder->base);
+ struct drm_display_mode *downclock_mode;
+ int ret = -EINVAL;
+
+ if (!intel_dp->drrs_ops ||
+ !intel_dp->drrs_ops->set_drrs_state) {
+ DRM_ERROR("Required platform ops are NULL\n");
+ return ret;
+ }
+
+ if (fixed_mode->vrefresh == 0)
+ fi
[Intel-gfx] [RFC PATCH 11/18] drm/i915: Updating the crtc modes in DRRS transitions
During the DRRS state transitions we are modifying the clock and
hence the vrefresh rate.
So we need to update the drm_crtc->mode and the adjusted
mode in intel_crtc. So that watermark calculations will be as per the
new modified clock.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_drrs.c | 14 ++
drivers/gpu/drm/i915/intel_dsi_drrs.c | 14 +-
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_drrs.c
b/drivers/gpu/drm/i915/intel_drrs.c
index 42b420d..2901832 100644
--- a/drivers/gpu/drm/i915/intel_drrs.c
+++ b/drivers/gpu/drm/i915/intel_drrs.c
@@ -169,6 +169,20 @@ void intel_set_drrs_state(struct i915_drrs *drrs)
* If it is non-DSI encoders.
* As only DSI has SEAMLESS_DRRS_SUPPORT_SW.
*/
+ /*
+* TODO: Protect the access to the crtc mode with corresponding
+* mutex in case of Idleness DRRS. As media playback update
+* will happen under crtc modeset lock protection
+*/
+ drm_modeset_lock(&intel_crtc->base.mutex, NULL);
+ intel_crtc->base.mode.clock = target_mode->clock;
+ intel_crtc->base.mode.vrefresh = target_mode->vrefresh;
+ intel_crtc->config->base.adjusted_mode.clock =
+ target_mode->clock;
+ intel_crtc->config->base.adjusted_mode.vrefresh =
+ target_mode->vrefresh;
+ drm_modeset_unlock(&intel_crtc->base.mutex);
+
drrs_state->current_rr_type = drrs_state->target_rr_type;
DRM_INFO("Refresh Rate set to : %dHz\n", refresh_rate);
}
diff --git a/drivers/gpu/drm/i915/intel_dsi_drrs.c
b/drivers/gpu/drm/i915/intel_dsi_drrs.c
index eb0758a..d4bb70a 100644
--- a/drivers/gpu/drm/i915/intel_dsi_drrs.c
+++ b/drivers/gpu/drm/i915/intel_dsi_drrs.c
@@ -46,6 +46,7 @@ static void intel_mipi_drrs_work_fn(struct work_struct
*__work)
struct i915_drrs *drrs = work->drrs;
struct intel_encoder *intel_encoder = drrs->connector->encoder;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(&intel_encoder->base);
+ struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc);
struct dsi_drrs *dsi_drrs = &intel_dsi->dsi_drrs;
struct dsi_mnp *dsi_mnp;
struct drm_display_mode *prev_mode = NULL;
@@ -69,11 +70,22 @@ retry:
/* PLL Programming is successful */
mutex_lock(&drrs->drrs_mutex);
drrs->drrs_state.current_rr_type = work->target_rr_type;
+
+ drm_modeset_lock(&intel_crtc->base.mutex, NULL);
+ intel_crtc->base.mode.clock = work->target_mode->clock;
+ intel_crtc->base.mode.vrefresh = work->target_mode->vrefresh;
+ intel_crtc->config->base.adjusted_mode.clock =
+ work->target_mode->clock;
+ intel_crtc->config->base.adjusted_mode.vrefresh =
+ work->target_mode->vrefresh;
+ drm_modeset_unlock(&intel_crtc->base.mutex);
+
mutex_unlock(&drrs->drrs_mutex);
+
DRM_INFO("Refresh Rate set to : %dHz\n",
work->target_mode->vrefresh);
- /* TODO: Update crtc mode and drain ladency with watermark */
+ /* TODO: Update drain ladency with watermark */
} else if (ret == -ETIMEDOUT && retry_cnt) {
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 09/18] drm/i915: Cloned mode check
If crtc is in clone mode, DRRS will be disabled. Because if the both
the displays are not sharing the same vrefresh, then userspace
activities based on vsync will go for toss.
Clone mode will be rechecked on every restarting Idleness DRRS events.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_drrs.c | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_drrs.c
b/drivers/gpu/drm/i915/intel_drrs.c
index e5d8bcd..42b420d 100644
--- a/drivers/gpu/drm/i915/intel_drrs.c
+++ b/drivers/gpu/drm/i915/intel_drrs.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include "i915_drv.h"
#include "intel_drv.h"
@@ -85,6 +86,31 @@ int get_free_drrs_struct_index(struct drm_i915_private
*dev_priv)
return -EBUSY;
}
+/*
+ * TODO: This is identifying the multiple active crtcs at a time.
+ * Here we assume that this is clone state and disable DRRS.
+ * But need to implement a proper method to find the real cloned mode
+ * state. DRRS need not be disabled incase of multiple crtcs with
+ * different content.
+ */
+
+bool is_cloned_mode_active(struct drm_device *dev)
+{
+ struct drm_crtc *crtc = NULL, *tmp_crtc;
+
+ list_for_each_entry(tmp_crtc, &dev->mode_config.crtc_list, head) {
+ if (crtc && intel_crtc_active(tmp_crtc)) {
+ DRM_DEBUG_KMS(
+ "more than one crtc active. Declared as clonec mode\n");
+ return true;
+ }
+
+ if (intel_crtc_active(tmp_crtc))
+ crtc = tmp_crtc;
+ }
+ return false;
+}
+
void intel_set_drrs_state(struct i915_drrs *drrs)
{
struct drrs_info *drrs_state;
@@ -158,7 +184,10 @@ static void intel_idleness_drrs_work_fn(struct work_struct
*__work)
panel = &drrs->connector->panel;
- /* TODO: If DRRS is not supported on clone mode act here */
+ /* Double check if the dual-display mode is active. */
+ if (drrs->is_clone)
+ return;
+
mutex_lock(&drrs->drrs_mutex);
if (panel->target_mode != NULL)
DRM_ERROR("FIXME: We shouldn't be here\n");
@@ -192,6 +221,11 @@ static void intel_enable_idleness_drrs(struct i915_drrs
*drrs)
mutex_lock(&drrs->drrs_mutex);
+ drrs->is_clone = is_cloned_mode_active(drrs->connector->base.dev);
+
+ if (drrs->is_clone)
+ return;
+
/* Capturing the deferred request for disable_drrs */
if (drrs->drrs_state.type == SEAMLESS_DRRS_SUPPORT_SW &&
drrs->encoder_ops->is_drrs_hr_state_pending) {
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 10/18] drm/i915: Initializing DRRS for all connectors
For all the connectors drrs init is invoked. drrs_init will initialize the drrs for those connectors that support DRRS. Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_display.c |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 3f48917..0e8467c 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -15021,6 +15021,7 @@ void intel_modeset_init(struct drm_device *dev) int sprite, ret; enum pipe pipe; struct intel_crtc *crtc; + struct intel_connector *connector; drm_mode_config_init(dev); @@ -15090,6 +15091,10 @@ void intel_modeset_init(struct drm_device *dev) i915_disable_vga(dev); intel_setup_outputs(dev); + list_for_each_entry(connector, &dev->mode_config.connector_list, + base.head) + intel_drrs_init(dev, connector, connector->panel.fixed_mode); + /* Just in case the BIOS is doing something questionable. */ intel_fbc_disable(dev); -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 08/18] drm/i915: VLV eDP DRRS methods
VLV related ePD drrs functions are implemented and registered
with generic eDP drrs module.
This will provide the platform specific services to generic ePD drrs
stack, like program the pll registers for DRRS functionality.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_edp_drrs.c | 72 +
1 file changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_edp_drrs.c
b/drivers/gpu/drm/i915/intel_edp_drrs.c
index 606271b..8968e4c 100644
--- a/drivers/gpu/drm/i915/intel_edp_drrs.c
+++ b/drivers/gpu/drm/i915/intel_edp_drrs.c
@@ -20,6 +20,71 @@
#include "i915_drv.h"
+/*
+ * VLV eDP DRRS Support
+ */
+
+static int vlv_edp_drrs_init(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
+
+ if (dev_priv->psr.enabled) {
+ DRM_ERROR("eDP DRRS is disabled as PSR is enabled already\n");
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static void vlv_edp_drrs_exit(struct intel_encoder *encoder)
+{
+}
+
+static int vlv_edp_set_drrs_state(struct intel_encoder *encoder,
+ enum drrs_refresh_rate_type target_rr_type)
+{
+ struct drm_device *dev = encoder->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
+ u32 reg, val;
+
+ if (!crtc)
+ return -EINVAL;
+
+ reg = PIPECONF(crtc->config->cpu_transcoder);
+ val = I915_READ(reg);
+
+ switch (target_rr_type) {
+ case DRRS_HIGH_RR:
+ if (IS_VALLEYVIEW(dev))
+ val &= ~PIPECONF_EDP_RR_MODE_SWITCH_VLV;
+ break;
+ case DRRS_LOW_RR:
+ if (IS_VALLEYVIEW(dev))
+ val |= PIPECONF_EDP_RR_MODE_SWITCH_VLV;
+ break;
+ default:
+ DRM_ERROR("invalid refresh rate type\n");
+ return -EINVAL;
+ }
+
+ I915_WRITE(reg, val);
+ return 0;
+}
+
+struct edp_drrs_platform_ops vlv_edp_drrs_ops = {
+ .init = vlv_edp_drrs_init,
+ .exit = vlv_edp_drrs_exit,
+ .set_drrs_state = vlv_edp_set_drrs_state,
+};
+
+struct edp_drrs_platform_ops *get_vlv_edp_drrs_ops(void)
+{
+ return &vlv_edp_drrs_ops;
+}
+
+/*
+ * Generic eDP DRRS implementation
+ */
void intel_edp_set_drrs_state(struct i915_drrs *drrs)
{
struct intel_encoder *intel_encoder = drrs->connector->encoder;
@@ -37,6 +102,13 @@ int intel_edp_drrs_init(struct i915_drrs *drrs,
struct drm_display_mode *downclock_mode;
int ret = -EINVAL;
+ if (IS_VALLEYVIEW(intel_encoder->base.dev))
+
+ /* VLV and CHV */
+ intel_dp->drrs_ops = get_vlv_edp_drrs_ops();
+ else
+ intel_dp->drrs_ops = NULL;
+
if (!intel_dp->drrs_ops ||
!intel_dp->drrs_ops->set_drrs_state) {
DRM_ERROR("Required platform ops are NULL\n");
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 06/18] drm/i915: VLV dsi drrs support
VLV related dsi drrs functions are implemented and registered
with generic dsi drrs.
This will provide the service to generic dsi drrs stack to calculate
the pll divider values and program the pll registers for DRRS
functionality.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_reg.h |4 +
drivers/gpu/drm/i915/intel_dsi_drrs.c | 27
drivers/gpu/drm/i915/intel_dsi_drrs.h |5 +
drivers/gpu/drm/i915/intel_dsi_pll.c | 225 ++---
4 files changed, 243 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0b979ad..9f1332b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2964,6 +2964,10 @@ enum skl_disp_power_wells {
#define VLV_EDP_PSR_IN_TRANS (1<<7)
#define VLV_PSRSTAT(pipe) _PIPE(pipe, _PSRSTATA, _PSRSTATB)
+#define VERTICAL_ACTIVE_DISPLAY_MASK (0xfff)
+#define VERTICAL_TOTAL_DISPLAY_OFFSET 16
+#define VERTICAL_TOTAL_DISPLAY_MASK(0xfff<<16)
+
/* HSW+ eDP PSR registers */
#define EDP_PSR_BASE(dev) (IS_HASWELL(dev) ? 0x64800 :
0x6f800)
#define EDP_PSR_CTL(dev) (EDP_PSR_BASE(dev) + 0)
diff --git a/drivers/gpu/drm/i915/intel_dsi_drrs.c
b/drivers/gpu/drm/i915/intel_dsi_drrs.c
index 6ab0e9e..eb0758a 100644
--- a/drivers/gpu/drm/i915/intel_dsi_drrs.c
+++ b/drivers/gpu/drm/i915/intel_dsi_drrs.c
@@ -20,6 +20,23 @@
#include "intel_drv.h"
#include "intel_dsi.h"
+/*
+ * VLV and CHV platform code
+ */
+struct drrs_dsi_platform_ops vlv_dsi_drrs_ops = {
+ .configure_dsi_pll = vlv_drrs_configure_dsi_pll,
+ .mnp_calculate_for_mode = vlv_dsi_mnp_calculate_for_mode,
+};
+
+inline struct drrs_dsi_platform_ops *get_vlv_dsi_drrs_ops(void)
+{
+ return &vlv_dsi_drrs_ops;
+}
+
+/*
+ * Generic DSI DRRS code
+ */
+
/* Work function for DSI deferred work */
static void intel_mipi_drrs_work_fn(struct work_struct *__work)
{
@@ -243,6 +260,16 @@ int intel_dsi_drrs_init(struct i915_drrs *drrs,
panel->target_mode = NULL;
+ if (IS_VALLEYVIEW(intel_encoder->base.dev)) {
+
+ /* VLV and CHV */
+ dsi_drrs->ops = get_vlv_dsi_drrs_ops();
+ } else {
+ DRM_ERROR("DRRS: Unsupported platform\n");
+ ret = -EINVAL;
+ goto out_err_2;
+ }
+
if (!dsi_drrs->ops || !dsi_drrs->ops->mnp_calculate_for_mode ||
!dsi_drrs->ops->configure_dsi_pll) {
DRM_ERROR("DSI platform ops not initialized\n");
diff --git a/drivers/gpu/drm/i915/intel_dsi_drrs.h
b/drivers/gpu/drm/i915/intel_dsi_drrs.h
index 27736a0..02f76f0 100644
--- a/drivers/gpu/drm/i915/intel_dsi_drrs.h
+++ b/drivers/gpu/drm/i915/intel_dsi_drrs.h
@@ -58,4 +58,9 @@ struct dsi_drrs {
};
extern inline struct drrs_encoder_ops *get_intel_dsi_drrs_ops(void);
+int vlv_dsi_mnp_calculate_for_mode(struct intel_encoder *encoder,
+ struct dsi_mnp *dsi_mnp,
+ struct drm_display_mode *mode);
+int vlv_drrs_configure_dsi_pll(struct intel_encoder *encoder,
+ struct dsi_mnp *dsi_mnp);
#endif /* INTEL_DSI_DRRS_H */
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index ce5949f..46346b3 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -29,6 +29,7 @@
#include "intel_drv.h"
#include "i915_drv.h"
#include "intel_dsi.h"
+#include "intel_drrs.h"
#define DSI_HSS_PACKET_SIZE4
#define DSI_HSE_PACKET_SIZE4
@@ -38,6 +39,8 @@
#define DSI_HFP_PACKET_EXTRA_SIZE 6
#define DSI_EOTP_PACKET_SIZE 4
+#define DSI_DRRS_PLL_CONFIG_TIMEOUT_MS 100
+
static const u32 lfsr_converts[] = {
426, 469, 234, 373, 442, 221, 110, 311, 411,/* 62 - 70 */
461, 486, 243, 377, 188, 350, 175, 343, 427, 213, /* 71 - 80 */
@@ -256,39 +259,225 @@ static int dsi_calc_mnp(int target_dsi_clk, struct
dsi_mnp *dsi_mnp)
}
/*
+ * vlv_dsi_pll_reg_configure:
+ * Function to configure the CCK registers for PLL control and dividers
+ *
+ * pll : Pll that is getting configure
+ * dsi_mnp : Struct with divider values
+ * pll_enable : Flag to indicate whether it is a fresh pll enable call or
+ * call on DRRS purpose
+ */
+static void vlv_dsi_pll_reg_configure(struct intel_encoder *encoder,
+ struct dsi_mnp *dsi_mnp, bool pll_enable)
+{
+ struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+
+ if (!intel_crtc)
+ return;
+
+ if (pll_enable) {
+ vlv_cck_write(dev_priv, CCK_REG_DS
[Intel-gfx] [RFC PATCH 04/18] drm/i915: Implementation of Generic DSI DRRS
This patch Implements the generic DSI DRRS functions and registers
them with Generic DRRS state machine.
Platform specific DSI DRRS functions will be implemented and
registered with this generic DSI DRRS implementation. Hence
extending the DSI DRRS to new platform is made simple.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/intel_drrs.c | 10 ++
drivers/gpu/drm/i915/intel_dsi.h |3 +
drivers/gpu/drm/i915/intel_dsi_drrs.c | 320 +
drivers/gpu/drm/i915/intel_dsi_drrs.h | 61 +++
drivers/gpu/drm/i915/intel_dsi_pll.c |5 -
6 files changed, 395 insertions(+), 5 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_dsi_drrs.c
create mode 100644 drivers/gpu/drm/i915/intel_dsi_drrs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5fd100b..4f77fb2 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -55,6 +55,7 @@ i915-y += intel_audio.o \
intel_overlay.o \
intel_psr.o \
intel_drrs.o \
+ intel_dsi_drrs.o \
intel_sideband.o \
intel_sprite.o
i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
diff --git a/drivers/gpu/drm/i915/intel_drrs.c
b/drivers/gpu/drm/i915/intel_drrs.c
index eb67909..2a776d2 100644
--- a/drivers/gpu/drm/i915/intel_drrs.c
+++ b/drivers/gpu/drm/i915/intel_drrs.c
@@ -19,6 +19,7 @@
#include "i915_drv.h"
#include "intel_drv.h"
+#include "intel_dsi.h"
#include "intel_drrs.h"
int get_drrs_struct_index_for_pipe(struct drm_i915_private *dev_priv, int pipe)
@@ -354,6 +355,7 @@ int intel_drrs_init(struct drm_device *dev,
struct drm_display_mode *fixed_mode)
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_encoder *intel_encoder = intel_connector->encoder;
struct i915_drrs *drrs;
int ret = 0, index;
@@ -384,6 +386,14 @@ int intel_drrs_init(struct drm_device *dev,
drrs = dev_priv->drrs[index];
drrs->connector = intel_connector;
+ if (intel_encoder->type == INTEL_OUTPUT_DSI) {
+ drrs->encoder_ops = get_intel_dsi_drrs_ops();
+ } else {
+ DRM_ERROR("DRRS: Unsupported Encoder\n");
+ ret = -EINVAL;
+ goto err_out;
+ }
+
if (!drrs->encoder_ops) {
DRM_ERROR("Encoder ops not initialized\n");
ret = -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 2784ac4..129f68e 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -28,6 +28,7 @@
#include
#include
#include "intel_drv.h"
+#include "intel_dsi_drrs.h"
/* Dual Link support */
#define DSI_DUAL_LINK_NONE 0
@@ -47,6 +48,8 @@ struct intel_dsi {
/* bit mask of ports being driven */
u16 ports;
+ struct dsi_drrs dsi_drrs;
+
/* if true, use HS mode, otherwise LP */
bool hs;
diff --git a/drivers/gpu/drm/i915/intel_dsi_drrs.c
b/drivers/gpu/drm/i915/intel_dsi_drrs.c
new file mode 100644
index 000..6ab0e9e
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dsi_drrs.c
@@ -0,0 +1,320 @@
+/*
+ * Copyright (C) 2015, Intel Corporation.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Author:
+ * Ramalingam C
+ */
+
+#include
+#include
+
+#include "intel_drv.h"
+#include "intel_dsi.h"
+
+/* Work function for DSI deferred work */
+static void intel_mipi_drrs_work_fn(struct work_struct *__work)
+{
+ struct intel_mipi_drrs_work *work =
+ container_of(to_delayed_work(__work),
+ struct intel_mipi_drrs_work, work);
+ struct i915_drrs *drrs = work->drrs;
+ struct intel_encoder *intel_encoder = drrs->connector->encoder;
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&intel_encoder->base);
+ struct dsi_drrs *dsi_drrs = &intel_dsi->dsi_drrs;
+ struct dsi_mnp *dsi_mnp;
+ struct drm_display_mode *prev_mode = NULL;
+ bool fallback_attempt = false;
+ int ret, retry_cnt = 3;
+
+init:
+ dsi_mnp = &dsi_drrs->mnp[work->target_rr_type];
+ DRM_DEBUG("Refresh rate Type: %d-->%d\n",
+ drrs->drrs_state.current_rr_type,
+ work->target_rr_type);
+ DRM_DEBUG("Target RR: %d\n", work->target_mode->vrefresh);
+
+retry:
+ if (!intel_crtc |
[Intel-gfx] [RFC PATCH 05/18] drm/i915: Adjusting the pclk for dual link and burst mode
dsi_clk is calculated for the clock of passed drm_display_mode
and pclk is adjusted considering dual link and the burst mode.
This change is required to make the drrs to co-exist with dual link
and Burst mode.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 77 ++
1 file changed, 68 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index c58eb02..ce5949f 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -128,13 +128,11 @@ static u32 dsi_rr_formula(const struct drm_display_mode
*mode,
#else
-/* Get DSI clock from pixel clock */
-static u32 dsi_clk_from_pclk(u32 pclk, int pixel_format, int lane_count)
+static u32 intel_get_bits_per_pixel(struct intel_dsi *intel_dsi)
{
- u32 dsi_clk_khz;
u32 bpp;
- switch (pixel_format) {
+ switch (intel_dsi->pixel_format) {
default:
case VID_MODE_FORMAT_RGB888:
case VID_MODE_FORMAT_RGB666_LOOSE:
@@ -147,10 +145,70 @@ static u32 dsi_clk_from_pclk(u32 pclk, int pixel_format,
int lane_count)
bpp = 16;
break;
}
+ return bpp;
+}
+
+void adjust_pclk_for_dual_link(struct intel_dsi *intel_dsi,
+ struct drm_display_mode *mode, u32 *pclk)
+{
+ /* In dual link mode each port needs half of pixel clock */
+ *pclk = *pclk / 2;
+
+ /*
+* If pixel_overlap needed by panel, we need to increase the pixel
+* clock for extra pixels.
+*/
+ if (intel_dsi->dual_link & DSI_DUAL_LINK_FRONT_BACK)
+ *pclk += DIV_ROUND_UP(mode->vtotal * intel_dsi->pixel_overlap *
+ mode->vrefresh, 1000);
+}
+
+void adjust_pclk_for_burst_mode(u32 *pclk, u16 burst_mode_ratio)
+{
+ *pclk = DIV_ROUND_UP(*pclk * burst_mode_ratio, 100);
+}
+
+
+/* To recalculate the pclk considering dual link and Burst mode */
+static u32 intel_drrs_calc_pclk(struct intel_dsi *intel_dsi,
+ struct drm_display_mode *mode)
+{
+ u32 pclk;
+ int pkt_pixel_size; /* in bits */
- /* DSI data rate = pixel clock * bits per pixel / lane count
- pixel clock is converted from KHz to Hz */
- dsi_clk_khz = DIV_ROUND_CLOSEST(pclk * bpp, lane_count);
+ pclk = mode->clock;
+
+ pkt_pixel_size = intel_get_bits_per_pixel(intel_dsi);
+
+ /* In dual link mode each port needs half of pixel clock */
+ if (intel_dsi->dual_link)
+ adjust_pclk_for_dual_link(intel_dsi, mode, &pclk);
+
+ /* Retaining the same Burst mode ratio for DRRS. Need to be tested */
+ if (intel_dsi->burst_mode_ratio > 100)
+ adjust_pclk_for_burst_mode(&pclk, intel_dsi->burst_mode_ratio);
+
+ DRM_DEBUG_KMS("mode->clock : %d, pclk : %d\n", mode->clock, pclk);
+ return pclk;
+}
+
+/* Get DSI clock from pixel clock */
+static u32 dsi_clk_from_pclk(struct intel_dsi *intel_dsi,
+ struct drm_display_mode *mode)
+{
+ u32 dsi_clk_khz;
+ u32 bpp;
+ u32 pclk;
+
+ bpp = intel_get_bits_per_pixel(intel_dsi);
+
+ pclk = intel_drrs_calc_pclk(intel_dsi, mode);
+
+ /*
+* DSI data rate = pixel clock * bits per pixel / lane count
+* pixel clock is converted from KHz to Hz
+*/
+ dsi_clk_khz = DIV_ROUND_CLOSEST(pclk * bpp, intel_dsi->lane_count);
return dsi_clk_khz;
}
@@ -205,12 +263,13 @@ static void vlv_configure_dsi_pll(struct intel_encoder
*encoder)
{
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ struct intel_connector *intel_connector = intel_dsi->attached_connector;
int ret;
struct dsi_mnp dsi_mnp;
u32 dsi_clk;
- dsi_clk = dsi_clk_from_pclk(intel_dsi->pclk, intel_dsi->pixel_format,
- intel_dsi->lane_count);
+ dsi_clk = dsi_clk_from_pclk(intel_dsi,
+ intel_connector->panel.fixed_mode);
ret = dsi_calc_mnp(dsi_clk, &dsi_mnp);
if (ret) {
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 01/18] drm/i915: Removing the eDP specific DRRS implementation
EDP specific DRRS implementation is removed to implement a
generic DRRS stack extentable accross the supportable encoders.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_debugfs.c | 110 -
drivers/gpu/drm/i915/i915_drv.h | 22 --
drivers/gpu/drm/i915/intel_ddi.c |2 -
drivers/gpu/drm/i915/intel_dp.c | 392 --
drivers/gpu/drm/i915/intel_drv.h |5 -
drivers/gpu/drm/i915/intel_frontbuffer.c |2 -
6 files changed, 533 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c49fe2a..7dbf170 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2962,115 +2962,6 @@ static int i915_ddb_info(struct seq_file *m, void
*unused)
return 0;
}
-static void drrs_status_per_crtc(struct seq_file *m,
- struct drm_device *dev, struct intel_crtc *intel_crtc)
-{
- struct intel_encoder *intel_encoder;
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct i915_drrs *drrs = &dev_priv->drrs;
- int vrefresh = 0;
-
- for_each_encoder_on_crtc(dev, &intel_crtc->base, intel_encoder) {
- /* Encoder connected on this CRTC */
- switch (intel_encoder->type) {
- case INTEL_OUTPUT_EDP:
- seq_puts(m, "eDP:\n");
- break;
- case INTEL_OUTPUT_DSI:
- seq_puts(m, "DSI:\n");
- break;
- case INTEL_OUTPUT_HDMI:
- seq_puts(m, "HDMI:\n");
- break;
- case INTEL_OUTPUT_DISPLAYPORT:
- seq_puts(m, "DP:\n");
- break;
- default:
- seq_printf(m, "Other encoder (id=%d).\n",
- intel_encoder->type);
- return;
- }
- }
-
- if (dev_priv->vbt.drrs_type == STATIC_DRRS_SUPPORT)
- seq_puts(m, "\tVBT: DRRS_type: Static");
- else if (dev_priv->vbt.drrs_type == SEAMLESS_DRRS_SUPPORT)
- seq_puts(m, "\tVBT: DRRS_type: Seamless");
- else if (dev_priv->vbt.drrs_type == DRRS_NOT_SUPPORTED)
- seq_puts(m, "\tVBT: DRRS_type: None");
- else
- seq_puts(m, "\tVBT: DRRS_type: FIXME: Unrecognized Value");
-
- seq_puts(m, "\n\n");
-
- if (to_intel_crtc_state(intel_crtc->base.state)->has_drrs) {
- struct intel_panel *panel;
-
- mutex_lock(&drrs->mutex);
- /* DRRS Supported */
- seq_puts(m, "\tDRRS Supported: Yes\n");
-
- /* disable_drrs() will make drrs->dp NULL */
- if (!drrs->dp) {
- seq_puts(m, "Idleness DRRS: Disabled");
- mutex_unlock(&drrs->mutex);
- return;
- }
-
- panel = &drrs->dp->attached_connector->panel;
- seq_printf(m, "\t\tBusy_frontbuffer_bits: 0x%X",
- drrs->busy_frontbuffer_bits);
-
- seq_puts(m, "\n\t\t");
- if (drrs->refresh_rate_type == DRRS_HIGH_RR) {
- seq_puts(m, "DRRS_State: DRRS_HIGH_RR\n");
- vrefresh = panel->fixed_mode->vrefresh;
- } else if (drrs->refresh_rate_type == DRRS_LOW_RR) {
- seq_puts(m, "DRRS_State: DRRS_LOW_RR\n");
- vrefresh = panel->downclock_mode->vrefresh;
- } else {
- seq_printf(m, "DRRS_State: Unknown(%d)\n",
- drrs->refresh_rate_type);
- mutex_unlock(&drrs->mutex);
- return;
- }
- seq_printf(m, "\t\tVrefresh: %d", vrefresh);
-
- seq_puts(m, "\n\t\t");
- mutex_unlock(&drrs->mutex);
- } else {
- /* DRRS not supported. Print the VBT parameter*/
- seq_puts(m, "\tDRRS Supported : No");
- }
- seq_puts(m, "\n");
-}
-
-static int i915_drrs_status(struct seq_file *m, void *unused)
-{
- struct drm_info_node *node = m->private;
- struct drm_device *dev = node->minor->dev;
- struct intel_crtc *intel_crtc;
- int active_crtc_cnt = 0;
-
- for_each_intel_crtc(dev, intel_crtc) {
- drm_modeset_lock(&intel_crtc->base.mutex, NULL);
-
- if (intel_crtc->base.state->active) {
- active_crtc_cnt++;
- seq_printf(m, "\nCRTC %d: ", active_crtc_cnt);
-
- drrs_status_per_crtc(m, dev, intel_crtc);
- }
-
- drm_modeset_unlock(&intel_crtc->base.mutex);
- }
-
- if (!active_crtc_cnt)
- seq_puts(m,
[Intel-gfx] [RFC PATCH 03/18] drm/i915: Addition of the drrs_min_vrefresh in VBT
VBT structure's block 42 is updated as per the current VBT v188
specification and additonal member drrs_min_vrefresh is added.
Corresponding logic for parsing drrs_min_vrefresh is added.
drrs_min_vrefresh is nothing but lowest vrefresh supported by the panel.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_bios.c |3 +++
drivers/gpu/drm/i915/intel_bios.h |9 +++--
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 00982bb..677293d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1479,6 +1479,7 @@ struct intel_vbt_data {
unsigned int bios_lvds_val; /* initial [PCH_]LVDS reg val in VBIOS */
enum drrs_support_type drrs_type;
+ unsigned int drrs_min_vrefresh;
/* eDP */
int edp_rate;
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 198fc3c..5d6117a 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -251,6 +251,9 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
if (!lvds_lfp_data)
return;
+ dev_priv->vbt.drrs_min_vrefresh = (unsigned int)
+ lvds_lfp_data->seamless_drrs_min_vrefresh[panel_type];
+
lvds_lfp_data_ptrs = find_section(bdb, BDB_LVDS_LFP_DATA_PTRS);
if (!lvds_lfp_data_ptrs)
return;
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index af0b476..b0cd827 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -338,8 +338,6 @@ struct lvds_fp_timing {
u32 pp_off_reg_val;
u32 pp_cycle_reg;
u32 pp_cycle_reg_val;
- u32 pfit_reg;
- u32 pfit_reg_val;
u16 terminator;
} __packed;
@@ -385,8 +383,15 @@ struct bdb_lvds_lfp_data_entry {
struct lvds_pnp_id pnp_id;
} __packed;
+struct lfp_panel_name {
+ u8 name[13];
+} __packed;
+
struct bdb_lvds_lfp_data {
struct bdb_lvds_lfp_data_entry data[16];
+ struct lfp_panel_name name[16];
+ u16 scaling_enabling_bits;
+ u8 seamless_drrs_min_vrefresh[16];
} __packed;
#define BDB_BACKLIGHT_TYPE_NONE0
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 02/18] drm/i915: Generic DRRS state Machine
DRRS is a power saving feature, which will refresh the display
at the lowest supported refresh rate, based on the rate of change
of display content to be rendered.
This patch implements the Generic state machine for the Idleness DRRS.
Idleness DRRS is nothing but, when the content of the Display is not
changed for a certain duration, refresh rate will be set to the
minimum vrefresh supported by the panel.
This will be extended for media playback DRRS. i.e based on the
display content's Frames Per Second, required lowest vrefresh to
support the FPS will be used to render the data. This involves
the Userspace and Kernel handshaking.
DRRS Support for the encoders like DSI and eDP can be implemented
as a separate module and get registered with this generic DRRS stack.
Hence extending to new encoder and platform is made easy.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/i915_drv.h | 77 -
drivers/gpu/drm/i915/intel_drrs.c| 460 ++
drivers/gpu/drm/i915/intel_drrs.h| 34 +++
drivers/gpu/drm/i915/intel_drv.h |5 +
drivers/gpu/drm/i915/intel_frontbuffer.c |2 +
6 files changed, 578 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/intel_drrs.c
create mode 100644 drivers/gpu/drm/i915/intel_drrs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b7ddf48..5fd100b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -54,6 +54,7 @@ i915-y += intel_audio.o \
intel_modes.o \
intel_overlay.o \
intel_psr.o \
+ intel_drrs.o \
intel_sideband.o \
intel_sprite.o
i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 922dd68..00982bb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -930,10 +930,82 @@ struct i915_fbc {
} no_fbc_reason;
};
+/**
+ * DRRS Support Type:
+ * DRRS_NOT_SUPPORTED : DRRS not supported
+ * STATIC_DRRS_SUPPORT : Need a complete modeset for DRRS
+ * SEAMLESS_DRRS_SUPPORT : Seamless vrefresh switch is supported on HW
+ * SEAMLESS_DRRS_SUPPORT_SW: Seamless vrefresh switch is supported on SW
+ */
enum drrs_support_type {
DRRS_NOT_SUPPORTED = 0,
STATIC_DRRS_SUPPORT = 1,
- SEAMLESS_DRRS_SUPPORT = 2
+ SEAMLESS_DRRS_SUPPORT = 2,
+ SEAMLESS_DRRS_SUPPORT_SW = 3,
+};
+
+/**
+ * Different DRRS States:
+ * DRRS_HIGH_RR: Refreshrate of Fixed mode. [Maximum Vrefresh]
+ * DRRS_LOW_RR : Refreshrate of Downclock mode. [Minimum vrefresh]
+ */
+enum drrs_refresh_rate_type {
+ DRRS_HIGH_RR,
+ DRRS_LOW_RR,
+ DRRS_MAX_RR,
+};
+
+struct drrs_info {
+ enum drrs_support_type type;
+ enum drrs_refresh_rate_type current_rr_type;
+ enum drrs_refresh_rate_type target_rr_type;
+};
+
+struct i915_drrs;
+
+/**
+ * intel_idleness_drrs_work:
+ * work: Deferred work to declare the Idleness, if not
disturbed.
+ * crtc: Target drm_crtc
+ * interval: Time to defer the deferred work
+ */
+struct intel_idleness_drrs_work {
+ struct delayed_work work;
+ struct i915_drrs *drrs;
+
+ /* Idleness interval in mSec*/
+ int interval;
+};
+
+/* Encoder related function pointers */
+struct drrs_encoder_ops {
+ int (*init)(struct i915_drrs *, struct drm_display_mode *);
+ void (*exit)(struct i915_drrs *);
+ void (*set_drrs_state)(struct i915_drrs *);
+ bool (*is_drrs_hr_state_pending)(struct i915_drrs *);
+};
+
+struct i915_drrs {
+ /* Whether another pipe is enabled in parallel */
+ bool is_clone;
+
+ /* Whether DRRS is supported on this Panel */
+ bool has_drrs;
+
+ /* Holds the DRRS state machine states */
+ struct drrs_info drrs_state;
+
+ /* Pointer to the relevant connector */
+ struct intel_connector *connector;
+
+ /* Front buffer tracking bits */
+ unsigned busy_frontbuffer_bits;
+
+ struct intel_idleness_drrs_work *idleness_drrs_work;
+
+ /* Functions to hold encoder specific DRRS functions */
+ struct drrs_encoder_ops *encoder_ops;
+ struct mutex drrs_mutex;
};
struct i915_psr {
@@ -1697,6 +1769,7 @@ struct drm_i915_private {
struct i915_hotplug hotplug;
struct i915_fbc fbc;
+ struct i915_drrs *drrs[I915_MAX_PIPES];
struct intel_opregion opregion;
struct intel_vbt_data vbt;
@@ -2394,6 +2467,8 @@ struct drm_i915_cmd_table {
#define IS_HSW_ULX(dev)(INTEL_DEVID(dev) == 0x0A0E || \
INTEL_DEVID(dev) == 0x0A1E)
#define IS_PRELIMINARY_HW(intel_info) ((intel_info)->is_preliminary)
+#define IS_PLATFORM_HAS_DRRS(dev) (INTEL_INFO(dev)->gen >= 7 || \
+
[Intel-gfx] [PATCH 2/2] drm/i915: In DBUF/WM calcs for 90/270, swap w & h
This patch swaps src width and height for dbuf/wm calculations
when rotation is 90/270 as per hw requirements.
Signed-off-by: Chandra Konduru
---
drivers/gpu/drm/i915/intel_pm.c | 32
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ea3e435..767313b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2913,6 +2913,8 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
enum pipe pipe = intel_crtc->pipe;
struct drm_plane *plane;
struct drm_framebuffer *fb;
+ struct intel_plane_state *plane_state;
+ int src_w, src_h;
int i = 1; /* Index for sprite planes start */
p->active = intel_crtc->active;
@@ -2921,6 +2923,7 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
p->pixel_rate = skl_pipe_pixel_rate(intel_crtc->config);
fb = crtc->primary->state->fb;
+ plane_state = to_intel_plane_state(crtc->primary->state);
/* For planar: Bpp is for uv plane, y_Bpp is for y plane */
if (fb) {
p->plane[0].enabled = true;
@@ -2935,8 +2938,22 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
p->plane[0].y_bytes_per_pixel = 0;
p->plane[0].tiling = DRM_FORMAT_MOD_NONE;
}
- p->plane[0].horiz_pixels = intel_crtc->config->pipe_src_w;
- p->plane[0].vert_pixels = intel_crtc->config->pipe_src_h;
+
+ if (drm_rect_width(&plane_state->src)) {
+ src_w = drm_rect_width(&plane_state->src) >> 16;
+ src_h = drm_rect_height(&plane_state->src) >> 16;
+ } else {
+ src_w = intel_crtc->config->pipe_src_w;
+ src_h = intel_crtc->config->pipe_src_h;
+ }
+
+ if (intel_rotation_90_or_270(crtc->primary->state->rotation)) {
+ p->plane[0].horiz_pixels = src_h;
+ p->plane[0].vert_pixels = src_w;
+ } else {
+ p->plane[0].horiz_pixels = src_w;
+ p->plane[0].vert_pixels = src_h;
+ }
p->plane[0].rotation = crtc->primary->state->rotation;
fb = crtc->cursor->state->fb;
@@ -3468,8 +3485,15 @@ skl_update_sprite_wm(struct drm_plane *plane, struct
drm_crtc *crtc,
intel_plane->wm.enabled = enabled;
intel_plane->wm.scaled = scaled;
- intel_plane->wm.horiz_pixels = sprite_width;
- intel_plane->wm.vert_pixels = sprite_height;
+
+ if (intel_rotation_90_or_270(plane->state->rotation)) {
+ intel_plane->wm.horiz_pixels = sprite_height;
+ intel_plane->wm.vert_pixels = sprite_width;
+ } else {
+ intel_plane->wm.horiz_pixels = sprite_width;
+ intel_plane->wm.vert_pixels = sprite_height;
+ }
+
intel_plane->wm.tiling = DRM_FORMAT_MOD_NONE;
/* For planar: Bpp is for UV plane, y_Bpp is for Y plane */
--
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/2] drm/i915: Allocate min dbuf blocks per bspec
Properly allocate min blocks per hw requirements.
Signed-off-by: Chandra Konduru
---
drivers/gpu/drm/i915/intel_pm.c | 39 +--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 32ff034..ea3e435 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2679,6 +2679,41 @@ skl_get_total_relative_data_rate(struct intel_crtc
*intel_crtc,
return total_data_rate;
}
+static uint16_t
+skl_dbuf_min_alloc(const struct intel_plane_wm_parameters *p, int y_plane)
+{
+ uint16_t min_alloc;
+
+ /* For packed formats, no y-plane, return 0 */
+ if (y_plane && !p->y_bytes_per_pixel)
+ return 0;
+
+
+ if (p->tiling == I915_FORMAT_MOD_Y_TILED ||
+ p->tiling == I915_FORMAT_MOD_Yf_TILED) {
+ uint32_t min_scanlines = 8;
+ uint8_t bytes_per_pixel =
+ y_plane ? p->y_bytes_per_pixel : p->bytes_per_pixel;
+
+ switch (bytes_per_pixel) {
+ case 1:
+ min_scanlines = 32;
+ break;
+ case 2:
+ min_scanlines = 16;
+ break;
+ case 8:
+ WARN(1, "Unsupported pixel depth for rotation");
+ }
+ min_alloc = DIV_ROUND_UP((4 * p->horiz_pixels/(y_plane ? 1 : 2)
*
+ bytes_per_pixel), 512) * min_scanlines/4 + 3;
+ } else {
+ min_alloc = 8;
+ }
+
+ return min_alloc;
+}
+
static void
skl_allocate_pipe_ddb(struct drm_crtc *crtc,
const struct intel_wm_config *config,
@@ -2719,9 +2754,9 @@ skl_allocate_pipe_ddb(struct drm_crtc *crtc,
if (!p->enabled)
continue;
- minimum[plane] = 8;
+ minimum[plane] = skl_dbuf_min_alloc(p, 0);/*
uv-plane/packed */
alloc_size -= minimum[plane];
- y_minimum[plane] = p->y_bytes_per_pixel ? 8 : 0;
+ y_minimum[plane] = skl_dbuf_min_alloc(p, 1); /* y-plane */
alloc_size -= y_minimum[plane];
}
--
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/2] Fix min dbuf, 90/270 wm calcs
Resending with correct patches. This patch series allocates minimum dbuf blocks required for tile-y, tile-yf buffers correctly as per bspec. Also in WM calculations, for 90/270, swaps source width and height. Chandra Konduru (2): drm/i915: Allocate min dbuf blocks per bspec drm/i915: In DBUF/WM calcs for 90/270, swap w & h drivers/gpu/drm/i915/intel_pm.c | 71 +++ 1 file changed, 65 insertions(+), 6 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 2/2] drm/i915: In DBUF/WM calcs for 90/270, swap w & h
This patch swaps src width and height for dbuf/wm calculations
when rotation is 90/270 as per hw requirements.
Signed-off-by: Chandra Konduru
---
drivers/gpu/drm/i915/intel_pm.c | 32
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ea3e435..767313b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2913,6 +2913,8 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
enum pipe pipe = intel_crtc->pipe;
struct drm_plane *plane;
struct drm_framebuffer *fb;
+ struct intel_plane_state *plane_state;
+ int src_w, src_h;
int i = 1; /* Index for sprite planes start */
p->active = intel_crtc->active;
@@ -2921,6 +2923,7 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
p->pixel_rate = skl_pipe_pixel_rate(intel_crtc->config);
fb = crtc->primary->state->fb;
+ plane_state = to_intel_plane_state(crtc->primary->state);
/* For planar: Bpp is for uv plane, y_Bpp is for y plane */
if (fb) {
p->plane[0].enabled = true;
@@ -2935,8 +2938,22 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
p->plane[0].y_bytes_per_pixel = 0;
p->plane[0].tiling = DRM_FORMAT_MOD_NONE;
}
- p->plane[0].horiz_pixels = intel_crtc->config->pipe_src_w;
- p->plane[0].vert_pixels = intel_crtc->config->pipe_src_h;
+
+ if (drm_rect_width(&plane_state->src)) {
+ src_w = drm_rect_width(&plane_state->src) >> 16;
+ src_h = drm_rect_height(&plane_state->src) >> 16;
+ } else {
+ src_w = intel_crtc->config->pipe_src_w;
+ src_h = intel_crtc->config->pipe_src_h;
+ }
+
+ if (intel_rotation_90_or_270(crtc->primary->state->rotation)) {
+ p->plane[0].horiz_pixels = src_h;
+ p->plane[0].vert_pixels = src_w;
+ } else {
+ p->plane[0].horiz_pixels = src_w;
+ p->plane[0].vert_pixels = src_h;
+ }
p->plane[0].rotation = crtc->primary->state->rotation;
fb = crtc->cursor->state->fb;
@@ -3468,8 +3485,15 @@ skl_update_sprite_wm(struct drm_plane *plane, struct
drm_crtc *crtc,
intel_plane->wm.enabled = enabled;
intel_plane->wm.scaled = scaled;
- intel_plane->wm.horiz_pixels = sprite_width;
- intel_plane->wm.vert_pixels = sprite_height;
+
+ if (intel_rotation_90_or_270(plane->state->rotation)) {
+ intel_plane->wm.horiz_pixels = sprite_height;
+ intel_plane->wm.vert_pixels = sprite_width;
+ } else {
+ intel_plane->wm.horiz_pixels = sprite_width;
+ intel_plane->wm.vert_pixels = sprite_height;
+ }
+
intel_plane->wm.tiling = DRM_FORMAT_MOD_NONE;
/* For planar: Bpp is for UV plane, y_Bpp is for Y plane */
--
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/2] drm/i915: Allocate min dbuf blocks per bspec
Properly allocate min blocks per hw requirements.
Signed-off-by: Chandra Konduru
---
drivers/gpu/drm/i915/intel_pm.c | 39 +--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 32ff034..ea3e435 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2679,6 +2679,41 @@ skl_get_total_relative_data_rate(struct intel_crtc
*intel_crtc,
return total_data_rate;
}
+static uint16_t
+skl_dbuf_min_alloc(const struct intel_plane_wm_parameters *p, int y_plane)
+{
+ uint16_t min_alloc;
+
+ /* For packed formats, no y-plane, return 0 */
+ if (y_plane && !p->y_bytes_per_pixel)
+ return 0;
+
+
+ if (p->tiling == I915_FORMAT_MOD_Y_TILED ||
+ p->tiling == I915_FORMAT_MOD_Yf_TILED) {
+ uint32_t min_scanlines = 8;
+ uint8_t bytes_per_pixel =
+ y_plane ? p->y_bytes_per_pixel : p->bytes_per_pixel;
+
+ switch (bytes_per_pixel) {
+ case 1:
+ min_scanlines = 32;
+ break;
+ case 2:
+ min_scanlines = 16;
+ break;
+ case 8:
+ WARN(1, "Unsupported pixel depth for rotation");
+ }
+ min_alloc = DIV_ROUND_UP((4 * p->horiz_pixels/(y_plane ? 1 : 2)
*
+ bytes_per_pixel), 512) * min_scanlines/4 + 3;
+ } else {
+ min_alloc = 8;
+ }
+
+ return min_alloc;
+}
+
static void
skl_allocate_pipe_ddb(struct drm_crtc *crtc,
const struct intel_wm_config *config,
@@ -2719,9 +2754,9 @@ skl_allocate_pipe_ddb(struct drm_crtc *crtc,
if (!p->enabled)
continue;
- minimum[plane] = 8;
+ minimum[plane] = skl_dbuf_min_alloc(p, 0);/*
uv-plane/packed */
alloc_size -= minimum[plane];
- y_minimum[plane] = p->y_bytes_per_pixel ? 8 : 0;
+ y_minimum[plane] = skl_dbuf_min_alloc(p, 1); /* y-plane */
alloc_size -= y_minimum[plane];
}
--
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/2] Fix min dbuf, 90/270 wm calcs
This patch series allocates minimum dbuf blocks required for tile-y, tile-yf buffers correctly as per bspec. Also in WM calculations, for 90/270, swaps source width and height. Chandra Konduru (2): drm/i915: Allocate min dbuf blocks per bspec drm/i915: In DBUF/WM calcs for 90/270, swap w & h drivers/gpu/drm/i915/intel_pm.c | 71 +++ 1 file changed, 65 insertions(+), 6 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 v4] drm/i915: Add support for SKL background color
This patch adds support for Skylake display pipe background color.
Signed-off-by: Chandra Konduru
---
Documentation/DocBook/drm.tmpl | 10 -
drivers/gpu/drm/i915/i915_reg.h | 10 +
drivers/gpu/drm/i915/intel_display.c | 73 ++
drivers/gpu/drm/i915/intel_drv.h |2 +
include/drm/drm_crtc.h |3 ++
5 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 7d03a74..1f6f4f0 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2663,7 +2663,7 @@ void intel_crt_init(struct drm_device *dev)
TBD
- i915
+ i915
Generic
"Broadcast RGB"
ENUM
@@ -2687,6 +2687,14 @@ void intel_crt_init(struct drm_device *dev)
TBD
+ CRTC
+ “background_color”
+ Range
+ Min=0, Max=0xFF
+ CRTC
+ Background color in 16bpc BGR (B-MSB, R-LSB)
+
+
SDVO-TV
“mode”
ENUM
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 84b37d7..795b53f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6579,6 +6579,16 @@ enum kdiv {
#define PIPE_CSC_POSTOFF_ME(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_ME,
_PIPE_B_CSC_POSTOFF_ME)
#define PIPE_CSC_POSTOFF_LO(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_LO,
_PIPE_B_CSC_POSTOFF_LO)
+/* Skylake pipe bottom color */
+#define _PIPE_BOTTOM_COLOR_A0x70034
+#define _PIPE_BOTTOM_COLOR_B0x71034
+#define _PIPE_BOTTOM_COLOR_C0x72034
+#define PIPE_BOTTOM_GAMMA_ENABLE (1 << 31)
+#define PIPE_BOTTOM_CSC_ENABLE (1 << 30)
+#define PIPE_BOTTOM_COLOR_MASK 0x3FFF
+#define PIPE_BOTTOM_COLOR(pipe) _PIPE3(pipe, _PIPE_BOTTOM_COLOR_A, \
+ _PIPE_BOTTOM_COLOR_B, _PIPE_BOTTOM_COLOR_C)
+
/* VLV MIPI registers */
#define _MIPIA_PORT_CTRL (VLV_DISPLAY_BASE + 0x61190)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d162dca..d4b7c0c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6951,6 +6951,7 @@ static void intel_set_pipe_csc(struct drm_crtc *crtc)
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc->pipe;
uint16_t coeff = 0x7800; /* 1.0 */
+ uint32_t color;
/*
* TODO: Check what kind of values actually come out of the pipe
@@ -6999,6 +7000,14 @@ static void intel_set_pipe_csc(struct drm_crtc *crtc)
I915_WRITE(PIPE_CSC_MODE(pipe), mode);
}
+
+ /* set csc for bottom color */
+ if (INTEL_INFO(dev)->gen >= 9) {
+ color = I915_READ(PIPE_BOTTOM_COLOR(pipe));
+ color |= PIPE_BOTTOM_CSC_ENABLE;
+ I915_WRITE(PIPE_BOTTOM_COLOR(pipe), color);
+ intel_crtc->background_color |= PIPE_BOTTOM_CSC_ENABLE;
+ }
}
static void haswell_set_pipeconf(struct drm_crtc *crtc)
@@ -8568,6 +8577,9 @@ static void intel_crtc_gamma_set(struct drm_crtc *crtc,
u16 *red, u16 *green,
{
int end = (start + size > 256) ? 256 : start + size, i;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ uint32_t color;
for (i = start; i < end; i++) {
intel_crtc->lut_r[i] = red[i] >> 8;
@@ -8576,6 +8588,14 @@ static void intel_crtc_gamma_set(struct drm_crtc *crtc,
u16 *red, u16 *green,
}
intel_crtc_load_lut(crtc);
+
+ if (INTEL_INFO(dev)->gen >= 9) {
+ /* set gamma for bottom color */
+ color = I915_READ(PIPE_BOTTOM_COLOR(intel_crtc->pipe));
+ color |= PIPE_BOTTOM_GAMMA_ENABLE;
+ I915_WRITE(PIPE_BOTTOM_COLOR(intel_crtc->pipe), color);
+ intel_crtc->background_color |= PIPE_BOTTOM_GAMMA_ENABLE;
+ }
}
/* VESA 640x480x72Hz mode to set on the pipe */
@@ -9350,6 +9370,12 @@ static void intel_crtc_destroy(struct drm_crtc *crtc)
kfree(work);
}
+ if (dev->mode_config.background_color_property) {
+ drm_property_destroy(crtc->dev,
+ dev->mode_config.background_color_property);
+ dev->mode_config.background_color_property = NULL;
+ }
+
drm_crtc_cleanup(crtc);
kfree(intel_crtc);
@@ -10131,6 +10157,33 @@ out_hang:
return ret;
}
+static int intel_crtc_set_property(struct drm_crtc *crtc,
+ struct drm_property *property, uint64_t val)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int i;
+
+ if (INTEL_INFO(dev)->gen >= 9) {
+ if (pr
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Interrupt driven fences
On Fri, Jun 26, 2015 at 01:58:11PM +0100, john.c.harri...@intel.com wrote: > From: John Harrison > > The intended usage model for struct fence is that the signalled status should > be > set on demand rather than polled. That is, there should not be a need for a > 'signaled' function to be called everytime the status is queried. Instead, > 'something' should be done to enable a signal callback from the hardware which > will update the state directly. In the case of requests, this is the seqno > update interrupt. The idea is that this callback will only be enabled on > demand > when something actually tries to wait on the fence. > > This change removes the polling test and replaces it with the callback scheme. > Each fence is added to a 'please poke me' list at the start of > i915_add_request(). The interrupt handler then scans through the 'poke me' > list > when a new seqno pops out and signals any matching fence/request. The fence is > then removed from the list so the entire request stack does not need to be > scanned every time. Note that the fence is added to the list before the > commands > to generate the seqno interrupt are added to the ring. Thus the sequence is > guaranteed to be race free if the interrupt is already enabled. > > One complication here is that the 'poke me' system requires holding a > reference > count on the request to guarantee that it won't be freed prematurely. > Unfortunately, it is unsafe to decrement the reference count from the > interrupt > handler because if that is the last reference, the clean up code gets run and > the clean up code is not IRQ friendly. Hence, the request is added to a > 'please > clean me' list that gets processed at retire time. Any request in this list > simply has its count decremented and is then removed from that list. > > Note that the interrupt is only enabled on demand (i.e. when __wait_request() > is > called). Thus there is still a potential race when enabling the interrupt as > the > request may already have completed. However, this is simply solved by calling > the interrupt processing code immediately after enabling the interrupt and > thereby checking for already completed requests. > > Lastly, the ring clean up code has the possibility to cancel outstanding > requests (e.g. because TDR has reset the ring). These requests will never get > signalled and so must be removed from the signal list manually. This is done > by > setting a 'cancelled' flag and then calling the regular notify/retire code > path > rather than attempting to duplicate the list manipulatation and clean up code > in > multiple places. This also avoid any race condition where the cancellation > request might occur after/during the completion interrupt actually arriving. -nightly nop: Time to exec x 1:15.000µs (ring=render) Time to exec x 1: 2.000µs (ring=blt) Time to exec x 131072:1.827µs (ring=render) Time to exec x 131072:1.555µs (ring=blt) rq tuning patches nop: Time to exec x 1:12.200µs (ring=render) Time to exec x 1: 1.600µs (ring=blt) Time to exec x 131072:1.516µs (ring=render) Time to exec x 131072:0.812µs (ring=blt) interrupt driven nop: Time to exec x 1:19.200µs (ring=render) Time to exec x 1: 5.200µs (ring=blt) Time to exec x 131072:2.381µs (ring=render) Time to exec x 131072:2.009µs (ring=blt) So the basic question that is left unanswered from last time is why would we want to slow down __i915_wait_request? And enabling IRQs still generates very high system load when processing the 30-40k IRQs per second found under some workloads. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/17 v2] drm/i915: Expose two LRC functions for GuC submission mode
On 26/06/15 08:31, Chris Wilson wrote:
> On Thu, Jun 25, 2015 at 01:57:16PM -0700, Yu Dai wrote:
>>
>> On 06/25/2015 07:40 AM, Dave Gordon wrote:
>>> GuC submission is basically execlist submission, but with the GuC
>>> handling the actual writes to the ELSP and the resulting context
>>> switch interrupts. So to prepare a context for submission via the
>>> GuC, we need some of the same functions used in execlist mode.
>>> This commit exposes two such functions, changing their names to
>>> better describe what they do (they're related to logical ring
>>> contexts rather than to execlists per se).
>>>
>>> v2:
>>> Replaces previous "drm/i915: Move execlists defines from .c to .h"
>>>
>>> Issue: VIZ-4884
>>> Signed-off-by: Dave Gordon
>>> ---
>>> drivers/gpu/drm/i915/intel_lrc.c | 27 +--
>>> drivers/gpu/drm/i915/intel_lrc.h |5 +
>>> 2 files changed, 18 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
>>> b/drivers/gpu/drm/i915/intel_lrc.c
>>> index e5f4040..a77b22d 100644
>>> --- a/drivers/gpu/drm/i915/intel_lrc.c
>>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
>>> @@ -264,8 +264,8 @@ u32 intel_execlists_ctx_id(struct drm_i915_gem_object
>>> *ctx_obj)
>>> return lrca >> 12;
>>> }
>>> -static uint64_t execlists_ctx_descriptor(struct intel_engine_cs *ring,
>>> -struct drm_i915_gem_object *ctx_obj)
>>> +uint64_t intel_lr_context_descriptor(struct intel_engine_cs *ring,
>>> +struct drm_i915_gem_object *ctx_obj)
>>> {
>>> struct drm_device *dev = ring->dev;
>>> uint64_t desc;
>>> @@ -306,13 +306,13 @@ static void execlists_elsp_write(struct
>>> intel_engine_cs *ring,
>>> /* XXX: You must always write both descriptors in the order below. */
>>> if (ctx_obj1)
>>> - temp = execlists_ctx_descriptor(ring, ctx_obj1);
>>> + temp = intel_lr_context_descriptor(ring, ctx_obj1);
>>> else
>>> temp = 0;
>>> desc[1] = (u32)(temp >> 32);
>>> desc[0] = (u32)temp;
>>> - temp = execlists_ctx_descriptor(ring, ctx_obj0);
>>> + temp = intel_lr_context_descriptor(ring, ctx_obj0);
>>> desc[3] = (u32)(temp >> 32);
>>> desc[2] = (u32)temp;
>>> @@ -331,10 +331,10 @@ static void execlists_elsp_write(struct
>>> intel_engine_cs *ring,
>>> spin_unlock(&dev_priv->uncore.lock);
>>> }
>>> -static int execlists_update_context(struct drm_i915_gem_object *ctx_obj,
>>> - struct drm_i915_gem_object *ring_obj,
>>> - struct i915_hw_ppgtt *ppgtt,
>>> - u32 tail)
>>> +/* Update the ringbuffer pointer and tail offset in a saved context image
>>> */
>>> +void intel_lr_context_update(struct drm_i915_gem_object *ctx_obj,
>>> +struct drm_i915_gem_object *ring_obj,
>>> +u32 tail)
>>> {
>>> struct page *page;
>>> uint32_t *reg_state;
>>> @@ -342,12 +342,11 @@ static int execlists_update_context(struct
>>> drm_i915_gem_object *ctx_obj,
>>> page = i915_gem_object_get_page(ctx_obj, 1);
>>> reg_state = kmap_atomic(page);
>>> - reg_state[CTX_RING_TAIL+1] = tail;
>>> reg_state[CTX_RING_BUFFER_START+1] = i915_gem_obj_ggtt_offset(ring_obj);
>>> + if (tail != ~0u)
>>> + reg_state[CTX_RING_TAIL+1] = tail;
>>
>> I actually regret my original copycat of this function for guc.
>> Because updating ring tail is moved to guc, there is no need to call
>> this for each submission. Maybe we should split this call into two
>> parts. The updating of ring buffer base is moved to where ring
>> buffer is newly mapped. And the updating of tail is kept here for
>> execlist submission only.
>
> If you would be so kind to review patches that do just that, it would
> make intel_lrc a much nicer place to work, and execlists much faster.
> -Chris
I've deleted Alex's coy of this function in the GuC code; that's why the
execlists/LRC version is exposed so that it can be shared with the GuC
path, and the update of "tail" here is conditional, so the GuC call
doesn't use that part.
I agree it would be nicer still to update the ringbuffer base address
only at the point when it's pinned to the GGTT, rather than on each
batch submission. As you say, that would allow us to remove this call
entirely from the GuC path.
Another improvement would be to kmap the context whenever it's active,
the way we already do for the ringbuffer, so we could get rid of the
kmap_atomic calls here. Since contexts and ringbuffers are one-to-one in
execlist/GuC modes, it should be simple to keep them mapped-and-pinned
in paralell.
Further, perhaps we could allocate them in a single contiguous structure
to further reduce overhead; 4 pages of ringbuffer, one page as a GuC
shared channel, one page for the (PP)HWSP, some number of pages for the
context image? All GGTT-pinned and kmapped together whenever they've got
any work in-
[Intel-gfx] [PATCH 1/4] drm/i915: Convert requests to use struct fence
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that is intended
to keep track of work that is executed on hardware. I.e. it solves the basic
problem that the drivers 'struct drm_i915_gem_request' is trying to address. The
request structure does quite a lot more than simply track the execution progress
so is very definitely still required. However, the basic completion status side
could be updated to use the ready made fence implementation and gain all the
advantages that provides.
This patch makes the first step of integrating a struct fence into the request.
It replaces the explicit reference count with that of the fence. It also
replaces the 'is completed' test with the fence's equivalent. Currently, that
simply chains on to the original request implementation. A future patch will
improve this.
For: VIZ-5190
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h | 45 +-
drivers/gpu/drm/i915/i915_gem.c | 56 ++---
drivers/gpu/drm/i915/intel_lrc.c| 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++
5 files changed, 78 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index afcca15..fe2c1af 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
/* General customization:
*/
@@ -2134,7 +2135,17 @@ void i915_gem_track_fb(struct drm_i915_gem_object *old,
* initial reference taken using kref_init
*/
struct drm_i915_gem_request {
- struct kref ref;
+ /*
+* Underlying object for implementing the signal/wait stuff.
+* NB: Never call fence_later() or return this fence object to user
+* land! Due to lazy allocation, scheduler re-ordering, pre-emption,
+* etc., there is no guarantee at all about the validity or
+* sequentiality of the fence's seqno! It is also unsafe to let
+* anything outside of the i915 driver get hold of the fence object
+* as the clean up when decrementing the reference count requires
+* holding the driver mutex lock.
+*/
+ struct fence fence;
/** On Which ring this request was generated */
struct drm_i915_private *i915;
@@ -2211,7 +,13 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
struct intel_context *ctx,
struct drm_i915_gem_request **req_out);
void i915_gem_request_cancel(struct drm_i915_gem_request *req);
-void i915_gem_request_free(struct kref *req_ref);
+
+static inline bool i915_gem_request_completed(struct drm_i915_gem_request *req,
+ bool lazy_coherency)
+{
+ return fence_is_signaled(&req->fence);
+}
+
int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
struct drm_file *file);
@@ -2231,7 +2248,7 @@ static inline struct drm_i915_gem_request *
i915_gem_request_reference(struct drm_i915_gem_request *req)
{
if (req)
- kref_get(&req->ref);
+ fence_get(&req->fence);
return req;
}
@@ -2239,7 +2256,7 @@ static inline void
i915_gem_request_unreference(struct drm_i915_gem_request *req)
{
WARN_ON(!mutex_is_locked(&req->ring->dev->struct_mutex));
- kref_put(&req->ref, i915_gem_request_free);
+ fence_put(&req->fence);
}
static inline void
@@ -2251,7 +2268,7 @@ i915_gem_request_unreference__unlocked(struct
drm_i915_gem_request *req)
return;
dev = req->ring->dev;
- if (kref_put_mutex(&req->ref, i915_gem_request_free,
&dev->struct_mutex))
+ if (kref_put_mutex(&req->fence.refcount, fence_release,
&dev->struct_mutex))
mutex_unlock(&dev->struct_mutex);
}
@@ -2268,12 +2285,6 @@ static inline void i915_gem_request_assign(struct
drm_i915_gem_request **pdst,
}
/*
- * XXX: i915_gem_request_completed should be here but currently needs the
- * definition of i915_seqno_passed() which is below. It will be moved in
- * a later patch when the call to i915_seqno_passed() is obsoleted...
- */
-
-/*
* A command that requires special handling by the command parser.
*/
struct drm_i915_cmd_descriptor {
@@ -2830,18 +2841,6 @@ i915_seqno_passed(uint32_t seq1, uint32_t seq2)
return (int32_t)(seq1 - seq2) >= 0;
}
-static inline bool i915_gem_request_completed(struct drm_i915_gem_request *req,
- bool lazy_coherency)
-{
- u32 seqno;
-
- BUG_ON(req == NULL);
-
- seqno = req->ring->get_seqno(req->ring, lazy_coherency);
-
- return i915_seqno_passed(seqno, req->seqno);
-}
-
int __must_check i915_gem_get_seqno(struct drm_device *dev, u32 *seqno);
int __must_check i915_gem_set_seqno(struct drm_dev
[Intel-gfx] [PATCH 2/4] drm/i915: Removed now redudant parameter to i915_gem_request_completed()
From: John Harrison
The change to the implementation of i915_gem_request_completed() means that the
lazy coherency flag is no longer used. This can now be removed to simplify the
interface.
For: VIZ-5190
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 3 +--
drivers/gpu/drm/i915/i915_gem.c | 18 +-
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
6 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 114aa13..3e19d04 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -588,7 +588,7 @@ static int i915_gem_pageflip_info(struct seq_file *m, void
*data)
i915_gem_request_get_seqno(work->flip_queued_req),
dev_priv->next_seqno,
ring->get_seqno(ring, true),
-
i915_gem_request_completed(work->flip_queued_req, true));
+
i915_gem_request_completed(work->flip_queued_req));
} else
seq_printf(m, "Flip not associated with any
ring\n");
seq_printf(m, "Flip queued on frame %d, (was ready on
frame %d), now %d\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fe2c1af..2e6c151 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2223,8 +2223,7 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
struct drm_i915_gem_request **req_out);
void i915_gem_request_cancel(struct drm_i915_gem_request *req);
-static inline bool i915_gem_request_completed(struct drm_i915_gem_request *req,
- bool lazy_coherency)
+static inline bool i915_gem_request_completed(struct drm_i915_gem_request *req)
{
return fence_is_signaled(&req->fence);
}
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5fc44bf..0ae76b4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1179,7 +1179,7 @@ static int __i915_spin_request(struct
drm_i915_gem_request *req)
timeout = jiffies + 1;
while (!need_resched()) {
- if (i915_gem_request_completed(req, true))
+ if (i915_gem_request_completed(req))
return 0;
if (time_after_eq(jiffies, timeout))
@@ -1187,7 +1187,7 @@ static int __i915_spin_request(struct
drm_i915_gem_request *req)
cpu_relax_lowlatency();
}
- if (i915_gem_request_completed(req, false))
+ if (i915_gem_request_completed(req))
return 0;
return -EAGAIN;
@@ -1231,7 +1231,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
if (list_empty(&req->list))
return 0;
- if (i915_gem_request_completed(req, true))
+ if (i915_gem_request_completed(req))
return 0;
timeout_expire = timeout ?
@@ -1271,7 +1271,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
break;
}
- if (i915_gem_request_completed(req, false)) {
+ if (i915_gem_request_completed(req)) {
ret = 0;
break;
}
@@ -2753,7 +2753,7 @@ i915_gem_find_active_request(struct intel_engine_cs *ring)
struct drm_i915_gem_request *request;
list_for_each_entry(request, &ring->request_list, list) {
- if (i915_gem_request_completed(request, false))
+ if (i915_gem_request_completed(request))
continue;
return request;
@@ -2896,7 +2896,7 @@ i915_gem_retire_requests_ring(struct intel_engine_cs
*ring)
struct drm_i915_gem_request,
list);
- if (!i915_gem_request_completed(request, true))
+ if (!i915_gem_request_completed(request))
break;
i915_gem_request_retire(request);
@@ -2920,7 +2920,7 @@ i915_gem_retire_requests_ring(struct intel_engine_cs
*ring)
}
if (unlikely(ring->trace_irq_req &&
-i915_gem_request_completed(ring->trace_irq_req, true))) {
+i915_gem_request_completed(ring->trace_irq_req))) {
ring->irq_put(ring);
i915_gem_request_assign(&ring->trace_irq_req, NULL);
}
@@ -3026,7 +3026,7 @@ i915_gem_object_flush_active(struct drm_i915_gem_object
*obj)
if (list_empty(&req->list
[Intel-gfx] [PATCH 4/4] drm/i915: Updated request structure tracing
From: John Harrison
Added the '_complete' trace event which occurs when a fence/request is signaled
as complete. Also moved the notify event from the IRQ handler code to inside the
notify function itself.
For: VIZ-5190
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem.c | 3 +++
drivers/gpu/drm/i915/i915_irq.c | 2 --
drivers/gpu/drm/i915/i915_trace.h | 7 +--
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8aec326..ded5609 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2728,6 +2728,8 @@ void i915_gem_request_notify(struct intel_engine_cs *ring)
unsigned long flags;
u32 seqno;
+ trace_i915_gem_request_notify(ring);
+
if (list_empty(&ring->fence_signal_list))
return;
@@ -2740,6 +2742,7 @@ void i915_gem_request_notify(struct intel_engine_cs *ring)
continue;
fence_signal_locked(&req->fence);
+ trace_i915_gem_request_complete(req);
}
list_del_init(&req->signal_list);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3390943..8083d2f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -851,8 +851,6 @@ static void notify_ring(struct intel_engine_cs *ring)
if (!intel_ring_initialized(ring))
return;
- trace_i915_gem_request_notify(ring);
-
i915_gem_request_notify(ring);
wake_up_all(&ring->irq_queue);
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 63328b6..e03d6fc 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -532,16 +532,19 @@ TRACE_EVENT(i915_gem_request_notify,
__field(u32, dev)
__field(u32, ring)
__field(u32, seqno)
+__field(bool, is_empty)
),
TP_fast_assign(
__entry->dev = ring->dev->primary->index;
__entry->ring = ring->id;
__entry->seqno = ring->get_seqno(ring, false);
+ __entry->is_empty =
list_empty(&ring->fence_signal_list);
),
- TP_printk("dev=%u, ring=%u, seqno=%u",
- __entry->dev, __entry->ring, __entry->seqno)
+ TP_printk("dev=%u, ring=%u, seqno=%u, empty=%d",
+ __entry->dev, __entry->ring, __entry->seqno,
+ __entry->is_empty)
);
DEFINE_EVENT(i915_gem_request, i915_gem_request_retire,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] Convert requests to use struct fence
From: John Harrison There is a construct in the linux kernel called 'struct fence' that is intended to keep track of work that is executed on hardware. I.e. it solves the basic problem that the drivers 'struct drm_i915_gem_request' is trying to address. The request structure does quite a lot more than simply track the execution progress so is very definitely still required. However, the basic completion status side could be updated to use the ready made fence implementation and gain all the advantages that provides. This is work that was planned since the conversion of the driver from being seqno value based to being request structure based. This patch series does that work. [Patches against drm-intel-nightly tree fetched 23/06/2015] John Harrison (4): drm/i915: Convert requests to use struct fence drm/i915: Removed now redudant parameter to i915_gem_request_completed() drm/i915: Interrupt driven fences drm/i915: Updated request structure tracing drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 52 + drivers/gpu/drm/i915/i915_gem.c | 195 +--- drivers/gpu/drm/i915/i915_irq.c | 4 +- drivers/gpu/drm/i915/i915_trace.h | 7 +- drivers/gpu/drm/i915/intel_display.c| 2 +- drivers/gpu/drm/i915/intel_lrc.c| 3 + drivers/gpu/drm/i915/intel_pm.c | 4 +- drivers/gpu/drm/i915/intel_ringbuffer.c | 3 + drivers/gpu/drm/i915/intel_ringbuffer.h | 5 + 10 files changed, 232 insertions(+), 45 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Interrupt driven fences
From: John Harrison
The intended usage model for struct fence is that the signalled status should be
set on demand rather than polled. That is, there should not be a need for a
'signaled' function to be called everytime the status is queried. Instead,
'something' should be done to enable a signal callback from the hardware which
will update the state directly. In the case of requests, this is the seqno
update interrupt. The idea is that this callback will only be enabled on demand
when something actually tries to wait on the fence.
This change removes the polling test and replaces it with the callback scheme.
Each fence is added to a 'please poke me' list at the start of
i915_add_request(). The interrupt handler then scans through the 'poke me' list
when a new seqno pops out and signals any matching fence/request. The fence is
then removed from the list so the entire request stack does not need to be
scanned every time. Note that the fence is added to the list before the commands
to generate the seqno interrupt are added to the ring. Thus the sequence is
guaranteed to be race free if the interrupt is already enabled.
One complication here is that the 'poke me' system requires holding a reference
count on the request to guarantee that it won't be freed prematurely.
Unfortunately, it is unsafe to decrement the reference count from the interrupt
handler because if that is the last reference, the clean up code gets run and
the clean up code is not IRQ friendly. Hence, the request is added to a 'please
clean me' list that gets processed at retire time. Any request in this list
simply has its count decremented and is then removed from that list.
Note that the interrupt is only enabled on demand (i.e. when __wait_request() is
called). Thus there is still a potential race when enabling the interrupt as the
request may already have completed. However, this is simply solved by calling
the interrupt processing code immediately after enabling the interrupt and
thereby checking for already completed requests.
Lastly, the ring clean up code has the possibility to cancel outstanding
requests (e.g. because TDR has reset the ring). These requests will never get
signalled and so must be removed from the signal list manually. This is done by
setting a 'cancelled' flag and then calling the regular notify/retire code path
rather than attempting to duplicate the list manipulatation and clean up code in
multiple places. This also avoid any race condition where the cancellation
request might occur after/during the completion interrupt actually arriving.
For: VIZ-5190
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h | 8 ++
drivers/gpu/drm/i915/i915_gem.c | 136 +---
drivers/gpu/drm/i915/i915_irq.c | 2 +
drivers/gpu/drm/i915/intel_lrc.c| 2 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +
6 files changed, 143 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2e6c151..c1f69cc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2146,6 +2146,10 @@ struct drm_i915_gem_request {
* holding the driver mutex lock.
*/
struct fence fence;
+ struct list_head signal_list;
+ struct list_head unsignal_list;
+ bool cancelled;
+ bool irq_enabled;
/** On Which ring this request was generated */
struct drm_i915_private *i915;
@@ -2223,6 +2227,10 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
struct drm_i915_gem_request **req_out);
void i915_gem_request_cancel(struct drm_i915_gem_request *req);
+void i915_gem_request_submit(struct drm_i915_gem_request *req);
+void i915_gem_request_enable_interrupt(struct drm_i915_gem_request *req);
+void i915_gem_request_notify(struct intel_engine_cs *ring);
+
static inline bool i915_gem_request_completed(struct drm_i915_gem_request *req)
{
return fence_is_signaled(&req->fence);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0ae76b4..8aec326 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1231,6 +1231,11 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
if (list_empty(&req->list))
return 0;
+ /*
+* Enable interrupt completion of the request.
+*/
+ i915_gem_request_enable_interrupt(req);
+
if (i915_gem_request_completed(req))
return 0;
@@ -1391,6 +1396,10 @@ static void i915_gem_request_retire(struct
drm_i915_gem_request *request)
list_del_init(&request->list);
i915_gem_request_remove_from_client(request);
+ /* In case the request is still in the signal pending list */
+ if (!list_empty(&request->signal_list))
+ request->cancelled = true;
+
i
Re: [Intel-gfx] [PATCH] drm/i915: Update rps frequencies for BXT
On to, 2015-06-25 at 14:54 -0700, Bob Paauwe wrote:
> Broxton is using a different register and different bit ordering
> for rps status capabilities.
>
> Also GT perf freqency register is different for Broxton so update
> that.
>
> Signed-off-by: Bob Paauwe
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 21 -
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> drivers/gpu/drm/i915/intel_pm.c | 16
> 3 files changed, 30 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index f3b8062..8a2a456a 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1132,9 +1132,9 @@ static int i915_frequency_info(struct seq_file *m, void
> *unused)
> (rgvstat & MEMSTAT_PSTATE_MASK) >>
> MEMSTAT_PSTATE_SHIFT);
> } else if (IS_GEN6(dev) || (IS_GEN7(dev) && !IS_VALLEYVIEW(dev)) ||
> IS_BROADWELL(dev) || IS_GEN9(dev)) {
> - u32 gt_perf_status = I915_READ(GEN6_GT_PERF_STATUS);
> - u32 rp_state_limits = I915_READ(GEN6_RP_STATE_LIMITS);
> - u32 rp_state_cap = I915_READ(GEN6_RP_STATE_CAP);
> + u32 rp_state_limits;
> + u32 gt_perf_status;
> + u32 rp_state_cap;
> u32 rpmodectl, rpinclimit, rpdeclimit;
> u32 rpstat, cagf, reqf;
> u32 rpupei, rpcurup, rpprevup;
> @@ -1142,6 +1142,15 @@ static int i915_frequency_info(struct seq_file *m,
> void *unused)
> u32 pm_ier, pm_imr, pm_isr, pm_iir, pm_mask;
> int max_freq;
>
> + rp_state_limits = I915_READ(GEN6_RP_STATE_LIMITS);
> + if (IS_BROXTON(dev)) {
> + rp_state_cap = I915_READ(BXT_RP_STATE_CAP);
> + gt_perf_status = I915_READ(BXT_GT_PERF_STATUS);
> + } else {
> + rp_state_cap = I915_READ(GEN6_RP_STATE_CAP);
> + gt_perf_status = I915_READ(GEN6_GT_PERF_STATUS);
> + }
> +
> /* RPSTAT1 is in the GT power well */
> ret = mutex_lock_interruptible(&dev->struct_mutex);
> if (ret)
> @@ -1229,7 +1238,8 @@ static int i915_frequency_info(struct seq_file *m, void
> *unused)
> seq_printf(m, "Down threshold: %d%%\n",
> dev_priv->rps.down_threshold);
>
> - max_freq = (rp_state_cap & 0xff) >> 16;
> + max_freq = (IS_BROXTON(dev) ? rp_state_cap >> 0 :
> + rp_state_cap >> 16) & 0xff;
> max_freq *= (IS_SKYLAKE(dev) ? GEN9_FREQ_SCALER : 1);
> seq_printf(m, "Lowest (RPN) frequency: %dMHz\n",
> intel_gpu_freq(dev_priv, max_freq));
> @@ -1239,7 +1249,8 @@ static int i915_frequency_info(struct seq_file *m, void
> *unused)
> seq_printf(m, "Nominal (RP1) frequency: %dMHz\n",
> intel_gpu_freq(dev_priv, max_freq));
>
> - max_freq = rp_state_cap & 0xff;
> + max_freq = (IS_BROXTON(dev) ? rp_state_cap >> 16 :
> + rp_state_cap >> 0) & 0xff;
> max_freq *= (IS_SKYLAKE(dev) ? GEN9_FREQ_SCALER : 1);
> seq_printf(m, "Max non-overclocked (RP0) frequency: %dMHz\n",
> intel_gpu_freq(dev_priv, max_freq));
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index fa9ccb87..17b5ca2 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2734,8 +2734,10 @@ enum skl_disp_power_wells {
> #define GEN6_GT_THREAD_STATUS_CORE_MASK 0x7
>
> #define GEN6_GT_PERF_STATUS (MCHBAR_MIRROR_BASE_SNB + 0x5948)
> +#define BXT_GT_PERF_STATUS (MCHBAR_MIRROR_BASE_SNB + 0x7070)
Nitpick: the format in GT_PERF_STATUS is the same on SKL and BXT so you
could have redefined GEN6_GT_PERF_STATUS to be a wrapper macro similar
to what you did in v1 of this patch.
> #define GEN6_RP_STATE_LIMITS (MCHBAR_MIRROR_BASE_SNB + 0x5994)
> #define GEN6_RP_STATE_CAP(MCHBAR_MIRROR_BASE_SNB + 0x5998)
> +#define BXT_RP_STATE_CAP0x138170
>
> #define INTERVAL_1_28_US(us) (((us) * 100) >> 7)
> #define INTERVAL_1_33_US(us) (((us) * 3) >> 2)
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 32ff034..213da42 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4288,13 +4288,21 @@ static void gen6_init_rps_frequencies(struct
> drm_device *dev)
> u32 ddcc_status = 0;
> int ret;
>
> - rp_state_cap = I915_READ(GEN6_RP_STATE_CAP);
> /* All of these values are in units of 50MHz */
On SKL/BXT the unit is 16.66MHz, so the above comment could be
clarified.
> dev_priv->rps.cur_freq = 0;
> /* static values from HW: RP0 > RP1 > RPn (min_freq) */
> - dev_priv->rps.rp0_f
[Intel-gfx] [PATCH v3] drm/i915/lrc: Update PDPx registers with lri commands
A safer way to update the PDPx registers is sending lri commands, added
in the ring before the batchbuffer start. Otherwise, the ctx must be idle
before trying to change anything (but the ring-tail) in the ctx image. An
example where the ctx won't be idle is lite-restore.
This patch depends on 5b7e4c9ce ("drm/i915/gtt: Mark TLBS dirty for gen8+").
v2: Combine lri writes (and save 8 commands). (Mika)
v3: Rebase after ring/req changes, and removed references to deprecated patches.
Cc: Dave Gordon
Cc: Mika Kuoppala
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_lrc.c | 42
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d527b7b..e87d74c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1379,6 +1379,34 @@ static int gen9_init_render_ring(struct intel_engine_cs
*ring)
return init_workarounds_ring(ring);
}
+static int intel_logical_ring_emit_pdps(struct drm_i915_gem_request *req)
+{
+ struct i915_hw_ppgtt *ppgtt = req->ctx->ppgtt;
+ struct intel_engine_cs *ring = req->ring;
+ struct intel_ringbuffer *ringbuf = req->ringbuf;
+ const int num_lri_cmds = GEN8_LEGACY_PDPES * 2;
+ int i, ret;
+
+ ret = intel_logical_ring_begin(req, num_lri_cmds * 2 + 2);
+ if (ret)
+ return ret;
+
+ intel_logical_ring_emit(ringbuf, MI_LOAD_REGISTER_IMM(num_lri_cmds));
+ for (i = GEN8_LEGACY_PDPES - 1; i >= 0; i--) {
+ const dma_addr_t pd_daddr = i915_page_dir_dma_addr(ppgtt, i);
+
+ intel_logical_ring_emit(ringbuf, GEN8_RING_PDP_UDW(ring, i));
+ intel_logical_ring_emit(ringbuf, upper_32_bits(pd_daddr));
+ intel_logical_ring_emit(ringbuf, GEN8_RING_PDP_LDW(ring, i));
+ intel_logical_ring_emit(ringbuf, lower_32_bits(pd_daddr));
+ }
+
+ intel_logical_ring_emit(ringbuf, MI_NOOP);
+ intel_logical_ring_advance(ringbuf);
+
+ return 0;
+}
+
static int gen8_emit_bb_start(struct drm_i915_gem_request *req,
u64 offset, unsigned dispatch_flags)
{
@@ -1386,6 +1414,20 @@ static int gen8_emit_bb_start(struct
drm_i915_gem_request *req,
bool ppgtt = !(dispatch_flags & I915_DISPATCH_SECURE);
int ret;
+ /* Don't rely in hw updating PDPs, specially in lite-restore.
+* Ideally, we should set Force PD Restore in ctx descriptor,
+* but we can't. Force Restore would be a second option, but
+* it is unsafe in case of lite-restore (because the ctx is
+* not idle). */
+ if (req->ctx->ppgtt &&
+ (intel_ring_flag(req->ring) & req->ctx->ppgtt->pd_dirty_rings)) {
+ ret = intel_logical_ring_emit_pdps(req);
+ if (ret)
+ return ret;
+
+ req->ctx->ppgtt->pd_dirty_rings &= ~intel_ring_flag(req->ring);
+ }
+
ret = intel_logical_ring_begin(req, 4);
if (ret)
return ret;
--
2.4.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3 5/7] pwm: crc: Add Crystalcove (CRC) PWM driver
On 06/26/2015 02:32 PM, Shobhit Kumar wrote: The Crystalcove PMIC provides three PWM signals and this driver exports one of them on the BYT platform which is used to control backlight for DSI panel. This is platform device implementation of the drivers/mfd cell device for CRC PMIC. CC: Samuel Ortiz Cc: Linus Walleij Cc: Alexandre Courbot Cc: Thierry Reding Cc: Paul Bolle Cc: Paul Gortmaker Tested-by: Ville Syrjälä Signed-off-by: Shobhit Kumar --- v2: Use the existing config callback with duty_ns and period_ns(Thierry) v3: Correct the subject line (Lee jones) v4: Address comment by Thierry & Paul - Commit message update and fixes for few syntax errors - Add PWM_CRC in Kconfig and Makefile sorted alphabetically - Use the PWM_BASE_CLK as 600 for better code readability - Remove the redundant rule of three while calculating pwm level - Use the platform_device in pwm_chip - Use builin_platform_driver v5: Address comments by Varka - Make the bit definition using BIT macro - reorder probe and remove code to directly return from pwmchip_add/remove drivers/pwm/Kconfig | 7 +++ drivers/pwm/Makefile | 1 + drivers/pwm/pwm-crc.c | 143 ++ 3 files changed, 151 insertions(+) create mode 100644 drivers/pwm/pwm-crc.c Reviewed-by: Varka Bhadram -- Best regards, Varka Bhadram. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/18] drm/i915/gtt: One instance of scratch page table/directory
Daniel Vetter writes:
> On Thu, Jun 25, 2015 at 06:35:18PM +0300, Mika Kuoppala wrote:
>> +static int setup_scratch(struct i915_address_space *vm)
>> +{
>> +struct i915_address_space *ggtt_vm = &to_i915(vm->dev)->gtt.base;
>> +
>> +if (i915_is_ggtt(vm))
>> +return setup_scratch_ggtt(vm);
>> +
>> +vm->scratch_page = ggtt_vm->scratch_page;
>> +vm->scratch_pt = ggtt_vm->scratch_pt;
>> +vm->scratch_pd = ggtt_vm->scratch_pd;
>> +
>> +return 0;
>> +}
>
> The point of a ppgtt is full isolation, sharing the scratch page destroys
> that. Hence nack. If you want a bit of polish, renaming initialize_pd/pt
> to initialize_scratch_pd/pt would make sense though I think.
> -Daniel
We already have a shared scratch. This just makes the upper layer
structures also shared as there is no point of having identical
scratch pt and scratch pd pointing to the same scratch.
Do we want per ppgtt scratch? I have patches for that also.
-Mika
>> +
>> +static void check_scratch_page(struct i915_address_space *vm)
>> +{
>> +struct i915_hw_ppgtt *ppgtt =
>> +container_of(vm, struct i915_hw_ppgtt, base);
>> +int i;
>> +u64 *vaddr;
>> +
>> +vaddr = kmap_px(vm->scratch_page);
>> +
>> +for (i = 0; i < PAGE_SIZE / sizeof(u64); i++) {
>> +if (vaddr[i] == SCRATCH_PAGE_MAGIC)
>> +continue;
>> +
>> +DRM_ERROR("%p scratch[%d] = 0x%08llx\n", vm, i, vaddr[i]);
>> +break;
>> +}
>> +
>> +kunmap_px(ppgtt, vaddr);
>> +}
>> +
>> +static void cleanup_scratch_ggtt(struct i915_address_space *vm)
>> +{
>> +check_scratch_page(vm);
>> +free_scratch_page(vm);
>> +
>> +if (INTEL_INFO(vm->dev)->gen < 6)
>> +return;
>> +
>> +free_pt(vm->dev, vm->scratch_pt);
>> +
>> +if (INTEL_INFO(vm->dev)->gen >= 8)
>> +free_pd(vm->dev, vm->scratch_pd);
>> +}
>> +
>> +static void cleanup_scratch(struct i915_address_space *vm)
>> +{
>> +if (i915_is_ggtt(vm))
>> +cleanup_scratch_ggtt(vm);
>> +
>> +vm->scratch_page = NULL;
>> +vm->scratch_pt = NULL;
>> +vm->scratch_pd = NULL;
>> +}
>> +
>> /* Broadwell Page Directory Pointer Descriptors */
>> static int gen8_write_pdp(struct drm_i915_gem_request *req,
>>unsigned entry,
>> @@ -525,7 +686,7 @@ static void gen8_ppgtt_clear_range(struct
>> i915_address_space *vm,
>> unsigned num_entries = length >> PAGE_SHIFT;
>> unsigned last_pte, i;
>>
>> -scratch_pte = gen8_pte_encode(px_dma(ppgtt->base.scratch_page),
>> +scratch_pte = gen8_pte_encode(px_dma(vm->scratch_page),
>>I915_CACHE_LLC, use_scratch);
>>
>> while (num_entries) {
>> @@ -609,16 +770,6 @@ static void gen8_ppgtt_insert_entries(struct
>> i915_address_space *vm,
>> kunmap_px(ppgtt, pt_vaddr);
>> }
>>
>> -static void gen8_initialize_pd(struct i915_address_space *vm,
>> - struct i915_page_directory *pd)
>> -{
>> -gen8_pde_t scratch_pde;
>> -
>> -scratch_pde = gen8_pde_encode(px_dma(vm->scratch_pt), I915_CACHE_LLC);
>> -
>> -fill_px(vm->dev, pd, scratch_pde);
>> -}
>> -
>> static void gen8_free_page_tables(struct i915_page_directory *pd, struct
>> drm_device *dev)
>> {
>> int i;
>> @@ -649,8 +800,7 @@ static void gen8_ppgtt_cleanup(struct i915_address_space
>> *vm)
>> free_pd(ppgtt->base.dev, ppgtt->pdp.page_directory[i]);
>> }
>>
>> -free_pd(vm->dev, vm->scratch_pd);
>> -free_pt(vm->dev, vm->scratch_pt);
>> +cleanup_scratch(vm);
>> }
>>
>> /**
>> @@ -937,16 +1087,7 @@ err_out:
>> */
>> static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
>> {
>> -ppgtt->base.scratch_pt = alloc_pt(ppgtt->base.dev);
>> -if (IS_ERR(ppgtt->base.scratch_pt))
>> -return PTR_ERR(ppgtt->base.scratch_pt);
>> -
>> -ppgtt->base.scratch_pd = alloc_pd(ppgtt->base.dev);
>> -if (IS_ERR(ppgtt->base.scratch_pd))
>> -return PTR_ERR(ppgtt->base.scratch_pd);
>> -
>> -gen8_initialize_pt(&ppgtt->base, ppgtt->base.scratch_pt);
>> -gen8_initialize_pd(&ppgtt->base, ppgtt->base.scratch_pd);
>> +int ret;
>>
>> ppgtt->base.start = 0;
>> ppgtt->base.total = 1ULL << 32;
>> @@ -966,6 +1107,10 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
>>
>> ppgtt->switch_mm = gen8_mm_switch;
>>
>> +ret = setup_scratch(&ppgtt->base);
>> +if (ret)
>> +return ret;
>> +
>> return 0;
>> }
>>
>> @@ -1272,19 +1417,6 @@ static void gen6_ppgtt_insert_entries(struct
>> i915_address_space *vm,
>> kunmap_px(ppgtt, pt_vaddr);
>> }
>>
>> -static void gen6_initialize_pt(struct i915_address_space *vm,
>> - struct i915_page_table *pt)
>> -{
>> -gen6_pte_t scratch_pte;
>> -
>> -WARN_ON(px_dma(vm->scratch_page) == 0);
>> -
>> -scratch_pte = vm->pte_encode(px_dma(vm->scratch_page),
>> -
[Intel-gfx] [PATCH i-g-t v3] tests/gem_ringfill: Add {render, blitter}-forked-1 subtests.
Add forking subtests to gem_ringfill. Tests cause consistent GPU
hangs on SKL.
v2: Removed noop parts.
v3:
- Allow executing the tests in order too (Chris Wilson).
- Rename the tests to -forked-1
Cc: Mika Kuoppala
Cc: Chris Wilson
Signed-off-by: Joonas Lahtinen
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89959
---
tests/gem_ringfill.c | 91
1 file changed, 57 insertions(+), 34 deletions(-)
diff --git a/tests/gem_ringfill.c b/tests/gem_ringfill.c
index 85b01ea..06da1c2 100644
--- a/tests/gem_ringfill.c
+++ b/tests/gem_ringfill.c
@@ -55,6 +55,7 @@ struct bo {
};
static const int width = 512, height = 512;
+int fd;
static void create_bo(drm_intel_bufmgr *bufmgr,
struct bo *b,
@@ -193,9 +194,52 @@ static void blt_copy(struct intel_batchbuffer *batch,
intel_batchbuffer_flush(batch);
}
-drm_intel_bufmgr *bufmgr;
-struct intel_batchbuffer *batch;
-int fd;
+static void run_test(int ring, bool interruptible, int nchild) {
+ drm_intel_bufmgr *bufmgr;
+ struct intel_batchbuffer *batch;
+ igt_render_copyfunc_t copy;
+ const char* ring_name;
+
+ bufmgr = drm_intel_bufmgr_gem_init(fd, 4096);
+ igt_require(bufmgr);
+ drm_intel_bufmgr_gem_enable_reuse(bufmgr);
+
+ batch = intel_batchbuffer_alloc(bufmgr, intel_get_drm_devid(fd));
+ igt_require(batch);
+
+ if (ring == I915_EXEC_RENDER) {
+ copy = igt_get_render_copyfunc(batch->devid);
+ ring_name = "render";
+ } else if (ring == I915_EXEC_BLT) {
+ copy = blt_copy;
+ ring_name = "blt";
+ } else {
+ igt_fail_on_f(true, "Unsupported ring.");
+ }
+
+ /* Not all platforms have dedicated render ring. */
+ igt_require(copy);
+
+ if (interruptible) {
+ igt_fork_signal_helper();
+ }
+
+ if (nchild) {
+ igt_fork(child, nchild) {
+ check_ring(bufmgr, batch, ring_name, copy);
+ }
+ igt_waitchildren();
+ } else {
+ check_ring(bufmgr, batch, ring_name, copy);
+ }
+
+ if (interruptible) {
+ igt_stop_signal_helper();
+ }
+
+ intel_batchbuffer_free(batch);
+ drm_intel_bufmgr_destroy(bufmgr);
+}
igt_main
{
@@ -203,48 +247,27 @@ igt_main
igt_fixture {
fd = drm_open_any();
-
- bufmgr = drm_intel_bufmgr_gem_init(fd, 4096);
- drm_intel_bufmgr_gem_enable_reuse(bufmgr);
- batch = intel_batchbuffer_alloc(bufmgr,
intel_get_drm_devid(fd));
}
igt_subtest("blitter")
- check_ring(bufmgr, batch, "blt", blt_copy);
+ run_test(I915_EXEC_BLT, false, 0);
- /* Strictly only required on architectures with a separate BLT ring,
-* but lets stress everybody.
-*/
- igt_subtest("render") {
- igt_render_copyfunc_t copy;
-
- copy = igt_get_render_copyfunc(batch->devid);
- igt_require(copy);
+ igt_subtest("render")
+ run_test(I915_EXEC_RENDER, false, 0);
- check_ring(bufmgr, batch, "render", copy);
- }
-
- igt_fork_signal_helper();
igt_subtest("blitter-interruptible")
- check_ring(bufmgr, batch, "blt", blt_copy);
+ run_test(I915_EXEC_BLT, true, 0);
- /* Strictly only required on architectures with a separate BLT ring,
-* but lets stress everybody.
-*/
- igt_subtest("render-interruptible") {
- igt_render_copyfunc_t copy;
+ igt_subtest("render-interruptible")
+ run_test(I915_EXEC_RENDER, true, 0);
- copy = igt_get_render_copyfunc(batch->devid);
- igt_require(copy);
+ igt_subtest("blitter-forked-1")
+ run_test(I915_EXEC_BLT, false, 1);
- check_ring(bufmgr, batch, "render", copy);
- }
- igt_stop_signal_helper();
+ igt_subtest("render-forked-1")
+ run_test(I915_EXEC_RENDER, false, 1);
igt_fixture {
- intel_batchbuffer_free(batch);
- drm_intel_bufmgr_destroy(bufmgr);
-
close(fd);
}
}
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: fix backlight after resume on 855gm
Some 855gm models (at least ThinkPad X40) regressed because of
commit b0cd324faed23d10d66ba6ade66579c681feef6f
Author: Jani Nikula
Date: Wed Nov 12 16:25:43 2014 +0200
drm/i915: don't save/restore backlight hist ctl registers
which tried to make our driver more robust by not blindly saving and
restoring registers, but it failed to take into account
commit 0eb96d6ed38430b72897adde58f5477a6b71757a
Author: Jesse Barnes
Date: Wed Oct 14 12:33:41 2009 -0700
drm/i915: save/restore BLC histogram control reg across suspend/resume
Fix the regression by enabling hist ctl on gen2.
v2: Improved the comment.
v3: Improved the comment, again.
Reported-and-tested-by: Philipp Gesang
References: http://mid.gmane.org/20150623222648.GD12335@acheron
Fixes: b0cd324faed2 ("drm/i915: don't save/restore backlight hist ctl
registers")
Cc: Ville Syrjälä
Cc: sta...@vger.kernel.org
Acked-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h| 1 +
drivers/gpu/drm/i915/intel_panel.c | 8
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fa9ccb87eb66..bf7c08b94088 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3507,6 +3507,7 @@ enum skl_disp_power_wells {
#define BLM_POLARITY_PNV (1 << 0) /* pnv only */
#define BLC_HIST_CTL (dev_priv->info.display_mmio_offset + 0x61260)
+#define BLM_HISTOGRAM_ENABLE (1 << 31)
/* New registers for PCH-split platforms. Safe where new bits show up, the
* register layout machtes with gen4 BLC_PWM_CTL[12]. */
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 7d83527f95f7..55aad2322e10 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -907,6 +907,14 @@ static void i9xx_enable_backlight(struct intel_connector
*connector)
/* XXX: combine this into above write? */
intel_panel_actually_set_backlight(connector, panel->backlight.level);
+
+ /*
+* Needed to enable backlight on some 855gm models. BLC_HIST_CTL is
+* 855gm only, but checking for gen2 is safe, as 855gm is the only gen2
+* that has backlight.
+*/
+ if (IS_GEN2(dev))
+ I915_WRITE(BLC_HIST_CTL, BLM_HISTOGRAM_ENABLE);
}
static void i965_enable_backlight(struct intel_connector *connector)
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix backlight after resume on 855gm
On Fri, Jun 26, 2015 at 01:54:18PM +0300, Jani Nikula wrote:
> Some 855gm models (at least ThinkPad X40) regressed because of
>
> commit b0cd324faed23d10d66ba6ade66579c681feef6f
> Author: Jani Nikula
> Date: Wed Nov 12 16:25:43 2014 +0200
>
> drm/i915: don't save/restore backlight hist ctl registers
>
> which tried to make our driver more robust by not blindly saving and
> restoring registers, but it failed to take into account
>
> commit 0eb96d6ed38430b72897adde58f5477a6b71757a
> Author: Jesse Barnes
> Date: Wed Oct 14 12:33:41 2009 -0700
>
> drm/i915: save/restore BLC histogram control reg across suspend/resume
>
> Fix the regression by enabling hist ctl on gen2.
>
> v2: Improved the comment.
>
> Reported-and-tested-by: Philipp Gesang
> References: http://mid.gmane.org/20150623222648.GD12335@acheron
> Fixes: b0cd324faed2 ("drm/i915: don't save/restore backlight hist ctl
> registers")
> Cc: Ville Syrjälä
> Cc: sta...@vger.kernel.org
> Acked-by: Chris Wilson
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_reg.h| 1 +
> drivers/gpu/drm/i915/intel_panel.c | 7 +++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index fa9ccb87eb66..bf7c08b94088 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3507,6 +3507,7 @@ enum skl_disp_power_wells {
> #define BLM_POLARITY_PNV (1 << 0) /* pnv only */
>
> #define BLC_HIST_CTL (dev_priv->info.display_mmio_offset + 0x61260)
> +#define BLM_HISTOGRAM_ENABLE(1 << 31)
>
> /* New registers for PCH-split platforms. Safe where new bits show up, the
> * register layout machtes with gen4 BLC_PWM_CTL[12]. */
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index 7d83527f95f7..a55477c59559 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -907,6 +907,13 @@ static void i9xx_enable_backlight(struct intel_connector
> *connector)
>
> /* XXX: combine this into above write? */
> intel_panel_actually_set_backlight(connector, panel->backlight.level);
> +
> + /*
> + * Needed to enable backlight on some 855gm models.
* BLC_HIST_CTL is 855gm only, but checking for gen2 is
> + * safe, as 855gm is the only gen2 that has backlight.
> + */
I just felt the second sentence lacked a little context to justify
itself.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Color management in DRM framework
Hi Emil, Thanks your time and suggestions. We actually have the complete implementation ready with us, but we wanted to know if community is agreeing to the design itself. In fact that was our plan ahead, that if we don’t get enough comments on the design, we will start pushing the patches. We will wait for few more days, and then as you suggested, we will send the patch series with design explained in the cover-letter itself. Regards Shashank -Original Message- From: Emil Velikov [mailto:emil.l.veli...@gmail.com] Sent: Friday, June 26, 2015 4:12 PM To: Sharma, Shashank Cc: robdcl...@gmail.com; alexander.deuc...@amd.com; bske...@redhat.com; dri-de...@lists.freedesktop.org; Matheson, Annie J; R, Dhanya p; Pillai, Manikandan K; Mukherjee, Indranil; Barnes, Jesse; Smith, Gary K; Palleti, Avinash Reddy; Kamath, Sunil; Vetter, Daniel; intel-gfx@lists.freedesktop.org; Bhattacharjee, Susanta Subject: Re: Color management in DRM framework Hi Shashank, On 25 June 2015 at 17:19, Sharma, Shashank wrote: > Gentle reminder for the review and comments. > > > > For those who prefer having the design available with the mail, I am > attaching a PDF copy of the design document with this mail. > Perhaps I'm not hte best person to comment on this, but many times when it comes to kernel development people explicitly describe the design in the summary email. As such issues like - expired links, unknow/unsupported format, etc. become impossible, plus everyone can reply inline on the part which they have comment on. Additionally (abeit very uncommon) people filter out HTML emails, which might contribute why there isn't any input on this. And finally you mention that there is a rough implementaiton, but I cannot see such one reaching the dri-devel mailing list. Did you send it over ? If not linking a repo for people can take a look could help. Cheers, Emil P.S. Some of us have a thing for top posting - that is, it's not always seen as a good idea. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix backlight after resume on 855gm
Some 855gm models (at least ThinkPad X40) regressed because of
commit b0cd324faed23d10d66ba6ade66579c681feef6f
Author: Jani Nikula
Date: Wed Nov 12 16:25:43 2014 +0200
drm/i915: don't save/restore backlight hist ctl registers
which tried to make our driver more robust by not blindly saving and
restoring registers, but it failed to take into account
commit 0eb96d6ed38430b72897adde58f5477a6b71757a
Author: Jesse Barnes
Date: Wed Oct 14 12:33:41 2009 -0700
drm/i915: save/restore BLC histogram control reg across suspend/resume
Fix the regression by enabling hist ctl on gen2.
v2: Improved the comment.
Reported-and-tested-by: Philipp Gesang
References: http://mid.gmane.org/20150623222648.GD12335@acheron
Fixes: b0cd324faed2 ("drm/i915: don't save/restore backlight hist ctl
registers")
Cc: Ville Syrjälä
Cc: sta...@vger.kernel.org
Acked-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h| 1 +
drivers/gpu/drm/i915/intel_panel.c | 7 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fa9ccb87eb66..bf7c08b94088 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3507,6 +3507,7 @@ enum skl_disp_power_wells {
#define BLM_POLARITY_PNV (1 << 0) /* pnv only */
#define BLC_HIST_CTL (dev_priv->info.display_mmio_offset + 0x61260)
+#define BLM_HISTOGRAM_ENABLE (1 << 31)
/* New registers for PCH-split platforms. Safe where new bits show up, the
* register layout machtes with gen4 BLC_PWM_CTL[12]. */
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 7d83527f95f7..a55477c59559 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -907,6 +907,13 @@ static void i9xx_enable_backlight(struct intel_connector
*connector)
/* XXX: combine this into above write? */
intel_panel_actually_set_backlight(connector, panel->backlight.level);
+
+ /*
+* Needed to enable backlight on some 855gm models. Checking for gen2 is
+* safe, as 855gm is the only gen2 that has backlight.
+*/
+ if (IS_GEN2(dev))
+ I915_WRITE(BLC_HIST_CTL, BLM_HISTOGRAM_ENABLE);
}
static void i965_enable_backlight(struct intel_connector *connector)
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
