From patchwork Thu Apr 19 11:30:32 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Maarten Lankhorst X-Patchwork-Id: 10349661 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A895A6023A for ; Thu, 19 Apr 2018 11:30:38 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 983A0289BA for ; Thu, 19 Apr 2018 11:30:38 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8CE6D289BE; Thu, 19 Apr 2018 11:30:38 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id E7B47289BA for ; Thu, 19 Apr 2018 11:30:37 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 693B6894DD; Thu, 19 Apr 2018 11:30:37 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id B89C6894DD for ; Thu, 19 Apr 2018 11:30:35 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2018 04:30:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,468,1517904000"; d="scan'208";a="33763459" Received: from prapkiew-mobl.ger.corp.intel.com (HELO [10.252.49.194]) ([10.252.49.194]) by fmsmga008.fm.intel.com with ESMTP; 19 Apr 2018 04:30:33 -0700 To: =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , "Srinivas, Vidya" References: <1524024493-23173-1-git-send-email-vidya.srinivas@intel.com> <1524024493-23173-7-git-send-email-vidya.srinivas@intel.com> <20180418153256.GV17795@intel.com> <9be96a32-cffa-5517-3363-461e882380be@linux.intel.com> <20180418183556.GY17795@intel.com> <20180419112250.GC17795@intel.com> From: Maarten Lankhorst Message-ID: <6142ae0b-a9da-f553-2726-632d44d83168@linux.intel.com> Date: Thu, 19 Apr 2018 13:30:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180419112250.GC17795@intel.com> Content-Language: en-US Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12 X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "intel-gfx@lists.freedesktop.org" Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP Op 19-04-18 om 13:22 schreef Ville Syrjälä: > On Thu, Apr 19, 2018 at 02:36:42AM +0000, Srinivas, Vidya wrote: >> >> >> >>> -----Original Message----- >>> From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] >>> Sent: Thursday, April 19, 2018 12:06 AM >>> To: Maarten Lankhorst >>> Cc: Srinivas, Vidya ; intel- >>> gfx@lists.freedesktop.org >>> Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add >>> skl_check_nv12_surface for NV12 >>> On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote: >>>> Op 18-04-18 om 17:32 schreef Ville Syrjälä: >>>>> On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote: >>>>>> From: Maarten Lankhorst > >>>>>> We skip src trunction/adjustments for >>>>>> NV12 case and handle the sizes directly. >>>>>> Without this, pipe fifo underruns are seen on APL/KBL. >>>>>> v2: For NV12, making the src coordinates multiplier of 4 >>>>>> v3: Moving all the src coords handling code for NV12 to >>>>>> skl_check_nv12_surface >>>>>> Signed-off-by: Maarten Lankhorst >>>>>> > >>>>>> Signed-off-by: Vidya Srinivas > >>>>>> --- >>>>>> drivers/gpu/drm/i915/intel_display.c | 39 >>>>>> ++++++++++++++++++++++++++++++++++++ >>>>>> drivers/gpu/drm/i915/intel_sprite.c | 15 ++++++++++---- >>>>>> 2 files changed, 50 insertions(+), 4 deletions(-) >>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c >>>>>> b/drivers/gpu/drm/i915/intel_display.c >>>>>> index 925402e..b8dbaca 100644 >>>>>> --- a/drivers/gpu/drm/i915/intel_display.c >>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c >>>>>> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const >>> struct intel_crtc_state *crtc_state, >>>>>> return 0; >>>>>> } >>>>>> +static int >>>>>> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state, >>>>>> + struct intel_plane_state *plane_state) { >>>>>> + int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w; >>>>>> + int crtc_y2 = plane_state->base.crtc_y + >>>>>> +plane_state->base.crtc_h; >>>>>> + >>>>>> + if (((plane_state->base.src_x >> 16) % 4) != 0 || >>>>>> + ((plane_state->base.src_y >> 16) % 4) != 0 || >>>>>> + ((plane_state->base.src_w >> 16) % 4) != 0 || >>>>>> + ((plane_state->base.src_h >> 16) % 4) != 0) { >>>>>> + DRM_DEBUG_KMS("src coords must be multiple of 4 for >>> NV12\n"); >>>>>> + return -EINVAL; >>>>>> + } >>>>> I don't really see why we should check these. The clipped >>>>> coordinates are what matters. >>>> To propagate our limits to the userspace. I think we should do it for >>>> all formats, but NV12 is the first YUV format we have tests for. If we >>>> could we should do something similar for the other YUV formats, but they >>> have different requirements. >>>> In case of NV12 we don't have existing userspace, there will be >>>> nothing that breaks if we enforce limits from the start. >>> But what about sub-pixel coordinates? You're totally ignoring them here. >>> We need to come up with some proper rules for this stuff. >>>>>> + >>>>>> + /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */ >>>>>> + if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w % >>> 4) || >>>>>> + (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4)) >>> { >>>>>> + DRM_DEBUG_KMS("It's not possible to clip %u,%u to >>> %u,%u\n", >>>>>> + crtc_x2, crtc_y2, >>>>>> + crtc_state->pipe_src_w, crtc_state->pipe_src_h); >>>>>> + return -EINVAL; >>>>>> + } >>>>> Why should we care? The current code already plays it fast and loose >>>>> and allows the dst rectangle to shrink to accomodate the hw limits. >>>>> If we want to change that we should change it universally. >>>> Unfortunately for the other formats we already have an existing >>>> userspace >>>> (X.org) that doesn't perform any validation. We can't change it for >>>> that, but we can prevent future mistakes. >>> We should do it uniformly. Not per-format. That will make the code >>> unmaintainable real quick. >>>>>> + >>>>>> + plane_state->base.src.x1 = >>>>>> + DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << >>> 18; >>>>>> + plane_state->base.src.x2 = >>>>>> + DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << >>> 18; >>>>>> + plane_state->base.src.y1 = >>>>>> + DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << >>> 18; >>>>>> + plane_state->base.src.y2 = >>>>>> + DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << >>> 18; >>>>> Since this can now increase the size of the source rectangle our >>>>> scaling factor checks are no longer 100% valid. We might end up with >>>>> a scaling factor that is too high. >>>>> I don't really like any of these "let's make NV12 behave special" >>>>> tricks. We should make the code behave the same way for all pixel >>>>> formats instead of adding format specific hacks. >>>> This is not nivalid because we restrict the original src coordinates >>>> to be a multiple of 4, you can only clip to something smaller, not to >>>> something bigger. :) >>> The clipped coordinates can be whatever thanks to scaling/etc. >>> Also why are we trying to make everything a multiple of four? I don't >>> remember any hw restrictions like that. >> >> >> Hi >> >> >> As per WA1106, Display corruption/color shift observed when using NV12 with 270 rotation or 90 rotation + horizontal flip. >> >> WA: NV12 with 270 rotation or 90 rotation + horizontal flip requires the programmed plane height to be a multiple of 4. > Does plane height here mean src height or dst height? > > Either way I don't see why we aren't just checking for the right thing > instead of trying to mandate a four pixel alignment everywhere. > Agreed, what about the below diff, would this be acceptable to you? I deliberately ignore the last 16 bits as that is what we currently do anyway for all formats. diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 4b3735720fee..3ff7b5491446 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3090,6 +3090,31 @@ static int skl_check_main_surface(const struct intel_crtc_state *crtc_state, return 0; } +static int +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state, + struct intel_plane_state *plane_state) +{ + /* Display WA #1106 */ + if (plane_state->base.rotation != (DRM_MODE_REFLECT_X | DRM_MODE_ROTATE_90) && + plane_state->base.rotation != DRM_MODE_ROTATE_270) + return 0; + + /* Because x/y are src coordinates will be rotated, we look at x/width here. */ + if (((plane_state->base.src_x >> 16) % 4) != 0 || + ((plane_state->base.src_w >> 16) % 4) != 0) { + DRM_DEBUG_KMS("src x/w must be multiple of 4 for rotated NV12\n"); + return -EINVAL; + } + + /* And round y here */ + plane_state->base.src.y1 = + DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18; + plane_state->base.src.y2 = + DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18; + + return 0; +} + static int skl_check_nv12_aux_surface(struct intel_plane_state *plane_state) { const struct drm_framebuffer *fb = plane_state->base.fb; @@ -3173,6 +3198,9 @@ int skl_check_plane_surface(const struct intel_crtc_state *crtc_state, * the main surface setup depends on it. */ if (fb->format->format == DRM_FORMAT_NV12) { + ret = skl_check_nv12_surface(crtc_state, plane_state); + if (ret) + return ret; ret = skl_check_nv12_aux_surface(plane_state); if (ret) return ret;