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@xxxxxxxxxx> 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. thanks, greg k-h
