Hi Sylwester,
On 8/28/20 17:49, Sylwester Nawrocki wrote:
> On 30.07.2020 14:28, Sylwester Nawrocki wrote:
>> 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.swi...@samsung.com>
>>>> Signed-off-by: Sylwester Nawrocki <s.nawro...@samsung.com>
>
>>>> --- 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.
>
> Actually we could do without any new property if we used existing interconnect
> consumers binding to specify linking between the provider nodes. I think those
> exynos-bus nodes could well be considered both the interconnect providers
> and consumers. The example would then be something along the lines
> (yes, I know the bus node naming needs to be fixed):
>
> soc {
> bus_dmc: bus_dmc {
> compatible = "samsung,exynos-bus";
> /* ... */
> samsung,data-clock-ratio = <4>;
> #interconnect-cells = <0>;
> };
>
> bus_leftbus: bus_leftbus {
> compatible = "samsung,exynos-bus";
> /* ... */
> interconnects = <&bus_leftbus &bus_dmc>;
> #interconnect-cells = <0>;
> };
>
> bus_display: bus_display {
> compatible = "samsung,exynos-bus";
> /* ... */
> interconnects = <&bus_display &bus_leftbus>;
Hmm, bus_display being a consumer of itself is a bit odd? Did you mean:
interconnects = <&bus_dmc &bus_leftbus>;
> #interconnect-cells = <0>;
> };
>
>
> &mixer {
> compatible = "samsung,exynos4212-mixer";
> interconnects = <&bus_display &bus_dmc>;
> /* ... */
> };
> };
>
> What do you think, Georgi, Rob?
I can't understand the above example with bus_display being it's own consumer.
This seems strange to me. Could you please clarify it?
Otherwise the interconnect consumer DT bindings are already well established
and i don't see anything preventing a node to be both consumer and provider.
So this should be okay in general.
Thanks,
Georgi
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
