Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp915929ybl; Wed, 8 Jan 2020 08:00:37 -0800 (PST) X-Google-Smtp-Source: APXvYqzCWNX2Ot+cI+zXzkVNO9XWfNOvfKg1xdh0WBDvl34/Ouf4eb6q5JDpgQ1w6h9qkQe3r7nD X-Received: by 2002:a54:4595:: with SMTP id z21mr3605007oib.136.1578499237659; Wed, 08 Jan 2020 08:00:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578499237; cv=none; d=google.com; s=arc-20160816; b=F2F5VVM883ZkPffIIu+zXc7Lr6kG96wvJaQ2SIhmMW4q0TSfZOztdYnhYXnvZ/1A2M 1kEsAEf0nSh20bgUMZCVeIMGvg6KL0R39RKEU+XwJh4+UBY+SggcGoObnR7k+C7s+toH DpiQysNd7+dl4HVDqYoQZN1kgXokdymp+E5bKJxwvNJqlQfO8ZPccK/xoKJymW4hs4U9 yrVEUGuFApSRwFd7VuJuM4DRXse9arpGR8m0287dVPoCMDPBArGNGP0TdydXa0FCTBd/ 9fgJQFJ0waKhQlM4NV3PxJjWgpgP/8orYTazW3rX0mmF0Pvsw6J4G5/juyauRGIIP3OC 8Uog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=8N6auOkOUI9EBQePB/gLYAhFAr4sHXqpFT+qTfELYHM=; b=E+5lvF4fUGuvU5U9jF92QH1O2m3H91eukn7A4odehQFRfpicIz+Lt997z9QA7YcYOL euJ/2CtBQxyVdCIJFppT2AkDQ/VfoXEPqO5YgSv4WExRP8t55OCpeNZFrKH1To6DlKS6 sdAjg6tD4qIhgc4kGwLQZSNhh8LMFE+tMVGxCqxT1MSmkQcitOxeJI/tU47/N3K96Ba5 jx9wSfulktHD39Y4F4OYztxhY8Jq6/jOeauj4yMgWI+sRb1g0Rb8ZIWMJeFUb1mfTAr3 20nH35/3z4Xsk3Y1JEtqb/oqU5q5qiXBhgV1fBPxGbP9JXL2QilIEFWJ1yxah6gy0lbR yR4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=biuLjm7a; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c19si1968954otp.3.2020.01.08.08.00.24; Wed, 08 Jan 2020 08:00:37 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=biuLjm7a; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728121AbgAHPKe (ORCPT + 99 others); Wed, 8 Jan 2020 10:10:34 -0500 Received: from mail-lj1-f194.google.com ([209.85.208.194]:37269 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726921AbgAHPKe (ORCPT ); Wed, 8 Jan 2020 10:10:34 -0500 Received: by mail-lj1-f194.google.com with SMTP id o13so3687920ljg.4; Wed, 08 Jan 2020 07:10:32 -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=8N6auOkOUI9EBQePB/gLYAhFAr4sHXqpFT+qTfELYHM=; b=biuLjm7aMHQWJyjiDU1z8tHxoz2PkBpj3EllPwynYOXp3U1b25Y37N3fL9m7uYZBYJ wJpmwVJne4XkIWn42w+2OG0Of24f3SMqDKrqnwRsXzkZAHWc8WWb2+MDv+E+vrb0zg07 Cz02hrb27HfQxgHSFsmPGfhRIQTZ1xOKgl5wAyQXEyTT2qK+IZVCHyHLefop8tfRJR3v 6uybFPww8NPheKBFGyGvMD9jmxfFxDX+kh5R7bomsX+oWTiD2lZF2eDYSDOWCpdkIAxe io9hazK7DVZGv3sT7COO7Zr0nVDeLo4VrgFN8IHWwcOvqb0efqHNe7W3FHx3xiqNdzgO fxVg== 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=8N6auOkOUI9EBQePB/gLYAhFAr4sHXqpFT+qTfELYHM=; b=sIjdA926Gyk9YmhZa1uyxRipN8Qr0qGSHhfmIJkN+oYYfntZg4x9n53FFBHYvaKjTb rbSxa7q0cuAaNlzzgjFuqb3MDRRojM/woJGOvjUg28O9jKyapTzk2rsdRX47/QS29ey1 2TspNE4TaNxXR11oI5lGxksqj2LuMdrXpurBoUeC8+2B9Dq/v55oMrNm0smHqGTOU0Ot 4M+d734LcZvdAns30KodVxnRCCdgO3L2VdkwXGx4MZkaunu3s1GA75J6U4nnPj7dWh/O Wc8kbG7EDUHi9QwsVE2lt+W6+9cPdtpnrHVf3qomEXxJD4k07k91+Q0agj0sgE84Nvk+ b/Uw== X-Gm-Message-State: APjAAAXwsv/dwhsRmaKNg5dm2aCILuBmW3hRyEYGuuPvSU90P1Vk8CYy gTOCXOw/8erqAs+703Bx2X8YVjE1 X-Received: by 2002:a05:651c:282:: with SMTP id b2mr3162824ljo.41.1578496231767; Wed, 08 Jan 2020 07:10:31 -0800 (PST) Received: from [192.168.2.145] (79-139-233-37.dynamic.spd-mgts.ru. [79.139.233.37]) by smtp.googlemail.com with ESMTPSA id r26sm1512029lfm.82.2020.01.08.07.10.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jan 2020 07:10:31 -0800 (PST) Subject: Re: [PATCH v3 09/13] dmaengine: tegra-apb: Remove runtime PM usage To: Jon Hunter , Laxman Dewangan , Vinod Koul , Dan Williams , Thierry Reding , =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Cc: dmaengine@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org References: <20200106011708.7463-1-digetx@gmail.com> <20200106011708.7463-10-digetx@gmail.com> <01660250-0489-870a-6f0e-d74c5041e8e3@nvidia.com> From: Dmitry Osipenko Message-ID: Date: Wed, 8 Jan 2020 18:10:30 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <01660250-0489-870a-6f0e-d74c5041e8e3@nvidia.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 07.01.2020 21:38, Jon Hunter пишет: > > On 07/01/2020 17:12, Dmitry Osipenko wrote: >> 07.01.2020 18:13, Jon Hunter пишет: >>> >>> On 06/01/2020 01:17, Dmitry Osipenko wrote: >>>> There is no benefit from runtime PM usage for the APB DMA driver because >>>> it enables clock at the time of channel's allocation and thus clock stays >>>> enabled all the time in practice, secondly there is benefit from manually >>>> disabled clock because hardware auto-gates it during idle by itself. >>> >>> This assumes that the channel is allocated during a driver >>> initialisation. That may not always be the case. I believe audio is one >>> case where channels are requested at the start of audio playback. >> >> At least serial, I2C, SPI and T20 FUSE are permanently keeping channels >> allocated, thus audio is an exception here. I don't think that it's >> practical to assume that there is a real-world use-case where audio >> driver is the only active DMA client. >> >> The benefits of gating the DMA clock are also dim, do you have any >> power-consumption numbers that show that it's really worth to care about >> the clock-gating? > > No, but at the same time, I really don't see the point in this. In fact, > I think it is a step backwards. If we wanted to only enable clocks while > DMA channels are active we could. So I request you drop this. I'll take a look at making RPM active only during the time of DMA activity, otherwise it's pretty much a dead code as it is now.