Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751470AbdLNKc3 (ORCPT ); Thu, 14 Dec 2017 05:32:29 -0500 Received: from mail.free-electrons.com ([62.4.15.54]:57505 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750808AbdLNKc2 (ORCPT ); Thu, 14 Dec 2017 05:32:28 -0500 Date: Thu, 14 Dec 2017 11:32:26 +0100 From: Maxime Ripard To: Thomas van Kleef Cc: Daniel Vetter , David Airlie , Chen-Yu Tsai , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Thomas Petazzoni Subject: Re: [PATCH 6/8] drm/sun4i: sun4i_layer: Wire in the frontend Message-ID: <20171214103226.qlcuginegkqzsksv@flea.lan> References: <1513182183-1118130873.0029cb8ee8@prakkezator.vehosting.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vwcinw3c23ilrtjm" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171027 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4974 Lines: 129 --vwcinw3c23ilrtjm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Dec 13, 2017 at 05:23:04PM +0100, Thomas van Kleef wrote: > I wondered if the following is still valid? > In file sun4i_layer.c, func sun4i_layers_init >=20 > ------------------ > /* > * 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 =3D 0; i < ARRAY_SIZE(sun4i_backend_planes); i++) { > const struct sun4i_plane_desc *plane =3D &sun4i_backend_p= lanes[i]; > struct sun4i_layer *layer; >=20 > layer =3D sun4i_layer_init_one(drm, backend, plane); > if (IS_ERR(layer)) { > dev_err(drm->dev, "Couldn't initialize %s plane\n= ", > i ? "overlay" : "primary"); > return ERR_CAST(layer); > }; >=20 > DRM_DEBUG_DRIVER("Assigning %s plane to pipe %d\n", > i ? "overlay" : "primary", plane->pipe); > regmap_update_bits(engine->regs, SUN4I_BACKEND_ATTCTL_REG= 0(i), > SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL_= MASK, > SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL(= plane->pipe)); >=20 > layer->id =3D i; > planes[i] =3D &layer->plane; > }; > ----------------- > > I have been using the 3rd layer (layer2) as the input for the > frontend. This essentially overlays the other 2 layers. Is it still > the case that we can only have 2 layers here? Yes. > Or could be present 1 additional layer when it is attached to the > frontend? The frontend will still consume a backend layer. In this current serie, we still define only two layers for the reasons exposed above, and whatever layer using hardware scaling will use the frontend. I have a few patches that would remove that limitation, but we need a few things in order to do that properly. The first one would be to add a check on the alpha component of our layers. We basically have two rules: - the lowest plane shouldn't use alpha at all, because of a bug in the display engine that would render the pixels completely transparents if the alpha is set to something less than 255 on the lowest plane. - we can only have a plane with alpha as the lowest plane of each pipe. This effectively means that the only scenario that works would be that there can be only one plane can use alpha at a time, that it shouldn't be the lowest one, and that it must be assigned to the second pipe. I worked on that a bit quite some time ago, and the only thing I was missing was a proper way to check for that in atomic_check, but with the work done in this serie it shouldn't be too hard. Then, we can enable the four layers, which is not really difficult in itself. > Perhaps this is not relevant for this patchset. Yep, that's quite orthogonal. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --vwcinw3c23ilrtjm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE0VqZU19dR2zEVaqr0rTAlCFNr3QFAloyUzYACgkQ0rTAlCFN r3QG+Q//YugaFBMNtDZ7wamqwHkht3RIPgTH67875LF1LwG1pnhtgyT54PjdLSd7 oojzGn/YA1Ejt/MvVOAF69lPwqfEg3bVU526WAlEYtHEc4c+AX3X3nqoTuZFzabW Bg+3DUmRCNdOziRpklcaib7zesl2uQvERdDZuDydWXYbcog0jGqFT3yZykn4KL4B oYj/c01aCXJQx+h136Ym2NLELTAf/T5c+xCHCP/nBC5fnSptNyDqH80L31+rgVZW 9KRTSPtdfFhRTGJchQb17fShyp0ap/TLKH6UuaY0KDkwUdRPdgFcfVGfb1WpCE+o xEA5capZsMmvu8N1k4QpgbpPNyhKsVHNlt+wxUvT8+dLOXQs5OjT0tXzKdDzfOHY 1avMcj/8erGexvfMtt+2GJIe3sWcJ/+BvBVQqRKeUgAvBUwljUKJtzNBPGT6Vac/ VOVdyVJAuYsqw2ZqdD0E3Uk9l5sYMXUNwU79Sol4QWxB1y6zzkUimdW4PBfRSb7r AUSw32R7lcWnNWHPmwStejJqlPcEinF72iLa3+Wmc/3Gpp+RsJ/PKQ6RmlFYIHWP WZpgCkI0eqeez5JOeCj8lp+dnXo1UJypPw4aZeAT+YFnu4v/VJVII8yKxJQkfw49 FtDL80NniIejoSfaFHJzwBuAifV7F5Y0d5m8TGXBtgMbBKlQOz4= =/+ta -----END PGP SIGNATURE----- --vwcinw3c23ilrtjm--