From patchwork Tue Apr 17 09:34:17 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Maarten Lankhorst X-Patchwork-Id: 10344629 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 16BA36039A for ; Tue, 17 Apr 2018 09:34:25 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0529528A35 for ; Tue, 17 Apr 2018 09:34:25 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EBB7428A38; Tue, 17 Apr 2018 09:34:24 +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 0FB3828A35 for ; Tue, 17 Apr 2018 09:34:24 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 84C676E152; Tue, 17 Apr 2018 09:34:22 +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 02C2F6E0FB for ; Tue, 17 Apr 2018 09:34:20 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2018 02:34:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,463,1517904000"; d="scan'208";a="221048923" Received: from prapkiew-mobl.ger.corp.intel.com (HELO [10.252.49.194]) ([10.252.49.194]) by fmsmga005.fm.intel.com with ESMTP; 17 Apr 2018 02:34:18 -0700 To: "Srinivas, Vidya" , "Saarinen, Jani" , "intel-gfx@lists.freedesktop.org" References: <1523527177-14285-6-git-send-email-vidya.srinivas@intel.com> <1523596958-26701-1-git-send-email-vidya.srinivas@intel.com> <43D4F724E12AB6478FC1572B3FBE89D075F4C0E8@IRSMSX106.ger.corp.intel.com> <3c90a8e9-4fc1-4f9c-717d-620122903162@linux.intel.com> <6928735a-7d7c-860f-0c8f-3e666549827e@linux.intel.com> From: Maarten Lankhorst Message-ID: <315e25ad-53be-3921-44a1-7a7785475afb@linux.intel.com> Date: Tue, 17 Apr 2018 11:34:17 +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: Content-Language: en-US Subject: Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments 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: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP Op 17-04-18 om 10:09 schreef Srinivas, Vidya: > >> -----Original Message----- >> From: Srinivas, Vidya >> Sent: Tuesday, April 17, 2018 1:32 PM >> To: 'Maarten Lankhorst' ; Saarinen, >> Jani ; intel-gfx@lists.freedesktop.org >> Cc: Kamath, Sunil >> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for >> NV12 >> >> >> >>> -----Original Message----- >>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com] >>> Sent: Tuesday, April 17, 2018 1:21 PM >>> To: Srinivas, Vidya ; Saarinen, Jani >>> ; intel-gfx@lists.freedesktop.org >>> Cc: Kamath, Sunil >>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for >>> NV12 >>> >>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya: >>>>> -----Original Message----- >>>>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com] >>>>> Sent: Tuesday, April 17, 2018 12:55 PM >>>>> To: Saarinen, Jani ; Srinivas, Vidya >>>>> ; intel-gfx-trybot@lists.freedesktop.org; >>>>> intel- gfx@lists.freedesktop.org >>>>> Cc: Kamath, Sunil >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments >>>>> for >>>>> NV12 >>>>> >>>>> Op 17-04-18 om 08:03 schreef Saarinen, Jani: >>>>>> Lets move this to intel-gfx to get more eyes on it. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Srinivas, Vidya >>>>>>> Sent: tiistai 17. huhtikuuta 2018 5.47 >>>>>>> To: Maarten Lankhorst ; >>>>>>> intel-gfx- trybot@lists.freedesktop.org >>>>>>> Cc: Kamath, Sunil ; Saarinen, Jani >>>>>>> >>>>>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src >>>>>>> adjustments for NV12 >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Maarten Lankhorst >>>>>>>> [mailto:maarten.lankhorst@linux.intel.com] >>>>>>>> Sent: Monday, April 16, 2018 8:00 PM >>>>>>>> To: Srinivas, Vidya ; intel-gfx- >>>>>>>> trybot@lists.freedesktop.org >>>>>>>> Cc: Kamath, Sunil ; Saarinen, Jani >>>>>>>> >>>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src >>>>>>>> adjustments for >>>>>>>> NV12 >>>>>>>> >>>>>>>> Hmm, more thought about src adjustments... >>>>>>>> >>>>>>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas: >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> Credits-to: Maarten Lankhorst >>>>>>>>> >>>>>>>>> Signed-off-by: Vidya Srinivas >>>>>>>>> --- >>>>>>>>> drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++ >>>>>>>>> drivers/gpu/drm/i915/intel_sprite.c | 15 +++++++++++++++ >>>>>>>>> 2 files changed, 26 insertions(+) >>>>>>>>> >>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c >>>>>>>>> b/drivers/gpu/drm/i915/intel_display.c >>>>>>>>> index bc83f10..f64708f 100644 >>>>>>>>> --- a/drivers/gpu/drm/i915/intel_display.c >>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c >>>>>>>>> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct >>>>>>>> intel_plane *plane, >>>>>>>>> bool can_position = false; >>>>>>>>> int ret; >>>>>>>>> uint32_t pixel_format = 0; >>>>>>>>> + struct drm_plane_state *plane_state = &state->base; >>>>>>>>> + struct drm_rect *src = &plane_state->src; >>>>>>>>> + >>>>>>>>> + *src = drm_plane_state_src(plane_state); >>>>>>>>> >>>>>>>>> if (INTEL_GEN(dev_priv) >= 9) { >>>>>>>>> /* use scaler when colorkey is not required */ @@ - >>> 13001,6 >>>>>>>>> +13005,13 @@ intel_check_primary_plane(struct intel_plane >>> *plane, >>>>>>>>> if (!state->base.fb) >>>>>>>>> return 0; >>>>>>>>> >>>>>>>>> + if (pixel_format == DRM_FORMAT_NV12) { >>>>>>>>> + src->x1 = (((src->x1 >> 16)/4)*4) << 16; >>>>>>>>> + src->x2 = (((src->x2 >> 16)/4)*4) << 16; >>>>>>>>> + src->y1 = (((src->y1 >> 16)/4)*4) << 16; >>>>>>>>> + src->y2 = (((src->y2 >> 16)/4)*4) << 16; >>>>>>>>> + } >>>>>>>> Lets reject non multiple of 4 coordinates for plane_state's >>>>>>>> src_x and src_y, and before adjustment also reject non multiple >>>>>>>> of 4 src_w/src_h.fter that we can also reject clipping to the >>>>>>>> right/bottom edge of the screen, if the pipe_src_w/h is not a >>>>>>>> multiple of 4. That way an application trying to go beyond the >> screen. >>>>>>> kms_plane_scaling and some other tests during execution generate >>>>>>> lots of non mult of 4 buffer width/height. All these tests will >>>>>>> show fail in the IGT BAT. >>>>>>> In some cases, even thought the width and height will be multiple >>>>>>> of >>>>>>> 4 before the Adjustment (say our 16x16 buffer), this after >>>>>>> adjustment becomes a 15 in intel_check_sprite_plane. >>>>>>> This again would cause underrun. If we reject non multiple of 4s >>>>>>> in our skl_update_scaler also, then even simple tests with 16x16 >>>>>>> like rotation will fail due to it getting adjusted. >>>>> Correct. This is why we fix up to a multiple of 4 after >>>>> adjustments, and reject user passed coordinates before adjustment.. >>>>> plane_state->src_x/y/w/h is the property set by the user, while the >>>>> plane_state->src rect is set and fixed up in the kernel. >>>>> >>>>> Rejecting clipping with positive coordinates if pipe_src w/h is not >>>>> a multiple of 4 will fix a border case that shouldn't affect most >>>>> modes, where the plane wouldn't extend to the crtc borders, which >>>>> is >>> what userspace wants there. >>>> Thank you. Oh okay. Sorry. I thought we just reject and not do the >>>> fixing >>> (mult of 4 later). >>>> Sure, I will change the patch to also reject the coordinates before >>>> adjustment (if its not Mult of 4). >>>> >>>> >>> This can be done in skl_check_plane_surface, >>> plane_state->src_{x,y,w,h} contains the user requested values. >> Apologies for asking again. The adjustments are done in check_plane (both >> primary and sprite) And towards the end of check_plane we call the >> skl_check_plane_surface. >> I got your point that we will reject the user requested values if they are not >> multiple of 4. >> But before we reach skl_check_plane_surface, they would’ve been >> adjusted/clipped etc They wont remain user requested as is when they enter >> skl_check_plane_surface. >> Please correct me if I am wrong or I am missing in understanding something >> here :( >> >> I can add the add conversion to multiple of 4 in skl_check_plane_surface but >> rejection should be done before the clipping/adjustment Or else, I move the >> entire clipping/adjustment code to skl_check_plane_surface? >> > Sorry, I got it. You said, we don’t do adjustments in case of NV12 in sprite and move > The handling to skl_check_plane_surface. I will do the change and submit. Sorry. > Thank you. > Something like below? Untested.. We should probably also restrict NV12 fb creation to not allow CCS formats. ~Maarten diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 4b3735720fee..c5da30c7ad04 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3090,6 +3090,38 @@ 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; + + /* Are the unadjusted coordinates passed in valid? */ + if ((plane_state->base.src_x >> 16) % 4 || + (plane_state->base.src_y >> 16) % 4 || + (plane_state->base.src_w >> 16) % 4 || + (plane_state->base.src_h >> 16) % 4) { + DRM_DEBUG_KMS("Source coordinates must be a multiple of 4 for NV12\n"); + return -EINVAL; + } + + /* 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; + } + + /* Make adjusted src coordinates a multiple of 4. */ + plane_state->base.src.x1 = DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 18; + plane_state->base.src.y1 = DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18; + plane_state->base.src.x2 = DIV_ROUND_CLOSEST(plane_state->base.src.x2, 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; @@ -3162,6 +3194,12 @@ int skl_check_plane_surface(const struct intel_crtc_state *crtc_state, if (!plane_state->base.visible) return 0; + if (fb->format->format == DRM_FORMAT_NV12) { + ret = skl_check_nv12_surface(crtc_state, plane_state); + if (ret) + return ret; + } + /* Rotate src coordinates to match rotated GTT view */ if (drm_rotation_90_or_270(rotation)) drm_rect_rotate(&plane_state->base.src,