[PATCH] mach-kirkwood: Support for DLink DNS-320 & DNS-325 NAS

Jason jason at lakedaemon.net
Wed Mar 7 09:45:35 EST 2012 

On Wed, Mar 07, 2012 at 02:25:10PM +0000, Jamie Lentin wrote:
> On Thu, 1 Mar 2012, Jason wrote:
> 
> >On Wed, Feb 29, 2012 at 02:40:10PM +0000, Arnd Bergmann wrote:
> >>On Sunday 12 February 2012, Jamie Lentin wrote:
> >>>This patch adds support for the D-Link DNS-320 & DNS-325 NAS. Kirkwood-based
> >>>successors to the DNS-323.
> >>>
> >>>Signed-off-by: Jamie Lentin <jm at lentin.co.uk>
> >>>---
> >>>My previous patch supported just the DNS-325, the DNS-320 is a very similar
> >>>device and so I've combined the support for both devices into one board support
> >>>file. The main difference with the DNS-320 is that the temperature sensor
> >>>is accessed via ttyS1 instead of I2C (I have a userland script to do this).
> >>>
> >>>I appreciate board support files like this are old hat and should be using
> >>>device tree instead. If I should be focusing on that instead of getting this
> >>>merged, some pointers would be very useful.
> >>
> >>Hi Jamie,
> >>
> >>I just saw this patch going through the mailing list and noticed that you
> >>had sent it out another time before without getting any reply.
> >>
> >>I'm sorry that you did not get any feedback on this. Jason Cooper had a
> >>similar patch and he ended up a bit more fortunate than you, since he
> >>got support for the kirkwood based "dreamplug" into the arm-soc tree
> >>and is working on converting that to device tree now.
> >>
> >>I would suggest that you two team up and put DNS-32x support into the new
> >>common board-dt.c file as well.
> >
> >Jamie,
> >
> >Take a look at the dreamplug initial support patch series, latest here
> >[1].  Make a kirkwood-dns-320.dts and a kirkwood-dns-325.dts file
> >mimicing kirkwood-dreamplug.dts.  All you should need to start out is
> >the compatible property and memory.
> >
> >[1] http://www.spinics.net/lists/arm-kernel/msg161696.html
> 
> Excellent, thank you both! This is definitely enough to get me
> going. All the patches seem to be in staging/kirkwood/dt, is
> submitting based on this tree reasonable too?

newest version is here:

git://git.infradead.org/users/jcooper/linux-kirkwood.git kirkwood_dt

> Will try to use CONFIG_ARM_APPENDED_DTB to get it booting, as
> D-Link's u-boot is probably not devicetree aware. Or is there a
> better approach (apart from a JTAG programmer and replacing u-boot)?

That's fine for testing, but upgrading u-boot is definitely advised.  I
have yet to find a commercially distributed u-boot binary worth a d*mn.

> >>Some more comments:
> >>
> >>>diff --git a/arch/arm/mach-kirkwood/dnskw-setup.c b/arch/arm/mach-kirkwood/dnskw-setup.c
> >>>new file mode 100644
> >>>index 0000000..25ea0fa
> >>>--- /dev/null
> >>>+++ b/arch/arm/mach-kirkwood/dnskw-setup.c
> >>>@@ -0,0 +1,431 @@
> >>>+/*
> >>>+ * arch/arm/mach-kirkwood/dnskw-setup.c
> >>
> >>All future boards should ideally go through a single board file, and the plan
> >>is to work on minimizing the non-generic contents of that over time.
> >>Right now, it only contains support for the dreamplug, but there is no
> >>reason why this one couldn't get merged into it as well.
> >>
> 
> Definitely do-able, although I'm tempted to leave out anything
> non-essential to avoid board-dt.c becoming too unweildy. The MPP
> config and it's comments summarise my research, the rest is C+P code
> that could be reconstructed.

As more drivers are converted to DT, board-dt.c will shrink.  If pinmux
becomes too unwieldy, we can break it out into a separate file(s).

> >>>+static struct mtd_partition dnskw_nand_parts[] = {
> >>>+	{
> >>>+		.name		= "u-boot",
> >>>+		.offset		= 0,
> >>>+		.size		= SZ_1M,
> >>>+		.mask_flags	= MTD_WRITEABLE
> >>>+	}, {
> >>>+		.name		= "uImage",
> >>>+		.offset		= MTDPART_OFS_NXTBLK,
> >>>+		.size		= 5 * SZ_1M
> >>>+	}, {
> >>>+		.name		= "ramdisk",
> >>>+		.offset		= MTDPART_OFS_NXTBLK,
> >>>+		.size		= 5 * SZ_1M
> >>>+	}, {
> >>>+		.name		= "image",
> >>>+		.offset		= MTDPART_OFS_NXTBLK,
> >>>+		.size		= 102 * SZ_1M
> >>>+	}, {
> >>>+		.name		= "mini firmware",
> >>>+		.offset		= MTDPART_OFS_NXTBLK,
> >>>+		.size		= 10 * SZ_1M
> >>>+	}, {
> >>>+		.name		= "config",
> >>>+		.offset		= MTDPART_OFS_NXTBLK,
> >>>+		.size		= 5 * SZ_1M
> >>>+	},
> >>>+};
> >>
> >>Jason already has a patch for NAND partitions through the SPI attachment,
> >>I would suggest that you do the same for the nand controller, the patch
> >>should be fairly similar.
> >>
> 
> Found this and can see what needs doing. Will attempt this after
> getting the basic devicetree support sorted.
> 
> >>>+/*****************************************************************************
> >>>+ * Power controls
> >>>+ ****************************************************************************/
> >>>+
> >>>+static void dnskw_power_off(void)
> >>>+{
> >>>+	gpio_set_value(DNSKW_GPIO_POWER, 1);
> >>>+}
> >>>... <snip -- lots of gpio stuff>
> >>
> >>The entire gpio setup is rather complex, and I don't know how much of it
> >>can be handled with the existing gpio device tree bindings. I hope someone
> >>else can comment here.
> >>
> 
> Turning on the HDDs is something a lot of NASes need to do. I wonder
> if the functionality to do so should be added to sata_mv. I don't
> know anywhere near enough to say if this makes sense, but could have
> a wild stab at a patch if it's not completely stupid.

sata_mv is in the latest series.

> The power-recovery pin is probably just random D-Link weirdness. The
> GPIO needs to be raised high on each boot to ensure the NAS turns
> back on after power failure. Just operating it from userland would
> work, although registering as a GPIO off/on-able switch would be
> neater. I'm not sure if anything similar exists?
> 
> >>>+/*****************************************************************************
> >>>+ * Main init
> >>>+ ****************************************************************************/
> >>>+
> >>>+static void __init dnskw_init(void)
> >>>+{
> >>>+	u32 dev, rev;
> >>>+
> >>>+	/*
> >>>+	 * Basic setup. Needs to be called early.
> >>>+	 */
> >>>+	kirkwood_init();
> >>>+	kirkwood_mpp_conf(dnskw_mpp_config);
> >>
> >>There is now a kirkwood_dt_init function that calls the board specific
> >>functions based on an of_machine_is_compatible() check. Best add anything
> >>from this function in there that cannot be handled using device tree
> >>probing yet.
> >>
> >>>+	kirkwood_uart0_init();
> >>>+	kirkwood_uart1_init();
> >>
> >>These can be done from the device tree already.
> >>
> >>>+	kirkwood_nand_init(ARRAY_AND_SIZE(dnskw_nand_parts), 25);
> >>
> >>This is the one I mentioned above that I think you should try to convert.
> >>
> >>>+	kirkwood_ehci_init();

This is converted.

> >>>+	kirkwood_i2c_init();
> >>>+	kirkwood_ge00_init(&dnskw_ge00_data);

> >>>+	kirkwood_sata_init(&dnskw_sata_data);

And so is this one.

> >>
> >>These should be handled next, but not necessarily before this board
> >>supports makes it into the upstream kernel. Adding the bindings for
> >>these should be fairly straightforward, and it will get easier
> >>if kirkwood is first converted to use the generic clock framework.
> >
> >I've got a handle on these after I do xor and crypto.  If you get to it
> >before I do, hit sata and ge00/01.  I'll start with ehci and i2c.
> >
> 
> Okay---I'll let you know if I do get that far.

ge and i2c are going to take a little work and coordination with Andrew
Lunn, he's doing the common clock stuff for orion.

> >>>+#ifdef CONFIG_MACH_DNS320
> >>>+	if (machine_is_dns320())
> >>>+		platform_device_register(&dns320_led_device);
> >>>+#endif
> >>>+#ifdef CONFIG_MACH_DNS325
> >>>+	if (machine_is_dns325()) {
> >>>+		platform_device_register(&dns325_led_device);
> >>>+
> >>>+		i2c_register_board_info(0, dns325_i2c_board_info,
> >>>+					ARRAY_SIZE(dns325_i2c_board_info));
> >>>+	}
> >>>+#endif
> >>>+
> >>>+	/*
> >>>+	 * Turn on power to harddrives, then enable SATA.
> >>>+	 * NB: Bootloader should have turned sata0 on already, kernel needs
> >>>+	 * to turn on sata1. The idea is to stagger spin-up of HDDs.
> >>>+	 */
> >>>+	dnskw_gpio_register(DNSKW_GPIO_POWER_SATA0, "dnskw:power:sata0", 1);
> >>>+	dnskw_gpio_register(DNSKW_GPIO_POWER_SATA1, "dnskw:power:sata1", 1);
> >>>+
> >>>+	platform_device_register(&dnskw_button_device);
> >>>+	platform_device_register(&dnskw_fan_device);
> >>
> >>It should be possible to handle all this by putting the right devices
> >>into the device tree, but I don't know how to do that.
> >>
> 
> arch/arm/boot/dts/imx53-qsb.dts amongst others have some examples,
> will steal them and see what happens.
> 
> >>>+	/* Register power off routine */
> >>>+	kirkwood_pcie_id(&dev, &rev);
> >>>+	if (dev == MV88F6281_DEV_ID) {
> >>>+		pr_info("PCI-E Device ID: MV88F6281, configuring power-off");
> >>>+		if (gpio_request(DNSKW_GPIO_POWER, "dnskw:power:off") == 0 &&
> >>>+		    gpio_direction_output(DNSKW_GPIO_POWER, 0) == 0)
> >>>+			pm_power_off = dnskw_power_off;
> >>>+		else
> >>>+			pr_err("dnskw: failed to configure power-off GPIO\n");
> >>>+	} else {
> >>>+		/*
> >>>+		 * Dlink code also defines 0x6192, and sets LOW_BASE +
> >>>+		 * 0x01000000 high. Either cargo-culted code or another model.
> >>>+		 */
> >>>+		pr_err("Unknown PCI-E Device ID %x, no power-off", dev);
> >>>+	}
> >>>+
> >>>+	/* Set state of power_recover pin */
> >>>+	if (gpio_request(DNSKW_GPIO_POWER_RECOVER, "dnskw:power:recover") == 0
> >>>+	 && gpio_direction_output(DNSKW_GPIO_POWER_RECOVER, 0) == 0) {
> >>>+		pr_info("dnskw: Setting power-recover %s\n",
> >>>+			power_recover_value ? "on" : "off");
> >>>+		gpio_set_value(DNSKW_GPIO_POWER_RECOVER, power_recover_value);
> >>>+	} else
> >>>+		pr_err("dnskw: Failed to register power-recover GPIO\n");
> >>>+}
> >>
> >>This might have to stay board specific.
> >>
> >>>+#ifdef CONFIG_MACH_DNS320
> >>>+MACHINE_START(DNS320, "D-Link DNS-320")
> >>>+	/* Maintainer: Jamie Lentin <jm at lentin.co.uk> */
> >>>+	.atag_offset	= 0x100,
> >>>+	.init_machine	= dnskw_init,
> >>>+	.map_io		= kirkwood_map_io,
> >>>+	.init_early	= kirkwood_init_early,
> >>>+	.init_irq	= kirkwood_init_irq,
> >>>+	.timer		= &kirkwood_timer,
> >>>+	.restart	= kirkwood_restart,
> >>>+MACHINE_END
> >>>+#endif
> >>>+
> >>>+#ifdef CONFIG_MACH_DNS325
> >>>+MACHINE_START(DNS325, "D-Link DNS-325")
> >>>+	/* Maintainer: Jamie Lentin <jm at lentin.co.uk> */
> >>>+	.atag_offset	= 0x100,
> >>>+	.init_machine	= dnskw_init,
> >>>+	.map_io		= kirkwood_map_io,
> >>>+	.init_early	= kirkwood_init_early,
> >>>+	.init_irq	= kirkwood_init_irq,
> >>>+	.timer		= &kirkwood_timer,
> >>>+	.restart	= kirkwood_restart,
> >>>+MACHINE_END
> >>>+#endif
> >>
> >>Just use DT_MACHINE_START here and remove the machine ID and atag_offset. See
> >>the board-dt.c file.
> >
> >See the link [1], above.
> >
> >thx,
> >
> >Jason.
> >
> 
> -- 
> Jamie Lentin

More information about the linux-arm-kernel mailing list