From: Tom <Tom.Rix@windriver.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/8 V2] add at91 SoC access with c structures
Date: Sun, 17 Jan 2010 12:25:31 -0600 [thread overview]
Message-ID: <4B53561B.9040104@windriver.com> (raw)
In-Reply-To: <4B534D7A.8030804@scharsoft.de>
Jens Scharsig wrote:
> Please look at
>
> <http://lists.denx.de/pipermail/u-boot/2009-December/065688.html>
>
<link included>
on request by Wolfgang, I have try to implement SoC access for AT91
arch with c structures. Additional I have add support for AT91RM9200
in at91 tree.
I need to switch to a different project for more than half a year.
So I think, it's time to publish the result.
What this Patch set do:
* add's the new temporary CONFIG_AT91_LEGACY to all board configs
that not converted by this patch
* add's a warning to all files, that not converted by this patch
* add's the support for AT91RM9200 in at91 tree
* add's c stucture SoC defines
* convert all files cpu/../at91 to use c stucture SoC access
* move the at gpio access to a real driver
* add's at91_emac (AT91RM9200) network driver (NET_MULTI)
* add's a new board (eb_cpux9k2) which demonstrates, how to use
boards with AT91RM9200 cpu in at91 arch tree
* convert following board: at91sam9263ek
</link included>
This is a concatenation of all the patches long commit logs.
It is a good starting point. With a change of this size and
when it is expected for others to carry on the work, more detail
is needed.
It should be clear from the name of the patch, as appears in the subject
line or short commit log, what the patch is trying to do. Then
all the changes related to that patch should be contained in that one
commit.
For example. It is unclear without looking closely at the patch
that 7/8 is a network patch or 8/8 is a board patch.
By bisectable, i mean that early patches do not depend on later patches.
It should be possible to just apply patch 1 without applying any of
the other patch.
Patch 1 looks like is contains the union of all the config file changes.
What it should have contained was only 1 change adding CONFIG_AT91_LEGACY.
Fixing this will mean separating this changes into their logical parts
and rebasing the patchset to include then in the correct order.
This is a task best done as you develop instead of after the fact. This is
why i recommended that it may be easier to break this patchset into multiple
pieces and submit them separately.
Tom
> for Patchset details
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
next prev parent reply other threads:[~2010-01-17 18:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-16 20:28 [U-Boot] [PATCH 1/8 V2] add at91 SoC access with c structures Jens Scharsig
2010-01-17 17:34 ` Tom
2010-01-17 17:48 ` Jens Scharsig
2010-01-17 18:25 ` Tom [this message]
2010-01-17 19:02 ` Jens Scharsig
2010-01-23 11:00 ` Jens Scharsig
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=4B53561B.9040104@windriver.com \
--to=tom.rix@windriver.com \
--cc=u-boot@lists.denx.de \
/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