From: Greg KH <gregkh@linuxfoundation.org>
To: Georgi Djakov <georgi.djakov@linaro.org>
Cc: sanjayc@nvidia.com, maxime.ripard@bootlin.com,
mturquette@baylibre.com, daidavid1@codeaurora.org,
bjorn.andersson@linaro.org, skannan@codeaurora.org,
abailon@baylibre.com, vincent.guittot@linaro.org,
seansw@qti.qualcomm.com, khilman@baylibre.com,
evgreen@chromium.org, ksitaraman@nvidia.com,
devicetree@vger.kernel.org, arnd@arndb.de,
linux-pm@vger.kernel.org, linux-arm-msm@vger.kernel.org,
henryc.chen@mediatek.com, andy.gross@linaro.org,
robh+dt@kernel.org, linux-mediatek@lists.infradead.org,
linux-tegra@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
dianders@chromium.org, amit.kucheria@linaro.org,
linux-kernel@vger.kernel.org, thierry.reding@gmail.com,
olof@lixom.net
Subject: Re: [PATCH v13 0/8] Introduce on-chip interconnect API
Date: Tue, 22 Jan 2019 13:42:04 +0100 [thread overview]
Message-ID: <20190122124204.GA26969@kroah.com> (raw)
In-Reply-To: <20190116161103.6937-1-georgi.djakov@linaro.org>
On Wed, Jan 16, 2019 at 06:10:55PM +0200, 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.
>
> The API is using a consumer/provider-based model, where the providers are
> the interconnect buses and the consumers could be various drivers.
> The consumers request interconnect resources (path) to an endpoint and set
> the desired constraints on this data flow path. The provider(s) receive
> requests from consumers and aggregate these requests for all master-slave
> pairs on that path. Then the providers configure each participating in the
> topology node according to the requested data flow path, physical links and
> constraints. The topology could be complicated and multi-tiered and is SoC
> specific.
>
> Below is a simplified diagram of a real-world SoC topology. The interconnect
> providers are the NoCs.
>
> +----------------+ +----------------+
> | HW Accelerator |--->| M NoC |<---------------+
> +----------------+ +----------------+ |
> | | +------------+
> +-----+ +-------------+ V +------+ | |
> | DDR | | +--------+ | PCIe | | |
> +-----+ | | Slaves | +------+ | |
> ^ ^ | +--------+ | | C NoC |
> | | V V | |
> +------------------+ +------------------------+ | | +-----+
> | |-->| |-->| |-->| CPU |
> | |-->| |<--| | +-----+
> | Mem NoC | | S NoC | +------------+
> | |<--| |---------+ |
> | |<--| |<------+ | | +--------+
> +------------------+ +------------------------+ | | +-->| Slaves |
> ^ ^ ^ ^ ^ | | +--------+
> | | | | | | V
> +------+ | +-----+ +-----+ +---------+ +----------------+ +--------+
> | CPUs | | | GPU | | DSP | | Masters |-->| P NoC |-->| Slaves |
> +------+ | +-----+ +-----+ +---------+ +----------------+ +--------+
> |
> +-------+
> | Modem |
> +-------+
>
> It's important to note that the interconnect API, in contrast with devfreq,
> is allowing drivers to express their needs in advance and be proactive.
> Devfreq is using a reactive approach (e.g. monitor performance counters and
> reconfigure bandwidth when the bottleneck had already occurred), which is
> suboptimal and might not work well. The interconnect API is designed to
> deal with multi-tiered bus topologies and aggregating constraints provided
> by drivers, while the devfreq is more oriented towards a device like GPU
> or CPU, that controls the power/performance of itself and not other devices.
>
> Some examples of how interconnect API is used by consumers:
> https://lkml.org/lkml/2018/12/20/811
> https://lkml.org/lkml/2019/1/9/740
> https://lkml.org/lkml/2018/10/11/499
> https://lkml.org/lkml/2018/9/20/986
>
> Platform drivers for different SoCs are available:
> https://lkml.org/lkml/2018/11/17/368
> https://lkml.org/lkml/2018/8/10/380
All now queued up, thanks.
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-01-22 12:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-16 16:10 [PATCH v13 0/8] Introduce on-chip interconnect API Georgi Djakov
2019-01-16 16:10 ` [PATCH v13 1/8] interconnect: Add generic " Georgi Djakov
2019-01-16 16:10 ` [PATCH v13 2/8] dt-bindings: Introduce interconnect binding Georgi Djakov
2019-01-16 16:10 ` [PATCH v13 3/8] interconnect: Allow endpoints translation via DT Georgi Djakov
2019-01-16 16:10 ` [PATCH v13 4/8] interconnect: Add debugfs support Georgi Djakov
2019-01-16 16:11 ` [PATCH v13 5/8] interconnect: qcom: Add sdm845 interconnect provider driver Georgi Djakov
2019-01-16 16:11 ` [PATCH v13 6/8] arm64: dts: sdm845: Add interconnect provider DT nodes Georgi Djakov
2019-01-16 16:11 ` [PATCH v13 7/8] MAINTAINERS: add a maintainer for the interconnect API Georgi Djakov
2019-01-16 16:11 ` [PATCH v13 8/8] interconnect: Revert to previous config if any request fails Georgi Djakov
2019-01-22 12:42 ` Greg KH [this message]
2019-01-22 14:45 ` [PATCH v13 0/8] Introduce on-chip interconnect API Georgi Djakov
2019-01-22 15:00 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190122124204.GA26969@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=abailon@baylibre.com \
--cc=amit.kucheria@linaro.org \
--cc=andy.gross@linaro.org \
--cc=arnd@arndb.de \
--cc=bjorn.andersson@linaro.org \
--cc=daidavid1@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=evgreen@chromium.org \
--cc=georgi.djakov@linaro.org \
--cc=henryc.chen@mediatek.com \
--cc=khilman@baylibre.com \
--cc=ksitaraman@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=maxime.ripard@bootlin.com \
--cc=mturquette@baylibre.com \
--cc=olof@lixom.net \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=sanjayc@nvidia.com \
--cc=seansw@qti.qualcomm.com \
--cc=skannan@codeaurora.org \
--cc=thierry.reding@gmail.com \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).