* [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).