[U-Boot-Users] Please pull 85xx

[U-Boot-Users] Please pull 85xx

[Andy Fleming]

This includes current changes in the libfdt testing branch, as they are 
required for the 85xx changes to work.  If we need to rework this a 
different way, let me know.  I'm not afraid of rebasing.

The following changes since commit 
41be969f4957115ed7b1fe8b890bfaee99d7a7a2:
  Wolfgang Denk (1):
        Release v1.3.1

are found in the git repository at:

  git://www.denx.de/git/u-boot-mpc85xx.git

Gerald Van Baren (2):
      Add spaces around the = in the fdt print format.
      Conditionally compile fdt_fixup_ethernet()

Haiying Wang (1):
      Add PCI Express support on MPC8568MDS

Kumar Gala (25):
      Fix build breakage due to libfdt import
      Conditionally compile fdt_support.c
      Add common memory fixup function
      Added fdt_fixup_stdout that uses aliases to set linux,stdout-path
      Convert boards that set memory node to use fdt_fixup_memory()
      Add libfdt based ft_cpu_setup for mpc85xx
      Update MPC8544DS to use libfdt
      Update MPC8544 DS config
      Stop using immap_t for guts offset on 85xx
      Stop using immap_t for cpm offset on 85xx
      Update MPC8560 ADS to use libfdt
      Update MPC8540 ADS to use libfdt
      Update MPC85xx CDS to use libfdt
      Update MPC8568 MDS to use libfdt
      Remove CONFIG_OF_FLAT_TREE related code from mpc85xx since we now 
use libfdt
      Stop using immap_t on 85xx
      Use standard LAWAR_TRGT_IF_* defines for LAW setup on 85xx
      Move the MPC8568 MDS board under board/freescale.
      Move the MPC8560 ADS board under board/freescale.
      Move the MPC8540 ADS board under board/freescale.
      Move the MPC8541/MPC8555/MPC8548 CDS board under board/freescale.
      Update Freescale MPC85xx ADS/CDS/MDS board config
      Handle Asynchronous DDR clock on 85xx
      Update Freescale MPC85xx ADS/CDS/MDS board config
      Handle MPC85xx PCIe reset errata (PCI-Ex 38)

 Makefile                                           |   12 +-
 board/cds/mpc8548cds/Makefile                      |   60 -----
 board/cds/mpc8555cds/Makefile                      |   60 -----
 board/cds/mpc8555cds/init.S                        |  255 
------------------
 board/cds/mpc8555cds/u-boot.lds                    |  150 -----------
 board/cm5200/cm5200.c                              |   15 +-
 board/{cds => freescale}/common/cadmus.c           |    0 
 board/{cds => freescale}/common/cadmus.h           |    0 
 board/{cds => freescale}/common/eeprom.c           |    0 
 board/{cds => freescale}/common/eeprom.h           |    0 
 board/{cds => freescale}/common/ft_board.c         |   50 ++--
 board/{cds => freescale}/common/via.c              |    0 
 board/{cds => freescale}/common/via.h              |    0 
 board/{ => freescale}/mpc8540ads/Makefile          |    0 
 board/{ => freescale}/mpc8540ads/config.mk         |    0 
 board/{ => freescale}/mpc8540ads/init.S            |    0 
 board/{ => freescale}/mpc8540ads/mpc8540ads.c      |   44 ++--
 board/{ => freescale}/mpc8540ads/u-boot.lds        |    4 +-
 board/{cds => freescale}/mpc8541cds/Makefile       |    0 
 board/{cds => freescale}/mpc8541cds/config.mk      |    0 
 board/{cds => freescale}/mpc8541cds/init.S         |    0 
 board/{cds => freescale}/mpc8541cds/mpc8541cds.c   |   44 +++-
 board/{cds => freescale}/mpc8541cds/u-boot.lds     |    4 +-
 board/freescale/mpc8544ds/init.S                   |   25 +--
 board/freescale/mpc8544ds/mpc8544ds.c              |   81 +++---
 .../mpc8541cds => freescale/mpc8548cds}/Makefile   |    0 
 board/{cds => freescale}/mpc8548cds/config.mk      |    0 
 board/{cds => freescale}/mpc8548cds/init.S         |   25 +--
 board/{cds => freescale}/mpc8548cds/mpc8548cds.c   |   58 ++---
 board/{cds => freescale}/mpc8548cds/u-boot.lds     |    4 +-
 .../mpc8541cds => freescale/mpc8555cds}/Makefile   |    0 
 board/{cds => freescale}/mpc8555cds/config.mk      |    0 
 .../mpc8541cds => freescale/mpc8555cds}/init.S     |    0 
 board/{cds => freescale}/mpc8555cds/mpc8555cds.c   |   44 +++-
 .../mpc8541cds => freescale/mpc8555cds}/u-boot.lds |    4 +-
 .../{mpc8540ads => freescale/mpc8560ads}/Makefile  |    0 
 board/{ => freescale}/mpc8560ads/config.mk         |    0 
 board/{mpc8540ads => freescale/mpc8560ads}/init.S  |    0 
 board/{ => freescale}/mpc8560ads/mpc8560ads.c      |   62 ++---
 board/{ => freescale}/mpc8560ads/u-boot.lds        |    4 +-
 board/{ => freescale}/mpc8568mds/Makefile          |    4 +-
 board/{ => freescale}/mpc8568mds/bcsr.c            |    0 
 board/{ => freescale}/mpc8568mds/bcsr.h            |    0 
 board/{ => freescale}/mpc8568mds/config.mk         |    0 
 board/{ => freescale}/mpc8568mds/init.S            |   10 +-
 board/{ => freescale}/mpc8568mds/mpc8568mds.c      |  182 ++++++++++++-
 board/{ => freescale}/mpc8568mds/u-boot.lds        |    4 +-
 board/ids8247/ids8247.c                            |   17 +-
 board/mpc8540eval/mpc8540eval.c                    |   14 +-
 board/mpc8560ads/Makefile                          |   52 ----
 board/mpc8560ads/init.S                            |  280 
--------------------
 board/mpc8568mds/ft_board.c                        |   45 ---
 board/pm854/pm854.c                                |   14 +-
 board/pm856/pm856.c                                |   11 +-
 board/sbc8560/sbc8560.c                            |   14 +-
 board/stxgp3/stxgp3.c                              |    6 +-
 board/stxssa/stxssa.c                              |    6 +-
 board/tqm85xx/sdram.c                              |    6 +-
 board/tqm85xx/tqm85xx.c                            |    8 +-
 common/Makefile                                    |    3 +-
 common/cmd_fdt.c                                   |    4 +-
 common/fdt_support.c                               |  130 +++++++++-
 cpu/mpc83xx/cpu.c                                  |   18 +--
 cpu/mpc85xx/Makefile                               |    4 +-
 cpu/mpc85xx/commproc.c                             |   28 +-
 cpu/mpc85xx/cpu.c                                  |  124 ++--------
 cpu/mpc85xx/cpu_init.c                             |   16 +-
 cpu/mpc85xx/ether_fcc.c                            |   54 ++--
 cpu/mpc85xx/fdt.c                                  |   64 +++++
 cpu/mpc85xx/interrupts.c                           |   10 +-
 cpu/mpc85xx/pci.c                                  |   34 +---
 cpu/mpc85xx/qe_io.c                                |    4 +-
 cpu/mpc85xx/serial_scc.c                           |   35 ++--
 cpu/mpc85xx/spd_sdram.c                            |   17 +-
 cpu/mpc85xx/speed.c                                |   34 ++-
 cpu/mpc85xx/traps.c                                |    4 +-
 drivers/pci/fsl_pci_init.c                         |   23 ++
 include/asm-ppc/immap_85xx.h                       |   45 ++--
 include/asm-ppc/immap_fsl_pci.h                    |    4 +-
 include/asm-ppc/iopin_85xx.h                       |   40 ++--
 include/asm-ppc/mmu.h                              |    4 +-
 include/common.h                                   |    1 +
 include/configs/MPC8540ADS.h                       |   12 +-
 include/configs/MPC8541CDS.h                       |   13 +-
 include/configs/MPC8544DS.h                        |  119 ++-------
 include/configs/MPC8548CDS.h                       |  103 +-------
 include/configs/MPC8555CDS.h                       |   13 +-
 include/configs/MPC8560ADS.h                       |   14 +-
 include/configs/MPC8568MDS.h                       |   39 ++-
 include/e500.h                                     |    1 +
 include/fdt_support.h                              |    1 +
 include/ioports.h                                  |    2 +-
 92 files changed, 909 insertions(+), 1786 deletions(-)
 delete mode 100644 board/cds/mpc8548cds/Makefile
 delete mode 100644 board/cds/mpc8555cds/Makefile
 delete mode 100644 board/cds/mpc8555cds/init.S
 delete mode 100644 board/cds/mpc8555cds/u-boot.lds
 rename board/{cds => freescale}/common/cadmus.c (100%)
 rename board/{cds => freescale}/common/cadmus.h (100%)
 rename board/{cds => freescale}/common/eeprom.c (100%)
 rename board/{cds => freescale}/common/eeprom.h (100%)
 rename board/{cds => freescale}/common/ft_board.c (70%)
 rename board/{cds => freescale}/common/via.c (100%)
 rename board/{cds => freescale}/common/via.h (100%)
 copy board/{ => freescale}/mpc8540ads/Makefile (100%)
 rename board/{ => freescale}/mpc8540ads/config.mk (100%)
 copy board/{ => freescale}/mpc8540ads/init.S (100%)
 rename board/{ => freescale}/mpc8540ads/mpc8540ads.c (90%)
 rename board/{ => freescale}/mpc8540ads/u-boot.lds (98%)
 copy board/{cds => freescale}/mpc8541cds/Makefile (100%)
 rename board/{cds => freescale}/mpc8541cds/config.mk (100%)
 copy board/{cds => freescale}/mpc8541cds/init.S (100%)
 rename board/{cds => freescale}/mpc8541cds/mpc8541cds.c (95%)
 copy board/{cds => freescale}/mpc8541cds/u-boot.lds (98%)
 copy board/{cds/mpc8541cds => freescale/mpc8548cds}/Makefile (100%)
 rename board/{cds => freescale}/mpc8548cds/config.mk (100%)
 rename board/{cds => freescale}/mpc8548cds/init.S (90%)
 rename board/{cds => freescale}/mpc8548cds/mpc8548cds.c (92%)
 rename board/{cds => freescale}/mpc8548cds/u-boot.lds (97%)
 rename board/{cds/mpc8541cds => freescale/mpc8555cds}/Makefile (100%)
 rename board/{cds => freescale}/mpc8555cds/config.mk (100%)
 rename board/{cds/mpc8541cds => freescale/mpc8555cds}/init.S (100%)
 rename board/{cds => freescale}/mpc8555cds/mpc8555cds.c (95%)
 rename board/{cds/mpc8541cds => freescale/mpc8555cds}/u-boot.lds (98%)
 rename board/{mpc8540ads => freescale/mpc8560ads}/Makefile (100%)
 rename board/{ => freescale}/mpc8560ads/config.mk (100%)
 rename board/{mpc8540ads => freescale/mpc8560ads}/init.S (100%)
 rename board/{ => freescale}/mpc8560ads/mpc8560ads.c (94%)
 rename board/{ => freescale}/mpc8560ads/u-boot.lds (98%)
 rename board/{ => freescale}/mpc8568mds/Makefile (97%)
 rename board/{ => freescale}/mpc8568mds/bcsr.c (100%)
 rename board/{ => freescale}/mpc8568mds/bcsr.h (100%)
 rename board/{ => freescale}/mpc8568mds/config.mk (100%)
 rename board/{ => freescale}/mpc8568mds/init.S (97%)
 rename board/{ => freescale}/mpc8568mds/mpc8568mds.c (65%)
 rename board/{ => freescale}/mpc8568mds/u-boot.lds (98%)
 delete mode 100644 board/mpc8560ads/Makefile
 delete mode 100644 board/mpc8560ads/init.S
 delete mode 100644 board/mpc8568mds/ft_board.c
 create mode 100644 cpu/mpc85xx/fdt.c

[U-Boot-Users] Please pull 85xx

[Jerry Van Baren]

Andy Fleming wrote:
> This includes current changes in the libfdt testing branch, as they are 
> required for the 85xx changes to work.  If we need to rework this a 
> different way, let me know.  I'm not afraid of rebasing.
> 
> The following changes since commit 
> 41be969f4957115ed7b1fe8b890bfaee99d7a7a2:
>   Wolfgang Denk (1):
>         Release v1.3.1
> 
> are found in the git repository at:
> 
>   git://www.denx.de/git/u-boot-mpc85xx.git
> 
> Gerald Van Baren (2):
>       Add spaces around the = in the fdt print format.
>       Conditionally compile fdt_fixup_ethernet()
> 
> Haiying Wang (1):
>       Add PCI Express support on MPC8568MDS
> 
> Kumar Gala (25):
>       Fix build breakage due to libfdt import
>       Conditionally compile fdt_support.c
 >	:

[snip]

Including the libfdt testing branch is fine by me.  Kim and I did a bit 
of patch swapping in August (same issue, patch interdependencies) and 
git magically figured it all out (Linus' choice to use a hash to 
identify patches was very smart).

Thanks,
gvb

[U-Boot-Users] Please pull 85xx

[Wolfgang Denk]

In message <Pine.LNX.4.61.0712112338550.25073@ld0175-tx32.am.freescale.net> you wrote:
> This includes current changes in the libfdt testing branch, as they are 
> required for the 85xx changes to work.  If we need to rework this a 
> different way, let me know.  I'm not afraid of rebasing.

I really hate such pull requests  that  include  changes  from  other
repositories like yours is doing.

If you need the libfdt stuff, fine, please use it for your work, but
do not include this into the branch you request me to pull from. 

Please keep the custodian's repositories separated and  allow  me  to
decide what to pull, and when.

The next time I will reject such a pull request.

> The following changes since commit 
> 41be969f4957115ed7b1fe8b890bfaee99d7a7a2:
>   Wolfgang Denk (1):
>         Release v1.3.1
> 
> are found in the git repository at:
> 
>   git://www.denx.de/git/u-boot-mpc85xx.git

Merged. Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"When people are least sure, they are often most dogmatic."
- John Kenneth Galbraith

[U-Boot-Users] Please pull 85xx

[Stefan Roese]

On Thursday 27 December 2007, Wolfgang Denk wrote:
> > This includes current changes in the libfdt testing branch, as they are
> > required for the 85xx changes to work.  If we need to rework this a
> > different way, let me know.  I'm not afraid of rebasing.
>
> I really hate such pull requests  that  include  changes  from  other
> repositories like yours is doing.
>
> If you need the libfdt stuff, fine, please use it for your work, but
> do not include this into the branch you request me to pull from.

That can be very hard sometimes. Please note that I had the same problem and 
also included the libfdt changes from Kumar into the 4xx for-1.3.2 branch, 
since this brings all this fdt work to a very nice status. Without it, it is 
nearly impossible to do any decent fdt stuff anymore. And since you didn't 
pull the changes from Jerry into the master or testing repository at that 
time, we *had* to do something to have a chance to get the stuff ready for 
merging within the merge window.

I am aware that you didn't find the time to do this at that time, but we had 
to act to not miss the merge window with all our changes. So please 
understand why we did it this way (Andy, please correct me if I don't speak 
for you here).

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot-Users] Please pull 85xx

[Wolfgang Denk]

In message <200712271701.09072.sr@denx.de> you wrote:
>
> That can be very hard sometimes. Please note that I had the same problem and 
> also included the libfdt changes from Kumar into the 4xx for-1.3.2 branch, 
> since this brings all this fdt work to a very nice status. Without it, it is 
> nearly impossible to do any decent fdt stuff anymore. And since you didn't 
> pull the changes from Jerry into the master or testing repository at that 
> time, we *had* to do something to have a chance to get the stuff ready for 
> merging within the merge window.

But when you pull any other repository into your tree, you leave me no
option wether I want to accept this repo as iis or request changes or
if I want to omit parts of it for one reason or another.

When I'm pulling the libfdt repo, I will check what's in there, but
when I pull the 4xx repo, I do NOT want to have to check any other
repo in parallel, too.

Sorry, if there are such dependencies, then please drop me a note and
we will find a way to dort it out. YOu know that I will try  to  help
if somebody has a reasonable request.

The current situation is not acceptable to me. The custodian  reposi-
tories  are supposed to be strictly orthogonal to each other. If they
are not, I will refuse to pull.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
PoB = "Prisoner of Bill" -- those held captive, unwillingly or other-
wise, by the contemptible Microsoft monopoly.
         -- Tom Christiansen in <6abo45$3lc$2@csnews.cs.colorado.edu>

[U-Boot-Users] Please pull 85xx

[Stefan Roese]

On Thursday 27 December 2007, Wolfgang Denk wrote:
> > That can be very hard sometimes. Please note that I had the same problem
> > and also included the libfdt changes from Kumar into the 4xx for-1.3.2
> > branch, since this brings all this fdt work to a very nice status.
> > Without it, it is nearly impossible to do any decent fdt stuff anymore.
> > And since you didn't pull the changes from Jerry into the master or
> > testing repository at that time, we *had* to do something to have a
> > chance to get the stuff ready for merging within the merge window.
>
> But when you pull any other repository into your tree, you leave me no
> option wether I want to accept this repo as iis or request changes or
> if I want to omit parts of it for one reason or another.
>
> When I'm pulling the libfdt repo, I will check what's in there, but
> when I pull the 4xx repo, I do NOT want to have to check any other
> repo in parallel, too.

If I understand this correctly, then recent git versions are capable of 
handling such cases without problems. Meaning pulling patches from another 
repo, that are allready present should cause no problems.

> Sorry, if there are such dependencies, then please drop me a note and
> we will find a way to dort it out. YOu know that I will try  to  help
> if somebody has a reasonable request.

I did ask you once or twice about this fdt repo, but I should have have been 
more insistant.

> The current situation is not acceptable to me. The custodian  reposi-
> tories  are supposed to be strictly orthogonal to each other. If they
> are not, I will refuse to pull.

Right. Generally I share this opinion. All this is probably something we have 
to "learn" in the next few merge windows.

I'll try to remove the already commited fdt patches from my repo and merge 
with mainline before asking you to pull from the 4xx repo. OK?

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot-Users] Please pull 85xx

[Wolfgang Denk]

In message <200712271922.50572.sr@denx.de> you wrote:
>
> > When I'm pulling the libfdt repo, I will check what's in there, but
> > when I pull the 4xx repo, I do NOT want to have to check any other
> > repo in parallel, too.
> 
> If I understand this correctly, then recent git versions are capable of 
> handling such cases without problems. Meaning pulling patches from another 
> repo, that are allready present should cause no problems.

Yes, *if* they are present, and if they are identical.

If I decide not to pull libfdt yet  for  some  reason  (for  example,
because  I  rejected  partrs  of  it and now wait for a new version),
pulling from your repo will sneak in the code I intended to reject.

If your version and what I  pulled  (and  eventually  modified)  from
libfdt differ, who knows what the end resulkt would look like?

> > Sorry, if there are such dependencies, then please drop me a note and
> > we will find a way to dort it out. YOu know that I will try  to  help
> > if somebody has a reasonable request.
> 
> I did ask you once or twice about this fdt repo, but I should have have been 
> more insistant.

Sorry, it seems I did not understand the importance of that request.
Sorry.

> I'll try to remove the already commited fdt patches from my repo and merge 
> with mainline before asking you to pull from the 4xx repo. OK?

Just rebase your stuff against current version and this should resolve
easily, I guess.

Here it was easy, as I accepted libfdt as it  was,  an  you  probably
have the correct code, too. But it could have been worse.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"When the only  tool  you  have  is  a  hammer,  you  tend  to  treat
everything as if it were a nail."                    - Abraham Maslow

[U-Boot-Users] Please pull 85xx

[Andy Fleming]

On Dec 26, 2007 5:38 PM, Wolfgang Denk <wd@denx.de> wrote:

> In message <Pine.LNX.4.61.0712112338550.25073@ld0175-tx32.am.freescale.net>
> you wrote:
> > This includes current changes in the libfdt testing branch, as they are
> > required for the 85xx changes to work.  If we need to rework this a
> > different way, let me know.  I'm not afraid of rebasing.
>
> I really hate such pull requests  that  include  changes  from  other
> repositories like yours is doing.
>
> If you need the libfdt stuff, fine, please use it for your work, but
> do not include this into the branch you request me to pull from.
>
> Please keep the custodian's repositories separated and  allow  me  to
> decide what to pull, and when.



I understand, completely.  It's a messy problem.  I made sure to alert you
to this so that you would have the opportunity to hold off on pulling my
tree in the event you wanted more time to look at the FDT tree.

However, there's no way I could have applied any of the other patches that
were 85xx-specific without those changes--they were dependent.  In the
future, I can choose to reject or hold off on applying any patches which
don't apply to the current custodian repository.  But the drawback is that
people who are working on the cutting edge will have to self-maintain their
patches longer.

My intent in pulling in the fdt changes and Kumar's patches was to have the
custodian tree represent the current state-of-the-art of 85xx development,
thus allowing Kumar to move ahead, and allowing others to build off what he
has done.  If you had decided to reject any of the FDT patches, I would have
happily (if not cheerfully) rebased my tree, and either fixed up the latest
patches on my own, or requested that Kumar resubmit.  This seemed to me to
be a reasonable way forward: it allows development to continue, while
keeping the main u-boot tree free from development work.

Anyway, I'm fine with whatever policy we want to follow.  But if this
happens again, I'd like to know what to do.   :)  I can always just create a
side tree which has the latest state of development, while I wait for any
dependent changes to propagate into the mainline.

Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20071229/ede993ca/attachment.htm 

[U-Boot-Users] Please pull 85xx

[Wolfgang Denk]

Dear Andy,

in message <2acbd3e40712291349u73982ccdub087eb4d90d88369@mail.gmail.com> you wrote:
>
> > Please keep the custodian's repositories separated and  allow  me  to
> > decide what to pull, and when.
> 
> 
> I understand, completely.  It's a messy problem.  I made sure to alert you
> to this so that you would have the opportunity to hold off on pulling my
> tree in the event you wanted more time to look at the FDT tree.

I understand your situation, too.

> Anyway, I'm fine with whatever policy we want to follow.  But if this
> happens again, I'd like to know what to do.   :)  I can always just create a
> side tree which has the latest state of development, while I wait for any
> dependent changes to propagate into the mainline.

Well, let's try this:

If your work depends on patches from another  repo,  please  ask  the
custodian  of  this other repo to send a pull request, and ask him to
mention in his pull request that this is urgent becasue  ...  depends
on it.

I will try to pull such things into testing ASAP.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Houston, Tranquillity Base here.  The Eagle has landed.
                                                    -- Neil Armstrong

[U-Boot-Users] Please pull 85xx

[Rafal Jaworowski]

Dear Wolfgang,
you wrote:

*snip*
>> Anyway, I'm fine with whatever policy we want to follow.  But if this
>> happens again, I'd like to know what to do.   :)  I can always just create a
>> side tree which has the latest state of development, while I wait for any
>> dependent changes to propagate into the mainline.
> 
> Well, let's try this:
> 
> If your work depends on patches from another  repo,  please  ask  the
> custodian  of  this other repo to send a pull request, and ask him to
> mention in his pull request that this is urgent becasue  ...  depends
> on it.
> 

I guess I'm still a bit confused about the process. So in case of inter-repo
dependencies, would you like something like the following?

1. ask the involved custodian(s) to merge my pieces that I depend on, but that
belong to different FA, and have them send pull requests to you

2. you merge those onto the testing branch

Should I then rebase against the testing repo, or wait until it makes to the
main line and only then come up with my pull request? (as there's a general
rule for pull requests to be based on the main line..). Please clarfiy.

kind regards,
Rafal

[U-Boot-Users] Please pull 85xx

[Wolfgang Denk]

Dear Rafal,

in message <477BD21F.7040205@semihalf.com> you wrote:
>
> > If your work depends on patches from another  repo,  please  ask  the
> > custodian  of  this other repo to send a pull request, and ask him to
> > mention in his pull request that this is urgent becasue  ...  depends
> > on it.
> 
> I guess I'm still a bit confused about the process. So in case of inter-repo
> dependencies, would you like something like the following?

I'm still trying to figure out myself how we could  come  up  with  a
compromize of having clean and orthogonal custodian's repositories on
one  side and a practical solution that is usable without introducing
unnecessary delays on the other side.

Thanks for your patience with me.

> 1. ask the involved custodian(s) to merge my pieces that I depend on, but that
> belong to different FA, and have them send pull requests to you
> 
> 2. you merge those onto the testing branch

No.

Assume you depend on feature X from repo xxx and on feature Y from
repo yyy.

Then you would ask both the custodians of the xxx and  yyy  repos  to
send  pull  requests.  The  pull  request  should contain a note that
others (you) depend on this stuff, thus marking it as urgent. [yes, I
know, sombody is always depending on  some  patch,  so  this  is  not
exactly  a  sharp definition. But we have to try something, only then
we can see if it works or not.]

I would then pull the xxx and yyy repos into testing.

> Should I then rebase against the testing repo, or wait until it makes to the
> main line and only then come up with my pull request? (as there's a general

Yes, you would then base your work on testing. I promise that I will
try to keep delays as small as possible.

> rule for pull requests to be based on the main line..). Please clarfiy.

Above assumes that the features X and Y  are  "ripe",  i.  e.  indeed
ready  for  inclusion  into  main line - but this is necessary in any
case, otherwise you could not use them in the first place because  if
they  were  not  clean  for  mainline I could never pull in your code
which depends on / includes them.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The easiest way to figure the cost of living is to take  your  income
and add ten percent.

[U-Boot-Users] Please pull 85xx

[Jerry Van Baren]

Wolfgang Denk wrote:
> Dear Rafal,
> 
> in message <477BD21F.7040205@semihalf.com> you wrote:
>>> If your work depends on patches from another  repo,  please  ask  the
>>> custodian  of  this other repo to send a pull request, and ask him to
>>> mention in his pull request that this is urgent becasue  ...  depends
>>> on it.
>> I guess I'm still a bit confused about the process. So in case of inter-repo
>> dependencies, would you like something like the following?
> 
> I'm still trying to figure out myself how we could  come  up  with  a
> compromize of having clean and orthogonal custodian's repositories on
> one  side and a practical solution that is usable without introducing
> unnecessary delays on the other side.
> 
> Thanks for your patience with me.

As I see it, when we have this situation and need a fast stream into 
u-boot, we need to (and can) use branches effectively.  Using the late 
lamented situation where 85xx was dependent on fdt changes, ideally Andy 
and I do some coordinating.

1) I would put *just the patches that Andy needs* into my "master" 
branch, putting less urgent patches into a side branch (e.g. "testing").

2) Andy can then pull my "master" branch into his repository and add his 
Value Added[tm] patches on top of the minimum necessary u-boot-fdt 
patches. [1]

3) Andy and I clamor for Wolfgang to pull u-boot-fdt and then u-boot-85xx.

4-good) If Wolfgang approves of u-boot-fdt, half is well.  If Wolfgang 
approves u-boot-85xx, all is well.

4-bad) In a worst case scenario, Wolfgang requires changes to the 
u-boot-fdt patches.  I (or the responsible party) would reroll the 
u-boot-fdt patches and generate a new "master" branch with acceptable 
patches.  Andy would have to save his Value Added[tm] patches, do a "git 
reset --hard" back to the original ToT, re-pull my u-boot-fdt "master" 
branch, and then re-apply his Value Added[tm] patches (fixing breakages 
as needed).  Goto step 3).

This should be quite reasonable in practice, although it will take some 
coordination.  Even after the fact, we (me in the fdt/85xx example) can 
use git-rebase or (git reset --hard + re-apply patches) to put only the 
critical patches in "master" and move the non-critical patches to a side 
branch, e.g. "testing".

In the specific instance of u-boot-fdt + u-boot-85xx, we ended up in 
state 4-good) by luck, laziness, some flexibility from Wolfgang.  The 
luck part was the fact that, due to laziness on my part, all or nearly 
all of the changes in the u-boot-fdt tree were the critical set needed 
by Andy.  Wolfgang was flexible enough to pull my "testing" branch 
(rather than "master"), then Andy's 85xx patches, approve of both, and 
life was good.

HTH,
gvb

[1] If Andy were paranoid, he would...
a) Pull my "master" branch into a new branch in his repository, say 
"ubootfdt"
b) Create a new branch based on "ubootfdt", say "testing"
c) Apply his Value Added[tm] patches to "testing".
Once he is happy with the result in c), he would pull the "testing" 
changes into his "master" branch and continue on to step 3)

I don't see any major advantage of this, but it would be helpful for 
keeping the patches straight if branches needed to be discarded and 
recreated due to state 4-bad).

[U-Boot-Users] Please pull 85xx

[Haavard Skinnemoen]

On Wed, 02 Jan 2008 15:52:17 -0500
Jerry Van Baren <gerald.vanbaren@ge.com> wrote:

> 4-bad) In a worst case scenario, Wolfgang requires changes to the 
> u-boot-fdt patches.

This really shouldn't happen very often. Any problems with the patches
should be sorted out during review on the list, so everything that ends
up as part of a pull request should be acceptable.

Of course, it sometimes happens that a pull request is rejected, but it
should be the exception rather than the rule.

Haavard