devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Georgi Djakov <georgi.djakov@linaro.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: linux-pm@vger.kernel.org, rjw@rjwysocki.net, robh+dt@kernel.org,
	khilman@baylibre.com, mturquette@baylibre.com,
	vincent.guittot@linaro.org, skannan@codeaurora.org,
	sboyd@codeaurora.org, andy.gross@linaro.org,
	seansw@qti.qualcomm.com, davidai@quicinc.com,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org
Subject: Re: [RFC v2 1/3] interconnect: Add generic interconnect controller API
Date: Tue, 13 Jun 2017 17:12:48 +0300	[thread overview]
Message-ID: <b827c5f0-9e28-e14d-a531-83a3559a06c3@linaro.org> (raw)
In-Reply-To: <20170613134200.GA4769@kroah.com>

On 06/13/2017 04:42 PM, Greg KH wrote:
> On Mon, Jun 12, 2017 at 05:13:57PM +0300, Georgi Djakov wrote:
>> This patch 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 using a consumer/provider-based model, where the providers are
>> the interconnect controllers 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.
>>
>> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
>> ---
>>  Documentation/interconnect/interconnect.txt |  65 +++++
>>  drivers/Kconfig                             |   2 +
>>  drivers/Makefile                            |   1 +
>>  drivers/interconnect/Kconfig                |  10 +
>>  drivers/interconnect/Makefile               |   1 +
>>  drivers/interconnect/interconnect.c         | 376 ++++++++++++++++++++++++++++
>>  include/linux/interconnect-consumer.h       |  72 ++++++
>>  include/linux/interconnect-provider.h       | 120 +++++++++
>>  8 files changed, 647 insertions(+)
>>  create mode 100644 Documentation/interconnect/interconnect.txt
>>  create mode 100644 drivers/interconnect/Kconfig
>>  create mode 100644 drivers/interconnect/Makefile
>>  create mode 100644 drivers/interconnect/interconnect.c
>>  create mode 100644 include/linux/interconnect-consumer.h
>>  create mode 100644 include/linux/interconnect-provider.h
>>
>> diff --git a/Documentation/interconnect/interconnect.txt b/Documentation/interconnect/interconnect.txt
>> new file mode 100644
>> index 000000000000..f761a2fb553c
>> --- /dev/null
>> +++ b/Documentation/interconnect/interconnect.txt
> 
> .rst for new Documenation files please, and hook it up to the larger
> documentation build process at the same time.

Ah right, will convert it to rst!

> 
> And why are these RFC patches?  Don't you feel they are ready to be
> reviewed?  I know I ignore RFC patches for the most part as obviously
> the author does not think they are ready :)

I'm trying to raise a discussion around this topic and get more comments
whether this is moving into the right direction and are there any big
concerns left. Its RFC because its not ready to be applied yet, but sure
i will make it a "patch" next time. Reviewing is very welcome!

Thanks,
Georgi

  reply	other threads:[~2017-06-13 14:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-12 14:13 [RFC v2 0/3] Introduce on-chip interconnect API Georgi Djakov
     [not found] ` <20170612141359.26117-1-georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-06-12 14:13   ` [RFC v2 1/3] interconnect: Add generic interconnect controller API Georgi Djakov
2017-06-13 13:42     ` Greg KH
2017-06-13 14:12       ` Georgi Djakov [this message]
2017-06-12 14:13 ` [RFC v2 2/3] interconnect: Add Qualcomm msm8916 interconnect provider driver Georgi Djakov
2017-06-12 14:13 ` [RFC v2 3/3] dt-binding: Interconnect device-tree bindings draft Georgi Djakov

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=b827c5f0-9e28-e14d-a531-83a3559a06c3@linaro.org \
    --to=georgi.djakov@linaro.org \
    --cc=andy.gross@linaro.org \
    --cc=davidai@quicinc.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=khilman@baylibre.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@codeaurora.org \
    --cc=seansw@qti.qualcomm.com \
    --cc=skannan@codeaurora.org \
    --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).