Re: [Intel-gfx] [PATCH 3/3] drm/i915/execlists: Read the context-status HEAD from the HWSP
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
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
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)
== 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
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
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
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
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
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
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
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
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
== 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
== 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
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
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
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
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
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
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
== 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
== 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
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
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
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