Re: [Intel-gfx] [PATCH 1/2] drm/i915: Unconditionally do fb tracking invalidate in set_domain
On Thu, Jun 25, 2015 at 11:47:22PM +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 :( Reported-by: Paulo Zanoni paulo.r.zan...@intel.com Cc: Paulo Zanoni paulo.r.zan...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@intel.com Note that I have a variant on this that observes that internally users all honor the fb invalidation and so we can move this into the set-domain ioctl. -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 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 david.s.gor...@intel.com
---
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
--
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 i-g-t 1/4] lib: Add a tiny utility function to compute averages
On Thu, Jun 25, 2015 at 04:21:40PM +0100, Damien Lespiau wrote:
The master plan would be to get a bit more stats in it, at least the
standard deviation and confidence interval. Just need the average for
now.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
gtkdoc is missing for this.
-Daniel
---
lib/Makefile.sources | 2 ++
lib/igt_stats.c| 56
++
lib/igt_stats.h| 36 +
lib/tests/.gitignore | 1 +
lib/tests/Makefile.sources | 1 +
lib/tests/igt_stats.c | 49
6 files changed, 145 insertions(+)
create mode 100644 lib/igt_stats.c
create mode 100644 lib/igt_stats.h
create mode 100644 lib/tests/igt_stats.c
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 85dc321..f8a1b92 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -12,6 +12,8 @@ libintel_tools_la_SOURCES = \
igt_aux.h \
igt_gt.c\
igt_gt.h\
+ igt_stats.c \
+ igt_stats.h \
instdone.c \
instdone.h \
intel_batchbuffer.c \
diff --git a/lib/igt_stats.c b/lib/igt_stats.c
new file mode 100644
index 000..fcf7abe
--- /dev/null
+++ b/lib/igt_stats.c
@@ -0,0 +1,56 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include igt_core.h
+#include igt_stats.h
+
+void igt_stats_init(igt_stats_t *stats, unsigned int capacity)
+{
+ stats-values = calloc(capacity, sizeof(*stats-values));
+ igt_assert(stats-values);
+ stats-capacity = capacity;
+ stats-n_values = 0;
+}
+
+void igt_stats_fini(igt_stats_t *stats)
+{
+ free(stats-values);
+}
+
+void igt_stats_push(igt_stats_t *stats, uint64_t value)
+{
+ igt_assert(stats-n_values stats-capacity);
+ stats-values[stats-n_values++] = value;
+}
+
+double igt_stats_get_average(igt_stats_t *stats)
+{
+ unsigned int i;
+ double a = 0.0;
+
+ for (i = 0; i stats-n_values; i++)
+ a += (double)stats-values[i] / stats-n_values;
+
+ return a;
+}
diff --git a/lib/igt_stats.h b/lib/igt_stats.h
new file mode 100644
index 000..99dc1c9
--- /dev/null
+++ b/lib/igt_stats.h
@@ -0,0 +1,36 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include stdint.h
+
+typedef struct {
+ uint64_t *values;
+ unsigned int capacity;
+ unsigned int n_values;
+} igt_stats_t;
+
+void igt_stats_init(igt_stats_t *stats, unsigned int capacity);
+void igt_stats_fini(igt_stats_t *stats);
+void
Re: [Intel-gfx] [PATCH 03/18] drm/i915/gtt: Allow = 4GB sizes for vm.
On Thu, Jun 25, 2015 at 06:46:06PM +0100, Michel Thierry wrote:
On 6/25/2015 4:35 PM, Mika Kuoppala wrote:
We can have exactly 4GB sized ppgtt with 32bit system.
size_t is inadequate for this.
v2: Convert a lot more places (Daniel)
Looks good to me.
The only possible remaining size_t are the return values in the *_pte_count
functions in i915_gem_gtt.h, but these won't return anything larger than
'512' (so they could be u32 if we want to get rid of size_t completely).
I also tried reverting commit 501fd70f (drm/i915: limit PPGTT size to 2GB
in 32-bit platforms) in a bdw running a 32-bit kernel and it worked fine.
Reviewed-by: Michel Thierry michel.thie...@intel.com
i915_gem_obj_offset is the first one I've checked and still unsigned long.
Essentially everything dealing with a g/ppgtt offset needs to be an u64,
starting from drm_mm down to gtt pte writing on the other end.
I merged up to this patch meanwhile.
-Daniel
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
drivers/char/agp/intel-gtt.c| 4 ++--
drivers/gpu/drm/i915/i915_debugfs.c | 42
++---
drivers/gpu/drm/i915/i915_gem.c | 6 +++---
drivers/gpu/drm/i915/i915_gem_gtt.c | 22 +--
drivers/gpu/drm/i915/i915_gem_gtt.h | 12 +--
include/drm/intel-gtt.h | 4 ++--
6 files changed, 45 insertions(+), 45 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 0b4188b..4734d02 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1408,8 +1408,8 @@ int intel_gmch_probe(struct pci_dev *bridge_pdev,
struct pci_dev *gpu_pdev,
}
EXPORT_SYMBOL(intel_gmch_probe);
-void intel_gtt_get(size_t *gtt_total, size_t *stolen_size,
- phys_addr_t *mappable_base, unsigned long *mappable_end)
+void intel_gtt_get(u64 *gtt_total, size_t *stolen_size,
+ phys_addr_t *mappable_base, u64 *mappable_end)
{
*gtt_total = intel_private.gtt_total_entries PAGE_SHIFT;
*stolen_size = intel_private.stolen_size;
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index f3b8062..c654b7d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -198,7 +198,7 @@ static int i915_gem_object_list_info(struct seq_file *m,
void *data)
struct drm_i915_private *dev_priv = dev-dev_private;
struct i915_address_space *vm = dev_priv-gtt.base;
struct i915_vma *vma;
- size_t total_obj_size, total_gtt_size;
+ u64 total_obj_size, total_gtt_size;
int count, ret;
ret = mutex_lock_interruptible(dev-struct_mutex);
@@ -231,7 +231,7 @@ static int i915_gem_object_list_info(struct seq_file *m,
void *data)
}
mutex_unlock(dev-struct_mutex);
- seq_printf(m, Total %d objects, %zu bytes, %zu GTT size\n,
+ seq_printf(m, Total %d objects, %llu bytes, %llu GTT size\n,
count, total_obj_size, total_gtt_size);
return 0;
}
@@ -253,7 +253,7 @@ static int i915_gem_stolen_list_info(struct seq_file *m,
void *data)
struct drm_device *dev = node-minor-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_gem_object *obj;
- size_t total_obj_size, total_gtt_size;
+ u64 total_obj_size, total_gtt_size;
LIST_HEAD(stolen);
int count, ret;
@@ -292,7 +292,7 @@ static int i915_gem_stolen_list_info(struct seq_file *m,
void *data)
}
mutex_unlock(dev-struct_mutex);
- seq_printf(m, Total %d objects, %zu bytes, %zu GTT size\n,
+ seq_printf(m, Total %d objects, %llu bytes, %llu GTT size\n,
count, total_obj_size, total_gtt_size);
return 0;
}
@@ -310,10 +310,10 @@ static int i915_gem_stolen_list_info(struct seq_file
*m, void *data)
struct file_stats {
struct drm_i915_file_private *file_priv;
- int count;
- size_t total, unbound;
- size_t global, shared;
- size_t active, inactive;
+ unsigned long count;
+ u64 total, unbound;
+ u64 global, shared;
+ u64 active, inactive;
};
static int per_file_stats(int id, void *ptr, void *data)
@@ -370,7 +370,7 @@ static int per_file_stats(int id, void *ptr, void *data)
#define print_file_stats(m, name, stats) do { \
if (stats.count) \
- seq_printf(m, %s: %u objects, %zu bytes (%zu active, %zu
inactive, %zu global, %zu shared, %zu unbound)\n, \
+ seq_printf(m, %s: %lu objects, %llu bytes (%llu active,
%llu inactive, %llu global, %llu shared, %llu unbound)\n, \
name, \
stats.count, \
stats.total, \
@@ -420,7 +420,7 @@ static int i915_gem_object_info(struct
[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. Cc: Chris Wilson ch...@chris-wilson.co.uk Reported-by: Paulo Zanoni paulo.r.zan...@intel.com Cc: Paulo Zanoni paulo.r.zan...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@intel.com --- drivers/gpu/drm/i915/i915_gem.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index f79ce9f22312..80b696a8277c 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1614,6 +1614,9 @@ 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, ORIGIN_CPU); + unref: drm_gem_object_unreference(obj-base); unlock: @@ -3982,9 +3985,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 +4256,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] [v2 7/7] drm/i915: Backlight control using CRC PMIC based PWM driver
On Thu, 25 Jun 2015, Shobhit Kumar ku...@shobhit.info wrote:
On Thu, Jun 25, 2015 at 2:18 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Mon, Jun 22, 2015 at 04:24:25PM +0530, Shobhit Kumar wrote:
Use the CRC PWM device in intel_panel.c and add new MIPI backlight
specififc callbacks
v2: Modify to use pwm_config callback
v3: Addressed Jani's comments
- Renamed all function as pwm_* instead of vlv_*
- Call intel_panel_actually_set_backlight in enable function
- Return -ENODEV in case pwm_get fails
- in case pwm_config error return error cdoe from pwm_config
- Cleanup pwm in intel_panel_destroy_backlight
CC: Samuel Ortiz sa...@linux.intel.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Thierry Reding thierry.red...@gmail.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/intel_drv.h | 4 ++
drivers/gpu/drm/i915/intel_dsi.c | 6 +++
drivers/gpu/drm/i915/intel_panel.c | 95
--
3 files changed, 100 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 2afb31a..561c17f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -182,6 +182,10 @@ struct intel_panel {
bool enabled;
bool combination_mode; /* gen 2/4 only */
bool active_low_pwm;
+
+ /* PWM chip */
+ struct pwm_device *pwm;
+
struct backlight_device *device;
} backlight;
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index c4db74a..be8722c 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -402,6 +402,8 @@ static void intel_dsi_enable(struct intel_encoder
*encoder)
intel_dsi_port_enable(encoder);
}
+
+ intel_panel_enable_backlight(intel_dsi-attached_connector);
}
static void intel_dsi_pre_enable(struct intel_encoder *encoder)
@@ -466,6 +468,8 @@ static void intel_dsi_pre_disable(struct intel_encoder
*encoder)
DRM_DEBUG_KMS(\n);
+ intel_panel_disable_backlight(intel_dsi-attached_connector);
+
if (is_vid_mode(intel_dsi)) {
/* Send Shutdown command to the panel in LP mode */
for_each_dsi_port(port, intel_dsi-ports)
@@ -1132,6 +1136,8 @@ void intel_dsi_init(struct drm_device *dev)
}
intel_panel_init(intel_connector-panel, fixed_mode, NULL);
+ intel_panel_setup_backlight(connector,
+ (intel_encoder-crtc_mask = (1 PIPE_A)) ? PIPE_A : PIPE_B);
^
Whoops. But since the PWM backlight doesn't need the initial pipe for
anything you can actually just pass INVALID_PIPE here.
You are right, its unused, but I thought passing right value still
made sense. Otherwise it makes it look like I am setting up back-light
for invalid pipe, when the real meaning is something like
DONTCARE_PIPE
return;
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 7d83527..2aa30db 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -32,8 +32,12 @@
#include linux/kernel.h
#include linux/moduleparam.h
+#include linux/pwm.h
#include intel_drv.h
+#define CRC_PMIC_PWM_PERIOD_NS 21333
+#define CRC_PMIC_PWM_STEPS 255
This define appears to be unused.
Yeah, missed removing it.
+
void
intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
@@ -544,6 +548,15 @@ static u32 bxt_get_backlight(struct intel_connector
*connector)
return I915_READ(BXT_BLC_PWM_DUTY1);
}
+static u32 pwm_get_backlight(struct intel_connector *connector)
+{
+ struct intel_panel *panel = connector-panel;
+ int duty_ns;
+
+ duty_ns = pwm_get_duty_cycle(panel-backlight.pwm);
+ return DIV_ROUND_UP(duty_ns * 100, CRC_PMIC_PWM_PERIOD_NS);
+}
+
static u32 intel_panel_get_backlight(struct intel_connector *connector)
{
struct drm_device *dev = connector-base.dev;
@@ -632,6 +645,14 @@ static void bxt_set_backlight(struct intel_connector
*connector, u32 level)
I915_WRITE(BXT_BLC_PWM_DUTY1, level);
}
+static void pwm_set_backlight(struct intel_connector *connector, u32 level)
+{
+ struct intel_panel *panel = connector-panel;
+ int duty_ns = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
+
+ pwm_config(panel-backlight.pwm, duty_ns, CRC_PMIC_PWM_PERIOD_NS);
+}
+
static void
intel_panel_actually_set_backlight(struct intel_connector *connector, u32
level)
{
@@ -769,6 +790,16 @@ static void bxt_disable_backlight(struct
intel_connector *connector)
I915_WRITE(BXT_BLC_PWM_CTL1, tmp ~BXT_BLC_PWM_ENABLE);
}
+static void
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 michel.thie...@intel.com 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 michel.thie...@intel.com
Reviewed-by: Mika Kuoppala mika.kuopp...@intel.com
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
[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 chandra.kond...@intel.com
---
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)
td valign=top TBD/td
/tr
tr
- td rowspan=21 valign=top i915/td
+ td rowspan=22 valign=top i915/td
td rowspan=2 valign=top Generic/td
td valign=top Broadcast RGB/td
td valign=top ENUM/td
@@ -2687,6 +2687,14 @@ void intel_crt_init(struct drm_device *dev)
td valign=top TBD/td
/tr
tr
+ td rowspan=1 valign=top CRTC/td
+ td valign=top “background_color”/td
+ td valign=top Range/td
+ td valign=top Min=0, Max=0xFF/td
+ td valign=top CRTC/td
+ td valign=top Background color in 16bpc BGR (B-MSB, R-LSB)/td
+ /tr
+ tr
td rowspan=17 valign=top SDVO-TV/td
td valign=top “mode”/td
td valign=top ENUM/td
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-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 1/2] drm/i915: Allocate min dbuf blocks per bspec
Properly allocate min blocks per hw requirements.
Signed-off-by: Chandra Konduru chandra.kond...@intel.com
---
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] [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 ramalinga...@intel.com
---
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] [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 ramalinga...@intel.com
---
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, No active crtc found\n);
-
- return 0;
-}
-
struct
[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 ramalinga...@intel.com
---
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 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 ramalinga...@intel.com
---
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 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 ramalinga...@intel.com
---
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 drm/drm_crtc.h
#include drm/drm_mipi_dsi.h
#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 ramalinga...@intel.com
+ */
+
+#include drm/i915_drm.h
+#include linux/delay.h
+
+#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,
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 links 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 refentries from the DocBook XML to generate a database. Then it looks for function,structnames and paramdef 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 danilo.ce...@collabora.co.uk Cc: Randy Dunlap rdun...@infradead.org Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: linux-...@vger.kernel.org Cc: intel-gfx intel-gfx@lists.freedesktop.org Cc: dri-devel dri-de...@lists.freedesktop.org --- 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 'a HREF=$(patsubst %.html,%,$(notdir $@))/index.html \ $(patsubst %.html,%,$(notdir $@))/ap' $@ +%.aux.xml: %.xml +@rm -rf $@ +(cat $ | egrep ^refentry id | egrep -o \.*\ | cut -f 2 -d \ $.db) +$(KERNELDOCXMLREF) -db $.db $ $@ -%.html: %.xml +%.html: %.aux.xml @(which xmlto /dev/null 21) || \ (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
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 david.s.gor...@intel.com
---
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-flight; all unpinned and unmapped either during retirement
of the last-active-request in that context or lazily some time later.
I expect Chris has already implemented some of these ideas :)
.Dave.
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 ramalinga...@intel.com
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) {
- drm_modeset_lock(intel_crtc-base.mutex, NULL);
-
- if (intel_crtc-base.state-active) {
- active_crtc_cnt++;
-
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 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
[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 daniel.vet...@ffwll.ch
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk (v2)
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
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:
+ * |[!-- language=C --
+ *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 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 minu.mat...@intel.com 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 abdiel.janul...@linux.intel.com --- 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 | (ppgtt8)); + intel_logical_ring_emit(ringbuf, MI_BATCH_BUFFER_START_GEN8 | + (ppgtt8) | + (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 arun.siluv...@linux.intel.com regards Arun ___ 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 chandra.kond...@intel.com
---
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 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 1/2] drm/i915: Allocate min dbuf blocks per bspec
Properly allocate min blocks per hw requirements.
Signed-off-by: Chandra Konduru chandra.kond...@intel.com
---
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 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 chandra.kond...@intel.com
---
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] [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] [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 ramalinga...@intel.com
---
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 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 ramalinga...@intel.com
---
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. [Max = 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-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 ramalinga...@intel.com
---
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) {
+
Re: [Intel-gfx] [PATCH v3] drm/i915/lrc: Update PDPx registers with lri commands
Michel Thierry michel.thie...@intel.com 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 david.s.gor...@intel.com
Cc: Mika Kuoppala mika.kuopp...@intel.com
Signed-off-by: Michel Thierry michel.thie...@intel.com
Reviewed-by: Mika Kuoppala mika.kuopp...@intel.com
---
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
[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 links 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 refentries from the DocBook XML to generate a database. Then it looks for function,structnames and paramdef 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 danilo.ce...@collabora.co.uk Cc: Randy Dunlap rdun...@infradead.org Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Jonathan Corbet cor...@lwn.net Cc: Herbert Xu herb...@gondor.apana.org.au Cc: Stephan Mueller smuel...@chronox.de Cc: Michal Marek mma...@suse.cz Cc: linux-ker...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: intel-gfx intel-gfx@lists.freedesktop.org Cc: dri-devel dri-de...@lists.freedesktop.org --- 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 'a HREF=$(patsubst %.html,%,$(notdir $@))/index.html \ $(patsubst %.html,%,$(notdir $@))/ap' $@ +%.aux.xml: %.xml + @rm -rf $@ + (cat $ | egrep ^refentry id | egrep -o \.*\ | cut -f 2 -d \ $.db) + $(KERNELDOCXMLREF) -db $.db $ $@ -%.html:%.xml +%.html:%.aux.xml @(which xmlto /dev/null 21) || \ (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.
[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 ramalinga...@intel.com
---
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 (17)
#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(0xfff16)
+
/* 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,
[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 ramalinga...@intel.com
---
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 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 ramalinga...@intel.com --- 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 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 ramalinga...@intel.com
---
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 drm/i915_drm.h
#include linux/delay.h
+#include linux/list.h
#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 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 ramalinga...@intel.com
---
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 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 ramalinga...@intel.com
---
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 drm/drm_atomic.h
#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 ramalinga...@intel.com
+ * Durgadoss R durgados...@intel.com
+ */
+
+#include linux/delay.h
+#include drm/i915_drm.h
+
+#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;
[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 ramalinga...@intel.com
---
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 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 ramalinga...@intel.com
---
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 the dsi func ptr */
--
1.7.9.5
[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 ramalinga...@intel.com
---
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 ramalinga...@intel.com
---
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(struct intel_crtc *crtc,
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 michel.thie...@intel.com
---
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 (10)
#define EXEC_OBJECT_NEEDS_GTT(11)
#define EXEC_OBJECT_WRITE(12)
-#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE1)
+#define EXEC_OBJECT_SUPPORTS_48BADDRESS (13)
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] 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.__dict__:
for value in bug.__dict__[field]:
Re: [Intel-gfx] [PATCH] drm/vblank: WARN_ON nested use of drm_vblank_on/off
On 22 June 2015 at 14:02, Daniel Vetter daniel.vet...@ffwll.ch 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
[c021b12c] (unwind_backtrace) from [c0215388] (show_stack+0x20/0x24)
[c0215388] (show_stack) from [c0a9637c] (dump_stack+0x8c/0x9c)
[c0a9637c] (dump_stack) from [c0256b58] (warn_slowpath_common+0x94/0xc4)
[c0256b58] (warn_slowpath_common) from [c0256c44]
(warn_slowpath_null+0x2c/0x34)
[c0256c44] (warn_slowpath_null) from [c0686d38] (drm_vblank_on+0x10c/0x130)
[c0686d38] (drm_vblank_on) from [c0686d84] (drm_crtc_vblank_on+0x28/0x2c)
[c0686d84] (drm_crtc_vblank_on) from [c06cd518]
(tegra_crtc_commit+0x18/0x1c)
[c06cd518] (tegra_crtc_commit) from [c067b014]
(drm_atomic_helper_commit_modeset_enables+0xa0/0x198)
[c067b014] (drm_atomic_helper_commit_modeset_enables) from
[c06cb068] (tegra_atomic_complete.isra.1+0x38/0x5c)
[c06cb068] (tegra_atomic_complete.isra.1) from [c06cb0f4]
(tegra_atomic_commit+0x68/0x98)
[c06cb0f4] (tegra_atomic_commit) from [c06a1690]
(drm_atomic_commit+0x54/0x74)
[c06a1690] (drm_atomic_commit) from [c067b6ec]
(drm_atomic_helper_set_config+0x1b4/0x414)
[c067b6ec] (drm_atomic_helper_set_config) from [c068f43c]
(drm_mode_set_config_internal+0x68/0xe4)
[c068f43c] (drm_mode_set_config_internal) from [c067d34c]
(restore_fbdev_mode+0xe8/0x108)
[c067d34c] (restore_fbdev_mode) from [c067f390]
(drm_fb_helper_restore_fbdev_mode_unlocked+0x2c/0x68)
[c067f390] (drm_fb_helper_restore_fbdev_mode_unlocked) from
[c067f3f4] (drm_fb_helper_set_par+0x28/0x44)
[c067f3f4] (drm_fb_helper_set_par) from [c067f328]
(drm_fb_helper_hotplug_event+0xcc/0x108)
[c067f328] (drm_fb_helper_hotplug_event) from [c06cce98]
(tegra_fb_output_poll_changed+0x28/0x2c)
[c06cce98] (tegra_fb_output_poll_changed) from [c0674228]
(drm_kms_helper_hotplug_event+0x34/0x38)
[c0674228] (drm_kms_helper_hotplug_event) from [c06743dc]
(output_poll_execute+0x158/0x198)
[c06743dc] (output_poll_execute) from [c026d830]
(process_one_work+0x154/0x48c)
[c026d830] (process_one_work) from [c026dbbc] (worker_thread+0x54/0x568)
[c026dbbc] (worker_thread) from [c02739ec] (kthread+0xec/0x104)
[c02739ec] (kthread) from [c0211228] (ret_from_fork+0x14/0x2c)
Regards,
Tomeu
Cc: Yogesh Mohan Marimuthu yogesh.mohan.marimu...@intel.com
Cc: Gaurav K Singh gaurav.k.si...@intel.com
Cc: Michel Dänzer michel.daen...@amd.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
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] [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 ramalinga...@intel.com --- 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 drm/i915_drm.h #include linux/delay.h +#include linux/list.h #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] 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
[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 ch...@chris-wilson.co.uk Reported-by: Paulo Zanoni paulo.r.zan...@intel.com Cc: Paulo Zanoni paulo.r.zan...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@intel.com --- 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] [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 ramalinga...@intel.com --- 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 drm/i915_drm.h #include linux/delay.h +#include linux/list.h #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 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 damien.lesp...@intel.com:
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 damien.lesp...@intel.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
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] [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 ch...@chris-wilson.co.uk Reported-by: Paulo Zanoni paulo.r.zan...@intel.com Cc: Paulo Zanoni paulo.r.zan...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@intel.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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 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 chandra.kond...@intel.com
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] [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 paulo.r.zan...@intel.com Suggested-by: Paulo Zanoni paulo.r.zan...@intel.com Signed-off-by: Damien Lespiau damien.lesp...@intel.com 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 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ä ville.syrj...@linux.intel.com
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ä ville.syrj...@linux.intel.com
---
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
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 john.c.harri...@intel.com 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] [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 ramalinga...@intel.com
---
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 drm/i915_drm.h
#include linux/delay.h
+#include linux/list.h
#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] [PATCH 12/13 v2] drm/i915/skl: Replace the HDMI DPLL divider computation algorithm
2015-06-25 12:15 GMT-03:00 Damien Lespiau damien.lesp...@intel.com:
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 damien.lesp...@intel.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
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;
+ *p2 = 5;
+ } else if (p == 21) {
+ *p0 = 7;
+
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] 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 13/13 v2] drm/i915/skl: Prefer even dividers for SKL DPLLs
2015-06-25 12:19 GMT-03:00 Damien Lespiau damien.lesp...@intel.com:
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 damien.lesp...@intel.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
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 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 ramalinga...@intel.com --- 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 ramalinga...@intel.com
---
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 seamlesstransparent 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] [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/intel_drrs.h| 38 ++ drivers/gpu/drm/i915/intel_drv.h | 45 +-
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 john.c.harri...@intel.com 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 random variation from one run to the next of the order of 10us - over 100us. And that is with a straight nightly build. I have never seen variance of that magnitude. That strongly suggests something is
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 paulo.r.zan...@intel.com 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] 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 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/skl: Skip remaining dividers when deviation is 0
2015-06-25 14:08 GMT-03:00 Damien Lespiau damien.lesp...@intel.com:
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 paulo.r.zan...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
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 paulo.r.zan...@intel.com
}
}
+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
[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 paulo.r.zan...@intel.com Suggested-by: Paulo Zanoni paulo.r.zan...@intel.com Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- 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
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 john.c.harri...@intel.com
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 dan...@ffwll.ch
Signed-off-by: John Harrison john.c.harri...@intel.com
---
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 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 b...@bwidawsk.net 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 ch...@chris-wilson.co.uk 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
[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 paulo.r.zan...@intel.com
Cc: Jani Nikula jani.nik...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Tested-by: Kenneth Graunke kenn...@whitecape.org
---
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 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ä ville.syrj...@linux.intel.com
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ä ville.syrj...@linux.intel.com
---
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
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ä ville.syrj...@linux.intel.com
Allow tweaking the VLV/CHV memory latencies thorugh sysfs, like we do
for ILK+.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
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 clinton.a.tay...@intel.com
Tested-by: Clint Taylor clinton.a.tay...@intel.com
___
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ä ville.syrj...@linux.intel.com
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ä ville.syrj...@linux.intel.com
---
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
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ä ville.syrj...@linux.intel.com
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ä ville.syrj...@linux.intel.com
---
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] +
-
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ä ville.syrj...@linux.intel.com
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ä ville.syrj...@linux.intel.com
---
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 clinton.a.tay...@intel.com
Tested-by: Clint Taylor clinton.a.tay...@intel.com
___
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
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 dan...@ffwll.ch 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 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] [git pull] drm tree for 4.2
On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie airl...@linux.ie 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
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ä ville.syrj...@linux.intel.com 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ä ville.syrj...@linux.intel.com --- 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 clinton.a.tay...@intel.com Tested-by: Clint Taylor clinton.a.tay...@intel.com ___ 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
2015-06-26 14:35 GMT-03:00 Chris Wilson ch...@chris-wilson.co.uk: 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 ch...@chris-wilson.co.uk Reported-by: Paulo Zanoni paulo.r.zan...@intel.com Cc: Paulo Zanoni paulo.r.zan...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@intel.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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 paulo.r.zan...@intel.com -- 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ä ville.syrj...@linux.intel.com
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ä ville.syrj...@linux.intel.com
---
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;
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ä ville.syrj...@linux.intel.com
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ä ville.syrj...@linux.intel.com
---
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
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ä ville.syrj...@linux.intel.com
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ä ville.syrj...@linux.intel.com
---
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] =
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ä ville.syrj...@linux.intel.com
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ä ville.syrj...@linux.intel.com
---
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 clinton.a.tay...@intel.com
Tested-by: Clint Taylor clinton.a.tay...@intel.com
___
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ä ville.syrj...@linux.intel.com
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ä ville.syrj...@linux.intel.com
---
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 clinton.a.tay...@intel.com
Tested-by: Clint Taylor clinton.a.tay...@intel.com
___
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 10:15:08AM +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. Cc: Chris Wilson ch...@chris-wilson.co.uk Reported-by: Paulo Zanoni paulo.r.zan...@intel.com Cc: Paulo Zanoni paulo.r.zan...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@intel.com --- drivers/gpu/drm/i915/i915_gem.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index f79ce9f22312..80b696a8277c 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1614,6 +1614,9 @@ 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, ORIGIN_CPU); Just the catch of doing write_domain == I915_GEM_DOMAIN_GTT ? ORIGIN_GTT : ORIGIN_CPU to keep Paulo happy. -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 i-g-t 2/5] tests/igt_stats: Call igt_stats_fini() to not leak the array
On Fri, Jun 26, 2015 at 12:26:56AM +0100, Damien Lespiau wrote: Sure, it'll be freed at exit(), but might as well be a bit pedantic. s/pedantic/pedagological/ Tests also serve as examples and will undoubtably be copy-pasted at some point. -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] [alsa-devel] [PATCH 3/4] snd: add support for displayport multi-stream to hda codec.
On Thu, 2015-06-25 at 10:44 +0100, Liam Girdwood wrote: On Wed, 2015-06-24 at 20:47 +, Kaskinen, Tanu wrote: On Wed, 2015-06-24 at 14:06 +0100, Liam Girdwood wrote: On Wed, 2015-06-24 at 12:41 +, Kaskinen, Tanu wrote: On Tue, 2015-06-23 at 10:06 +0200, Takashi Iwai wrote: At Tue, 23 Jun 2015 07:51:22 +, Kaskinen, Tanu 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: snip Tanu, what's your take on the effort for dynamically created PCMs support for pulseaudio ? It's a significant amount of work, but I think PulseAudio should be improved to support this in any case, if other approaches make life miserable for driver developers. What would be the interface for getting notifications about new and removed PCM devices? udev? In general, yes. 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. Maybe we should introduce a new device class for dynamic HDMI/DP device, something like dhdmi:x,y, to make things straightforward. (Just a concept -- I'm not good at naming.) Alternatively, we may introduce a new argument to hdmi PCM to access like hdmi:CARD=x,SYSDEV=y. What happens if PulseAudio tries to open dhdmi:x,y or hdmi:CARD=x,SYSDEV=y, when y points to a non-HDMI device? If it fails, then PulseAudio can replace its current hdmi:x,[0-7] devices with hdmi:CARD=X,SYSDEV=[0-13] and blindly try every hw PCM device. But if opening a non-HDMI device through hdmi:CARD=x,SYSDEV=y succeeds, then how is PulseAudio supposed to know which hw PCM devices are HDMI devices? It's a good question. I think this is the core part of the missing pieces. What I have in my mind is to extend SNDRV_PCM_CLASS_* definition for dedicated to HDMI/DP, e.g. SNDRV_PCM_CLASS_HDMI. The difference between DP and HDMI can be specified in subclass optionally. Sounds good. Knowing the difference between HDMI, DisplayPort and Thunderbolt would be very nice too. It would enable better labelling in UIs. I have one minor concern, though: what if a PCM device isn't statically assigned to one output connector? Is it possible that some DSP is able to dynamically change the PCM routing between different outputs? In those cases the PCM class would be useless information (unless there are notifications when the class changes). I don't have any better ideas, though. This is possible atm, we can route from one PCM to multiple outputs depending on DSP and codec mixer settings. The outputs can even be on different physical interfaces. Hmm, my question was a bit silly. It has been possible forever to switch between e.g. headphones and speakers using just the mixer. And in this case that we're discussing, the question was irrelevant anyway, because surely the dynamically created PCM would be dedicated to the plugged-in HDMI port, otherwise the dynamic creation wouldn't really make sense. So, setting the PCM class should work at least in this case. If there are cases where the DSP may route the same PCM to either HDMI or non-HDMI output depending on mixer settings, then that's when the PCM class would be less useful. Yeah, we may need to provide other hints here. DSPs make it possible now to route one PCM to multiple HW endpoints. Getting information to userspace about the hw endpoints and how each hw PCM and the endpoints are related would probably also solve this dynamic HDMI PCM issue, but it would probably be much more complicated than just adding a couple of bits to the PCM info. I suggest that we leave the dynamically routed PCM problem alone for now, and only focus on the dynamic HDMI PCM issue, even if that means that we devise a solution for the HDMI PCM issue that will become obsolete later. In any case, PulseAudio needs to figure out whether it should ignore the PCM class and use hdmi:x,y or whether it should check the PCM class and use hdmi:CARD=x,SYSDEV=y. How should that be done? Is
[Intel-gfx] [v3 7/7] drm/i915: Backlight control using CRC PMIC based PWM driver
Use the CRC PWM device in intel_panel.c and add new MIPI backlight
specififc callbacks
v2: Modify to use pwm_config callback
v3: Addressed Jani's comments
- Renamed all function as pwm_* instead of vlv_*
- Call intel_panel_actually_set_backlight in enable function
- Return -ENODEV in case pwm_get fails
- in case pwm_config error return error cdoe from pwm_config
- Cleanup pwm in intel_panel_destroy_backlight
v4: Removed unused #defines and initialized backlight with INVALID_PIPE (Ville)
CC: Samuel Ortiz sa...@linux.intel.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Thierry Reding thierry.red...@gmail.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Tested-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/intel_drv.h | 4 ++
drivers/gpu/drm/i915/intel_dsi.c | 5 ++
drivers/gpu/drm/i915/intel_panel.c | 94 --
3 files changed, 98 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2afb31a..561c17f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -182,6 +182,10 @@ struct intel_panel {
bool enabled;
bool combination_mode; /* gen 2/4 only */
bool active_low_pwm;
+
+ /* PWM chip */
+ struct pwm_device *pwm;
+
struct backlight_device *device;
} backlight;
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index c4db74a..892b936 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -402,6 +402,8 @@ static void intel_dsi_enable(struct intel_encoder *encoder)
intel_dsi_port_enable(encoder);
}
+
+ intel_panel_enable_backlight(intel_dsi-attached_connector);
}
static void intel_dsi_pre_enable(struct intel_encoder *encoder)
@@ -466,6 +468,8 @@ static void intel_dsi_pre_disable(struct intel_encoder
*encoder)
DRM_DEBUG_KMS(\n);
+ intel_panel_disable_backlight(intel_dsi-attached_connector);
+
if (is_vid_mode(intel_dsi)) {
/* Send Shutdown command to the panel in LP mode */
for_each_dsi_port(port, intel_dsi-ports)
@@ -1132,6 +1136,7 @@ void intel_dsi_init(struct drm_device *dev)
}
intel_panel_init(intel_connector-panel, fixed_mode, NULL);
+ intel_panel_setup_backlight(connector, INVALID_PIPE);
return;
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 7d83527..952fadc 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -32,8 +32,11 @@
#include linux/kernel.h
#include linux/moduleparam.h
+#include linux/pwm.h
#include intel_drv.h
+#define CRC_PMIC_PWM_PERIOD_NS 21333
+
void
intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
@@ -544,6 +547,15 @@ static u32 bxt_get_backlight(struct intel_connector
*connector)
return I915_READ(BXT_BLC_PWM_DUTY1);
}
+static u32 pwm_get_backlight(struct intel_connector *connector)
+{
+ struct intel_panel *panel = connector-panel;
+ int duty_ns;
+
+ duty_ns = pwm_get_duty_cycle(panel-backlight.pwm);
+ return DIV_ROUND_UP(duty_ns * 100, CRC_PMIC_PWM_PERIOD_NS);
+}
+
static u32 intel_panel_get_backlight(struct intel_connector *connector)
{
struct drm_device *dev = connector-base.dev;
@@ -632,6 +644,14 @@ static void bxt_set_backlight(struct intel_connector
*connector, u32 level)
I915_WRITE(BXT_BLC_PWM_DUTY1, level);
}
+static void pwm_set_backlight(struct intel_connector *connector, u32 level)
+{
+ struct intel_panel *panel = connector-panel;
+ int duty_ns = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
+
+ pwm_config(panel-backlight.pwm, duty_ns, CRC_PMIC_PWM_PERIOD_NS);
+}
+
static void
intel_panel_actually_set_backlight(struct intel_connector *connector, u32
level)
{
@@ -769,6 +789,16 @@ static void bxt_disable_backlight(struct intel_connector
*connector)
I915_WRITE(BXT_BLC_PWM_CTL1, tmp ~BXT_BLC_PWM_ENABLE);
}
+static void pwm_disable_backlight(struct intel_connector *connector)
+{
+ struct intel_panel *panel = connector-panel;
+
+ /* Disable the backlight */
+ pwm_config(panel-backlight.pwm, 0, CRC_PMIC_PWM_PERIOD_NS);
+ usleep_range(2000, 3000);
+ pwm_disable(panel-backlight.pwm);
+}
+
void intel_panel_disable_backlight(struct intel_connector *connector)
{
struct drm_device *dev = connector-base.dev;
@@ -1002,6 +1032,14 @@ static void bxt_enable_backlight(struct intel_connector
*connector)
I915_WRITE(BXT_BLC_PWM_CTL1, pwm_ctl | BXT_BLC_PWM_ENABLE);
}
+static void pwm_enable_backlight(struct
[Intel-gfx] [v3 4/7] mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM
On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup
entry for the same to be used by the consumer (Intel GFX)
CC: Samuel Ortiz sa...@linux.intel.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Thierry Reding thierry.red...@gmail.com
Acked-by: Lee Jones lee.jo...@linaro.org
Tested-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
v2: Remove the lookup table on driver unload (Thierry)
v3: Correct the subject line (Lee jones)
drivers/mfd/intel_soc_pmic_core.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/mfd/intel_soc_pmic_core.c
b/drivers/mfd/intel_soc_pmic_core.c
index f3d918e..a00ddd9 100644
--- a/drivers/mfd/intel_soc_pmic_core.c
+++ b/drivers/mfd/intel_soc_pmic_core.c
@@ -25,6 +25,7 @@
#include linux/regmap.h
#include linux/mfd/intel_soc_pmic.h
#include linux/gpio/machine.h
+#include linux/pwm.h
#include intel_soc_pmic_core.h
/* Lookup table for the Panel Enable/Disable line as GPIO signals */
@@ -37,6 +38,11 @@ static struct gpiod_lookup_table panel_gpio_table = {
},
};
+/* PWM consumed by the Intel GFX */
+static struct pwm_lookup crc_pwm_lookup[] = {
+ PWM_LOOKUP(crystal_cove_pwm, 0, :00:02.0, pwm_backlight, 0,
PWM_POLARITY_NORMAL),
+};
+
static int intel_soc_pmic_find_gpio_irq(struct device *dev)
{
struct gpio_desc *desc;
@@ -99,6 +105,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
/* Add lookup table binding for Panel Control to the GPIO Chip */
gpiod_add_lookup_table(panel_gpio_table);
+ /* Add lookup table for crc-pwm */
+ pwm_add_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
+
ret = mfd_add_devices(dev, -1, config-cell_dev,
config-n_cell_devs, NULL, 0,
regmap_irq_get_domain(pmic-irq_chip_data));
@@ -121,6 +130,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client *i2c)
/* Remove lookup table for Panel Control from the GPIO Chip */
gpiod_remove_lookup_table(panel_gpio_table);
+ /* remove crc-pwm lookup table */
+ pwm_remove_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
+
mfd_remove_devices(i2c-dev);
return 0;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/18] drm/i915/gtt: Move scratch_pd and scratch_pt into vm area
On Thu, Jun 25, 2015 at 06:35:17PM +0300, Mika Kuoppala wrote:
Scratch page is part of struct i915_address_space. Move other
scratch entities into the same struct. This is a preparatory patch
for having only one instance of each scratch_pt/pd.
v2: make commit msg more readable
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
Reviewed-by: Michel Thierry michel.thie...@intel.com (v1)
I bikesheded the summary from vm area to vm struct. Since vm area is the
vma we already have to track obj bindings into a vm ;-)
-Daniel
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 51
+
drivers/gpu/drm/i915/i915_gem_gtt.h | 7 +++--
2 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 03f86ce..9b5e813 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -612,12 +612,9 @@ static void gen8_ppgtt_insert_entries(struct
i915_address_space *vm,
static void gen8_initialize_pd(struct i915_address_space *vm,
struct i915_page_directory *pd)
{
- struct i915_hw_ppgtt *ppgtt =
- container_of(vm, struct i915_hw_ppgtt, base);
gen8_pde_t scratch_pde;
- scratch_pde = gen8_pde_encode(px_dma(ppgtt-scratch_pt),
- I915_CACHE_LLC);
+ scratch_pde = gen8_pde_encode(px_dma(vm-scratch_pt), I915_CACHE_LLC);
fill_px(vm-dev, pd, scratch_pde);
}
@@ -652,8 +649,8 @@ static void gen8_ppgtt_cleanup(struct i915_address_space
*vm)
free_pd(ppgtt-base.dev, ppgtt-pdp.page_directory[i]);
}
- free_pd(ppgtt-base.dev, ppgtt-scratch_pd);
- free_pt(ppgtt-base.dev, ppgtt-scratch_pt);
+ free_pd(vm-dev, vm-scratch_pd);
+ free_pt(vm-dev, vm-scratch_pt);
}
/**
@@ -689,7 +686,7 @@ static int gen8_ppgtt_alloc_pagetabs(struct i915_hw_ppgtt
*ppgtt,
/* Don't reallocate page tables */
if (pt) {
/* Scratch is never allocated this way */
- WARN_ON(pt == ppgtt-scratch_pt);
+ WARN_ON(pt == ppgtt-base.scratch_pt);
continue;
}
@@ -940,16 +937,16 @@ err_out:
*/
static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
{
- ppgtt-scratch_pt = alloc_pt(ppgtt-base.dev);
- if (IS_ERR(ppgtt-scratch_pt))
- return PTR_ERR(ppgtt-scratch_pt);
+ ppgtt-base.scratch_pt = alloc_pt(ppgtt-base.dev);
+ if (IS_ERR(ppgtt-base.scratch_pt))
+ return PTR_ERR(ppgtt-base.scratch_pt);
- ppgtt-scratch_pd = alloc_pd(ppgtt-base.dev);
- if (IS_ERR(ppgtt-scratch_pd))
- return PTR_ERR(ppgtt-scratch_pd);
+ 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-scratch_pt);
- gen8_initialize_pd(ppgtt-base, ppgtt-scratch_pd);
+ gen8_initialize_pt(ppgtt-base, ppgtt-base.scratch_pt);
+ gen8_initialize_pd(ppgtt-base, ppgtt-base.scratch_pd);
ppgtt-base.start = 0;
ppgtt-base.total = 1ULL 32;
@@ -981,7 +978,8 @@ static void gen6_dump_ppgtt(struct i915_hw_ppgtt *ppgtt,
struct seq_file *m)
uint32_t pte, pde, temp;
uint32_t start = ppgtt-base.start, length = ppgtt-base.total;
- scratch_pte = vm-pte_encode(px_dma(vm-scratch_page), I915_CACHE_LLC,
true, 0);
+ scratch_pte = vm-pte_encode(px_dma(vm-scratch_page),
+ I915_CACHE_LLC, true, 0);
gen6_for_each_pde(unused, ppgtt-pd, start, length, temp, pde) {
u32 expected;
@@ -1314,7 +1312,7 @@ static int gen6_alloc_va_range(struct
i915_address_space *vm,
* tables.
*/
gen6_for_each_pde(pt, ppgtt-pd, start, length, temp, pde) {
- if (pt != ppgtt-scratch_pt) {
+ if (pt != vm-scratch_pt) {
WARN_ON(bitmap_empty(pt-used_ptes, GEN6_PTES));
continue;
}
@@ -1369,7 +1367,7 @@ unwind_out:
for_each_set_bit(pde, new_page_tables, I915_PDES) {
struct i915_page_table *pt = ppgtt-pd.page_table[pde];
- ppgtt-pd.page_table[pde] = ppgtt-scratch_pt;
+ ppgtt-pd.page_table[pde] = vm-scratch_pt;
free_pt(vm-dev, pt);
}
@@ -1384,15 +1382,14 @@ static void gen6_ppgtt_cleanup(struct
i915_address_space *vm)
struct i915_page_table *pt;
uint32_t pde;
-
drm_mm_remove_node(ppgtt-node);
gen6_for_all_pdes(pt, ppgtt, pde) {
- if (pt != ppgtt-scratch_pt)
+ if (pt != vm-scratch_pt)
free_pt(ppgtt-base.dev, pt);
}
- free_pt(ppgtt-base.dev, ppgtt-scratch_pt);
+ free_pt(vm-dev, vm-scratch_pt);
[Intel-gfx] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control
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 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
[Intel-gfx] [v3 3/7] mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC
Needed for PWM control suuported by the PMIC
CC: Samuel Ortiz sa...@linux.intel.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Thierry Reding thierry.red...@gmail.com
Acked-by: Lee Jones lee.jo...@linaro.org
Tested-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
v2: Correct the subject line (Lee jones)
drivers/mfd/intel_soc_pmic_crc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/intel_soc_pmic_crc.c b/drivers/mfd/intel_soc_pmic_crc.c
index 7436075..4a74948 100644
--- a/drivers/mfd/intel_soc_pmic_crc.c
+++ b/drivers/mfd/intel_soc_pmic_crc.c
@@ -109,6 +109,9 @@ static struct mfd_cell crystal_cove_dev[] = {
{
.name = crystal_cove_pmic,
},
+ {
+ .name = crystal_cove_pwm,
+ },
};
static const struct regmap_config crystal_cove_regmap_config = {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v3 1/7] gpiolib: Add support for removing registered consumer lookup table
In case we unload and load a driver module again that is registering a
lookup table, without this it will result in multiple entries. Provide
an option to remove the lookup table on driver unload
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Thierry Reding thierry.red...@gmail.com
Reviewed-by: Alexandre Courbot acour...@nvidia.com
Reviewed-by: Linus Walleij linus.wall...@linaro.org
Tested-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
v2: Ccing maintainers
v3: Correct the subject line (Lee jones)
drivers/gpio/gpiolib.c | 13 +
include/linux/gpio/machine.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 957ede5..9d3ea4e 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1675,6 +1675,19 @@ void gpiod_add_lookup_table(struct gpiod_lookup_table
*table)
mutex_unlock(gpio_lookup_lock);
}
+/**
+ * gpiod_remove_lookup_table() - unregister GPIO device consumers
+ * @table: table of consumers to unregister
+ */
+void gpiod_remove_lookup_table(struct gpiod_lookup_table *table)
+{
+ mutex_lock(gpio_lookup_lock);
+
+ list_del(table-list);
+
+ mutex_unlock(gpio_lookup_lock);
+}
+
static struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
unsigned int idx,
enum gpio_lookup_flags *flags)
diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h
index e270614..c0d712d 100644
--- a/include/linux/gpio/machine.h
+++ b/include/linux/gpio/machine.h
@@ -57,5 +57,6 @@ struct gpiod_lookup_table {
}
void gpiod_add_lookup_table(struct gpiod_lookup_table *table);
+void gpiod_remove_lookup_table(struct gpiod_lookup_table *table);
#endif /* __LINUX_GPIO_MACHINE_H */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v3 2/7] mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO signal
On some Intel SoC platforms, the panel enable/disable signals are
controlled by CRC PMIC. Add those control as a new GPIO in a lookup
table for gpio-crystalcove chip during CRC driver load
CC: Samuel Ortiz sa...@linux.intel.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Thierry Reding thierry.red...@gmail.com
Acked-by: Lee Jones lee.jo...@linaro.org
Acked-by: Linus Walleij linus.wall...@linaro.org
Tested-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
v2: Make the lookup table static (Thierry)
Remove the lookup table during driver remove (Thierry)
v3: Correct the subject line (Lee jones)
drivers/mfd/intel_soc_pmic_core.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/mfd/intel_soc_pmic_core.c
b/drivers/mfd/intel_soc_pmic_core.c
index 7b50b6b..f3d918e 100644
--- a/drivers/mfd/intel_soc_pmic_core.c
+++ b/drivers/mfd/intel_soc_pmic_core.c
@@ -24,8 +24,19 @@
#include linux/acpi.h
#include linux/regmap.h
#include linux/mfd/intel_soc_pmic.h
+#include linux/gpio/machine.h
#include intel_soc_pmic_core.h
+/* Lookup table for the Panel Enable/Disable line as GPIO signals */
+static struct gpiod_lookup_table panel_gpio_table = {
+ /* Intel GFX is consumer */
+ .dev_id = :00:02.0,
+ .table = {
+ /* Panel EN/DISABLE */
+ GPIO_LOOKUP(gpio_crystalcove, 94, panel, GPIO_ACTIVE_HIGH),
+ },
+};
+
static int intel_soc_pmic_find_gpio_irq(struct device *dev)
{
struct gpio_desc *desc;
@@ -85,6 +96,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
if (ret)
dev_warn(dev, Can't enable IRQ as wake source: %d\n, ret);
+ /* Add lookup table binding for Panel Control to the GPIO Chip */
+ gpiod_add_lookup_table(panel_gpio_table);
+
ret = mfd_add_devices(dev, -1, config-cell_dev,
config-n_cell_devs, NULL, 0,
regmap_irq_get_domain(pmic-irq_chip_data));
@@ -104,6 +118,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client *i2c)
regmap_del_irq_chip(pmic-irq, pmic-irq_chip_data);
+ /* Remove lookup table for Panel Control from the GPIO Chip */
+ gpiod_remove_lookup_table(panel_gpio_table);
+
mfd_remove_devices(i2c-dev);
return 0;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
