* Re: [PATCH v8 3/6] i2c: designware: MASTER mode as separated driver
From: Jarkko Nikula @ 2017-04-20 12:49 UTC (permalink / raw)
To: Luis Oliveira, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
mika.westerberg-VuQAYsv1563Yd54FQh9/CA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w,
Joao.Pinto-HKixBCOQz3hWk0Htik3J/w,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <f4ffddb9cb8206d299700d9de89b11246757e8c0.1492014220.git.lolivei-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On 04/12/2017 07:47 PM, Luis Oliveira wrote:
> - The functions related to I2C master mode of operation were transformed
> in a single driver.
> - Common definitions were moved to i2c-designware-core.h
> - The i2c-designware-core is now only a library file, the functions
> associated are in a source file called i2c-designware-common and
> are used by both i2c-designware-master and i2c-designware-slave.
> - To decrease noise in namespace common i2c_dw_*() functions are
> now using ops to keep them private.
> - Designware PCI driver had to be changed to match the previous ops
> functions implementation.
>
> Almost all of the "core" source is now part of the "master" source. The
> difference is the functions used by both modes and they are in the
> "common" source file.
>
> Signed-off-by: Luis Oliveira <lolivei-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> Acked-by: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> ---
> v7-v8
> - removed "@dynamic_tar_update_enabled" comment
>
> drivers/i2c/busses/Makefile | 1 +
> drivers/i2c/busses/i2c-designware-common.c | 274 +++++++++++++++
> drivers/i2c/busses/i2c-designware-core.h | 145 +++++++-
> ...c-designware-core.c => i2c-designware-master.c} | 367 +--------------------
> drivers/i2c/busses/i2c-designware-pcidrv.c | 8 +-
> drivers/i2c/busses/i2c-designware-platdrv.c | 6 +-
> 6 files changed, 432 insertions(+), 369 deletions(-)
> create mode 100644 drivers/i2c/busses/i2c-designware-common.c
> rename drivers/i2c/busses/{i2c-designware-core.c => i2c-designware-master.c} (65%)
>
Acked-by: Jarkko Nikula <jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
--
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 1/4] mfd: Add ROHM BD9571MWV-M PMIC DT bindings
From: Geert Uytterhoeven @ 2017-04-20 12:35 UTC (permalink / raw)
To: Marek Vasut
Cc: Linux-Renesas, Marek Vasut, devicetree@vger.kernel.org,
Rob Herring, Geert Uytterhoeven
In-Reply-To: <20170416180801.17828-1-marek.vasut+renesas@gmail.com>
Hi Marek,
On Sun, Apr 16, 2017 at 8:07 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> Add DT bindings for the ROHM BD9571MWV-M PMIC. This PMIC has
> the following features:
> - multiple voltage monitors for 1V8, 2V5, 3V3 voltage rail
> - one voltage regulator for DVFS
> - two GPIOs
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: devicetree@vger.kernel.org
> Cc: Rob Herring <robh@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> .../devicetree/bindings/mfd/bd9571mwv.txt | 49 ++++++++++++++++++++++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/bd9571mwv.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
> new file mode 100644
> index 000000000000..0952ee3bc30b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
> @@ -0,0 +1,49 @@
> +* ROHM BD9571MWV Power Management Integrated Circuit (PMIC) bindings
> +
> +Required properties:
> + - compatible : Should be "rohm,bd9571mwv".
> + - reg : I2C slave address.
> + - interrupt-parent : Phandle to the parent interrupt controller.
> + - interrupts : The interrupt line the device is connected to.
> + - interrupt-controller : Marks the device node as an interrupt controller.
> + - #interrupt-cells : The number of cells to describe an IRQ, should be 2.
> + The first cell is the IRQ number.
> + The second cell is the flags, encoded as trigger
> + masks from ../interrupt-controller/interrupts.txt.
> + - gpio-controller : Marks the device node as a GPIO Controller.
> + - #gpio-cells : Should be two. The first cell is the pin number and
> + the second cell is used to specify flags.
> + See ../gpio/gpio.txt for more information.
> + - regulators: : List of child nodes that specify the regulator
> + initialization data. Child nodes must be named
> + after their hardware counterparts:
> + - vd18
> + - vd25
> + - vd33
> + - dvfs
Missing vd09, which is used for VDD0.8 on Salvator-X.
> + Each child node is defined using the standard
> + binding for regulators.
> +
> +Example:
> +
> + pmic: bd9571mwv@30 {
> + compatible = "rohm,bd9571mwv";
> + reg = <0x30>;
> + interrupt-parent = <&gpio2>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + regulators {
> + dvfs: dvfs {
> + compatible = "regulator-fixed";
What's the purpose of this compatible value?
> + regulator-name = "dvfs";
> + regulator-min-microvolt = <750000>;
> + regulator-max-microvolt = <1030000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> + };
> + };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dts: r8a7743: add PFC support
From: Sergei Shtylyov @ 2017-04-20 12:24 UTC (permalink / raw)
To: Simon Horman
Cc: Rob Herring, Mark Rutland,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Magnus Damm, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170420085112.GF3760-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
Hello.
On 04/20/2017 11:51 AM, Simon Horman wrote:
>> Define the generic R8A7743 part of the PFC device node.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
>>
>> ---
>> 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.
The reason is simple: I was trying to follow the DT specs which require
generic node names. The "pin-controller" looked more generic than "pfc".
> 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.
Yes, probably.
[...]
MBR, Sergei
--
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 v2] pinctrl: sh-pfc: r8a7794: add R8A7745 support
From: Geert Uytterhoeven @ 2017-04-20 12:20 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Rob Herring, Mark Rutland, Laurent Pinchart, Geert Uytterhoeven,
Linus Walleij, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux-Renesas, linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170413201932.890107963-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Hi Sergei,
On Thu, Apr 13, 2017 at 10:19 PM, Sergei Shtylyov
<sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> wrote:
> Renesas RZ/G1E (R8A7745) is pin compatible with R-Car E2 (R8A7794),
> however it doesn't have several automotive specific peripherals.
> Annotate all the items that only exist on the R-Car SoCs and only
> supply the pin groups/functions existing on a given SoC (that required
> splitting of the AVB function)...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
>
> ---
> This patch is against the 'devel' branch of Linus Walleij's 'linux-pinctrl.git'
> repo plus R8A7794 PFC fix and R8A7743 PFC support patch...
>
> Changes in version 2:
> - fixed indentation to use tabs instead of spaces;
> - updated the PFC bindings.
Thanks for the update!
> --- linux-pinctrl.orig/drivers/pinctrl/sh-pfc/pfc-r8a7794.c
> +++ linux-pinctrl/drivers/pinctrl/sh-pfc/pfc-r8a7794.c
> @@ -110,10 +110,12 @@ enum {
> FN_I2C1_SDA_B, FN_D10, FN_HSCIF2_HSCK, FN_SCIF1_SCK_C, FN_IRQ6,
> FN_PWM5_C, FN_D11, FN_HSCIF2_HCTS_N, FN_SCIF1_RXD_C, FN_I2C1_SCL_D,
> FN_D12, FN_HSCIF2_HRTS_N, FN_SCIF1_TXD_C, FN_I2C1_SDA_D, FN_D13,
> - FN_SCIFA1_SCK, FN_TANS1, FN_PWM2_C, FN_TCLK2_B, FN_D14, FN_SCIFA1_RXD,
> - FN_IIC0_SCL_B, FN_D15, FN_SCIFA1_TXD, FN_IIC0_SDA_B, FN_A0,
> - FN_SCIFB1_SCK, FN_PWM3_B, FN_A1, FN_SCIFB1_TXD, FN_A3, FN_SCIFB0_SCK,
> - FN_A4, FN_SCIFB0_TXD, FN_A5, FN_SCIFB0_RXD, FN_PWM4_B, FN_TPUTO3_C,
> + FN_SCIFA1_SCK, FN_TANS1 /* R8A7794 only */, FN_PWM2_C, FN_TCLK2_B,
> + FN_D14, FN_SCIFA1_RXD, FN_IIC0_SCL_B,
> + FN_D15, FN_SCIFA1_TXD, FN_IIC0_SDA_B,
> + FN_A0, FN_SCIFB1_SCK, FN_PWM3_B, FN_A1, FN_SCIFB1_TXD,
> + FN_A3, FN_SCIFB0_SCK, FN_A4, FN_SCIFB0_TXD,
> + FN_A5, FN_SCIFB0_RXD, FN_PWM4_B, FN_TPUTO3_C,
I still have mixed feelings about adding all these annotations.
IMHO the groups and functions provide sufficient documentation, and not adding
the annotations means less code has to be changed now, and perhaps in the
future.
> @@ -123,77 +125,139 @@ enum {
> FN_A12, FN_MSIOF1_SS1, FN_SCIFA5_RXD_B, FN_A13, FN_MSIOF1_SS2,
> FN_SCIFA5_TXD_B, FN_A14, FN_MSIOF2_RXD, FN_HSCIF0_HRX_B, FN_DREQ1_N,
> FN_A15, FN_MSIOF2_TXD, FN_HSCIF0_HTX_B, FN_DACK1, FN_A16,
> - FN_MSIOF2_SCK, FN_HSCIF0_HSCK_B, FN_SPEEDIN, FN_VSP, FN_CAN_CLK_C,
> - FN_TPUTO2_B, FN_A17, FN_MSIOF2_SYNC, FN_SCIF4_RXD_E, FN_CAN1_RX_B,
> - FN_AVB_AVTP_CAPTURE_B, FN_A18, FN_MSIOF2_SS1, FN_SCIF4_TXD_E,
> - FN_CAN1_TX_B, FN_AVB_AVTP_MATCH_B, FN_A19, FN_MSIOF2_SS2, FN_PWM4,
> - FN_TPUTO2, FN_MOUT0, FN_A20, FN_SPCLK, FN_MOUT1,
> + FN_MSIOF2_SCK, FN_HSCIF0_HSCK_B, FN_SPEEDIN /* R8A7794 only */,
> + FN_VSP /* R8A7794 only */, FN_CAN_CLK_C, FN_TPUTO2_B,
> + FN_A17, FN_MSIOF2_SYNC, FN_SCIF4_RXD_E, FN_CAN1_RX_B,
> + FN_AVB_AVTP_CAPTURE_B /* R8A7794 only */,
> + FN_A18, FN_MSIOF2_SS1, FN_SCIF4_TXD_E, FN_CAN1_TX_B,
> + FN_AVB_AVTP_MATCH_B /* R8A7794 only */,
> + FN_A19, FN_MSIOF2_SS2, FN_PWM4, FN_TPUTO2, FN_MOUT0 /* R8A7794 only */,
> + FN_A20, FN_SPCLK, FN_MOUT1 /* R8A7794 only */,
Interestingly, the AVB_AVTP bits are marked "reserved" in revision 1.10
of the R-Car E2 user manual as well.
The only remnants are in Table 5.2, for GP5[11] and GP5[12].
> static const struct sh_pfc_pin pinmux_pins[] = {
> @@ -1660,6 +1898,7 @@ static const unsigned int avb_gmii_mux[]
> AVB_TX_EN_MARK, AVB_TX_ER_MARK, AVB_TX_CLK_MARK,
> AVB_COL_MARK,
> };
> +/* - AVB AVTP (R8A7794 only) ------------------------------------------------ */
> static const unsigned int avb_avtp_capture_pins[] = {
> RCAR_GP_PIN(5, 11),
> };
> @@ -3809,6 +4055,9 @@ static const char * const avb_groups[] =
> "avb_mdio",
> "avb_mii",
> "avb_gmii",
> +};
> +
> +static const char * const avb_avtp_groups[] = {
> "avb_avtp_capture",
> "avb_avtp_match",
> "avb_avtp_capture_b",
> @@ -4183,50 +4432,58 @@ static const char * const vin1_groups[]
> "vin1_clk",
> };
>
> -static const struct sh_pfc_function pinmux_functions[] = {
[...]
> +static const struct {
> + struct sh_pfc_function common[43];
> + struct sh_pfc_function r8a7794[1];
> +} pinmux_functions = {
[...]
> + .r8a7794 = {
> + SH_PFC_FUNCTION(avb_avtp),
> + }
This changes the user-visible name of the pinctrl function from "avb" to
"avb_avtp", which is part of the DT ABI.
Combined with the above, I'm inclined to not touch AVB_AVTP for now.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: [RFC 1/2] dt-bindings: add mmio-based syscon mux controller DT bindings
From: Peter Rosin @ 2017-04-20 11:57 UTC (permalink / raw)
To: Philipp Zabel, Rob Herring
Cc: Mark Rutland, Sakari Ailus, Steve Longerbeam,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <1492676048.2158.25.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 2017-04-20 10:14, Philipp Zabel wrote:
> 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 */
> };
> };
Why do you need three values for one register+field? The shift can be
implied from the mask, if the mask is pre-shifted. I.e. specifying a
mask of 0x60 in this case. What I'm I missing?
>>> + #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.
Yes, when talking about e.g. PWMs or GPIOs, there seem to be little
question that they can sit in their own nodes. I don't get the reluctance
to have MUXes in nodes of their own?
PWMs and GPIOs are controlled from one end and mostly used for something
completely different. Just like MUXes. At least there are many MUXes like
that. Agreed, there are also many MUXes where the MUX is tightly integrated
in some bigger function. But in this case, it appears that there is benefit
in moving the MUX to its own DT node and have the MUX consumer oblivious
of the details of the MUX. Why is that a problem?
Cheers,
peda
--
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/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Geert Uytterhoeven @ 2017-04-20 11:36 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda,
Kuninori Morimoto, Wolfram Sang, Rob Herring, Mark Rutland,
Linux-Renesas, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <3119026.3cPho1BBNv@avalon>
Hi Laurent,
On Thu, Apr 20, 2017 at 1:24 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 20 Apr 2017 12:55:28 Geert Uytterhoeven wrote:
>> On Thu, Apr 20, 2017 at 12:42 PM, Laurent Pinchart wrote:
>> > On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote:
>> >> On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote:
>> >>> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote:
>> >>>> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later:
>> >>>> - The following devices no longer exist on ES2.0, and are thus
>> >>>> removed:
>> >>>> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2.
>> >>>>
>> >>>> - The DU <-> VSPD topology is different on ES2.0, hence remove the
>> >>>> "vsps" property from the DU node until the driver can handle this.
>> >>>
>> >>> I think I'll need a different compatible string between ES1.x and ES2
>> >>> for the DU. It could make sense to move the whole DU node to *-es1.dtsi.
>> >>> We can decide about that later when I'll have a DU driver prototype
>> >>> ready.
>> >>
>> >> Why would you need a different compatible string?
>> >> Can't you use soc_device_match() to handle ES1.x SoCs?
>> >>
>> >> The different DU <-> VSPD topology is handled through the vsps property
>> >> in
>> >> DTS. Are the ports different, too? That can be handled in DTS.
>> >
>> > My point (not expressed clearly) was that, as I'll need a different vsps
>> > property, I can as well go for a different compatible string.
>>
>> Do you need a different vsps property?
>> AFAIK, the current array links each DU channel to a VSPD.
>> When a VSPD is shared between multiple channels, you can still link these
>> channels to the same VSPD.
>>
>> Or is my understanding incorrect?
>
> Do you mean listing the same VSP multiple times in the vsps array ? Yes, from
Yes, that's what I mean.
> a bindings point of view I think that would work too. That is, until we get a
OK.
> ES2.1 that will have a completely different hardware topology :-)
We'll fix that after we have received ES2.1 documentation...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3] pinctrl: sh-pfc: r8a7791: add R8A7743 support
From: Geert Uytterhoeven @ 2017-04-20 11:33 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Rob Herring, Mark Rutland, Laurent Pinchart, Geert Uytterhoeven,
Linus Walleij, devicetree@vger.kernel.org, Linux-Renesas,
linux-gpio@vger.kernel.org
In-Reply-To: <20170413201346.358012116@cogentembedded.com>
Hi Sergei,
On Thu, Apr 13, 2017 at 10:13 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Renesas RZ/G1M (R8A7743) is pin compatible with R-Car M2-W/N (R8A7791/3),
> however it doesn't have several automotive specific peripherals. Annotate
> all the items that only exist on the R-Car SoCs and only supply the pin
> groups/functions existing on a given SoC...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> This patch is against the 'devel' branch of Linus Walleij's 'linux-pinctrl.git'
> repo plus 4 R8A7791 PFC fixes and the "grand I2C rename" patch...
>
> Changes in version 3:
> - updated the PFC bindings.
>
> Changes in version 2:
> - switch to supplying exactly the groups/functions existing on a given SoC,
> update the patch descriptions accordingly;
> - resolved rejects due to the "grand I2C rename" patch being updated.
Thanks for the update!
> --- linux-pinctrl.orig/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
> +++ linux-pinctrl/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
> @@ -129,11 +129,12 @@ enum {
> FN_A9, FN_MSIOF1_SS2, FN_I2C0_SDA,
> FN_A10, FN_MSIOF1_TXD, FN_MSIOF1_TXD_D,
> FN_A11, FN_MSIOF1_RXD, FN_I2C3_SCL_D, FN_MSIOF1_RXD_D,
> - FN_A12, FN_FMCLK, FN_I2C3_SDA_D, FN_MSIOF1_SCK_D,
> - FN_A13, FN_ATAG0_N_C, FN_BPFCLK, FN_MSIOF1_SS1_D,
> - FN_A14, FN_ATADIR0_N_C, FN_FMIN, FN_FMIN_C, FN_MSIOF1_SYNC_D,
> - FN_A15, FN_BPFCLK_C,
> - FN_A16, FN_DREQ2_B, FN_FMCLK_C, FN_SCIFA1_SCK_B,
> + FN_A12, FN_FMCLK /* R8A779x only */, FN_I2C3_SDA_D, FN_MSIOF1_SCK_D,
> + FN_A13, FN_ATAG0_N_C, FN_BPFCLK /* R8A779x only */, FN_MSIOF1_SS1_D,
> + FN_A14, FN_ATADIR0_N_C, FN_FMIN /* R8A779x only */,
> + FN_FMIN_C /* R8A779x only */, FN_MSIOF1_SYNC_D,
> + FN_A15, FN_BPFCLK_C /* R8A779x only */,
> + FN_A16, FN_DREQ2_B, FN_FMCLK_C /* R8A779x only */, FN_SCIFA1_SCK_B,
I still have mixed feelings about adding all these annotations.
IMHO the groups and functions provide sufficient documentation, and not adding
the annotations means less code has to be changed now, and perhaps in the
future.
More about that in the r8a7794 patch...
> @@ -4419,359 +4506,367 @@ static const unsigned int vin2_clk_mux[]
> VI2_CLK_MARK,
> };
>
> -static const struct sh_pfc_pin_group pinmux_groups[] = {
> - SH_PFC_PIN_GROUP(adi_common),
> - SH_PFC_PIN_GROUP(adi_chsel0),
[...]
> - SH_PFC_PIN_GROUP(vin2_clkenb),
> - SH_PFC_PIN_GROUP(vin2_clk),
> +static const struct {
> + struct sh_pfc_pin_group common[341];
> + struct sh_pfc_pin_group r8a779x[9];
> +} pinmux_groups = {
Thanks, that's exactly what I had in mind!
> + .common = {
> + SH_PFC_PIN_GROUP(audio_clk_a),
> + SH_PFC_PIN_GROUP(audio_clk_b),
[...]
> + SH_PFC_PIN_GROUP(i2c4),
> + SH_PFC_PIN_GROUP(i2c4_b),
> + SH_PFC_PIN_GROUP(i2c4_c),
> + SH_PFC_PIN_GROUP(i2c8),
> + SH_PFC_PIN_GROUP(i2c8_b),
> + SH_PFC_PIN_GROUP(i2c8_c),
What happened to i2c7? (revealed by "git show -b").
> + SH_PFC_PIN_GROUP(i2c8),
> + SH_PFC_PIN_GROUP(i2c8_b),
> + SH_PFC_PIN_GROUP(i2c8_c),
[...]
> + SH_PFC_PIN_GROUP(vin2_clkenb),
> + SH_PFC_PIN_GROUP(vin2_clk),
> + },
> + .r8a779x = {
> + SH_PFC_PIN_GROUP(adi_common),
> + SH_PFC_PIN_GROUP(adi_chsel0),
> + SH_PFC_PIN_GROUP(adi_chsel1),
> + SH_PFC_PIN_GROUP(adi_chsel2),
> + SH_PFC_PIN_GROUP(adi_common_b),
> + SH_PFC_PIN_GROUP(adi_chsel0_b),
> + SH_PFC_PIN_GROUP(adi_chsel1_b),
> + SH_PFC_PIN_GROUP(adi_chsel2_b),
> + SH_PFC_PIN_GROUP(mlb_3pin),
> + }
Given the relatively small additional set of data needed to support
r8a779[13], it's probably not worth protecting it with #if
defined(CONFIG_PINCTRL_PFC_R8A7791) || defined(CONFIG_PINCTRL_PFC_R8A7793).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Laurent Pinchart @ 2017-04-20 11:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda,
Kuninori Morimoto, Wolfram Sang, Rob Herring, Mark Rutland,
Linux-Renesas, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAMuHMdWmvhZjxKfEdGJ3d_w0d2s2kK+8iW1tsEM584qZc+dVEQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Geert,
On Thursday 20 Apr 2017 12:55:28 Geert Uytterhoeven wrote:
> On Thu, Apr 20, 2017 at 12:42 PM, Laurent Pinchart wrote:
> > On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote:
> >> On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote:
> >>> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote:
> >>>> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later:
> >>>> - The following devices no longer exist on ES2.0, and are thus
> >>>> removed:
> >>>> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2.
> >>>>
> >>>> - The DU <-> VSPD topology is different on ES2.0, hence remove the
> >>>> "vsps" property from the DU node until the driver can handle this.
> >>>
> >>> I think I'll need a different compatible string between ES1.x and ES2
> >>> for the DU. It could make sense to move the whole DU node to *-es1.dtsi.
> >>> We can decide about that later when I'll have a DU driver prototype
> >>> ready.
> >>
> >> Why would you need a different compatible string?
> >> Can't you use soc_device_match() to handle ES1.x SoCs?
> >>
> >> The different DU <-> VSPD topology is handled through the vsps property
> >> in
> >> DTS. Are the ports different, too? That can be handled in DTS.
> >
> > My point (not expressed clearly) was that, as I'll need a different vsps
> > property, I can as well go for a different compatible string.
>
> Do you need a different vsps property?
> AFAIK, the current array links each DU channel to a VSPD.
> When a VSPD is shared between multiple channels, you can still link these
> channels to the same VSPD.
>
> Or is my understanding incorrect?
Do you mean listing the same VSP multiple times in the vsps array ? Yes, from
a bindings point of view I think that would work too. That is, until we get a
ES2.1 that will have a completely different hardware topology :-)
> >> The main reason why I kept the DU node in r8a7795.dtsi is that the board
> >> DTS refers to it. Sharing board DTS means there needs to be at least a
> >> placeholder node for the DU in r8a7795.dtsi, unless you want to keep on
> >> shuffling board overrides around.
> >
> > As the ports are identical it makes sense to share the same board DTS, I
> > agree with you. We could override the compatible string in
> > r8a7795-es1.dtsi and leave it blank in r8a7795.dtsi for now, as there's
> > no driver support for ES2.0. That's a bit of a workaround as it shouldn't
> > matter to DT whether driver support is available or not. On the other
> > hand, leaving the vsps property out is a workaround too.
> >
> > The current driver will fail probing if the number of VSPs is different
> > than the number of CRTCs, so I believe you can keep the vsps property in
> > r8a7795.dtsi with 3 VSPS without causing any problem. However, there's no
> > DT bindings for the H3 ES2.0 DU yet, so we would end up merging DT
> > without bindings, which is not good. I think that regardless of how we
> > proceed, keeping the DU node in the ES2.0 .dtsi will be a violation of
> > that policy.
>
> What does the current driver do if the number of VSPs is the same as the
> number of CRTCs, but some VSPs are listed more than once?
> I guess it will break in a subtle way, instead of refusing to probe?
Correct, it will be messy.
--
Regards,
Laurent Pinchart
--
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 v2] pinctrl: sh-pfc: r8a7794: add R8A7745 support
From: Geert Uytterhoeven @ 2017-04-20 11:14 UTC (permalink / raw)
To: Rob Herring
Cc: Sergei Shtylyov, Mark Rutland, Laurent Pinchart,
Geert Uytterhoeven, Linus Walleij,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170419224646.wwjerpgnidvk4fkh@rob-hp-laptop>
Hi Rob,
On Thu, Apr 20, 2017 at 12:46 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Apr 13, 2017 at 11:19:24PM +0300, Sergei Shtylyov wrote:
>> Renesas RZ/G1E (R8A7745) is pin compatible with R-Car E2 (R8A7794),
>> however it doesn't have several automotive specific peripherals.
>
> Is a single space between words really so hard for you? You've been told
> to write proper sentences multiple times.
>
> Yes, kernel developers suffer from OCD. Sorry.
No problem, my OCD corrects the spacing while applying...
>> Annotate all the items that only exist on the R-Car SoCs and only
>> supply the pin groups/functions existing on a given SoC (that required
>> splitting of the AVB function)...
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
>>
>> ---
>> This patch is against the 'devel' branch of Linus Walleij's 'linux-pinctrl.git'
>> repo plus R8A7794 PFC fix and R8A7743 PFC support patch...
>>
>> Changes in version 2:
>> - fixed indentation to use tabs instead of spaces;
>> - updated the PFC bindings.
>>
>> Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt | 1
>
> But given it's a one line DT change:
Which is always correct ;-)
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Geert Uytterhoeven @ 2017-04-20 10:55 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mark Rutland, devicetree@vger.kernel.org, Geert Uytterhoeven,
Kuninori Morimoto, Yoshihiro Shimoda, Magnus Damm, Rob Herring,
Wolfram Sang, Linux-Renesas, Simon Horman,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1714563.qChlbIjNcO@avalon>
Hi Laurent,
On Thu, Apr 20, 2017 at 12:42 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote:
>> On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote:
>> > On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote:
>> >> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later:
>> >> - The following devices no longer exist on ES2.0, and are thus removed:
>> >> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2.
>> >>
>> >> - The DU <-> VSPD topology is different on ES2.0, hence remove the
>> >> "vsps" property from the DU node until the driver can handle this.
>> >
>> > I think I'll need a different compatible string between ES1.x and ES2 for
>> > the DU. It could make sense to move the whole DU node to *-es1.dtsi. We
>> > can decide about that later when I'll have a DU driver prototype ready.
>>
>> Why would you need a different compatible string?
>> Can't you use soc_device_match() to handle ES1.x SoCs?
>>
>> The different DU <-> VSPD topology is handled through the vsps property in
>> DTS. Are the ports different, too? That can be handled in DTS.
>
> My point (not expressed clearly) was that, as I'll need a different vsps
> property, I can as well go for a different compatible string.
Do you need a different vsps property?
AFAIK, the current array links each DU channel to a VSPD.
When a VSPD is shared between multiple channels, you can still link these
channels to the same VSPD.
Or is my understanding incorrect?
>> The main reason why I kept the DU node in r8a7795.dtsi is that the board DTS
>> refers to it. Sharing board DTS means there needs to be at least a
>> placeholder node for the DU in r8a7795.dtsi, unless you want to keep on
>> shuffling board overrides around.
>
> As the ports are identical it makes sense to share the same board DTS, I agree
> with you. We could override the compatible string in r8a7795-es1.dtsi and
> leave it blank in r8a7795.dtsi for now, as there's no driver support for
> ES2.0. That's a bit of a workaround as it shouldn't matter to DT whether
> driver support is available or not. On the other hand, leaving the vsps
> property out is a workaround too.
>
> The current driver will fail probing if the number of VSPs is different than
> the number of CRTCs, so I believe you can keep the vsps property in
> r8a7795.dtsi with 3 VSPS without causing any problem. However, there's no DT
> bindings for the H3 ES2.0 DU yet, so we would end up merging DT without
> bindings, which is not good. I think that regardless of how we proceed,
> keeping the DU node in the ES2.0 .dtsi will be a violation of that policy.
What does the current driver do if the number of VSPs is the same as the
number of CRTCs, but some VSPs are listed more than once?
I guess it will break in a subtle way, instead of refusing to probe?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH V5 7/7] ARM: ZTE: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 10:55 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.1492685450.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 316dc713268c..d83bf789c864 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 V5 6/7] ARM: uniphier: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 10:55 UTC (permalink / raw)
To: arm, Rob Herring, Mark Rutland, Masahiro Yamada
Cc: linaro-kernel, linux-arm-kernel, linux-pm, Rafael Wysocki,
Viresh Kumar, Krzysztof Kozlowski, Rob Herring, devicetree,
linux-kernel
In-Reply-To: <cover.1492685450.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 df07b555cbed..81605e3a5e0a 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 58c3e2f35706..bc5a1afedee8 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 151c043b4835..4beb67b4535c 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 6193f11acb78..adde6a10de20 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 V5 5/7] ARM: sun8i: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 10:55 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.1492685450.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-sinlinx-sina33.dts | 4 ++--
arch/arm/boot/dts/sun8i-a33.dtsi | 30 +++++++++++++-------------
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index 9b620cc1d5f1..8a0b42a2c2da 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -88,13 +88,13 @@
};
&cpu0_opp_table {
- opp@1104000000 {
+ opp-1104000000 {
opp-hz = /bits/ 64 <1104000000>;
opp-microvolt = <1320000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1320000>;
clock-latency-ns = <244144>; /* 8 32k periods */
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 61de52b9940d..6a33f840d981 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -50,73 +50,73 @@
compatible = "operating-points-v2";
opp-shared;
- opp@120000000 {
+ opp-120000000 {
opp-hz = /bits/ 64 <120000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp@240000000 {
+ opp-240000000 {
opp-hz = /bits/ 64 <240000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp@312000000 {
+ opp-312000000 {
opp-hz = /bits/ 64 <312000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp@408000000 {
+ opp-408000000 {
opp-hz = /bits/ 64 <408000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp@480000000 {
+ opp-480000000 {
opp-hz = /bits/ 64 <480000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp@504000000 {
+ opp-504000000 {
opp-hz = /bits/ 64 <504000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp@600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp@648000000 {
+ opp-648000000 {
opp-hz = /bits/ 64 <648000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp@720000000 {
+ opp-720000000 {
opp-hz = /bits/ 64 <720000000>;
opp-microvolt = <1100000>;
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@912000000 {
+ opp-912000000 {
opp-hz = /bits/ 64 <912000000>;
opp-microvolt = <1200000>;
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 */
@@ -164,15 +164,15 @@
mali_opp_table: gpu-opp-table {
compatible = "operating-points-v2";
- opp@144000000 {
+ opp-144000000 {
opp-hz = /bits/ 64 <144000000>;
};
- opp@240000000 {
+ opp-240000000 {
opp-hz = /bits/ 64 <240000000>;
};
- opp@384000000 {
+ opp-384000000 {
opp-hz = /bits/ 64 <384000000>;
};
};
--
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 V5 4/7] ARM: pxa: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 10:55 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.1492685450.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 V5 3/7] ARM: exynos: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 10:55 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.1492685450.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 e6e62103a71f..768fb075b1fd 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -343,15 +343,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>;
};
@@ -361,13 +361,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>;
};
};
@@ -376,10 +376,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>;
};
};
@@ -388,10 +388,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>;
};
};
@@ -400,13 +400,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>;
};
};
@@ -415,13 +415,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 cc69466f17c0..7ff03a7e8fb9 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>;
@@ -442,23 +442,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>;
};
@@ -468,16 +468,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>;
};
};
@@ -534,19 +534,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>;
};
@@ -556,10 +556,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>;
};
};
@@ -568,10 +568,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>;
};
};
@@ -580,10 +580,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 83b3899d228d..0db0bcf8da36 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 V5 2/7] ARM: TI: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 10:55 UTC (permalink / raw)
To: arm, Benoît Cousson, Tony Lindgren, 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, linux-omap
In-Reply-To: <cover.1492685450.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/am335x-boneblack.dts | 2 +-
arch/arm/boot/dts/am33xx.dtsi | 20 ++++++++++----------
arch/arm/boot/dts/am4372.dtsi | 10 +++++-----
arch/arm/boot/dts/dra7.dtsi | 4 ++--
5 files changed, 28 insertions(+), 28 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/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
index 935ed17d22e4..d154d3133c16 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -22,7 +22,7 @@
* BeagleBone Blacks have PG 2.0 silicon which is guaranteed
* to support 1GHz OPP so enable it for PG 2.0 on this board.
*/
- oppnitro@1000000000 {
+ oppnitro-1000000000 {
opp-supported-hw = <0x06 0x0100>;
};
};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9e242943dcec..bdacb3dd689c 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -64,64 +64,64 @@
* because the 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 176e09e9a45e..e5b061469bf8 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -59,32 +59,32 @@
compatible = "operating-points-v2-ti-cpu";
syscon = <&scm_conf>;
- 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>;
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 57892f264cea..25908dd338ee 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -99,14 +99,14 @@
compatible = "operating-points-v2-ti-cpu";
syscon = <&scm_wkup>;
- opp_nom@1000000000 {
+ opp_nom-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1060000 850000 1150000>;
opp-supported-hw = <0xFF 0x01>;
opp-suspend;
};
- opp_od@1176000000 {
+ opp_od-1176000000 {
opp-hz = /bits/ 64 <1176000000>;
opp-microvolt = <1160000 885000 1160000>;
opp-supported-hw = <0xFF 0x02>;
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
* [PATCH V5 1/7] PM / OPP: Use - instead of @ for DT entries
From: Viresh Kumar @ 2017-04-20 10:55 UTC (permalink / raw)
To: arm-DgEjT+Ai2ygdnm+yROfE0A, Viresh Kumar, Nishanth Menon,
Stephen Boyd
Cc: linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Rafael Wysocki, Viresh Kumar,
Krzysztof Kozlowski, Masahiro Yamada, Mark Rutland, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1492685450.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: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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
--
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
* Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle
From: Frank Rowand @ 2017-04-20 10:44 UTC (permalink / raw)
To: Tyrel Datwyler, Steven Rostedt
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
nfont-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
mpe-Gsx/Oe8HsFggBc27wqDAHg, mingo-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <58F81EF4.5070304-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 04/19/17 19:37, Frank Rowand wrote:
> On 04/19/17 11:45, Tyrel Datwyler wrote:
>> On 04/18/2017 07:49 PM, Steven Rostedt wrote:
>>> On Tue, 18 Apr 2017 18:42:32 -0700
>>> Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>
>>>> And of course the other issue with using tracepoints is the extra space
>>>> required to hold the tracepoint info. With the pr_debug() approach, the
>>>> space usage can be easily removed for a production kernel via a config
>>>> option.
>>>
>>> Now if you are saying you want to be able to enable debugging without
>>> the tracing infrastructure I would agree. As the tracing infrastructure
>>> is large. But I'm working on shrinking it more.
>>
>> The primary consumers of OF_DYNAMIC seem to be pseries and powernv where
>> we are generally going to see the trace infrastructure enabled by
>> default in production.
>
> Another primary consumer will be overlays for ARM expansion boards. Still
> a work in progress.
And dynamic configuration for the FPGA folks.
> -Frank
>
>>
>> -Tyrel
>>
>>>
>>>>
>>>> Tracepoints are wonderful technology, but not always the proper tool to
>>>> use for debug info.
>>>
>>> But if you are going to have tracing enabled regardless, adding a few
>>> more tracepoints isn't going to make the difference.
>>>
>>> -- Steve
>>>
>>>>
>>>>> If Rob wants to convert printk() style data to trace data (and I can't
>>>>> convince him otherwise) then I will have further comments on this specific
>>>>> patch.
>>>>>
>>
>> .
>>
>
> .
>
--
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/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Laurent Pinchart @ 2017-04-20 10:42 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda,
Kuninori Morimoto, Wolfram Sang, Rob Herring, Mark Rutland,
Linux-Renesas, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAMuHMdXOzyo+kzaGAXp+jZTtUejYyXCQzezo+SmvNVQuEC9=_Q@mail.gmail.com>
Hi Geert,
On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote:
> On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote:
> > On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote:
> >> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later:
> >> - The following devices no longer exist on ES2.0, and are thus removed:
> >> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2.
> >>
> >> - The DU <-> VSPD topology is different on ES2.0, hence remove the
> >> "vsps" property from the DU node until the driver can handle this.
> >
> > I think I'll need a different compatible string between ES1.x and ES2 for
> > the DU. It could make sense to move the whole DU node to *-es1.dtsi. We
> > can decide about that later when I'll have a DU driver prototype ready.
>
> Why would you need a different compatible string?
> Can't you use soc_device_match() to handle ES1.x SoCs?
>
> The different DU <-> VSPD topology is handled through the vsps property in
> DTS. Are the ports different, too? That can be handled in DTS.
My point (not expressed clearly) was that, as I'll need a different vsps
property, I can as well go for a different compatible string.
> The main reason why I kept the DU node in r8a7795.dtsi is that the board DTS
> refers to it. Sharing board DTS means there needs to be at least a
> placeholder node for the DU in r8a7795.dtsi, unless you want to keep on
> shuffling board overrides around.
As the ports are identical it makes sense to share the same board DTS, I agree
with you. We could override the compatible string in r8a7795-es1.dtsi and
leave it blank in r8a7795.dtsi for now, as there's no driver support for
ES2.0. That's a bit of a workaround as it shouldn't matter to DT whether
driver support is available or not. On the other hand, leaving the vsps
property out is a workaround too.
The current driver will fail probing if the number of VSPs is different than
the number of CRTCs, so I believe you can keep the vsps property in
r8a7795.dtsi with 3 VSPS without causing any problem. However, there's no DT
bindings for the H3 ES2.0 DU yet, so we would end up merging DT without
bindings, which is not good. I think that regardless of how we proceed,
keeping the DU node in the ES2.0 .dtsi will be a violation of that policy.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 1/2] extcon: cros-ec: Add extcon-cros-ec driver to support display out.
From: Enric Balletbo i Serra @ 2017-04-20 10:16 UTC (permalink / raw)
To: Chanwoo Choi, MyungJoo Ham, Rob Herring
Cc: Lee Jones, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Benson Leung, Olof Johansson
In-Reply-To: <58E44698.5020605-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On 05/04/17 03:21, Chanwoo Choi wrote:
> Hi Enric,
>
> On 2017년 03월 02일 16:29, Chanwoo Choi wrote:
>> Hi,
>>
>> On 2017년 03월 01일 20:19, Enric Balletbo i Serra wrote:
>>> From: Benson Leung <bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>>>
>>> This is the driver for the USB Type C cable detection mechanism
>>> built into the ChromeOS Embedded Controller on systems that
>>> have USB Type-C ports.
>>>
>>> At present, this allows for the presence of display out, but in
>>> future, it may also be used to notify host and device type cables
>>> and the presence of power.
>>>
>>> Signed-off-by: Benson Leung <bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
>>> ---
>>> Changes since v1:
>>> Requested by Chanwoo Choi
>>> - Rename files changing _ for -
>>> - Remove the unneeded blank line on bottom of header.
>>> - Remove kobject.h and cros_ec_commands.h includes.
>>> - Remove the debug message as is not necessary.
>>> - Use the tab for indentation instead of space for if sentence.
>>> - Define each variable on different lines when the variables should be
>>> initialized.
>>> - Remove EXTCON_USB and EXTCON_USB_HOST as are not really used for now.
>>> - Add one blank line to split out between state and property setting.
>>> - Add the author information (header and module)
>>>
>>> Enric Balletbo
>>> - As Rob suggested to rename the compatible name to something indicating that
>>> is USB Type C related I also renamed the file names, extcon-cros-ec ->
>>> extcon-usbc-cros-ec, I think it's more clear.
>>>
>>> drivers/extcon/Kconfig | 7 +
>>> drivers/extcon/Makefile | 1 +
>>> drivers/extcon/extcon-usbc-cros-ec.c | 415 +++++++++++++++++++++++++++++++++++
>>> include/linux/mfd/cros_ec_commands.h | 75 +++++++
>>> 4 files changed, 498 insertions(+)
>>> create mode 100644 drivers/extcon/extcon-usbc-cros-ec.c
>>>
>>
>> Looks good to me.
>> Acked-by: Chanwoo Choi <cw00.chio-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>
>> I think this patch should be handled with patches[1].
>> [1] https://lkml.org/lkml/2017/2/14/655
>>
>> I think that one maintainer among following subsystems
>> (mfd, chrome h/w platform, rtc and extcon)
>> will apply their git repository, and then one maintainer
>> will send the pull request of immutable branch for these patches.
>>
>
> As I mentioned, these patch should be handled with related patches[1].
> [1] https://lkml.org/lkml/2017/2/14/655
>
> So, I can't apply these patch on extcon git because there is a merge conflict
> and we should handle these patches with immutable branch between subsystem maintainer.
>
> The v4.11-rc5 was released, if you want to apply this patch to the v4.12-rc1,
> please take care of these patches.
>
CC'ied : Olof Johansson
Olof, Benson,
Could at least the following patch in this series [1] picked as soon as possible
if it's ok.
9630769 New [01/13] mfd: cros_ec: Add helper for event notifier
This specific patch is blocking this and others like the rtc-cros-ec to land and
the series were send some time ago without received bad feedback.
[1] https://lkml.org/lkml/2017/3/17/321
Many thanks,
Enric
--
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 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-04-20 9:52 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rafael Wysocki, ulf.hansson, Kevin Hilman, Viresh Kumar,
Nishanth Menon, Stephen Boyd, linaro-kernel, linux-pm,
linux-kernel, Vincent Guittot, robh+dt, lina.iyer, rnayak,
devicetree
In-Reply-To: <34c7fb69-0324-ad06-678d-8726064e9a18@arm.com>
On 20-04-17, 10:43, Sudeep Holla wrote:
> Just that the term performance is closely related to frequency, it needs
> to be explicit on what *exactly* it means. As it stands now,
> it can be used for OPP as I explain which controls both but as you
> clarify that's not what it's designed for.
We are talking about active states of a power domain here and
*performance* is the best word I got. And yes we can still have
frequency as a configurable here, just that current platforms don't
have it.
> I am not sure if choosing highest performance point makes it difficult
> to fit it in regulator framework. It could be some configuration.
I was just pointing out a difference :)
> Also IIUC the actual programming is done in the firmware in this case
> and I fail to see how that adds lot of platform code.
Oh I meant that for converting general regulator only cases to OPP. No
firmware was involved there.
--
viresh
^ permalink raw reply
* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Sudeep Holla @ 2017-04-20 9:51 UTC (permalink / raw)
To: Ulf Hansson, Viresh Kumar
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 09: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?
>
No, I am saying that it has to be modeled as regulators or some kind of
advanced regulators. I am against modeling it as some new feature and
using similar terminology that are quite close to OPP/CPPC in which case
it's quite hard not to misunderstand the concepts and eventually use
these bindings incorrectly.
> To me there is no doubt, these regulators is exactly the definition of
> PM domain regulators.
>
+1
> 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.
>
I completely agree with you on all the above points. I am against the
performance state terminology. Since the regulators and OPP are already
defined in the bindings, all we need to explicitly state(if not already)
is that there are hierarchical.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Sudeep Holla @ 2017-04-20 9:43 UTC (permalink / raw)
To: Viresh Kumar
Cc: Sudeep Holla, Rafael Wysocki, ulf.hansson, Kevin Hilman,
Viresh Kumar, Nishanth Menon, Stephen Boyd, linaro-kernel,
linux-pm, linux-kernel, Vincent Guittot, robh+dt, lina.iyer,
rnayak, devicetree
In-Reply-To: <20170420052533.GF5436@vireshk-i7>
On 20/04/17 06:25, Viresh Kumar wrote:
> On 19-04-17, 14:58, Sudeep Holla wrote:
>> On 19/04/17 12:47, Viresh Kumar wrote:
>>> On 18-04-17, 17:01, Sudeep Holla wrote:
[...]
>>
>> Yes, I completely agree. I am not saying the direction is wrong. I
>> am saying it's confusing and binding needs to be more clear.
>
> What exactly isn't clear? (Yeah, there had been lots of emails and I
> want to know what improvements are you looking for).
>
Just that the term performance is closely related to frequency, it needs
to be explicit on what *exactly* it means. As it stands now,
it can be used for OPP as I explain which controls both but as you
clarify that's not what it's designed for.
>> 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.
>
I am not sure if choosing highest performance point makes it difficult
to fit it in regulator framework. It could be some configuration.
Also IIUC the actual programming is done in the firmware in this case
and I fail to see how that adds lot of platform code.
> 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.
>
Yes I understand that.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Geert Uytterhoeven @ 2017-04-20 9:36 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda,
Kuninori Morimoto, Wolfram Sang, Rob Herring, Mark Rutland,
Linux-Renesas, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1612430.SNEha5n02K@avalon>
Hi Laurent,
On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote:
>> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later:
>> - The following devices no longer exist on ES2.0, and are thus removed:
>> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2.
>> - The DU <-> VSPD topology is different on ES2.0, hence remove the
>> "vsps" property from the DU node until the driver can handle this.
>
> I think I'll need a different compatible string between ES1.x and ES2 for the
> DU. It could make sense to move the whole DU node to *-es1.dtsi. We can decide
> about that later when I'll have a DU driver prototype ready.
Why would you need a different compatible string?
Can't you use soc_device_match() to handle ES1.x SoCs?
The different DU <-> VSPD topology is handled through the vsps property in DTS.
Are the ports different, too? That can be handled in DTS.
The main reason why I kept the DU node in r8a7795.dtsi is that the board DTS
refers to it. Sharing board DTS means there needs to be at least a
placeholder node for the DU in r8a7795.dtsi, unless you want to keep on
shuffling board overrides around.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* 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
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