[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0d42e370-4c1e-13a1-9a5a-f8ae00d8512d@gmail.com>
Date: Sat, 23 Oct 2021 16:46:01 +0300
From: Dmitry Osipenko <digetx@...il.com>
To: Viresh Kumar <viresh.kumar@...aro.org>,
Rob Herring <robh@...nel.org>
Cc: Viresh Kumar <vireshk@...nel.org>, Stephen Boyd <sboyd@...nel.org>,
Nishanth Menon <nm@...com>, David Heidelberg <david@...t.cz>,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH v1] dt-bindings: opp: Allow multi-worded node names
23.10.2021 16:00, Dmitry Osipenko пишет:
> 22.10.2021 10:45, Viresh Kumar пишет:
>> On 22-10-21, 10:39, Dmitry Osipenko wrote:
>>> What we currently have for Tegra is a tegra-opps.dtsi and tegra.dtsi
>>> which includes the OPP's dtsi.
>>>
>>> the tegra-opps.dtsi has this structure:
>>>
>>> table: devname-opp-table {
>>> opp: ...
>>> };
>>>
>>> and tegra.dtsi:
>>>
>>> #include "tegra-opps.dtsi"
>>>
>>> device@...0 {
>>> operating-points-v2 = <&table>;
>>> };
>>>
>>> It just occurred to me that there is no need to move all tables to
>>> tegra.dtsi, but change structure of tegra-opps.dtsi to:
>>>
>>> device@...0 {
>>> operating-points-v2 = <&table>;
>>>
>>> table: opp-table {
>>> opp: ...
>>> };
>>> };
>>
>> I thought you would have already thought about that and I was surprised when you
>> saw the tables are big enough to be moved. I was wondering what does it really
>> mean :)
>>
>>> Then there no need to change current naming scheme. Let me try to
>>> implement it and see how it goes.
>>
>> That's good then.
>>
>
> I implemented that approach and it works, but there are two problems:
>
> 1. I had to factor out OPP tables from SPI device-tree nodes because DTC doesn't allow to have them within SPI nodes [1] and dtb fails to compile.
>
> [1] https://elixir.bootlin.com/linux/v5.15-rc6/source/scripts/dtc/checks.c#L1141
>
> 2. dtbs_check now warns about every opp-table sub-node, like this:
>
> /home/runner/work/linux/linux/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-E1565.dt.yaml: memory-controller@...0f400: 'opp-table' does not match any of the regexes: '^emc-timings-[0-9]+$', 'pinctrl-[0-9]+'
> From schema: /home/runner/work/linux/linux/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
>
Thinking more about this, it's not a good idea to add new sub-node to
nodes which already have sub-nodes because existing driver code that
parses sub-nodes may not be ready to face the new opp-table sub-node.
I'll revert back to the previous variant with distinct opp-table nodes.
Powered by blists - more mailing lists