From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Rob Herring <robh@kernel.org>, georgi.djakov@linaro.org
Cc: cw00.choi@samsung.com, krzk@kernel.org,
devicetree@vger.kernel.org, a.swigon@samsung.com,
myungjoo.ham@samsung.com, inki.dae@samsung.com,
sw0312.kim@samsung.com, b.zolnierkie@samsung.com,
m.szyprowski@samsung.com, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC v6 1/6] dt-bindings: exynos-bus: Add documentation for interconnect properties
Date: Thu, 30 Jul 2020 14:28:18 +0200 [thread overview]
Message-ID: <65af1a5c-8f8a-ef65-07f8-e0b3d04c336c@samsung.com> (raw)
In-Reply-To: <20200709210448.GA876103@bogus>
On 09.07.2020 23:04, Rob Herring wrote:
> On Thu, Jul 02, 2020 at 06:37:19PM +0200, Sylwester Nawrocki wrote:
>> Add documentation for new optional properties in the exynos bus nodes:
>> samsung,interconnect-parent, #interconnect-cells, bus-width.
>> These properties allow to specify the SoC interconnect structure which
>> then allows the interconnect consumer devices to request specific
>> bandwidth requirements.
>>
>> Signed-off-by: Artur Świgoń <a.swigon@samsung.com>
>> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>> ---
>> .../devicetree/bindings/devfreq/exynos-bus.txt | 68 +++++++++++++++++++++-
>> 1 file changed, 66 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> index e71f752..4035e3e 100644
>> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> @@ -51,6 +51,13 @@ Optional properties only for parent bus device:
>> - exynos,saturation-ratio: the percentage value which is used to calibrate
>> the performance count against total cycle count.
>>
>> +Optional properties for interconnect functionality (QoS frequency constraints):
>> +- samsung,interconnect-parent: phandle to the parent interconnect node; for
>> + passive devices should point to same node as the exynos,parent-bus property.
>
> Adding vendor specific properties for a common binding defeats the
> point.
Should we make it then a common interconnect-parent property? Perhaps allowing
also a second cell after the phandle to indicate the target interconnect id?
Currently the links are only being defined in drivers, I'm not sure if we want
to go that direction and extend the interconnect binding so it is possible
to define any link between the nodes.
With the samsung,interconnect-parent property there was an assumption that
each DT node ("samsung,exynos-bus" compatible) corresponds to an interconnect
provider with single interconnect node. The source and destination node id
for the link were unspecified and dynamically allocated by the driver.
I guess we don't want a property that would contain pairs of the interconnect
node specifiers (phandle + interconnect id) to define all links, since usually
additional data is required per each link.
Then perhaps we could make the new interconnect-parent property applicable
only to DT nodes with #interconnect-cells == 0, i.e. valid only in such DT
nodes?
>> +- #interconnect-cells: should be 0.
>> +- bus-width: the interconnect bus width in bits, default value is 8 when this
>> + property is missing.
>
> Your bus is 8-bits or 4-bits as the example?
Bus width might not be a good term for the intended purpose of that property.
It has been added to specify minimum bus clock rate required for given data
throughput. After checking the documentation again the AXI bus width is
actually 128 bits everywhere for instance. The example defines data path
leftbus <- dmc <- (memory) and for leftbus we have bus-width=<8> and for dmc
bus-width=<4>.
Perhaps it's better to use a vendor specific property instead, e.g.
samsung, data-clock-ratio?
--
Thanks,
Sylwester
next prev parent reply other threads:[~2020-07-30 12:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20200702163746eucas1p2363251b3b6fb6084123cedd67fa132d5@eucas1p2.samsung.com>
2020-07-02 16:37 ` [PATCH RFC v6 0/6] Exynos: Simple QoS for exynos-bus using interconnect Sylwester Nawrocki
[not found] ` <CGME20200702163748eucas1p2cf7eab70bc072dea9a95183018b38ad3@eucas1p2.samsung.com>
2020-07-02 16:37 ` [PATCH RFC v6 1/6] dt-bindings: exynos-bus: Add documentation for interconnect properties Sylwester Nawrocki
2020-07-03 0:47 ` Chanwoo Choi
2020-07-09 21:04 ` Rob Herring
2020-07-30 12:28 ` Sylwester Nawrocki [this message]
2020-08-28 14:49 ` Sylwester Nawrocki
2020-09-09 9:07 ` Georgi Djakov
2020-09-09 14:47 ` Sylwester Nawrocki
2020-09-15 21:40 ` Georgi Djakov
2020-10-30 12:29 ` Sylwester Nawrocki
[not found] ` <CGME20200702163753eucas1p16fbd5d59d05fb8e4fdcde9df839cb71e@eucas1p1.samsung.com>
2020-07-02 16:37 ` [PATCH RFC v6 2/6] interconnect: Add generic interconnect driver for Exynos SoCs Sylwester Nawrocki
[not found] ` <CGME20200702163754eucas1p2bbe44897234a3e39dcd10b23e536a927@eucas1p2.samsung.com>
2020-07-02 16:37 ` [PATCH RFC v6 3/6] PM / devfreq: exynos-bus: Add registration of interconnect child device Sylwester Nawrocki
[not found] ` <CGME20200702163756eucas1p282c6bc5a61f8dd7b6a5d59d92e92e2f1@eucas1p2.samsung.com>
2020-07-02 16:37 ` [PATCH RFC v6 4/6] ARM: dts: exynos: Add interconnect properties to Exynos4412 bus nodes Sylwester Nawrocki
[not found] ` <CGME20200702163758eucas1p1e18d95f3dce34df1f4334da5462a04a2@eucas1p1.samsung.com>
2020-07-02 16:37 ` [PATCH RFC v6 5/6] ARM: dts: exynos: Add interconnects to Exynos4412 mixer Sylwester Nawrocki
[not found] ` <CGME20200702163801eucas1p12db276c7ac9e244e93e4b2f3d33ba729@eucas1p1.samsung.com>
2020-07-02 16:37 ` [PATCH RFC v6 6/6] drm: exynos: mixer: Add interconnect support Sylwester Nawrocki
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=65af1a5c-8f8a-ef65-07f8-e0b3d04c336c@samsung.com \
--to=s.nawrocki@samsung.com \
--cc=a.swigon@samsung.com \
--cc=b.zolnierkie@samsung.com \
--cc=cw00.choi@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=georgi.djakov@linaro.org \
--cc=inki.dae@samsung.com \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=myungjoo.ham@samsung.com \
--cc=robh@kernel.org \
--cc=sw0312.kim@samsung.com \
/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).