* [patch v2 0/1 - resend] Introduce Device Tree bindings for Mellanox programming devices
@ 2017-08-03 12:04 Vadim Pasternak
2017-08-03 12:04 ` [patch v2 1/1 - resend] Documentation: dt-bindings: Add " Vadim Pasternak
0 siblings, 1 reply; 4+ messages in thread
From: Vadim Pasternak @ 2017-08-03 12:04 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, pavel-+ZI9xUNit7I,
j.anaszewski-Sze3O3UU22JBDgjK7y7TUQ,
rpurdie-Fm38FmjxZ/leoWH0uzbU5w, linux-leds-u79uwXL29TY76Z2rM5mHXA,
jiri-rHqAuBHg3fBzbRFIqnYvSA,
jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w, Vadim Pasternak
This patch related to the previously sent:
[patch v3 1/2] mfd: Add Mellanox regmap core driver
Vadim Pasternak (1):
Documentation: dt-bindings: Add Device Tree bindings for Mellanox
programming devices
.../devicetree/bindings/mfd/mellanox,mlxreg-core | 346 +++++++++++++++++++++
1 file changed, 346 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/mellanox,mlxreg-core
--
2.1.4
--
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 [flat|nested] 4+ messages in thread
* [patch v2 1/1 - resend] Documentation: dt-bindings: Add Device Tree bindings for Mellanox programming devices
2017-08-03 12:04 [patch v2 0/1 - resend] Introduce Device Tree bindings for Mellanox programming devices Vadim Pasternak
@ 2017-08-03 12:04 ` Vadim Pasternak
2017-08-10 17:40 ` Rob Herring
0 siblings, 1 reply; 4+ messages in thread
From: Vadim Pasternak @ 2017-08-03 12:04 UTC (permalink / raw)
To: robh+dt
Cc: devicetree, lee.jones, pavel, j.anaszewski, rpurdie, linux-leds,
jiri, jacek.anaszewski, Vadim Pasternak
The mlxreg a multifunction device driver handling LEDs, events, exposing
through sysfs reset signal, and reset causes info. These components share
a common register space.
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
---
.../devicetree/bindings/mfd/mellanox,mlxreg-core | 346 +++++++++++++++++++++
1 file changed, 346 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/mellanox,mlxreg-core
diff --git a/Documentation/devicetree/bindings/mfd/mellanox,mlxreg-core b/Documentation/devicetree/bindings/mfd/mellanox,mlxreg-core
new file mode 100644
index 0000000..a90933e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mellanox,mlxreg-core
@@ -0,0 +1,346 @@
+Mellanox programmable device control.
+-------------------------------------
+This binding defines the device control interface over I2C bus for Mellanox BMC
+based switches.
+
+Required properties:
+- compatible = "mellanox,mlxreg-i2c",
+ "mellanox,mlxreg-i2c-16",
+ "mellanox,mlxreg-core";
+- #address-cells : must be 1;
+- #size-cells : must be 0;
+- reg : I2C address;
+
+Optional properties:
+- interrupt-parent : phandle of parent interrupt controller;
+- interrupts : interrupt line;
+- deferred - I2C deferred bus phandle;
+ For example, for the case when device attached to I2C bus number 4
+ performs dynamic attachment of device to bus 12 upon some event.
+ Due to this reason bus 4 is enforced to be activated after bus 12;
+- cell - top aggregation register offset;
+- mask - top aggregation register mask;
+- psu - power supply unit nodes:
+ - aggr_mask - effective bit in aggregation mask;
+ - reg - register offset for all group members;
+ - mask - register mask;
+ - phandles - list of relevant device nodes;
+- fan - fan unit nodes:
+ - aggr_mask - effective bit in aggregation mask;
+ - reg - register offset for all group members;
+ - mask - register mask;
+ - phandles - list of relevant device nodes;
+- pwr - power cable nodes.
+ - aggr_mask - effective bit in aggregation mask;
+ - reg - register offset for all group members;
+ - mask - register mask;
+ - phandles - list of relevant device nodes;
+- host - host side nodes (CPU host side for BMC):
+ - aggr_mask - effective bit in aggregation mask;
+ - reg - register offset for all group members;
+ - mask - register mask;
+ - phandles - list of relevant device nodes;
+- asic - asic nodes.
+ - aggr_mask - effective bit in aggregation mask;
+ - regs - register offsets array per group member;
+ - masks = register masks array per group member;
+ - phandles - list of relevant device nodes;
+- reset - reset nodes:
+ - #address-cells : must be 1;
+ - #size-cells : must be 0;
+ - reset_name - reset control node:
+ - reg - register offset;
+ - mask - attribute mask;
+- cause - reset cause nodes:
+ - #address-cells : must be 1;
+ - #size-cells : must be 0;
+ - cause_name - cause info node:
+ - reg - register offset;
+ - mask - attribute mask;
+- mux - mux nodes:
+ - #address-cells : must be 1;
+ - #size-cells : must be 0;
+ - mux_name - mux control node:
+ - reg - register offset;
+ - mask - attribute mask;
+ - bit - effective bit;
+- gprw - general purpose register nodes:
+ - #address-cells : must be 1;
+ - #size-cells : must be 0;
+ - gprw_name - general purpose read-write register;
+ - reg - register offset;
+ - mask - attribute mask;
+- gpro - general purpose register nodes:
+ - #address-cells : must be 1;
+ - #size-cells : must be 0;
+ - gpro_name - general purpose read only register.
+ - reg - register offset.
+ - mask - attribute mask.
+- led - led nodes:
+ - #address-cells : must be 1;
+ - #size-cells : must be 0;
+ - led_name-color - led control node:
+ - label - symbolic name;
+ - reg - register offset;
+ - mask - attribute mask;
+
+Example:
+ mlxcpld-mng-ctrl@71 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&gpio>;
+ interrupts = <ASPEED_GPIO(S, 1) 2>;
+ compatible = "mellanox,mlxcpld-ctrl-i2c";
+ reg = <0x71>;
+ deferred = <&i2c6>;
+ cell = <0x3a>;
+ mask = <0x4c>;
+
+ psu {
+ aggr_mask = <0x08>;
+ reg = <0x58>;
+ mask = <0x03>;
+ phandles = <&psu1_eeprom &psu2_eeprom>;
+ };
+
+ pwr {
+ aggr_mask = <0x08>;
+ reg = <0x64>;
+ mask = <0x03>;
+ phandles = <&psu1_ctrl &psu2_ctrl>;
+ };
+
+ fan {
+ aggr_mask = <0x40>;
+ reg = <0x88>;
+ mask = <0x0f>;
+ phandles = <&fan1_eeprom &fan2_eeprom &fan3_eeprom
+ &fan4_eeprom>;
+ };
+
+ mux {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ uart_sel {
+ reg = <0x30>;
+ mask = <0xef>;
+ bit = <0x00>;
+ };
+ spi_burn_bios_ci {
+ reg = <0x32>;
+ mask = <0xfe>;
+ bit = <0x00>;
+ of-phandle = <&spi2>;
+ };
+ spi_burn_ncsi {
+ reg = <0x32>;
+ mask = <0xfd>;
+ bit = <0x00>;
+ of-phandle = <&spi2>;
+ };
+ bmc_uart_en {
+ reg = <0x32>;
+ mask = <0xdf>;
+ bit = <0x00>;
+ };
+ safe_bios1 {
+ reg = <0x35>;
+ mask = <0xfb>;
+ bit = <0x01>;
+ };
+ safe_bios2 {
+ reg = <0x35>;
+ mask = <0xf7>;
+ bit = <0x01>;
+ };
+ safe_bios_disable {
+ reg = <0x35>;
+ mask = <0xdf>;
+ bit = <0x01>;
+ };
+ };
+
+ led {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status-green {
+ reg = <0x20>;
+ mask = <0xf0>;
+ };
+ status-red {
+ reg = <0x20>;
+ mask = <0xf0>;
+ };
+ status-amber {
+ reg = <0x20>;
+ mask = <0xf0>;
+ };
+ fan1-green {
+ reg = <0x21>;
+ mask = <0xf0>;
+ };
+ fan1-red {
+ reg = <0x21>;
+ mask = <0xf0>;
+ };
+ fan2-green {
+ reg = <0x21>;
+ mask = <0x0f>;
+ };
+ fan2-red {
+ reg = <0x21>;
+ mask = <0x0f>;
+ };
+ fan3-green {
+ reg = <0x22>;
+ mask = <0xf0>;
+ };
+ fan3-red {
+ label = "fan3:red";
+ reg = <0x22>;
+ mask = <0xf0>;
+ };
+ fan4-green {
+ reg = <0x22>;
+ mask = <0x0f>;
+ };
+ fan4-red {
+ reg = <0x22>;
+ mask = <0x0f>;
+ };
+ };
+
+ reset {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bmc_reset_soft {
+ reg = <0x17>;
+ mask = <0xfd>;
+ };
+ system_reset_hard {
+ reg = <0x17>;
+ mask = <0xfe>;
+ };
+ cpu_reset_soft {
+ reg = <0x17>;
+ mask = <0xf7>;
+ };
+ ps1_on {
+ reg = <0x30>;
+ mask = <0xfe>;
+ };
+ ps2_on {
+ label = "ps2_on";
+ reg = <0x30>;
+ mask = <0xfd>;
+ };
+ sys_power_cycle {
+ reg = <0x30>;
+ mask = <0xfb>;
+ };
+ mng_pg_ovrd {
+ reg = <0x30>;
+ mask = <0xf7>;
+ };
+ cpu_reset_hard {
+ reg = <0x30>;
+ mask = <0xdf>;
+ };
+ };
+
+ cause {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ac_power_cycle {
+ reg = <0x1d>;
+ mask = <0xfe>;
+ };
+ dc_power_cycle {
+ reg = <0x1d>;
+ mask = <0xfd>;
+ };
+ cpu_power_down {
+ reg = <0x1d>;
+ mask = <0xfb>;
+ };
+ cpu_reboot {
+ reg = <0x1d>;
+ mask = <0xf7>;
+ };
+ cpu_shutdown {
+ reg = <0x1d>;
+ mask = <0xef>;
+ };
+ cpu_watchdog {
+ reg = <0x1d>;
+ mask = <0xef>;
+ };
+ cpu_kernel_panic {
+ reg = <0x1d>;
+ mask = <0xef>;
+ };
+ bmc_warm_reset {
+ reg = <0x71>;
+ mask = <0xfe>;
+ };
+ bmc_upgrade {
+ reg = <0x2e>;
+ mask = <0xf7>;
+ };
+ };
+
+ gpro {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ version {
+ reg = <0x00>;
+ mask = <0xff>;
+ bit = <0xff>;
+ };
+ };
+ };
+
+ mlxcpld-swb-ctrl@72 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&gpio>;
+ interrupts = <ASPEED_GPIO(S, 1) 2>;
+ compatible = "mellanox,mlxcpld-ctrl-i2c";
+ reg = <0x72>;
+ deferred = <&i2c12>;
+ cell = <0x40>;
+ mask = <0x01>;
+
+ asic {
+ aggr_mask = <0x01>;
+ regs = <0x50>;
+ masks = <0x03>;
+ phandles = <&asic_thermal>;
+ };
+
+ gpro {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ version {
+ reg = <0x01>;
+ mask = <0xff>;
+ bit = <0xff>;
+ };
+ };
+
+ reset {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ asic_reset {
+ reg = <0x19>;
+ mask = <0xf7>;
+ };
+ phy_reset {
+ reg = <0x19>;
+ mask = <0xef>;
+ };
+ };
+
+ };
--
2.1.4
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [patch v2 1/1 - resend] Documentation: dt-bindings: Add Device Tree bindings for Mellanox programming devices
2017-08-03 12:04 ` [patch v2 1/1 - resend] Documentation: dt-bindings: Add " Vadim Pasternak
@ 2017-08-10 17:40 ` Rob Herring
2017-08-10 19:02 ` Vadim Pasternak
0 siblings, 1 reply; 4+ messages in thread
From: Rob Herring @ 2017-08-10 17:40 UTC (permalink / raw)
To: Vadim Pasternak
Cc: devicetree, lee.jones, pavel, j.anaszewski, rpurdie, linux-leds,
jiri, jacek.anaszewski
On Thu, Aug 03, 2017 at 12:04:19PM +0000, Vadim Pasternak wrote:
> The mlxreg a multifunction device driver handling LEDs, events, exposing
> through sysfs reset signal, and reset causes info. These components share
> a common register space.
"dt-bindings: mfd: ..." for the subject please.
>
> Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
> ---
> .../devicetree/bindings/mfd/mellanox,mlxreg-core | 346 +++++++++++++++++++++
> 1 file changed, 346 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/mellanox,mlxreg-core
>
> diff --git a/Documentation/devicetree/bindings/mfd/mellanox,mlxreg-core b/Documentation/devicetree/bindings/mfd/mellanox,mlxreg-core
> new file mode 100644
> index 0000000..a90933e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/mellanox,mlxreg-core
> @@ -0,0 +1,346 @@
> +Mellanox programmable device control.
> +-------------------------------------
> +This binding defines the device control interface over I2C bus for Mellanox BMC
> +based switches.
> +
> +Required properties:
> +- compatible = "mellanox,mlxreg-i2c",
> + "mellanox,mlxreg-i2c-16",
> + "mellanox,mlxreg-core";
This is all one compatible entry? Why 3 compatibles?
> +- #address-cells : must be 1;
> +- #size-cells : must be 0;
> +- reg : I2C address;
> +
> +Optional properties:
> +- interrupt-parent : phandle of parent interrupt controller;
> +- interrupts : interrupt line;
> +- deferred - I2C deferred bus phandle;
> + For example, for the case when device attached to I2C bus number 4
> + performs dynamic attachment of device to bus 12 upon some event.
> + Due to this reason bus 4 is enforced to be activated after bus 12;
I don't understand...
> +- cell - top aggregation register offset;
> +- mask - top aggregation register mask;
> +- psu - power supply unit nodes:
This section is "Optional Properties" and this is a sub-node. Each
subnode should have its own section.
> + - aggr_mask - effective bit in aggregation mask;
Don't use '_' in node or property names.
> + - reg - register offset for all group members;
> + - mask - register mask;
> + - phandles - list of relevant device nodes;
Other than reg, I don't understand what any of these are.
>From what I can tell you are describing things down to register bit
level which generally is too much detail in DT. How many variations of
h/w do you have? Do you really need to be able to define any possible
combination or have some finite set?
Rob
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: [patch v2 1/1 - resend] Documentation: dt-bindings: Add Device Tree bindings for Mellanox programming devices
2017-08-10 17:40 ` Rob Herring
@ 2017-08-10 19:02 ` Vadim Pasternak
0 siblings, 0 replies; 4+ messages in thread
From: Vadim Pasternak @ 2017-08-10 19:02 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree@vger.kernel.org, lee.jones@linaro.org, pavel@ucw.cz,
j.anaszewski@samsung.com, rpurdie@rpsys.net,
linux-leds@vger.kernel.org, jiri@resnulli.us,
jacek.anaszewski@gmail.com
> -----Original Message-----
> From: Rob Herring [mailto:robh@kernel.org]
> Sent: Thursday, August 10, 2017 8:40 PM
> To: Vadim Pasternak <vadimp@mellanox.com>
> Cc: devicetree@vger.kernel.org; lee.jones@linaro.org; pavel@ucw.cz;
> j.anaszewski@samsung.com; rpurdie@rpsys.net; linux-
> leds@vger.kernel.org; jiri@resnulli.us; jacek.anaszewski@gmail.com
> Subject: Re: [patch v2 1/1 - resend] Documentation: dt-bindings: Add Device
> Tree bindings for Mellanox programming devices
>
> On Thu, Aug 03, 2017 at 12:04:19PM +0000, Vadim Pasternak wrote:
> > The mlxreg a multifunction device driver handling LEDs, events,
> > exposing through sysfs reset signal, and reset causes info. These
> > components share a common register space.
>
> "dt-bindings: mfd: ..." for the subject please.
>
Hi Rob,
Thank you for review.
OK, will change the subject.
> >
> > Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
> > ---
> > .../devicetree/bindings/mfd/mellanox,mlxreg-core | 346
> +++++++++++++++++++++
> > 1 file changed, 346 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/mfd/mellanox,mlxreg-core
> >
> > diff --git
> > a/Documentation/devicetree/bindings/mfd/mellanox,mlxreg-core
> > b/Documentation/devicetree/bindings/mfd/mellanox,mlxreg-core
> > new file mode 100644
> > index 0000000..a90933e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/mellanox,mlxreg-core
> > @@ -0,0 +1,346 @@
> > +Mellanox programmable device control.
> > +-------------------------------------
> > +This binding defines the device control interface over I2C bus for
> > +Mellanox BMC based switches.
> > +
> > +Required properties:
> > +- compatible = "mellanox,mlxreg-i2c",
> > + "mellanox,mlxreg-i2c-16",
> > + "mellanox,mlxreg-core";
>
> This is all one compatible entry? Why 3 compatibles?
It could be
"mellanox,mlxreg-i2c" or
"mellanox,mlxreg-i2c-16"
Is it not correct syntax?
And I think I'll drop "mellanox,mlxreg-core".
>
> > +- #address-cells : must be 1;
> > +- #size-cells : must be 0;
> > +- reg : I2C address;
> > +
> > +Optional properties:
> > +- interrupt-parent : phandle of parent interrupt controller;
> > +- interrupts : interrupt line;
> > +- deferred - I2C deferred bus phandle;
> > + For example, for the case when device attached to I2C bus
> number 4
> > + performs dynamic attachment of device to bus 12 upon some
> event.
> > + Due to this reason bus 4 is enforced to be activated after bus
> > +12;
>
> I don't understand...
For example I have CPLD device on i2c4, which handles the signals for ASIC device. I can connect this device to the bus at initialization time in case it's ready, or upon receiving the relevant signal when it's getting ready:
&i2c4 {
mlxcpld-swb-ctrl@72 {
#address-cells = <1>;
#size-cells = <0>;
interrupt-parent = <&gpio>;
interrupts = <ASPEED_GPIO(S, 1) 2>;
compatible = "mellanox,mlxreg-i2c";
reg = <0x72>;
deferred = <&i2c12>;
cell = <0x40>;
mask = <0x01>;
asic {
aggr_mask = <0x01>;
regs = <0x50>;
masks = <0x03>;
phandles = <&asic_thermal>;
};
....
};
The ASIC device is connected to i2c12:
&i2c12 {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
asic_thermal: mlxsw_minimal@48 {
compatible = "mlxsw_minimal";
reg = <0x48>;
status = "disabled";
cooling-phandle = <&cooling>;
trips {
/* trip type, temp in mcelsius, temp min, temp max */
trip@0 {
trip = <0 75000 0 0>;
};
trip@1 {
trip = <2 85000 1 5>;
};
trip@3 {
trip = <2 105000 5 5>;
};
};
};
};
So, in this case i2c4 should be activated after i2c12 and for this reason device mlxcpld-swb-ctrl@72 is deferred on activation of i2c12.
>
> > +- cell - top aggregation register offset;
> > +- mask - top aggregation register mask;
> > +- psu - power supply unit nodes:
>
> This section is "Optional Properties" and this is a sub-node. Each subnode
> should have its own section.
ACK
>
> > + - aggr_mask - effective bit in aggregation mask;
>
> Don't use '_' in node or property names.
ACK
>
> > + - reg - register offset for all group members;
> > + - mask - register mask;
> > + - phandles - list of relevant device nodes;
>
> Other than reg, I don't understand what any of these are.
>
> From what I can tell you are describing things down to register bit level which
> generally is too much detail in DT. How many variations of h/w do you have?
> Do you really need to be able to define any possible combination or have
> some finite set?
We have about 10 different 1U systems with different numbers of FANs, with replicable or
non-replaceable PSU. I am also planning to support director systems, which has different
configurations - different number of leaf and spine cards and power supply and FAN units.
This is the wide range of system from smallest with 16x100G ports with biggest with 800x200G ports.
I really need flexibility in device description.
In field mask I assign the affective mask for dynamic devices, f.e. example for system with 4 FANs
mask will be 0x0f, with 6 0x3f and for director system it can be located in several registers with masks
0xff.
Handles have the next purpose. For example for fan nodes I provide the list of EEPROM devices'
handles, which should be connected/disconnected on insert/remove:
fan {
aggr_mask = <0x40>;
reg = <0x88>;
mask = <0x0f>;
phandles = <&fan1_eeprom &fan2_eeprom &fan3_eeprom
&fan4_eeprom>;
};
And this EEPROM devices are connected to i2c switch device like below:
&i2c6 {
...
i2cswitch@71 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x71>;
i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
fan1_eeprom: at24c04@50 {
compatible = "atmel,24c32";
reg = <0x50>;
status = "disabled";
};
};
i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
fan2_eeprom: at24c04@50 {
compatible = "atmel,24c32";
reg = <0x50>;
status = "disabled";
};
};
i2c@2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
fan3_eeprom: at24c04@50 {
compatible = "atmel,24c32";
reg = <0x50>;
status = "disabled";
};
};
i2c@3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
fan4_eeprom: at24c04@50 {
compatible = "atmel,24c32";
reg = <0x50>;
status = "disabled";
};
};
};
};
>
> Rob
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-08-10 19:02 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-08-03 12:04 [patch v2 0/1 - resend] Introduce Device Tree bindings for Mellanox programming devices Vadim Pasternak
2017-08-03 12:04 ` [patch v2 1/1 - resend] Documentation: dt-bindings: Add " Vadim Pasternak
2017-08-10 17:40 ` Rob Herring
2017-08-10 19:02 ` Vadim Pasternak
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).