All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.