public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ryan Mallon <ryan@bluewatersys.com>
To: Igor Plyatov <plyatov@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux@maxim.org.za,
	nicolas.ferre@atmel.com, linux@arm.linux.org.uk,
	costa.antonior@gmail.com, plagnioj@jcrosoft.com,
	Russell King - ARM Linux <linux@arm.linux.org.uk>
Subject: Re: [PATCH v2] mach-at91: Support for gms board added
Date: Wed, 08 Dec 2010 08:53:46 +1300	[thread overview]
Message-ID: <4CFE90CA.9050004@bluewatersys.com> (raw)
In-Reply-To: <1291732927-9429-1-git-send-email-plyatov@gmail.com>

On 12/08/2010 03:42 AM, Igor Plyatov wrote:
> * The gms is a board from GeoSIG Ltd company.
>   It is based on the Stamp9G20 module from Taskit company.
> * This is a second version of the patch with adjustments according
>   to comments from Ryan Mallon.
> * This patch made for Linux 2.6.37-rc5.
> 
> Signed-off-by: Igor Plyatov <plyatov@gmail.com>
> ---

Couple more comments below.

>  arch/arm/configs/stamp9g20gms_defconfig |  147 +++++++
>  arch/arm/mach-at91/Kconfig              |    6 +
>  arch/arm/mach-at91/Makefile             |    1 +
>  arch/arm/mach-at91/board-stamp9g20gms.c |  698 +++++++++++++++++++++++++++++++
>  arch/arm/mach-at91/include/mach/gms.h   |   33 ++
>  5 files changed, 885 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/configs/stamp9g20gms_defconfig
>  create mode 100644 arch/arm/mach-at91/board-stamp9g20gms.c
>  create mode 100644 arch/arm/mach-at91/include/mach/gms.h
> 
> diff --git a/arch/arm/configs/stamp9g20gms_defconfig b/arch/arm/configs/stamp9g20gms_defconfig
> new file mode 100644
> index 0000000..c44057f
> --- /dev/null
> +++ b/arch/arm/configs/stamp9g20gms_defconfig
> @@ -0,0 +1,147 @@
> +CONFIG_EXPERIMENTAL=y
> +CONFIG_SYSVIPC=y
> +CONFIG_LOG_BUF_SHIFT=14
> +CONFIG_BLK_DEV_INITRD=y
> +CONFIG_SLAB=y
> +CONFIG_MODULES=y
> +CONFIG_MODULE_UNLOAD=y
> +CONFIG_ARCH_AT91=y
> +CONFIG_ARCH_AT91SAM9G20=y
> +CONFIG_MACH_STAMP9G20GMS=y

This is better and now looks (at a glance) almost identical to
stamp9g20_defconfig. Can you just add CONFIG_MACH_STAMP9G20GMS to
stamp9g20_defconfig and support both boards?

> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index c015b68..6bc9372 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -375,6 +375,12 @@ config MACH_STAMP9G20
>  	  evaluation board.
>  	  <http://www.taskit.de/en/>
>  
> +config MACH_STAMP9G20GMS
> +	bool "GeoSIG Stamp9G20 GMS"
> +	help
> +	  Select this if you are using taskit's Stamp9G20 with GeoSIG's GMS.
> +	  <http://www.geosig.com>
> +

Looking at this a bit more closely, the Stamp9G20 is a system on module
(SoM) board. The MACH_STAMP9G20 option supports the Stamp9G20 on
taskits's evaluation board and the MACH_PCONTROL_G20 option supports it
on the PControl carrier board. There is a reasonable amount of code
replication in each of the board files for the UARTs, NAND, MMC, etc.

Would it be better to have MACH_STAMPG20/board-stamp-9g20.c contain the
core support for the Stamp9G20 module and then each of the carrier board
files contain only the setup/devices found on the carrier board?

I don't know what the correct approach for SoMs. We are also interested
in this as we develop SoMs with carrier boards. Cc'ed Russell King for
his opinion.

<snip>

> +
> +static int pcf8574x_0x20_teardown(struct i2c_client *client, int gpio,
> +					unsigned ngpio, void *context)
> +{
> +	gpio_free(gpio + 4);

gpio_free(gpio + PCF_GPIO_ETH_DETECT)?

<snip>

> +
> +/*
> + * Compact Flash
> + */
> +#if	defined(CONFIG_PATA_AT91) || defined(CONFIG_PATA_AT91_MODULE)
> +static struct at91_cf_data __initdata stamp9g20gms_cf1_data = {
> +	.irq_pin	= AT91_PIN_PA27,
> +	.det_pin	= AT91_PIN_PB30,
> +	.rst_pin	= AT91_PIN_PB31,
> +	.chipselect	= 5,
> +	.flags		= AT91_CF_TRUE_IDE,
> +};
> +#endif /* CONFIG_PATA_AT91 */

I still think you can do away with some of these ifdef guards.
Registering the device is not a problem, and you are only saving a
handful of bytes by having this ifdef. I think the code is more
readable/maintainable without all the ifdefs.

> +/* Power Off by RTC */
> +static void stamp9g20gms_power_off(void)
> +{
> +	pr_notice("Power supply will be switched off automatically now or ");
> +	pr_notice("after 60 seconds without ArmDAS.\n");

No. It should all be one call to pr_notice on one single line so that
the full message can easily be grepped. Lines over 80 columns are
allowed for printk functions and checkpatch will not warn about this.

> +	at91_set_gpio_output(AT91_PIN_PA25, 1);
> +	/* Spin to death... */
> +	while (1)
> +		;
> +}

<snip>

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

  reply	other threads:[~2010-12-07 19:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-07 14:42 [PATCH v2] mach-at91: Support for gms board added Igor Plyatov
2010-12-07 19:53 ` Ryan Mallon [this message]
2010-12-08  8:53   ` Nicolas Ferre
2010-12-08 14:03     ` Jean-Christophe PLAGNIOL-VILLARD
2010-12-08 19:29       ` Igor Plyatov
2010-12-08 14:50     ` Christian Glindkamp
2010-12-08 20:08       ` Ryan Mallon
2010-12-09 10:15         ` [PATCH] at91: Refactor Stamp9G20 and PControl G20 board file Christian Glindkamp
2010-12-10  3:38           ` Jean-Christophe PLAGNIOL-VILLARD
2010-12-10  9:03             ` Christian Glindkamp
2010-12-10  6:19           ` Igor Plyatov
     [not found]           ` <1291909193.6251.32.camel@homepc>
2010-12-10  8:44             ` Christian Glindkamp
2010-12-10  9:45               ` Nicolas Ferre
2010-12-08 19:26   ` [PATCH v2] mach-at91: Support for gms board added Igor Plyatov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CFE90CA.9050004@bluewatersys.com \
    --to=ryan@bluewatersys.com \
    --cc=costa.antonior@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=linux@maxim.org.za \
    --cc=nicolas.ferre@atmel.com \
    --cc=plagnioj@jcrosoft.com \
    --cc=plyatov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox