On Thu, 5 Nov 2020 at 00:44, Dmitry Osipenko <digetx@xxxxxxxxx> wrote: > > Document new DVFS OPP table and voltage regulator properties of the > Host1x bus and devices sitting on the bus. > > Signed-off-by: Dmitry Osipenko <digetx@xxxxxxxxx> > --- > .../display/tegra/nvidia,tegra20-host1x.txt | 56 +++++++++++++++++++ > 1 file changed, 56 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt > index 34d993338453..0593c8df70bb 100644 > --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt > @@ -20,6 +20,18 @@ Required properties: > - reset-names: Must include the following entries: > - host1x > > +Optional properties: > +- operating-points-v2: See ../bindings/opp/opp.txt for details. > +- core-supply: Phandle of voltage regulator of the SoC "core" power domain. > + > +For each opp entry in 'operating-points-v2' table of host1x and its modules: > +- opp-supported-hw: One bitfield indicating: > + On Tegra20: SoC process ID mask > + On Tegra30+: SoC speedo ID mask > + > + A bitwise AND is performed against the value and if any bit > + matches, the OPP gets enabled. > + > Each host1x client module having to perform DMA through the Memory Controller > should have the interconnect endpoints set to the Memory Client and External > Memory respectively. > @@ -45,6 +57,8 @@ of the following host1x client modules: > - interconnect-names: Must include name of the interconnect path for each > interconnect entry. Consult TRM documentation for information about > available memory clients, see MEMORY CONTROLLER section. > + - core-supply: Phandle of voltage regulator of the SoC "core" power domain. > + - operating-points-v2: See ../bindings/opp/opp.txt for details. > As discussed in the thread for the cover-letter. We already have DT bindings for power-domains (providers and consumers). Please use them instead of adding SoC specific bindings to each peripheral device. [...] Kind regards Uffe _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
