Received: by 10.223.176.5 with SMTP id f5csp2368491wra; Sun, 28 Jan 2018 19:03:20 -0800 (PST) X-Google-Smtp-Source: AH8x224jl+/FGbHJTH+HFnxXrVGPeQpXFoTJk1qm5txRh/nDnbUIKH60UwvVbtZ2wQaKeOtb3ZWH X-Received: by 10.99.111.65 with SMTP id k62mr20070286pgc.253.1517195000585; Sun, 28 Jan 2018 19:03:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517195000; cv=none; d=google.com; s=arc-20160816; b=PIQtG70l6LFzQ9Wp9Is09NiL/Yl5RqP1gd79gT1Lr2Q9rTwkz4yleqa00nHJPpiU2Y W25aMxVA9S9g+dYA+JwAW7TmujQ4TSKGNojnlWo9tQykOjr17BQbY3usct3BGY2uuqPa AYBElA1PG1uu9tXL+bwH/0C2/4maNZNNbDryKp4CqWsCKhdbDyUIvHM88wnZx5fQTakn 57bAbqDwGaDuKTfl9XAgdrQ4UYjMcSxIpoTt8ZVWv8eZtz3hnIvqBcNXpEozr/P3F7I5 E0thKx1rSr/WQ3dn9oyZD+p0u10nFylGR7puqv3gEPCFOW1CZOydIA1pT2joiZ83kZhQ lYMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:arc-authentication-results; bh=mTgD8sFQI6Ojg2Sfqn5cvuMisTexuXg3x+aKC403Qhs=; b=v0G1nJOVo64+NJGdEfL2cW6axqYjwQbAhIAgLC9aWOlyHK+dxz8KPSHOS3BY3PHcHJ TWtKEI2WK1nAUU4npSN4JdL56FfTZTT1fniN4hBAktr106joUqNwoZ2QP3B6fR9uk2se Il9+S9Gsjk3iqJL73rJKV1vn0PyUTDV5d0oiyVQEXafLsUx/oCVbpRYBtKfNGoxD3CvZ NsOEd7+QKwDgpEPT21U9hg8VMqrsMY/t3/6PJozqHmLJlTHwu2tRgpknQ7O/7jnpcQml Ha9psoGnvqpGjOzggNt0UfxNK+mF0yOF843nF9J1vzaZPPtl1E2C0a9XEpQ02d+bO15s Gd6Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h16-v6si7533976pli.9.2018.01.28.19.03.06; Sun, 28 Jan 2018 19:03:20 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932595AbeA2CPJ (ORCPT + 99 others); Sun, 28 Jan 2018 21:15:09 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:39390 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932372AbeA2CPH (ORCPT ); Sun, 28 Jan 2018 21:15:07 -0500 Received: by mail-wm0-f66.google.com with SMTP id b21so30796393wme.4 for ; Sun, 28 Jan 2018 18:15:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mTgD8sFQI6Ojg2Sfqn5cvuMisTexuXg3x+aKC403Qhs=; b=I2RS7TwVu5C5ymKWeMu2cSj7187zxAl/x0OWeQztBc8zx5jr+ra+Au99V9Lje8YYJ5 7lHRYCFEkpQVOTb+DOSnf3u2S1K1QqaRB/0bwzc7yTr/Xllb6f24ptp9Vc9gEv7nY+hZ x9L3XXB6RKb2cLm8bo93d8oe8evzJDtilyB3uj+4iY/63kPVe+1cfN3Fda6P4vyVT12a wqq7J1MGpAwh/SWT+MF/LV9ZyuE4nFuk0j1X2/TYXMKNzVrbArMpnih7uoow0SoZJI9v SW4S1xO9Htbo2Uu/KPomYs5g3hoIwPtF0WrmA8mvHj2T3eCk2+Bk2ombaI5dTnVO6GwT +/og== X-Gm-Message-State: AKwxyteGuoKSNLcXDs16nU1ScxcuaKKOeD+/hhXlPt4hb68rWuRtCq5U tIUAVjagI5szeDir9dmlAsIYHVgV X-Received: by 10.80.134.132 with SMTP id r4mr45727150eda.250.1517192105749; Sun, 28 Jan 2018 18:15:05 -0800 (PST) Received: from mail-wr0-f182.google.com (mail-wr0-f182.google.com. [209.85.128.182]) by smtp.gmail.com with ESMTPSA id d4sm5749143eda.78.2018.01.28.18.15.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Jan 2018 18:15:05 -0800 (PST) Received: by mail-wr0-f182.google.com with SMTP id v15so5489215wrb.8 for ; Sun, 28 Jan 2018 18:15:05 -0800 (PST) X-Received: by 10.223.195.132 with SMTP id p4mr16897749wrf.151.1517192105000; Sun, 28 Jan 2018 18:15:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.88 with HTTP; Sun, 28 Jan 2018 18:14:44 -0800 (PST) In-Reply-To: <7371f62a1385f2cbe3ed75dfca2e746338eb2286.1516617243.git-series.maxime.ripard@free-electrons.com> References: <7371f62a1385f2cbe3ed75dfca2e746338eb2286.1516617243.git-series.maxime.ripard@free-electrons.com> From: Chen-Yu Tsai Date: Mon, 29 Jan 2018 10:14:44 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 15/19] drm/sun4i: backend: Check for the number of alpha planes To: Maxime Ripard Cc: Daniel Vetter , Jani Nikula , Sean Paul , dri-devel , linux-kernel , linux-arm-kernel , thomas@vitsch.nl Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 22, 2018 at 6:35 PM, Maxime Ripard wrote: > Due to the way the composition is done in hardware, we can only have a > single alpha-enabled plane active at a time, placed in the second (highest > priority) pipe. > > Make sure of that in our atomic_check to not end up in an impossible > scenario. > > Signed-off-by: Maxime Ripard > --- > drivers/gpu/drm/sun4i/sun4i_backend.c | 50 ++++++++++++++++++++++++++++- > drivers/gpu/drm/sun4i/sun4i_backend.h | 2 +- > drivers/gpu/drm/sun4i/sun4i_layer.c | 23 +------------- > 3 files changed, 53 insertions(+), 22 deletions(-) > > diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c > index c4986054909b..eb1749d2c0d5 100644 > --- a/drivers/gpu/drm/sun4i/sun4i_backend.c > +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c > @@ -329,6 +329,8 @@ static int sun4i_backend_atomic_check(struct sunxi_engine *engine, > struct drm_atomic_state *state = crtc_state->state; > struct drm_device *drm = state->dev; > struct drm_plane *plane; > + unsigned int num_planes = 0; > + unsigned int num_alpha_planes = 0; > unsigned int num_frontend_planes = 0; > > DRM_DEBUG_DRIVER("Starting checking our planes\n"); > @@ -341,6 +343,7 @@ static int sun4i_backend_atomic_check(struct sunxi_engine *engine, > drm_atomic_get_plane_state(state, plane); > struct sun4i_layer_state *layer_state = > state_to_sun4i_layer_state(plane_state); > + struct drm_framebuffer *fb = plane_state->fb; > > if (sun4i_backend_plane_uses_frontend(plane_state)) { > DRM_DEBUG_DRIVER("Using the frontend for plane %d\n", > @@ -351,6 +354,50 @@ static int sun4i_backend_atomic_check(struct sunxi_engine *engine, > } else { > layer_state->uses_frontend = false; > } > + > + DRM_DEBUG_DRIVER("Plane FB format is %s\n", > + drm_get_format_name(fb->format->format, > + &format_name)); > + if (fb->format->has_alpha) > + num_alpha_planes++; > + > + num_planes++; > + } > + > + /* > + * The hardware is a bit unusual here. > + * > + * Even though it supports 4 layers, it does the composition > + * in two separate steps. > + * > + * The first one is assigning a layer to one of its two > + * pipes. If more that 1 layer is assigned to the same pipe, > + * and if pixels overlaps, the pipe will take the pixel from > + * the layer with the highest priority. > + * > + * The second step is the actual alpha blending, that takes > + * the two pipes as input, and uses the eventual alpha > + * component to do the transparency between the two. > + * > + * This two steps scenario makes us unable to guarantee a > + * robust alpha blending between the 4 layers in all > + * situations, since this means that we need to have one layer > + * with alpha at the lowest position of our two pipes. > + * > + * However, we cannot even do that, since the hardware has a > + * bug where the lowest plane of the lowest pipe (pipe 0, > + * priority 0), if it has any alpha, will discard the pixel > + * entirely and just display the pixels in the background > + * color (black by default). > + * > + * Since means that we effectively have only three valid ^^^^^ This > + * configurations with alpha, all of them with the alpha being > + * on pipe1 with the lowest position, which can be 1, 2 or 3 > + * depending on the number of planes and their zpos. > + */ > + if (num_alpha_planes > SUN4I_BACKEND_NUM_ALPHA_LAYERS) { > + DRM_DEBUG_DRIVER("Too many planes with alpha, rejecting...\n"); > + return -EINVAL; > } > > if (num_frontend_planes > SUN4I_BACKEND_NUM_FRONTEND_LAYERS) { > @@ -358,6 +405,9 @@ static int sun4i_backend_atomic_check(struct sunxi_engine *engine, > return -EINVAL; > } > > + DRM_DEBUG_DRIVER("State valid with %u planes, %u alpha, %u video\n", > + num_planes, num_alpha_planes, num_frontend_planes); > + > return 0; > } > > diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h b/drivers/gpu/drm/sun4i/sun4i_backend.h > index 04a4f11b87a8..52e77591186a 100644 > --- a/drivers/gpu/drm/sun4i/sun4i_backend.h > +++ b/drivers/gpu/drm/sun4i/sun4i_backend.h > @@ -146,6 +146,8 @@ > #define SUN4I_BACKEND_HWCCOLORTAB_OFF 0x4c00 > #define SUN4I_BACKEND_PIPE_OFF(p) (0x5000 + (0x400 * (p))) > > +#define SUN4I_BACKEND_NUM_LAYERS 4 > +#define SUN4I_BACKEND_NUM_ALPHA_LAYERS 1 > #define SUN4I_BACKEND_NUM_FRONTEND_LAYERS 1 > > struct sun4i_backend { > diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c b/drivers/gpu/drm/sun4i/sun4i_layer.c > index fbf25d59cf88..900e716443b8 100644 > --- a/drivers/gpu/drm/sun4i/sun4i_layer.c > +++ b/drivers/gpu/drm/sun4i/sun4i_layer.c > @@ -201,32 +201,11 @@ struct drm_plane **sun4i_layers_init(struct drm_device *drm, > struct sun4i_backend *backend = engine_to_sun4i_backend(engine); > int i; > > - planes = devm_kcalloc(drm->dev, ARRAY_SIZE(sun4i_backend_planes) + 1, > + planes = devm_kcalloc(drm->dev, SUN4I_BACKEND_NUM_LAYERS, > sizeof(*planes), GFP_KERNEL); The returned "planes" array has to have a sentinel at the end, as we never return the actual number of layers created. That is what the +1 was for in the original code. Otherwise, Reviewed-by: Chen-Yu Tsai > if (!planes) > return ERR_PTR(-ENOMEM); > > - /* > - * The hardware is a bit unusual here. > - * > - * Even though it supports 4 layers, it does the composition > - * in two separate steps. > - * > - * The first one is assigning a layer to one of its two > - * pipes. If more that 1 layer is assigned to the same pipe, > - * and if pixels overlaps, the pipe will take the pixel from > - * the layer with the highest priority. > - * > - * The second step is the actual alpha blending, that takes > - * the two pipes as input, and uses the eventual alpha > - * component to do the transparency between the two. > - * > - * This two steps scenario makes us unable to guarantee a > - * robust alpha blending between the 4 layers in all > - * situations. So we just expose two layers, one per pipe. On > - * SoCs that support it, sprites could fill the need for more > - * layers. > - */ > for (i = 0; i < ARRAY_SIZE(sun4i_backend_planes); i++) { > const struct sun4i_plane_desc *plane = &sun4i_backend_planes[i]; > struct sun4i_layer *layer; > -- > git-series 0.9.1