Re: [Intel-gfx] [PATCH 3/3] drm/i915/execlists: Read the context-status HEAD from the HWSP

[Chris Wilson]

Quoting Michel Thierry (2017-07-13 01:38:18)
> On 7/12/2017 4:41 PM, Daniele Ceraolo Spurio wrote:
> > 
> > 
> > On 12/07/17 15:58, Chris Wilson wrote:
> >> The engine provides also provides mirror of the CSB write pointer in the
> >> HWSP, but not of our read pointer. To take advantage of this we need to
> >> remember where we read up to on the last interrupt and continue off from
> >> there. This poses a problem following a reset, as we don't know where
> >> the hw will start writing from, and due to the use of power contexts we
> >> cannot perform that query during the reset itself. So we continue the
> >> current modus operandi of delaying the first read of the context-status
> >> read/write pointers until after the first interrupt. With this we should
> >> now have eliminated all uncached mmio reads in handling the
> >> context-status interrupt, though we still have the uncached mmio writes
> >> for submitting new work, and many uncached mmio reads in the global
> >> interrupt handler itself. Still a step in the right direction towards
> >> reducing our resubmit latency, although it appears lost in the noise!
> >>
> >> Signed-off-by: Chris Wilson 
> >> Cc: Michel Thierry 
> >> Cc: Tvrtko Ursulin 
> >> Cc: Mika Kuoppala 
> >> ---
> >>drivers/gpu/drm/i915/intel_lrc.c| 20 +++-
> >>drivers/gpu/drm/i915/intel_ringbuffer.h |  1 +
> >>2 files changed, 16 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >> b/drivers/gpu/drm/i915/intel_lrc.c
> >> index e413465a552b..db750abb905e 100644
> >> --- a/drivers/gpu/drm/i915/intel_lrc.c
> >> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> >> @@ -562,9 +562,15 @@ static void intel_lrc_irq_handler(unsigned long data)
> >> * is set and we do a new loop.
> >> */
> >>__clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
> >> - head = readl(csb_mmio);
> >> - tail = GEN8_CSB_WRITE_PTR(head);
> >> - head = GEN8_CSB_READ_PTR(head);
> >> + if (unlikely(engine->csb_head == -1)) { /* following a reset 
> >> */
> >> + head = readl(csb_mmio);
> >> + tail = GEN8_CSB_WRITE_PTR(head);
> >> + head = GEN8_CSB_READ_PTR(head);
> >> + engine->csb_head = head;
> >> + } else {
> >> + head = engine->csb_head;
> >> + tail = buf[0xf];
> > 
> > In CNL the tail moves to offset 0x2f of the HWSP (i.e. buf[0x1f]), might
> >be worth considering it immediately since CNL support is being merged.
> > 
> > -Daniele
> > 
> 
> Also right now it is implicitly doing csb_head_dword - csb_start_dword 
> (0x1f - 0x10). I would vote to have them as defines.
> 
> And my only other comment, wouldn't the same changes should apply to the 
> i915_engine_info debugfs? For example: https://hastebin.com/tahurezeri

Both. You only start to look in debugfs when you suspect something is
going wrong, so you definitely want the confirmation of checking the
mmio against the hwsp.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/gvt: Fix the vblank timer close issue after shutdown VMs in reverse

[fred gao]

Once the Windows guest is shutdown, the display pipe will be disabled
and intel_gvt_check_vblank_emulation will be called to check if the
vblank timer is turned off. Given the scenario of creating VM1 ,VM2,
destoying VM2 in current code, VM1 has pipe enabled and continues to
check VM2, the flag have_enabled_pipe is always false since all the VM2
pipes are disabled, so the vblank timer will be canceled and TDR happens
in Windows VM1 guest due to the vsync timeout.

In this patch the vblank timer will be never canceled once one pipe is
enabled.

Cc: Wang, Hongbo 
Signed-off-by: fred gao 
---
 drivers/gpu/drm/i915/gvt/display.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/display.c 
b/drivers/gpu/drm/i915/gvt/display.c
index 2deb05f..1ab6639 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -329,21 +329,23 @@ void intel_gvt_check_vblank_emulation(struct intel_gvt 
*gvt)
if (WARN_ON(!mutex_is_locked(&gvt->lock)))
return;
 
-   hrtimer_cancel(&irq->vblank_timer.timer);
-
for_each_active_vgpu(gvt, vgpu, id) {
for (pipe = 0; pipe < I915_MAX_PIPES; pipe++) {
have_enabled_pipe =
pipe_is_enabled(vgpu, pipe);
if (have_enabled_pipe)
-   break;
+   goto out;
}
}
 
+out:
if (have_enabled_pipe)
hrtimer_start(&irq->vblank_timer.timer,
ktime_add_ns(ktime_get(), irq->vblank_timer.period),
HRTIMER_MODE_ABS);
+   else
+   hrtimer_cancel(&irq->vblank_timer.timer);
+
 }
 
 static void emulate_vblank_on_pipe(struct intel_vgpu *vgpu, int pipe)
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH xf86-video-amdgpu] Adapt to PixmapDirtyUpdateRec::src being a DrawablePtr

[Michel Dänzer]

On 18/04/17 07:07 PM, Michel Dänzer wrote:
> From: Michel Dänzer 
> 
> Signed-off-by: Michel Dänzer 
> ---
> 
> Chris / Ilia / Ben, this should be manageable for the intel/nouveau
> drivers, right?

Any feedback, guys?

I want to push the xserver change soon-ish. I could probably come up
with a corresponding patch for nouveau in the worst case, but I'm afraid
not for intel.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
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/gvt: Fix the vblank timer close issue after shutdown VMs in reverse (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: Fix the vblank timer close issue after shutdown VMs in 
reverse (rev2)
URL   : https://patchwork.freedesktop.org/series/27215/
State : warning

== Summary ==

Series 27215v2 drm/i915/gvt: Fix the vblank timer close issue after shutdown 
VMs in reverse
https://patchwork.freedesktop.org/api/1.0/series/27215/revisions/2/mbox/

Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> SKIP   (fi-skl-x1585l)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-pnv-d510) fdo#101597 +1
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#101705

fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:448s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:427s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:357s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:526s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:508s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:487s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:481s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:592s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:437s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:414s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:421s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:503s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:468s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:470s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:572s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:590s
fi-pnv-d510  total:279  pass:222  dwarn:2   dfail:0   fail:0   skip:55  
time:563s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:457s
fi-skl-6700hqtotal:279  pass:262  dwarn:0   dfail:0   fail:0   skip:17  
time:586s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:463s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:484s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:434s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:476s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:542s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:398s

8ad9e19aafea47c272163c2cbf554e06ff7f9857 drm-tip: 2017y-07m-11d-19h-08m-20s UTC 
integration manifest
4c9ce1a drm/i915/gvt: Fix the vblank timer close issue after shutdown VMs in 
reverse

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5180/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915/lrc: allocate separate page for HWSP

[Chris Wilson]

Quoting Michel Thierry (2017-07-13 00:51:11)
> On 7/12/2017 3:57 PM, Chris Wilson wrote:
> > From: Daniele Ceraolo Spurio 
> > 
> > On gen8+ we're currently using the PPHWSP of the kernel ctx as the
> > global HWSP. However, when the kernel ctx gets submitted (e.g. from
> > __intel_autoenable_gt_powersave) the HW will use that page as both
> > HWSP and PPHWSP. This causes a conflict in the register arena of the
> > HWSP, i.e. offsets below 0x80. We don't current utilize this arena,
> > but in the following patches we will take advantage of the cached
> > register state for handling execlist's context status interrupt.
> > 
> > To avoid the conflict, instead of re-using the PPHWSP of the kernel
> > ctx we can allocate a separate page for the HWSP like what happens for
> > pre-execlists platform.
> > 
> 
> I'm sure you haven't forgotten, but anyway a reminder for others; this 
> change depends on "drm/i915/guc: Don't make assumptions while getting 
> the lrca offset" [https://patchwork.freedesktop.org/patch/166519/], or 
> guc loading will break.
> 
> > v2: Add a use-case for the register arena.
> > 
> 
> s/arena/area/ ?

I like arena when I want the impression of an enclosed space, and area
for an open space. Here I felt that the registers are a reserved block
inside the hwsp, which I felt acted like an enclosure.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Daniel Vetter]

On Thu, Jul 13, 2017 at 8:54 AM, Ramalingam C  wrote:
> On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote:
>
> On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul  wrote:
>
> Why all these intermediate steps and different failure modes? Either hdcp
> works, or it doesnt (and we can split up with the type 0 or type 1 if
> needed), but I don't know what userspace would do with all the other
> stuff?
>
> enum values  HDCP_ENABLE, HDCP_ENABLE_TYPE1 and HDCP_DISABLE along with
> kobj-uevent
> for HDCP state change, could do the bare minimal HDCP1.4 and HDCP2.2
> configuration.
>
> And without Type info it is not possible for HDCP2.2.
>
> I've had requests from chrome team to expose HDCP version, so I don't think
> this
> is too contentious.
>
> I think it'd still be easier if we start out with the current content
> protection props that CrOS is using, and then figure out how to layer
> the exact version/standard on top? One thing at a time and all that.
> -Daniel
>
> I understand the approach.
>
> But Only problem is current upstreaming effort is for HDCP2.2 support at DRM
> with a design which can
> easily accommodate other versions too. So we  need to stretch current CrOS
> property a bit with
> ENABLE_TYPE1 and UNSUPPORTED etc. Hope that should be fine for all.

Yeah, but if we just go with enable (without specifying the type) we
could still enable the highest hdcp level (so 2.2 for our case). At
least I don't see a reason why we need to already have the
enable_type1 thing. Can you pls explain why you think this is
necessary?

There seems to be a need to force type1, but I think it's easier to do
that as an extension. Of course we need to keep it in mind meanwhile.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 1/5] drm/i915/lrc: Clarify the format of the context image

[Chris Wilson]

From: Michel Thierry 

Not only the context image consist of two parts (the PPHWSP, and the
logical context state), but we also allocate a header at the start of
for sharing data with GuC. Thus every lrc looks like this:

  | [guc]  | [hwsp] [logical state] |
  |<- our header ->|<- context image  ->|

So far, we have oversimplified whenever we use each of these parts of the
context, just because the GuC header happens to be in page 0, and the
(PP)HWSP is in page 1. But this had led to using the same define for more
than one meaning (as a page index in the lrc and as 1 page).

This patch adds defines for the GuC shared page, the PPHWSP page and the
start of the logical state. It also updated the places where the old
define was being used. Since we are not changing the size (or format) of
the context, there are no functional changes.

v2: Use PPHWSP index for hws again.

Suggested-by: Chris Wilson 
Signed-off-by: Michel Thierry 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: intel-gvt-...@lists.freedesktop.org
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170712193032.27080-1-michel.thie...@intel.com
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/scheduler.c   |  4 ++--
 drivers/gpu/drm/i915/i915_guc_submission.c |  4 ++--
 drivers/gpu/drm/i915/intel_lrc.c   |  9 ++---
 drivers/gpu/drm/i915/intel_lrc.h   | 25 ++---
 4 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 0e2e36ad6196..8e9eeff156f6 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -87,7 +87,7 @@ static int populate_shadow_context(struct intel_vgpu_workload 
*workload)
return -EINVAL;
}
 
-   page = i915_gem_object_get_page(ctx_obj, LRC_PPHWSP_PN + i);
+   page = i915_gem_object_get_page(ctx_obj, LRC_HEADER_PAGES + i);
dst = kmap(page);
intel_gvt_hypervisor_read_gpa(vgpu, context_gpa, dst,
GTT_PAGE_SIZE);
@@ -361,7 +361,7 @@ static void update_guest_context(struct intel_vgpu_workload 
*workload)
return;
}
 
-   page = i915_gem_object_get_page(ctx_obj, LRC_PPHWSP_PN + i);
+   page = i915_gem_object_get_page(ctx_obj, LRC_HEADER_PAGES + i);
src = kmap(page);
intel_gvt_hypervisor_write_gpa(vgpu, context_gpa, src,
GTT_PAGE_SIZE);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 48a1e9349a2c..b7ca13860677 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1310,7 +1310,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
/* any value greater than GUC_POWER_D0 */
data[1] = GUC_POWER_D1;
/* first page is shared data with GuC */
-   data[2] = guc_ggtt_offset(ctx->engine[RCS].state);
+   data[2] = guc_ggtt_offset(ctx->engine[RCS].state) + LRC_GUCSHR_PN * 
PAGE_SIZE;
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -1336,7 +1336,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
data[1] = GUC_POWER_D0;
/* first page is shared data with GuC */
-   data[2] = guc_ggtt_offset(ctx->engine[RCS].state);
+   data[2] = guc_ggtt_offset(ctx->engine[RCS].state) + LRC_GUCSHR_PN * 
PAGE_SIZE;
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 699868d81de8..fde145c552ef 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -279,7 +279,7 @@ intel_lr_context_descriptor_update(struct i915_gem_context 
*ctx,
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > (1state) + LRC_PPHWSP_PN * PAGE_SIZE;
+   desc |= i915_ggtt_offset(ce->state) + LRC_HEADER_PAGES * PAGE_SIZE;
/* bits 12-31 */
desc |= (u64)ctx->hw_id << GEN8_CTX_ID_SHIFT;   /* bits 32-52 */
 
@@ -2015,8 +2015,11 @@ static int execlists_context_deferred_alloc(struct 
i915_gem_context *ctx,
 
context_size = round_up(engine->context_size, I915_GTT_PAGE_SIZE);
 
-   /* One extra page as the sharing data between driver and GuC */
-   context_size += PAGE_SIZE * LRC_PPHWSP_PN;
+   /*
+* Before the actual start of the context image, we insert a few pages
+* for our own use and for sharing with the GuC.
+*/
+   context_size += LRC_HEADER_PAGES * PAGE_SIZE;
 
ctx_obj = i915_gem_object_c

[Intel-gfx] [PATCH v2 2/5] drm/i915/guc: Don't make assumptions while getting the lrca offset

[Chris Wilson]

From: Michel Thierry 

Using the HWSP ggtt_offset to get the lrca offset is only correct if the
HWSP happens to be before it (when we reuse the PPHWSP of the kernel
context as the engine HWSP). Instead of making this assumption, get the
lrca offset from the kernel_context engine state.

And while looking at this part of the GuC interaction, it was also
noticed that the firmware expects the size of only the engine context
(context minus the execlist part, i.e. don't include the first 80
dwords), so pass the right size.

v2: Use the new macros to prevent abusive overuse of the old ones (Chris).

Reported-by: Daniele Ceraolo Spurio 
Signed-off-by: Michel Thierry 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Oscar Mateo 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170712193032.27080-2-michel.thie...@intel.com
Reviewed-by: Chris Wilson 
Acked-by: Daniele Ceraolo Spurio 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index b7ca13860677..8b96935cf96a 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1018,6 +1018,12 @@ static void guc_policies_init(struct guc_policies 
*policies)
policies->is_valid = 1;
 }
 
+/*
+ * The first 80 dwords of the register state context, containing the
+ * execlists and ppgtt registers.
+ */
+#define LR_HW_CONTEXT_SIZE (80 * sizeof(u32))
+
 static int guc_ads_create(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -1032,6 +1038,8 @@ static int guc_ads_create(struct intel_guc *guc)
} __packed *blob;
struct intel_engine_cs *engine;
enum intel_engine_id id;
+   const u32 skipped_offset = LRC_HEADER_PAGES * PAGE_SIZE;
+   const u32 skipped_size = LRC_PPHWSP_SZ * PAGE_SIZE + LR_HW_CONTEXT_SIZE;
u32 base;
 
GEM_BUG_ON(guc->ads_vma);
@@ -1062,13 +1070,20 @@ static int guc_ads_create(struct intel_guc *guc)
 * engines after a reset. Here we use the Render ring default
 * context, which must already exist and be pinned in the GGTT,
 * so its address won't change after we've told the GuC where
-* to find it.
+* to find it. Note that we have to skip our header (1 page),
+* because our GuC shared data is there.
 */
blob->ads.golden_context_lrca =
-   dev_priv->engine[RCS]->status_page.ggtt_offset;
+   guc_ggtt_offset(dev_priv->kernel_context->engine[RCS].state) + 
skipped_offset;
 
+   /*
+* The GuC expects us to exclude the portion of the context image that
+* it skips from the size it is to read. It starts reading from after
+* the execlist context (so skipping the first page [PPHWSP] and 80
+* dwords). Weird guc is weird.
+*/
for_each_engine(engine, dev_priv, id)
-   blob->ads.eng_state_size[engine->guc_id] = engine->context_size;
+   blob->ads.eng_state_size[engine->guc_id] = engine->context_size 
- skipped_size;
 
base = guc_ggtt_offset(vma);
blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
-- 
2.13.2

___
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/execlists: Read the context-status buffer from the HWSP

[Chris Wilson]

The engine provides a mirror of the CSB in the HWSP. If we use the
cacheable reads from the HWSP, we can shave off a few mmio reads per
context-switch interrupt (which are quite frequent!). Just removing a
couple of mmio is not enough to actually reduce any latency, but a small
reduction in overall cpu usage.

Much appreciation for Ben dropping the bombshell that the CSB was in the
HWSP and for Michel in digging out the details.

v2: Don't be lazy, add the defines for the indices.
v3: Include the HWSP in debugfs/i915_engine_info

Suggested-by: Ben Widawsky 
Signed-off-by: Chris Wilson 
Cc: Michel Thierry 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Acked-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  7 +--
 drivers/gpu/drm/i915/intel_lrc.c| 10 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 ++
 3 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 620c9218d1c1..5fd01c14a3ec 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3384,6 +3384,7 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
   upper_32_bits(addr), lower_32_bits(addr));
 
if (i915.enable_execlists) {
+   const u32 *hws = 
&engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
u32 ptr, read, write;
unsigned int idx;
 
@@ -3404,10 +3405,12 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
write += GEN8_CSB_ENTRIES;
while (read < write) {
idx = ++read % GEN8_CSB_ENTRIES;
-   seq_printf(m, "\tExeclist CSB[%d]: 0x%08x, 
context: %d\n",
+   seq_printf(m, "\tExeclist CSB[%d]: 0x%08x 
[0x%08x in hwsp], context: %d [%d in hwsp]\n",
   idx,
   
I915_READ(RING_CONTEXT_STATUS_BUF_LO(engine, idx)),
-  
I915_READ(RING_CONTEXT_STATUS_BUF_HI(engine, idx)));
+  hws[idx * 2],
+  
I915_READ(RING_CONTEXT_STATUS_BUF_HI(engine, idx)),
+  hws[idx * 2 + 1]);
}
 
rcu_read_lock();
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3469badedbe0..a887379b004d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -547,8 +547,9 @@ static void intel_lrc_irq_handler(unsigned long data)
while (test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted)) {
u32 __iomem *csb_mmio =
dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
-   u32 __iomem *buf =
-   dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0));
+   /* The HWSP contains a (cacheable) mirror of the CSB */
+   const u32 *buf =
+   &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
unsigned int head, tail;
 
/* The write will be ordered by the uncached read (itself
@@ -590,13 +591,12 @@ static void intel_lrc_irq_handler(unsigned long data)
 * status notifier.
 */
 
-   status = readl(buf + 2 * head);
+   status = buf[2 * head];
if (!(status & GEN8_CTX_STATUS_COMPLETED_MASK))
continue;
 
/* Check the context/desc id for this event matches */
-   GEM_DEBUG_BUG_ON(readl(buf + 2 * head + 1) !=
-port->context_id);
+   GEM_DEBUG_BUG_ON(buf[2 * head + 1] != port->context_id);
 
rq = port_unpack(port, &count);
GEM_BUG_ON(count == 0);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index d33c93444c0d..2c55cfa14fb5 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -496,6 +496,8 @@ intel_write_status_page(struct intel_engine_cs *engine, int 
reg, u32 value)
 #define I915_GEM_HWS_SCRATCH_INDEX 0x40
 #define I915_GEM_HWS_SCRATCH_ADDR (I915_GEM_HWS_SCRATCH_INDEX << 
MI_STORE_DWORD_INDEX_SHIFT)
 
+#define I915_HWS_CSB_BUF0_INDEX0x10
+
 struct intel_ring *
 intel_engine_create_ring(struct intel_engine_cs *engine, int size);
 int intel_ring_pin(struct intel_ring *ring,
-- 
2.13.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/

[Intel-gfx] [PATCH v2 5/5] drm/i915/execlists: Read the context-status HEAD from the HWSP

[Chris Wilson]

The engine provides also provides mirror of the CSB write pointer in the
HWSP, but not of our read pointer. To take advantage of this we need to
remember where we read up to on the last interrupt and continue off from
there. This poses a problem following a reset, as we don't know where
the hw will start writing from, and due to the use of power contexts we
cannot perform that query during the reset itself. So we continue the
current modus operandi of delaying the first read of the context-status
read/write pointers until after the first interrupt. With this we should
now have eliminated all uncached mmio reads in handling the
context-status interrupt, though we still have the uncached mmio writes
for submitting new work, and many uncached mmio reads in the global
interrupt handler itself. Still a step in the right direction towards
reducing our resubmit latency, although it appears lost in the noise!

v2: Cannonlake moved the CSB write index
v3: Include the sw/hwsp state in debugfs/i915_engine_info

Signed-off-by: Chris Wilson 
Cc: Michel Thierry 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Cc: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  6 --
 drivers/gpu/drm/i915/i915_drv.h |  8 
 drivers/gpu/drm/i915/intel_lrc.c| 24 +++-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  3 +++
 4 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5fd01c14a3ec..552aef61b47b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3395,8 +3395,10 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
ptr = I915_READ(RING_CONTEXT_STATUS_PTR(engine));
read = GEN8_CSB_READ_PTR(ptr);
write = GEN8_CSB_WRITE_PTR(ptr);
-   seq_printf(m, "\tExeclist CSB read %d, write %d\n",
-  read, write);
+   seq_printf(m, "\tExeclist CSB read %d [%d cached], 
write %d [%d from hws]\n",
+  read, engine->csb_head,
+  write,
+  intel_read_status_page(engine, 
intel_hws_csb_write_index(engine->i915)));
if (read >= GEN8_CSB_ENTRIES)
read = 0;
if (write >= GEN8_CSB_ENTRIES)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 81cd21ecfa7d..f62c9db8a9a8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4228,4 +4228,12 @@ static inline bool i915_gem_object_is_coherent(struct 
drm_i915_gem_object *obj)
HAS_LLC(to_i915(obj->base.dev)));
 }
 
+static inline int intel_hws_csb_write_index(struct drm_i915_private *i915)
+{
+   if (INTEL_GEN(i915) >= 10)
+   return CNL_HWS_CSB_WRITE_INDEX;
+   else
+   return I915_HWS_CSB_WRITE_INDEX;
+}
+
 #endif
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a887379b004d..7fb908a6fa0a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -563,9 +563,19 @@ static void intel_lrc_irq_handler(unsigned long data)
 * is set and we do a new loop.
 */
__clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
-   head = readl(csb_mmio);
-   tail = GEN8_CSB_WRITE_PTR(head);
-   head = GEN8_CSB_READ_PTR(head);
+   if (unlikely(engine->csb_head == -1)) { /* following a reset */
+   head = readl(csb_mmio);
+   tail = GEN8_CSB_WRITE_PTR(head);
+   head = GEN8_CSB_READ_PTR(head);
+   engine->csb_head = head;
+   } else {
+   const int write_idx =
+   intel_hws_csb_write_index(dev_priv) -
+   I915_HWS_CSB_BUF0_INDEX;
+
+   head = engine->csb_head;
+   tail = buf[write_idx];
+   }
while (head != tail) {
struct drm_i915_gem_request *rq;
unsigned int status;
@@ -619,8 +629,11 @@ static void intel_lrc_irq_handler(unsigned long data)
   !(status & GEN8_CTX_STATUS_ACTIVE_IDLE));
}
 
-   writel(_MASKED_FIELD(GEN8_CSB_READ_PTR_MASK, head << 8),
-  csb_mmio);
+   if (head != engine->csb_head) {
+   engine->csb_head = head;
+   writel(_MASKED_FIELD(GEN8_CSB_READ_PTR_MASK, head << 8),
+  csb_mmio);
+   }
}
 
if (execlists_elsp_ready(engine))
@@ -1247,6 +1260,7 @@ static int gen8_init_common_r

[Intel-gfx] [PATCH v2 3/5] drm/i915/lrc: allocate separate page for HWSP

[Chris Wilson]

From: Daniele Ceraolo Spurio 

On gen8+ we're currently using the PPHWSP of the kernel ctx as the
global HWSP. However, when the kernel ctx gets submitted (e.g. from
__intel_autoenable_gt_powersave) the HW will use that page as both
HWSP and PPHWSP. This causes a conflict in the register arena of the
HWSP, i.e. dword indices below 0x30. We don't current utilize this arena,
but in the following patches we will take advantage of the cached
register state for handling execlist's context status interrupt.

To avoid the conflict, instead of re-using the PPHWSP of the kernel
ctx we can allocate a separate page for the HWSP like what happens for
pre-execlists platform.

v2: Add a use-case for the register arena of the HWSP.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Michel Thierry 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1499357440-34688-1-git-send-email-daniele.ceraolospu...@intel.com
Signed-off-by: Chris Wilson 
Reviewded-by: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  | 126 +++-
 drivers/gpu/drm/i915/intel_lrc.c|  34 +
 drivers/gpu/drm/i915/intel_ringbuffer.c | 125 +--
 3 files changed, 127 insertions(+), 158 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 24db316e0fd1..cba120f3d89d 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -445,6 +445,114 @@ static void intel_engine_cleanup_scratch(struct 
intel_engine_cs *engine)
i915_vma_unpin_and_release(&engine->scratch);
 }
 
+static void cleanup_phys_status_page(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *dev_priv = engine->i915;
+
+   if (!dev_priv->status_page_dmah)
+   return;
+
+   drm_pci_free(&dev_priv->drm, dev_priv->status_page_dmah);
+   engine->status_page.page_addr = NULL;
+}
+
+static void cleanup_status_page(struct intel_engine_cs *engine)
+{
+   struct i915_vma *vma;
+   struct drm_i915_gem_object *obj;
+
+   vma = fetch_and_zero(&engine->status_page.vma);
+   if (!vma)
+   return;
+
+   obj = vma->obj;
+
+   i915_vma_unpin(vma);
+   i915_vma_close(vma);
+
+   i915_gem_object_unpin_map(obj);
+   __i915_gem_object_release_unless_active(obj);
+}
+
+static int init_status_page(struct intel_engine_cs *engine)
+{
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+   unsigned int flags;
+   void *vaddr;
+   int ret;
+
+   obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
+   if (IS_ERR(obj)) {
+   DRM_ERROR("Failed to allocate status page\n");
+   return PTR_ERR(obj);
+   }
+
+   ret = i915_gem_object_set_cache_level(obj, I915_CACHE_LLC);
+   if (ret)
+   goto err;
+
+   vma = i915_vma_instance(obj, &engine->i915->ggtt.base, NULL);
+   if (IS_ERR(vma)) {
+   ret = PTR_ERR(vma);
+   goto err;
+   }
+
+   flags = PIN_GLOBAL;
+   if (!HAS_LLC(engine->i915))
+   /* On g33, we cannot place HWS above 256MiB, so
+* restrict its pinning to the low mappable arena.
+* Though this restriction is not documented for
+* gen4, gen5, or byt, they also behave similarly
+* and hang if the HWS is placed at the top of the
+* GTT. To generalise, it appears that all !llc
+* platforms have issues with us placing the HWS
+* above the mappable region (even though we never
+* actualy map it).
+*/
+   flags |= PIN_MAPPABLE;
+   ret = i915_vma_pin(vma, 0, 4096, flags);
+   if (ret)
+   goto err;
+
+   vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+   if (IS_ERR(vaddr)) {
+   ret = PTR_ERR(vaddr);
+   goto err_unpin;
+   }
+
+   engine->status_page.vma = vma;
+   engine->status_page.ggtt_offset = i915_ggtt_offset(vma);
+   engine->status_page.page_addr = memset(vaddr, 0, PAGE_SIZE);
+
+   DRM_DEBUG_DRIVER("%s hws offset: 0x%08x\n",
+engine->name, i915_ggtt_offset(vma));
+   return 0;
+
+err_unpin:
+   i915_vma_unpin(vma);
+err:
+   i915_gem_object_put(obj);
+   return ret;
+}
+
+static int init_phys_status_page(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *dev_priv = engine->i915;
+
+   GEM_BUG_ON(engine->id != RCS);
+
+   dev_priv->status_page_dmah =
+   drm_pci_alloc(&dev_priv->drm, PAGE_SIZE, PAGE_SIZE);
+   if (!dev_priv->status_page_dmah)
+   return -ENOMEM;
+
+   engine->status_page.page_addr = dev_priv->status_page_dmah->vaddr;
+   memset(engine->status_page.page_addr, 0, PAGE_SIZE);
+
+   return 0;
+}
+
 /**
  * intel_engines_init_common - initialize cengine state wh

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/execlists: Read the context-status buffer from the HWSP

[Zhenyu Wang]

On 2017.07.13 10:00:25 +0100, Chris Wilson wrote:
> The engine provides a mirror of the CSB in the HWSP. If we use the
> cacheable reads from the HWSP, we can shave off a few mmio reads per
> context-switch interrupt (which are quite frequent!). Just removing a
> couple of mmio is not enough to actually reduce any latency, but a small
> reduction in overall cpu usage.

Unfortunately current gvt's execlist emulation depends on MMIO CSB read
for guest workload without guest HWSP update. So this can't work for guest.
We need to fix that in gvt, also reduce MMIO trap is good benefit for vGPU too.
But might have to fallback to mmio mode if vgpu active now, and once gvt host
got fixed, will notify through pvinfo to enable this.

> 
> Much appreciation for Ben dropping the bombshell that the CSB was in the
> HWSP and for Michel in digging out the details.
> 
> v2: Don't be lazy, add the defines for the indices.
> v3: Include the HWSP in debugfs/i915_engine_info
> 
> Suggested-by: Ben Widawsky 
> Signed-off-by: Chris Wilson 
> Cc: Michel Thierry 
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 
> Acked-by: Michel Thierry 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  7 +--
>  drivers/gpu/drm/i915/intel_lrc.c| 10 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.h |  2 ++
>  3 files changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 620c9218d1c1..5fd01c14a3ec 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3384,6 +3384,7 @@ static int i915_engine_info(struct seq_file *m, void 
> *unused)
>  upper_32_bits(addr), lower_32_bits(addr));
>  
>   if (i915.enable_execlists) {
> + const u32 *hws = 
> &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
>   u32 ptr, read, write;
>   unsigned int idx;
>  
> @@ -3404,10 +3405,12 @@ static int i915_engine_info(struct seq_file *m, void 
> *unused)
>   write += GEN8_CSB_ENTRIES;
>   while (read < write) {
>   idx = ++read % GEN8_CSB_ENTRIES;
> - seq_printf(m, "\tExeclist CSB[%d]: 0x%08x, 
> context: %d\n",
> + seq_printf(m, "\tExeclist CSB[%d]: 0x%08x 
> [0x%08x in hwsp], context: %d [%d in hwsp]\n",
>  idx,
>  
> I915_READ(RING_CONTEXT_STATUS_BUF_LO(engine, idx)),
> -
> I915_READ(RING_CONTEXT_STATUS_BUF_HI(engine, idx)));
> +hws[idx * 2],
> +
> I915_READ(RING_CONTEXT_STATUS_BUF_HI(engine, idx)),
> +hws[idx * 2 + 1]);
>   }
>  
>   rcu_read_lock();
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 3469badedbe0..a887379b004d 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -547,8 +547,9 @@ static void intel_lrc_irq_handler(unsigned long data)
>   while (test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted)) {
>   u32 __iomem *csb_mmio =
>   dev_priv->regs + 
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
> - u32 __iomem *buf =
> - dev_priv->regs + 
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0));
> + /* The HWSP contains a (cacheable) mirror of the CSB */
> + const u32 *buf =
> + &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
>   unsigned int head, tail;
>  
>   /* The write will be ordered by the uncached read (itself
> @@ -590,13 +591,12 @@ static void intel_lrc_irq_handler(unsigned long data)
>* status notifier.
>*/
>  
> - status = readl(buf + 2 * head);
> + status = buf[2 * head];
>   if (!(status & GEN8_CTX_STATUS_COMPLETED_MASK))
>   continue;
>  
>   /* Check the context/desc id for this event matches */
> - GEM_DEBUG_BUG_ON(readl(buf + 2 * head + 1) !=
> -  port->context_id);
> + GEM_DEBUG_BUG_ON(buf[2 * head + 1] != port->context_id);
>  
>   rq = port_unpack(port, &count);
>   GEM_BUG_ON(count == 0);
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index d33c93444c0d..2c55cfa14fb5 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -496,6 +496,8 @@ intel_write_status_page(struct intel

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v2,1/5] drm/i915/lrc: Clarify the format of the context image

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/5] drm/i915/lrc: Clarify the format of the 
context image
URL   : https://patchwork.freedesktop.org/series/27227/
State : warning

== Summary ==

Series 27227v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/27227/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> FAIL   (fi-snb-2600) fdo#100215
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> SKIP   (fi-skl-x1585l)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-pnv-d510) fdo#101597 +1

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:445s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:432s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:360s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:530s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:504s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:485s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:485s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:600s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:439s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:418s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:501s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:472s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:466s
fi-kbl-7560u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:565s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:580s
fi-pnv-d510  total:279  pass:222  dwarn:2   dfail:0   fail:0   skip:55  
time:561s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:469s
fi-skl-6700hqtotal:279  pass:262  dwarn:0   dfail:0   fail:0   skip:17  
time:585s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:467s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:478s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:436s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:469s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:544s
fi-snb-2600  total:279  pass:248  dwarn:0   dfail:0   fail:2   skip:29  
time:402s

8ad9e19aafea47c272163c2cbf554e06ff7f9857 drm-tip: 2017y-07m-11d-19h-08m-20s UTC 
integration manifest
b0b24fe drm/i915/execlists: Read the context-status HEAD from the HWSP
3157f6e drm/i915/execlists: Read the context-status buffer from the HWSP
e0b33ef drm/i915/lrc: allocate separate page for HWSP
45f36dd drm/i915/guc: Don't make assumptions while getting the lrca offset
5ce6944 drm/i915/lrc: Clarify the format of the context image

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5181/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/execlists: Read the context-status buffer from the HWSP

[Chris Wilson]

Quoting Zhenyu Wang (2017-07-13 10:14:34)
> On 2017.07.13 10:00:25 +0100, Chris Wilson wrote:
> > The engine provides a mirror of the CSB in the HWSP. If we use the
> > cacheable reads from the HWSP, we can shave off a few mmio reads per
> > context-switch interrupt (which are quite frequent!). Just removing a
> > couple of mmio is not enough to actually reduce any latency, but a small
> > reduction in overall cpu usage.
> 
> Unfortunately current gvt's execlist emulation depends on MMIO CSB read
> for guest workload without guest HWSP update. So this can't work for guest.
> We need to fix that in gvt, also reduce MMIO trap is good benefit for vGPU 
> too.
> But might have to fallback to mmio mode if vgpu active now, and once gvt host
> got fixed, will notify through pvinfo to enable this.

* shakes fist at gvt, spoilsports.

Is the right test intel_vgpu_active()? i.e. something like

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e3e9d850cf88..a259d584e1fd 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -504,6 +504,13 @@ static void intel_lrc_irq_handler(unsigned long data)
&engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
unsigned int head, tail;
 
+   /* However GVT emulation depends upon intercepting CSB mmio */
+   if (unlikely(intel_vgpu_active(dev_priv))) {
+   buf = (u32 * __force)dev_priv->regs +
+   
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
+   engine->csb_head = -1;
+   }
+

would do the trick, though I guess it wants to test a version if GVT
starts providing CSB emulation via the HWSP.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/execlists: Read the context-status buffer from the HWSP

[Chris Wilson]

Quoting Zhenyu Wang (2017-07-13 10:14:34)
> On 2017.07.13 10:00:25 +0100, Chris Wilson wrote:
> > The engine provides a mirror of the CSB in the HWSP. If we use the
> > cacheable reads from the HWSP, we can shave off a few mmio reads per
> > context-switch interrupt (which are quite frequent!). Just removing a
> > couple of mmio is not enough to actually reduce any latency, but a small
> > reduction in overall cpu usage.
> 
> Unfortunately current gvt's execlist emulation depends on MMIO CSB read
> for guest workload without guest HWSP update. So this can't work for guest.
> We need to fix that in gvt, also reduce MMIO trap is good benefit for vGPU 
> too.
> But might have to fallback to mmio mode if vgpu active now, and once gvt host
> got fixed, will notify through pvinfo to enable this.

Is there any chance you can work with Tomi to get a gvt-g test host in
CI, or provide a similar CI service for gvt (would have to be coupled
into trybot as well)?

Also I will have to try to remember to cc you on any execlists/guc patches
in future.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/execlists: Read the context-status buffer from the HWSP

[Wang, Zhi A]

Sorry, my bad for missing it as I only saw it used on CHV before your patch 
because of some HW issue.

Kinda of interested in the reason why HWSP CSB gains people's interest now? :P. 
Anyway, it's good move to reduce the MMIO trap here.

Thanks,
Zhi.

-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] 
Sent: Thursday, July 13, 2017 12:28 PM
To: Zhenyu Wang 
Cc: intel-gfx@lists.freedesktop.org; Kuoppala, Mika ; 
Wang, Zhi A 
Subject: Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/execlists: Read the 
context-status buffer from the HWSP

Quoting Zhenyu Wang (2017-07-13 10:14:34)
> On 2017.07.13 10:00:25 +0100, Chris Wilson wrote:
> > The engine provides a mirror of the CSB in the HWSP. If we use the 
> > cacheable reads from the HWSP, we can shave off a few mmio reads per 
> > context-switch interrupt (which are quite frequent!). Just removing 
> > a couple of mmio is not enough to actually reduce any latency, but a 
> > small reduction in overall cpu usage.
> 
> Unfortunately current gvt's execlist emulation depends on MMIO CSB 
> read for guest workload without guest HWSP update. So this can't work for 
> guest.
> We need to fix that in gvt, also reduce MMIO trap is good benefit for vGPU 
> too.
> But might have to fallback to mmio mode if vgpu active now, and once 
> gvt host got fixed, will notify through pvinfo to enable this.

* shakes fist at gvt, spoilsports.

Is the right test intel_vgpu_active()? i.e. something like

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e3e9d850cf88..a259d584e1fd 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -504,6 +504,13 @@ static void intel_lrc_irq_handler(unsigned long data)
&engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
unsigned int head, tail;
 
+   /* However GVT emulation depends upon intercepting CSB mmio */
+   if (unlikely(intel_vgpu_active(dev_priv))) {
+   buf = (u32 * __force)dev_priv->regs +
+   
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
+   engine->csb_head = -1;
+   }
+

would do the trick, though I guess it wants to test a version if GVT starts 
providing CSB emulation via the HWSP.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/execlists: Read the context-status buffer from the HWSP

[Zhenyu Wang]

On 2017.07.13 10:28:04 +0100, Chris Wilson wrote:
> Quoting Zhenyu Wang (2017-07-13 10:14:34)
> > On 2017.07.13 10:00:25 +0100, Chris Wilson wrote:
> > > The engine provides a mirror of the CSB in the HWSP. If we use the
> > > cacheable reads from the HWSP, we can shave off a few mmio reads per
> > > context-switch interrupt (which are quite frequent!). Just removing a
> > > couple of mmio is not enough to actually reduce any latency, but a small
> > > reduction in overall cpu usage.
> > 
> > Unfortunately current gvt's execlist emulation depends on MMIO CSB read
> > for guest workload without guest HWSP update. So this can't work for guest.
> > We need to fix that in gvt, also reduce MMIO trap is good benefit for vGPU 
> > too.
> > But might have to fallback to mmio mode if vgpu active now, and once gvt 
> > host
> > got fixed, will notify through pvinfo to enable this.
> 
> * shakes fist at gvt, spoilsports.
>

:( sorry...btw we also had internal proposal to remove i915 CSB MMIO read,
although only in POC hacking form, so this actually aligns with our plan. ;)

> Is the right test intel_vgpu_active()? i.e. something like
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index e3e9d850cf88..a259d584e1fd 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -504,6 +504,13 @@ static void intel_lrc_irq_handler(unsigned long data)
> 
> &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
> unsigned int head, tail;
>  
> +   /* However GVT emulation depends upon intercepting CSB mmio */
> +   if (unlikely(intel_vgpu_active(dev_priv))) {
> +   buf = (u32 * __force)dev_priv->regs +
> +   
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
> +   engine->csb_head = -1;
> +   }
> +
> 
> would do the trick, though I guess it wants to test a version if GVT
> starts providing CSB emulation via the HWSP.

yeah, looks good to me.

-- 
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 v2 4/5] drm/i915/execlists: Read the context-status buffer from the HWSP

[Chris Wilson]

Quoting Wang, Zhi A (2017-07-13 10:36:14)
> Sorry, my bad for missing it as I only saw it used on CHV before your patch 
> because of some HW issue.
> 
> Kinda of interested in the reason why HWSP CSB gains people's interest now? 
> :P. Anyway, it's good move to reduce the MMIO trap here.

We've been chasing the elimination of mmio reads here for the last few
years, since the buffer is tantalising laid out inside a cacheline and
bspec says it was designed to be read in a single cacheline load.
Previously I had an alias for the CSB using ioremap_cache(), which
sort-of-worked (bxt was being a little unhappy) but still required a
clflush. Imagine then the surprise and delight that the information we
wanted was in the HWSP ever since execlists was a twinkle in the
architect's eye (back in gm45!).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/execlists: Read the context-status buffer from the HWSP

[Zhenyu Wang]

On 2017.07.13 10:32:38 +0100, Chris Wilson wrote:
> Quoting Zhenyu Wang (2017-07-13 10:14:34)
> > On 2017.07.13 10:00:25 +0100, Chris Wilson wrote:
> > > The engine provides a mirror of the CSB in the HWSP. If we use the
> > > cacheable reads from the HWSP, we can shave off a few mmio reads per
> > > context-switch interrupt (which are quite frequent!). Just removing a
> > > couple of mmio is not enough to actually reduce any latency, but a small
> > > reduction in overall cpu usage.
> > 
> > Unfortunately current gvt's execlist emulation depends on MMIO CSB read
> > for guest workload without guest HWSP update. So this can't work for guest.
> > We need to fix that in gvt, also reduce MMIO trap is good benefit for vGPU 
> > too.
> > But might have to fallback to mmio mode if vgpu active now, and once gvt 
> > host
> > got fixed, will notify through pvinfo to enable this.
> 
> Is there any chance you can work with Tomi to get a gvt-g test host in
> CI, or provide a similar CI service for gvt (would have to be coupled
> into trybot as well)?
>

cc Terence. I haven't heard news on that part, although I think it
should be easy with setup if you prepared VM image with IGT loaded.

> Also I will have to try to remember to cc you on any execlists/guc patches
> in future.

my pleasure

-- 
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 RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Ville Syrjälä]

On Wed, Jul 12, 2017 at 07:28:14PM -0700, Stéphane Marchesin wrote:
> On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä
>  wrote:
> >
> > On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
> > > El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
> > >
> > > > In several instances the driver passes an 'enum pipe' value to a
> > > > function expecting an 'enum transcoder' and viceversa. Since PIPE_x and
> > > > TRANSCODER_x have the same values this doesn't cause functional
> > > > problems. Still it is incorrect and causes clang to generate warnings
> > > > like this:
> > > >
> > > > drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit
> > > >   conversion from enumeration type 'enum transcoder' to different
> > > >   enumeration type 'enum pipe' [-Wenum-conversion]
> > > > assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
> > > >
> > > > Change the code to pass values of the type expected by the callee.
> > > >
> > > > Signed-off-by: Matthias Kaehlcke 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
> > > >  drivers/gpu/drm/i915/intel_dp.c  | 6 --
> > > >  drivers/gpu/drm/i915/intel_hdmi.c| 6 --
> > > >  drivers/gpu/drm/i915/intel_sdvo.c| 6 --
> > > >  4 files changed, 14 insertions(+), 8 deletions(-)
> > >
> > > Ping, any comments on this patch?
> >
> > I'm not convinced the patch is making things any better really. To
> > fix this really properly, I think we'd need to introduce a new enum
> > pch_transcoder and thus avoid the confusion of which type of
> > transcoder we're talking about. Currently most places expect an
> > enum pipe when dealing with PCH transcoders, and enum transcoder
> > when dealing with CPU transcoders. But there are some exceptions
> > of course.
> 
> 
> I don't follow -- these functions take an enum transcoder; what's
> wrong about passing what they expect? It seems like what you are
> asking for has nothing to do with the warning here...

There's a warning? I don't get any.

Anyways, I just don't see much point in blindly changing the types
because it doesn't actually solve the underlying confusion for human
readers. It might even make it worse, not sure.

-- 
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] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Ramalingam C]

On Thursday 13 July 2017 02:15 PM, Daniel Vetter wrote:

On Thu, Jul 13, 2017 at 8:54 AM, Ramalingam C  wrote:

On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote:

On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul  wrote:

Why all these intermediate steps and different failure modes? Either hdcp
works, or it doesnt (and we can split up with the type 0 or type 1 if
needed), but I don't know what userspace would do with all the other
stuff?

enum values  HDCP_ENABLE, HDCP_ENABLE_TYPE1 and HDCP_DISABLE along with
kobj-uevent
for HDCP state change, could do the bare minimal HDCP1.4 and HDCP2.2
configuration.

And without Type info it is not possible for HDCP2.2.

I've had requests from chrome team to expose HDCP version, so I don't think
this
is too contentious.

I think it'd still be easier if we start out with the current content
protection props that CrOS is using, and then figure out how to layer
the exact version/standard on top? One thing at a time and all that.
-Daniel

I understand the approach.

But Only problem is current upstreaming effort is for HDCP2.2 support at DRM
with a design which can
easily accommodate other versions too. So we  need to stretch current CrOS
property a bit with
ENABLE_TYPE1 and UNSUPPORTED etc. Hope that should be fine for all.

Yeah, but if we just go with enable (without specifying the type) we
could still enable the highest hdcp level (so 2.2 for our case). At
least I don't see a reason why we need to already have the
enable_type1 thing. Can you pls explain why you think this is
necessary?

There seems to be a need to force type1, but I think it's easier to do
that as an extension. Of course we need to keep it in mind meanwhile.
Background for this need of Type info in HDCP2.2 implementation is as 
follows:


HDCP2.2 Spec classify the protected content as Type 0 and Type 1. For 
Example lets say

- A HDCP2.2 Src is connected to HDCP repeater
- that repeater is connected to a HDCP2.2 panel
- that same repeater is also connected to a HDCP1.4 panel.

In this topology, as part of Repeater authentication:
- HDCP2.2 Source will mention the Content Type to HDCP2.2 Repeater
- Repeater can transmit this Type 1 content to HDCP2.2 compliant sink 
only (which is HDCP 2.2 panel here).
- Repeater can transmit any type0 content to any other devices (like 
HDCP1.4 panel here).

- Device with no HDCP support will get Neither of Type 0 or Type 1.

So if we implement HDCP2.2 with HDCP_ENABLE state alone there is no way 
for Userspace
to request for HDCP2.2 protection only. In this case we wont know the 
content type classification.


Even if we force Content type to Type1, in above topology Type 0 content 
that could be rendered to
HDCP1.4 compliant panel wont be rendered as that has been forcibly 
classified as Type 1 by KMD.


Forcing type 1 content to Type 0 will break the association of type1 
content to HDCP2.2 devices only.


More than that Devices with our indented DRM HDCP2.2 support wont pass 
the HDCP2.2 compliance.
Considering we could extend the CrOS Userspace for HDCP2.2, I would 
prefer to go ahead with

HDCP_ENABLE_TYPE1 along with HDCP_ENABLE.

--Ram

-Daniel


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 1/5] drm/i915/lrc: Clarify the format of the context image

[Chris Wilson]

From: Michel Thierry 

Not only the context image consist of two parts (the PPHWSP, and the
logical context state), but we also allocate a header at the start of
for sharing data with GuC. Thus every lrc looks like this:

  | [guc]  | [hwsp] [logical state] |
  |<- our header ->|<- context image  ->|

So far, we have oversimplified whenever we use each of these parts of the
context, just because the GuC header happens to be in page 0, and the
(PP)HWSP is in page 1. But this had led to using the same define for more
than one meaning (as a page index in the lrc and as 1 page).

This patch adds defines for the GuC shared page, the PPHWSP page and the
start of the logical state. It also updated the places where the old
define was being used. Since we are not changing the size (or format) of
the context, there are no functional changes.

v2: Use PPHWSP index for hws again.

Suggested-by: Chris Wilson 
Signed-off-by: Michel Thierry 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: intel-gvt-...@lists.freedesktop.org
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170712193032.27080-1-michel.thie...@intel.com
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/scheduler.c   |  4 ++--
 drivers/gpu/drm/i915/i915_guc_submission.c |  4 ++--
 drivers/gpu/drm/i915/intel_lrc.c   |  9 ++---
 drivers/gpu/drm/i915/intel_lrc.h   | 25 ++---
 4 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 0e2e36ad6196..8e9eeff156f6 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -87,7 +87,7 @@ static int populate_shadow_context(struct intel_vgpu_workload 
*workload)
return -EINVAL;
}
 
-   page = i915_gem_object_get_page(ctx_obj, LRC_PPHWSP_PN + i);
+   page = i915_gem_object_get_page(ctx_obj, LRC_HEADER_PAGES + i);
dst = kmap(page);
intel_gvt_hypervisor_read_gpa(vgpu, context_gpa, dst,
GTT_PAGE_SIZE);
@@ -361,7 +361,7 @@ static void update_guest_context(struct intel_vgpu_workload 
*workload)
return;
}
 
-   page = i915_gem_object_get_page(ctx_obj, LRC_PPHWSP_PN + i);
+   page = i915_gem_object_get_page(ctx_obj, LRC_HEADER_PAGES + i);
src = kmap(page);
intel_gvt_hypervisor_write_gpa(vgpu, context_gpa, src,
GTT_PAGE_SIZE);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 48a1e9349a2c..b7ca13860677 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1310,7 +1310,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
/* any value greater than GUC_POWER_D0 */
data[1] = GUC_POWER_D1;
/* first page is shared data with GuC */
-   data[2] = guc_ggtt_offset(ctx->engine[RCS].state);
+   data[2] = guc_ggtt_offset(ctx->engine[RCS].state) + LRC_GUCSHR_PN * 
PAGE_SIZE;
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -1336,7 +1336,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
data[1] = GUC_POWER_D0;
/* first page is shared data with GuC */
-   data[2] = guc_ggtt_offset(ctx->engine[RCS].state);
+   data[2] = guc_ggtt_offset(ctx->engine[RCS].state) + LRC_GUCSHR_PN * 
PAGE_SIZE;
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 699868d81de8..fde145c552ef 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -279,7 +279,7 @@ intel_lr_context_descriptor_update(struct i915_gem_context 
*ctx,
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > (1state) + LRC_PPHWSP_PN * PAGE_SIZE;
+   desc |= i915_ggtt_offset(ce->state) + LRC_HEADER_PAGES * PAGE_SIZE;
/* bits 12-31 */
desc |= (u64)ctx->hw_id << GEN8_CTX_ID_SHIFT;   /* bits 32-52 */
 
@@ -2015,8 +2015,11 @@ static int execlists_context_deferred_alloc(struct 
i915_gem_context *ctx,
 
context_size = round_up(engine->context_size, I915_GTT_PAGE_SIZE);
 
-   /* One extra page as the sharing data between driver and GuC */
-   context_size += PAGE_SIZE * LRC_PPHWSP_PN;
+   /*
+* Before the actual start of the context image, we insert a few pages
+* for our own use and for sharing with the GuC.
+*/
+   context_size += LRC_HEADER_PAGES * PAGE_SIZE;
 
ctx_obj = i915_gem_object_c

[Intel-gfx] [PATCH v3 2/5] drm/i915/guc: Don't make assumptions while getting the lrca offset

[Chris Wilson]

From: Michel Thierry 

Using the HWSP ggtt_offset to get the lrca offset is only correct if the
HWSP happens to be before it (when we reuse the PPHWSP of the kernel
context as the engine HWSP). Instead of making this assumption, get the
lrca offset from the kernel_context engine state.

And while looking at this part of the GuC interaction, it was also
noticed that the firmware expects the size of only the engine context
(context minus the execlist part, i.e. don't include the first 80
dwords), so pass the right size.

v2: Use the new macros to prevent abusive overuse of the old ones (Chris).

Reported-by: Daniele Ceraolo Spurio 
Signed-off-by: Michel Thierry 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Oscar Mateo 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170712193032.27080-2-michel.thie...@intel.com
Reviewed-by: Chris Wilson 
Acked-by: Daniele Ceraolo Spurio 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index b7ca13860677..8b96935cf96a 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1018,6 +1018,12 @@ static void guc_policies_init(struct guc_policies 
*policies)
policies->is_valid = 1;
 }
 
+/*
+ * The first 80 dwords of the register state context, containing the
+ * execlists and ppgtt registers.
+ */
+#define LR_HW_CONTEXT_SIZE (80 * sizeof(u32))
+
 static int guc_ads_create(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -1032,6 +1038,8 @@ static int guc_ads_create(struct intel_guc *guc)
} __packed *blob;
struct intel_engine_cs *engine;
enum intel_engine_id id;
+   const u32 skipped_offset = LRC_HEADER_PAGES * PAGE_SIZE;
+   const u32 skipped_size = LRC_PPHWSP_SZ * PAGE_SIZE + LR_HW_CONTEXT_SIZE;
u32 base;
 
GEM_BUG_ON(guc->ads_vma);
@@ -1062,13 +1070,20 @@ static int guc_ads_create(struct intel_guc *guc)
 * engines after a reset. Here we use the Render ring default
 * context, which must already exist and be pinned in the GGTT,
 * so its address won't change after we've told the GuC where
-* to find it.
+* to find it. Note that we have to skip our header (1 page),
+* because our GuC shared data is there.
 */
blob->ads.golden_context_lrca =
-   dev_priv->engine[RCS]->status_page.ggtt_offset;
+   guc_ggtt_offset(dev_priv->kernel_context->engine[RCS].state) + 
skipped_offset;
 
+   /*
+* The GuC expects us to exclude the portion of the context image that
+* it skips from the size it is to read. It starts reading from after
+* the execlist context (so skipping the first page [PPHWSP] and 80
+* dwords). Weird guc is weird.
+*/
for_each_engine(engine, dev_priv, id)
-   blob->ads.eng_state_size[engine->guc_id] = engine->context_size;
+   blob->ads.eng_state_size[engine->guc_id] = engine->context_size 
- skipped_size;
 
base = guc_ggtt_offset(vma);
blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
-- 
2.13.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 4/5] drm/i915/execlists: Read the context-status buffer from the HWSP

[Chris Wilson]

The engine provides a mirror of the CSB in the HWSP. If we use the
cacheable reads from the HWSP, we can shave off a few mmio reads per
context-switch interrupt (which are quite frequent!). Just removing a
couple of mmio is not enough to actually reduce any latency, but a small
reduction in overall cpu usage.

Much appreciation for Ben dropping the bombshell that the CSB was in the
HWSP and for Michel in digging out the details.

v2: Don't be lazy, add the defines for the indices.
v3: Include the HWSP in debugfs/i915_engine_info
v4: Check for GVT-g, it currently depends on intercepting CSB mmio

Suggested-by: Ben Widawsky 
Signed-off-by: Chris Wilson 
Cc: Michel Thierry 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Cc: Daniele Ceraolo Spurio 
Cc: Zhenyu Wang 
Cc: Zhi Wang 
Acked-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  7 +--
 drivers/gpu/drm/i915/intel_lrc.c| 16 +++-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 ++
 3 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 620c9218d1c1..5fd01c14a3ec 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3384,6 +3384,7 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
   upper_32_bits(addr), lower_32_bits(addr));
 
if (i915.enable_execlists) {
+   const u32 *hws = 
&engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
u32 ptr, read, write;
unsigned int idx;
 
@@ -3404,10 +3405,12 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
write += GEN8_CSB_ENTRIES;
while (read < write) {
idx = ++read % GEN8_CSB_ENTRIES;
-   seq_printf(m, "\tExeclist CSB[%d]: 0x%08x, 
context: %d\n",
+   seq_printf(m, "\tExeclist CSB[%d]: 0x%08x 
[0x%08x in hwsp], context: %d [%d in hwsp]\n",
   idx,
   
I915_READ(RING_CONTEXT_STATUS_BUF_LO(engine, idx)),
-  
I915_READ(RING_CONTEXT_STATUS_BUF_HI(engine, idx)));
+  hws[idx * 2],
+  
I915_READ(RING_CONTEXT_STATUS_BUF_HI(engine, idx)),
+  hws[idx * 2 + 1]);
}
 
rcu_read_lock();
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3469badedbe0..5b721f65d232 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -547,10 +547,17 @@ static void intel_lrc_irq_handler(unsigned long data)
while (test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted)) {
u32 __iomem *csb_mmio =
dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
-   u32 __iomem *buf =
-   dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0));
+   /* The HWSP contains a (cacheable) mirror of the CSB */
+   const u32 *buf =
+   &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
unsigned int head, tail;
 
+   /* However GVT emulation depends upon intercepting CSB mmio */
+   if (unlikely(intel_vgpu_active(dev_priv))) {
+   buf = (u32 * __force)
+   (dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
+   }
+
/* The write will be ordered by the uncached read (itself
 * a memory barrier), so we do not need another in the form
 * of a locked instruction. The race between the interrupt
@@ -590,13 +597,12 @@ static void intel_lrc_irq_handler(unsigned long data)
 * status notifier.
 */
 
-   status = readl(buf + 2 * head);
+   status = buf[2 * head];
if (!(status & GEN8_CTX_STATUS_COMPLETED_MASK))
continue;
 
/* Check the context/desc id for this event matches */
-   GEM_DEBUG_BUG_ON(readl(buf + 2 * head + 1) !=
-port->context_id);
+   GEM_DEBUG_BUG_ON(buf[2 * head + 1] != port->context_id);
 
rq = port_unpack(port, &count);
GEM_BUG_ON(count == 0);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index d33c93444c0d..2c55cfa14fb5 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbu

[Intel-gfx] [PATCH v3 3/5] drm/i915/lrc: allocate separate page for HWSP

[Chris Wilson]

From: Daniele Ceraolo Spurio 

On gen8+ we're currently using the PPHWSP of the kernel ctx as the
global HWSP. However, when the kernel ctx gets submitted (e.g. from
__intel_autoenable_gt_powersave) the HW will use that page as both
HWSP and PPHWSP. This causes a conflict in the register arena of the
HWSP, i.e. dword indices below 0x30. We don't current utilize this arena,
but in the following patches we will take advantage of the cached
register state for handling execlist's context status interrupt.

To avoid the conflict, instead of re-using the PPHWSP of the kernel
ctx we can allocate a separate page for the HWSP like what happens for
pre-execlists platform.

v2: Add a use-case for the register arena of the HWSP.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Michel Thierry 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1499357440-34688-1-git-send-email-daniele.ceraolospu...@intel.com
Signed-off-by: Chris Wilson 
Reviewded-by: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  | 126 +++-
 drivers/gpu/drm/i915/intel_lrc.c|  34 +
 drivers/gpu/drm/i915/intel_ringbuffer.c | 125 +--
 3 files changed, 127 insertions(+), 158 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 24db316e0fd1..cba120f3d89d 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -445,6 +445,114 @@ static void intel_engine_cleanup_scratch(struct 
intel_engine_cs *engine)
i915_vma_unpin_and_release(&engine->scratch);
 }
 
+static void cleanup_phys_status_page(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *dev_priv = engine->i915;
+
+   if (!dev_priv->status_page_dmah)
+   return;
+
+   drm_pci_free(&dev_priv->drm, dev_priv->status_page_dmah);
+   engine->status_page.page_addr = NULL;
+}
+
+static void cleanup_status_page(struct intel_engine_cs *engine)
+{
+   struct i915_vma *vma;
+   struct drm_i915_gem_object *obj;
+
+   vma = fetch_and_zero(&engine->status_page.vma);
+   if (!vma)
+   return;
+
+   obj = vma->obj;
+
+   i915_vma_unpin(vma);
+   i915_vma_close(vma);
+
+   i915_gem_object_unpin_map(obj);
+   __i915_gem_object_release_unless_active(obj);
+}
+
+static int init_status_page(struct intel_engine_cs *engine)
+{
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+   unsigned int flags;
+   void *vaddr;
+   int ret;
+
+   obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
+   if (IS_ERR(obj)) {
+   DRM_ERROR("Failed to allocate status page\n");
+   return PTR_ERR(obj);
+   }
+
+   ret = i915_gem_object_set_cache_level(obj, I915_CACHE_LLC);
+   if (ret)
+   goto err;
+
+   vma = i915_vma_instance(obj, &engine->i915->ggtt.base, NULL);
+   if (IS_ERR(vma)) {
+   ret = PTR_ERR(vma);
+   goto err;
+   }
+
+   flags = PIN_GLOBAL;
+   if (!HAS_LLC(engine->i915))
+   /* On g33, we cannot place HWS above 256MiB, so
+* restrict its pinning to the low mappable arena.
+* Though this restriction is not documented for
+* gen4, gen5, or byt, they also behave similarly
+* and hang if the HWS is placed at the top of the
+* GTT. To generalise, it appears that all !llc
+* platforms have issues with us placing the HWS
+* above the mappable region (even though we never
+* actualy map it).
+*/
+   flags |= PIN_MAPPABLE;
+   ret = i915_vma_pin(vma, 0, 4096, flags);
+   if (ret)
+   goto err;
+
+   vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+   if (IS_ERR(vaddr)) {
+   ret = PTR_ERR(vaddr);
+   goto err_unpin;
+   }
+
+   engine->status_page.vma = vma;
+   engine->status_page.ggtt_offset = i915_ggtt_offset(vma);
+   engine->status_page.page_addr = memset(vaddr, 0, PAGE_SIZE);
+
+   DRM_DEBUG_DRIVER("%s hws offset: 0x%08x\n",
+engine->name, i915_ggtt_offset(vma));
+   return 0;
+
+err_unpin:
+   i915_vma_unpin(vma);
+err:
+   i915_gem_object_put(obj);
+   return ret;
+}
+
+static int init_phys_status_page(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *dev_priv = engine->i915;
+
+   GEM_BUG_ON(engine->id != RCS);
+
+   dev_priv->status_page_dmah =
+   drm_pci_alloc(&dev_priv->drm, PAGE_SIZE, PAGE_SIZE);
+   if (!dev_priv->status_page_dmah)
+   return -ENOMEM;
+
+   engine->status_page.page_addr = dev_priv->status_page_dmah->vaddr;
+   memset(engine->status_page.page_addr, 0, PAGE_SIZE);
+
+   return 0;
+}
+
 /**
  * intel_engines_init_common - initialize cengine state wh

[Intel-gfx] [PATCH v3 5/5] drm/i915/execlists: Read the context-status HEAD from the HWSP

[Chris Wilson]

The engine also provides a mirror of the CSB write pointer in the HWSP,
but not of our read pointer. To take advantage of this we need to
remember where we read up to on the last interrupt and continue off from
there. This poses a problem following a reset, as we don't know where
the hw will start writing from, and due to the use of power contexts we
cannot perform that query during the reset itself. So we continue the
current modus operandi of delaying the first read of the context-status
read/write pointers until after the first interrupt. With this we should
now have eliminated all uncached mmio reads in handling the
context-status interrupt, though we still have the uncached mmio writes
for submitting new work, and many uncached mmio reads in the global
interrupt handler itself. Still a step in the right direction towards
reducing our resubmit latency, although it appears lost in the noise!

v2: Cannonlake moved the CSB write index
v3: Include the sw/hwsp state in debugfs/i915_engine_info
v4: Also revert to using CSB mmio for GVT-g

Signed-off-by: Chris Wilson 
Cc: Michel Thierry 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Cc: Daniele Ceraolo Spurio 
Cc: Zhenyu Wang 
Cc: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  6 --
 drivers/gpu/drm/i915/i915_drv.h |  8 
 drivers/gpu/drm/i915/intel_lrc.c| 25 -
 drivers/gpu/drm/i915/intel_ringbuffer.h |  3 +++
 4 files changed, 35 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5fd01c14a3ec..552aef61b47b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3395,8 +3395,10 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
ptr = I915_READ(RING_CONTEXT_STATUS_PTR(engine));
read = GEN8_CSB_READ_PTR(ptr);
write = GEN8_CSB_WRITE_PTR(ptr);
-   seq_printf(m, "\tExeclist CSB read %d, write %d\n",
-  read, write);
+   seq_printf(m, "\tExeclist CSB read %d [%d cached], 
write %d [%d from hws]\n",
+  read, engine->csb_head,
+  write,
+  intel_read_status_page(engine, 
intel_hws_csb_write_index(engine->i915)));
if (read >= GEN8_CSB_ENTRIES)
read = 0;
if (write >= GEN8_CSB_ENTRIES)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 81cd21ecfa7d..f62c9db8a9a8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4228,4 +4228,12 @@ static inline bool i915_gem_object_is_coherent(struct 
drm_i915_gem_object *obj)
HAS_LLC(to_i915(obj->base.dev)));
 }
 
+static inline int intel_hws_csb_write_index(struct drm_i915_private *i915)
+{
+   if (INTEL_GEN(i915) >= 10)
+   return CNL_HWS_CSB_WRITE_INDEX;
+   else
+   return I915_HWS_CSB_WRITE_INDEX;
+}
+
 #endif
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 5b721f65d232..7c3dce27e504 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -556,6 +556,7 @@ static void intel_lrc_irq_handler(unsigned long data)
if (unlikely(intel_vgpu_active(dev_priv))) {
buf = (u32 * __force)
(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
+   engine->csb_head = -1;
}
 
/* The write will be ordered by the uncached read (itself
@@ -569,9 +570,19 @@ static void intel_lrc_irq_handler(unsigned long data)
 * is set and we do a new loop.
 */
__clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
-   head = readl(csb_mmio);
-   tail = GEN8_CSB_WRITE_PTR(head);
-   head = GEN8_CSB_READ_PTR(head);
+   if (unlikely(engine->csb_head == -1)) { /* following a reset */
+   head = readl(csb_mmio);
+   tail = GEN8_CSB_WRITE_PTR(head);
+   head = GEN8_CSB_READ_PTR(head);
+   engine->csb_head = head;
+   } else {
+   const int write_idx =
+   intel_hws_csb_write_index(dev_priv) -
+   I915_HWS_CSB_BUF0_INDEX;
+
+   head = engine->csb_head;
+   tail = buf[write_idx];
+   }
while (head != tail) {
struct drm_i915_gem_request *rq;
unsigned int status;
@@ -625,8 +636,11 @@ static void intel_lrc_irq_handler(unsigned long data)
   !(status & GEN

[Intel-gfx] [PATCH 11/13] drm/i915/bxt: Enable IPC support

[Mahesh Kumar]

From: "Kumar, Mahesh" 

This patch adds IPC support. This patch also enables IPC in all supported
platforms.
IPC (Isochronous Priority Control) is the hardware feature, which
dynamically controls the memory read priority of Display.

When IPC is enabled, plane read requests are sent at high priority until
filling above the transition watermark, then the requests are sent at
lower priority until dropping below the level 0 watermark.
The lower priority requests allow other memory clients to have better
memory access. When IPC is disabled, all plane read requests are sent at
high priority.

Changes since V1:
 - Remove commandline parameter to disable ipc
 - Address Paulo's comments
Changes since V2:
 - Address review comments
 - Set ipc_enabled flag
Changes since V3:
 - move ipc_enabled flag assignment inside intel_ipc_enable function
Changes since V4:
 - Re-enable IPC after suspend/resume
Changes since V5:
 - Enable IPC for all gen >=9 except SKL
Changes since V6:
 - fix commit msg
 - after resume program IPC based on SW state.

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_drv.c  |  4 +++-
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 drivers/gpu/drm/i915/intel_display.c |  1 +
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_pm.c  | 24 
 5 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9167a73f3c69..340424ed1fce 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1334,7 +1334,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
intel_runtime_pm_enable(dev_priv);
 
-   dev_priv->ipc_enabled = false;
+   intel_init_ipc(dev_priv);
 
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG))
DRM_INFO("DRM_I915_DEBUG enabled\n");
@@ -2598,6 +2598,8 @@ static int intel_runtime_resume(struct device *kdev)
if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
intel_hpd_init(dev_priv);
 
+   intel_enable_ipc(dev_priv);
+
enable_rpm_wakeref_asserts(dev_priv);
 
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 64cc674b652a..09af90f8cd0a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6728,6 +6728,7 @@ enum {
 #define  DISP_FBC_WM_DIS   (1<<15)
 #define DISP_ARB_CTL2  _MMIO(0x45004)
 #define  DISP_DATA_PARTITION_5_6   (1<<6)
+#define  DISP_IPC_ENABLE   (1<<3)
 #define DBUF_CTL   _MMIO(0x45008)
 #define  DBUF_POWER_REQUEST(1<<31)
 #define  DBUF_POWER_STATE  (1<<30)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0648fd74be87..e610b4395dcc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15723,6 +15723,7 @@ void intel_display_resume(struct drm_device *dev)
if (!ret)
ret = __intel_display_resume(dev, state, &ctx);
 
+   intel_enable_ipc(dev_priv);
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d17a32437f07..9f52922afce6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1883,6 +1883,8 @@ bool ilk_disable_lp_wm(struct drm_device *dev);
 int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
 int skl_check_pipe_max_pixel_rate(struct intel_crtc *intel_crtc,
  struct intel_crtc_state *cstate);
+void intel_init_ipc(struct drm_i915_private *dev_priv);
+void intel_enable_ipc(struct drm_i915_private *dev_priv);
 static inline int intel_enable_rc6(void)
 {
return i915.enable_rc6;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ad3b3d758d5c..e2641ddeb2bf 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5772,6 +5772,30 @@ void intel_update_watermarks(struct intel_crtc *crtc)
dev_priv->display.update_wm(crtc);
 }
 
+void intel_enable_ipc(struct drm_i915_private *dev_priv)
+{
+   u32 val;
+
+   val = I915_READ(DISP_ARB_CTL2);
+
+   if (dev_priv->ipc_enabled)
+   val |= DISP_IPC_ENABLE;
+   else
+   val &= ~DISP_IPC_ENABLE;
+
+   I915_WRITE(DISP_ARB_CTL2, val);
+}
+
+void intel_init_ipc(struct drm_i915_private *dev_priv)
+{
+   dev_priv->ipc_enabled = false;
+   if (INTEL_GEN(dev_priv) < 9 || IS_SKYLAKE(dev_priv))
+   return;
+
+   dev_priv->ipc_enabled = true;
+   intel_enable_ipc(dev_priv);
+}
+
 /*
  * Lock protecting IPS related data structures
  */
-- 
2.13.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/int

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Daniel Vetter]

On Thu, Jul 13, 2017 at 12:15 PM, Ramalingam C  wrote:
>
>
> On Thursday 13 July 2017 02:15 PM, Daniel Vetter wrote:
>
> On Thu, Jul 13, 2017 at 8:54 AM, Ramalingam C 
> wrote:
>
> On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote:
>
> On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul  wrote:
>
> Why all these intermediate steps and different failure modes? Either hdcp
> works, or it doesnt (and we can split up with the type 0 or type 1 if
> needed), but I don't know what userspace would do with all the other
> stuff?
>
> enum values  HDCP_ENABLE, HDCP_ENABLE_TYPE1 and HDCP_DISABLE along with
> kobj-uevent
> for HDCP state change, could do the bare minimal HDCP1.4 and HDCP2.2
> configuration.
>
> And without Type info it is not possible for HDCP2.2.
>
> I've had requests from chrome team to expose HDCP version, so I don't think
> this
> is too contentious.
>
> I think it'd still be easier if we start out with the current content
> protection props that CrOS is using, and then figure out how to layer
> the exact version/standard on top? One thing at a time and all that.
> -Daniel
>
> I understand the approach.
>
> But Only problem is current upstreaming effort is for HDCP2.2 support at DRM
> with a design which can
> easily accommodate other versions too. So we  need to stretch current CrOS
> property a bit with
> ENABLE_TYPE1 and UNSUPPORTED etc. Hope that should be fine for all.
>
> Yeah, but if we just go with enable (without specifying the type) we
> could still enable the highest hdcp level (so 2.2 for our case). At
> least I don't see a reason why we need to already have the
> enable_type1 thing. Can you pls explain why you think this is
> necessary?
>
> There seems to be a need to force type1, but I think it's easier to do
> that as an extension. Of course we need to keep it in mind meanwhile.
>
> Background for this need of Type info in HDCP2.2 implementation is as
> follows:

Aside: You're quoting is broken for inline quoting. Either fix the
quoting or top-quote (there's no difference between your text and
mine, mine should be indented with > or | or similar).

> HDCP2.2 Spec classify the protected content as Type 0 and Type 1. For
> Example lets say
> - A HDCP2.2 Src is connected to HDCP repeater
> - that repeater is connected to a HDCP2.2 panel
> - that same repeater is also connected to a HDCP1.4 panel.
>
> In this topology, as part of Repeater authentication:
> - HDCP2.2 Source will mention the Content Type to HDCP2.2 Repeater
> - Repeater can transmit this Type 1 content to HDCP2.2 compliant sink only
> (which is HDCP 2.2 panel here).
> - Repeater can transmit any type0 content to any other devices (like HDCP1.4
> panel here).
> - Device with no HDCP support will get Neither of Type 0 or Type 1.
>
> So if we implement HDCP2.2 with HDCP_ENABLE state alone there is no way for
> Userspace
> to request for HDCP2.2 protection only. In this case we wont know the
> content type classification.

Yes, that is the case, but also the point of gradual enabling. Atm
(with the current CrOS usersapce) userspace can ask for "pls give me
content protection, I don't care what level/type". That itself is
already useful, and a good step forward. Allowing to ask for a
specific type is something on top.

> Even if we force Content type to Type1, in above topology Type 0 content
> that could be rendered to
> HDCP1.4 compliant panel wont be rendered as that has been forcibly
> classified as Type 1 by KMD.

Why? HDCP_ENABLE would just give you the "best" HDCP, so we'd fall
back to type 0 (if that's available).

> Forcing type 1 content to Type 0 will break the association of type1 content
> to HDCP2.2 devices only.

I didn't propose to force type1 everywhere. Why do you think this is needed.

> More than that Devices with our indented DRM HDCP2.2 support wont pass the
> HDCP2.2 compliance.
> Considering we could extend the CrOS Userspace for HDCP2.2, I would prefer
> to go ahead with
> HDCP_ENABLE_TYPE1 along with HDCP_ENABLE.

Yes, it's only hdcp1.4, and getting to full hdcp2.2 will take more
work. You can do all of that in one go, but my experience with
upstreaming new uabi is that usually that's not the most effective way
to go about things. But in the end, that's your choice.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 11/13] drm/i915/bxt: Enable IPC support

[Chris Wilson]

Quoting Mahesh Kumar (2017-07-13 11:39:02)
> +void intel_enable_ipc(struct drm_i915_private *dev_priv)
> +{
> +   u32 val;
> +
> +   val = I915_READ(DISP_ARB_CTL2);
> +
> +   if (dev_priv->ipc_enabled)
> +   val |= DISP_IPC_ENABLE;
> +   else
> +   val &= ~DISP_IPC_ENABLE;
> +
> +   I915_WRITE(DISP_ARB_CTL2, val);
> +}
> +
> +void intel_init_ipc(struct drm_i915_private *dev_priv)
> +{
> +   dev_priv->ipc_enabled = false;
> +   if (INTEL_GEN(dev_priv) < 9 || IS_SKYLAKE(dev_priv))
> +   return;

So dev_priv->ipc_enabled is just a dev_priv->info.has_ipc, its state
never changes at runtime? Using a intel_device_info field then has a few
useful side-effects including automatic printing in the lists of
capabilities.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v3,1/5] drm/i915/lrc: Clarify the format of the context image

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/5] drm/i915/lrc: Clarify the format of the 
context image
URL   : https://patchwork.freedesktop.org/series/27232/
State : warning

== Summary ==

Series 27232v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/27232/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> SKIP   (fi-skl-x1585l)

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:444s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:431s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:356s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:528s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:500s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:492s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:482s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:595s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:443s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:413s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:421s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:490s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:494s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:465s
fi-kbl-7560u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:581s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:582s
fi-pnv-d510  total:279  pass:222  dwarn:2   dfail:0   fail:0   skip:55  
time:561s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:456s
fi-skl-6700hqtotal:279  pass:262  dwarn:0   dfail:0   fail:0   skip:17  
time:583s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:463s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:476s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:433s
fi-skl-x1585ltotal:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:469s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:544s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:402s

8ad9e19aafea47c272163c2cbf554e06ff7f9857 drm-tip: 2017y-07m-11d-19h-08m-20s UTC 
integration manifest
01e5e06 drm/i915/execlists: Read the context-status HEAD from the HWSP
047511e drm/i915/execlists: Read the context-status buffer from the HWSP
8a537bb drm/i915/lrc: allocate separate page for HWSP
5e246f6 drm/i915/guc: Don't make assumptions while getting the lrca offset
9e5da4b drm/i915/lrc: Clarify the format of the context image

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5182/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] igt/perf: add tests to verify create/destroy userspace configs

[Lionel Landwerlin]

On 10/07/17 12:55, Matthew Auld wrote:

On 7 July 2017 at 17:57, Lionel Landwerlin
 wrote:

Signed-off-by: Lionel Landwerlin 
---
  tests/perf.c | 135 +++
  1 file changed, 135 insertions(+)

diff --git a/tests/perf.c b/tests/perf.c
index db28ba1f..14bbb361 100644
--- a/tests/perf.c
+++ b/tests/perf.c
@@ -146,6 +146,33 @@ enum drm_i915_perf_record_type {
  };
  #endif /* !DRM_I915_PERF_OPEN */

+#ifndef DRM_IOCTL_I915_PERF_ADD_CONFIG
+
+#define DRM_I915_PERF_ADD_CONFIG   0x37
+#define DRM_I915_PERF_REMOVE_CONFIG0x38
+
+#define DRM_IOCTL_I915_PERF_ADD_CONFIG DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_PERF_ADD_CONFIG, struct drm_i915_perf_oa_config)
+#define DRM_IOCTL_I915_PERF_REMOVE_CONFIG  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_PERF_REMOVE_CONFIG, __u64)
+
+/**
+ * Structure to upload perf dynamic configuration into the kernel.
+ */
+struct drm_i915_perf_oa_config {
+   /* string formatted like "%08x-%04x-%04x-%04x-%012x" **/
+   __u64 uuid;
+
+   __u32 n_mux_regs;
+   __u64 mux_regs;
+
+   __u32 n_boolean_regs;
+   __u64 boolean_regs;
+
+   __u32 n_flex_regs;
+   __u64 flex_regs;
+};
+
+#endif /* !DRM_IOCTL_I915_PERF_ADD_CONFIG */
+
  struct accumulator {
  #define MAX_RAW_OA_COUNTERS 62
 enum drm_i915_oa_format format;
@@ -4001,6 +4028,108 @@ test_rc6_disable(void)
 igt_assert_neq(n_events_end - n_events_start, 0);
  }

+static void
+test_create_destroy_userspace_invalid_config(void)
+{
+   struct drm_i915_perf_oa_config userspace_config;
+   const char *uuid = "01234567-0123-0123-0123-0123456789ab";
+   const char *invalid_uuid = "blablabla-wrong";
+   uint32_t mux_regs[] = { 0x9888 /* NOA_WRITE */, 0x0 };
+   uint32_t invalid_mux_regs[] = { 0x12345678 /* invalid register */, 0x0 
};

Maybe also test for bool/flex?


It's a bit tricky because this is per generation stuff...




+
+   memset(&userspace_config, 0, sizeof(userspace_config));
+
+   /* invalid uuid */
+   userspace_config.uuid = to_user_pointer(invalid_uuid);
+   userspace_config.n_mux_regs = 1;
+   userspace_config.mux_regs = to_user_pointer(mux_regs);
+   userspace_config.n_boolean_regs = 0;
+   userspace_config.n_flex_regs = 0;

Test for adding two configs with conflicting uuid's?


Done.




+
+   do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &userspace_config, 
EINVAL);
+
+   /* invalid mux_regs */
+   userspace_config.uuid = to_user_pointer(uuid);
+   userspace_config.n_mux_regs = 1;
+   userspace_config.mux_regs = to_user_pointer(invalid_mux_regs);
+   userspace_config.n_boolean_regs = 0;
+   userspace_config.n_flex_regs = 0;
+
+   do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &userspace_config, 
EINVAL);
+
+   /* empty config */
+   userspace_config.uuid = to_user_pointer(uuid);
+   userspace_config.n_mux_regs = 0;
+   userspace_config.mux_regs = to_user_pointer(mux_regs);
+   userspace_config.n_boolean_regs = 0;
+   userspace_config.n_flex_regs = 0;
+
+   do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &userspace_config, 
EINVAL);
+
+   /* empty config with null pointers */
+   userspace_config.uuid = to_user_pointer(uuid);
+   userspace_config.n_mux_regs = 1;
+   userspace_config.mux_regs = to_user_pointer(NULL);
+   userspace_config.n_boolean_regs = 2;
+   userspace_config.boolean_regs = to_user_pointer(NULL);
+   userspace_config.n_flex_regs = 3;
+   userspace_config.flex_regs = to_user_pointer(NULL);
+
+   do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &userspace_config, 
EINVAL);
+}

Maybe we also want some invalid tests for removing a config?

Also add/remove without root?


Done.




+
+static void
+test_create_destroy_userspace_config(void)
+{
+   struct drm_i915_perf_oa_config config;
+   const char *uuid = "01234567-0123-0123-0123-0123456789ab";
+   uint32_t mux_regs[] = { 0x9888 /* NOA_WRITE */, 0x0 };
+   int ret;
+   uint64_t config_id;

int config_id;


The kernel interface takes a uint64_t.




+   uint64_t properties[] = {
+   DRM_I915_PERF_PROP_OA_METRICS_SET, 0, /* Filled later */
+
+   /* OA unit configuration */
+   DRM_I915_PERF_PROP_SAMPLE_OA, true,
+   DRM_I915_PERF_PROP_OA_FORMAT, test_oa_format,
+   DRM_I915_PERF_PROP_OA_EXPONENT, oa_exp_1_millisec,
+   DRM_I915_PERF_PROP_OA_METRICS_SET
+   };
+   struct drm_i915_perf_open_param param = {
+   .flags = I915_PERF_FLAG_FD_CLOEXEC |
+   I915_PERF_FLAG_FD_NONBLOCK |
+   I915_PERF_FLAG_DISABLED,
+   .num_properties = ARRAY_SIZE(properties) / 2,
+   .properties_ptr = to_user_pointer(properties),
+   };
+   char path[512];
+
+   snprintf(path, sizeof(path), "/sys/class/drm/card%d/metrics/%s/id", 
card, uuid);
+
+ 

[Intel-gfx] [PATCH v2 i-g-t] igt/perf: add tests to verify create/destroy userspace configs

[Lionel Landwerlin]

v2: Add tests regarding removing configs (Matthew)
Add tests regarding adding/removing configs without permissions
(Matthew)

Signed-off-by: Lionel Landwerlin 
---
 tests/perf.c | 201 +++
 1 file changed, 201 insertions(+)

diff --git a/tests/perf.c b/tests/perf.c
index db28ba1f..47caf1c6 100644
--- a/tests/perf.c
+++ b/tests/perf.c
@@ -146,6 +146,36 @@ enum drm_i915_perf_record_type {
 };
 #endif /* !DRM_I915_PERF_OPEN */

+#ifndef DRM_IOCTL_I915_PERF_ADD_CONFIG
+
+#define DRM_I915_PERF_ADD_CONFIG   0x37
+#define DRM_I915_PERF_REMOVE_CONFIG0x38
+
+#define DRM_IOCTL_I915_PERF_ADD_CONFIG DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_PERF_ADD_CONFIG, struct drm_i915_perf_oa_config)
+#define DRM_IOCTL_I915_PERF_REMOVE_CONFIG  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_PERF_REMOVE_CONFIG, __u64)
+
+/**
+ * Structure to upload perf dynamic configuration into the kernel.
+ */
+struct drm_i915_perf_oa_config {
+   /** String formatted like "%08x-%04x-%04x-%04x-%012x" */
+   __u64 uuid;
+
+   __u32 n_mux_regs;
+   __u32 pad0;
+   __u64 mux_regs;
+
+   __u32 n_boolean_regs;
+   __u32 pad1;
+   __u64 boolean_regs;
+
+   __u32 n_flex_regs;
+   __u32 pad2;
+   __u64 flex_regs;
+};
+
+#endif /* !DRM_IOCTL_I915_PERF_ADD_CONFIG */
+
 struct accumulator {
 #define MAX_RAW_OA_COUNTERS 62
enum drm_i915_oa_format format;
@@ -4001,6 +4031,168 @@ test_rc6_disable(void)
igt_assert_neq(n_events_end - n_events_start, 0);
 }

+static void
+test_invalid_userspace_config_create(void)
+{
+   struct drm_i915_perf_oa_config config;
+   const char *uuid = "01234567-0123-0123-0123-0123456789ab";
+   const char *invalid_uuid = "blablabla-wrong";
+   uint32_t mux_regs[] = { 0x9888 /* NOA_WRITE */, 0x0 };
+   uint32_t invalid_mux_regs[] = { 0x12345678 /* invalid register */, 0x0 
};
+
+   memset(&config, 0, sizeof(config));
+
+   /* invalid uuid */
+   config.uuid = to_user_pointer(invalid_uuid);
+   config.n_mux_regs = 1;
+   config.mux_regs = to_user_pointer(mux_regs);
+   config.n_boolean_regs = 0;
+   config.n_flex_regs = 0;
+
+   do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config, EINVAL);
+
+   /* invalid mux_regs */
+   config.uuid = to_user_pointer(uuid);
+   config.n_mux_regs = 1;
+   config.mux_regs = to_user_pointer(invalid_mux_regs);
+   config.n_boolean_regs = 0;
+   config.n_flex_regs = 0;
+
+   do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config, EINVAL);
+
+   /* empty config */
+   config.uuid = to_user_pointer(uuid);
+   config.n_mux_regs = 0;
+   config.mux_regs = to_user_pointer(mux_regs);
+   config.n_boolean_regs = 0;
+   config.n_flex_regs = 0;
+
+   do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config, EINVAL);
+
+   /* empty config with null pointers */
+   config.uuid = to_user_pointer(uuid);
+   config.n_mux_regs = 1;
+   config.mux_regs = to_user_pointer(NULL);
+   config.n_boolean_regs = 2;
+   config.boolean_regs = to_user_pointer(NULL);
+   config.n_flex_regs = 3;
+   config.flex_regs = to_user_pointer(NULL);
+
+   do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config, EINVAL);
+}
+
+static void
+test_invalid_userspace_config_remove(void)
+{
+   struct drm_i915_perf_oa_config config;
+   const char *uuid = "01234567-0123-0123-0123-0123456789ab";
+   uint32_t mux_regs[] = { 0x9888 /* NOA_WRITE */, 0x0 };
+   uint64_t config_id, wrong_config_id = 9;
+   char path[512];
+   int ret;
+
+   snprintf(path, sizeof(path), "/sys/class/drm/card%d/metrics/%s/id", 
card, uuid);
+
+   /* Destroy previous configuration if present */
+   if (try_read_u64_file(path, &config_id))
+ igt_assert(igt_ioctl(drm_fd, DRM_IOCTL_I915_PERF_REMOVE_CONFIG, 
&config_id) == 0);
+
+   memset(&config, 0, sizeof(config));
+
+   config.uuid = to_user_pointer(uuid);
+
+   config.n_mux_regs = 1;
+   config.mux_regs = to_user_pointer(mux_regs);
+   config.n_boolean_regs = 0;
+   config.n_flex_regs = 0;
+
+   ret = igt_ioctl(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config);
+   igt_assert(ret > 0);
+   config_id = ret;
+
+   /* Removing configs without permissions should fail. */
+   igt_fork(child, 1) {
+   igt_drop_root();
+
+   do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_REMOVE_CONFIG, 
&config_id, EACCES);
+   }
+   igt_waitchildren();
+
+   /* Removing invalid config ID should fail. */
+   do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_REMOVE_CONFIG, 
&wrong_config_id, EINVAL);
+
+   igt_assert(igt_ioctl(drm_fd, DRM_IOCTL_I915_PERF_REMOVE_CONFIG, 
&config_id) == 0);
+}
+
+static void
+test_create_destroy_userspace_config(void)
+{
+   struct drm_i915_perf_oa_config config;
+   const char *uuid = "01234567-0123-01

[Intel-gfx] [PATCH v2 0/2] Add support for loadable OA configs

[Lionel Landwerlin]

Hi,

Here is an update following Matthew's comments. There is significant
changes in the pruning configs patch. I thought it would make more
sense to completely rework how we hold configs in kernel since we're
just going to leave the test one.

Cheers,

Lionel Landwerlin (1):
  drm/i915/perf: prune OA configs

Matthew Auld (1):
  drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

 drivers/gpu/drm/i915/i915_drv.c   |2 +
 drivers/gpu/drm/i915/i915_drv.h   |   69 +-
 drivers/gpu/drm/i915/i915_oa_bdw.c| 5360 +
 drivers/gpu/drm/i915/i915_oa_bdw.h|8 +-
 drivers/gpu/drm/i915/i915_oa_bxt.c| 2623 +---
 drivers/gpu/drm/i915/i915_oa_bxt.h|8 +-
 drivers/gpu/drm/i915/i915_oa_chv.c| 2806 +
 drivers/gpu/drm/i915/i915_oa_chv.h|8 +-
 drivers/gpu/drm/i915/i915_oa_glk.c| 2535 +---
 drivers/gpu/drm/i915/i915_oa_glk.h|8 +-
 drivers/gpu/drm/i915/i915_oa_hsw.c|  764 +
 drivers/gpu/drm/i915/i915_oa_hsw.h|8 +-
 drivers/gpu/drm/i915/i915_oa_kblgt2.c | 2971 +-
 drivers/gpu/drm/i915/i915_oa_kblgt2.h |8 +-
 drivers/gpu/drm/i915/i915_oa_kblgt3.c | 3020 +--
 drivers/gpu/drm/i915/i915_oa_kblgt3.h |8 +-
 drivers/gpu/drm/i915/i915_oa_sklgt2.c | 3458 +
 drivers/gpu/drm/i915/i915_oa_sklgt2.h |8 +-
 drivers/gpu/drm/i915/i915_oa_sklgt3.c | 3019 +--
 drivers/gpu/drm/i915/i915_oa_sklgt3.h |8 +-
 drivers/gpu/drm/i915/i915_oa_sklgt4.c | 3073 +--
 drivers/gpu/drm/i915/i915_oa_sklgt4.h |8 +-
 drivers/gpu/drm/i915/i915_perf.c  |  650 ++--
 drivers/gpu/drm/i915/i915_reg.h   |2 +
 include/uapi/drm/i915_drm.h   |   24 +
 25 files changed, 902 insertions(+), 29554 deletions(-)

--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

[Lionel Landwerlin]

From: Matthew Auld 

The motivation behind this new interface is expose at runtime the
creation of new OA configs which can be used as part of the i915 perf
open interface. This will enable the kernel to learn new configs which
may be experimental, or otherwise not part of the core set currently
available through the i915 perf interface.

This will relieve the kernel from holding all the possible configs, so
we can leave only the test configs here.

Signed-off-by: Matthew Auld 
Signed-off-by: Lionel Landwerlin 
Signed-off-by: Andrzej Datczuk 
---
 drivers/gpu/drm/i915/i915_drv.c  |   2 +
 drivers/gpu/drm/i915/i915_drv.h  |  25 +++
 drivers/gpu/drm/i915/i915_perf.c | 351 ++-
 drivers/gpu/drm/i915/i915_reg.h  |   2 +
 include/uapi/drm/i915_drm.h  |  24 +++
 5 files changed, 403 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d310d8245dca..a3d339670ec1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2730,6 +2730,8 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, 
i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 
 static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0c45a89d165e..3d62276d9fad 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2037,6 +2037,25 @@ struct i915_perf_stream {
  */
 struct i915_oa_ops {
/**
+* @is_valid_b_counter_reg: Validates register's address for
+* programming boolean counters for a particular platform.
+*/
+   bool (*is_valid_b_counter_reg)(struct drm_i915_private *dev_priv,
+  u32 addr);
+
+   /**
+* @is_valid_mux_reg: Validates register's address for programming mux
+* for a particular platform.
+*/
+   bool (*is_valid_mux_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+   /**
+* @is_valid_flex_reg: Validates register's address for programming
+* flex EU filtering for a particular platform.
+*/
+   bool (*is_valid_flex_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+   /**
 * @init_oa_buffer: Resets the head and tail pointers of the
 * circular buffer for periodic OA reports.
 *
@@ -2427,6 +2446,8 @@ struct drm_i915_private {
struct mutex lock;
struct list_head streams;
 
+   struct idr metrics_idr;
+
struct {
struct i915_perf_stream *exclusive_stream;
 
@@ -3595,6 +3616,10 @@ i915_gem_context_lookup_timeline(struct i915_gem_context 
*ctx,
 
 int i915_perf_open_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file);
+int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file);
+int i915_perf_remove_config_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file);
 void i915_oa_init_reg_state(struct intel_engine_cs *engine,
struct i915_gem_context *ctx,
uint32_t *reg_state);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index d4647b3d8119..5f3d544a93cf 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2652,7 +2652,7 @@ static struct i915_oa_config *get_oa_config(struct 
drm_i915_private *dev_priv,
if (metrics_set == 1)
return &dev_priv->perf.oa.test_config;
 
-   return NULL;
+   return idr_find(&dev_priv->perf.metrics_idr, metrics_set);
 }
 
 /**
@@ -2913,6 +2913,7 @@ void i915_perf_register(struct drm_i915_private *dev_priv)
 &dev_priv->perf.oa.test_config.sysfs_metric);
if (ret)
goto sysfs_error;
+
goto exit;
 
 sysfs_error:
@@ -2944,6 +2945,333 @@ void i915_perf_unregister(struct drm_i915_private 
*dev_priv)
dev_priv->perf.metrics_kobj = NULL;
 }
 
+static bool gen8_is_valid_flex_addr(struct drm_i915_private *dev_priv, u32 
addr)
+{
+   static const i915_reg_t flex_eu_regs[] = {
+   EU_PERF_CNTL0,
+   EU_PERF_CNTL1,
+   EU_PERF_CNTL2,
+   EU_PERF_CNTL3,
+   EU_PERF_CNTL4,
+   EU_PERF_CNTL5,
+   EU_PERF_CNTL6,
+   };
+   int i;
+
+   for (

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

[Lionel Landwerlin]

On 10/07/17 11:48, Matthew Auld wrote:

On 7 July 2017 at 18:08, Lionel Landwerlin
 wrote:

From: Matthew Auld 

The motivation behind this new interface is expose at runtime the
creation of new OA configs which can be used as part of the i915 perf
open interface. This will enable the kernel to learn new configs which
may be experimental, or otherwise not part of the core set currently
available through the i915 perf interface.

This will relieve the kernel from holding all the possible configs, so
we can leave only the test configs here.

Signed-off-by: Matthew Auld 
Signed-off-by: Lionel Landwerlin 
Signed-off-by: Andrzej Datczuk 
---
  drivers/gpu/drm/i915/i915_drv.c  |   2 +
  drivers/gpu/drm/i915/i915_drv.h  |  30 +++
  drivers/gpu/drm/i915/i915_perf.c | 391 ++-
  drivers/gpu/drm/i915/i915_reg.h  |   2 +
  include/uapi/drm/i915_drm.h  |  21 +++
  5 files changed, 441 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d310d8245dca..a3d339670ec1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2730,6 +2730,8 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
 DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
 DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
 DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, 
i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
  };

  static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 81cd21ecfa7d..ce733c2db963 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2009,6 +2009,11 @@ struct i915_perf_stream {
  * type of configured stream.
  */
 const struct i915_perf_stream_ops *ops;
+
+   /**
+* @metrics_set: The ID of the config used by the stream.
+*/
+   int metrics_set;
  };

  /**
@@ -2016,6 +2021,25 @@ struct i915_perf_stream {
   */
  struct i915_oa_ops {
 /**
+* @is_valid_b_counter_reg: Validates register's address for
+* programming boolean counters for a particular platform.
+*/
+   bool (*is_valid_b_counter_reg)(struct drm_i915_private *dev_priv,
+  u32 addr);
+
+   /**
+* @is_valid_mux_reg: Validates register's address for programming mux
+* for a particular platform.
+*/
+   bool (*is_valid_mux_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+   /**
+* @is_valid_flex_reg: Validates register's address for programming
+* flex EU filtering for a particular platform.
+*/
+   bool (*is_valid_flex_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+   /**
  * @init_oa_buffer: Resets the head and tail pointers of the
  * circular buffer for periodic OA reports.
  *
@@ -2413,6 +2437,8 @@ struct drm_i915_private {
 struct mutex lock;
 struct list_head streams;

+   struct idr metrics_idr;
+
 struct {
 struct i915_perf_stream *exclusive_stream;

@@ -3589,6 +3615,10 @@ i915_gem_context_lookup_timeline(struct i915_gem_context 
*ctx,

  int i915_perf_open_ioctl(struct drm_device *dev, void *data,
  struct drm_file *file);
+int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file);
+int i915_perf_remove_config_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file);
  void i915_oa_init_reg_state(struct intel_engine_cs *engine,
 struct i915_gem_context *ctx,
 uint32_t *reg_state);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index d9f77a4d85db..92cb6a7568e7 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -357,6 +357,23 @@ struct perf_open_properties {
 int oa_period_exponent;
  };

+struct i915_oa_dynamic_config
+{
+   char guid[40];
+   int id;
+
+   const struct i915_oa_reg *mux_regs;
+   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 attribute_group sysfs_metric;
+   struct attribute *attrs[2];
+   struct device_attribute sysfs_metric_id;
+};
+
  static u32 gen8_oa_hw_tail_read(struct drm_i915_private *dev_priv)
  {
 return I915_READ(GEN8_OATAILPTR) & GEN8_OATAILPTR_MASK;
@@ -1

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

[Lionel Landwerlin]

On 08/07/17 00:53, Matthew Auld wrote:

On 7 July 2017 at 18:08, Lionel Landwerlin
  wrote:

From: Matthew Auld

The motivation behind this new interface is expose at runtime the
creation of new OA configs which can be used as part of the i915 perf
open interface. This will enable the kernel to learn new configs which
may be experimental, or otherwise not part of the core set currently
available through the i915 perf interface.

This will relieve the kernel from holding all the possible configs, so
we can leave only the test configs here.

Signed-off-by: Matthew Auld
Signed-off-by: Lionel Landwerlin
Signed-off-by: Andrzej Datczuk
---
  drivers/gpu/drm/i915/i915_drv.c  |   2 +
  drivers/gpu/drm/i915/i915_drv.h  |  30 +++
  drivers/gpu/drm/i915/i915_perf.c | 391 ++-
  drivers/gpu/drm/i915/i915_reg.h  |   2 +
  include/uapi/drm/i915_drm.h  |  21 +++
  5 files changed, 441 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d310d8245dca..a3d339670ec1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2730,6 +2730,8 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
 DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
 DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
 DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, 
i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
  };

  static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 81cd21ecfa7d..ce733c2db963 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2009,6 +2009,11 @@ struct i915_perf_stream {
  * type of configured stream.
  */
 const struct i915_perf_stream_ops *ops;
+
+   /**
+* @metrics_set: The ID of the config used by the stream.
+*/
+   int metrics_set;
  };

  /**
@@ -2016,6 +2021,25 @@ struct i915_perf_stream {
   */
  struct i915_oa_ops {
 /**
+* @is_valid_b_counter_reg: Validates register's address for
+* programming boolean counters for a particular platform.
+*/
+   bool (*is_valid_b_counter_reg)(struct drm_i915_private *dev_priv,
+  u32 addr);
+
+   /**
+* @is_valid_mux_reg: Validates register's address for programming mux
+* for a particular platform.
+*/
+   bool (*is_valid_mux_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+   /**
+* @is_valid_flex_reg: Validates register's address for programming
+* flex EU filtering for a particular platform.
+*/
+   bool (*is_valid_flex_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+   /**
  * @init_oa_buffer: Resets the head and tail pointers of the
  * circular buffer for periodic OA reports.
  *
@@ -2413,6 +2437,8 @@ struct drm_i915_private {
 struct mutex lock;
 struct list_head streams;

+   struct idr metrics_idr;
+
 struct {
 struct i915_perf_stream *exclusive_stream;

@@ -3589,6 +3615,10 @@ i915_gem_context_lookup_timeline(struct i915_gem_context 
*ctx,

  int i915_perf_open_ioctl(struct drm_device *dev, void *data,
  struct drm_file *file);
+int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file);
+int i915_perf_remove_config_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file);
  void i915_oa_init_reg_state(struct intel_engine_cs *engine,
 struct i915_gem_context *ctx,
 uint32_t *reg_state);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index d9f77a4d85db..92cb6a7568e7 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -357,6 +357,23 @@ struct perf_open_properties {
 int oa_period_exponent;
  };

+struct i915_oa_dynamic_config
+{
+   char guid[40];

s/guid/uuid/ to be consistent with elsewhere?


done.


+   int id;
+
+   const struct i915_oa_reg *mux_regs;
+   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 attribute_group sysfs_metric;
+   struct attribute *attrs[2];
+   struct device_attribute sysfs_metric_id;
+};
+
  static u32 gen8_oa_hw_tail_read(struct drm_i915_private *dev_priv)
  {
 return 

[Intel-gfx] ✓ Fi.CI.BAT: success for Add support for loadable OA configs

[Patchwork]

== Series Details ==

Series: Add support for loadable OA configs
URL   : https://patchwork.freedesktop.org/series/27238/
State : success

== Summary ==

Series 27238v1 Add support for loadable OA configs
https://patchwork.freedesktop.org/api/1.0/series/27238/revisions/1/mbox/

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:426s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:413s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:361s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:475s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:476s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:487s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:487s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:569s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:426s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:400s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:492s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:485s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:450s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:558s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:561s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:441s
fi-skl-6700hqtotal:279  pass:262  dwarn:0   dfail:0   fail:0   skip:17  
time:572s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:624s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:456s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:426s
fi-skl-x1585ltotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:480s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:545s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:404s
fi-pnv-d510 failed to collect. IGT log at Patchwork_5183/fi-pnv-d510/igt.log

8ad9e19aafea47c272163c2cbf554e06ff7f9857 drm-tip: 2017y-07m-11d-19h-08m-20s UTC 
integration manifest
bd0d945 drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface
7410bfd drm/i915/perf: prune OA configs

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5183/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 11/13] drm/i915/bxt: Enable IPC support

[Mahesh Kumar]

Hi,


On Thursday 13 July 2017 04:18 PM, Chris Wilson wrote:

Quoting Mahesh Kumar (2017-07-13 11:39:02)

+void intel_enable_ipc(struct drm_i915_private *dev_priv)
+{
+   u32 val;
+
+   val = I915_READ(DISP_ARB_CTL2);
+
+   if (dev_priv->ipc_enabled)
+   val |= DISP_IPC_ENABLE;
+   else
+   val &= ~DISP_IPC_ENABLE;
+
+   I915_WRITE(DISP_ARB_CTL2, val);
+}
+
+void intel_init_ipc(struct drm_i915_private *dev_priv)
+{
+   dev_priv->ipc_enabled = false;
+   if (INTEL_GEN(dev_priv) < 9 || IS_SKYLAKE(dev_priv))
+   return;

So dev_priv->ipc_enabled is just a dev_priv->info.has_ipc, its state
never changes at runtime?
For debug purpose we may want to disable ipc, So no, it's value 
(dev_priv->ipc_enabled) will not be a fixed value.

I have a plan to make a debugfs entry to change the IPC value at runtime.
But having it also in dev_priv->info.has_ipc a good idea, It will make 
condition check easy.

I'll float another patch incorporating this change.

thanks,
-Mahesh

Using a intel_device_info field then has a few
useful side-effects including automatic printing in the lists of
capabilities.
-Chris


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Daniel Vetter]

On Thu, Jul 13, 2017 at 01:13:51PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 12, 2017 at 07:28:14PM -0700, Stéphane Marchesin wrote:
> > On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä
> >  wrote:
> > >
> > > On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
> > > > El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
> > > >
> > > > > In several instances the driver passes an 'enum pipe' value to a
> > > > > function expecting an 'enum transcoder' and viceversa. Since PIPE_x 
> > > > > and
> > > > > TRANSCODER_x have the same values this doesn't cause functional
> > > > > problems. Still it is incorrect and causes clang to generate warnings
> > > > > like this:
> > > > >
> > > > > drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit
> > > > >   conversion from enumeration type 'enum transcoder' to different
> > > > >   enumeration type 'enum pipe' [-Wenum-conversion]
> > > > > assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
> > > > >
> > > > > Change the code to pass values of the type expected by the callee.
> > > > >
> > > > > Signed-off-by: Matthias Kaehlcke 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
> > > > >  drivers/gpu/drm/i915/intel_dp.c  | 6 --
> > > > >  drivers/gpu/drm/i915/intel_hdmi.c| 6 --
> > > > >  drivers/gpu/drm/i915/intel_sdvo.c| 6 --
> > > > >  4 files changed, 14 insertions(+), 8 deletions(-)
> > > >
> > > > Ping, any comments on this patch?
> > >
> > > I'm not convinced the patch is making things any better really. To
> > > fix this really properly, I think we'd need to introduce a new enum
> > > pch_transcoder and thus avoid the confusion of which type of
> > > transcoder we're talking about. Currently most places expect an
> > > enum pipe when dealing with PCH transcoders, and enum transcoder
> > > when dealing with CPU transcoders. But there are some exceptions
> > > of course.
> > 
> > 
> > I don't follow -- these functions take an enum transcoder; what's
> > wrong about passing what they expect? It seems like what you are
> > asking for has nothing to do with the warning here...
> 
> There's a warning? I don't get any.
> 
> Anyways, I just don't see much point in blindly changing the types
> because it doesn't actually solve the underlying confusion for human
> readers. It might even make it worse, not sure.

Yeah the current patch just makes it worse. Either enum pch_transcoder, or
the enum pipe changes I suggested somewhere else. Blindly fixing type
mismatches without actually fixing the underlying confusion isn't really
useful work. And at least the switch to enum pipe for pch won't be (much)
bigger.
-Daniel
-- 
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 20/20] drm/i915: write AVI infoframes for LSPCON

[Ville Syrjälä]

On Thu, Jul 13, 2017 at 11:11:53AM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 7/12/2017 10:54 PM, Ville Syrjälä wrote:
> > On Mon, Jul 10, 2017 at 04:48:48PM +0530, Shashank Sharma wrote:
> >> LSPCON chips can't pick the HDMI AVI infoframes from direct link.
> >> In order to pass AVI infoframes from display controller to LSPCON,
> >> we have to write infoframe packets into vendor specified AUX address.
> >>
> >> Also, LSPCON vendors provide AUX offsets, to inform the LSPCON
> >> chip that the AVI IF packets are written, so that the firmware
> >> can pick it up and apply.
> >>
> >> This patch adds function to write AVI infoframes for both MCA as
> >> well as Parade Tech LSPCON chips. These two vendors provide different
> >> methods for writing infoframes, so this patch contains two different
> >> functions, one for each.
> > Seems to me that we should also be checking the receiver cap for the
> > 444->420 conversion support, and enable it in the PROTOCOL_CONVERTER
> > DPCD register. Or are these LSPCON things even ignoring that part of the
> > spec?
> Yes, LSPCON just needs the YCBCR444 input, and info frames for 420, and 
> it would take care of
> 444->420 conversion in FW.

So it snoops the AVI infoframe we write to it to figure out that it has
to do the 444->420 downsampling?

> Also, its a part of LSPCON specs, that it has 
> to have 420 output capability.
> 
> - Shashank
> >
> >> Cc: Ville Syrjälä 
> >> Cc: Imre Deak 
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/i915/intel_ddi.c|   8 ++
> >>   drivers/gpu/drm/i915/intel_drv.h|   3 +
> >>   drivers/gpu/drm/i915/intel_lspcon.c | 174 
> >> 
> >>   3 files changed, 185 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> >> b/drivers/gpu/drm/i915/intel_ddi.c
> >> index f691710..944d9d5 100644
> >> --- a/drivers/gpu/drm/i915/intel_ddi.c
> >> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> >> @@ -2068,6 +2068,14 @@ void intel_ddi_set_avi_infoframe(struct drm_encoder 
> >> *encoder,
> >>   rgb_qrange_limited,
> >>   rgb_qrange_selectable);
> >>   
> >> +  if (crtc_state->lspcon_active) {
> >> +  struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
> >> +
> >> +  /* LSPCON writes infoframes via AUX */
> >> +  lspcon->write_infoframe(encoder, crtc_state, &frame);
> >> +  return;
> >> +  }
> >> +
> >>intel_write_infoframe(encoder, crtc_state, &frame);
> >>   }
> >>   
> >> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> >> b/drivers/gpu/drm/i915/intel_drv.h
> >> index fad9a53..3e686d2 100644
> >> --- a/drivers/gpu/drm/i915/intel_drv.h
> >> +++ b/drivers/gpu/drm/i915/intel_drv.h
> >> @@ -1079,6 +1079,9 @@ struct intel_lspcon {
> >>/* AVI IF setup function for LSPCON */
> >>void (*set_infoframes)(struct drm_encoder *encoder,
> >>const struct intel_crtc_state *crtc_state);
> >> +  void (*write_infoframe)(struct drm_encoder *encoder,
> >> +  const struct intel_crtc_state *crtc_state,
> >> +  union hdmi_infoframe *frame);
> >>   };
> >>   
> >>   struct intel_digital_port {
> >> diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
> >> b/drivers/gpu/drm/i915/intel_lspcon.c
> >> index 53ddd39..01fddf7 100644
> >> --- a/drivers/gpu/drm/i915/intel_lspcon.c
> >> +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> >> @@ -31,6 +31,18 @@
> >>   #define LSPCON_VENDOR_PARADE_OUI 0x001CF8
> >>   #define LSPCON_VENDOR_MCA_OUI 0x0060AD
> >>   
> >> +/* AUX addresses to write AVI IF into */
> >> +#define LSPCON_MCA_AVI_IF_WRITE_OFFSET 0x5C0
> >> +#define LSPCON_MCA_AVI_IF_CTRL 0x5DF
> >> +#define  LSPCON_MCA_AVI_IF_KICKOFF (1 << 0)
> >> +#define  LSPCON_MCA_AVI_IF_HANDLED (1 << 1)
> >> +
> >> +#define LSPCON_PARADE_AVI_IF_WRITE_OFFSET 0x516
> >> +#define LSPCON_PARADE_AVI_IF_CTRL 0x51E
> >> +#define  LSPCON_PARADE_AVI_IF_KICKOFF (1 << 7)
> >> +#define LSPCON_PARADE_AVI_IF_STATUS 0x51F
> >> +#define  LSPCON_PARADE_AVI_IF_HANDLED (2 << 6)
> >> +
> >>   static struct intel_dp *lspcon_to_intel_dp(struct intel_lspcon *lspcon)
> >>   {
> >>struct intel_digital_port *dig_port =
> >> @@ -217,6 +229,167 @@ bool lspcon_ycbcr420_config(struct drm_connector 
> >> *connector,
> >>return false;
> >>   }
> >>   
> >> +static bool _lspcon_write_infoframe_parade(struct drm_dp_aux *aux,
> >> + uint8_t *buffer, ssize_t len)
> >> +{
> >> +  u8 avi_if_ctrl;
> >> +  u8 avi_if_status;
> >> +  u8 count = 0;
> >> +  u8 retry = 5;
> >> +  u8 avi_buf[8] = {0, };
> >> +  uint16_t reg;
> >> +  ssize_t ret;
> >> +
> >> +  while (count++ < 4) {
> >> +
> >> +  do {
> >> +  /* Is LSPCON FW ready */
> >> +  reg = LSPCON_PARADE_AVI_IF_CTRL;
> >> +  ret = drm_dp_dpcd_read(aux, reg, &avi_if_ctrl, 1);
> >> +  if (re

Re: [Intel-gfx] [Nouveau] [PATCH xf86-video-amdgpu] Adapt to PixmapDirtyUpdateRec::src being a DrawablePtr

[Ilia Mirkin]

On Thu, Jul 13, 2017 at 4:27 AM, Michel Dänzer  wrote:
> On 18/04/17 07:07 PM, Michel Dänzer wrote:
>> From: Michel Dänzer 
>>
>> Signed-off-by: Michel Dänzer 
>> ---
>>
>> Chris / Ilia / Ben, this should be manageable for the intel/nouveau
>> drivers, right?
>
> Any feedback, guys?
>
> I want to push the xserver change soon-ish. I could probably come up
> with a corresponding patch for nouveau in the worst case, but I'm afraid
> not for intel.

Sorry, I'm not 1000% clear on what this patch is doing. Is it
literally just a type change from A to B and so code has to be fixed
up for the new API? Or are there further implications like having to
do/support new things?

Thanks,

  -ilia
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/20] drm: add helper to validate YCBCR420 modes

[Ville Syrjälä]

On Thu, Jul 13, 2017 at 11:02:18AM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 7/12/2017 10:48 PM, Ville Syrjälä wrote:
> > On Mon, Jul 10, 2017 at 04:48:34PM +0530, Shashank Sharma wrote:
> >> YCBCR420 modes are supported only on HDMI 2.0 capable sources.
> >> This patch adds:
> >> - A drm helper to validate YCBCR420-only mode on a particular
> >>connector. This function will help pruning the YCBCR420-only
> >>modes from the connector's modelist.
> >> - A bool variable (ycbcr_420_allowed) in the drm connector structure.
> >>While handling the EDID from HDMI 2.0 sinks, its important to know
> >>if the source is capable of handling YCBCR420 output, so that no
> >>YCBCR 420 modes will be listed for sources which can't handle it.
> >>A driver should set this variable if it wants to see YCBCR420 modes
> >>in the modedb.
> >>
> >> V5: Introduced the patch in series.
> >> V5-resend: Squashed two patches (validate YCBCR420 and add YCBCR420
> >>   identifier)
> >>
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/drm_edid.c |  3 ++-
> >>   drivers/gpu/drm/drm_modes.c| 28 
> >>   drivers/gpu/drm/drm_probe_helper.c |  4 
> >>   include/drm/drm_connector.h|  9 +
> >>   include/drm/drm_edid.h |  1 +
> >>   include/drm/drm_modes.h|  5 +
> >>   6 files changed, 49 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 10dab62..44be128 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -2950,10 +2950,11 @@ u8 drm_match_cea_mode(const struct 
> >> drm_display_mode *to_match)
> >>   }
> >>   EXPORT_SYMBOL(drm_match_cea_mode);
> >>   
> >> -static bool drm_valid_cea_vic(u8 vic)
> >> +bool drm_valid_cea_vic(u8 vic)
> >>   {
> >>return vic > 0 && vic < ARRAY_SIZE(edid_cea_modes);
> >>   }
> >> +EXPORT_SYMBOL(drm_valid_cea_vic);
> >>   
> >>   /**
> >>* drm_get_cea_aspect_ratio - get the picture aspect ratio corresponding 
> >> to
> >> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> >> index f2493b9..3b53c8e3 100644
> >> --- a/drivers/gpu/drm/drm_modes.c
> >> +++ b/drivers/gpu/drm/drm_modes.c
> >> @@ -1083,6 +1083,34 @@ drm_mode_validate_size(const struct 
> >> drm_display_mode *mode,
> >>   }
> >>   EXPORT_SYMBOL(drm_mode_validate_size);
> >>   
> >> +/**
> >> + * drm_mode_ycbcr420_only - add 'ycbcr420-only' modes only when allowed
> >> + * @mode: mode to check
> >> + * @connector: drm connector under action
> >> + *
> >> + * This function is a helper which can be used to filter out any YCBCR420
> >> + * only mode, when the source doesn't support it.
> >> + *
> >> + * Returns:
> >> + * The mode status
> >> + */
> >> +enum drm_mode_status
> >> +drm_mode_validate_ycbcr420(const struct drm_display_mode *mode,
> >> + struct drm_connector *connector)
> >> +{
> >> +  u8 vic = drm_match_cea_mode(mode);
> >> +  enum drm_mode_status status = MODE_OK;
> >> +  struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
> >> +
> >> +  if (drm_valid_cea_vic(vic) && test_bit(vic, hdmi->y420_vdb_modes)) {
> > Still think the valid check is pointless.
> I still think that we should only pass valid CEA VIC to VDB check, but 
> Ok, I will remove that.
> >   Skipping that would also avoid
> > having to make the function non-static
> Ok
> > (the EXPORT_SYMBOL there seems
> > unnecessary either way).
> Why ?

It's all in the same module AFAICS.

Oh, and the patch ordering here still looks potentially problematic. We
should add the 420 mode validation before we start adding the 420 modes.
Otherwise anyone bisecting through this may get a black/corrupted screen
if they have a monitor with "420 only" modes.

> >
> >> +  if (!connector->ycbcr_420_allowed)
> >> +  status = MODE_NO_420;
> >> +  }
> >> +
> >> +  return status;
> >> +}
> >> +EXPORT_SYMBOL(drm_mode_validate_ycbcr420);
> >> +
> >>   #define MODE_STATUS(status) [MODE_ ## status + 3] = #status
> >>   
> >>   static const char * const drm_mode_status_names[] = {
> > ^
> > This thing needs to be updated as well.
> Oh sorry, good catch.
> - Shashank
> >> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> >> b/drivers/gpu/drm/drm_probe_helper.c
> >> index 00e6832..904966c 100644
> >> --- a/drivers/gpu/drm/drm_probe_helper.c
> >> +++ b/drivers/gpu/drm/drm_probe_helper.c
> >> @@ -528,6 +528,10 @@ int drm_helper_probe_single_connector_modes(struct 
> >> drm_connector *connector,
> >>if (mode->status == MODE_OK)
> >>mode->status = drm_mode_validate_pipeline(mode,
> >>  connector);
> >> +
> >> +  if (mode->status == MODE_OK)
> >> +  mode->status = drm_mode_validate_ycbcr420(mode,
> >> +co

Re: [Intel-gfx] [PATCH 15/16] drm/nouveau: Convert nouveau to use new iterator macros

[Daniel Vetter]

On Wed, Jul 12, 2017 at 10:13:43AM +0200, Maarten Lankhorst wrote:
> Use the new atomic iterator macros, the old ones are about to be
> removed. With the new macros, it's more easy to get old and new state so
> get them from the macros instead of from obj->state.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Ben Skeggs 
> Cc: nouv...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/nouveau/nv50_display.c | 71 
> +-
>  1 file changed, 36 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
> b/drivers/gpu/drm/nouveau/nv50_display.c
> index 42a85c14aea0..b1ce8f1f58dc 100644
> --- a/drivers/gpu/drm/nouveau/nv50_display.c
> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
> @@ -2103,7 +2103,7 @@ nv50_head_atomic_check(struct drm_crtc *crtc, struct 
> drm_crtc_state *state)
>  
>   NV_ATOMIC(drm, "%s atomic_check %d\n", crtc->name, asyh->state.active);
>   if (asyh->state.active) {
> - for_each_connector_in_state(asyh->state.state, conn, conns, i) {
> + for_each_new_connector_in_state(asyh->state.state, conn, conns, 
> i) {
>   if (conns->crtc == crtc) {
>   asyc = nouveau_conn_atom(conns);
>   break;
> @@ -3904,9 +3904,9 @@ static void
>  nv50_disp_atomic_commit_tail(struct drm_atomic_state *state)
>  {
>   struct drm_device *dev = state->dev;
> - struct drm_crtc_state *crtc_state;
> + struct drm_crtc_state *new_crtc_state;
>   struct drm_crtc *crtc;
> - struct drm_plane_state *plane_state;
> + struct drm_plane_state *new_plane_state;
>   struct drm_plane *plane;
>   struct nouveau_drm *drm = nouveau_drm(dev);
>   struct nv50_disp *disp = nv50_disp(dev);
> @@ -3925,8 +3925,8 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
> *state)
>   mutex_lock(&disp->mutex);
>  
>   /* Disable head(s). */
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - struct nv50_head_atom *asyh = nv50_head_atom(crtc->state);
> + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> + struct nv50_head_atom *asyh = nv50_head_atom(new_crtc_state);
>   struct nv50_head *head = nv50_head(crtc);
>  
>   NV_ATOMIC(drm, "%s: clr %04x (set %04x)\n", crtc->name,
> @@ -3939,8 +3939,8 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
> *state)
>   }
>  
>   /* Disable plane(s). */
> - for_each_plane_in_state(state, plane, plane_state, i) {
> - struct nv50_wndw_atom *asyw = nv50_wndw_atom(plane->state);
> + for_each_new_plane_in_state(state, plane, new_plane_state, i) {
> + struct nv50_wndw_atom *asyw = nv50_wndw_atom(new_plane_state);
>   struct nv50_wndw *wndw = nv50_wndw(plane);
>  
>   NV_ATOMIC(drm, "%s: clr %02x (set %02x)\n", plane->name,
> @@ -4005,8 +4005,8 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
> *state)
>   }
>  
>   /* Update head(s). */
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - struct nv50_head_atom *asyh = nv50_head_atom(crtc->state);
> + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> + struct nv50_head_atom *asyh = nv50_head_atom(new_crtc_state);
>   struct nv50_head *head = nv50_head(crtc);
>  
>   NV_ATOMIC(drm, "%s: set %04x (clr %04x)\n", crtc->name,
> @@ -4018,14 +4018,14 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
> *state)
>   }
>   }
>  
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - if (crtc->state->event)
> + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->event)
>   drm_crtc_vblank_get(crtc);
>   }
>  
>   /* Update plane(s). */
> - for_each_plane_in_state(state, plane, plane_state, i) {
> - struct nv50_wndw_atom *asyw = nv50_wndw_atom(plane->state);
> + for_each_new_plane_in_state(state, plane, new_plane_state, i) {
> + struct nv50_wndw_atom *asyw = nv50_wndw_atom(new_plane_state);
>   struct nv50_wndw *wndw = nv50_wndw(plane);
>  
>   NV_ATOMIC(drm, "%s: set %02x (clr %02x)\n", plane->name,
> @@ -4055,23 +4055,23 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
> *state)
>   mutex_unlock(&disp->mutex);
>  
>   /* Wait for HW to signal completion. */
> - for_each_plane_in_state(state, plane, plane_state, i) {
> - struct nv50_wndw_atom *asyw = nv50_wndw_atom(plane->state);
> + for_each_new_plane_in_state(state, plane, new_plane_state, i) {
> + struct nv50_wndw_atom *asyw = nv50_wndw_atom(new_plane_state);
>   struct nv50_wndw *wndw = nv50_wndw(plane);
>   int ret = nv50_wndw_wait_armed(wndw, asyw);
>   if (ret)
>   NV_ERROR(drm, "%s: tim

Re: [Intel-gfx] [PATCH 08/20] drm: set output colorspace in AVI infoframe

[Ville Syrjälä]

On Thu, Jul 13, 2017 at 10:37:53AM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 7/12/2017 10:47 PM, Ville Syrjälä wrote:
> > On Mon, Jul 10, 2017 at 04:48:36PM +0530, Shashank Sharma wrote:
> >> A source must set output colorspace information in AVI
> >> infoframes, so that the sink can decode upcoming frames
> >> accordingly.
> >>
> >> This patch adds a function to add the output colorspace
> >> information in the AVI infoframes.
> >>
> >> V2: Rebase
> >> V3: Rebase
> >> V4: Rebase
> >> V5: Rebase
> >> V6: Made patch independent of HDMI output type.
> >>
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/drm_edid.c | 29 +
> >>   include/drm/drm_edid.h |  5 +
> >>   2 files changed, 34 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 944a28f..cede86e 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -4796,6 +4796,35 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
> >> hdmi_avi_infoframe *frame,
> >>   EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
> >>   
> >>   /**
> >> + * drm_hdmi_avi_infoframe_set_colorspace - fill an HDMI AVI infoframe with
> >> + * colorspace data of the output type
> >> + *
> >> + * @frame: HDMI AVI infoframe
> >> + * @mode: DRM display mode
> >> + * @hdmi_output: HDMI output colorspace
> >> + *
> >> + * Return: 0 on success or a negative error code on failure.
> >> + */
> >> +int
> >> +drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
> >> +const struct drm_display_mode *mode,
> >> +enum hdmi_colorspace colorspace)
> >> +{
> >> +  if (colorspace > HDMI_COLORSPACE_YUV420 ||
> >> +  colorspace < HDMI_COLORSPACE_RGB) {
> >> +  DRM_ERROR("Invalid color space type\n");
> >> +  return -EINVAL;
> >> +  }
> > Seems overly defensive. I'd say that if someone insists on writing
> > buggy code just let them do it.
> :) yep can be done, you know, its a new implementation, don't want to 
> create unnecessary noise so being
> a bit defensive :)
> >> +
> >> +  frame->colorspace = colorspace;
> >> +  if (colorspace == HDMI_COLORSPACE_YUV420)
> >> +  frame->pixel_repeat = 0;
> > Most VICs don't allow pixel repeat in 444/etc. either, and we don't
> > protect against that. So this looks like pretty pointless check in
> > this form.
> >
> > So IMO just drop this entire patch and just assign frame->colorspace in
> > the driver.
> Actually YCBCR420 section of spec specifically calls out for not 
> allowing repetition, also, when I tested this on a
> HDMI 2.0 analyzer, if was giving a AVI IF failure on pixel_repeat not 0, 
> so IMHO it would be a good idea to keep
> this and get the tests passing.

That's just papering over bugs elsewhere. If we can't use pixel repeat
with a specific mode, then we should have rejected that mode much earlier.

> 
> - Shashank
> >> +
> >> +  return 0;
> >> +}
> >> +EXPORT_SYMBOL(drm_hdmi_avi_infoframe_set_colorspace);
> >> +
> >> +/**
> >>* drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
> >>*quantization range information
> >>* @frame: HDMI AVI infoframe
> >> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> >> index aa58146..b79e0cb 100644
> >> --- a/include/drm/drm_edid.h
> >> +++ b/include/drm/drm_edid.h
> >> @@ -332,6 +332,7 @@ struct cea_sad {
> >>   struct drm_encoder;
> >>   struct drm_connector;
> >>   struct drm_display_mode;
> >> +enum drm_hdmi_output_type;
> >>   
> >>   void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
> >>   int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
> >> @@ -354,6 +355,10 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
> >> hdmi_avi_infoframe *frame,
> >> const struct drm_display_mode *mode,
> >> bool is_hdmi2_sink);
> >>   int
> >> +drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
> >> +   const struct drm_display_mode *mode,
> >> +   enum hdmi_colorspace colorspace);
> >> +int
> >>   drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe 
> >> *frame,
> >>const struct drm_display_mode 
> >> *mode);
> >>   void
> >> -- 
> >> 2.7.4
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-de...@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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 16/20] drm: add function to read vendor OUI

[Ville Syrjälä]

On Thu, Jul 13, 2017 at 10:34:26AM +0530, Sharma, Shashank wrote:
> Regads
> 
> Shashank
> 
> 
> On 7/12/2017 10:45 PM, Ville Syrjälä wrote:
> > On Mon, Jul 10, 2017 at 04:48:44PM +0530, Shashank Sharma wrote:
> >> This patch adds a helper function in DP dual mode layer to
> >> read the vendor's IEEE OUI signature from a Dual mode adapter.
> >> This will be used to differentiate between different LSPCON
> >> vendors, to address their custom programming requirements.
> > Can't we just read it from DPCD instead?
> You are right, as we have DPCD cached, we can do it from DPCD too, and 
> in fact that was my first implementation.
> But then I thought what if some driver doesn't cache DPCD, so thought it 
> would be good to have a helper function
> to check this out.
> If you think DPCD would be a better idea, I need not to touch DRM layer 
> at all, and this will be only I915 implementation.

Yeah, less code seems like a good thing. I think we might even have that
OUI stuff already read out and cached for other purposes.

> 
> - Shashank
> >
> >> Cc: Ville Syrjälä 
> >> Cc: Imre Deak 
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/drm_dp_dual_mode_helper.c | 24 
> >>   include/drm/drm_dp_dual_mode_helper.h |  4 +++-
> >>   2 files changed, 27 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
> >> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> >> index 80e62f6..0b890dc 100644
> >> --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> >> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> >> @@ -396,6 +396,30 @@ const char *drm_dp_get_dual_mode_type_name(enum 
> >> drm_dp_dual_mode_type type)
> >>   EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
> >>   
> >>   /**
> >> + * drm_lspcon_get_vendor_oui: match vendor OUI signature
> >> + * @adapter: i2c adapter under action
> >> + * @vendor_id = 3 bytes of vendor OUI signature, LSB=lower byte
> >> + *
> >> + * Returns:
> >> + * Vendor OUI id if got one, 0 if not
> >> + */
> >> +uint32_t drm_lspcon_get_vendor_oui(struct i2c_adapter *adapter)
> >> +{
> >> +  uint8_t sign[3] = {0, };
> >> +  uint32_t oui = 0;
> >> +
> >> +  if (drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_LSPCON_OUI_OFFSET,
> >> +  sign, 3)) {
> >> +  DRM_ERROR("Can't identify vendor sign\n");
> >> +  return 0;
> >> +  }
> >> +
> >> +  oui = (sign[0] << 16) | (sign[1] << 8) | sign[2];
> >> +  return oui;
> >> +}
> >> +EXPORT_SYMBOL(drm_lspcon_get_vendor_oui);
> >> +
> >> +/**
> >>* drm_lspcon_get_mode: Get LSPCON's current mode of operation by
> >>* reading offset (0x80, 0x41)
> >>* @adapter: I2C-over-aux adapter
> >> diff --git a/include/drm/drm_dp_dual_mode_helper.h 
> >> b/include/drm/drm_dp_dual_mode_helper.h
> >> index 4c42db8..f81b526 100644
> >> --- a/include/drm/drm_dp_dual_mode_helper.h
> >> +++ b/include/drm/drm_dp_dual_mode_helper.h
> >> @@ -60,7 +60,8 @@
> >>   /* LSPCON specific registers, defined by MCA */
> >>   #define DP_DUAL_MODE_LSPCON_MODE_CHANGE  0x40
> >>   #define DP_DUAL_MODE_LSPCON_CURRENT_MODE 0x41
> >> -#define  DP_DUAL_MODE_LSPCON_MODE_PCON0x1
> >> +#define DP_DUAL_MODE_LSPCON_MODE_PCON 0x1
> >> +#define DP_DUAL_MODE_LSPCON_OUI_OFFSET0x11
> >>   
> >>   struct i2c_adapter;
> >>   
> >> @@ -116,4 +117,5 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
> >>enum drm_lspcon_mode *current_mode);
> >>   int drm_lspcon_set_mode(struct i2c_adapter *adapter,
> >>enum drm_lspcon_mode reqd_mode);
> >> +uint32_t drm_lspcon_get_vendor_oui(struct i2c_adapter *adapter);
> >>   #endif
> >> -- 
> >> 2.7.4

-- 
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 20/20] drm/i915: write AVI infoframes for LSPCON

[Sharma, Shashank]

Regards

Shashank


On 7/13/2017 5:57 PM, Ville Syrjälä wrote:

On Thu, Jul 13, 2017 at 11:11:53AM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 7/12/2017 10:54 PM, Ville Syrjälä wrote:

On Mon, Jul 10, 2017 at 04:48:48PM +0530, Shashank Sharma wrote:

LSPCON chips can't pick the HDMI AVI infoframes from direct link.
In order to pass AVI infoframes from display controller to LSPCON,
we have to write infoframe packets into vendor specified AUX address.

Also, LSPCON vendors provide AUX offsets, to inform the LSPCON
chip that the AVI IF packets are written, so that the firmware
can pick it up and apply.

This patch adds function to write AVI infoframes for both MCA as
well as Parade Tech LSPCON chips. These two vendors provide different
methods for writing infoframes, so this patch contains two different
functions, one for each.

Seems to me that we should also be checking the receiver cap for the
444->420 conversion support, and enable it in the PROTOCOL_CONVERTER
DPCD register. Or are these LSPCON things even ignoring that part of the
spec?

Yes, LSPCON just needs the YCBCR444 input, and info frames for 420, and
it would take care of
444->420 conversion in FW.

So it snoops the AVI infoframe we write to it to figure out that it has
to do the 444->420 downsampling?

Yes, that's exactly what it does.
- Shashank

Also, its a part of LSPCON specs, that it has
to have 420 output capability.

- Shashank

Cc: Ville Syrjälä 
Cc: Imre Deak 
Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/i915/intel_ddi.c|   8 ++
   drivers/gpu/drm/i915/intel_drv.h|   3 +
   drivers/gpu/drm/i915/intel_lspcon.c | 174 

   3 files changed, 185 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index f691710..944d9d5 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2068,6 +2068,14 @@ void intel_ddi_set_avi_infoframe(struct drm_encoder 
*encoder,
   rgb_qrange_limited,
   rgb_qrange_selectable);
   
+	if (crtc_state->lspcon_active) {

+   struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
+
+   /* LSPCON writes infoframes via AUX */
+   lspcon->write_infoframe(encoder, crtc_state, &frame);
+   return;
+   }
+
intel_write_infoframe(encoder, crtc_state, &frame);
   }
   
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h

index fad9a53..3e686d2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1079,6 +1079,9 @@ struct intel_lspcon {
/* AVI IF setup function for LSPCON */
void (*set_infoframes)(struct drm_encoder *encoder,
const struct intel_crtc_state *crtc_state);
+   void (*write_infoframe)(struct drm_encoder *encoder,
+   const struct intel_crtc_state *crtc_state,
+   union hdmi_infoframe *frame);
   };
   
   struct intel_digital_port {

diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index 53ddd39..01fddf7 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -31,6 +31,18 @@
   #define LSPCON_VENDOR_PARADE_OUI 0x001CF8
   #define LSPCON_VENDOR_MCA_OUI 0x0060AD
   
+/* AUX addresses to write AVI IF into */

+#define LSPCON_MCA_AVI_IF_WRITE_OFFSET 0x5C0
+#define LSPCON_MCA_AVI_IF_CTRL 0x5DF
+#define  LSPCON_MCA_AVI_IF_KICKOFF (1 << 0)
+#define  LSPCON_MCA_AVI_IF_HANDLED (1 << 1)
+
+#define LSPCON_PARADE_AVI_IF_WRITE_OFFSET 0x516
+#define LSPCON_PARADE_AVI_IF_CTRL 0x51E
+#define  LSPCON_PARADE_AVI_IF_KICKOFF (1 << 7)
+#define LSPCON_PARADE_AVI_IF_STATUS 0x51F
+#define  LSPCON_PARADE_AVI_IF_HANDLED (2 << 6)
+
   static struct intel_dp *lspcon_to_intel_dp(struct intel_lspcon *lspcon)
   {
struct intel_digital_port *dig_port =
@@ -217,6 +229,167 @@ bool lspcon_ycbcr420_config(struct drm_connector 
*connector,
return false;
   }
   
+static bool _lspcon_write_infoframe_parade(struct drm_dp_aux *aux,

+  uint8_t *buffer, ssize_t len)
+{
+   u8 avi_if_ctrl;
+   u8 avi_if_status;
+   u8 count = 0;
+   u8 retry = 5;
+   u8 avi_buf[8] = {0, };
+   uint16_t reg;
+   ssize_t ret;
+
+   while (count++ < 4) {
+
+   do {
+   /* Is LSPCON FW ready */
+   reg = LSPCON_PARADE_AVI_IF_CTRL;
+   ret = drm_dp_dpcd_read(aux, reg, &avi_if_ctrl, 1);
+   if (ret < 0) {
+   DRM_ERROR("DPCD read failed, add:0x%x\n", reg);
+   return false;
+   }
+
+   if (avi_if_ctrl & LSPCON_PARADE_AVI_IF_KICKOFF)
+   break;
+ 

Re: [Intel-gfx] [PATCH 06/20] drm: add helper to validate YCBCR420 modes

[Sharma, Shashank]

Regards

Shashank


On 7/13/2017 6:01 PM, Ville Syrjälä wrote:

On Thu, Jul 13, 2017 at 11:02:18AM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 7/12/2017 10:48 PM, Ville Syrjälä wrote:

On Mon, Jul 10, 2017 at 04:48:34PM +0530, Shashank Sharma wrote:

YCBCR420 modes are supported only on HDMI 2.0 capable sources.
This patch adds:
- A drm helper to validate YCBCR420-only mode on a particular
connector. This function will help pruning the YCBCR420-only
modes from the connector's modelist.
- A bool variable (ycbcr_420_allowed) in the drm connector structure.
While handling the EDID from HDMI 2.0 sinks, its important to know
if the source is capable of handling YCBCR420 output, so that no
YCBCR 420 modes will be listed for sources which can't handle it.
A driver should set this variable if it wants to see YCBCR420 modes
in the modedb.

V5: Introduced the patch in series.
V5-resend: Squashed two patches (validate YCBCR420 and add YCBCR420
   identifier)

Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/drm_edid.c |  3 ++-
   drivers/gpu/drm/drm_modes.c| 28 
   drivers/gpu/drm/drm_probe_helper.c |  4 
   include/drm/drm_connector.h|  9 +
   include/drm/drm_edid.h |  1 +
   include/drm/drm_modes.h|  5 +
   6 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 10dab62..44be128 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2950,10 +2950,11 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
   }
   EXPORT_SYMBOL(drm_match_cea_mode);
   
-static bool drm_valid_cea_vic(u8 vic)

+bool drm_valid_cea_vic(u8 vic)
   {
return vic > 0 && vic < ARRAY_SIZE(edid_cea_modes);
   }
+EXPORT_SYMBOL(drm_valid_cea_vic);
   
   /**

* drm_get_cea_aspect_ratio - get the picture aspect ratio corresponding to
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f2493b9..3b53c8e3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1083,6 +1083,34 @@ drm_mode_validate_size(const struct drm_display_mode 
*mode,
   }
   EXPORT_SYMBOL(drm_mode_validate_size);
   
+/**

+ * drm_mode_ycbcr420_only - add 'ycbcr420-only' modes only when allowed
+ * @mode: mode to check
+ * @connector: drm connector under action
+ *
+ * This function is a helper which can be used to filter out any YCBCR420
+ * only mode, when the source doesn't support it.
+ *
+ * Returns:
+ * The mode status
+ */
+enum drm_mode_status
+drm_mode_validate_ycbcr420(const struct drm_display_mode *mode,
+  struct drm_connector *connector)
+{
+   u8 vic = drm_match_cea_mode(mode);
+   enum drm_mode_status status = MODE_OK;
+   struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+
+   if (drm_valid_cea_vic(vic) && test_bit(vic, hdmi->y420_vdb_modes)) {

Still think the valid check is pointless.

I still think that we should only pass valid CEA VIC to VDB check, but
Ok, I will remove that.

   Skipping that would also avoid
having to make the function non-static

Ok

(the EXPORT_SYMBOL there seems
unnecessary either way).

Why ?

It's all in the same module AFAICS.

Oh, and the patch ordering here still looks potentially problematic. We
should add the 420 mode validation before we start adding the 420 modes.
Otherwise anyone bisecting through this may get a black/corrupted screen
if they have a monitor with "420 only" modes.
Actually, the 420 mode validation patch uses 420_only bitmap, which is 
added in add_420_modes patch.
So I can't put this patch before other one (you reviewed that sequence 
once, and found that).

- Shashank

+   if (!connector->ycbcr_420_allowed)
+   status = MODE_NO_420;
+   }
+
+   return status;
+}
+EXPORT_SYMBOL(drm_mode_validate_ycbcr420);
+
   #define MODE_STATUS(status) [MODE_ ## status + 3] = #status
   
   static const char * const drm_mode_status_names[] = {

^
This thing needs to be updated as well.

Oh sorry, good catch.
- Shashank

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 00e6832..904966c 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -528,6 +528,10 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
if (mode->status == MODE_OK)
mode->status = drm_mode_validate_pipeline(mode,
  connector);
+
+   if (mode->status == MODE_OK)
+   mode->status = drm_mode_validate_ycbcr420(mode,
+ connector);
}
   
   prune:

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index b3af8e3..225e092 100644
--- a/include/d

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

[Lionel Landwerlin]

On 07/07/17 18:31, Chris Wilson wrote:

Quoting Lionel Landwerlin (2017-07-07 18:08:37)

+static bool gen8_is_valid_flex_addr(struct drm_i915_private *dev_priv, u32 
addr)
+{
+   static const i915_reg_t flex_eu_regs[] = {
+   EU_PERF_CNTL0,
+   EU_PERF_CNTL1,
+   EU_PERF_CNTL2,
+   EU_PERF_CNTL3,
+   EU_PERF_CNTL4,
+   EU_PERF_CNTL5,
+   EU_PERF_CNTL6,
+   };
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(flex_eu_regs); i++) {
+   if (flex_eu_regs[i].reg == addr)
+   return true;
+   }
+   return false;
+}
+
+static bool gen7_is_valid_b_counter_addr(struct drm_i915_private *dev_priv, 
u32 addr)
+{
+   return (addr >= 0x2380 && addr <= 0x27ac);
+}
+
+static bool gen7_is_valid_mux_addr(struct drm_i915_private *dev_priv, u32 addr)
+{
+   return addr == NOA_WRITE.reg ||
+   (addr >= 0xd0c && addr <= 0xd3c) ||
+   (addr >= 0x25100 && addr <= 0x2FB9C);
+}
+
+static bool hsw_is_valid_mux_addr(struct drm_i915_private *dev_priv, u32 addr)
+{
+   return (addr >= 0x25100 && addr <= 0x2FF90) ||
+   gen7_is_valid_mux_addr(dev_priv, addr);
+}
+
+static bool chv_is_valid_mux_addr(struct drm_i915_private *dev_priv, u32 addr)
+{
+   return (addr >= 0x182300 && addr <= 0x1823A4) ||
+   gen7_is_valid_mux_addr(dev_priv, addr);
+}

Looks like you've already thought of what I was about to say: we need
whitelisting of what userspace can read/tweak. It's a nuisance, but we
could let the privileged (oa_paranoid?) client load an arbitrary config
(though again that may have to be within reason).
-Chris



Sorry, forgot to press send.
It doesn't look like there is much point in doing this, mostly because 
on gen8+ we already require oa_paranoid to use perf :(


-
Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/20] drm: set output colorspace in AVI infoframe

[Sharma, Shashank]

Regards

Shashank


On 7/13/2017 6:05 PM, Ville Syrjälä wrote:

On Thu, Jul 13, 2017 at 10:37:53AM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 7/12/2017 10:47 PM, Ville Syrjälä wrote:

On Mon, Jul 10, 2017 at 04:48:36PM +0530, Shashank Sharma wrote:

A source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.

This patch adds a function to add the output colorspace
information in the AVI infoframes.

V2: Rebase
V3: Rebase
V4: Rebase
V5: Rebase
V6: Made patch independent of HDMI output type.

Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/drm_edid.c | 29 +
   include/drm/drm_edid.h |  5 +
   2 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 944a28f..cede86e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4796,6 +4796,35 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
   EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
   
   /**

+ * drm_hdmi_avi_infoframe_set_colorspace - fill an HDMI AVI infoframe with
+ * colorspace data of the output type
+ *
+ * @frame: HDMI AVI infoframe
+ * @mode: DRM display mode
+ * @hdmi_output: HDMI output colorspace
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int
+drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
+ const struct drm_display_mode *mode,
+ enum hdmi_colorspace colorspace)
+{
+   if (colorspace > HDMI_COLORSPACE_YUV420 ||
+   colorspace < HDMI_COLORSPACE_RGB) {
+   DRM_ERROR("Invalid color space type\n");
+   return -EINVAL;
+   }

Seems overly defensive. I'd say that if someone insists on writing
buggy code just let them do it.

:) yep can be done, you know, its a new implementation, don't want to
create unnecessary noise so being
a bit defensive :)

+
+   frame->colorspace = colorspace;
+   if (colorspace == HDMI_COLORSPACE_YUV420)
+   frame->pixel_repeat = 0;

Most VICs don't allow pixel repeat in 444/etc. either, and we don't
protect against that. So this looks like pretty pointless check in
this form.

So IMO just drop this entire patch and just assign frame->colorspace in
the driver.

Actually YCBCR420 section of spec specifically calls out for not
allowing repetition, also, when I tested this on a
HDMI 2.0 analyzer, if was giving a AVI IF failure on pixel_repeat not 0,
so IMHO it would be a good idea to keep
this and get the tests passing.

That's just papering over bugs elsewhere. If we can't use pixel repeat
with a specific mode, then we should have rejected that mode much earlier.
I dint get this point, HDMI 2.0 spec section 7.1 says "when YCBCR420 
encoding is active, pixel repetition is not allowed" and
pixel repetition field should be set to = 0, in AVI IF.  This seems to 
be like - if you are displaying YCBCR420, set PR=0 regardless of

mode, isn't it ?

- Shashank

- Shashank

+
+   return 0;
+}
+EXPORT_SYMBOL(drm_hdmi_avi_infoframe_set_colorspace);
+
+/**
* drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
*quantization range information
* @frame: HDMI AVI infoframe
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index aa58146..b79e0cb 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -332,6 +332,7 @@ struct cea_sad {
   struct drm_encoder;
   struct drm_connector;
   struct drm_display_mode;
+enum drm_hdmi_output_type;
   
   void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);

   int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
@@ -354,6 +355,10 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode,
 bool is_hdmi2_sink);
   int
+drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
+const struct drm_display_mode *mode,
+enum hdmi_colorspace colorspace);
+int
   drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe 
*frame,
const struct drm_display_mode 
*mode);
   void
--
2.7.4

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 16/20] drm: add function to read vendor OUI

[Sharma, Shashank]

Regards

Shashank


On 7/13/2017 6:07 PM, Ville Syrjälä wrote:

On Thu, Jul 13, 2017 at 10:34:26AM +0530, Sharma, Shashank wrote:

Regads

Shashank


On 7/12/2017 10:45 PM, Ville Syrjälä wrote:

On Mon, Jul 10, 2017 at 04:48:44PM +0530, Shashank Sharma wrote:

This patch adds a helper function in DP dual mode layer to
read the vendor's IEEE OUI signature from a Dual mode adapter.
This will be used to differentiate between different LSPCON
vendors, to address their custom programming requirements.

Can't we just read it from DPCD instead?

You are right, as we have DPCD cached, we can do it from DPCD too, and
in fact that was my first implementation.
But then I thought what if some driver doesn't cache DPCD, so thought it
would be good to have a helper function
to check this out.
If you think DPCD would be a better idea, I need not to touch DRM layer
at all, and this will be only I915 implementation.

Yeah, less code seems like a good thing. I think we might even have that
OUI stuff already read out and cached for other purposes.

Sure, then, I will extract OUI and cache it in a variable.
- Shashank

- Shashank

Cc: Ville Syrjälä 
Cc: Imre Deak 
Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/drm_dp_dual_mode_helper.c | 24 
   include/drm/drm_dp_dual_mode_helper.h |  4 +++-
   2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 80e62f6..0b890dc 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -396,6 +396,30 @@ const char *drm_dp_get_dual_mode_type_name(enum 
drm_dp_dual_mode_type type)
   EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
   
   /**

+ * drm_lspcon_get_vendor_oui: match vendor OUI signature
+ * @adapter: i2c adapter under action
+ * @vendor_id = 3 bytes of vendor OUI signature, LSB=lower byte
+ *
+ * Returns:
+ * Vendor OUI id if got one, 0 if not
+ */
+uint32_t drm_lspcon_get_vendor_oui(struct i2c_adapter *adapter)
+{
+   uint8_t sign[3] = {0, };
+   uint32_t oui = 0;
+
+   if (drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_LSPCON_OUI_OFFSET,
+   sign, 3)) {
+   DRM_ERROR("Can't identify vendor sign\n");
+   return 0;
+   }
+
+   oui = (sign[0] << 16) | (sign[1] << 8) | sign[2];
+   return oui;
+}
+EXPORT_SYMBOL(drm_lspcon_get_vendor_oui);
+
+/**
* drm_lspcon_get_mode: Get LSPCON's current mode of operation by
* reading offset (0x80, 0x41)
* @adapter: I2C-over-aux adapter
diff --git a/include/drm/drm_dp_dual_mode_helper.h 
b/include/drm/drm_dp_dual_mode_helper.h
index 4c42db8..f81b526 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -60,7 +60,8 @@
   /* LSPCON specific registers, defined by MCA */
   #define DP_DUAL_MODE_LSPCON_MODE_CHANGE  0x40
   #define DP_DUAL_MODE_LSPCON_CURRENT_MODE 0x41
-#define  DP_DUAL_MODE_LSPCON_MODE_PCON 0x1
+#define DP_DUAL_MODE_LSPCON_MODE_PCON  0x1
+#define DP_DUAL_MODE_LSPCON_OUI_OFFSET 0x11
   
   struct i2c_adapter;
   
@@ -116,4 +117,5 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,

enum drm_lspcon_mode *current_mode);
   int drm_lspcon_set_mode(struct i2c_adapter *adapter,
enum drm_lspcon_mode reqd_mode);
+uint32_t drm_lspcon_get_vendor_oui(struct i2c_adapter *adapter);
   #endif
--
2.7.4


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 13/20] drm/i915: prepare csc unit for YCBCR420 output

[Ville Syrjälä]

On Thu, Jul 13, 2017 at 10:44:51AM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 7/12/2017 10:47 PM, Ville Syrjälä wrote:
> > On Mon, Jul 10, 2017 at 04:48:41PM +0530, Shashank Sharma wrote:
> >> To support ycbcr output, we need a pipe CSC block to do
> >> RGB->YCBCR conversion.
> >>
> >> Current Intel platforms have only one pipe CSC unit, so
> >> we can either do color correction using it, or we can perform
> >> RGB->YCBCR conversion.
> >>
> >> This function adds a csc handler, which uses recommended bspec
> >> values to perform RGB->YCBCR conversion (target color space BT709)
> >>
> >> V2: Rebase
> >> V3: Rebase
> >> V4: Rebase
> >> V5: Addressed review comments from Ander
> >>  - Remove extra line added in the patch
> >>  - Add the spec details in the commit message
> >>  - Combine two if(cond) while calling intel_crtc_compute_config
> >> V6: Handle YCBCR420 outputs only (Ville)
> >>
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/i915/intel_color.c   | 47 
> >> +++-
> >>   drivers/gpu/drm/i915/intel_display.c | 17 +
> >>   2 files changed, 63 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_color.c 
> >> b/drivers/gpu/drm/i915/intel_color.c
> >> index 306c6b0..8a5d211 100644
> >> --- a/drivers/gpu/drm/i915/intel_color.c
> >> +++ b/drivers/gpu/drm/i915/intel_color.c
> >> @@ -41,6 +41,19 @@
> >>   
> >>   #define LEGACY_LUT_LENGTH(sizeof(struct drm_color_lut) * 
> >> 256)
> >>   
> >> +/* Post offset values for RGB->YCBCR conversion */
> >> +#define POSTOFF_RGB_TO_YUV_HI 0x800
> >> +#define POSTOFF_RGB_TO_YUV_ME 0x100
> >> +#define POSTOFF_RGB_TO_YUV_LO 0x800
> >> +
> >> +/* Direct spec values for RGB->YUV conversion matrix */
> > Are these BT.601 or BT.709 or something else?
> I thought I added some comment mentioning this being BT 709, but looks 
> like dealing with too many paptches :)
> Will add those details.
> >> +#define CSC_RGB_TO_YUV_RU_GU 0x2ba809d8
> >> +#define CSC_RGB_TO_YUV_BU 0x37e8
> >> +#define CSC_RGB_TO_YUV_RY_GY 0x1e089cc0
> >> +#define CSC_RGB_TO_YUV_BY 0xb528
> >> +#define CSC_RGB_TO_YUV_RV_GV 0xbce89ad8
> >> +#define CSC_RGB_TO_YUV_BV 0x1e08
> > IIRC Ander didn't like these, and neither do I. I'd much prefer to reuse
> > the code we alreayd have for dealing with the CSC. Except I think that's
> > pretty broken in places so I guess we can go with this for now and try
> > to clean up the color management stuff later.
> Yes, that was the plan. I was planning to fix the complete CSC cleanup 
> stuff in a separate patch, but as that needs much
> of validation before we can merge it, I added in a bottom half. I will 
> send a patch for the same soon.
> >> +
> >>   /*
> >>* Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed 
> >> point
> >>* format). This macro takes the coefficient we want transformed and the
> >> @@ -91,6 +104,35 @@ static void ctm_mult_by_limited(uint64_t *result, 
> >> int64_t *input)
> >>}
> >>   }
> >>   
> >> +void i9xx_load_ycbcr_conversion_matrix(struct intel_crtc *intel_crtc)
> >> +{
> >> +  int pipe = intel_crtc->pipe;
> >> +  struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
> >> +
> >> +  /* We don't use high values for conversion */
> > I don't understand what this comment is trying so say.
> Yeah, it should have been "we dont use pre-offsets for conversion"

I think that's very obvious from the code. So no need for comment IMO.

> >
> >> +  I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
> >> +  I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
> >> +  I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
> >> +
> >> +  /* Program direct spec values for RGB to YCBCR conversion matrix */

In fact pretty much all the comments in this patch seem redundant.
Comments should explain why we do something, if necessary. They
should not just transcribe the actual code into words.

> >> +  I915_WRITE(PIPE_CSC_COEFF_RU_GU(pipe), CSC_RGB_TO_YUV_RU_GU);
> >> +  I915_WRITE(PIPE_CSC_COEFF_BU(pipe), CSC_RGB_TO_YUV_BU);
> >> +
> >> +  I915_WRITE(PIPE_CSC_COEFF_RY_GY(pipe), CSC_RGB_TO_YUV_RY_GY);
> >> +  I915_WRITE(PIPE_CSC_COEFF_BY(pipe), CSC_RGB_TO_YUV_BY);
> >> +
> >> +  I915_WRITE(PIPE_CSC_COEFF_RV_GV(pipe), CSC_RGB_TO_YUV_RV_GV);
> >> +  I915_WRITE(PIPE_CSC_COEFF_BV(pipe), CSC_RGB_TO_YUV_BV);
> >> +
> >> +  /* Spec postoffset values */
> >> +  I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), POSTOFF_RGB_TO_YUV_HI);
> >> +  I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), POSTOFF_RGB_TO_YUV_ME);
> >> +  I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), POSTOFF_RGB_TO_YUV_LO);
> >> +
> >> +  /* CSC mode before gamma */
> >> +  I915_WRITE(PIPE_CSC_MODE(pipe), 0);
> >> +}
> >> +
> >>   /* Set up the pipe CSC unit. */
> >>   static void i9xx_load_csc_matrix(struct drm_crtc_state *crtc_state)
> >>   {
> >> @@ -101,7 +143,10 @@ static void i9xx_load_csc_matrix(struct 
> >> drm_crtc_state *crtc_state)
> >>uint16_t coeffs[9] = { 0, };
> >>

Re: [Intel-gfx] [PATCH 11/20] drm/i915: prepare scaler for YCBCR420 modeset

[Ville Syrjälä]

On Thu, Jul 13, 2017 at 10:51:04AM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 7/12/2017 10:47 PM, Ville Syrjälä wrote:
> > On Mon, Jul 10, 2017 at 04:48:39PM +0530, Shashank Sharma wrote:
> >> To get a YCBCR420 output from intel platforms, we need one
> >> scaler to scale down YCBCR444 samples to YCBCR420 samples.
> >>
> >> This patch:
> >> - Does scaler allocation for HDMI ycbcr420 outputs.
> >> - Programs PIPE_MISC register for ycbcr420 output.
> >> - Adds a new scaler user "HDMI output" to plug-into existing
> >>scaler framework. This output type is identified using bit
> >>30 of the scaler users bitmap.
> >>
> >> V2: rebase
> >> V3: rebase
> >> V4: rebase
> >> V5: addressed review comments from Ander:
> >>  - No need to check both scaler_user && hdmi_output.
> >>Check for scaler_user is enough.
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/i915/intel_atomic.c  |  6 ++
> >>   drivers/gpu/drm/i915/intel_display.c | 23 +++
> >>   drivers/gpu/drm/i915/intel_drv.h | 10 +-
> >>   drivers/gpu/drm/i915/intel_hdmi.c| 12 
> >>   drivers/gpu/drm/i915/intel_panel.c   |  3 ++-
> >>   5 files changed, 52 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> >> b/drivers/gpu/drm/i915/intel_atomic.c
> >> index 36d4e63..040d111 100644
> >> --- a/drivers/gpu/drm/i915/intel_atomic.c
> >> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> >> @@ -264,6 +264,12 @@ int intel_atomic_setup_scalers(struct 
> >> drm_i915_private *dev_priv,
> >>   
> >>/* panel fitter case: assign as a crtc scaler */
> >>scaler_id = &scaler_state->scaler_id;
> >> +  } else if (i == SKL_420_OUTPUT_INDEX) {
> > I think Ander already said that we should just tie this into the normal
> > pfit pipe scaler user. I agree. Having to users doesn't actually make
> > sense because there can be only one pipe scaler, and if we want to do
> > scaled 4:2:0 output then we anyway need to handle both cases
> > simultaneosly.
> I thought our idea of having a separate scalar user was a good one, 
> because, this gives additional information
> how and why the scalar is being used. Also, we dont program the other 
> scaling factors in this case, but we get
> the scaling profile set using PIPEMISC. So I would prefer to have this 
> as a special case or separate user, but you
> can think about this, and let me know.

Eventually we'll want scaling and 420 at the same time. So a separate
user just doesn't work.

> 
> - Shashank
> >
> >> +  name = "YCBCR420-OUTPUT";
> >> +  idx = intel_crtc->base.base.id;
> >> +
> >> +  /* YCBCR420 case: needs a pipe scaler */
> >> +  scaler_id = &scaler_state->scaler_id;
> >>} else {
> >>name = "PLANE";
> >>   
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 01900e1..c56081e 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -4621,6 +4621,9 @@ skl_update_scaler(struct intel_crtc_state 
> >> *crtc_state, bool force_detach,
> >> */
> >>need_scaling = src_w != dst_w || src_h != dst_h;
> >>   
> >> +  if (scaler_user == SKL_420_OUTPUT_INDEX)
> >> +  need_scaling = true;
> >> +
> >>/*
> >> * if plane is being disabled or scaler is no more required or force 
> >> detach
> >> *  - free scaler binded to this plane/crtc
> >> @@ -4668,6 +4671,26 @@ skl_update_scaler(struct intel_crtc_state 
> >> *crtc_state, bool force_detach,
> >>   }
> >>   
> >>   /**
> >> + * skl_update_scaler_crtc_420_output - Stages update to scaler state
> >> + * for YCBCR420 which needs a scaler, for downsampling.
> >> + *
> >> + * @state: crtc's scaler state
> >> + *
> >> + * Return
> >> + * 0 - scaler_usage updated successfully
> >> + *error - requested scaling cannot be supported or other error 
> >> condition
> >> + */
> >> +int skl_update_scaler_crtc_420_output(struct intel_crtc_state *state)
> >> +{
> >> +  const struct drm_display_mode *mode = &state->base.adjusted_mode;
> >> +
> >> +  return skl_update_scaler(state, !state->base.active,
> >> +  SKL_420_OUTPUT_INDEX, &state->scaler_state.scaler_id,
> >> +  state->pipe_src_w, state->pipe_src_h,
> >> +  mode->crtc_hdisplay, mode->crtc_vdisplay);
> >> +}
> >> +
> >> +/**
> >>* skl_update_scaler_crtc - Stages update to scaler state for a given 
> >> crtc.
> >>*
> >>* @state: crtc's scaler state
> >> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> >> b/drivers/gpu/drm/i915/intel_drv.h
> >> index 592243b..68b4fba 100644
> >> --- a/drivers/gpu/drm/i915/intel_drv.h
> >> +++ b/drivers/gpu/drm/i915/intel_drv.h
> >> @@ -471,7 +471,8 @@ struct intel_crtc_scaler_state {
> >> *
> >> * If a bit is set, a user is using a scaler.
> >> *  

Re: [Intel-gfx] [PATCH 13/20] drm/i915: prepare csc unit for YCBCR420 output

[Sharma, Shashank]

Regards

Shashank


On 7/13/2017 6:20 PM, Ville Syrjälä wrote:

On Thu, Jul 13, 2017 at 10:44:51AM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 7/12/2017 10:47 PM, Ville Syrjälä wrote:

On Mon, Jul 10, 2017 at 04:48:41PM +0530, Shashank Sharma wrote:

To support ycbcr output, we need a pipe CSC block to do
RGB->YCBCR conversion.

Current Intel platforms have only one pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.

This function adds a csc handler, which uses recommended bspec
values to perform RGB->YCBCR conversion (target color space BT709)

V2: Rebase
V3: Rebase
V4: Rebase
V5: Addressed review comments from Ander
  - Remove extra line added in the patch
  - Add the spec details in the commit message
  - Combine two if(cond) while calling intel_crtc_compute_config
V6: Handle YCBCR420 outputs only (Ville)

Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/i915/intel_color.c   | 47 
+++-
   drivers/gpu/drm/i915/intel_display.c | 17 +
   2 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 306c6b0..8a5d211 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,19 @@
   
   #define LEGACY_LUT_LENGTH		(sizeof(struct drm_color_lut) * 256)
   
+/* Post offset values for RGB->YCBCR conversion */

+#define POSTOFF_RGB_TO_YUV_HI 0x800
+#define POSTOFF_RGB_TO_YUV_ME 0x100
+#define POSTOFF_RGB_TO_YUV_LO 0x800
+
+/* Direct spec values for RGB->YUV conversion matrix */

Are these BT.601 or BT.709 or something else?

I thought I added some comment mentioning this being BT 709, but looks
like dealing with too many paptches :)
Will add those details.

+#define CSC_RGB_TO_YUV_RU_GU 0x2ba809d8
+#define CSC_RGB_TO_YUV_BU 0x37e8
+#define CSC_RGB_TO_YUV_RY_GY 0x1e089cc0
+#define CSC_RGB_TO_YUV_BY 0xb528
+#define CSC_RGB_TO_YUV_RV_GV 0xbce89ad8
+#define CSC_RGB_TO_YUV_BV 0x1e08

IIRC Ander didn't like these, and neither do I. I'd much prefer to reuse
the code we alreayd have for dealing with the CSC. Except I think that's
pretty broken in places so I guess we can go with this for now and try
to clean up the color management stuff later.

Yes, that was the plan. I was planning to fix the complete CSC cleanup
stuff in a separate patch, but as that needs much
of validation before we can merge it, I added in a bottom half. I will
send a patch for the same soon.

+
   /*
* Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
* format). This macro takes the coefficient we want transformed and the
@@ -91,6 +104,35 @@ static void ctm_mult_by_limited(uint64_t *result, int64_t 
*input)
}
   }
   
+void i9xx_load_ycbcr_conversion_matrix(struct intel_crtc *intel_crtc)

+{
+   int pipe = intel_crtc->pipe;
+   struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+
+   /* We don't use high values for conversion */

I don't understand what this comment is trying so say.

Yeah, it should have been "we dont use pre-offsets for conversion"

I think that's very obvious from the code. So no need for comment IMO.

Ok.

+   I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
+
+   /* Program direct spec values for RGB to YCBCR conversion matrix */

In fact pretty much all the comments in this patch seem redundant.
Comments should explain why we do something, if necessary. They
should not just transcribe the actual code into words.

Ok.

+   I915_WRITE(PIPE_CSC_COEFF_RU_GU(pipe), CSC_RGB_TO_YUV_RU_GU);
+   I915_WRITE(PIPE_CSC_COEFF_BU(pipe), CSC_RGB_TO_YUV_BU);
+
+   I915_WRITE(PIPE_CSC_COEFF_RY_GY(pipe), CSC_RGB_TO_YUV_RY_GY);
+   I915_WRITE(PIPE_CSC_COEFF_BY(pipe), CSC_RGB_TO_YUV_BY);
+
+   I915_WRITE(PIPE_CSC_COEFF_RV_GV(pipe), CSC_RGB_TO_YUV_RV_GV);
+   I915_WRITE(PIPE_CSC_COEFF_BV(pipe), CSC_RGB_TO_YUV_BV);
+
+   /* Spec postoffset values */
+   I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), POSTOFF_RGB_TO_YUV_HI);
+   I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), POSTOFF_RGB_TO_YUV_ME);
+   I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), POSTOFF_RGB_TO_YUV_LO);
+
+   /* CSC mode before gamma */
+   I915_WRITE(PIPE_CSC_MODE(pipe), 0);
+}
+
   /* Set up the pipe CSC unit. */
   static void i9xx_load_csc_matrix(struct drm_crtc_state *crtc_state)
   {
@@ -101,7 +143,10 @@ static void i9xx_load_csc_matrix(struct drm_crtc_state 
*crtc_state)
uint16_t coeffs[9] = { 0, };
struct intel_crtc_state *intel_crtc_state = 
to_intel_crtc_state(crtc_state);
   
-	if (crtc_state->ctm) {

+   if (intel_crtc_state->ycbcr420) {
+   i9xx_load_ycbcr_conversion_matrix(intel_crtc);
+   return;
+   } else if (crtc_state->ctm) {
struct drm_color_ctm *ctm =
  

Re: [Intel-gfx] [PATCH 10/20] drm/i915: add config function for YCBCR420 outputs

[Ville Syrjälä]

On Thu, Jul 13, 2017 at 10:56:06AM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 7/12/2017 10:47 PM, Ville Syrjälä wrote:
> > On Mon, Jul 10, 2017 at 04:48:38PM +0530, Shashank Sharma wrote:
> >> This patch checks encoder level support for YCBCR420 outputs.
> >> The logic goes as simple as this:
> >> If the input mode is YCBCR420-only mode: prepare HDMI for
> >> YCBCR420 output, else continue with RGB output mode.
> >>
> >> It checks if the mode is YCBCR420 and source can support this
> >> output then it marks the ycbcr_420 output indicator into crtc
> >> state, for further staging in driver.
> >>
> >> V2: Split the patch into two, kept helper functions in DRM layer.
> >> V3: Changed the compute_config function based on new DRM API.
> >> V4: Rebase
> >> V5: Rebase
> >> V6: Check and handle YCBCR420-only modes, discard the property
> >>  based approach (Ville)
> >>
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/i915/intel_display.c |  1 +
> >>   drivers/gpu/drm/i915/intel_drv.h |  3 +++
> >>   drivers/gpu/drm/i915/intel_hdmi.c| 42 
> >> +---
> >>   3 files changed, 43 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 4e03ca6..01900e1 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -11930,6 +11930,7 @@ intel_pipe_config_compare(struct drm_i915_private 
> >> *dev_priv,
> >>PIPE_CONF_CHECK_I(hdmi_scrambling);
> >>PIPE_CONF_CHECK_I(hdmi_high_tmds_clock_ratio);
> >>PIPE_CONF_CHECK_I(has_infoframe);
> >> +  PIPE_CONF_CHECK_I(ycbcr420);
> >>   
> >>PIPE_CONF_CHECK_I(has_audio);
> >>   
> >> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> >> b/drivers/gpu/drm/i915/intel_drv.h
> >> index d17a324..592243b 100644
> >> --- a/drivers/gpu/drm/i915/intel_drv.h
> >> +++ b/drivers/gpu/drm/i915/intel_drv.h
> >> @@ -780,6 +780,9 @@ struct intel_crtc_state {
> >>   
> >>/* HDMI High TMDS char rate ratio */
> >>bool hdmi_high_tmds_clock_ratio;
> >> +
> >> +  /* HDMI output type */
> >> +  bool ycbcr420;
> >>   };
> >>   
> >>   struct intel_crtc {
> >> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> >> b/drivers/gpu/drm/i915/intel_hdmi.c
> >> index cc0d100..276d916 100644
> >> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> >> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> >> @@ -1305,7 +1305,8 @@ intel_hdmi_mode_valid(struct drm_connector 
> >> *connector,
> >>return status;
> >>   }
> >>   
> >> -static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state)
> >> +static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state,
> >> +  bool output_ycbcr420)
> > You alreayd have the crtc state, so no need to pass that stuff
> > separately.
> Ah, this was dumb, thanks !
> >>   {
> >>struct drm_i915_private *dev_priv =
> >>to_i915(crtc_state->base.crtc->dev);
> >> @@ -1330,6 +1331,13 @@ static bool hdmi_12bpc_possible(struct 
> >> intel_crtc_state *crtc_state)
> >>if (connector_state->crtc != crtc_state->base.crtc)
> >>continue;
> >>   
> >> +  if (output_ycbcr420) {
> >> +  const struct drm_hdmi_info *hdmi = &info->hdmi;
> >> +
> >> +  if (!(hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_36))
> >> +  return false;
> >> +  }
> >> +
> > else?
> Oops, needs an else { break;}

I was thinking 'else if ...'

> 
> - Shashank
> >
> >>if ((info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36) == 0)
> >>return false;
> >>}
> >> @@ -1342,6 +1350,25 @@ static bool hdmi_12bpc_possible(struct 
> >> intel_crtc_state *crtc_state)
> >>return true;
> >>   }
> >>   
> >> +static bool
> >> +intel_hdmi_ycbcr420_config(struct drm_connector *connector,
> >> + struct intel_crtc_state *config,
> >> + int *clock_12bpc, int *clock_8bpc)
> >> +{
> >> +
> >> +  if (!connector->ycbcr_420_allowed) {
> >> +  DRM_ERROR("Platform doesn't support YCBCR420 output\n");
> >> +  return false;
> >> +  }
> >> +
> >> +  /* YCBCR420 TMDS rate requirement is half the pixel clock */
> >> +  config->port_clock /= 2;
> >> +  *clock_12bpc /= 2;
> >> +  *clock_8bpc /= 2;
> >> +  config->ycbcr420 = true;
> >> +  return true;
> >> +}
> >> +
> >>   bool intel_hdmi_compute_config(struct intel_encoder *encoder,
> >>   struct intel_crtc_state *pipe_config,
> >>   struct drm_connector_state *conn_state)
> >> @@ -1349,7 +1376,8 @@ bool intel_hdmi_compute_config(struct intel_encoder 
> >> *encoder,
> >>struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
> >>struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> >>struct drm_display_mode *adjusted_mode = 
> >> &pipe_config->base.adjusted_mode;
> >>

Re: [Intel-gfx] [PATCH 20/20] drm/i915: write AVI infoframes for LSPCON

[Ville Syrjälä]

On Thu, Jul 13, 2017 at 06:09:53PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 7/13/2017 5:57 PM, Ville Syrjälä wrote:
> > On Thu, Jul 13, 2017 at 11:11:53AM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 7/12/2017 10:54 PM, Ville Syrjälä wrote:
> >>> On Mon, Jul 10, 2017 at 04:48:48PM +0530, Shashank Sharma wrote:
>  LSPCON chips can't pick the HDMI AVI infoframes from direct link.
>  In order to pass AVI infoframes from display controller to LSPCON,
>  we have to write infoframe packets into vendor specified AUX address.
> 
>  Also, LSPCON vendors provide AUX offsets, to inform the LSPCON
>  chip that the AVI IF packets are written, so that the firmware
>  can pick it up and apply.
> 
>  This patch adds function to write AVI infoframes for both MCA as
>  well as Parade Tech LSPCON chips. These two vendors provide different
>  methods for writing infoframes, so this patch contains two different
>  functions, one for each.
> >>> Seems to me that we should also be checking the receiver cap for the
> >>> 444->420 conversion support, and enable it in the PROTOCOL_CONVERTER
> >>> DPCD register. Or are these LSPCON things even ignoring that part of the
> >>> spec?
> >> Yes, LSPCON just needs the YCBCR444 input, and info frames for 420, and
> >> it would take care of
> >> 444->420 conversion in FW.
> > So it snoops the AVI infoframe we write to it to figure out that it has
> > to do the 444->420 downsampling?
> Yes, that's exactly what it does.

Can you add a comment somewhere appropriate to make that clear.
Otherwise people might wonder why we're not enabling the downsampling at
all.

Does LSPCON then not even implement the PROTOCOL_CONVERTER DCPD
registers?

Can you send the spec for this stuff my way? What I have now doesn't
document any DPCD registers.

> - Shashank
> >> Also, its a part of LSPCON specs, that it has
> >> to have 420 output capability.
> >>
> >> - Shashank
>  Cc: Ville Syrjälä 
>  Cc: Imre Deak 
>  Signed-off-by: Shashank Sharma 
>  ---
> drivers/gpu/drm/i915/intel_ddi.c|   8 ++
> drivers/gpu/drm/i915/intel_drv.h|   3 +
> drivers/gpu/drm/i915/intel_lspcon.c | 174 
>  
> 3 files changed, 185 insertions(+)
> 
>  diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
>  b/drivers/gpu/drm/i915/intel_ddi.c
>  index f691710..944d9d5 100644
>  --- a/drivers/gpu/drm/i915/intel_ddi.c
>  +++ b/drivers/gpu/drm/i915/intel_ddi.c
>  @@ -2068,6 +2068,14 @@ void intel_ddi_set_avi_infoframe(struct 
>  drm_encoder *encoder,
>  rgb_qrange_limited,
>  rgb_qrange_selectable);
> 
>  +if (crtc_state->lspcon_active) {
>  +struct intel_lspcon *lspcon = 
>  enc_to_intel_lspcon(encoder);
>  +
>  +/* LSPCON writes infoframes via AUX */
>  +lspcon->write_infoframe(encoder, crtc_state, &frame);
>  +return;
>  +}
>  +
>   intel_write_infoframe(encoder, crtc_state, &frame);
> }
> 
>  diff --git a/drivers/gpu/drm/i915/intel_drv.h 
>  b/drivers/gpu/drm/i915/intel_drv.h
>  index fad9a53..3e686d2 100644
>  --- a/drivers/gpu/drm/i915/intel_drv.h
>  +++ b/drivers/gpu/drm/i915/intel_drv.h
>  @@ -1079,6 +1079,9 @@ struct intel_lspcon {
>   /* AVI IF setup function for LSPCON */
>   void (*set_infoframes)(struct drm_encoder *encoder,
>   const struct intel_crtc_state 
>  *crtc_state);
>  +void (*write_infoframe)(struct drm_encoder *encoder,
>  +const struct intel_crtc_state 
>  *crtc_state,
>  +union hdmi_infoframe *frame);
> };
> 
> struct intel_digital_port {
>  diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
>  b/drivers/gpu/drm/i915/intel_lspcon.c
>  index 53ddd39..01fddf7 100644
>  --- a/drivers/gpu/drm/i915/intel_lspcon.c
>  +++ b/drivers/gpu/drm/i915/intel_lspcon.c
>  @@ -31,6 +31,18 @@
> #define LSPCON_VENDOR_PARADE_OUI 0x001CF8
> #define LSPCON_VENDOR_MCA_OUI 0x0060AD
> 
>  +/* AUX addresses to write AVI IF into */
>  +#define LSPCON_MCA_AVI_IF_WRITE_OFFSET 0x5C0
>  +#define LSPCON_MCA_AVI_IF_CTRL 0x5DF
>  +#define  LSPCON_MCA_AVI_IF_KICKOFF (1 << 0)
>  +#define  LSPCON_MCA_AVI_IF_HANDLED (1 << 1)
>  +
>  +#define LSPCON_PARADE_AVI_IF_WRITE_OFFSET 0x516
>  +#define LSPCON_PARADE_AVI_IF_CTRL 0x51E
>  +#define  LSPCON_PARADE_AVI_IF_KICKOFF (1 << 7)
>  +#define LSPCON_PARADE_AVI_IF_STATUS 0x51F
>  +#define  LSPCON_PARADE_AVI_IF_HANDLED (2 << 6)
>  +
> static struc

Re: [Intel-gfx] [PATCH 11/20] drm/i915: prepare scaler for YCBCR420 modeset

[Sharma, Shashank]

Regards

Shashank


On 7/13/2017 6:22 PM, Ville Syrjälä wrote:

On Thu, Jul 13, 2017 at 10:51:04AM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 7/12/2017 10:47 PM, Ville Syrjälä wrote:

On Mon, Jul 10, 2017 at 04:48:39PM +0530, Shashank Sharma wrote:

To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.

This patch:
- Does scaler allocation for HDMI ycbcr420 outputs.
- Programs PIPE_MISC register for ycbcr420 output.
- Adds a new scaler user "HDMI output" to plug-into existing
scaler framework. This output type is identified using bit
30 of the scaler users bitmap.

V2: rebase
V3: rebase
V4: rebase
V5: addressed review comments from Ander:
  - No need to check both scaler_user && hdmi_output.
Check for scaler_user is enough.
Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/i915/intel_atomic.c  |  6 ++
   drivers/gpu/drm/i915/intel_display.c | 23 +++
   drivers/gpu/drm/i915/intel_drv.h | 10 +-
   drivers/gpu/drm/i915/intel_hdmi.c| 12 
   drivers/gpu/drm/i915/intel_panel.c   |  3 ++-
   5 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 36d4e63..040d111 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -264,6 +264,12 @@ int intel_atomic_setup_scalers(struct drm_i915_private 
*dev_priv,
   
   			/* panel fitter case: assign as a crtc scaler */

scaler_id = &scaler_state->scaler_id;
+   } else if (i == SKL_420_OUTPUT_INDEX) {

I think Ander already said that we should just tie this into the normal
pfit pipe scaler user. I agree. Having to users doesn't actually make
sense because there can be only one pipe scaler, and if we want to do
scaled 4:2:0 output then we anyway need to handle both cases
simultaneosly.

I thought our idea of having a separate scalar user was a good one,
because, this gives additional information
how and why the scalar is being used. Also, we dont program the other
scaling factors in this case, but we get
the scaling profile set using PIPEMISC. So I would prefer to have this
as a special case or separate user, but you
can think about this, and let me know.

Eventually we'll want scaling and 420 at the same time. So a separate
user just doesn't work.
Ok, I was just following the design, which we discussed during F2F. I 
will remove this user then.

- Shashank

- Shashank

+   name = "YCBCR420-OUTPUT";
+   idx = intel_crtc->base.base.id;
+
+   /* YCBCR420 case: needs a pipe scaler */
+   scaler_id = &scaler_state->scaler_id;
} else {
name = "PLANE";
   
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c

index 01900e1..c56081e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4621,6 +4621,9 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
 */
need_scaling = src_w != dst_w || src_h != dst_h;
   
+	if (scaler_user == SKL_420_OUTPUT_INDEX)

+   need_scaling = true;
+
/*
 * if plane is being disabled or scaler is no more required or force 
detach
 *  - free scaler binded to this plane/crtc
@@ -4668,6 +4671,26 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
   }
   
   /**

+ * skl_update_scaler_crtc_420_output - Stages update to scaler state
+ * for YCBCR420 which needs a scaler, for downsampling.
+ *
+ * @state: crtc's scaler state
+ *
+ * Return
+ * 0 - scaler_usage updated successfully
+ *error - requested scaling cannot be supported or other error condition
+ */
+int skl_update_scaler_crtc_420_output(struct intel_crtc_state *state)
+{
+   const struct drm_display_mode *mode = &state->base.adjusted_mode;
+
+   return skl_update_scaler(state, !state->base.active,
+   SKL_420_OUTPUT_INDEX, &state->scaler_state.scaler_id,
+   state->pipe_src_w, state->pipe_src_h,
+   mode->crtc_hdisplay, mode->crtc_vdisplay);
+}
+
+/**
* skl_update_scaler_crtc - Stages update to scaler state for a given crtc.
*
* @state: crtc's scaler state
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 592243b..68b4fba 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -471,7 +471,8 @@ struct intel_crtc_scaler_state {
 *
 * If a bit is set, a user is using a scaler.
 * Here user can be a plane or crtc as defined below:
-*   bits 0-30 - plane (bit position is index from drm_plane_index)
+*   bits 0-29 - plane (bit position is index from drm_plane_index)
+*   bit 30- hdmi output
   

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Ramalingam C]

On Thursday 13 July 2017 04:06 PM, Daniel Vetter wrote:

On Thu, Jul 13, 2017 at 12:15 PM, Ramalingam C  wrote:


On Thursday 13 July 2017 02:15 PM, Daniel Vetter wrote:

On Thu, Jul 13, 2017 at 8:54 AM, Ramalingam C 
wrote:

On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote:

On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul  wrote:

Why all these intermediate steps and different failure modes? Either hdcp
works, or it doesnt (and we can split up with the type 0 or type 1 if
needed), but I don't know what userspace would do with all the other
stuff?

enum values  HDCP_ENABLE, HDCP_ENABLE_TYPE1 and HDCP_DISABLE along with
kobj-uevent
for HDCP state change, could do the bare minimal HDCP1.4 and HDCP2.2
configuration.

And without Type info it is not possible for HDCP2.2.

I've had requests from chrome team to expose HDCP version, so I don't think
this
is too contentious.

I think it'd still be easier if we start out with the current content
protection props that CrOS is using, and then figure out how to layer
the exact version/standard on top? One thing at a time and all that.
-Daniel

I understand the approach.

But Only problem is current upstreaming effort is for HDCP2.2 support at DRM
with a design which can
easily accommodate other versions too. So we  need to stretch current CrOS
property a bit with
ENABLE_TYPE1 and UNSUPPORTED etc. Hope that should be fine for all.

Yeah, but if we just go with enable (without specifying the type) we
could still enable the highest hdcp level (so 2.2 for our case). At
least I don't see a reason why we need to already have the
enable_type1 thing. Can you pls explain why you think this is
necessary?

There seems to be a need to force type1, but I think it's easier to do
that as an extension. Of course we need to keep it in mind meanwhile.

Background for this need of Type info in HDCP2.2 implementation is as
follows:

Aside: You're quoting is broken for inline quoting. Either fix the
quoting or top-quote (there's no difference between your text and
mine, mine should be indented with > or | or similar).
Sorry for the inconvenience. Hope now it is fine. Just reset the 
settings on thunderbird



HDCP2.2 Spec classify the protected content as Type 0 and Type 1. For
Example lets say
- A HDCP2.2 Src is connected to HDCP repeater
- that repeater is connected to a HDCP2.2 panel
- that same repeater is also connected to a HDCP1.4 panel.

In this topology, as part of Repeater authentication:
- HDCP2.2 Source will mention the Content Type to HDCP2.2 Repeater
- Repeater can transmit this Type 1 content to HDCP2.2 compliant sink only
(which is HDCP 2.2 panel here).
- Repeater can transmit any type0 content to any other devices (like HDCP1.4
panel here).
- Device with no HDCP support will get Neither of Type 0 or Type 1.

So if we implement HDCP2.2 with HDCP_ENABLE state alone there is no way for
Userspace
to request for HDCP2.2 protection only. In this case we wont know the
content type classification.

Yes, that is the case, but also the point of gradual enabling. Atm
(with the current CrOS usersapce) userspace can ask for "pls give me
content protection, I don't care what level/type". That itself is
already useful, and a good step forward. Allowing to ask for a
specific type is something on top.
Ok. When i think over it, that sounds as a  good idea to go gradually 
for enabling HDCP2.2.



Even if we force Content type to Type1, in above topology Type 0 content
that could be rendered to
HDCP1.4 compliant panel wont be rendered as that has been forcibly
classified as Type 1 by KMD.

Why? HDCP_ENABLE would just give you the "best" HDCP, so we'd fall
back to type 0 (if that's available).
I think i misinterpreted. We could enable the HDCP2.2(if supported on 
panel) for the Type 0 content. No issue on that

Forcing type 1 content to Type 0 will break the association of type1 content
to HDCP2.2 devices only.

I didn't propose to force type1 everywhere. Why do you think this is needed.



More than that Devices with our indented DRM HDCP2.2 support wont pass the
HDCP2.2 compliance.
Considering we could extend the CrOS Userspace for HDCP2.2, I would prefer
to go ahead with
HDCP_ENABLE_TYPE1 along with HDCP_ENABLE.

Yes, it's only hdcp1.4, and getting to full hdcp2.2 will take more
work. You can do all of that in one go, but my experience with
upstreaming new uabi is that usually that's not the most effective way
to go about things. But in the end, that's your choice.

Agreed. We will go gradually about enabling HDCP2.2.
1. Enable HDCP2.2 for HDCP_ENABLE with Content type as 0.
2. Enable HDCP2.2 for Type 1 content with Enum value HDCP_ENABLE_TYPE1
3. Making HDCP2.2 support as HDCP2.2 spec compliant.

But I think i will just add another enum value HDCP_UNSUPPORTED to mark 
the no HDCP supported on the setup.

I hope that is fine.

-Daniel


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailm

Re: [Intel-gfx] [PATCH 06/20] drm: add helper to validate YCBCR420 modes

[Ville Syrjälä]

On Thu, Jul 13, 2017 at 06:12:50PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 7/13/2017 6:01 PM, Ville Syrjälä wrote:
> > On Thu, Jul 13, 2017 at 11:02:18AM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 7/12/2017 10:48 PM, Ville Syrjälä wrote:
> >>> On Mon, Jul 10, 2017 at 04:48:34PM +0530, Shashank Sharma wrote:
>  YCBCR420 modes are supported only on HDMI 2.0 capable sources.
>  This patch adds:
>  - A drm helper to validate YCBCR420-only mode on a particular
>  connector. This function will help pruning the YCBCR420-only
>  modes from the connector's modelist.
>  - A bool variable (ycbcr_420_allowed) in the drm connector structure.
>  While handling the EDID from HDMI 2.0 sinks, its important to know
>  if the source is capable of handling YCBCR420 output, so that no
>  YCBCR 420 modes will be listed for sources which can't handle it.
>  A driver should set this variable if it wants to see YCBCR420 modes
>  in the modedb.
> 
>  V5: Introduced the patch in series.
>  V5-resend: Squashed two patches (validate YCBCR420 and add YCBCR420
>  identifier)
> 
>  Signed-off-by: Shashank Sharma 
>  ---
> drivers/gpu/drm/drm_edid.c |  3 ++-
> drivers/gpu/drm/drm_modes.c| 28 
> drivers/gpu/drm/drm_probe_helper.c |  4 
> include/drm/drm_connector.h|  9 +
> include/drm/drm_edid.h |  1 +
> include/drm/drm_modes.h|  5 +
> 6 files changed, 49 insertions(+), 1 deletion(-)
> 
>  diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>  index 10dab62..44be128 100644
>  --- a/drivers/gpu/drm/drm_edid.c
>  +++ b/drivers/gpu/drm/drm_edid.c
>  @@ -2950,10 +2950,11 @@ u8 drm_match_cea_mode(const struct 
>  drm_display_mode *to_match)
> }
> EXPORT_SYMBOL(drm_match_cea_mode);
> 
>  -static bool drm_valid_cea_vic(u8 vic)
>  +bool drm_valid_cea_vic(u8 vic)
> {
>   return vic > 0 && vic < ARRAY_SIZE(edid_cea_modes);
> }
>  +EXPORT_SYMBOL(drm_valid_cea_vic);
> 
> /**
>  * drm_get_cea_aspect_ratio - get the picture aspect ratio 
>  corresponding to
>  diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>  index f2493b9..3b53c8e3 100644
>  --- a/drivers/gpu/drm/drm_modes.c
>  +++ b/drivers/gpu/drm/drm_modes.c
>  @@ -1083,6 +1083,34 @@ drm_mode_validate_size(const struct 
>  drm_display_mode *mode,
> }
> EXPORT_SYMBOL(drm_mode_validate_size);
> 
>  +/**
>  + * drm_mode_ycbcr420_only - add 'ycbcr420-only' modes only when allowed
>  + * @mode: mode to check
>  + * @connector: drm connector under action
>  + *
>  + * This function is a helper which can be used to filter out any 
>  YCBCR420
>  + * only mode, when the source doesn't support it.
>  + *
>  + * Returns:
>  + * The mode status
>  + */
>  +enum drm_mode_status
>  +drm_mode_validate_ycbcr420(const struct drm_display_mode *mode,
>  +   struct drm_connector *connector)
>  +{
>  +u8 vic = drm_match_cea_mode(mode);
>  +enum drm_mode_status status = MODE_OK;
>  +struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
>  +
>  +if (drm_valid_cea_vic(vic) && test_bit(vic, 
>  hdmi->y420_vdb_modes)) {
> >>> Still think the valid check is pointless.
> >> I still think that we should only pass valid CEA VIC to VDB check, but
> >> Ok, I will remove that.
> >>>Skipping that would also avoid
> >>> having to make the function non-static
> >> Ok
> >>> (the EXPORT_SYMBOL there seems
> >>> unnecessary either way).
> >> Why ?
> > It's all in the same module AFAICS.
> >
> > Oh, and the patch ordering here still looks potentially problematic. We
> > should add the 420 mode validation before we start adding the 420 modes.
> > Otherwise anyone bisecting through this may get a black/corrupted screen
> > if they have a monitor with "420 only" modes.
> Actually, the 420 mode validation patch uses 420_only bitmap, which is 
> added in add_420_modes patch.
> So I can't put this patch before other one (you reviewed that sequence 
> once, and found that).

I guess then you just need to add the bitmap already in the validation
patch.

An alternative would be just squash the patches, but that seems a bit
drastic, and probably would mix up too many things in one patch.

> - Shashank
>  +if (!connector->ycbcr_420_allowed)
>  +status = MODE_NO_420;
>  +}
>  +
>  +return status;
>  +}
>  +EXPORT_SYMBOL(drm_mode_validate_ycbcr420);
>  +
> #define MODE_STATUS(status) [MODE_

Re: [Intel-gfx] [PATCH 10/20] drm/i915: add config function for YCBCR420 outputs

[Sharma, Shashank]

Regards

Shashank


On 7/13/2017 6:23 PM, Ville Syrjälä wrote:

On Thu, Jul 13, 2017 at 10:56:06AM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 7/12/2017 10:47 PM, Ville Syrjälä wrote:

On Mon, Jul 10, 2017 at 04:48:38PM +0530, Shashank Sharma wrote:

This patch checks encoder level support for YCBCR420 outputs.
The logic goes as simple as this:
If the input mode is YCBCR420-only mode: prepare HDMI for
YCBCR420 output, else continue with RGB output mode.

It checks if the mode is YCBCR420 and source can support this
output then it marks the ycbcr_420 output indicator into crtc
state, for further staging in driver.

V2: Split the patch into two, kept helper functions in DRM layer.
V3: Changed the compute_config function based on new DRM API.
V4: Rebase
V5: Rebase
V6: Check and handle YCBCR420-only modes, discard the property
  based approach (Ville)

Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/i915/intel_display.c |  1 +
   drivers/gpu/drm/i915/intel_drv.h |  3 +++
   drivers/gpu/drm/i915/intel_hdmi.c| 42 
+---
   3 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4e03ca6..01900e1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11930,6 +11930,7 @@ intel_pipe_config_compare(struct drm_i915_private 
*dev_priv,
PIPE_CONF_CHECK_I(hdmi_scrambling);
PIPE_CONF_CHECK_I(hdmi_high_tmds_clock_ratio);
PIPE_CONF_CHECK_I(has_infoframe);
+   PIPE_CONF_CHECK_I(ycbcr420);
   
   	PIPE_CONF_CHECK_I(has_audio);
   
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h

index d17a324..592243b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -780,6 +780,9 @@ struct intel_crtc_state {
   
   	/* HDMI High TMDS char rate ratio */

bool hdmi_high_tmds_clock_ratio;
+
+   /* HDMI output type */
+   bool ycbcr420;
   };
   
   struct intel_crtc {

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index cc0d100..276d916 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1305,7 +1305,8 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
return status;
   }
   
-static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state)

+static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state,
+   bool output_ycbcr420)

You alreayd have the crtc state, so no need to pass that stuff
separately.

Ah, this was dumb, thanks !

   {
struct drm_i915_private *dev_priv =
to_i915(crtc_state->base.crtc->dev);
@@ -1330,6 +1331,13 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state 
*crtc_state)
if (connector_state->crtc != crtc_state->base.crtc)
continue;
   
+		if (output_ycbcr420) {

+   const struct drm_hdmi_info *hdmi = &info->hdmi;
+
+   if (!(hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_36))
+   return false;
+   }
+

else?

Oops, needs an else { break;}

I was thinking 'else if ...'

Do we need else if for 12 BPC case, I was thinking of:
if (!hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_36)
   /* 12 BPC Y420 not possible */
   return false;
else
  /* output is going to be 420, and 12BPC is possible, so break the 
loop */

  break;

This will also allow the code to go through the WAR Added below.
- Shashank



- Shashank

if ((info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36) == 0)
return false;
}
@@ -1342,6 +1350,25 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state 
*crtc_state)
return true;
   }
   
+static bool

+intel_hdmi_ycbcr420_config(struct drm_connector *connector,
+  struct intel_crtc_state *config,
+  int *clock_12bpc, int *clock_8bpc)
+{
+
+   if (!connector->ycbcr_420_allowed) {
+   DRM_ERROR("Platform doesn't support YCBCR420 output\n");
+   return false;
+   }
+
+   /* YCBCR420 TMDS rate requirement is half the pixel clock */
+   config->port_clock /= 2;
+   *clock_12bpc /= 2;
+   *clock_8bpc /= 2;
+   config->ycbcr420 = true;
+   return true;
+}
+
   bool intel_hdmi_compute_config(struct intel_encoder *encoder,
   struct intel_crtc_state *pipe_config,
   struct drm_connector_state *conn_state)
@@ -1349,7 +1376,8 @@ bool intel_hdmi_compute_config(struct intel_encoder 
*encoder,
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct drm_display_mode *adjusted_mode = 
&pipe_config->base.adjusted_mode;

Re: [Intel-gfx] [PATCH 08/20] drm: set output colorspace in AVI infoframe

[Ville Syrjälä]

On Thu, Jul 13, 2017 at 06:19:01PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 7/13/2017 6:05 PM, Ville Syrjälä wrote:
> > On Thu, Jul 13, 2017 at 10:37:53AM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 7/12/2017 10:47 PM, Ville Syrjälä wrote:
> >>> On Mon, Jul 10, 2017 at 04:48:36PM +0530, Shashank Sharma wrote:
>  A source must set output colorspace information in AVI
>  infoframes, so that the sink can decode upcoming frames
>  accordingly.
> 
>  This patch adds a function to add the output colorspace
>  information in the AVI infoframes.
> 
>  V2: Rebase
>  V3: Rebase
>  V4: Rebase
>  V5: Rebase
>  V6: Made patch independent of HDMI output type.
> 
>  Signed-off-by: Shashank Sharma 
>  ---
> drivers/gpu/drm/drm_edid.c | 29 +
> include/drm/drm_edid.h |  5 +
> 2 files changed, 34 insertions(+)
> 
>  diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>  index 944a28f..cede86e 100644
>  --- a/drivers/gpu/drm/drm_edid.c
>  +++ b/drivers/gpu/drm/drm_edid.c
>  @@ -4796,6 +4796,35 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
>  hdmi_avi_infoframe *frame,
> EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
> 
> /**
>  + * drm_hdmi_avi_infoframe_set_colorspace - fill an HDMI AVI infoframe 
>  with
>  + * colorspace data of the output type
>  + *
>  + * @frame: HDMI AVI infoframe
>  + * @mode: DRM display mode
>  + * @hdmi_output: HDMI output colorspace
>  + *
>  + * Return: 0 on success or a negative error code on failure.
>  + */
>  +int
>  +drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
>  +  const struct drm_display_mode 
>  *mode,
>  +  enum hdmi_colorspace colorspace)
>  +{
>  +if (colorspace > HDMI_COLORSPACE_YUV420 ||
>  +colorspace < HDMI_COLORSPACE_RGB) {
>  +DRM_ERROR("Invalid color space type\n");
>  +return -EINVAL;
>  +}
> >>> Seems overly defensive. I'd say that if someone insists on writing
> >>> buggy code just let them do it.
> >> :) yep can be done, you know, its a new implementation, don't want to
> >> create unnecessary noise so being
> >> a bit defensive :)
>  +
>  +frame->colorspace = colorspace;
>  +if (colorspace == HDMI_COLORSPACE_YUV420)
>  +frame->pixel_repeat = 0;
> >>> Most VICs don't allow pixel repeat in 444/etc. either, and we don't
> >>> protect against that. So this looks like pretty pointless check in
> >>> this form.
> >>>
> >>> So IMO just drop this entire patch and just assign frame->colorspace in
> >>> the driver.
> >> Actually YCBCR420 section of spec specifically calls out for not
> >> allowing repetition, also, when I tested this on a
> >> HDMI 2.0 analyzer, if was giving a AVI IF failure on pixel_repeat not 0,
> >> so IMHO it would be a good idea to keep
> >> this and get the tests passing.
> > That's just papering over bugs elsewhere. If we can't use pixel repeat
> > with a specific mode, then we should have rejected that mode much earlier.
> I dint get this point, HDMI 2.0 spec section 7.1 says "when YCBCR420 
> encoding is active, pixel repetition is not allowed" and
> pixel repetition field should be set to = 0, in AVI IF.  This seems to 
> be like - if you are displaying YCBCR420, set PR=0 regardless of
> mode, isn't it ?

If the mode requires pixel repeat to meet the minimum clock requirement,
then we can't just not do pixel repeat. That would violate the spec in
other ways, and IIRC we couldn't even generate a low enough clock for
it.

> 
> - Shashank
> >> - Shashank
>  +
>  +return 0;
>  +}
>  +EXPORT_SYMBOL(drm_hdmi_avi_infoframe_set_colorspace);
>  +
>  +/**
>  * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
>  *quantization range 
>  information
>  * @frame: HDMI AVI infoframe
>  diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
>  index aa58146..b79e0cb 100644
>  --- a/include/drm/drm_edid.h
>  +++ b/include/drm/drm_edid.h
>  @@ -332,6 +332,7 @@ struct cea_sad {
> struct drm_encoder;
> struct drm_connector;
> struct drm_display_mode;
>  +enum drm_hdmi_output_type;
> 
> void drm_edid_to_eld(struct drm_connector *connector, struct edid 
>  *edid);
> int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
>  @@ -354,6 +355,10 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
>  hdmi_avi_infoframe *frame,
>    const struct drm_display_mode 
>  *mode,

Re: [Intel-gfx] [PATCH 11/20] drm/i915: prepare scaler for YCBCR420 modeset

[Ville Syrjälä]

On Thu, Jul 13, 2017 at 06:27:04PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 7/13/2017 6:22 PM, Ville Syrjälä wrote:
> > On Thu, Jul 13, 2017 at 10:51:04AM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 7/12/2017 10:47 PM, Ville Syrjälä wrote:
> >>> On Mon, Jul 10, 2017 at 04:48:39PM +0530, Shashank Sharma wrote:
>  To get a YCBCR420 output from intel platforms, we need one
>  scaler to scale down YCBCR444 samples to YCBCR420 samples.
> 
>  This patch:
>  - Does scaler allocation for HDMI ycbcr420 outputs.
>  - Programs PIPE_MISC register for ycbcr420 output.
>  - Adds a new scaler user "HDMI output" to plug-into existing
>  scaler framework. This output type is identified using bit
>  30 of the scaler users bitmap.
> 
>  V2: rebase
>  V3: rebase
>  V4: rebase
>  V5: addressed review comments from Ander:
>    - No need to check both scaler_user && hdmi_output.
>  Check for scaler_user is enough.
>  Signed-off-by: Shashank Sharma 
>  ---
> drivers/gpu/drm/i915/intel_atomic.c  |  6 ++
> drivers/gpu/drm/i915/intel_display.c | 23 +++
> drivers/gpu/drm/i915/intel_drv.h | 10 +-
> drivers/gpu/drm/i915/intel_hdmi.c| 12 
> drivers/gpu/drm/i915/intel_panel.c   |  3 ++-
> 5 files changed, 52 insertions(+), 2 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
>  b/drivers/gpu/drm/i915/intel_atomic.c
>  index 36d4e63..040d111 100644
>  --- a/drivers/gpu/drm/i915/intel_atomic.c
>  +++ b/drivers/gpu/drm/i915/intel_atomic.c
>  @@ -264,6 +264,12 @@ int intel_atomic_setup_scalers(struct 
>  drm_i915_private *dev_priv,
> 
>   /* panel fitter case: assign as a crtc scaler */
>   scaler_id = &scaler_state->scaler_id;
>  +} else if (i == SKL_420_OUTPUT_INDEX) {
> >>> I think Ander already said that we should just tie this into the normal
> >>> pfit pipe scaler user. I agree. Having to users doesn't actually make
> >>> sense because there can be only one pipe scaler, and if we want to do
> >>> scaled 4:2:0 output then we anyway need to handle both cases
> >>> simultaneosly.
> >> I thought our idea of having a separate scalar user was a good one,
> >> because, this gives additional information
> >> how and why the scalar is being used. Also, we dont program the other
> >> scaling factors in this case, but we get
> >> the scaling profile set using PIPEMISC. So I would prefer to have this
> >> as a special case or separate user, but you
> >> can think about this, and let me know.
> > Eventually we'll want scaling and 420 at the same time. So a separate
> > user just doesn't work.
> Ok, I was just following the design, which we discussed during F2F. I 
> will remove this user then.

Yeah. Sorry for the ping-pong, I guess I didn't think this through
fully back then.

> - Shashank
> >> - Shashank
>  +name = "YCBCR420-OUTPUT";
>  +idx = intel_crtc->base.base.id;
>  +
>  +/* YCBCR420 case: needs a pipe scaler */
>  +scaler_id = &scaler_state->scaler_id;
>   } else {
>   name = "PLANE";
> 
>  diff --git a/drivers/gpu/drm/i915/intel_display.c 
>  b/drivers/gpu/drm/i915/intel_display.c
>  index 01900e1..c56081e 100644
>  --- a/drivers/gpu/drm/i915/intel_display.c
>  +++ b/drivers/gpu/drm/i915/intel_display.c
>  @@ -4621,6 +4621,9 @@ skl_update_scaler(struct intel_crtc_state 
>  *crtc_state, bool force_detach,
>    */
>   need_scaling = src_w != dst_w || src_h != dst_h;
> 
>  +if (scaler_user == SKL_420_OUTPUT_INDEX)
>  +need_scaling = true;
>  +
>   /*
>    * if plane is being disabled or scaler is no more required or 
>  force detach
>    *  - free scaler binded to this plane/crtc
>  @@ -4668,6 +4671,26 @@ skl_update_scaler(struct intel_crtc_state 
>  *crtc_state, bool force_detach,
> }
> 
> /**
>  + * skl_update_scaler_crtc_420_output - Stages update to scaler state
>  + * for YCBCR420 which needs a scaler, for downsampling.
>  + *
>  + * @state: crtc's scaler state
>  + *
>  + * Return
>  + * 0 - scaler_usage updated successfully
>  + *error - requested scaling cannot be supported or other error 
>  condition
>  + */
>  +int skl_update_scaler_crtc_420_output(struct intel_crtc_state *state)
>  +{
>  +const struct drm_display_mode *mode = 
>  &state->base.adjusted_mode;
>  +
>  +return skl_update_scaler(state, !state->base.active,
>  +   

Re: [Intel-gfx] [PATCH 19/20] drm/i915: Move AVI infoframe function to DDI layer

[Ville Syrjälä]

On Thu, Jul 13, 2017 at 10:28:00AM +0530, Sharma, Shashank wrote:
> Thanks for the review, Ville.
> 
> My comments, inline.
> 
> Regards
> Shashank
> On 7/12/2017 10:45 PM, Ville Syrjälä wrote:
> > On Mon, Jul 10, 2017 at 04:48:47PM +0530, Shashank Sharma wrote:
> >> We have an existing function to prepare AVI infoframes for HDMI,
> >> this patch moves that function from HDMI layer, to DDI layer, so
> >> that we can reuse the function for DP(LSPCON) displays too.
> >>
> >> This patch:
> >> - Moves the intel_hdmi_set_avi_infoframes function in ddi layer.
> >> - Adds code to accommodate LSPCON in the same function.
> >> - Links this function as AVI infoframe setup function for LSPCON.
> >>
> >> Cc: Ville Syrjälä 
> >> Cc: Imre Deak 
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/i915/intel_ddi.c| 89 
> >> ++---
> >>   drivers/gpu/drm/i915/intel_drv.h|  9 
> >>   drivers/gpu/drm/i915/intel_hdmi.c   | 52 +++---
> >>   drivers/gpu/drm/i915/intel_lspcon.c |  1 +
> >>   4 files changed, 99 insertions(+), 52 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> >> b/drivers/gpu/drm/i915/intel_ddi.c
> >> index 80e96f1..f691710 100644
> >> --- a/drivers/gpu/drm/i915/intel_ddi.c
> >> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> >> @@ -2003,8 +2003,76 @@ static void intel_ddi_clk_select(struct 
> >> intel_encoder *encoder,
> >>}
> >>   }
> >>   
> >> +void intel_ddi_set_avi_infoframe(struct drm_encoder *encoder,
> >> +const struct intel_crtc_state *crtc_state)
> > NAK. Please look at my 'move infoframe stuff into intel_dig_port' series
> > if you need infoframes with DP. IIRC you already reviewed part of that.
> Oh, looks like we were thinking in the same direction :).
> Sure, I will look for the whole patch series, and will re-use that code 
> in LSPCON/DP AVI IF series.
> Also, do let me know if you need review for those !

Please do review if you can. I was also hoping for some review
from people in the PSR front but that didn't happen so probably
no one else is looking at those patches anymore.

> 
> - Shashank
> >> +{
> >> +  int ret;
> >> +  union hdmi_infoframe frame;
> >> +  struct drm_connector *connector;
> >> +  struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> >> +  struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> >> +  const struct drm_display_mode *adjusted_mode =
> >> +  &crtc_state->base.adjusted_mode;
> >> +  enum intel_output_type type = to_intel_encoder(encoder)->type;
> >> +  bool is_hdmi2_sink = false;
> >> +  bool rgb_qrange_selectable = false;
> >> +  enum hdmi_colorspace colorspace = crtc_state->ycbcr420 ?
> >> +HDMI_COLORSPACE_YUV420 :
> >> +HDMI_COLORSPACE_RGB;
> >> +  bool rgb_qrange_limited =  crtc_state->limited_color_range ?
> >> +  HDMI_QUANTIZATION_RANGE_LIMITED :
> >> +  HDMI_QUANTIZATION_RANGE_FULL;
> >> +
> >> +  switch (type) {
> >> +  case INTEL_OUTPUT_HDMI:
> >> +  connector = &intel_hdmi->attached_connector->base;
> >> +  is_hdmi2_sink = connector->display_info.hdmi.scdc.supported;
> >> +  rgb_qrange_selectable = intel_hdmi->rgb_quant_range_selectable;
> >> +  break;
> >> +
> >> +  case INTEL_OUTPUT_DP:
> >> +  /* We are here means its a LSPCON device, still be paranoid */
> >> +  if (!crtc_state->lspcon_active) {
> >> +  DRM_ERROR("No LSPCON, why am I here ?\n");
> >> +  return;
> >> +  }
> >> +
> >> +  connector = &intel_dp->attached_connector->base;
> >> +  is_hdmi2_sink = connector->display_info.hdmi.scdc.supported;
> >> +  if (crtc_state->ycbcr420)
> >> +  rgb_qrange_limited = true;
> >> +  break;
> >> +
> >> +  default:
> >> +  DRM_ERROR("No other encoder allowed\n");
> >> +  return;
> >> +  }
> >> +
> >> +  ret = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
> >> + adjusted_mode,
> >> + is_hdmi2_sink);
> >> +  if (ret < 0) {
> >> +  DRM_ERROR("couldn't fill AVI infoframe\n");
> >> +  return;
> >> +  }
> >> +
> >> +  ret = drm_hdmi_avi_infoframe_set_colorspace(&frame.avi,
> >> +  adjusted_mode,
> >> +  colorspace);
> >> +  if (ret < 0) {
> >> +  DRM_ERROR("couldn't fill AVI colorspace\n");
> >> +  return;
> >> +  }
> >> +
> >> +  drm_hdmi_avi_infoframe_quant_range(&frame.avi, adjusted_mode,
> >> + rgb_qrange_limited,
> >> + rgb_qrange_selectable);
> >> +
> >> +  intel_write_infoframe(encoder, crtc_state, &frame);
> >> +}
> >> 

Re: [Intel-gfx] [PATCH 20/20] drm/i915: write AVI infoframes for LSPCON

[Sharma, Shashank]

Regards

Shashank


On 7/13/2017 6:25 PM, Ville Syrjälä wrote:

On Thu, Jul 13, 2017 at 06:09:53PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 7/13/2017 5:57 PM, Ville Syrjälä wrote:

On Thu, Jul 13, 2017 at 11:11:53AM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 7/12/2017 10:54 PM, Ville Syrjälä wrote:

On Mon, Jul 10, 2017 at 04:48:48PM +0530, Shashank Sharma wrote:

LSPCON chips can't pick the HDMI AVI infoframes from direct link.
In order to pass AVI infoframes from display controller to LSPCON,
we have to write infoframe packets into vendor specified AUX address.

Also, LSPCON vendors provide AUX offsets, to inform the LSPCON
chip that the AVI IF packets are written, so that the firmware
can pick it up and apply.

This patch adds function to write AVI infoframes for both MCA as
well as Parade Tech LSPCON chips. These two vendors provide different
methods for writing infoframes, so this patch contains two different
functions, one for each.

Seems to me that we should also be checking the receiver cap for the
444->420 conversion support, and enable it in the PROTOCOL_CONVERTER
DPCD register. Or are these LSPCON things even ignoring that part of the
spec?

Yes, LSPCON just needs the YCBCR444 input, and info frames for 420, and
it would take care of
444->420 conversion in FW.

So it snoops the AVI infoframe we write to it to figure out that it has
to do the 444->420 downsampling?

Yes, that's exactly what it does.

Can you add a comment somewhere appropriate to make that clear.
Otherwise people might wonder why we're not enabling the downsampling at
all.

Does LSPCON then not even implement the PROTOCOL_CONVERTER DCPD
registers?

Can you send the spec for this stuff my way? What I have now doesn't
document any DPCD registers.
Actually I also don't have a document/spec which describes this. This is 
kind of knowledge sharing from people who
had design discussions with MCA/PARADE vendors on how to implement 
LSPCON specs and features.
Typically LSPCON firmware parses the AVI IF packets, and does the 
scaling down from 444->420. That's why

we are writing the AVI IF at custom AUX location.

I have added this description in patch 18's text, which talks about the 
steps to get a YCBCR420 output from LSPCON.

It says:

LSPCON chips support YCBCR420 outputs. To be able to get
YCBCR420 output from LSPCON chip, the source should:
- Generate YCBCR444 HDMI output
- Set AVI infoframes for a YCBCR420 output.

And added this small comment in 420_config:
+ /* LSPCON doesn't need scaler for YCBCR420 output */
+ if (config->lspcon_active)
+ return true;
+

But probably I should discreetly mention that LSPCON doesn't need a scalar 
somehow.

- Shashank


- Shashank

Also, its a part of LSPCON specs, that it has
to have 420 output capability.

- Shashank

Cc: Ville Syrjälä 
Cc: Imre Deak 
Signed-off-by: Shashank Sharma 
---
drivers/gpu/drm/i915/intel_ddi.c|   8 ++
drivers/gpu/drm/i915/intel_drv.h|   3 +
drivers/gpu/drm/i915/intel_lspcon.c | 174 

3 files changed, 185 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index f691710..944d9d5 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2068,6 +2068,14 @@ void intel_ddi_set_avi_infoframe(struct drm_encoder 
*encoder,
   rgb_qrange_limited,
   rgb_qrange_selectable);

+	if (crtc_state->lspcon_active) {

+   struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
+
+   /* LSPCON writes infoframes via AUX */
+   lspcon->write_infoframe(encoder, crtc_state, &frame);
+   return;
+   }
+
intel_write_infoframe(encoder, crtc_state, &frame);
}

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h

index fad9a53..3e686d2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1079,6 +1079,9 @@ struct intel_lspcon {
/* AVI IF setup function for LSPCON */
void (*set_infoframes)(struct drm_encoder *encoder,
const struct intel_crtc_state *crtc_state);
+   void (*write_infoframe)(struct drm_encoder *encoder,
+   const struct intel_crtc_state *crtc_state,
+   union hdmi_infoframe *frame);
};

struct intel_digital_port {

diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index 53ddd39..01fddf7 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -31,6 +31,18 @@
#define LSPCON_VENDOR_PARADE_OUI 0x001CF8
#define LSPCON_VENDOR_MCA_OUI 0x0060AD

+/* AUX addresses to write AVI IF into */

+#define LSPCON_MCA_AVI_IF_WRITE_OFFSET 0x5C0
+#define LSPCON_MCA_AVI_IF_CTRL 0x5DF
+#define  LSPCON_MCA_AVI_IF_KICKOFF (1 <

Re: [Intel-gfx] [PATCH 06/20] drm: add helper to validate YCBCR420 modes

[Sharma, Shashank]

On 7/13/2017 6:30 PM, Ville Syrjälä wrote:


I guess then you just need to add the bitmap already in the validation
patch.

An alternative would be just squash the patches, but that seems a bit
drastic, and probably would mix up too many things in one patch.
Ok then, I will introduce this bitmap in the validation patch, and move 
if before.

- Shashank
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 18/20] drm/i915: YCBCR 420 support for LSPCON

[Ville Syrjälä]

On Thu, Jul 13, 2017 at 10:32:00AM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 7/12/2017 10:45 PM, Ville Syrjälä wrote:
> > On Mon, Jul 10, 2017 at 04:48:46PM +0530, Shashank Sharma wrote:
> >> LSPCON chips support YCBCR420 outputs. To be able to get
> >> YCBCR420 output from LSPCON chip, the source should:
> >> - Generate YCBCR444 HDMI output
> >> - Set AVI infoframes for a YCBCR420 output.
> >>
> >> LSPCON FW gets the information from AVI infoframes, and generates
> >> YCBCR420 output from a YCBCR444 input. This patch adds the necessary
> >> changes to drive YCBCR420 output from LSPCON based HDMI output.
> >>
> >> Cc: Ville Syrjälä 
> >> Cc: Imre Deak 
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/i915/intel_display.c | 10 +++---
> >>   drivers/gpu/drm/i915/intel_dp.c  | 16 +++-
> >>   drivers/gpu/drm/i915/intel_drv.h | 20 +---
> >>   drivers/gpu/drm/i915/intel_hdmi.c|  7 +--
> >>   drivers/gpu/drm/i915/intel_lspcon.c  | 17 +
> >>   5 files changed, 61 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index c5ff568..c3c7b31 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -8125,9 +8125,11 @@ static void haswell_set_pipemisc(struct drm_crtc 
> >> *crtc)
> >>val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
> >>   
> >>if (config->ycbcr420) {
> >> -  val |= PIPEMISC_OUTPUT_YCBCR |
> >> -  PIPEMISC_YCBCR420_ENABLE |
> >> -  PIPEMISC_YCBCR420_MODE_BLEND;
> >> +  val |= PIPEMISC_OUTPUT_YCBCR;
> >> +
> >> +  if (!config->lspcon_active)
> >> +  val |= PIPEMISC_YCBCR420_ENABLE |
> >> +  PIPEMISC_YCBCR420_MODE_BLEND;
> >>}
> >>   
> >>I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
> >> @@ -14205,11 +14207,13 @@ static void intel_setup_outputs(struct 
> >> drm_i915_private *dev_priv)
> >> * DDI_BUF_CTL_A or SFUSE_STRAP registers, find another way to
> >> * detect the ports.
> >> */
> >> +
> >>intel_ddi_init(dev_priv, PORT_A);
> >>intel_ddi_init(dev_priv, PORT_B);
> >>intel_ddi_init(dev_priv, PORT_C);
> >>   
> >>intel_dsi_init(dev_priv);
> >> +
> >>} else if (HAS_DDI(dev_priv)) {
> >>int found;
> >>   
> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> >> b/drivers/gpu/drm/i915/intel_dp.c
> >> index 67bc8a7a..1690aa9 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -1614,7 +1614,9 @@ intel_dp_compute_config(struct intel_encoder 
> >> *encoder,
> >>struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> >>struct drm_display_mode *adjusted_mode = 
> >> &pipe_config->base.adjusted_mode;
> >>struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> >> -  enum port port = dp_to_dig_port(intel_dp)->port;
> >> +  struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
> >> +  enum port port = dig_port->port;
> >> +  struct intel_lspcon *lspcon = &dig_port->lspcon;
> >>struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
> >>struct intel_connector *intel_connector = intel_dp->attached_connector;
> >>struct intel_digital_connector_state *intel_conn_state =
> >> @@ -1635,6 +1637,18 @@ intel_dp_compute_config(struct intel_encoder 
> >> *encoder,
> >>common_len = intel_dp_common_len_rate_limit(intel_dp,
> >>intel_dp->max_link_rate);
> >>   
> >> +  /* LSPCON needs special handling to drive YCBCR420 outputs */
> >> +  if (lspcon->active) {
> >> +  struct drm_connector *connector = &intel_connector->base;
> >> +  int clock_8bpc = pipe_config->base.adjusted_mode.crtc_clock;
> >> +  int clock_12bpc = clock_8bpc * 3 / 2;
> >> +
> >> +  pipe_config->lspcon_active = true;
> >> +  pipe_config->ycbcr420 = lspcon_ycbcr420_config(connector,
> >> +   pipe_config, &clock_12bpc,
> >> +   &clock_8bpc);
> > All this clock stuff here seems pointless. So I'd just replace this
> > stuff with the straightforward 'pipe_config->ycbcr420 = mode_needs_420';
> pipe_config->ycbcr_420 = true means we have committed into state that we 
> can support this mode in YCBCR420.
> But for that, we need to check connector->ycbcr420_allowed too.
> Also, when the mode is 420, we need to half the clock_8bpc and clock_12bpc.

We don't use those clocks with DP. You've just added them here because
the function call requires them as parameters. 

Also the function call is actually doing the wrong thing for DP
by halving 

Re: [Intel-gfx] [PATCH 08/20] drm: set output colorspace in AVI infoframe

[Sharma, Shashank]

On 7/13/2017 6:33 PM, Ville Syrjälä wrote:


If the mode requires pixel repeat to meet the minimum clock requirement,
then we can't just not do pixel repeat. That would violate the spec in
other ways, and IIRC we couldn't even generate a low enough clock for
it.
The YCBCR420 modes I am seeing on several EDIDs, are 4K modes, and they 
typically need a clock of

594/2 = 297Mhz, is that too low ?
- Shashank
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 18/20] drm/i915: YCBCR 420 support for LSPCON

[Sharma, Shashank]

On 7/13/2017 6:43 PM, Ville Syrjälä wrote:


We don't use those clocks with DP. You've just added them here because
the function call requires them as parameters.

Also the function call is actually doing the wrong thing for DP
by halving port_clock.
Ah, missed that part. Thanks for letting me know, I will modify this 
accordingly.

- Shashank
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 20/20] drm/i915: write AVI infoframes for LSPCON

[Ville Syrjälä]

On Thu, Jul 13, 2017 at 06:40:36PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 7/13/2017 6:25 PM, Ville Syrjälä wrote:
> > On Thu, Jul 13, 2017 at 06:09:53PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 7/13/2017 5:57 PM, Ville Syrjälä wrote:
> >>> On Thu, Jul 13, 2017 at 11:11:53AM +0530, Sharma, Shashank wrote:
>  Regards
> 
>  Shashank
> 
> 
>  On 7/12/2017 10:54 PM, Ville Syrjälä wrote:
> > On Mon, Jul 10, 2017 at 04:48:48PM +0530, Shashank Sharma wrote:
> >> LSPCON chips can't pick the HDMI AVI infoframes from direct link.
> >> In order to pass AVI infoframes from display controller to LSPCON,
> >> we have to write infoframe packets into vendor specified AUX address.
> >>
> >> Also, LSPCON vendors provide AUX offsets, to inform the LSPCON
> >> chip that the AVI IF packets are written, so that the firmware
> >> can pick it up and apply.
> >>
> >> This patch adds function to write AVI infoframes for both MCA as
> >> well as Parade Tech LSPCON chips. These two vendors provide different
> >> methods for writing infoframes, so this patch contains two different
> >> functions, one for each.
> > Seems to me that we should also be checking the receiver cap for the
> > 444->420 conversion support, and enable it in the PROTOCOL_CONVERTER
> > DPCD register. Or are these LSPCON things even ignoring that part of the
> > spec?
>  Yes, LSPCON just needs the YCBCR444 input, and info frames for 420, and
>  it would take care of
>  444->420 conversion in FW.
> >>> So it snoops the AVI infoframe we write to it to figure out that it has
> >>> to do the 444->420 downsampling?
> >> Yes, that's exactly what it does.
> > Can you add a comment somewhere appropriate to make that clear.
> > Otherwise people might wonder why we're not enabling the downsampling at
> > all.
> >
> > Does LSPCON then not even implement the PROTOCOL_CONVERTER DCPD
> > registers?
> >
> > Can you send the spec for this stuff my way? What I have now doesn't
> > document any DPCD registers.
> Actually I also don't have a document/spec which describes this. This is 
> kind of knowledge sharing from people who
> had design discussions with MCA/PARADE vendors on how to implement 
> LSPCON specs and features.

So there are no specs at all? That's no way to do things. As is, no
one can actually review this code without experimenting with the
hardware themselves.

> Typically LSPCON firmware parses the AVI IF packets, and does the 
> scaling down from 444->420. That's why
> we are writing the AVI IF at custom AUX location.
> 
> I have added this description in patch 18's text, which talks about the 
> steps to get a YCBCR420 output from LSPCON.
> It says:
> 
> LSPCON chips support YCBCR420 outputs. To be able to get
> YCBCR420 output from LSPCON chip, the source should:
> - Generate YCBCR444 HDMI output
> - Set AVI infoframes for a YCBCR420 output.
> 
> And added this small comment in 420_config:
> + /* LSPCON doesn't need scaler for YCBCR420 output */
> + if (config->lspcon_active)
> + return true;
> +
> 
> But probably I should discreetly mention that LSPCON doesn't need a scalar 
> somehow.

Yeah something like this perhaps:
"We send 4:4:4 data to LSPCON which performs the 4:4:4->4:2:0
 downsampling or us, hence we don't need a pipe scaler."

> 
> - Shashank
> 
> >> - Shashank
>  Also, its a part of LSPCON specs, that it has
>  to have 420 output capability.
> 
>  - Shashank
> >> Cc: Ville Syrjälä 
> >> Cc: Imre Deak 
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >> drivers/gpu/drm/i915/intel_ddi.c|   8 ++
> >> drivers/gpu/drm/i915/intel_drv.h|   3 +
> >> drivers/gpu/drm/i915/intel_lspcon.c | 174 
> >> 
> >> 3 files changed, 185 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> >> b/drivers/gpu/drm/i915/intel_ddi.c
> >> index f691710..944d9d5 100644
> >> --- a/drivers/gpu/drm/i915/intel_ddi.c
> >> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> >> @@ -2068,6 +2068,14 @@ void intel_ddi_set_avi_infoframe(struct 
> >> drm_encoder *encoder,
> >>   rgb_qrange_limited,
> >>   rgb_qrange_selectable);
> >> 
> >> +  if (crtc_state->lspcon_active) {
> >> +  struct intel_lspcon *lspcon = 
> >> enc_to_intel_lspcon(encoder);
> >> +
> >> +  /* LSPCON writes infoframes via AUX */
> >> +  lspcon->write_infoframe(encoder, crtc_state, &frame);
> >> +  return;
> >> +  }
> >> +
> >>intel_write_infoframe(encoder, crtc_state, &frame);
> >> }
> >> 
> >> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> >> b/drivers/gpu/drm/i915/intel_drv.h
> >

Re: [Intel-gfx] [PATCH 20/20] drm/i915: write AVI infoframes for LSPCON

[Sharma, Shashank]

On 7/13/2017 6:49 PM, Ville Syrjälä wrote:


Yeah something like this perhaps:
"We send 4:4:4 data to LSPCON which performs the 4:4:4->4:2:0
  downsampling or us, hence we don't need a pipe scaler."

Seems good ! Will add this.
- Shashank
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/20] drm/i915: add config function for YCBCR420 outputs

[Ville Syrjälä]

On Thu, Jul 13, 2017 at 06:31:25PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 7/13/2017 6:23 PM, Ville Syrjälä wrote:
> > On Thu, Jul 13, 2017 at 10:56:06AM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 7/12/2017 10:47 PM, Ville Syrjälä wrote:
> >>> On Mon, Jul 10, 2017 at 04:48:38PM +0530, Shashank Sharma wrote:
>  This patch checks encoder level support for YCBCR420 outputs.
>  The logic goes as simple as this:
>  If the input mode is YCBCR420-only mode: prepare HDMI for
>  YCBCR420 output, else continue with RGB output mode.
> 
>  It checks if the mode is YCBCR420 and source can support this
>  output then it marks the ycbcr_420 output indicator into crtc
>  state, for further staging in driver.
> 
>  V2: Split the patch into two, kept helper functions in DRM layer.
>  V3: Changed the compute_config function based on new DRM API.
>  V4: Rebase
>  V5: Rebase
>  V6: Check and handle YCBCR420-only modes, discard the property
>    based approach (Ville)
> 
>  Signed-off-by: Shashank Sharma 
>  ---
> drivers/gpu/drm/i915/intel_display.c |  1 +
> drivers/gpu/drm/i915/intel_drv.h |  3 +++
> drivers/gpu/drm/i915/intel_hdmi.c| 42 
>  +---
> 3 files changed, 43 insertions(+), 3 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/i915/intel_display.c 
>  b/drivers/gpu/drm/i915/intel_display.c
>  index 4e03ca6..01900e1 100644
>  --- a/drivers/gpu/drm/i915/intel_display.c
>  +++ b/drivers/gpu/drm/i915/intel_display.c
>  @@ -11930,6 +11930,7 @@ intel_pipe_config_compare(struct 
>  drm_i915_private *dev_priv,
>   PIPE_CONF_CHECK_I(hdmi_scrambling);
>   PIPE_CONF_CHECK_I(hdmi_high_tmds_clock_ratio);
>   PIPE_CONF_CHECK_I(has_infoframe);
>  +PIPE_CONF_CHECK_I(ycbcr420);
> 
>   PIPE_CONF_CHECK_I(has_audio);
> 
>  diff --git a/drivers/gpu/drm/i915/intel_drv.h 
>  b/drivers/gpu/drm/i915/intel_drv.h
>  index d17a324..592243b 100644
>  --- a/drivers/gpu/drm/i915/intel_drv.h
>  +++ b/drivers/gpu/drm/i915/intel_drv.h
>  @@ -780,6 +780,9 @@ struct intel_crtc_state {
> 
>   /* HDMI High TMDS char rate ratio */
>   bool hdmi_high_tmds_clock_ratio;
>  +
>  +/* HDMI output type */
>  +bool ycbcr420;
> };
> 
> struct intel_crtc {
>  diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
>  b/drivers/gpu/drm/i915/intel_hdmi.c
>  index cc0d100..276d916 100644
>  --- a/drivers/gpu/drm/i915/intel_hdmi.c
>  +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>  @@ -1305,7 +1305,8 @@ intel_hdmi_mode_valid(struct drm_connector 
>  *connector,
>   return status;
> }
> 
>  -static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state)
>  +static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state,
>  +bool output_ycbcr420)
> >>> You alreayd have the crtc state, so no need to pass that stuff
> >>> separately.
> >> Ah, this was dumb, thanks !
> {
>   struct drm_i915_private *dev_priv =
>   to_i915(crtc_state->base.crtc->dev);
>  @@ -1330,6 +1331,13 @@ static bool hdmi_12bpc_possible(struct 
>  intel_crtc_state *crtc_state)
>   if (connector_state->crtc != crtc_state->base.crtc)
>   continue;
> 
>  +if (output_ycbcr420) {
>  +const struct drm_hdmi_info *hdmi = &info->hdmi;
>  +
>  +if (!(hdmi->y420_dc_modes & 
>  DRM_EDID_YCBCR420_DC_36))
>  +return false;
>  +}
>  +
> >>> else?
> >> Oops, needs an else { break;}
> > I was thinking 'else if ...'
> Do we need else if for 12 BPC case, I was thinking of:
> if (!hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_36)
> /* 12 BPC Y420 not possible */
> return false;
> else
>/* output is going to be 420, and 12BPC is possible, so break the 
> loop */
>break;
> 
> This will also allow the code to go through the WAR Added below.

We don't want breaks in the loop. It's meant to go through all the
connectors for the crtc. Granted on modern platforms there can only be
one, but IMO assuming that just makes the whole thing look confusing.
It's much clearer IMO if we do 

if (420) {
check 420 dc modes;
} else {
check 444 dc modes;
}

> - Shashank
> >
> >> - Shashank
>   if ((info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36) == 
>  0)
>   return false;
>   }
>  @@ -1342,6 +1350,25 @@ static bool hdmi_12bpc_possible(struct 
>  intel_crtc_state *crtc_s

Re: [Intel-gfx] [PATCH 10/20] drm/i915: add config function for YCBCR420 outputs

[Sharma, Shashank]

On 7/13/2017 6:56 PM, Ville Syrjälä wrote:


We don't want breaks in the loop. It's meant to go through all the
connectors for the crtc. Granted on modern platforms there can only be
one, but IMO assuming that just makes the whole thing look confusing.
It's much clearer IMO if we do

if (420) {
check 420 dc modes;
} else {
check 444 dc modes;
}
I dint want to add another loop for the 420 stuff, hence was reusing the 
existing loop.

Now, my steps were:
- If there is a CRTC match, I got the right CRTC.
- On this CRTC, if YCBCR420 output is enabled, I should just check 
DRM_EDID_YCBCR420_DC_36
   for 420_12BPC, so if it supports DRM_EDID_YCBCR420_DC_36 say yes, 
else no.
- But I also want to go through the WAR condition below, added for GLK. 
So I can't return from here.


Do you prefer me adding another loop just for YCBCR420 ?

- Shashank
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 15/16] drm/nouveau: Convert nouveau to use new iterator macros

[Maarten Lankhorst]

Op 13-07-17 om 14:33 schreef Daniel Vetter:
> On Wed, Jul 12, 2017 at 10:13:43AM +0200, Maarten Lankhorst wrote:
>> Use the new atomic iterator macros, the old ones are about to be
>> removed. With the new macros, it's more easy to get old and new state so
>> get them from the macros instead of from obj->state.
>>
>> Signed-off-by: Maarten Lankhorst 
>> Cc: Ben Skeggs 
>> Cc: nouv...@lists.freedesktop.org
>> ---
>>  drivers/gpu/drm/nouveau/nv50_display.c | 71 
>> +-
>>  1 file changed, 36 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
>> b/drivers/gpu/drm/nouveau/nv50_display.c
>> index 42a85c14aea0..b1ce8f1f58dc 100644
>> --- a/drivers/gpu/drm/nouveau/nv50_display.c
>> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
>> @@ -2103,7 +2103,7 @@ nv50_head_atomic_check(struct drm_crtc *crtc, struct 
>> drm_crtc_state *state)
>>  
>>  NV_ATOMIC(drm, "%s atomic_check %d\n", crtc->name, asyh->state.active);
>>  if (asyh->state.active) {
>> -for_each_connector_in_state(asyh->state.state, conn, conns, i) {
>> +for_each_new_connector_in_state(asyh->state.state, conn, conns, 
>> i) {
>>  if (conns->crtc == crtc) {
>>  asyc = nouveau_conn_atom(conns);
>>  break;
>> @@ -3904,9 +3904,9 @@ static void
>>  nv50_disp_atomic_commit_tail(struct drm_atomic_state *state)
>>  {
>>  struct drm_device *dev = state->dev;
>> -struct drm_crtc_state *crtc_state;
>> +struct drm_crtc_state *new_crtc_state;
>>  struct drm_crtc *crtc;
>> -struct drm_plane_state *plane_state;
>> +struct drm_plane_state *new_plane_state;
>>  struct drm_plane *plane;
>>  struct nouveau_drm *drm = nouveau_drm(dev);
>>  struct nv50_disp *disp = nv50_disp(dev);
>> @@ -3925,8 +3925,8 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
>> *state)
>>  mutex_lock(&disp->mutex);
>>  
>>  /* Disable head(s). */
>> -for_each_crtc_in_state(state, crtc, crtc_state, i) {
>> -struct nv50_head_atom *asyh = nv50_head_atom(crtc->state);
>> +for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
>> +struct nv50_head_atom *asyh = nv50_head_atom(new_crtc_state);
>>  struct nv50_head *head = nv50_head(crtc);
>>  
>>  NV_ATOMIC(drm, "%s: clr %04x (set %04x)\n", crtc->name,
>> @@ -3939,8 +3939,8 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
>> *state)
>>  }
>>  
>>  /* Disable plane(s). */
>> -for_each_plane_in_state(state, plane, plane_state, i) {
>> -struct nv50_wndw_atom *asyw = nv50_wndw_atom(plane->state);
>> +for_each_new_plane_in_state(state, plane, new_plane_state, i) {
>> +struct nv50_wndw_atom *asyw = nv50_wndw_atom(new_plane_state);
>>  struct nv50_wndw *wndw = nv50_wndw(plane);
>>  
>>  NV_ATOMIC(drm, "%s: clr %02x (set %02x)\n", plane->name,
>> @@ -4005,8 +4005,8 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
>> *state)
>>  }
>>  
>>  /* Update head(s). */
>> -for_each_crtc_in_state(state, crtc, crtc_state, i) {
>> -struct nv50_head_atom *asyh = nv50_head_atom(crtc->state);
>> +for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
>> +struct nv50_head_atom *asyh = nv50_head_atom(new_crtc_state);
>>  struct nv50_head *head = nv50_head(crtc);
>>  
>>  NV_ATOMIC(drm, "%s: set %04x (clr %04x)\n", crtc->name,
>> @@ -4018,14 +4018,14 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
>> *state)
>>  }
>>  }
>>  
>> -for_each_crtc_in_state(state, crtc, crtc_state, i) {
>> -if (crtc->state->event)
>> +for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
>> +if (new_crtc_state->event)
>>  drm_crtc_vblank_get(crtc);
>>  }
>>  
>>  /* Update plane(s). */
>> -for_each_plane_in_state(state, plane, plane_state, i) {
>> -struct nv50_wndw_atom *asyw = nv50_wndw_atom(plane->state);
>> +for_each_new_plane_in_state(state, plane, new_plane_state, i) {
>> +struct nv50_wndw_atom *asyw = nv50_wndw_atom(new_plane_state);
>>  struct nv50_wndw *wndw = nv50_wndw(plane);
>>  
>>  NV_ATOMIC(drm, "%s: set %02x (clr %02x)\n", plane->name,
>> @@ -4055,23 +4055,23 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
>> *state)
>>  mutex_unlock(&disp->mutex);
>>  
>>  /* Wait for HW to signal completion. */
>> -for_each_plane_in_state(state, plane, plane_state, i) {
>> -struct nv50_wndw_atom *asyw = nv50_wndw_atom(plane->state);
>> +for_each_new_plane_in_state(state, plane, new_plane_state, i) {
>> +struct nv50_wndw_atom *asyw = nv50_wndw_atom(new_plane_state);
>>  struct nv50_wndw *wndw = nv50_wndw(plane);
>>  int ret = nv50_wndw_wait_ar

Re: [Intel-gfx] [PATCH] fbdev: Nuke FBINFO_MODULE

[Bartlomiej Zolnierkiewicz]

On Wednesday, July 12, 2017 05:07:42 PM Daniel Vetter wrote:
> On Wed, Jul 12, 2017 at 2:54 PM, Bartlomiej Zolnierkiewicz
>  wrote:
> > On Wednesday, July 12, 2017 02:42:14 PM Daniel Vetter wrote:
> >> On Wed, Jul 12, 2017 at 12:41:34PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >> > On Tuesday, July 11, 2017 04:52:19 PM Daniel Vetter wrote:
> >> > > Instead check info->ops->owner, which amounts to the same.
> >> > >
> >> > > Spotted because I want to remove the pile of broken and cargo-culted
> >> > > fb_info->flags assignments in drm drivers.
> >> > >
> >> > > v2: Fixup matrox (reported by kbuild). Also nuke FBINFO_FLAG_* defines
> >> > > that I've failed to spot.
> >> > >
> >> > > v3: Don't nuke FBINFO_FLAG_DEFAULT, that's used all over the place.
> >> > >
> >> > > Cc: Bartlomiej Zolnierkiewicz 
> >> > > Cc: linux-fb...@vger.kernel.org
> >> > > Signed-off-by: Daniel Vetter 
> >> >
> >> > Acked-by: Bartlomiej Zolnierkiewicz 
> >>
> >> Do you plan to pick these two patches up yourself, or do you expect me to
> >> merge them?
> >
> > Since the original patchset contained DRM changes (two last patches)
> > depending on fbdev changes (two first patches, the patch being discussed
> > was the second one) I assumed that you would like to take them all
> > through DRM tree. If this is not what is preferred, please tell me.
> 
> There's no direct depency between 1&2 and 3&4, the only effect of
> merging them through separate trees is that the bootup logo might not
> show up when it's expected, until the trees are merged together. We
> could merge them through separate trees if you prefer that (I forgot
> to mention that in the cover letter), but I'm fine with putting them
> all into drm-misc with your ack for 4.14.
> 
> Whatever you prefer, I don't mind either way.

Then I will merge patches 1&2 for v4.14 through fbdev tree (there are
some other changes pending touching fbdev core and I would like to avoid
conflicts between fbdev & drm-misc trees). Thanks!

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/20] drm/i915: add config function for YCBCR420 outputs

[Ville Syrjälä]

On Thu, Jul 13, 2017 at 07:05:12PM +0530, Sharma, Shashank wrote:
> On 7/13/2017 6:56 PM, Ville Syrjälä wrote:
> 
> > We don't want breaks in the loop. It's meant to go through all the
> > connectors for the crtc. Granted on modern platforms there can only be
> > one, but IMO assuming that just makes the whole thing look confusing.
> > It's much clearer IMO if we do
> >
> > if (420) {
> > check 420 dc modes;
> > } else {
> > check 444 dc modes;
> > }
> I dint want to add another loop for the 420 stuff, hence was reusing the 
> existing loop.

What I mean is

 for_each() {
...
+   if (420) {
+   if (!420_dc)
+   return false;
+   } else {
if (!444_dc)
return false;
+   }
 }

> Now, my steps were:
> - If there is a CRTC match, I got the right CRTC.
> - On this CRTC, if YCBCR420 output is enabled, I should just check 
> DRM_EDID_YCBCR420_DC_36
> for 420_12BPC, so if it supports DRM_EDID_YCBCR420_DC_36 say yes, 
> else no.
> - But I also want to go through the WAR condition below, added for GLK. 
> So I can't return from here.
> 
> Do you prefer me adding another loop just for YCBCR420 ?
> 
> - Shashank

-- 
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 10/20] drm/i915: add config function for YCBCR420 outputs

[Sharma, Shashank]

On 7/13/2017 7:40 PM, Ville Syrjälä wrote:


What I mean is

  for_each() {
...
+   if (420) {
+   if (!420_dc)
+   return false;
+   } else {
if (!444_dc)
return false;
+   }
  }

Got it, Thanks !
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/execlists: Read the context-status HEAD from the HWSP

[Chris Wilson]

Quoting Chris Wilson (2017-07-13 11:27:06)
> The engine also provides a mirror of the CSB write pointer in the HWSP,
> but not of our read pointer. To take advantage of this we need to
> remember where we read up to on the last interrupt and continue off from
> there. This poses a problem following a reset, as we don't know where
> the hw will start writing from, and due to the use of power contexts we
> cannot perform that query during the reset itself. So we continue the
> current modus operandi of delaying the first read of the context-status
> read/write pointers until after the first interrupt. With this we should
> now have eliminated all uncached mmio reads in handling the
> context-status interrupt, though we still have the uncached mmio writes
> for submitting new work, and many uncached mmio reads in the global
> interrupt handler itself. Still a step in the right direction towards
> reducing our resubmit latency, although it appears lost in the noise!

It is also worth noting that Broxton seems to handle per-engine resets
better when using the HWSP than CSB mmio. Too early to say for sure,
needs a few days to be sure the error doesn't occur.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

[Matthew Auld]

On 13 July 2017 at 12:22, Lionel Landwerlin
 wrote:
> From: Matthew Auld 
>
> The motivation behind this new interface is expose at runtime the
> creation of new OA configs which can be used as part of the i915 perf
> open interface. This will enable the kernel to learn new configs which
> may be experimental, or otherwise not part of the core set currently
> available through the i915 perf interface.
>
> This will relieve the kernel from holding all the possible configs, so
> we can leave only the test configs here.
>
> Signed-off-by: Matthew Auld 
> Signed-off-by: Lionel Landwerlin 
> Signed-off-by: Andrzej Datczuk 
> ---
>  drivers/gpu/drm/i915/i915_drv.c  |   2 +
>  drivers/gpu/drm/i915/i915_drv.h  |  25 +++
>  drivers/gpu/drm/i915/i915_perf.c | 351 
> ++-
>  drivers/gpu/drm/i915/i915_reg.h  |   2 +
>  include/uapi/drm/i915_drm.h  |  24 +++
>  5 files changed, 403 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index d310d8245dca..a3d339670ec1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2730,6 +2730,8 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
> DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
> i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
> i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
> DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, 
> i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
>  };
>
>  static struct drm_driver driver = {
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 0c45a89d165e..3d62276d9fad 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2037,6 +2037,25 @@ struct i915_perf_stream {
>   */
>  struct i915_oa_ops {
> /**
> +* @is_valid_b_counter_reg: Validates register's address for
> +* programming boolean counters for a particular platform.
> +*/
> +   bool (*is_valid_b_counter_reg)(struct drm_i915_private *dev_priv,
> +  u32 addr);
> +
> +   /**
> +* @is_valid_mux_reg: Validates register's address for programming mux
> +* for a particular platform.
> +*/
> +   bool (*is_valid_mux_reg)(struct drm_i915_private *dev_priv, u32 addr);
> +
> +   /**
> +* @is_valid_flex_reg: Validates register's address for programming
> +* flex EU filtering for a particular platform.
> +*/
> +   bool (*is_valid_flex_reg)(struct drm_i915_private *dev_priv, u32 
> addr);
> +
> +   /**
>  * @init_oa_buffer: Resets the head and tail pointers of the
>  * circular buffer for periodic OA reports.
>  *
> @@ -2427,6 +2446,8 @@ struct drm_i915_private {
> struct mutex lock;
> struct list_head streams;
>
> +   struct idr metrics_idr;
> +
> struct {
> struct i915_perf_stream *exclusive_stream;
>
> @@ -3595,6 +3616,10 @@ i915_gem_context_lookup_timeline(struct 
> i915_gem_context *ctx,
>
>  int i915_perf_open_ioctl(struct drm_device *dev, void *data,
>  struct drm_file *file);
> +int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
> +  struct drm_file *file);
> +int i915_perf_remove_config_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file);
>  void i915_oa_init_reg_state(struct intel_engine_cs *engine,
> struct i915_gem_context *ctx,
> uint32_t *reg_state);
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index d4647b3d8119..5f3d544a93cf 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -2652,7 +2652,7 @@ static struct i915_oa_config *get_oa_config(struct 
> drm_i915_private *dev_priv,
> if (metrics_set == 1)
> return &dev_priv->perf.oa.test_config;
>
> -   return NULL;
> +   return idr_find(&dev_priv->perf.metrics_idr, metrics_set);
>  }
>
>  /**
> @@ -2913,6 +2913,7 @@ void i915_perf_register(struct drm_i915_private 
> *dev_priv)
>  &dev_priv->perf.oa.test_config.sysfs_metric);
> if (ret)
> goto sysfs_error;
> +
> goto exit;
>
>  sysfs_error:
> @@ -2944,6 +2945,333 @@ void i915_perf_unregister(struct drm_i915_private 
> *dev_priv)
> dev_priv->perf.metrics_kobj = NULL;
>  }
>
> +static bool gen8_is_valid_flex_addr(struct drm_i915_private *dev_priv, u32 
> addr)
> +{
> +   static const 

Re: [Intel-gfx] [PATCH 1/4] fbcon: Make fbcon a built-time depency for fbdev

[Sean Paul]

On Thu, Jul 06, 2017 at 02:57:32PM +0200, Daniel Vetter wrote:



> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Daniel Vetter 

Just 2 nits, code looks good.

Reviewed-by: Sean Paul 

> ---
> v2: Switch to building fbcon code into fb.ko right away because the
> cheap trick leads to a module depency loop.
> ---
>  drivers/video/console/Kconfig|  2 +-
>  drivers/video/console/Makefile   |  8 
>  drivers/video/fbdev/core/Makefile| 11 +++
>  drivers/video/{console => fbdev/core}/bitblit.c  |  4 
>  drivers/video/{console => fbdev/core}/fbcon.c| 13 +++--
>  drivers/video/{console => fbdev/core}/fbcon.h|  0
>  drivers/video/{console => fbdev/core}/fbcon_ccw.c|  4 
>  drivers/video/{console => fbdev/core}/fbcon_cw.c |  4 
>  drivers/video/{console => fbdev/core}/fbcon_rotate.c |  4 
>  drivers/video/{console => fbdev/core}/fbcon_rotate.h |  0
>  drivers/video/{console => fbdev/core}/fbcon_ud.c |  4 
>  drivers/video/fbdev/core/fbmem.c |  6 ++
>  drivers/video/{console => fbdev/core}/softcursor.c   |  4 
>  drivers/video/{console => fbdev/core}/tileblit.c |  5 -
>  include/linux/fbcon.h| 12 
>  15 files changed, 33 insertions(+), 48 deletions(-)
>  rename drivers/video/{console => fbdev/core}/bitblit.c (98%)
>  rename drivers/video/{console => fbdev/core}/fbcon.c (99%)
>  rename drivers/video/{console => fbdev/core}/fbcon.h (100%)
>  rename drivers/video/{console => fbdev/core}/fbcon_ccw.c (98%)
>  rename drivers/video/{console => fbdev/core}/fbcon_cw.c (98%)
>  rename drivers/video/{console => fbdev/core}/fbcon_rotate.c (95%)
>  rename drivers/video/{console => fbdev/core}/fbcon_rotate.h (100%)
>  rename drivers/video/{console => fbdev/core}/fbcon_ud.c (98%)
>  rename drivers/video/{console => fbdev/core}/softcursor.c (93%)
>  rename drivers/video/{console => fbdev/core}/tileblit.c (96%)
>  create mode 100644 include/linux/fbcon.h
> 
> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
> index 2111d06f8c81..7f1f1fbcef9e 100644
> --- a/drivers/video/console/Kconfig
> +++ b/drivers/video/console/Kconfig
> @@ -117,7 +117,7 @@ config DUMMY_CONSOLE_ROWS
>Select 25 if you use a 640x480 resolution by default.
>  
>  config FRAMEBUFFER_CONSOLE
> - tristate "Framebuffer Console support"
> + bool "Framebuffer Console support"
>   depends on FB && !UML
>   select VT_HW_CONSOLE_BINDING
>   select CRC32
> diff --git a/drivers/video/console/Makefile b/drivers/video/console/Makefile
> index 43bfa485db96..eb2cbec52643 100644
> --- a/drivers/video/console/Makefile
> +++ b/drivers/video/console/Makefile
> @@ -7,13 +7,5 @@ obj-$(CONFIG_SGI_NEWPORT_CONSOLE) += newport_con.o
>  obj-$(CONFIG_STI_CONSOLE) += sticon.o sticore.o
>  obj-$(CONFIG_VGA_CONSOLE) += vgacon.o
>  obj-$(CONFIG_MDA_CONSOLE) += mdacon.o
> -obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += fbcon.o bitblit.o softcursor.o
> -ifeq ($(CONFIG_FB_TILEBLITTING),y)
> -obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += tileblit.o
> -endif
> -ifeq ($(CONFIG_FRAMEBUFFER_CONSOLE_ROTATION),y)
> -obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += fbcon_rotate.o fbcon_cw.o 
> fbcon_ud.o \
> - fbcon_ccw.o
> -endif
>  
>  obj-$(CONFIG_FB_STI)  += sticore.o
> diff --git a/drivers/video/fbdev/core/Makefile 
> b/drivers/video/fbdev/core/Makefile
> index 9e3ddf225393..0214b863ac3f 100644
> --- a/drivers/video/fbdev/core/Makefile
> +++ b/drivers/video/fbdev/core/Makefile
> @@ -4,6 +4,17 @@ obj-$(CONFIG_FB)  += fb.o
>  fb-y  := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
>   modedb.o fbcvt.o
>  fb-$(CONFIG_FB_DEFERRED_IO)   += fb_defio.o
> +
> +ifeq ($(CONFIG_FRAMEBUFFER_CONSOLE),y)
> +fb-y   += fbcon.o bitblit.o softcursor.o

fb-$(CONFIG_FRAMEBUFFER_CONSOLE) ?

> +ifeq ($(CONFIG_FB_TILEBLITTING),y)
> +fb-y   += tileblit.o
> +endif
> +ifeq ($(CONFIG_FRAMEBUFFER_CONSOLE_ROTATION),y)
> +fb-y   += fbcon_rotate.o fbcon_cw.o fbcon_ud.o \
> +  fbcon_ccw.o
> +endif
> +endif
>  fb-objs   := $(fb-y)
>  
>  obj-$(CONFIG_FB_CFB_FILLRECT)  += cfbfillrect.o



> diff --git a/include/linux/fbcon.h b/include/linux/fbcon.h
> new file mode 100644
> index ..0fac6305d51c
> --- /dev/null
> +++ b/include/linux/fbcon.h

IANAL, but it seems like you're missing some GPL legalese here?

Sean

> @@ -0,0 +1,12 @@
> +#ifndef _LINUX_FBCON_H
> +#define _LINUX_FBCON_H
> +
> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE
> +void __init fb_console_init(void);
> +void __exit fb_console_exit(void);
> +#else
> +static void fb_console_init(void) {}
> +static void fb_console_exit(void) {}
> +#endif
> +

Re: [Intel-gfx] [PATCH] fbdev: Nuke FBINFO_MODULE

[Sean Paul]

On Tue, Jul 11, 2017 at 04:52:19PM +0200, Daniel Vetter wrote:
> Instead check info->ops->owner, which amounts to the same.
> 
> Spotted because I want to remove the pile of broken and cargo-culted
> fb_info->flags assignments in drm drivers.
> 
> v2: Fixup matrox (reported by kbuild). Also nuke FBINFO_FLAG_* defines
> that I've failed to spot.
> 
> v3: Don't nuke FBINFO_FLAG_DEFAULT, that's used all over the place.
> 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Daniel Vetter 

Reviewed-by: Sean Paul 

> ---
>  drivers/video/fbdev/core/fbcon.c   |  2 +-
>  drivers/video/fbdev/core/fbmem.c   |  4 ++--
>  drivers/video/fbdev/matrox/matroxfb_base.c |  4 +---
>  include/linux/fb.h | 10 +-
>  4 files changed, 5 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/video/fbdev/core/fbcon.c 
> b/drivers/video/fbdev/core/fbcon.c
> index 86b3bcbd01a8..431a1533a2fe 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -564,7 +564,7 @@ static void fbcon_prepare_logo(struct vc_data *vc, struct 
> fb_info *info,
>   unsigned short *save = NULL, *r, *q;
>   int logo_height;
>  
> - if (info->flags & FBINFO_MODULE) {
> + if (info->fbops->owner) {
>   logo_shown = FBCON_LOGO_DONTSHOW;
>   return;
>   }
> diff --git a/drivers/video/fbdev/core/fbmem.c 
> b/drivers/video/fbdev/core/fbmem.c
> index 283d57cf8526..2636f192e8c9 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -463,7 +463,7 @@ static int fb_show_logo_line(struct fb_info *info, int 
> rotate,
>  
>   /* Return if the frame buffer is not mapped or suspended */
>   if (logo == NULL || info->state != FBINFO_STATE_RUNNING ||
> - info->flags & FBINFO_MODULE)
> + info->fbops->owner)
>   return 0;
>  
>   image.depth = 8;
> @@ -601,7 +601,7 @@ int fb_prepare_logo(struct fb_info *info, int rotate)
>   memset(&fb_logo, 0, sizeof(struct logo_data));
>  
>   if (info->flags & FBINFO_MISC_TILEBLITTING ||
> - info->flags & FBINFO_MODULE)
> + info->fbops->owner)
>   return 0;
>  
>   if (info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
> diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c 
> b/drivers/video/fbdev/matrox/matroxfb_base.c
> index 11eb094396ae..15b412b4b783 100644
> --- a/drivers/video/fbdev/matrox/matroxfb_base.c
> +++ b/drivers/video/fbdev/matrox/matroxfb_base.c
> @@ -1794,9 +1794,7 @@ static int initMatrox2(struct matrox_fb_info *minfo, 
> struct board *b)
>   minfo->fbops = matroxfb_ops;
>   minfo->fbcon.fbops = &minfo->fbops;
>   minfo->fbcon.pseudo_palette = minfo->cmap;
> - /* after __init time we are like module... no logo */
> - minfo->fbcon.flags = hotplug ? FBINFO_FLAG_MODULE : FBINFO_FLAG_DEFAULT;
> - minfo->fbcon.flags |= FBINFO_PARTIAL_PAN_OK |/* Prefer panning for 
> scroll under MC viewer/edit */
> + minfo->fbcon.flags = FBINFO_PARTIAL_PAN_OK | /* Prefer panning for 
> scroll under MC viewer/edit */
> FBINFO_HWACCEL_COPYAREA |  /* We have 
> hw-assisted bmove */
> FBINFO_HWACCEL_FILLRECT |  /* And 
> fillrect */
> FBINFO_HWACCEL_IMAGEBLIT | /* And 
> imageblit */
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index a964d076b4dc..f4386b0ccf40 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -400,7 +400,7 @@ struct fb_tile_ops {
>  #endif /* CONFIG_FB_TILEBLITTING */
>  
>  /* FBINFO_* = fb_info.flags bit flags */
> -#define FBINFO_MODULE0x0001  /* Low-level driver is a module 
> */
> +#define FBINFO_DEFAULT   0
>  #define FBINFO_HWACCEL_DISABLED  0x0002
>   /* When FBINFO_HWACCEL_DISABLED is set:
>*  Hardware acceleration is turned off.  Software implementations
> @@ -533,14 +533,6 @@ static inline struct apertures_struct 
> *alloc_apertures(unsigned int max_num) {
>   return a;
>  }
>  
> -#ifdef MODULE
> -#define FBINFO_DEFAULT   FBINFO_MODULE
> -#else
> -#define FBINFO_DEFAULT   0
> -#endif
> -
> -// This will go away
> -#define FBINFO_FLAG_MODULE   FBINFO_MODULE
>  #define FBINFO_FLAG_DEFAULT  FBINFO_DEFAULT
>  
>  /* This will go away
> -- 
> 2.13.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/: Drop fbdev info flags

[Sean Paul]

On Thu, Jul 06, 2017 at 02:57:35PM +0200, Daniel Vetter wrote:
> - FBINFO_CAN_FORCE_OUTPUT has been a lie ever since we nerfed&removed
>   the entire panic handling code in our fbdev emulation. We might
>   restore kms panic output, but not through the bazillion of legacy
>   code layers called fbdev/fbcon, there's just no way to make that
>   work safely.
> 
> - With the module check change FBINFO_DEFAULT is always 0, so can be
>   removed too.
> 
> That removes another change to cargo-cult stuff in kms drivers, yay!
> 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 1 -
>  drivers/gpu/drm/armada/armada_fbdev.c | 1 -
>  drivers/gpu/drm/ast/ast_fb.c  | 1 -
>  drivers/gpu/drm/bochs/bochs_fbdev.c   | 1 -
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c | 1 -
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 1 -
>  drivers/gpu/drm/i915/intel_fbdev.c| 1 -
>  drivers/gpu/drm/mgag200/mgag200_fb.c  | 1 -
>  drivers/gpu/drm/msm/msm_fbdev.c   | 1 -
>  drivers/gpu/drm/omapdrm/omap_fbdev.c  | 1 -
>  drivers/gpu/drm/qxl/qxl_fb.c  | 1 -
>  drivers/gpu/drm/radeon/radeon_fb.c| 1 -
>  drivers/gpu/drm/udl/udl_fb.c  | 1 -
>  drivers/gpu/drm/virtio/virtgpu_fb.c   | 1 -
>  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c| 1 -
>  15 files changed, 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> index c0d8c6ff6380..1c57fefc364c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> @@ -245,7 +245,6 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
>  
>   drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth);
>  
> - info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
>   info->fbops = &amdgpufb_ops;
>  
>   tmp = amdgpu_bo_gpu_offset(abo) - adev->mc.vram_start;
> diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
> b/drivers/gpu/drm/armada/armada_fbdev.c
> index 602dfead8eef..5b479b0ed06c 100644
> --- a/drivers/gpu/drm/armada/armada_fbdev.c
> +++ b/drivers/gpu/drm/armada/armada_fbdev.c
> @@ -81,7 +81,6 @@ static int armada_fb_create(struct drm_fb_helper *fbh,
>  
>   strlcpy(info->fix.id, "armada-drmfb", sizeof(info->fix.id));
>   info->par = fbh;
> - info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
>   info->fbops = &armada_fb_ops;
>   info->fix.smem_start = obj->phys_addr;
>   info->fix.smem_len = obj->obj.size;
> diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
> index 4ad4acd0ccab..53ca6d099234 100644
> --- a/drivers/gpu/drm/ast/ast_fb.c
> +++ b/drivers/gpu/drm/ast/ast_fb.c
> @@ -231,7 +231,6 @@ static int astfb_create(struct drm_fb_helper *helper,
>  
>   strcpy(info->fix.id, "astdrmfb");
>  
> - info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
>   info->fbops = &astfb_ops;
>  
>   info->apertures->ranges[0].base = pci_resource_start(dev->pdev, 0);
> diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
> b/drivers/gpu/drm/bochs/bochs_fbdev.c
> index 49d5a2b7d630..14eb8d0d5a00 100644
> --- a/drivers/gpu/drm/bochs/bochs_fbdev.c
> +++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
> @@ -118,7 +118,6 @@ static int bochsfb_create(struct drm_fb_helper *helper,
>  
>   strcpy(info->fix.id, "bochsdrmfb");
>  
> - info->flags = FBINFO_DEFAULT;
>   info->fbops = &bochsfb_ops;
>  
>   drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth);
> diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
> b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> index 7fa58eeadc9d..c69586163d92 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> @@ -215,7 +215,6 @@ static int cirrusfb_create(struct drm_fb_helper *helper,
>  
>   strcpy(info->fix.id, "cirrusdrmfb");
>  
> - info->flags = FBINFO_DEFAULT;
>   info->fbops = &cirrusfb_ops;
>  
>   drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth);
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c 
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
> index f5ac80daeef2..9740eed9231a 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
> @@ -131,7 +131,6 @@ static int hibmc_drm_fb_create(struct drm_fb_helper 
> *helper,
>  
>   strcpy(info->fix.id, "hibmcdrmfb");
>  
> - info->flags = FBINFO_DEFAULT;
>   info->fbops = &hibmc_drm_fb_ops;
>  
>   drm_fb_helper_fill_fix(info, hi_fbdev->fb->fb.pitches[0],
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 5536591d3da0..b953365a3eec 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -232,7 +232,6 @@ static i

[Intel-gfx] [PATCH v2 00/14] YCBCR 4:2:0 handling in DRM layer

[Shashank Sharma]

Following YCBCR 4:4:4 and 4:2:2, YCBCR 4:2:0 is a new output format,
which is currently supported on HDMI 2.0 sources/sinks. Due to lower
chroma sub-sampling rate, YCBCR 4:2:0 can drive the video modes at half
the pixel clock than YCBCR 4:4:4 or RGB 8:8:8 outputs. For example, a CEA
4K@60, RGB 8:8:8 mode needs a clock of appx 594Mhz, but it can be driven at
297Mhz using YCBCR 4:2:0 output.

Of course, the lower rate of chroma subsampling, causes the quality of YCBCR
4:2:0 to be lower than YCBCR 4:4:4 or RGB 8:8:8.

This patch series adds support for YCBCR 4:2:0 output in DRM layer.

- First 2 patches, complete the CEA mode-db in drm driver, by adding
  new 4k modes. Current CEA mode-db contains 64 modes only (VIC 1-64),
  whereas CEA-861-F defined VICs up to 107, including 4k modes, from VIC
  range 93-107. First patch makes sure that inclusion of these modes doesn't
  break existing HDMI 1.4 monitors, across various drivers.

- Next 5 patches focus on parsing new YCBCR 4:2:0 EDID blocks, and adding
  YCBCR 4:2:0 modes in connector. They also contain a prune function, which
  will cleanup the YCBCR 4:2:0 modes from list, if the connector doesn't
  declare them supported.

- Next 2 patches add helper functions for identifing YCBCR 4:2:0 modes and
  setup the color space in AVI infoframes.

- Next 6 patches add code for I915 layer handling of YCBCR 4:2:0 output.

This patch series was initially published as a complete framework to handle
all YCBCR outputs (4:4:4, 4:2:2, 4:2:0), but based on the code reviews, now
its been published as YCBCR 4:2:0 handling series only.

The previous discussion and reviews can be found here:
V5: https://patchwork.freedesktop.org/series/26815/
V1-V4: https://patchwork.freedesktop.org/series/22683/

Now re-publishing this patch series as YCBCR 4:2:0 handling series here.
V2: Addressed review comments from Ville 
This series dropped one patch in V2(patch 8 from V1), so 14 patches in V2

This series has been tested with drm-tip code with following setup:
Source: Intel Geminilake device.
Sink: ACER S277HK HDMI 2.0 monitor.
Protocol testing: Astro VA-1844A HDMI analyzer.

Shashank Sharma (14):
  drm: handle HDMI 2.0 VICs in AVI info-frames
  drm/edid: complete CEA modedb(VIC 1-107)
  drm/edid: parse sink information before CEA blocks
  drm/edid: cleanup patch for CEA extended-tag macro
  drm: add helper to validate YCBCR420 modes
  drm/edid: parse YCBCR420 videomodes from EDID
  drm/edid: parse ycbcr 420 deep color information
  drm: add helper functions for YCBCR420 handling
  drm/i915: add config function for YCBCR420 outputs
  drm/i915: prepare scaler for YCBCR420 modeset
  drm/i915: prepare pipe for YCBCR420 output
  drm/i915: prepare csc unit for YCBCR420 output
  drm/i915: set colorspace for YCBCR420 outputs
  drm/i915/glk: set HDMI 2.0 identifier

 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_v6_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| 438 +-
 drivers/gpu/drm/drm_modes.c   |  87 ++
 drivers/gpu/drm/drm_probe_helper.c|   4 +
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   2 +-
 drivers/gpu/drm/i2c/tda998x_drv.c |   2 +-
 drivers/gpu/drm/i915/i915_reg.h   |   3 +
 drivers/gpu/drm/i915/intel_color.c|  46 +++-
 drivers/gpu/drm/i915/intel_display.c  |  26 ++
 drivers/gpu/drm/i915/intel_drv.h  |   7 +-
 drivers/gpu/drm/i915/intel_hdmi.c |  69 -
 drivers/gpu/drm/i915/intel_panel.c|   3 +-
 drivers/gpu/drm/i915/intel_sdvo.c |   3 +-
 drivers/gpu/drm/mediatek/mtk_hdmi.c   |   2 +-
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c|   2 +-
 drivers/gpu/drm/nouveau/nv50_display.c|   3 +-
 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/sun4i/sun4i_hdmi_enc.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_connector.h   |  32 +++
 include/drm/drm_edid.h|  11 +-
 include/drm/drm_modes.h   |  11 +
 34 files changed, 746 insertions(+), 39 deletions(-)

-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 01/14] drm: handle HDMI 2.0 VICs in AVI info-frames

[Shashank Sharma]

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 if the connected display is HDMI 2.0.
- HDMI infoframes carry one of this two type of information:
- VIC for 4K modes for HDMI 1.4 sinks
- S3D information for S3D modes
  As CEA-861-F has already defined VICs for 4K videomodes, this
  patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks,
  until the mode is 3D.

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

V2: Rebase, Added r-b from Andrzej
V3: Addressed review comment from Ville:
- Do not send VICs in both AVI-IF and HDMI-IF
  send only one of it.
V4: Rebase
V5: Added r-b from Neil.
Addressed review comments from Ville
- Do not block HDMI vendor IF, instead check for VIC while
  handling AVI infoframes
V6: Rebase
V7: Rebase

Reviewed-by: Andrzej Hajda 
Reviewed-by: Neil Armstrong 
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_v6_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| 26 +-
 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/msm/hdmi/hdmi_bridge.c|  2 +-
 drivers/gpu/drm/nouveau/nv50_display.c|  3 ++-
 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/sun4i/sun4i_hdmi_enc.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 ++-
 25 files changed, 57 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 9f78c03..aff1f48 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1867,7 +1867,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 4bcf01d..2df650d 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1851,7 +1851,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_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index fd134a4..0c3891f 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -1597,7 +1597,7 @@ static void dce_v6_0_audio_set_avi_infoframe(struct 
drm_encoder *encoder,
ssize_t err;
u32 tmp;
 
-   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

[Intel-gfx] [PATCH v2 02/14] drm/edid: complete CEA modedb(VIC 1-107)

[Shashank Sharma]

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).

The patch was originaly discussed and reviewed here:
https://patchwork.freedesktop.org/patch/135810/

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Harry Wentland 

V2: Rebase
V3: Rebase
V4: Added native bit handling as per CEA-861-F spec (Ville)
V5: Fix timings for VIC 77:1920x1080 and 104:3840x2160p (Ville)
Remove unnecessary paranthesis from function svd_to_vic (Ville)
Added r-b (Neil)
V6: Rebase
V7: Fix indentation for modes from VIC 80

Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 
Reviewed-by: Neil Armstrong 
Acked-by: Harry Wentland 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 227 -
 1 file changed, 226 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0667b07..8de3092 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1006,6 +1006,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 =

[Intel-gfx] [PATCH v2 03/14] drm/edid: parse sink information before CEA blocks

[Shashank Sharma]

CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
This block contains a map of indexes of CEA modes, which can
support YCBCR 420 output also. To avoid multiple parsing of same
CEA block, let's parse the sink information and get this map, before
parsing CEA modes.

This patch moves the call to drm_add_display_info function, before the
mode parsing block.

V4: Introduced new patch in the series
V5: Move this patch before 4:2:0 parsing patch (ville)
Added r-b from Ville
V6: Rebase
V7: Rebase

Reviewed-by: Ville Syrjälä 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8de3092..57c09d2 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4440,6 +4440,13 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
quirks = edid_get_quirks(edid);
 
/*
+* CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
+* To avoid multiple parsing of same block, lets parse that map
+* from sink info, before parsing CEA modes.
+*/
+   drm_add_display_info(connector, edid);
+
+   /*
 * EDID spec says modes should be preferred in this order:
 * - preferred detailed mode
 * - other detailed modes from base block
@@ -4466,8 +4473,6 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75))
edid_fixup_preferred(connector, quirks);
 
-   drm_add_display_info(connector, edid);
-
if (quirks & EDID_QUIRK_FORCE_6BPC)
connector->display_info.bpc = 6;
 
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 05/14] drm: add helper to validate YCBCR420 modes

[Shashank Sharma]

YCBCR420 modes are supported only on HDMI 2.0 capable sources.
This patch adds:
- A drm helper to validate YCBCR420-only mode on a particular
  connector. This function will help pruning the YCBCR420-only
  modes from the connector's modelist.
- A bool variable (ycbcr_420_allowed) in the drm connector structure.
  While handling the EDID from HDMI 2.0 sinks, its important to know
  if the source is capable of handling YCBCR420 output, so that no
  YCBCR 420 modes will be listed for sources which can't handle it.
  A driver should set this variable if it wants to see YCBCR420 modes
  in the modedb.

V5: Introduced the patch in series.
V6: Squashed two patches (validate YCBCR420 and add YCBCR420
   identifier)
V7: Addressed review comments from Vile:
- Move this patch before we add 420 modes from EDID.
- No need for drm_valid_cea_vic() check, function back to non-static.
- Update MODE_STATUS with NO_420 condition.
- Introduce y420_vdb_modes variable in this patch

Cc: Ville Syrjala 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c |  1 +
 drivers/gpu/drm/drm_modes.c| 29 +
 drivers/gpu/drm/drm_probe_helper.c |  4 
 include/drm/drm_connector.h| 17 +
 include/drm/drm_modes.h|  5 +
 5 files changed, 56 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 16f73c5..96eee5a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2952,6 +2952,7 @@ static bool drm_valid_cea_vic(u8 vic)
 {
return vic > 0 && vic < ARRAY_SIZE(edid_cea_modes);
 }
+EXPORT_SYMBOL(drm_valid_cea_vic);
 
 /**
  * drm_get_cea_aspect_ratio - get the picture aspect ratio corresponding to
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f2493b9..35630b8 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1083,6 +1083,34 @@ drm_mode_validate_size(const struct drm_display_mode 
*mode,
 }
 EXPORT_SYMBOL(drm_mode_validate_size);
 
+/**
+ * drm_mode_validate_ycbcr420 - add 'ycbcr420-only' modes only when allowed
+ * @mode: mode to check
+ * @connector: drm connector under action
+ *
+ * This function is a helper which can be used to filter out any YCBCR420
+ * only mode, when the source doesn't support it.
+ *
+ * Returns:
+ * The mode status
+ */
+enum drm_mode_status
+drm_mode_validate_ycbcr420(const struct drm_display_mode *mode,
+  struct drm_connector *connector)
+{
+   u8 vic = drm_match_cea_mode(mode);
+   enum drm_mode_status status = MODE_OK;
+   struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+
+   if (test_bit(vic, hdmi->y420_vdb_modes)) {
+   if (!connector->ycbcr_420_allowed)
+   status = MODE_NO_420;
+   }
+
+   return status;
+}
+EXPORT_SYMBOL(drm_mode_validate_ycbcr420);
+
 #define MODE_STATUS(status) [MODE_ ## status + 3] = #status
 
 static const char * const drm_mode_status_names[] = {
@@ -1122,6 +1150,7 @@ static const char * const drm_mode_status_names[] = {
MODE_STATUS(ONE_SIZE),
MODE_STATUS(NO_REDUCED),
MODE_STATUS(NO_STEREO),
+   MODE_STATUS(NO_420),
MODE_STATUS(STALE),
MODE_STATUS(BAD),
MODE_STATUS(ERROR),
diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 00e6832..904966c 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -528,6 +528,10 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
if (mode->status == MODE_OK)
mode->status = drm_mode_validate_pipeline(mode,
  connector);
+
+   if (mode->status == MODE_OK)
+   mode->status = drm_mode_validate_ycbcr420(mode,
+ connector);
}
 
 prune:
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ae5b7dc..26dd3eb 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -135,6 +135,14 @@ struct drm_scdc {
 struct drm_hdmi_info {
/** @scdc: sink's scdc support and capabilities */
struct drm_scdc scdc;
+
+   /**
+* @y420_vdb_modes: bitmap of modes which can support ycbcr420
+* output only (not normal RGB/YCBCR444/422 outputs). There are total
+* 107 VICs defined by CEA-861-F spec, so the size is 128 bits to map
+* upto 128 VICs;
+*/
+   unsigned long y420_vdb_modes[BITS_TO_LONGS(128)];
 };
 
 /**
@@ -726,6 +734,15 @@ struct drm_connector {
bool interlace_allowed;
bool doublescan_allowed;
bool stereo_allowed;
+
+   /**
+* @ycbcr_420_allowed : This bool indicates if this connector is
+* capable of handling YCBCR 420 output. While parsing th

[Intel-gfx] [PATCH v2 06/14] drm/edid: parse YCBCR420 videomodes from EDID

[Shashank Sharma]

HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.

These blocks are:

- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.

- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.

This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
  an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Emil Velikov 

V2: Addressed
Review comments from Emil:
- Use 1ULL< 64 modes in capability map block.
- Use y420cmdb in function names and macros while dealing with vcb
  to be aligned with spec.
- Move the display information parsing block ahead of mode parsing
  blocks.

V3: Addressed design/review comments from Ville
- Do not add flags in video modes, else we have to expose them to user
- There should not be a UABI change, and kernel should detect the
  choice of the output based on type of mode, and the bitmaps.
- Use standard bitops from kernel bitmap header, instead of calculating
  bit positions manually.

V4: Addressed review comments from Ville:
- s/ycbcr_420_vdb/y420vdb
- s/ycbcr_420_vcb/y420cmdb
- Be less verbose on description of do_y420vdb_modes
- Move newmode variable in the loop scope.
- Use svd_to_vic() to get a VIC, instead of 0x7f
- Remove bitmap description for CMDB modes & VDB modes
- Dont add connector->ycbcr_420_allowed check for cmdb modes
- Remove 'len' variable, in is_y420cmdb function, which is used
  only once
- Add length check in is_y420vdb function
- Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap
- Do not add print about YCBCR 420 modes
- Fix indentation in few places
- Move ycbcr420_dc_modes in next patch, where its used
- Add a separate patch for movement of drm_add_display_info()

V5: Addressed review comments from Ville:
- Add the patch which cleans up the current EXTENDED_TAG usage
- Make y420_cmdb_map u64
- Do not block ycbcr420 modes while parsing the EDID, rather
  add a separate helper function to prune ycbcr420-only modes from
  connector's probed modes.

V6: Rebase
V7: Move this patch after the 420_only validation patch (Ville)

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c  | 148 +++-
 include/drm/drm_connector.h |  12 
 2 files changed, 158 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 96eee5a..b86afb9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2783,6 +2783,8 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
 #define SPEAKER_BLOCK  0x04
 #define USE_EXTENDED_TAG 0x07
 #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
+#define EXT_VIDEO_DATA_BLOCK_420   0x0E
+#define EXT_VIDEO_CAP_BLOCK_Y420CMDB 0x0F
 #define EDID_BASIC_AUDIO   (1 << 6)
 #define EDID_CEA_YCRCB444  (1 << 5)
 #define EDID_CEA_YCRCB422  (1 << 4)
@@ -3155,15 +3157,79 @@ drm_display_mode_from_vic_index(struct drm_connector 
*connector,
return newmode;
 }
 
+/*
+ * do_y420vdb_modes - Parse YCBCR 420 only modes
+ * @connector: connector corresponding to the HDMI sink
+ * @svds: start of the data block of CEA YCBCR 420 VDB
+ * @len: length of the CEA YCBCR 420 VDB
+ *
+ * Parse the CEA-861-F YCBCR 420 Video Data Block (Y420VDB)
+ * which contains modes which can be supported in YCBCR 420
+ * output format only.
+ */
+static int do_y420vdb_modes(struct drm_connector *connector,
+  const u8 *svds, u8 svds_len)
+{
+   int modes = 0, i;
+   struct drm_device *dev = connector->dev;
+   struct drm_display_info *info = &connector->display_info;
+   struct drm_hdmi_info *hdmi = &info->hdmi;
+
+   for (i = 0; i < svds_len; i++) {
+   u8 vic = svd_to_vic(svds[i]);
+   struct drm_display_mode *newmode;
+
+   newmode = drm_mode_duplicate(dev, &edid_cea_modes[vic]);
+   if (!newmode)
+   break;
+   bitmap_set(hdmi->

[Intel-gfx] [PATCH v2 04/14] drm/edid: cleanup patch for CEA extended-tag macro

[Shashank Sharma]

CEA-861-F introduces extended tag codes for EDID extension blocks,
which indicates the actual type of the data block. The code for
using exteded tag is 0x7, whereas in the existing code, the
corresponding macro is named as "VIDEO_CAPABILITY_BLOCK"

This patch renames the macro and usages from "VIDEO_CAPABILITY_BLOCK"
to "USE_EXTENDED_TAG"

V2: Add extended tag code check for video capabilitiy block (ville)
V3: Ville:
- Use suggested names for macros
- Check the block length first, before checking the extended tag
V4: Fix commit message (David)
V5: Introduced this patch into HDMI-YCBCR-output series
V6: Rebase
V7: Rebase

Cc: Ville Syrjala 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 57c09d2..16f73c5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2781,7 +2781,8 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
 #define VIDEO_BLOCK 0x02
 #define VENDOR_BLOCK0x03
 #define SPEAKER_BLOCK  0x04
-#define VIDEO_CAPABILITY_BLOCK 0x07
+#define USE_EXTENDED_TAG 0x07
+#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
 #define EDID_BASIC_AUDIO   (1 << 6)
 #define EDID_CEA_YCRCB444  (1 << 5)
 #define EDID_CEA_YCRCB422  (1 << 4)
@@ -3443,6 +3444,12 @@ cea_db_payload_len(const u8 *db)
 }
 
 static int
+cea_db_extended_tag(const u8 *db)
+{
+   return db[1];
+}
+
+static int
 cea_db_tag(const u8 *db)
 {
return db[0] >> 5;
@@ -4018,8 +4025,10 @@ bool drm_rgb_quant_range_selectable(struct edid *edid)
return false;
 
for_each_cea_db(edid_ext, i, start, end) {
-   if (cea_db_tag(&edid_ext[i]) == VIDEO_CAPABILITY_BLOCK &&
-   cea_db_payload_len(&edid_ext[i]) == 2) {
+   if (cea_db_tag(&edid_ext[i]) == USE_EXTENDED_TAG &&
+   cea_db_payload_len(&edid_ext[i]) == 2 &&
+   cea_db_extended_tag(&edid_ext[i]) ==
+   EXT_VIDEO_CAPABILITY_BLOCK) {
DRM_DEBUG_KMS("CEA VCDB 0x%02x\n", edid_ext[i + 2]);
return edid_ext[i + 2] & EDID_CEA_VCDB_QS;
}
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 07/14] drm/edid: parse ycbcr 420 deep color information

[Shashank Sharma]

CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 deep color support from the
EDID and adding it into display information stored.

V2: Rebase
V3: Rebase
V4: Moved definition of y420_dc_modes into this patch, where its used
(Ville)
V5: Optimize function, if(conditions) not reqd (Ville)
V6: Rebase
V7: Rebase

Cc: Ville Syrjälä 
Cc: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c  | 12 
 include/drm/drm_connector.h |  3 +++
 include/drm/drm_edid.h  |  8 
 3 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b86afb9..6ef1f3f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4199,6 +4199,16 @@ drm_default_rgb_quant_range(const struct 
drm_display_mode *mode)
 }
 EXPORT_SYMBOL(drm_default_rgb_quant_range);
 
+static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
+const u8 *db)
+{
+   u8 dc_mask;
+   struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+
+   dc_mask = db[7] & DRM_EDID_YCBCR420_DC_MASK;
+   hdmi->y420_dc_modes |= dc_mask;
+}
+
 static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
 const u8 *hf_vsdb)
 {
@@ -4239,6 +4249,8 @@ static void drm_parse_hdmi_forum_vsdb(struct 
drm_connector *connector,
scdc->scrambling.low_rates = true;
}
}
+
+   drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
 }
 
 static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 225e092..4bc0882 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -154,6 +154,9 @@ struct drm_hdmi_info {
 
/** @y420_cmdb_map: bitmap of SVD index, to extraxt vcb modes */
u64 y420_cmdb_map;
+
+   /** @y420_dc_modes: bitmap of deep color support index */
+   u8 y420_dc_modes;
 };
 
 /**
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 89c0062..1e1908a 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -213,6 +213,14 @@ struct detailed_timing {
 #define DRM_EDID_HDMI_DC_30   (1 << 4)
 #define DRM_EDID_HDMI_DC_Y444 (1 << 3)
 
+/* YCBCR 420 deep color modes */
+#define DRM_EDID_YCBCR420_DC_48  (1 << 6)
+#define DRM_EDID_YCBCR420_DC_36  (1 << 5)
+#define DRM_EDID_YCBCR420_DC_30  (1 << 4)
+#define DRM_EDID_YCBCR420_DC_MASK (DRM_EDID_YCBCR420_DC_48 | \
+   DRM_EDID_YCBCR420_DC_36 | \
+   DRM_EDID_YCBCR420_DC_30)
+
 /* ELD Header Block */
 #define DRM_ELD_HEADER_BLOCK_SIZE  4
 
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 08/14] drm: add helper functions for YCBCR420 handling

[Shashank Sharma]

This patch adds helper functions for YCBCR 420 handling.
These functions do:
- check if a given video mode is YCBCR 420 only mode.
- check if a given video mode is YCBCR 420 also mode.

V2: Added YCBCR functions as helpers in DRM layer, instead of
keeping it in I915 layer.
V3: Added handling for YCBCR-420 only modes too.
V4: EXPORT_SYMBOL(drm_find_hdmi_output_type)
V5: Addressed review comments from Danvet:
- %s/drm_find_hdmi_output_type/drm_display_info_hdmi_output_type
- %s/drm_can_support_ycbcr_output/drm_display_supports_ycbcr_output
- %s/drm_can_support_this_ycbcr_output/
drm_display_supports_this_ycbcr_output
- pass drm_display_info instead of drm_connector for consistency
- For drm_get_highest_quality_ycbcr_supported doc, move the variable
  description above, and then the function description.
V6: Add only YCBCR420 helpers (Ville)
V7: Addressed review comments from Ville
- Remove cea_vic_valid() check.
- Fix indentation.
- Make input parameters to helpers, const.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_modes.c | 58 +
 include/drm/drm_modes.h |  6 +
 2 files changed, 64 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 35630b8..c1aec53 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1605,3 +1605,61 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
 out:
return ret;
 }
+
+/**
+ * drm_mode_is_420_only - if a given videomode can be only supported in 
YCBCR420
+ * output format
+ *
+ * @connector: drm connector under action.
+ * @mode: video mode to be tested.
+ *
+ * Returns:
+ * true if the mode can be supported in YCBCR420 format
+ * false if not.
+ */
+bool drm_mode_is_420_only(const struct drm_display_info *display,
+ const struct drm_display_mode *mode)
+{
+   u8 vic = drm_match_cea_mode(mode);
+
+   return test_bit(vic, display->hdmi.y420_vdb_modes);
+}
+EXPORT_SYMBOL(drm_mode_is_420_only);
+
+/**
+ * drm_mode_is_420_also - if a given videomode can be supported in YCBCR420
+ * output format also (along with RGB/YCBCR444/422)
+ *
+ * @display: display under action.
+ * @mode: video mode to be tested.
+ *
+ * Returns:
+ * true if the mode can be support YCBCR420 format
+ * false if not.
+ */
+bool drm_mode_is_420_also(const struct drm_display_info *display,
+ const struct drm_display_mode *mode)
+{
+   u8 vic = drm_match_cea_mode(mode);
+
+   return test_bit(vic, display->hdmi.y420_cmdb_modes);
+}
+EXPORT_SYMBOL(drm_mode_is_420_also);
+/**
+ * drm_mode_is_420 - if a given videomode can be supported in YCBCR420
+ * output format
+ *
+ * @display: display under action.
+ * @mode: video mode to be tested.
+ *
+ * Returns:
+ * true if the mode can be supported in YCBCR420 format
+ * false if not.
+ */
+bool drm_mode_is_420(const struct drm_display_info *display,
+const struct drm_display_mode *mode)
+{
+   return drm_mode_is_420_only(display, mode) ||
+   drm_mode_is_420_also(display, mode);
+}
+EXPORT_SYMBOL(drm_mode_is_420);
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index f8a1268..e9a42591 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -452,6 +452,12 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
   const struct drm_mode_modeinfo *in);
 void drm_mode_probed_add(struct drm_connector *connector, struct 
drm_display_mode *mode);
 void drm_mode_debug_printmodeline(const struct drm_display_mode *mode);
+bool drm_mode_is_420_only(const struct drm_display_info *display,
+ const struct drm_display_mode *mode);
+bool drm_mode_is_420_also(const struct drm_display_info *display,
+ const struct drm_display_mode *mode);
+bool drm_mode_is_420(const struct drm_display_info *display,
+ const struct drm_display_mode *mode);
 
 struct drm_display_mode *drm_cvt_mode(struct drm_device *dev,
  int hdisplay, int vdisplay, int vrefresh,
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 10/14] drm/i915: prepare scaler for YCBCR420 modeset

[Shashank Sharma]

To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.

This patch:
- Does scaler allocation for HDMI ycbcr420 outputs.
- Programs PIPE_MISC register for ycbcr420 output.
- Adds a new scaler user "HDMI output" to plug-into existing
  scaler framework. This output type is identified using bit
  30 of the scaler users bitmap.

V2: rebase
V3: rebase
V4: rebase
V5: addressed review comments from Ander:
- No need to check both scaler_user && hdmi_output.
  Check for scaler_user is enough.
V6: rebase
V7: Do not create a new scaler user, use existing pipe scaler user.

Cc: Ville Syrjala 
Cc: Ander Conselvan De Oliveira 

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_display.c |  3 +++
 drivers/gpu/drm/i915/intel_drv.h |  4 +++-
 drivers/gpu/drm/i915/intel_hdmi.c| 12 
 drivers/gpu/drm/i915/intel_panel.c   |  3 ++-
 4 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a5140e4..d78f1c2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4624,6 +4624,9 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
 */
need_scaling = src_w != dst_w || src_h != dst_h;
 
+   if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
+   need_scaling = true;
+
/*
 * Scaling/fitting not supported in IF-ID mode in GEN9+
 * TODO: Interlace fetch mode doesn't support YUV420 planar formats.
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 592243b..94ea6ed 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -471,7 +471,8 @@ struct intel_crtc_scaler_state {
 *
 * If a bit is set, a user is using a scaler.
 * Here user can be a plane or crtc as defined below:
-*   bits 0-30 - plane (bit position is index from drm_plane_index)
+*   bits 0-29 - plane (bit position is index from drm_plane_index)
+*   bit 30- hdmi output
 *   bit 31- crtc
 *
 * Instead of creating a new index to cover planes and crtc, using
@@ -484,6 +485,7 @@ struct intel_crtc_scaler_state {
 * avilability.
 */
 #define SKL_CRTC_INDEX 31
+
unsigned scaler_users;
 
/* scaler used by crtc for panel fitting purpose */
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index eb6243c..49f4fb8 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1356,6 +1356,7 @@ intel_hdmi_ycbcr420_config(struct drm_connector 
*connector,
   struct intel_crtc_state *config,
   int *clock_12bpc, int *clock_8bpc)
 {
+   struct intel_crtc *intel_crtc = to_intel_crtc(config->base.crtc);
 
if (!connector->ycbcr_420_allowed) {
DRM_ERROR("Platform doesn't support YCBCR420 output\n");
@@ -1367,6 +1368,17 @@ intel_hdmi_ycbcr420_config(struct drm_connector 
*connector,
*clock_12bpc /= 2;
*clock_8bpc /= 2;
config->ycbcr420 = true;
+
+   /* YCBCR 420 output conversion needs a scaler */
+   if (skl_update_scaler_crtc(config)) {
+   DRM_ERROR("Scaler allocation for output failed\n");
+   return false;
+   }
+
+   /* Bind this scaler to pipe */
+   intel_pch_panel_fitting(intel_crtc, config,
+   DRM_MODE_SCALE_FULLSCREEN);
+
return true;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 96c2cbd..fd2e081 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -110,7 +110,8 @@ intel_pch_panel_fitting(struct intel_crtc *intel_crtc,
 
/* Native modes don't need fitting */
if (adjusted_mode->crtc_hdisplay == pipe_config->pipe_src_w &&
-   adjusted_mode->crtc_vdisplay == pipe_config->pipe_src_h)
+   adjusted_mode->crtc_vdisplay == pipe_config->pipe_src_h &&
+   !pipe_config->ycbcr420)
goto done;
 
switch (fitting_mode) {
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 12/14] drm/i915: prepare csc unit for YCBCR420 output

[Shashank Sharma]

To support ycbcr output, we need a pipe CSC block to do
RGB->YCBCR conversion.

Current Intel platforms have only one pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.

This function adds a csc handler, which uses recommended bspec
values to perform RGB->YCBCR conversion (target color space BT709)

V2: Rebase
V3: Rebase
V4: Rebase
V5: Addressed review comments from Ander
- Remove extra line added in the patch
- Add the spec details in the commit message
- Combine two if(cond) while calling intel_crtc_compute_config
V6: Handle YCBCR420 outputs only (Ville)
V7: Addressed review comments from Ville:
- Add description about target colorspace
- Remove the comments from CSC function
- DRM_DEBUG->DEBUG_KMS for atomic failure due to CSC unit busy
- Remove unnecessary debug message about YCBCR420 possibe

Cc: Ville Syrjala 
Cc: Daniel Vetter 
Cc: Ander Conselvan de Oliveira 

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_color.c   | 46 +++-
 drivers/gpu/drm/i915/intel_display.c | 15 
 2 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index f85d575..8698691 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,22 @@
 
 #define LEGACY_LUT_LENGTH  (sizeof(struct drm_color_lut) * 256)
 
+/* Post offset values for RGB->YCBCR conversion */
+#define POSTOFF_RGB_TO_YUV_HI 0x800
+#define POSTOFF_RGB_TO_YUV_ME 0x100
+#define POSTOFF_RGB_TO_YUV_LO 0x800
+
+/*
+ * These values are direct register values specified in the Bspec,
+ * for RGB->YUV conversion matrix (colorspace BT709)
+ */
+#define CSC_RGB_TO_YUV_RU_GU 0x2ba809d8
+#define CSC_RGB_TO_YUV_BU 0x37e8
+#define CSC_RGB_TO_YUV_RY_GY 0x1e089cc0
+#define CSC_RGB_TO_YUV_BY 0xb528
+#define CSC_RGB_TO_YUV_RV_GV 0xbce89ad8
+#define CSC_RGB_TO_YUV_BV 0x1e08
+
 /*
  * Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
  * format). This macro takes the coefficient we want transformed and the
@@ -91,6 +107,31 @@ static void ctm_mult_by_limited(uint64_t *result, int64_t 
*input)
}
 }
 
+void i9xx_load_ycbcr_conversion_matrix(struct intel_crtc *intel_crtc)
+{
+   int pipe = intel_crtc->pipe;
+   struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+
+
+   I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
+
+   I915_WRITE(PIPE_CSC_COEFF_RU_GU(pipe), CSC_RGB_TO_YUV_RU_GU);
+   I915_WRITE(PIPE_CSC_COEFF_BU(pipe), CSC_RGB_TO_YUV_BU);
+
+   I915_WRITE(PIPE_CSC_COEFF_RY_GY(pipe), CSC_RGB_TO_YUV_RY_GY);
+   I915_WRITE(PIPE_CSC_COEFF_BY(pipe), CSC_RGB_TO_YUV_BY);
+
+   I915_WRITE(PIPE_CSC_COEFF_RV_GV(pipe), CSC_RGB_TO_YUV_RV_GV);
+   I915_WRITE(PIPE_CSC_COEFF_BV(pipe), CSC_RGB_TO_YUV_BV);
+
+   I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), POSTOFF_RGB_TO_YUV_HI);
+   I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), POSTOFF_RGB_TO_YUV_ME);
+   I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), POSTOFF_RGB_TO_YUV_LO);
+   I915_WRITE(PIPE_CSC_MODE(pipe), 0);
+}
+
 /* Set up the pipe CSC unit. */
 static void i9xx_load_csc_matrix(struct drm_crtc_state *crtc_state)
 {
@@ -101,7 +142,10 @@ static void i9xx_load_csc_matrix(struct drm_crtc_state 
*crtc_state)
uint16_t coeffs[9] = { 0, };
struct intel_crtc_state *intel_crtc_state = 
to_intel_crtc_state(crtc_state);
 
-   if (crtc_state->ctm) {
+   if (intel_crtc_state->ycbcr420) {
+   i9xx_load_ycbcr_conversion_matrix(intel_crtc);
+   return;
+   } else if (crtc_state->ctm) {
struct drm_color_ctm *ctm =
(struct drm_color_ctm *)crtc_state->ctm->data;
uint64_t input[9] = { 0, };
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 1a23ec0..9c6a1ed 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6283,6 +6283,21 @@ static int intel_crtc_compute_config(struct intel_crtc 
*crtc,
return -EINVAL;
}
 
+   /* YCBCR420 feasibility check */
+   if (pipe_config->ycbcr420) {
+   struct drm_crtc_state *drm_state = &pipe_config->base;
+
+   /*
+* There is only one pipe CSC unit per pipe, and we need that
+* for output conversion from RGB->YCBCR. So if CTM is already
+* applied we can't support YCBCR420 output.
+*/
+   if (drm_state->ctm) {
+   DRM_DEBUG_KMS("YCBCR420 and CTM is not possible\n");
+   return -EINVAL;
+   }
+   }
+
/*
 * Pipe horizontal size must be even in:
 * - DVO ganged mode
-- 
2.7.4

[Intel-gfx] [PATCH v2 09/14] drm/i915: add config function for YCBCR420 outputs

[Shashank Sharma]

This patch checks encoder level support for YCBCR420 outputs.
The logic goes as simple as this:
If the input mode is YCBCR420-only mode: prepare HDMI for
YCBCR420 output, else continue with RGB output mode.

It checks if the mode is YCBCR420 and source can support this
output then it marks the ycbcr_420 output indicator into crtc
state, for further staging in driver.

V2: Split the patch into two, kept helper functions in DRM layer.
V3: Changed the compute_config function based on new DRM API.
V4: Rebase
V5: Rebase
V6: Check and handle YCBCR420-only modes, discard the property
based approach (Ville)
V7: Addressed review comments from Ville
- add else case in 12BPC check.
- extract ycbcr420 state inside hdmi_12bpc_possible function.

Cc: Ville Syrjala 
Cc: Daniel Vetter 
Cc: Ander Conselvan de Oliveira 

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_display.c |  1 +
 drivers/gpu/drm/i915/intel_drv.h |  3 +++
 drivers/gpu/drm/i915/intel_hdmi.c| 43 +---
 3 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 2144adc..a5140e4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11945,6 +11945,7 @@ intel_pipe_config_compare(struct drm_i915_private 
*dev_priv,
PIPE_CONF_CHECK_I(hdmi_scrambling);
PIPE_CONF_CHECK_I(hdmi_high_tmds_clock_ratio);
PIPE_CONF_CHECK_I(has_infoframe);
+   PIPE_CONF_CHECK_I(ycbcr420);
 
PIPE_CONF_CHECK_I(has_audio);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d17a324..592243b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -780,6 +780,9 @@ struct intel_crtc_state {
 
/* HDMI High TMDS char rate ratio */
bool hdmi_high_tmds_clock_ratio;
+
+   /* HDMI output type */
+   bool ycbcr420;
 };
 
 struct intel_crtc {
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index cc0d100..eb6243c 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1312,6 +1312,7 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state 
*crtc_state)
struct drm_atomic_state *state = crtc_state->base.state;
struct drm_connector_state *connector_state;
struct drm_connector *connector;
+   bool output_ycbcr420 = crtc_state->ycbcr420;
int i;
 
if (HAS_GMCH_DISPLAY(dev_priv))
@@ -1330,8 +1331,16 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state 
*crtc_state)
if (connector_state->crtc != crtc_state->base.crtc)
continue;
 
-   if ((info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36) == 0)
-   return false;
+   if (output_ycbcr420) {
+   const struct drm_hdmi_info *hdmi = &info->hdmi;
+
+   if (!(hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_36))
+   return false;
+   } else {
+
+   if (!(info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36))
+   return false;
+   }
}
 
/* Display Wa #1139 */
@@ -1342,6 +1351,25 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state 
*crtc_state)
return true;
 }
 
+static bool
+intel_hdmi_ycbcr420_config(struct drm_connector *connector,
+  struct intel_crtc_state *config,
+  int *clock_12bpc, int *clock_8bpc)
+{
+
+   if (!connector->ycbcr_420_allowed) {
+   DRM_ERROR("Platform doesn't support YCBCR420 output\n");
+   return false;
+   }
+
+   /* YCBCR420 TMDS rate requirement is half the pixel clock */
+   config->port_clock /= 2;
+   *clock_12bpc /= 2;
+   *clock_8bpc /= 2;
+   config->ycbcr420 = true;
+   return true;
+}
+
 bool intel_hdmi_compute_config(struct intel_encoder *encoder,
   struct intel_crtc_state *pipe_config,
   struct drm_connector_state *conn_state)
@@ -1349,7 +1377,8 @@ bool intel_hdmi_compute_config(struct intel_encoder 
*encoder,
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct drm_display_mode *adjusted_mode = 
&pipe_config->base.adjusted_mode;
-   struct drm_scdc *scdc = &conn_state->connector->display_info.hdmi.scdc;
+   struct drm_connector *connector = conn_state->connector;
+   struct drm_scdc *scdc = &connector->display_info.hdmi.scdc;
struct intel_digital_connector_state *intel_conn_state =
to_intel_digital_connector_state(conn_state);
int clock_8bpc = pipe_config->base.adjusted_mode.crtc_clock;
@@ -1379,6 +1408,14 @@ bool intel_hdmi_compute_co

[Intel-gfx] [PATCH v2 13/14] drm/i915: set colorspace for YCBCR420 outputs

[Shashank Sharma]

When output colorspace is YCBCR420, we have to load the
corresponding colorspace in AVI infoframe. This patch fills
the colorspace of AVI infoframe as per the output mode.

V2: Rebase
V3: Rebase
V4: Rebase
V5: Added r-b from Ander
V6: Checking RGB/YCBCR420 output only (Ville)
V7: Add colorspace info in driver(not drm layer) (Ville)

Cc: Ville Syrjala 
Cc: Ander Conselvan de Oliveira 

Reviewed-by: Ander Conselvan de Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 49f4fb8..412b6e3 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -472,12 +472,18 @@ static void intel_hdmi_set_avi_infoframe(struct 
drm_encoder *encoder,
return;
}
 
+   if (crtc_state->ycbcr420)
+   frame.avi.colorspace = HDMI_COLORSPACE_YUV420;
+   else
+   frame.avi.colorspace = HDMI_COLORSPACE_RGB;
+
drm_hdmi_avi_infoframe_quant_range(&frame.avi, adjusted_mode,
   crtc_state->limited_color_range ?
   HDMI_QUANTIZATION_RANGE_LIMITED :
   HDMI_QUANTIZATION_RANGE_FULL,
   
intel_hdmi->rgb_quant_range_selectable);
 
+   /* TODO: handle pixel repetition for YCBCR420 outputs */
intel_write_infoframe(encoder, crtc_state, &frame);
 }
 
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 11/14] drm/i915: prepare pipe for YCBCR420 output

[Shashank Sharma]

To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
  blend mode to use the scaler in 5x3 ratio (bits 26 and 27)

This patch:
- Adds definition of these bits.
- Programs PIPEMISC for YCBCR420 outputs.

V2: rebase
V3: rebase
V4: rebase
V5: added r-b from Ander
V6: Handle only YCBCR420 outputs (ville)
V7: rebase

Cc: Ville Syrjala 
Cc: Ander Conselvan de Oliveira 
Cc: Daniel Vetter 

Reviewed-by: Ander Conselvan de Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/i915_reg.h  | 3 +++
 drivers/gpu/drm/i915/intel_display.c | 7 +++
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c712d01..e5020d6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5227,6 +5227,9 @@ enum {
 
 #define _PIPE_MISC_A   0x70030
 #define _PIPE_MISC_B   0x71030
+#define   PIPEMISC_YCBCR420_ENABLE (1<<27)
+#define   PIPEMISC_YCBCR420_MODE_BLEND (1<<26)
+#define   PIPEMISC_OUTPUT_YCBCR(1<<11)
 #define   PIPEMISC_DITHER_BPC_MASK (7<<5)
 #define   PIPEMISC_DITHER_8_BPC(0<<5)
 #define   PIPEMISC_DITHER_10_BPC   (1<<5)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d78f1c2..1a23ec0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8076,6 +8076,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *config = intel_crtc->config;
 
if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
u32 val = 0;
@@ -8101,6 +8102,12 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
if (intel_crtc->config->dither)
val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
 
+   if (config->ycbcr420) {
+   val |= PIPEMISC_OUTPUT_YCBCR |
+   PIPEMISC_YCBCR420_ENABLE |
+   PIPEMISC_YCBCR420_MODE_BLEND;
+   }
+
I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
}
 }
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 14/14] drm/i915/glk: set HDMI 2.0 identifier

[Shashank Sharma]

This patch sets the is_hdmi2_src identifier in drm connector
for GLK platform. GLK contains a native HDMI 2.0 controller.
This identifier will help the EDID handling functions to save
lot of work which is specific to HDMI 2.0 sources.

V3: Added this patch
V4: Rebase
V4: Rebase
V5: Added r-b from Ander
V6: Rebase
V7: Rebase

Cc: Ville Syrjala 
Cc: Ander Conselvan de Oliveira 

Reviewed-by: Ander Conselvan de Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 412b6e3..bd08ae4 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1917,6 +1917,9 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
connector->doublescan_allowed = 0;
connector->stereo_allowed = 1;
 
+   if (IS_GEMINILAKE(dev_priv))
+   connector->ycbcr_420_allowed = true;
+
intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
 
switch (port) {
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/11] drm/i915/skl+: unify cpp value in WM calculation

[Maarten Lankhorst]

Op 05-07-17 om 16:31 schreef Mahesh Kumar:
> From: "Kumar, Mahesh" 
>
> use same cpp value in different phase of plane WM caluclation.
>
> Signed-off-by: Mahesh Kumar 
> Reviewed-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 9e2ca70bed5d..9753210d79ae 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4399,13 +4399,11 @@ static int skl_compute_plane_wm(const struct 
> drm_i915_private *dev_priv,
>   width = drm_rect_width(&intel_pstate->base.src) >> 16;
>   }
>  
> - cpp = fb->format->cpp[0];
> + cpp = (fb->format->format == DRM_FORMAT_NV12) ? fb->format->cpp[1] :
> + fb->format->cpp[0];
>   plane_pixel_rate = skl_adjusted_plane_pixel_rate(cstate, intel_pstate);
>  
>   if (drm_rotation_90_or_270(pstate->rotation)) {
> - int cpp = (fb->format->format == DRM_FORMAT_NV12) ?
> - fb->format->cpp[1] :
> - fb->format->cpp[0];
>  
>   switch (cpp) {
>   case 1:

First 6 patches pushed, thanks.

I'll take a closer look at the other patches on monday. :)

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for YCBCR 4:2:0 handling in DRM layer (rev2)

[Patchwork]

== Series Details ==

Series: YCBCR 4:2:0 handling in DRM layer (rev2)
URL   : https://patchwork.freedesktop.org/series/26972/
State : success

== Summary ==

Series 26972v2 YCBCR 4:2:0 handling in DRM layer
https://patchwork.freedesktop.org/api/1.0/series/26972/revisions/2/mbox/

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:437s
fi-bdw-gvtdvmtotal:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  
time:424s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:358s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:538s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:512s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:490s
fi-byt-n2820 total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  
time:485s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:592s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:434s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:415s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:498s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:469s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:463s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:566s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:575s
fi-pnv-d510  total:279  pass:222  dwarn:2   dfail:0   fail:0   skip:55  
time:563s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:454s
fi-skl-6700hqtotal:279  pass:262  dwarn:0   dfail:0   fail:0   skip:17  
time:580s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:474s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:482s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:430s
fi-skl-x1585ltotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:486s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:400s

8ad9e19aafea47c272163c2cbf554e06ff7f9857 drm-tip: 2017y-07m-11d-19h-08m-20s UTC 
integration manifest
706180a drm/i915/glk: set HDMI 2.0 identifier
23c1aaa drm/i915: set colorspace for YCBCR420 outputs
f1885be drm/i915: prepare csc unit for YCBCR420 output
d550d0a drm/i915: prepare pipe for YCBCR420 output
0d4052d drm/i915: prepare scaler for YCBCR420 modeset
230c4ad drm/i915: add config function for YCBCR420 outputs
93fe7db drm: add helper functions for YCBCR420 handling
426d8ac drm/edid: parse ycbcr 420 deep color information
1fd56bd drm/edid: parse YCBCR420 videomodes from EDID
cb40a11 drm: add helper to validate YCBCR420 modes
9bff1cf drm/edid: cleanup patch for CEA extended-tag macro
a2d60dc drm/edid: parse sink information before CEA blocks
fd87ef7 drm/edid: complete CEA modedb(VIC 1-107)
510e1eb drm: handle HDMI 2.0 VICs in AVI info-frames

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5184/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 13/16] drm/mediatek: Convert to new iterator macros

[Maarten Lankhorst]

Op 12-07-17 om 11:45 schreef Daniel Vetter:
> On Wed, Jul 12, 2017 at 10:13:41AM +0200, Maarten Lankhorst wrote:
>> for_each_obj_in_state is about to be removed, so use the new atomic
>> iterator macros.
>>
>> Signed-off-by: Maarten Lankhorst 
>> Cc: CK Hu 
>> Cc: Philipp Zabel 
>> Cc: Matthias Brugger 
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-media...@lists.infradead.org
>> ---
>>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
>> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> index 56f802d0a51c..be0741638f94 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> @@ -48,11 +48,11 @@ static void mtk_atomic_schedule(struct mtk_drm_private 
>> *private,
>>  static void mtk_atomic_wait_for_fences(struct drm_atomic_state *state)
>>  {
>>  struct drm_plane *plane;
>> -struct drm_plane_state *plane_state;
>> +struct drm_plane_state *new_plane_state;
>>  int i;
>>  
>> -for_each_plane_in_state(state, plane, plane_state, i)
>> -mtk_fb_wait(plane->state->fb);
>> +for_each_new_plane_in_state(state, plane, new_plane_state, i)
>> +mtk_fb_wait(new_plane_state->fb);
>>  }
> I think a variant of drm_atomic_set_fence_for_plane, which takes a
> reservation obj (or a dma-buf and then derefs dma_buf->resv itself) would
> be nice, so that drivers don't have to hand-roll sub-par fence waiting
> code like this (it's e.g. not interruptible for blocking commits).
>
> Anyway, patch itself looks good.
>
> Reviewed-by: Daniel Vetter 
>

Thanks.

Pushed patch 1-3, 4 (first hunk only), 5 (with static fix), 6, 8, 9, 11-13.

Still hoping for ack from driver maintainers on patch 7 (v2), 10, 14 (v2) and 
15 (with the fix daniel spotted).

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 06/14] drm/edid: parse YCBCR420 videomodes from EDID

[Ville Syrjälä]

On Thu, Jul 13, 2017 at 09:03:12PM +0530, Shashank Sharma wrote:
> HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
> CEA-861-F adds two new blocks in EDID's CEA extension blocks,
> to provide information about sink's YCBCR420 output capabilities.
> 
> These blocks are:
> 
> - YCBCR420vdb(YCBCR 420 video data block):
> This block contains VICs of video modes, which can be sopported only
> in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
> SVD block, valid for YCBCR420 modes only.
> 
> - YCBCR420cmdb(YCBCR 420 capability map data block):
> This block gives information about video modes which can support
> YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
> block contains a bitmap index of normal svd videomodes, which can
> support YCBCR420 output too.
> So if bit 0 from first vcb byte is set, first video mode in the svd
> list can support YCBCR420 output too. Bit 1 means second video mode
> from svd list can support YCBCR420 output too, and so on.
> 
> This patch adds two bitmaps in display's hdmi_info structure, one each
> for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
> adds:
> - VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
>   an entry in the vdb_bitmap per vic.
> - VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.
> 
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Emil Velikov 
> 
> V2: Addressed
> Review comments from Emil:
> - Use 1ULL< - Use the suggested method for updating dbmap.
> - Add documentation for YCBCR420_vcb_map to fix kbuild warning.
> 
> Review comments from Ville:
> - Do not expose the YCBCR420 flags in uabi layer, keep it internal.
> - Save a map of YCBCR420 modes for future reference.
> - Check db length before trying to parse extended tag.
> - Add a warning if there are > 64 modes in capability map block.
> - Use y420cmdb in function names and macros while dealing with vcb
>   to be aligned with spec.
> - Move the display information parsing block ahead of mode parsing
>   blocks.
> 
> V3: Addressed design/review comments from Ville
> - Do not add flags in video modes, else we have to expose them to user
> - There should not be a UABI change, and kernel should detect the
>   choice of the output based on type of mode, and the bitmaps.
> - Use standard bitops from kernel bitmap header, instead of calculating
>   bit positions manually.
> 
> V4: Addressed review comments from Ville:
> - s/ycbcr_420_vdb/y420vdb
> - s/ycbcr_420_vcb/y420cmdb
> - Be less verbose on description of do_y420vdb_modes
> - Move newmode variable in the loop scope.
> - Use svd_to_vic() to get a VIC, instead of 0x7f
> - Remove bitmap description for CMDB modes & VDB modes
> - Dont add connector->ycbcr_420_allowed check for cmdb modes
> - Remove 'len' variable, in is_y420cmdb function, which is used
>   only once
> - Add length check in is_y420vdb function
> - Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap
> - Do not add print about YCBCR 420 modes
> - Fix indentation in few places
> - Move ycbcr420_dc_modes in next patch, where its used
> - Add a separate patch for movement of drm_add_display_info()
> 
> V5: Addressed review comments from Ville:
> - Add the patch which cleans up the current EXTENDED_TAG usage
> - Make y420_cmdb_map u64
> - Do not block ycbcr420 modes while parsing the EDID, rather
>   add a separate helper function to prune ycbcr420-only modes from
>   connector's probed modes.
> 
> V6: Rebase
> V7: Move this patch after the 420_only validation patch (Ville)
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c  | 148 
> +++-
>  include/drm/drm_connector.h |  12 
>  2 files changed, 158 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 96eee5a..b86afb9 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2783,6 +2783,8 @@ add_detailed_modes(struct drm_connector *connector, 
> struct edid *edid,
>  #define SPEAKER_BLOCK0x04
>  #define USE_EXTENDED_TAG 0x07
>  #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> +#define EXT_VIDEO_DATA_BLOCK_420 0x0E
> +#define EXT_VIDEO_CAP_BLOCK_Y420CMDB 0x0F
>  #define EDID_BASIC_AUDIO (1 << 6)
>  #define EDID_CEA_YCRCB444(1 << 5)
>  #define EDID_CEA_YCRCB422(1 << 4)
> @@ -3155,15 +3157,79 @@ drm_display_mode_from_vic_index(struct drm_connector 
> *connector,
>   return newmode;
>  }
>  
> +/*
> + * do_y420vdb_modes - Parse YCBCR 420 only modes
> + * @connector: connector corresponding to the HDMI sink
> + * @svds: start of the data block of CEA YCBCR 420 VDB
> + * @len: length of the CEA YCBCR 420 VDB
> + *
> + * Parse the CEA-861-F YCBCR 420 Video Data Block (Y420VDB)
> + * which contains modes which can be supported in YC

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Stéphane Marchesin]

On Thu, Jul 13, 2017 at 3:13 AM, Ville Syrjälä
 wrote:
> On Wed, Jul 12, 2017 at 07:28:14PM -0700, Stéphane Marchesin wrote:
>> On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä
>>  wrote:
>> >
>> > On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
>> > > El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
>> > >
>> > > > In several instances the driver passes an 'enum pipe' value to a
>> > > > function expecting an 'enum transcoder' and viceversa. Since PIPE_x and
>> > > > TRANSCODER_x have the same values this doesn't cause functional
>> > > > problems. Still it is incorrect and causes clang to generate warnings
>> > > > like this:
>> > > >
>> > > > drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit
>> > > >   conversion from enumeration type 'enum transcoder' to different
>> > > >   enumeration type 'enum pipe' [-Wenum-conversion]
>> > > > assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
>> > > >
>> > > > Change the code to pass values of the type expected by the callee.
>> > > >
>> > > > Signed-off-by: Matthias Kaehlcke 
>> > > > ---
>> > > >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
>> > > >  drivers/gpu/drm/i915/intel_dp.c  | 6 --
>> > > >  drivers/gpu/drm/i915/intel_hdmi.c| 6 --
>> > > >  drivers/gpu/drm/i915/intel_sdvo.c| 6 --
>> > > >  4 files changed, 14 insertions(+), 8 deletions(-)
>> > >
>> > > Ping, any comments on this patch?
>> >
>> > I'm not convinced the patch is making things any better really. To
>> > fix this really properly, I think we'd need to introduce a new enum
>> > pch_transcoder and thus avoid the confusion of which type of
>> > transcoder we're talking about. Currently most places expect an
>> > enum pipe when dealing with PCH transcoders, and enum transcoder
>> > when dealing with CPU transcoders. But there are some exceptions
>> > of course.
>>
>>
>> I don't follow -- these functions take an enum transcoder; what's
>> wrong about passing what they expect? It seems like what you are
>> asking for has nothing to do with the warning here...
>
> There's a warning? I don't get any.

Yup, clang generates a warning.

>
> Anyways, I just don't see much point in blindly changing the types
> because it doesn't actually solve the underlying confusion for human
> readers. It might even make it worse, not sure.

The function expects type A, you pass type B, how can that ever be the
right thing to do?

Stéphane


>
> --
> Ville Syrjälä
> Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx