Date:   Fri, 7 Dec 2018 12:06:21 +0200
From:   Georgi Djakov <georgi.djakov@...aro.org>
To:     Greg KH <gregkh@...uxfoundation.org>,
        Evan Green <evgreen@...omium.org>
Cc:     linux-pm@...r.kernel.org, rjw@...ysocki.net, robh+dt@...nel.org,
        Michael Turquette <mturquette@...libre.com>,
        khilman@...libre.com, Vincent Guittot <vincent.guittot@...aro.org>,
        Saravana Kannan <skannan@...eaurora.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        amit.kucheria@...aro.org, seansw@....qualcomm.com,
        daidavid1@...eaurora.org, mark.rutland@....com,
        lorenzo.pieralisi@....com, Alexandre Bailon <abailon@...libre.com>,
        maxime.ripard@...tlin.com, Arnd Bergmann <arnd@...db.de>,
        Thierry Reding <thierry.reding@...il.com>,
        ksitaraman@...dia.com, sanjayc@...dia.com,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-arm-msm@...r.kernel.org, linux-tegra@...r.kernel.org,
        Doug Anderson <dianders@...omium.org>
Subject: Re: [PATCH v10 0/8] Introduce on-chip interconnect API

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 <georgi.djakov@...aro.org> 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

Powered by blists - more mailing lists