From mboxrd@z Thu Jan 1 00:00:00 1970 From: Georgi Djakov Subject: Re: [PATCH v10 0/8] Introduce on-chip interconnect API Date: Fri, 7 Dec 2018 12:06:21 +0200 Message-ID: References: <20181127180349.29997-1-georgi.djakov@linaro.org> <20181206145547.GA7884@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20181206145547.GA7884@kroah.com> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Greg KH , Evan Green Cc: linux-pm@vger.kernel.org, rjw@rjwysocki.net, robh+dt@kernel.org, Michael Turquette , khilman@baylibre.com, Vincent Guittot , Saravana Kannan , Bjorn Andersson , amit.kucheria@linaro.org, seansw@qti.qualcomm.com, daidavid1@codeaurora.org, mark.rutland@arm.com, lorenzo.pieralisi@arm.com, Alexandre Bailon , maxime.ripard@bootlin.com, Arnd Bergmann , Thierry Reding , ksitaraman@nvidia.com, sanjayc@nvidia.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-tegra@vger.kernel.org, Doug Anderson List-Id: linux-arm-msm@vger.kernel.org Hi Greg and Evan, On 12/6/18 16:55, Greg KH wrote: > On Wed, Dec 05, 2018 at 12:41:35PM -0800, Evan Green wrote: >> On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov wrote: >>> >>> Modern SoCs have multiple processors and various dedicated cores (video, gpu, >>> graphics, modem). These cores are talking to each other and can generate a >>> lot of data flowing through the on-chip interconnects. These interconnect >>> buses could form different topologies such as crossbar, point to point buses, >>> hierarchical buses or use the network-on-chip concept. >>> >>> These buses have been sized usually to handle use cases with high data >>> throughput but it is not necessary all the time and consume a lot of power. >>> Furthermore, the priority between masters can vary depending on the running >>> use case like video playback or CPU intensive tasks. >>> >>> Having an API to control the requirement of the system in terms of bandwidth >>> and QoS, so we can adapt the interconnect configuration to match those by >>> scaling the frequencies, setting link priority and tuning QoS parameters. >>> This configuration can be a static, one-time operation done at boot for some >>> platforms or a dynamic set of operations that happen at run-time. >>> >>> This patchset introduce a new API to get the requirement and configure the >>> interconnect buses across the entire chipset to fit with the current demand. >>> The API is NOT for changing the performance of the endpoint devices, but only >>> the interconnect path in between them. >> >> For what it's worth, we are ready to land this in Chrome OS. I think >> this series has been very well discussed and reviewed, hasn't changed >> much in the last few spins, and is in good enough shape to use as a >> base for future patches. Georgi's also done a great job reaching out >> to other SoC vendors, and there appears to be enough consensus that >> this framework will be usable by more than just Qualcomm. There are >> also several drivers out on the list trying to add patches to use this >> framework, with more to come, so it made sense (to us) to get this >> base framework nailed down. In my experiments this is an important >> piece of the overall power management story, especially on systems >> that are mostly idle. >> >> I'll continue to track changes to this series and we will ultimately >> reconcile with whatever happens upstream, but I thought it was worth >> sending this note to express our "thumbs up" towards this framework. > > Looks like a v11 will be forthcoming, so I'll wait for that one to apply > it to the tree if all looks good. > Yes, it's coming. I will also include an additional fixup patch, as the sdm845 provider driver will fail to build in linux-next, due to a recent change in the cmd_db API. Thanks, Georgi