[U-Boot] Please pull u-boot-atmel/master
Dear Albert,
The following changes since commit 0d8bc1c7b3caffd5626b6cf4888bfb5751f24041: Fabio Estevam (1): mx31pdk: Add DHCP command
are available in the git repository at:
git://git.denx.de/u-boot-atmel.git master
Eric Benard (4): arm926ejs/at91/lowlevel_init.S: fix defines cpu9260/9G20: fix board support cpuat91: fix board support include/asm/arch-at91: update several .h files to ATMEL_xxx name scheme
Jens Scharsig (1): update arm/at91rm9200 work with rework rework110202
Reinhard Meyer (3): AT91 rework: fix at91sam(9260/9g20/9xe)ek board port to build again: AT91 rework: fix TOP9000 files to build again ATMEL spi_dataflash driver - fix to build again
Ryan Mallon (1): Add support for Bluewater Systems Snapper 9260/9G20 modules
Sergey Lapin (1): Build fix/update of AFEB9260
andreas.devel@googlemail.com (2): at91_emac: fix compile warning macb: fix compile warning
MAINTAINERS | 5 + MAKEALL | 3 - Makefile | 45 ----- arch/arm/cpu/arm920t/at91/reset.c | 2 +- arch/arm/cpu/arm920t/at91/timer.c | 12 +- arch/arm/cpu/arm926ejs/at91/lowlevel_init.S | 24 ++-- arch/arm/include/asm/arch-at91/at91_matrix.h | 10 +- arch/arm/include/asm/arch-at91/at91_mc.h | 12 +- arch/arm/include/asm/arch-at91/at91_pio.h | 14 +- arch/arm/include/asm/arch-at91/at91_pmc.h | 10 +- arch/arm/include/asm/arch-at91/at91_rstc.h | 2 +- arch/arm/include/asm/arch-at91/at91_wdt.h | 2 +- arch/arm/include/asm/arch-at91/at91rm9200.h | 209 ++++++++++++---------- arch/arm/include/asm/arch-at91/at91sam9260.h | 1 + arch/arm/include/asm/arch-at91/at91sam9261.h | 1 + arch/arm/include/asm/arch-at91/at91sam9263.h | 1 + arch/arm/include/asm/arch-at91/at91sam9_sdramc.h | 30 ++-- arch/arm/include/asm/arch-at91/at91sam9_smc.h | 12 +- board/BuS/eb_cpux9k2/cpux9k2.c | 52 +++--- board/afeb9260/afeb9260.c | 101 ++++++----- board/atmel/at91rm9200ek/at91rm9200ek.c | 4 +- board/atmel/at91rm9200ek/led.c | 22 ++- board/atmel/at91sam9260ek/at91sam9260ek.c | 127 +++++++------ board/atmel/at91sam9260ek/config.mk | 1 - board/atmel/at91sam9260ek/led.c | 8 +- board/bluewater/snapper9260/Makefile | 53 ++++++ board/bluewater/snapper9260/snapper9260.c | 169 +++++++++++++++++ board/emk/top9000/top9000.c | 64 ++++--- board/eukrea/cpu9260/cpu9260.c | 33 ++-- board/eukrea/cpu9260/led.c | 6 +- board/eukrea/cpuat91/cpuat91.c | 6 +- boards.cfg | 9 + drivers/net/at91_emac.c | 44 +++--- drivers/net/macb.c | 5 +- drivers/spi/atmel_dataflash_spi.c | 3 +- include/configs/afeb9260.h | 78 +++++---- include/configs/at91rm9200ek.h | 5 +- include/configs/at91sam9260ek.h | 107 +++++++----- include/configs/cpu9260.h | 11 +- include/configs/eb_cpux9k2.h | 23 ++-- include/configs/snapper9260.h | 191 ++++++++++++++++++++ include/configs/top9000.h | 30 ++-- 42 files changed, 996 insertions(+), 551 deletions(-) delete mode 100644 board/atmel/at91sam9260ek/config.mk create mode 100644 board/bluewater/snapper9260/Makefile create mode 100644 board/bluewater/snapper9260/snapper9260.c create mode 100644 include/configs/snapper9260.h
Best Regards, Reinhard
Hi Reinhard,
Le 20/06/2011 08:49, Reinhard Meyer a écrit :
Dear Albert,
The following changes since commit 0d8bc1c7b3caffd5626b6cf4888bfb5751f24041: Fabio Estevam (1): mx31pdk: Add DHCP command
are available in the git repository at:
git://git.denx.de/u-boot-atmel.git master
Eric Benard (4): arm926ejs/at91/lowlevel_init.S: fix defines cpu9260/9G20: fix board support cpuat91: fix board support include/asm/arch-at91: update several .h files to ATMEL_xxx name scheme
Jens Scharsig (1): update arm/at91rm9200 work with rework rework110202
Reinhard Meyer (3): AT91 rework: fix at91sam(9260/9g20/9xe)ek board port to build again: AT91 rework: fix TOP9000 files to build again ATMEL spi_dataflash driver - fix to build again
Ryan Mallon (1): Add support for Bluewater Systems Snapper 9260/9G20 modules
Sergey Lapin (1): Build fix/update of AFEB9260
andreas.devel@googlemail.com (2): at91_emac: fix compile warning macb: fix compile warning
Applied, thanks!
Amicalement,
Dear Albert ARIBAUD,
In message 4DFF3389.30200@aribaud.net you wrote:
git://git.denx.de/u-boot-atmel.git master
...
Applied, thanks!
Thanks. Can you please send an ARM pull req ASAP, too, so we can get -rc3 out?
Thanks a lot in advance.
Best regards,
Wolfgang Denk
Dear Wolfgang Denk:
Dear Albert ARIBAUD,
In message 4DFF3389.30200@aribaud.net you wrote:
git://git.denx.de/u-boot-atmel.git master
...
Applied, thanks!
Thanks. Can you please send an ARM pull req ASAP, too, so we can get -rc3 out?
Thanks a lot in advance.
Just to explain: those patches do only fix 9260 based and 9200 based SoCs and boards.
Other patches still need some rework and I did not want that to delay RC3.
They will have to be in next.
Best Regards, Reinhard
Hi Wolfgang,
Le 20/06/2011 15:44, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4DFF3389.30200@aribaud.net you wrote:
git://git.denx.de/u-boot-atmel.git master...
Applied, thanks!
Thanks. Can you please send an ARM pull req ASAP, too, so we can get -rc3 out?
I can do a pull request now, but if I did and if Prafulla actually wanted the marvell next branch to be pulled in ARM master for inclusion in 2011-06, I'll then have to issue yet another pull req after rc3. Would that be ok with you?
Thanks a lot in advance.
Best regards,
Wolfgang Denk
Amicalement,
Dear Albert ARIBAUD,
In message 4DFF737A.4040202@aribaud.net you wrote:
I can do a pull request now, but if I did and if Prafulla actually wanted the marvell next branch to be pulled in ARM master for inclusion in 2011-06, I'll then have to issue yet another pull req after rc3. Would that be ok with you?
No. I understand MV next branch is not intended to go into this release. When -rc3 is out, we may create a next branch, where this can be pulled into.
Best regards,
Wolfgang Denk
Hi Wolfgang,
Le 20/06/2011 21:43, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4DFF737A.4040202@aribaud.net you wrote:
I can do a pull request now, but if I did and if Prafulla actually wanted the marvell next branch to be pulled in ARM master for inclusion in 2011-06, I'll then have to issue yet another pull req after rc3. Would that be ok with you?
No. I understand MV next branch is not intended to go into this release. When -rc3 is out, we may create a next branch, where this can be pulled into.
Wolfgang: I am not as convinced as you are about the MV next branch pull request not being intended for this release: the custodian wiki addresses pull requests for master branches only, and considers next branches only as temp storage for commits accepted outside a merge window. Next branches are supposed to be used only to rebase the master the same repo; there is no process, nor reason, reason to ask for a pull of a next branch. So if Prafulla asked for a pull, it may be that he actually wanted a pull into ARM master, somehow mentally squezing the 'rebase MV master onto MV next then ask for a pull of master' process.
Prafulla: can you make it clear onto which branch of ARM, master or next, you intend MV next to be pulled? Please let me know before 7:30 GMT+2. Around 8:00 GMT+2 I'll issue a pull request for ARM/master, with or without MV next pulled in.
Best regards,
Wolfgang Denk
Amicalement,
Dear Albert ARIBAUD,
In message 4DFFB961.7070406@aribaud.net you wrote:
No. I understand MV next branch is not intended to go into this release. When -rc3 is out, we may create a next branch, where this can be pulled into.
Wolfgang: I am not as convinced as you are about the MV next branch pull request not being intended for this release: the custodian wiki
Prafulla, can you please comment what your actual intentions were, i. e. wether Albert or me are interpreting your pull request correctly?
addresses pull requests for master branches only, and considers next branches only as temp storage for commits accepted outside a merge window. ...
Right, but that means (or is supposed to mean - sorry if this is not documented clear enough) that all custodians can do this as well, i. e. they can pull patches into their own "next" branches and send pull requests for the next branch.
... Next branches are supposed to be used only to rebase the masterthe same repo; there is no process, nor reason, reason to ask for a pull of a next branch. ...
I disagree here.
It makes perfecxt sense to keep the stack of open patches small, and a next branch is a good way to handle stuff that is waiting for the next merge window to open.
The only issue with this is that I am not very strict with this process; theoretically we should (1) create -rc1 as soon as the merge window closes and all patches have checked in, and (2) create a "next" branch as soon as we have -rc1.
My problems with this is that usually there is a lot of unprocesses stuff queued when the MW closes, so I wait with the -rc1 until at least most of this has gone in; additionally I wait with "next" until I feel the tree is reasonable stable - in the current release for example I'm waiting for all these ARM build fixes, i. e. especially the AT91 stuff.
... So if Prafulla asked for a pull, it may be that heactually wanted a pull into ARM master, somehow mentally squezing the 'rebase MV master onto MV next then ask for a pull of master' process.
I don't think so.
Best regards,
Wolfgang Denk
participants (3)
-
Albert ARIBAUD -
Reinhard Meyer -
Wolfgang Denk