Re: [Intel-gfx] [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer
On 2017.03.23 14:43:44 +0100, Frans Klaver wrote:
> On Thu, Mar 23, 2017 at 1:22 PM, Colin King wrote:
> > From: Colin Ian King
> >
> > info is being checked to see if it is a null pointer, however, vpgu is
> > dereferencing info before this check, leading to a potential null
> > pointer dereference. If info is null, then the error message being
> > printed by macro gvt_vgpu_err and this requires vpgu to exist. We can
> > use a null vpgu as the macro has a sanity check to see if vpgu is null,
> > so this is OK.
> >
> > Detected with CoverityScan, CID#1420672 ("Dereference nefore null check")
>
> s,nefore,before,
>
>
> >
> > Fixes: 695fbc08d80f ("drm/i915/gvt: replace the gvt_err with gvt_vgpu_err")
> > Signed-off-by: Colin Ian King
> > ---
> > drivers/gpu/drm/i915/gvt/kvmgt.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> > b/drivers/gpu/drm/i915/gvt/kvmgt.c
> > index 1ea3eb270de8..f8619a772c44 100644
> > --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> > +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> > @@ -1339,9 +1339,9 @@ static int kvmgt_guest_init(struct mdev_device *mdev)
> >
> > static bool kvmgt_guest_exit(struct kvmgt_guest_info *info)
> > {
> > - struct intel_vgpu *vgpu = info->vgpu;
> > -
> > if (!info) {
> > + struct intel_vgpu *vgpu = NULL;
> > +
> > gvt_vgpu_err("kvmgt_guest_info invalid\n");
> > return false;
> > }
>
> Does this mean the original gvt_err() macro is no longer there?
>
> And apparently gvt_vgpu_err is a macro that depends on the specifics
> of its environment? Yikes.
>
The null check is redundant there, we can just remove that block and extra
vgpu variable.
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Make the decision to keep vblank irq enabled earlier
On 03/23/2017 02:26 PM, Ville Syrjälä wrote:
On Thu, Mar 23, 2017 at 07:51:06AM +, Chris Wilson wrote:
We want to provide the vblank irq shadow for pageflip events as well as
vblank queries. Such events are completed within the vblank interrupt
handler, and so the current check for disabling the irq will disable it
from with the same interrupt as the last pageflip event. If we move the
decision on whether to disable the irq (based on there no being no
remaining vblank events, i.e. vblank->refcount == 0) to before we signal
the events, we will only disable the irq on the interrupt after the last
event was signaled. In the normal course of events, this will keep the
vblank irq enabled for the entire flip sequence whereas before it would
flip-flop around every interrupt.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Michel Dänzer
Cc: Laurent Pinchart
Cc: Dave Airlie ,
Cc: Mario Kleiner
---
drivers/gpu/drm/drm_irq.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 5b77057e91ca..1d6bcee3708f 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1741,6 +1741,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
{
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
unsigned long irqflags;
+ bool disable_irq;
if (WARN_ON_ONCE(!dev->num_crtcs))
return false;
@@ -1768,16 +1769,19 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
spin_unlock(&dev->vblank_time_lock);
wake_up(&vblank->queue);
- drm_handle_vblank_events(dev, pipe);
/* With instant-off, we defer disabling the interrupt until after
-* we finish processing the following vblank. The disable has to
-* be last (after drm_handle_vblank_events) so that the timestamp
-* is always accurate.
+* we finish processing the following vblank after all events have
+* been signaled. The disable has to be last (after
+* drm_handle_vblank_events) so that the timestamp is always accurate.
We wouldn't actually do the disable as long there's a reference still
held, so the timestamp should be fine in that case. And if there aren't
any references the timestamp shouldn't matter... I think. But it's
probably more clear to keep to the order you propose here anyway.
Reviewed-by: Ville Syrjälä
Looks good to me. As a further optimization, i think we could move the
vblank_disable_fn() call outside/below the spin_unlock_irqrestore for
event_lock, as vblank_disable_fn() doesn't need any locks held at call
time, so slightly reduce event_lock hold time. Don't know if it is worth it.
In any case
Reviewed-by: Mario Kleiner
thanks,
-mario
Oh, and now that I think about this stuff again, I start to wonder why
I made the disable actually update the seq/ts. If the interrupt is
currently enabled the seq/ts should be reasonably uptodate already
when we do disable the interrupt. Perhaps I was only thinking about
drm_vblank_off() when I made that change, or I decided that I didn't
want two different disable codepaths. Anyways, just an idea that
we might be able to make the vblank irq disable a little cheaper.
*/
- if (dev->vblank_disable_immediate &&
- drm_vblank_offdelay > 0 &&
- !atomic_read(&vblank->refcount))
+ disable_irq = (dev->vblank_disable_immediate &&
+ drm_vblank_offdelay > 0 &&
+ !atomic_read(&vblank->refcount));
+
+ drm_handle_vblank_events(dev, pipe);
+
+ if (disable_irq)
vblank_disable_fn((unsigned long)vblank);
spin_unlock_irqrestore(&dev->event_lock, irqflags);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer
On 2017.03.23 16:11:00 +0200, Joonas Lahtinen wrote: > Dropping the irrelevant Cc's. > > On to, 2017-03-23 at 12:39 +, Chris Wilson wrote: > > On Thu, Mar 23, 2017 at 12:22:30PM +, Colin King wrote: > > > > > > From: Colin Ian King > > > > > > info is being checked to see if it is a null pointer, however, vpgu is > > > dereferencing info before this check, leading to a potential null > > > pointer dereference. If info is null, then the error message being > > > printed by macro gvt_vgpu_err and this requires vpgu to exist. We can > > > use a null vpgu as the macro has a sanity check to see if vpgu is null, > > > so this is OK. > > > > It is never NULL, it gets checked by its only caller. > > Took me a while to make any sense of the code as gvt_vgpu_err depends > on a vgpu variable being declared in the scope without taking it as a > parameter and that is a one big no-no: > > https://01.org/linuxgraphics/gfx-docs/drm/process/coding-style.html#macros-enums-and-rtl > Thanks for comment, Joonas. Current gvt dbg print is still a mess, we will try to clean it up. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915/scheduler: add gvt notification for guc submission
GVT request needs a manual mmio load/restore. Before GuC submit
a request, send notification to gvt for mmio loading. And after
the GuC finished this GVT request, notify gvt again for mmio
restore. This follows the usage when using execlists submission.
v2: use context_status_change instead of execlists_context_status_change
for better understanding (ZhengXiao)
v3: remove the comment as it is obvious and not friendly to
the caller (Kevin)
v4: fix indent issues (Joonas)
rename the context_status_change to intel_gvt_notify_context_status (Chris)
Cc: xiao.zh...@intel.com
Cc: kevin.t...@intel.com
Cc: joonas.lahti...@linux.intel.com
Cc: ch...@chris-wilson.co.uk
Signed-off-by: Chuanxiao Dong
---
drivers/gpu/drm/i915/i915_guc_submission.c | 4
drivers/gpu/drm/i915/intel_lrc.c | 27 ++-
drivers/gpu/drm/i915/intel_lrc.h | 14 ++
3 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 055467a..91a567d 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -520,6 +520,8 @@ static void __i915_guc_submit(struct drm_i915_gem_request
*rq)
unsigned long flags;
int b_ret;
+ intel_gvt_notify_context_status(rq, INTEL_CONTEXT_SCHEDULE_IN);
+
/* WA to flush out the pending GMADR writes to ring buffer. */
if (i915_vma_is_map_and_fenceable(rq->ring->vma))
POSTING_READ_FW(GUC_STATUS);
@@ -634,6 +636,8 @@ static void i915_guc_irq_handler(unsigned long data)
rq = port[0].request;
while (rq && i915_gem_request_completed(rq)) {
trace_i915_gem_request_out(rq);
+ intel_gvt_notify_context_status(rq,
+ INTEL_CONTEXT_SCHEDULE_OUT);
i915_gem_request_put(rq);
port[0].request = port[1].request;
port[1].request = NULL;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index eec1e71..8b0c937 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -295,21 +295,6 @@ uint64_t intel_lr_context_descriptor(struct
i915_gem_context *ctx,
return ctx->engine[engine->id].lrc_desc;
}
-static inline void
-execlists_context_status_change(struct drm_i915_gem_request *rq,
- unsigned long status)
-{
- /*
-* Only used when GVT-g is enabled now. When GVT-g is disabled,
-* The compiler should eliminate this function as dead-code.
-*/
- if (!IS_ENABLED(CONFIG_DRM_I915_GVT))
- return;
-
- atomic_notifier_call_chain(&rq->engine->context_status_notifier,
- status, rq);
-}
-
static void
execlists_update_context_pdps(struct i915_hw_ppgtt *ppgtt, u32 *reg_state)
{
@@ -350,16 +335,16 @@ static void execlists_submit_ports(struct intel_engine_cs
*engine)
GEM_BUG_ON(port[0].count > 1);
if (!port[0].count)
- execlists_context_status_change(port[0].request,
- INTEL_CONTEXT_SCHEDULE_IN);
+ intel_gvt_notify_context_status(port[0].request,
+ INTEL_CONTEXT_SCHEDULE_IN);
desc[0] = execlists_update_context(port[0].request);
GEM_DEBUG_EXEC(port[0].context_id = upper_32_bits(desc[0]));
port[0].count++;
if (port[1].request) {
GEM_BUG_ON(port[1].count);
- execlists_context_status_change(port[1].request,
- INTEL_CONTEXT_SCHEDULE_IN);
+ intel_gvt_notify_context_status(port[1].request,
+ INTEL_CONTEXT_SCHEDULE_IN);
desc[1] = execlists_update_context(port[1].request);
GEM_DEBUG_EXEC(port[1].context_id = upper_32_bits(desc[1]));
port[1].count = 1;
@@ -581,8 +566,8 @@ static void intel_lrc_irq_handler(unsigned long data)
if (--port[0].count == 0) {
GEM_BUG_ON(status & GEN8_CTX_STATUS_PREEMPTED);
GEM_BUG_ON(!i915_gem_request_completed(port[0].request));
- execlists_context_status_change(port[0].request,
-
INTEL_CONTEXT_SCHEDULE_OUT);
+ intel_gvt_notify_context_status(port[0].request,
+ INTEL_CONTEXT_SCHEDULE_OUT);
trace_i915_gem_request_out(port[0].request);
i915_gem_request_put(port[0].request);
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index e8015e7..3
[Intel-gfx] [PATCH v2] drm/i915: Add 'render basic' Gen8+ OA unit configs
Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic
render metrics on Broadwell, Cherryview, Skylake and Broxton. These are
auto generated from an XML description of metric sets, currently
maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scripts/i915-perf-kernelgen.py
$ make -C gputop-data -f Makefile.xml WHITELIST=RenderBasic
v2: add newlines to debug messages + fix comment (Matthew Auld)
Signed-off-by: Robert Bragg
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 8 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_oa_bdw.c| 380 ++
drivers/gpu/drm/i915/i915_oa_bdw.h| 38
drivers/gpu/drm/i915/i915_oa_bxt.c| 238 +
drivers/gpu/drm/i915/i915_oa_bxt.h| 38
drivers/gpu/drm/i915/i915_oa_chv.c| 225
drivers/gpu/drm/i915/i915_oa_chv.h| 38
drivers/gpu/drm/i915/i915_oa_sklgt2.c | 228
drivers/gpu/drm/i915/i915_oa_sklgt2.h | 38
drivers/gpu/drm/i915/i915_oa_sklgt3.c | 236 +
drivers/gpu/drm/i915/i915_oa_sklgt3.h | 38
drivers/gpu/drm/i915/i915_oa_sklgt4.c | 247 ++
drivers/gpu/drm/i915/i915_oa_sklgt4.h | 38
14 files changed, 1791 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2cf04504e494..41400a138a1e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -127,7 +127,13 @@ i915-y += i915_vgpu.o
# perf code
i915-y += i915_perf.o \
- i915_oa_hsw.o
+ i915_oa_hsw.o \
+ i915_oa_bdw.o \
+ i915_oa_chv.o \
+ i915_oa_sklgt2.o \
+ i915_oa_sklgt3.o \
+ i915_oa_sklgt4.o \
+ i915_oa_bxt.o
ifeq ($(CONFIG_DRM_I915_GVT),y)
i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a7986c0c29ad..c4156a8a5dc0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2486,6 +2486,8 @@ struct drm_i915_private {
int mux_regs_len;
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
+ const struct i915_oa_reg *flex_regs;
+ int flex_regs_len;
struct {
struct i915_vma *vma;
diff --git a/drivers/gpu/drm/i915/i915_oa_bdw.c
b/drivers/gpu/drm/i915/i915_oa_bdw.c
new file mode 100644
index ..b0b1b75fb431
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_bdw.c
@@ -0,0 +1,380 @@
+/*
+ * Autogenerated file, DO NOT EDIT manually!
+ *
+ * Copyright (c) 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
+
+#include "i915_drv.h"
+#include "i915_oa_bdw.h"
+
+enum metric_set_id {
+ METRIC_SET_ID_RENDER_BASIC = 1,
+};
+
+int i915_oa_n_builtin_metric_sets_bdw = 1;
+
+static const struct i915_oa_reg b_counter_config_render_basic[] = {
+ { _MMIO(0x2710), 0x },
+ { _MMIO(0x2714), 0x0080 },
+ { _MMIO(0x2720), 0x }
Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Add 'render basic' Gen8+ OA unit configs
On Fri, Mar 24, 2017 at 12:52 AM, Robert Bragg wrote:
> On Thu, Mar 23, 2017 at 8:48 PM, Matthew Auld
> wrote:
>> On 23 March 2017 at 20:18, Robert Bragg wrote:
>>> Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic
>>> render metrics on Broadwell, Cherryview, Skylake and Broxton. These are
>>> auto generated from an XML description of metric sets, currently
>>> maintained in gputop, ref:
>>>
>>> https://github.com/rib/gputop
>>> > gputop-data/oa-*.xml
>>> > scripts/i915-perf-kernelgen.py
>>>
>>> $ make -C gputop-data -f Makefile.xml WHITELIST=RenderBasic
>>>
>>> Signed-off-by: Robert Bragg
>>
>>
>>
>>> +
>>> +int i915_oa_select_metric_set_bdw(struct drm_i915_private *dev_priv)
>>> +{
>>> + dev_priv->perf.oa.mux_regs = NULL;
>>> + dev_priv->perf.oa.mux_regs_len = 0;
>>> + dev_priv->perf.oa.b_counter_regs = NULL;
>>> + dev_priv->perf.oa.b_counter_regs_len = 0;
>>> + dev_priv->perf.oa.flex_regs = NULL;
>>> + dev_priv->perf.oa.flex_regs_len = 0;
>>> +
>>> + switch (dev_priv->perf.oa.metrics_set) {
>>> + case METRIC_SET_ID_RENDER_BASIC:
>>> + dev_priv->perf.oa.mux_regs =
>>> + get_render_basic_mux_config(dev_priv,
>>> +
>>> &dev_priv->perf.oa.mux_regs_len);
>>> + if (!dev_priv->perf.oa.mux_regs) {
>>> + DRM_DEBUG_DRIVER("No suitable MUX config for
>>> \"RENDER_BASIC\" metric set");
>> You forgot to update your script ;)
>
> Hmm, that's odd; I didn't:
> https://github.com/rib/gputop/commit/95bc05957d488e2004ef2e7b5ba5b33d7dd559dd
>
> So need to double check what's up here.
*facepalm* - must have been on autopilot, sorry will fix.
>
>>
>>> +
>>> + /* EINVAL because *_register_sysfs already checked
>>> this
>>> +* and so it wouldn't have been advertised so
>>> userspace and
>>> +* so shouldn't have been requested
>> s/so userspace/to userspace/ ?
>
> Ah yup.
>
>>
>> Otherwise assuming the configs are indeed correct:
>> Reviewed-by: Matthew Auld
>
> Thanks
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Add 'render basic' Gen8+ OA unit configs
On Thu, Mar 23, 2017 at 8:48 PM, Matthew Auld
wrote:
> On 23 March 2017 at 20:18, Robert Bragg wrote:
>> Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic
>> render metrics on Broadwell, Cherryview, Skylake and Broxton. These are
>> auto generated from an XML description of metric sets, currently
>> maintained in gputop, ref:
>>
>> https://github.com/rib/gputop
>> > gputop-data/oa-*.xml
>> > scripts/i915-perf-kernelgen.py
>>
>> $ make -C gputop-data -f Makefile.xml WHITELIST=RenderBasic
>>
>> Signed-off-by: Robert Bragg
>
>
>
>> +
>> +int i915_oa_select_metric_set_bdw(struct drm_i915_private *dev_priv)
>> +{
>> + dev_priv->perf.oa.mux_regs = NULL;
>> + dev_priv->perf.oa.mux_regs_len = 0;
>> + dev_priv->perf.oa.b_counter_regs = NULL;
>> + dev_priv->perf.oa.b_counter_regs_len = 0;
>> + dev_priv->perf.oa.flex_regs = NULL;
>> + dev_priv->perf.oa.flex_regs_len = 0;
>> +
>> + switch (dev_priv->perf.oa.metrics_set) {
>> + case METRIC_SET_ID_RENDER_BASIC:
>> + dev_priv->perf.oa.mux_regs =
>> + get_render_basic_mux_config(dev_priv,
>> +
>> &dev_priv->perf.oa.mux_regs_len);
>> + if (!dev_priv->perf.oa.mux_regs) {
>> + DRM_DEBUG_DRIVER("No suitable MUX config for
>> \"RENDER_BASIC\" metric set");
> You forgot to update your script ;)
Hmm, that's odd; I didn't:
https://github.com/rib/gputop/commit/95bc05957d488e2004ef2e7b5ba5b33d7dd559dd
So need to double check what's up here.
>
>> +
>> + /* EINVAL because *_register_sysfs already checked
>> this
>> +* and so it wouldn't have been advertised so
>> userspace and
>> +* so shouldn't have been requested
> s/so userspace/to userspace/ ?
Ah yup.
>
> Otherwise assuming the configs are indeed correct:
> Reviewed-by: Matthew Auld
Thanks
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Reduce Data Link N value for 1 lane DP->hdmi converters
From: Clint Taylor
Several major vendor USB-C->HDMI converters fail to recover a 5.4 GHz 1 lane
signal if the Data Link N is greater than 0x8.
Patch detects when 1 lane 5.4 GHz signal is being used and makes the maximum
value 20 bit instead of the maximum specification supported 24 bit value.
v2: Detect specific device that exhibits the issue.
Cc: Dhinakaran Pandiyan
Cc: Jani Nikula
Cc: Anusha Srivatsa
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93578
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/i915_drv.h |3 ++-
drivers/gpu/drm/i915/i915_reg.h |2 ++
drivers/gpu/drm/i915/intel_display.c | 20 ++--
drivers/gpu/drm/i915/intel_dp.c | 14 --
drivers/gpu/drm/i915/intel_dp_mst.c |3 ++-
5 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a5947a4..6869df9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -580,7 +580,8 @@ struct intel_link_m_n {
void intel_link_compute_m_n(int bpp, int nlanes,
int pixel_clock, int link_clock,
- struct intel_link_m_n *m_n);
+ struct intel_link_m_n *m_n,
+ bool reduced_n);
/* Interface history:
*
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 04c8f69..838d8d5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4869,6 +4869,8 @@ enum {
#define DATA_LINK_M_N_MASK(0xff)
#define DATA_LINK_N_MAX (0x80)
+/* Maximum N value useable on some DP->HDMI converters */
+#define DATA_LINK_REDUCED_N_MAX (0x8)
#define _PIPEA_DATA_N_G4X 0x70054
#define _PIPEB_DATA_N_G4X 0x71054
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 010e5dd..143c7ac 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6139,7 +6139,7 @@ static int ironlake_fdi_compute_config(struct intel_crtc
*intel_crtc,
pipe_config->fdi_lanes = lane;
intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,
- link_bw, &pipe_config->fdi_m_n);
+ link_bw, &pipe_config->fdi_m_n, false);
ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe, pipe_config);
if (ret == -EINVAL && pipe_config->pipe_bpp > 6*3) {
@@ -6315,9 +6315,10 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
}
static void compute_m_n(unsigned int m, unsigned int n,
- uint32_t *ret_m, uint32_t *ret_n)
+ uint32_t *ret_m, uint32_t *ret_n,
+ uint32_t max_link_n)
{
- *ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX);
+ *ret_n = min_t(unsigned int, roundup_pow_of_two(n), max_link_n);
*ret_m = div_u64((uint64_t) m * *ret_n, n);
intel_reduce_m_n_ratio(ret_m, ret_n);
}
@@ -6325,16 +6326,23 @@ static void compute_m_n(unsigned int m, unsigned int n,
void
intel_link_compute_m_n(int bits_per_pixel, int nlanes,
int pixel_clock, int link_clock,
- struct intel_link_m_n *m_n)
+ struct intel_link_m_n *m_n,
+ bool reduced_n)
{
+ uint32_t max_link_n = DATA_LINK_N_MAX;
m_n->tu = 64;
+ if ((reduced_n) && (nlanes == 1) && (link_clock >= 54))
+ max_link_n = DATA_LINK_REDUCED_N_MAX;
+
compute_m_n(bits_per_pixel * pixel_clock,
link_clock * nlanes * 8,
- &m_n->gmch_m, &m_n->gmch_n);
+ &m_n->gmch_m, &m_n->gmch_n,
+ max_link_n);
compute_m_n(pixel_clock, link_clock,
- &m_n->link_m, &m_n->link_n);
+ &m_n->link_m, &m_n->link_n,
+ max_link_n);
}
static inline bool intel_panel_use_ssc(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fd96a6c..9c96f5f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1624,6 +1624,8 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
int common_rates[DP_MAX_SUPPORTED_RATES] = {};
int common_len;
uint8_t link_bw, rate_select;
+ char id[6];
+ bool reduced_n = false;
common_len = intel_dp_common_rates(intel_dp, common_rates);
@@ -1750,10 +1752,17 @@ static int intel_dp_compute_bpp(struct intel_dp
*intel_dp,
DRM_DEBUG_KMS("DP link bw required %i available %i\n",
mode_rate, link_avail);
+ /* Quirk to detect DP->HDMI converter */
+ drm_dp_downstream_id(&intel_dp->aux, id);
+ if (!strncmp(id , "7737" ,4)) {
+ reduced_n = true;
+
Re: [Intel-gfx] [PATCH v4 03/13] drm/i915/guc: Add onion teardown to the GuC setup
On 03/23/2017 03:57 PM, Chris Wilson wrote:
On Wed, Mar 22, 2017 at 10:39:46AM -0700, Oscar Mateo wrote:
Starting with intel_guc_loader, down to intel_guc_submission
and finally to intel_guc_log.
v2:
- Null execbuf client outside guc_client_free (Daniele)
- Assert if things try to get allocated twice (Daniele/Joonas)
- Null guc->log.buf_addr when destroyed (Daniele)
- Newline between returning success and error labels (Joonas)
- Remove some unnecessary comments (Joonas)
- Keep guc_log_create_extras naming convention (Joonas)
- Helper function guc_log_has_extras (Joonas)
- No need for separate relay_channel create/destroy. It's just another extra.
- No need to nullify guc->log.flush_wq when destroyed (Joonas)
- Hoist the check for has_extras out of guc_log_create_extras (Joonas)
- Try to do i915_guc_log_register/unregister calls (kind of) symmetric
(Daniele)
- Make sure initel_guc_fini is not called before init is ever called
(Daniele)
v3:
- Remove unnecessary parenthesis (Joonas)
- Check for logs enabled on debugfs registration
- Rebase on top of Tvrtko's "Fix request re-submission after reset"
v4:
- Rebased
- Comment around enabling/disabling interrupts inside GuC logging (Joonas)
Cc: Daniele Ceraolo Spurio
Reviewed-by: Joonas Lahtinen
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_drv.c| 11 +-
drivers/gpu/drm/i915/i915_gem.c| 10 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 97
drivers/gpu/drm/i915/intel_guc_loader.c| 21 --
drivers/gpu/drm/i915/intel_guc_log.c | 364 ++---
drivers/gpu/drm/i915/intel_uc.c| 55 +++--
drivers/gpu/drm/i915/intel_uc.h| 8 +-
7 files changed, 297 insertions(+), 269 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 03d9e45..6d9944a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -549,6 +549,8 @@ static bool i915_switcheroo_can_switch(struct pci_dev *pdev)
static void i915_gem_fini(struct drm_i915_private *dev_priv)
{
mutex_lock(&dev_priv->drm.struct_mutex);
+ if (i915.enable_guc_loading)
+ intel_uc_fini_hw(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fd611b4..4eb46e4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4596,10 +4596,12 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
intel_mocs_init_l3cc_table(dev_priv);
- /* We can't enable contexts until all firmware is loaded */
- ret = intel_uc_init_hw(dev_priv);
- if (ret)
- goto out;
+ if (i915.enable_guc_loading) {
+ /* We can't enable contexts until all firmware is loaded */
+ ret = intel_uc_init_hw(dev_priv);
+ if (ret)
+ goto out;
+ }
out:
I'm not happy with moving subfeature detection logic into the core GEM
code. if (i915.enable_guc_loading) firstly should never be a module
parameter (it's derived state!) and secondly it should reside next to
the dependent logic and not be interrupting the central control flow.
-Chris
What do you mean it's derived state? from what?
As for interrupting the central control flow, you are probably right, I
can change it back (the code was refactored so many times that I cannot
remember my logic behind that change anymore)
- Oscar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/dp: Validate cached link rate and lane count before retraining
Currently intel_dp_check_link_status() tries to retrain the link if
Clock recovery or Channel EQ for any of the lanes indicated by
intel_dp->lane_count is not set. However these values cached in intel_dp
structure can be stale if link training has failed for these values
during previous modeset. Or these values can get stale since we have
now re read the DPCD registers or it can be 0 in case of connected boot
case.
This patch validates these values against the common_rates and max lane
count values.
This is absolutely required incase the common_rates or max lane count
are now different due to link fallback.
Cc: Ville Syrjala
Cc: Jani Nikula
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/intel_dp.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fd96a6c..51fa6b5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -295,6 +295,23 @@ static int intel_dp_link_rate_index(struct intel_dp
*intel_dp,
return -1;
}
+static bool intel_dp_link_params_is_valid(struct intel_dp *intel_dp)
+{
+ int common_rates[DP_MAX_SUPPORTED_RATES];
+ int link_rate_index;
+
+ link_rate_index = intel_dp_link_rate_index(intel_dp,
+ common_rates,
+ intel_dp->link_rate);
+ if (link_rate_index < 0)
+ return false;
+ if (!intel_dp->lane_count ||
+ (intel_dp->lane_count > intel_dp_max_lane_count(intel_dp)))
+ return false;
+
+ return true;
+}
+
int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
int link_rate, uint8_t lane_count)
{
@@ -4224,9 +4241,10 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
if (!to_intel_crtc(intel_encoder->base.crtc)->active)
return;
- /* FIXME: we need to synchronize this sort of stuff with hardware
-* readout. Currently fast link training doesn't work on boot-up. */
- if (!intel_dp->lane_count)
+ /* Validate the cached values of intel_dp->link_rate and
+* intel_dp->lane_count before attempting to retrain.
+*/
+ if (!intel_dp_link_params_is_valid(intel_dp))
return;
/* Retrain if Channel EQ or CR not ok */
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/guc: Refactor the retrieval of guc_process_desc
Move the common "client->vaddr + client->proc_desc_offset" to its own
function, __get_process_desc() to match the newly established pattern.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_guc_submission.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 18fd36147dd5..6abf982ee594 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -280,6 +280,12 @@ static unsigned long __select_cacheline(struct intel_guc*
guc)
return offset;
}
+static inline struct guc_process_desc *
+__get_process_desc(struct i915_guc_client *client)
+{
+ return client->vaddr + client->proc_desc_offset;
+}
+
/*
* Initialise the process descriptor shared with the GuC firmware.
*/
@@ -288,9 +294,7 @@ static void guc_proc_desc_init(struct intel_guc *guc,
{
struct guc_process_desc *desc;
- desc = client->vaddr + client->proc_desc_offset;
-
- memset(desc, 0, sizeof(*desc));
+ desc = memset(__get_process_desc(client), 0, sizeof(*desc));
/*
* XXX: pDoorbell and WQVBaseAddress are pointers in process address
@@ -422,8 +426,7 @@ int i915_guc_wq_reserve(struct drm_i915_gem_request
*request)
{
const size_t wqi_size = sizeof(struct guc_wq_item);
struct i915_guc_client *client = request->i915->guc.execbuf_client;
- struct guc_process_desc *desc = client->vaddr +
- client->proc_desc_offset;
+ struct guc_process_desc *desc = __get_process_desc(client);
u32 freespace;
int ret;
@@ -468,12 +471,10 @@ static void guc_wq_item_append(struct i915_guc_client
*client,
const size_t wqi_size = sizeof(struct guc_wq_item);
const u32 wqi_len = wqi_size/sizeof(u32) - 1;
struct intel_engine_cs *engine = rq->engine;
- struct guc_process_desc *desc;
+ struct guc_process_desc *desc = __get_process_desc(client);
struct guc_wq_item *wqi;
u32 freespace, tail, wq_off;
- desc = client->vaddr + client->proc_desc_offset;
-
/* Free space is guaranteed, see i915_guc_wq_reserve() above */
freespace = CIRC_SPACE(client->wq_tail, desc->head, client->wq_size);
GEM_BUG_ON(freespace < wqi_size);
@@ -519,8 +520,7 @@ static void guc_wq_item_append(struct i915_guc_client
*client,
static void guc_reset_wq(struct i915_guc_client *client)
{
- struct guc_process_desc *desc = client->vaddr +
- client->proc_desc_offset;
+ struct guc_process_desc *desc = __get_process_desc(client);
desc->head = 0;
desc->tail = 0;
@@ -530,13 +530,11 @@ static void guc_reset_wq(struct i915_guc_client *client)
static int guc_ring_doorbell(struct i915_guc_client *client)
{
- struct guc_process_desc *desc;
+ struct guc_process_desc *desc = __get_process_desc(client);
union guc_doorbell_qw db_cmp, db_exc, db_ret;
union guc_doorbell_qw *db;
int attempt = 2, ret = -EAGAIN;
- desc = client->vaddr + client->proc_desc_offset;
-
/* Update the tail so it is visible to GuC */
desc->tail = client->wq_tail;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 03/13] drm/i915/guc: Add onion teardown to the GuC setup
On Wed, Mar 22, 2017 at 10:39:46AM -0700, Oscar Mateo wrote:
> Starting with intel_guc_loader, down to intel_guc_submission
> and finally to intel_guc_log.
>
> v2:
> - Null execbuf client outside guc_client_free (Daniele)
> - Assert if things try to get allocated twice (Daniele/Joonas)
> - Null guc->log.buf_addr when destroyed (Daniele)
> - Newline between returning success and error labels (Joonas)
> - Remove some unnecessary comments (Joonas)
> - Keep guc_log_create_extras naming convention (Joonas)
> - Helper function guc_log_has_extras (Joonas)
> - No need for separate relay_channel create/destroy. It's just another
> extra.
> - No need to nullify guc->log.flush_wq when destroyed (Joonas)
> - Hoist the check for has_extras out of guc_log_create_extras (Joonas)
> - Try to do i915_guc_log_register/unregister calls (kind of) symmetric
> (Daniele)
> - Make sure initel_guc_fini is not called before init is ever called
> (Daniele)
>
> v3:
> - Remove unnecessary parenthesis (Joonas)
> - Check for logs enabled on debugfs registration
> - Rebase on top of Tvrtko's "Fix request re-submission after reset"
>
> v4:
> - Rebased
> - Comment around enabling/disabling interrupts inside GuC logging (Joonas)
>
> Cc: Daniele Ceraolo Spurio
> Reviewed-by: Joonas Lahtinen
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_drv.c| 11 +-
> drivers/gpu/drm/i915/i915_gem.c| 10 +-
> drivers/gpu/drm/i915/i915_guc_submission.c | 97
> drivers/gpu/drm/i915/intel_guc_loader.c| 21 --
> drivers/gpu/drm/i915/intel_guc_log.c | 364
> ++---
> drivers/gpu/drm/i915/intel_uc.c| 55 +++--
> drivers/gpu/drm/i915/intel_uc.h| 8 +-
> 7 files changed, 297 insertions(+), 269 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 03d9e45..6d9944a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -549,6 +549,8 @@ static bool i915_switcheroo_can_switch(struct pci_dev
> *pdev)
> static void i915_gem_fini(struct drm_i915_private *dev_priv)
> {
> mutex_lock(&dev_priv->drm.struct_mutex);
> + if (i915.enable_guc_loading)
> + intel_uc_fini_hw(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index fd611b4..4eb46e4 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4596,10 +4596,12 @@ int i915_gem_init_hw(struct drm_i915_private
> *dev_priv)
>
> intel_mocs_init_l3cc_table(dev_priv);
>
> - /* We can't enable contexts until all firmware is loaded */
> - ret = intel_uc_init_hw(dev_priv);
> - if (ret)
> - goto out;
> + if (i915.enable_guc_loading) {
> + /* We can't enable contexts until all firmware is loaded */
> + ret = intel_uc_init_hw(dev_priv);
> + if (ret)
> + goto out;
> + }
>
> out:
I'm not happy with moving subfeature detection logic into the core GEM
code. if (i915.enable_guc_loading) firstly should never be a module
parameter (it's derived state!) and secondly it should reside next to
the dependent logic and not be interrupting the central control flow.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH I-G-T 4/4] tests/kms_fbcon_fbt: Refactor to use IGT PSR library functions
On Mon, 2017-02-13 at 15:43 -0800, Jim Bride wrote:
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Signed-off-by: Jim Bride
> ---
> tests/kms_fbcon_fbt.c | 47 +++
> 1 file changed, 11 insertions(+), 36 deletions(-)
>
> diff --git a/tests/kms_fbcon_fbt.c b/tests/kms_fbcon_fbt.c
> index 6342289..a59257b 100644
> --- a/tests/kms_fbcon_fbt.c
> +++ b/tests/kms_fbcon_fbt.c
> @@ -103,8 +103,9 @@ static bool fbc_is_enabled(void)
> return strstr(buf, "FBC enabled\n");
> }
>
> -static bool fbc_wait_until_enabled(void)
> +static bool fbc_wait_until_enabled(bool enabled)
> {
> + enabled = enabled;
why is this needed?
> return igt_wait(fbc_is_enabled(), 5000, 1);
> }
>
> @@ -147,35 +148,9 @@ static void set_mode_for_one_screen(struct drm_info
> *drm, struct igt_fb *fb,
> igt_assert_eq(rc, 0);
> }
>
> -static bool psr_supported_on_chipset(void)
> -{
> - char buf[256];
> -
> - igt_debugfs_read("i915_edp_psr_status", buf);
> - return strstr(buf, "Sink_Support: yes\n");
> -}
> -
> -static bool connector_can_psr(drmModeConnectorPtr connector)
> -{
> - return (connector->connector_type == DRM_MODE_CONNECTOR_eDP);
> -}
> -
> -static bool psr_is_enabled(void)
> -{
> - char buf[256];
> -
> - igt_debugfs_read("i915_edp_psr_status", buf);
> - return strstr(buf, "\nActive: yes\n");
> -}
> -
> -static bool psr_wait_until_enabled(void)
> -{
> - return igt_wait(psr_is_enabled(), 5000, 1);
> -}
> -
> struct feature {
> bool (*supported_on_chipset)(void);
> - bool (*wait_until_enabled)(void);
> + bool (*wait_until_enabled)(bool status);
> bool (*connector_possible_fn)(drmModeConnectorPtr connector);
> const char *param_name;
> } fbc = {
> @@ -184,9 +159,9 @@ struct feature {
> .connector_possible_fn = connector_can_fbc,
> .param_name = "enable_fbc",
> }, psr = {
> - .supported_on_chipset = psr_supported_on_chipset,
> - .wait_until_enabled = psr_wait_until_enabled,
> - .connector_possible_fn = connector_can_psr,
> + .supported_on_chipset = igt_psr_sink_support,
> + .wait_until_enabled = igt_psr_await_status,
> + .connector_possible_fn = igt_psr_valid_connector,
> .param_name = "enable_psr",
> };
>
> @@ -210,17 +185,17 @@ static void subtest(struct feature *feature, bool
> suspend)
>
> kmstest_unset_all_crtcs(drm.fd, drm.res);
> wait_user("Modes unset.");
> - igt_assert(!feature->wait_until_enabled());
> + igt_assert(!feature->wait_until_enabled(true));
>
> set_mode_for_one_screen(&drm, &fb, feature->connector_possible_fn);
> wait_user("Screen set.");
> - igt_assert(feature->wait_until_enabled());
> + igt_assert(feature->wait_until_enabled(true));
>
> if (suspend) {
> igt_system_suspend_autoresume(SUSPEND_STATE_MEM,
> SUSPEND_TEST_NONE);
> sleep(5);
> - igt_assert(feature->wait_until_enabled());
> + igt_assert(feature->wait_until_enabled(true));
> }
>
> igt_remove_fb(drm.fd, &fb);
> @@ -230,13 +205,13 @@ static void subtest(struct feature *feature, bool
> suspend)
> sleep(3);
>
> wait_user("Back to fbcon.");
> - igt_assert(!feature->wait_until_enabled());
> + igt_assert(!feature->wait_until_enabled(true));
>
> if (suspend) {
> igt_system_suspend_autoresume(SUSPEND_STATE_MEM,
> SUSPEND_TEST_NONE);
> sleep(5);
> - igt_assert(!feature->wait_until_enabled());
> + igt_assert(!feature->wait_until_enabled(true));
> }
> }
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH I-G-T 3/4] tests/kms_frontbuffer_tracking: Refactor to use IGT PSR library functions
Reviewed-by: Rodrigo Vivi
On Mon, 2017-02-13 at 15:43 -0800, Jim Bride wrote:
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Signed-off-by: Jim Bride
> ---
> tests/kms_frontbuffer_tracking.c | 47
>
> 1 file changed, 9 insertions(+), 38 deletions(-)
>
> diff --git a/tests/kms_frontbuffer_tracking.c
> b/tests/kms_frontbuffer_tracking.c
> index 4f4848b..91376e4 100644
> --- a/tests/kms_frontbuffer_tracking.c
> +++ b/tests/kms_frontbuffer_tracking.c
> @@ -793,23 +793,6 @@ static void fbc_print_status(void)
> igt_info("FBC status:\n%s\n", buf);
> }
>
> -static bool psr_is_enabled(void)
> -{
> - char buf[256];
> -
> - igt_debugfs_read("i915_edp_psr_status", buf);
> - return strstr(buf, "\nActive: yes\n") &&
> -strstr(buf, "\nHW Enabled & Active bit: yes\n");
> -}
> -
> -static void psr_print_status(void)
> -{
> - char buf[256];
> -
> - igt_debugfs_read("i915_edp_psr_status", buf);
> - igt_info("PSR status:\n%s\n", buf);
> -}
> -
> static struct timespec fbc_get_last_action(void)
> {
> struct timespec ret = { 0, 0 };
> @@ -915,15 +898,8 @@ static bool fbc_wait_until_enabled(void)
> return igt_wait(fbc_is_enabled(), 2000, 1);
> }
>
> -static bool psr_wait_until_enabled(void)
> -{
> - return igt_wait(psr_is_enabled(), 5000, 1);
> -}
> -
> #define fbc_enable() igt_set_module_param_int("enable_fbc", 1)
> #define fbc_disable() igt_set_module_param_int("enable_fbc", 0)
> -#define psr_enable() igt_set_module_param_int("enable_psr", 1)
> -#define psr_disable() igt_set_module_param_int("enable_psr", 0)
>
> static void get_sink_crc(sink_crc_t *crc, bool mandatory)
> {
> @@ -1169,7 +1145,7 @@ static void disable_features(const struct test_mode *t)
> return;
>
> fbc_disable();
> - psr_disable();
> + igt_psr_disable();
> }
>
> static void *busy_thread_func(void *data)
> @@ -1529,14 +1505,6 @@ static void teardown_fbc(void)
> {
> }
>
> -static bool psr_sink_has_support(void)
> -{
> - char buf[256];
> -
> - igt_debugfs_read("i915_edp_psr_status", buf);
> - return strstr(buf, "Sink_Support: yes\n");
> -}
> -
> static void setup_psr(void)
> {
> if (get_connector(prim_mode_params.connector_id)->connector_type !=
> @@ -1545,7 +1513,7 @@ static void setup_psr(void)
> return;
> }
>
> - if (!psr_sink_has_support()) {
> + if (!igt_psr_sink_support()) {
> igt_info("Can't test PSR: not supported by sink.\n");
> return;
> }
> @@ -1699,12 +1667,15 @@ static int adjust_assertion_flags(const struct
> test_mode *t, int flags)
> } \
> \
> if (flags_ & ASSERT_PSR_ENABLED) { \
> - if (!psr_wait_until_enabled()) {\
> - psr_print_status(); \
> + if (!igt_psr_await_status(true)) { \
> + igt_psr_print_status(); \
> igt_assert_f(false, "PSR disabled\n"); \
> } \
> } else if (flags_ & ASSERT_PSR_DISABLED) { \
> - igt_assert(!psr_wait_until_enabled()); \
> + if (!igt_psr_await_status(false)) { \
> + igt_psr_print_status(); \
> + igt_assert_f(false, "PSR enabled\n"); \
> + } \
> } \
> } while (0)
>
> @@ -1804,7 +1775,7 @@ static void enable_features_for_test(const struct
> test_mode *t)
> if (t->feature & FEATURE_FBC)
> fbc_enable();
> if (t->feature & FEATURE_PSR)
> - psr_enable();
> + igt_psr_enable();
> }
>
> static void check_test_requirements(const struct test_mode *t)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH I-G-T 2/4] tests/kms_psr_sink_crc: Refactor to use new PSR library primitives
On Mon, 2017-02-13 at 15:43 -0800, Jim Bride wrote:
> Cc: Rodrigo Vivi
> Signed-off-by: Jim Bride
> ---
> tests/kms_psr_sink_crc.c | 53
> ++--
> 1 file changed, 11 insertions(+), 42 deletions(-)
>
> diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
> index 8f6bdc0..1d9eb11 100644
> --- a/tests/kms_psr_sink_crc.c
> +++ b/tests/kms_psr_sink_crc.c
> @@ -191,37 +191,6 @@ static void fill_render(data_t *data, uint32_t handle,
> unsigned char color)
> gem_bo_busy(data->drm_fd, handle);
> }
>
> -static bool psr_possible(data_t *data)
> -{
> - char buf[512];
> -
> - igt_debugfs_read("i915_edp_psr_status", buf);
> -
> - return running_with_psr_disabled ||
Oh! this patch removes the hability to run with psr disabled!
I really likes this functionality so we can know what to expect when PSR
is in place.
> - strstr(buf, "Sink_Support: yes\n");
> -}
> -
> -static bool psr_active(data_t *data)
> -{
> - char buf[512];
> -
> - igt_debugfs_read("i915_edp_psr_status", buf);
> -
> - return running_with_psr_disabled ||
> - strstr(buf, "HW Enabled & Active bit: yes\n");
> -}
> -
> -static bool wait_psr_entry(data_t *data)
> -{
> - int timeout = 5;
> - while (timeout--) {
> - if (psr_active(data))
> - return true;
> - sleep(1);
> - }
> - return false;
> -}
> -
> static void get_sink_crc(data_t *data, char *crc) {
> int ret;
> FILE *file;
> @@ -301,7 +270,7 @@ static void run_test(data_t *data)
> assert_or_manual(is_green(ref_crc), "screen GREEN");
>
> /* Confirm screen stays Green after PSR got active */
> - igt_assert(wait_psr_entry(data));
> + igt_assert(igt_psr_await_status(true));
> get_sink_crc(data, ref_crc);
> assert_or_manual(is_green(ref_crc), "screen GREEN");
>
> @@ -315,7 +284,7 @@ static void run_test(data_t *data)
> igt_display_commit(&data->display);
>
> /* Confirm it is not Green anymore */
> - igt_assert(wait_psr_entry(data));
> + igt_assert(igt_psr_await_status(true));
> get_sink_crc(data, ref_crc);
> if (data->test_plane == DRM_PLANE_TYPE_PRIMARY)
> assert_or_manual(!is_green(ref_crc), "screen WHITE");
> @@ -513,7 +482,7 @@ int main(int argc, char *argv[])
> igt_set_module_param_int("enable_psr",
> running_with_psr_disabled ?
>0 : 1);
>
> - igt_skip_on(!psr_possible(&data));
> + igt_skip_on(!igt_psr_possible());
>
> data.bufmgr = drm_intel_bufmgr_gem_init(data.drm_fd, 4096);
> igt_assert(data.bufmgr);
> @@ -524,7 +493,7 @@ int main(int argc, char *argv[])
>
> igt_subtest("psr_basic") {
> setup_test_plane(&data);
> - igt_assert(wait_psr_entry(&data));
> + igt_assert(igt_psr_await_status(true));
> }
>
> for (op = PAGE_FLIP; op <= RENDER; op++) {
> @@ -532,7 +501,7 @@ int main(int argc, char *argv[])
> data.test_plane = DRM_PLANE_TYPE_PRIMARY;
> data.op = op;
> setup_test_plane(&data);
> - igt_assert(wait_psr_entry(&data));
> + igt_assert(igt_psr_await_status(true));
> run_test(&data);
> test_cleanup(&data);
> }
> @@ -543,7 +512,7 @@ int main(int argc, char *argv[])
> data.test_plane = DRM_PLANE_TYPE_OVERLAY;
> data.op = op;
> setup_test_plane(&data);
> - igt_assert(wait_psr_entry(&data));
> + igt_assert(igt_psr_await_status(true));
> run_test(&data);
> test_cleanup(&data);
> }
> @@ -554,7 +523,7 @@ int main(int argc, char *argv[])
> data.test_plane = DRM_PLANE_TYPE_CURSOR;
> data.op = op;
> setup_test_plane(&data);
> - igt_assert(wait_psr_entry(&data));
> + igt_assert(igt_psr_await_status(true));
> run_test(&data);
> test_cleanup(&data);
> }
> @@ -564,7 +533,7 @@ int main(int argc, char *argv[])
> data.test_plane = DRM_PLANE_TYPE_PRIMARY;
> data.op = RENDER;
> setup_test_plane(&data);
> - igt_assert(wait_psr_entry(&data));
> + igt_assert(igt_psr_await_status(true));
>
> dpms_off_on(data);
>
> @@ -579,7 +548,7 @@ int main(int argc, char *argv[])
>
> dpms_off_on(data);
>
> - igt_assert(wait_psr_entry(&data));
> + igt_assert(igt_psr_await_status(true));
> run_test(&data);
> test_cleanup(&data);
> }
> @@ -588,7 +557,7 @@ int main(in
Re: [Intel-gfx] [PATCH I-G-T 1/4] lib: Add PSR utility functions to igt library.
On Mon, 2017-02-13 at 15:43 -0800, Jim Bride wrote:
> Factor out some code that was replicated in three test utilities into
> some new IGT library functions so that we are checking PSR status in
> a consistent fashion across all of our PSR tests.
>
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Signed-off-by: Jim Bride
> ---
> lib/Makefile.sources | 2 +
> lib/igt.h| 1 +
> lib/igt_psr.c| 147
> +++
> lib/igt_psr.h| 38 +
> 4 files changed, 188 insertions(+)
> create mode 100644 lib/igt_psr.c
> create mode 100644 lib/igt_psr.h
>
> diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> index 6348487..0a8835b 100644
> --- a/lib/Makefile.sources
> +++ b/lib/Makefile.sources
> @@ -83,6 +83,8 @@ lib_source_list = \
> uwildmat/uwildmat.c \
> igt_kmod.c \
> igt_kmod.h \
> + igt_psr.c \
> + igt_psr.h \
> $(NULL)
>
> if HAVE_CHAMELIUM
> diff --git a/lib/igt.h b/lib/igt.h
> index a97923e..7f52d6c 100644
> --- a/lib/igt.h
> +++ b/lib/igt.h
> @@ -37,6 +37,7 @@
> #include "igt_gt.h"
> #include "igt_kms.h"
> #include "igt_pm.h"
> +#include "igt_psr.h"
> #include "igt_stats.h"
> #include "igt_chamelium.h"
> #include "instdone.h"
> diff --git a/lib/igt_psr.c b/lib/igt_psr.c
> new file mode 100644
> index 000..833a9d6
> --- /dev/null
> +++ b/lib/igt_psr.c
> @@ -0,0 +1,147 @@
> +/*
> + * Copyright © 2017 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.h"
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + * SECTION:igt_psr
> + * @short_description: Panel Self Refresh helpers
> + * @title: Panel Self Refresh
> + * @include: igt.h
> + *
> + * This library provides various helpers to enable Panel Self Refresh,
> + * as well as to check the state of PSR on the system (enabled vs.
> + * disabled, active vs. inactive) or to wait for PSR to be active
> + * or inactive.
> + */
> +
> +/**
> + * igt_psr_possible:
> + *
> + * Returns true if both the source and sink support PSR.
> + */
> +bool igt_psr_possible(void)
> +{
> + char buf[512];
> +
> + igt_debugfs_read("i915_edp_psr_status", buf);
> +
> + return strstr(buf, "Source_OK: yes\n") &&
Remember that with i915.enable_psr=0 Source_OK is "no". But PSR might
still be "possible".
Maybe we could find a better name for the function?
Anyways
Reviewed-by: Rodrigo Vivi
> + strstr(buf, "Sink_Support: yes\n");
> +}
> +
> +/**
> + * igt_psr_active:
> + *
> + * Returns true if PSR is active on the panel.
> + */
> +bool igt_psr_active(void)
> +{
> + char buf[512];
> + bool actret = false;
> + bool hwactret = false;
> +
> + igt_debugfs_read("i915_edp_psr_status", buf);
> + hwactret = (strstr(buf, "HW Enabled & Active bit: yes\n") != NULL);
> + actret = (strstr(buf, "Active: yes\n") != NULL);
> + igt_debug("hwactret: %s actret: %s\n", hwactret ? "true" : "false",
> + actret ? "true" : "false");
> + return hwactret && actret;
> +}
> +
> +/**
> + * igt_psr_await_status:
> + * @active: A boolean that causes the function to wait for PSR to activate
> + * if set to true, or to wait for PSR to deactivate if false.
> + *
> + * Returns true if the requested condition is met.
> + */
> +bool igt_psr_await_status(bool active)
> +{
> + const int timeout = 5;
> + int count = 0;
> + while (count < timeout) {
> + if (igt_psr_active() == active) {
> + igt_debug("PSR %s after %d seconds.\n",
> + active ? "Active" : "Inactive", count);
> + return true;
> + }
> + count++;
> + sleep(1);
> + }
> + return false;
> +}
> +
> +/**
> +
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Relax the locked clear_bit(IRQ_EXECLIST)
On Thu, Mar 23, 2017 at 04:51:54PM +, Tvrtko Ursulin wrote: > > On 23/03/2017 13:48, Chris Wilson wrote: > >We only need to care about the ordering of the clearing of the bit with > >the uncached CSB read in order to correctly detect a new interrupt > >before the read completes. The uncached read itself acts as a full > >memory barrier, so we do not to enforce another in the form of a locked > >need ^ > > >clear_bit. > > > >Signed-off-by: Chris Wilson > >Cc: Tvrtko Ursulin > >--- > > drivers/gpu/drm/i915/intel_lrc.c | 9 - > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > >diff --git a/drivers/gpu/drm/i915/intel_lrc.c > >b/drivers/gpu/drm/i915/intel_lrc.c > >index 59acdd3b7a12..c9010fa881b4 100644 > >--- a/drivers/gpu/drm/i915/intel_lrc.c > >+++ b/drivers/gpu/drm/i915/intel_lrc.c > >@@ -540,7 +540,14 @@ static void intel_lrc_irq_handler(unsigned long data) > > dev_priv->regs + > > i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)); > > unsigned int csb, head, tail; > > > >-clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted); > >+/* The write will be ordered by the uncached read (itself > >+ * a memory barrier), we do need another in the form a > > not ^ > > >+ * locked instruction. That is the clear of IRQ_EXECLIST bit > >+ * will be visible to another cpu prior to the completion > >+ * of the CSB read. If the other cpu receives an interrupt > >+ * before then, we will redo the CSB read. > > I don't think the the visibility of clearing the bit matters to > anyone. Just the harmlessness of the race between the interrupt > sandwiching between test bit and clear bit. Yes, spelling out the harmlessness makes a better comment. Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Various improvements around the GuC topic
On 03/23/2017 06:20 AM, Joonas Lahtinen wrote: Merged this series except the HAX patch (also, reordered the S-o-b, R-b and Cc lines to canonical form), so do rebase your work. Regards, Joonas Thanks! On to, 2017-03-23 at 11:06 +, Patchwork wrote: == Series Details == Series: Various improvements around the GuC topic URL : https://patchwork.freedesktop.org/series/21726/ State : success == Summary == Series 21726v1 Various improvements around the GuC topic https://patchwork.freedesktop.org/api/1.0/series/21726/revisions/1/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 460s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 461s fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 time: 593s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 523s fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 time: 511s fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 time: 502s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 441s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 431s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 436s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 509s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 496s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 478s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 468s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 588s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 480s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 513s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 446s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 558s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time: 416s 8229a8c712c22ff8e94e3244d4fd942a7dcd89af drm-tip: 2017y-03m-23d-09h-57m-34s UTC integration manifest f003ba2 HAX Enable GuC loading & submission 43d51b6 drm/i915/guc: Move guc_interrupts_release next to guc_interrupts_capture 19b8f8a drm/i915/guc: Split out the mmio_white_list struct 22675ac drm/i915/guc: Refactor the concept "GuC context descriptor" into "GuC stage descriptor" 98c3280 drm/i915/guc: A little bit more of doorbell sanitization a5d1810 drm/i915/guc: Wait for doorbell to be inactive before deallocating cf3850d drm/i915/guc: Improve the GuC documentation & comments about proxy submissions 7112b1b drm/i915/guc: Make intel_guc_send a function pointer cdbbc12 drm/i915/guc: Break out the GuC log extras into their own "runtime" struct 0009b27 drm/i915/guc: The Additional Data Struct (ADS) should get enabled together with GuC submission c11c121 drm/i915/guc: Add onion teardown to the GuC setup d1a1ced drm/i915/guc: Keep the ctx_pool_vaddr mapped, for easy access 5956a8b drm/i915/guc: Sanitize GuC client initialization == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4273/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Nuke ironlake_plane_ctl()
On Thu, Mar 23, 2017 at 09:27:08PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Share the code to compute the primary plane control register value > between the i9xx and ilk codepaths as the differences are minimal. > Actually there are no differences between g4x and ilk, so the > current split doesn't really make any sense. > > Cc: Chris Wilson > Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson > --- > drivers/gpu/drm/i915/intel_display.c | 58 > > 1 file changed, 6 insertions(+), 52 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index aa2c85b2bf78..4f57ce982a72 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -2974,9 +2974,13 @@ static u32 i9xx_plane_ctl(const struct > intel_crtc_state *crtc_state, > > dspcntr = DISPLAY_PLANE_ENABLE | DISPPLANE_GAMMA_ENABLE; > > - if (IS_G4X(dev_priv)) > + if (IS_G4X(dev_priv) || IS_GEN5(dev_priv) || > + IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv)) > dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE; Fortunately I remembered the explanation last time about vlv and chv, and yes this does make that much more obvious. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Extract i9xx_plane_ctl() and ironlake_plane_ctl()
On Thu, Mar 23, 2017 at 09:27:07PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Pull the code to calculate the pre-SKL primary plane control register > value into separate functions. Allows us to pre-compute it in the > future. > > v2: Split the pre-ilk vs. ilk+ unification to a separate patch (Chris) > > Cc: Chris Wilson > Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Regression in i915 for 4.11-rc1 - bisected to commit 69df05e11ab8
On 03/23/2017 03:44 PM, Chris Wilson wrote:
On Thu, Mar 23, 2017 at 01:19:43PM -0500, Larry Finger wrote:
Since kernel 4.11-rc1, my desktop (Plasma5/KDE) has encountered
intermittent hangs with the following information in the logs:
linux-4v1g.suse kernel: [drm] GPU HANG: ecode 7:0:0xf3ce, in
plasmashell [1283], reason: Hang on render ring, action: reset
linux-4v1g.suse kernel: [drm] GPU hangs can indicate a bug anywhere
in the entire gfx stack, including userspace.
linux-4v1g.suse kernel: [drm] Please file a _new_ bug report on
bugs.freedesktop.org against DRI -> DRM/Intel
linux-4v1g.suse kernel: [drm] drm/i915 developers can then reassign
to the right component if it's not a kernel issue.
linux-4v1g.suse kernel: [drm] The gpu crash dump is required to
analyze gpu hangs, so please always attach it.
linux-4v1g.suse kernel: [drm] GPU crash dump saved to /sys/class/drm/card0/error
linux-4v1g.suse kernel: drm/i915: Resetting chip after gpu hang
This problem was added to
https://bugs.freedesktop.org/show_bug.cgi?id=99380, but it probably
is a different bug, as the OP in that report has problems with
kernel 4.10.x, whereas my problem did not appear until 4.11.
Close. Actually that patch touches code you are not using (oa-perf and
gvt), the real culprit was e8a9c58fcd9a ("drm/i915: Unify active context
tracking between legacy/execlists/guc").
The fix
commit 5d4bac5503fcc67dd7999571e243cee49371aef7
Author: Chris Wilson
Date: Wed Mar 22 20:59:30 2017 +
drm/i915: Restore marking context objects as dirty on pinning
Commit e8a9c58fcd9a ("drm/i915: Unify active context tracking between
legacy/execlists/guc") converted the legacy intel_ringbuffer submission
to the same context pinning mechanism as execlists - that is to pin the
context until the subsequent request is retired. Previously it used the
vma retirement of the context object to keep itself pinned until the
next request (after i915_vma_move_to_active()). In the conversion, I
missed that the vma retirement was also responsible for marking the
object as dirty. Mark the context object as dirty when pinning
(equivalent to execlists) which ensures that if the context is swapped
out due to mempressure or suspend/hibernation, when it is loaded back in
it does so with the previous state (and not all zero).
Fixes: e8a9c58fcd9a ("drm/i915: Unify active context tracking between
legacy/execlists/guc")
Reported-by: Dennis Gilmore
Reported-by: Mathieu Marquer
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=3
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100181
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v4.11-rc1
Link:
http://patchwork.freedesktop.org/patch/msgid/20170322205930.12762-1-ch...@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin
went in this morning and so will be upstreamed ~next week.
-Chris
Thanks. With a bug that is difficult to trigger, bisection is difficult. I am
surprised that the only step I got wrong was the last one. BTW, my reversion
failed after 20 hours. I was ready to write again when I got your fix. Good timing.
If your patch does not fix my problem, I will let you know.
Larry
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH dim 2/2] dim: Curate and insert tags into patch(es)
Launch $EDITOR when extracting tags to curate the tags immediately. Once the
tags are proper, automatically add them before the first Signed-off-by line
to all patches in the range.
Signed-off-by: Sean Paul
---
dim | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/dim b/dim
index 43ea794..6a5580a 100755
--- a/dim
+++ b/dim
@@ -1145,6 +1145,12 @@ function rangeish()
fi
}
+function insert_extracted_tags
+{
+ new_tabs=`cat $1 | awk '{ORS="n"} {print $0}' | head -c-3`
+ awk "/Signed-off-by/{p++} p==1{print \"$new_tabs\"; p++} p!=1{print}"
+}
+
function dim_extract_tags
{
local branch range file tags
@@ -1167,9 +1173,10 @@ function dim_extract_tags
return 0
fi
- tags=$(printf -- "# *** extracted tags ***\n%s" "$tags")
-
- git filter-branch -f --msg-filter "cat ; echo \"$tags\"" $range
+ echo "$tags" > $file
+ $EDITOR $file
+ export -f insert_extracted_tags
+ git filter-branch -f --msg-filter "insert_extracted_tags $file" $range
}
function dim_extract_queued
--
2.12.1.500.gab5fba24ee-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH dim 1/2] dim: Add support for multiple messages in extract-tags
Make extract-tags process tags from all messages in the supplied
mbox. This allows the user to tag multiple replies and extract
all tags at once.
Signed-off-by: Sean Paul
---
dim | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/dim b/dim
index 989674a..43ea794 100755
--- a/dim
+++ b/dim
@@ -342,25 +342,27 @@ if message_id is not None:
EOF
}
-message_print_body ()
+mbox_cat_messages ()
{
python2 < $file
- tags=$(message_print_body "$file" | grep -ai '^[^>]*[A-Za-z-]\+: [^ ]')
+ tags=$(mbox_cat_messages "$file" | grep -ai '^[^>]*[A-Za-z-]\+: [^ ]')
rm -f $file
--
2.12.1.500.gab5fba24ee-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Add 'render basic' Gen8+ OA unit configs
On 23 March 2017 at 20:18, Robert Bragg wrote:
> Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic
> render metrics on Broadwell, Cherryview, Skylake and Broxton. These are
> auto generated from an XML description of metric sets, currently
> maintained in gputop, ref:
>
> https://github.com/rib/gputop
> > gputop-data/oa-*.xml
> > scripts/i915-perf-kernelgen.py
>
> $ make -C gputop-data -f Makefile.xml WHITELIST=RenderBasic
>
> Signed-off-by: Robert Bragg
> +
> +int i915_oa_select_metric_set_bdw(struct drm_i915_private *dev_priv)
> +{
> + dev_priv->perf.oa.mux_regs = NULL;
> + dev_priv->perf.oa.mux_regs_len = 0;
> + dev_priv->perf.oa.b_counter_regs = NULL;
> + dev_priv->perf.oa.b_counter_regs_len = 0;
> + dev_priv->perf.oa.flex_regs = NULL;
> + dev_priv->perf.oa.flex_regs_len = 0;
> +
> + switch (dev_priv->perf.oa.metrics_set) {
> + case METRIC_SET_ID_RENDER_BASIC:
> + dev_priv->perf.oa.mux_regs =
> + get_render_basic_mux_config(dev_priv,
> +
> &dev_priv->perf.oa.mux_regs_len);
> + if (!dev_priv->perf.oa.mux_regs) {
> + DRM_DEBUG_DRIVER("No suitable MUX config for
> \"RENDER_BASIC\" metric set");
You forgot to update your script ;)
> +
> + /* EINVAL because *_register_sysfs already checked
> this
> +* and so it wouldn't have been advertised so
> userspace and
> +* so shouldn't have been requested
s/so userspace/to userspace/ ?
Otherwise assuming the configs are indeed correct:
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Regression in i915 for 4.11-rc1 - bisected to commit 69df05e11ab8
On Thu, Mar 23, 2017 at 01:19:43PM -0500, Larry Finger wrote:
> Since kernel 4.11-rc1, my desktop (Plasma5/KDE) has encountered
> intermittent hangs with the following information in the logs:
>
> linux-4v1g.suse kernel: [drm] GPU HANG: ecode 7:0:0xf3ce, in
> plasmashell [1283], reason: Hang on render ring, action: reset
> linux-4v1g.suse kernel: [drm] GPU hangs can indicate a bug anywhere
> in the entire gfx stack, including userspace.
> linux-4v1g.suse kernel: [drm] Please file a _new_ bug report on
> bugs.freedesktop.org against DRI -> DRM/Intel
> linux-4v1g.suse kernel: [drm] drm/i915 developers can then reassign
> to the right component if it's not a kernel issue.
> linux-4v1g.suse kernel: [drm] The gpu crash dump is required to
> analyze gpu hangs, so please always attach it.
> linux-4v1g.suse kernel: [drm] GPU crash dump saved to
> /sys/class/drm/card0/error
> linux-4v1g.suse kernel: drm/i915: Resetting chip after gpu hang
>
> This problem was added to
> https://bugs.freedesktop.org/show_bug.cgi?id=99380, but it probably
> is a different bug, as the OP in that report has problems with
> kernel 4.10.x, whereas my problem did not appear until 4.11.
Close. Actually that patch touches code you are not using (oa-perf and
gvt), the real culprit was e8a9c58fcd9a ("drm/i915: Unify active context
tracking between legacy/execlists/guc").
The fix
commit 5d4bac5503fcc67dd7999571e243cee49371aef7
Author: Chris Wilson
Date: Wed Mar 22 20:59:30 2017 +
drm/i915: Restore marking context objects as dirty on pinning
Commit e8a9c58fcd9a ("drm/i915: Unify active context tracking between
legacy/execlists/guc") converted the legacy intel_ringbuffer submission
to the same context pinning mechanism as execlists - that is to pin the
context until the subsequent request is retired. Previously it used the
vma retirement of the context object to keep itself pinned until the
next request (after i915_vma_move_to_active()). In the conversion, I
missed that the vma retirement was also responsible for marking the
object as dirty. Mark the context object as dirty when pinning
(equivalent to execlists) which ensures that if the context is swapped
out due to mempressure or suspend/hibernation, when it is loaded back in
it does so with the previous state (and not all zero).
Fixes: e8a9c58fcd9a ("drm/i915: Unify active context tracking between
legacy/execlists/guc")
Reported-by: Dennis Gilmore
Reported-by: Mathieu Marquer
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=3
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100181
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v4.11-rc1
Link:
http://patchwork.freedesktop.org/patch/msgid/20170322205930.12762-1-ch...@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin
went in this morning and so will be upstreamed ~next week.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: expose _SUBSLICE_MASK GETPARM
On 23 March 2017 at 20:18, Robert Bragg wrote: > Assuming a uniform mask across all slices, this enables userspace to > determine the specific sub slices enabled. This information is required, > for example, to be able to analyse some OA counter reports where the > counter configuration depends on the HW sub slice configuration. > > Signed-off-by: Robert Bragg Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/5] drm/i915: expose _SLICE_MASK GETPARM
On 23 March 2017 at 20:18, Robert Bragg wrote: > Enables userspace to determine the number of slices enabled and also > know what specific slices are enabled. This information is required, for > example, to be able to analyse some OA counter reports where the counter > configuration depends on the HW slice configuration. > > Signed-off-by: Robert Bragg Assuming you remember to update the 45 when landing: Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/5] drm/i915: Add OA unit support for Gen 8+
Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all
share (more-or-less) the same OA unit design.
Of particular note in comparison to Haswell: some OA unit HW config
state has become per-context state and as a consequence it is somewhat
more complicated to manage synchronous state changes from the cpu while
there's no guarantee of what context (if any) is currently actively
running on the gpu.
The periodic sampling frequency which can be particularly useful for
system-wide analysis (as opposed to command stream synchronised
MI_REPORT_PERF_COUNT commands) is perhaps the most surprising state to
have become per-context save and restored (while the OABUFFER
destination is still a shared, system-wide resource).
This support for gen8+ takes care to consider a number of timing
challenges involved in synchronously updating per-context state
primarily by programming all config state from the cpu and updating all
current and saved contexts synchronously while the OA unit is still
disabled.
The driver intentionally avoids depending on command streamer
programming to update OA state considering the lack of synchronization
between the automatic loading of OACTXCONTROL state (that includes the
periodic sampling state and enable state) on context restore and the
parsing of any general purpose BB the driver can control. I.e. this
implementation is careful to avoid the possibility of a context restore
temporarily enabling any out-of-date periodic sampling state. In
addition to the risk of transiently-out-of-date state being loaded
automatically; there are also internal HW latencies involved in the
loading of MUX configurations which would be difficult to account for
from the command streamer (and we only want to enable the unit when once
the MUX configuration is complete).
Since the Gen8+ OA unit design no longer supports clock gating the unit
off for a single given context (which effectively stopped any progress
of counters while any other context was running) and instead supports
tagging OA reports with a context ID for filtering on the CPU, it means
we can no longer hide the system-wide progress of counters from a
non-privileged application only interested in metrics for its own
context. Although we could theoretically try and subtract the progress
of other contexts before forwarding reports via read() we aren't in a
position to filter reports captured via MI_REPORT_PERF_COUNT commands.
As a result, for Gen8+, we always require the
dev.i915.perf_stream_paranoid to be unset for any access to OA metrics
if not root.
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_drv.h | 29 +-
drivers/gpu/drm/i915/i915_gem_context.h |1 +
drivers/gpu/drm/i915/i915_perf.c| 1034 ---
drivers/gpu/drm/i915/i915_reg.h | 22 +
drivers/gpu/drm/i915/intel_lrc.c|5 +
include/uapi/drm/i915_drm.h | 19 +-
6 files changed, 1029 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c4156a8a5dc0..190e699d5851 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -731,6 +731,7 @@ intel_uncore_forcewake_for_reg(struct drm_i915_private
*dev_priv,
i915_reg_t reg, unsigned int op);
struct intel_uncore_funcs {
+ int (*wait_for_rcs_busy)(struct drm_i915_private *dev_priv);
void (*force_wake_get)(struct drm_i915_private *dev_priv,
enum forcewake_domains domains);
void (*force_wake_put)(struct drm_i915_private *dev_priv,
@@ -2084,9 +2085,17 @@ struct i915_oa_ops {
void (*init_oa_buffer)(struct drm_i915_private *dev_priv);
/**
-* @enable_metric_set: Applies any MUX configuration to set up the
-* Boolean and Custom (B/C) counters that are part of the counter
-* reports being sampled. May apply system constraints such as
+* @select_metric_set: The auto generated code that checks whether a
+* requested OA config is applicable to the system and if so sets up
+* the mux, oa and flex eu register config pointers according to the
+* current dev_priv->perf.oa.metrics_set.
+*/
+ int (*select_metric_set)(struct drm_i915_private *dev_priv);
+
+ /**
+* @enable_metric_set: Selects and applies any MUX configuration to set
+* up the Boolean and Custom (B/C) counters that are part of the
+* counter reports being sampled. May apply system constraints such as
* disabling EU clock gating as required.
*/
int (*enable_metric_set)(struct drm_i915_private *dev_priv);
@@ -2492,6 +2501,7 @@ struct drm_i915_private {
struct {
struct i915_vma *vma;
u8 *vaddr;
+ u32 last_ctx_id;
int format;
[Intel-gfx] [PATCH v2 3/5] drm/i915: Add 'render basic' Gen8+ OA unit configs
Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic
render metrics on Broadwell, Cherryview, Skylake and Broxton. These are
auto generated from an XML description of metric sets, currently
maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scripts/i915-perf-kernelgen.py
$ make -C gputop-data -f Makefile.xml WHITELIST=RenderBasic
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/Makefile | 8 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_oa_bdw.c| 380 ++
drivers/gpu/drm/i915/i915_oa_bdw.h| 38
drivers/gpu/drm/i915/i915_oa_bxt.c| 238 +
drivers/gpu/drm/i915/i915_oa_bxt.h| 38
drivers/gpu/drm/i915/i915_oa_chv.c| 225
drivers/gpu/drm/i915/i915_oa_chv.h| 38
drivers/gpu/drm/i915/i915_oa_sklgt2.c | 228
drivers/gpu/drm/i915/i915_oa_sklgt2.h | 38
drivers/gpu/drm/i915/i915_oa_sklgt3.c | 236 +
drivers/gpu/drm/i915/i915_oa_sklgt3.h | 38
drivers/gpu/drm/i915/i915_oa_sklgt4.c | 247 ++
drivers/gpu/drm/i915/i915_oa_sklgt4.h | 38
14 files changed, 1791 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2cf04504e494..41400a138a1e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -127,7 +127,13 @@ i915-y += i915_vgpu.o
# perf code
i915-y += i915_perf.o \
- i915_oa_hsw.o
+ i915_oa_hsw.o \
+ i915_oa_bdw.o \
+ i915_oa_chv.o \
+ i915_oa_sklgt2.o \
+ i915_oa_sklgt3.o \
+ i915_oa_sklgt4.o \
+ i915_oa_bxt.o
ifeq ($(CONFIG_DRM_I915_GVT),y)
i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a7986c0c29ad..c4156a8a5dc0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2486,6 +2486,8 @@ struct drm_i915_private {
int mux_regs_len;
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
+ const struct i915_oa_reg *flex_regs;
+ int flex_regs_len;
struct {
struct i915_vma *vma;
diff --git a/drivers/gpu/drm/i915/i915_oa_bdw.c
b/drivers/gpu/drm/i915/i915_oa_bdw.c
new file mode 100644
index ..539484aef6b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_bdw.c
@@ -0,0 +1,380 @@
+/*
+ * Autogenerated file, DO NOT EDIT manually!
+ *
+ * Copyright (c) 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
+
+#include "i915_drv.h"
+#include "i915_oa_bdw.h"
+
+enum metric_set_id {
+ METRIC_SET_ID_RENDER_BASIC = 1,
+};
+
+int i915_oa_n_builtin_metric_sets_bdw = 1;
+
+static const struct i915_oa_reg b_counter_config_render_basic[] = {
+ { _MMIO(0x2710), 0x },
+ { _MMIO(0x2714), 0x0080 },
+ { _MMIO(0x2720), 0x },
+ { _MMIO(0x2724), 0x0080 },
+ { _MMIO(0x2740), 0x },
+};
+
+stati
[Intel-gfx] [PATCH v2 2/5] drm/i915: expose _SUBSLICE_MASK GETPARM
Assuming a uniform mask across all slices, this enables userspace to
determine the specific sub slices enabled. This information is required,
for example, to be able to analyse some OA counter reports where the
counter configuration depends on the HW sub slice configuration.
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_drv.c | 5 +
include/uapi/drm/i915_drm.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ad12ffc356be..c39a03c1f78d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -362,6 +362,11 @@ static int i915_getparam(struct drm_device *dev, void
*data,
if (!value)
return -ENODEV;
break;
+ case I915_PARAM_SUBSLICE_MASK:
+ value = INTEL_INFO(dev_priv)->sseu.subslice_mask;
+ if (!value)
+ return -ENODEV;
+ break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index f47fb7f26f36..e0599e729e68 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -393,6 +393,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_MIN_EU_IN_POOL 39
#define I915_PARAM_MMAP_GTT_VERSION 40
#define I915_PARAM_SLICE_MASK 45 /* XXX: rebase before landing */
+#define I915_PARAM_SUBSLICE_MASK46
/* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
* priorities and the driver will attempt to execute batches in priority order.
--
2.12.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/5] drm/i915: expose _SLICE_MASK GETPARM
Enables userspace to determine the number of slices enabled and also
know what specific slices are enabled. This information is required, for
example, to be able to analyse some OA counter reports where the counter
configuration depends on the HW slice configuration.
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_drv.c | 5 +
include/uapi/drm/i915_drm.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6d9944a00b7d..ad12ffc356be 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -357,6 +357,11 @@ static int i915_getparam(struct drm_device *dev, void
*data,
*/
value = 1;
break;
+ case I915_PARAM_SLICE_MASK:
+ value = INTEL_INFO(dev_priv)->sseu.slice_mask;
+ if (!value)
+ return -ENODEV;
+ break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3554495bef13..f47fb7f26f36 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -392,6 +392,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_POOLED_EU38
#define I915_PARAM_MIN_EU_IN_POOL 39
#define I915_PARAM_MMAP_GTT_VERSION 40
+#define I915_PARAM_SLICE_MASK 45 /* XXX: rebase before landing */
/* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
* priorities and the driver will attempt to execute batches in priority order.
--
2.12.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/5] Enable OA unit for Gen 8 and 9 in i915 perf
Compared to the last Gen8+ OA series I've been investigating and debugging a number of issues with the configuration of the Flexible EU counters whose state is per-context: * Removes assumption about the mmio registers having a contiguous range of addresses which wasn't true. * Ensures that newly allocated contexts (while the OA unit is in use) will have their OA state properly initialized. * Makes sure to only update render context state. Instead of attempting to have a general purpose uncore api for dealing with the details of allowing mmio writes to per-context registers this just adds a constrained utility in i915_perf.c itself. The per-gen initialization/configuration has been reworked to avoid a lot of copy and paste boilerplate. Addresses the codegen issue Matt noticed with the Broadwell ComputeExtended metric set after checking with the authors of the XML files that the second unconditional MUX config should affectively be appended to the end of all the conditional configs. (as with the last gen8+ series I sent, it's based on the various gen7 prep patches that have been sent out separately) These patches can be pulled from my wip/rib/oa-next branch here: https://github.com/rib/linux In case anyone wants to take a look at the IGT tests so far they can be found here: https://github.com/rib/intel-gpu-tools/commits/wip/rib/i915-perf-tests Regards, - Robert Robert Bragg (5): drm/i915: expose _SLICE_MASK GETPARM drm/i915: expose _SUBSLICE_MASK GETPARM drm/i915: Add 'render basic' Gen8+ OA unit configs drm/i915: Add OA unit support for Gen 8+ drm/i915: Add more OA configs for BDW, CHV, SKL + BXT drivers/gpu/drm/i915/Makefile |8 +- drivers/gpu/drm/i915/i915_drv.c | 10 + drivers/gpu/drm/i915/i915_drv.h | 31 +- drivers/gpu/drm/i915/i915_gem_context.h |1 + drivers/gpu/drm/i915/i915_oa_bdw.c | 5154 +++ drivers/gpu/drm/i915/i915_oa_bdw.h | 38 + drivers/gpu/drm/i915/i915_oa_bxt.c | 2541 +++ drivers/gpu/drm/i915/i915_oa_bxt.h | 38 + drivers/gpu/drm/i915/i915_oa_chv.c | 2730 drivers/gpu/drm/i915/i915_oa_chv.h | 38 + drivers/gpu/drm/i915/i915_oa_hsw.c | 58 +- drivers/gpu/drm/i915/i915_oa_sklgt2.c | 3303 drivers/gpu/drm/i915/i915_oa_sklgt2.h | 38 + drivers/gpu/drm/i915/i915_oa_sklgt3.c | 2856 + drivers/gpu/drm/i915/i915_oa_sklgt3.h | 38 + drivers/gpu/drm/i915/i915_oa_sklgt4.c | 2910 + drivers/gpu/drm/i915/i915_oa_sklgt4.h | 38 + drivers/gpu/drm/i915/i915_perf.c| 1034 ++- drivers/gpu/drm/i915/i915_reg.h | 22 + drivers/gpu/drm/i915/intel_lrc.c|5 + include/uapi/drm/i915_drm.h | 21 +- 21 files changed, 20825 insertions(+), 87 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.c create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.h create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.c create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.h create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.c create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.h create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.c create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.h create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.c create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.h create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.c create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.h -- 2.12.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/i915: Use i9xx_check_plane_surface() for sprite planes as well
From: Ville Syrjälä
All the pre-SKL sprite planes compute the x/y/tile offsets in a
similar way. There are a couple of minor differences but the primary
planes have those as well. Thus i9xx_check_plane_surface()
already does what we need, so let's use it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_sprite.c | 71 +---
3 files changed, 27 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 73aeb2405a16..6dc75552c753 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3026,7 +3026,7 @@ static u32 i9xx_plane_ctl(const struct intel_crtc_state
*crtc_state,
return dspcntr;
}
-static int i9xx_check_plane_surface(struct intel_plane_state *plane_state)
+int i9xx_check_plane_surface(struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv =
to_i915(plane_state->base.plane->dev);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a35442eadd36..15e3eb2824e3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1453,6 +1453,7 @@ u32 skl_plane_ctl(const struct intel_crtc_state
*crtc_state,
u32 skl_plane_stride(const struct drm_framebuffer *fb, int plane,
unsigned int rotation);
int skl_check_plane_surface(struct intel_plane_state *plane_state);
+int i9xx_check_plane_surface(struct intel_plane_state *plane_state);
/* intel_csr.c */
void intel_csr_ucode_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 6b76012ded1a..f7d431427115 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -419,35 +419,21 @@ vlv_update_plane(struct drm_plane *dplane,
enum pipe pipe = intel_plane->pipe;
enum plane_id plane_id = intel_plane->id;
u32 sprctl = plane_state->ctl;
- u32 sprsurf_offset, linear_offset;
- unsigned int rotation = plane_state->base.rotation;
+ u32 sprsurf_offset = plane_state->main.offset;
+ u32 linear_offset;
const struct drm_intel_sprite_colorkey *key = &plane_state->ckey;
int crtc_x = plane_state->base.dst.x1;
int crtc_y = plane_state->base.dst.y1;
uint32_t crtc_w = drm_rect_width(&plane_state->base.dst);
uint32_t crtc_h = drm_rect_height(&plane_state->base.dst);
- uint32_t x = plane_state->base.src.x1 >> 16;
- uint32_t y = plane_state->base.src.y1 >> 16;
- uint32_t src_w = drm_rect_width(&plane_state->base.src) >> 16;
- uint32_t src_h = drm_rect_height(&plane_state->base.src) >> 16;
+ uint32_t x = plane_state->main.x;
+ uint32_t y = plane_state->main.y;
unsigned long irqflags;
/* Sizes are 0 based */
- src_w--;
- src_h--;
crtc_w--;
crtc_h--;
- intel_add_fb_offsets(&x, &y, plane_state, 0);
- sprsurf_offset = intel_compute_tile_offset(&x, &y, plane_state, 0);
-
- if (rotation & DRM_ROTATE_180) {
- x += src_w;
- y += src_h;
- } else if (rotation & DRM_REFLECT_X) {
- x += src_w;
- }
-
linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
@@ -566,15 +552,15 @@ ivb_update_plane(struct drm_plane *plane,
struct drm_framebuffer *fb = plane_state->base.fb;
enum pipe pipe = intel_plane->pipe;
u32 sprctl = plane_state->ctl, sprscale = 0;
- u32 sprsurf_offset, linear_offset;
- unsigned int rotation = plane_state->base.rotation;
+ u32 sprsurf_offset = plane_state->main.offset;
+ u32 linear_offset;
const struct drm_intel_sprite_colorkey *key = &plane_state->ckey;
int crtc_x = plane_state->base.dst.x1;
int crtc_y = plane_state->base.dst.y1;
uint32_t crtc_w = drm_rect_width(&plane_state->base.dst);
uint32_t crtc_h = drm_rect_height(&plane_state->base.dst);
- uint32_t x = plane_state->base.src.x1 >> 16;
- uint32_t y = plane_state->base.src.y1 >> 16;
+ uint32_t x = plane_state->main.x;
+ uint32_t y = plane_state->main.y;
uint32_t src_w = drm_rect_width(&plane_state->base.src) >> 16;
uint32_t src_h = drm_rect_height(&plane_state->base.src) >> 16;
unsigned long irqflags;
@@ -588,16 +574,6 @@ ivb_update_plane(struct drm_plane *plane,
if (crtc_w != src_w || crtc_h != src_h)
sprscale = SPRITE_SCALE_ENABLE | (src_w << 16) | src_h;
- intel_add_fb_offsets(&x, &y, plane_state, 0);
- sprsurf_offset = intel_compute_tile_offset(&x, &y, plane_state, 0);
-
- /* HSW+ does this automagically in hardware */
- if (!IS_HASWELL(dev_pr
[Intel-gfx] [PATCH v2 4/6] drm/i915: Introduce i9xx_check_plane_surface()
From: Ville Syrjälä
Extract the primary plane surfae offset/x/y calculations for
pre-SKL platforms into a common function, and call it during the
atomic check phase to reduce the amount of stuff we have to do
during the commit phase. SKL is already doing this.
v2: Update the comment about the rotation adjustments to
match the code better (Chris)
Cc: Chris Wilson
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 82 ++--
1 file changed, 50 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index def3dfea0ffe..95b5f8cc14fa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3026,6 +3026,43 @@ static u32 i9xx_plane_ctl(const struct intel_crtc_state
*crtc_state,
return dspcntr;
}
+static int i9xx_check_plane_surface(struct intel_plane_state *plane_state)
+{
+ struct drm_i915_private *dev_priv =
+ to_i915(plane_state->base.plane->dev);
+ int src_x = plane_state->base.src.x1 >> 16;
+ int src_y = plane_state->base.src.y1 >> 16;
+ u32 offset;
+
+ intel_add_fb_offsets(&src_x, &src_y, plane_state, 0);
+
+ if (INTEL_GEN(dev_priv) >= 4)
+ offset = intel_compute_tile_offset(&src_x, &src_y,
+ plane_state, 0);
+ else
+ offset = 0;
+
+ /* HSW/BDW do this automagically in hardware */
+ if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv)) {
+ unsigned int rotation = plane_state->base.rotation;
+ int src_w = drm_rect_width(&plane_state->base.src) >> 16;
+ int src_h = drm_rect_height(&plane_state->base.src) >> 16;
+
+ if (rotation & DRM_ROTATE_180) {
+ src_x += src_w - 1;
+ src_y += src_h - 1;
+ } else if (rotation & DRM_REFLECT_X) {
+ src_x += src_w - 1;
+ }
+ }
+
+ plane_state->main.offset = offset;
+ plane_state->main.x = src_x;
+ plane_state->main.y = src_y;
+
+ return 0;
+}
+
static void i9xx_update_primary_plane(struct drm_plane *primary,
const struct intel_crtc_state *crtc_state,
const struct intel_plane_state
*plane_state)
@@ -3037,27 +3074,15 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
u32 linear_offset;
u32 dspcntr = plane_state->ctl;
i915_reg_t reg = DSPCNTR(plane);
- unsigned int rotation = plane_state->base.rotation;
- int x = plane_state->base.src.x1 >> 16;
- int y = plane_state->base.src.y1 >> 16;
+ int x = plane_state->main.x;
+ int y = plane_state->main.y;
unsigned long irqflags;
- intel_add_fb_offsets(&x, &y, plane_state, 0);
-
- if (INTEL_GEN(dev_priv) >= 4)
- intel_crtc->dspaddr_offset =
- intel_compute_tile_offset(&x, &y, plane_state, 0);
-
- if (rotation & DRM_ROTATE_180) {
- x += crtc_state->pipe_src_w - 1;
- y += crtc_state->pipe_src_h - 1;
- } else if (rotation & DRM_REFLECT_X) {
- x += crtc_state->pipe_src_w - 1;
- }
-
linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
- if (INTEL_GEN(dev_priv) < 4)
+ if (INTEL_GEN(dev_priv) >= 4)
+ intel_crtc->dspaddr_offset = plane_state->main.offset;
+ else
intel_crtc->dspaddr_offset = linear_offset;
intel_crtc->adjusted_x = x;
@@ -3133,25 +3158,14 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
u32 linear_offset;
u32 dspcntr = plane_state->ctl;
i915_reg_t reg = DSPCNTR(plane);
- unsigned int rotation = plane_state->base.rotation;
- int x = plane_state->base.src.x1 >> 16;
- int y = plane_state->base.src.y1 >> 16;
+ int x = plane_state->main.x;
+ int y = plane_state->main.y;
unsigned long irqflags;
- intel_add_fb_offsets(&x, &y, plane_state, 0);
-
- intel_crtc->dspaddr_offset =
- intel_compute_tile_offset(&x, &y, plane_state, 0);
-
- /* HSW+ does this automagically in hardware */
- if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv) &&
- rotation & DRM_ROTATE_180) {
- x += crtc_state->pipe_src_w - 1;
- y += crtc_state->pipe_src_h - 1;
- }
-
linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
+ intel_crtc->dspaddr_offset = plane_state->main.offset;
+
intel_crtc->adjusted_x = x;
intel_crtc->adjusted_y = y;
@@ -13365,6 +13379,10 @@ intel_check_primary_plane(struct drm_plane *plane,
state->ctl = skl_plane_ctl(crtc_state, state);
} else {
+
[Intel-gfx] [PATCH 3/6] drm/i915: Pre-compute plane control register value
From: Ville Syrjälä
Computing the plane control register value is branchy so moving it out
from the plane commit hook seems prudent. Let's pre-compute it during
the atomic check phase and store the result in the plane state.
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 41 ++--
drivers/gpu/drm/i915/intel_drv.h | 3 +++
drivers/gpu/drm/i915/intel_sprite.c | 24 ++---
3 files changed, 36 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4f57ce982a72..def3dfea0ffe 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3035,15 +3035,13 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
struct drm_framebuffer *fb = plane_state->base.fb;
int plane = intel_crtc->plane;
u32 linear_offset;
- u32 dspcntr;
+ u32 dspcntr = plane_state->ctl;
i915_reg_t reg = DSPCNTR(plane);
unsigned int rotation = plane_state->base.rotation;
int x = plane_state->base.src.x1 >> 16;
int y = plane_state->base.src.y1 >> 16;
unsigned long irqflags;
- dspcntr = i9xx_plane_ctl(crtc_state, plane_state);
-
intel_add_fb_offsets(&x, &y, plane_state, 0);
if (INTEL_GEN(dev_priv) >= 4)
@@ -3133,15 +3131,13 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
struct drm_framebuffer *fb = plane_state->base.fb;
int plane = intel_crtc->plane;
u32 linear_offset;
- u32 dspcntr;
+ u32 dspcntr = plane_state->ctl;
i915_reg_t reg = DSPCNTR(plane);
unsigned int rotation = plane_state->base.rotation;
int x = plane_state->base.src.x1 >> 16;
int y = plane_state->base.src.y1 >> 16;
unsigned long irqflags;
- dspcntr = i9xx_plane_ctl(crtc_state, plane_state);
-
intel_add_fb_offsets(&x, &y, plane_state, 0);
intel_crtc->dspaddr_offset =
@@ -3358,7 +3354,7 @@ static void skylake_update_primary_plane(struct drm_plane
*plane,
struct drm_framebuffer *fb = plane_state->base.fb;
enum plane_id plane_id = to_intel_plane(plane)->id;
enum pipe pipe = to_intel_plane(plane)->pipe;
- u32 plane_ctl;
+ u32 plane_ctl = plane_state->ctl;
unsigned int rotation = plane_state->base.rotation;
u32 stride = skl_plane_stride(fb, 0, rotation);
u32 surf_addr = plane_state->main.offset;
@@ -3373,8 +3369,6 @@ static void skylake_update_primary_plane(struct drm_plane
*plane,
int dst_h = drm_rect_height(&plane_state->base.dst);
unsigned long irqflags;
- plane_ctl = skl_plane_ctl(crtc_state, plane_state);
-
/* Sizes are 0 based */
src_w--;
src_h--;
@@ -9187,7 +9181,6 @@ static u32 i845_cursor_ctl(const struct intel_crtc_state
*crtc_state,
}
static void i845_update_cursor(struct drm_crtc *crtc, u32 base,
- const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state)
{
struct drm_device *dev = crtc->dev;
@@ -9199,7 +9192,7 @@ static void i845_update_cursor(struct drm_crtc *crtc, u32
base,
unsigned int width = plane_state->base.crtc_w;
unsigned int height = plane_state->base.crtc_h;
- cntl = i845_cursor_ctl(crtc_state, plane_state);
+ cntl = plane_state->ctl;
size = (height << 12) | width;
}
@@ -9270,7 +9263,6 @@ static u32 i9xx_cursor_ctl(const struct intel_crtc_state
*crtc_state,
}
static void i9xx_update_cursor(struct drm_crtc *crtc, u32 base,
- const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state)
{
struct drm_device *dev = crtc->dev;
@@ -9280,7 +9272,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32
base,
uint32_t cntl = 0;
if (plane_state && plane_state->base.visible)
- cntl = i9xx_cursor_ctl(crtc_state, plane_state);
+ cntl = plane_state->ctl;
if (intel_crtc->cursor_cntl != cntl) {
I915_WRITE_FW(CURCNTR(pipe), cntl);
@@ -9297,7 +9289,6 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32
base,
/* If no-part of the cursor is visible on the framebuffer, then the GPU may
hang... */
static void intel_crtc_update_cursor(struct drm_crtc *crtc,
-const struct intel_crtc_state *crtc_state,
const struct intel_plane_state
*plane_state)
{
struct drm_device *dev = crtc->dev;
@@ -9337,9 +9328,9 @@ static void intel_crtc_update_cursor(struct drm_crtc
*crtc,
I915_WRITE_FW(CURPOS(pipe), pos);
if (IS_I845G(dev_priv) || IS_I865G(dev_priv))
-
[Intel-gfx] [PATCH 5/6] drm/i915: Eliminate ironlake_update_primary_plane()
From: Ville Syrjälä
The effective difference between i9xx_update_primary_plane()
and ironlake_update_primary_plane() is only the HSW/BDW
DSPOFFSET special case. So bring that over into
i9xx_update_primary_plane() and eliminate the duplicated code.
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 55
1 file changed, 6 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 95b5f8cc14fa..73aeb2405a16 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3109,7 +3109,12 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
I915_WRITE_FW(reg, dspcntr);
I915_WRITE_FW(DSPSTRIDE(plane), fb->pitches[0]);
- if (INTEL_GEN(dev_priv) >= 4) {
+ if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
+ I915_WRITE_FW(DSPSURF(plane),
+ intel_plane_ggtt_offset(plane_state) +
+ intel_crtc->dspaddr_offset);
+ I915_WRITE_FW(DSPOFFSET(plane), (y << 16) | x);
+ } else if (INTEL_GEN(dev_priv) >= 4) {
I915_WRITE_FW(DSPSURF(plane),
intel_plane_ggtt_offset(plane_state) +
intel_crtc->dspaddr_offset);
@@ -3146,48 +3151,6 @@ static void i9xx_disable_primary_plane(struct drm_plane
*primary,
spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
}
-static void ironlake_update_primary_plane(struct drm_plane *primary,
- const struct intel_crtc_state
*crtc_state,
- const struct intel_plane_state
*plane_state)
-{
- struct drm_device *dev = primary->dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
- struct drm_framebuffer *fb = plane_state->base.fb;
- int plane = intel_crtc->plane;
- u32 linear_offset;
- u32 dspcntr = plane_state->ctl;
- i915_reg_t reg = DSPCNTR(plane);
- int x = plane_state->main.x;
- int y = plane_state->main.y;
- unsigned long irqflags;
-
- linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
-
- intel_crtc->dspaddr_offset = plane_state->main.offset;
-
- intel_crtc->adjusted_x = x;
- intel_crtc->adjusted_y = y;
-
- spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
-
- I915_WRITE_FW(reg, dspcntr);
-
- I915_WRITE_FW(DSPSTRIDE(plane), fb->pitches[0]);
- I915_WRITE_FW(DSPSURF(plane),
- intel_plane_ggtt_offset(plane_state) +
- intel_crtc->dspaddr_offset);
- if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
- I915_WRITE_FW(DSPOFFSET(plane), (y << 16) | x);
- } else {
- I915_WRITE_FW(DSPTILEOFF(plane), (y << 16) | x);
- I915_WRITE_FW(DSPLINOFF(plane), linear_offset);
- }
- POSTING_READ_FW(reg);
-
- spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
-}
-
static u32
intel_fb_stride_alignment(const struct drm_framebuffer *fb, int plane)
{
@@ -13642,12 +13605,6 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
primary->update_plane = skylake_update_primary_plane;
primary->disable_plane = skylake_disable_primary_plane;
- } else if (HAS_PCH_SPLIT(dev_priv)) {
- intel_primary_formats = i965_primary_formats;
- num_formats = ARRAY_SIZE(i965_primary_formats);
-
- primary->update_plane = ironlake_update_primary_plane;
- primary->disable_plane = i9xx_disable_primary_plane;
} else if (INTEL_GEN(dev_priv) >= 4) {
intel_primary_formats = i965_primary_formats;
num_formats = ARRAY_SIZE(i965_primary_formats);
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915: Nuke ironlake_plane_ctl()
From: Ville Syrjälä
Share the code to compute the primary plane control register value
between the i9xx and ilk codepaths as the differences are minimal.
Actually there are no differences between g4x and ilk, so the
current split doesn't really make any sense.
Cc: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 58
1 file changed, 6 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index aa2c85b2bf78..4f57ce982a72 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2974,9 +2974,13 @@ static u32 i9xx_plane_ctl(const struct intel_crtc_state
*crtc_state,
dspcntr = DISPLAY_PLANE_ENABLE | DISPPLANE_GAMMA_ENABLE;
- if (IS_G4X(dev_priv))
+ if (IS_G4X(dev_priv) || IS_GEN5(dev_priv) ||
+ IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
+ if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
+ dspcntr |= DISPPLANE_PIPE_CSC_ENABLE;
+
if (INTEL_GEN(dev_priv) < 4) {
if (crtc->pipe == PIPE_B)
dspcntr |= DISPPLANE_SEL_PIPE_B;
@@ -3119,56 +3123,6 @@ static void i9xx_disable_primary_plane(struct drm_plane
*primary,
spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
}
-static u32 ironlake_plane_ctl(const struct intel_crtc_state *crtc_state,
- const struct intel_plane_state *plane_state)
-{
- struct drm_i915_private *dev_priv =
- to_i915(plane_state->base.plane->dev);
- const struct drm_framebuffer *fb = plane_state->base.fb;
- unsigned int rotation = plane_state->base.rotation;
- u32 dspcntr;
-
- dspcntr = DISPLAY_PLANE_ENABLE | DISPPLANE_GAMMA_ENABLE;
-
- if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv))
- dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
-
- if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
- dspcntr |= DISPPLANE_PIPE_CSC_ENABLE;
-
- switch (fb->format->format) {
- case DRM_FORMAT_C8:
- dspcntr |= DISPPLANE_8BPP;
- break;
- case DRM_FORMAT_RGB565:
- dspcntr |= DISPPLANE_BGRX565;
- break;
- case DRM_FORMAT_XRGB:
- dspcntr |= DISPPLANE_BGRX888;
- break;
- case DRM_FORMAT_XBGR:
- dspcntr |= DISPPLANE_RGBX888;
- break;
- case DRM_FORMAT_XRGB2101010:
- dspcntr |= DISPPLANE_BGRX101010;
- break;
- case DRM_FORMAT_XBGR2101010:
- dspcntr |= DISPPLANE_RGBX101010;
- break;
- default:
- MISSING_CASE(fb->format->format);
- return 0;
- }
-
- if (fb->modifier == I915_FORMAT_MOD_X_TILED)
- dspcntr |= DISPPLANE_TILED;
-
- if (rotation & DRM_ROTATE_180)
- dspcntr |= DISPPLANE_ROTATE_180;
-
- return dspcntr;
-}
-
static void ironlake_update_primary_plane(struct drm_plane *primary,
const struct intel_crtc_state
*crtc_state,
const struct intel_plane_state
*plane_state)
@@ -3186,7 +3140,7 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
int y = plane_state->base.src.y1 >> 16;
unsigned long irqflags;
- dspcntr = ironlake_plane_ctl(crtc_state, plane_state);
+ dspcntr = i9xx_plane_ctl(crtc_state, plane_state);
intel_add_fb_offsets(&x, &y, plane_state, 0);
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/6] drm/i915: Moar plane update optimizations (v2)
From: Ville Syrjälä Here are the easy leftovers from the previous series. I left out the more experimental parts (single lock/unlock, posting read elimination) for now. I'll have to revisit those after we get this stuff in. This time I even took the precaution of testing this on one of my gen2 machines. Still seemed to work correctly, so apparently I didn't mess up anything with the tile vs. linear offset stuff. Ville Syrjälä (6): drm/i915: Extract i9xx_plane_ctl() and ironlake_plane_ctl() drm/i915: Nuke ironlake_plane_ctl() drm/i915: Pre-compute plane control register value drm/i915: Introduce i9xx_check_plane_surface() drm/i915: Eliminate ironlake_update_primary_plane() drm/i915: Use i9xx_check_plane_surface() for sprite planes as well drivers/gpu/drm/i915/intel_display.c | 238 +++ drivers/gpu/drm/i915/intel_drv.h | 4 + drivers/gpu/drm/i915/intel_sprite.c | 93 ++ 3 files changed, 138 insertions(+), 197 deletions(-) -- 2.10.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/6] drm/i915: Extract i9xx_plane_ctl() and ironlake_plane_ctl()
From: Ville Syrjälä
Pull the code to calculate the pre-SKL primary plane control register
value into separate functions. Allows us to pre-compute it in the
future.
v2: Split the pre-ilk vs. ilk+ unification to a separate patch (Chris)
Cc: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 104 ++-
1 file changed, 66 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9a28a8917dc1..aa2c85b2bf78 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2962,28 +2962,23 @@ int skl_check_plane_surface(struct intel_plane_state
*plane_state)
return 0;
}
-static void i9xx_update_primary_plane(struct drm_plane *primary,
- const struct intel_crtc_state *crtc_state,
- const struct intel_plane_state
*plane_state)
+static u32 i9xx_plane_ctl(const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
{
- struct drm_i915_private *dev_priv = to_i915(primary->dev);
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
- struct drm_framebuffer *fb = plane_state->base.fb;
- int plane = intel_crtc->plane;
- u32 linear_offset;
- u32 dspcntr;
- i915_reg_t reg = DSPCNTR(plane);
+ struct drm_i915_private *dev_priv =
+ to_i915(plane_state->base.plane->dev);
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ const struct drm_framebuffer *fb = plane_state->base.fb;
unsigned int rotation = plane_state->base.rotation;
- int x = plane_state->base.src.x1 >> 16;
- int y = plane_state->base.src.y1 >> 16;
- unsigned long irqflags;
+ u32 dspcntr;
- dspcntr = DISPPLANE_GAMMA_ENABLE;
+ dspcntr = DISPLAY_PLANE_ENABLE | DISPPLANE_GAMMA_ENABLE;
- dspcntr |= DISPLAY_PLANE_ENABLE;
+ if (IS_G4X(dev_priv))
+ dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
if (INTEL_GEN(dev_priv) < 4) {
- if (intel_crtc->pipe == PIPE_B)
+ if (crtc->pipe == PIPE_B)
dspcntr |= DISPPLANE_SEL_PIPE_B;
}
@@ -3010,7 +3005,8 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
dspcntr |= DISPPLANE_RGBX101010;
break;
default:
- BUG();
+ MISSING_CASE(fb->format->format);
+ return 0;
}
if (INTEL_GEN(dev_priv) >= 4 &&
@@ -3023,8 +3019,26 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
if (rotation & DRM_REFLECT_X)
dspcntr |= DISPPLANE_MIRROR;
- if (IS_G4X(dev_priv))
- dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
+ return dspcntr;
+}
+
+static void i9xx_update_primary_plane(struct drm_plane *primary,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state
*plane_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(primary->dev);
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_framebuffer *fb = plane_state->base.fb;
+ int plane = intel_crtc->plane;
+ u32 linear_offset;
+ u32 dspcntr;
+ i915_reg_t reg = DSPCNTR(plane);
+ unsigned int rotation = plane_state->base.rotation;
+ int x = plane_state->base.src.x1 >> 16;
+ int y = plane_state->base.src.y1 >> 16;
+ unsigned long irqflags;
+
+ dspcntr = i9xx_plane_ctl(crtc_state, plane_state);
intel_add_fb_offsets(&x, &y, plane_state, 0);
@@ -3105,25 +3119,19 @@ static void i9xx_disable_primary_plane(struct drm_plane
*primary,
spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
}
-static void ironlake_update_primary_plane(struct drm_plane *primary,
- const struct intel_crtc_state
*crtc_state,
- const struct intel_plane_state
*plane_state)
+static u32 ironlake_plane_ctl(const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
{
- struct drm_device *dev = primary->dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
- struct drm_framebuffer *fb = plane_state->base.fb;
- int plane = intel_crtc->plane;
- u32 linear_offset;
- u32 dspcntr;
- i915_reg_t reg = DSPCNTR(plane);
+ struct drm_i915_private *dev_priv =
+ to_i915(plane_state->base.plane->dev);
+ const struct drm_framebuffer *fb = plane_state->base.fb;
unsigned int rotation = plane_state->base.rotation;
-
[Intel-gfx] [PATCH v2] drm/i915/perf: rate limit spurious oa report notice
This change is pre-emptively aiming to avoid a potential cause of kernel
logging noise in case some condition were to result in us seeing invalid
OA reports.
The workaround for the OA unit's tail pointer race condition is what
avoids the primary know cause of invalid reports being seen and with
that in place we aren't expecting to see this notice but it can't be
entirely ruled out.
Just in case some condition does lead to the notice then it's likely
that it will be triggered repeatedly while attempting to append a
sequence of reports and depending on the configured OA sampling
frequency that might be a large number of repeat notices.
v2: (Chris) avoid inconsistent warning on throttle with
printk_ratelimit()
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/i915_perf.c | 17 -
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a7b49cad6ab2..a7986c0c29ad 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2471,6 +2471,12 @@ struct drm_i915_private {
wait_queue_head_t poll_wq;
bool pollin;
+ /**
+* For rate limiting any notifications of spurious
+* invalid OA reports
+*/
+ struct ratelimit_state spurious_report_rs;
+
bool periodic;
int period_exponent;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c09a7c9b61d9..36d07ca68029 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -632,7 +632,8 @@ static int gen7_append_oa_reports(struct i915_perf_stream
*stream,
* copying it to userspace...
*/
if (report32[0] == 0) {
- DRM_NOTE("Skipping spurious, invalid OA report\n");
+ if (__ratelimit(&dev_priv->perf.oa.spurious_report_rs))
+ DRM_NOTE("Skipping spurious, invalid OA
report\n");
continue;
}
@@ -2144,6 +2145,15 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
if (!IS_HASWELL(dev_priv))
return;
+ /* Using the same limiting factors as printk_ratelimit() */
+ ratelimit_state_init(&dev_priv->perf.oa.spurious_report_rs,
+ 5 * HZ, 10);
+ /* We use a DRM_NOTE for spurious reports so it would be
+* inconsistent to print a warning for throttling.
+*/
+ ratelimit_set_flags(&dev_priv->perf.oa.spurious_report_rs,
+ RATELIMIT_MSG_ON_RELEASE);
+
hrtimer_init(&dev_priv->perf.oa.poll_check_timer,
CLOCK_MONOTONIC, HRTIMER_MODE_REL);
dev_priv->perf.oa.poll_check_timer.function = oa_poll_check_timer_cb;
@@ -2182,6 +2192,11 @@ void i915_perf_fini(struct drm_i915_private *dev_priv)
if (!dev_priv->perf.initialized)
return;
+ if (dev_priv->perf.oa.spurious_report_rs.missed) {
+ DRM_NOTE("%d spurious OA report notices suppressed due to
ratelimiting",
+dev_priv->perf.oa.spurious_report_rs.missed);
+ }
+
unregister_sysctl_table(dev_priv->perf.sysctl_header);
memset(&dev_priv->perf.oa.ops, 0, sizeof(dev_priv->perf.oa.ops));
--
2.12.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Replace literal tabs in ns2501 debug messages with spaces
From: Ville Syrjälä
Literal tabs in printk() come out as garbage. Let's just use spaces.
Cc: Thomas Richter
Fixes: 14f1fa2d0c86 ("drm/i915: Enable dithering on NatSemi DVO2501 for Fujitsu
S6010")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/dvo_ns2501.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c
b/drivers/gpu/drm/i915/dvo_ns2501.c
index 2379c33cfe51..0be266a1e9ca 100644
--- a/drivers/gpu/drm/i915/dvo_ns2501.c
+++ b/drivers/gpu/drm/i915/dvo_ns2501.c
@@ -558,20 +558,20 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,
mode->hdisplay, mode->htotal, mode->vdisplay, mode->vtotal);
DRM_DEBUG_KMS("Detailed requested mode settings are:\n"
- "clock : %d kHz\n"
- "hdisplay : %d\n"
- "hblank start : %d\n"
- "hblank end : %d\n"
- "hsync start: %d\n"
- "hsync end : %d\n"
- "htotal : %d\n"
- "hskew : %d\n"
- "vdisplay : %d\n"
- "vblank start : %d\n"
- "hblank end : %d\n"
- "vsync start: %d\n"
- "vsync end : %d\n"
- "vtotal : %d\n",
+ "clock: %d kHz\n"
+ "hdisplay : %d\n"
+ "hblank start : %d\n"
+ "hblank end : %d\n"
+ "hsync start : %d\n"
+ "hsync end: %d\n"
+ "htotal : %d\n"
+ "hskew: %d\n"
+ "vdisplay : %d\n"
+ "vblank start : %d\n"
+ "hblank end : %d\n"
+ "vsync start : %d\n"
+ "vsync end: %d\n"
+ "vtotal : %d\n",
adjusted_mode->crtc_clock,
adjusted_mode->crtc_hdisplay,
adjusted_mode->crtc_hblank_start,
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reduce Data Link N value for 1 lane DP->hdmi converters
On Thu, 2017-03-23 at 10:59 -0700, Clint Taylor wrote:
> On 03/23/2017 10:23 AM, Jani Nikula wrote:
> > On Thu, 23 Mar 2017, Clint Taylor wrote:
> >> On 03/23/2017 05:30 AM, Jani Nikula wrote:
> >>> On Thu, 23 Mar 2017, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Several major vendor USB-C->HDMI converters fail to recover a 5.4 GHz 1
> lane
> signal if the Data Link N is greater than 0x8.
> Patch detects when 1 lane 5.4 GHz signal is being used and makes the
> maximum
> value 20 bit instead of the maximum specification supported 24 bit value.
>
> Cc: Jani Nikula
> Cc: Anusha Srivatsa
>
> >>>
> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93578
> >>
> >> I will add to the commit message.
> >>
> >>>
> Signed-off-by: Clint Taylor
> ---
> drivers/gpu/drm/i915/i915_reg.h |2 ++
> drivers/gpu/drm/i915/intel_display.c | 15 +++
> 2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 04c8f69..838d8d5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4869,6 +4869,8 @@ enum {
>
> #define DATA_LINK_M_N_MASK (0xff)
> #define DATA_LINK_N_MAX(0x80)
> +/* Maximum N value useable on some DP->HDMI converters */
> +#define DATA_LINK_REDUCED_N_MAX (0x8)
>
> #define _PIPEA_DATA_N_G4X 0x70054
> #define _PIPEB_DATA_N_G4X 0x71054
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 010e5dd..6e1fdd2 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6315,9 +6315,10 @@ static int intel_crtc_compute_config(struct
> intel_crtc *crtc,
> }
>
> static void compute_m_n(unsigned int m, unsigned int n,
> -uint32_t *ret_m, uint32_t *ret_n)
> +uint32_t *ret_m, uint32_t *ret_n,
> +uint32_t max_link_n)
> {
> -*ret_n = min_t(unsigned int, roundup_pow_of_two(n),
> DATA_LINK_N_MAX);
> +*ret_n = min_t(unsigned int, roundup_pow_of_two(n), max_link_n);
> >>>
> >>> If there's evidence suggesting "certain other operating systems" always
> >>> use a max (or fixed value) of 0x8, perhaps we should just follow
> >>> suit? Simpler and less magical.
> >>>
> >>
> >> The other OS's don't appear to be fixed to 0x8. The calculation in
> >> i915 rounds up to the nearest power of 2 and the other OS's might have a
> >> slightly different calculation to the nearest power of 2. Of course I
> >> haven't seen the other OS's code to know their exact formula. HBR3 will
> >> cause a higher value to be calculated and having a fixed value may cause
> >> issues. The i915 formula works and reducing the value can cause
> >> precision issues in the ratio with the pixel clock.
> >>
> *ret_m = div_u64((uint64_t) m * *ret_n, n);
> intel_reduce_m_n_ratio(ret_m, ret_n);
> }
> @@ -6327,14 +6328,20 @@ static void compute_m_n(unsigned int m, unsigned
> int n,
> int pixel_clock, int link_clock,
> struct intel_link_m_n *m_n)
> {
> +uint32_t max_link_n = DATA_LINK_N_MAX;
> m_n->tu = 64;
>
> +if ((nlanes==1) && (link_clock >= 54))
> >>>
> >>> Is the problem really dependent on these conditions? You can get the
> >>> same problematic N value with nlanes == 2 && link_clock == 27 too.
> >>>
> >>
> >> The offending device only supports a single DP lane up to HBR2.5. This
> >> check matches the datasheet for the part. The offending device works
> >> with our current calculation at 1 lane HBR (27).
> >
> > Okay, so what bugs me about the approach here is that this adds an
> > arbitrary condition to apply a quirk to a specific device.
> >
> > Instead of "if device X, then apply restriction A", this adds "if
> > condition Y, then apply restriction A". If I understand you correctly,
> > "condition Y" is a superset of "device X", i.e. Y happens also on
> > devices other than X, but on device X condition Y always holds.
> >
> > I'd really like it if we could come up with a) a quirk that we apply
> > only on the affected device(s), or b) rules for M/N that generally make
> > sense with no need to resort to seeminly arbitrary exceptions.
> >
>
> I can detect the specific device through the DP OUI branch value
> returned during DP detect. I can also detect through the device ID
> string DPCD 0x503-0x508 currently not parsed in i915. Either would
> satisfy Device X, Condition Y, then apply workaround A.
>
drm_dp_helper.c: drm_dp_downstream_id() does that.
-DK
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
Hi Ville, On 23-03-2017 18:14, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 05:53:34PM +, Jose Abreu wrote: >> Hi Ville, >> >> >> On 23-03-2017 17:42, Ville Syrjälä wrote: >>> On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote: Hi Shashank, On 23-03-2017 16:43, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/23/2017 6:33 PM, Jose Abreu wrote: >> Hi Shashank, >> >> >> On 23-03-2017 16:08, Sharma, Shashank wrote: >>> Regards >>> >>> Shashank >>> >>> >>> On 3/23/2017 5:57 PM, Jose Abreu wrote: Hi Ville, On 23-03-2017 15:45, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: >> Hi Shashank, >> >> >> On 23-03-2017 15:14, Shashank Sharma wrote: >>> HDMI 1.4b support the CEA video modes as per range of >>> CEA-861-D (VIC 1-64). >>> For any other mode, the VIC filed in AVI infoframes should >>> be 0. >>> HDMI 2.0 sinks, support video modes range as per CEA-861-F >>> spec, which is >>> extended to (VIC 1-107). >>> >>> This patch adds a bool input variable, which indicates if >>> the connected >>> sink is a HDMI 2.0 sink or not. This will make sure that we >>> don't pass a >>> HDMI 2.0 VIC to a HDMI 1.4 sink. >>> >>> This patch touches all drm drivers, who are callers of this >>> function >>> drm_hdmi_avi_infoframe_from_display_mode but to make sure >>> there is >>> no change in current behavior, is_hdmi2 is kept as false. >>> >>> In case of I915 driver, this patch checks the >>> connector->display_info >>> to check if the connected display is HDMI 2.0. >>> >>> Cc: Ville Syrjala >>> Cc: Jose Abreu >>> Cc: Andrzej Hajda >>> Cc: Alex Deucher >>> Cc: Daniel Vetter >>> >>> PS: This patch touches a few lines in few files, which were >>> already above 80 char, so checkpatch gives 80 char warning >>> again. >>> - gpu/drm/omapdrm/omap_encoder.c >>> - gpu/drm/i915/intel_sdvo.c >>> >>> Signed-off-by: Shashank Sharma >>> --- >>>drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- >>>drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- >>>drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- >>>drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++- >>>drivers/gpu/drm/bridge/sii902x.c | 2 +- >>>drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- >>>drivers/gpu/drm/drm_edid.c| 12 >>> +++- >>>drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- >>>drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- >>>drivers/gpu/drm/i915/intel_hdmi.c | 5 - >>>drivers/gpu/drm/i915/intel_sdvo.c | 3 ++- >>>drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- >>>drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++- >>>drivers/gpu/drm/radeon/radeon_audio.c | 2 +- >>>drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +- >>>drivers/gpu/drm/sti/sti_hdmi.c| 2 +- >>>drivers/gpu/drm/tegra/hdmi.c | 2 +- >>>drivers/gpu/drm/tegra/sor.c | 2 +- >>>drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- >>>drivers/gpu/drm/zte/zx_hdmi.c | 2 +- >>>include/drm/drm_edid.h| 3 ++- >>>21 files changed, 38 insertions(+), 21 deletions(-) >>> >> [snip] >> >>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> index af93f7a..5ff2886 100644 >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct >>> dw_hdmi *hdmi, struct drm_display_mode *mode) >>>u8 val; >>> /* Initialise info frame from DRM mode */ >>> -drm_hdmi_avi_infoframe_from_display_mode(&frame, mode); >>> +drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, >>> false); >>> if (hdmi->hdmi_data.enc_out_format == YCBCR444) >>>frame.colorspace = HDMI_COLORSPACE_YUV444; >>> >> dw-hdmi controller has full support for HDMI 2.0 features. >> It all >> depends on the platform it is integrated. >> >> I think adding a parameter to >> drm_hdmi_avi_infoframe_from_display_mode is not the best idea >> because of this case: A bridge can have su
[Intel-gfx] Regression in i915 for 4.11-rc1 - bisected to commit 69df05e11ab8
Since kernel 4.11-rc1, my desktop (Plasma5/KDE) has encountered intermittent
hangs with the following information in the logs:
linux-4v1g.suse kernel: [drm] GPU HANG: ecode 7:0:0xf3ce, in plasmashell
[1283], reason: Hang on render ring, action: reset
linux-4v1g.suse kernel: [drm] GPU hangs can indicate a bug anywhere in the
entire gfx stack, including userspace.
linux-4v1g.suse kernel: [drm] Please file a _new_ bug report on
bugs.freedesktop.org against DRI -> DRM/Intel
linux-4v1g.suse kernel: [drm] drm/i915 developers can then reassign to the right
component if it's not a kernel issue.
linux-4v1g.suse kernel: [drm] The gpu crash dump is required to analyze gpu
hangs, so please always attach it.
linux-4v1g.suse kernel: [drm] GPU crash dump saved to /sys/class/drm/card0/error
linux-4v1g.suse kernel: drm/i915: Resetting chip after gpu hang
This problem was added to https://bugs.freedesktop.org/show_bug.cgi?id=99380,
but it probably is a different bug, as the OP in that report has problems with
kernel 4.10.x, whereas my problem did not appear until 4.11.
The problem was bisected to commit 69df05e11ab8 ("drm/i915: Simplify releasing
context reference"). The accuracy of the bisection was tested by reverting that
patch in kernel 4.11-rc3. With that change, my kernel has now run for over 17
hours with no problem. Before the reversion, the longest any affected kernel
would run was ~3 hours until a gpu hang was detected.
I admit that I do not understand this driver, but my guess is that this commit
introduced a race condition in the context put.
Thanks,
Larry
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
On Thu, Mar 23, 2017 at 05:53:34PM +, Jose Abreu wrote: > Hi Ville, > > > On 23-03-2017 17:42, Ville Syrjälä wrote: > > On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote: > >> Hi Shashank, > >> > >> > >> On 23-03-2017 16:43, Sharma, Shashank wrote: > >>> Regards > >>> > >>> Shashank > >>> > >>> > >>> On 3/23/2017 6:33 PM, Jose Abreu wrote: > Hi Shashank, > > > On 23-03-2017 16:08, Sharma, Shashank wrote: > > Regards > > > > Shashank > > > > > > On 3/23/2017 5:57 PM, Jose Abreu wrote: > >> Hi Ville, > >> > >> > >> On 23-03-2017 15:45, Ville Syrjälä wrote: > >>> On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: > Hi Shashank, > > > On 23-03-2017 15:14, Shashank Sharma wrote: > > HDMI 1.4b support the CEA video modes as per range of > > CEA-861-D (VIC 1-64). > > For any other mode, the VIC filed in AVI infoframes should > > be 0. > > HDMI 2.0 sinks, support video modes range as per CEA-861-F > > spec, which is > > extended to (VIC 1-107). > > > > This patch adds a bool input variable, which indicates if > > the connected > > sink is a HDMI 2.0 sink or not. This will make sure that we > > don't pass a > > HDMI 2.0 VIC to a HDMI 1.4 sink. > > > > This patch touches all drm drivers, who are callers of this > > function > > drm_hdmi_avi_infoframe_from_display_mode but to make sure > > there is > > no change in current behavior, is_hdmi2 is kept as false. > > > > In case of I915 driver, this patch checks the > > connector->display_info > > to check if the connected display is HDMI 2.0. > > > > Cc: Ville Syrjala > > Cc: Jose Abreu > > Cc: Andrzej Hajda > > Cc: Alex Deucher > > Cc: Daniel Vetter > > > > PS: This patch touches a few lines in few files, which were > > already above 80 char, so checkpatch gives 80 char warning > > again. > > - gpu/drm/omapdrm/omap_encoder.c > > - gpu/drm/i915/intel_sdvo.c > > > > Signed-off-by: Shashank Sharma > > --- > >drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- > >drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- > >drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- > >drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++- > >drivers/gpu/drm/bridge/sii902x.c | 2 +- > >drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > >drivers/gpu/drm/drm_edid.c| 12 > > +++- > >drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- > >drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- > >drivers/gpu/drm/i915/intel_hdmi.c | 5 - > >drivers/gpu/drm/i915/intel_sdvo.c | 3 ++- > >drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- > >drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++- > >drivers/gpu/drm/radeon/radeon_audio.c | 2 +- > >drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +- > >drivers/gpu/drm/sti/sti_hdmi.c| 2 +- > >drivers/gpu/drm/tegra/hdmi.c | 2 +- > >drivers/gpu/drm/tegra/sor.c | 2 +- > >drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- > >drivers/gpu/drm/zte/zx_hdmi.c | 2 +- > >include/drm/drm_edid.h| 3 ++- > >21 files changed, 38 insertions(+), 21 deletions(-) > > > [snip] > > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > > index af93f7a..5ff2886 100644 > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > > @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct > > dw_hdmi *hdmi, struct drm_display_mode *mode) > >u8 val; > > /* Initialise info frame from DRM mode */ > > -drm_hdmi_avi_infoframe_from_display_mode(&frame, mode); > > +drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, > > false); > > if (hdmi->hdmi_data.enc_out_format == YCBCR444) > >frame.colorspace = HDMI_COLORSPACE_YUV444; > > > dw-hdmi controller has full support for HDMI 2.0 features. > It all > depends on the platform it is integrated. > > I think adding a parameter to > drm_hdmi_avi_infoframe_from_display_mode is not the best idea > because of this case: A bridge can have support for HDMI 2.0 > features but the platform ma
Re: [Intel-gfx] [PATCH] drm/i915: Reduce Data Link N value for 1 lane DP->hdmi converters
On 03/23/2017 10:23 AM, Jani Nikula wrote:
On Thu, 23 Mar 2017, Clint Taylor wrote:
On 03/23/2017 05:30 AM, Jani Nikula wrote:
On Thu, 23 Mar 2017, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
Several major vendor USB-C->HDMI converters fail to recover a 5.4 GHz 1 lane
signal if the Data Link N is greater than 0x8.
Patch detects when 1 lane 5.4 GHz signal is being used and makes the maximum
value 20 bit instead of the maximum specification supported 24 bit value.
Cc: Jani Nikula
Cc: Anusha Srivatsa
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93578
I will add to the commit message.
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/i915_reg.h |2 ++
drivers/gpu/drm/i915/intel_display.c | 15 +++
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 04c8f69..838d8d5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4869,6 +4869,8 @@ enum {
#define DATA_LINK_M_N_MASK(0xff)
#define DATA_LINK_N_MAX (0x80)
+/* Maximum N value useable on some DP->HDMI converters */
+#define DATA_LINK_REDUCED_N_MAX (0x8)
#define _PIPEA_DATA_N_G4X 0x70054
#define _PIPEB_DATA_N_G4X 0x71054
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 010e5dd..6e1fdd2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6315,9 +6315,10 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
}
static void compute_m_n(unsigned int m, unsigned int n,
- uint32_t *ret_m, uint32_t *ret_n)
+ uint32_t *ret_m, uint32_t *ret_n,
+ uint32_t max_link_n)
{
- *ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX);
+ *ret_n = min_t(unsigned int, roundup_pow_of_two(n), max_link_n);
If there's evidence suggesting "certain other operating systems" always
use a max (or fixed value) of 0x8, perhaps we should just follow
suit? Simpler and less magical.
The other OS's don't appear to be fixed to 0x8. The calculation in
i915 rounds up to the nearest power of 2 and the other OS's might have a
slightly different calculation to the nearest power of 2. Of course I
haven't seen the other OS's code to know their exact formula. HBR3 will
cause a higher value to be calculated and having a fixed value may cause
issues. The i915 formula works and reducing the value can cause
precision issues in the ratio with the pixel clock.
*ret_m = div_u64((uint64_t) m * *ret_n, n);
intel_reduce_m_n_ratio(ret_m, ret_n);
}
@@ -6327,14 +6328,20 @@ static void compute_m_n(unsigned int m, unsigned int n,
int pixel_clock, int link_clock,
struct intel_link_m_n *m_n)
{
+ uint32_t max_link_n = DATA_LINK_N_MAX;
m_n->tu = 64;
+ if ((nlanes==1) && (link_clock >= 54))
Is the problem really dependent on these conditions? You can get the
same problematic N value with nlanes == 2 && link_clock == 27 too.
The offending device only supports a single DP lane up to HBR2.5. This
check matches the datasheet for the part. The offending device works
with our current calculation at 1 lane HBR (27).
Okay, so what bugs me about the approach here is that this adds an
arbitrary condition to apply a quirk to a specific device.
Instead of "if device X, then apply restriction A", this adds "if
condition Y, then apply restriction A". If I understand you correctly,
"condition Y" is a superset of "device X", i.e. Y happens also on
devices other than X, but on device X condition Y always holds.
I'd really like it if we could come up with a) a quirk that we apply
only on the affected device(s), or b) rules for M/N that generally make
sense with no need to resort to seeminly arbitrary exceptions.
I can detect the specific device through the DP OUI branch value
returned during DP detect. I can also detect through the device ID
string DPCD 0x503-0x508 currently not parsed in i915. Either would
satisfy Device X, Condition Y, then apply workaround A.
I would prefer a solution for B (rules for M/N), but the code doesn't
appear to be broken and I don't believe we should "Fix" something that
is working. The device also works by changing the roundup_pow_of_two()
to rounddown_pow_of_two() however that would apply the change to every
device connected.
With the latter I mean things like reducing the M/N before rounding N up
to power of two (M and N are always divisible by 2, for example) or
having intel_reduce_m_n_ratio() shift them right as long as they have
bit 0 unset. At a glance, I'm not sure if this is enough to bring down
the N to within the limits of the device, without intentional loss of
precision.
BR,
Jani.
BR,
Jani.
+ max_link_n = DATA_LINK_REDUCED_N_MAX
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
Hi Ville, On 23-03-2017 17:42, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote: >> Hi Shashank, >> >> >> On 23-03-2017 16:43, Sharma, Shashank wrote: >>> Regards >>> >>> Shashank >>> >>> >>> On 3/23/2017 6:33 PM, Jose Abreu wrote: Hi Shashank, On 23-03-2017 16:08, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/23/2017 5:57 PM, Jose Abreu wrote: >> Hi Ville, >> >> >> On 23-03-2017 15:45, Ville Syrjälä wrote: >>> On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: Hi Shashank, On 23-03-2017 15:14, Shashank Sharma wrote: > HDMI 1.4b support the CEA video modes as per range of > CEA-861-D (VIC 1-64). > For any other mode, the VIC filed in AVI infoframes should > be 0. > HDMI 2.0 sinks, support video modes range as per CEA-861-F > spec, which is > extended to (VIC 1-107). > > This patch adds a bool input variable, which indicates if > the connected > sink is a HDMI 2.0 sink or not. This will make sure that we > don't pass a > HDMI 2.0 VIC to a HDMI 1.4 sink. > > This patch touches all drm drivers, who are callers of this > function > drm_hdmi_avi_infoframe_from_display_mode but to make sure > there is > no change in current behavior, is_hdmi2 is kept as false. > > In case of I915 driver, this patch checks the > connector->display_info > to check if the connected display is HDMI 2.0. > > Cc: Ville Syrjala > Cc: Jose Abreu > Cc: Andrzej Hajda > Cc: Alex Deucher > Cc: Daniel Vetter > > PS: This patch touches a few lines in few files, which were > already above 80 char, so checkpatch gives 80 char warning > again. > - gpu/drm/omapdrm/omap_encoder.c > - gpu/drm/i915/intel_sdvo.c > > Signed-off-by: Shashank Sharma > --- >drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- >drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- >drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- >drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++- >drivers/gpu/drm/bridge/sii902x.c | 2 +- >drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- >drivers/gpu/drm/drm_edid.c| 12 > +++- >drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- >drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- >drivers/gpu/drm/i915/intel_hdmi.c | 5 - >drivers/gpu/drm/i915/intel_sdvo.c | 3 ++- >drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- >drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++- >drivers/gpu/drm/radeon/radeon_audio.c | 2 +- >drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +- >drivers/gpu/drm/sti/sti_hdmi.c| 2 +- >drivers/gpu/drm/tegra/hdmi.c | 2 +- >drivers/gpu/drm/tegra/sor.c | 2 +- >drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- >drivers/gpu/drm/zte/zx_hdmi.c | 2 +- >include/drm/drm_edid.h| 3 ++- >21 files changed, 38 insertions(+), 21 deletions(-) > [snip] > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > index af93f7a..5ff2886 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct > dw_hdmi *hdmi, struct drm_display_mode *mode) >u8 val; > /* Initialise info frame from DRM mode */ > -drm_hdmi_avi_infoframe_from_display_mode(&frame, mode); > +drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, > false); > if (hdmi->hdmi_data.enc_out_format == YCBCR444) >frame.colorspace = HDMI_COLORSPACE_YUV444; > dw-hdmi controller has full support for HDMI 2.0 features. It all depends on the platform it is integrated. I think adding a parameter to drm_hdmi_avi_infoframe_from_display_mode is not the best idea because of this case: A bridge can have support for HDMI 2.0 features but the platform may limit this support. I guess it can happen in other drivers too. >>> Your driver is in full control of what gets passed here. So I >>> don't see >>> why that would be a problem. >>> >>> Also this doesn't really have anything to do with the >>> capabilities of
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote: > Hi Shashank, > > > On 23-03-2017 16:43, Sharma, Shashank wrote: > > Regards > > > > Shashank > > > > > > On 3/23/2017 6:33 PM, Jose Abreu wrote: > >> Hi Shashank, > >> > >> > >> On 23-03-2017 16:08, Sharma, Shashank wrote: > >>> Regards > >>> > >>> Shashank > >>> > >>> > >>> On 3/23/2017 5:57 PM, Jose Abreu wrote: > Hi Ville, > > > On 23-03-2017 15:45, Ville Syrjälä wrote: > > On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: > >> Hi Shashank, > >> > >> > >> On 23-03-2017 15:14, Shashank Sharma wrote: > >>> HDMI 1.4b support the CEA video modes as per range of > >>> CEA-861-D (VIC 1-64). > >>> For any other mode, the VIC filed in AVI infoframes should > >>> be 0. > >>> HDMI 2.0 sinks, support video modes range as per CEA-861-F > >>> spec, which is > >>> extended to (VIC 1-107). > >>> > >>> This patch adds a bool input variable, which indicates if > >>> the connected > >>> sink is a HDMI 2.0 sink or not. This will make sure that we > >>> don't pass a > >>> HDMI 2.0 VIC to a HDMI 1.4 sink. > >>> > >>> This patch touches all drm drivers, who are callers of this > >>> function > >>> drm_hdmi_avi_infoframe_from_display_mode but to make sure > >>> there is > >>> no change in current behavior, is_hdmi2 is kept as false. > >>> > >>> In case of I915 driver, this patch checks the > >>> connector->display_info > >>> to check if the connected display is HDMI 2.0. > >>> > >>> Cc: Ville Syrjala > >>> Cc: Jose Abreu > >>> Cc: Andrzej Hajda > >>> Cc: Alex Deucher > >>> Cc: Daniel Vetter > >>> > >>> PS: This patch touches a few lines in few files, which were > >>> already above 80 char, so checkpatch gives 80 char warning > >>> again. > >>> - gpu/drm/omapdrm/omap_encoder.c > >>> - gpu/drm/i915/intel_sdvo.c > >>> > >>> Signed-off-by: Shashank Sharma > >>> --- > >>>drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- > >>>drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- > >>>drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- > >>>drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++- > >>>drivers/gpu/drm/bridge/sii902x.c | 2 +- > >>>drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > >>>drivers/gpu/drm/drm_edid.c| 12 > >>> +++- > >>>drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- > >>>drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- > >>>drivers/gpu/drm/i915/intel_hdmi.c | 5 - > >>>drivers/gpu/drm/i915/intel_sdvo.c | 3 ++- > >>>drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- > >>>drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++- > >>>drivers/gpu/drm/radeon/radeon_audio.c | 2 +- > >>>drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +- > >>>drivers/gpu/drm/sti/sti_hdmi.c| 2 +- > >>>drivers/gpu/drm/tegra/hdmi.c | 2 +- > >>>drivers/gpu/drm/tegra/sor.c | 2 +- > >>>drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- > >>>drivers/gpu/drm/zte/zx_hdmi.c | 2 +- > >>>include/drm/drm_edid.h| 3 ++- > >>>21 files changed, 38 insertions(+), 21 deletions(-) > >>> > >> [snip] > >> > >>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > >>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > >>> index af93f7a..5ff2886 100644 > >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > >>> @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct > >>> dw_hdmi *hdmi, struct drm_display_mode *mode) > >>>u8 val; > >>> /* Initialise info frame from DRM mode */ > >>> -drm_hdmi_avi_infoframe_from_display_mode(&frame, mode); > >>> +drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, > >>> false); > >>> if (hdmi->hdmi_data.enc_out_format == YCBCR444) > >>>frame.colorspace = HDMI_COLORSPACE_YUV444; > >>> > >> dw-hdmi controller has full support for HDMI 2.0 features. > >> It all > >> depends on the platform it is integrated. > >> > >> I think adding a parameter to > >> drm_hdmi_avi_infoframe_from_display_mode is not the best idea > >> because of this case: A bridge can have support for HDMI 2.0 > >> features but the platform may limit this support. I guess it > >> can > >> happen in other drivers too. > > Your driver is in full control of what gets passed here. So I > > don't see > > why that would be a problem. > > > > Also this doesn't really have anything to do with the > > capabilities of > > the source. All we want to make sure is that we d
Re: [Intel-gfx] [PATCH] drm/i915: Reduce Data Link N value for 1 lane DP->hdmi converters
On Thu, 23 Mar 2017, Clint Taylor wrote:
> On 03/23/2017 05:30 AM, Jani Nikula wrote:
>> On Thu, 23 Mar 2017, clinton.a.tay...@intel.com wrote:
>>> From: Clint Taylor
>>>
>>> Several major vendor USB-C->HDMI converters fail to recover a 5.4 GHz 1 lane
>>> signal if the Data Link N is greater than 0x8.
>>> Patch detects when 1 lane 5.4 GHz signal is being used and makes the maximum
>>> value 20 bit instead of the maximum specification supported 24 bit value.
>>>
>>> Cc: Jani Nikula
>>> Cc: Anusha Srivatsa
>>>
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93578
>
> I will add to the commit message.
>
>>
>>> Signed-off-by: Clint Taylor
>>> ---
>>> drivers/gpu/drm/i915/i915_reg.h |2 ++
>>> drivers/gpu/drm/i915/intel_display.c | 15 +++
>>> 2 files changed, 13 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>>> b/drivers/gpu/drm/i915/i915_reg.h
>>> index 04c8f69..838d8d5 100644
>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>> @@ -4869,6 +4869,8 @@ enum {
>>>
>>> #define DATA_LINK_M_N_MASK(0xff)
>>> #define DATA_LINK_N_MAX (0x80)
>>> +/* Maximum N value useable on some DP->HDMI converters */
>>> +#define DATA_LINK_REDUCED_N_MAX (0x8)
>>>
>>> #define _PIPEA_DATA_N_G4X 0x70054
>>> #define _PIPEB_DATA_N_G4X 0x71054
>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>> b/drivers/gpu/drm/i915/intel_display.c
>>> index 010e5dd..6e1fdd2 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>> @@ -6315,9 +6315,10 @@ static int intel_crtc_compute_config(struct
>>> intel_crtc *crtc,
>>> }
>>>
>>> static void compute_m_n(unsigned int m, unsigned int n,
>>> - uint32_t *ret_m, uint32_t *ret_n)
>>> + uint32_t *ret_m, uint32_t *ret_n,
>>> + uint32_t max_link_n)
>>> {
>>> - *ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX);
>>> + *ret_n = min_t(unsigned int, roundup_pow_of_two(n), max_link_n);
>>
>> If there's evidence suggesting "certain other operating systems" always
>> use a max (or fixed value) of 0x8, perhaps we should just follow
>> suit? Simpler and less magical.
>>
>
> The other OS's don't appear to be fixed to 0x8. The calculation in
> i915 rounds up to the nearest power of 2 and the other OS's might have a
> slightly different calculation to the nearest power of 2. Of course I
> haven't seen the other OS's code to know their exact formula. HBR3 will
> cause a higher value to be calculated and having a fixed value may cause
> issues. The i915 formula works and reducing the value can cause
> precision issues in the ratio with the pixel clock.
>
>>> *ret_m = div_u64((uint64_t) m * *ret_n, n);
>>> intel_reduce_m_n_ratio(ret_m, ret_n);
>>> }
>>> @@ -6327,14 +6328,20 @@ static void compute_m_n(unsigned int m, unsigned
>>> int n,
>>>int pixel_clock, int link_clock,
>>>struct intel_link_m_n *m_n)
>>> {
>>> + uint32_t max_link_n = DATA_LINK_N_MAX;
>>> m_n->tu = 64;
>>>
>>> + if ((nlanes==1) && (link_clock >= 54))
>>
>> Is the problem really dependent on these conditions? You can get the
>> same problematic N value with nlanes == 2 && link_clock == 27 too.
>>
>
> The offending device only supports a single DP lane up to HBR2.5. This
> check matches the datasheet for the part. The offending device works
> with our current calculation at 1 lane HBR (27).
Okay, so what bugs me about the approach here is that this adds an
arbitrary condition to apply a quirk to a specific device.
Instead of "if device X, then apply restriction A", this adds "if
condition Y, then apply restriction A". If I understand you correctly,
"condition Y" is a superset of "device X", i.e. Y happens also on
devices other than X, but on device X condition Y always holds.
I'd really like it if we could come up with a) a quirk that we apply
only on the affected device(s), or b) rules for M/N that generally make
sense with no need to resort to seeminly arbitrary exceptions.
With the latter I mean things like reducing the M/N before rounding N up
to power of two (M and N are always divisible by 2, for example) or
having intel_reduce_m_n_ratio() shift them right as long as they have
bit 0 unset. At a glance, I'm not sure if this is enough to bring down
the N to within the limits of the device, without intentional loss of
precision.
BR,
Jani.
>
>> BR,
>> Jani.
>>
>>> + max_link_n = DATA_LINK_REDUCED_N_MAX;
>>> +
>>> compute_m_n(bits_per_pixel * pixel_clock,
>>> link_clock * nlanes * 8,
>>> - &m_n->gmch_m, &m_n->gmch_n);
>>> + &m_n->gmch_m, &m_n->gmch_n,
>>> + max_link_n);
>>>
>>> compute_m_n(pixel_clock, link_clock,
>>> - &m_n->link_m, &m_n->link_n);
>>> + &m_n->link_m, &m_n->link_n,
>>>
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
Hi Shashank, On 23-03-2017 16:43, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/23/2017 6:33 PM, Jose Abreu wrote: >> Hi Shashank, >> >> >> On 23-03-2017 16:08, Sharma, Shashank wrote: >>> Regards >>> >>> Shashank >>> >>> >>> On 3/23/2017 5:57 PM, Jose Abreu wrote: Hi Ville, On 23-03-2017 15:45, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: >> Hi Shashank, >> >> >> On 23-03-2017 15:14, Shashank Sharma wrote: >>> HDMI 1.4b support the CEA video modes as per range of >>> CEA-861-D (VIC 1-64). >>> For any other mode, the VIC filed in AVI infoframes should >>> be 0. >>> HDMI 2.0 sinks, support video modes range as per CEA-861-F >>> spec, which is >>> extended to (VIC 1-107). >>> >>> This patch adds a bool input variable, which indicates if >>> the connected >>> sink is a HDMI 2.0 sink or not. This will make sure that we >>> don't pass a >>> HDMI 2.0 VIC to a HDMI 1.4 sink. >>> >>> This patch touches all drm drivers, who are callers of this >>> function >>> drm_hdmi_avi_infoframe_from_display_mode but to make sure >>> there is >>> no change in current behavior, is_hdmi2 is kept as false. >>> >>> In case of I915 driver, this patch checks the >>> connector->display_info >>> to check if the connected display is HDMI 2.0. >>> >>> Cc: Ville Syrjala >>> Cc: Jose Abreu >>> Cc: Andrzej Hajda >>> Cc: Alex Deucher >>> Cc: Daniel Vetter >>> >>> PS: This patch touches a few lines in few files, which were >>> already above 80 char, so checkpatch gives 80 char warning >>> again. >>> - gpu/drm/omapdrm/omap_encoder.c >>> - gpu/drm/i915/intel_sdvo.c >>> >>> Signed-off-by: Shashank Sharma >>> --- >>>drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- >>>drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- >>>drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- >>>drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++- >>>drivers/gpu/drm/bridge/sii902x.c | 2 +- >>>drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- >>>drivers/gpu/drm/drm_edid.c| 12 >>> +++- >>>drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- >>>drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- >>>drivers/gpu/drm/i915/intel_hdmi.c | 5 - >>>drivers/gpu/drm/i915/intel_sdvo.c | 3 ++- >>>drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- >>>drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++- >>>drivers/gpu/drm/radeon/radeon_audio.c | 2 +- >>>drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +- >>>drivers/gpu/drm/sti/sti_hdmi.c| 2 +- >>>drivers/gpu/drm/tegra/hdmi.c | 2 +- >>>drivers/gpu/drm/tegra/sor.c | 2 +- >>>drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- >>>drivers/gpu/drm/zte/zx_hdmi.c | 2 +- >>>include/drm/drm_edid.h| 3 ++- >>>21 files changed, 38 insertions(+), 21 deletions(-) >>> >> [snip] >> >>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> index af93f7a..5ff2886 100644 >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct >>> dw_hdmi *hdmi, struct drm_display_mode *mode) >>>u8 val; >>> /* Initialise info frame from DRM mode */ >>> -drm_hdmi_avi_infoframe_from_display_mode(&frame, mode); >>> +drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, >>> false); >>> if (hdmi->hdmi_data.enc_out_format == YCBCR444) >>>frame.colorspace = HDMI_COLORSPACE_YUV444; >>> >> dw-hdmi controller has full support for HDMI 2.0 features. >> It all >> depends on the platform it is integrated. >> >> I think adding a parameter to >> drm_hdmi_avi_infoframe_from_display_mode is not the best idea >> because of this case: A bridge can have support for HDMI 2.0 >> features but the platform may limit this support. I guess it >> can >> happen in other drivers too. > Your driver is in full control of what gets passed here. So I > don't see > why that would be a problem. > > Also this doesn't really have anything to do with the > capabilities of > the source. All we want to make sure is that we don't send a > VIC the > sink will not understand. > But the driver is not aware of the platform limitations, its generic to the controller only. We could add a field in pdata which tells if platform is HDMI 2.0+ but what about other bridge drivers or HDMI drivers? They wil
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
On Thu, Mar 23, 2017 at 06:31:33PM +0200, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/23/2017 5:52 PM, Jose Abreu wrote: > > Hi Ville, > > > > > > On 23-03-2017 15:36, Ville Syrjälä wrote: > >> On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote: > >>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC > >>> 1-64). > >>> For any other mode, the VIC filed in AVI infoframes should be 0. > >>> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is > >>> extended to (VIC 1-107). > >>> > >>> This patch adds a bool input variable, which indicates if the connected > >>> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a > >>> HDMI 2.0 VIC to a HDMI 1.4 sink. > >> The spec is unfortunately vague when it comes to the CEA-861-F VIC > >> transmission when there is a corresponding HDMI VIC for the same mode. > >> I'm not sure if it's telling us to set both or just one depending on > >> whether we're transmitting 3D video or not. Or at least I can't parse > >> that information from the spec. Anyone have a better crystal ball > >> in their possession? > >> > > I've been working in HDMI receivers and this is what I've got in > > a comment: > > > > 1282 > > /* > > > > 1283 * Update current VIC: When transmitting any > > extended video format > > 1284 * indicated through use of the HDMI_VIC field in > > the HDMI Vendor > > 1285 * Specific InfoFrame or any other format which is > > not described in > > 1286 * the above cases, an HDMI Source shall set the AVI > > InfoFrame VIC > > 1287 * field to > > zero. > > > > 1288 */ > > > > This was directly taken from the spec, can't remember exactly > > were though. > > > > So, the VIC in AVIIF must be set to 0 and the HDMI_VIC field in > > VSIF shall be set to the HDMI 4k VIC. > > > > Best regards, > > Jose Miguel Abreu > Even my understanding of the two specs seems similar > If its a HDMI 1.4b monitor, 2D mode > - VIC field in AVI_IF should be set to appropriate VIC [if VIC is > not listed in CEA-861-D (VIC 1-64), make VIC=0] > If its a HDMI 1.4b monitor, 3D mode > - VIC field in AVI_IF should be set to appropriate VIC, in > conjunction with 3D_structure field in HDMI VSIF > If its a HDMI 2.0 monitor, 2D mode > - VIC filed in the AVI_IF should be set to appropriate VIC (1-107) > If its a HDMI 2.0 monitor, 3D mode > - VIC field in AVI_IF should be set to appropriate VIC, in > conjunction with 3D_structure field in HDMI VSIF You're overlooking the HDMI VIC entirely in that list. OK, so our code even refuses to send both 3D stuff and HDMI VIC at the same time. I presume this was an illegal combination in HDMI 1.4. And since there was no overlap between the CEA VICs and HDMI VICs this was all that we needed. But now that there is overlap, I think we'll need to set CEA VIC=0 whenever HDMI VIC!=0. Or at least that's my strictest interpretation of the spec. I wish they would have stated this stuff more explicitly. So either we need to pass the AVI IF to drm_hdmi_vendor_infoframe_from_display_mode() and have it clear the AVI IF VIC if HDMI VIC is specified, or we need to pass the HDMI IF to drm_hdmi_avi_infoframe_from_display_mode() and have it not set the AVI IF VIC if HDMI VIC is specified. Or we need to make the caller handle this, which would probably lead to more bugs. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Relax the locked clear_bit(IRQ_EXECLIST)
On 23/03/2017 13:48, Chris Wilson wrote: We only need to care about the ordering of the clearing of the bit with the uncached CSB read in order to correctly detect a new interrupt before the read completes. The uncached read itself acts as a full memory barrier, so we do not to enforce another in the form of a locked need ^ clear_bit. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 59acdd3b7a12..c9010fa881b4 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -540,7 +540,14 @@ static void intel_lrc_irq_handler(unsigned long data) dev_priv->regs + i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)); unsigned int csb, head, tail; - clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted); + /* The write will be ordered by the uncached read (itself +* a memory barrier), we do need another in the form a not ^ +* locked instruction. That is the clear of IRQ_EXECLIST bit +* will be visible to another cpu prior to the completion +* of the CSB read. If the other cpu receives an interrupt +* before then, we will redo the CSB read. I don't think the the visibility of clearing the bit matters to anyone. Just the harmlessness of the race between the interrupt sandwiching between test bit and clear bit. +*/ + __clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted); csb = readl(csb_mmio); head = GEN8_CSB_READ_PTR(csb); tail = GEN8_CSB_WRITE_PTR(csb); With some commit and comment fixes: Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Add uncore mmio api for per-context registers
On Thu, Feb 23, 2017 at 3:35 PM, Chris Wilson wrote:
> On Wed, Feb 22, 2017 at 04:36:31PM +, Robert Bragg wrote:
>> Since the exponent for periodic OA counter sampling is maintained in a
>> per-context register while we want to treat it as if it were global
>> state we need to be able to safely issue an mmio write to a per-context
>> register and affect any currently running context.
>>
>> We have to take some extra care in this case and this adds a utility
>> api to encapsulate what's required.
>
> Been waying up the pros/cons of having this in uncore. It doesn't
> attempt to be generic nor replace the existing instance, so atm I think
> it might be better as local to i915_perf.
Thanks. Can you maybe clarify for me what "the existing instance"
that's not replaced is in this context?
>
>> Signed-off-by: Robert Bragg
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 4 ++
>> drivers/gpu/drm/i915/i915_reg.h | 3 ++
>> drivers/gpu/drm/i915/intel_uncore.c | 73
>> +
>> 3 files changed, 80 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 105b97bd34d7..c8d03a2e89cc 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -718,6 +718,7 @@ intel_uncore_forcewake_for_reg(struct drm_i915_private
>> *dev_priv,
>> i915_reg_t reg, unsigned int op);
>>
>> struct intel_uncore_funcs {
>> + int (*wait_for_rcs_busy)(struct drm_i915_private *dev_priv);
>> void (*force_wake_get)(struct drm_i915_private *dev_priv,
>> enum forcewake_domains
>> domains);
>> void (*force_wake_put)(struct drm_i915_private *dev_priv,
>> @@ -751,6 +752,7 @@ struct intel_uncore {
>>
>> struct intel_uncore_funcs funcs;
>>
>> + atomic_t hold_rcs_busy_count;
>> unsigned fifo_count;
>>
>> enum forcewake_domains fw_domains;
>> @@ -3139,6 +3141,8 @@ static inline bool intel_vgpu_active(struct
>> drm_i915_private *dev_priv)
>> {
>> return dev_priv->vgpu.active;
>> }
>> +int intel_uncore_begin_ctx_mmio(struct drm_i915_private *dev_priv);
>> +void intel_uncore_end_ctx_mmio(struct drm_i915_private *dev_priv);
>>
>> void
>> i915_enable_pipestat(struct drm_i915_private *dev_priv, enum pipe pipe,
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 141a5c1e3895..94d40e82edc1 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -2313,6 +2313,9 @@ enum skl_disp_power_wells {
>> #define GEN8_RC_SEMA_IDLE_MSG_DISABLE (1 << 12)
>> #define GEN8_FF_DOP_CLOCK_GATE_DISABLE (1<<10)
>>
>> +#define GEN6_RCS_PWR_FSM _MMIO(0x22ac)
>> +#define GEN9_RCS_FE_FSM2 _MMIO(0x22a4)
>> +
>> /* Fuse readout registers for GT */
>> #define CHV_FUSE_GT _MMIO(VLV_DISPLAY_BASE + 0x2168)
>> #define CHV_FGT_DISABLE_SS0(1 << 10)
>> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
>> b/drivers/gpu/drm/i915/intel_uncore.c
>> index 441c51fd9746..06bfe5f89ac5 100644
>> --- a/drivers/gpu/drm/i915/intel_uncore.c
>> +++ b/drivers/gpu/drm/i915/intel_uncore.c
>> @@ -1274,6 +1274,16 @@ static void intel_uncore_fw_domains_init(struct
>> drm_i915_private *dev_priv)
>> WARN_ON(dev_priv->uncore.fw_domains == 0);
>> }
>>
>> +static int gen8_wait_for_rcs_busy(struct drm_i915_private *dev_priv)
>> +{
>> + return wait_for((I915_READ(GEN6_RCS_PWR_FSM) & 0x3f) == 0x30, 50);
>> +}
>> +
>> +static int gen9_wait_for_rcs_busy(struct drm_i915_private *dev_priv)
>> +{
>> + return wait_for((I915_READ(GEN9_RCS_FE_FSM2) & 0x3f) == 0x30, 50);
>> +}
>> +
>> #define ASSIGN_FW_DOMAINS_TABLE(d) \
>> { \
>> dev_priv->uncore.fw_domains_table = \
>> @@ -1305,6 +1315,8 @@ void intel_uncore_init(struct drm_i915_private
>> *dev_priv)
>> dev_priv->uncore.funcs.mmio_writel =
>> gen9_decoupled_write32;
>> }
>> + dev_priv->uncore.funcs.wait_for_rcs_busy =
>> + gen9_wait_for_rcs_busy;
>> break;
>> case 8:
>> if (IS_CHERRYVIEW(dev_priv)) {
>> @@ -1316,6 +1328,8 @@ void intel_uncore_init(struct drm_i915_private
>> *dev_priv)
>> ASSIGN_WRITE_MMIO_VFUNCS(gen8);
>> ASSIGN_READ_MMIO_VFUNCS(gen6);
>> }
>> + dev_priv->uncore.funcs.wait_for_rcs_busy =
>> + gen8_wait_for_rcs_busy;
>> break;
>> case 7:
>> case 6:
>> @@ -1858,6 +1872,65 @@ intel_uncore_forcewake_for_reg(struct
>> drm_i915_private *dev_priv,
>> return fw_domains;
>> }
>>
>> +static int hold_rcs_busy(struct drm_i915_private *dev_priv)
>> +{
>> + int ret = 0;
>> +
>> + if (atomic_inc_and_test(&dev_priv->uncore.hold_rcs_busy_
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
Regards Shashank On 3/23/2017 6:33 PM, Jose Abreu wrote: Hi Shashank, On 23-03-2017 16:08, Sharma, Shashank wrote: Regards Shashank On 3/23/2017 5:57 PM, Jose Abreu wrote: Hi Ville, On 23-03-2017 15:45, Ville Syrjälä wrote: On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: Hi Shashank, On 23-03-2017 15:14, Shashank Sharma wrote: HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is extended to (VIC 1-107). This patch adds a bool input variable, which indicates if the connected sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a HDMI 2.0 VIC to a HDMI 1.4 sink. This patch touches all drm drivers, who are callers of this function drm_hdmi_avi_infoframe_from_display_mode but to make sure there is no change in current behavior, is_hdmi2 is kept as false. In case of I915 driver, this patch checks the connector->display_info to check if the connected display is HDMI 2.0. Cc: Ville Syrjala Cc: Jose Abreu Cc: Andrzej Hajda Cc: Alex Deucher Cc: Daniel Vetter PS: This patch touches a few lines in few files, which were already above 80 char, so checkpatch gives 80 char warning again. - gpu/drm/omapdrm/omap_encoder.c - gpu/drm/i915/intel_sdvo.c Signed-off-by: Shashank Sharma --- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++- drivers/gpu/drm/bridge/sii902x.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- drivers/gpu/drm/drm_edid.c| 12 +++- drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- drivers/gpu/drm/i915/intel_hdmi.c | 5 - drivers/gpu/drm/i915/intel_sdvo.c | 3 ++- drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++- drivers/gpu/drm/radeon/radeon_audio.c | 2 +- drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +- drivers/gpu/drm/sti/sti_hdmi.c| 2 +- drivers/gpu/drm/tegra/hdmi.c | 2 +- drivers/gpu/drm/tegra/sor.c | 2 +- drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- drivers/gpu/drm/zte/zx_hdmi.c | 2 +- include/drm/drm_edid.h| 3 ++- 21 files changed, 38 insertions(+), 21 deletions(-) [snip] diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index af93f7a..5ff2886 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct drm_display_mode *mode) u8 val; /* Initialise info frame from DRM mode */ -drm_hdmi_avi_infoframe_from_display_mode(&frame, mode); +drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false); if (hdmi->hdmi_data.enc_out_format == YCBCR444) frame.colorspace = HDMI_COLORSPACE_YUV444; dw-hdmi controller has full support for HDMI 2.0 features. It all depends on the platform it is integrated. I think adding a parameter to drm_hdmi_avi_infoframe_from_display_mode is not the best idea because of this case: A bridge can have support for HDMI 2.0 features but the platform may limit this support. I guess it can happen in other drivers too. Your driver is in full control of what gets passed here. So I don't see why that would be a problem. Also this doesn't really have anything to do with the capabilities of the source. All we want to make sure is that we don't send a VIC the sink will not understand. But the driver is not aware of the platform limitations, its generic to the controller only. We could add a field in pdata which tells if platform is HDMI 2.0+ but what about other bridge drivers or HDMI drivers? They will have to replicate the same thing also. Best regards, Jose Miguel Abreu I think the driver would be aware of the platform's capabilities, isn't it ? Else how would it even decide which mode to allow, and which to reject ? The DRM core propagates the mode to the chain of configuration before reaching the bridge driver also, there is a callback supplied by pdata (mode_valid) which can check if the mode is valid. (see https://cgit.freedesktop.org/~airlied/linux/tree/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c?h=drm-next#n1740) Best regards, Jose Miguel Abreu Regards Shashank Please correct me if my understanding is not right, but drivers call mode_valid() to prune/reject modes which they cant support. and they call drm_set_infoframe_from_videomode() function, when they are going ahead to the modeset with a mode. Why would a driver choose to do a modeset, which it could not support (shouldn't
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
Hi Shashank, On 23-03-2017 16:08, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/23/2017 5:57 PM, Jose Abreu wrote: >> Hi Ville, >> >> >> On 23-03-2017 15:45, Ville Syrjälä wrote: >>> On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: Hi Shashank, On 23-03-2017 15:14, Shashank Sharma wrote: > HDMI 1.4b support the CEA video modes as per range of > CEA-861-D (VIC 1-64). > For any other mode, the VIC filed in AVI infoframes should > be 0. > HDMI 2.0 sinks, support video modes range as per CEA-861-F > spec, which is > extended to (VIC 1-107). > > This patch adds a bool input variable, which indicates if > the connected > sink is a HDMI 2.0 sink or not. This will make sure that we > don't pass a > HDMI 2.0 VIC to a HDMI 1.4 sink. > > This patch touches all drm drivers, who are callers of this > function > drm_hdmi_avi_infoframe_from_display_mode but to make sure > there is > no change in current behavior, is_hdmi2 is kept as false. > > In case of I915 driver, this patch checks the > connector->display_info > to check if the connected display is HDMI 2.0. > > Cc: Ville Syrjala > Cc: Jose Abreu > Cc: Andrzej Hajda > Cc: Alex Deucher > Cc: Daniel Vetter > > PS: This patch touches a few lines in few files, which were > already above 80 char, so checkpatch gives 80 char warning > again. > - gpu/drm/omapdrm/omap_encoder.c > - gpu/drm/i915/intel_sdvo.c > > Signed-off-by: Shashank Sharma > --- > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++- > drivers/gpu/drm/bridge/sii902x.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > drivers/gpu/drm/drm_edid.c| 12 +++- > drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- > drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- > drivers/gpu/drm/i915/intel_hdmi.c | 5 - > drivers/gpu/drm/i915/intel_sdvo.c | 3 ++- > drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- > drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++- > drivers/gpu/drm/radeon/radeon_audio.c | 2 +- > drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +- > drivers/gpu/drm/sti/sti_hdmi.c| 2 +- > drivers/gpu/drm/tegra/hdmi.c | 2 +- > drivers/gpu/drm/tegra/sor.c | 2 +- > drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- > drivers/gpu/drm/zte/zx_hdmi.c | 2 +- > include/drm/drm_edid.h| 3 ++- > 21 files changed, 38 insertions(+), 21 deletions(-) > [snip] > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > index af93f7a..5ff2886 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct > dw_hdmi *hdmi, struct drm_display_mode *mode) > u8 val; > /* Initialise info frame from DRM mode */ > -drm_hdmi_avi_infoframe_from_display_mode(&frame, mode); > +drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, > false); > if (hdmi->hdmi_data.enc_out_format == YCBCR444) > frame.colorspace = HDMI_COLORSPACE_YUV444; > dw-hdmi controller has full support for HDMI 2.0 features. It all depends on the platform it is integrated. I think adding a parameter to drm_hdmi_avi_infoframe_from_display_mode is not the best idea because of this case: A bridge can have support for HDMI 2.0 features but the platform may limit this support. I guess it can happen in other drivers too. >>> Your driver is in full control of what gets passed here. So I >>> don't see >>> why that would be a problem. >>> >>> Also this doesn't really have anything to do with the >>> capabilities of >>> the source. All we want to make sure is that we don't send a >>> VIC the >>> sink will not understand. >>> >> But the driver is not aware of the platform limitations, its >> generic to the controller only. We could add a field in pdata >> which tells if platform is HDMI 2.0+ but what about other bridge >> drivers or HDMI drivers? They will have to replicate the same >> thing also. >> >> Best regards, >> Jose Miguel Abreu > I think the driver would be aware of the platform's > capabilities, isn't it ? > Else how would it even decide which mode to allow, and which to > reject ? The DRM core propagates the mode to the chain of configuration before reaching the bridge driver also, there is a callback supplied by pdata (mode_valid) which can chec
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
Regards Shashank On 3/23/2017 5:28 PM, Ilia Mirkin wrote: On Thu, Mar 23, 2017 at 11:22 AM, Sharma, Shashank wrote: On 3/23/2017 5:17 PM, Ilia Mirkin wrote: On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma wrote: HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is extended to (VIC 1-107). This patch adds a bool input variable, which indicates if the connected sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a HDMI 2.0 VIC to a HDMI 1.4 sink. Should this patch come before the patch which recognizes VICs 65+? Otherwise if only the first patch is applied but not this one, you could end up with the bad scenario. (As can happen in bisections, for example.) I kindof agree, this could be the case, but also, for the correct functionality, you should have the whole series together. OK, so ... I have a bug in my filesystem, and I'm bisecting it and rebooting my box at each step. I happen to hit this commit in my bisect and my monitor doesn't turn on? Seems unpleasant, no? Cant say no :-), will happily change the order if this makes you feel better. Regards Shashank ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
Regards Shashank On 3/23/2017 5:52 PM, Jose Abreu wrote: Hi Ville, On 23-03-2017 15:36, Ville Syrjälä wrote: On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote: HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is extended to (VIC 1-107). This patch adds a bool input variable, which indicates if the connected sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a HDMI 2.0 VIC to a HDMI 1.4 sink. The spec is unfortunately vague when it comes to the CEA-861-F VIC transmission when there is a corresponding HDMI VIC for the same mode. I'm not sure if it's telling us to set both or just one depending on whether we're transmitting 3D video or not. Or at least I can't parse that information from the spec. Anyone have a better crystal ball in their possession? I've been working in HDMI receivers and this is what I've got in a comment: 1282 /* 1283 * Update current VIC: When transmitting any extended video format 1284 * indicated through use of the HDMI_VIC field in the HDMI Vendor 1285 * Specific InfoFrame or any other format which is not described in 1286 * the above cases, an HDMI Source shall set the AVI InfoFrame VIC 1287 * field to zero. 1288 */ This was directly taken from the spec, can't remember exactly were though. So, the VIC in AVIIF must be set to 0 and the HDMI_VIC field in VSIF shall be set to the HDMI 4k VIC. Best regards, Jose Miguel Abreu Even my understanding of the two specs seems similar If its a HDMI 1.4b monitor, 2D mode - VIC field in AVI_IF should be set to appropriate VIC [if VIC is not listed in CEA-861-D (VIC 1-64), make VIC=0] If its a HDMI 1.4b monitor, 3D mode - VIC field in AVI_IF should be set to appropriate VIC, in conjunction with 3D_structure field in HDMI VSIF If its a HDMI 2.0 monitor, 2D mode - VIC filed in the AVI_IF should be set to appropriate VIC (1-107) If its a HDMI 2.0 monitor, 3D mode - VIC field in AVI_IF should be set to appropriate VIC, in conjunction with 3D_structure field in HDMI VSIF Regards Shashank ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reduce Data Link N value for 1 lane DP->hdmi converters
On 03/23/2017 05:30 AM, Jani Nikula wrote:
On Thu, 23 Mar 2017, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
Several major vendor USB-C->HDMI converters fail to recover a 5.4 GHz 1 lane
signal if the Data Link N is greater than 0x8.
Patch detects when 1 lane 5.4 GHz signal is being used and makes the maximum
value 20 bit instead of the maximum specification supported 24 bit value.
Cc: Jani Nikula
Cc: Anusha Srivatsa
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93578
I will add to the commit message.
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/i915_reg.h |2 ++
drivers/gpu/drm/i915/intel_display.c | 15 +++
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 04c8f69..838d8d5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4869,6 +4869,8 @@ enum {
#define DATA_LINK_M_N_MASK(0xff)
#define DATA_LINK_N_MAX (0x80)
+/* Maximum N value useable on some DP->HDMI converters */
+#define DATA_LINK_REDUCED_N_MAX (0x8)
#define _PIPEA_DATA_N_G4X 0x70054
#define _PIPEB_DATA_N_G4X 0x71054
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 010e5dd..6e1fdd2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6315,9 +6315,10 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
}
static void compute_m_n(unsigned int m, unsigned int n,
- uint32_t *ret_m, uint32_t *ret_n)
+ uint32_t *ret_m, uint32_t *ret_n,
+ uint32_t max_link_n)
{
- *ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX);
+ *ret_n = min_t(unsigned int, roundup_pow_of_two(n), max_link_n);
If there's evidence suggesting "certain other operating systems" always
use a max (or fixed value) of 0x8, perhaps we should just follow
suit? Simpler and less magical.
The other OS's don't appear to be fixed to 0x8. The calculation in
i915 rounds up to the nearest power of 2 and the other OS's might have a
slightly different calculation to the nearest power of 2. Of course I
haven't seen the other OS's code to know their exact formula. HBR3 will
cause a higher value to be calculated and having a fixed value may cause
issues. The i915 formula works and reducing the value can cause
precision issues in the ratio with the pixel clock.
*ret_m = div_u64((uint64_t) m * *ret_n, n);
intel_reduce_m_n_ratio(ret_m, ret_n);
}
@@ -6327,14 +6328,20 @@ static void compute_m_n(unsigned int m, unsigned int n,
int pixel_clock, int link_clock,
struct intel_link_m_n *m_n)
{
+ uint32_t max_link_n = DATA_LINK_N_MAX;
m_n->tu = 64;
+ if ((nlanes==1) && (link_clock >= 54))
Is the problem really dependent on these conditions? You can get the
same problematic N value with nlanes == 2 && link_clock == 27 too.
The offending device only supports a single DP lane up to HBR2.5. This
check matches the datasheet for the part. The offending device works
with our current calculation at 1 lane HBR (27).
BR,
Jani.
+ max_link_n = DATA_LINK_REDUCED_N_MAX;
+
compute_m_n(bits_per_pixel * pixel_clock,
link_clock * nlanes * 8,
- &m_n->gmch_m, &m_n->gmch_n);
+ &m_n->gmch_m, &m_n->gmch_n,
+ max_link_n);
compute_m_n(pixel_clock, link_clock,
- &m_n->link_m, &m_n->link_n);
+ &m_n->link_m, &m_n->link_n,
+ max_link_n);
}
static inline bool intel_panel_use_ssc(struct drm_i915_private *dev_priv)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
Regards Shashank On 3/23/2017 5:57 PM, Jose Abreu wrote: Hi Ville, On 23-03-2017 15:45, Ville Syrjälä wrote: On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: Hi Shashank, On 23-03-2017 15:14, Shashank Sharma wrote: HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is extended to (VIC 1-107). This patch adds a bool input variable, which indicates if the connected sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a HDMI 2.0 VIC to a HDMI 1.4 sink. This patch touches all drm drivers, who are callers of this function drm_hdmi_avi_infoframe_from_display_mode but to make sure there is no change in current behavior, is_hdmi2 is kept as false. In case of I915 driver, this patch checks the connector->display_info to check if the connected display is HDMI 2.0. Cc: Ville Syrjala Cc: Jose Abreu Cc: Andrzej Hajda Cc: Alex Deucher Cc: Daniel Vetter PS: This patch touches a few lines in few files, which were already above 80 char, so checkpatch gives 80 char warning again. - gpu/drm/omapdrm/omap_encoder.c - gpu/drm/i915/intel_sdvo.c Signed-off-by: Shashank Sharma --- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++- drivers/gpu/drm/bridge/sii902x.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- drivers/gpu/drm/drm_edid.c| 12 +++- drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- drivers/gpu/drm/i915/intel_hdmi.c | 5 - drivers/gpu/drm/i915/intel_sdvo.c | 3 ++- drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++- drivers/gpu/drm/radeon/radeon_audio.c | 2 +- drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +- drivers/gpu/drm/sti/sti_hdmi.c| 2 +- drivers/gpu/drm/tegra/hdmi.c | 2 +- drivers/gpu/drm/tegra/sor.c | 2 +- drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- drivers/gpu/drm/zte/zx_hdmi.c | 2 +- include/drm/drm_edid.h| 3 ++- 21 files changed, 38 insertions(+), 21 deletions(-) [snip] diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index af93f7a..5ff2886 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct drm_display_mode *mode) u8 val; /* Initialise info frame from DRM mode */ - drm_hdmi_avi_infoframe_from_display_mode(&frame, mode); + drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false); if (hdmi->hdmi_data.enc_out_format == YCBCR444) frame.colorspace = HDMI_COLORSPACE_YUV444; dw-hdmi controller has full support for HDMI 2.0 features. It all depends on the platform it is integrated. I think adding a parameter to drm_hdmi_avi_infoframe_from_display_mode is not the best idea because of this case: A bridge can have support for HDMI 2.0 features but the platform may limit this support. I guess it can happen in other drivers too. Your driver is in full control of what gets passed here. So I don't see why that would be a problem. Also this doesn't really have anything to do with the capabilities of the source. All we want to make sure is that we don't send a VIC the sink will not understand. But the driver is not aware of the platform limitations, its generic to the controller only. We could add a field in pdata which tells if platform is HDMI 2.0+ but what about other bridge drivers or HDMI drivers? They will have to replicate the same thing also. Best regards, Jose Miguel Abreu I think the driver would be aware of the platform's capabilities, isn't it ? Else how would it even decide which mode to allow, and which to reject ? Regards Shashank ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/2] drm/edid: Complete CEA modedb(VIC 1-107)
== Series Details == Series: series starting with [v4,1/2] drm/edid: Complete CEA modedb(VIC 1-107) URL : https://patchwork.freedesktop.org/series/21772/ State : success == Summary == Series 21772v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/21772/revisions/1/mbox/ Test gem_sync: Subgroup basic-many-each: incomplete -> PASS (fi-ilk-650) fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 463s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 452s fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 time: 584s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 536s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time: 578s fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 time: 510s fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 time: 504s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 436s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 435s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 442s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 518s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 501s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 485s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 485s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 606s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 491s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 520s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 461s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 553s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time: 415s 0b29bac4adfc0329c9235f8e496eaefb2bcc41e9 drm-tip: 2017y-03m-23d-14h-20m-03s UTC integration manifest 3aebd5f drm: Add HDMI 2.0 VIC support for AVI info-frames 7143d26 drm/edid: Complete CEA modedb(VIC 1-107) == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4281/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
Hi Ville, On 23-03-2017 15:45, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: >> Hi Shashank, >> >> >> On 23-03-2017 15:14, Shashank Sharma wrote: >>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). >>> For any other mode, the VIC filed in AVI infoframes should be 0. >>> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is >>> extended to (VIC 1-107). >>> >>> This patch adds a bool input variable, which indicates if the connected >>> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a >>> HDMI 2.0 VIC to a HDMI 1.4 sink. >>> >>> This patch touches all drm drivers, who are callers of this function >>> drm_hdmi_avi_infoframe_from_display_mode but to make sure there is >>> no change in current behavior, is_hdmi2 is kept as false. >>> >>> In case of I915 driver, this patch checks the connector->display_info >>> to check if the connected display is HDMI 2.0. >>> >>> Cc: Ville Syrjala >>> Cc: Jose Abreu >>> Cc: Andrzej Hajda >>> Cc: Alex Deucher >>> Cc: Daniel Vetter >>> >>> PS: This patch touches a few lines in few files, which were >>> already above 80 char, so checkpatch gives 80 char warning again. >>> - gpu/drm/omapdrm/omap_encoder.c >>> - gpu/drm/i915/intel_sdvo.c >>> >>> Signed-off-by: Shashank Sharma >>> --- >>> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- >>> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- >>> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- >>> drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++- >>> drivers/gpu/drm/bridge/sii902x.c | 2 +- >>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- >>> drivers/gpu/drm/drm_edid.c| 12 +++- >>> drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- >>> drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- >>> drivers/gpu/drm/i915/intel_hdmi.c | 5 - >>> drivers/gpu/drm/i915/intel_sdvo.c | 3 ++- >>> drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- >>> drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++- >>> drivers/gpu/drm/radeon/radeon_audio.c | 2 +- >>> drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +- >>> drivers/gpu/drm/sti/sti_hdmi.c| 2 +- >>> drivers/gpu/drm/tegra/hdmi.c | 2 +- >>> drivers/gpu/drm/tegra/sor.c | 2 +- >>> drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- >>> drivers/gpu/drm/zte/zx_hdmi.c | 2 +- >>> include/drm/drm_edid.h| 3 ++- >>> 21 files changed, 38 insertions(+), 21 deletions(-) >>> >> [snip] >> >>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> index af93f7a..5ff2886 100644 >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, >>> struct drm_display_mode *mode) >>> u8 val; >>> >>> /* Initialise info frame from DRM mode */ >>> - drm_hdmi_avi_infoframe_from_display_mode(&frame, mode); >>> + drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false); >>> >>> if (hdmi->hdmi_data.enc_out_format == YCBCR444) >>> frame.colorspace = HDMI_COLORSPACE_YUV444; >>> >> dw-hdmi controller has full support for HDMI 2.0 features. It all >> depends on the platform it is integrated. >> >> I think adding a parameter to >> drm_hdmi_avi_infoframe_from_display_mode is not the best idea >> because of this case: A bridge can have support for HDMI 2.0 >> features but the platform may limit this support. I guess it can >> happen in other drivers too. > Your driver is in full control of what gets passed here. So I don't see > why that would be a problem. > > Also this doesn't really have anything to do with the capabilities of > the source. All we want to make sure is that we don't send a VIC the > sink will not understand. > But the driver is not aware of the platform limitations, its generic to the controller only. We could add a field in pdata which tells if platform is HDMI 2.0+ but what about other bridge drivers or HDMI drivers? They will have to replicate the same thing also. Best regards, Jose Miguel Abreu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
Hi Ville, On 23-03-2017 15:36, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote: >> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). >> For any other mode, the VIC filed in AVI infoframes should be 0. >> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is >> extended to (VIC 1-107). >> >> This patch adds a bool input variable, which indicates if the connected >> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a >> HDMI 2.0 VIC to a HDMI 1.4 sink. > The spec is unfortunately vague when it comes to the CEA-861-F VIC > transmission when there is a corresponding HDMI VIC for the same mode. > I'm not sure if it's telling us to set both or just one depending on > whether we're transmitting 3D video or not. Or at least I can't parse > that information from the spec. Anyone have a better crystal ball > in their possession? > I've been working in HDMI receivers and this is what I've got in a comment: 1282 /* 1283 * Update current VIC: When transmitting any extended video format 1284 * indicated through use of the HDMI_VIC field in the HDMI Vendor 1285 * Specific InfoFrame or any other format which is not described in 1286 * the above cases, an HDMI Source shall set the AVI InfoFrame VIC 1287 * field to zero. 1288 */ This was directly taken from the spec, can't remember exactly were though. So, the VIC in AVIIF must be set to 0 and the HDMI_VIC field in VSIF shall be set to the HDMI 4k VIC. Best regards, Jose Miguel Abreu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave, drm-misc-fixes-2017-03-23: One fbdev regression fix from Michel Cheers, Daniel The following changes since commit 97da3854c526d3a6ee05c849c96e48d21527606c: Linux 4.11-rc3 (2017-03-19 19:09:39 -0700) are available in the git repository at: git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-03-23 for you to fetch changes up to 12ffed96d4369f086261ba2ee734fa8c932d7f55: drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again (2017-03-23 15:12:07 +0100) One fbdev regression fix from Michel Michel Dänzer (1): drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again drivers/gpu/drm/drm_fb_helper.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: > Hi Shashank, > > > On 23-03-2017 15:14, Shashank Sharma wrote: > > HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). > > For any other mode, the VIC filed in AVI infoframes should be 0. > > HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is > > extended to (VIC 1-107). > > > > This patch adds a bool input variable, which indicates if the connected > > sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a > > HDMI 2.0 VIC to a HDMI 1.4 sink. > > > > This patch touches all drm drivers, who are callers of this function > > drm_hdmi_avi_infoframe_from_display_mode but to make sure there is > > no change in current behavior, is_hdmi2 is kept as false. > > > > In case of I915 driver, this patch checks the connector->display_info > > to check if the connected display is HDMI 2.0. > > > > Cc: Ville Syrjala > > Cc: Jose Abreu > > Cc: Andrzej Hajda > > Cc: Alex Deucher > > Cc: Daniel Vetter > > > > PS: This patch touches a few lines in few files, which were > > already above 80 char, so checkpatch gives 80 char warning again. > > - gpu/drm/omapdrm/omap_encoder.c > > - gpu/drm/i915/intel_sdvo.c > > > > Signed-off-by: Shashank Sharma > > --- > > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- > > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- > > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- > > drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++- > > drivers/gpu/drm/bridge/sii902x.c | 2 +- > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > > drivers/gpu/drm/drm_edid.c| 12 +++- > > drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- > > drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- > > drivers/gpu/drm/i915/intel_hdmi.c | 5 - > > drivers/gpu/drm/i915/intel_sdvo.c | 3 ++- > > drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- > > drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++- > > drivers/gpu/drm/radeon/radeon_audio.c | 2 +- > > drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +- > > drivers/gpu/drm/sti/sti_hdmi.c| 2 +- > > drivers/gpu/drm/tegra/hdmi.c | 2 +- > > drivers/gpu/drm/tegra/sor.c | 2 +- > > drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- > > drivers/gpu/drm/zte/zx_hdmi.c | 2 +- > > include/drm/drm_edid.h| 3 ++- > > 21 files changed, 38 insertions(+), 21 deletions(-) > > > > [snip] > > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > > index af93f7a..5ff2886 100644 > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > > @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, > > struct drm_display_mode *mode) > > u8 val; > > > > /* Initialise info frame from DRM mode */ > > - drm_hdmi_avi_infoframe_from_display_mode(&frame, mode); > > + drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false); > > > > if (hdmi->hdmi_data.enc_out_format == YCBCR444) > > frame.colorspace = HDMI_COLORSPACE_YUV444; > > > > dw-hdmi controller has full support for HDMI 2.0 features. It all > depends on the platform it is integrated. > > I think adding a parameter to > drm_hdmi_avi_infoframe_from_display_mode is not the best idea > because of this case: A bridge can have support for HDMI 2.0 > features but the platform may limit this support. I guess it can > happen in other drivers too. Your driver is in full control of what gets passed here. So I don't see why that would be a problem. Also this doesn't really have anything to do with the capabilities of the source. All we want to make sure is that we don't send a VIC the sink will not understand. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Check we have an wake device before flushing GTT writes (rev2)
== Series Details == Series: drm/i915: Check we have an wake device before flushing GTT writes (rev2) URL : https://patchwork.freedesktop.org/series/20899/ State : success == Summary == Series 20899v2 drm/i915: Check we have an wake device before flushing GTT writes https://patchwork.freedesktop.org/api/1.0/series/20899/revisions/2/mbox/ Test gem_sync: Subgroup basic-many-each: incomplete -> PASS (fi-ilk-650) fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 459s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 461s fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 time: 589s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 544s fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 time: 506s fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 time: 499s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 438s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 433s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 445s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 519s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 494s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 485s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 480s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 601s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 486s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 512s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 468s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 552s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time: 427s 0b29bac4adfc0329c9235f8e496eaefb2bcc41e9 drm-tip: 2017y-03m-23d-14h-20m-03s UTC integration manifest 26ecce0 drm/i915: Check we have an wake device before flushing GTT writes == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4280/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC 1-107).
>
> This patch adds a bool input variable, which indicates if the connected
> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
> HDMI 2.0 VIC to a HDMI 1.4 sink.
The spec is unfortunately vague when it comes to the CEA-861-F VIC
transmission when there is a corresponding HDMI VIC for the same mode.
I'm not sure if it's telling us to set both or just one depending on
whether we're transmitting 3D video or not. Or at least I can't parse
that information from the spec. Anyone have a better crystal ball
in their possession?
>
> This patch touches all drm drivers, who are callers of this function
> drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
> no change in current behavior, is_hdmi2 is kept as false.
>
> In case of I915 driver, this patch checks the connector->display_info
> to check if the connected display is HDMI 2.0.
>
> Cc: Ville Syrjala
> Cc: Jose Abreu
> Cc: Andrzej Hajda
> Cc: Alex Deucher
> Cc: Daniel Vetter
>
> PS: This patch touches a few lines in few files, which were
> already above 80 char, so checkpatch gives 80 char warning again.
> - gpu/drm/omapdrm/omap_encoder.c
> - gpu/drm/i915/intel_sdvo.c
>
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
> drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++-
> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> drivers/gpu/drm/drm_edid.c| 12 +++-
> drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
> drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
> drivers/gpu/drm/i915/intel_hdmi.c | 5 -
> drivers/gpu/drm/i915/intel_sdvo.c | 3 ++-
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++-
> drivers/gpu/drm/radeon/radeon_audio.c | 2 +-
> drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +-
> drivers/gpu/drm/sti/sti_hdmi.c| 2 +-
> drivers/gpu/drm/tegra/hdmi.c | 2 +-
> drivers/gpu/drm/tegra/sor.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +-
> drivers/gpu/drm/zte/zx_hdmi.c | 2 +-
> include/drm/drm_edid.h| 3 ++-
> 21 files changed, 38 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index d4452d8..ab7a399 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -1877,7 +1877,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder
> *encoder,
> dce_v10_0_audio_write_sad_regs(encoder);
> dce_v10_0_audio_write_latency_fields(encoder, mode);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index 5b24e89..3c5fd83 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -1861,7 +1861,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder
> *encoder,
> dce_v11_0_audio_write_sad_regs(encoder);
> dce_v11_0_audio_write_latency_fields(encoder, mode);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index d2590d7..c564dca 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -1760,7 +1760,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder
> *encoder,
> dce_v8_0_audio_write_sad_regs(encoder);
> dce_v8_0_audio_write_latency_fields(encoder, mode);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> index a2a8236..f9b77b8 100644
> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> +++ b/d
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
Hi Shashank, On 23-03-2017 15:14, Shashank Sharma wrote: > HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). > For any other mode, the VIC filed in AVI infoframes should be 0. > HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is > extended to (VIC 1-107). > > This patch adds a bool input variable, which indicates if the connected > sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a > HDMI 2.0 VIC to a HDMI 1.4 sink. > > This patch touches all drm drivers, who are callers of this function > drm_hdmi_avi_infoframe_from_display_mode but to make sure there is > no change in current behavior, is_hdmi2 is kept as false. > > In case of I915 driver, this patch checks the connector->display_info > to check if the connected display is HDMI 2.0. > > Cc: Ville Syrjala > Cc: Jose Abreu > Cc: Andrzej Hajda > Cc: Alex Deucher > Cc: Daniel Vetter > > PS: This patch touches a few lines in few files, which were > already above 80 char, so checkpatch gives 80 char warning again. > - gpu/drm/omapdrm/omap_encoder.c > - gpu/drm/i915/intel_sdvo.c > > Signed-off-by: Shashank Sharma > --- > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++- > drivers/gpu/drm/bridge/sii902x.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > drivers/gpu/drm/drm_edid.c| 12 +++- > drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- > drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- > drivers/gpu/drm/i915/intel_hdmi.c | 5 - > drivers/gpu/drm/i915/intel_sdvo.c | 3 ++- > drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- > drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++- > drivers/gpu/drm/radeon/radeon_audio.c | 2 +- > drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +- > drivers/gpu/drm/sti/sti_hdmi.c| 2 +- > drivers/gpu/drm/tegra/hdmi.c | 2 +- > drivers/gpu/drm/tegra/sor.c | 2 +- > drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- > drivers/gpu/drm/zte/zx_hdmi.c | 2 +- > include/drm/drm_edid.h| 3 ++- > 21 files changed, 38 insertions(+), 21 deletions(-) > [snip] > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > index af93f7a..5ff2886 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > @@ -1146,7 +1146,7 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, > struct drm_display_mode *mode) > u8 val; > > /* Initialise info frame from DRM mode */ > - drm_hdmi_avi_infoframe_from_display_mode(&frame, mode); > + drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false); > > if (hdmi->hdmi_data.enc_out_format == YCBCR444) > frame.colorspace = HDMI_COLORSPACE_YUV444; > dw-hdmi controller has full support for HDMI 2.0 features. It all depends on the platform it is integrated. I think adding a parameter to drm_hdmi_avi_infoframe_from_display_mode is not the best idea because of this case: A bridge can have support for HDMI 2.0 features but the platform may limit this support. I guess it can happen in other drivers too. Best regards, Jose Miguel Abreu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
On Thu, Mar 23, 2017 at 11:22 AM, Sharma, Shashank wrote: > On 3/23/2017 5:17 PM, Ilia Mirkin wrote: >> >> On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma >> wrote: >>> >>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC >>> 1-64). >>> For any other mode, the VIC filed in AVI infoframes should be 0. >>> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is >>> extended to (VIC 1-107). >>> >>> This patch adds a bool input variable, which indicates if the connected >>> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a >>> HDMI 2.0 VIC to a HDMI 1.4 sink. >> >> Should this patch come before the patch which recognizes VICs 65+? >> Otherwise if only the first patch is applied but not this one, you >> could end up with the bad scenario. (As can happen in bisections, for >> example.) > > I kindof agree, this could be the case, but also, for the correct > functionality, you should have the whole series > together. OK, so ... I have a bug in my filesystem, and I'm bisecting it and rebooting my box at each step. I happen to hit this commit in my bisect and my monitor doesn't turn on? Seems unpleasant, no? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
Regards
Shashank
On 3/23/2017 5:17 PM, Ilia Mirkin wrote:
On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.
Should this patch come before the patch which recognizes VICs 65+?
Otherwise if only the first patch is applied but not this one, you
could end up with the bad scenario. (As can happen in bisections, for
example.)
I kindof agree, this could be the case, but also, for the correct
functionality, you should have the whole series
together.
This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.
In case of I915 driver, this patch checks the connector->display_info
to check if the connected display is HDMI 2.0.
Cc: Ville Syrjala
Cc: Jose Abreu
Cc: Andrzej Hajda
Cc: Alex Deucher
Cc: Daniel Vetter
PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++-
drivers/gpu/drm/bridge/sii902x.c | 2 +-
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
drivers/gpu/drm/drm_edid.c| 12 +++-
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
drivers/gpu/drm/i915/intel_hdmi.c | 5 -
drivers/gpu/drm/i915/intel_sdvo.c | 3 ++-
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++-
drivers/gpu/drm/radeon/radeon_audio.c | 2 +-
drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +-
drivers/gpu/drm/sti/sti_hdmi.c| 2 +-
drivers/gpu/drm/tegra/hdmi.c | 2 +-
drivers/gpu/drm/tegra/sor.c | 2 +-
drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +-
drivers/gpu/drm/zte/zx_hdmi.c | 2 +-
include/drm/drm_edid.h| 3 ++-
21 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index d4452d8..ab7a399 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1877,7 +1877,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder
*encoder,
dce_v10_0_audio_write_sad_regs(encoder);
dce_v10_0_audio_write_latency_fields(encoder, mode);
- err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+ err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 5b24e89..3c5fd83 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1861,7 +1861,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder
*encoder,
dce_v11_0_audio_write_sad_regs(encoder);
dce_v11_0_audio_write_latency_fields(encoder, mode);
- err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+ err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index d2590d7..c564dca 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1760,7 +1760,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder
*encoder,
dce_v8_0_audio_write_sad_regs(encoder);
dce_v8_0_audio_write_latency_fields(encoder, mode);
- err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+ err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index a2a8236..f9b77b8 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1097,7 +1097,8 @@ static void anx78xx_bridge_mode_s
Re: [Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC 1-107).
>
> This patch adds a bool input variable, which indicates if the connected
> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
> HDMI 2.0 VIC to a HDMI 1.4 sink.
Should this patch come before the patch which recognizes VICs 65+?
Otherwise if only the first patch is applied but not this one, you
could end up with the bad scenario. (As can happen in bisections, for
example.)
>
> This patch touches all drm drivers, who are callers of this function
> drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
> no change in current behavior, is_hdmi2 is kept as false.
>
> In case of I915 driver, this patch checks the connector->display_info
> to check if the connected display is HDMI 2.0.
>
> Cc: Ville Syrjala
> Cc: Jose Abreu
> Cc: Andrzej Hajda
> Cc: Alex Deucher
> Cc: Daniel Vetter
>
> PS: This patch touches a few lines in few files, which were
> already above 80 char, so checkpatch gives 80 char warning again.
> - gpu/drm/omapdrm/omap_encoder.c
> - gpu/drm/i915/intel_sdvo.c
>
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
> drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++-
> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> drivers/gpu/drm/drm_edid.c| 12 +++-
> drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
> drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
> drivers/gpu/drm/i915/intel_hdmi.c | 5 -
> drivers/gpu/drm/i915/intel_sdvo.c | 3 ++-
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++-
> drivers/gpu/drm/radeon/radeon_audio.c | 2 +-
> drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +-
> drivers/gpu/drm/sti/sti_hdmi.c| 2 +-
> drivers/gpu/drm/tegra/hdmi.c | 2 +-
> drivers/gpu/drm/tegra/sor.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +-
> drivers/gpu/drm/zte/zx_hdmi.c | 2 +-
> include/drm/drm_edid.h| 3 ++-
> 21 files changed, 38 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index d4452d8..ab7a399 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -1877,7 +1877,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder
> *encoder,
> dce_v10_0_audio_write_sad_regs(encoder);
> dce_v10_0_audio_write_latency_fields(encoder, mode);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index 5b24e89..3c5fd83 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -1861,7 +1861,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder
> *encoder,
> dce_v11_0_audio_write_sad_regs(encoder);
> dce_v11_0_audio_write_latency_fields(encoder, mode);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index d2590d7..c564dca 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -1760,7 +1760,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder
> *encoder,
> dce_v8_0_audio_write_sad_regs(encoder);
> dce_v8_0_audio_write_latency_fields(encoder, mode);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> index a2a8236..f9b77b8 100644
> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> @@ -1097,7 +1097,8 @@ static void anx78xx_bridge_mode_set(struct drm_bridge
> *bridg
[Intel-gfx] [PATCH v4 1/2] drm/edid: Complete CEA modedb(VIC 1-107)
CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.
Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onwards).
This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).
Cc: Ville Syrjala
Cc: Jose Abreu
Cc: Andrzej Hajda
Cc: Alex Deucher
V2: Addressed review comments from Jose:
- fix the timings for VIC 83, 90 and 91
- fix formatting for VIC 93-107
V3: Rebase on drm-tip, added R-B from Jose, Alex.
V4: Addressed review comments from Andrzej not to modify the
VIC filed for HDMI 1.4b sinks (by adding another patch).
Reviewed-by: Jose Abreu
Reviewed-by: Alex Deucher
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 215 +
1 file changed, 215 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e66397a..3b494c2 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1001,6 +1001,221 @@ static const struct drm_display_mode edid_cea_modes[] =
{
2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 65 - 1280x720@24Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+ 3080, 3300, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 66 - 1280x720@25Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+ 3740, 3960, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 67 - 1280x720@30Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+ 3080, 3300, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 68 - 1280x720@50Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+ 1760, 1980, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 69 - 1280x720@60Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+ 1430, 1650, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 70 - 1280x720@100Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+ 1760, 1980, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 71 - 1280x720@120Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+ 1430, 1650, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 72 - 1920x1080@24Hz */
+ { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+ 2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 73 - 1920x1080@25Hz */
+ { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+ 2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 74 - 1920x1080@30Hz */
+ { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
+ 2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 75 - 1920x1080@50Hz */
+ { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
+ 2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 76 - 1920x1080@60Hz */
+ { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2008,
+ 2052, 22
[Intel-gfx] [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.
This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.
In case of I915 driver, this patch checks the connector->display_info
to check if the connected display is HDMI 2.0.
Cc: Ville Syrjala
Cc: Jose Abreu
Cc: Andrzej Hajda
Cc: Alex Deucher
Cc: Daniel Vetter
PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++-
drivers/gpu/drm/bridge/sii902x.c | 2 +-
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
drivers/gpu/drm/drm_edid.c| 12 +++-
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
drivers/gpu/drm/i915/intel_hdmi.c | 5 -
drivers/gpu/drm/i915/intel_sdvo.c | 3 ++-
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++-
drivers/gpu/drm/radeon/radeon_audio.c | 2 +-
drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +-
drivers/gpu/drm/sti/sti_hdmi.c| 2 +-
drivers/gpu/drm/tegra/hdmi.c | 2 +-
drivers/gpu/drm/tegra/sor.c | 2 +-
drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +-
drivers/gpu/drm/zte/zx_hdmi.c | 2 +-
include/drm/drm_edid.h| 3 ++-
21 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index d4452d8..ab7a399 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1877,7 +1877,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder
*encoder,
dce_v10_0_audio_write_sad_regs(encoder);
dce_v10_0_audio_write_latency_fields(encoder, mode);
- err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+ err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 5b24e89..3c5fd83 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1861,7 +1861,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder
*encoder,
dce_v11_0_audio_write_sad_regs(encoder);
dce_v11_0_audio_write_latency_fields(encoder, mode);
- err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+ err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index d2590d7..c564dca 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1760,7 +1760,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder
*encoder,
dce_v8_0_audio_write_sad_regs(encoder);
dce_v8_0_audio_write_latency_fields(encoder, mode);
- err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+ err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index a2a8236..f9b77b8 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1097,7 +1097,8 @@ static void anx78xx_bridge_mode_set(struct drm_bridge
*bridge,
mutex_lock(&anx78xx->lock);
- err = drm_hdmi_avi_infoframe_from_display_mode(&frame, adjusted_mode);
+ err = drm_hdmi_avi_infoframe_from_display_mode(&frame, adjusted_mode,
+ false);
if (err) {
DRM_ERROR("Failed to setup AVI infoframe: %d\n", err);
goto unlock;
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index
[Intel-gfx] [PATCH] drm/i915: Check we have an wake device before flushing GTT writes
We can assume that if the device is asleep then all pending GTT writes
will have been posted, and so we can defer the flush from
i915_gem_object_flush_gtt_write_domain()
[ 1957.462568] WARNING: CPU: 0 PID: 6132 at
drivers/gpu/drm/i915/intel_drv.h:1742 fwtable_read32+0x123/0x150 [i915]
[ 1957.462582] RPM wakelock ref not held during HW access
[ 1957.462583] Modules linked in: i915 intel_gtt drm_kms_helper prime_numbers
[ 1957.462607] CPU: 0 PID: 6132 Comm: gem_concurrent_ Tainted: G U
4.11.0-rc1+ #464
[ 1957.462619] Hardware name: /, BIOS
PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[ 1957.462630] Call Trace:
[ 1957.462646] dump_stack+0x4d/0x6f
[ 1957.462657] __warn+0xc1/0xe0
[ 1957.462667] warn_slowpath_fmt+0x4a/0x50
[ 1957.462709] fwtable_read32+0x123/0x150 [i915]
[ 1957.462750] i915_gem_object_flush_gtt_write_domain+0x43/0x70 [i915]
[ 1957.462791] i915_gem_object_set_to_cpu_domain+0x46/0xa0 [i915]
[ 1957.462831] i915_gem_set_domain_ioctl+0x15d/0x220 [i915]
[ 1957.462843] drm_ioctl+0x1d7/0x440
[ 1957.462885] ? i915_gem_obj_prepare_shmem_write+0x1d0/0x1d0 [i915]
[ 1957.462896] ? pick_next_task_fair+0x436/0x440
[ 1957.462906] ? mntput+0x1f/0x30
[ 1957.462915] do_vfs_ioctl+0x8f/0x5c0
[ 1957.462925] ? __schedule+0x16f/0x5f0
[ 1957.462935] ? fput+0x9/0x10
[ 1957.462943] SyS_ioctl+0x3c/0x70
[ 1957.462952] entry_SYSCALL_64_fastpath+0x17/0x98
[ 1957.462961] RIP: 0033:0x7fc542179ca7
[ 1957.462968] RSP: 002b:7ffeef12ff98 EFLAGS: 0246 ORIG_RAX:
0010
[ 1957.462982] RAX: ffda RBX: 7ffeef1301d0 RCX: 7fc542179ca7
[ 1957.462990] RDX: 7ffeef12ffd0 RSI: 400c645f RDI: 0003
[ 1957.462999] RBP: 0003 R08: 55f433bc7c40 R09: 002c
[ 1957.463006] R10: 0073 R11: 0246 R12: 0018
[ 1957.463015] R13: 55f432c89d20 R14: 55f432c87690 R15:
Fixes: 3b5724d702ef ("drm/i915: Wait for writes through the GTT to land before
reading back")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: # v4.9
---
drivers/gpu/drm/i915/i915_gem.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4e66daa12bc9..39d5b849367e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3104,9 +3104,12 @@ i915_gem_object_flush_gtt_write_domain(struct
drm_i915_gem_object *obj)
*/
wmb();
if (INTEL_GEN(dev_priv) >= 6 && !HAS_LLC(dev_priv)) {
- spin_lock_irq(&dev_priv->uncore.lock);
- POSTING_READ_FW(RING_ACTHD(dev_priv->engine[RCS]->mmio_base));
- spin_unlock_irq(&dev_priv->uncore.lock);
+ if (intel_runtime_pm_get_if_in_use(dev_priv)) {
+ spin_lock_irq(&dev_priv->uncore.lock);
+
POSTING_READ_FW(RING_ACTHD(dev_priv->engine[RCS]->mmio_base));
+ spin_unlock_irq(&dev_priv->uncore.lock);
+ intel_runtime_pm_put(dev_priv);
+ }
}
intel_fb_obj_flush(obj, write_origin(obj, I915_GEM_DOMAIN_GTT));
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Store a direct lookup from object handle to vma
On Thu, Mar 23, 2017 at 03:23:28PM +0100, Daniel Vetter wrote: > On Wed, Mar 22, 2017 at 04:22:38PM +0200, Joonas Lahtinen wrote: > > + Daniel for the rsvd2 > > I'd go with a shadow struct definition which matches the uapi one exactly, > except for having a proper name and type for this ... Or we do the > anynomous union thing again. Definitely not an anon union since this is not part of the ABI, just taking advantage of the overallocation in the kernel copy of the user structs. I've plonked it behind a macro so that we have only one point of failure, though realistically expanding the struct or using a lut[] will take more massaging than just renaming the field. It's not a big job so I don't feel like the code is hamstringing our future selves. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [dim PATCH 7/7] dim: propagate errors from check_maintainer
On Thu, Mar 23, 2017 at 12:06:22PM +0200, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
Ack on the entire pile.
-Daniel
> ---
> dim | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/dim b/dim
> index 7b6275e7796f..989674ab7a91 100755
> --- a/dim
> +++ b/dim
> @@ -701,7 +701,9 @@ function dim_apply_branch
> if ! checkpatch_commit HEAD; then
> rv=1
> fi
> - check_maintainer $branch HEAD
> + if ! check_maintainer $branch HEAD; then
> + rv=1
> + fi
>
> eval $DRY $DIM_POST_APPLY_ACTION
>
> @@ -1090,7 +1092,7 @@ function dim_conf
> # $2 commit
> function check_maintainer
> {
> - local branch commit
> + local branch commit rv
>
> branch=$1
> commit=$2
> @@ -1101,8 +1103,11 @@ function check_maintainer
> echo -e "The following files are outside of i915
> maintenance scope:\n"
> echo "$non_i915_files"
> echo -e "\nConfirm you have appropriate Acked-by and
> Reviewed-by for above files."
> + rv=1
> fi
> fi
> +
> + return $rv
> }
>
> # $1 is the git sha1 to check
> --
> 2.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [dim PATCH 1/7] dim: don't fail on grep not matching
On Thu, Mar 23, 2017 at 12:06:16PM +0200, Jani Nikula wrote:
> Oops, the comment told us to watch out for this.
>
> Fixes: 56e53a49e28f ("dim: declare and assign separately")
I just hacked around this with a || true :-)
Ack.
-Daniel
> Signed-off-by: Jani Nikula
> ---
> dim | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/dim b/dim
> index c1ac9e546ea9..ddcc18f17f0d 100755
> --- a/dim
> +++ b/dim
> @@ -1091,10 +1091,7 @@ function checkpatch_commit
> git --no-pager log --oneline -1 $commit
> $cmd | scripts/checkpatch.pl -q --emacs --strict - || true
>
> - # FIXME: this relies on local assignment not failing on command
> - # substitution failures
> - bug_lines=$($cmd | grep -m 1 -B 1 '^\+.*\WBUG' | grep -c '^[+-].*\WBUG')
> - if test "$bug_lines" -eq 1; then
> + if bug_lines=$($cmd | grep -m 1 -B 1 '^\+.*\WBUG' | grep -c
> '^[+-].*\WBUG') && [[ "$bug_lines" = "1" ]]; then
> warn_or_fail "New BUG macro added"
> fi
>
> --
> 2.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/5] drm/i915: SKL+ render decompression support
Hi Ville, On 21 March 2017 at 18:12, wrote: > Another iteration of the i915 CCS support. Main change is lifting the > fb dimensions hsub/vsub alignment restrictions from the core. Without that > userspace would have to align the fb size be a multiple of 8x16 pixels > which isn't something they are interested in doing. With a rebase of Ben's GBM branch[0], and my last Weston atomic series, for Y_CCS this series is: Tested-by: Daniel Stone I had to disable Yf_CCS due to complaints about the kernel's idea of the tiling mode not matching the modifier. Not sure if this is something which has subsequently been fixed, or ... Cheers, Daniel [0]: https://git.collabora.com/cgit/user/daniels/mesa.git/log/?h=wip/2017-03/modifiers-v9-rebased ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Store a direct lookup from object handle to vma
On Wed, Mar 22, 2017 at 04:22:38PM +0200, Joonas Lahtinen wrote:
> + Daniel for the rsvd2
I'd go with a shadow struct definition which matches the uapi one exactly,
except for having a proper name and type for this ... Or we do the
anynomous union thing again.
-Daniel
>
> On ke, 2017-03-22 at 09:33 +, Chris Wilson wrote:
> > The advent of full-ppgtt lead to an extra indirection between the object
> > and its binding. That extra indirection has a noticeable impact on how
> > fast we can convert from the user handles to our internal vma for
> > execbuffer. In order to bypass the extra indirection, we use a
> > resizable hashtable to jump from the object to the per-ctx vma.
> > rhashtable was considered but we don't need the online resizing feature
> > and the extra complexity proved to undermine its usefulness. Instead, we
> > simply reallocate the hastable on demand in a background task and
> > serialize it before iterating.
> >
> > In non-full-ppgtt modes, multiple files and multiple contexts can share
> > the same vma. This leads to having multiple possible handle->vma links,
> > so we only use the first to establish the fast path. The majority of
> > buffers are not shared and so we should still be able to realise
> > speedups with multiple clients.
> >
> > v2: Prettier names, more magic.
> >
> > Signed-off-by: Chris Wilson
>
>
>
> > +static void resize_vma_ht(struct work_struct *work)
> > +{
> > + struct i915_gem_context_vma_lut *lut =
> > + container_of(work, typeof(*lut), resize);
> > + unsigned int size, bits, new_bits, i;
> > + struct hlist_head *new_ht;
> > +
> > + bits = 1 + ilog2(4*lut->ht_count/3);
> > + new_bits = min_t(unsigned int,
> > + max(bits, VMA_HT_BITS),
> > + sizeof(unsigned int)*8);
>
> * BITS_PER_BYTE for extra clarity.
>
> > + if (new_bits == lut->ht_bits)
> > + goto out;
> > +
> > + new_ht = kzalloc(sizeof(*new_ht)< > + if (!new_ht)
> > + new_ht = vzalloc(sizeof(*new_ht)<
> No vcalloc :( Otherwise would've suggested
>
> vzalloc(BIT(new_bits), sizeof(*new_ht), ...);
>
> but
>
> kzalloc(BIT(new_bits)*sizeof(*new_ht), ...)
>
> might still be clearer.
>
> > @@ -266,6 +331,16 @@ __create_hw_context(struct drm_i915_private *dev_priv,
> > list_add_tail(&ctx->link, &dev_priv->context_list);
> > ctx->i915 = dev_priv;
> >
> > + ctx->vma_lut.ht_bits = VMA_HT_BITS;
> > + ctx->vma_lut.ht_size = BIT(VMA_HT_BITS);
> > + ctx->vma_lut.ht = kcalloc(ctx->vma_lut.ht_size,
> > + sizeof(*ctx->vma_lut.ht),
> > + GFP_KERNEL);
> > + if (!ctx->vma_lut.ht)
> > + goto err_out;
> > +
>
> Errors after this point will leak lut. Need err_lut label and call it
> from further error gotos.
>
> > @@ -143,6 +143,31 @@ struct i915_gem_context {
> > /** ggtt_offset_bias: placement restriction for context objects */
> > u32 ggtt_offset_bias;
> >
> > + struct i915_gem_context_vma_lut {
> > + /** ht_size: last request size to allocate the hashtable for. */
> > + unsigned int ht_size;
> > +#define RESIZE_IN_PROGRESS BIT(0)
>
> Easily conflicting name? Forward declare and hide in .c file? By making
> ht[0] at the end, and maybe pull out work. Or maybe just prefix :P
>
> > +#define to_ptr(T, x) ((T *)(uintptr_t)(x))
>
> i915_utils.h so we some day push to core. from_uintptr might make more
> sense, though.
>
> The remainder is somewhat hard to review due to combined code motion
> and changes becoming mess, but didn't find anything else but I still
> dislike rsvd2 usage, and the magic bit it has.
>
> We could at least #define proper_name rsvd2 in the .c file... Jani
> would be glad, I guess. I think if somebody touches a reserved field by
> name, they deserve to have their build broken.
>
> Regards, Joonas
> --
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer
Dropping the irrelevant Cc's. On to, 2017-03-23 at 12:39 +, Chris Wilson wrote: > On Thu, Mar 23, 2017 at 12:22:30PM +, Colin King wrote: > > > > From: Colin Ian King > > > > info is being checked to see if it is a null pointer, however, vpgu is > > dereferencing info before this check, leading to a potential null > > pointer dereference. If info is null, then the error message being > > printed by macro gvt_vgpu_err and this requires vpgu to exist. We can > > use a null vpgu as the macro has a sanity check to see if vpgu is null, > > so this is OK. > > It is never NULL, it gets checked by its only caller. Took me a while to make any sense of the code as gvt_vgpu_err depends on a vgpu variable being declared in the scope without taking it as a parameter and that is a one big no-no: https://01.org/linuxgraphics/gfx-docs/drm/process/coding-style.html#macros-enums-and-rtl Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/execlists: Relax the locked clear_bit(IRQ_EXECLIST)
== Series Details == Series: drm/i915/execlists: Relax the locked clear_bit(IRQ_EXECLIST) URL : https://patchwork.freedesktop.org/series/21767/ State : failure == Summary == Series 21767v1 drm/i915/execlists: Relax the locked clear_bit(IRQ_EXECLIST) https://patchwork.freedesktop.org/api/1.0/series/21767/revisions/1/mbox/ Test drv_module_reload: Subgroup basic-reload: pass -> INCOMPLETE (fi-byt-j1900) Test gem_exec_suspend: Subgroup basic-s3: pass -> DMESG-WARN (fi-byt-j1900) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> FAIL (fi-byt-j1900) Subgroup basic-rte: pass -> FAIL (fi-byt-j1900) fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 468s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 462s fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 time: 577s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 539s fi-byt-j1900 total:274 pass:244 dwarn:1 dfail:0 fail:2 skip:26 time: 0s fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 time: 502s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 444s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 436s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 435s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 516s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 488s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 480s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 480s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 598s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 489s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 522s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 457s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 549s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time: 419s f05fca81afc25c60190fae715e09c3554b16a012 drm-tip: 2017y-03m-23d-13h-08m-10s UTC integration manifest 8149945 drm/i915/execlists: Relax the locked clear_bit(IRQ_EXECLIST) == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4279/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/14] drm/i915: Moar plane update optimizations
On Fri, Mar 17, 2017 at 11:17:54PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The plane updates are still taking far too long, at least with > heavy kernel debug knobs turned on. Using kms_atomic_transitions > I'm currently seeing numbers as high as 170 usec on my VLV. > > To combat lockdep the most beneficial thing is taking the > uncore.lock around the entire pipe update. Combined with all > the other optimizations here I was able to push the max > duration below 60 usec with my debug kernel. > > The pre-compute stuff isn't supremely important with lockdep/etc. > turned on, but once those are turned off the few usec saved by > the other optimizations start to matter. With all the optimization > and a less debug heavy kernel I was able to get the max duration > to around 15 usec. It was around 25 usec with the current code. > > Mika was saying that he's still seeing huge numbers (as high > as 400 usec) with the current drm-tip, and that wasn't even with > a particularly debug heavy kernel. One theory is that there's > contention on the uncore.lock. So I'm thinking we may want to > split the lock into two; one for gt, the other for display. Not > starving the GPU by hogging the shared lock for display stuff > might also be a good thing. I've not tried playing with more > GPU heavy scenarios yet > > Anyways, running out of time to play with this more today so > I figured I'd post what I have now. > > Series available here: > git://github.com/vsyrjala/linux.git plane_update_optimization > > Ville Syrjälä (14): > drm/i915: Extract skl_plane_ctl() > drm/i915: Use skl_plane_ctl() for the SKL "sprite" planes > drm/i915: Extract vlv_sprite_ctl() > drm/i915: Extract ivb_sprite_ctl() > drm/i915: Extract ilk_sprite_ctl() > drm/i915: Extract i845_cursor_ctl() and i9xx_cursor_ctl() I've pushed these to dinq. Thanks for the review. > drm/i915: Extract i9xx_plane_ctl() > drm/i915: Pre-compute plane control register value > drm/i915: Introduce i9xx_check_plane_surface() > drm/i915: Eliminate ironlake_update_primary_plane() > drm/i915: Use i9xx_check_plane_surface() for sprite planes as well I'll repost these as new series. > drm/i915: Keep vblanks enabled during the entire pipe update > WIP/drm/i915: Protect the entire pipe update with uncore.lock > WIP/drm/i915: Nuke posting reads from plane updates And these I'll probably leave out from the next series, and repost separately later. > > drivers/gpu/drm/i915/i915_irq.c | 66 -- > drivers/gpu/drm/i915/i915_trace.h| 28 +-- > drivers/gpu/drm/i915/intel_display.c | 436 > +-- > drivers/gpu/drm/i915/intel_drv.h | 16 +- > drivers/gpu/drm/i915/intel_pm.c | 11 +- > drivers/gpu/drm/i915/intel_sprite.c | 355 > 6 files changed, 440 insertions(+), 472 deletions(-) > > -- > 2.10.2 -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/15] drm/i915: Copy user requested buffers into the error state (rev4)
== Series Details == Series: series starting with [01/15] drm/i915: Copy user requested buffers into the error state (rev4) URL : https://patchwork.freedesktop.org/series/21377/ State : failure == Summary == drivers/gpu/drm/i915/i915_gem_execbuffer.c:1891:1: error: expected expression before ‘<<’ token <<< b63fa3700fd66618174ee4d422c0867a0fc30e0f ^ drivers/gpu/drm/i915/i915_gem_execbuffer.c:2184:1: error: expected declaration or statement at end of input } ^ drivers/gpu/drm/i915/i915_gem_execbuffer.c:1889:3: error: label ‘err_vma’ used but not defined goto err_vma; ^ drivers/gpu/drm/i915/i915_gem_execbuffer.c:1873:3: error: label ‘err_unlock’ used but not defined goto err_unlock; ^ drivers/gpu/drm/i915/i915_gem_execbuffer.c:1869:3: error: label ‘err_rpm’ used but not defined goto err_rpm; ^ drivers/gpu/drm/i915/i915_gem_execbuffer.c:1853:4: error: label ‘err_in_fence’ used but not defined goto err_in_fence; ^ drivers/gpu/drm/i915/i915_gem_execbuffer.c:1793:20: error: unused variable ‘out_fence’ [-Werror=unused-variable] struct sync_file *out_fence = NULL; ^ drivers/gpu/drm/i915/i915_gem_execbuffer.c: At top level: drivers/gpu/drm/i915/i915_gem_execbuffer.c:442:1: error: ‘eb_reserve_vma’ defined but not used [-Werror=unused-function] eb_reserve_vma(struct i915_execbuffer *eb, struct i915_vma *vma) ^ drivers/gpu/drm/i915/i915_gem_execbuffer.c:773:13: error: ‘eb_release_vma’ defined but not used [-Werror=unused-function] static void eb_release_vma(const struct i915_execbuffer *eb) ^ drivers/gpu/drm/i915/i915_gem_execbuffer.c:796:13: error: ‘eb_destroy’ defined but not used [-Werror=unused-function] static void eb_destroy(const struct i915_execbuffer *eb) ^ drivers/gpu/drm/i915/i915_gem_execbuffer.c:1546:1: error: ‘i915_gem_check_execbuffer’ defined but not used [-Werror=unused-function] i915_gem_check_execbuffer(struct drm_i915_gem_execbuffer2 *exec) ^ drivers/gpu/drm/i915/i915_gem_execbuffer.c:1630:25: error: ‘eb_parse’ defined but not used [-Werror=unused-function] static struct i915_vma *eb_parse(struct i915_execbuffer *eb, bool is_master) ^ drivers/gpu/drm/i915/i915_gem_execbuffer.c:1672:1: error: ‘add_to_client’ defined but not used [-Werror=unused-function] add_to_client(struct drm_i915_gem_request *req, ^ drivers/gpu/drm/i915/i915_gem_execbuffer.c:1680:1: error: ‘eb_submit’ defined but not used [-Werror=unused-function] eb_submit(struct i915_execbuffer *eb) ^ drivers/gpu/drm/i915/i915_gem_execbuffer.c:1786:1: error: ‘i915_gem_do_execbuffer’ defined but not used [-Werror=unused-function] i915_gem_do_execbuffer(struct drm_device *dev, ^ cc1: all warnings being treated as errors scripts/Makefile.build:294: recipe for target 'drivers/gpu/drm/i915/i915_gem_execbuffer.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_gem_execbuffer.o] Error 1 make[4]: *** Waiting for unfinished jobs LD drivers/usb/gadget/udc/udc-core.o LD drivers/video/console/built-in.o LD drivers/usb/gadget/udc/built-in.o LD drivers/video/built-in.o LD drivers/usb/gadget/built-in.o LD [M] drivers/net/ethernet/intel/e1000/e1000.o LD net/ipv6/ipv6.o LD net/ipv6/built-in.o LD drivers/tty/serial/8250/8250_base.o LD drivers/scsi/sd_mod.o LD drivers/tty/serial/8250/built-in.o LD drivers/scsi/built-in.o AR lib/lib.a LD drivers/tty/serial/built-in.o LD [M] drivers/net/ethernet/intel/igb/igb.o EXPORTS lib/lib-ksyms.o LD lib/built-in.o LD net/xfrm/built-in.o LD drivers/usb/core/usbcore.o LD drivers/usb/core/built-in.o LD drivers/md/md-mod.o LD drivers/md/built-in.o CC arch/x86/kernel/cpu/capflags.o LD arch/x86/kernel/cpu/built-in.o LD arch/x86/kernel/built-in.o LD drivers/tty/vt/built-in.o LD drivers/usb/host/xhci-hcd.o LD drivers/tty/built-in.o LD fs/btrfs/btrfs.o LD fs/ext4/ext4.o LD arch/x86/built-in.o LD drivers/usb/host/built-in.o LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o LD drivers/usb/built-in.o LD fs/ext4/built-in.o LD fs/btrfs/built-in.o LD net/core/built-in.o LD fs/built-in.o LD net/ipv4/built-in.o LD net/built-in.o LD drivers/net/ethernet/built-in.o LD drivers/net/built-in.o scripts/Makefile.build:553: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:553: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:553: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1002: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman
Re: [Intel-gfx] [PATCH v3] drm/i915/scheduler: add gvt notification for guc submission
> -Original Message-
> From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
> Sent: Thursday, March 23, 2017 5:52 PM
> To: Dong, Chuanxiao; intel-gfx@lists.freedesktop.org
> Cc: intel-gvt-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/scheduler: add gvt notification
> for guc submission
>
>
> On 22/03/2017 06:34, Chuanxiao Dong wrote:
> > GVT request needs a manual mmio load/restore. Before GuC submit a
> > request, send notification to gvt for mmio loading. And after the GuC
> > finished this GVT request, notify gvt again for mmio restore. This
> > follows the usage when using execlists submission.
> >
> > v2: use context_status_change instead of
> execlists_context_status_change
> > for better understanding (ZhengXiao)
> > v3: remove the comment as it is obvious and not friendly to
> > the caller (Kevin)
> >
> > Cc: xiao.zh...@intel.com
> > Cc: kevin.t...@intel.com
> > Signed-off-by: Chuanxiao Dong
> > ---
> > drivers/gpu/drm/i915/i915_guc_submission.c | 3 +++
> > drivers/gpu/drm/i915/intel_lrc.c | 21 +++--
> > drivers/gpu/drm/i915/intel_lrc.h | 13 +
> > 3 files changed, 19 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
> > b/drivers/gpu/drm/i915/i915_guc_submission.c
> > index 055467a..0195547 100644
> > --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> > @@ -520,6 +520,8 @@ static void __i915_guc_submit(struct
> drm_i915_gem_request *rq)
> > unsigned long flags;
> > int b_ret;
> >
> > + context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
> > +
> > /* WA to flush out the pending GMADR writes to ring buffer. */
> > if (i915_vma_is_map_and_fenceable(rq->ring->vma))
> > POSTING_READ_FW(GUC_STATUS);
> > @@ -634,6 +636,7 @@ static void i915_guc_irq_handler(unsigned long data)
> > rq = port[0].request;
> > while (rq && i915_gem_request_completed(rq)) {
> > trace_i915_gem_request_out(rq);
> > + context_status_change(rq,
> INTEL_CONTEXT_SCHEDULE_OUT);
>
> Does GVT care that the context will still be active on the GPU for a small
> window after this notification? (User interrupt happens before context
> complete, which GuC hides from the driver.)
Actually GVT cares. GVT driver will check the context status register to make
sure the status is ACTIVE_IDLE in this notification before manually doing the
context switch out for the GuC submission case.
Thanks
Chuanxiao
>
> Regards,
>
> Tvrtko
>
> > i915_gem_request_put(rq);
> > port[0].request = port[1].request;
> > port[1].request = NULL;
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index eec1e71..24c69b5 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -295,21 +295,6 @@ uint64_t intel_lr_context_descriptor(struct
> i915_gem_context *ctx,
> > return ctx->engine[engine->id].lrc_desc; }
> >
> > -static inline void
> > -execlists_context_status_change(struct drm_i915_gem_request *rq,
> > - unsigned long status)
> > -{
> > - /*
> > -* Only used when GVT-g is enabled now. When GVT-g is disabled,
> > -* The compiler should eliminate this function as dead-code.
> > -*/
> > - if (!IS_ENABLED(CONFIG_DRM_I915_GVT))
> > - return;
> > -
> > - atomic_notifier_call_chain(&rq->engine->context_status_notifier,
> > - status, rq);
> > -}
> > -
> > static void
> > execlists_update_context_pdps(struct i915_hw_ppgtt *ppgtt, u32
> > *reg_state) { @@ -350,7 +335,7 @@ static void
> > execlists_submit_ports(struct intel_engine_cs *engine)
> >
> > GEM_BUG_ON(port[0].count > 1);
> > if (!port[0].count)
> > - execlists_context_status_change(port[0].request,
> > + context_status_change(port[0].request,
> >
> INTEL_CONTEXT_SCHEDULE_IN);
> > desc[0] = execlists_update_context(port[0].request);
> > GEM_DEBUG_EXEC(port[0].context_id = upper_32_bits(desc[0]));
> @@
> > -358,7 +343,7 @@ static void execlists_submit_ports(struct
> > intel_engine_cs *engine)
> >
> > if (port[1].request) {
> > GEM_BUG_ON(port[1].count);
> > - execlists_context_status_change(port[1].request,
> > + context_status_change(port[1].request,
> >
> INTEL_CONTEXT_SCHEDULE_IN);
> > desc[1] = execlists_update_context(port[1].request);
> > GEM_DEBUG_EXEC(port[1].context_id =
> upper_32_bits(desc[1])); @@
> > -581,7 +566,7 @@ static void intel_lrc_irq_handler(unsigned long data)
> > if (--port[0].count == 0) {
> > GEM_BUG_ON(status &
> GEN8_CTX_STATUS_PREEMPTED);
> >
> GEM_BUG_ON(!i915_gem_request_completed(port[0].request
Re: [Intel-gfx] [PATCH v3] drm/i915/scheduler: add gvt notification for guc submission
> -Original Message- > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > Behalf Of Chris Wilson > Sent: Thursday, March 23, 2017 5:43 PM > To: Joonas Lahtinen > Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org; > Dong, Chuanxiao > Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/scheduler: add gvt notification > for guc submission > > On Thu, Mar 23, 2017 at 11:37:32AM +0200, Joonas Lahtinen wrote: > > On ke, 2017-03-22 at 14:34 +0800, Chuanxiao Dong wrote: > > > @@ -87,5 +87,18 @@ uint64_t intel_lr_context_descriptor(struct > > > i915_gem_context *ctx, > > > /* Execlists */ > > > int intel_sanitize_enable_execlists(struct drm_i915_private *dev_priv, > > > int enable_execlists); > > > +static inline void > > > +context_status_change(struct drm_i915_gem_request *rq, unsigned > > > +long status) > > > > This needs intel_lr_ prefix now that it's in .h file. > > But not in this header. The event is not strictly tied to execlists, it > consumes > request for starters - but on the other hand it is gvt specific. > > I'm tempted to say intel_gvt_notify_context_status(). It makes sense. Will change the name in the next version. Thanks Chuanxiao > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > ___ > intel-gvt-dev mailing list > intel-gvt-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/execlists: Relax the locked clear_bit(IRQ_EXECLIST)
We only need to care about the ordering of the clearing of the bit with the uncached CSB read in order to correctly detect a new interrupt before the read completes. The uncached read itself acts as a full memory barrier, so we do not to enforce another in the form of a locked clear_bit. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 59acdd3b7a12..c9010fa881b4 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -540,7 +540,14 @@ static void intel_lrc_irq_handler(unsigned long data) dev_priv->regs + i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)); unsigned int csb, head, tail; - clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted); + /* The write will be ordered by the uncached read (itself +* a memory barrier), we do need another in the form a +* locked instruction. That is the clear of IRQ_EXECLIST bit +* will be visible to another cpu prior to the completion +* of the CSB read. If the other cpu receives an interrupt +* before then, we will redo the CSB read. +*/ + __clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted); csb = readl(csb_mmio); head = GEN8_CSB_READ_PTR(csb); tail = GEN8_CSB_WRITE_PTR(csb); -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/scheduler: add gvt notification for guc submission
> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Thursday, March 23, 2017 5:38 PM
> To: Dong, Chuanxiao; intel-gfx@lists.freedesktop.org
> Cc: intel-gvt-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/scheduler: add gvt notification
> for guc submission
>
> On ke, 2017-03-22 at 14:34 +0800, Chuanxiao Dong wrote:
> > GVT request needs a manual mmio load/restore. Before GuC submit a
> > request, send notification to gvt for mmio loading. And after the GuC
> > finished this GVT request, notify gvt again for mmio restore. This
> > follows the usage when using execlists submission.
> >
> > v2: use context_status_change instead of
> > execlists_context_status_change
> > for better understanding (ZhengXiao)
> > v3: remove the comment as it is obvious and not friendly to
> > the caller (Kevin)
> >
> > Cc: xiao.zh...@intel.com
> > Cc: kevin.t...@intel.com
> > Signed-off-by: Chuanxiao Dong
>
>
>
> > @@ -350,7 +335,7 @@ static void execlists_submit_ports(struct
> > intel_engine_cs *engine)
> >
> > GEM_BUG_ON(port[0].count > 1);
> > if (!port[0].count)
> > - execlists_context_status_change(port[0].request,
> > + context_status_change(port[0].request,
> >
> INTEL_CONTEXT_SCHEDULE_IN);
>
> Fix indent.
>
> > desc[0] = execlists_update_context(port[0].request);
> > GEM_DEBUG_EXEC(port[0].context_id = upper_32_bits(desc[0]));
> @@
> > -358,7 +343,7 @@ static void execlists_submit_ports(struct
> > intel_engine_cs *engine)
> >
> > if (port[1].request) {
> > GEM_BUG_ON(port[1].count);
> > - execlists_context_status_change(port[1].request,
> > + context_status_change(port[1].request,
> >
> INTEL_CONTEXT_SCHEDULE_IN);
>
> Ditto.
>
> > @@ -581,7 +566,7 @@ static void intel_lrc_irq_handler(unsigned long data)
> > if (--port[0].count == 0) {
> > GEM_BUG_ON(status &
> GEN8_CTX_STATUS_PREEMPTED);
> >
> GEM_BUG_ON(!i915_gem_request_completed(port[0].request));
> > -
> execlists_context_status_change(port[0].request,
> > + context_status_change(port[0].request,
> >
> INTEL_CONTEXT_SCHEDULE_OUT);
>
> Ditto.
>
> > @@ -87,5 +87,18 @@ uint64_t intel_lr_context_descriptor(struct
> > i915_gem_context *ctx,
> > /* Execlists */
> > int intel_sanitize_enable_execlists(struct drm_i915_private *dev_priv,
> > int enable_execlists);
> > +static inline void
> > +context_status_change(struct drm_i915_gem_request *rq, unsigned long
> > +status)
>
> This needs intel_lr_ prefix now that it's in .h file.
>
> With those changes (make sure context_status_change doesn't become
> over character 80 line), this is;
Sure. Will fix in the next version.
Thanks
Chuanxiao
>
> Reviewed-by: Joonas Lahtinen
>
> Regards, Joonas
> --
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Make the decision to keep vblank irq enabled earlier
On Thu, Mar 23, 2017 at 07:51:06AM +, Chris Wilson wrote:
> We want to provide the vblank irq shadow for pageflip events as well as
> vblank queries. Such events are completed within the vblank interrupt
> handler, and so the current check for disabling the irq will disable it
> from with the same interrupt as the last pageflip event. If we move the
> decision on whether to disable the irq (based on there no being no
> remaining vblank events, i.e. vblank->refcount == 0) to before we signal
> the events, we will only disable the irq on the interrupt after the last
> event was signaled. In the normal course of events, this will keep the
> vblank irq enabled for the entire flip sequence whereas before it would
> flip-flop around every interrupt.
>
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Michel Dänzer
> Cc: Laurent Pinchart
> Cc: Dave Airlie ,
> Cc: Mario Kleiner
> ---
> drivers/gpu/drm/drm_irq.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 5b77057e91ca..1d6bcee3708f 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1741,6 +1741,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
> int pipe)
> {
> struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
> unsigned long irqflags;
> + bool disable_irq;
>
> if (WARN_ON_ONCE(!dev->num_crtcs))
> return false;
> @@ -1768,16 +1769,19 @@ bool drm_handle_vblank(struct drm_device *dev,
> unsigned int pipe)
> spin_unlock(&dev->vblank_time_lock);
>
> wake_up(&vblank->queue);
> - drm_handle_vblank_events(dev, pipe);
>
> /* With instant-off, we defer disabling the interrupt until after
> - * we finish processing the following vblank. The disable has to
> - * be last (after drm_handle_vblank_events) so that the timestamp
> - * is always accurate.
> + * we finish processing the following vblank after all events have
> + * been signaled. The disable has to be last (after
> + * drm_handle_vblank_events) so that the timestamp is always accurate.
We wouldn't actually do the disable as long there's a reference still
held, so the timestamp should be fine in that case. And if there aren't
any references the timestamp shouldn't matter... I think. But it's
probably more clear to keep to the order you propose here anyway.
Reviewed-by: Ville Syrjälä
Oh, and now that I think about this stuff again, I start to wonder why
I made the disable actually update the seq/ts. If the interrupt is
currently enabled the seq/ts should be reasonably uptodate already
when we do disable the interrupt. Perhaps I was only thinking about
drm_vblank_off() when I made that change, or I decided that I didn't
want two different disable codepaths. Anyways, just an idea that
we might be able to make the vblank irq disable a little cheaper.
>*/
> - if (dev->vblank_disable_immediate &&
> - drm_vblank_offdelay > 0 &&
> - !atomic_read(&vblank->refcount))
> + disable_irq = (dev->vblank_disable_immediate &&
> +drm_vblank_offdelay > 0 &&
> +!atomic_read(&vblank->refcount));
> +
> + drm_handle_vblank_events(dev, pipe);
> +
> + if (disable_irq)
> vblank_disable_fn((unsigned long)vblank);
>
> spin_unlock_irqrestore(&dev->event_lock, irqflags);
> --
> 2.11.0
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Various improvements around the GuC topic
Merged this series except the HAX patch (also, reordered the S-o-b, R-b and Cc lines to canonical form), so do rebase your work. Regards, Joonas On to, 2017-03-23 at 11:06 +, Patchwork wrote: > == Series Details == > > Series: Various improvements around the GuC topic > URL : https://patchwork.freedesktop.org/series/21726/ > State : success > > == Summary == > > Series 21726v1 Various improvements around the GuC topic > https://patchwork.freedesktop.org/api/1.0/series/21726/revisions/1/mbox/ > > fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 > time: 460s > fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 > time: 461s > fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 > time: 593s > fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 > time: 523s > fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 > time: 511s > fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 > time: 502s > fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 > time: 441s > fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 > time: 431s > fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 > time: 436s > fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 > time: 509s > fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 > time: 496s > fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 > time: 478s > fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 > time: 468s > fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 > time: 588s > fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 > time: 480s > fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 > time: 513s > fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 > time: 446s > fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 > time: 558s > fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 > time: 416s > > 8229a8c712c22ff8e94e3244d4fd942a7dcd89af drm-tip: 2017y-03m-23d-09h-57m-34s > UTC integration manifest > f003ba2 HAX Enable GuC loading & submission > 43d51b6 drm/i915/guc: Move guc_interrupts_release next to > guc_interrupts_capture > 19b8f8a drm/i915/guc: Split out the mmio_white_list struct > 22675ac drm/i915/guc: Refactor the concept "GuC context descriptor" into "GuC > stage descriptor" > 98c3280 drm/i915/guc: A little bit more of doorbell sanitization > a5d1810 drm/i915/guc: Wait for doorbell to be inactive before deallocating > cf3850d drm/i915/guc: Improve the GuC documentation & comments about proxy > submissions > 7112b1b drm/i915/guc: Make intel_guc_send a function pointer > cdbbc12 drm/i915/guc: Break out the GuC log extras into their own "runtime" > struct > 0009b27 drm/i915/guc: The Additional Data Struct (ADS) should get enabled > together with GuC submission > c11c121 drm/i915/guc: Add onion teardown to the GuC setup > d1a1ced drm/i915/guc: Keep the ctx_pool_vaddr mapped, for easy access > 5956a8b drm/i915/guc: Sanitize GuC client initialization > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4273/ > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/kvmgt: avoid dereferencing a potentially null info pointer
== Series Details == Series: drm/i915/kvmgt: avoid dereferencing a potentially null info pointer URL : https://patchwork.freedesktop.org/series/21762/ State : warning == Summary == Series 21762v1 drm/i915/kvmgt: avoid dereferencing a potentially null info pointer https://patchwork.freedesktop.org/api/1.0/series/21762/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-snb-2600) fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 455s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 456s fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 time: 582s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 547s fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 time: 508s fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 time: 507s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 441s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 434s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 441s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 521s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 496s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 485s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 486s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 603s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 484s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 523s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 465s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 546s fi-snb-2600 total:278 pass:248 dwarn:1 dfail:0 fail:0 skip:29 time: 420s f99a2e3df860d56c83a726a1183162cb467b2ad4 drm-tip: 2017y-03m-23d-12h-06m-41s UTC integration manifest eee6d67 drm/i915/kvmgt: avoid dereferencing a potentially null info pointer == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4277/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/19] drm: Add acquire ctx parameter to ->update_plane
On Wed, Mar 22, 2017 at 10:50:41PM +0100, Daniel Vetter wrote: > diff --git a/drivers/gpu/drm/armada/armada_overlay.c > b/drivers/gpu/drm/armada/armada_overlay.c > index 34cb73d0db77..b54fd8cbd3a6 100644 > --- a/drivers/gpu/drm/armada/armada_overlay.c > +++ b/drivers/gpu/drm/armada/armada_overlay.c > @@ -94,7 +94,8 @@ static int > armada_ovl_plane_update(struct drm_plane *plane, struct drm_crtc *crtc, > struct drm_framebuffer *fb, > int crtc_x, int crtc_y, unsigned crtc_w, unsigned crtc_h, > - uint32_t src_x, uint32_t src_y, uint32_t src_w, uint32_t src_h) > + uint32_t src_x, uint32_t src_y, uint32_t src_w, uint32_t src_h, > + struct drm_modeset_acquire_ctx *ctx) I'm rather unhappy that we're ending up with a function taking soo many arguments. Most of these have to be stacked on ARM, and I'm guessing most architectures end up doing something similar. Is there a reason why we don't pass pointers to drm_rect's or maybe even consider passing the drm_plane_state structure in? I've found that, when cleaning up these code paths in armada, that storing all the parameters into a drm_plane_state and then validating it with drm_plane_helper_check_state() is by way the simplest solution, and of course, it's forward-compatible with atomic modeset. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Pass vma to relocate entry
We can simplify our tracking of pending writes in an execbuf to the
single bit in the vma->exec_entry->flags, but that requires the
relocation function knowing the object's vma. Pass it along.
Note we have only been using a single bit to track flushing since
commit cc889e0f6ce6a63c62db17d702ecfed86d58083f
Author: Daniel Vetter
Date: Wed Jun 13 20:45:19 2012 +0200
drm/i915: disable flushing_list/gpu_write_list
unconditionally flushed all render caches before the breadcrumb and
commit 6ac42f4148bc27e5ffd18a9ab0eac57f58822af4
Author: Daniel Vetter
Date: Sat Jul 21 12:25:01 2012 +0200
drm/i915: Replace the complex flushing logic with simple invalidate/flush
all
did away with the explicit GPU domain tracking. This was then codified
into the ABI with NO_RELOC in
commit ed5982e6ce5f106abcbf071f80730db344a6da42
Author: Daniel Vetter # Oi! Patch stealer!
Date: Thu Jan 17 22:23:36 2013 +0100
drm/i915: Allow userspace to hint that the relocations were known
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 101 -
1 file changed, 41 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 27868798eb85..a07375bad449 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -622,42 +622,25 @@ relocate_entry(struct drm_i915_gem_object *obj,
}
static int
-eb_relocate_entry(struct drm_i915_gem_object *obj,
+eb_relocate_entry(struct i915_vma *vma,
struct i915_execbuffer *eb,
struct drm_i915_gem_relocation_entry *reloc)
{
- struct drm_gem_object *target_obj;
- struct drm_i915_gem_object *target_i915_obj;
- struct i915_vma *target_vma;
- uint64_t target_offset;
+ struct i915_vma *target;
+ u64 target_offset;
int ret;
/* we've already hold a reference to all valid objects */
- target_vma = eb_get_vma(eb, reloc->target_handle);
- if (unlikely(target_vma == NULL))
+ target = eb_get_vma(eb, reloc->target_handle);
+ if (unlikely(!target))
return -ENOENT;
- target_i915_obj = target_vma->obj;
- target_obj = &target_vma->obj->base;
-
- target_offset = gen8_canonical_addr(target_vma->node.start);
-
- /* Sandybridge PPGTT errata: We need a global gtt mapping for MI and
-* pipe_control writes because the gpu doesn't properly redirect them
-* through the ppgtt for non_secure batchbuffers. */
- if (unlikely(IS_GEN6(eb->i915) &&
-reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION)) {
- ret = i915_vma_bind(target_vma, target_i915_obj->cache_level,
- PIN_GLOBAL);
- if (WARN_ONCE(ret, "Unexpected failure to bind target VMA!"))
- return ret;
- }
/* Validate that the target is in a valid r/w GPU domain */
if (unlikely(reloc->write_domain & (reloc->write_domain - 1))) {
DRM_DEBUG("reloc with multiple write domains: "
- "obj %p target %d offset %d "
+ "target %d offset %d "
"read %08x write %08x",
- obj, reloc->target_handle,
+ reloc->target_handle,
(int) reloc->offset,
reloc->read_domains,
reloc->write_domain);
@@ -666,43 +649,56 @@ eb_relocate_entry(struct drm_i915_gem_object *obj,
if (unlikely((reloc->write_domain | reloc->read_domains)
& ~I915_GEM_GPU_DOMAINS)) {
DRM_DEBUG("reloc with read/write non-GPU domains: "
- "obj %p target %d offset %d "
+ "target %d offset %d "
"read %08x write %08x",
- obj, reloc->target_handle,
+ reloc->target_handle,
(int) reloc->offset,
reloc->read_domains,
reloc->write_domain);
return -EINVAL;
}
- target_obj->pending_read_domains |= reloc->read_domains;
- target_obj->pending_write_domain |= reloc->write_domain;
+ if (reloc->write_domain)
+ target->exec_entry->flags |= EXEC_OBJECT_WRITE;
+
+ /* Sandybridge PPGTT errata: We need a global gtt mapping for MI and
+* pipe_control writes because the gpu doesn't properly redirect them
+* through the ppgtt for non_secure batchbuffers.
+*/
+ if (unlikely(IS_GEN6(eb->i915) &&
+reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION)) {
+ ret = i915_vma_bind(target, target->obj->cache_level,
+ PIN_GLOBAL);
+
Re: [Intel-gfx] [PATCH] drm/scdc: declare drm_scdc_get_scrambling_status
On Wed, 22 Mar 2017, "Sharma, Shashank" wrote:
> Thanks for this patch, Jani.
>
> Reviewed-by: Shashank Sharma
And pushed to drm-misc-next, thanks for the review.
BR,
Jani.
>
>
> Regards
> Shashank
> On 3/22/2017 4:33 PM, Jani Nikula wrote:
>> Fix sparse warning:
>>
>> drivers/gpu/drm/drm_scdc_helper.c:138:6: warning: symbol
>> 'drm_scdc_get_scrambling_status' was not declared. Should it be static?
>>
>> Fixes: 62c58af32c93 ("drm/edid: detect SCDC support in HF-VSDB")
>> Cc: Shashank Sharma
>> Signed-off-by: Jani Nikula
>> ---
>> include/drm/drm_scdc_helper.h | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/include/drm/drm_scdc_helper.h b/include/drm/drm_scdc_helper.h
>> index ab6bcfbceba9..c25122bb490a 100644
>> --- a/include/drm/drm_scdc_helper.h
>> +++ b/include/drm/drm_scdc_helper.h
>> @@ -129,6 +129,8 @@ static inline int drm_scdc_writeb(struct i2c_adapter
>> *adapter, u8 offset,
>> return drm_scdc_write(adapter, offset, &value, sizeof(value));
>> }
>>
>> +bool drm_scdc_get_scrambling_status(struct i2c_adapter *adapter);
>> +
>> /**
>>* drm_scdc_set_scrambling - enable scrambling
>>* @adapter: I2C adapter for DDC channel
>
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 2/7] tests/kms_plane_multiple: Add TEST_ONLY flag
Add TEST_ONLY flag to test atomic modesetting commits without
actual real-life commit.
v2: Use flag to indicate to test with TEST_ONLY flag with atomic
commit
v3: Moved force_test_atomic flag set to 'test_plane_position()'
v4: Fix typo in subject field
Signed-off-by: Mika Kahola
---
tests/kms_plane_multiple.c | 48 --
1 file changed, 38 insertions(+), 10 deletions(-)
diff --git a/tests/kms_plane_multiple.c b/tests/kms_plane_multiple.c
index 93dce6b..84fd411 100644
--- a/tests/kms_plane_multiple.c
+++ b/tests/kms_plane_multiple.c
@@ -365,7 +365,8 @@ test_legacy_plane_position_with_output(data_t *data, enum
pipe pipe,
}
static void
-test_plane_position(data_t *data, enum pipe pipe, bool atomic, uint64_t tiling)
+test_plane_position(data_t *data, enum pipe pipe, bool atomic,
+ bool force_test_atomic, uint64_t tiling)
{
igt_output_t *output;
int connected_outs;
@@ -379,6 +380,8 @@ test_plane_position(data_t *data, enum pipe pipe, bool
atomic, uint64_t tiling)
tiling == LOCAL_I915_FORMAT_MOD_Yf_TILED))
igt_require(AT_LEAST_GEN(devid, 9));
+ data->display.force_test_atomic = force_test_atomic;
+
if (!opt.user_seed)
opt.seed = time(NULL);
@@ -421,46 +424,71 @@ run_tests_for_pipe(data_t *data, enum pipe pipe)
igt_require(data->display.pipes[pipe].n_planes > 0);
}
-
igt_subtest_f("legacy-pipe-%s-tiling-none",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, false,
LOCAL_DRM_FORMAT_MOD_NONE);
+ test_plane_position(data, pipe, false, false,
+ LOCAL_DRM_FORMAT_MOD_NONE);
igt_subtest_f("atomic-pipe-%s-tiling-none",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, true,
LOCAL_I915_FORMAT_MOD_X_TILED);
+ test_plane_position(data, pipe, true, false,
+ LOCAL_I915_FORMAT_MOD_X_TILED);
igt_subtest_f("legacy-pipe-%s-tiling-x",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, false,
LOCAL_I915_FORMAT_MOD_X_TILED);
+ test_plane_position(data, pipe, false, false,
+ LOCAL_I915_FORMAT_MOD_X_TILED);
igt_subtest_f("atomic-pipe-%s-tiling-x",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, true,
LOCAL_I915_FORMAT_MOD_X_TILED);
+ test_plane_position(data, pipe, true, false,
+ LOCAL_I915_FORMAT_MOD_X_TILED);
igt_subtest_f("legacy-pipe-%s-tiling-y",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, false,
LOCAL_I915_FORMAT_MOD_Y_TILED);
+ test_plane_position(data, pipe, false, false,
+ LOCAL_I915_FORMAT_MOD_Y_TILED);
igt_subtest_f("atomic-pipe-%s-tiling-y",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, true,
LOCAL_I915_FORMAT_MOD_Y_TILED);
+ test_plane_position(data, pipe, true, false,
+ LOCAL_I915_FORMAT_MOD_Y_TILED);
igt_subtest_f("legacy-pipe-%s-tiling-yf",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, false,
LOCAL_I915_FORMAT_MOD_Yf_TILED);
+ test_plane_position(data, pipe, false, false,
+ LOCAL_I915_FORMAT_MOD_Yf_TILED);
igt_subtest_f("atomic-pipe-%s-tiling-yf",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, true,
LOCAL_I915_FORMAT_MOD_Yf_TILED);
+ test_plane_position(data, pipe, true, false,
+ LOCAL_I915_FORMAT_MOD_Yf_TILED);
+
+ igt_subtest_f("atomic-pipe-%s-tiling-x-with-test",
+ kmstest_pipe_name(pipe))
+ for_each_valid_output_on_pipe(&data->display, pipe, output)
+ test_pl
Re: [Intel-gfx] [PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack
On Thu, Mar 23, 2017 at 11:32:49AM +0100, Thomas Hellstrom wrote: > On 03/23/2017 11:10 AM, Daniel Vetter wrote: > > On Thu, Mar 23, 2017 at 09:35:25AM +0100, Thomas Hellstrom wrote: > >> Hi, Daniel, > >> > >> On 03/23/2017 08:31 AM, Daniel Vetter wrote: > >>> On Thu, Mar 23, 2017 at 08:28:32AM +0100, Daniel Vetter wrote: > On Thu, Mar 23, 2017 at 07:22:31AM +0100, Thomas Hellstrom wrote: > > On 03/22/2017 10:50 PM, Daniel Vetter wrote: > >> It's been around forever, no one bothered to address the FIXME, so I > >> presume it's all fine. > >> > >> Cc: Sinclair Yeh > >> Cc: Thomas Hellstrom > >> Signed-off-by: Daniel Vetter > > NAK. We need to properly address this. Probably as part of the atomic > > update. > So could someone with vmwgfx understanding explain this? Note that the > FIXME was originally added by me years ago, because I wasn't sure (only > about 90%) that this is safe, and was essentially pleading for a vmwgfx > expert to review this? > > Since it didn't happen I presume it's not that terribly and probably safe > ... > > I'm still 90% sure that this is correct, but I'd love for a vmwgfx to > audit it. Replying with a NAK is kinda not the response I was hoping for > (and yes I guess I should have explained what's going on here better, but > it's just a git blame of the FIXME comment away). > >> So the code has been left in place because it works. Altering it now > >> will create unnecessary merge conflicts with the atomic code, and the > >> change isn't tested and audited which means we need to drop focus from > >> what we're doing and audit and test code that isn't going to be used > >> anyway for not apparent reason? But otoh put in the below context there > >> indeed is a reason. > >> > >> From a quick audit of the existing code it seems like at least > >> vmw_cursor_update_position is touching global device state so I think at > >> a minimum we need to take a spinlock in that function. Otherwise it > >> seems to be safe. > > Note that you're holding the crtc lock already, which gives you exclusion > > against concurrent page_flips, mode_sets and property changes. Note also > > that page_flips themselves also only hold the crtc lock, so you can run > > multiple page_flips in parallel on different crtc (iirc vmwgfx has > > multiple crtc, if not this discussion is entirely moot). > > > > tbh I'd be surprised if my patch really breaks something that hasn't been > > a pre-existing issue for a long time. The original commit which added this > > FIXME comment is from 2012. Note also that because it's a hack, you > > already have a pretty a real race with the core drm state keeping, and no > > one seems to have hit that either. > > > > I mean I can dig through vmwgfx code and do the audit, but it'll take a > > few hours and vmwgfx is it's own world, so much harder to understand (for > > me). > > > > I'm thinking of the situation when someone would call a cursor_set ioctl > in parallell > for two crtcs at the same time and race writing the position registers? > Note that the device has only a single global cursor. > Admittedly the effects of a race would probably be small, but I'd rather > see it being > properly protected. Hm, didn't realize you only have 1 cursor for everything together. In that case you indeed have a problem. Not sure why that didn't come up 4 years ago with the original patch, would be pretty easy to add a quite mutex in v2 ... Since read-only global state is perfectly fine, having the crtc lock gives you a read-only global state lock (for legacy drivers at least, not for atomic). > > >> But I prefer if we can do that as part of the atomic update? > > When does that vmwgfx atomic happen? > > We're targeting 4.12, which means the code that is currently under > testing will need to be sent out for review pretty soon. > It's already in our standalone testing repo at > > git://git.freedesktop.org/git/mesa/vmwgfx Deadline is in 2 weeks for 4.12 feature work, per the discussion we've had after the 4.11 merge window fallout with Linus. You pretty much have to submit the patches now to have a reasonable chance of them landing in time. Since vmwgfx has traditionally been the odd kms driver out I'd really like to give the new atomic code at least a quick read-through, to make sure it's aligned as much as possible with the other 20+ atomic drivers. > but the cursor code hasn't been fixed in that repo yet. Well if you switched to universal planes it's pretty easy to fix with the acquire ctx and grabbing mode_config.connection_mutex. Without that you can just add a global cursor mutex (equally few lines) to patch it up. > > BTW is this blocking some other core drm work you're doing? Just removing lock_crtc and preventing abuse from spreading. Somehow both tegra and tilcdc starting using it in places it was definitely not meant for. vmwgfx (with this FIXME here) was the only legit
[Intel-gfx] [PATCH i-g-t v4 3/7] tests/kms_atomic_transition: Add TEST_ONLY flag
Add TEST_ONLY flag to test atomic transition display commits without
actual real-life commit.
v2: use flag to force atomic commit with TEST_ONLY flag
v3: Rebase
Signed-off-by: Mika Kahola
---
tests/kms_atomic_transition.c | 72 +++
1 file changed, 59 insertions(+), 13 deletions(-)
diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index 70bff20..466280e 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -397,7 +397,8 @@ static void atomic_commit(igt_display_t *display, enum pipe
pipe, unsigned int f
*/
static void
run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t
*output,
- enum transition_type type, bool nonblocking, bool fencing)
+ enum transition_type type, bool nonblocking, bool fencing,
+ bool force_test_atomic)
{
struct igt_fb fb, argb_fb, sprite_fb;
drmModeModeInfo *mode, override_mode;
@@ -408,6 +409,8 @@ run_transition_test(igt_display_t *display, enum pipe pipe,
igt_output_t *output
unsigned flags = DRM_MODE_PAGE_FLIP_EVENT;
int ret;
+ display->force_test_atomic = force_test_atomic;
+
if (fencing)
prepare_fencing(display, pipe);
@@ -782,12 +785,15 @@ cleanup:
}
-static void run_modeset_transition(igt_display_t *display, int
requested_outputs, bool nonblocking, bool fencing)
+static void run_modeset_transition(igt_display_t *display, int
requested_outputs,
+ bool nonblocking, bool fencing, bool
force_test_atomic)
{
igt_output_t *outputs[I915_MAX_PIPES] = {};
int num_outputs = 0;
enum pipe pipe;
+ display->force_test_atomic = force_test_atomic;
+
for_each_pipe(display, pipe) {
igt_output_t *output;
@@ -845,44 +851,84 @@ igt_main
igt_subtest("plane-all-transition")
for_each_pipe_with_valid_output(&display, pipe, output)
- run_transition_test(&display, pipe, output,
TRANSITION_PLANES, false, false);
+ run_transition_test(&display, pipe, output,
TRANSITION_PLANES, false, false, false);
+
+ igt_subtest("plane-all-transition-with-test")
+ for_each_pipe_with_valid_output(&display, pipe, output)
+ run_transition_test(&display, pipe, output,
TRANSITION_PLANES, false, false, true);
igt_subtest("plane-all-transition-fencing")
for_each_pipe_with_valid_output(&display, pipe, output)
- run_transition_test(&display, pipe, output,
TRANSITION_PLANES, false, true);
+ run_transition_test(&display, pipe, output,
TRANSITION_PLANES, false, true, false);
+
+ igt_subtest("plane-all-transition-fencing-with-test")
+ for_each_pipe_with_valid_output(&display, pipe, output)
+ run_transition_test(&display, pipe, output,
TRANSITION_PLANES, false, true, true);
igt_subtest("plane-all-transition-nonblocking")
for_each_pipe_with_valid_output(&display, pipe, output)
- run_transition_test(&display, pipe, output,
TRANSITION_PLANES, true, false);
+ run_transition_test(&display, pipe, output,
TRANSITION_PLANES, true, false, false);
+
+ igt_subtest("plane-all-transition-nonblocking-with-test")
+ for_each_pipe_with_valid_output(&display, pipe, output)
+ run_transition_test(&display, pipe, output,
TRANSITION_PLANES, true, false, true);
igt_subtest("plane-all-transition-nonblocking-fencing")
for_each_pipe_with_valid_output(&display, pipe, output)
- run_transition_test(&display, pipe, output,
TRANSITION_PLANES, true, true);
+ run_transition_test(&display, pipe, output,
TRANSITION_PLANES, true, true, false);
+
+ igt_subtest("plane-all-transition-nonblocking-fencing-with-test")
+ for_each_pipe_with_valid_output(&display, pipe, output)
+ run_transition_test(&display, pipe, output,
TRANSITION_PLANES, true, true, true);
igt_subtest("plane-all-modeset-transition")
for_each_pipe_with_valid_output(&display, pipe, output)
- run_transition_test(&display, pipe, output,
TRANSITION_MODESET, false, false);
+ run_transition_test(&display, pipe, output,
TRANSITION_MODESET, false, false, false);
+
+ igt_subtest("plane-all-modeset-transition-with-test")
+ for_each_pipe_with_valid_output(&display, pipe, output)
+ run_transition_test(&display, pipe, output,
TRANSITION_MODESET, false, false, true);
igt_subtest("plane-all-modeset-transition-fencing")
for_each_pipe_with_valid_output(&display, pipe, output)
- run_
[Intel-gfx] [PATCH i-g-t v4 7/7] tests/kms_cursor_legacy: Add TEST_ONLY flag
Add TEST_ONLY flag to test atomic modesetting commits without
actual real-life commit.
Signed-off-by: Mika Kahola
---
tests/kms_cursor_legacy.c | 230 --
1 file changed, 204 insertions(+), 26 deletions(-)
diff --git a/tests/kms_cursor_legacy.c b/tests/kms_cursor_legacy.c
index 8a8c71b..6f79ad8 100644
--- a/tests/kms_cursor_legacy.c
+++ b/tests/kms_cursor_legacy.c
@@ -1441,53 +1441,165 @@ igt_main
igt_subtest("all-pipes-torture-move")
stress(&display, -1, -ncpus, DRM_MODE_CURSOR_MOVE, 20);
- igt_subtest("nonblocking-modeset-vs-cursor-atomic")
+ igt_subtest("nonblocking-modeset-vs-cursor-atomic") {
+ display.force_test_atomic = false;
nonblocking_modeset_vs_cursor(&display, 1);
+ }
- igt_subtest("long-nonblocking-modeset-vs-cursor-atomic")
+ igt_subtest("nonblocking-modeset-vs-cursor-atomic-with-test") {
+ display.force_test_atomic = true;
+ nonblocking_modeset_vs_cursor(&display, 1);
+ }
+
+ igt_subtest("long-nonblocking-modeset-vs-cursor-atomic") {
+ display.force_test_atomic = false;
+ nonblocking_modeset_vs_cursor(&display, 16);
+ }
+
+ igt_subtest("long-nonblocking-modeset-vs-cursor-atomic-with-test") {
+ display.force_test_atomic = true;
nonblocking_modeset_vs_cursor(&display, 16);
+ }
- igt_subtest("2x-flip-vs-cursor-legacy")
+ igt_subtest("2x-flip-vs-cursor-legacy") {
+ display.force_test_atomic = false;
two_screens_flip_vs_cursor(&display, 8, false, false);
+ }
+
+ igt_subtest("2x-flip-vs-cursor-legacy-with-test") {
+ display.force_test_atomic = true;
+ two_screens_flip_vs_cursor(&display, 8, false, false);
+ }
+
+ igt_subtest("2x-flip-vs-cursor-atomic") {
+ display.force_test_atomic = false;
+ two_screens_flip_vs_cursor(&display, 4, false, true);
+ }
- igt_subtest("2x-flip-vs-cursor-atomic")
+ igt_subtest("2x-flip-vs-cursor-atomic-with-test") {
+ display.force_test_atomic = true;
two_screens_flip_vs_cursor(&display, 4, false, true);
+ }
- igt_subtest("2x-cursor-vs-flip-legacy")
+ igt_subtest("2x-cursor-vs-flip-legacy") {
+ display.force_test_atomic = false;
two_screens_cursor_vs_flip(&display, 8, false);
+ }
- igt_subtest("2x-long-flip-vs-cursor-legacy")
+ igt_subtest("2x-cursor-vs-flip-legacy-with-test") {
+ display.force_test_atomic = true;
+ two_screens_cursor_vs_flip(&display, 8, false);
+ }
+
+ igt_subtest("2x-long-flip-vs-cursor-legacy") {
+ display.force_test_atomic = false;
+ two_screens_flip_vs_cursor(&display, 150, false, false);
+ }
+
+ igt_subtest("2x-long-flip-vs-cursor-legacy-with-test") {
+ display.force_test_atomic = true;
two_screens_flip_vs_cursor(&display, 150, false, false);
+ }
- igt_subtest("2x-long-flip-vs-cursor-atomic")
+ igt_subtest("2x-long-flip-vs-cursor-atomic") {
+ display.force_test_atomic = false;
two_screens_flip_vs_cursor(&display, 150, false, true);
+ }
+
+ igt_subtest("2x-long-flip-vs-cursor-atomic-with-test") {
+ display.force_test_atomic = true;
+ two_screens_flip_vs_cursor(&display, 150, false, true);
+ }
+
+ igt_subtest("2x-long-cursor-vs-flip-legacy") {
+ display.force_test_atomic = false;
+ two_screens_cursor_vs_flip(&display, 50, false);
+ }
- igt_subtest("2x-long-cursor-vs-flip-legacy")
+ igt_subtest("2x-long-cursor-vs-flip-legacy-with-test") {
+ display.force_test_atomic = true;
two_screens_cursor_vs_flip(&display, 50, false);
+ }
- igt_subtest("2x-nonblocking-modeset-vs-cursor-atomic")
+ igt_subtest("2x-nonblocking-modeset-vs-cursor-atomic") {
+ display.force_test_atomic = false;
two_screens_flip_vs_cursor(&display, 8, true, true);
+ }
- igt_subtest("2x-cursor-vs-flip-atomic")
+ igt_subtest("2x-nonblocking-modeset-vs-cursor-atomic-with-test") {
+ display.force_test_atomic = true;
+ two_screens_flip_vs_cursor(&display, 8, true, true);
+ }
+
+ igt_subtest("2x-cursor-vs-flip-atomic") {
+ display.force_test_atomic = false;
+ two_screens_cursor_vs_flip(&display, 8, true);
+ }
+
+ igt_subtest("2x-cursor-vs-flip-atomic-with-test") {
+ display.force_test_atomic = true;
two_screens_cursor_vs_flip(&display, 8, true);
+ }
- igt_subtest("2x-long-nonblocking-modeset-vs-cursor-atomic")
+ igt_subtest(
[Intel-gfx] [PATCH i-g-t v4 2/7] tests/kms_plane_multiple: Add TEST_ONLY flag Cc: maarten.lankho...@linux.intel.com
Add TEST_ONLY flag to test atomic modesetting commits without
actual real-life commit.
v2: Use flag to indicate to test with TEST_ONLY flag with atomic
commit
v3: Moved force_test_atomic flag set to 'test_plane_position()'
Signed-off-by: Mika Kahola
---
tests/kms_plane_multiple.c | 48 --
1 file changed, 38 insertions(+), 10 deletions(-)
diff --git a/tests/kms_plane_multiple.c b/tests/kms_plane_multiple.c
index 93dce6b..84fd411 100644
--- a/tests/kms_plane_multiple.c
+++ b/tests/kms_plane_multiple.c
@@ -365,7 +365,8 @@ test_legacy_plane_position_with_output(data_t *data, enum
pipe pipe,
}
static void
-test_plane_position(data_t *data, enum pipe pipe, bool atomic, uint64_t tiling)
+test_plane_position(data_t *data, enum pipe pipe, bool atomic,
+ bool force_test_atomic, uint64_t tiling)
{
igt_output_t *output;
int connected_outs;
@@ -379,6 +380,8 @@ test_plane_position(data_t *data, enum pipe pipe, bool
atomic, uint64_t tiling)
tiling == LOCAL_I915_FORMAT_MOD_Yf_TILED))
igt_require(AT_LEAST_GEN(devid, 9));
+ data->display.force_test_atomic = force_test_atomic;
+
if (!opt.user_seed)
opt.seed = time(NULL);
@@ -421,46 +424,71 @@ run_tests_for_pipe(data_t *data, enum pipe pipe)
igt_require(data->display.pipes[pipe].n_planes > 0);
}
-
igt_subtest_f("legacy-pipe-%s-tiling-none",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, false,
LOCAL_DRM_FORMAT_MOD_NONE);
+ test_plane_position(data, pipe, false, false,
+ LOCAL_DRM_FORMAT_MOD_NONE);
igt_subtest_f("atomic-pipe-%s-tiling-none",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, true,
LOCAL_I915_FORMAT_MOD_X_TILED);
+ test_plane_position(data, pipe, true, false,
+ LOCAL_I915_FORMAT_MOD_X_TILED);
igt_subtest_f("legacy-pipe-%s-tiling-x",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, false,
LOCAL_I915_FORMAT_MOD_X_TILED);
+ test_plane_position(data, pipe, false, false,
+ LOCAL_I915_FORMAT_MOD_X_TILED);
igt_subtest_f("atomic-pipe-%s-tiling-x",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, true,
LOCAL_I915_FORMAT_MOD_X_TILED);
+ test_plane_position(data, pipe, true, false,
+ LOCAL_I915_FORMAT_MOD_X_TILED);
igt_subtest_f("legacy-pipe-%s-tiling-y",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, false,
LOCAL_I915_FORMAT_MOD_Y_TILED);
+ test_plane_position(data, pipe, false, false,
+ LOCAL_I915_FORMAT_MOD_Y_TILED);
igt_subtest_f("atomic-pipe-%s-tiling-y",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, true,
LOCAL_I915_FORMAT_MOD_Y_TILED);
+ test_plane_position(data, pipe, true, false,
+ LOCAL_I915_FORMAT_MOD_Y_TILED);
igt_subtest_f("legacy-pipe-%s-tiling-yf",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, false,
LOCAL_I915_FORMAT_MOD_Yf_TILED);
+ test_plane_position(data, pipe, false, false,
+ LOCAL_I915_FORMAT_MOD_Yf_TILED);
igt_subtest_f("atomic-pipe-%s-tiling-yf",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, true,
LOCAL_I915_FORMAT_MOD_Yf_TILED);
+ test_plane_position(data, pipe, true, false,
+ LOCAL_I915_FORMAT_MOD_Yf_TILED);
+
+ igt_subtest_f("atomic-pipe-%s-tiling-x-with-test",
+ kmstest_pipe_name(pipe))
+ for_each_valid_output_on_pipe(&data->display, pipe, output)
+ test_plane_position(data, pipe, true,
[Intel-gfx] [PATCH i-g-t v4 2/3] tests/kms_plane_multiple: Add TEST_ONLY flag Cc: maarten.lankho...@linux.intel.com
Add TEST_ONLY flag to test atomic modesetting commits without
actual real-life commit.
v2: Use flag to indicate to test with TEST_ONLY flag with atomic
commit
v3: Moved force_test_atomic flag set to 'test_plane_position()'
Signed-off-by: Mika Kahola
---
tests/kms_plane_multiple.c | 48 --
1 file changed, 38 insertions(+), 10 deletions(-)
diff --git a/tests/kms_plane_multiple.c b/tests/kms_plane_multiple.c
index 93dce6b..84fd411 100644
--- a/tests/kms_plane_multiple.c
+++ b/tests/kms_plane_multiple.c
@@ -365,7 +365,8 @@ test_legacy_plane_position_with_output(data_t *data, enum
pipe pipe,
}
static void
-test_plane_position(data_t *data, enum pipe pipe, bool atomic, uint64_t tiling)
+test_plane_position(data_t *data, enum pipe pipe, bool atomic,
+ bool force_test_atomic, uint64_t tiling)
{
igt_output_t *output;
int connected_outs;
@@ -379,6 +380,8 @@ test_plane_position(data_t *data, enum pipe pipe, bool
atomic, uint64_t tiling)
tiling == LOCAL_I915_FORMAT_MOD_Yf_TILED))
igt_require(AT_LEAST_GEN(devid, 9));
+ data->display.force_test_atomic = force_test_atomic;
+
if (!opt.user_seed)
opt.seed = time(NULL);
@@ -421,46 +424,71 @@ run_tests_for_pipe(data_t *data, enum pipe pipe)
igt_require(data->display.pipes[pipe].n_planes > 0);
}
-
igt_subtest_f("legacy-pipe-%s-tiling-none",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, false,
LOCAL_DRM_FORMAT_MOD_NONE);
+ test_plane_position(data, pipe, false, false,
+ LOCAL_DRM_FORMAT_MOD_NONE);
igt_subtest_f("atomic-pipe-%s-tiling-none",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, true,
LOCAL_I915_FORMAT_MOD_X_TILED);
+ test_plane_position(data, pipe, true, false,
+ LOCAL_I915_FORMAT_MOD_X_TILED);
igt_subtest_f("legacy-pipe-%s-tiling-x",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, false,
LOCAL_I915_FORMAT_MOD_X_TILED);
+ test_plane_position(data, pipe, false, false,
+ LOCAL_I915_FORMAT_MOD_X_TILED);
igt_subtest_f("atomic-pipe-%s-tiling-x",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, true,
LOCAL_I915_FORMAT_MOD_X_TILED);
+ test_plane_position(data, pipe, true, false,
+ LOCAL_I915_FORMAT_MOD_X_TILED);
igt_subtest_f("legacy-pipe-%s-tiling-y",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, false,
LOCAL_I915_FORMAT_MOD_Y_TILED);
+ test_plane_position(data, pipe, false, false,
+ LOCAL_I915_FORMAT_MOD_Y_TILED);
igt_subtest_f("atomic-pipe-%s-tiling-y",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, true,
LOCAL_I915_FORMAT_MOD_Y_TILED);
+ test_plane_position(data, pipe, true, false,
+ LOCAL_I915_FORMAT_MOD_Y_TILED);
igt_subtest_f("legacy-pipe-%s-tiling-yf",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, false,
LOCAL_I915_FORMAT_MOD_Yf_TILED);
+ test_plane_position(data, pipe, false, false,
+ LOCAL_I915_FORMAT_MOD_Yf_TILED);
igt_subtest_f("atomic-pipe-%s-tiling-yf",
kmstest_pipe_name(pipe))
for_each_valid_output_on_pipe(&data->display, pipe, output)
- test_plane_position(data, pipe, true,
LOCAL_I915_FORMAT_MOD_Yf_TILED);
+ test_plane_position(data, pipe, true, false,
+ LOCAL_I915_FORMAT_MOD_Yf_TILED);
+
+ igt_subtest_f("atomic-pipe-%s-tiling-x-with-test",
+ kmstest_pipe_name(pipe))
+ for_each_valid_output_on_pipe(&data->display, pipe, output)
+ test_plane_position(data, pipe, true,
[Intel-gfx] [PATCH i-g-t v4 4/7] tests/kms_plane_scaling: Add TEST_ONLY flag
Add TEST_ONLY flag to test atomic scaling without
actually committing the changes.
v2: Create subtests with TEST_ONLY flag and one without
v3: Rename subtest 'force-atomic-test' as 'with-atomic-test'
Signed-off-by: Mika Kahola
---
tests/kms_plane_scaling.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/tests/kms_plane_scaling.c b/tests/kms_plane_scaling.c
index 1457894..8db91c3 100644
--- a/tests/kms_plane_scaling.c
+++ b/tests/kms_plane_scaling.c
@@ -310,21 +310,33 @@ static void test_plane_scaling(data_t *d)
igt_require_f(valid_tests, "no valid crtc/connector combinations
found\n");
}
-igt_simple_main
+igt_main
{
data_t data = {};
igt_skip_on_simulation();
+ igt_fixture {
+ data.drm_fd = drm_open_driver(DRIVER_INTEL);
+ igt_require_pipe_crc(data.drm_fd);
+ igt_display_init(&data.display, data.drm_fd);
+ data.devid = intel_get_drm_devid(data.drm_fd);
+ data.num_scalers = intel_gen(data.devid) >= 9 ? 2 : 0;
+ }
- data.drm_fd = drm_open_driver(DRIVER_INTEL);
- igt_require_pipe_crc(data.drm_fd);
- igt_display_init(&data.display, data.drm_fd);
- data.devid = intel_get_drm_devid(data.drm_fd);
+ igt_subtest("with-atomic-test") {
+ data.display.force_test_atomic = true;
+ test_plane_scaling(&data);
+ }
- data.num_scalers = intel_gen(data.devid) >= 9 ? 2 : 0;
+ igt_subtest("normal") {
+ data.display.force_test_atomic = false;
+ test_plane_scaling(&data);
+ }
- test_plane_scaling(&data);
+ igt_fixture {
+ igt_display_fini(&data.display);
+ }
- igt_display_fini(&data.display);
+ igt_exit();
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 1/7] lib/igt_kms: Add forcing TEST_ONLY for atomic commits
Add an option to force atomic commits to do commits with TEST_ONLY flag
first before doing the actual commit.
v2: Clear force_test_atomic flag if atomic commit with TEST_ONLY
flag fails (Maarten)
Signed-off-by: Mika Kahola
---
lib/igt_kms.c | 22 +-
lib/igt_kms.h | 1 +
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index d9f9672..a687939 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -2436,7 +2436,27 @@ static int igt_atomic_commit(igt_display_t *display,
uint32_t flags, void *user_
igt_atomic_prepare_connector_commit(output, req);
}
- ret = drmModeAtomicCommit(display->drm_fd, req, flags, user_data);
+ if (display->force_test_atomic &&
+ !(flags & DRM_MODE_ATOMIC_TEST_ONLY)) {
+ unsigned int test_flags = flags & ~DRM_MODE_PAGE_FLIP_EVENT;
+ int test_ret;
+
+ test_flags |= DRM_MODE_ATOMIC_TEST_ONLY;
+
+ test_ret = drmModeAtomicCommit(display->drm_fd, req,
test_flags, user_data);
+ ret = drmModeAtomicCommit(display->drm_fd, req, flags,
user_data);
+
+ if (test_ret) {
+ if (test_ret != ret)
+ display->force_test_atomic = false;
+
+ igt_assert_eq(test_ret, ret);
+ } else {
+ igt_assert(ret != -EINVAL);
+ }
+ } else
+ ret = drmModeAtomicCommit(display->drm_fd, req, flags,
user_data);
+
if (!ret) {
for_each_pipe(display, pipe) {
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 595832d..2972e94 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -368,6 +368,7 @@ struct igt_display {
igt_pipe_t *pipes;
bool has_cursor_plane;
bool is_atomic;
+ bool force_test_atomic;
};
void igt_display_init(igt_display_t *display, int drm_fd);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
