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,URIBL_BLOCKED,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 A644EC47404 for ; Fri, 11 Oct 2019 10:56:28 +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 743C12084C for ; Fri, 11 Oct 2019 10:56:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="hLYyggkV"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=armh.onmicrosoft.com header.i=@armh.onmicrosoft.com header.b="dfCRgbIA"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=armh.onmicrosoft.com header.i=@armh.onmicrosoft.com header.b="dfCRgbIA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 743C12084C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.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:MIME-Version:Content-ID:In-Reply-To: References:Message-ID:Date:Subject:To:From:Reply-To:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4If9kAF0J1uVpUT/xMFEF8lQayTIVMBHuqE7T24WZy8=; b=hLYyggkVi4gJZ2 xJR/i+d3w8Sf5QJK8ynZXQpvUmJxC6p+LexcC3W5L20Y0LS2hWt5qZcvZD0VH4sPiv0ef26JnIXfq PGt2MQnFQv2q44i4y+ITSqp611URkKTKUl/L6UtiUIoXD+9lr8ppYz8lVFhkD9GYUC3UuciVt4JLA JFoYOnQn7wfLOxfPRcLnvwCPutQ6VnAB0eAU2mVkchSfSU+KBIKiA5aALzY5QlAC/MJ2I10S3K949 SlJIsWVNmQ8xusaVquzCX1u42xxHIlUz9X5Q8tZ7FL6OIPl6fHLtm3dMXLItTTPVlH+zaNuV+99Fu PdVHHBnxGI0EbOQ0phfQ==; 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 1iIsar-0004Vp-Ez; Fri, 11 Oct 2019 10:56:21 +0000 Received: from mail-eopbgr80074.outbound.protection.outlook.com ([40.107.8.74] helo=EUR04-VI1-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iIsan-0004Ux-3k; Fri, 11 Oct 2019 10:56:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yoXMqgkrVOlA9w3mwWbFLbUt4qFRzx5cc74EwqZiVtY=; b=dfCRgbIAV1zlJn+vUpOnPUVJEGyckcwqYVkyVZDcJnAxMwXCnnnkRJiWPjsEas0hWsdY7ZaJH4Ub2QBMUIpWA3fYWKe5t8ivCrACOl9O0+u/upJihO/7bPQj4ycpZAqzPdKlaW4WvVhmFoLXmeEs82TVpMi9acKB1+k10ZJJHpw= Received: from DB6PR0801CA0061.eurprd08.prod.outlook.com (2603:10a6:4:2b::29) by AM0PR08MB5009.eurprd08.prod.outlook.com (2603:10a6:208:160::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.21; Fri, 11 Oct 2019 10:56:12 +0000 Received: from DB5EUR03FT023.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e0a::206) by DB6PR0801CA0061.outlook.office365.com (2603:10a6:4:2b::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2347.16 via Frontend Transport; Fri, 11 Oct 2019 10:56:12 +0000 Authentication-Results: spf=temperror (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.infradead.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.infradead.org; dmarc=none action=none header.from=arm.com; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of arm.com: DNS Timeout) Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT023.mail.protection.outlook.com (10.152.20.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.15 via Frontend Transport; Fri, 11 Oct 2019 10:56:11 +0000 Received: ("Tessian outbound 0cf06bf5c60e:v33"); Fri, 11 Oct 2019 10:56:10 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 8a007ee49b10e978 X-CR-MTA-TID: 64aa7808 Received: from aa32cf6c135b.1 (ip-172-16-0-2.eu-west-1.compute.internal [104.47.4.57]) by 64aa7808-outbound-1.mta.getcheckrecipient.com id 48BECC57-E34D-4728-9C65-D5FF2659F6BC.1; Fri, 11 Oct 2019 10:56:05 +0000 Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02lp2057.outbound.protection.outlook.com [104.47.4.57]) by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id aa32cf6c135b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 11 Oct 2019 10:56:05 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EC/xLyzYCYbd6RIPi3kQpezBvJR4c6MCUsTREh31AfifkPl83vvNbaoniCvwhrhkBrcJpWjSu0/UNo1bQlOouDDlMrrh8EbUhQuxOKZ7NaNsPQtLWIv2stqrFVtAtvF0VFfl/mC2ka3mJc/DT7uBnLJEavwx4dLCWlp6/jOE6brai0dHOqQspIHgQLxCF4ZMYjWLv8/+qrlEYnBR5UNeSjmcj2FdU6E4YALDv4fEaQ6J+w4Ub0SGFCCgt8mrW9/Ftg8hFSbFi1pfKwx0y+iLwp8N4HjSRtXppVZY8ZQa+37hXthrwE0Lcpq/9n8Zg1wh2avs+Xg32szhC9fmU/21SQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yoXMqgkrVOlA9w3mwWbFLbUt4qFRzx5cc74EwqZiVtY=; b=hr7iN4l7nRdqG8XhvisBD/c3JclEECHdpUKtrB16ttqwlAPE7g6TrqfXVoPELp+sgq4o4G9c+jLpPAR7kuL4Wsvdued1r4zKPfc7+2mcUPFlo4B0kHgZnJvBGkJ39eKhyFRqboJ1Z0Y/rPDnIAW2DjAdytzRhuMWobGCoUxrORCp5KQhMQpJ0L9y2pFrnD+9i+UhabMWqlAp31sX6/cL4W17gSK4J5K7cwIwhHDZQ7ip7/J/Nnl8T5Yx7fiCEwv9ktfEFnlaJxU867L5b3Ygezpg4pa+WHVpCTl3v39kVTc8+jLMsY41zyc/Hriz9D9pG28TLAsM3MmK7PYcM/Ivyw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yoXMqgkrVOlA9w3mwWbFLbUt4qFRzx5cc74EwqZiVtY=; b=dfCRgbIAV1zlJn+vUpOnPUVJEGyckcwqYVkyVZDcJnAxMwXCnnnkRJiWPjsEas0hWsdY7ZaJH4Ub2QBMUIpWA3fYWKe5t8ivCrACOl9O0+u/upJihO/7bPQj4ycpZAqzPdKlaW4WvVhmFoLXmeEs82TVpMi9acKB1+k10ZJJHpw= Received: from AM6PR08MB3829.eurprd08.prod.outlook.com (20.178.89.14) by AM6PR08MB4820.eurprd08.prod.outlook.com (10.255.99.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.19; Fri, 11 Oct 2019 10:56:00 +0000 Received: from AM6PR08MB3829.eurprd08.prod.outlook.com ([fe80::ce0:f47b:919d:561a]) by AM6PR08MB3829.eurprd08.prod.outlook.com ([fe80::ce0:f47b:919d:561a%5]) with mapi id 15.20.2347.021; Fri, 11 Oct 2019 10:56:00 +0000 From: Brian Starkey To: Neil Armstrong Subject: Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane Thread-Topic: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane Thread-Index: AQHVgA+hW0YpyPd1Sk22upjR9Lo04KdVKIOAgAAcS4A= Date: Fri, 11 Oct 2019 10:56:00 +0000 Message-ID: <20191011105559.clttghy52wfdmb34@DESKTOP-E1NTVVP.localdomain> 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> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: NeoMutt/20180716-849-147d51-dirty x-originating-ip: [217.140.106.54] x-clientproxiedby: LO2P265CA0120.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::36) To AM6PR08MB3829.eurprd08.prod.outlook.com (2603:10a6:20b:85::14) Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Brian.Starkey@arm.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 0c4f4911-f4a2-46d3-ef2e-08d74e39a11b X-MS-Office365-Filtering-HT: Tenant X-MS-TrafficTypeDiagnostic: AM6PR08MB4820:|AM6PR08MB4820:|AM0PR08MB5009: X-MS-Exchange-PUrlCount: 4 x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 0187F3EA14 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(346002)(376002)(366004)(39860400002)(199004)(189003)(51914003)(52314003)(305945005)(71190400001)(71200400001)(478600001)(58126008)(7736002)(6116002)(8676002)(54906003)(3846002)(6246003)(2906002)(966005)(316002)(25786009)(6916009)(26005)(30864003)(64756008)(66446008)(1076003)(186003)(66946007)(66476007)(66556008)(6436002)(86362001)(5660300002)(52116002)(102836004)(6506007)(53546011)(6512007)(386003)(11346002)(8936002)(44832011)(6306002)(446003)(4326008)(66066001)(76176011)(9686003)(6486002)(476003)(486006)(99286004)(256004)(14444005)(14454004)(81156014)(81166006)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4820; H:AM6PR08MB3829.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: JIaJWUJWP0WG1PK/HOcJ3+PKQFY0r4CxGS1H1v5xai6h+tV6m35HwE6oMaNZGIq3KTlCJY6/SCEuUydy2Z6S6PjW/zIZvDEo8Vj8OZ73FW9zk6U95ioz53+G5VyR9H8yKEkfaMouS0dxv9X0T/JZQSrpQng9J4qblHcVhE8IribIjVwUvEsUDoB5Is65YVkg6lkboIDRXTZQj4d0IW6E5X/p75MM6bPxPP7hD1O0uO0HwAGLQGCd3u9PqiXNtnZGDXdcpNZJe1Nq8wVnuCSdzyin7tcZfTfaDWZTYSGYqfghW7Hs9ruvLYwycLN3mZuMIx7INhKDrYoaKIU8WyNbcR73W8tgJEELX1oaSO4ZRQDnRVxzBGF6axxPjW8gof1BPGmLpE6iOGMMynXSrVSmpLzlVkJ9IhHiuhsUYFg2pWLua34tPyu9/bqGFBJWkNDhvpgLvYbD5wIw25jYRNZL6Q== Content-ID: MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4820 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Brian.Starkey@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT023.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(346002)(376002)(39860400002)(199004)(189003)(51914003)(52314003)(76130400001)(6116002)(3846002)(46406003)(54906003)(229853002)(70206006)(6486002)(6862004)(4326008)(99286004)(9686003)(6512007)(6306002)(70586007)(58126008)(23726003)(316002)(22756006)(86362001)(6246003)(25786009)(7736002)(305945005)(30864003)(50466002)(1076003)(5660300002)(47776003)(66066001)(81166006)(81156014)(8676002)(8746002)(8936002)(450100002)(356004)(14444005)(186003)(14454004)(966005)(6506007)(126002)(53546011)(478600001)(76176011)(97756001)(386003)(102836004)(446003)(486006)(2906002)(11346002)(336012)(26005)(63350400001)(26826003)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB5009; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:TempError; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: 8f9169d1-aa18-41dc-0cb6-08d74e399a06 NoDisclaimer: True X-Forefront-PRVS: 0187F3EA14 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: v95fesv4TffCX+IrOLWOkQDc1SkKA9nCaaelIFPuwhhwZmH4ZHYlXXe6niVMGLtTseqfdNXsuh97yZ+/pwQbrGJX/Vht/v3T9Cz1Blx5pEMAY0+QYXn+Vaf8GPtYl0uDGns5wt2bHMQ16M7qbBbQxurX267XVuC7vWq7pdTJanEfjo6LIb5/DQGUdrhS4dDtPnsmVib+8ocRPZxE8FNY0sdTR86HyVCpdwMI3ugdPyepodj7PvBK3yl6B1+lCUdindmaCDUWNHimrSQNsdlUZQUXlh9lLJfbCUTs3Sw5XB5NLDxwD/07KU0h/sa+nXq8jRQ35DCCK/9Gx9LezPWKWSq8sUhmAUgp2K8HhIZvTWFHzkbp8DjjI3zmJQhUxrgl1yxX4AvISU6V6q4x8qiLwDBiBRKJrp1SY+wQg3iwUq8XaVsEMrP6OXBlnIHZkEWZPZrNEjymhEJX39NUi4CBEg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2019 10:56:11.8478 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0c4f4911-f4a2-46d3-ef2e-08d74e39a11b X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5009 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191011_035617_318268_10D1CFCC X-CRM114-Status: GOOD ( 18.09 ) 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 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. > > > > 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. > 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? 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. > 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. > > > >> 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. 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: Brian Starkey Subject: Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane Date: Fri, 11 Oct 2019 10:56:00 +0000 Message-ID: <20191011105559.clttghy52wfdmb34@DESKTOP-E1NTVVP.localdomain> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40068.outbound.protection.outlook.com [40.107.4.68]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7B4606EC0E for ; Fri, 11 Oct 2019 10:56:17 +0000 (UTC) In-Reply-To: Content-Language: en-US Content-ID: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Neil Armstrong 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 SGksCgpPbiBGcmksIE9jdCAxMSwgMjAxOSBhdCAxMToxNDo0M0FNICswMjAwLCBOZWlsIEFybXN0 cm9uZyB3cm90ZToKPiBIaSBCcmlhbiwKPiAKPiBPbiAxMS8xMC8yMDE5IDEwOjQxLCBCcmlhbiBT dGFya2V5IHdyb3RlOgo+ID4gSGkgTmVpbCwKPiA+IAo+ID4gT24gVGh1LCBPY3QgMTAsIDIwMTkg YXQgMDM6NDE6MTVQTSArMDIwMCwgTmVpbCBBcm1zdHJvbmcgd3JvdGU6Cj4gPj4gSGkgQXlhbiwK PiA+Pgo+ID4+IE9uIDEwLzEwLzIwMTkgMTU6MjYsIEF5YW4gSGFsZGVyIHdyb3RlOgo+ID4+PiBP biBUaHUsIE9jdCAxMCwgMjAxOSBhdCAxMToyNToyM0FNICswMjAwLCBOZWlsIEFybXN0cm9uZyB3 cm90ZToKPiA+Pj4+IFRoaXMgYWRkcyBhbGwgdGhlIE9TRCBjb25maWd1cmF0aW9uIHBsdW1iaW5n IHRvIHN1cHBvcnQgdGhlIEFGQkMgZGVjb2RlcnMKPiA+Pj4+IHBhdGggdG8gZGlzcGxheSBvZiB0 aGUgT1NEMSBwbGFuZS4KPiA+Pj4+Cj4gPj4+PiBUaGUgQW1sb2dpYyBHWE0gYW5kIEcxMkEgQUZC QyBkZWNvZGVycyBhcmUgaW50ZWdyYXRlZCB2ZXJ5IGRpZmZlcmVudGx5Lgo+ID4+Pj4KPiA+Pj4+ IFRoZSBBbWxvZ2ljIEdYTSBoYXMgYSBkaXJlY3Qgb3V0cHV0IHBhdGggdG8gdGhlIE9TRDEgVklV IHBpeGVsIGlucHV0LAo+ID4+Pj4gYmVjYXVzZSB0aGUgR1hNIEFGQkMgZGVjb2RlciBzZWVtIHRv IGJlIGEgY3VzdG9tIElQIGRldmVsb3BlZCBieSBBbWxvZ2ljLgo+ID4+Pj4KPiA+Pj4+IE9uIHRo ZSBvdGhlciBzaWRlLCB0aGUgQW1sb2dpYyBHMTJBIEFGQkMgZGVjb2RlciBzZWVtcyB0byBiZSBh biBleHRlcm5hbAo+ID4+Pj4gSVAgdGhhdCBlbWl0IHBpeGVscyBvbiBhbiBBWEkgbWFzdGVyIGhv b2tlZCB0byBhICJNYWxpIFVucGFjayIgYmxvY2sKPiA+Pj4+IGZlZWRpbmcgdGhlIE9TRDEgVklV IHBpeGVsIGlucHV0Lgo+ID4+Pj4gVGhpcyB1c2VzIGEgd2VpcmQgIjB4MTAwMDAwMCIgaW50ZXJu YWwgSFcgcGh5c2ljYWwgYWRkcmVzcyBvbiBib3RoCj4gPj4+PiBzaWRlcyB0byB0cmFuc2ZlciB0 aGUgcGl4ZWxzLgo+ID4+Pj4KPiA+Pj4+IEZvciBBbWxvZ2ljIEdYTSwgdGhlIHN1cHBvcnRlZCBw aXhlbCBmb3JtYXRzIGFyZSB0aGUgc2FtZSBhcyB0aGUgbm9ybWFsCj4gPj4+PiBsaW5lYXIgT1NE MSBtb2RlLgo+ID4+Pj4KPiA+Pj4+IE9uIHRoZSBvdGhlciBzaWRlLCBBbWxvZ2ljIGFkZGVkIHN1 cHBvcnQgZm9yIGFsbCBBRkJDIHYxLjIgZm9ybWF0cyBmb3IKPiA+Pj4+IHRoZSBHMTJBIEFGQkMg aW50ZWdyYXRpb24uCj4gPj4+Pgo+ID4+Pj4gRm9yIHNpbXBsaWNpdHksIHdlIHN0aWNrIHRvIHRo ZSBhbHJlYWR5IHN1cHBvcnRlZCBmb3JtYXRzIGZvciBub3cuCj4gPj4+Pgo+ID4+Pj4gU2lnbmVk LW9mZi1ieTogTmVpbCBBcm1zdHJvbmcgPG5hcm1zdHJvbmdAYmF5bGlicmUuY29tPgo+ID4+Pj4g LS0tCj4gPj4+PiAgZHJpdmVycy9ncHUvZHJtL21lc29uL21lc29uX2NydGMuYyAgfCAgIDIgKwo+ ID4+Pj4gIGRyaXZlcnMvZ3B1L2RybS9tZXNvbi9tZXNvbl9kcnYuaCAgIHwgICA0ICsKPiA+Pj4+ ICBkcml2ZXJzL2dwdS9kcm0vbWVzb24vbWVzb25fcGxhbmUuYyB8IDIxNSArKysrKysrKysrKysr KysrKysrKysrKystLS0tCj4gPj4+PiAgMyBmaWxlcyBjaGFuZ2VkLCAxOTAgaW5zZXJ0aW9ucygr KSwgMzEgZGVsZXRpb25zKC0pCj4gPj4+Pgo+ID4+Pj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvZ3B1 L2RybS9tZXNvbi9tZXNvbl9jcnRjLmMgYi9kcml2ZXJzL2dwdS9kcm0vbWVzb24vbWVzb25fY3J0 Yy5jCj4gPj4+PiBpbmRleCA1N2FlMWMxM2QxZTYuLmQ0NzhmYTIzMjk1MSAxMDA2NDQKPiA+Pj4+ IC0tLSBhL2RyaXZlcnMvZ3B1L2RybS9tZXNvbi9tZXNvbl9jcnRjLmMKPiA+Pj4+ICsrKyBiL2Ry aXZlcnMvZ3B1L2RybS9tZXNvbi9tZXNvbl9jcnRjLmMKPiA+Pj4+IEBAIC0yODEsNiArMjgxLDgg QEAgdm9pZCBtZXNvbl9jcnRjX2lycShzdHJ1Y3QgbWVzb25fZHJtICpwcml2KQo+ID4+Pj4gIAlp ZiAocHJpdi0+dml1Lm9zZDFfZW5hYmxlZCAmJiBwcml2LT52aXUub3NkMV9jb21taXQpIHsKPiA+ Pj4+ICAJCXdyaXRlbF9yZWxheGVkKHByaXYtPnZpdS5vc2QxX2N0cmxfc3RhdCwKPiA+Pj4+ICAJ CQkJcHJpdi0+aW9fYmFzZSArIF9SRUcoVklVX09TRDFfQ1RSTF9TVEFUKSk7Cj4gPj4+PiArCQl3 cml0ZWxfcmVsYXhlZChwcml2LT52aXUub3NkMV9jdHJsX3N0YXQyLAo+ID4+Pj4gKwkJCQlwcml2 LT5pb19iYXNlICsgX1JFRyhWSVVfT1NEMV9DVFJMX1NUQVQyKSk7Cj4gPj4+PiAgCQl3cml0ZWxf cmVsYXhlZChwcml2LT52aXUub3NkMV9ibGswX2NmZ1swXSwKPiA+Pj4+ICAJCQkJcHJpdi0+aW9f YmFzZSArIF9SRUcoVklVX09TRDFfQkxLMF9DRkdfVzApKTsKPiA+Pj4+ICAJCXdyaXRlbF9yZWxh eGVkKHByaXYtPnZpdS5vc2QxX2JsazBfY2ZnWzFdLAo+ID4+Pj4gZGlmZiAtLWdpdCBhL2RyaXZl cnMvZ3B1L2RybS9tZXNvbi9tZXNvbl9kcnYuaCBiL2RyaXZlcnMvZ3B1L2RybS9tZXNvbi9tZXNv bl9kcnYuaAo+ID4+Pj4gaW5kZXggNjBmMTNjNmYzNGU1Li5kZTI1MzQ5YmU4YWEgMTAwNjQ0Cj4g Pj4+PiAtLS0gYS9kcml2ZXJzL2dwdS9kcm0vbWVzb24vbWVzb25fZHJ2LmgKPiA+Pj4+ICsrKyBi L2RyaXZlcnMvZ3B1L2RybS9tZXNvbi9tZXNvbl9kcnYuaAo+ID4+Pj4gQEAgLTUzLDggKzUzLDEy IEBAIHN0cnVjdCBtZXNvbl9kcm0gewo+ID4+Pj4gIAkJYm9vbCBvc2QxX2VuYWJsZWQ7Cj4gPj4+ PiAgCQlib29sIG9zZDFfaW50ZXJsYWNlOwo+ID4+Pj4gIAkJYm9vbCBvc2QxX2NvbW1pdDsKPiA+ Pj4+ICsJCWJvb2wgb3NkMV9hZmJjZDsKPiA+Pj4+ICAJCXVpbnQzMl90IG9zZDFfY3RybF9zdGF0 Owo+ID4+Pj4gKwkJdWludDMyX3Qgb3NkMV9jdHJsX3N0YXQyOwo+ID4+Pj4gIAkJdWludDMyX3Qg b3NkMV9ibGswX2NmZ1s1XTsKPiA+Pj4+ICsJCXVpbnQzMl90IG9zZDFfYmxrMV9jZmc0Owo+ID4+ Pj4gKwkJdWludDMyX3Qgb3NkMV9ibGsyX2NmZzQ7Cj4gPj4+PiAgCQl1aW50MzJfdCBvc2QxX2Fk ZHI7Cj4gPj4+PiAgCQl1aW50MzJfdCBvc2QxX3N0cmlkZTsKPiA+Pj4+ICAJCXVpbnQzMl90IG9z ZDFfaGVpZ2h0Owo+ID4+Pj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvZ3B1L2RybS9tZXNvbi9tZXNv bl9wbGFuZS5jIGIvZHJpdmVycy9ncHUvZHJtL21lc29uL21lc29uX3BsYW5lLmMKPiA+Pj4+IGlu ZGV4IDVlNzk4YzI3NjAzNy4uNDEyOTQxYWE4NDAyIDEwMDY0NAo+ID4+Pj4gLS0tIGEvZHJpdmVy cy9ncHUvZHJtL21lc29uL21lc29uX3BsYW5lLmMKPiA+Pj4+ICsrKyBiL2RyaXZlcnMvZ3B1L2Ry bS9tZXNvbi9tZXNvbl9wbGFuZS5jCj4gPj4+PiBAQCAtMjMsNiArMjMsNyBAQAo+ID4+Pj4gICNp bmNsdWRlICJtZXNvbl9wbGFuZS5oIgo+ID4+Pj4gICNpbmNsdWRlICJtZXNvbl9yZWdpc3RlcnMu aCIKPiA+Pj4+ICAjaW5jbHVkZSAibWVzb25fdml1LmgiCj4gPj4+PiArI2luY2x1ZGUgIm1lc29u X29zZF9hZmJjZC5oIgo+ID4+Pj4gIAo+ID4+Pj4gIC8qIE9TRF9TQ0lfV0hfTTEgKi8KPiA+Pj4+ ICAjZGVmaW5lIFNDSV9XSF9NMV9XKHcpCQkJRklFTERfUFJFUChHRU5NQVNLKDI4LCAxNiksIHcp Cj4gPj4+PiBAQCAtOTIsMTIgKzkzLDM4IEBAIHN0YXRpYyBpbnQgbWVzb25fcGxhbmVfYXRvbWlj X2NoZWNrKHN0cnVjdCBkcm1fcGxhbmUgKnBsYW5lLAo+ID4+Pj4gIAkJCQkJCSAgIGZhbHNlLCB0 cnVlKTsKPiA+Pj4+ICB9Cj4gPj4+PiAgCj4gPj4+PiArI2RlZmluZSBNRVNPTl9NT0RfQUZCQ19W QUxJRF9CSVRTIChBRkJDX0ZPUk1BVF9NT0RfQkxPQ0tfU0laRV8xNngxNiB8CVwKPiA+Pj4+ICsJ CQkJICAgQUZCQ19GT1JNQVRfTU9EX0JMT0NLX1NJWkVfMzJ4OCB8CVwKPiA+Pj4+ICsJCQkJICAg QUZCQ19GT1JNQVRfTU9EX1lUUiB8CQlcCj4gPj4+PiArCQkJCSAgIEFGQkNfRk9STUFUX01PRF9T UEFSU0UgfAkJXAo+ID4+Pj4gKwkJCQkgICBBRkJDX0ZPUk1BVF9NT0RfU1BMSVQpCj4gPj4+PiAr Cj4gPj4+PiAgLyogVGFrZXMgYSBmaXhlZCAxNi4xNiBudW1iZXIgYW5kIGNvbnZlcnRzIGl0IHRv IGludGVnZXIuICovCj4gPj4+PiAgc3RhdGljIGlubGluZSBpbnQ2NF90IGZpeGVkMTZfdG9faW50 KGludDY0X3QgdmFsdWUpCj4gPj4+PiAgewo+ID4+Pj4gIAlyZXR1cm4gdmFsdWUgPj4gMTY7Cj4g Pj4+PiAgfQo+ID4+Pj4gIAo+ID4+Pj4gK3N0YXRpYyB1MzIgbWVzb25fZzEyYV9hZmJjZF9saW5l X3N0cmlkZShzdHJ1Y3QgbWVzb25fZHJtICpwcml2KQo+ID4+Pj4gK3sKPiA+Pj4+ICsJdTMyIGxp bmVfc3RyaWRlID0gMDsKPiA+Pj4+ICsKPiA+Pj4+ICsJc3dpdGNoIChwcml2LT5hZmJjZC5mb3Jt YXQpIHsKPiA+Pj4+ICsJY2FzZSBEUk1fRk9STUFUX1JHQjU2NToKPiA+Pj4+ICsJCWxpbmVfc3Ry aWRlID0gKChwcml2LT52aXUub3NkMV93aWR0aCA8PCA0KSArIDEyNykgPj4gNzsKPiA+Pj4+ICsJ CWJyZWFrOwo+ID4+Pj4gKwljYXNlIERSTV9GT1JNQVRfUkdCODg4Ogo+ID4+Pj4gKwljYXNlIERS TV9GT1JNQVRfWFJHQjg4ODg6Cj4gPj4+PiArCWNhc2UgRFJNX0ZPUk1BVF9BUkdCODg4ODoKPiA+ Pj4+ICsJY2FzZSBEUk1fRk9STUFUX1hCR1I4ODg4Ogo+ID4+Pj4gKwljYXNlIERSTV9GT1JNQVRf QUJHUjg4ODg6Cj4gPj4+IFBsZWFzZSBoYXZlIGEgbG9vayBhdAo+ID4+PiBodHRwczovL3d3dy5r ZXJuZWwub3JnL2RvYy9odG1sL2xhdGVzdC9ncHUvYWZiYy5odG1sIGZvciBvdXIKPiA+Pj4gcmVj b21tZW5kYXRpb24uIFdlIHN1Z2dlc3QgdGhhdCAqWCogZm9ybWF0cyBhcmUgYXZvaWRlZC4KPiA+ Pj4KPiA+Pj4gQWxzbywgZm9yIGludGVyb3BlcmFiaWxpdHkgYW5kIG1heGltdW0gY29tcHJlc3Np b24gZWZmaWNpZW5jeSAod2l0aAo+ID4+PiBBRkJDX0ZPUk1BVF9NT0RfWVRSKSwgd2Ugc3VnZ2Vz dCB0aGUgZm9sbG93aW5nIG9yZGVyIDotCj4gPj4+Cj4gPj4+ICAgICAgICAgQ29tcG9uZW50IDA6 IFIKPiA+Pj4gICAgICAgICBDb21wb25lbnQgMTogRwo+ID4+PiAgICAgICAgIENvbXBvbmVudCAy OiBCCj4gPj4+ICAgICAgICAgQ29tcG9uZW50IDM6IEEgKGlmIGF2YWlsYWJsZSkKPiA+Pgo+ID4+ Cj4gPj4gU29ycnkgSSBkb24ndCB1bmRlcnN0YW5kLCB5b3UgYXNrIG1lIHRvIGxpbWl0IEFGQkMg dG8gQUJHUjg4ODggPwo+ID4+Cj4gPj4gQnV0IHdoeSBpZiB0aGUgSFcgKEdQVSBhbmQgRFBVKSBp cyBjYXBhYmxlIG9mID8KPiA+IAo+ID4gQUZCQyBkb2Vzbid0IGhhdmUgYW4gaW4tbWVtb3J5IGNv bXBvbmVudCBvcmRlciBpbiB0aGUgdHJhZGl0aW9uYWwKPiA+IHNlbnNlIChpLmUuIGEgYml0LXBv c2l0aW9uIHRvIGNvbXBvbmVudCBtYXBwaW5nKSwgc28gQXJtCj4gPiBoYXZlIGRlY2lkZWQgdG8g ZGVmaW5lIHRoZSBjb252ZW50aW9uIHRoYXQgRFJNX0ZPUk1BVF9BQkdSODg4OAo+ID4gcmVwcmVz ZW50cyB0aGUgQUZCQyBsYXlvdXQgd2l0aCBSIGluIGNvbXBvbmVudCAwLgo+IAo+IEluIHRoaXMg aW1wbGVtZW50YXRpb24sIHdlIGhhbmRsZSB0aGUgQVJHQi9BQkdSIGFzIHRoZSBzYW1lIG1vZGUK PiBzaW5jZSB0aGUgQUZCQyBjYW4gb25seSByZXByZXNlbnQgdGhlIGxheW91dCBhcyAiQUJHUiIg YW55d2F5Lgo+IAoKSW4gdGhpcyBjYXNlLCB3aXRoIHRoZSBleHRlcm5hbCBBRkJDIElQLCB0aGVy ZSdzIGEgd2hvbGUgZXh0cmEgbGF5ZXIKb2YgcG90ZW50aWFsIGNvbmZ1c2lvbiA6LSgKClRoZSBk ZWNvZGVyIG9ubHkgbmVlZHMgdG8ga25vdyB0aGUgbnVtYmVyIG9mIGNvbXBvbmVudHMgLSBzbwpp cnJlc3BlY3RpdmUgb2Ygd2hhdCBjb2xvciBjaGFubmVsIGlzIG1hcHBlZCB0byB3aGF0IGNvbXBv bmVudCwgaXQgY2FuCmFsd2F5cyBiZSBjb25maWd1cmVkIHdpdGggdGhlIHNhbWUgbW9kZSBmb3Ig NC1jb21wb25lbnQgMzItYml0CmZvcm1hdHMuCgpGb3IgZXZlcnl0aGluZyB0byB3b3JrIGNvcnJl Y3RseSB3aXRoIFlUUiwgdGhlIHRoaW5nIGNvbnN1bWluZyB0aGUKb3V0cHV0IGZyb20gdGhlIGRl Y29kZXIgbXVzdCB0cmVhdCBjb21wb25lbnQgMCBhcyAnUicsIGJ1dCBvdGhlcndpc2UKaXQgZG9l c24ndCBtYXR0ZXIuCgpJcyB5b3VyIEhXIGFibGUgdG8gdHJlYXQgdGhlIGRlY29kZXIgb3V0cHV0 IGluIGRpZmZlcmVudCB3YXlzPyBlLmcuCm1hcHBpbmcgY29tcG9uZW50IDAgdG8gJ0InPyBJZiB0 aGF0J3MgdGhlIGNhc2UsIHRoZW4gZXhwb3NpbmcgdGhlCmRpZmZlcmVudCBvcmRlcnMgaXMgdmFs aWQgLSBidXQgb25seSBBQkdSIHNob3VsZCBhbGxvdyBZVFIuCgo+ID4gCj4gPiBBcmUgeW91IHN1 cmUgdGhlIEdQVSBzdXBwb3J0cyBvdGhlciBvcmRlcnM/IEkgdGhpbmsgYW55IEFybSBkcml2ZXIK PiA+IHdpbGwgb25seSBiZSBwcm9kdWNpbmcgRFJNX0ZPUk1BVHMgd2l0aCAiQkdSIiBvcmRlciBl LmcuIEFCR1I4ODg+Cj4gPiBJJ20gbm90IGNvbnZpbmNlZCB0aGUgR1BVIEhXIGFjdHVhbGx5IHN1 cHBvcnRzIGFueSBvdGhlciBvcmRlciwgYnV0Cj4gPiBpdCdzIGFsbCByYXRoZXIgY29uZnVzaW5n IHdpdGggdGV4dHVyZSBzd2l6emxpbmcuIFdoYXQgSSBjYW4gdGVsbCB5b3UKPiA+IGZvciBzdXJl IGlzIHRoYXQgaXQgX2RvZXNfIHN1cHBvcnQgQkdSIG9yZGVyIChpbiBEUk0gbmFtaW5nCj4gPiBj b252ZW50aW9uKS4KPiAKPiBXZWxsLCBzaW5jZSB0aGUgQmlmcm9zdCBNYWxpIGJsb2JzIGFyZSBj bG9zZWQtc291cmNlIGFuZCBkZWxpdmVyZWQKPiBieSBsaWNlbnNlZXMsIGl0J3MgaGFyZCB0byBk ZWZpbmUgd2hhdCBpcyBzdXBwb3J0ZWQgZnJvbSBhIGNsb3NlZAo+IEdQVSBIVywgY2xvc2VkIFNX IGltcGxlbWVudGF0aW9uIHRvIGEgY2xvc2VkIHBpeGVsIGZvcm1hdCBpbXBsZW1lbnRhdGlvbi4K PiAKCkkgaGVhciB5b3UuIElNTyB0aGUgb25seSB3YXkgdG8gbWFrZSBhbnkgb2YgdGhpcyBjbGVh ciBpcyB0byBwdWJsaXNoCnJlZmVyZW5jZSBkYXRhIGFuZCB0ZXN0cyB3aGljaCBtYWtlIHN1cmUg aW1wbGVtZW50YXRpb25zIG1hdGNoIGVhY2gKb3RoZXIuIEl0J3Mgc29tZXRoaW5nIEknbSB0cnlp bmcgdG8gbWFrZSBoYXBwZW4uCgo+IFlvdSdsbCBoYXZlIHRvIHRlbGwgdXMgaWYgdGhlIGNsb3Nl ZCBsaWJNYWxpIGhhbmRsaW5nIEFGQkMgd291bGQgYWNjZXB0Cj4gQVJHQjg4ODggYXMgZm9ybWF0 IHRvIHJlbmRlciB3aXRoIEFGQkMgZW5hYmxlZCwgaWYgbm90IHlvdSdyZSByaWdodAo+IEknbGwg ZGlzY2FyZCBYUkdCODg4OC9BUkdCODg4OCBmb3IgQUZCQyBidWZmZXJzIGNvbXBsZXRlbHkuCj4g Cj4gQnV0IGl0IHRoZSBsaWJNYWxpIGNob29zZXMgdHQgZ2VuZXJhdGUgYW4gQVJHQjg4ODggYnVm ZmVyIHdoYXRldmVyCj4gQVJHQjg4ODgvWFJHQjg4ODgvQUJHUjg4OC9YQkdSODg4IGlzIGFza2Vk LCB0aGVuIG5vIEknbGwga2VlcCBpdCB0aGF0IHdheS4KPiAKClllYWgsIEknbGwgdHJ5IGFuZCBn ZXQgY2xhcml0eSBvbiB0aGlzLiBJdCdzIG5vdCBhdCBhbGwgY2xlYXIgdG8gbWUKZWl0aGVyLiBX aGVuIHlvdSBzYXkgImFjY2VwdCBBUkdCODg4OCBhcyBmb3JtYXQgdG8gcmVuZGVyIHdpdGggQUZC QwplbmFibGVkIiwgd2hpY2ggQVBJIGFyZSB5b3UgcmVmZXJyaW5nIHRvLCBqdXN0IHNvIEkgY2Fu IGJlIGNsZWFyPyBEbwp5b3UgaGF2ZSBhbiBleGFtcGxlIG9mIHNvbWUgY29kZSB5b3UncmUgdXNp bmcgdG8gcmVuZGVyIEFGQkMgd2l0aCB0aGUKR1BVIGJsb2I/CgpJbiBtYW55IEFQSXMsIHRoZXJl J3Mgbm8gcmVhbCBleHBlY3RhdGlvbiBvbiBpbi1tZW1vcnkgY29tcG9uZW50Cm9yZGVyLCBzbyBw ZXJoYXBzIHRoZXJlIHRyZWF0aW5nIHRoZW0gYXMgYWxsIHRoZSBzYW1lIGlzIGFjY2VwdGFibGUu CgpIb3dldmVyLCBmb3VyY2MgKyBBRkJDIG1vZGlmaWVyIGlzIGV4cGxpY2l0IGluIHRlcm1zIG9m IGNvbXBvbmVudApvcmRlciwgYW5kIHNvIElNTyBpdCdzIHZlcnkgaGFybWZ1bCB0byAiaWdub3Jl IiBjb21wb25lbnQgb3JkZXIgaW4KaW50ZXJmYWNlcyB1c2luZyBmb3VyY2MgKyBBRkJDIG1vZGlm aWVyLgoKVGhlcmUgYXJlIGltcGxlbWVudGF0aW9ucyB3aGljaCBzdXBwb3J0IG90aGVyIG9yZGVy cywgc28gaWdub3JpbmcKb3JkZXIgd2lsbCBicmVhayB0aG9zZSBpbXBsZW1lbnRhdGlvbnMuIElu IHNvbWUgY2FzZXMgKEFuZHJvaWQsIG1heWJlCkdMKSwgdGhpcyBjYW4gYmUgaGlkZGVuIGJlaGlu ZCAiZHJpdmVyIG1hZ2ljIiwgYnV0IGlmIHRoZSBBUEkgaXMKZm91cmNjICsgQUZCQyBtb2RpZmll ciwgSU1PIGl0IGhhZCBiZXR0ZXIgYmUgY29tcGxldGVseSBleHBsaWNpdCB3aXRoCm5vIHRyaWNr cyAtIGlycmVzcGVjdGl2ZSBvZiB3aGF0ZXZlciBvdGhlciBsZXNzLXByZXNjcmlwdGl2ZSBBUElz IGRvLgoKPiBCVFcgSSBrZXB0IHRoZSB2ZW5kb3IgaW1wbGVtZW50YXRpb24gaGVyZSwgd2hpY2gg bWF5IGJlIHdyb25nIGJ1dCBzaW5jZQo+IHRoZXkgaGF2ZSB0aGUgQUZCQyBJUCBsaWNlbnNlIGFu ZCBNYWxpIEJpZnJvc3QgR1BVIGxpY2Vuc2UuLi4KPiAKPiA+IAo+ID4gSWYgeW91IGRvIGNob29z ZSB0byBleHBvc2Ugb3JkZXJzIG90aGVyIHRoYW4gQkdSL0FCR1IsIHRoZW4geW91IHNob3VsZAo+ ID4gY2VydGFpbmx5IG5vdCBhbGxvdyBZVFIgdG8gYmUgdXNlZCB3aXRoIGFueSBvcmRlcnMgb3Ro ZXIgdGhhbgo+ID4gQkdSL0FCR1IuIFRoZSBBRkJDIHNwZWMgZGVmaW5lcyBZVFIgYXMgdXNpbmcg UiBpbiBjb21wb25lbnQgMCwgd2hpY2gKPiA+IEFybSBoYXMgZGVmaW5lZCBhcyBEUk1fRk9STUFU XypCR1IqIChjb21wb25lbnQgMCBpbiBMRSBMU0JzKS4KPiA+IAo+IAo+IFRoZSBNQUZCQ19GTVRf UkdCQTg4ODggcGl4ZWwgZm9ybWF0IGlzIGRlZmluZWQgaW4gdGhlIEFGQkMgZGVjb2RlciwKPiB3 aGljaCBzZWVtcyB0byBiZSBhbiBBUk0gSVAsIHRoZSByZWdpc3RlcnMgZG9jdW1lbnRhdGlvbiBp cyBpbiB0aGUKPiBTb0MgZGF0YXNoZWV0IGF0IFsxXSBhbmQgdGhlIGZvcm1hdHMgYml0cyBhcmUg ZGVmaW5lZCBpbiB0aGUgcGF0Y2ggMyBhdCBbMl0uCj4gCj4gU28gaXQgc2VlbXMgdGhlIGRlY29k ZXIgaGFuZGxlcyBvbmx5IGEgc2luZ2xlIHR5cGUgZm9yIDMyYml0IFJHQiBidWZmZXIKPiBmb3Jt YXQsIGFzIEFtbG9naWMgbmFtZXMgaXQgTUFGQkNfRk1UX1JHQkE4ODg4Cj4gCgpIb3BlZnVsbHkg bXkgY29tbWVudHMgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGlzIG1haWwgaGVscHMgY2xlYXIgdGhp cwpwYXJ0IHVwIGEgYml0LgoKPiBGb3IgWFJHQjg4ODgvWEJHUjg4ODggd2Ugc2ltcGx5ICJyZXBs YWNlIiB0aGUgQSBjb21wb25lbnQgd2l0aCBhIGZpeGVkCj4gdmFsdWUgaW4gdGhlIHBpeGVsIGdl bmVyYXRvci4KClRoYXQgc2VlbXMgY29ycmVjdCwgc28gbG9uZyBhcyB0aGUgZGVjb2RlciBpcyBj b25maWd1cmVkIGluIHRoZQo0LWNvbXBvbmVudCBtb2RlLgoKPiAKPiBbMV0gaHR0cHM6Ly9kbC5r aGFkYXMuY29tL0hhcmR3YXJlL1ZJTTMvRGF0YXNoZWV0L1M5MDVEM19kYXRhc2hlZXRfMC4yX1dl c2lvbi5wZGYgcGFnZSA3NzIKPiBbMl0gaHR0cHM6Ly9wYXRjaHdvcmsuZnJlZWRlc2t0b3Aub3Jn L3BhdGNoLzMzNTE5OS8/c2VyaWVzPTY3ODMyJnJldj0xCj4gCj4gPj4KPiA+PiBJc24ndCBpdCBh biB1c2Vyc3BhY2UgY2hvaWNlID8gSSB1bmRlcnN0YW5kIFhSR0I4ODg4IGlzIGEgd2FzdGUKPiA+ PiBvZiBtZW1vcnkgc3BhY2UgYW5kIGNvbXByZXNzaW9uIGVmZmljaWVuY3ksIGJ1dCB0aGlzIGlz IG5vdCB0aGUKPiA+PiBrZXJuZWwgZHJpdmVyJ3MgdG8gZGVjaWRlIHRoaXMsIHJpZ2h0ID8KPiA+ Pgo+ID4gCj4gPiBBcyBsb25nIGFzIGl0J3MgYWdyZWVkIGFuZCB1bmRlcnN0b29kIHdoYXQgWFJH Qjg4ODggbWVhbnMuIEl0IG11c3QgYmUKPiA+IGFuIEFGQkMgYml0c3RyZWFtIHdpdGggNC1jb21w b25lbnRzLCB3aXRoIEIgaW4gY29tcG9uZW50IDAsIEcgaW4KPiA+IGNvbXBvbmVudCAxLCBSIGlu IGNvbXBvbmVudCAyIGFuZCA4IHdhc3RlZCBiaXRzIGluIGNvbXBvbmVudCAzLgo+IAo+IFllcywg YnV0IHRoaXMgaXMgc29tZXRoaW5nIHVzZXJzcGFjZSBtdXN0IGFzc3VtZSwgYW5kIGl0J3MgYWxy ZWFkeQo+IHdhc3RlZCBpbiB0aGUgbGluZWFyIFhSR0I4ODg4IGZvcm1hdCBhbnl3YXkuCj4gCj4g PiAKPiA+IEkga25vdyBvZiBIVyB3aGljaCB0cmVhdHMgIlhCR1IiIHdpdGggQUZCQyBhcyBhIDMt Y29tcG9uZW50IGZvcm1hdCwKPiA+IHdoaWNoIGlzbid0IGNvcnJlY3QgYnV0IGNhbiBlYXNpbHkg bGVhZCB0byBjb25mdXNpb24gYW5kCj4gPiBpbmNvbXBhdGliaWxpdHkuCj4gCj4gU2VlbXMgaXQn cyBub3QgdGhlIGNhc2UgaGVyZSwgYXQgbGVhc3QgZm9yIHRoZSBHMTJBIFNvQyBmYW1pbHkuCgpU aGF0J3MgZ29vZCA6LSkKCj4gCj4gPiAKPiA+PiBGb3IgaW50ZXJvcGVyYWJpbGl0eSBJJ2xsIHVu ZGVyc3RhbmQgcmVjb21tZW5kaW5nIGEgbWluaW1hbCBzZXQKPiA+PiBvZiBtb2RpZmllcnMgYW5k IGZvcm1hdHMuIEJ1dCBoZXJlLCBlYWNoIHBsYXRmb3JtIGlzIGFsc28gbGltaXRlZAo+ID4+IGJ5 IGl0J3MgR1BVIGNhcGFiaWxpdGVzIGFzd2VsbC4KPiA+Pgo+ID4gCj4gPiBUaGUgKEFybSkgR1BV cyBzdXBwb3J0IEFCR1Igb3JkZXJpbmcsIHNvIGlmIGV2ZXJ5b25lIHN0aWNrcyB0byB0aGF0IHdl Cj4gPiBjYW4gbWFrZSBzdXJlIGV2ZXJ5dGhpbmcncyBuaWNlIGFuZCBjb21wYXRpYmxlICh1bnRp bCBzb21lb25lIHR1cm5zIHVwCj4gPiB3aXRoIEhXIHdoaWNoIF9kb2Vzbid0XyBzdXBwb3J0IHRo YXQgb3JkZXJpbmcpLgo+IAo+IFRoaXMgaXMgbm90IGNsZWFuIGVub3VnaCBpbiB0aGUgaHR0cHM6 Ly93d3cua2VybmVsLm9yZy9kb2MvaHRtbC9sYXRlc3QvZ3B1L2FmYmMuaHRtbAo+IGRvY3VtZW50 LiBTaW5jZSBBUk0gaXMgaW4gY29udHJvbCBvZiB0aGUgcmVuZGVyZXJzLCBzYXlpbmcgQUZCQyBk b2VzIF9ub3RfCj4gc3VwcG9ydCBhbm90aGVyIGNvbXBvbmVudHMgZm9ybWF0IGFzIEFCR1Igb3Jk ZXJpbmcgaW4gYWxsIHRoZQo+IE9wZW5HTCBFUy9WdWxrYW4gaW1wbGVtZW50YXRpb25zLCBpdCB3 b3VsZCBiZSBjbGVhciB3ZSBjb3VsZG4ndCByZW5kZXIKPiBhbnl0aGluZyB1c2luZyBBRkJDIHdp dGggQVJHQi4KPiBCdXQgd2UgaGl0IHRoZSBjbG9zZWQtc291cmNlL2Nsb3NlZC1zcGVjaWZpY2F0 aW9ucyBoZXJlIGFnYWluLgo+IAoKSSBkaWRuJ3QgcmVhbGx5IHVuZGVyc3RhbmQgdGhlIG1pZGRs ZSBzZW50ZW5jZS4KCkkga25vdyBhbmQgdW5kZXJzdGFuZCB0aGF0IHRoZSAiY2xvc2VkLW5lc3Mi IGlzIGEgcHJvYmxlbS4gVGhlIHBhZ2UKeW91IGxpbmtlZCB3YXMgYW4gaW5pdGlhbCBhdHRlbXB0 IGF0IG1ha2luZyBhIGNsZWFyLCBwdWJsaWMKc3BlY2lmaWNhdGlvbi4KCldoYXQgSSBuZWVkIHRv IGJlIGNsZWFyIGFib3V0LCB0aG91Z2gsIGlzIHRoYXQgaXQgZGVzY3JpYmVzIF9vbmx5XwpjYXNl cyB3aGVyZSBEUk0gZm91cmNjICsgQUZCQyBtb2RpZmllciBhcmUgdXNlZC4gSSBkb24ndCB0aGlu ayB0aGVyZSdzCmFueSBzYW5lIHdheSB0byBhcHBseSBpdCB0byBvdGhlciBBUElzLCBiZWNhdXNl IHRoZSBmb3JtYXRzIGFyZQpkZXNjcmliZWQgZGlmZmVyZW50bHksIGFuZCB0aGUgImxlZXdheSIg YWxsb3dlZCBmb3IgZG9pbmcgdGhpbmdzCiJ1bmRlci10aGUtaG9vZCIgaXMgdmVyeSBkaWZmZXJl bnQuCgo+ID4gCj4gPj4gTGltaXRpbmcgdG8gQUJHUjg4ODggd291bGQgZGlzY2FyZCBsaWtlIGV2 ZXJ5IG5vbi1BbmRyb2lkIHJlbmRlcmVycywKPiA+PiB1c2luZyBBRkJDLCBJJ20gbm90IHN1cmUg aXQncyB0aGUga2VybmVscyBkcml2ZXIncyByZXNwb25zaWJpbGl0eS4KPiA+Pgo+ID4gCj4gPiBJ dCBwcmV2ZW50cyByZW5kZXJlcnMgd2l0aCBoYXJkLWNvZGVkIHBpeGVsIGZvcm1hdHMsIHBlcmhh cHMuIEJ1dAo+ID4gdGhvc2UgYXJlIGFscmVhZHkgZnJhZ2lsZSBieSBuYXR1cmUsIHN1cmVseT8K PiAKPiBXZWxsLCBleGNlcHQgQW5kcm9pZCwgYWxsIHRoZSBvdGhlciByZW5kZXJlcnMgdXNlcyBB UkdCODg4OC9YUkdCODg4OCwKPiBhcyBmaXhlZCBwaXhlbCBmb3JtYXQsIHdoaWNoIGlzIHF1aXRl IGEgbGFyZ2UgYW1vdW50IG9mIGNvZGUuCj4gCgpJIHRoaW5rIHdoZXRoZXIgdGhhdCBtYXR0ZXJz IG9yIG5vdCByZWFsbHkgZGVwZW5kcyBvbiB3aGljaCBncmFwaGljcwpBUElzIHlvdSdyZSByZWZl cnJpbmcgdG8uIElNTyBpdCdzIGluZXZpdGFibGUgdGhhdCBtb2RpZmllcnMgZG9uJ3QKc2ltcGx5 ICJkcm9wIGluIiBldmVyeXdoZXJlLiBUaGUga2VybmVsIEFQSSBhbGxvd3MgeW91IHRvIHF1ZXJ5 IHdoYXQncwpzdXBwb3J0ZWQgYW5kIHBpY2sgdGhhdC4KClRoYW5rcywKLUJyaWFuCgo+IAo+IEFu eXdheSwgdGhhbmtzIGZvciB0aGVzZSB0ZWNobmljYWwgY2xhcmlmaWNhdGlvbnMsIGl0IG1ha2Vz IHRoaW5ncwo+IG11Y2ggbW9yZSBjbGVhcmVyLgo+IAo+IE5laWwKPiAKPiA+IAo+ID4gQ2hlZXJz LAo+ID4gLUJyaWFuCj4gPiAKPiA+Pj4KPiA+Pj4gVGh1cywgRFJNX0ZPUk1BVF9BQkdSLCBEUk1f Rk9STUFUX0JHUiBzaG91bGQgb25seSBiZSBhbGxvd2VkLgo+ID4+Pj4gKwkJbGluZV9zdHJpZGUg PSAoKHByaXYtPnZpdS5vc2QxX3dpZHRoIDw8IDUpICsgMTI3KSA+PiA3Owo+ID4+Pj4gKwkJYnJl YWs7Cj4gPj4+PiArCX0KPiA+Pj4+ICsKPiA+Pj4+ICsJcmV0dXJuICgobGluZV9zdHJpZGUgKyAx KSA+PiAxKSA8PCAxOwo+ID4+Pj4gK30KPiA+Pj4+ICsKPiA+Pj4+ICBzdGF0aWMgdm9pZCBtZXNv bl9wbGFuZV9hdG9taWNfdXBkYXRlKHN0cnVjdCBkcm1fcGxhbmUgKnBsYW5lLAo+ID4+Pj4gIAkJ CQkgICAgICBzdHJ1Y3QgZHJtX3BsYW5lX3N0YXRlICpvbGRfc3RhdGUpCj4gPj4+PiAgewo+ID4+ Cj4gPj4gWy4uLl0KPiA+Pgo+ID4+Pj4gIAo+ID4+Pj4gK3N0YXRpYyBib29sIG1lc29uX3BsYW5l X2Zvcm1hdF9tb2Rfc3VwcG9ydGVkKHN0cnVjdCBkcm1fcGxhbmUgKnBsYW5lLAo+ID4+Pj4gKwkJ CQkJICAgICB1MzIgZm9ybWF0LCB1NjQgbW9kaWZpZXIpCj4gPj4+PiArewo+ID4+Pj4gKwlzdHJ1 Y3QgbWVzb25fcGxhbmUgKm1lc29uX3BsYW5lID0gdG9fbWVzb25fcGxhbmUocGxhbmUpOwo+ID4+ Pj4gKwlzdHJ1Y3QgbWVzb25fZHJtICpwcml2ID0gbWVzb25fcGxhbmUtPnByaXY7Cj4gPj4+PiAr CWludCBpOwo+ID4+Pj4gKwo+ID4+Pj4gKwlpZiAobW9kaWZpZXIgPT0gRFJNX0ZPUk1BVF9NT0Rf SU5WQUxJRCkKPiA+Pj4+ICsJCXJldHVybiBmYWxzZTsKPiA+Pj4+ICsKPiA+Pj4+ICsJaWYgKG1v ZGlmaWVyID09IERSTV9GT1JNQVRfTU9EX0xJTkVBUikKPiA+Pj4+ICsJCXJldHVybiB0cnVlOwo+ ID4+Pj4gKwo+ID4+Pj4gKwlpZiAoIW1lc29uX3ZwdV9pc19jb21wYXRpYmxlKHByaXYsIFZQVV9D T01QQVRJQkxFX0dYTSkgJiYKPiA+Pj4+ICsJICAgICFtZXNvbl92cHVfaXNfY29tcGF0aWJsZShw cml2LCBWUFVfQ09NUEFUSUJMRV9HMTJBKSkKPiA+Pj4+ICsJCXJldHVybiBmYWxzZTsKPiA+Pj4+ ICsKPiA+Pj4+ICsJaWYgKG1vZGlmaWVyICYgfkRSTV9GT1JNQVRfTU9EX0FSTV9BRkJDKE1FU09O X01PRF9BRkJDX1ZBTElEX0JJVFMpKQo+ID4+Pj4gKwkJcmV0dXJuIGZhbHNlOwo+ID4+Pj4gKwo+ ID4+Pj4gKwlmb3IgKGkgPSAwIDsgaSA8IHBsYW5lLT5tb2RpZmllcl9jb3VudCA7ICsraSkKPiA+ Pj4+ICsJCWlmIChwbGFuZS0+bW9kaWZpZXJzW2ldID09IG1vZGlmaWVyKQo+ID4+Pj4gKwkJCWJy ZWFrOwo+ID4+Pj4gKwo+ID4+Pj4gKwlpZiAoaSA9PSBwbGFuZS0+bW9kaWZpZXJfY291bnQpIHsK PiA+Pj4+ICsJCURSTV9ERUJVR19LTVMoIlVuc3VwcG9ydGVkIG1vZGlmaWVyXG4iKTsKPiA+Pj4+ ICsJCXJldHVybiBmYWxzZTsKPiA+Pj4+ICsJfQo+ID4+Cj4gPj4gSSBjYW4gYWRkIGEgd2Fybl9v bmNlIGhlcmUsIHdvdWxkIGl0IGJlIGVub3VnaCA/Cj4gPj4KPiA+Pj4+ICsKPiA+Pj4+ICsJaWYg KHByaXYtPmFmYmNkLm9wcyAmJiBwcml2LT5hZmJjZC5vcHMtPnN1cHBvcnRlZF9mbXQpCj4gPj4+ PiArCQlyZXR1cm4gcHJpdi0+YWZiY2Qub3BzLT5zdXBwb3J0ZWRfZm10KG1vZGlmaWVyLCBmb3Jt YXQpOwo+ID4+Pj4gKwo+ID4+Pj4gKwlEUk1fREVCVUdfS01TKCJBRkJDIFVuc3VwcG9ydGVkXG4i KTsKPiA+Pj4+ICsJcmV0dXJuIGZhbHNlOwo+ID4+Pj4gK30KPiA+Pj4+ICsKPiA+Pj4+ICBzdGF0 aWMgY29uc3Qgc3RydWN0IGRybV9wbGFuZV9mdW5jcyBtZXNvbl9wbGFuZV9mdW5jcyA9IHsKPiA+ Pj4+ICAJLnVwZGF0ZV9wbGFuZQkJPSBkcm1fYXRvbWljX2hlbHBlcl91cGRhdGVfcGxhbmUsCj4g Pj4+PiAgCS5kaXNhYmxlX3BsYW5lCQk9IGRybV9hdG9taWNfaGVscGVyX2Rpc2FibGVfcGxhbmUs Cj4gPj4+PiBAQCAtMzUzLDYgKzQ1Nyw3IEBAIHN0YXRpYyBjb25zdCBzdHJ1Y3QgZHJtX3BsYW5l X2Z1bmNzIG1lc29uX3BsYW5lX2Z1bmNzID0gewo+ID4+Pj4gIAkucmVzZXQJCQk9IGRybV9hdG9t aWNfaGVscGVyX3BsYW5lX3Jlc2V0LAo+ID4+Pj4gIAkuYXRvbWljX2R1cGxpY2F0ZV9zdGF0ZSA9 IGRybV9hdG9taWNfaGVscGVyX3BsYW5lX2R1cGxpY2F0ZV9zdGF0ZSwKPiA+Pj4+ICAJLmF0b21p Y19kZXN0cm95X3N0YXRlCT0gZHJtX2F0b21pY19oZWxwZXJfcGxhbmVfZGVzdHJveV9zdGF0ZSwK PiA+Pj4+ICsJLmZvcm1hdF9tb2Rfc3VwcG9ydGVkICAgPSBtZXNvbl9wbGFuZV9mb3JtYXRfbW9k X3N1cHBvcnRlZCwKPiA+Pj4+ICB9Owo+ID4+Pj4gIAo+ID4+Pj4gIHN0YXRpYyBjb25zdCB1aW50 MzJfdCBzdXBwb3J0ZWRfZHJtX2Zvcm1hdHNbXSA9IHsKPiA+Pj4+IEBAIC0zNjQsMTAgKzQ2OSw1 MyBAQCBzdGF0aWMgY29uc3QgdWludDMyX3Qgc3VwcG9ydGVkX2RybV9mb3JtYXRzW10gPSB7Cj4g Pj4+PiAgCURSTV9GT1JNQVRfUkdCNTY1LAo+ID4+Pj4gIH07Cj4gPj4+PiAgCj4gPj4+PiArc3Rh dGljIGNvbnN0IHVpbnQ2NF90IGZvcm1hdF9tb2RpZmllcnNfYWZiY19neG1bXSA9IHsKPiA+Pj4+ ICsJRFJNX0ZPUk1BVF9NT0RfQVJNX0FGQkMoQUZCQ19GT1JNQVRfTU9EX0JMT0NLX1NJWkVfMTZ4 MTYgfAo+ID4+Pj4gKwkJCQlBRkJDX0ZPUk1BVF9NT0RfU1BBUlNFIHwKPiA+Pj4+ICsJCQkJQUZC Q19GT1JNQVRfTU9EX1lUUiksCj4gPj4+PiArCS8qIFNQTElUIG1hbmRhdGVzIFNQQVJTRSwgUkdC IG1vZGVzIG1hbmRhdGVzIFlUUiAqLwo+ID4+Pj4gKwlEUk1fRk9STUFUX01PRF9BUk1fQUZCQyhB RkJDX0ZPUk1BVF9NT0RfQkxPQ0tfU0laRV8xNngxNiB8Cj4gPj4+PiArCQkJCUFGQkNfRk9STUFU X01PRF9ZVFIgfAo+ID4+Pj4gKwkJCQlBRkJDX0ZPUk1BVF9NT0RfU1BBUlNFIHwKPiA+Pj4+ICsJ CQkJQUZCQ19GT1JNQVRfTU9EX1NQTElUKSwKPiA+Pj4+ICsJRFJNX0ZPUk1BVF9NT0RfTElORUFS LAo+ID4+Pj4gKwlEUk1fRk9STUFUX01PRF9JTlZBTElELAo+ID4+Pj4gK307Cj4gPj4+PiArCj4g Pj4+PiArc3RhdGljIGNvbnN0IHVpbnQ2NF90IGZvcm1hdF9tb2RpZmllcnNfYWZiY19nMTJhW10g PSB7Cj4gPj4+PiArCS8qCj4gPj4+PiArCSAqIC0gVE9GSVggU3VwcG9ydCBBRkJDIG1vZGlmaWVy cyBmb3IgWVVWIGZvcm1hdHMgKDE2eDE2ICsgVElMRUQpCj4gPj4+PiArCSAqIC0gQUZCQ19GT1JN QVRfTU9EX1lUUiBpcyBtYW5kYXRvcnkgc2luY2Ugd2Ugb25seSBzdXBwb3J0IFJHQgo+ID4+Pj4g KwkgKiAtIFNQTElUIGlzIG1hbmRhdG9yeSBmb3IgcGVyZm9ybWFuY2VzIHJlYXNvbnMgd2hlbiBp biAxNngxNgo+ID4+Pj4gKwkgKiAgIGJsb2NrIHNpemUKPiA+Pj4+ICsJICogLSAzMng4IGJsb2Nr IHNpemUgKyBTUExJVCBpcyBtYW5kYXRvcnkgd2l0aCA0SyBmcmFtZSBzaXplCj4gPj4+PiArCSAq ICAgZm9yIHBlcmZvcm1hbmNlcyByZWFzb25zCj4gPj4+PiArCSAqLwo+ID4+Pj4gKwlEUk1fRk9S TUFUX01PRF9BUk1fQUZCQyhBRkJDX0ZPUk1BVF9NT0RfQkxPQ0tfU0laRV8xNngxNiB8Cj4gPj4+ PiArCQkJCUFGQkNfRk9STUFUX01PRF9ZVFIgfAo+ID4+Pj4gKwkJCQlBRkJDX0ZPUk1BVF9NT0Rf U1BBUlNFIHwKPiA+Pj4+ICsJCQkJQUZCQ19GT1JNQVRfTU9EX1NQTElUKSwKPiA+Pj4+ICsJRFJN X0ZPUk1BVF9NT0RfQVJNX0FGQkMoQUZCQ19GT1JNQVRfTU9EX0JMT0NLX1NJWkVfMzJ4OCB8Cj4g Pj4+PiArCQkJCUFGQkNfRk9STUFUX01PRF9ZVFIgfAo+ID4+Pj4gKwkJCQlBRkJDX0ZPUk1BVF9N T0RfU1BBUlNFKSwKPiA+Pj4+ICsJRFJNX0ZPUk1BVF9NT0RfQVJNX0FGQkMoQUZCQ19GT1JNQVRf TU9EX0JMT0NLX1NJWkVfMzJ4OCB8Cj4gPj4+PiArCQkJCUFGQkNfRk9STUFUX01PRF9ZVFIgfAo+ ID4+Pj4gKwkJCQlBRkJDX0ZPUk1BVF9NT0RfU1BBUlNFIHwKPiA+Pj4+ICsJCQkJQUZCQ19GT1JN QVRfTU9EX1NQTElUKSwKPiA+Pj4+ICsJRFJNX0ZPUk1BVF9NT0RfTElORUFSLAo+ID4+Pj4gKwlE Uk1fRk9STUFUX01PRF9JTlZBTElELAo+ID4+Pj4gK307Cj4gPj4+PiArCj4gPj4+PiArc3RhdGlj IGNvbnN0IHVpbnQ2NF90IGZvcm1hdF9tb2RpZmllcnNfZGVmYXVsdFtdID0gewo+ID4+Pj4gKwlE Uk1fRk9STUFUX01PRF9MSU5FQVIsCj4gPj4+PiArCURSTV9GT1JNQVRfTU9EX0lOVkFMSUQsCj4g Pj4+PiArfTsKPiA+Pj4+ICsKPiA+Pj4+ICBpbnQgbWVzb25fcGxhbmVfY3JlYXRlKHN0cnVjdCBt ZXNvbl9kcm0gKnByaXYpCj4gPj4+PiAgewo+ID4+Pj4gIAlzdHJ1Y3QgbWVzb25fcGxhbmUgKm1l c29uX3BsYW5lOwo+ID4+Pj4gIAlzdHJ1Y3QgZHJtX3BsYW5lICpwbGFuZTsKPiA+Pj4+ICsJY29u c3QgdWludDY0X3QgKmZvcm1hdF9tb2RpZmllcnMgPSBmb3JtYXRfbW9kaWZpZXJzX2RlZmF1bHQ7 Cj4gPj4+PiAgCj4gPj4+PiAgCW1lc29uX3BsYW5lID0gZGV2bV9remFsbG9jKHByaXYtPmRybS0+ ZGV2LCBzaXplb2YoKm1lc29uX3BsYW5lKSwKPiA+Pj4+ICAJCQkJICAgR0ZQX0tFUk5FTCk7Cj4g Pj4+PiBAQCAtMzc3LDExICs1MjUsMTYgQEAgaW50IG1lc29uX3BsYW5lX2NyZWF0ZShzdHJ1Y3Qg bWVzb25fZHJtICpwcml2KQo+ID4+Pj4gIAltZXNvbl9wbGFuZS0+cHJpdiA9IHByaXY7Cj4gPj4+ PiAgCXBsYW5lID0gJm1lc29uX3BsYW5lLT5iYXNlOwo+ID4+Pj4gIAo+ID4+Pj4gKwlpZiAobWVz b25fdnB1X2lzX2NvbXBhdGlibGUocHJpdiwgVlBVX0NPTVBBVElCTEVfR1hNKSkKPiA+Pj4+ICsJ CWZvcm1hdF9tb2RpZmllcnMgPSBmb3JtYXRfbW9kaWZpZXJzX2FmYmNfZ3htOwo+ID4+Pj4gKwll bHNlIGlmIChtZXNvbl92cHVfaXNfY29tcGF0aWJsZShwcml2LCBWUFVfQ09NUEFUSUJMRV9HMTJB KSkKPiA+Pj4+ICsJCWZvcm1hdF9tb2RpZmllcnMgPSBmb3JtYXRfbW9kaWZpZXJzX2FmYmNfZzEy YTsKPiA+Pj4+ICsKPiA+Pj4+ICAJZHJtX3VuaXZlcnNhbF9wbGFuZV9pbml0KHByaXYtPmRybSwg cGxhbmUsIDB4RkYsCj4gPj4+PiAgCQkJCSAmbWVzb25fcGxhbmVfZnVuY3MsCj4gPj4+PiAgCQkJ CSBzdXBwb3J0ZWRfZHJtX2Zvcm1hdHMsCj4gPj4+PiAgCQkJCSBBUlJBWV9TSVpFKHN1cHBvcnRl ZF9kcm1fZm9ybWF0cyksCj4gPj4+PiAtCQkJCSBOVUxMLAo+ID4+Pj4gKwkJCQkgZm9ybWF0X21v ZGlmaWVycywKPiA+Pj4+ICAJCQkJIERSTV9QTEFORV9UWVBFX1BSSU1BUlksICJtZXNvbl9wcmlt YXJ5X3BsYW5lIik7Cj4gPj4+PiAgCj4gPj4+PiAgCWRybV9wbGFuZV9oZWxwZXJfYWRkKHBsYW5l LCAmbWVzb25fcGxhbmVfaGVscGVyX2Z1bmNzKTsKPiA+Pj4+IC0tIAo+ID4+Pj4gMi4yMi4wCj4g Pj4KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ ID4+IGRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKPiA+PiBkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0 b3Aub3JnCj4gPj4gaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5m by9kcmktZGV2ZWwKPiAKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Au b3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRl dmVs 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,URIBL_BLOCKED,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 F1C2FECE58C for ; Fri, 11 Oct 2019 10:56:41 +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 BC1632084C for ; Fri, 11 Oct 2019 10:56:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="G1picBLZ"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=armh.onmicrosoft.com header.i=@armh.onmicrosoft.com header.b="dfCRgbIA"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=armh.onmicrosoft.com header.i=@armh.onmicrosoft.com header.b="dfCRgbIA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC1632084C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.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:MIME-Version:Content-ID:In-Reply-To: References:Message-ID:Date:Subject:To:From:Reply-To:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tfTuKgUPgop666tF/qtkhwI1KIVYW/bAtW6/TGQkC+c=; b=G1picBLZeOybTN dSNAESe8mIEqlA71fx1rmmevgHRQr+fXE5be/AjoMxXABmX2wTfbi0Q3cJtXJCwu7Eo0g4xH9NXu9 AvKZe5pAg36YLbYhwT61Mr5vW/B2ShBKoVbHY+nto1RM7YU8owIcTM507tQr+HOLD2CyDnanlbe7d RiwWnBTsur2Z2bfYPKqWh5+ojkqE46g0DdrVTFl5xgF/DW1I89nL3Dzo2Vbwvc1lYyU8nQH4QeG9/ AHAcl106nxgjKtVLiL5bbK5Q3TLBDaKwpGzjE7ve5dl2/AOgSxHcYNehhCgRQyDHut7Bw5sDle9L4 0y1B+teEqAswPMNEMZ5w==; 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 1iIsb2-0004fm-DW; Fri, 11 Oct 2019 10:56:32 +0000 Received: from mail-eopbgr80074.outbound.protection.outlook.com ([40.107.8.74] helo=EUR04-VI1-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iIsan-0004Ux-3k; Fri, 11 Oct 2019 10:56:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yoXMqgkrVOlA9w3mwWbFLbUt4qFRzx5cc74EwqZiVtY=; b=dfCRgbIAV1zlJn+vUpOnPUVJEGyckcwqYVkyVZDcJnAxMwXCnnnkRJiWPjsEas0hWsdY7ZaJH4Ub2QBMUIpWA3fYWKe5t8ivCrACOl9O0+u/upJihO/7bPQj4ycpZAqzPdKlaW4WvVhmFoLXmeEs82TVpMi9acKB1+k10ZJJHpw= Received: from DB6PR0801CA0061.eurprd08.prod.outlook.com (2603:10a6:4:2b::29) by AM0PR08MB5009.eurprd08.prod.outlook.com (2603:10a6:208:160::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.21; Fri, 11 Oct 2019 10:56:12 +0000 Received: from DB5EUR03FT023.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e0a::206) by DB6PR0801CA0061.outlook.office365.com (2603:10a6:4:2b::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2347.16 via Frontend Transport; Fri, 11 Oct 2019 10:56:12 +0000 Authentication-Results: spf=temperror (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.infradead.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.infradead.org; dmarc=none action=none header.from=arm.com; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of arm.com: DNS Timeout) Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT023.mail.protection.outlook.com (10.152.20.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.15 via Frontend Transport; Fri, 11 Oct 2019 10:56:11 +0000 Received: ("Tessian outbound 0cf06bf5c60e:v33"); Fri, 11 Oct 2019 10:56:10 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 8a007ee49b10e978 X-CR-MTA-TID: 64aa7808 Received: from aa32cf6c135b.1 (ip-172-16-0-2.eu-west-1.compute.internal [104.47.4.57]) by 64aa7808-outbound-1.mta.getcheckrecipient.com id 48BECC57-E34D-4728-9C65-D5FF2659F6BC.1; Fri, 11 Oct 2019 10:56:05 +0000 Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02lp2057.outbound.protection.outlook.com [104.47.4.57]) by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id aa32cf6c135b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 11 Oct 2019 10:56:05 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EC/xLyzYCYbd6RIPi3kQpezBvJR4c6MCUsTREh31AfifkPl83vvNbaoniCvwhrhkBrcJpWjSu0/UNo1bQlOouDDlMrrh8EbUhQuxOKZ7NaNsPQtLWIv2stqrFVtAtvF0VFfl/mC2ka3mJc/DT7uBnLJEavwx4dLCWlp6/jOE6brai0dHOqQspIHgQLxCF4ZMYjWLv8/+qrlEYnBR5UNeSjmcj2FdU6E4YALDv4fEaQ6J+w4Ub0SGFCCgt8mrW9/Ftg8hFSbFi1pfKwx0y+iLwp8N4HjSRtXppVZY8ZQa+37hXthrwE0Lcpq/9n8Zg1wh2avs+Xg32szhC9fmU/21SQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yoXMqgkrVOlA9w3mwWbFLbUt4qFRzx5cc74EwqZiVtY=; b=hr7iN4l7nRdqG8XhvisBD/c3JclEECHdpUKtrB16ttqwlAPE7g6TrqfXVoPELp+sgq4o4G9c+jLpPAR7kuL4Wsvdued1r4zKPfc7+2mcUPFlo4B0kHgZnJvBGkJ39eKhyFRqboJ1Z0Y/rPDnIAW2DjAdytzRhuMWobGCoUxrORCp5KQhMQpJ0L9y2pFrnD+9i+UhabMWqlAp31sX6/cL4W17gSK4J5K7cwIwhHDZQ7ip7/J/Nnl8T5Yx7fiCEwv9ktfEFnlaJxU867L5b3Ygezpg4pa+WHVpCTl3v39kVTc8+jLMsY41zyc/Hriz9D9pG28TLAsM3MmK7PYcM/Ivyw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yoXMqgkrVOlA9w3mwWbFLbUt4qFRzx5cc74EwqZiVtY=; b=dfCRgbIAV1zlJn+vUpOnPUVJEGyckcwqYVkyVZDcJnAxMwXCnnnkRJiWPjsEas0hWsdY7ZaJH4Ub2QBMUIpWA3fYWKe5t8ivCrACOl9O0+u/upJihO/7bPQj4ycpZAqzPdKlaW4WvVhmFoLXmeEs82TVpMi9acKB1+k10ZJJHpw= Received: from AM6PR08MB3829.eurprd08.prod.outlook.com (20.178.89.14) by AM6PR08MB4820.eurprd08.prod.outlook.com (10.255.99.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.19; Fri, 11 Oct 2019 10:56:00 +0000 Received: from AM6PR08MB3829.eurprd08.prod.outlook.com ([fe80::ce0:f47b:919d:561a]) by AM6PR08MB3829.eurprd08.prod.outlook.com ([fe80::ce0:f47b:919d:561a%5]) with mapi id 15.20.2347.021; Fri, 11 Oct 2019 10:56:00 +0000 From: Brian Starkey To: Neil Armstrong Subject: Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane Thread-Topic: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane Thread-Index: AQHVgA+hW0YpyPd1Sk22upjR9Lo04KdVKIOAgAAcS4A= Date: Fri, 11 Oct 2019 10:56:00 +0000 Message-ID: <20191011105559.clttghy52wfdmb34@DESKTOP-E1NTVVP.localdomain> 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> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: NeoMutt/20180716-849-147d51-dirty x-originating-ip: [217.140.106.54] x-clientproxiedby: LO2P265CA0120.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::36) To AM6PR08MB3829.eurprd08.prod.outlook.com (2603:10a6:20b:85::14) Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Brian.Starkey@arm.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 0c4f4911-f4a2-46d3-ef2e-08d74e39a11b X-MS-Office365-Filtering-HT: Tenant X-MS-TrafficTypeDiagnostic: AM6PR08MB4820:|AM6PR08MB4820:|AM0PR08MB5009: X-MS-Exchange-PUrlCount: 4 x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 0187F3EA14 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(346002)(376002)(366004)(39860400002)(199004)(189003)(51914003)(52314003)(305945005)(71190400001)(71200400001)(478600001)(58126008)(7736002)(6116002)(8676002)(54906003)(3846002)(6246003)(2906002)(966005)(316002)(25786009)(6916009)(26005)(30864003)(64756008)(66446008)(1076003)(186003)(66946007)(66476007)(66556008)(6436002)(86362001)(5660300002)(52116002)(102836004)(6506007)(53546011)(6512007)(386003)(11346002)(8936002)(44832011)(6306002)(446003)(4326008)(66066001)(76176011)(9686003)(6486002)(476003)(486006)(99286004)(256004)(14444005)(14454004)(81156014)(81166006)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4820; H:AM6PR08MB3829.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: JIaJWUJWP0WG1PK/HOcJ3+PKQFY0r4CxGS1H1v5xai6h+tV6m35HwE6oMaNZGIq3KTlCJY6/SCEuUydy2Z6S6PjW/zIZvDEo8Vj8OZ73FW9zk6U95ioz53+G5VyR9H8yKEkfaMouS0dxv9X0T/JZQSrpQng9J4qblHcVhE8IribIjVwUvEsUDoB5Is65YVkg6lkboIDRXTZQj4d0IW6E5X/p75MM6bPxPP7hD1O0uO0HwAGLQGCd3u9PqiXNtnZGDXdcpNZJe1Nq8wVnuCSdzyin7tcZfTfaDWZTYSGYqfghW7Hs9ruvLYwycLN3mZuMIx7INhKDrYoaKIU8WyNbcR73W8tgJEELX1oaSO4ZRQDnRVxzBGF6axxPjW8gof1BPGmLpE6iOGMMynXSrVSmpLzlVkJ9IhHiuhsUYFg2pWLua34tPyu9/bqGFBJWkNDhvpgLvYbD5wIw25jYRNZL6Q== Content-ID: MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4820 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Brian.Starkey@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT023.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(346002)(376002)(39860400002)(199004)(189003)(51914003)(52314003)(76130400001)(6116002)(3846002)(46406003)(54906003)(229853002)(70206006)(6486002)(6862004)(4326008)(99286004)(9686003)(6512007)(6306002)(70586007)(58126008)(23726003)(316002)(22756006)(86362001)(6246003)(25786009)(7736002)(305945005)(30864003)(50466002)(1076003)(5660300002)(47776003)(66066001)(81166006)(81156014)(8676002)(8746002)(8936002)(450100002)(356004)(14444005)(186003)(14454004)(966005)(6506007)(126002)(53546011)(478600001)(76176011)(97756001)(386003)(102836004)(446003)(486006)(2906002)(11346002)(336012)(26005)(63350400001)(26826003)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB5009; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:TempError; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: 8f9169d1-aa18-41dc-0cb6-08d74e399a06 NoDisclaimer: True X-Forefront-PRVS: 0187F3EA14 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: v95fesv4TffCX+IrOLWOkQDc1SkKA9nCaaelIFPuwhhwZmH4ZHYlXXe6niVMGLtTseqfdNXsuh97yZ+/pwQbrGJX/Vht/v3T9Cz1Blx5pEMAY0+QYXn+Vaf8GPtYl0uDGns5wt2bHMQ16M7qbBbQxurX267XVuC7vWq7pdTJanEfjo6LIb5/DQGUdrhS4dDtPnsmVib+8ocRPZxE8FNY0sdTR86HyVCpdwMI3ugdPyepodj7PvBK3yl6B1+lCUdindmaCDUWNHimrSQNsdlUZQUXlh9lLJfbCUTs3Sw5XB5NLDxwD/07KU0h/sa+nXq8jRQ35DCCK/9Gx9LezPWKWSq8sUhmAUgp2K8HhIZvTWFHzkbp8DjjI3zmJQhUxrgl1yxX4AvISU6V6q4x8qiLwDBiBRKJrp1SY+wQg3iwUq8XaVsEMrP6OXBlnIHZkEWZPZrNEjymhEJX39NUi4CBEg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2019 10:56:11.8478 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0c4f4911-f4a2-46d3-ef2e-08d74e39a11b X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5009 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191011_035617_318268_10D1CFCC X-CRM114-Status: GOOD ( 18.09 ) 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 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. > > > > 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. > 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? 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. > 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. > > > >> 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. 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