From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4822FC47404 for ; Fri, 11 Oct 2019 12:07:14 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EE6F9214E0 for ; Fri, 11 Oct 2019 12:07:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="NRzT4l/l"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=baylibre-com.20150623.gappssmtp.com header.i=@baylibre-com.20150623.gappssmtp.com header.b="eQdJEhQ9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EE6F9214E0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=KVXpfp/kt581VfDpouYLbVC89JSwUuC3OTwytvqNLYU=; b=NRzT4l/lJse/Kz xAYDyv90CkFFyj4p0AZIKVstj9kdusfvgyEyNEJKuwdUy6jh95Dz/xVUREkpeh2hdEpJiBYZ58vBc 3yjdBOuRF0Jk3PDxA1l2Aq68WfZ7s0fRGbPc9bYQ6FEyyoGXwr7UUsa7lTKs9/Vd/6ACUQI2V1ESc 9ds9KJFKXpgqLg0ZgJet7rH2lE+RHgHB8H3Y8n++62sOVyVIYSozm+iUB9pcSuvp+ovF/p8UEciyw uH4fl8o9GE+xOKhXGgFI0sHyt5d7QtdlJO+8CkcDG5aFKilcbeWsbZE3bBGUg2oMfUSFHiXBEqpLA 8XlfWqe4OuIcMy2gjmfw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iIthQ-0000zt-Sm; Fri, 11 Oct 2019 12:07:12 +0000 Received: from mail-wr1-x442.google.com ([2a00:1450:4864:20::442]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iIthL-0000yG-7C for linux-arm-kernel@lists.infradead.org; Fri, 11 Oct 2019 12:07:10 +0000 Received: by mail-wr1-x442.google.com with SMTP id r3so11655723wrj.6 for ; Fri, 11 Oct 2019 05:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:openpgp:autocrypt:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=skVJpFrwlbssHfoMwJ5Qz60jZ7+YZBL8hOeGfInPjgA=; b=eQdJEhQ9jA/XxQ+4OdRfQw3vG1COpB7sZod80GFYclFBzZIMCvlVxoOsWF4lakumyS kUhj4jmx1yvNh8i35JLziPqfLW+Iz9CwsQ5481idEwdFCuibc701xnx+ufqLrcmAPc5l +p7hecBboyxgWWiJTOBu9AcZJ//CmWE7VOtVi9RKBFCp5xfKVCVbAKcVrIDTNoea/ItQ aYutnT2NnWbamv1XuHzefcSVMRPhcTY53befxKME+338/iF0VGuZEKuPqG8IVOe12WrF zJFVi+odqTt1iy+JmaYM8wkoqvK13nf6VnPYp3R8hqKwZdInAEL2txPo5NOn5VJuI697 a5qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=skVJpFrwlbssHfoMwJ5Qz60jZ7+YZBL8hOeGfInPjgA=; b=dayEQa2AkRaiy0gq6Q3zKbuG4U1o7HT38+KsNdZ7Wab7dX83q9AfQ0i5Pl7LnJpOLb Xm24EBhvlOXBX6fYVvEFsA+u/vEu48d7eDcywMLkcBa6b2UJyyi/4YAOj4F55T7BRqU5 QwJkuX/WD7hAu47jtDzvgBe2rW1wrApxKRGKJsRAikQuMzTESKvyrxB//9PTDU2PAd9V WqbZUGhZi0KzB6lpob3grYlZx8lEQ8eIQN2bTLm5bvYcXFWIwRj6z/1PbfXDUN99+636 /TV4btqadMlRDRm8+xv2DzR+rJCjs+DQ72tmhJvlbZdPyxueCIl2wbnPUBQ1yejUg72B Beqw== X-Gm-Message-State: APjAAAWKkJBA/v3ITAjfWXh9zORNN7xEr5wK9FUX+C92RV83i0A9B4xl TfKHURD4YLNQlp6lI5LzYxVE5A== X-Google-Smtp-Source: APXvYqzmbbFALORP/sVFC6QVYMkGTRWBmOdVEvPwtEXDxANM1No+1064NIyHI19EXXLz3qJk6Sf1gQ== X-Received: by 2002:a5d:5705:: with SMTP id a5mr13426722wrv.112.1570795622822; Fri, 11 Oct 2019 05:07:02 -0700 (PDT) Received: from [10.1.2.12] (lmontsouris-657-1-212-31.w90-63.abo.wanadoo.fr. [90.63.244.31]) by smtp.gmail.com with ESMTPSA id p5sm11842456wmi.4.2019.10.11.05.07.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Oct 2019 05:07:02 -0700 (PDT) Subject: Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane To: Brian Starkey References: <20191010092526.10419-1-narmstrong@baylibre.com> <20191010092526.10419-5-narmstrong@baylibre.com> <20191010132601.GA10110@arm.com> <44f1771f-d640-f23d-995f-7bfcadd213bc@baylibre.com> <20191011084108.i7lfh2d7asfmcdk4@DESKTOP-E1NTVVP.localdomain> <20191011105559.clttghy52wfdmb34@DESKTOP-E1NTVVP.localdomain> From: Neil Armstrong Openpgp: preference=signencrypt Autocrypt: addr=narmstrong@baylibre.com; prefer-encrypt=mutual; keydata= mQENBE1ZBs8BCAD78xVLsXPwV/2qQx2FaO/7mhWL0Qodw8UcQJnkrWmgTFRobtTWxuRx8WWP GTjuhvbleoQ5Cxjr+v+1ARGCH46MxFP5DwauzPekwJUD5QKZlaw/bURTLmS2id5wWi3lqVH4 BVF2WzvGyyeV1o4RTCYDnZ9VLLylJ9bneEaIs/7cjCEbipGGFlfIML3sfqnIvMAxIMZrvcl9 qPV2k+KQ7q+aXavU5W+yLNn7QtXUB530Zlk/d2ETgzQ5FLYYnUDAaRl+8JUTjc0CNOTpCeik 80TZcE6f8M76Xa6yU8VcNko94Ck7iB4vj70q76P/J7kt98hklrr85/3NU3oti3nrIHmHABEB AAG0KE5laWwgQXJtc3Ryb25nIDxuYXJtc3Ryb25nQGJheWxpYnJlLmNvbT6JATsEEwEKACUC GyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJXDO2CAhkBAAoJEBaat7Gkz/iubGIH/iyk RqvgB62oKOFlgOTYCMkYpm2aAOZZLf6VKHKc7DoVwuUkjHfIRXdslbrxi4pk5VKU6ZP9AKsN NtMZntB8WrBTtkAZfZbTF7850uwd3eU5cN/7N1Q6g0JQihE7w4GlIkEpQ8vwSg5W7hkx3yQ6 2YzrUZh/b7QThXbNZ7xOeSEms014QXazx8+txR7jrGF3dYxBsCkotO/8DNtZ1R+aUvRfpKg5 ZgABTC0LmAQnuUUf2PHcKFAHZo5KrdO+tyfL+LgTUXIXkK+tenkLsAJ0cagz1EZ5gntuheLD YJuzS4zN+1Asmb9kVKxhjSQOcIh6g2tw7vaYJgL/OzJtZi6JlIW5AQ0ETVkGzwEIALyKDN/O GURaHBVzwjgYq+ZtifvekdrSNl8TIDH8g1xicBYpQTbPn6bbSZbdvfeQPNCcD4/EhXZuhQXM coJsQQQnO4vwVULmPGgtGf8PVc7dxKOeta+qUh6+SRh3vIcAUFHDT3f/Zdspz+e2E0hPV2hi SvICLk11qO6cyJE13zeNFoeY3ggrKY+IzbFomIZY4yG6xI99NIPEVE9lNBXBKIlewIyVlkOa YvJWSV+p5gdJXOvScNN1epm5YHmf9aE2ZjnqZGoMMtsyw18YoX9BqMFInxqYQQ3j/HpVgTSv mo5ea5qQDDUaCsaTf8UeDcwYOtgI8iL4oHcsGtUXoUk33HEAEQEAAYkBHwQYAQIACQUCTVkG zwIbDAAKCRAWmrexpM/4rrXiB/sGbkQ6itMrAIfnM7IbRuiSZS1unlySUVYu3SD6YBYnNi3G 5EpbwfBNuT3H8//rVvtOFK4OD8cRYkxXRQmTvqa33eDIHu/zr1HMKErm+2SD6PO9umRef8V8 2o2oaCLvf4WeIssFjwB0b6a12opuRP7yo3E3gTCSKmbUuLv1CtxKQF+fUV1cVaTPMyT25Od+ RC1K+iOR0F54oUJvJeq7fUzbn/KdlhA8XPGzwGRy4zcsPWvwnXgfe5tk680fEKZVwOZKIEuJ C3v+/yZpQzDvGYJvbyix0lHnrCzq43WefRHI5XTTQbM0WUIBIcGmq38+OgUsMYu4NzLu7uZF Acmp6h8guQINBFYnf6QBEADQ+wBYa+X2n/xIQz/RUoGHf84Jm+yTqRT43t7sO48/cBW9vAn9 GNwnJ3HRJWKATW0ZXrCr40ES/JqM1fUTfiFDB3VMdWpEfwOAT1zXS+0rX8yljgsWR1UvqyEP 3xN0M/40Zk+rdmZKaZS8VQaXbveaiWMEmY7sBV3QvgOzB7UF2It1HwoCon5Y+PvyE3CguhBd 9iq5iEampkMIkbA3FFCpQFI5Ai3BywkLzbA3ZtnMXR8Qt9gFZtyXvFQrB+/6hDzEPnBGZOOx zkd/iIX59SxBuS38LMlhPPycbFNmtauOC0DNpXCv9ACgC9tFw3exER/xQgSpDVc4vrL2Cacr wmQp1k9E0W+9pk/l8S1jcHx03hgCxPtQLOIyEu9iIJb27TjcXNjiInd7Uea195NldIrndD+x 58/yU3X70qVY+eWbqzpdlwF1KRm6uV0ZOQhEhbi0FfKKgsYFgBIBchGqSOBsCbL35f9hK/JC 6LnGDtSHeJs+jd9/qJj4WqF3x8i0sncQ/gszSajdhnWrxraG3b7/9ldMLpKo/OoihfLaCxtv xYmtw8TGhlMaiOxjDrohmY1z7f3rf6njskoIXUO0nabun1nPAiV1dpjleg60s3OmVQeEpr3a K7gR1ljkemJzM9NUoRROPaT7nMlNYQL+IwuthJd6XQqwzp1jRTGG26J97wARAQABiQM+BBgB AgAJBQJWJ3+kAhsCAikJEBaat7Gkz/iuwV0gBBkBAgAGBQJWJ3+kAAoJEHfc29rIyEnRk6MQ AJDo0nxsadLpYB26FALZsWlN74rnFXth5dQVQ7SkipmyFWZhFL8fQ9OiIoxWhM6rSg9+C1w+ n45eByMg2b8H3mmQmyWztdI95OxSREKwbaXVapCcZnv52JRjlc3DoiiHqTZML5x1Z7lQ1T3F 8o9sKrbFO1WQw1+Nc91+MU0MGN0jtfZ0Tvn/ouEZrSXCE4K3oDGtj3AdC764yZVq6CPigCgs 6Ex80k6QlzCdVP3RKsnPO2xQXXPgyJPJlpD8bHHHW7OLfoR9DaBNympfcbQJeekQrTvyoASw EOTPKE6CVWrcQIztUp0WFTdRGgMK0cZB3Xfe6sOp24PQTHAKGtjTHNP/THomkH24Fum9K3iM /4Wh4V2eqGEgpdeSp5K+LdaNyNgaqzMOtt4HYk86LYLSHfFXywdlbGrY9+TqiJ+ZVW4trmui NIJCOku8SYansq34QzYM0x3UFRwff+45zNBEVzctSnremg1mVgrzOfXU8rt+4N1b2MxorPF8 619aCwVP7U16qNSBaqiAJr4e5SNEnoAq18+1Gp8QsFG0ARY8xp+qaKBByWES7lRi3QbqAKZf yOHS6gmYo9gBmuAhc65/VtHMJtxwjpUeN4Bcs9HUpDMDVHdfeRa73wM+wY5potfQ5zkSp0Jp bxnv/cRBH6+c43stTffprd//4Hgz+nJcCgZKtCYIAPkUxABC85ID2CidzbraErVACmRoizhT KR2OiqSLW2x4xdmSiFNcIWkWJB6Qdri0Fzs2dHe8etD1HYaht1ZhZ810s7QOL7JwypO8dscN KTEkyoTGn6cWj0CX+PeP4xp8AR8ot4d0BhtUY34UPzjE1/xyrQFAdnLd0PP4wXxdIUuRs0+n WLY9Aou/vC1LAdlaGsoTVzJ2gX4fkKQIWhX0WVk41BSFeDKQ3RQ2pnuzwedLO94Bf6X0G48O VsbXrP9BZ6snXyHfebPnno/te5XRqZTL9aJOytB/1iUna+1MAwBxGFPvqeEUUyT+gx1l3Acl ZaTUOEkgIor5losDrePdPgE= Organization: Baylibre Message-ID: Date: Fri, 11 Oct 2019 14:07:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20191011105559.clttghy52wfdmb34@DESKTOP-E1NTVVP.localdomain> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191011_050707_297166_EE2F45E7 X-CRM114-Status: GOOD ( 30.28 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ayan Halder , "khilman@baylibre.com" , "dri-devel@lists.freedesktop.org" , "linux-amlogic@lists.infradead.org" , nd , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 11/10/2019 12:56, Brian Starkey wrote: > Hi, > > On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote: >> Hi Brian, >> >> On 11/10/2019 10:41, Brian Starkey wrote: >>> Hi Neil, >>> >>> On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote: >>>> Hi Ayan, >>>> >>>> On 10/10/2019 15:26, Ayan Halder wrote: >>>>> On Thu, Oct 10, 2019 at 11:25:23AM +0200, Neil Armstrong wrote: >>>>>> This adds all the OSD configuration plumbing to support the AFBC decoders >>>>>> path to display of the OSD1 plane. >>>>>> >>>>>> The Amlogic GXM and G12A AFBC decoders are integrated very differently. >>>>>> >>>>>> The Amlogic GXM has a direct output path to the OSD1 VIU pixel input, >>>>>> because the GXM AFBC decoder seem to be a custom IP developed by Amlogic. >>>>>> >>>>>> On the other side, the Amlogic G12A AFBC decoder seems to be an external >>>>>> IP that emit pixels on an AXI master hooked to a "Mali Unpack" block >>>>>> feeding the OSD1 VIU pixel input. >>>>>> This uses a weird "0x1000000" internal HW physical address on both >>>>>> sides to transfer the pixels. >>>>>> >>>>>> For Amlogic GXM, the supported pixel formats are the same as the normal >>>>>> linear OSD1 mode. >>>>>> >>>>>> On the other side, Amlogic added support for all AFBC v1.2 formats for >>>>>> the G12A AFBC integration. >>>>>> >>>>>> For simplicity, we stick to the already supported formats for now. >>>>>> >>>>>> Signed-off-by: Neil Armstrong >>>>>> --- >>>>>> drivers/gpu/drm/meson/meson_crtc.c | 2 + >>>>>> drivers/gpu/drm/meson/meson_drv.h | 4 + >>>>>> drivers/gpu/drm/meson/meson_plane.c | 215 ++++++++++++++++++++++++---- >>>>>> 3 files changed, 190 insertions(+), 31 deletions(-) >>>>>> >>>>>> diff --git a/drivers/gpu/drm/meson/meson_crtc.c b/drivers/gpu/drm/meson/meson_crtc.c >>>>>> index 57ae1c13d1e6..d478fa232951 100644 >>>>>> --- a/drivers/gpu/drm/meson/meson_crtc.c >>>>>> +++ b/drivers/gpu/drm/meson/meson_crtc.c >>>>>> @@ -281,6 +281,8 @@ void meson_crtc_irq(struct meson_drm *priv) >>>>>> if (priv->viu.osd1_enabled && priv->viu.osd1_commit) { >>>>>> writel_relaxed(priv->viu.osd1_ctrl_stat, >>>>>> priv->io_base + _REG(VIU_OSD1_CTRL_STAT)); >>>>>> + writel_relaxed(priv->viu.osd1_ctrl_stat2, >>>>>> + priv->io_base + _REG(VIU_OSD1_CTRL_STAT2)); >>>>>> writel_relaxed(priv->viu.osd1_blk0_cfg[0], >>>>>> priv->io_base + _REG(VIU_OSD1_BLK0_CFG_W0)); >>>>>> writel_relaxed(priv->viu.osd1_blk0_cfg[1], >>>>>> diff --git a/drivers/gpu/drm/meson/meson_drv.h b/drivers/gpu/drm/meson/meson_drv.h >>>>>> index 60f13c6f34e5..de25349be8aa 100644 >>>>>> --- a/drivers/gpu/drm/meson/meson_drv.h >>>>>> +++ b/drivers/gpu/drm/meson/meson_drv.h >>>>>> @@ -53,8 +53,12 @@ struct meson_drm { >>>>>> bool osd1_enabled; >>>>>> bool osd1_interlace; >>>>>> bool osd1_commit; >>>>>> + bool osd1_afbcd; >>>>>> uint32_t osd1_ctrl_stat; >>>>>> + uint32_t osd1_ctrl_stat2; >>>>>> uint32_t osd1_blk0_cfg[5]; >>>>>> + uint32_t osd1_blk1_cfg4; >>>>>> + uint32_t osd1_blk2_cfg4; >>>>>> uint32_t osd1_addr; >>>>>> uint32_t osd1_stride; >>>>>> uint32_t osd1_height; >>>>>> diff --git a/drivers/gpu/drm/meson/meson_plane.c b/drivers/gpu/drm/meson/meson_plane.c >>>>>> index 5e798c276037..412941aa8402 100644 >>>>>> --- a/drivers/gpu/drm/meson/meson_plane.c >>>>>> +++ b/drivers/gpu/drm/meson/meson_plane.c >>>>>> @@ -23,6 +23,7 @@ >>>>>> #include "meson_plane.h" >>>>>> #include "meson_registers.h" >>>>>> #include "meson_viu.h" >>>>>> +#include "meson_osd_afbcd.h" >>>>>> >>>>>> /* OSD_SCI_WH_M1 */ >>>>>> #define SCI_WH_M1_W(w) FIELD_PREP(GENMASK(28, 16), w) >>>>>> @@ -92,12 +93,38 @@ static int meson_plane_atomic_check(struct drm_plane *plane, >>>>>> false, true); >>>>>> } >>>>>> >>>>>> +#define MESON_MOD_AFBC_VALID_BITS (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | \ >>>>>> + AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 | \ >>>>>> + AFBC_FORMAT_MOD_YTR | \ >>>>>> + AFBC_FORMAT_MOD_SPARSE | \ >>>>>> + AFBC_FORMAT_MOD_SPLIT) >>>>>> + >>>>>> /* Takes a fixed 16.16 number and converts it to integer. */ >>>>>> static inline int64_t fixed16_to_int(int64_t value) >>>>>> { >>>>>> return value >> 16; >>>>>> } >>>>>> >>>>>> +static u32 meson_g12a_afbcd_line_stride(struct meson_drm *priv) >>>>>> +{ >>>>>> + u32 line_stride = 0; >>>>>> + >>>>>> + switch (priv->afbcd.format) { >>>>>> + case DRM_FORMAT_RGB565: >>>>>> + line_stride = ((priv->viu.osd1_width << 4) + 127) >> 7; >>>>>> + break; >>>>>> + case DRM_FORMAT_RGB888: >>>>>> + case DRM_FORMAT_XRGB8888: >>>>>> + case DRM_FORMAT_ARGB8888: >>>>>> + case DRM_FORMAT_XBGR8888: >>>>>> + case DRM_FORMAT_ABGR8888: >>>>> Please have a look at >>>>> https://www.kernel.org/doc/html/latest/gpu/afbc.html for our >>>>> recommendation. We suggest that *X* formats are avoided. >>>>> >>>>> Also, for interoperability and maximum compression efficiency (with >>>>> AFBC_FORMAT_MOD_YTR), we suggest the following order :- >>>>> >>>>> Component 0: R >>>>> Component 1: G >>>>> Component 2: B >>>>> Component 3: A (if available) >>>> >>>> >>>> Sorry I don't understand, you ask me to limit AFBC to ABGR8888 ? >>>> >>>> But why if the HW (GPU and DPU) is capable of ? >>> >>> AFBC doesn't have an in-memory component order in the traditional >>> sense (i.e. a bit-position to component mapping), so Arm >>> have decided to define the convention that DRM_FORMAT_ABGR8888 >>> represents the AFBC layout with R in component 0. >> >> In this implementation, we handle the ARGB/ABGR as the same mode >> since the AFBC can only represent the layout as "ABGR" anyway. >> > > In this case, with the external AFBC IP, there's a whole extra layer > of potential confusion :-( > > The decoder only needs to know the number of components - so > irrespective of what color channel is mapped to what component, it can > always be configured with the same mode for 4-component 32-bit > formats. > > For everything to work correctly with YTR, the thing consuming the > output from the decoder must treat component 0 as 'R', but otherwise > it doesn't matter. > > Is your HW able to treat the decoder output in different ways? e.g. > mapping component 0 to 'B'? If that's the case, then exposing the > different orders is valid - but only ABGR should allow YTR. Yes, we can remap each components from AFBC in any order. Ok thanks for clarifying, so: - I'll allow only ABGR/XBGR with YTR - I'll allow ABGR/XBGR/ARGB/XRGB only if !YTR and use the AFBC components remapping for ARGB/XRGB I'll also need to clean up the RGB888/BGR888 as we support only RGB888 for now. And I'll reject RGB565 since we don't support it without AFBC. > >>> >>> Are you sure the GPU supports other orders? I think any Arm driver >>> will only be producing DRM_FORMATs with "BGR" order e.g. ABGR888> >>> I'm not convinced the GPU HW actually supports any other order, but >>> it's all rather confusing with texture swizzling. What I can tell you >>> for sure is that it _does_ support BGR order (in DRM naming >>> convention). >> >> Well, since the Bifrost Mali blobs are closed-source and delivered >> by licensees, it's hard to define what is supported from a closed >> GPU HW, closed SW implementation to a closed pixel format implementation. >> > > I hear you. IMO the only way to make any of this clear is to publish > reference data and tests which make sure implementations match each > other. It's something I'm trying to make happen. I'll be happy to run them when available and fix the implementation accordingly ! > >> You'll have to tell us if the closed libMali handling AFBC would accept >> ARGB8888 as format to render with AFBC enabled, if not you're right >> I'll discard XRGB8888/ARGB8888 for AFBC buffers completely. >> >> But it the libMali chooses tt generate an ARGB8888 buffer whatever >> ARGB8888/XRGB8888/ABGR888/XBGR888 is asked, then no I'll keep it that way. >> > > Yeah, I'll try and get clarity on this. It's not at all clear to me > either. When you say "accept ARGB8888 as format to render with AFBC > enabled", which API are you referring to, just so I can be clear? Do > you have an example of some code you're using to render AFBC with the > GPU blob? Let's take kmscube using EGL and GBM. The buffer is allocated using gbm_surface_create_with_modifiers(), but the gbm implementation is vendor specified. Then the surface is passed to eglCreateWindowSurface(). Then the format is matched using eglGetConfigAttrib() with the returned configs. Here support on the gbm and EGL implementation. > > In many APIs, there's no real expectation on in-memory component > order, so perhaps there treating them as all the same is acceptable. > > However, fourcc + AFBC modifier is explicit in terms of component > order, and so IMO it's very harmful to "ignore" component order in > interfaces using fourcc + AFBC modifier. > > There are implementations which support other orders, so ignoring > order will break those implementations. In some cases (Android, maybe > GL), this can be hidden behind "driver magic", but if the API is > fourcc + AFBC modifier, IMO it had better be completely explicit with > no tricks - irrespective of whatever other less-prescriptive APIs do. Sure > >> BTW I kept the vendor implementation here, which may be wrong but since >> they have the AFBC IP license and Mali Bifrost GPU license... >> >>> >>> If you do choose to expose orders other than BGR/ABGR, then you should >>> certainly not allow YTR to be used with any orders other than >>> BGR/ABGR. The AFBC spec defines YTR as using R in component 0, which >>> Arm has defined as DRM_FORMAT_*BGR* (component 0 in LE LSBs). >>> >> >> The MAFBC_FMT_RGBA8888 pixel format is defined in the AFBC decoder, >> which seems to be an ARM IP, the registers documentation is in the >> SoC datasheet at [1] and the formats bits are defined in the patch 3 at [2]. >> >> So it seems the decoder handles only a single type for 32bit RGB buffer >> format, as Amlogic names it MAFBC_FMT_RGBA8888 >> > > Hopefully my comments at the beginning of this mail helps clear this > part up a bit. > >> For XRGB8888/XBGR8888 we simply "replace" the A component with a fixed >> value in the pixel generator. > > That seems correct, so long as the decoder is configured in the > 4-component mode. > >> >> [1] https://dl.khadas.com/Hardware/VIM3/Datasheet/S905D3_datasheet_0.2_Wesion.pdf page 772 >> [2] https://patchwork.freedesktop.org/patch/335199/?series=67832&rev=1 >> >>>> >>>> Isn't it an userspace choice ? I understand XRGB8888 is a waste >>>> of memory space and compression efficiency, but this is not the >>>> kernel driver's to decide this, right ? >>>> >>> >>> As long as it's agreed and understood what XRGB8888 means. It must be >>> an AFBC bitstream with 4-components, with B in component 0, G in >>> component 1, R in component 2 and 8 wasted bits in component 3. >> >> Yes, but this is something userspace must assume, and it's already >> wasted in the linear XRGB8888 format anyway. >> >>> >>> I know of HW which treats "XBGR" with AFBC as a 3-component format, >>> which isn't correct but can easily lead to confusion and >>> incompatibility. >> >> Seems it's not the case here, at least for the G12A SoC family. > > That's good :-) > >> >>> >>>> For interoperability I'll understand recommending a minimal set >>>> of modifiers and formats. But here, each platform is also limited >>>> by it's GPU capabilites aswell. >>>> >>> >>> The (Arm) GPUs support ABGR ordering, so if everyone sticks to that we >>> can make sure everything's nice and compatible (until someone turns up >>> with HW which _doesn't_ support that ordering). >> >> This is not clean enough in the https://www.kernel.org/doc/html/latest/gpu/afbc.html >> document. Since ARM is in control of the renderers, saying AFBC does _not_ >> support another components format as ABGR ordering in all the >> OpenGL ES/Vulkan implementations, it would be clear we couldn't render >> anything using AFBC with ARGB. >> But we hit the closed-source/closed-specifications here again. >> > > I didn't really understand the middle sentence. > > I know and understand that the "closed-ness" is a problem. The page > you linked was an initial attempt at making a clear, public > specification. > > What I need to be clear about, though, is that it describes _only_ > cases where DRM fourcc + AFBC modifier are used. I don't think there's > any sane way to apply it to other APIs, because the formats are > described differently, and the "leeway" allowed for doing things > "under-the-hood" is very different. Indeed > >>> >>>> Limiting to ABGR8888 would discard like every non-Android renderers, >>>> using AFBC, I'm not sure it's the kernels driver's responsibility. >>>> >>> >>> It prevents renderers with hard-coded pixel formats, perhaps. But >>> those are already fragile by nature, surely? >> >> Well, except Android, all the other renderers uses ARGB8888/XRGB8888, >> as fixed pixel format, which is quite a large amount of code. >> > > I think whether that matters or not really depends on which graphics > APIs you're referring to. IMO it's inevitable that modifiers don't > simply "drop in" everywhere. The kernel API allows you to query what's > supported and pick that. Sure, we'll need to add an extra layer to discover the GL API capabilities vs the DRM Display driver capabilities in term of fourcc+modifiers at some point. This may be an goal for the liboutput library ! Thanks, Neil > > Thanks, > -Brian > >> >> Anyway, thanks for these technical clarifications, it makes things >> much more clearer. >> >> Neil >> >>> >>> Cheers, >>> -Brian >>> >>>>> >>>>> Thus, DRM_FORMAT_ABGR, DRM_FORMAT_BGR should only be allowed. >>>>>> + line_stride = ((priv->viu.osd1_width << 5) + 127) >> 7; >>>>>> + break; >>>>>> + } >>>>>> + >>>>>> + return ((line_stride + 1) >> 1) << 1; >>>>>> +} >>>>>> + >>>>>> static void meson_plane_atomic_update(struct drm_plane *plane, >>>>>> struct drm_plane_state *old_state) >>>>>> { >>>> >>>> [...] >>>> >>>>>> >>>>>> +static bool meson_plane_format_mod_supported(struct drm_plane *plane, >>>>>> + u32 format, u64 modifier) >>>>>> +{ >>>>>> + struct meson_plane *meson_plane = to_meson_plane(plane); >>>>>> + struct meson_drm *priv = meson_plane->priv; >>>>>> + int i; >>>>>> + >>>>>> + if (modifier == DRM_FORMAT_MOD_INVALID) >>>>>> + return false; >>>>>> + >>>>>> + if (modifier == DRM_FORMAT_MOD_LINEAR) >>>>>> + return true; >>>>>> + >>>>>> + if (!meson_vpu_is_compatible(priv, VPU_COMPATIBLE_GXM) && >>>>>> + !meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) >>>>>> + return false; >>>>>> + >>>>>> + if (modifier & ~DRM_FORMAT_MOD_ARM_AFBC(MESON_MOD_AFBC_VALID_BITS)) >>>>>> + return false; >>>>>> + >>>>>> + for (i = 0 ; i < plane->modifier_count ; ++i) >>>>>> + if (plane->modifiers[i] == modifier) >>>>>> + break; >>>>>> + >>>>>> + if (i == plane->modifier_count) { >>>>>> + DRM_DEBUG_KMS("Unsupported modifier\n"); >>>>>> + return false; >>>>>> + } >>>> >>>> I can add a warn_once here, would it be enough ? >>>> >>>>>> + >>>>>> + if (priv->afbcd.ops && priv->afbcd.ops->supported_fmt) >>>>>> + return priv->afbcd.ops->supported_fmt(modifier, format); >>>>>> + >>>>>> + DRM_DEBUG_KMS("AFBC Unsupported\n"); >>>>>> + return false; >>>>>> +} >>>>>> + >>>>>> static const struct drm_plane_funcs meson_plane_funcs = { >>>>>> .update_plane = drm_atomic_helper_update_plane, >>>>>> .disable_plane = drm_atomic_helper_disable_plane, >>>>>> @@ -353,6 +457,7 @@ static const struct drm_plane_funcs meson_plane_funcs = { >>>>>> .reset = drm_atomic_helper_plane_reset, >>>>>> .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state, >>>>>> .atomic_destroy_state = drm_atomic_helper_plane_destroy_state, >>>>>> + .format_mod_supported = meson_plane_format_mod_supported, >>>>>> }; >>>>>> >>>>>> static const uint32_t supported_drm_formats[] = { >>>>>> @@ -364,10 +469,53 @@ static const uint32_t supported_drm_formats[] = { >>>>>> DRM_FORMAT_RGB565, >>>>>> }; >>>>>> >>>>>> +static const uint64_t format_modifiers_afbc_gxm[] = { >>>>>> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | >>>>>> + AFBC_FORMAT_MOD_SPARSE | >>>>>> + AFBC_FORMAT_MOD_YTR), >>>>>> + /* SPLIT mandates SPARSE, RGB modes mandates YTR */ >>>>>> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | >>>>>> + AFBC_FORMAT_MOD_YTR | >>>>>> + AFBC_FORMAT_MOD_SPARSE | >>>>>> + AFBC_FORMAT_MOD_SPLIT), >>>>>> + DRM_FORMAT_MOD_LINEAR, >>>>>> + DRM_FORMAT_MOD_INVALID, >>>>>> +}; >>>>>> + >>>>>> +static const uint64_t format_modifiers_afbc_g12a[] = { >>>>>> + /* >>>>>> + * - TOFIX Support AFBC modifiers for YUV formats (16x16 + TILED) >>>>>> + * - AFBC_FORMAT_MOD_YTR is mandatory since we only support RGB >>>>>> + * - SPLIT is mandatory for performances reasons when in 16x16 >>>>>> + * block size >>>>>> + * - 32x8 block size + SPLIT is mandatory with 4K frame size >>>>>> + * for performances reasons >>>>>> + */ >>>>>> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | >>>>>> + AFBC_FORMAT_MOD_YTR | >>>>>> + AFBC_FORMAT_MOD_SPARSE | >>>>>> + AFBC_FORMAT_MOD_SPLIT), >>>>>> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 | >>>>>> + AFBC_FORMAT_MOD_YTR | >>>>>> + AFBC_FORMAT_MOD_SPARSE), >>>>>> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 | >>>>>> + AFBC_FORMAT_MOD_YTR | >>>>>> + AFBC_FORMAT_MOD_SPARSE | >>>>>> + AFBC_FORMAT_MOD_SPLIT), >>>>>> + DRM_FORMAT_MOD_LINEAR, >>>>>> + DRM_FORMAT_MOD_INVALID, >>>>>> +}; >>>>>> + >>>>>> +static const uint64_t format_modifiers_default[] = { >>>>>> + DRM_FORMAT_MOD_LINEAR, >>>>>> + DRM_FORMAT_MOD_INVALID, >>>>>> +}; >>>>>> + >>>>>> int meson_plane_create(struct meson_drm *priv) >>>>>> { >>>>>> struct meson_plane *meson_plane; >>>>>> struct drm_plane *plane; >>>>>> + const uint64_t *format_modifiers = format_modifiers_default; >>>>>> >>>>>> meson_plane = devm_kzalloc(priv->drm->dev, sizeof(*meson_plane), >>>>>> GFP_KERNEL); >>>>>> @@ -377,11 +525,16 @@ int meson_plane_create(struct meson_drm *priv) >>>>>> meson_plane->priv = priv; >>>>>> plane = &meson_plane->base; >>>>>> >>>>>> + if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_GXM)) >>>>>> + format_modifiers = format_modifiers_afbc_gxm; >>>>>> + else if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) >>>>>> + format_modifiers = format_modifiers_afbc_g12a; >>>>>> + >>>>>> drm_universal_plane_init(priv->drm, plane, 0xFF, >>>>>> &meson_plane_funcs, >>>>>> supported_drm_formats, >>>>>> ARRAY_SIZE(supported_drm_formats), >>>>>> - NULL, >>>>>> + format_modifiers, >>>>>> DRM_PLANE_TYPE_PRIMARY, "meson_primary_plane"); >>>>>> >>>>>> drm_plane_helper_add(plane, &meson_plane_helper_funcs); >>>>>> -- >>>>>> 2.22.0 >>>> >>>> _______________________________________________ >>>> dri-devel mailing list >>>> dri-devel@lists.freedesktop.org >>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Armstrong Subject: Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane Date: Fri, 11 Oct 2019 14:07:01 +0200 Message-ID: References: <20191010092526.10419-1-narmstrong@baylibre.com> <20191010092526.10419-5-narmstrong@baylibre.com> <20191010132601.GA10110@arm.com> <44f1771f-d640-f23d-995f-7bfcadd213bc@baylibre.com> <20191011084108.i7lfh2d7asfmcdk4@DESKTOP-E1NTVVP.localdomain> <20191011105559.clttghy52wfdmb34@DESKTOP-E1NTVVP.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by gabe.freedesktop.org (Postfix) with ESMTPS id D17316EC27 for ; Fri, 11 Oct 2019 12:07:04 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id h4so11660028wrv.7 for ; Fri, 11 Oct 2019 05:07:04 -0700 (PDT) In-Reply-To: <20191011105559.clttghy52wfdmb34@DESKTOP-E1NTVVP.localdomain> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Brian Starkey Cc: Ayan Halder , "khilman@baylibre.com" , "dri-devel@lists.freedesktop.org" , "linux-amlogic@lists.infradead.org" , nd , "linux-arm-kernel@lists.infradead.org" List-Id: dri-devel@lists.freedesktop.org T24gMTEvMTAvMjAxOSAxMjo1NiwgQnJpYW4gU3RhcmtleSB3cm90ZToKPiBIaSwKPiAKPiBPbiBG cmksIE9jdCAxMSwgMjAxOSBhdCAxMToxNDo0M0FNICswMjAwLCBOZWlsIEFybXN0cm9uZyB3cm90 ZToKPj4gSGkgQnJpYW4sCj4+Cj4+IE9uIDExLzEwLzIwMTkgMTA6NDEsIEJyaWFuIFN0YXJrZXkg d3JvdGU6Cj4+PiBIaSBOZWlsLAo+Pj4KPj4+IE9uIFRodSwgT2N0IDEwLCAyMDE5IGF0IDAzOjQx OjE1UE0gKzAyMDAsIE5laWwgQXJtc3Ryb25nIHdyb3RlOgo+Pj4+IEhpIEF5YW4sCj4+Pj4KPj4+ PiBPbiAxMC8xMC8yMDE5IDE1OjI2LCBBeWFuIEhhbGRlciB3cm90ZToKPj4+Pj4gT24gVGh1LCBP Y3QgMTAsIDIwMTkgYXQgMTE6MjU6MjNBTSArMDIwMCwgTmVpbCBBcm1zdHJvbmcgd3JvdGU6Cj4+ Pj4+PiBUaGlzIGFkZHMgYWxsIHRoZSBPU0QgY29uZmlndXJhdGlvbiBwbHVtYmluZyB0byBzdXBw b3J0IHRoZSBBRkJDIGRlY29kZXJzCj4+Pj4+PiBwYXRoIHRvIGRpc3BsYXkgb2YgdGhlIE9TRDEg cGxhbmUuCj4+Pj4+Pgo+Pj4+Pj4gVGhlIEFtbG9naWMgR1hNIGFuZCBHMTJBIEFGQkMgZGVjb2Rl cnMgYXJlIGludGVncmF0ZWQgdmVyeSBkaWZmZXJlbnRseS4KPj4+Pj4+Cj4+Pj4+PiBUaGUgQW1s b2dpYyBHWE0gaGFzIGEgZGlyZWN0IG91dHB1dCBwYXRoIHRvIHRoZSBPU0QxIFZJVSBwaXhlbCBp bnB1dCwKPj4+Pj4+IGJlY2F1c2UgdGhlIEdYTSBBRkJDIGRlY29kZXIgc2VlbSB0byBiZSBhIGN1 c3RvbSBJUCBkZXZlbG9wZWQgYnkgQW1sb2dpYy4KPj4+Pj4+Cj4+Pj4+PiBPbiB0aGUgb3RoZXIg c2lkZSwgdGhlIEFtbG9naWMgRzEyQSBBRkJDIGRlY29kZXIgc2VlbXMgdG8gYmUgYW4gZXh0ZXJu YWwKPj4+Pj4+IElQIHRoYXQgZW1pdCBwaXhlbHMgb24gYW4gQVhJIG1hc3RlciBob29rZWQgdG8g YSAiTWFsaSBVbnBhY2siIGJsb2NrCj4+Pj4+PiBmZWVkaW5nIHRoZSBPU0QxIFZJVSBwaXhlbCBp bnB1dC4KPj4+Pj4+IFRoaXMgdXNlcyBhIHdlaXJkICIweDEwMDAwMDAiIGludGVybmFsIEhXIHBo eXNpY2FsIGFkZHJlc3Mgb24gYm90aAo+Pj4+Pj4gc2lkZXMgdG8gdHJhbnNmZXIgdGhlIHBpeGVs cy4KPj4+Pj4+Cj4+Pj4+PiBGb3IgQW1sb2dpYyBHWE0sIHRoZSBzdXBwb3J0ZWQgcGl4ZWwgZm9y bWF0cyBhcmUgdGhlIHNhbWUgYXMgdGhlIG5vcm1hbAo+Pj4+Pj4gbGluZWFyIE9TRDEgbW9kZS4K Pj4+Pj4+Cj4+Pj4+PiBPbiB0aGUgb3RoZXIgc2lkZSwgQW1sb2dpYyBhZGRlZCBzdXBwb3J0IGZv ciBhbGwgQUZCQyB2MS4yIGZvcm1hdHMgZm9yCj4+Pj4+PiB0aGUgRzEyQSBBRkJDIGludGVncmF0 aW9uLgo+Pj4+Pj4KPj4+Pj4+IEZvciBzaW1wbGljaXR5LCB3ZSBzdGljayB0byB0aGUgYWxyZWFk eSBzdXBwb3J0ZWQgZm9ybWF0cyBmb3Igbm93Lgo+Pj4+Pj4KPj4+Pj4+IFNpZ25lZC1vZmYtYnk6 IE5laWwgQXJtc3Ryb25nIDxuYXJtc3Ryb25nQGJheWxpYnJlLmNvbT4KPj4+Pj4+IC0tLQo+Pj4+ Pj4gIGRyaXZlcnMvZ3B1L2RybS9tZXNvbi9tZXNvbl9jcnRjLmMgIHwgICAyICsKPj4+Pj4+ICBk cml2ZXJzL2dwdS9kcm0vbWVzb24vbWVzb25fZHJ2LmggICB8ICAgNCArCj4+Pj4+PiAgZHJpdmVy cy9ncHUvZHJtL21lc29uL21lc29uX3BsYW5lLmMgfCAyMTUgKysrKysrKysrKysrKysrKysrKysr KysrLS0tLQo+Pj4+Pj4gIDMgZmlsZXMgY2hhbmdlZCwgMTkwIGluc2VydGlvbnMoKyksIDMxIGRl bGV0aW9ucygtKQo+Pj4+Pj4KPj4+Pj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2dwdS9kcm0vbWVz b24vbWVzb25fY3J0Yy5jIGIvZHJpdmVycy9ncHUvZHJtL21lc29uL21lc29uX2NydGMuYwo+Pj4+ Pj4gaW5kZXggNTdhZTFjMTNkMWU2Li5kNDc4ZmEyMzI5NTEgMTAwNjQ0Cj4+Pj4+PiAtLS0gYS9k cml2ZXJzL2dwdS9kcm0vbWVzb24vbWVzb25fY3J0Yy5jCj4+Pj4+PiArKysgYi9kcml2ZXJzL2dw dS9kcm0vbWVzb24vbWVzb25fY3J0Yy5jCj4+Pj4+PiBAQCAtMjgxLDYgKzI4MSw4IEBAIHZvaWQg bWVzb25fY3J0Y19pcnEoc3RydWN0IG1lc29uX2RybSAqcHJpdikKPj4+Pj4+ICAJaWYgKHByaXYt PnZpdS5vc2QxX2VuYWJsZWQgJiYgcHJpdi0+dml1Lm9zZDFfY29tbWl0KSB7Cj4+Pj4+PiAgCQl3 cml0ZWxfcmVsYXhlZChwcml2LT52aXUub3NkMV9jdHJsX3N0YXQsCj4+Pj4+PiAgCQkJCXByaXYt PmlvX2Jhc2UgKyBfUkVHKFZJVV9PU0QxX0NUUkxfU1RBVCkpOwo+Pj4+Pj4gKwkJd3JpdGVsX3Jl bGF4ZWQocHJpdi0+dml1Lm9zZDFfY3RybF9zdGF0MiwKPj4+Pj4+ICsJCQkJcHJpdi0+aW9fYmFz ZSArIF9SRUcoVklVX09TRDFfQ1RSTF9TVEFUMikpOwo+Pj4+Pj4gIAkJd3JpdGVsX3JlbGF4ZWQo cHJpdi0+dml1Lm9zZDFfYmxrMF9jZmdbMF0sCj4+Pj4+PiAgCQkJCXByaXYtPmlvX2Jhc2UgKyBf UkVHKFZJVV9PU0QxX0JMSzBfQ0ZHX1cwKSk7Cj4+Pj4+PiAgCQl3cml0ZWxfcmVsYXhlZChwcml2 LT52aXUub3NkMV9ibGswX2NmZ1sxXSwKPj4+Pj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2dwdS9k cm0vbWVzb24vbWVzb25fZHJ2LmggYi9kcml2ZXJzL2dwdS9kcm0vbWVzb24vbWVzb25fZHJ2LmgK Pj4+Pj4+IGluZGV4IDYwZjEzYzZmMzRlNS4uZGUyNTM0OWJlOGFhIDEwMDY0NAo+Pj4+Pj4gLS0t IGEvZHJpdmVycy9ncHUvZHJtL21lc29uL21lc29uX2Rydi5oCj4+Pj4+PiArKysgYi9kcml2ZXJz L2dwdS9kcm0vbWVzb24vbWVzb25fZHJ2LmgKPj4+Pj4+IEBAIC01Myw4ICs1MywxMiBAQCBzdHJ1 Y3QgbWVzb25fZHJtIHsKPj4+Pj4+ICAJCWJvb2wgb3NkMV9lbmFibGVkOwo+Pj4+Pj4gIAkJYm9v bCBvc2QxX2ludGVybGFjZTsKPj4+Pj4+ICAJCWJvb2wgb3NkMV9jb21taXQ7Cj4+Pj4+PiArCQli b29sIG9zZDFfYWZiY2Q7Cj4+Pj4+PiAgCQl1aW50MzJfdCBvc2QxX2N0cmxfc3RhdDsKPj4+Pj4+ ICsJCXVpbnQzMl90IG9zZDFfY3RybF9zdGF0MjsKPj4+Pj4+ICAJCXVpbnQzMl90IG9zZDFfYmxr MF9jZmdbNV07Cj4+Pj4+PiArCQl1aW50MzJfdCBvc2QxX2JsazFfY2ZnNDsKPj4+Pj4+ICsJCXVp bnQzMl90IG9zZDFfYmxrMl9jZmc0Owo+Pj4+Pj4gIAkJdWludDMyX3Qgb3NkMV9hZGRyOwo+Pj4+ Pj4gIAkJdWludDMyX3Qgb3NkMV9zdHJpZGU7Cj4+Pj4+PiAgCQl1aW50MzJfdCBvc2QxX2hlaWdo dDsKPj4+Pj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2dwdS9kcm0vbWVzb24vbWVzb25fcGxhbmUu YyBiL2RyaXZlcnMvZ3B1L2RybS9tZXNvbi9tZXNvbl9wbGFuZS5jCj4+Pj4+PiBpbmRleCA1ZTc5 OGMyNzYwMzcuLjQxMjk0MWFhODQwMiAxMDA2NDQKPj4+Pj4+IC0tLSBhL2RyaXZlcnMvZ3B1L2Ry bS9tZXNvbi9tZXNvbl9wbGFuZS5jCj4+Pj4+PiArKysgYi9kcml2ZXJzL2dwdS9kcm0vbWVzb24v bWVzb25fcGxhbmUuYwo+Pj4+Pj4gQEAgLTIzLDYgKzIzLDcgQEAKPj4+Pj4+ICAjaW5jbHVkZSAi bWVzb25fcGxhbmUuaCIKPj4+Pj4+ICAjaW5jbHVkZSAibWVzb25fcmVnaXN0ZXJzLmgiCj4+Pj4+ PiAgI2luY2x1ZGUgIm1lc29uX3ZpdS5oIgo+Pj4+Pj4gKyNpbmNsdWRlICJtZXNvbl9vc2RfYWZi Y2QuaCIKPj4+Pj4+ICAKPj4+Pj4+ICAvKiBPU0RfU0NJX1dIX00xICovCj4+Pj4+PiAgI2RlZmlu ZSBTQ0lfV0hfTTFfVyh3KQkJCUZJRUxEX1BSRVAoR0VOTUFTSygyOCwgMTYpLCB3KQo+Pj4+Pj4g QEAgLTkyLDEyICs5MywzOCBAQCBzdGF0aWMgaW50IG1lc29uX3BsYW5lX2F0b21pY19jaGVjayhz dHJ1Y3QgZHJtX3BsYW5lICpwbGFuZSwKPj4+Pj4+ICAJCQkJCQkgICBmYWxzZSwgdHJ1ZSk7Cj4+ Pj4+PiAgfQo+Pj4+Pj4gIAo+Pj4+Pj4gKyNkZWZpbmUgTUVTT05fTU9EX0FGQkNfVkFMSURfQklU UyAoQUZCQ19GT1JNQVRfTU9EX0JMT0NLX1NJWkVfMTZ4MTYgfAlcCj4+Pj4+PiArCQkJCSAgIEFG QkNfRk9STUFUX01PRF9CTE9DS19TSVpFXzMyeDggfAlcCj4+Pj4+PiArCQkJCSAgIEFGQkNfRk9S TUFUX01PRF9ZVFIgfAkJXAo+Pj4+Pj4gKwkJCQkgICBBRkJDX0ZPUk1BVF9NT0RfU1BBUlNFIHwJ CVwKPj4+Pj4+ICsJCQkJICAgQUZCQ19GT1JNQVRfTU9EX1NQTElUKQo+Pj4+Pj4gKwo+Pj4+Pj4g IC8qIFRha2VzIGEgZml4ZWQgMTYuMTYgbnVtYmVyIGFuZCBjb252ZXJ0cyBpdCB0byBpbnRlZ2Vy LiAqLwo+Pj4+Pj4gIHN0YXRpYyBpbmxpbmUgaW50NjRfdCBmaXhlZDE2X3RvX2ludChpbnQ2NF90 IHZhbHVlKQo+Pj4+Pj4gIHsKPj4+Pj4+ICAJcmV0dXJuIHZhbHVlID4+IDE2Owo+Pj4+Pj4gIH0K Pj4+Pj4+ICAKPj4+Pj4+ICtzdGF0aWMgdTMyIG1lc29uX2cxMmFfYWZiY2RfbGluZV9zdHJpZGUo c3RydWN0IG1lc29uX2RybSAqcHJpdikKPj4+Pj4+ICt7Cj4+Pj4+PiArCXUzMiBsaW5lX3N0cmlk ZSA9IDA7Cj4+Pj4+PiArCj4+Pj4+PiArCXN3aXRjaCAocHJpdi0+YWZiY2QuZm9ybWF0KSB7Cj4+ Pj4+PiArCWNhc2UgRFJNX0ZPUk1BVF9SR0I1NjU6Cj4+Pj4+PiArCQlsaW5lX3N0cmlkZSA9ICgo cHJpdi0+dml1Lm9zZDFfd2lkdGggPDwgNCkgKyAxMjcpID4+IDc7Cj4+Pj4+PiArCQlicmVhazsK Pj4+Pj4+ICsJY2FzZSBEUk1fRk9STUFUX1JHQjg4ODoKPj4+Pj4+ICsJY2FzZSBEUk1fRk9STUFU X1hSR0I4ODg4Ogo+Pj4+Pj4gKwljYXNlIERSTV9GT1JNQVRfQVJHQjg4ODg6Cj4+Pj4+PiArCWNh c2UgRFJNX0ZPUk1BVF9YQkdSODg4ODoKPj4+Pj4+ICsJY2FzZSBEUk1fRk9STUFUX0FCR1I4ODg4 Ogo+Pj4+PiBQbGVhc2UgaGF2ZSBhIGxvb2sgYXQKPj4+Pj4gaHR0cHM6Ly93d3cua2VybmVsLm9y Zy9kb2MvaHRtbC9sYXRlc3QvZ3B1L2FmYmMuaHRtbCBmb3Igb3VyCj4+Pj4+IHJlY29tbWVuZGF0 aW9uLiBXZSBzdWdnZXN0IHRoYXQgKlgqIGZvcm1hdHMgYXJlIGF2b2lkZWQuCj4+Pj4+Cj4+Pj4+ IEFsc28sIGZvciBpbnRlcm9wZXJhYmlsaXR5IGFuZCBtYXhpbXVtIGNvbXByZXNzaW9uIGVmZmlj aWVuY3kgKHdpdGgKPj4+Pj4gQUZCQ19GT1JNQVRfTU9EX1lUUiksIHdlIHN1Z2dlc3QgdGhlIGZv bGxvd2luZyBvcmRlciA6LQo+Pj4+Pgo+Pj4+PiAgICAgICAgIENvbXBvbmVudCAwOiBSCj4+Pj4+ ICAgICAgICAgQ29tcG9uZW50IDE6IEcKPj4+Pj4gICAgICAgICBDb21wb25lbnQgMjogQgo+Pj4+ PiAgICAgICAgIENvbXBvbmVudCAzOiBBIChpZiBhdmFpbGFibGUpCj4+Pj4KPj4+Pgo+Pj4+IFNv cnJ5IEkgZG9uJ3QgdW5kZXJzdGFuZCwgeW91IGFzayBtZSB0byBsaW1pdCBBRkJDIHRvIEFCR1I4 ODg4ID8KPj4+Pgo+Pj4+IEJ1dCB3aHkgaWYgdGhlIEhXIChHUFUgYW5kIERQVSkgaXMgY2FwYWJs ZSBvZiA/Cj4+Pgo+Pj4gQUZCQyBkb2Vzbid0IGhhdmUgYW4gaW4tbWVtb3J5IGNvbXBvbmVudCBv cmRlciBpbiB0aGUgdHJhZGl0aW9uYWwKPj4+IHNlbnNlIChpLmUuIGEgYml0LXBvc2l0aW9uIHRv IGNvbXBvbmVudCBtYXBwaW5nKSwgc28gQXJtCj4+PiBoYXZlIGRlY2lkZWQgdG8gZGVmaW5lIHRo ZSBjb252ZW50aW9uIHRoYXQgRFJNX0ZPUk1BVF9BQkdSODg4OAo+Pj4gcmVwcmVzZW50cyB0aGUg QUZCQyBsYXlvdXQgd2l0aCBSIGluIGNvbXBvbmVudCAwLgo+Pgo+PiBJbiB0aGlzIGltcGxlbWVu dGF0aW9uLCB3ZSBoYW5kbGUgdGhlIEFSR0IvQUJHUiBhcyB0aGUgc2FtZSBtb2RlCj4+IHNpbmNl IHRoZSBBRkJDIGNhbiBvbmx5IHJlcHJlc2VudCB0aGUgbGF5b3V0IGFzICJBQkdSIiBhbnl3YXku Cj4+Cj4gCj4gSW4gdGhpcyBjYXNlLCB3aXRoIHRoZSBleHRlcm5hbCBBRkJDIElQLCB0aGVyZSdz IGEgd2hvbGUgZXh0cmEgbGF5ZXIKPiBvZiBwb3RlbnRpYWwgY29uZnVzaW9uIDotKAo+IAo+IFRo ZSBkZWNvZGVyIG9ubHkgbmVlZHMgdG8ga25vdyB0aGUgbnVtYmVyIG9mIGNvbXBvbmVudHMgLSBz bwo+IGlycmVzcGVjdGl2ZSBvZiB3aGF0IGNvbG9yIGNoYW5uZWwgaXMgbWFwcGVkIHRvIHdoYXQg Y29tcG9uZW50LCBpdCBjYW4KPiBhbHdheXMgYmUgY29uZmlndXJlZCB3aXRoIHRoZSBzYW1lIG1v ZGUgZm9yIDQtY29tcG9uZW50IDMyLWJpdAo+IGZvcm1hdHMuCj4gCj4gRm9yIGV2ZXJ5dGhpbmcg dG8gd29yayBjb3JyZWN0bHkgd2l0aCBZVFIsIHRoZSB0aGluZyBjb25zdW1pbmcgdGhlCj4gb3V0 cHV0IGZyb20gdGhlIGRlY29kZXIgbXVzdCB0cmVhdCBjb21wb25lbnQgMCBhcyAnUicsIGJ1dCBv dGhlcndpc2UKPiBpdCBkb2Vzbid0IG1hdHRlci4KPiAKPiBJcyB5b3VyIEhXIGFibGUgdG8gdHJl YXQgdGhlIGRlY29kZXIgb3V0cHV0IGluIGRpZmZlcmVudCB3YXlzPyBlLmcuCj4gbWFwcGluZyBj b21wb25lbnQgMCB0byAnQic/IElmIHRoYXQncyB0aGUgY2FzZSwgdGhlbiBleHBvc2luZyB0aGUK PiBkaWZmZXJlbnQgb3JkZXJzIGlzIHZhbGlkIC0gYnV0IG9ubHkgQUJHUiBzaG91bGQgYWxsb3cg WVRSLgoKWWVzLCB3ZSBjYW4gcmVtYXAgZWFjaCBjb21wb25lbnRzIGZyb20gQUZCQyBpbiBhbnkg b3JkZXIuCgpPayB0aGFua3MgZm9yIGNsYXJpZnlpbmcsIHNvOgotIEknbGwgYWxsb3cgb25seSBB QkdSL1hCR1Igd2l0aCBZVFIKLSBJJ2xsIGFsbG93IEFCR1IvWEJHUi9BUkdCL1hSR0Igb25seSBp ZiAhWVRSIGFuZCB1c2UgdGhlIEFGQkMgY29tcG9uZW50cyByZW1hcHBpbmcKZm9yIEFSR0IvWFJH QgoKSSdsbCBhbHNvIG5lZWQgdG8gY2xlYW4gdXAgdGhlIFJHQjg4OC9CR1I4ODggYXMgd2Ugc3Vw cG9ydCBvbmx5IFJHQjg4OCBmb3Igbm93LgoKQW5kIEknbGwgcmVqZWN0IFJHQjU2NSBzaW5jZSB3 ZSBkb24ndCBzdXBwb3J0IGl0IHdpdGhvdXQgQUZCQy4KCj4gCj4+Pgo+Pj4gQXJlIHlvdSBzdXJl IHRoZSBHUFUgc3VwcG9ydHMgb3RoZXIgb3JkZXJzPyBJIHRoaW5rIGFueSBBcm0gZHJpdmVyCj4+ PiB3aWxsIG9ubHkgYmUgcHJvZHVjaW5nIERSTV9GT1JNQVRzIHdpdGggIkJHUiIgb3JkZXIgZS5n LiBBQkdSODg4Pgo+Pj4gSSdtIG5vdCBjb252aW5jZWQgdGhlIEdQVSBIVyBhY3R1YWxseSBzdXBw b3J0cyBhbnkgb3RoZXIgb3JkZXIsIGJ1dAo+Pj4gaXQncyBhbGwgcmF0aGVyIGNvbmZ1c2luZyB3 aXRoIHRleHR1cmUgc3dpenpsaW5nLiBXaGF0IEkgY2FuIHRlbGwgeW91Cj4+PiBmb3Igc3VyZSBp cyB0aGF0IGl0IF9kb2VzXyBzdXBwb3J0IEJHUiBvcmRlciAoaW4gRFJNIG5hbWluZwo+Pj4gY29u dmVudGlvbikuCj4+Cj4+IFdlbGwsIHNpbmNlIHRoZSBCaWZyb3N0IE1hbGkgYmxvYnMgYXJlIGNs b3NlZC1zb3VyY2UgYW5kIGRlbGl2ZXJlZAo+PiBieSBsaWNlbnNlZXMsIGl0J3MgaGFyZCB0byBk ZWZpbmUgd2hhdCBpcyBzdXBwb3J0ZWQgZnJvbSBhIGNsb3NlZAo+PiBHUFUgSFcsIGNsb3NlZCBT VyBpbXBsZW1lbnRhdGlvbiB0byBhIGNsb3NlZCBwaXhlbCBmb3JtYXQgaW1wbGVtZW50YXRpb24u Cj4+Cj4gCj4gSSBoZWFyIHlvdS4gSU1PIHRoZSBvbmx5IHdheSB0byBtYWtlIGFueSBvZiB0aGlz IGNsZWFyIGlzIHRvIHB1Ymxpc2gKPiByZWZlcmVuY2UgZGF0YSBhbmQgdGVzdHMgd2hpY2ggbWFr ZSBzdXJlIGltcGxlbWVudGF0aW9ucyBtYXRjaCBlYWNoCj4gb3RoZXIuIEl0J3Mgc29tZXRoaW5n IEknbSB0cnlpbmcgdG8gbWFrZSBoYXBwZW4uCgpJJ2xsIGJlIGhhcHB5IHRvIHJ1biB0aGVtIHdo ZW4gYXZhaWxhYmxlIGFuZCBmaXggdGhlIGltcGxlbWVudGF0aW9uIGFjY29yZGluZ2x5ICEKCj4g Cj4+IFlvdSdsbCBoYXZlIHRvIHRlbGwgdXMgaWYgdGhlIGNsb3NlZCBsaWJNYWxpIGhhbmRsaW5n IEFGQkMgd291bGQgYWNjZXB0Cj4+IEFSR0I4ODg4IGFzIGZvcm1hdCB0byByZW5kZXIgd2l0aCBB RkJDIGVuYWJsZWQsIGlmIG5vdCB5b3UncmUgcmlnaHQKPj4gSSdsbCBkaXNjYXJkIFhSR0I4ODg4 L0FSR0I4ODg4IGZvciBBRkJDIGJ1ZmZlcnMgY29tcGxldGVseS4KPj4KPj4gQnV0IGl0IHRoZSBs aWJNYWxpIGNob29zZXMgdHQgZ2VuZXJhdGUgYW4gQVJHQjg4ODggYnVmZmVyIHdoYXRldmVyCj4+ IEFSR0I4ODg4L1hSR0I4ODg4L0FCR1I4ODgvWEJHUjg4OCBpcyBhc2tlZCwgdGhlbiBubyBJJ2xs IGtlZXAgaXQgdGhhdCB3YXkuCj4+Cj4gCj4gWWVhaCwgSSdsbCB0cnkgYW5kIGdldCBjbGFyaXR5 IG9uIHRoaXMuIEl0J3Mgbm90IGF0IGFsbCBjbGVhciB0byBtZQo+IGVpdGhlci4gV2hlbiB5b3Ug c2F5ICJhY2NlcHQgQVJHQjg4ODggYXMgZm9ybWF0IHRvIHJlbmRlciB3aXRoIEFGQkMKPiBlbmFi bGVkIiwgd2hpY2ggQVBJIGFyZSB5b3UgcmVmZXJyaW5nIHRvLCBqdXN0IHNvIEkgY2FuIGJlIGNs ZWFyPyBEbwo+IHlvdSBoYXZlIGFuIGV4YW1wbGUgb2Ygc29tZSBjb2RlIHlvdSdyZSB1c2luZyB0 byByZW5kZXIgQUZCQyB3aXRoIHRoZQo+IEdQVSBibG9iPwoKTGV0J3MgdGFrZSBrbXNjdWJlIHVz aW5nIEVHTCBhbmQgR0JNLgoKVGhlIGJ1ZmZlciBpcyBhbGxvY2F0ZWQgdXNpbmcgZ2JtX3N1cmZh Y2VfY3JlYXRlX3dpdGhfbW9kaWZpZXJzKCksCmJ1dCB0aGUgZ2JtIGltcGxlbWVudGF0aW9uIGlz IHZlbmRvciBzcGVjaWZpZWQuCgpUaGVuIHRoZSBzdXJmYWNlIGlzIHBhc3NlZCB0byBlZ2xDcmVh dGVXaW5kb3dTdXJmYWNlKCkuClRoZW4gdGhlIGZvcm1hdCBpcyBtYXRjaGVkIHVzaW5nIGVnbEdl dENvbmZpZ0F0dHJpYigpIHdpdGggdGhlCnJldHVybmVkIGNvbmZpZ3MuCgpIZXJlIHN1cHBvcnQg b24gdGhlIGdibSBhbmQgRUdMIGltcGxlbWVudGF0aW9uLgoKPiAKPiBJbiBtYW55IEFQSXMsIHRo ZXJlJ3Mgbm8gcmVhbCBleHBlY3RhdGlvbiBvbiBpbi1tZW1vcnkgY29tcG9uZW50Cj4gb3JkZXIs IHNvIHBlcmhhcHMgdGhlcmUgdHJlYXRpbmcgdGhlbSBhcyBhbGwgdGhlIHNhbWUgaXMgYWNjZXB0 YWJsZS4KPiAKPiBIb3dldmVyLCBmb3VyY2MgKyBBRkJDIG1vZGlmaWVyIGlzIGV4cGxpY2l0IGlu IHRlcm1zIG9mIGNvbXBvbmVudAo+IG9yZGVyLCBhbmQgc28gSU1PIGl0J3MgdmVyeSBoYXJtZnVs IHRvICJpZ25vcmUiIGNvbXBvbmVudCBvcmRlciBpbgo+IGludGVyZmFjZXMgdXNpbmcgZm91cmNj ICsgQUZCQyBtb2RpZmllci4KPiAKPiBUaGVyZSBhcmUgaW1wbGVtZW50YXRpb25zIHdoaWNoIHN1 cHBvcnQgb3RoZXIgb3JkZXJzLCBzbyBpZ25vcmluZwo+IG9yZGVyIHdpbGwgYnJlYWsgdGhvc2Ug aW1wbGVtZW50YXRpb25zLiBJbiBzb21lIGNhc2VzIChBbmRyb2lkLCBtYXliZQo+IEdMKSwgdGhp cyBjYW4gYmUgaGlkZGVuIGJlaGluZCAiZHJpdmVyIG1hZ2ljIiwgYnV0IGlmIHRoZSBBUEkgaXMK PiBmb3VyY2MgKyBBRkJDIG1vZGlmaWVyLCBJTU8gaXQgaGFkIGJldHRlciBiZSBjb21wbGV0ZWx5 IGV4cGxpY2l0IHdpdGgKPiBubyB0cmlja3MgLSBpcnJlc3BlY3RpdmUgb2Ygd2hhdGV2ZXIgb3Ro ZXIgbGVzcy1wcmVzY3JpcHRpdmUgQVBJcyBkby4KClN1cmUKCj4gCj4+IEJUVyBJIGtlcHQgdGhl IHZlbmRvciBpbXBsZW1lbnRhdGlvbiBoZXJlLCB3aGljaCBtYXkgYmUgd3JvbmcgYnV0IHNpbmNl Cj4+IHRoZXkgaGF2ZSB0aGUgQUZCQyBJUCBsaWNlbnNlIGFuZCBNYWxpIEJpZnJvc3QgR1BVIGxp Y2Vuc2UuLi4KPj4KPj4+Cj4+PiBJZiB5b3UgZG8gY2hvb3NlIHRvIGV4cG9zZSBvcmRlcnMgb3Ro ZXIgdGhhbiBCR1IvQUJHUiwgdGhlbiB5b3Ugc2hvdWxkCj4+PiBjZXJ0YWlubHkgbm90IGFsbG93 IFlUUiB0byBiZSB1c2VkIHdpdGggYW55IG9yZGVycyBvdGhlciB0aGFuCj4+PiBCR1IvQUJHUi4g VGhlIEFGQkMgc3BlYyBkZWZpbmVzIFlUUiBhcyB1c2luZyBSIGluIGNvbXBvbmVudCAwLCB3aGlj aAo+Pj4gQXJtIGhhcyBkZWZpbmVkIGFzIERSTV9GT1JNQVRfKkJHUiogKGNvbXBvbmVudCAwIGlu IExFIExTQnMpLgo+Pj4KPj4KPj4gVGhlIE1BRkJDX0ZNVF9SR0JBODg4OCBwaXhlbCBmb3JtYXQg aXMgZGVmaW5lZCBpbiB0aGUgQUZCQyBkZWNvZGVyLAo+PiB3aGljaCBzZWVtcyB0byBiZSBhbiBB Uk0gSVAsIHRoZSByZWdpc3RlcnMgZG9jdW1lbnRhdGlvbiBpcyBpbiB0aGUKPj4gU29DIGRhdGFz aGVldCBhdCBbMV0gYW5kIHRoZSBmb3JtYXRzIGJpdHMgYXJlIGRlZmluZWQgaW4gdGhlIHBhdGNo IDMgYXQgWzJdLgo+Pgo+PiBTbyBpdCBzZWVtcyB0aGUgZGVjb2RlciBoYW5kbGVzIG9ubHkgYSBz aW5nbGUgdHlwZSBmb3IgMzJiaXQgUkdCIGJ1ZmZlcgo+PiBmb3JtYXQsIGFzIEFtbG9naWMgbmFt ZXMgaXQgTUFGQkNfRk1UX1JHQkE4ODg4Cj4+Cj4gCj4gSG9wZWZ1bGx5IG15IGNvbW1lbnRzIGF0 IHRoZSBiZWdpbm5pbmcgb2YgdGhpcyBtYWlsIGhlbHBzIGNsZWFyIHRoaXMKPiBwYXJ0IHVwIGEg Yml0Lgo+IAo+PiBGb3IgWFJHQjg4ODgvWEJHUjg4ODggd2Ugc2ltcGx5ICJyZXBsYWNlIiB0aGUg QSBjb21wb25lbnQgd2l0aCBhIGZpeGVkCj4+IHZhbHVlIGluIHRoZSBwaXhlbCBnZW5lcmF0b3Iu Cj4gCj4gVGhhdCBzZWVtcyBjb3JyZWN0LCBzbyBsb25nIGFzIHRoZSBkZWNvZGVyIGlzIGNvbmZp Z3VyZWQgaW4gdGhlCj4gNC1jb21wb25lbnQgbW9kZS4KPiAKPj4KPj4gWzFdIGh0dHBzOi8vZGwu a2hhZGFzLmNvbS9IYXJkd2FyZS9WSU0zL0RhdGFzaGVldC9TOTA1RDNfZGF0YXNoZWV0XzAuMl9X ZXNpb24ucGRmIHBhZ2UgNzcyCj4+IFsyXSBodHRwczovL3BhdGNod29yay5mcmVlZGVza3RvcC5v cmcvcGF0Y2gvMzM1MTk5Lz9zZXJpZXM9Njc4MzImcmV2PTEKPj4KPj4+Pgo+Pj4+IElzbid0IGl0 IGFuIHVzZXJzcGFjZSBjaG9pY2UgPyBJIHVuZGVyc3RhbmQgWFJHQjg4ODggaXMgYSB3YXN0ZQo+ Pj4+IG9mIG1lbW9yeSBzcGFjZSBhbmQgY29tcHJlc3Npb24gZWZmaWNpZW5jeSwgYnV0IHRoaXMg aXMgbm90IHRoZQo+Pj4+IGtlcm5lbCBkcml2ZXIncyB0byBkZWNpZGUgdGhpcywgcmlnaHQgPwo+ Pj4+Cj4+Pgo+Pj4gQXMgbG9uZyBhcyBpdCdzIGFncmVlZCBhbmQgdW5kZXJzdG9vZCB3aGF0IFhS R0I4ODg4IG1lYW5zLiBJdCBtdXN0IGJlCj4+PiBhbiBBRkJDIGJpdHN0cmVhbSB3aXRoIDQtY29t cG9uZW50cywgd2l0aCBCIGluIGNvbXBvbmVudCAwLCBHIGluCj4+PiBjb21wb25lbnQgMSwgUiBp biBjb21wb25lbnQgMiBhbmQgOCB3YXN0ZWQgYml0cyBpbiBjb21wb25lbnQgMy4KPj4KPj4gWWVz LCBidXQgdGhpcyBpcyBzb21ldGhpbmcgdXNlcnNwYWNlIG11c3QgYXNzdW1lLCBhbmQgaXQncyBh bHJlYWR5Cj4+IHdhc3RlZCBpbiB0aGUgbGluZWFyIFhSR0I4ODg4IGZvcm1hdCBhbnl3YXkuCj4+ Cj4+Pgo+Pj4gSSBrbm93IG9mIEhXIHdoaWNoIHRyZWF0cyAiWEJHUiIgd2l0aCBBRkJDIGFzIGEg My1jb21wb25lbnQgZm9ybWF0LAo+Pj4gd2hpY2ggaXNuJ3QgY29ycmVjdCBidXQgY2FuIGVhc2ls eSBsZWFkIHRvIGNvbmZ1c2lvbiBhbmQKPj4+IGluY29tcGF0aWJpbGl0eS4KPj4KPj4gU2VlbXMg aXQncyBub3QgdGhlIGNhc2UgaGVyZSwgYXQgbGVhc3QgZm9yIHRoZSBHMTJBIFNvQyBmYW1pbHku Cj4gCj4gVGhhdCdzIGdvb2QgOi0pCj4gCj4+Cj4+Pgo+Pj4+IEZvciBpbnRlcm9wZXJhYmlsaXR5 IEknbGwgdW5kZXJzdGFuZCByZWNvbW1lbmRpbmcgYSBtaW5pbWFsIHNldAo+Pj4+IG9mIG1vZGlm aWVycyBhbmQgZm9ybWF0cy4gQnV0IGhlcmUsIGVhY2ggcGxhdGZvcm0gaXMgYWxzbyBsaW1pdGVk Cj4+Pj4gYnkgaXQncyBHUFUgY2FwYWJpbGl0ZXMgYXN3ZWxsLgo+Pj4+Cj4+Pgo+Pj4gVGhlIChB cm0pIEdQVXMgc3VwcG9ydCBBQkdSIG9yZGVyaW5nLCBzbyBpZiBldmVyeW9uZSBzdGlja3MgdG8g dGhhdCB3ZQo+Pj4gY2FuIG1ha2Ugc3VyZSBldmVyeXRoaW5nJ3MgbmljZSBhbmQgY29tcGF0aWJs ZSAodW50aWwgc29tZW9uZSB0dXJucyB1cAo+Pj4gd2l0aCBIVyB3aGljaCBfZG9lc24ndF8gc3Vw cG9ydCB0aGF0IG9yZGVyaW5nKS4KPj4KPj4gVGhpcyBpcyBub3QgY2xlYW4gZW5vdWdoIGluIHRo ZSBodHRwczovL3d3dy5rZXJuZWwub3JnL2RvYy9odG1sL2xhdGVzdC9ncHUvYWZiYy5odG1sCj4+ IGRvY3VtZW50LiBTaW5jZSBBUk0gaXMgaW4gY29udHJvbCBvZiB0aGUgcmVuZGVyZXJzLCBzYXlp bmcgQUZCQyBkb2VzIF9ub3RfCj4+IHN1cHBvcnQgYW5vdGhlciBjb21wb25lbnRzIGZvcm1hdCBh cyBBQkdSIG9yZGVyaW5nIGluIGFsbCB0aGUKPj4gT3BlbkdMIEVTL1Z1bGthbiBpbXBsZW1lbnRh dGlvbnMsIGl0IHdvdWxkIGJlIGNsZWFyIHdlIGNvdWxkbid0IHJlbmRlcgo+PiBhbnl0aGluZyB1 c2luZyBBRkJDIHdpdGggQVJHQi4KPj4gQnV0IHdlIGhpdCB0aGUgY2xvc2VkLXNvdXJjZS9jbG9z ZWQtc3BlY2lmaWNhdGlvbnMgaGVyZSBhZ2Fpbi4KPj4KPiAKPiBJIGRpZG4ndCByZWFsbHkgdW5k ZXJzdGFuZCB0aGUgbWlkZGxlIHNlbnRlbmNlLgo+IAo+IEkga25vdyBhbmQgdW5kZXJzdGFuZCB0 aGF0IHRoZSAiY2xvc2VkLW5lc3MiIGlzIGEgcHJvYmxlbS4gVGhlIHBhZ2UKPiB5b3UgbGlua2Vk IHdhcyBhbiBpbml0aWFsIGF0dGVtcHQgYXQgbWFraW5nIGEgY2xlYXIsIHB1YmxpYwo+IHNwZWNp ZmljYXRpb24uCj4gCj4gV2hhdCBJIG5lZWQgdG8gYmUgY2xlYXIgYWJvdXQsIHRob3VnaCwgaXMg dGhhdCBpdCBkZXNjcmliZXMgX29ubHlfCj4gY2FzZXMgd2hlcmUgRFJNIGZvdXJjYyArIEFGQkMg bW9kaWZpZXIgYXJlIHVzZWQuIEkgZG9uJ3QgdGhpbmsgdGhlcmUncwo+IGFueSBzYW5lIHdheSB0 byBhcHBseSBpdCB0byBvdGhlciBBUElzLCBiZWNhdXNlIHRoZSBmb3JtYXRzIGFyZQo+IGRlc2Ny aWJlZCBkaWZmZXJlbnRseSwgYW5kIHRoZSAibGVld2F5IiBhbGxvd2VkIGZvciBkb2luZyB0aGlu Z3MKPiAidW5kZXItdGhlLWhvb2QiIGlzIHZlcnkgZGlmZmVyZW50LgoKSW5kZWVkCgo+IAo+Pj4K Pj4+PiBMaW1pdGluZyB0byBBQkdSODg4OCB3b3VsZCBkaXNjYXJkIGxpa2UgZXZlcnkgbm9uLUFu ZHJvaWQgcmVuZGVyZXJzLAo+Pj4+IHVzaW5nIEFGQkMsIEknbSBub3Qgc3VyZSBpdCdzIHRoZSBr ZXJuZWxzIGRyaXZlcidzIHJlc3BvbnNpYmlsaXR5Lgo+Pj4+Cj4+Pgo+Pj4gSXQgcHJldmVudHMg cmVuZGVyZXJzIHdpdGggaGFyZC1jb2RlZCBwaXhlbCBmb3JtYXRzLCBwZXJoYXBzLiBCdXQKPj4+ IHRob3NlIGFyZSBhbHJlYWR5IGZyYWdpbGUgYnkgbmF0dXJlLCBzdXJlbHk/Cj4+Cj4+IFdlbGws IGV4Y2VwdCBBbmRyb2lkLCBhbGwgdGhlIG90aGVyIHJlbmRlcmVycyB1c2VzIEFSR0I4ODg4L1hS R0I4ODg4LAo+PiBhcyBmaXhlZCBwaXhlbCBmb3JtYXQsIHdoaWNoIGlzIHF1aXRlIGEgbGFyZ2Ug YW1vdW50IG9mIGNvZGUuCj4+Cj4gCj4gSSB0aGluayB3aGV0aGVyIHRoYXQgbWF0dGVycyBvciBu b3QgcmVhbGx5IGRlcGVuZHMgb24gd2hpY2ggZ3JhcGhpY3MKPiBBUElzIHlvdSdyZSByZWZlcnJp bmcgdG8uIElNTyBpdCdzIGluZXZpdGFibGUgdGhhdCBtb2RpZmllcnMgZG9uJ3QKPiBzaW1wbHkg ImRyb3AgaW4iIGV2ZXJ5d2hlcmUuIFRoZSBrZXJuZWwgQVBJIGFsbG93cyB5b3UgdG8gcXVlcnkg d2hhdCdzCj4gc3VwcG9ydGVkIGFuZCBwaWNrIHRoYXQuCgpTdXJlLCB3ZSdsbCBuZWVkIHRvIGFk ZCBhbiBleHRyYSBsYXllciB0byBkaXNjb3ZlciB0aGUgR0wgQVBJIGNhcGFiaWxpdGllcwp2cyB0 aGUgRFJNIERpc3BsYXkgZHJpdmVyIGNhcGFiaWxpdGllcyBpbiB0ZXJtIG9mIGZvdXJjYyttb2Rp ZmllcnMgYXQgc29tZSBwb2ludC4KVGhpcyBtYXkgYmUgYW4gZ29hbCBmb3IgdGhlIGxpYm91dHB1 dCBsaWJyYXJ5ICEKClRoYW5rcywKTmVpbAoKPiAKPiBUaGFua3MsCj4gLUJyaWFuCj4gCj4+Cj4+ IEFueXdheSwgdGhhbmtzIGZvciB0aGVzZSB0ZWNobmljYWwgY2xhcmlmaWNhdGlvbnMsIGl0IG1h a2VzIHRoaW5ncwo+PiBtdWNoIG1vcmUgY2xlYXJlci4KPj4KPj4gTmVpbAo+Pgo+Pj4KPj4+IENo ZWVycywKPj4+IC1Ccmlhbgo+Pj4KPj4+Pj4KPj4+Pj4gVGh1cywgRFJNX0ZPUk1BVF9BQkdSLCBE Uk1fRk9STUFUX0JHUiBzaG91bGQgb25seSBiZSBhbGxvd2VkLgo+Pj4+Pj4gKwkJbGluZV9zdHJp ZGUgPSAoKHByaXYtPnZpdS5vc2QxX3dpZHRoIDw8IDUpICsgMTI3KSA+PiA3Owo+Pj4+Pj4gKwkJ YnJlYWs7Cj4+Pj4+PiArCX0KPj4+Pj4+ICsKPj4+Pj4+ICsJcmV0dXJuICgobGluZV9zdHJpZGUg KyAxKSA+PiAxKSA8PCAxOwo+Pj4+Pj4gK30KPj4+Pj4+ICsKPj4+Pj4+ICBzdGF0aWMgdm9pZCBt ZXNvbl9wbGFuZV9hdG9taWNfdXBkYXRlKHN0cnVjdCBkcm1fcGxhbmUgKnBsYW5lLAo+Pj4+Pj4g IAkJCQkgICAgICBzdHJ1Y3QgZHJtX3BsYW5lX3N0YXRlICpvbGRfc3RhdGUpCj4+Pj4+PiAgewo+ Pj4+Cj4+Pj4gWy4uLl0KPj4+Pgo+Pj4+Pj4gIAo+Pj4+Pj4gK3N0YXRpYyBib29sIG1lc29uX3Bs YW5lX2Zvcm1hdF9tb2Rfc3VwcG9ydGVkKHN0cnVjdCBkcm1fcGxhbmUgKnBsYW5lLAo+Pj4+Pj4g KwkJCQkJICAgICB1MzIgZm9ybWF0LCB1NjQgbW9kaWZpZXIpCj4+Pj4+PiArewo+Pj4+Pj4gKwlz dHJ1Y3QgbWVzb25fcGxhbmUgKm1lc29uX3BsYW5lID0gdG9fbWVzb25fcGxhbmUocGxhbmUpOwo+ Pj4+Pj4gKwlzdHJ1Y3QgbWVzb25fZHJtICpwcml2ID0gbWVzb25fcGxhbmUtPnByaXY7Cj4+Pj4+ PiArCWludCBpOwo+Pj4+Pj4gKwo+Pj4+Pj4gKwlpZiAobW9kaWZpZXIgPT0gRFJNX0ZPUk1BVF9N T0RfSU5WQUxJRCkKPj4+Pj4+ICsJCXJldHVybiBmYWxzZTsKPj4+Pj4+ICsKPj4+Pj4+ICsJaWYg KG1vZGlmaWVyID09IERSTV9GT1JNQVRfTU9EX0xJTkVBUikKPj4+Pj4+ICsJCXJldHVybiB0cnVl Owo+Pj4+Pj4gKwo+Pj4+Pj4gKwlpZiAoIW1lc29uX3ZwdV9pc19jb21wYXRpYmxlKHByaXYsIFZQ VV9DT01QQVRJQkxFX0dYTSkgJiYKPj4+Pj4+ICsJICAgICFtZXNvbl92cHVfaXNfY29tcGF0aWJs ZShwcml2LCBWUFVfQ09NUEFUSUJMRV9HMTJBKSkKPj4+Pj4+ICsJCXJldHVybiBmYWxzZTsKPj4+ Pj4+ICsKPj4+Pj4+ICsJaWYgKG1vZGlmaWVyICYgfkRSTV9GT1JNQVRfTU9EX0FSTV9BRkJDKE1F U09OX01PRF9BRkJDX1ZBTElEX0JJVFMpKQo+Pj4+Pj4gKwkJcmV0dXJuIGZhbHNlOwo+Pj4+Pj4g Kwo+Pj4+Pj4gKwlmb3IgKGkgPSAwIDsgaSA8IHBsYW5lLT5tb2RpZmllcl9jb3VudCA7ICsraSkK Pj4+Pj4+ICsJCWlmIChwbGFuZS0+bW9kaWZpZXJzW2ldID09IG1vZGlmaWVyKQo+Pj4+Pj4gKwkJ CWJyZWFrOwo+Pj4+Pj4gKwo+Pj4+Pj4gKwlpZiAoaSA9PSBwbGFuZS0+bW9kaWZpZXJfY291bnQp IHsKPj4+Pj4+ICsJCURSTV9ERUJVR19LTVMoIlVuc3VwcG9ydGVkIG1vZGlmaWVyXG4iKTsKPj4+ Pj4+ICsJCXJldHVybiBmYWxzZTsKPj4+Pj4+ICsJfQo+Pj4+Cj4+Pj4gSSBjYW4gYWRkIGEgd2Fy bl9vbmNlIGhlcmUsIHdvdWxkIGl0IGJlIGVub3VnaCA/Cj4+Pj4KPj4+Pj4+ICsKPj4+Pj4+ICsJ aWYgKHByaXYtPmFmYmNkLm9wcyAmJiBwcml2LT5hZmJjZC5vcHMtPnN1cHBvcnRlZF9mbXQpCj4+ Pj4+PiArCQlyZXR1cm4gcHJpdi0+YWZiY2Qub3BzLT5zdXBwb3J0ZWRfZm10KG1vZGlmaWVyLCBm b3JtYXQpOwo+Pj4+Pj4gKwo+Pj4+Pj4gKwlEUk1fREVCVUdfS01TKCJBRkJDIFVuc3VwcG9ydGVk XG4iKTsKPj4+Pj4+ICsJcmV0dXJuIGZhbHNlOwo+Pj4+Pj4gK30KPj4+Pj4+ICsKPj4+Pj4+ICBz dGF0aWMgY29uc3Qgc3RydWN0IGRybV9wbGFuZV9mdW5jcyBtZXNvbl9wbGFuZV9mdW5jcyA9IHsK Pj4+Pj4+ICAJLnVwZGF0ZV9wbGFuZQkJPSBkcm1fYXRvbWljX2hlbHBlcl91cGRhdGVfcGxhbmUs Cj4+Pj4+PiAgCS5kaXNhYmxlX3BsYW5lCQk9IGRybV9hdG9taWNfaGVscGVyX2Rpc2FibGVfcGxh bmUsCj4+Pj4+PiBAQCAtMzUzLDYgKzQ1Nyw3IEBAIHN0YXRpYyBjb25zdCBzdHJ1Y3QgZHJtX3Bs YW5lX2Z1bmNzIG1lc29uX3BsYW5lX2Z1bmNzID0gewo+Pj4+Pj4gIAkucmVzZXQJCQk9IGRybV9h dG9taWNfaGVscGVyX3BsYW5lX3Jlc2V0LAo+Pj4+Pj4gIAkuYXRvbWljX2R1cGxpY2F0ZV9zdGF0 ZSA9IGRybV9hdG9taWNfaGVscGVyX3BsYW5lX2R1cGxpY2F0ZV9zdGF0ZSwKPj4+Pj4+ICAJLmF0 b21pY19kZXN0cm95X3N0YXRlCT0gZHJtX2F0b21pY19oZWxwZXJfcGxhbmVfZGVzdHJveV9zdGF0 ZSwKPj4+Pj4+ICsJLmZvcm1hdF9tb2Rfc3VwcG9ydGVkICAgPSBtZXNvbl9wbGFuZV9mb3JtYXRf bW9kX3N1cHBvcnRlZCwKPj4+Pj4+ICB9Owo+Pj4+Pj4gIAo+Pj4+Pj4gIHN0YXRpYyBjb25zdCB1 aW50MzJfdCBzdXBwb3J0ZWRfZHJtX2Zvcm1hdHNbXSA9IHsKPj4+Pj4+IEBAIC0zNjQsMTAgKzQ2 OSw1MyBAQCBzdGF0aWMgY29uc3QgdWludDMyX3Qgc3VwcG9ydGVkX2RybV9mb3JtYXRzW10gPSB7 Cj4+Pj4+PiAgCURSTV9GT1JNQVRfUkdCNTY1LAo+Pj4+Pj4gIH07Cj4+Pj4+PiAgCj4+Pj4+PiAr c3RhdGljIGNvbnN0IHVpbnQ2NF90IGZvcm1hdF9tb2RpZmllcnNfYWZiY19neG1bXSA9IHsKPj4+ Pj4+ICsJRFJNX0ZPUk1BVF9NT0RfQVJNX0FGQkMoQUZCQ19GT1JNQVRfTU9EX0JMT0NLX1NJWkVf MTZ4MTYgfAo+Pj4+Pj4gKwkJCQlBRkJDX0ZPUk1BVF9NT0RfU1BBUlNFIHwKPj4+Pj4+ICsJCQkJ QUZCQ19GT1JNQVRfTU9EX1lUUiksCj4+Pj4+PiArCS8qIFNQTElUIG1hbmRhdGVzIFNQQVJTRSwg UkdCIG1vZGVzIG1hbmRhdGVzIFlUUiAqLwo+Pj4+Pj4gKwlEUk1fRk9STUFUX01PRF9BUk1fQUZC QyhBRkJDX0ZPUk1BVF9NT0RfQkxPQ0tfU0laRV8xNngxNiB8Cj4+Pj4+PiArCQkJCUFGQkNfRk9S TUFUX01PRF9ZVFIgfAo+Pj4+Pj4gKwkJCQlBRkJDX0ZPUk1BVF9NT0RfU1BBUlNFIHwKPj4+Pj4+ ICsJCQkJQUZCQ19GT1JNQVRfTU9EX1NQTElUKSwKPj4+Pj4+ICsJRFJNX0ZPUk1BVF9NT0RfTElO RUFSLAo+Pj4+Pj4gKwlEUk1fRk9STUFUX01PRF9JTlZBTElELAo+Pj4+Pj4gK307Cj4+Pj4+PiAr Cj4+Pj4+PiArc3RhdGljIGNvbnN0IHVpbnQ2NF90IGZvcm1hdF9tb2RpZmllcnNfYWZiY19nMTJh W10gPSB7Cj4+Pj4+PiArCS8qCj4+Pj4+PiArCSAqIC0gVE9GSVggU3VwcG9ydCBBRkJDIG1vZGlm aWVycyBmb3IgWVVWIGZvcm1hdHMgKDE2eDE2ICsgVElMRUQpCj4+Pj4+PiArCSAqIC0gQUZCQ19G T1JNQVRfTU9EX1lUUiBpcyBtYW5kYXRvcnkgc2luY2Ugd2Ugb25seSBzdXBwb3J0IFJHQgo+Pj4+ Pj4gKwkgKiAtIFNQTElUIGlzIG1hbmRhdG9yeSBmb3IgcGVyZm9ybWFuY2VzIHJlYXNvbnMgd2hl biBpbiAxNngxNgo+Pj4+Pj4gKwkgKiAgIGJsb2NrIHNpemUKPj4+Pj4+ICsJICogLSAzMng4IGJs b2NrIHNpemUgKyBTUExJVCBpcyBtYW5kYXRvcnkgd2l0aCA0SyBmcmFtZSBzaXplCj4+Pj4+PiAr CSAqICAgZm9yIHBlcmZvcm1hbmNlcyByZWFzb25zCj4+Pj4+PiArCSAqLwo+Pj4+Pj4gKwlEUk1f Rk9STUFUX01PRF9BUk1fQUZCQyhBRkJDX0ZPUk1BVF9NT0RfQkxPQ0tfU0laRV8xNngxNiB8Cj4+ Pj4+PiArCQkJCUFGQkNfRk9STUFUX01PRF9ZVFIgfAo+Pj4+Pj4gKwkJCQlBRkJDX0ZPUk1BVF9N T0RfU1BBUlNFIHwKPj4+Pj4+ICsJCQkJQUZCQ19GT1JNQVRfTU9EX1NQTElUKSwKPj4+Pj4+ICsJ RFJNX0ZPUk1BVF9NT0RfQVJNX0FGQkMoQUZCQ19GT1JNQVRfTU9EX0JMT0NLX1NJWkVfMzJ4OCB8 Cj4+Pj4+PiArCQkJCUFGQkNfRk9STUFUX01PRF9ZVFIgfAo+Pj4+Pj4gKwkJCQlBRkJDX0ZPUk1B VF9NT0RfU1BBUlNFKSwKPj4+Pj4+ICsJRFJNX0ZPUk1BVF9NT0RfQVJNX0FGQkMoQUZCQ19GT1JN QVRfTU9EX0JMT0NLX1NJWkVfMzJ4OCB8Cj4+Pj4+PiArCQkJCUFGQkNfRk9STUFUX01PRF9ZVFIg fAo+Pj4+Pj4gKwkJCQlBRkJDX0ZPUk1BVF9NT0RfU1BBUlNFIHwKPj4+Pj4+ICsJCQkJQUZCQ19G T1JNQVRfTU9EX1NQTElUKSwKPj4+Pj4+ICsJRFJNX0ZPUk1BVF9NT0RfTElORUFSLAo+Pj4+Pj4g KwlEUk1fRk9STUFUX01PRF9JTlZBTElELAo+Pj4+Pj4gK307Cj4+Pj4+PiArCj4+Pj4+PiArc3Rh dGljIGNvbnN0IHVpbnQ2NF90IGZvcm1hdF9tb2RpZmllcnNfZGVmYXVsdFtdID0gewo+Pj4+Pj4g KwlEUk1fRk9STUFUX01PRF9MSU5FQVIsCj4+Pj4+PiArCURSTV9GT1JNQVRfTU9EX0lOVkFMSUQs Cj4+Pj4+PiArfTsKPj4+Pj4+ICsKPj4+Pj4+ICBpbnQgbWVzb25fcGxhbmVfY3JlYXRlKHN0cnVj dCBtZXNvbl9kcm0gKnByaXYpCj4+Pj4+PiAgewo+Pj4+Pj4gIAlzdHJ1Y3QgbWVzb25fcGxhbmUg Km1lc29uX3BsYW5lOwo+Pj4+Pj4gIAlzdHJ1Y3QgZHJtX3BsYW5lICpwbGFuZTsKPj4+Pj4+ICsJ Y29uc3QgdWludDY0X3QgKmZvcm1hdF9tb2RpZmllcnMgPSBmb3JtYXRfbW9kaWZpZXJzX2RlZmF1 bHQ7Cj4+Pj4+PiAgCj4+Pj4+PiAgCW1lc29uX3BsYW5lID0gZGV2bV9remFsbG9jKHByaXYtPmRy bS0+ZGV2LCBzaXplb2YoKm1lc29uX3BsYW5lKSwKPj4+Pj4+ICAJCQkJICAgR0ZQX0tFUk5FTCk7 Cj4+Pj4+PiBAQCAtMzc3LDExICs1MjUsMTYgQEAgaW50IG1lc29uX3BsYW5lX2NyZWF0ZShzdHJ1 Y3QgbWVzb25fZHJtICpwcml2KQo+Pj4+Pj4gIAltZXNvbl9wbGFuZS0+cHJpdiA9IHByaXY7Cj4+ Pj4+PiAgCXBsYW5lID0gJm1lc29uX3BsYW5lLT5iYXNlOwo+Pj4+Pj4gIAo+Pj4+Pj4gKwlpZiAo bWVzb25fdnB1X2lzX2NvbXBhdGlibGUocHJpdiwgVlBVX0NPTVBBVElCTEVfR1hNKSkKPj4+Pj4+ ICsJCWZvcm1hdF9tb2RpZmllcnMgPSBmb3JtYXRfbW9kaWZpZXJzX2FmYmNfZ3htOwo+Pj4+Pj4g KwllbHNlIGlmIChtZXNvbl92cHVfaXNfY29tcGF0aWJsZShwcml2LCBWUFVfQ09NUEFUSUJMRV9H MTJBKSkKPj4+Pj4+ICsJCWZvcm1hdF9tb2RpZmllcnMgPSBmb3JtYXRfbW9kaWZpZXJzX2FmYmNf ZzEyYTsKPj4+Pj4+ICsKPj4+Pj4+ICAJZHJtX3VuaXZlcnNhbF9wbGFuZV9pbml0KHByaXYtPmRy bSwgcGxhbmUsIDB4RkYsCj4+Pj4+PiAgCQkJCSAmbWVzb25fcGxhbmVfZnVuY3MsCj4+Pj4+PiAg CQkJCSBzdXBwb3J0ZWRfZHJtX2Zvcm1hdHMsCj4+Pj4+PiAgCQkJCSBBUlJBWV9TSVpFKHN1cHBv cnRlZF9kcm1fZm9ybWF0cyksCj4+Pj4+PiAtCQkJCSBOVUxMLAo+Pj4+Pj4gKwkJCQkgZm9ybWF0 X21vZGlmaWVycywKPj4+Pj4+ICAJCQkJIERSTV9QTEFORV9UWVBFX1BSSU1BUlksICJtZXNvbl9w cmltYXJ5X3BsYW5lIik7Cj4+Pj4+PiAgCj4+Pj4+PiAgCWRybV9wbGFuZV9oZWxwZXJfYWRkKHBs YW5lLCAmbWVzb25fcGxhbmVfaGVscGVyX2Z1bmNzKTsKPj4+Pj4+IC0tIAo+Pj4+Pj4gMi4yMi4w Cj4+Pj4KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+Pj4+IGRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKPj4+PiBkcmktZGV2ZWxAbGlzdHMuZnJlZWRl c2t0b3Aub3JnCj4+Pj4gaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0 aW5mby9kcmktZGV2ZWwKPj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNr dG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ry aS1kZXZlbA== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15AF9ECE58C for ; Fri, 11 Oct 2019 12:07:23 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D58702190F for ; Fri, 11 Oct 2019 12:07:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="MKvFsfTc"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=baylibre-com.20150623.gappssmtp.com header.i=@baylibre-com.20150623.gappssmtp.com header.b="eQdJEhQ9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D58702190F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=We+dIsmx/u5cHirEjMNWT0DaBf/MLC2GZM0ZCmFL59Y=; b=MKvFsfTciDVmUL ykqe4e0hot9pqfNxo1/pJcpsS3zIIIWU/pP5AhkQKoj+wyLid1ANJ2WsbVW/Dhoh58zpea5VC9f8v vYFwBi3Rq/CWVIhut4PuAsV1uY2rK14Fu3lZpLhcmGk2eHAmQQxLLZWokk3wgVMqG/zfqQxe+CIpW 3oRklkF8GDXxXcD4Akml4mFlK1y2+mKbsBWcc/uomp+Sv1oQFKhuVWGGgqi6lHHdY1uRq9f0/cEfV hmibo3prR2H/HzrQNmcqoDMwYKaJ44HSJRO+H4JpQv7MS+alU/NeAeD2bNCDyH09CRLvNNdCooDDC ekTzTevphjSWKnxXS4FA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iIthP-0000zB-Jp; Fri, 11 Oct 2019 12:07:11 +0000 Received: from mail-wr1-x442.google.com ([2a00:1450:4864:20::442]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iIthL-0000yI-7K for linux-amlogic@lists.infradead.org; Fri, 11 Oct 2019 12:07:10 +0000 Received: by mail-wr1-x442.google.com with SMTP id j18so11623274wrq.10 for ; Fri, 11 Oct 2019 05:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:openpgp:autocrypt:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=skVJpFrwlbssHfoMwJ5Qz60jZ7+YZBL8hOeGfInPjgA=; b=eQdJEhQ9jA/XxQ+4OdRfQw3vG1COpB7sZod80GFYclFBzZIMCvlVxoOsWF4lakumyS kUhj4jmx1yvNh8i35JLziPqfLW+Iz9CwsQ5481idEwdFCuibc701xnx+ufqLrcmAPc5l +p7hecBboyxgWWiJTOBu9AcZJ//CmWE7VOtVi9RKBFCp5xfKVCVbAKcVrIDTNoea/ItQ aYutnT2NnWbamv1XuHzefcSVMRPhcTY53befxKME+338/iF0VGuZEKuPqG8IVOe12WrF zJFVi+odqTt1iy+JmaYM8wkoqvK13nf6VnPYp3R8hqKwZdInAEL2txPo5NOn5VJuI697 a5qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=skVJpFrwlbssHfoMwJ5Qz60jZ7+YZBL8hOeGfInPjgA=; b=hgaa7z2VygwbZVQLMUuIl7WahUduNW8ZIXl1t57rgV8FhM4mI0siILZC+Dr255byBr /6PtvxSIJ24HZVRchm9krW5Kux9nvFe/jpMOFMpVD5JaHkJfxSh8ELsNChL+7mK0rSuT N+tIAr+AD1vDqfT4ktel+1EMn3ijvhFB8mUf2p/OwvoyDZ4ub2/XLyBbAuxWvSb+y1GW xK9jDr+DI/fpsp2QnukU+3qEil5TH3ZzPe3uKSvhxsARMPPyuF9TWnWUlFQXgFvbgDRJ f+ASUxvSjG4VydQ7mhHDoTtXKW01XEi4H4oUq+giLxrEyyh6FfYOkz/nRmkl2cOxTutQ my4Q== X-Gm-Message-State: APjAAAXRtbFQKBhh2xBJcuF3dUE4/rwcnnKa5p+zvvMkNKNG8tGxbbdx j06QQdBgF4nnwN87ZOX1hMN9JxaO3y15rw== X-Google-Smtp-Source: APXvYqzmbbFALORP/sVFC6QVYMkGTRWBmOdVEvPwtEXDxANM1No+1064NIyHI19EXXLz3qJk6Sf1gQ== X-Received: by 2002:a5d:5705:: with SMTP id a5mr13426722wrv.112.1570795622822; Fri, 11 Oct 2019 05:07:02 -0700 (PDT) Received: from [10.1.2.12] (lmontsouris-657-1-212-31.w90-63.abo.wanadoo.fr. [90.63.244.31]) by smtp.gmail.com with ESMTPSA id p5sm11842456wmi.4.2019.10.11.05.07.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Oct 2019 05:07:02 -0700 (PDT) Subject: Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane To: Brian Starkey References: <20191010092526.10419-1-narmstrong@baylibre.com> <20191010092526.10419-5-narmstrong@baylibre.com> <20191010132601.GA10110@arm.com> <44f1771f-d640-f23d-995f-7bfcadd213bc@baylibre.com> <20191011084108.i7lfh2d7asfmcdk4@DESKTOP-E1NTVVP.localdomain> <20191011105559.clttghy52wfdmb34@DESKTOP-E1NTVVP.localdomain> From: Neil Armstrong Openpgp: preference=signencrypt Autocrypt: addr=narmstrong@baylibre.com; prefer-encrypt=mutual; keydata= mQENBE1ZBs8BCAD78xVLsXPwV/2qQx2FaO/7mhWL0Qodw8UcQJnkrWmgTFRobtTWxuRx8WWP GTjuhvbleoQ5Cxjr+v+1ARGCH46MxFP5DwauzPekwJUD5QKZlaw/bURTLmS2id5wWi3lqVH4 BVF2WzvGyyeV1o4RTCYDnZ9VLLylJ9bneEaIs/7cjCEbipGGFlfIML3sfqnIvMAxIMZrvcl9 qPV2k+KQ7q+aXavU5W+yLNn7QtXUB530Zlk/d2ETgzQ5FLYYnUDAaRl+8JUTjc0CNOTpCeik 80TZcE6f8M76Xa6yU8VcNko94Ck7iB4vj70q76P/J7kt98hklrr85/3NU3oti3nrIHmHABEB AAG0KE5laWwgQXJtc3Ryb25nIDxuYXJtc3Ryb25nQGJheWxpYnJlLmNvbT6JATsEEwEKACUC GyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJXDO2CAhkBAAoJEBaat7Gkz/iubGIH/iyk RqvgB62oKOFlgOTYCMkYpm2aAOZZLf6VKHKc7DoVwuUkjHfIRXdslbrxi4pk5VKU6ZP9AKsN NtMZntB8WrBTtkAZfZbTF7850uwd3eU5cN/7N1Q6g0JQihE7w4GlIkEpQ8vwSg5W7hkx3yQ6 2YzrUZh/b7QThXbNZ7xOeSEms014QXazx8+txR7jrGF3dYxBsCkotO/8DNtZ1R+aUvRfpKg5 ZgABTC0LmAQnuUUf2PHcKFAHZo5KrdO+tyfL+LgTUXIXkK+tenkLsAJ0cagz1EZ5gntuheLD YJuzS4zN+1Asmb9kVKxhjSQOcIh6g2tw7vaYJgL/OzJtZi6JlIW5AQ0ETVkGzwEIALyKDN/O GURaHBVzwjgYq+ZtifvekdrSNl8TIDH8g1xicBYpQTbPn6bbSZbdvfeQPNCcD4/EhXZuhQXM coJsQQQnO4vwVULmPGgtGf8PVc7dxKOeta+qUh6+SRh3vIcAUFHDT3f/Zdspz+e2E0hPV2hi SvICLk11qO6cyJE13zeNFoeY3ggrKY+IzbFomIZY4yG6xI99NIPEVE9lNBXBKIlewIyVlkOa YvJWSV+p5gdJXOvScNN1epm5YHmf9aE2ZjnqZGoMMtsyw18YoX9BqMFInxqYQQ3j/HpVgTSv mo5ea5qQDDUaCsaTf8UeDcwYOtgI8iL4oHcsGtUXoUk33HEAEQEAAYkBHwQYAQIACQUCTVkG zwIbDAAKCRAWmrexpM/4rrXiB/sGbkQ6itMrAIfnM7IbRuiSZS1unlySUVYu3SD6YBYnNi3G 5EpbwfBNuT3H8//rVvtOFK4OD8cRYkxXRQmTvqa33eDIHu/zr1HMKErm+2SD6PO9umRef8V8 2o2oaCLvf4WeIssFjwB0b6a12opuRP7yo3E3gTCSKmbUuLv1CtxKQF+fUV1cVaTPMyT25Od+ RC1K+iOR0F54oUJvJeq7fUzbn/KdlhA8XPGzwGRy4zcsPWvwnXgfe5tk680fEKZVwOZKIEuJ C3v+/yZpQzDvGYJvbyix0lHnrCzq43WefRHI5XTTQbM0WUIBIcGmq38+OgUsMYu4NzLu7uZF Acmp6h8guQINBFYnf6QBEADQ+wBYa+X2n/xIQz/RUoGHf84Jm+yTqRT43t7sO48/cBW9vAn9 GNwnJ3HRJWKATW0ZXrCr40ES/JqM1fUTfiFDB3VMdWpEfwOAT1zXS+0rX8yljgsWR1UvqyEP 3xN0M/40Zk+rdmZKaZS8VQaXbveaiWMEmY7sBV3QvgOzB7UF2It1HwoCon5Y+PvyE3CguhBd 9iq5iEampkMIkbA3FFCpQFI5Ai3BywkLzbA3ZtnMXR8Qt9gFZtyXvFQrB+/6hDzEPnBGZOOx zkd/iIX59SxBuS38LMlhPPycbFNmtauOC0DNpXCv9ACgC9tFw3exER/xQgSpDVc4vrL2Cacr wmQp1k9E0W+9pk/l8S1jcHx03hgCxPtQLOIyEu9iIJb27TjcXNjiInd7Uea195NldIrndD+x 58/yU3X70qVY+eWbqzpdlwF1KRm6uV0ZOQhEhbi0FfKKgsYFgBIBchGqSOBsCbL35f9hK/JC 6LnGDtSHeJs+jd9/qJj4WqF3x8i0sncQ/gszSajdhnWrxraG3b7/9ldMLpKo/OoihfLaCxtv xYmtw8TGhlMaiOxjDrohmY1z7f3rf6njskoIXUO0nabun1nPAiV1dpjleg60s3OmVQeEpr3a K7gR1ljkemJzM9NUoRROPaT7nMlNYQL+IwuthJd6XQqwzp1jRTGG26J97wARAQABiQM+BBgB AgAJBQJWJ3+kAhsCAikJEBaat7Gkz/iuwV0gBBkBAgAGBQJWJ3+kAAoJEHfc29rIyEnRk6MQ AJDo0nxsadLpYB26FALZsWlN74rnFXth5dQVQ7SkipmyFWZhFL8fQ9OiIoxWhM6rSg9+C1w+ n45eByMg2b8H3mmQmyWztdI95OxSREKwbaXVapCcZnv52JRjlc3DoiiHqTZML5x1Z7lQ1T3F 8o9sKrbFO1WQw1+Nc91+MU0MGN0jtfZ0Tvn/ouEZrSXCE4K3oDGtj3AdC764yZVq6CPigCgs 6Ex80k6QlzCdVP3RKsnPO2xQXXPgyJPJlpD8bHHHW7OLfoR9DaBNympfcbQJeekQrTvyoASw EOTPKE6CVWrcQIztUp0WFTdRGgMK0cZB3Xfe6sOp24PQTHAKGtjTHNP/THomkH24Fum9K3iM /4Wh4V2eqGEgpdeSp5K+LdaNyNgaqzMOtt4HYk86LYLSHfFXywdlbGrY9+TqiJ+ZVW4trmui NIJCOku8SYansq34QzYM0x3UFRwff+45zNBEVzctSnremg1mVgrzOfXU8rt+4N1b2MxorPF8 619aCwVP7U16qNSBaqiAJr4e5SNEnoAq18+1Gp8QsFG0ARY8xp+qaKBByWES7lRi3QbqAKZf yOHS6gmYo9gBmuAhc65/VtHMJtxwjpUeN4Bcs9HUpDMDVHdfeRa73wM+wY5potfQ5zkSp0Jp bxnv/cRBH6+c43stTffprd//4Hgz+nJcCgZKtCYIAPkUxABC85ID2CidzbraErVACmRoizhT KR2OiqSLW2x4xdmSiFNcIWkWJB6Qdri0Fzs2dHe8etD1HYaht1ZhZ810s7QOL7JwypO8dscN KTEkyoTGn6cWj0CX+PeP4xp8AR8ot4d0BhtUY34UPzjE1/xyrQFAdnLd0PP4wXxdIUuRs0+n WLY9Aou/vC1LAdlaGsoTVzJ2gX4fkKQIWhX0WVk41BSFeDKQ3RQ2pnuzwedLO94Bf6X0G48O VsbXrP9BZ6snXyHfebPnno/te5XRqZTL9aJOytB/1iUna+1MAwBxGFPvqeEUUyT+gx1l3Acl ZaTUOEkgIor5losDrePdPgE= Organization: Baylibre Message-ID: Date: Fri, 11 Oct 2019 14:07:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20191011105559.clttghy52wfdmb34@DESKTOP-E1NTVVP.localdomain> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191011_050707_297018_8DEC7A8E X-CRM114-Status: GOOD ( 28.82 ) X-BeenThere: linux-amlogic@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ayan Halder , "khilman@baylibre.com" , "dri-devel@lists.freedesktop.org" , "linux-amlogic@lists.infradead.org" , nd , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org On 11/10/2019 12:56, Brian Starkey wrote: > Hi, > > On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote: >> Hi Brian, >> >> On 11/10/2019 10:41, Brian Starkey wrote: >>> Hi Neil, >>> >>> On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote: >>>> Hi Ayan, >>>> >>>> On 10/10/2019 15:26, Ayan Halder wrote: >>>>> On Thu, Oct 10, 2019 at 11:25:23AM +0200, Neil Armstrong wrote: >>>>>> This adds all the OSD configuration plumbing to support the AFBC decoders >>>>>> path to display of the OSD1 plane. >>>>>> >>>>>> The Amlogic GXM and G12A AFBC decoders are integrated very differently. >>>>>> >>>>>> The Amlogic GXM has a direct output path to the OSD1 VIU pixel input, >>>>>> because the GXM AFBC decoder seem to be a custom IP developed by Amlogic. >>>>>> >>>>>> On the other side, the Amlogic G12A AFBC decoder seems to be an external >>>>>> IP that emit pixels on an AXI master hooked to a "Mali Unpack" block >>>>>> feeding the OSD1 VIU pixel input. >>>>>> This uses a weird "0x1000000" internal HW physical address on both >>>>>> sides to transfer the pixels. >>>>>> >>>>>> For Amlogic GXM, the supported pixel formats are the same as the normal >>>>>> linear OSD1 mode. >>>>>> >>>>>> On the other side, Amlogic added support for all AFBC v1.2 formats for >>>>>> the G12A AFBC integration. >>>>>> >>>>>> For simplicity, we stick to the already supported formats for now. >>>>>> >>>>>> Signed-off-by: Neil Armstrong >>>>>> --- >>>>>> drivers/gpu/drm/meson/meson_crtc.c | 2 + >>>>>> drivers/gpu/drm/meson/meson_drv.h | 4 + >>>>>> drivers/gpu/drm/meson/meson_plane.c | 215 ++++++++++++++++++++++++---- >>>>>> 3 files changed, 190 insertions(+), 31 deletions(-) >>>>>> >>>>>> diff --git a/drivers/gpu/drm/meson/meson_crtc.c b/drivers/gpu/drm/meson/meson_crtc.c >>>>>> index 57ae1c13d1e6..d478fa232951 100644 >>>>>> --- a/drivers/gpu/drm/meson/meson_crtc.c >>>>>> +++ b/drivers/gpu/drm/meson/meson_crtc.c >>>>>> @@ -281,6 +281,8 @@ void meson_crtc_irq(struct meson_drm *priv) >>>>>> if (priv->viu.osd1_enabled && priv->viu.osd1_commit) { >>>>>> writel_relaxed(priv->viu.osd1_ctrl_stat, >>>>>> priv->io_base + _REG(VIU_OSD1_CTRL_STAT)); >>>>>> + writel_relaxed(priv->viu.osd1_ctrl_stat2, >>>>>> + priv->io_base + _REG(VIU_OSD1_CTRL_STAT2)); >>>>>> writel_relaxed(priv->viu.osd1_blk0_cfg[0], >>>>>> priv->io_base + _REG(VIU_OSD1_BLK0_CFG_W0)); >>>>>> writel_relaxed(priv->viu.osd1_blk0_cfg[1], >>>>>> diff --git a/drivers/gpu/drm/meson/meson_drv.h b/drivers/gpu/drm/meson/meson_drv.h >>>>>> index 60f13c6f34e5..de25349be8aa 100644 >>>>>> --- a/drivers/gpu/drm/meson/meson_drv.h >>>>>> +++ b/drivers/gpu/drm/meson/meson_drv.h >>>>>> @@ -53,8 +53,12 @@ struct meson_drm { >>>>>> bool osd1_enabled; >>>>>> bool osd1_interlace; >>>>>> bool osd1_commit; >>>>>> + bool osd1_afbcd; >>>>>> uint32_t osd1_ctrl_stat; >>>>>> + uint32_t osd1_ctrl_stat2; >>>>>> uint32_t osd1_blk0_cfg[5]; >>>>>> + uint32_t osd1_blk1_cfg4; >>>>>> + uint32_t osd1_blk2_cfg4; >>>>>> uint32_t osd1_addr; >>>>>> uint32_t osd1_stride; >>>>>> uint32_t osd1_height; >>>>>> diff --git a/drivers/gpu/drm/meson/meson_plane.c b/drivers/gpu/drm/meson/meson_plane.c >>>>>> index 5e798c276037..412941aa8402 100644 >>>>>> --- a/drivers/gpu/drm/meson/meson_plane.c >>>>>> +++ b/drivers/gpu/drm/meson/meson_plane.c >>>>>> @@ -23,6 +23,7 @@ >>>>>> #include "meson_plane.h" >>>>>> #include "meson_registers.h" >>>>>> #include "meson_viu.h" >>>>>> +#include "meson_osd_afbcd.h" >>>>>> >>>>>> /* OSD_SCI_WH_M1 */ >>>>>> #define SCI_WH_M1_W(w) FIELD_PREP(GENMASK(28, 16), w) >>>>>> @@ -92,12 +93,38 @@ static int meson_plane_atomic_check(struct drm_plane *plane, >>>>>> false, true); >>>>>> } >>>>>> >>>>>> +#define MESON_MOD_AFBC_VALID_BITS (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | \ >>>>>> + AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 | \ >>>>>> + AFBC_FORMAT_MOD_YTR | \ >>>>>> + AFBC_FORMAT_MOD_SPARSE | \ >>>>>> + AFBC_FORMAT_MOD_SPLIT) >>>>>> + >>>>>> /* Takes a fixed 16.16 number and converts it to integer. */ >>>>>> static inline int64_t fixed16_to_int(int64_t value) >>>>>> { >>>>>> return value >> 16; >>>>>> } >>>>>> >>>>>> +static u32 meson_g12a_afbcd_line_stride(struct meson_drm *priv) >>>>>> +{ >>>>>> + u32 line_stride = 0; >>>>>> + >>>>>> + switch (priv->afbcd.format) { >>>>>> + case DRM_FORMAT_RGB565: >>>>>> + line_stride = ((priv->viu.osd1_width << 4) + 127) >> 7; >>>>>> + break; >>>>>> + case DRM_FORMAT_RGB888: >>>>>> + case DRM_FORMAT_XRGB8888: >>>>>> + case DRM_FORMAT_ARGB8888: >>>>>> + case DRM_FORMAT_XBGR8888: >>>>>> + case DRM_FORMAT_ABGR8888: >>>>> Please have a look at >>>>> https://www.kernel.org/doc/html/latest/gpu/afbc.html for our >>>>> recommendation. We suggest that *X* formats are avoided. >>>>> >>>>> Also, for interoperability and maximum compression efficiency (with >>>>> AFBC_FORMAT_MOD_YTR), we suggest the following order :- >>>>> >>>>> Component 0: R >>>>> Component 1: G >>>>> Component 2: B >>>>> Component 3: A (if available) >>>> >>>> >>>> Sorry I don't understand, you ask me to limit AFBC to ABGR8888 ? >>>> >>>> But why if the HW (GPU and DPU) is capable of ? >>> >>> AFBC doesn't have an in-memory component order in the traditional >>> sense (i.e. a bit-position to component mapping), so Arm >>> have decided to define the convention that DRM_FORMAT_ABGR8888 >>> represents the AFBC layout with R in component 0. >> >> In this implementation, we handle the ARGB/ABGR as the same mode >> since the AFBC can only represent the layout as "ABGR" anyway. >> > > In this case, with the external AFBC IP, there's a whole extra layer > of potential confusion :-( > > The decoder only needs to know the number of components - so > irrespective of what color channel is mapped to what component, it can > always be configured with the same mode for 4-component 32-bit > formats. > > For everything to work correctly with YTR, the thing consuming the > output from the decoder must treat component 0 as 'R', but otherwise > it doesn't matter. > > Is your HW able to treat the decoder output in different ways? e.g. > mapping component 0 to 'B'? If that's the case, then exposing the > different orders is valid - but only ABGR should allow YTR. Yes, we can remap each components from AFBC in any order. Ok thanks for clarifying, so: - I'll allow only ABGR/XBGR with YTR - I'll allow ABGR/XBGR/ARGB/XRGB only if !YTR and use the AFBC components remapping for ARGB/XRGB I'll also need to clean up the RGB888/BGR888 as we support only RGB888 for now. And I'll reject RGB565 since we don't support it without AFBC. > >>> >>> Are you sure the GPU supports other orders? I think any Arm driver >>> will only be producing DRM_FORMATs with "BGR" order e.g. ABGR888> >>> I'm not convinced the GPU HW actually supports any other order, but >>> it's all rather confusing with texture swizzling. What I can tell you >>> for sure is that it _does_ support BGR order (in DRM naming >>> convention). >> >> Well, since the Bifrost Mali blobs are closed-source and delivered >> by licensees, it's hard to define what is supported from a closed >> GPU HW, closed SW implementation to a closed pixel format implementation. >> > > I hear you. IMO the only way to make any of this clear is to publish > reference data and tests which make sure implementations match each > other. It's something I'm trying to make happen. I'll be happy to run them when available and fix the implementation accordingly ! > >> You'll have to tell us if the closed libMali handling AFBC would accept >> ARGB8888 as format to render with AFBC enabled, if not you're right >> I'll discard XRGB8888/ARGB8888 for AFBC buffers completely. >> >> But it the libMali chooses tt generate an ARGB8888 buffer whatever >> ARGB8888/XRGB8888/ABGR888/XBGR888 is asked, then no I'll keep it that way. >> > > Yeah, I'll try and get clarity on this. It's not at all clear to me > either. When you say "accept ARGB8888 as format to render with AFBC > enabled", which API are you referring to, just so I can be clear? Do > you have an example of some code you're using to render AFBC with the > GPU blob? Let's take kmscube using EGL and GBM. The buffer is allocated using gbm_surface_create_with_modifiers(), but the gbm implementation is vendor specified. Then the surface is passed to eglCreateWindowSurface(). Then the format is matched using eglGetConfigAttrib() with the returned configs. Here support on the gbm and EGL implementation. > > In many APIs, there's no real expectation on in-memory component > order, so perhaps there treating them as all the same is acceptable. > > However, fourcc + AFBC modifier is explicit in terms of component > order, and so IMO it's very harmful to "ignore" component order in > interfaces using fourcc + AFBC modifier. > > There are implementations which support other orders, so ignoring > order will break those implementations. In some cases (Android, maybe > GL), this can be hidden behind "driver magic", but if the API is > fourcc + AFBC modifier, IMO it had better be completely explicit with > no tricks - irrespective of whatever other less-prescriptive APIs do. Sure > >> BTW I kept the vendor implementation here, which may be wrong but since >> they have the AFBC IP license and Mali Bifrost GPU license... >> >>> >>> If you do choose to expose orders other than BGR/ABGR, then you should >>> certainly not allow YTR to be used with any orders other than >>> BGR/ABGR. The AFBC spec defines YTR as using R in component 0, which >>> Arm has defined as DRM_FORMAT_*BGR* (component 0 in LE LSBs). >>> >> >> The MAFBC_FMT_RGBA8888 pixel format is defined in the AFBC decoder, >> which seems to be an ARM IP, the registers documentation is in the >> SoC datasheet at [1] and the formats bits are defined in the patch 3 at [2]. >> >> So it seems the decoder handles only a single type for 32bit RGB buffer >> format, as Amlogic names it MAFBC_FMT_RGBA8888 >> > > Hopefully my comments at the beginning of this mail helps clear this > part up a bit. > >> For XRGB8888/XBGR8888 we simply "replace" the A component with a fixed >> value in the pixel generator. > > That seems correct, so long as the decoder is configured in the > 4-component mode. > >> >> [1] https://dl.khadas.com/Hardware/VIM3/Datasheet/S905D3_datasheet_0.2_Wesion.pdf page 772 >> [2] https://patchwork.freedesktop.org/patch/335199/?series=67832&rev=1 >> >>>> >>>> Isn't it an userspace choice ? I understand XRGB8888 is a waste >>>> of memory space and compression efficiency, but this is not the >>>> kernel driver's to decide this, right ? >>>> >>> >>> As long as it's agreed and understood what XRGB8888 means. It must be >>> an AFBC bitstream with 4-components, with B in component 0, G in >>> component 1, R in component 2 and 8 wasted bits in component 3. >> >> Yes, but this is something userspace must assume, and it's already >> wasted in the linear XRGB8888 format anyway. >> >>> >>> I know of HW which treats "XBGR" with AFBC as a 3-component format, >>> which isn't correct but can easily lead to confusion and >>> incompatibility. >> >> Seems it's not the case here, at least for the G12A SoC family. > > That's good :-) > >> >>> >>>> For interoperability I'll understand recommending a minimal set >>>> of modifiers and formats. But here, each platform is also limited >>>> by it's GPU capabilites aswell. >>>> >>> >>> The (Arm) GPUs support ABGR ordering, so if everyone sticks to that we >>> can make sure everything's nice and compatible (until someone turns up >>> with HW which _doesn't_ support that ordering). >> >> This is not clean enough in the https://www.kernel.org/doc/html/latest/gpu/afbc.html >> document. Since ARM is in control of the renderers, saying AFBC does _not_ >> support another components format as ABGR ordering in all the >> OpenGL ES/Vulkan implementations, it would be clear we couldn't render >> anything using AFBC with ARGB. >> But we hit the closed-source/closed-specifications here again. >> > > I didn't really understand the middle sentence. > > I know and understand that the "closed-ness" is a problem. The page > you linked was an initial attempt at making a clear, public > specification. > > What I need to be clear about, though, is that it describes _only_ > cases where DRM fourcc + AFBC modifier are used. I don't think there's > any sane way to apply it to other APIs, because the formats are > described differently, and the "leeway" allowed for doing things > "under-the-hood" is very different. Indeed > >>> >>>> Limiting to ABGR8888 would discard like every non-Android renderers, >>>> using AFBC, I'm not sure it's the kernels driver's responsibility. >>>> >>> >>> It prevents renderers with hard-coded pixel formats, perhaps. But >>> those are already fragile by nature, surely? >> >> Well, except Android, all the other renderers uses ARGB8888/XRGB8888, >> as fixed pixel format, which is quite a large amount of code. >> > > I think whether that matters or not really depends on which graphics > APIs you're referring to. IMO it's inevitable that modifiers don't > simply "drop in" everywhere. The kernel API allows you to query what's > supported and pick that. Sure, we'll need to add an extra layer to discover the GL API capabilities vs the DRM Display driver capabilities in term of fourcc+modifiers at some point. This may be an goal for the liboutput library ! Thanks, Neil > > Thanks, > -Brian > >> >> Anyway, thanks for these technical clarifications, it makes things >> much more clearer. >> >> Neil >> >>> >>> Cheers, >>> -Brian >>> >>>>> >>>>> Thus, DRM_FORMAT_ABGR, DRM_FORMAT_BGR should only be allowed. >>>>>> + line_stride = ((priv->viu.osd1_width << 5) + 127) >> 7; >>>>>> + break; >>>>>> + } >>>>>> + >>>>>> + return ((line_stride + 1) >> 1) << 1; >>>>>> +} >>>>>> + >>>>>> static void meson_plane_atomic_update(struct drm_plane *plane, >>>>>> struct drm_plane_state *old_state) >>>>>> { >>>> >>>> [...] >>>> >>>>>> >>>>>> +static bool meson_plane_format_mod_supported(struct drm_plane *plane, >>>>>> + u32 format, u64 modifier) >>>>>> +{ >>>>>> + struct meson_plane *meson_plane = to_meson_plane(plane); >>>>>> + struct meson_drm *priv = meson_plane->priv; >>>>>> + int i; >>>>>> + >>>>>> + if (modifier == DRM_FORMAT_MOD_INVALID) >>>>>> + return false; >>>>>> + >>>>>> + if (modifier == DRM_FORMAT_MOD_LINEAR) >>>>>> + return true; >>>>>> + >>>>>> + if (!meson_vpu_is_compatible(priv, VPU_COMPATIBLE_GXM) && >>>>>> + !meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) >>>>>> + return false; >>>>>> + >>>>>> + if (modifier & ~DRM_FORMAT_MOD_ARM_AFBC(MESON_MOD_AFBC_VALID_BITS)) >>>>>> + return false; >>>>>> + >>>>>> + for (i = 0 ; i < plane->modifier_count ; ++i) >>>>>> + if (plane->modifiers[i] == modifier) >>>>>> + break; >>>>>> + >>>>>> + if (i == plane->modifier_count) { >>>>>> + DRM_DEBUG_KMS("Unsupported modifier\n"); >>>>>> + return false; >>>>>> + } >>>> >>>> I can add a warn_once here, would it be enough ? >>>> >>>>>> + >>>>>> + if (priv->afbcd.ops && priv->afbcd.ops->supported_fmt) >>>>>> + return priv->afbcd.ops->supported_fmt(modifier, format); >>>>>> + >>>>>> + DRM_DEBUG_KMS("AFBC Unsupported\n"); >>>>>> + return false; >>>>>> +} >>>>>> + >>>>>> static const struct drm_plane_funcs meson_plane_funcs = { >>>>>> .update_plane = drm_atomic_helper_update_plane, >>>>>> .disable_plane = drm_atomic_helper_disable_plane, >>>>>> @@ -353,6 +457,7 @@ static const struct drm_plane_funcs meson_plane_funcs = { >>>>>> .reset = drm_atomic_helper_plane_reset, >>>>>> .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state, >>>>>> .atomic_destroy_state = drm_atomic_helper_plane_destroy_state, >>>>>> + .format_mod_supported = meson_plane_format_mod_supported, >>>>>> }; >>>>>> >>>>>> static const uint32_t supported_drm_formats[] = { >>>>>> @@ -364,10 +469,53 @@ static const uint32_t supported_drm_formats[] = { >>>>>> DRM_FORMAT_RGB565, >>>>>> }; >>>>>> >>>>>> +static const uint64_t format_modifiers_afbc_gxm[] = { >>>>>> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | >>>>>> + AFBC_FORMAT_MOD_SPARSE | >>>>>> + AFBC_FORMAT_MOD_YTR), >>>>>> + /* SPLIT mandates SPARSE, RGB modes mandates YTR */ >>>>>> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | >>>>>> + AFBC_FORMAT_MOD_YTR | >>>>>> + AFBC_FORMAT_MOD_SPARSE | >>>>>> + AFBC_FORMAT_MOD_SPLIT), >>>>>> + DRM_FORMAT_MOD_LINEAR, >>>>>> + DRM_FORMAT_MOD_INVALID, >>>>>> +}; >>>>>> + >>>>>> +static const uint64_t format_modifiers_afbc_g12a[] = { >>>>>> + /* >>>>>> + * - TOFIX Support AFBC modifiers for YUV formats (16x16 + TILED) >>>>>> + * - AFBC_FORMAT_MOD_YTR is mandatory since we only support RGB >>>>>> + * - SPLIT is mandatory for performances reasons when in 16x16 >>>>>> + * block size >>>>>> + * - 32x8 block size + SPLIT is mandatory with 4K frame size >>>>>> + * for performances reasons >>>>>> + */ >>>>>> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | >>>>>> + AFBC_FORMAT_MOD_YTR | >>>>>> + AFBC_FORMAT_MOD_SPARSE | >>>>>> + AFBC_FORMAT_MOD_SPLIT), >>>>>> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 | >>>>>> + AFBC_FORMAT_MOD_YTR | >>>>>> + AFBC_FORMAT_MOD_SPARSE), >>>>>> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 | >>>>>> + AFBC_FORMAT_MOD_YTR | >>>>>> + AFBC_FORMAT_MOD_SPARSE | >>>>>> + AFBC_FORMAT_MOD_SPLIT), >>>>>> + DRM_FORMAT_MOD_LINEAR, >>>>>> + DRM_FORMAT_MOD_INVALID, >>>>>> +}; >>>>>> + >>>>>> +static const uint64_t format_modifiers_default[] = { >>>>>> + DRM_FORMAT_MOD_LINEAR, >>>>>> + DRM_FORMAT_MOD_INVALID, >>>>>> +}; >>>>>> + >>>>>> int meson_plane_create(struct meson_drm *priv) >>>>>> { >>>>>> struct meson_plane *meson_plane; >>>>>> struct drm_plane *plane; >>>>>> + const uint64_t *format_modifiers = format_modifiers_default; >>>>>> >>>>>> meson_plane = devm_kzalloc(priv->drm->dev, sizeof(*meson_plane), >>>>>> GFP_KERNEL); >>>>>> @@ -377,11 +525,16 @@ int meson_plane_create(struct meson_drm *priv) >>>>>> meson_plane->priv = priv; >>>>>> plane = &meson_plane->base; >>>>>> >>>>>> + if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_GXM)) >>>>>> + format_modifiers = format_modifiers_afbc_gxm; >>>>>> + else if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) >>>>>> + format_modifiers = format_modifiers_afbc_g12a; >>>>>> + >>>>>> drm_universal_plane_init(priv->drm, plane, 0xFF, >>>>>> &meson_plane_funcs, >>>>>> supported_drm_formats, >>>>>> ARRAY_SIZE(supported_drm_formats), >>>>>> - NULL, >>>>>> + format_modifiers, >>>>>> DRM_PLANE_TYPE_PRIMARY, "meson_primary_plane"); >>>>>> >>>>>> drm_plane_helper_add(plane, &meson_plane_helper_funcs); >>>>>> -- >>>>>> 2.22.0 >>>> >>>> _______________________________________________ >>>> dri-devel mailing list >>>> dri-devel@lists.freedesktop.org >>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic