* [PATCH 1/2] Adding Lenovo - Lenovo Group Ltd. to the vendor-prefixes list.
@ 2014-07-23 22:35 Benoit Masson
2014-07-23 22:32 ` Andrew Lunn
` (3 more replies)
0 siblings, 4 replies; 15+ messages in thread
From: Benoit Masson @ 2014-07-23 22:35 UTC (permalink / raw)
To: linux-arm-kernel
Lenovo Group Ltd. (stylized as lenovo) is a Chinese multinational computer technology company with headquarters in Beijing, China, and Morrisville, North Carolina, United States.
http://www.lenovo.com/
Signed-off-by: Benoit Masson <yahoo@perenite.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 46a311e..ae09892 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -71,6 +71,7 @@ karo Ka-Ro electronics GmbH
keymile Keymile GmbH
lacie LaCie
lantiq Lantiq Semiconductor
+lenovo Lenovo Group Ltd.
lg LG Corporation
linux Linux-specific binding
lsi LSI Corp. (LSI Logic)
--
1.9.1
^ permalink raw reply related [flat|nested] 15+ messages in thread* [PATCH 1/2] Adding Lenovo - Lenovo Group Ltd. to the vendor-prefixes list. 2014-07-23 22:35 [PATCH 1/2] Adding Lenovo - Lenovo Group Ltd. to the vendor-prefixes list Benoit Masson @ 2014-07-23 22:32 ` Andrew Lunn 2014-07-23 22:35 ` [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS Benoit Masson ` (2 subsequent siblings) 3 siblings, 0 replies; 15+ messages in thread From: Andrew Lunn @ 2014-07-23 22:32 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jul 23, 2014 at 03:35:22PM -0700, Benoit Masson wrote: > Lenovo Group Ltd. (stylized as lenovo) is a Chinese multinational computer technology company with headquarters in Beijing, China, and Morrisville, North Carolina, United States. > > http://www.lenovo.com/ > Signed-off-by: Benoit Masson <yahoo@perenite.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Andrew > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt > index 46a311e..ae09892 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -71,6 +71,7 @@ karo Ka-Ro electronics GmbH > keymile Keymile GmbH > lacie LaCie > lantiq Lantiq Semiconductor > +lenovo Lenovo Group Ltd. > lg LG Corporation > linux Linux-specific binding > lsi LSI Corp. (LSI Logic) > -- > 1.9.1 > ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS 2014-07-23 22:35 [PATCH 1/2] Adding Lenovo - Lenovo Group Ltd. to the vendor-prefixes list Benoit Masson 2014-07-23 22:32 ` Andrew Lunn @ 2014-07-23 22:35 ` Benoit Masson 2014-07-23 22:42 ` Andrew Lunn 2014-07-24 12:45 ` [PATCH 1/2] Adding Lenovo - Lenovo Group Ltd. to the vendor-prefixes list Rob Herring 2014-07-28 13:43 ` Jason Cooper 3 siblings, 1 reply; 15+ messages in thread From: Benoit Masson @ 2014-07-23 22:35 UTC (permalink / raw) To: linux-arm-kernel The Lenovo Iomega ix4-300d is a 4-Bay sata NAS with dual Gb, USB2.0 & 3.0, powered by a Marvell Armada XP MV78230 dual core CPU. http://shop.lenovo.com/fr/fr/servers/network-storage/lenovoemc/ix4-300d/ Signed-off-by: Benoit Masson <yahoo@perenite.com> --- arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 284 ++++++++++++++++++++++++ 2 files changed, 286 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index adb5ed9..4429495 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -437,8 +437,9 @@ dtb-$(CONFIG_MACH_ARMADA_XP) += \ armada-xp-axpwifiap.dtb \ armada-xp-db.dtb \ armada-xp-gp.dtb \ - armada-xp-netgear-rn2120.dtb \ + armada-xp-lenovo-ix4-300d.dtb \ armada-xp-matrix.dtb \ + armada-xp-netgear-rn2120.dtb \ armada-xp-openblocks-ax3-4.dtb dtb-$(CONFIG_MACH_DOVE) += dove-cm-a510.dtb \ dove-cubox.dtb \ diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts new file mode 100644 index 0000000..aedc9dc --- /dev/null +++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts @@ -0,0 +1,284 @@ +/* + * Device Tree file for Lenovo Iomega ix4-300d + * + * Copyright (C) 2014, Benoit Masson <yahoo@perenite.com> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +/dts-v1/; + +#include <dt-bindings/input/input.h> +#include <dt-bindings/gpio/gpio.h> +#include "armada-xp-mv78230.dtsi" + +/ { + model = "Lenovo Iomega ix4-300d"; + compatible = "lenovo,ix4-300d", "marvell,armadaxp-mv78230", + "marvell,armadaxp", "marvell,armada-370-xp"; + + chosen { + bootargs = "console=ttyS0,115200 earlyprintk"; + stdout-path = "/soc/internal-regs/serial at 12000"; + }; + + memory { + device_type = "memory"; + reg = <0 0x00000000 0 0x20000000>; /* 512MB */ + }; + + soc { + ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000 + MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>; + + pcie-controller { + status = "okay"; + + /* Quad port sata: Marvell 88SX7042 */ + pcie at 1,0 { + /* Port 0, Lane 0 */ + status = "okay"; + }; + + /* USB 3.0 xHCI controller: NEC D720200F1 */ + pcie at 5,0 { + /* Port 1, Lane 0 */ + status = "okay"; + }; + }; + + internal-regs { + pinctrl { + poweroff_pin: poweroff-pin { + marvell,pins = "mpp24"; + marvell,function = "gpio"; + }; + + power_button_pin: power-button-pin { + marvell,pins = "mpp44"; + marvell,function = "gpio"; + }; + + reset_button_pin: reset-button-pin { + marvell,pins = "mpp45"; + marvell,function = "gpio"; + }; + select_button_pin: select-button-pin { + marvell,pins = "mpp41"; + marvell,function = "gpio"; + }; + + scroll_button_pin: scroll-button-pin { + marvell,pins = "mpp42"; + marvell,function = "gpio"; + }; + + hdd_led_pin: hdd-led-pin { + marvell,pins = "mpp26"; + marvell,function = "gpio"; + }; + }; + + serial at 12000 { + status = "okay"; + }; + + mdio { + phy0: ethernet-phy at 0 { /* Marvell 88E1318 */ + reg = <0>; + }; + + phy1: ethernet-phy at 1 { /* Marvell 88E1318 */ + reg = <1>; + }; + }; + + ethernet at 70000 { + status = "okay"; + phy = <&phy0>; + phy-mode = "rgmii-id"; + }; + + ethernet at 74000 { + status = "okay"; + phy = <&phy1>; + phy-mode = "rgmii-id"; + }; + + usb at 50000 { + status = "okay"; + }; + + usb at 51000 { + status = "okay"; + }; + + i2c at 11000 { + compatible = "marvell,mv78230-a0-i2c", + "marvell,mv64xxx-i2c"; + clock-frequency = <400000>; + status = "okay"; + + adt7473 at 2e { + compatible = "adi,adt7473"; + reg = <0x2e>; + }; + + pcf8563 at 51 { + compatible = "nxp,pcf8563"; + reg = <0x51>; + }; + + }; + + nand at d0000 { + status = "okay"; + num-cs = <1>; + marvell,nand-keep-config; + marvell,nand-enable-arbiter; + nand-on-flash-bbt; + + partition at 0 { + label = "u-boot"; + reg = <0x0000000 0xe0000>; + read-only; + }; + + partition at e0000 { + label = "u-boot-env"; + reg = <0xe0000 0x20000>; + read-only; + }; + + partition at 100000 { + label = "u-boot-env2"; + reg = <0x100000 0x20000>; + read-only; + }; + + partition at 120000 { + label = "zImage"; + reg = <0x120000 0x400000>; + }; + + partition at 520000 { + label = "initrd"; + reg = <0x520000 0x400000>; + }; + + partition at xE00000 { + label = "boot"; + reg = <0xE00000 0x3F200000>; + }; + + partition at flash { + label = "flash"; + reg = <0x0 0x40000000>; + }; + }; + }; + }; + + gpio-keys { + compatible = "gpio-keys"; + pinctrl-0 = <&power_button_pin &reset_button_pin + &select_button_pin &scroll_button_pin>; + pinctrl-names = "default"; + + power-button { + label = "Power Button"; + linux,code = <KEY_POWER>; + gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>; + }; + + reset-button { + label = "Reset Button"; + linux,code = <KEY_RESTART>; + gpios = <&gpio1 13 GPIO_ACTIVE_LOW>; + }; + + select-button { + label = "Select Button"; + linux,code = <BTN_SELECT>; + gpios = <&gpio1 9 GPIO_ACTIVE_LOW>; + }; + + scroll-button { + label = "Scroll Button"; + linux,code = <KEY_SCROLLDOWN>; + gpios = <&gpio1 10 GPIO_ACTIVE_LOW>; + }; + }; + + spi3 { + compatible = "spi-gpio"; + status = "okay"; + gpio-sck = <&gpio0 25 0>; + gpio-mosi = <&gpio1 15 0>; /*gpio 47*/ + cs-gpios = <&gpio0 27 0 >; + num-chipselects = <1>; + #address-cells = <1>; + #size-cells = <0>; + + gpio2: gpio2 at 0 { + compatible = "fairchild,74hc595"; + gpio-controller; + #gpio-cells = <2>; + reg = <0>; + registers-number = <2>; + spi-max-frequency = <100000>; + }; + }; + + gpio-leds { + compatible = "gpio-leds"; + pinctrl-0 = <&hdd_led_pin>; + pinctrl-names = "default"; + + hdd-led { + label = "ix4-300d:blue:hdd"; + gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>; + default-state = "off"; + }; + + power-led { + label = "ix4-300d:power"; + gpios = <&gpio2 1 GPIO_ACTIVE_LOW>; + /* init blinking while booting */ + linux,default-trigger = "timer"; + default-state = "on"; + }; + + sysfail-led { + label = "ix4-300d:sysfail:red"; + gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>; + default-state = "off"; + }; + + sys-led { + label = "ix4-300d:sys:blue"; + gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>; + default-state = "off"; + }; + + hddfail-led { + label = "ix4-300d:hddfail:red"; + gpios = <&gpio2 4 GPIO_ACTIVE_HIGH>; + default-state = "off"; + }; + + }; + + /* Warning: you need both eth1 & 0 PHY initialized + (i.e having them up does the tweak) + for poweroff to shutdown otherwise it reboots */ + gpio-poweroff { + compatible = "gpio-poweroff"; + pinctrl-0 = <&poweroff_pin>; + pinctrl-names = "default"; + gpios = <&gpio0 24 GPIO_ACTIVE_HIGH>; + }; +}; -- 1.9.1 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS 2014-07-23 22:35 ` [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS Benoit Masson @ 2014-07-23 22:42 ` Andrew Lunn 2014-07-23 22:56 ` Benoit Masson 0 siblings, 1 reply; 15+ messages in thread From: Andrew Lunn @ 2014-07-23 22:42 UTC (permalink / raw) To: linux-arm-kernel > + i2c at 11000 { > + compatible = "marvell,mv78230-a0-i2c", > + "marvell,mv64xxx-i2c"; Ah sorry, i missed this first time. Do you really need "marvell,mv78230-a0-i2c"? Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt says: - "marvell,mv78230-a0-i2c" * Note: Only use "marvell,mv78230-a0-i2c" for a very rare, initial version of the SoC which had broken offload support. Linux auto-detects this and sets it appropriately. So i don't think you should have this hear. Gregory, please could you comment. > + power-led { > + label = "ix4-300d:power"; It is normal to include the colour, and you did for all the other LEDs. Andrew ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS 2014-07-23 22:42 ` Andrew Lunn @ 2014-07-23 22:56 ` Benoit Masson 2014-07-23 22:58 ` Andrew Lunn 0 siblings, 1 reply; 15+ messages in thread From: Benoit Masson @ 2014-07-23 22:56 UTC (permalink / raw) To: linux-arm-kernel No worries, sorry it makes more email for you guys, I've added the colors for power and revert order hdd:blue instead of blue:hdd for the hdd led. For the marvell,mv78230-a0-i2c unfortunately i've spend 3 hours trying to understand this but it only works with this on the ix4-300d :(. There was multiple patch around this and maybe one broke the auto-detect part of this, I've tried compiling with some 3.10 or lower kernel but no luck here I still have to put this a0 option. Benoit Le 24 juil. 2014 ? 00:42, Andrew Lunn <andrew@lunn.ch> a ?crit : >> + i2c at 11000 { >> + compatible = "marvell,mv78230-a0-i2c", >> + "marvell,mv64xxx-i2c"; > > Ah sorry, i missed this first time. Do you really need > "marvell,mv78230-a0-i2c"? > > Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt says: > > - "marvell,mv78230-a0-i2c" > * Note: Only use "marvell,mv78230-a0-i2c" for a > very rare, initial version of the SoC which > had broken offload support. Linux > auto-detects this and sets it appropriately. > > So i don't think you should have this hear. > > Gregory, please could you comment. > >> + power-led { >> + label = "ix4-300d:power"; > > It is normal to include the colour, and you did for all the other > LEDs. > > Andrew ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS 2014-07-23 22:56 ` Benoit Masson @ 2014-07-23 22:58 ` Andrew Lunn [not found] ` <10A7C530-7CD2-4ED0-889A-7FAC1922320F@perenite.com> 0 siblings, 1 reply; 15+ messages in thread From: Andrew Lunn @ 2014-07-23 22:58 UTC (permalink / raw) To: linux-arm-kernel > For the marvell,mv78230-a0-i2c unfortunately i've spend 3 hours > trying to understand this but it only works with this on the > ix4-300d :(. There was multiple patch around this and maybe one > broke the auto-detect part of this, I've tried compiling with some > 3.10 or lower kernel but no luck here I still have to put this a0 > option. Lets first confirm you have an a0 SoC. At boot time, it should print: pr_info("MVEBU SoC ID=0x%X, Rev=0x%X\n", soc_dev_id, soc_rev); What revision do you have? If the auto detect code really is broken, Gregory will likely take a look. Andrew ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <10A7C530-7CD2-4ED0-889A-7FAC1922320F@perenite.com>]
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS [not found] ` <10A7C530-7CD2-4ED0-889A-7FAC1922320F@perenite.com> @ 2014-07-23 23:15 ` Jason Cooper 2014-07-24 12:21 ` Gregory CLEMENT 0 siblings, 1 reply; 15+ messages in thread From: Jason Cooper @ 2014-07-23 23:15 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jul 24, 2014 at 01:11:12AM +0200, Benoit Masson wrote: > Le 24 juil. 2014 ? 00:58, Andrew Lunn <andrew@lunn.ch> a ?crit : > > >> For the marvell,mv78230-a0-i2c unfortunately i've spend 3 hours > >> trying to understand this but it only works with this on the > >> ix4-300d :(. There was multiple patch around this and maybe one > >> broke the auto-detect part of this, I've tried compiling with some > >> 3.10 or lower kernel but no luck here I still have to put this a0 > >> option. > > > > Lets first confirm you have an a0 SoC. > > > > At boot time, it should print: > > > > pr_info("MVEBU SoC ID=0x%X, Rev=0x%X\n", soc_dev_id, soc_rev); > > > > What revision do you have? > > > > If the auto detect code really is broken, Gregory will likely take a > > look. > > I sure do, > > confirmed by u-boot output below: > > U-Boot 2009.08 (Mar 04 2013 - 11:13:04) Marvell version: 2.3.2 PQ > U-Boot Addressing: > Code:..00600000:006BFFF0 > BSS:..00708EC0 > Stack:..0x5fff70 > PageTable:.0x8e0000 > Heap address:.0x900000:0xe00000 > Board: DB-78230-BP rev 2.0 Wistron > SoC: MV78230 A0 > > From kernel I get: > > mvebu-soc-id: MVEBU SoC ID=0x7823, Rev=0x1 Well, isn't that a peach? :) Gregory? thx, Jason. ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS 2014-07-23 23:15 ` Jason Cooper @ 2014-07-24 12:21 ` Gregory CLEMENT 2014-07-24 12:45 ` Jason Cooper 0 siblings, 1 reply; 15+ messages in thread From: Gregory CLEMENT @ 2014-07-24 12:21 UTC (permalink / raw) To: linux-arm-kernel On 24/07/2014 01:15, Jason Cooper wrote: > On Thu, Jul 24, 2014 at 01:11:12AM +0200, Benoit Masson wrote: >> Le 24 juil. 2014 ? 00:58, Andrew Lunn <andrew@lunn.ch> a ?crit : >> >>>> For the marvell,mv78230-a0-i2c unfortunately i've spend 3 hours >>>> trying to understand this but it only works with this on the >>>> ix4-300d :(. There was multiple patch around this and maybe one >>>> broke the auto-detect part of this, I've tried compiling with some >>>> 3.10 or lower kernel but no luck here I still have to put this a0 >>>> option. >>> >>> Lets first confirm you have an a0 SoC. >>> >>> At boot time, it should print: >>> >>> pr_info("MVEBU SoC ID=0x%X, Rev=0x%X\n", soc_dev_id, soc_rev); >>> >>> What revision do you have? >>> >>> If the auto detect code really is broken, Gregory will likely take a >>> look. >> >> I sure do, >> >> confirmed by u-boot output below: >> >> U-Boot 2009.08 (Mar 04 2013 - 11:13:04) Marvell version: 2.3.2 PQ >> U-Boot Addressing: >> Code:..00600000:006BFFF0 >> BSS:..00708EC0 >> Stack:..0x5fff70 >> PageTable:.0x8e0000 >> Heap address:.0x900000:0xe00000 >> Board: DB-78230-BP rev 2.0 Wistron >> SoC: MV78230 A0 >> >> From kernel I get: >> >> mvebu-soc-id: MVEBU SoC ID=0x7823, Rev=0x1 > > Well, isn't that a peach? :) Gregory? A peach?? For me it is either a fruit or a princess, so I am puzzled! Well about the issue, we patch the device tree for the i2c quirk only for the openblock AX3. If I remember well it was because the device tree was already written for this board before we found there was an issue with the A0 version of the CPU. The rule was that for new boards then they have to set the marvell,mv78230-a0-i2c compatible string. I also didn't expect that we found "new" product using the A0 version. We have 3 options now: - remove the check on the openblock AX3 board and always try to apply the quirck for A0 version - add a check for this new board in the mvebu_dt_init function - let the compatible string marvell,mv78230-a0-i2c in this dts I would prefer the option 1 but I fear that Arnd would prefer the 2 other options. Gregory > > thx, > > Jason. > -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS 2014-07-24 12:21 ` Gregory CLEMENT @ 2014-07-24 12:45 ` Jason Cooper 2014-07-24 13:29 ` Andrew Lunn [not found] ` <C2E7C8C1-1198-4785-AB9C-C27B5E27A8D4@perenite.com> 0 siblings, 2 replies; 15+ messages in thread From: Jason Cooper @ 2014-07-24 12:45 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jul 24, 2014 at 02:21:03PM +0200, Gregory CLEMENT wrote: > On 24/07/2014 01:15, Jason Cooper wrote: > > On Thu, Jul 24, 2014 at 01:11:12AM +0200, Benoit Masson wrote: > >> Le 24 juil. 2014 ? 00:58, Andrew Lunn <andrew@lunn.ch> a ?crit : > >> > >>>> For the marvell,mv78230-a0-i2c unfortunately i've spend 3 hours > >>>> trying to understand this but it only works with this on the > >>>> ix4-300d :(. There was multiple patch around this and maybe one > >>>> broke the auto-detect part of this, I've tried compiling with some > >>>> 3.10 or lower kernel but no luck here I still have to put this a0 > >>>> option. > >>> > >>> Lets first confirm you have an a0 SoC. > >>> > >>> At boot time, it should print: > >>> > >>> pr_info("MVEBU SoC ID=0x%X, Rev=0x%X\n", soc_dev_id, soc_rev); > >>> > >>> What revision do you have? > >>> > >>> If the auto detect code really is broken, Gregory will likely take a > >>> look. > >> > >> I sure do, > >> > >> confirmed by u-boot output below: > >> > >> U-Boot 2009.08 (Mar 04 2013 - 11:13:04) Marvell version: 2.3.2 PQ > >> U-Boot Addressing: > >> Code:..00600000:006BFFF0 > >> BSS:..00708EC0 > >> Stack:..0x5fff70 > >> PageTable:.0x8e0000 > >> Heap address:.0x900000:0xe00000 > >> Board: DB-78230-BP rev 2.0 Wistron > >> SoC: MV78230 A0 > >> > >> From kernel I get: > >> > >> mvebu-soc-id: MVEBU SoC ID=0x7823, Rev=0x1 > > > > Well, isn't that a peach? :) Gregory? > > A peach?? For me it is either a fruit or a princess, so I am puzzled! Doc Holiday quote from the movie Tombstone. The full quote was "Well, isn't that a peach of a hand?" while sitting at the poker table. > Well about the issue, we patch the device tree for the i2c quirk only for > the openblock AX3. Ahhh, that's right. I need to slow down and dig a bit more. :( > If I remember well it was because the device tree was already written > for this board before we found there was an issue with the A0 version > of the CPU. No, it's because we didn't think any manufacturers would be silly enough to use the a0 in production. That assumption worked out well. :-P > The rule was that for new boards then they have to set the marvell,mv78230-a0-i2c > compatible string. I also didn't expect that we found "new" product using the A0 version. > > We have 3 options now: > > - remove the check on the openblock AX3 board and always try to apply the quirck for A0 version > - add a check for this new board in the mvebu_dt_init function > - let the compatible string marvell,mv78230-a0-i2c in this dts > > I would prefer the option 1 but I fear that Arnd would prefer the 2 other options. I like option 1 and 3. Option 3 is a *correct* description of the hardware, and should be done. Option 1 makes Linux user-friendly for boards that are exactly the same, but changed out SoC stepping mid-production. Option 2 needs to be undone. We shouldn't need to change compiled code for every new board that comes along. Which was the whole point of DT, right? thx, Jason. ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS 2014-07-24 12:45 ` Jason Cooper @ 2014-07-24 13:29 ` Andrew Lunn [not found] ` <C2E7C8C1-1198-4785-AB9C-C27B5E27A8D4@perenite.com> 1 sibling, 0 replies; 15+ messages in thread From: Andrew Lunn @ 2014-07-24 13:29 UTC (permalink / raw) To: linux-arm-kernel > > Well about the issue, we patch the device tree for the i2c quirk only for > > the openblock AX3. > > Ahhh, that's right. I need to slow down and dig a bit more. :( > > > If I remember well it was because the device tree was already written > > for this board before we found there was an issue with the A0 version > > of the CPU. > > No, it's because we didn't think any manufacturers would be silly enough > to use the a0 in production. That assumption worked out well. :-P > > > The rule was that for new boards then they have to set the marvell,mv78230-a0-i2c > > compatible string. I also didn't expect that we found "new" product using the A0 version. > > > > We have 3 options now: > > > > - remove the check on the openblock AX3 board and always try to apply the quirck for A0 version > > - add a check for this new board in the mvebu_dt_init function > > - let the compatible string marvell,mv78230-a0-i2c in this dts > > > > I would prefer the option 1 but I fear that Arnd would prefer the 2 other options. > > I like option 1 and 3. Option 3 is a *correct* description of the > hardware, and should be done. Option 1 makes Linux user-friendly for boards > that are exactly the same, but changed out SoC stepping mid-production. I would prefer 1 as well. It is the SoC that has the problem, not the board. So we should not be making the quirk board specific. Andrew ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <C2E7C8C1-1198-4785-AB9C-C27B5E27A8D4@perenite.com>]
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS [not found] ` <C2E7C8C1-1198-4785-AB9C-C27B5E27A8D4@perenite.com> @ 2014-07-24 14:07 ` Jason Cooper 2014-07-24 14:29 ` Andrew Lunn 0 siblings, 1 reply; 15+ messages in thread From: Jason Cooper @ 2014-07-24 14:07 UTC (permalink / raw) To: linux-arm-kernel Benoit, Please try to avoid top-posting. I've re-flowed it, below. Arnd, Andrew, question for both of you below. On Thu, Jul 24, 2014 at 03:40:42PM +0200, Benoit Masson wrote: > Le 24 juil. 2014 ? 14:45, Jason Cooper <jason@lakedaemon.net> a ?crit : > > > On Thu, Jul 24, 2014 at 02:21:03PM +0200, Gregory CLEMENT wrote: > >> On 24/07/2014 01:15, Jason Cooper wrote: > >>> On Thu, Jul 24, 2014 at 01:11:12AM +0200, Benoit Masson wrote: > >>>> Le 24 juil. 2014 ? 00:58, Andrew Lunn <andrew@lunn.ch> a ?crit : > >>>> > >>>>>> For the marvell,mv78230-a0-i2c unfortunately i've spend 3 hours > >>>>>> trying to understand this but it only works with this on the > >>>>>> ix4-300d :(. There was multiple patch around this and maybe one > >>>>>> broke the auto-detect part of this, I've tried compiling with some > >>>>>> 3.10 or lower kernel but no luck here I still have to put this a0 > >>>>>> option. > >>>>> > >>>>> Lets first confirm you have an a0 SoC. > >>>>> > >>>>> At boot time, it should print: > >>>>> > >>>>> pr_info("MVEBU SoC ID=0x%X, Rev=0x%X\n", soc_dev_id, soc_rev); > >>>>> > >>>>> What revision do you have? > >>>>> > >>>>> If the auto detect code really is broken, Gregory will likely take a > >>>>> look. > >>>> > >>>> I sure do, > >>>> > >>>> confirmed by u-boot output below: > >>>> > >>>> U-Boot 2009.08 (Mar 04 2013 - 11:13:04) Marvell version: 2.3.2 PQ > >>>> U-Boot Addressing: > >>>> Code:..00600000:006BFFF0 > >>>> BSS:..00708EC0 > >>>> Stack:..0x5fff70 > >>>> PageTable:.0x8e0000 > >>>> Heap address:.0x900000:0xe00000 > >>>> Board: DB-78230-BP rev 2.0 Wistron > >>>> SoC: MV78230 A0 > >>>> > >>>> From kernel I get: > >>>> > >>>> mvebu-soc-id: MVEBU SoC ID=0x7823, Rev=0x1 > >>> > >>> Well, isn't that a peach? :) Gregory? > >> > >> A peach?? For me it is either a fruit or a princess, so I am puzzled! > > > > Doc Holiday quote from the movie Tombstone. The full quote was "Well, > > isn't that a peach of a hand?" while sitting at the poker table. > > > >> Well about the issue, we patch the device tree for the i2c quirk only for > >> the openblock AX3. > > > > Ahhh, that's right. I need to slow down and dig a bit more. :( ^^^^^ This is the important bit. > > > >> If I remember well it was because the device tree was already written > >> for this board before we found there was an issue with the A0 version > >> of the CPU. > > > > No, it's because we didn't think any manufacturers would be silly enough > > to use the a0 in production. That assumption worked out well. :-P > > > >> The rule was that for new boards then they have to set the marvell,mv78230-a0-i2c > >> compatible string. I also didn't expect that we found "new" product using the A0 version. > >> > >> We have 3 options now: > >> > >> - remove the check on the openblock AX3 board and always try to apply the quirck for A0 version > >> - add a check for this new board in the mvebu_dt_init function > >> - let the compatible string marvell,mv78230-a0-i2c in this dts > >> > >> I would prefer the option 1 but I fear that Arnd would prefer the 2 other options. > > > > I like option 1 and 3. Option 3 is a *correct* description of the > > hardware, and should be done. Option 1 makes Linux user-friendly for boards > > that are exactly the same, but changed out SoC stepping mid-production. > > > > Option 2 needs to be undone. We shouldn't need to change compiled code > > for every new board that comes along. Which was the whole point of DT, > > right? > > > So I'm a bit puzzled now. First email from Jason mention that the > final patch was doe in 3.16rc3 and indeed I made my dts using 3.15, > now I'm on 3.16 mainline, but didn't tested since to remove the a0 > compatible string. Should I give it a try or from Gregory's email > understand that the patch was only for ax3 board ? Ignore what I said before about the patch. It doesn't apply to your board. We need to fix the quirk to trigger on SoC revision, not board compatible, as it currently does. The only outstanding point (Arnd?), is that I think it's ok to have the i2c...a0 compatible string in the dts files, but Andrew seems to think otherwise. Is that still true Andrew? > Feel free as long as the device is still opened, uart connected, to > send me your test as I'll soon have to turn into a production NAS ... Hopefully, we'll hear from one of them today, and we can merge your patch as-is with the minor comment reformatting. thx, Jason. ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS 2014-07-24 14:07 ` Jason Cooper @ 2014-07-24 14:29 ` Andrew Lunn 2014-07-24 14:56 ` Jason Cooper 0 siblings, 1 reply; 15+ messages in thread From: Andrew Lunn @ 2014-07-24 14:29 UTC (permalink / raw) To: linux-arm-kernel > The only outstanding point (Arnd?), is that I think it's ok to have the > i2c...a0 compatible string in the dts files, but Andrew seems to think > otherwise. Is that still true Andrew? Hi Jason I can live with i2c...a0 compatible string, but it has minor problems: 1) The binding Documentation says not to do it. So we are ignoring our own documentation. 2) It seems likely that at some point the OEM will swap to B1 revision SoCs. The i2c device then does not require this quirk, but we have hard coded in the DT file that it is required. B1 revision would work, but not optimally. So i would prefer not to explicitly enable the quirk, but determine at run time if the quirk is needed for the SoC revision it is running on. Andrew ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS 2014-07-24 14:29 ` Andrew Lunn @ 2014-07-24 14:56 ` Jason Cooper 0 siblings, 0 replies; 15+ messages in thread From: Jason Cooper @ 2014-07-24 14:56 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jul 24, 2014 at 04:29:18PM +0200, Andrew Lunn wrote: > > The only outstanding point (Arnd?), is that I think it's ok to have the > > i2c...a0 compatible string in the dts files, but Andrew seems to think > > otherwise. Is that still true Andrew? > > Hi Jason > > I can live with i2c...a0 compatible string, but it has minor problems: > > 1) The binding Documentation says not to do it. So we are ignoring our > own documentation. This can be updated. > 2) It seems likely that at some point the OEM will swap to B1 revision > SoCs. The i2c device then does not require this quirk, but we have > hard coded in the DT file that it is required. B1 revision would > work, but not optimally. The quirk can go both ways. eg, we can detect that we *aren't* on an A0 and need to remove the compatible string. > So i would prefer not to explicitly enable the quirk, but determine at > run time if the quirk is needed for the SoC revision it is running on. I agree, but that is Linux-centric. We need to handle it coherently in the binding docs for *BSD, bootloaders, etc. I suggest we update the binding to allow using the compatible string, and advise that to avoid end-user frustration, implementations should detect the SoC revision at runtime and either add or remove the compatible string. thx, Jason. ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 1/2] Adding Lenovo - Lenovo Group Ltd. to the vendor-prefixes list. 2014-07-23 22:35 [PATCH 1/2] Adding Lenovo - Lenovo Group Ltd. to the vendor-prefixes list Benoit Masson 2014-07-23 22:32 ` Andrew Lunn 2014-07-23 22:35 ` [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS Benoit Masson @ 2014-07-24 12:45 ` Rob Herring 2014-07-28 13:43 ` Jason Cooper 3 siblings, 0 replies; 15+ messages in thread From: Rob Herring @ 2014-07-24 12:45 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jul 23, 2014 at 5:35 PM, Benoit Masson <yahoo@perenite.com> wrote: > Lenovo Group Ltd. (stylized as lenovo) is a Chinese multinational computer technology company with headquarters in Beijing, China, and Morrisville, North Carolina, United States. > > http://www.lenovo.com/ > Signed-off-by: Benoit Masson <yahoo@perenite.com> Acked-by: Rob Herring <robh@kernel.org> > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt > index 46a311e..ae09892 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -71,6 +71,7 @@ karo Ka-Ro electronics GmbH > keymile Keymile GmbH > lacie LaCie > lantiq Lantiq Semiconductor > +lenovo Lenovo Group Ltd. > lg LG Corporation > linux Linux-specific binding > lsi LSI Corp. (LSI Logic) > -- > 1.9.1 > ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 1/2] Adding Lenovo - Lenovo Group Ltd. to the vendor-prefixes list. 2014-07-23 22:35 [PATCH 1/2] Adding Lenovo - Lenovo Group Ltd. to the vendor-prefixes list Benoit Masson ` (2 preceding siblings ...) 2014-07-24 12:45 ` [PATCH 1/2] Adding Lenovo - Lenovo Group Ltd. to the vendor-prefixes list Rob Herring @ 2014-07-28 13:43 ` Jason Cooper 3 siblings, 0 replies; 15+ messages in thread From: Jason Cooper @ 2014-07-28 13:43 UTC (permalink / raw) To: linux-arm-kernel Benoit, On Wed, Jul 23, 2014 at 03:35:22PM -0700, Benoit Masson wrote: > Lenovo Group Ltd. (stylized as lenovo) is a Chinese multinational > computer technology company with headquarters in Beijing, China, and > Morrisville, North Carolina, United States. > > http://www.lenovo.com/ > Signed-off-by: Benoit Masson <yahoo@perenite.com> > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Applied to mvebu/dt with a few minor style changes to the commit log. - Added a blank line between the URL and the S-o-B. - Reflowed the paragraph to wrap at >80 chars - Changed subject to match other changes to vendor-prefixes.txt The Subject line now reads: of: Add Lenovo Group Ltd. to the vendor-prefixes list. You can view the patch here: http://git.infradead.org/linux-mvebu.git/commitdiff/74e025501bb834000b3c7eceab69383806520a36 Next, it'll go to arm-soc. Then, Linus' tree. thx, Jason. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2014-07-28 13:43 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-23 22:35 [PATCH 1/2] Adding Lenovo - Lenovo Group Ltd. to the vendor-prefixes list Benoit Masson
2014-07-23 22:32 ` Andrew Lunn
2014-07-23 22:35 ` [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS Benoit Masson
2014-07-23 22:42 ` Andrew Lunn
2014-07-23 22:56 ` Benoit Masson
2014-07-23 22:58 ` Andrew Lunn
[not found] ` <10A7C530-7CD2-4ED0-889A-7FAC1922320F@perenite.com>
2014-07-23 23:15 ` Jason Cooper
2014-07-24 12:21 ` Gregory CLEMENT
2014-07-24 12:45 ` Jason Cooper
2014-07-24 13:29 ` Andrew Lunn
[not found] ` <C2E7C8C1-1198-4785-AB9C-C27B5E27A8D4@perenite.com>
2014-07-24 14:07 ` Jason Cooper
2014-07-24 14:29 ` Andrew Lunn
2014-07-24 14:56 ` Jason Cooper
2014-07-24 12:45 ` [PATCH 1/2] Adding Lenovo - Lenovo Group Ltd. to the vendor-prefixes list Rob Herring
2014-07-28 13:43 ` Jason Cooper
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).