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.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 E85D0C3815B for ; Tue, 14 Apr 2020 15:18:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C69ED20768 for ; Tue, 14 Apr 2020 15:18:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YIhYIz+C" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407353AbgDNPSi (ORCPT ); Tue, 14 Apr 2020 11:18:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46056 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S2407351AbgDNPSd (ORCPT ); Tue, 14 Apr 2020 11:18:33 -0400 Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B2219C061A0E; Tue, 14 Apr 2020 08:18:32 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id f8so3535lfe.12; Tue, 14 Apr 2020 08:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EaqdjDcz077guZZFx5utO0urvqfVvTtoCeZlyZLJ4kY=; b=YIhYIz+CpSklWfCMJiTQBwpRgBV0ctYIjrrVfeiHT9KHQexJd3U4HTtPCr4YalaSor Nb/P9+fWUhEsKtY7TsxML4gIPd5EAK5Ea/FBa2dXkvA/Ka/S2TcspycJTVowoi8l/lvV bK0PHJg39vlv9KuSwx8jW5cpVUz2xh6WeiWBTOgDFSmo5jjUx8+nRixvPGoTu/sRCl53 xYmnFJQ/Dj6jC6TBu2wwg9vVcia08ijGsDcewfTfwArjgo7QZT4pzKdYLV5PCAdO/Dvg fh12n66uiF5FpV8ODdEGvsRqDELFXYsEYpdgoT76TZ+yn5bYItrrl54uRhcevznrgAQW Pd+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EaqdjDcz077guZZFx5utO0urvqfVvTtoCeZlyZLJ4kY=; b=GqQ+0toOZ8vyW9tFLcR/Knkn2LgjVR3IzbDMdwI0C1lyIGPSnkOuw8eVoLwAMqfjUw STpGymBaN/eiA4Dd0pAmkfIsHUf38Xx/uRE/oABlJq6kKIrAGyhDKEzzE9hb8w4f98eW H2gdUdPsL0OUqPE9SwAknxTTDpdHp86mSaVMFf6+1P6K7aulQikUsQspsbB5eUw3Cy2L 2qI0JLdPgS1TXsV7HZALNorOAD4jiI+J9gcfF3ePY3Wx8RnqlCLFJn+gOLFiK4WLWZxN ILBZYv7PG9z5n+XJ7jKAMlIRHlkCZQyOkuY86veXSnh0GmcU7ic5lWFg+p4s/yej6FDa JRRA== X-Gm-Message-State: AGi0PubQUvAkqRl7ntjGBoN8AdI0w5UoMbTW7SCO53Ar5jEG7yhCpgYU ktx0yUUUngXYlbsUjSWNqPw= X-Google-Smtp-Source: APiQypLUTnN9jhL1/kjbd/qXnyU7SH/YSbBa5XG5eUCrFPojjrbpHlIpRKG9PuFRu/KbkQRc6zRgEg== X-Received: by 2002:a19:c14e:: with SMTP id r75mr221935lff.62.1586877510987; Tue, 14 Apr 2020 08:18:30 -0700 (PDT) Received: from [192.168.2.145] (ppp91-78-208-152.pppoe.mtu-net.ru. [91.78.208.152]) by smtp.googlemail.com with ESMTPSA id j14sm9865266lfm.73.2020.04.14.08.18.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Apr 2020 08:18:30 -0700 (PDT) Subject: Re: [PATCH v6 07/14] clk: tegra: Implement Tegra210 EMC clock To: Thierry Reding Cc: Rob Herring , Jon Hunter , Michael Turquette , Stephen Boyd , Joseph Lo , linux-tegra@vger.kernel.org, devicetree@vger.kernel.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20200409175238.3586487-1-thierry.reding@gmail.com> <20200409175238.3586487-8-thierry.reding@gmail.com> <8dc000fb-8867-cf8f-8204-a9e1e79a4811@gmail.com> <20200414143424.GG3593749@ulmo> From: Dmitry Osipenko Message-ID: <92eb73ba-73e4-f9f1-bb22-9b515e32cee6@gmail.com> Date: Tue, 14 Apr 2020 18:18:29 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200414143424.GG3593749@ulmo> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-clk-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org 14.04.2020 17:34, Thierry Reding пишет: > On Thu, Apr 09, 2020 at 09:24:31PM +0300, Dmitry Osipenko wrote: >> 09.04.2020 20:52, Thierry Reding пишет: >> ... >>> +static long tegra210_clk_emc_round_rate(struct clk_hw *hw, unsigned long rate, >>> + unsigned long *prate) >>> +{ >>> + struct tegra210_clk_emc *emc = to_tegra210_clk_emc(hw); >>> + struct tegra210_clk_emc_provider *provider = emc->provider; >>> + unsigned int i; >>> + >>> + if (!provider || !provider->configs || provider->num_configs == 0) >>> + return clk_hw_get_rate(hw); >> >> This still looks wrong to me. Nobody should be able to get EMC clock >> until provider is registered. > > The EMC clock is mostly orthogonal to the provider. The provider really > only allows you to actually change the frequency. The clock will still > remain even if the provider goes away, it just will loose the ability to > change rate. It's not only about changing the clock rate, but also about rounding the rate and etc. Besides, you won't be able to change the rate until provider is registered, which might be a quite big problem by itself. >> This is troublesome, especially given that you're allowing the EMC >> driver to be compiled as a loadable module. For example, this won't work >> with the current ACTMON driver because it builds OPP table based on the >> clk-rate rounding during the driver's probe, so it won't be able to do >> it properly if provider is "temporarily" missing. >> >> ... I think that in a longer run we should stop manually building the >> ACTMON's OPP table and instead define a proper OPP table (per-HW Speedo >> ID, with voltages) in a device-tree. But this is just a vague plans for >> the future for now. > > This code only applies to Tegra210 and we don't currently support ACTMON > on Tegra210. I'm also not sure we'll ever do because using interconnects > to describe paths to system memory and then using ICC requests for each > driver to submit memory bandwidth requests seems like a better way of > dealing with this problem than using ACTMON to monitor activity because > that only allows you to react, whereas we really want to be able to > allocate memory bandwidth upfront. You absolutely have to have the ACTMON support if you want to provide a good user experience because interconnect won't take into account the dynamic CPU memory traffic. Without ACTMON support CPU will turn into a "turtle" if memory runs on a lowest freq, while CPU needs the highest. Secondly, the interconnect could underestimate the memory BW requirement because memory performance depends quite a lot on the memory-accessing patterns and it's not possible to predict it properly. Otherwise you may need to always overestimate the BW, which perhaps is not what anyone would really want to have. I'm not sure why you're resisting to do it all properly from the start, it looks to me that it will take you just a few lines of code (like in a case of the T20/30 EMC). From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Osipenko Subject: Re: [PATCH v6 07/14] clk: tegra: Implement Tegra210 EMC clock Date: Tue, 14 Apr 2020 18:18:29 +0300 Message-ID: <92eb73ba-73e4-f9f1-bb22-9b515e32cee6@gmail.com> References: <20200409175238.3586487-1-thierry.reding@gmail.com> <20200409175238.3586487-8-thierry.reding@gmail.com> <8dc000fb-8867-cf8f-8204-a9e1e79a4811@gmail.com> <20200414143424.GG3593749@ulmo> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <20200414143424.GG3593749@ulmo> Content-Language: en-US Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Thierry Reding Cc: Rob Herring , Jon Hunter , Michael Turquette , Stephen Boyd , Joseph Lo , linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: linux-tegra@vger.kernel.org 14.04.2020 17:34, Thierry Reding пишет: > On Thu, Apr 09, 2020 at 09:24:31PM +0300, Dmitry Osipenko wrote: >> 09.04.2020 20:52, Thierry Reding пишет: >> ... >>> +static long tegra210_clk_emc_round_rate(struct clk_hw *hw, unsigned long rate, >>> + unsigned long *prate) >>> +{ >>> + struct tegra210_clk_emc *emc = to_tegra210_clk_emc(hw); >>> + struct tegra210_clk_emc_provider *provider = emc->provider; >>> + unsigned int i; >>> + >>> + if (!provider || !provider->configs || provider->num_configs == 0) >>> + return clk_hw_get_rate(hw); >> >> This still looks wrong to me. Nobody should be able to get EMC clock >> until provider is registered. > > The EMC clock is mostly orthogonal to the provider. The provider really > only allows you to actually change the frequency. The clock will still > remain even if the provider goes away, it just will loose the ability to > change rate. It's not only about changing the clock rate, but also about rounding the rate and etc. Besides, you won't be able to change the rate until provider is registered, which might be a quite big problem by itself. >> This is troublesome, especially given that you're allowing the EMC >> driver to be compiled as a loadable module. For example, this won't work >> with the current ACTMON driver because it builds OPP table based on the >> clk-rate rounding during the driver's probe, so it won't be able to do >> it properly if provider is "temporarily" missing. >> >> ... I think that in a longer run we should stop manually building the >> ACTMON's OPP table and instead define a proper OPP table (per-HW Speedo >> ID, with voltages) in a device-tree. But this is just a vague plans for >> the future for now. > > This code only applies to Tegra210 and we don't currently support ACTMON > on Tegra210. I'm also not sure we'll ever do because using interconnects > to describe paths to system memory and then using ICC requests for each > driver to submit memory bandwidth requests seems like a better way of > dealing with this problem than using ACTMON to monitor activity because > that only allows you to react, whereas we really want to be able to > allocate memory bandwidth upfront. You absolutely have to have the ACTMON support if you want to provide a good user experience because interconnect won't take into account the dynamic CPU memory traffic. Without ACTMON support CPU will turn into a "turtle" if memory runs on a lowest freq, while CPU needs the highest. Secondly, the interconnect could underestimate the memory BW requirement because memory performance depends quite a lot on the memory-accessing patterns and it's not possible to predict it properly. Otherwise you may need to always overestimate the BW, which perhaps is not what anyone would really want to have. I'm not sure why you're resisting to do it all properly from the start, it looks to me that it will take you just a few lines of code (like in a case of the T20/30 EMC). 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.0 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 3B5C4C38A29 for ; Tue, 14 Apr 2020 15:18: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 0CE9C2076B for ; Tue, 14 Apr 2020 15:18: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="aUpDW31X"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YIhYIz+C" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0CE9C2076B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=dME9OyMl1x79D2K2xzyBj12F7oXmqfgR8kMdJUYPug0=; b=aUpDW31XZSvyb4 3FXRYywwcS2n85EB1fYX8TP9nElIwFwQemNDNwxmbRBlfeoQrFl17H0OumwOZFbmXH0Wu44umIxnV 5esMOp7XbuNSPd8Id1FSdY9EZlTyPNPWeMoyqFXDxerVcEiKRB++I758oijnf+aH71gYZdQqGsZO0 jyjhgknjiyiTB2AF1JQGUzykaIukq8bABeCBE1qjF5FiAALpOQYHDqzBxxqgO6Ge5+Hs/Naub8KwM 06lMrm6jIK34FplLVe+iDjoRmT+/PWvu9Wmf9sQfr3j1EXsAyOCqQwJFPtiDYLoRZEEEmAmyO1H42 1vmjm2RHg2X5GbG151Mg==; 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 1jONKf-00027L-0l; Tue, 14 Apr 2020 15:18:37 +0000 Received: from mail-lf1-x143.google.com ([2a00:1450:4864:20::143]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jONKc-00026z-0K for linux-arm-kernel@lists.infradead.org; Tue, 14 Apr 2020 15:18:35 +0000 Received: by mail-lf1-x143.google.com with SMTP id k28so14387lfe.10 for ; Tue, 14 Apr 2020 08:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EaqdjDcz077guZZFx5utO0urvqfVvTtoCeZlyZLJ4kY=; b=YIhYIz+CpSklWfCMJiTQBwpRgBV0ctYIjrrVfeiHT9KHQexJd3U4HTtPCr4YalaSor Nb/P9+fWUhEsKtY7TsxML4gIPd5EAK5Ea/FBa2dXkvA/Ka/S2TcspycJTVowoi8l/lvV bK0PHJg39vlv9KuSwx8jW5cpVUz2xh6WeiWBTOgDFSmo5jjUx8+nRixvPGoTu/sRCl53 xYmnFJQ/Dj6jC6TBu2wwg9vVcia08ijGsDcewfTfwArjgo7QZT4pzKdYLV5PCAdO/Dvg fh12n66uiF5FpV8ODdEGvsRqDELFXYsEYpdgoT76TZ+yn5bYItrrl54uRhcevznrgAQW Pd+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EaqdjDcz077guZZFx5utO0urvqfVvTtoCeZlyZLJ4kY=; b=Bz/6P4rod3X0ZiTAHDI6idJQv4yuZS+7d+37lkl+JjV4uXPHJu2oh3Lr2TRrS4SO80 o0Dvy9xdZW6Ck+5px0WmsiK51/dQzh4AJR5NhpeNeIXPs6j1FcIAY0XHdtsuZ+1jh+Q0 97Y1GxG8blnpx3HLjVd5sqS5pJo07Tq+d1Rc2Y7Luc0Id2HRQLuSpKpBeAvjlhmj6121 C+1NW0cePtE5zNgazuGzXURSMiRV9ht5l7sl4Hg6dgya21MIiilMYTN+XQ8tFFvxgrF9 TRlg8c179hzyN1PK8sf+R8I7yMNB81aSNCm977/xyY2fRvP32wXeyLJACmFYaghtMtCP +0aw== X-Gm-Message-State: AGi0PuY1crTeedGj/VDw1T3cDgR53Pze2X8Jo79zxGwZLSv87xR7Eftd OvObBs6A5i9XgNOfZ9CkhpO+yWfk X-Google-Smtp-Source: APiQypLUTnN9jhL1/kjbd/qXnyU7SH/YSbBa5XG5eUCrFPojjrbpHlIpRKG9PuFRu/KbkQRc6zRgEg== X-Received: by 2002:a19:c14e:: with SMTP id r75mr221935lff.62.1586877510987; Tue, 14 Apr 2020 08:18:30 -0700 (PDT) Received: from [192.168.2.145] (ppp91-78-208-152.pppoe.mtu-net.ru. [91.78.208.152]) by smtp.googlemail.com with ESMTPSA id j14sm9865266lfm.73.2020.04.14.08.18.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Apr 2020 08:18:30 -0700 (PDT) Subject: Re: [PATCH v6 07/14] clk: tegra: Implement Tegra210 EMC clock To: Thierry Reding References: <20200409175238.3586487-1-thierry.reding@gmail.com> <20200409175238.3586487-8-thierry.reding@gmail.com> <8dc000fb-8867-cf8f-8204-a9e1e79a4811@gmail.com> <20200414143424.GG3593749@ulmo> From: Dmitry Osipenko Message-ID: <92eb73ba-73e4-f9f1-bb22-9b515e32cee6@gmail.com> Date: Tue, 14 Apr 2020 18:18:29 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200414143424.GG3593749@ulmo> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200414_081834_046203_119542F2 X-CRM114-Status: GOOD ( 21.28 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Stephen Boyd , Michael Turquette , Jon Hunter , Rob Herring , Joseph Lo , linux-tegra@vger.kernel.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org MTQuMDQuMjAyMCAxNzozNCwgVGhpZXJyeSBSZWRpbmcg0L/QuNGI0LXRgjoKPiBPbiBUaHUsIEFw ciAwOSwgMjAyMCBhdCAwOToyNDozMVBNICswMzAwLCBEbWl0cnkgT3NpcGVua28gd3JvdGU6Cj4+ IDA5LjA0LjIwMjAgMjA6NTIsIFRoaWVycnkgUmVkaW5nINC/0LjRiNC10YI6Cj4+IC4uLgo+Pj4g K3N0YXRpYyBsb25nIHRlZ3JhMjEwX2Nsa19lbWNfcm91bmRfcmF0ZShzdHJ1Y3QgY2xrX2h3ICpo dywgdW5zaWduZWQgbG9uZyByYXRlLAo+Pj4gKwkJCQkJdW5zaWduZWQgbG9uZyAqcHJhdGUpCj4+ PiArewo+Pj4gKwlzdHJ1Y3QgdGVncmEyMTBfY2xrX2VtYyAqZW1jID0gdG9fdGVncmEyMTBfY2xr X2VtYyhodyk7Cj4+PiArCXN0cnVjdCB0ZWdyYTIxMF9jbGtfZW1jX3Byb3ZpZGVyICpwcm92aWRl ciA9IGVtYy0+cHJvdmlkZXI7Cj4+PiArCXVuc2lnbmVkIGludCBpOwo+Pj4gKwo+Pj4gKwlpZiAo IXByb3ZpZGVyIHx8ICFwcm92aWRlci0+Y29uZmlncyB8fCBwcm92aWRlci0+bnVtX2NvbmZpZ3Mg PT0gMCkKPj4+ICsJCXJldHVybiBjbGtfaHdfZ2V0X3JhdGUoaHcpOwo+Pgo+PiBUaGlzIHN0aWxs IGxvb2tzIHdyb25nIHRvIG1lLiBOb2JvZHkgc2hvdWxkIGJlIGFibGUgdG8gZ2V0IEVNQyBjbG9j awo+PiB1bnRpbCBwcm92aWRlciBpcyByZWdpc3RlcmVkLgo+IAo+IFRoZSBFTUMgY2xvY2sgaXMg bW9zdGx5IG9ydGhvZ29uYWwgdG8gdGhlIHByb3ZpZGVyLiBUaGUgcHJvdmlkZXIgcmVhbGx5Cj4g b25seSBhbGxvd3MgeW91IHRvIGFjdHVhbGx5IGNoYW5nZSB0aGUgZnJlcXVlbmN5LiBUaGUgY2xv Y2sgd2lsbCBzdGlsbAo+IHJlbWFpbiBldmVuIGlmIHRoZSBwcm92aWRlciBnb2VzIGF3YXksIGl0 IGp1c3Qgd2lsbCBsb29zZSB0aGUgYWJpbGl0eSB0bwo+IGNoYW5nZSByYXRlLgoKSXQncyBub3Qg b25seSBhYm91dCBjaGFuZ2luZyB0aGUgY2xvY2sgcmF0ZSwgYnV0IGFsc28gYWJvdXQgcm91bmRp bmcgdGhlCnJhdGUgYW5kIGV0Yy4KCkJlc2lkZXMsIHlvdSB3b24ndCBiZSBhYmxlIHRvIGNoYW5n ZSB0aGUgcmF0ZSB1bnRpbCBwcm92aWRlciBpcwpyZWdpc3RlcmVkLCB3aGljaCBtaWdodCBiZSBh IHF1aXRlIGJpZyBwcm9ibGVtIGJ5IGl0c2VsZi4KCj4+IFRoaXMgaXMgdHJvdWJsZXNvbWUsIGVz cGVjaWFsbHkgZ2l2ZW4gdGhhdCB5b3UncmUgYWxsb3dpbmcgdGhlIEVNQwo+PiBkcml2ZXIgdG8g YmUgY29tcGlsZWQgYXMgYSBsb2FkYWJsZSBtb2R1bGUuIEZvciBleGFtcGxlLCB0aGlzIHdvbid0 IHdvcmsKPj4gd2l0aCB0aGUgY3VycmVudCBBQ1RNT04gZHJpdmVyIGJlY2F1c2UgaXQgYnVpbGRz IE9QUCB0YWJsZSBiYXNlZCBvbiB0aGUKPj4gY2xrLXJhdGUgcm91bmRpbmcgZHVyaW5nIHRoZSBk cml2ZXIncyBwcm9iZSwgc28gaXQgd29uJ3QgYmUgYWJsZSB0byBkbwo+PiBpdCBwcm9wZXJseSBp ZiBwcm92aWRlciBpcyAidGVtcG9yYXJpbHkiIG1pc3NpbmcuCj4+Cj4+IC4uLiBJIHRoaW5rIHRo YXQgaW4gYSBsb25nZXIgcnVuIHdlIHNob3VsZCBzdG9wIG1hbnVhbGx5IGJ1aWxkaW5nIHRoZQo+ PiBBQ1RNT04ncyBPUFAgdGFibGUgYW5kIGluc3RlYWQgZGVmaW5lIGEgcHJvcGVyIE9QUCB0YWJs ZSAocGVyLUhXIFNwZWVkbwo+PiBJRCwgd2l0aCB2b2x0YWdlcykgaW4gYSBkZXZpY2UtdHJlZS4g QnV0IHRoaXMgaXMganVzdCBhIHZhZ3VlIHBsYW5zIGZvcgo+PiB0aGUgZnV0dXJlIGZvciBub3cu Cj4gCj4gVGhpcyBjb2RlIG9ubHkgYXBwbGllcyB0byBUZWdyYTIxMCBhbmQgd2UgZG9uJ3QgY3Vy cmVudGx5IHN1cHBvcnQgQUNUTU9OCj4gb24gVGVncmEyMTAuIEknbSBhbHNvIG5vdCBzdXJlIHdl J2xsIGV2ZXIgZG8gYmVjYXVzZSB1c2luZyBpbnRlcmNvbm5lY3RzCj4gdG8gZGVzY3JpYmUgcGF0 aHMgdG8gc3lzdGVtIG1lbW9yeSBhbmQgdGhlbiB1c2luZyBJQ0MgcmVxdWVzdHMgZm9yIGVhY2gK PiBkcml2ZXIgdG8gc3VibWl0IG1lbW9yeSBiYW5kd2lkdGggcmVxdWVzdHMgc2VlbXMgbGlrZSBh IGJldHRlciB3YXkgb2YKPiBkZWFsaW5nIHdpdGggdGhpcyBwcm9ibGVtIHRoYW4gdXNpbmcgQUNU TU9OIHRvIG1vbml0b3IgYWN0aXZpdHkgYmVjYXVzZQo+IHRoYXQgb25seSBhbGxvd3MgeW91IHRv IHJlYWN0LCB3aGVyZWFzIHdlIHJlYWxseSB3YW50IHRvIGJlIGFibGUgdG8KPiBhbGxvY2F0ZSBt ZW1vcnkgYmFuZHdpZHRoIHVwZnJvbnQuCgpZb3UgYWJzb2x1dGVseSBoYXZlIHRvIGhhdmUgdGhl IEFDVE1PTiBzdXBwb3J0IGlmIHlvdSB3YW50IHRvIHByb3ZpZGUgYQpnb29kIHVzZXIgZXhwZXJp ZW5jZSBiZWNhdXNlIGludGVyY29ubmVjdCB3b24ndCB0YWtlIGludG8gYWNjb3VudCB0aGUKZHlu YW1pYyBDUFUgbWVtb3J5IHRyYWZmaWMuIFdpdGhvdXQgQUNUTU9OIHN1cHBvcnQgQ1BVIHdpbGwg dHVybiBpbnRvIGEKInR1cnRsZSIgaWYgbWVtb3J5IHJ1bnMgb24gYSBsb3dlc3QgZnJlcSwgd2hp bGUgQ1BVIG5lZWRzIHRoZSBoaWdoZXN0LgoKU2Vjb25kbHksIHRoZSBpbnRlcmNvbm5lY3QgY291 bGQgdW5kZXJlc3RpbWF0ZSB0aGUgbWVtb3J5IEJXIHJlcXVpcmVtZW50CmJlY2F1c2UgbWVtb3J5 IHBlcmZvcm1hbmNlIGRlcGVuZHMgcXVpdGUgYSBsb3Qgb24gdGhlIG1lbW9yeS1hY2Nlc3NpbmcK cGF0dGVybnMgYW5kIGl0J3Mgbm90IHBvc3NpYmxlIHRvIHByZWRpY3QgaXQgcHJvcGVybHkuIE90 aGVyd2lzZSB5b3UgbWF5Cm5lZWQgdG8gYWx3YXlzIG92ZXJlc3RpbWF0ZSB0aGUgQlcsIHdoaWNo IHBlcmhhcHMgaXMgbm90IHdoYXQgYW55b25lCndvdWxkIHJlYWxseSB3YW50IHRvIGhhdmUuCgpJ J20gbm90IHN1cmUgd2h5IHlvdSdyZSByZXNpc3RpbmcgdG8gZG8gaXQgYWxsIHByb3Blcmx5IGZy b20gdGhlIHN0YXJ0LAppdCBsb29rcyB0byBtZSB0aGF0IGl0IHdpbGwgdGFrZSB5b3UganVzdCBh IGZldyBsaW5lcyBvZiBjb2RlIChsaWtlIGluIGEKY2FzZSBvZiB0aGUgVDIwLzMwIEVNQykuCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0t a2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcK aHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2Vy bmVsCg==