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=-5.2 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, 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 79F29C433E9 for ; Wed, 3 Feb 2021 11:19:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 40DE664F61 for ; Wed, 3 Feb 2021 11:19:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233957AbhBCLTt (ORCPT ); Wed, 3 Feb 2021 06:19:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233970AbhBCLTr (ORCPT ); Wed, 3 Feb 2021 06:19:47 -0500 Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E88F8C06174A for ; Wed, 3 Feb 2021 03:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Gl7sCApRFJtBXnfga0Dh5hI1R8/2+lI2ntQWVhdy+mk=; b=E27X9izTmzcQzga6jy2dEuNoJO 9MC7V9W+sA/8ivSdgpSXPWzoAhHveywclwtujxBF+BwIxQL3OO2RLE1ZOLGN4uZj+6PrvmKY41Cbf w7plO+Jp/n71PlrKVTOgF/vTzID9hU+8Zt5lFby27hAuF41U06A8ugWWusc+D5iI4PDI3pyN8CGUc 1wMWJ591IOM436tTXIc8rxg0zkK0iASMgcy85K5m0C91mN8diIBINrYrL7ZJQ6oim44JAaFyObAtj VTc8SLc4YvXdOBw39mQNMuGl+M1jCTRXrL/SYEhITBTXTRw8gS2ZX8plZchRcTAg1qsUtWfYgyN6z mkDdil6g==; Received: from dsl-hkibng22-54f986-236.dhcp.inet.fi ([84.249.134.236] helo=[192.168.1.10]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1l7GBU-0008Nz-CH; Wed, 03 Feb 2021 13:18:56 +0200 Subject: Re: [PATCH v5 00/21] Host1x sync point UAPI should not be used for tracking DRM jobs To: Dmitry Osipenko , Thierry Reding Cc: Mikko Perttunen , jonathanh@nvidia.com, airlied@linux.ie, daniel@ffwll.ch, linux-tegra@vger.kernel.org, dri-devel@lists.freedesktop.org, talho@nvidia.com, bhuntsman@nvidia.com References: <20210111130019.3515669-1-mperttunen@nvidia.com> <2f999b6d-d781-503a-78f4-d444bce72c58@kapsi.fi> <2ee12338-bd5a-4b99-f86d-13da0d2a899b@gmail.com> <8504c239-d5df-3033-934c-7b3fab52e387@kapsi.fi> <1ff922b2-161d-c8b9-7b08-4454ff7329f8@gmail.com> From: Mikko Perttunen Message-ID: <25248139-5487-a15b-8965-1a29a71eacd7@kapsi.fi> Date: Wed, 3 Feb 2021 13:18:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <1ff922b2-161d-c8b9-7b08-4454ff7329f8@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 84.249.134.236 X-SA-Exim-Mail-From: cyndis@kapsi.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org On 1/29/21 7:30 PM, Dmitry Osipenko wrote: > 28.01.2021 19:58, Thierry Reding пишет: >> On Thu, Jan 28, 2021 at 01:08:54PM +0200, Mikko Perttunen wrote: >>> On 1/27/21 11:20 PM, Dmitry Osipenko wrote: >>>> 26.01.2021 05:45, Mikko Perttunen пишет: >>>>>> 2. We will probably need a dedicated drm_tegra_submit_cmd for sync point >>>>>> increments.  The job's sync point will be allocated dynamically when job >>>>>> is submitted.  We will need a fag for the sync_incr and wait_syncpt >>>>>> commands, saying "it's a job's sync point increment/wait" >>>>> >>>>> Negative. Like I have explained in previous discussions, with the >>>>> current way the usage of hardware resources is much more deterministic >>>>> and obvious. I disagree on the point that this is much more complicated >>>>> for the userspace. Separating syncpoint and channel allocation is one of >>>>> the primary motivations of this series for me. >>>> >>>> Sync points are a limited resource. The most sensible way to work around >>>> it is to keep sync points within kernel as much as possible. This is not >>>> only much simpler for user space, but also allows to utilize DRM API >>>> properly without re-inventing what already exists and it's easier to >>>> maintain hardware in a good state. >>> >>> I've spent the last few years designing for automotive and industrial >>> products, where we don't want to at runtime notice that the system is out of >>> free syncpoints and because of that we can only process the next camera >>> frame in a second or two instead of 16 milliseconds. We need to know that >>> once we have allocated the resource, it is there. The newer chips are also >>> designed to support this. >>> >>> Considering Linux is increasingly being used for such applications, and they >>> are important target markets for NVIDIA, these need to be supported. >>> >>> Because of the above design constraint the userspace software that runs in >>> these environments also expects resources to be allocated up front. This >>> isn't a matter of having to design that software according to what kind of >>> allocation API we decide do at Linux level -- it's no use designing for >>> dynamic allocation if it leads to you not meeting the safety requirement of >>> needing to ensure you have all resources allocated up front. >>> >>> This isn't a good design feature just in a car, but in anything that needs >>> to be reliable. However, it does pose some tradeoffs, and if you think that >>> running out of syncpoints on T20-T114 because of upfront allocation is an >>> actual problem, I'm not opposed to having both options available. > > The word "reliable" contradicts to the error-prone approach. On the > other hand, it should be very difficult to change the stubborn > downstream firmware and we want driver to be usable as much as possible, > so in reality not much can be done about it. Depends on the perspective. > >> I think that's a fair point. I don't see why we can't support both >> implicit and explicit syncpoint requests. If most of the use-cases can >> work with implicit syncpoints and let the kernel handle all aspects of >> it, that's great. But there's no reason we can't provide more explicit >> controls for cases where it's really important that all the resources >> are allocated upfront. >> >> Ultimately this is very specific to each use-case, so I think having >> both options will provide us with the most flexibility. > It should be fine to support both. This will add complexity to the > driver, thus it needs to be done wisely. > > I'll need more time to think about it. > How about something like this: Turn the syncpt_incr field back into an array of structs like #define DRM_TEGRA_SUBMIT_SYNCPT_INCR_REPLACE_SYNCOBJ (1<<0) #define DRM_TEGRA_SUBMIT_SYNCPT_INCR_PATCH_DYNAMIC_SYNCPT (1<<1) struct drm_tegra_submit_syncpt_incr { /* can be left as zero if using dynamic syncpt */ __u32 syncpt_id; __u32 flags; struct { __u32 syncobj; __u32 value; } fence; /* patch word as such: * *word = *word | (syncpt_id << shift) */ struct { __u32 gather_offset_words; __u32 shift; } patch; }; So this will work similarly to the buffer reloc system; the kernel driver will allocate a job syncpoint and patch in the syncpoint ID if requested, and allows outputting syncobjs for each increment. Mikko 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=-5.2 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, 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 02DA6C433E0 for ; Wed, 3 Feb 2021 11:19:02 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 163A564F61 for ; Wed, 3 Feb 2021 11:19:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 163A564F61 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kapsi.fi Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6C4EC6EA67; Wed, 3 Feb 2021 11:19:00 +0000 (UTC) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) by gabe.freedesktop.org (Postfix) with ESMTPS id 12E276EA67 for ; Wed, 3 Feb 2021 11:18:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Gl7sCApRFJtBXnfga0Dh5hI1R8/2+lI2ntQWVhdy+mk=; b=E27X9izTmzcQzga6jy2dEuNoJO 9MC7V9W+sA/8ivSdgpSXPWzoAhHveywclwtujxBF+BwIxQL3OO2RLE1ZOLGN4uZj+6PrvmKY41Cbf w7plO+Jp/n71PlrKVTOgF/vTzID9hU+8Zt5lFby27hAuF41U06A8ugWWusc+D5iI4PDI3pyN8CGUc 1wMWJ591IOM436tTXIc8rxg0zkK0iASMgcy85K5m0C91mN8diIBINrYrL7ZJQ6oim44JAaFyObAtj VTc8SLc4YvXdOBw39mQNMuGl+M1jCTRXrL/SYEhITBTXTRw8gS2ZX8plZchRcTAg1qsUtWfYgyN6z mkDdil6g==; Received: from dsl-hkibng22-54f986-236.dhcp.inet.fi ([84.249.134.236] helo=[192.168.1.10]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1l7GBU-0008Nz-CH; Wed, 03 Feb 2021 13:18:56 +0200 Subject: Re: [PATCH v5 00/21] Host1x sync point UAPI should not be used for tracking DRM jobs To: Dmitry Osipenko , Thierry Reding References: <20210111130019.3515669-1-mperttunen@nvidia.com> <2f999b6d-d781-503a-78f4-d444bce72c58@kapsi.fi> <2ee12338-bd5a-4b99-f86d-13da0d2a899b@gmail.com> <8504c239-d5df-3033-934c-7b3fab52e387@kapsi.fi> <1ff922b2-161d-c8b9-7b08-4454ff7329f8@gmail.com> From: Mikko Perttunen Message-ID: <25248139-5487-a15b-8965-1a29a71eacd7@kapsi.fi> Date: Wed, 3 Feb 2021 13:18:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <1ff922b2-161d-c8b9-7b08-4454ff7329f8@gmail.com> Content-Language: en-US X-SA-Exim-Connect-IP: 84.249.134.236 X-SA-Exim-Mail-From: cyndis@kapsi.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: airlied@linux.ie, dri-devel@lists.freedesktop.org, jonathanh@nvidia.com, talho@nvidia.com, bhuntsman@nvidia.com, linux-tegra@vger.kernel.org, Mikko Perttunen Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" T24gMS8yOS8yMSA3OjMwIFBNLCBEbWl0cnkgT3NpcGVua28gd3JvdGU6Cj4gMjguMDEuMjAyMSAx OTo1OCwgVGhpZXJyeSBSZWRpbmcg0L/QuNGI0LXRgjoKPj4gT24gVGh1LCBKYW4gMjgsIDIwMjEg YXQgMDE6MDg6NTRQTSArMDIwMCwgTWlra28gUGVydHR1bmVuIHdyb3RlOgo+Pj4gT24gMS8yNy8y MSAxMToyMCBQTSwgRG1pdHJ5IE9zaXBlbmtvIHdyb3RlOgo+Pj4+IDI2LjAxLjIwMjEgMDU6NDUs IE1pa2tvIFBlcnR0dW5lbiDQv9C40YjQtdGCOgo+Pj4+Pj4gMi4gV2Ugd2lsbCBwcm9iYWJseSBu ZWVkIGEgZGVkaWNhdGVkIGRybV90ZWdyYV9zdWJtaXRfY21kIGZvciBzeW5jIHBvaW50Cj4+Pj4+ PiBpbmNyZW1lbnRzLsKgIFRoZSBqb2IncyBzeW5jIHBvaW50IHdpbGwgYmUgYWxsb2NhdGVkIGR5 bmFtaWNhbGx5IHdoZW4gam9iCj4+Pj4+PiBpcyBzdWJtaXR0ZWQuwqAgV2Ugd2lsbCBuZWVkIGEg ZmFnIGZvciB0aGUgc3luY19pbmNyIGFuZCB3YWl0X3N5bmNwdAo+Pj4+Pj4gY29tbWFuZHMsIHNh eWluZyAiaXQncyBhIGpvYidzIHN5bmMgcG9pbnQgaW5jcmVtZW50L3dhaXQiCj4+Pj4+Cj4+Pj4+ IE5lZ2F0aXZlLiBMaWtlIEkgaGF2ZSBleHBsYWluZWQgaW4gcHJldmlvdXMgZGlzY3Vzc2lvbnMs IHdpdGggdGhlCj4+Pj4+IGN1cnJlbnQgd2F5IHRoZSB1c2FnZSBvZiBoYXJkd2FyZSByZXNvdXJj ZXMgaXMgbXVjaCBtb3JlIGRldGVybWluaXN0aWMKPj4+Pj4gYW5kIG9idmlvdXMuIEkgZGlzYWdy ZWUgb24gdGhlIHBvaW50IHRoYXQgdGhpcyBpcyBtdWNoIG1vcmUgY29tcGxpY2F0ZWQKPj4+Pj4g Zm9yIHRoZSB1c2Vyc3BhY2UuIFNlcGFyYXRpbmcgc3luY3BvaW50IGFuZCBjaGFubmVsIGFsbG9j YXRpb24gaXMgb25lIG9mCj4+Pj4+IHRoZSBwcmltYXJ5IG1vdGl2YXRpb25zIG9mIHRoaXMgc2Vy aWVzIGZvciBtZS4KPj4+Pgo+Pj4+IFN5bmMgcG9pbnRzIGFyZSBhIGxpbWl0ZWQgcmVzb3VyY2Uu IFRoZSBtb3N0IHNlbnNpYmxlIHdheSB0byB3b3JrIGFyb3VuZAo+Pj4+IGl0IGlzIHRvIGtlZXAg c3luYyBwb2ludHMgd2l0aGluIGtlcm5lbCBhcyBtdWNoIGFzIHBvc3NpYmxlLiBUaGlzIGlzIG5v dAo+Pj4+IG9ubHkgbXVjaCBzaW1wbGVyIGZvciB1c2VyIHNwYWNlLCBidXQgYWxzbyBhbGxvd3Mg dG8gdXRpbGl6ZSBEUk0gQVBJCj4+Pj4gcHJvcGVybHkgd2l0aG91dCByZS1pbnZlbnRpbmcgd2hh dCBhbHJlYWR5IGV4aXN0cyBhbmQgaXQncyBlYXNpZXIgdG8KPj4+PiBtYWludGFpbiBoYXJkd2Fy ZSBpbiBhIGdvb2Qgc3RhdGUuCj4+Pgo+Pj4gSSd2ZSBzcGVudCB0aGUgbGFzdCBmZXcgeWVhcnMg ZGVzaWduaW5nIGZvciBhdXRvbW90aXZlIGFuZCBpbmR1c3RyaWFsCj4+PiBwcm9kdWN0cywgd2hl cmUgd2UgZG9uJ3Qgd2FudCB0byBhdCBydW50aW1lIG5vdGljZSB0aGF0IHRoZSBzeXN0ZW0gaXMg b3V0IG9mCj4+PiBmcmVlIHN5bmNwb2ludHMgYW5kIGJlY2F1c2Ugb2YgdGhhdCB3ZSBjYW4gb25s eSBwcm9jZXNzIHRoZSBuZXh0IGNhbWVyYQo+Pj4gZnJhbWUgaW4gYSBzZWNvbmQgb3IgdHdvIGlu c3RlYWQgb2YgMTYgbWlsbGlzZWNvbmRzLiBXZSBuZWVkIHRvIGtub3cgdGhhdAo+Pj4gb25jZSB3 ZSBoYXZlIGFsbG9jYXRlZCB0aGUgcmVzb3VyY2UsIGl0IGlzIHRoZXJlLiBUaGUgbmV3ZXIgY2hp cHMgYXJlIGFsc28KPj4+IGRlc2lnbmVkIHRvIHN1cHBvcnQgdGhpcy4KPj4+Cj4+PiBDb25zaWRl cmluZyBMaW51eCBpcyBpbmNyZWFzaW5nbHkgYmVpbmcgdXNlZCBmb3Igc3VjaCBhcHBsaWNhdGlv bnMsIGFuZCB0aGV5Cj4+PiBhcmUgaW1wb3J0YW50IHRhcmdldCBtYXJrZXRzIGZvciBOVklESUEs IHRoZXNlIG5lZWQgdG8gYmUgc3VwcG9ydGVkLgo+Pj4KPj4+IEJlY2F1c2Ugb2YgdGhlIGFib3Zl IGRlc2lnbiBjb25zdHJhaW50IHRoZSB1c2Vyc3BhY2Ugc29mdHdhcmUgdGhhdCBydW5zIGluCj4+ PiB0aGVzZSBlbnZpcm9ubWVudHMgYWxzbyBleHBlY3RzIHJlc291cmNlcyB0byBiZSBhbGxvY2F0 ZWQgdXAgZnJvbnQuIFRoaXMKPj4+IGlzbid0IGEgbWF0dGVyIG9mIGhhdmluZyB0byBkZXNpZ24g dGhhdCBzb2Z0d2FyZSBhY2NvcmRpbmcgdG8gd2hhdCBraW5kIG9mCj4+PiBhbGxvY2F0aW9uIEFQ SSB3ZSBkZWNpZGUgZG8gYXQgTGludXggbGV2ZWwgLS0gaXQncyBubyB1c2UgZGVzaWduaW5nIGZv cgo+Pj4gZHluYW1pYyBhbGxvY2F0aW9uIGlmIGl0IGxlYWRzIHRvIHlvdSBub3QgbWVldGluZyB0 aGUgc2FmZXR5IHJlcXVpcmVtZW50IG9mCj4+PiBuZWVkaW5nIHRvIGVuc3VyZSB5b3UgaGF2ZSBh bGwgcmVzb3VyY2VzIGFsbG9jYXRlZCB1cCBmcm9udC4KPj4+Cj4+PiBUaGlzIGlzbid0IGEgZ29v ZCBkZXNpZ24gZmVhdHVyZSBqdXN0IGluIGEgY2FyLCBidXQgaW4gYW55dGhpbmcgdGhhdCBuZWVk cwo+Pj4gdG8gYmUgcmVsaWFibGUuIEhvd2V2ZXIsIGl0IGRvZXMgcG9zZSBzb21lIHRyYWRlb2Zm cywgYW5kIGlmIHlvdSB0aGluayB0aGF0Cj4+PiBydW5uaW5nIG91dCBvZiBzeW5jcG9pbnRzIG9u IFQyMC1UMTE0IGJlY2F1c2Ugb2YgdXBmcm9udCBhbGxvY2F0aW9uIGlzIGFuCj4+PiBhY3R1YWwg cHJvYmxlbSwgSSdtIG5vdCBvcHBvc2VkIHRvIGhhdmluZyBib3RoIG9wdGlvbnMgYXZhaWxhYmxl Lgo+IAo+IFRoZSB3b3JkICJyZWxpYWJsZSIgY29udHJhZGljdHMgdG8gdGhlIGVycm9yLXByb25l IGFwcHJvYWNoLiBPbiB0aGUKPiBvdGhlciBoYW5kLCBpdCBzaG91bGQgYmUgdmVyeSBkaWZmaWN1 bHQgdG8gY2hhbmdlIHRoZSBzdHViYm9ybgo+IGRvd25zdHJlYW0gZmlybXdhcmUgYW5kIHdlIHdh bnQgZHJpdmVyIHRvIGJlIHVzYWJsZSBhcyBtdWNoIGFzIHBvc3NpYmxlLAo+IHNvIGluIHJlYWxp dHkgbm90IG11Y2ggY2FuIGJlIGRvbmUgYWJvdXQgaXQuCgpEZXBlbmRzIG9uIHRoZSBwZXJzcGVj dGl2ZS4KCj4gCj4+IEkgdGhpbmsgdGhhdCdzIGEgZmFpciBwb2ludC4gSSBkb24ndCBzZWUgd2h5 IHdlIGNhbid0IHN1cHBvcnQgYm90aAo+PiBpbXBsaWNpdCBhbmQgZXhwbGljaXQgc3luY3BvaW50 IHJlcXVlc3RzLiBJZiBtb3N0IG9mIHRoZSB1c2UtY2FzZXMgY2FuCj4+IHdvcmsgd2l0aCBpbXBs aWNpdCBzeW5jcG9pbnRzIGFuZCBsZXQgdGhlIGtlcm5lbCBoYW5kbGUgYWxsIGFzcGVjdHMgb2YK Pj4gaXQsIHRoYXQncyBncmVhdC4gQnV0IHRoZXJlJ3Mgbm8gcmVhc29uIHdlIGNhbid0IHByb3Zp ZGUgbW9yZSBleHBsaWNpdAo+PiBjb250cm9scyBmb3IgY2FzZXMgd2hlcmUgaXQncyByZWFsbHkg aW1wb3J0YW50IHRoYXQgYWxsIHRoZSByZXNvdXJjZXMKPj4gYXJlIGFsbG9jYXRlZCB1cGZyb250 Lgo+Pgo+PiBVbHRpbWF0ZWx5IHRoaXMgaXMgdmVyeSBzcGVjaWZpYyB0byBlYWNoIHVzZS1jYXNl LCBzbyBJIHRoaW5rIGhhdmluZwo+PiBib3RoIG9wdGlvbnMgd2lsbCBwcm92aWRlIHVzIHdpdGgg dGhlIG1vc3QgZmxleGliaWxpdHkuCj4gSXQgc2hvdWxkIGJlIGZpbmUgdG8gc3VwcG9ydCBib3Ro LiBUaGlzIHdpbGwgYWRkIGNvbXBsZXhpdHkgdG8gdGhlCj4gZHJpdmVyLCB0aHVzIGl0IG5lZWRz IHRvIGJlIGRvbmUgd2lzZWx5Lgo+IAo+IEknbGwgbmVlZCBtb3JlIHRpbWUgdG8gdGhpbmsgYWJv dXQgaXQuCj4gCgpIb3cgYWJvdXQgc29tZXRoaW5nIGxpa2UgdGhpczoKClR1cm4gdGhlIHN5bmNw dF9pbmNyIGZpZWxkIGJhY2sgaW50byBhbiBhcnJheSBvZiBzdHJ1Y3RzIGxpa2UKCiNkZWZpbmUg RFJNX1RFR1JBX1NVQk1JVF9TWU5DUFRfSU5DUl9SRVBMQUNFX1NZTkNPQkoJCSgxPDwwKQojZGVm aW5lIERSTV9URUdSQV9TVUJNSVRfU1lOQ1BUX0lOQ1JfUEFUQ0hfRFlOQU1JQ19TWU5DUFQJKDE8 PDEpCgpzdHJ1Y3QgZHJtX3RlZ3JhX3N1Ym1pdF9zeW5jcHRfaW5jciB7CgkvKiBjYW4gYmUgbGVm dCBhcyB6ZXJvIGlmIHVzaW5nIGR5bmFtaWMgc3luY3B0ICovCglfX3UzMiBzeW5jcHRfaWQ7Cglf X3UzMiBmbGFnczsKCglzdHJ1Y3QgewoJCV9fdTMyIHN5bmNvYmo7CgkJX191MzIgdmFsdWU7Cgl9 IGZlbmNlOwoKCS8qIHBhdGNoIHdvcmQgYXMgc3VjaDoKICAgICAgICAgICogKndvcmQgPSAqd29y ZCB8IChzeW5jcHRfaWQgPDwgc2hpZnQpCiAgICAgICAgICAqLwoJc3RydWN0IHsKCQlfX3UzMiBn YXRoZXJfb2Zmc2V0X3dvcmRzOwoJCV9fdTMyIHNoaWZ0OwoJfSBwYXRjaDsKfTsKClNvIHRoaXMg d2lsbCB3b3JrIHNpbWlsYXJseSB0byB0aGUgYnVmZmVyIHJlbG9jIHN5c3RlbTsgdGhlIGtlcm5l bCAKZHJpdmVyIHdpbGwgYWxsb2NhdGUgYSBqb2Igc3luY3BvaW50IGFuZCBwYXRjaCBpbiB0aGUg c3luY3BvaW50IElEIGlmIApyZXF1ZXN0ZWQsIGFuZCBhbGxvd3Mgb3V0cHV0dGluZyBzeW5jb2Jq cyBmb3IgZWFjaCBpbmNyZW1lbnQuCgpNaWtrbwpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0 cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9s aXN0aW5mby9kcmktZGV2ZWwK