linux-kernel - Re: [PATCH v3 09/13] dmaengine: tegra-apb: Remove runtime PM usage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20200110080510.GH2818@vkoul-mobl>
Date:   Fri, 10 Jan 2020 13:35:10 +0530
From:   Vinod Koul <vkoul@...nel.org>
To:     Jon Hunter <jonathanh@...dia.com>
Cc:     Dmitry Osipenko <digetx@...il.com>,
        Laxman Dewangan <ldewangan@...dia.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Michał Mirosław <mirq-linux@...e.qmqm.pl>,
        dmaengine@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 09/13] dmaengine: tegra-apb: Remove runtime PM usage

On 07-01-20, 18:38, Jon Hunter wrote:
> 
> 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.

Agree, if pm is working fine with audio, doesnt make much sense to
remove. Future clients or updates to existing clients can be done to
make it dynamic..

-- 
~Vinod