* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-04-20 9:33 UTC (permalink / raw)
To: Ulf Hansson
Cc: Sudeep Holla, Rafael Wysocki, Kevin Hilman, Viresh Kumar,
Nishanth Menon, Stephen Boyd, linaro-kernel,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
Vincent Guittot, Rob Herring, Lina Iyer, Rajendra Nayak,
devicetree@vger.kernel.org
In-Reply-To: <CAPDyKFq5xwv5Vy6wNfjFYi_4+immDH9UKTS1EG2j6c4OwnQONg@mail.gmail.com>
On 20-04-17, 10:23, Ulf Hansson wrote:
> Viresh, Sudeep,
>
> Sorry for jumping in late.
>
> [...]
>
> >> On the contrary(playing devil's advocate here), we can treat all
> >> existing regulators alone as OPP then if you strip the voltages and
> >> treat it as abstract number.
> >
> > But then we are going to have lots of platform specific code which
> > will program the actual hardware, etc. Which is all handled by the
> > regulator framework. Also note that the regulator core selects the
> > common voltage selected by all the children, while we want to select
> > the highest performance point here.
>
> If I understand correctly, Sudeep is not convinced that this is about
> PM domain regulator(s), right?
>
> To me there is no doubt, these regulators is exactly the definition of
> PM domain regulators.
>
> That said, long time ago we have decided PM domain regulator shall be
> modeled as exactly that. From DT point of view, this means the handle
> to the PM domain regulator belongs in the node of the PM domain
> controller - and not in each device's node of those belonging to the
> PM domain.
>
> Isn't that what this discussion really boils down to? Or maybe I am
> not getting it.
Maybe not. I think Sudeep understands that this is about PM domain
regulators only but he is asking why aren't we solving this problem
using regulators framework but performance-levels instead.
> >
> > Even if we have to configure both clock and voltage for the power
> > domain using standard clk/regulator frameworks, OPP will work just
> > fine as it will do that then. So, its not that we are bypassing the
> > regulator framework here. It will be used if we have the voltages
> > available for the power-domain's performance states.
> >
> >> So if the firmware handles more than just
> >> regulators, I agree.
> >
> > I don't know the internals of that really.
> >
> >> At the same time, I would have preferred firmware
> >> to even abstract the frequency like ACPI CPPC.
> >
> > Frequency isn't required to be configured for the cases I know, but it
> > can be in future implementations.
>
> To me using OPP tables makes sense as it gives us the flexibility that
> is needed. If I understand correct, that was also Kevin's point.
Right.
--
viresh
^ permalink raw reply
* Re: [PATCH V4 5/7] ARM: sun8i: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 9:29 UTC (permalink / raw)
To: Maxime Ripard
Cc: arm-DgEjT+Ai2ygdnm+yROfE0A, Rob Herring, Mark Rutland,
Chen-Yu Tsai, linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Rafael Wysocki,
Krzysztof Kozlowski, Masahiro Yamada, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170420080202.olu2mhel6xtmnnjt@lukather>
On 20-04-17, 10:02, Maxime Ripard wrote:
> Hi,
>
> On Thu, Apr 20, 2017 at 11:14:16AM +0530, Viresh Kumar wrote:
> > Compiling the DT file with W=1, DTC warns like follows:
> >
> > Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> > unit name, but no reg property
> >
> > Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > "reg" property.
> >
> > Reported-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Reported-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> > Suggested-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> > Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> This patch doesn't apply, please make sure to base them on linux-next
I can do that tomorrow once linux-next includes the new PM tree as the
old PM tree had my patch from V3.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 4/4] arm64: dts: salvator-x: Add current sense amplifiers
From: Simon Horman @ 2017-04-20 9:16 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jacopo Mondi, Wolfram Sang, Magnus Damm, Laurent Pinchart,
Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald, Rob Herring, Mark Rutland, linux-iio,
Linux-Renesas, devicetree@vger.kernel.org
In-Reply-To: <CAMuHMdXkixLn9xdnrhEXW9pCg-4WjOuoPdyxXYeBwRfetMSYsA@mail.gmail.com>
On Wed, Apr 19, 2017 at 10:40:21AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Thu, Apr 6, 2017 at 4:20 PM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> > [PATCH v5 4/4] arm64: dts: salvator-x: Add current sense amplifiers
>
> This should be "arm64: dts: r8a7796: salvator-x: Add current sense amplifiers".
> Perhaps Simon can just fix that himself while applying?
Done :)
^ permalink raw reply
* Re: [PATCH 0/3] Add R8A7743/SK-RZG1M PFC support
From: Simon Horman @ 2017-04-20 8:52 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Mark Rutland, devicetree, Magnus Damm, Russell King,
linux-renesas-soc, Rob Herring, linux-arm-kernel
In-Reply-To: <20170414210941.143838720@cogentembedded.com>
On Sat, Apr 15, 2017 at 12:09:41AM +0300, Sergei Shtylyov wrote:
> Hello.
>
> Here's the set of 3 patches against Simon Horman's 'renesas.git' repo,
> 'renesas-devel-20170410-v4.11-rc6' tag. We're adding the R8A7743 PFC node and
> then describe the pins for SCIF0 and Ether devices described eralier. These
> patches depend on the R8A7743 PFC suport in order to work properly.
>
> [1/3] ARM: dts: r8a7743: add PFC support
> [2/3] ARM: dts: sk-rzg1m: add SCIF0 pins
> [3/3] ARM: dts: sk-rzg1m: add Ether pins
These look good to me. Please repost me or ping me once the prerequisites
have been accepted. Likewise for the similar patchset for the R8A7745/SK-RZG1E.
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dts: r8a7743: add PFC support
From: Simon Horman @ 2017-04-20 8:51 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Rob Herring, Mark Rutland, linux-renesas-soc, devicetree,
Magnus Damm, Russell King, linux-arm-kernel
In-Reply-To: <20170414211505.733692280@cogentembedded.com>
On Sat, Apr 15, 2017 at 12:09:42AM +0300, Sergei Shtylyov wrote:
> Define the generic R8A7743 part of the PFC device node.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> arch/arm/boot/dts/r8a7743.dtsi | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
> ===================================================================
> --- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
> +++ renesas/arch/arm/boot/dts/r8a7743.dtsi
> @@ -1,7 +1,7 @@
> /*
> * Device Tree Source for the r8a7743 SoC
> *
> - * Copyright (C) 2016 Cogent Embedded Inc.
> + * Copyright (C) 2016-2017 Cogent Embedded Inc.
> *
> * This file is licensed under the terms of the GNU General Public License
> * version 2. This program is licensed "as is" without any warranty of any
> @@ -123,6 +123,11 @@
> #power-domain-cells = <1>;
> };
>
> + pfc: pin-controller@e6060000 {
> + compatible = "renesas,pfc-r8a7743";
> + reg = <0 0xe6060000 0 0x250>;
> + };
> +
I am curious to know why pin-controller was chosen rather than pfc which
is dominant in the DT for Renesas SoCs. And as a follow-up question, do
you think it would be worth creating patches to make this uniform
across the DT for Renesas SoCs.
> dmac0: dma-controller@e6700000 {
> compatible = "renesas,dmac-r8a7743",
> "renesas,rcar-dmac";
>
^ permalink raw reply
* Re: [PATCH v4 06/11] drm/sun4i: add support for Allwinner DE2 mixers
From: Maxime Ripard @ 2017-04-20 8:37 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Jernej Skrabec, David Airlie,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Chen-Yu Tsai,
Rob Herring, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <88F5FAC9-1873-4C76-9AB9-FF361C07664E-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]
On Tue, Apr 18, 2017 at 06:47:56PM +0800, Icenowy Zheng wrote:
> >> + /* Get the physical address of the buffer in memory */
> >> + gem = drm_fb_cma_get_gem_obj(fb, 0);
> >> +
> >> + DRM_DEBUG_DRIVER("Using GEM @ %pad\n", &gem->paddr);
> >> +
> >> + /* Compute the start of the displayed memory */
> >> + bpp = fb->format->cpp[0];
> >> + paddr = gem->paddr + fb->offsets[0];
> >> + paddr += (state->src_x >> 16) * bpp;
> >> + paddr += (state->src_y >> 16) * fb->pitches[0];
> >> +
> >> + DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
> >> +
> >> + paddr_u32 = (uint32_t) paddr;
> >
> >How does that work on 64-bits systems ?
>
> The hardware is not designed to work on 64-bit systems.
>
> Even 64-bit A64/H5 has also 3GiB memory limit.
That's a fragile assumption.
> The address cell in mixer hardware is also only 32-bit.
>
> So we should just keep the force conversion here. If we then really
> met 4GiB-capable AW SoC without changing DE2, I think we should have
> other way to limit CMA pool inside 4GiB.
The register name looks like this is only the lower 32 bits that you
can set here, and that there is another register for the upper 32 bits
of that address somewhere.
In that case, please use the lower_32_bits and upper_32_bits helper,
and don't cast it that way.
If it isn't the case, you should set the DMA mask (through
dma_set_mask) so that we only allocate memory that can be accessed by
this device.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Ulf Hansson @ 2017-04-20 8:23 UTC (permalink / raw)
To: Viresh Kumar, Sudeep Holla
Cc: Rafael Wysocki, Kevin Hilman, Viresh Kumar, Nishanth Menon,
Stephen Boyd, linaro-kernel, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, Vincent Guittot, Rob Herring,
Lina Iyer, Rajendra Nayak, devicetree@vger.kernel.org
In-Reply-To: <20170420052533.GF5436@vireshk-i7>
Viresh, Sudeep,
Sorry for jumping in late.
[...]
>> On the contrary(playing devil's advocate here), we can treat all
>> existing regulators alone as OPP then if you strip the voltages and
>> treat it as abstract number.
>
> But then we are going to have lots of platform specific code which
> will program the actual hardware, etc. Which is all handled by the
> regulator framework. Also note that the regulator core selects the
> common voltage selected by all the children, while we want to select
> the highest performance point here.
If I understand correctly, Sudeep is not convinced that this is about
PM domain regulator(s), right?
To me there is no doubt, these regulators is exactly the definition of
PM domain regulators.
That said, long time ago we have decided PM domain regulator shall be
modeled as exactly that. From DT point of view, this means the handle
to the PM domain regulator belongs in the node of the PM domain
controller - and not in each device's node of those belonging to the
PM domain.
Isn't that what this discussion really boils down to? Or maybe I am
not getting it.
>
> Even if we have to configure both clock and voltage for the power
> domain using standard clk/regulator frameworks, OPP will work just
> fine as it will do that then. So, its not that we are bypassing the
> regulator framework here. It will be used if we have the voltages
> available for the power-domain's performance states.
>
>> So if the firmware handles more than just
>> regulators, I agree.
>
> I don't know the internals of that really.
>
>> At the same time, I would have preferred firmware
>> to even abstract the frequency like ACPI CPPC.
>
> Frequency isn't required to be configured for the cases I know, but it
> can be in future implementations.
To me using OPP tables makes sense as it gives us the flexibility that
is needed. If I understand correct, that was also Kevin's point.
[...]
Kind regards
Uffe
^ permalink raw reply
* Re: [RFC 1/2] dt-bindings: add mmio-based syscon mux controller DT bindings
From: Philipp Zabel @ 2017-04-20 8:14 UTC (permalink / raw)
To: Rob Herring
Cc: Peter Rosin, Mark Rutland, Sakari Ailus, Steve Longerbeam,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <20170419220900.ndrtt2m7d6tqsddh@rob-hp-laptop>
Hi Rob,
On Wed, 2017-04-19 at 17:09 -0500, Rob Herring wrote:
> On Thu, Apr 13, 2017 at 05:48:11PM +0200, Philipp Zabel wrote:
> > This adds device tree binding documentation for mmio-based syscon
> > multiplexers controlled by a single bitfield in a syscon register
> > range.
> >
> > Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > ---
> > Documentation/devicetree/bindings/mux/mmio-mux.txt | 56 ++++++++++++++++++++++
> > 1 file changed, 56 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mux/mmio-mux.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mux/mmio-mux.txt b/Documentation/devicetree/bindings/mux/mmio-mux.txt
> > new file mode 100644
> > index 0000000000000..11d96f5d98583
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mux/mmio-mux.txt
> > @@ -0,0 +1,56 @@
> > +MMIO bitfield-based multiplexer controller bindings
> > +
> > +Define a syscon bitfield to be used to control a multiplexer. The parent
> > +device tree node must be a syscon node to provide register access.
> > +
> > +Required properties:
> > +- compatible : "gpio-mux"
>
> ?
>
> > +- reg : register base of the register containing the control bitfield
> > +- bit-mask : bitmask of the control bitfield in the control register
> > +- bit-shift : bit offset of the control bitfield in the control register
> > +- #mux-control-cells : <0>
> > +* Standard mux-controller bindings as decribed in mux-controller.txt
> > +
> > +Optional properties:
> > +- idle-state : if present, the state the mux will have when idle. The
> > + special state MUX_IDLE_AS_IS is the default.
> > +
> > +The multiplexer state is defined as the value of the bitfield described
> > +by the reg, bit-mask, and bit-shift properties, accessed through the parent
> > +syscon.
> > +
> > +Example:
> > +
> > + syscon {
> > + compatible = "syscon";
> > +
> > + mux: mux-controller@3 {
> > + compatible = "mmio-mux";
> > + reg = <0x3>;
> > + bit-mask = <0x1>;
> > + bit-shift = <5>;
>
> This pattern doesn't scale once you have multiple fields @ addr 3. I
> also don't really think a node per register field in DT really scales.
Thanks, I have been a bit uneasy with the separate per-bitfield mux
controller node, so I'm eager to agree. But thit makes me unsure how to
best represent the information that is spelled out above.
> I think the parent should be declared as a mux controller instead.
The syscon node itself should be the mux controller? Would you expect
the mmio-mux driver bind to the syscon node, or should the mux framework
handle creation of the mux controls in this case (i.e. does the syscon
node get a "mmio-mux" added to its compatible list)?
> You could encode the mux addr and bit position in the mux cells.
What about the bit-mask / bitfield width? Just add a cell for it?
gpr: syscon {
compatible = "mmio-mux", "syscon", "simple-mfd";
#mux-control-cells = <3>;
video-mux {
compatible = "video-mux";
/* register 0x3, bits [6:5] */
mux-controls = <&gpr 0x3 5 0x3>;
ports {
/* ports 0..5 */
};
};
};
Or maybe using MSB and LSB would be better to read?
video-mux {
/* register 0x3, bits [6:5] */
mux-control = <&gpr 0x3 6 5>;
ports {
/* ports 0..5 */
};
};
> > + #mux-control-cells = <0>;
> > + };
> > + };
> > +
> > + video-mux {
> > + compatible = "video-mux";
> > + mux-controls = <&mux>;
>
> The mux binding was largely defined for a single control controling
> multiple muxes. This doesn't really fit that, but I guess this is an
> improvement over a custom syscon phandle.
What I especially like about the mux-controls property is that would
allow me to use the gpio-mux driver (or any other mux controller)
instead of having to code variants of the video-mux for all possible
control schemes.
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V4 5/7] ARM: sun8i: Use - instead of @ for DT OPP entries
From: Maxime Ripard @ 2017-04-20 8:02 UTC (permalink / raw)
To: Viresh Kumar
Cc: arm, Rob Herring, Mark Rutland, Chen-Yu Tsai, linaro-kernel,
linux-arm-kernel, linux-pm, Rafael Wysocki, Krzysztof Kozlowski,
Masahiro Yamada, Rob Herring, devicetree, linux-kernel
In-Reply-To: <d13e447e9cc080d81c4f2db3bd5433506d3ef739.1492666725.git.viresh.kumar@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 859 bytes --]
Hi,
On Thu, Apr 20, 2017 at 11:14:16AM +0530, Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
>
> Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Acked-by: Rob Herring <robh@kernel.org>
This patch doesn't apply, please make sure to base them on linux-next
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Re: [PATCH 2/8] ARM: sun4i: Add display blocks for the sun4i dtsi.
From: Philippe Fouquet @ 2017-04-20 7:23 UTC (permalink / raw)
To: linux-sunxi
Cc: wens-jdAy2FN1RRM, maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
net147-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, airlied-cv59FeDIM0c,
quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <1487004405.20308.3.camel-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 3170 bytes --]
Hi
If you want I work with a Allwinner A20 (my board are derived from
OlinuXino-Micro-A20), and I will interest with LVDS function.
I use your patch but I have nothing to display on my screen.
You can see my work on
https://github.com/Philippe12/linux-sunxi/tree/sun7i-A20-lvds
My hardware is good, it word with u-boot and a older kernel 3.4.104
I use a dlc screen (dlc0700DDG-T-11) my fault is probably on simple-panel
information but I didn't seen were
If you can tell me some things to check.
Thank for your help
Best regards
Philippe FOUQUET
Le lundi 13 février 2017 17:46:48 UTC+1, Priit Laes a écrit :
>
> On Mon, 2017-02-13 at 17:20 +0800, Chen-Yu Tsai wrote:
> > On Mon, Feb 13, 2017 at 5:16 PM, Maxime Ripard
> > <maxime...-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org <javascript:>> wrote:
> > > Hi,
> > >
> > > On Sat, Feb 11, 2017 at 07:43:59PM +0200, Priit Laes wrote:
> > > > Added basic display pipeline consisting of tcon, display backend
> > > > and
> > > > frontend blocks.
> > > >
> > > > Signed-off-by: Priit Laes <pl...-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org <javascript:>>
> > > > ---
> > > > arch/arm/boot/dts/sun4i-a10.dtsi | 104
> > > > +++++++++++++++++++++++++++++++++++++++
> > > > 1 file changed, 104 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi
> > > > b/arch/arm/boot/dts/sun4i-a10.dtsi
> > > > index ba20b48..70991c9 100644
> > > > --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> > > > +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> > > > @@ -779,6 +779,45 @@
> > > > #size-cells = <0>;
> > > > };
> > > >
> > > > + tcon0: lcd-controller@1c0c000 {
> > > > + compatible = "allwinner,sun5i-a13-tcon";
> > >
> > > There's a few bits here and there that need to be setup differently
> > > in
> > > A10, so you cannot reuse that compatible (same thing for the
> > > other).
> > >
> > > Also, I'd really like to have all the blocks listed here, and not
> > > only
> > > the first pipeline. Ideally, on the A10, the two pipelines should
> > > be
> > > enabled too.
> >
> > The display pipeline driver has to be fixed before that can happen
> > though. And I haven't started to work on what I proposed yet. Though
> > if someone wants to take over I can forward any design plans I have.
>
> Well, my plan was to get at least minimum bits mainlined and then build
> additional features on top.
>
> Wens, it would be cool though, if you could share your plans.
>
> Unfortunately I have only single A10 device (with LVDS and mini-HDMI)
> but I don't actually have other LVDS-displays I could easily use with
> A20 devices (I have CubieTruck and A20-Olinuxino Micro).
>
> Päikest,
> Priit :)
>
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #1.2: Type: text/html, Size: 4597 bytes --]
^ permalink raw reply
* Re: Re: [PATCH v3 02/12] arm64: allwinner: a64: add NMI controller on A64
From: icenowy-h8G6r0blFSE @ 2017-04-20 7:03 UTC (permalink / raw)
To: maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
Cc: Lee Jones, Rob Herring, Chen-Yu Tsai, Liam Girdwood, Mark Brown,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170420055802.btibui5pspan4qal@lukather>
在 2017-04-20 13:58，Maxime Ripard 写道：
> On Tue, Apr 18, 2017 at 06:56:43PM +0800, Icenowy Zheng wrote:
>>
>>
>> 于 2017年4月18日 GMT+08:00 下午3:00:16, Maxime Ripard
>> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> 写到:
>> >On Mon, Apr 17, 2017 at 07:57:37PM +0800, Icenowy Zheng wrote:
>> >> Allwinner A64 SoC features a NMI controller, which is usually
>> >connected
>> >> to the AXP PMIC.
>> >>
>> >> Add support for it.
>> >>
>> >> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> >> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>> >> ---
>> >> Changes in v2:
>> >> - Added Chen-Yu's ACK.
>> >>
>> >> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 ++++++++
>> >> 1 file changed, 8 insertions(+)
>> >>
>> >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> index 05ec9fc5e81f..53c18ca372ea 100644
>> >> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> @@ -403,6 +403,14 @@
>> >> <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
>> >> };
>> >>
>> >> + nmi_intc: interrupt-controller@01f00c0c {
>> >> + compatible = "allwinner,sun6i-a31-sc-nmi";
>> >> + interrupt-controller;
>> >> + #interrupt-cells = <2>;
>> >> + reg = <0x01f00c0c 0x38>;
>> >
>> >The base address is not correct, and there's uncertainty on whether
>> >this is this particular controller or not. Did you even test this?
>>
>> Tested by axp20x-pek.
>
> Still, the base address is wrong, which is yet another hint that this
> is not the same interrupt controller, and just works by accident.
No, it's the same as other post-sun6i device trees.
See other post-sun6i device trees: (or maybe they're all wrong, but
as we have no document for it, we should temporarily keep them)
sun6i-a31.dtsi
```
nmi_intc: interrupt-controller@01f00c0c {
compatible = "allwinner,sun6i-a31-sc-nmi";
interrupt-controller;
#interrupt-cells = <2>;
reg = <0x01f00c0c 0x38>;
interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
};
```
sun8i-a23-a33.dtsi
```
nmi_intc: interrupt-controller@01f00c0c {
compatible = "allwinner,sun6i-a31-sc-nmi";
interrupt-controller;
#interrupt-cells = <2>;
reg = <0x01f00c0c 0x38>;
interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
};
```
But according to the BSP device tree, the base address should be
0x01f00c00. Should I send some patch to fix all of them? (but it will
break device tree compatibility)
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v4 04/18] dt-bindings: syscon: Add DT bindings documentation for Allwinner syscon
From: Corentin Labbe @ 2017-04-20 6:50 UTC (permalink / raw)
To: André Przywara
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <9382f9ae-895a-397b-3d8c-846cb0bc4486-5wv7dgnIgG8@public.gmane.org>
On Thu, Apr 20, 2017 at 12:38:50AM +0100, André Przywara wrote:
> On 12/04/17 12:13, Corentin Labbe wrote:
> > This patch adds documentation for Device-Tree bindings for the
> > syscon present in allwinner devices.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> > .../devicetree/bindings/misc/allwinner,syscon.txt | 19 +++++++++++++++++++
> > 1 file changed, 19 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
> >
> > diff --git a/Documentation/devicetree/bindings/misc/allwinner,syscon.txt b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
> > new file mode 100644
> > index 0000000..c056c5b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
> > @@ -0,0 +1,19 @@
> > +* Allwinner sun8i system controller
> > +
> > +This file describes the bindings for the system controller present in
> > +Allwinner SoC H3, A83T and A64.
> > +The principal function of this syscon is to control EMAC PHY choice and
> > +config.
> > +
> > +Required properties for the system controller:
> > +- reg: address and length of the register for the device.
> > +- compatible: should be "syscon" and one of the following string:
> > + "allwinner,sun8i-h3-system-controller"
> > + "allwinner,sun8i-a64-system-controller"
>
> While sun8i might make some sense technically, all 64-bit sunxi
> compatible strings use the sun50i prefix to follow the Allwinner naming.
> So this should read:
> "allwinner,sun50i-a64-system-controller"
>
> Also I am wondering if we should add a compatible string for the H5
> (support for that SoC is in -next already):
> "allwinner,sun50i-h5-system-controller"
>
> Cheers,
> Andre.
>
I agree with sun50i-a64-system-controller, the sun8i-a64 is a copy/paste error.
I will add sun50i-h5-system-controller since all xxx-system-controller are just hypothetic compatible.
Thanks
Regards
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: tegra: Add CCPLEX_CLUSTER area in Tegra186
From: Mikko Perttunen @ 2017-04-20 6:44 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: Mikko Perttunen, rjw-LthD3rsA81gm4RdzfppkhA,
viresh.kumar-QSEj5FYQhm4dnm+yROfE0A,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
jonathanh-DDmLM1+adcrQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491313417-25085-3-git-send-email-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 04.04.2017 16:43, Mikko Perttunen wrote:
> The Tegra186 CCPLEX_CLUSTER area contains memory-mapped
> registers that initiate CPU frequency/voltage transitions.
>
> Signed-off-by: Mikko Perttunen <mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> v2:
> - Only one regs entry
>
> arch/arm64/boot/dts/nvidia/tegra186.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> index 3ea5e6369bc3..c023af0be43d 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> @@ -347,6 +347,13 @@
> reg-names = "pmc", "wake", "aotag", "scratch";
> };
>
> + ccplex@e000000 {
> + compatible = "nvidia,tegra186-ccplex-cluster";
> + reg = <0x0 0x0e000000 0x0 0x3fffff>;
> +
> + nvidia,bpmp = <&bpmp>;
> + };
> +
> sysram@30000000 {
> compatible = "nvidia,tegra186-sysram", "mmio-sram";
> reg = <0x0 0x30000000 0x0 0x50000>;
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/5] ARM: dts: rockchip: add ARM Mali GPU node for rk3288
From: Heiko Stuebner @ 2017-04-20 6:43 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Neil Armstrong,
Sjoerd Simons, Wookey, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, John Reitan,
Rob Herring, Enric Balletbo i Serra,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <319a2a72-ca25-08d7-68dc-7eae74f1a622-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Hi Guillaume,
Am Donnerstag, 20. April 2017, 06:44:56 CEST schrieb Guillaume Tucker:
> On 19/04/17 09:59, Heiko Stuebner wrote:
> > Am Mittwoch, 19. April 2017, 09:06:18 CEST schrieb Guillaume Tucker:
> >> Add Mali GPU device tree node for the rk3288 SoC, with devfreq
> >> opp table.
> >>
> >> Tested-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> >> Signed-off-by: Guillaume Tucker <guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> >> ---
> >> arch/arm/boot/dts/rk3288.dtsi | 22 ++++++++++++++++++++++
> >> 1 file changed, 22 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> >> index df8a0dbe9d91..187eed528f83 100644
> >> --- a/arch/arm/boot/dts/rk3288.dtsi
> >> +++ b/arch/arm/boot/dts/rk3288.dtsi
> >> @@ -43,6 +43,7 @@
> >> #include <dt-bindings/interrupt-controller/arm-gic.h>
> >> #include <dt-bindings/pinctrl/rockchip.h>
> >> #include <dt-bindings/clock/rk3288-cru.h>
> >> +#include <dt-bindings/power/rk3288-power.h>
> >> #include <dt-bindings/thermal/thermal.h>
> >> #include <dt-bindings/power/rk3288-power.h>
> >> #include <dt-bindings/soc/rockchip,boot-mode.h>
> >> @@ -227,6 +228,27 @@
> >> ports = <&vopl_out>, <&vopb_out>;
> >> };
> >>
> >> + gpu: mali@ffa30000 {
> >
> > please sort nodes by address. ffa30000 should be placed below hdmi@ff980000
> > and above qos@ffaa0000 .
>
> Sure, will fix that in v4.
>
> >> + compatible = "arm,mali-t760", "arm,mali-midgard";
> >
> > As indicated before I don't trust that a generic binding will work for
> > everything, so I would feel safer if we had a "rockchip,rk3288-mali" in
> > front for future purposes, making it a
> >
> > compatible = "rockchip,rk3288-mali", "arm,mali-t760", "arm,mali-midgard";
>
> OK, sorry I overlooked this part. I'll add it in v4 with a
> vendor compatible string in the binding documentation.
great, thanks :-)
>
> >> + reg = <0xffa30000 0x10000>;
> >> + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> >> + interrupt-names = "job", "mmu", "gpu";
> >> + clocks = <&cru ACLK_GPU>;
> >> + operating-points = <
> >> + /* KHz uV */
> >> + 100000 950000
> >> + 200000 950000
> >> + 300000 1000000
> >> + 400000 1100000
> >> + 500000 1200000
> >> + 600000 1250000
> >> + >;
> >
> > Wasn't there a wish for opp-v2 in a previous version?
>
> Well it wasn't entirely clear to me in Rob's email whether it was
> necessary to use opp-v2 now or rather if it would be a potential
> option whenever opp-v2 was needed. If operating-points (v1) are
> being deprecated then I can change that in my next patch v4.
> Using operating-points-v2 with the Mali driver works as far as I
> can tell on rk3288 so that's not an issue.
I don't care to much either way, just remembered it being mentioned
in the previous version. So lets see what Rob says.
Heiko
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: Add bindings for nvidia,tegra186-ccplex-cluster
From: Mikko Perttunen @ 2017-04-20 6:43 UTC (permalink / raw)
To: robh+dt, Mark Rutland
Cc: Mikko Perttunen, rjw, viresh.kumar, thierry.reding, jonathanh,
linux-kernel, linux-pm, linux-tegra, devicetree
In-Reply-To: <1491313417-25085-2-git-send-email-mperttunen@nvidia.com>
Rob, Mark,
could you review this and the 3/3 in the series (which I'm sending to
you momentarily)?
Thanks,
Mikko.
On 04.04.2017 16:43, Mikko Perttunen wrote:
> The Tegra186 CCPLEX_CLUSTER area contains memory-mapped
> registers that initiate CPU frequency/voltage transitions.
>
> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---
> v2:
> - Only one regs entry.
> - s/Phandle/phandle/
>
> .../arm/tegra/nvidia,tegra186-ccplex-cluster.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-ccplex-cluster.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-ccplex-cluster.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-ccplex-cluster.txt
> new file mode 100644
> index 000000000000..e8fb416c892b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-ccplex-cluster.txt
> @@ -0,0 +1,17 @@
> +NVIDIA Tegra CCPLEX_CLUSTER area
> +
> +Required properties:
> +- compatible: Should contain one of the following:
> + - "nvidia,tegra186-ccplex-cluster": for Tegra186
> +- reg: Must contain an (offset, length) pair of the device's MMIO
> + register area
> +- nvidia,bpmp: phandle to BPMP device that can be queried for OPP tables
> +
> +Example:
> +
> + ccplex@e000000 {
> + compatible = "nvidia,tegra186-ccplex-cluster";
> + reg = <0x0 0x0e000000 0x0 0x3fffff>,
> +
> + nvidia,bpmp = <&bpmp>;
> + };
>
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Guillaume Tucker @ 2017-04-20 5:58 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Rob Herring, Mark Rutland, Neil Armstrong, Sjoerd Simons,
Enric Balletbo i Serra, John Reitan, Wookey,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5481965.3RkcDb038R@phil>
Hi Heiko,
On 19/04/17 10:02, Heiko Stuebner wrote:
> Am Mittwoch, 19. April 2017, 09:06:17 CEST schrieb Guillaume Tucker:
>> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>> new file mode 100644
>> index 000000000000..917c4f8d178f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>> @@ -0,0 +1,57 @@
>> +ARM Mali Midgard GPU
>> +====================
>> +
>> +Required properties:
>> +
>> +- compatible :
>> + * Must be one of the following:
>> + + "arm,mali-t60x"
>> + + "arm,mali-t62x"
>> + + "arm,mali-t720"
>> + + "arm,mali-t760"
>> + + "arm,mali-t820"
>> + + "arm,mali-t830"
>> + + "arm,mali-t860"
>> + + "arm,mali-t880"
>> + * And, optionally, one of the vendor specific compatible:
>> + + "amlogic,meson-gxm-mali"
>
> Please add a "rockchip,rk3288-mali" as well :-) , as I don't trust that the
> generic compatible will be enough for all time and having that already
> defined makes fixing the per soc things later a lot easier.
Sure, will do in patch v4.
>> +
>> +- reg : Physical base address of the device and length of the register area.
>> +
>> +- interrupts : Contains the three IRQ lines required by Mali Midgard devices.
>> +
>> +- interrupt-names : Contains the names of IRQ resources in the order they were
>> + provided in the interrupts property. Must contain: "job", "mmu", "gpu".
>> +
>> +
>> +Optional properties:
>> +
>> +- clocks : Phandle to clock for the Mali Midgard device.
>> +
>> +- mali-supply : Phandle to regulator for the Mali device. Refer to
>> + Documentation/devicetree/bindings/regulator/regulator.txt for details.
>> +
>> +- operating-points : Refer to Documentation/devicetree/bindings/power/opp.txt
>> + for details.
So I can simply change that to operating-points-v2. Both
versions can be used in practice but it sounds like
operating-points can just be ignored in this binding's
documentation. Could you please confirm?
Thanks,
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Re: [PATCH v3 02/12] arm64: allwinner: a64: add NMI controller on A64
From: Maxime Ripard @ 2017-04-20 5:58 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Lee Jones, Rob Herring, Chen-Yu Tsai, Liam Girdwood, Mark Brown,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <FB3B3C68-EB16-4352-B0B9-64857B1A6C03-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]
On Tue, Apr 18, 2017 at 06:56:43PM +0800, Icenowy Zheng wrote:
>
>
> 于 2017年4月18日 GMT+08:00 下午3:00:16, Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> 写到:
> >On Mon, Apr 17, 2017 at 07:57:37PM +0800, Icenowy Zheng wrote:
> >> Allwinner A64 SoC features a NMI controller, which is usually
> >connected
> >> to the AXP PMIC.
> >>
> >> Add support for it.
> >>
> >> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> >> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> >> ---
> >> Changes in v2:
> >> - Added Chen-Yu's ACK.
> >>
> >> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 ++++++++
> >> 1 file changed, 8 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> index 05ec9fc5e81f..53c18ca372ea 100644
> >> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> @@ -403,6 +403,14 @@
> >> <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
> >> };
> >>
> >> + nmi_intc: interrupt-controller@01f00c0c {
> >> + compatible = "allwinner,sun6i-a31-sc-nmi";
> >> + interrupt-controller;
> >> + #interrupt-cells = <2>;
> >> + reg = <0x01f00c0c 0x38>;
> >
> >The base address is not correct, and there's uncertainty on whether
> >this is this particular controller or not. Did you even test this?
>
> Tested by axp20x-pek.
Still, the base address is wrong, which is yet another hint that this
is not the same interrupt controller, and just works by accident.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/5] ARM: dts: rockchip: add ARM Mali GPU node for rk3288
From: Guillaume Tucker @ 2017-04-20 5:44 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Rob Herring, Mark Rutland, Neil Armstrong, Sjoerd Simons,
Enric Balletbo i Serra, John Reitan, Wookey,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5403013.fQWx48MQOq@phil>
Hi Heiko,
On 19/04/17 09:59, Heiko Stuebner wrote:
> Am Mittwoch, 19. April 2017, 09:06:18 CEST schrieb Guillaume Tucker:
>> Add Mali GPU device tree node for the rk3288 SoC, with devfreq
>> opp table.
>>
>> Tested-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
>> Signed-off-by: Guillaume Tucker <guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
>> ---
>> arch/arm/boot/dts/rk3288.dtsi | 22 ++++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
>> index df8a0dbe9d91..187eed528f83 100644
>> --- a/arch/arm/boot/dts/rk3288.dtsi
>> +++ b/arch/arm/boot/dts/rk3288.dtsi
>> @@ -43,6 +43,7 @@
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> #include <dt-bindings/pinctrl/rockchip.h>
>> #include <dt-bindings/clock/rk3288-cru.h>
>> +#include <dt-bindings/power/rk3288-power.h>
>> #include <dt-bindings/thermal/thermal.h>
>> #include <dt-bindings/power/rk3288-power.h>
>> #include <dt-bindings/soc/rockchip,boot-mode.h>
>> @@ -227,6 +228,27 @@
>> ports = <&vopl_out>, <&vopb_out>;
>> };
>>
>> + gpu: mali@ffa30000 {
>
> please sort nodes by address. ffa30000 should be placed below hdmi@ff980000
> and above qos@ffaa0000 .
Sure, will fix that in v4.
>> + compatible = "arm,mali-t760", "arm,mali-midgard";
>
> As indicated before I don't trust that a generic binding will work for
> everything, so I would feel safer if we had a "rockchip,rk3288-mali" in
> front for future purposes, making it a
>
> compatible = "rockchip,rk3288-mali", "arm,mali-t760", "arm,mali-midgard";
OK, sorry I overlooked this part. I'll add it in v4 with a
vendor compatible string in the binding documentation.
>> + reg = <0xffa30000 0x10000>;
>> + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "job", "mmu", "gpu";
>> + clocks = <&cru ACLK_GPU>;
>> + operating-points = <
>> + /* KHz uV */
>> + 100000 950000
>> + 200000 950000
>> + 300000 1000000
>> + 400000 1100000
>> + 500000 1200000
>> + 600000 1250000
>> + >;
>
> Wasn't there a wish for opp-v2 in a previous version?
Well it wasn't entirely clear to me in Rob's email whether it was
necessary to use opp-v2 now or rather if it would be a potential
option whenever opp-v2 was needed. If operating-points (v1) are
being deprecated then I can change that in my next patch v4.
Using operating-points-v2 with the Mali driver works as far as I
can tell on rk3288 so that's not an issue.
Thanks,
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V4 7/7] ARM: ZTE: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 5:44 UTC (permalink / raw)
To: arm
Cc: linaro-kernel, linux-arm-kernel, linux-pm, Rafael Wysocki,
Viresh Kumar, Krzysztof Kozlowski, Masahiro Yamada, Mark Rutland,
Rob Herring, devicetree, linux-kernel
In-Reply-To: <cover.1492666725.git.viresh.kumar@linaro.org>
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index b850b2cd0adc..2c7dc69987df 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -118,27 +118,27 @@
compatible = "operating-points-v2";
opp-shared;
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
clock-latency-ns = <500000>;
};
- opp@648000000 {
+ opp-648000000 {
opp-hz = /bits/ 64 <648000000>;
clock-latency-ns = <500000>;
};
- opp@800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
clock-latency-ns = <500000>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
clock-latency-ns = <500000>;
};
- opp@1188000000 {
+ opp-1188000000 {
opp-hz = /bits/ 64 <1188000000>;
clock-latency-ns = <500000>;
};
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
* [PATCH V4 6/7] ARM: uniphier: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 5:44 UTC (permalink / raw)
To: arm, Rob Herring, Mark Rutland, Masahiro Yamada
Cc: Rob Herring, linaro-kernel, linux-pm, Viresh Kumar,
Rafael Wysocki, linux-kernel, Krzysztof Kozlowski, devicetree,
linux-arm-kernel
In-Reply-To: <cover.1492666725.git.viresh.kumar@linaro.org>
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
---
arch/arm/boot/dts/uniphier-pro5.dtsi | 32 ++++++++++++------------
arch/arm/boot/dts/uniphier-pxs2.dtsi | 16 ++++++------
arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 14 +++++------
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 32 ++++++++++++------------
4 files changed, 47 insertions(+), 47 deletions(-)
diff --git a/arch/arm/boot/dts/uniphier-pro5.dtsi b/arch/arm/boot/dts/uniphier-pro5.dtsi
index dbc5e5333163..22ef2842be3a 100644
--- a/arch/arm/boot/dts/uniphier-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-pro5.dtsi
@@ -77,67 +77,67 @@
compatible = "operating-points-v2";
opp-shared;
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
clock-latency-ns = <300>;
};
- opp@116667000 {
+ opp-116667000 {
opp-hz = /bits/ 64 <116667000>;
clock-latency-ns = <300>;
};
- opp@150000000 {
+ opp-150000000 {
opp-hz = /bits/ 64 <150000000>;
clock-latency-ns = <300>;
};
- opp@175000000 {
+ opp-175000000 {
opp-hz = /bits/ 64 <175000000>;
clock-latency-ns = <300>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
clock-latency-ns = <300>;
};
- opp@233334000 {
+ opp-233334000 {
opp-hz = /bits/ 64 <233334000>;
clock-latency-ns = <300>;
};
- opp@300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
clock-latency-ns = <300>;
};
- opp@350000000 {
+ opp-350000000 {
opp-hz = /bits/ 64 <350000000>;
clock-latency-ns = <300>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
clock-latency-ns = <300>;
};
- opp@466667000 {
+ opp-466667000 {
opp-hz = /bits/ 64 <466667000>;
clock-latency-ns = <300>;
};
- opp@600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
clock-latency-ns = <300>;
};
- opp@700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
clock-latency-ns = <300>;
};
- opp@800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
clock-latency-ns = <300>;
};
- opp@933334000 {
+ opp-933334000 {
opp-hz = /bits/ 64 <933334000>;
clock-latency-ns = <300>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
clock-latency-ns = <300>;
};
- opp@1400000000 {
+ opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
clock-latency-ns = <300>;
};
diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi b/arch/arm/boot/dts/uniphier-pxs2.dtsi
index e9e031d63c1a..acaaa2187843 100644
--- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
@@ -97,35 +97,35 @@
compatible = "operating-points-v2";
opp-shared;
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
clock-latency-ns = <300>;
};
- opp@150000000 {
+ opp-150000000 {
opp-hz = /bits/ 64 <150000000>;
clock-latency-ns = <300>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
clock-latency-ns = <300>;
};
- opp@300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
clock-latency-ns = <300>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
clock-latency-ns = <300>;
};
- opp@600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
clock-latency-ns = <300>;
};
- opp@800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
clock-latency-ns = <300>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
clock-latency-ns = <300>;
};
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
index da881f5b6ed4..0f2bee028ab0 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
@@ -89,31 +89,31 @@
compatible = "operating-points-v2";
opp-shared;
- opp@245000000 {
+ opp-245000000 {
opp-hz = /bits/ 64 <245000000>;
clock-latency-ns = <300>;
};
- opp@250000000 {
+ opp-250000000 {
opp-hz = /bits/ 64 <250000000>;
clock-latency-ns = <300>;
};
- opp@490000000 {
+ opp-490000000 {
opp-hz = /bits/ 64 <490000000>;
clock-latency-ns = <300>;
};
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
clock-latency-ns = <300>;
};
- opp@653334000 {
+ opp-653334000 {
opp-hz = /bits/ 64 <653334000>;
clock-latency-ns = <300>;
};
- opp@666667000 {
+ opp-666667000 {
opp-hz = /bits/ 64 <666667000>;
clock-latency-ns = <300>;
};
- opp@980000000 {
+ opp-980000000 {
opp-hz = /bits/ 64 <980000000>;
clock-latency-ns = <300>;
};
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index a6b3a70dae83..19f782408d54 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -116,35 +116,35 @@
compatible = "operating-points-v2";
opp-shared;
- opp@250000000 {
+ opp-250000000 {
opp-hz = /bits/ 64 <250000000>;
clock-latency-ns = <300>;
};
- opp@275000000 {
+ opp-275000000 {
opp-hz = /bits/ 64 <275000000>;
clock-latency-ns = <300>;
};
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
clock-latency-ns = <300>;
};
- opp@550000000 {
+ opp-550000000 {
opp-hz = /bits/ 64 <550000000>;
clock-latency-ns = <300>;
};
- opp@666667000 {
+ opp-666667000 {
opp-hz = /bits/ 64 <666667000>;
clock-latency-ns = <300>;
};
- opp@733334000 {
+ opp-733334000 {
opp-hz = /bits/ 64 <733334000>;
clock-latency-ns = <300>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
clock-latency-ns = <300>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
clock-latency-ns = <300>;
};
@@ -154,35 +154,35 @@
compatible = "operating-points-v2";
opp-shared;
- opp@250000000 {
+ opp-250000000 {
opp-hz = /bits/ 64 <250000000>;
clock-latency-ns = <300>;
};
- opp@275000000 {
+ opp-275000000 {
opp-hz = /bits/ 64 <275000000>;
clock-latency-ns = <300>;
};
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
clock-latency-ns = <300>;
};
- opp@550000000 {
+ opp-550000000 {
opp-hz = /bits/ 64 <550000000>;
clock-latency-ns = <300>;
};
- opp@666667000 {
+ opp-666667000 {
opp-hz = /bits/ 64 <666667000>;
clock-latency-ns = <300>;
};
- opp@733334000 {
+ opp-733334000 {
opp-hz = /bits/ 64 <733334000>;
clock-latency-ns = <300>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
clock-latency-ns = <300>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
clock-latency-ns = <300>;
};
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
* [PATCH V4 5/7] ARM: sun8i: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 5:44 UTC (permalink / raw)
To: arm-DgEjT+Ai2ygdnm+yROfE0A, Rob Herring, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai
Cc: linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Rafael Wysocki, Viresh Kumar,
Krzysztof Kozlowski, Masahiro Yamada, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1492666725.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Reported-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Suggested-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
arch/arm/boot/dts/sun8i-a33.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 306af6cadf26..a2c555d6475c 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -49,19 +49,19 @@
compatible = "operating-points-v2";
opp-shared;
- opp@648000000 {
+ opp-648000000 {
opp-hz = /bits/ 64 <648000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp@816000000 {
+ opp-816000000 {
opp-hz = /bits/ 64 <816000000>;
opp-microvolt = <1100000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp@1008000000 {
+ opp-1008000000 {
opp-hz = /bits/ 64 <1008000000>;
opp-microvolt = <1200000>;
clock-latency-ns = <244144>; /* 8 32k periods */
--
2.12.0.432.g71c3a4f4ba37
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V4 4/7] ARM: pxa: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 5:44 UTC (permalink / raw)
To: arm, Daniel Mack, Haojian Zhuang, Robert Jarzmik, Rob Herring,
Mark Rutland
Cc: linaro-kernel, linux-arm-kernel, linux-pm, Rafael Wysocki,
Viresh Kumar, Krzysztof Kozlowski, Masahiro Yamada, Rob Herring,
devicetree, linux-kernel
In-Reply-To: <cover.1492666725.git.viresh.kumar@linaro.org>
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
---
arch/arm/boot/dts/pxa25x.dtsi | 8 ++++----
arch/arm/boot/dts/pxa27x.dtsi | 14 +++++++-------
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/pxa25x.dtsi b/arch/arm/boot/dts/pxa25x.dtsi
index f9f4726396a0..95d59be97213 100644
--- a/arch/arm/boot/dts/pxa25x.dtsi
+++ b/arch/arm/boot/dts/pxa25x.dtsi
@@ -93,22 +93,22 @@
pxa250_opp_table: opp_table0 {
compatible = "operating-points-v2";
- opp@99532800 {
+ opp-99532800 {
opp-hz = /bits/ 64 <99532800>;
opp-microvolt = <1000000 950000 1650000>;
clock-latency-ns = <20>;
};
- opp@199065600 {
+ opp-199065600 {
opp-hz = /bits/ 64 <199065600>;
opp-microvolt = <1000000 950000 1650000>;
clock-latency-ns = <20>;
};
- opp@298598400 {
+ opp-298598400 {
opp-hz = /bits/ 64 <298598400>;
opp-microvolt = <1100000 1045000 1650000>;
clock-latency-ns = <20>;
};
- opp@398131200 {
+ opp-398131200 {
opp-hz = /bits/ 64 <398131200>;
opp-microvolt = <1300000 1235000 1650000>;
clock-latency-ns = <20>;
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index e0fab48ba6fa..5f1d6da02a4c 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -141,37 +141,37 @@
pxa270_opp_table: opp_table0 {
compatible = "operating-points-v2";
- opp@104000000 {
+ opp-104000000 {
opp-hz = /bits/ 64 <104000000>;
opp-microvolt = <900000 900000 1705000>;
clock-latency-ns = <20>;
};
- opp@156000000 {
+ opp-156000000 {
opp-hz = /bits/ 64 <156000000>;
opp-microvolt = <1000000 1000000 1705000>;
clock-latency-ns = <20>;
};
- opp@208000000 {
+ opp-208000000 {
opp-hz = /bits/ 64 <208000000>;
opp-microvolt = <1180000 1180000 1705000>;
clock-latency-ns = <20>;
};
- opp@312000000 {
+ opp-312000000 {
opp-hz = /bits/ 64 <312000000>;
opp-microvolt = <1250000 1250000 1705000>;
clock-latency-ns = <20>;
};
- opp@416000000 {
+ opp-416000000 {
opp-hz = /bits/ 64 <416000000>;
opp-microvolt = <1350000 1350000 1705000>;
clock-latency-ns = <20>;
};
- opp@520000000 {
+ opp-520000000 {
opp-hz = /bits/ 64 <520000000>;
opp-microvolt = <1450000 1450000 1705000>;
clock-latency-ns = <20>;
};
- opp@624000000 {
+ opp-624000000 {
opp-hz = /bits/ 64 <624000000>;
opp-microvolt = <1550000 1550000 1705000>;
clock-latency-ns = <20>;
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
* [PATCH V4 3/7] ARM: exynos: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 5:44 UTC (permalink / raw)
To: arm, Chanwoo Choi, MyungJoo Ham, Kyungmin Park, Kukjin Kim,
Krzysztof Kozlowski, Javier Martinez Canillas, Rob Herring,
Mark Rutland
Cc: linaro-kernel, linux-arm-kernel, linux-pm, Rafael Wysocki,
Viresh Kumar, Masahiro Yamada, Rob Herring, linux-samsung-soc,
devicetree, linux-kernel
In-Reply-To: <cover.1492666725.git.viresh.kumar@linaro.org>
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++++++--------
arch/arm/boot/dts/exynos3250.dtsi | 46 +++++++--------
arch/arm/boot/dts/exynos4210.dtsi | 32 +++++------
arch/arm/boot/dts/exynos4412-prime.dtsi | 4 +-
arch/arm/boot/dts/exynos4412.dtsi | 66 +++++++++++-----------
arch/arm/boot/dts/exynos5420.dtsi | 40 ++++++-------
arch/arm/boot/dts/exynos5800.dtsi | 56 +++++++++---------
arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 ++++++++--------
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 ++++++++--------
9 files changed, 194 insertions(+), 194 deletions(-)
diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index d085ef90d27c..f8e946471a58 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -202,23 +202,23 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
opp-microvolt = <800000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <800000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <800000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <825000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <875000>;
};
@@ -292,23 +292,23 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
opp-microvolt = <900000>;
};
- opp@80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
opp-microvolt = <900000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <1000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <1000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <1000000>;
};
@@ -318,19 +318,19 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp@80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
};
};
@@ -339,19 +339,19 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp@80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp@300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
};
};
@@ -360,13 +360,13 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp@80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index 9c28ef4508e0..590ee442d0ae 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -745,23 +745,23 @@
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
opp-microvolt = <800000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <800000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <800000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <825000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <875000>;
};
@@ -835,23 +835,23 @@
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
opp-microvolt = <900000>;
};
- opp@80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
opp-microvolt = <900000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <1000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <1000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <1000000>;
};
@@ -861,19 +861,19 @@
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp@80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
};
};
@@ -882,19 +882,19 @@
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp@80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp@300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
};
};
@@ -903,13 +903,13 @@
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp@80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index f9408188f97f..3678d5b44d80 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -335,15 +335,15 @@
compatible = "operating-points-v2";
opp-shared;
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <1025000>;
};
- opp@267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
opp-microvolt = <1050000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <1150000>;
};
@@ -353,13 +353,13 @@
compatible = "operating-points-v2";
opp-shared;
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
};
@@ -368,10 +368,10 @@
compatible = "operating-points-v2";
opp-shared;
- opp@5000000 {
+ opp-5000000 {
opp-hz = /bits/ 64 <5000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
@@ -380,10 +380,10 @@
compatible = "operating-points-v2";
opp-shared;
- opp@10000000 {
+ opp-10000000 {
opp-hz = /bits/ 64 <10000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
};
@@ -392,13 +392,13 @@
compatible = "operating-points-v2";
opp-shared;
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
};
@@ -407,13 +407,13 @@
compatible = "operating-points-v2";
opp-shared;
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
};
diff --git a/arch/arm/boot/dts/exynos4412-prime.dtsi b/arch/arm/boot/dts/exynos4412-prime.dtsi
index e75bc170c89c..a67bd953d754 100644
--- a/arch/arm/boot/dts/exynos4412-prime.dtsi
+++ b/arch/arm/boot/dts/exynos4412-prime.dtsi
@@ -20,12 +20,12 @@
};
&cpu0_opp_table {
- opp@1600000000 {
+ opp-1600000000 {
opp-hz = /bits/ 64 <1600000000>;
opp-microvolt = <1350000>;
clock-latency-ns = <200000>;
};
- opp@1704000000 {
+ opp-1704000000 {
opp-hz = /bits/ 64 <1704000000>;
opp-microvolt = <1350000>;
clock-latency-ns = <200000>;
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 235bbb69ad7c..ce240d0198b3 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -76,73 +76,73 @@
compatible = "operating-points-v2";
opp-shared;
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <900000>;
clock-latency-ns = <200000>;
};
- opp@300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <900000>;
clock-latency-ns = <200000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <925000>;
clock-latency-ns = <200000>;
};
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <950000>;
clock-latency-ns = <200000>;
};
- opp@600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <975000>;
clock-latency-ns = <200000>;
};
- opp@700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
opp-microvolt = <987500>;
clock-latency-ns = <200000>;
};
- opp@800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1000000>;
clock-latency-ns = <200000>;
opp-suspend;
};
- opp@900000000 {
+ opp-900000000 {
opp-hz = /bits/ 64 <900000000>;
opp-microvolt = <1037500>;
clock-latency-ns = <200000>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1087500>;
clock-latency-ns = <200000>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1137500>;
clock-latency-ns = <200000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1187500>;
clock-latency-ns = <200000>;
};
- opp@1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1250000>;
clock-latency-ns = <200000>;
};
- opp@1400000000 {
+ opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1287500>;
clock-latency-ns = <200000>;
};
- cpu0_opp_1500: opp@1500000000 {
+ cpu0_opp_1500: opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1350000>;
clock-latency-ns = <200000>;
@@ -433,23 +433,23 @@
compatible = "operating-points-v2";
opp-shared;
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <900000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <900000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
opp-microvolt = <900000>;
};
- opp@267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
opp-microvolt = <950000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <1050000>;
};
@@ -459,16 +459,16 @@
compatible = "operating-points-v2";
opp-shared;
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp@267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
};
};
@@ -525,19 +525,19 @@
compatible = "operating-points-v2";
opp-shared;
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <900000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <925000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
opp-microvolt = <950000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <1000000>;
};
@@ -547,10 +547,10 @@
compatible = "operating-points-v2";
opp-shared;
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
};
@@ -559,10 +559,10 @@
compatible = "operating-points-v2";
opp-shared;
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
};
@@ -571,10 +571,10 @@
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index 7dc9dc82afd8..5cd6c7389d51 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -49,62 +49,62 @@
cluster_a15_opp_table: opp_table0 {
compatible = "operating-points-v2";
opp-shared;
- opp@1800000000 {
+ opp-1800000000 {
opp-hz = /bits/ 64 <1800000000>;
opp-microvolt = <1250000>;
clock-latency-ns = <140000>;
};
- opp@1700000000 {
+ opp-1700000000 {
opp-hz = /bits/ 64 <1700000000>;
opp-microvolt = <1212500>;
clock-latency-ns = <140000>;
};
- opp@1600000000 {
+ opp-1600000000 {
opp-hz = /bits/ 64 <1600000000>;
opp-microvolt = <1175000>;
clock-latency-ns = <140000>;
};
- opp@1500000000 {
+ opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1137500>;
clock-latency-ns = <140000>;
};
- opp@1400000000 {
+ opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1112500>;
clock-latency-ns = <140000>;
};
- opp@1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1062500>;
clock-latency-ns = <140000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1037500>;
clock-latency-ns = <140000>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1012500>;
clock-latency-ns = <140000>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = < 987500>;
clock-latency-ns = <140000>;
};
- opp@900000000 {
+ opp-900000000 {
opp-hz = /bits/ 64 <900000000>;
opp-microvolt = < 962500>;
clock-latency-ns = <140000>;
};
- opp@800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = < 937500>;
clock-latency-ns = <140000>;
};
- opp@700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
opp-microvolt = < 912500>;
clock-latency-ns = <140000>;
@@ -114,42 +114,42 @@
cluster_a7_opp_table: opp_table1 {
compatible = "operating-points-v2";
opp-shared;
- opp@1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1275000>;
clock-latency-ns = <140000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1212500>;
clock-latency-ns = <140000>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1162500>;
clock-latency-ns = <140000>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1112500>;
clock-latency-ns = <140000>;
};
- opp@900000000 {
+ opp-900000000 {
opp-hz = /bits/ 64 <900000000>;
opp-microvolt = <1062500>;
clock-latency-ns = <140000>;
};
- opp@800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1025000>;
clock-latency-ns = <140000>;
};
- opp@700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
opp-microvolt = <975000>;
clock-latency-ns = <140000>;
};
- opp@600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <937500>;
clock-latency-ns = <140000>;
diff --git a/arch/arm/boot/dts/exynos5800.dtsi b/arch/arm/boot/dts/exynos5800.dtsi
index 8213016803e5..9ddb6bacac5a 100644
--- a/arch/arm/boot/dts/exynos5800.dtsi
+++ b/arch/arm/boot/dts/exynos5800.dtsi
@@ -24,60 +24,60 @@
};
&cluster_a15_opp_table {
- opp@1700000000 {
+ opp-1700000000 {
opp-microvolt = <1250000>;
};
- opp@1600000000 {
+ opp-1600000000 {
opp-microvolt = <1250000>;
};
- opp@1500000000 {
+ opp-1500000000 {
opp-microvolt = <1100000>;
};
- opp@1400000000 {
+ opp-1400000000 {
opp-microvolt = <1100000>;
};
- opp@1300000000 {
+ opp-1300000000 {
opp-microvolt = <1100000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-microvolt = <1000000>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-microvolt = <1000000>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-microvolt = <1000000>;
};
- opp@900000000 {
+ opp-900000000 {
opp-microvolt = <1000000>;
};
- opp@800000000 {
+ opp-800000000 {
opp-microvolt = <900000>;
};
- opp@700000000 {
+ opp-700000000 {
opp-microvolt = <900000>;
};
- opp@600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
};
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
};
- opp@300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
@@ -85,46 +85,46 @@
};
&cluster_a7_opp_table {
- opp@1300000000 {
+ opp-1300000000 {
opp-microvolt = <1250000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-microvolt = <1250000>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-microvolt = <1250000>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-microvolt = <1100000>;
};
- opp@900000000 {
+ opp-900000000 {
opp-microvolt = <1100000>;
};
- opp@800000000 {
+ opp-800000000 {
opp-microvolt = <1100000>;
};
- opp@700000000 {
+ opp-700000000 {
opp-microvolt = <1000000>;
};
- opp@600000000 {
+ opp-600000000 {
opp-microvolt = <1000000>;
};
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <1000000>;
clock-latency-ns = <140000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <1000000>;
clock-latency-ns = <140000>;
};
- opp@300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
index c42dc39c3223..ec11343dc528 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
@@ -94,27 +94,27 @@
compatible = "operating-points-v2";
opp-shared;
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <1075000>;
};
- opp@267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
opp-microvolt = <1000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <975000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
opp-microvolt = <962500>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <950000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <937500>;
};
@@ -123,19 +123,19 @@
bus_g2d_266_opp_table: opp_table3 {
compatible = "operating-points-v2";
- opp@267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
@@ -143,13 +143,13 @@
bus_gscl_opp_table: opp_table4 {
compatible = "operating-points-v2";
- opp@333000000 {
+ opp-333000000 {
opp-hz = /bits/ 64 <333000000>;
};
- opp@222000000 {
+ opp-222000000 {
opp-hz = /bits/ 64 <222000000>;
};
- opp@166500000 {
+ opp-166500000 {
opp-hz = /bits/ 64 <166500000>;
};
};
@@ -158,22 +158,22 @@
compatible = "operating-points-v2";
opp-shared;
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
};
- opp@267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
@@ -181,16 +181,16 @@
bus_noc2_opp_table: opp_table6 {
compatible = "operating-points-v2";
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 16072c1c3ed3..727f36abf3d4 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -119,43 +119,43 @@
compatible = "operating-points-v2";
opp-shared;
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <900000>;
};
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <925000>;
};
- opp@600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <950000>;
};
- opp@700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
opp-microvolt = <975000>;
};
- opp@800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1000000>;
};
- opp@900000000 {
+ opp-900000000 {
opp-hz = /bits/ 64 <900000000>;
opp-microvolt = <1050000>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1075000>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1112500>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1112500>;
};
- opp@1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1150000>;
};
@@ -165,63 +165,63 @@
compatible = "operating-points-v2";
opp-shared;
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <900000>;
};
- opp@600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <900000>;
};
- opp@700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
opp-microvolt = <912500>;
};
- opp@800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <912500>;
};
- opp@900000000 {
+ opp-900000000 {
opp-hz = /bits/ 64 <900000000>;
opp-microvolt = <937500>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1012500>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1037500>;
};
- opp@1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1062500>;
};
- opp@1400000000 {
+ opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1087500>;
};
- opp@1500000000 {
+ opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1125000>;
};
- opp@1600000000 {
+ opp-1600000000 {
opp-hz = /bits/ 64 <1600000000>;
opp-microvolt = <1137500>;
};
- opp@1700000000 {
+ opp-1700000000 {
opp-hz = /bits/ 64 <1700000000>;
opp-microvolt = <1175000>;
};
- opp@1800000000 {
+ opp-1800000000 {
opp-hz = /bits/ 64 <1800000000>;
opp-microvolt = <1212500>;
};
- opp@1900000000 {
+ opp-1900000000 {
opp-hz = /bits/ 64 <1900000000>;
opp-microvolt = <1262500>;
};
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
* [PATCH V4 2/7] ARM: TI: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 5:44 UTC (permalink / raw)
To: arm, Benoît Cousson, Tony Lindgren, Rob Herring,
Mark Rutland
Cc: Rob Herring, linaro-kernel, linux-pm, Viresh Kumar,
Rafael Wysocki, linux-kernel, Krzysztof Kozlowski,
Masahiro Yamada, devicetree, linux-omap, linux-arm-kernel
In-Reply-To: <cover.1492666725.git.viresh.kumar@linaro.org>
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Tony Lindgren <tony@atomide.com>
---
.../devicetree/bindings/cpufreq/ti-cpufreq.txt | 20 ++++++++++----------
arch/arm/boot/dts/am4372.dtsi | 10 +++++-----
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
index ba0e15ad5bd9..0c38e4b8fc51 100644
--- a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
+++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
@@ -63,64 +63,64 @@ cpu0_opp_table: opp-table {
* because they can not be enabled simultaneously on a
* single SoC.
*/
- opp50@300000000 {
+ opp50-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <950000 931000 969000>;
opp-supported-hw = <0x06 0x0010>;
opp-suspend;
};
- opp100@275000000 {
+ opp100-275000000 {
opp-hz = /bits/ 64 <275000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x01 0x00FF>;
opp-suspend;
};
- opp100@300000000 {
+ opp100-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x06 0x0020>;
opp-suspend;
};
- opp100@500000000 {
+ opp100-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x01 0xFFFF>;
};
- opp100@600000000 {
+ opp100-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x06 0x0040>;
};
- opp120@600000000 {
+ opp120-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1200000 1176000 1224000>;
opp-supported-hw = <0x01 0xFFFF>;
};
- opp120@720000000 {
+ opp120-720000000 {
opp-hz = /bits/ 64 <720000000>;
opp-microvolt = <1200000 1176000 1224000>;
opp-supported-hw = <0x06 0x0080>;
};
- oppturbo@720000000 {
+ oppturbo-720000000 {
opp-hz = /bits/ 64 <720000000>;
opp-microvolt = <1260000 1234800 1285200>;
opp-supported-hw = <0x01 0xFFFF>;
};
- oppturbo@800000000 {
+ oppturbo-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1260000 1234800 1285200>;
opp-supported-hw = <0x06 0x0100>;
};
- oppnitro@1000000000 {
+ oppnitro-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1325000 1298500 1351500>;
opp-supported-hw = <0x04 0x0200>;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 97fcaf415de1..1532ffe1de63 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -60,32 +60,32 @@
cpu0_opp_table: opp_table0 {
compatible = "operating-points-v2";
- opp50@300000000 {
+ opp50-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <950000 931000 969000>;
opp-supported-hw = <0xFF 0x01>;
opp-suspend;
};
- opp100@600000000 {
+ opp100-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0xFF 0x04>;
};
- opp120@720000000 {
+ opp120-720000000 {
opp-hz = /bits/ 64 <720000000>;
opp-microvolt = <1200000 1176000 1224000>;
opp-supported-hw = <0xFF 0x08>;
};
- oppturbo@800000000 {
+ oppturbo-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1260000 1234800 1285200>;
opp-supported-hw = <0xFF 0x10>;
};
- oppnitro@1000000000 {
+ oppnitro-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1325000 1298500 1351500>;
opp-supported-hw = <0xFF 0x20>;
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
* [PATCH V4 1/7] PM / OPP: Use - instead of @ for DT entries
From: Viresh Kumar @ 2017-04-20 5:44 UTC (permalink / raw)
To: arm, Viresh Kumar, Nishanth Menon, Stephen Boyd
Cc: linaro-kernel, linux-arm-kernel, linux-pm, Rafael Wysocki,
Viresh Kumar, Krzysztof Kozlowski, Masahiro Yamada, Mark Rutland,
Rob Herring, devicetree, linux-kernel
In-Reply-To: <cover.1492666725.git.viresh.kumar@linaro.org>
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/opp/opp.txt | 38 +++++++++++++--------------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index 63725498bd20..e36d261b9ba6 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -186,20 +186,20 @@ Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
compatible = "operating-points-v2";
opp-shared;
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
clock-latency-ns = <290000>;
@@ -265,20 +265,20 @@ independently.
* independently.
*/
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
opp-microamp = <90000;
@@ -341,20 +341,20 @@ DVFS state together.
compatible = "operating-points-v2";
opp-shared;
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
opp-microamp = <90000>;
@@ -367,20 +367,20 @@ DVFS state together.
compatible = "operating-points-v2";
opp-shared;
- opp@1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1050000 1045000 1055000>;
opp-microamp = <95000>;
clock-latency-ns = <400000>;
opp-suspend;
};
- opp@1400000000 {
+ opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1075000>;
opp-microamp = <100000>;
clock-latency-ns = <400000>;
};
- opp@1500000000 {
+ opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1100000 1010000 1110000>;
opp-microamp = <95000>;
@@ -409,7 +409,7 @@ Example 4: Handling multiple regulators
compatible = "operating-points-v2";
opp-shared;
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000>, /* Supply 0 */
<960000>, /* Supply 1 */
@@ -422,7 +422,7 @@ Example 4: Handling multiple regulators
/* OR */
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>, /* Supply 0 */
<965000 960000 975000>, /* Supply 1 */
@@ -435,7 +435,7 @@ Example 4: Handling multiple regulators
/* OR */
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>, /* Supply 0 */
<965000 960000 975000>, /* Supply 1 */
@@ -467,7 +467,7 @@ Example 5: opp-supported-hw
status = "okay";
opp-shared;
- opp@600000000 {
+ opp-600000000 {
/*
* Supports all substrate and process versions for 0xF
* cuts, i.e. only first four cuts.
@@ -478,7 +478,7 @@ Example 5: opp-supported-hw
...
};
- opp@800000000 {
+ opp-800000000 {
/*
* Supports:
* - cuts: only one, 6th cut (represented by 6th bit).
@@ -510,7 +510,7 @@ Example 5: opp-supported-hw
compatible = "operating-points-v2";
opp-shared;
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt-slow = <915000 900000 925000>;
opp-microvolt-fast = <975000 970000 985000>;
@@ -518,7 +518,7 @@ Example 5: opp-supported-hw
opp-microamp-fast = <71000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt-slow = <915000 900000 925000>, /* Supply vcc0 */
<925000 910000 935000>; /* Supply vcc1 */
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox