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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 585FBC4360C for ; Thu, 26 Sep 2019 11:21:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3673F222C4 for ; Thu, 26 Sep 2019 11:21:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725912AbfIZLUz (ORCPT ); Thu, 26 Sep 2019 07:20:55 -0400 Received: from foss.arm.com ([217.140.110.172]:46496 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725536AbfIZLUy (ORCPT ); Thu, 26 Sep 2019 07:20:54 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9053B142F; Thu, 26 Sep 2019 04:20:53 -0700 (PDT) Received: from [192.168.1.124] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A8D1D3F67D; Thu, 26 Sep 2019 04:20:50 -0700 (PDT) Subject: Re: [PATCH 00/11] of: Fix DMA configuration for non-DT masters To: Nicolas Saenz Julienne , Rob Herring Cc: "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , devicetree@vger.kernel.org, Matthias Brugger , Frank Rowand , linux-arm-msm , linux-wireless , "linux-kernel@vger.kernel.org" , dri-devel , etnaviv@lists.freedesktop.org, "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" , Florian Fainelli , Stefan Wahren , james.quinlan@broadcom.com, linux-pci@vger.kernel.org, linux-tegra@vger.kernel.org, xen-devel@lists.xenproject.org, Dan Williams , freedreno , Linux Media Mailing List References: <20190924181244.7159-1-nsaenzjulienne@suse.de> <43fb5fe1de317d65a4edf592f88ea150c6e3b8cc.camel@suse.de> <307b988d0c67fb1c42166eca12742bcfda09d92d.camel@suse.de> From: Robin Murphy Message-ID: Date: Thu, 26 Sep 2019 12:20:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <307b988d0c67fb1c42166eca12742bcfda09d92d.camel@suse.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org On 2019-09-26 11:44 am, Nicolas Saenz Julienne wrote: >>>>> Robin, have you looked into supporting multiple dma-ranges? It's the >>>>> next thing >>>>> we need for BCM STB's PCIe. I'll have a go at it myself if nothing is in >>>>> the >>>>> works already. >>>> >>>> Multiple dma-ranges as far as configuring inbound windows should work >>>> already other than the bug when there's any parent translation. But if >>>> you mean supporting multiple DMA offsets and masks per device in the >>>> DMA API, there's nothing in the works yet. > > Sorry, I meant supporting multiple DMA offsets[1]. I think I could still make > it with a single DMA mask though. The main problem for supporting that case in general is the disgusting carving up of the physical memory map you may have to do to guarantee that a single buffer allocation cannot ever span two windows with different offsets. I don't think we ever reached a conclusion on whether that was even achievable in practice. >>> There's also the in-between step of making of_dma_get_range() return a >>> size based on all the dma-ranges entries rather than only the first one >>> - otherwise, something like [1] can lead to pretty unworkable default >>> masks. We implemented that when doing acpi_dma_get_range(), it's just >>> that the OF counterpart never caught up. >> >> Right. I suppose we assume any holes in the ranges are addressable by >> the device but won't get used for other reasons (such as no memory >> there). However, to be correct, the range of the dma offset plus mask >> would need to be within the min start and max end addresses. IOW, >> while we need to round up (0xa_8000_0000 - 0x2c1c_0000) to the next >> power of 2, the 'correct' thing to do is round down. > > IIUC I also have this issue on my list. The RPi4 PCIe block has an integration > bug that only allows DMA to the lower 3GB. With dma-ranges of size 0xc000_0000 > you get a 32bit DMA mask wich is not what you need. So far I faked it in the > device-tree but I guess it be better to add an extra check in > of_dma_configure(), decrease the mask and print some kind of warning stating > that DMA addressing is suboptimal. Yeah, there's just no way for masks to describe that the device can drive all the individual bits, just not in certain combinations :( The plan I have sketched out there is to merge dma_pfn_offset and bus_dma_mask into a "DMA range" descriptor, so we can then hang one or more of those off a device to properly cope with all these weird interconnects. Conceptually it feels pretty straightforward; I think most of the challenge is in implementing it efficiently. Plus there's the question of whether it could also subsume the dma_mask as well. Robin. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robin Murphy Subject: Re: [PATCH 00/11] of: Fix DMA configuration for non-DT masters Date: Thu, 26 Sep 2019 12:20:44 +0100 Message-ID: References: <20190924181244.7159-1-nsaenzjulienne@suse.de> <43fb5fe1de317d65a4edf592f88ea150c6e3b8cc.camel@suse.de> <307b988d0c67fb1c42166eca12742bcfda09d92d.camel@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <307b988d0c67fb1c42166eca12742bcfda09d92d.camel@suse.de> Content-Language: en-GB Sender: linux-kernel-owner@vger.kernel.org To: Nicolas Saenz Julienne , Rob Herring Cc: "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , devicetree@vger.kernel.org, Matthias Brugger , Frank Rowand , linux-arm-msm , linux-wireless , "linux-kernel@vger.kernel.org" , dri-devel , etnaviv@lists.freedesktop.org, "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" , Florian Fainelli , Stefan Wahren , james.quinlan@broadcom.com, linux-pci@vger.kernel.org, linux-tegra@vger.kernel.org, xen-devel@lists.xenproject.org, Dan Williams , freedreno List-Id: linux-tegra@vger.kernel.org On 2019-09-26 11:44 am, Nicolas Saenz Julienne wrote: >>>>> Robin, have you looked into supporting multiple dma-ranges? It's the >>>>> next thing >>>>> we need for BCM STB's PCIe. I'll have a go at it myself if nothing is in >>>>> the >>>>> works already. >>>> >>>> Multiple dma-ranges as far as configuring inbound windows should work >>>> already other than the bug when there's any parent translation. But if >>>> you mean supporting multiple DMA offsets and masks per device in the >>>> DMA API, there's nothing in the works yet. > > Sorry, I meant supporting multiple DMA offsets[1]. I think I could still make > it with a single DMA mask though. The main problem for supporting that case in general is the disgusting carving up of the physical memory map you may have to do to guarantee that a single buffer allocation cannot ever span two windows with different offsets. I don't think we ever reached a conclusion on whether that was even achievable in practice. >>> There's also the in-between step of making of_dma_get_range() return a >>> size based on all the dma-ranges entries rather than only the first one >>> - otherwise, something like [1] can lead to pretty unworkable default >>> masks. We implemented that when doing acpi_dma_get_range(), it's just >>> that the OF counterpart never caught up. >> >> Right. I suppose we assume any holes in the ranges are addressable by >> the device but won't get used for other reasons (such as no memory >> there). However, to be correct, the range of the dma offset plus mask >> would need to be within the min start and max end addresses. IOW, >> while we need to round up (0xa_8000_0000 - 0x2c1c_0000) to the next >> power of 2, the 'correct' thing to do is round down. > > IIUC I also have this issue on my list. The RPi4 PCIe block has an integration > bug that only allows DMA to the lower 3GB. With dma-ranges of size 0xc000_0000 > you get a 32bit DMA mask wich is not what you need. So far I faked it in the > device-tree but I guess it be better to add an extra check in > of_dma_configure(), decrease the mask and print some kind of warning stating > that DMA addressing is suboptimal. Yeah, there's just no way for masks to describe that the device can drive all the individual bits, just not in certain combinations :( The plan I have sketched out there is to merge dma_pfn_offset and bus_dma_mask into a "DMA range" descriptor, so we can then hang one or more of those off a device to properly cope with all these weird interconnects. Conceptually it feels pretty straightforward; I think most of the challenge is in implementing it efficiently. Plus there's the question of whether it could also subsume the dma_mask as well. Robin. 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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 1FB19C432C2 for ; Thu, 26 Sep 2019 11:21:08 +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 E6D4A21A4A for ; Thu, 26 Sep 2019 11:21:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="F8GfhZf9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E6D4A21A4A 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-Type: Content-Transfer-Encoding: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=GlGeXN8gHfg1Ozk6sjanLga50kqBZIQmO+lPvkiQSaQ=; b=F8GfhZf97RK704NOmIqhMzKjg pGqZjqz7CiVV6gyYYRwhsMs6cu2x87JD1BIxXytCr5KZBHQl8mFkwWhqRZDxnvmFp1zZ+XvYGmiR4 F6+0Tv11M0+YHdxKlYtPPch+CZrQpbnFV1BY1hTg4zMODXOouHxz5FLgY9tEHWRT9m2D3Ld1kIy2W 7SRh8uDHpW/oz3HSPm3vFACTzqZwEYJueq34FWQ+xm4Iq/Ru1V1Chpa++xqOQjLWNYqcI4LrK+eq0 W7aaHwELnjiiYKHrtTgmhHWD3yUvtF1kauMYelXz56KkmACd1ZtUQpjZwv7Ec6VkdBiCKg1543ybE iv7Laxm0A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.2 #3 (Red Hat Linux)) id 1iDRpS-0006KA-Sr; Thu, 26 Sep 2019 11:20:58 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.2 #3 (Red Hat Linux)) id 1iDRpP-0006Il-VX for linux-arm-kernel@lists.infradead.org; Thu, 26 Sep 2019 11:20:57 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9053B142F; Thu, 26 Sep 2019 04:20:53 -0700 (PDT) Received: from [192.168.1.124] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A8D1D3F67D; Thu, 26 Sep 2019 04:20:50 -0700 (PDT) Subject: Re: [PATCH 00/11] of: Fix DMA configuration for non-DT masters To: Nicolas Saenz Julienne , Rob Herring References: <20190924181244.7159-1-nsaenzjulienne@suse.de> <43fb5fe1de317d65a4edf592f88ea150c6e3b8cc.camel@suse.de> <307b988d0c67fb1c42166eca12742bcfda09d92d.camel@suse.de> From: Robin Murphy Message-ID: Date: Thu, 26 Sep 2019 12:20:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <307b988d0c67fb1c42166eca12742bcfda09d92d.camel@suse.de> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190926_042056_098779_2044ADF4 X-CRM114-Status: GOOD ( 20.96 ) 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: devicetree@vger.kernel.org, Matthias Brugger , linux-arm-msm , linux-wireless , "linux-kernel@vger.kernel.org" , dri-devel , etnaviv@lists.freedesktop.org, linux-tegra@vger.kernel.org, Florian Fainelli , Stefan Wahren , james.quinlan@broadcom.com, linux-pci@vger.kernel.org, "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" , xen-devel@lists.xenproject.org, Dan Williams , freedreno , Frank Rowand , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Linux Media Mailing List Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2019-09-26 11:44 am, Nicolas Saenz Julienne wrote: >>>>> Robin, have you looked into supporting multiple dma-ranges? It's the >>>>> next thing >>>>> we need for BCM STB's PCIe. I'll have a go at it myself if nothing is in >>>>> the >>>>> works already. >>>> >>>> Multiple dma-ranges as far as configuring inbound windows should work >>>> already other than the bug when there's any parent translation. But if >>>> you mean supporting multiple DMA offsets and masks per device in the >>>> DMA API, there's nothing in the works yet. > > Sorry, I meant supporting multiple DMA offsets[1]. I think I could still make > it with a single DMA mask though. The main problem for supporting that case in general is the disgusting carving up of the physical memory map you may have to do to guarantee that a single buffer allocation cannot ever span two windows with different offsets. I don't think we ever reached a conclusion on whether that was even achievable in practice. >>> There's also the in-between step of making of_dma_get_range() return a >>> size based on all the dma-ranges entries rather than only the first one >>> - otherwise, something like [1] can lead to pretty unworkable default >>> masks. We implemented that when doing acpi_dma_get_range(), it's just >>> that the OF counterpart never caught up. >> >> Right. I suppose we assume any holes in the ranges are addressable by >> the device but won't get used for other reasons (such as no memory >> there). However, to be correct, the range of the dma offset plus mask >> would need to be within the min start and max end addresses. IOW, >> while we need to round up (0xa_8000_0000 - 0x2c1c_0000) to the next >> power of 2, the 'correct' thing to do is round down. > > IIUC I also have this issue on my list. The RPi4 PCIe block has an integration > bug that only allows DMA to the lower 3GB. With dma-ranges of size 0xc000_0000 > you get a 32bit DMA mask wich is not what you need. So far I faked it in the > device-tree but I guess it be better to add an extra check in > of_dma_configure(), decrease the mask and print some kind of warning stating > that DMA addressing is suboptimal. Yeah, there's just no way for masks to describe that the device can drive all the individual bits, just not in certain combinations :( The plan I have sketched out there is to merge dma_pfn_offset and bus_dma_mask into a "DMA range" descriptor, so we can then hang one or more of those off a device to properly cope with all these weird interconnects. Conceptually it feels pretty straightforward; I think most of the challenge is in implementing it efficiently. Plus there's the question of whether it could also subsume the dma_mask as well. Robin. _______________________________________________ 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 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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 76467C47E48 for ; Thu, 26 Sep 2019 11:21:22 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (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 4F268217F4 for ; Thu, 26 Sep 2019 11:21:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4F268217F4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iDRpP-0008CL-QS; Thu, 26 Sep 2019 11:20:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iDRpP-0008CG-0u for xen-devel@lists.xenproject.org; Thu, 26 Sep 2019 11:20:55 +0000 X-Inumbo-ID: b3f85038-e04f-11e9-bf31-bc764e2007e4 Received: from foss.arm.com (unknown [217.140.110.172]) by localhost (Halon) with ESMTP id b3f85038-e04f-11e9-bf31-bc764e2007e4; Thu, 26 Sep 2019 11:20:53 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9053B142F; Thu, 26 Sep 2019 04:20:53 -0700 (PDT) Received: from [192.168.1.124] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A8D1D3F67D; Thu, 26 Sep 2019 04:20:50 -0700 (PDT) To: Nicolas Saenz Julienne , Rob Herring References: <20190924181244.7159-1-nsaenzjulienne@suse.de> <43fb5fe1de317d65a4edf592f88ea150c6e3b8cc.camel@suse.de> <307b988d0c67fb1c42166eca12742bcfda09d92d.camel@suse.de> From: Robin Murphy Message-ID: Date: Thu, 26 Sep 2019 12:20:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <307b988d0c67fb1c42166eca12742bcfda09d92d.camel@suse.de> Content-Language: en-GB Subject: Re: [Xen-devel] [PATCH 00/11] of: Fix DMA configuration for non-DT masters X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Matthias Brugger , linux-arm-msm , linux-wireless , "linux-kernel@vger.kernel.org" , dri-devel , etnaviv@lists.freedesktop.org, linux-tegra@vger.kernel.org, Florian Fainelli , Stefan Wahren , james.quinlan@broadcom.com, linux-pci@vger.kernel.org, "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" , xen-devel@lists.xenproject.org, Dan Williams , freedreno , Frank Rowand , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Linux Media Mailing List Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" T24gMjAxOS0wOS0yNiAxMTo0NCBhbSwgTmljb2xhcyBTYWVueiBKdWxpZW5uZSB3cm90ZToKPj4+ Pj4gUm9iaW4sIGhhdmUgeW91IGxvb2tlZCBpbnRvIHN1cHBvcnRpbmcgbXVsdGlwbGUgZG1hLXJh bmdlcz8gSXQncyB0aGUKPj4+Pj4gbmV4dCB0aGluZwo+Pj4+PiB3ZSBuZWVkIGZvciBCQ00gU1RC J3MgUENJZS4gSSdsbCBoYXZlIGEgZ28gYXQgaXQgbXlzZWxmIGlmIG5vdGhpbmcgaXMgaW4KPj4+ Pj4gdGhlCj4+Pj4+IHdvcmtzIGFscmVhZHkuCj4+Pj4KPj4+PiBNdWx0aXBsZSBkbWEtcmFuZ2Vz IGFzIGZhciBhcyBjb25maWd1cmluZyBpbmJvdW5kIHdpbmRvd3Mgc2hvdWxkIHdvcmsKPj4+PiBh bHJlYWR5IG90aGVyIHRoYW4gdGhlIGJ1ZyB3aGVuIHRoZXJlJ3MgYW55IHBhcmVudCB0cmFuc2xh dGlvbi4gQnV0IGlmCj4+Pj4geW91IG1lYW4gc3VwcG9ydGluZyBtdWx0aXBsZSBETUEgb2Zmc2V0 cyBhbmQgbWFza3MgcGVyIGRldmljZSBpbiB0aGUKPj4+PiBETUEgQVBJLCB0aGVyZSdzIG5vdGhp bmcgaW4gdGhlIHdvcmtzIHlldC4KPiAKPiBTb3JyeSwgSSBtZWFudCBzdXBwb3J0aW5nIG11bHRp cGxlIERNQSBvZmZzZXRzWzFdLiBJIHRoaW5rIEkgY291bGQgc3RpbGwgbWFrZQo+IGl0IHdpdGgg YSBzaW5nbGUgRE1BIG1hc2sgdGhvdWdoLgoKVGhlIG1haW4gcHJvYmxlbSBmb3Igc3VwcG9ydGlu ZyB0aGF0IGNhc2UgaW4gZ2VuZXJhbCBpcyB0aGUgZGlzZ3VzdGluZyAKY2FydmluZyB1cCBvZiB0 aGUgcGh5c2ljYWwgbWVtb3J5IG1hcCB5b3UgbWF5IGhhdmUgdG8gZG8gdG8gZ3VhcmFudGVlIAp0 aGF0IGEgc2luZ2xlIGJ1ZmZlciBhbGxvY2F0aW9uIGNhbm5vdCBldmVyIHNwYW4gdHdvIHdpbmRv d3Mgd2l0aCAKZGlmZmVyZW50IG9mZnNldHMuIEkgZG9uJ3QgdGhpbmsgd2UgZXZlciByZWFjaGVk IGEgY29uY2x1c2lvbiBvbiB3aGV0aGVyIAp0aGF0IHdhcyBldmVuIGFjaGlldmFibGUgaW4gcHJh Y3RpY2UuCgo+Pj4gVGhlcmUncyBhbHNvIHRoZSBpbi1iZXR3ZWVuIHN0ZXAgb2YgbWFraW5nIG9m X2RtYV9nZXRfcmFuZ2UoKSByZXR1cm4gYQo+Pj4gc2l6ZSBiYXNlZCBvbiBhbGwgdGhlIGRtYS1y YW5nZXMgZW50cmllcyByYXRoZXIgdGhhbiBvbmx5IHRoZSBmaXJzdCBvbmUKPj4+IC0gb3RoZXJ3 aXNlLCBzb21ldGhpbmcgbGlrZSBbMV0gY2FuIGxlYWQgdG8gcHJldHR5IHVud29ya2FibGUgZGVm YXVsdAo+Pj4gbWFza3MuIFdlIGltcGxlbWVudGVkIHRoYXQgd2hlbiBkb2luZyBhY3BpX2RtYV9n ZXRfcmFuZ2UoKSwgaXQncyBqdXN0Cj4+PiB0aGF0IHRoZSBPRiBjb3VudGVycGFydCBuZXZlciBj YXVnaHQgdXAuCj4+Cj4+IFJpZ2h0LiBJIHN1cHBvc2Ugd2UgYXNzdW1lIGFueSBob2xlcyBpbiB0 aGUgcmFuZ2VzIGFyZSBhZGRyZXNzYWJsZSBieQo+PiB0aGUgZGV2aWNlIGJ1dCB3b24ndCBnZXQg dXNlZCBmb3Igb3RoZXIgcmVhc29ucyAoc3VjaCBhcyBubyBtZW1vcnkKPj4gdGhlcmUpLiBIb3dl dmVyLCB0byBiZSBjb3JyZWN0LCB0aGUgcmFuZ2Ugb2YgdGhlIGRtYSBvZmZzZXQgcGx1cyBtYXNr Cj4+IHdvdWxkIG5lZWQgdG8gYmUgd2l0aGluIHRoZSBtaW4gc3RhcnQgYW5kIG1heCBlbmQgYWRk cmVzc2VzLiBJT1csCj4+IHdoaWxlIHdlIG5lZWQgdG8gcm91bmQgdXAgKDB4YV84MDAwXzAwMDAg LSAweDJjMWNfMDAwMCkgdG8gdGhlIG5leHQKPj4gcG93ZXIgb2YgMiwgdGhlICdjb3JyZWN0JyB0 aGluZyB0byBkbyBpcyByb3VuZCBkb3duLgo+IAo+IElJVUMgSSBhbHNvIGhhdmUgdGhpcyBpc3N1 ZSBvbiBteSBsaXN0LiBUaGUgUlBpNCBQQ0llIGJsb2NrIGhhcyBhbiBpbnRlZ3JhdGlvbgo+IGJ1 ZyB0aGF0IG9ubHkgYWxsb3dzIERNQSB0byB0aGUgbG93ZXIgM0dCLiBXaXRoIGRtYS1yYW5nZXMg b2Ygc2l6ZSAweGMwMDBfMDAwMAo+IHlvdSBnZXQgYSAzMmJpdCBETUEgbWFzayB3aWNoIGlzIG5v dCB3aGF0IHlvdSBuZWVkLiBTbyBmYXIgSSBmYWtlZCBpdCBpbiB0aGUKPiBkZXZpY2UtdHJlZSBi dXQgSSBndWVzcyBpdCBiZSBiZXR0ZXIgdG8gYWRkIGFuIGV4dHJhIGNoZWNrIGluCj4gb2ZfZG1h X2NvbmZpZ3VyZSgpLCBkZWNyZWFzZSB0aGUgbWFzayBhbmQgcHJpbnQgc29tZSBraW5kIG9mIHdh cm5pbmcgc3RhdGluZwo+IHRoYXQgRE1BIGFkZHJlc3NpbmcgaXMgc3Vib3B0aW1hbC4KClllYWgs IHRoZXJlJ3MganVzdCBubyB3YXkgZm9yIG1hc2tzIHRvIGRlc2NyaWJlIHRoYXQgdGhlIGRldmlj ZSBjYW4gCmRyaXZlIGFsbCB0aGUgaW5kaXZpZHVhbCBiaXRzLCBqdXN0IG5vdCBpbiBjZXJ0YWlu IGNvbWJpbmF0aW9ucyA6KAoKVGhlIHBsYW4gSSBoYXZlIHNrZXRjaGVkIG91dCB0aGVyZSBpcyB0 byBtZXJnZSBkbWFfcGZuX29mZnNldCBhbmQgCmJ1c19kbWFfbWFzayBpbnRvIGEgIkRNQSByYW5n ZSIgZGVzY3JpcHRvciwgc28gd2UgY2FuIHRoZW4gaGFuZyBvbmUgb3IgCm1vcmUgb2YgdGhvc2Ug b2ZmIGEgZGV2aWNlIHRvIHByb3Blcmx5IGNvcGUgd2l0aCBhbGwgdGhlc2Ugd2VpcmQgCmludGVy Y29ubmVjdHMuIENvbmNlcHR1YWxseSBpdCBmZWVscyBwcmV0dHkgc3RyYWlnaHRmb3J3YXJkOyBJ IHRoaW5rIAptb3N0IG9mIHRoZSBjaGFsbGVuZ2UgaXMgaW4gaW1wbGVtZW50aW5nIGl0IGVmZmlj aWVudGx5LiBQbHVzIHRoZXJlJ3MgCnRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIGl0IGNvdWxkIGFs c28gc3Vic3VtZSB0aGUgZG1hX21hc2sgYXMgd2VsbC4KClJvYmluLgoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cHM6Ly9saXN0cy54ZW5wcm9qZWN0Lm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3hlbi1kZXZlbA==