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=-14.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 002FAC63777 for ; Tue, 17 Nov 2020 22:02:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 94E8B241A7 for ; Tue, 17 Nov 2020 22:02:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="aUPTRert" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728608AbgKQWCh (ORCPT ); Tue, 17 Nov 2020 17:02:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56010 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726504AbgKQWCh (ORCPT ); Tue, 17 Nov 2020 17:02:37 -0500 Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CBBA0C0613CF; Tue, 17 Nov 2020 14:02:36 -0800 (PST) Received: by mail-lj1-x244.google.com with SMTP id b17so16550ljf.12; Tue, 17 Nov 2020 14:02:36 -0800 (PST) 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=W5om3zQzsHiBGMpHdWoQikEGL2r18KBMb1Ag+GnaG08=; b=aUPTRertfb05h4PXQBp+XblhFmhkq3dYxYo19vCMmRFRwFfo3o1IW4o98iLAok03IX SB7/dAIf/DxDZrSAmId3g1EI40aBDac3fFJ5YPVvSW4ZcmMmQ1/fZT7zXo9ji1tnSBH2 2ryoHGWBmcPCOGGdekoRik9gvEfoJIq1jigT730xbZyGcrmpeGU4NrOrXGvOplzotgE/ YujRyvzI7YgCBSKphSJsvHJdJaz64JVUE1DdR45WFz0QWc2ezvGHPVWoY5Lg6HFf46Nl 0V2nRoj5jQVYhYcul1ZHcmKsPqCQgZ5dqIGEIVHgEXRfIfsykIDOct6IpeM1FbHDQTJX oN4g== 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=W5om3zQzsHiBGMpHdWoQikEGL2r18KBMb1Ag+GnaG08=; b=Ue1BuOWJ5esZvC4xTAbhknFSXbd5ZEjvBF0Z0EzmHKQgLAE25nteGP60PitT7U5xtx Ni30aY5XdRyyLCCu/O+8xujmhLSTUsadauTIfMhnlMCIvMHo8frwgV8A8DEMTAZmFJBz tZQglRBPi8FxjI8pW2YUTvpnZAb9/QTcLmm6qqZnIkasyKMcOkxjxJWQSkPMa3zv/T4l 92w7keejWhlc7RZqID5OF412FqEmlrOWT+iHEmHgHnjG5Itkan8NjB+6VOC10FM9nPKe HYqGCYlRUvrSi1PT53jYoQLbtw+5mAqRncx5i/auDPd2zVOMN6cSXlOmvN4h76fHcvCV 3iqg== X-Gm-Message-State: AOAM530Q/iTPEWsZaEltAKuHfYU0u5d7Uyr3uI8BYoD46z3NTII/bZgu LZw8EnL0BcEwmj4QYxQ5kKE= X-Google-Smtp-Source: ABdhPJxGxTDDbi0d8oMMgkGSyKhMr/XNvJc72UcmGlAMm4SW4FF2fTuHTUsirRfiv8AMfkDsmlK1rg== X-Received: by 2002:a05:651c:30d:: with SMTP id a13mr2849268ljp.386.1605650555139; Tue, 17 Nov 2020 14:02:35 -0800 (PST) Received: from [192.168.2.145] (109-252-193-159.dynamic.spd-mgts.ru. [109.252.193.159]) by smtp.googlemail.com with ESMTPSA id v16sm3215544ljj.0.2020.11.17.14.02.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Nov 2020 14:02:34 -0800 (PST) Subject: Re: [PATCH v9 01/17] memory: tegra30: Support interconnect framework To: Georgi Djakov , Thierry Reding , Jonathan Hunter , Rob Herring , Michael Turquette , Stephen Boyd , Peter De Schrijver , MyungJoo Ham , Kyungmin Park , Chanwoo Choi , Mikko Perttunen , Viresh Kumar , Peter Geis , Nicolas Chauvet , Krzysztof Kozlowski Cc: linux-tegra@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org References: <20201115212922.4390-1-digetx@gmail.com> <20201115212922.4390-2-digetx@gmail.com> <61e777d9-b730-02c6-cedf-cf0aa1a50fb8@linaro.org> From: Dmitry Osipenko Message-ID: <7e484678-43cc-e612-1017-73ed580f9840@gmail.com> Date: Wed, 18 Nov 2020 01:02:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 MIME-Version: 1.0 In-Reply-To: <61e777d9-b730-02c6-cedf-cf0aa1a50fb8@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 17.11.2020 23:24, Georgi Djakov пишет: > Hi Dmitry, > > Thank you working on this! > > On 15.11.20 23:29, Dmitry Osipenko wrote: >> Now Internal and External memory controllers are memory interconnection >> providers. This allows us to use interconnect API for tuning of memory >> configuration. EMC driver now supports OPPs and DVFS. MC driver now >> supports tuning of memory arbitration latency, which needs to be done >> for ISO memory clients, like a Display client for example. >> >> Tested-by: Peter Geis >> Signed-off-by: Dmitry Osipenko >> --- >>   drivers/memory/tegra/Kconfig       |   1 + >>   drivers/memory/tegra/tegra30-emc.c | 349 +++++++++++++++++++++++++++-- >>   drivers/memory/tegra/tegra30.c     | 173 +++++++++++++- >>   3 files changed, 501 insertions(+), 22 deletions(-) >> > [..]> diff --git a/drivers/memory/tegra/tegra30.c > b/drivers/memory/tegra/tegra30.c >> index d0314f29608d..ea849003014b 100644 >> --- a/drivers/memory/tegra/tegra30.c >> +++ b/drivers/memory/tegra/tegra30.c > [..] >> + >> +static int tegra30_mc_icc_set(struct icc_node *src, struct icc_node >> *dst) >> +{ >> +    struct tegra_mc *mc = icc_provider_to_tegra_mc(src->provider); >> +    const struct tegra_mc_client *client = &mc->soc->clients[src->id]; >> +    u64 peak_bandwidth = icc_units_to_bps(src->peak_bw); >> + >> +    /* >> +     * Skip pre-initialization that is done by icc_node_add(), which >> sets >> +     * bandwidth to maximum for all clients before drivers are loaded. >> +     * >> +     * This doesn't make sense for us because we don't have drivers >> for all >> +     * clients and it's okay to keep configuration left from bootloader >> +     * during boot, at least for today. >> +     */ >> +    if (src == dst) >> +        return 0; > > Nit: The "proper" way to express this should be to implement the > .get_bw() callback to return zero as initial average/peak bandwidth. > I'm wondering if this will work here? > > The rest looks good to me! Hello Georgi, Returning zeros doesn't allow us to skip the initialization that is done by provider->set(node, node) in icc_node_add(). It will reconfigure memory latency in accordance to a zero memory bandwidth, which is wrong to do. It actually should be more preferred to preset bandwidth to a maximum before all drivers are synced, but this should be done only once we will wire up all drivers to use ICC framework. For now it's safer to keep the default hardware configuration untouched.