From: christian.glindkamp@taskit.de (Christian Glindkamp)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] at91: Refactor Stamp9G20 and PControl G20 board file
Date: Fri, 10 Dec 2010 10:03:24 +0100 [thread overview]
Message-ID: <20101210090324.GB24295@taskit.de> (raw)
In-Reply-To: <20101210033850.GC19897@game.jcrosoft.org>
On 2010-12-10 04:38, Jean-Christophe PLAGNIOL-VILLARD wrote:
> HI,
>
> If the hardware are so near I do need to the need to create a new
> machine use system_rev to auto detect it will be better
>
> but we need to have only one defconfig as done on rm9200
> it's really reduce the maintainance and allow to be sure when we
> compile the at91sam9g20_defconfig that we do not brake any board
>
> if a board have incompatible option please the system_rev to specify
> them or a specific entry in the Kconfig for this board it will allow
> also to known this information for the maintainance
Just because it is near does not mean it is a revision of the other
board. Just compare
http://www.taskit.de/en/products/portuxg20/index.htm
http://www.taskit.de/en/products/stamp9g20/starterkit.htm
Apart from that, both boards are correctly identifiable via the machine
id for a year, respectively one and a half year for the Stamp9G20 EVB.
Why change it for sake of change?
They both have there own machine id to make it clear that these are
really different boards. I could have also submitted two board files
and maybe nobody would have noticed that share a lot, but I thought code
reuse is better so there are in the same file.
And for different carrier boards, system_rev does not make sense at all.
>
> Best Regards,
> J.
> On 11:15 Thu 09 Dec , Christian Glindkamp wrote:
> > As PControl G20 is a carrier board for the Stamp9G20 SoM, some code can
> > be shared. Therefore board-stamp9g20.c is refactored to allow reusing the
> > SoM initialization and board-pcontrol-g20.c is modified to use it.
> >
> > Signed-off-by: Christian Glindkamp <christian.glindkamp@taskit.de>
> > ---
> >
> > How about this approach? Compile tested for PControl G20 and run time tested
> > for Stamp9G20 EVB and PortuxG20.
> >
> > Just a side note: PortuxG20 is not a carrier board for the Stamp9G20. It just
> > shares so much with the evaluation board, that it makes sense to put them both
> > into the same file. And there is no intention to put other boards into this
> > file.
> >
> > arch/arm/mach-at91/Makefile | 2 +-
> > arch/arm/mach-at91/board-pcontrol-g20.c | 98 +--------------------------
> > arch/arm/mach-at91/board-stamp9g20.c | 82 ++++++++++++-----------
> > arch/arm/mach-at91/include/mach/stamp9g20.h | 7 ++
> > 4 files changed, 54 insertions(+), 135 deletions(-)
> > create mode 100644 arch/arm/mach-at91/include/mach/stamp9g20.h
WARNING: multiple messages have this Message-ID (diff)
From: Christian Glindkamp <christian.glindkamp@taskit.de>
To: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Ryan Mallon <ryan@bluewatersys.com>,
linux@arm.linux.org.uk, costa.antonior@gmail.com,
Igor Plyatov <plyatov@gmail.com>,
Nicolas Ferre <nicolas.ferre@atmel.com>,
linux-kernel@vger.kernel.org, linux@maxim.org.za,
linux-arm-kernel@lists.infradead.org,
pgsellmann@portner-elektronik.at
Subject: Re: [PATCH] at91: Refactor Stamp9G20 and PControl G20 board file
Date: Fri, 10 Dec 2010 10:03:24 +0100 [thread overview]
Message-ID: <20101210090324.GB24295@taskit.de> (raw)
In-Reply-To: <20101210033850.GC19897@game.jcrosoft.org>
On 2010-12-10 04:38, Jean-Christophe PLAGNIOL-VILLARD wrote:
> HI,
>
> If the hardware are so near I do need to the need to create a new
> machine use system_rev to auto detect it will be better
>
> but we need to have only one defconfig as done on rm9200
> it's really reduce the maintainance and allow to be sure when we
> compile the at91sam9g20_defconfig that we do not brake any board
>
> if a board have incompatible option please the system_rev to specify
> them or a specific entry in the Kconfig for this board it will allow
> also to known this information for the maintainance
Just because it is near does not mean it is a revision of the other
board. Just compare
http://www.taskit.de/en/products/portuxg20/index.htm
http://www.taskit.de/en/products/stamp9g20/starterkit.htm
Apart from that, both boards are correctly identifiable via the machine
id for a year, respectively one and a half year for the Stamp9G20 EVB.
Why change it for sake of change?
They both have there own machine id to make it clear that these are
really different boards. I could have also submitted two board files
and maybe nobody would have noticed that share a lot, but I thought code
reuse is better so there are in the same file.
And for different carrier boards, system_rev does not make sense at all.
>
> Best Regards,
> J.
> On 11:15 Thu 09 Dec , Christian Glindkamp wrote:
> > As PControl G20 is a carrier board for the Stamp9G20 SoM, some code can
> > be shared. Therefore board-stamp9g20.c is refactored to allow reusing the
> > SoM initialization and board-pcontrol-g20.c is modified to use it.
> >
> > Signed-off-by: Christian Glindkamp <christian.glindkamp@taskit.de>
> > ---
> >
> > How about this approach? Compile tested for PControl G20 and run time tested
> > for Stamp9G20 EVB and PortuxG20.
> >
> > Just a side note: PortuxG20 is not a carrier board for the Stamp9G20. It just
> > shares so much with the evaluation board, that it makes sense to put them both
> > into the same file. And there is no intention to put other boards into this
> > file.
> >
> > arch/arm/mach-at91/Makefile | 2 +-
> > arch/arm/mach-at91/board-pcontrol-g20.c | 98 +--------------------------
> > arch/arm/mach-at91/board-stamp9g20.c | 82 ++++++++++++-----------
> > arch/arm/mach-at91/include/mach/stamp9g20.h | 7 ++
> > 4 files changed, 54 insertions(+), 135 deletions(-)
> > create mode 100644 arch/arm/mach-at91/include/mach/stamp9g20.h
next prev parent reply other threads:[~2010-12-10 9:03 UTC|newest]
Thread overview: 28+ 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 14:42 ` Igor Plyatov
2010-12-07 19:53 ` Ryan Mallon
2010-12-07 19:53 ` Ryan Mallon
2010-12-08 8:53 ` Nicolas Ferre
2010-12-08 8:53 ` Nicolas Ferre
2010-12-08 14:03 ` Jean-Christophe PLAGNIOL-VILLARD
2010-12-08 14:03 ` Jean-Christophe PLAGNIOL-VILLARD
2010-12-08 19:29 ` Igor Plyatov
2010-12-08 19:29 ` Igor Plyatov
2010-12-08 14:50 ` Christian Glindkamp
2010-12-08 14:50 ` Christian Glindkamp
2010-12-08 20:08 ` Ryan Mallon
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-09 10:15 ` Christian Glindkamp
2010-12-10 3:38 ` Jean-Christophe PLAGNIOL-VILLARD
2010-12-10 3:38 ` Jean-Christophe PLAGNIOL-VILLARD
2010-12-10 9:03 ` Christian Glindkamp [this message]
2010-12-10 9:03 ` Christian Glindkamp
2010-12-10 6:19 ` Igor Plyatov
2010-12-10 6:19 ` Igor Plyatov
[not found] ` <1291909193.6251.32.camel@homepc>
2010-12-10 8:44 ` Christian Glindkamp
2010-12-10 8:44 ` Christian Glindkamp
2010-12-10 9:45 ` Nicolas Ferre
2010-12-10 9:45 ` Nicolas Ferre
2010-12-08 19:26 ` [PATCH v2] mach-at91: Support for gms board added Igor Plyatov
2010-12-08 19:26 ` 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=20101210090324.GB24295@taskit.de \
--to=christian.glindkamp@taskit.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.