| Message ID | 1349277270-24962-1-git-send-email-simon.guinot@sequanux.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Oct 03, 2012 at 05:14:30PM +0200, Simon Guinot wrote: > This patch adds DT board setup for LaCie Network Space v2 and parents, > based the Marvell Kirkwood 6281 SoC. This includes Network Space (Max) > v2 and Internet Space v2. Hi Simon At a first look, this looks good. Also nice to see you use the new gpio-fan binding. > --- a/arch/arm/mach-kirkwood/board-dt.c > +++ b/arch/arm/mach-kirkwood/board-dt.c > @@ -96,6 +96,11 @@ static void __init kirkwood_dt_init(void) > if (of_machine_is_compatible("keymile,km_kirkwood")) > km_kirkwood_init(); > > + if (of_machine_is_compatible("lacie,inetspace_v2") || > + of_machine_is_compatible("lacie,netspace_v2") || > + of_machine_is_compatible("lacie,netspace_max_v2")) > + ns2_init(); > + > of_platform_populate(NULL, kirkwood_dt_match_table, > kirkwood_auxdata_lookup, NULL); I'm not a DT policy expert. Could this be one compatibility string for all the boards? Maybe ask on the DT mainline list? > +#define NETSPACE_V2_GPIO_BLUE_LED_SLOW 29 > +#define NETSPACE_V2_GPIO_BLUE_LED_CMD 30 > + > +static struct ns2_led ns2_led_pins[] = { > + { > + .name = "ns_v2:blue:sata", > + .cmd = NETSPACE_V2_GPIO_BLUE_LED_CMD, > + .slow = NETSPACE_V2_GPIO_BLUE_LED_SLOW, > + }, > +}; > + > +static struct ns2_led_platform_data ns2_leds_data = { > + .num_leds = ARRAY_SIZE(ns2_led_pins), > + .leds = ns2_led_pins, > +}; > + > +static struct platform_device ns2_leds = { > + .name = "leds-ns2", > + .id = -1, > + .dev = { > + .platform_data = &ns2_leds_data, > + }, > +}; Have you thought about adding a DT binding for this driver? It would be nice if you could respin the patches for -rc1, when it comes out. There are changes to Makefile.boot at least required. Thanks Andrew
On Wed, Oct 03, 2012 at 05:43:10PM +0200, Andrew Lunn wrote: > On Wed, Oct 03, 2012 at 05:14:30PM +0200, Simon Guinot wrote: > > This patch adds DT board setup for LaCie Network Space v2 and parents, > > based the Marvell Kirkwood 6281 SoC. This includes Network Space (Max) > > v2 and Internet Space v2. > > Hi Simon > > At a first look, this looks good. Also nice to see you use the new > gpio-fan binding. Hi Andrew, It is nice to have this binding. It works fine. > > > --- a/arch/arm/mach-kirkwood/board-dt.c > > +++ b/arch/arm/mach-kirkwood/board-dt.c > > @@ -96,6 +96,11 @@ static void __init kirkwood_dt_init(void) > > if (of_machine_is_compatible("keymile,km_kirkwood")) > > km_kirkwood_init(); > > > > + if (of_machine_is_compatible("lacie,inetspace_v2") || > > + of_machine_is_compatible("lacie,netspace_v2") || > > + of_machine_is_compatible("lacie,netspace_max_v2")) > > + ns2_init(); > > + > > of_platform_populate(NULL, kirkwood_dt_match_table, > > kirkwood_auxdata_lookup, NULL); > > I'm not a DT policy expert. Could this be one compatibility string for > all the boards? Maybe ask on the DT mainline list? Maybe I could use "lacie,ns2_common" as a compatibility string. But this does not match any existing device. I don't know if it is correct. > > > +#define NETSPACE_V2_GPIO_BLUE_LED_SLOW 29 > > +#define NETSPACE_V2_GPIO_BLUE_LED_CMD 30 > > + > > +static struct ns2_led ns2_led_pins[] = { > > + { > > + .name = "ns_v2:blue:sata", > > + .cmd = NETSPACE_V2_GPIO_BLUE_LED_CMD, > > + .slow = NETSPACE_V2_GPIO_BLUE_LED_SLOW, > > + }, > > +}; > > + > > +static struct ns2_led_platform_data ns2_leds_data = { > > + .num_leds = ARRAY_SIZE(ns2_led_pins), > > + .leds = ns2_led_pins, > > +}; > > + > > +static struct platform_device ns2_leds = { > > + .name = "leds-ns2", > > + .id = -1, > > + .dev = { > > + .platform_data = &ns2_leds_data, > > + }, > > +}; > > Have you thought about adding a DT binding for this driver? Yes. I am on it. > > It would be nice if you could respin the patches for -rc1, when it > comes out. There are changes to Makefile.boot at least required. OK. I will. Note that this patch is based against the branch kirkwood/boards from the git repository git://git.infradead.org/users/jcooper/linux.git. Is that correct ? Thanks. Simon
On Thu, Oct 04, 2012 at 12:09:16AM +0200, Simon Guinot wrote: > On Wed, Oct 03, 2012 at 05:43:10PM +0200, Andrew Lunn wrote: > > On Wed, Oct 03, 2012 at 05:14:30PM +0200, Simon Guinot wrote: > > > This patch adds DT board setup for LaCie Network Space v2 and parents, > > > based the Marvell Kirkwood 6281 SoC. This includes Network Space (Max) > > > v2 and Internet Space v2. > > > > Hi Simon > > > > At a first look, this looks good. Also nice to see you use the new > > gpio-fan binding. > > Hi Andrew, > > It is nice to have this binding. It works fine. It good to hear that it works. There is one other board which could use it. I plan to convert it over for 3.8. I will take a look at other DT boards and see if there is any patterns which might help here, for naming of a shared compatibility string. > > Have you thought about adding a DT binding for this driver? > > Yes. I am on it. Great. Please include my CC: when you post it. > > It would be nice if you could respin the patches for -rc1, when it > > comes out. There are changes to Makefile.boot at least required. > > OK. I will. > > Note that this patch is based against the branch kirkwood/boards from > the git repository git://git.infradead.org/users/jcooper/linux.git. Is > that correct ? Its a good start. However, the Makefile.boot changes were merged in in arm-soc, and not by the Marvell maintainers in our trees. So changes across multiple arm platforms are not in Jason's tree. -rc1 will have all these changes, and forms the best base for a new board. Thanks Andrew
> > > --- a/arch/arm/mach-kirkwood/board-dt.c > > > +++ b/arch/arm/mach-kirkwood/board-dt.c > > > @@ -96,6 +96,11 @@ static void __init kirkwood_dt_init(void) > > > if (of_machine_is_compatible("keymile,km_kirkwood")) > > > km_kirkwood_init(); > > > > > > + if (of_machine_is_compatible("lacie,inetspace_v2") || > > > + of_machine_is_compatible("lacie,netspace_v2") || > > > + of_machine_is_compatible("lacie,netspace_max_v2")) > > > + ns2_init(); > > > + > > > of_platform_populate(NULL, kirkwood_dt_match_table, > > > kirkwood_auxdata_lookup, NULL); > > > > I'm not a DT policy expert. Could this be one compatibility string for > > all the boards? Maybe ask on the DT mainline list? > > Maybe I could use "lacie,ns2_common" as a compatibility string. But this > does not match any existing device. I don't know if it is correct. Hi Simon I did a bit of looking around. For kirkwood, we already have two boards sharing the same compatibility string. kirkwood-dns320.dts and kirkwood-dns325.dts both have dlink,dns-kirkwood and this is what the board-dt.c matches on. For the tegra20 soc, all boards match on nvidia,tegra20, and that is the only compatibility string in board-dt-tegra20.c. So i don't see any problem having just one compatibility string here. The question is, what is the appropriate name. How common is this common C code? Are there ns2 where this C code is not appropriate. One thing to remember is that most of this C code will soon disappear and become DT. All the mpp will be replaced with pinctrl in 3.8. I hope we can get the Ethernet setup in DT as well. You are working on ns2_led, so all the C code will be replaced by DT. So all we are really left with is power off GPIO handling. So i think the danger of using lacie,ns2_common, and then finding it does not work with some other ns2 device is quite low. What do you think? Thanks Andrew
On Thu, Oct 04, 2012 at 07:54:43AM +0200, Andrew Lunn wrote: > > > > --- a/arch/arm/mach-kirkwood/board-dt.c > > > > +++ b/arch/arm/mach-kirkwood/board-dt.c > > > > @@ -96,6 +96,11 @@ static void __init kirkwood_dt_init(void) > > > > if (of_machine_is_compatible("keymile,km_kirkwood")) > > > > km_kirkwood_init(); > > > > > > > > + if (of_machine_is_compatible("lacie,inetspace_v2") || > > > > + of_machine_is_compatible("lacie,netspace_v2") || > > > > + of_machine_is_compatible("lacie,netspace_max_v2")) > > > > + ns2_init(); > > > > + > > > > of_platform_populate(NULL, kirkwood_dt_match_table, > > > > kirkwood_auxdata_lookup, NULL); > > > > > > I'm not a DT policy expert. Could this be one compatibility string for > > > all the boards? Maybe ask on the DT mainline list? > > > > Maybe I could use "lacie,ns2_common" as a compatibility string. But this > > does not match any existing device. I don't know if it is correct. > > Hi Simon > > I did a bit of looking around. For kirkwood, we already have two > boards sharing the same compatibility string. kirkwood-dns320.dts and > kirkwood-dns325.dts both have dlink,dns-kirkwood and this is what the > board-dt.c matches on. > > For the tegra20 soc, all boards match on nvidia,tegra20, and that is the only > compatibility string in board-dt-tegra20.c. > > So i don't see any problem having just one compatibility string here. > > The question is, what is the appropriate name. How common is this > common C code? Are there ns2 where this C code is not appropriate. One > thing to remember is that most of this C code will soon disappear and > become DT. All the mpp will be replaced with pinctrl in 3.8. I hope we > can get the Ethernet setup in DT as well. You are working on ns2_led, > so all the C code will be replaced by DT. So all we are really left > with is power off GPIO handling. > > So i think the danger of using lacie,ns2_common, and then finding it > does not work with some other ns2 device is quite low. > > What do you think? The status for this ns2 boards is more or less end-of-life. I mean, this boards are no longer in production. So I think it is safe to consider the code inside board-ns2.c as common and shareable between ns2, is2 and ns2max. Once this file will be removed, the compatibility checks will be removed as well. But one could easily forget to remove the useless compatibility string "lacie,ns2_common" from the dts... Let me know your preference. Simon
On 10/04/2012 01:53 AM, Simon Guinot wrote: > On Thu, Oct 04, 2012 at 07:54:43AM +0200, Andrew Lunn wrote: >>>>> --- a/arch/arm/mach-kirkwood/board-dt.c +++ >>>>> b/arch/arm/mach-kirkwood/board-dt.c @@ -96,6 +96,11 @@ >>>>> static void __init kirkwood_dt_init(void) if >>>>> (of_machine_is_compatible("keymile,km_kirkwood")) >>>>> km_kirkwood_init(); >>>>> >>>>> + if (of_machine_is_compatible("lacie,inetspace_v2") || + >>>>> of_machine_is_compatible("lacie,netspace_v2") || + >>>>> of_machine_is_compatible("lacie,netspace_max_v2")) + >>>>> ns2_init(); + of_platform_populate(NULL, >>>>> kirkwood_dt_match_table, kirkwood_auxdata_lookup, NULL); >>>> >>>> I'm not a DT policy expert. Could this be one compatibility >>>> string for all the boards? Maybe ask on the DT mainline >>>> list? >>> >>> Maybe I could use "lacie,ns2_common" as a compatibility string. >>> But this does not match any existing device. I don't know if it >>> is correct. >> >> Hi Simon >> >> I did a bit of looking around. For kirkwood, we already have two >> boards sharing the same compatibility string. kirkwood-dns320.dts >> and kirkwood-dns325.dts both have dlink,dns-kirkwood and this is >> what the board-dt.c matches on. >> >> For the tegra20 soc, all boards match on nvidia,tegra20, and that >> is the only compatibility string in board-dt-tegra20.c. nvidia,tegra20 is the compatible value for the SoC itself, so naturally any Tegra20-based board has that. >> So i don't see any problem having just one compatibility string >> here. >> >> The question is, what is the appropriate name. How common is >> this common C code? Are there ns2 where this C code is not >> appropriate. One thing to remember is that most of this C code >> will soon disappear and become DT. All the mpp will be replaced >> with pinctrl in 3.8. I hope we can get the Ethernet setup in DT >> as well. You are working on ns2_led, so all the C code will be >> replaced by DT. So all we are really left with is power off GPIO >> handling. >> >> So i think the danger of using lacie,ns2_common, and then finding >> it does not work with some other ns2 device is quite low. lacie,ns2_common doesn't sound like a HW description, but rather a SW invention. DT should be describing purely the HW. If there's no common HW between these compatible boards (which seems unlikely), then there shouldn't be a shared compatible value. >> What do you think? > > The status for this ns2 boards is more or less end-of-life. I mean, > this boards are no longer in production. So I think it is safe to > consider the code inside board-ns2.c as common and shareable > between ns2, is2 and ns2max. > > Once this file will be removed, the compatibility checks will be > removed as well. But one could easily forget to remove the useless > compatibility string "lacie,ns2_common" from the dts... If that value is added to the DT, it should not be removed, and the kernel should continue to support it indefinitely.
> >> The question is, what is the appropriate name. How common is > >> this common C code? Are there ns2 where this C code is not > >> appropriate. One thing to remember is that most of this C code > >> will soon disappear and become DT. All the mpp will be replaced > >> with pinctrl in 3.8. I hope we can get the Ethernet setup in DT > >> as well. You are working on ns2_led, so all the C code will be > >> replaced by DT. So all we are really left with is power off GPIO > >> handling. > >> > >> So i think the danger of using lacie,ns2_common, and then finding > >> it does not work with some other ns2 device is quite low. > > lacie,ns2_common doesn't sound like a HW description, but rather a SW > invention. DT should be describing purely the HW. If there's no common > HW between these compatible boards (which seems unlikely), then there > shouldn't be a shared compatible value. Actually, there is common hardware between these boards: NS2 LED driver Pinctrl setup GPIO used for power off Ethernet configuration. At the moment, we don't have DT for these, so there is C code. The "lacie,ns2_common" compatibility string would be used to enable this C code for these boards. Andrew
On Thu, Oct 04, 2012 at 09:41:06AM -0600, Stephen Warren wrote: > On 10/04/2012 01:53 AM, Simon Guinot wrote: > > On Thu, Oct 04, 2012 at 07:54:43AM +0200, Andrew Lunn wrote: > >>>>> --- a/arch/arm/mach-kirkwood/board-dt.c +++ > >>>>> b/arch/arm/mach-kirkwood/board-dt.c @@ -96,6 +96,11 @@ > >>>>> static void __init kirkwood_dt_init(void) if > >>>>> (of_machine_is_compatible("keymile,km_kirkwood")) > >>>>> km_kirkwood_init(); > >>>>> > >>>>> + if (of_machine_is_compatible("lacie,inetspace_v2") || + > >>>>> of_machine_is_compatible("lacie,netspace_v2") || + > >>>>> of_machine_is_compatible("lacie,netspace_max_v2")) + > >>>>> ns2_init(); + of_platform_populate(NULL, > >>>>> kirkwood_dt_match_table, kirkwood_auxdata_lookup, NULL); > >>>> > >>>> I'm not a DT policy expert. Could this be one compatibility > >>>> string for all the boards? Maybe ask on the DT mainline > >>>> list? > >>> > >>> Maybe I could use "lacie,ns2_common" as a compatibility string. > >>> But this does not match any existing device. I don't know if it > >>> is correct. > >> > >> Hi Simon > >> > >> I did a bit of looking around. For kirkwood, we already have two > >> boards sharing the same compatibility string. kirkwood-dns320.dts > >> and kirkwood-dns325.dts both have dlink,dns-kirkwood and this is > >> what the board-dt.c matches on. > >> > >> For the tegra20 soc, all boards match on nvidia,tegra20, and that > >> is the only compatibility string in board-dt-tegra20.c. > > nvidia,tegra20 is the compatible value for the SoC itself, so > naturally any Tegra20-based board has that. > > >> So i don't see any problem having just one compatibility string > >> here. > >> > >> The question is, what is the appropriate name. How common is > >> this common C code? Are there ns2 where this C code is not > >> appropriate. One thing to remember is that most of this C code > >> will soon disappear and become DT. All the mpp will be replaced > >> with pinctrl in 3.8. I hope we can get the Ethernet setup in DT > >> as well. You are working on ns2_led, so all the C code will be > >> replaced by DT. So all we are really left with is power off GPIO > >> handling. > >> > >> So i think the danger of using lacie,ns2_common, and then finding > >> it does not work with some other ns2 device is quite low. > > lacie,ns2_common doesn't sound like a HW description, but rather a SW > invention. DT should be describing purely the HW. If there's no common > HW between these compatible boards (which seems unlikely), then there > shouldn't be a shared compatible value. Indeed "lacie,ns2_common" is not an hardware description. But actually, even if the PCB and the BOM are not exactly the same, there is a lot of common HW between this boards. I understand that sharing a compatible value between all this boards could be uncertain. For example, the BOMs could evolve differently during the production process and at a given time, the compatibility could be broken. But as I said, this will not happen here because this boards are no longer in production. > > >> What do you think? > > > > The status for this ns2 boards is more or less end-of-life. I mean, > > this boards are no longer in production. So I think it is safe to > > consider the code inside board-ns2.c as common and shareable > > between ns2, is2 and ns2max. > > > > Once this file will be removed, the compatibility checks will be > > removed as well. But one could easily forget to remove the useless > > compatibility string "lacie,ns2_common" from the dts... > > If that value is added to the DT, it should not be removed, and the > kernel should continue to support it indefinitely. I understand it is a strong requirement. But as I mentioned before, due to the production process, one could easily end up with an embedded DTB not matching exactly the hardware. It could even be worse. A end-of-life device could be replaced by a supposed compatible one. And sometimes the compatibility assumption is false. In a such scenario, maybe you don't want the kernel to support indefinitely a DT statement. Simon > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 10/09/2012 05:17 AM, Andrew Lunn wrote: >>>> The question is, what is the appropriate name. How common is >>>> this common C code? Are there ns2 where this C code is not >>>> appropriate. One thing to remember is that most of this C code >>>> will soon disappear and become DT. All the mpp will be replaced >>>> with pinctrl in 3.8. I hope we can get the Ethernet setup in DT >>>> as well. You are working on ns2_led, so all the C code will be >>>> replaced by DT. So all we are really left with is power off GPIO >>>> handling. >>>> >>>> So i think the danger of using lacie,ns2_common, and then finding >>>> it does not work with some other ns2 device is quite low. >> >> lacie,ns2_common doesn't sound like a HW description, but rather a SW >> invention. DT should be describing purely the HW. If there's no common >> HW between these compatible boards (which seems unlikely), then there >> shouldn't be a shared compatible value. > > Actually, there is common hardware between these boards: > > NS2 LED driver > Pinctrl setup > GPIO used for power off > Ethernet configuration. > > At the moment, we don't have DT for these, so there is C code. The > "lacie,ns2_common" compatibility string would be used to enable this C > code for these boards. The typical way to support this is to simply include a .dtsi file from both board-specific .dts file. That .dtsi file will provide the description of the two common pieces of hardware. In the interim where you're stilling using some board file C code rather than DT for this common part, just trigger that C code from any of the compatible values for the boards where it's needed. Don't invent a new compatible value that means "run this C code".
On 10/09/2012 09:05 AM, Simon Guinot wrote: > On Thu, Oct 04, 2012 at 09:41:06AM -0600, Stephen Warren wrote: >> On 10/04/2012 01:53 AM, Simon Guinot wrote: >>> On Thu, Oct 04, 2012 at 07:54:43AM +0200, Andrew Lunn wrote: >>>>>>> --- a/arch/arm/mach-kirkwood/board-dt.c +++ >>>>>>> b/arch/arm/mach-kirkwood/board-dt.c @@ -96,6 +96,11 @@ >>>>>>> static void __init kirkwood_dt_init(void) if >>>>>>> (of_machine_is_compatible("keymile,km_kirkwood")) >>>>>>> km_kirkwood_init(); >>>>>>> >>>>>>> + if (of_machine_is_compatible("lacie,inetspace_v2") || >>>>>>> + of_machine_is_compatible("lacie,netspace_v2") || + >>>>>>> of_machine_is_compatible("lacie,netspace_max_v2")) + >>>>>>> ns2_init(); + of_platform_populate(NULL, >>>>>>> kirkwood_dt_match_table, kirkwood_auxdata_lookup, >>>>>>> NULL); >>>>>> >>>>>> I'm not a DT policy expert. Could this be one >>>>>> compatibility string for all the boards? Maybe ask on the >>>>>> DT mainline list? >>>>> >>>>> Maybe I could use "lacie,ns2_common" as a compatibility >>>>> string. But this does not match any existing device. I >>>>> don't know if it is correct. ... >>> The status for this ns2 boards is more or less end-of-life. I >>> mean, this boards are no longer in production. So I think it is >>> safe to consider the code inside board-ns2.c as common and >>> shareable between ns2, is2 and ns2max. >>> >>> Once this file will be removed, the compatibility checks will >>> be removed as well. But one could easily forget to remove the >>> useless compatibility string "lacie,ns2_common" from the >>> dts... >> >> If that value is added to the DT, it should not be removed, and >> the kernel should continue to support it indefinitely. > > I understand it is a strong requirement. But as I mentioned before, > due to the production process, one could easily end up with an > embedded DTB not matching exactly the hardware. It could even be > worse. A end-of-life device could be replaced by a supposed > compatible one. And sometimes the compatibility assumption is > false. In a such scenario, maybe you don't want the kernel to > support indefinitely a DT statement. I'm not sure I fully understand that last paragraph. However, if the board is replaced by a new board model, and that new board model is not 100% SW-compatible with the old model, then you'll want to invent a new compatible value to represent the new board version. Removing support from the kernel for the old compatible value, or keeping the same compatible value and changing how the kernel handles it in a way that prevents the original board and .dts from working, is not appropriate.
diff --git a/arch/arm/boot/dts/kirkwood-is2.dts b/arch/arm/boot/dts/kirkwood-is2.dts new file mode 100644 index 0000000..6390db5 --- /dev/null +++ b/arch/arm/boot/dts/kirkwood-is2.dts @@ -0,0 +1,20 @@ +/dts-v1/; + +/include/ "kirkwood-ns2-common.dtsi" + +/ { + model = "LaCie Internet Space v2"; + compatible = "lacie,inetspace_v2", "marvell,kirkwood-88f6281", "marvell,kirkwood"; + + memory { + device_type = "memory"; + reg = <0x00000000 0x8000000>; + }; + + ocp@f1000000 { + sata@80000 { + status = "okay"; + nr-ports = <1>; + }; + }; +}; diff --git a/arch/arm/boot/dts/kirkwood-ns2-common.dtsi b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi new file mode 100644 index 0000000..030904d --- /dev/null +++ b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi @@ -0,0 +1,63 @@ +/include/ "kirkwood.dtsi" + +/ { + chosen { + bootargs = "console=ttyS0,115200n8"; + }; + + ocp@f1000000 { + serial@12000 { + clock-frequency = <166666667>; + status = "okay"; + }; + + spi@10600 { + status = "okay"; + + flash@0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "mx25l4005a"; + reg = <0>; + spi-max-frequency = <20000000>; + mode = <0>; + + partition@0 { + reg = <0x0 0x80000>; + label = "u-boot"; + }; + }; + }; + + i2c@11000 { + status = "okay"; + + eeprom@50 { + compatible = "at,24c04"; + pagesize = <16>; + reg = <0x50>; + }; + }; + }; + + gpio_keys { + compatible = "gpio-keys"; + #address-cells = <1>; + #size-cells = <0>; + + button@1 { + label = "Power push button"; + linux,code = <116>; + gpios = <&gpio1 0 0>; + }; + }; + + gpio-leds { + compatible = "gpio-leds"; + + red-fail { + label = "ns_v2:red:fail"; + gpios = <&gpio0 12 0>; + }; + }; +}; diff --git a/arch/arm/boot/dts/kirkwood-ns2.dts b/arch/arm/boot/dts/kirkwood-ns2.dts new file mode 100644 index 0000000..6ef66b9 --- /dev/null +++ b/arch/arm/boot/dts/kirkwood-ns2.dts @@ -0,0 +1,20 @@ +/dts-v1/; + +/include/ "kirkwood-ns2-common.dtsi" + +/ { + model = "LaCie Network Space v2"; + compatible = "lacie,netspace_v2", "marvell,kirkwood-88f6281", "marvell,kirkwood"; + + memory { + device_type = "memory"; + reg = <0x00000000 0x10000000>; + }; + + ocp@f1000000 { + sata@80000 { + status = "okay"; + nr-ports = <1>; + }; + }; +}; diff --git a/arch/arm/boot/dts/kirkwood-ns2max.dts b/arch/arm/boot/dts/kirkwood-ns2max.dts new file mode 100644 index 0000000..30ed909 --- /dev/null +++ b/arch/arm/boot/dts/kirkwood-ns2max.dts @@ -0,0 +1,39 @@ +/dts-v1/; + +/include/ "kirkwood-ns2-common.dtsi" + +/ { + model = "LaCie Network Space Max v2"; + compatible = "lacie,netspace_max_v2", "marvell,kirkwood-88f6281", "marvell,kirkwood"; + + memory { + device_type = "memory"; + reg = <0x00000000 0x10000000>; + }; + + ocp@f1000000 { + sata@80000 { + status = "okay"; + nr-ports = <2>; + }; + }; + + gpio_fan { + compatible = "gpio-fan"; + gpios = <&gpio0 22 1 + &gpio0 7 1 + &gpio1 1 1 + &gpio0 23 1>; + gpio-fan,speed-map = + < 0 0 + 1500 15 + 1700 14 + 1800 13 + 2100 12 + 3100 11 + 3300 10 + 4300 9 + 5500 8>; + alarm-gpios = <&gpio0 25 1>; + }; +}; diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig index 50bca50..5b239a6 100644 --- a/arch/arm/mach-kirkwood/Kconfig +++ b/arch/arm/mach-kirkwood/Kconfig @@ -130,6 +130,14 @@ config MACH_KM_KIRKWOOD_DT Say 'Y' here if you want your kernel to support the Keymile Kirkwood Reference Desgin, using Flattened Device Tree. +config MACH_NETSPACE_V2_DT + bool "LaCie Network Space v2 NAS and parents (Flattened Device Tree)" + select ARCH_KIRKWOOD_DT + help + Say 'Y' here if you want your kernel to support the LaCie + Network Space v2 NAS and parents, using Flattened Device Tree. + This includes Network Space (Max) v2 and Internet Space v2. + config MACH_TS219 bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS" help diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile index 294779f..0562753 100644 --- a/arch/arm/mach-kirkwood/Makefile +++ b/arch/arm/mach-kirkwood/Makefile @@ -31,3 +31,4 @@ obj-$(CONFIG_MACH_GOFLEXNET_DT) += board-goflexnet.o obj-$(CONFIG_MACH_LSXL_DT) += board-lsxl.o obj-$(CONFIG_MACH_IOMEGA_IX2_200_DT) += board-iomega_ix2_200.o obj-$(CONFIG_MACH_KM_KIRKWOOD_DT) += board-km_kirkwood.o +obj-$(CONFIG_MACH_NETSPACE_V2_DT) += board-ns2.o diff --git a/arch/arm/mach-kirkwood/Makefile.boot b/arch/arm/mach-kirkwood/Makefile.boot index 5edef8e..1e15c37 100644 --- a/arch/arm/mach-kirkwood/Makefile.boot +++ b/arch/arm/mach-kirkwood/Makefile.boot @@ -15,3 +15,4 @@ dtb-$(CONFIG_MACH_LSXL_DT) += kirkwood-lsxhl.dtb dtb-$(CONFIG_MACH_IOMEGA_IX2_200_DT) += kirkwood-iomega_ix2_200.dtb dtb-$(CONFIG_MACH_DOCKSTAR_DT) += kirkwood-dockstar.dtb dtb-$(CONFIG_MACH_KM_KIRKWOOD_DT) += kirkwood-km_kirkwood.dtb +dtb-$(CONFIG_MACH_NETSPACE_V2_DT) += kirkwood-ns2.dtb diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c index 4965546..f1746b3 100644 --- a/arch/arm/mach-kirkwood/board-dt.c +++ b/arch/arm/mach-kirkwood/board-dt.c @@ -96,6 +96,11 @@ static void __init kirkwood_dt_init(void) if (of_machine_is_compatible("keymile,km_kirkwood")) km_kirkwood_init(); + if (of_machine_is_compatible("lacie,inetspace_v2") || + of_machine_is_compatible("lacie,netspace_v2") || + of_machine_is_compatible("lacie,netspace_max_v2")) + ns2_init(); + of_platform_populate(NULL, kirkwood_dt_match_table, kirkwood_auxdata_lookup, NULL); } @@ -112,6 +117,9 @@ static const char *kirkwood_dt_board_compat[] = { "buffalo,lsxl", "iom,ix2-200", "keymile,km_kirkwood", + "lacie,inetspace_v2", + "lacie,netspace_max_v2", + "lacie,netspace_v2", NULL }; diff --git a/arch/arm/mach-kirkwood/board-ns2.c b/arch/arm/mach-kirkwood/board-ns2.c new file mode 100644 index 0000000..f87abad --- /dev/null +++ b/arch/arm/mach-kirkwood/board-ns2.c @@ -0,0 +1,117 @@ +/* + * Copyright 2012 (C), Simon Guinot <simon.guinot@sequanux.org> + * + * arch/arm/mach-kirkwood/board-ns2.c + * + * LaCie Network Space v2 board (and parents) initialization for drivers + * not converted to flattened device tree yet. + * + * 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 kind, whether express or implied. + */ + +#include <linux/kernel.h> +#include <linux/init.h> +#include <linux/platform_device.h> +#include <linux/mv643xx_eth.h> +#include <linux/gpio.h> +#include <mach/leds-ns2.h> +#include "common.h" +#include "mpp.h" + +static struct mv643xx_eth_platform_data ns2_ge00_data = { + .phy_addr = MV643XX_ETH_PHY_ADDR(8), +}; + +/***************************************************************************** + * Dual-GPIO CPLD LEDs + ****************************************************************************/ + +#define NETSPACE_V2_GPIO_BLUE_LED_SLOW 29 +#define NETSPACE_V2_GPIO_BLUE_LED_CMD 30 + +static struct ns2_led ns2_led_pins[] = { + { + .name = "ns_v2:blue:sata", + .cmd = NETSPACE_V2_GPIO_BLUE_LED_CMD, + .slow = NETSPACE_V2_GPIO_BLUE_LED_SLOW, + }, +}; + +static struct ns2_led_platform_data ns2_leds_data = { + .num_leds = ARRAY_SIZE(ns2_led_pins), + .leds = ns2_led_pins, +}; + +static struct platform_device ns2_leds = { + .name = "leds-ns2", + .id = -1, + .dev = { + .platform_data = &ns2_leds_data, + }, +}; + +/***************************************************************************** + * General Setup + ****************************************************************************/ + +static unsigned int ns2_mpp_config[] __initdata = { + MPP0_SPI_SCn, + MPP1_SPI_MOSI, + MPP2_SPI_SCK, + MPP3_SPI_MISO, + MPP4_NF_IO6, + MPP5_NF_IO7, + MPP6_SYSRST_OUTn, + MPP7_GPO, /* Fan speed (bit 1) */ + MPP8_TW0_SDA, + MPP9_TW0_SCK, + MPP10_UART0_TXD, + MPP11_UART0_RXD, + MPP12_GPO, /* Red led */ + MPP14_GPIO, /* USB fuse */ + MPP16_GPIO, /* SATA 0 power */ + MPP17_GPIO, /* SATA 1 power */ + MPP18_NF_IO0, + MPP19_NF_IO1, + MPP20_SATA1_ACTn, + MPP21_SATA0_ACTn, + MPP22_GPIO, /* Fan speed (bit 0) */ + MPP23_GPIO, /* Fan power */ + MPP24_GPIO, /* USB mode select */ + MPP25_GPIO, /* Fan rotation fail */ + MPP26_GPIO, /* USB device vbus */ + MPP28_GPIO, /* USB enable host vbus */ + MPP29_GPIO, /* Blue led (slow register) */ + MPP30_GPIO, /* Blue led (command register) */ + MPP31_GPIO, /* Board power off */ + MPP32_GPIO, /* Power button (0 = Released, 1 = Pushed) */ + MPP33_GPO, /* Fan speed (bit 2) */ + 0 +}; + +#define NETSPACE_V2_GPIO_POWER_OFF 31 + +static void ns2_power_off(void) +{ + gpio_set_value(NETSPACE_V2_GPIO_POWER_OFF, 1); +} + +void __init ns2_init(void) +{ + /* + * Basic setup. Needs to be called early. + */ + kirkwood_mpp_conf(ns2_mpp_config); + + kirkwood_ehci_init(); + kirkwood_ge00_init(&ns2_ge00_data); + platform_device_register(&ns2_leds); + + if (gpio_request(NETSPACE_V2_GPIO_POWER_OFF, "power-off") == 0 && + gpio_direction_output(NETSPACE_V2_GPIO_POWER_OFF, 0) == 0) + pm_power_off = ns2_power_off; + else + pr_err("ns2: failed to configure power-off GPIO\n"); +} diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h index bcffd7c..f6c0fc9 100644 --- a/arch/arm/mach-kirkwood/common.h +++ b/arch/arm/mach-kirkwood/common.h @@ -112,6 +112,12 @@ void km_kirkwood_init(void); static inline void km_kirkwood_init(void) {}; #endif +#ifdef CONFIG_MACH_NETSPACE_V2_DT +void ns2_init(void); +#else +static inline void ns2_init(void) {}; +#endif + /* early init functions not converted to fdt yet */ char *kirkwood_id(void); void kirkwood_l2_init(void); diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index c96bbaa..483ef81 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -367,7 +367,8 @@ config LEDS_NS2 tristate "LED support for Network Space v2 GPIO LEDs" depends on LEDS_CLASS depends on MACH_NETSPACE_V2 || MACH_INETSPACE_V2 || \ - MACH_NETSPACE_MAX_V2 || MACH_D2NET_V2 + MACH_NETSPACE_MAX_V2 || MACH_D2NET_V2 || \ + MACH_NETSPACE_V2_DT default y help This option enable support for the dual-GPIO LED found on the
This patch adds DT board setup for LaCie Network Space v2 and parents, based the Marvell Kirkwood 6281 SoC. This includes Network Space (Max) v2 and Internet Space v2. Signed-off-by: Simon Guinot <simon.guinot@sequanux.org> --- arch/arm/boot/dts/kirkwood-is2.dts | 20 +++++ arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 63 +++++++++++++++ arch/arm/boot/dts/kirkwood-ns2.dts | 20 +++++ arch/arm/boot/dts/kirkwood-ns2max.dts | 39 ++++++++++ arch/arm/mach-kirkwood/Kconfig | 8 ++ arch/arm/mach-kirkwood/Makefile | 1 + arch/arm/mach-kirkwood/Makefile.boot | 1 + arch/arm/mach-kirkwood/board-dt.c | 8 ++ arch/arm/mach-kirkwood/board-ns2.c | 117 ++++++++++++++++++++++++++++ arch/arm/mach-kirkwood/common.h | 6 ++ drivers/leds/Kconfig | 3 +- 11 files changed, 285 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/kirkwood-is2.dts create mode 100644 arch/arm/boot/dts/kirkwood-ns2-common.dtsi create mode 100644 arch/arm/boot/dts/kirkwood-ns2.dts create mode 100644 arch/arm/boot/dts/kirkwood-ns2max.dts create mode 100644 arch/arm/mach-kirkwood/board-ns2.c