From: Dirk Behme <dirk.behme@googlemail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Creating u-boot-arm-omap3 branch
Date: Sun, 02 Nov 2008 19:41:08 +0100 [thread overview]
Message-ID: <490DF444.7030501@googlemail.com> (raw)
At IRC we had a short discussion what might be the best way how to go
on with OMAP3 patch series. We are now at version 5 of this patch set,
unfortunately there are still review comments open [1]. On the other
hand, from reviewer point of view, sending patch series again and
again (v6, v7, ...) would need always a complete re-review as reviewer
can't be sure that no new changes slipped into already reviewed patch
parts.
Therefore, Jean-Christophe kindly offered to create an
u-boot-arm-omap3 git branch with v5 patch set just sent. We see
several advantages:
First, the patch set is more visible for people able to test and
hopefully willing to help sending patches. Second, only patches to fix
the open/new review results have to be send to the list and not whole
patch series. Third, this will avoid need for re-review of whole patch
series as only the (smaller) fixes have to be reviewed, not the whole
series again. And fourth, just in case I will disappear, the branch
can be just deleted if there is no progress to make it mainline ready
(in contrast to adding OMAP3 now to mainline and trusting that I will
fix the remaining issues in mainline).
Once we think that OMAP3 patch set in u-boot-arm-omap3 branch is ready
for mainline, it will be extracted (e.g. by git-rebase -i) and resend
for final inclusion/review to U-Boot list again. This will avoid git
pollution with "fix style here" "fix style there" commits.
Thanks for your patience and help, best regards
Dirk
[1] Review comments still open:
1) Use readx/writex with base + offset with base being e.g. from
uint32_t. NAND driver gpmc_omap.c is already (hopefully correctly)
converted to this style and can be taken as example.
2) For start.S, function cpu_init_crit():
cpu_init_crit: "why create function that could be call from c also"
cpu_init_crit: "why create function that could be call from c also
this could be availlable for all cache/mmu/interruptions function"
Jean-Christophe likes that this code can be called from C, too.
3) Replace all hard coded values with macros.
The main places I know are
- misc_init_r() in the board files (evm.c, overo.c, beagle.c)
- dpll_param tables in lowlevel_init.S (to be done like core_dpll_param)
- do_sdrc_init() in mem.c
x) Hopefully all other comments are already fixed. More review
comments are welcome
next reply other threads:[~2008-11-02 18:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-02 18:41 Dirk Behme [this message]
2008-11-02 20:02 ` [U-Boot] Creating u-boot-arm-omap3 branch Dirk Behme
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=490DF444.7030501@googlemail.com \
--to=dirk.behme@googlemail.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 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.