[U-Boot-Users] [PATCH] AT91SAM9263 Board files

[Haavard Skinnemoen]

On 2/2/07, Ulf Samuelsson <ulf at atmel.com> wrote:
> >> Then adding patches for the ARM926 based cpu/board directories,
> >> but without any references to these patches in Makefiles/MAKEALL.
> >> At the end a patch which would make them buildable.
> >
> > No. Each patch is supposed to be independent of the others. It should
> > be possible to apply only the first N patches of your  sequenbce  and
> > get a useful, buildable code version - otherwise you will always have
> > to  rework the whole sequence if patch N+1 gets rejected for a reason
> > or another.
>
> What I mean is that I want to start with creating the
> cpu/arm926ejs/at91sam926x directory and associated includes.
> All the AT91SAM926x boards use this.
> Before the boardpatches are submitted, this will be a dangling patch
> since no board depends on it.

I think this makes sense. Adding support for a CPU is one logical
change. If it gets used by a board patch later in the series, what's
the problem?

Combining it with a board patch means that the series will have to be
reworked if either of them changes. And it becomes very difficult to
obey the size restrictions.

> It will be a little easier to do the board patches if the cpu support is
> there.

Exactly.

> > But all this is documented in the README.

A bit OT: Would it make sense to split up the README a bit? For
example, pull the patch submission rules out and put it into
doc/SubmittingPatches or something? Similarly with the coding style
rules and the CONFIG/CFG macro documentation. I think this would make
it easier for everyone to get an overview of what documentation is
really available and maybe more people would actually read the rules?

> >> This would during a short period give some "dangling" or unused code
> >> I know you don't like that, so how proceed with such a large
> >> patchset, where things depend on each other?
> >
> > Split it in orthogonal chunks. That's what they do  with  Linux,  and
> > what we have been doing with U-Boot for a long, long time.

I think board and cpu support _are_ two orthogonal chunks.

> >> I dont have any git server which I can use for this.
> >
> > You don't need a git server. Use a local repositoy, and git to create
> > the patches.
>
> I was thinking of the problem of size.
> The AT91SAM9263 header > 40 kB bzip2 compressed.

A header file (or really any single files) which weighs in at more
than 40k compressed is just wrong. The at91 u-boot people need to talk
more with the Linux people -- the at91 Linux headers are a lot more
sane.

Register definitions for specific hardware modules should be split out
into separate files IMO. For example, the USART definitions are
redundant with drivers/atmel_usart.h anyway.

I think we should become better at collaborating on u-boot drivers
between the avr32 and arm departments in Atmel. We're already doing
this with Linux -- several drivers are already shared between avr32
and at91, e.g. atmel_serial and atmel_spi (which I'm hoping will go in
during the 2.6.21 merge window.) I'll try to contact whoever is in
charge of u-boot in the at91 departement and see if I can get the ball
rolling on a joint effort to consolidate some of the at91 and avr32
stuff.

> I assumed that if I use a git from where people can pull
> I can have larger patches, but that might be a mistake.

I think the size of the patches is more of an indicator that something
is wrong. But I also think that if an oversize patch is otherwise ok
we shouldn't let the size rule block it iff the coding style rules and
the rule about single logical changes are being followed.

In Linux, oversize patches are usually posted at a public webserver
with a link to it in the e-mail unless they have been fully reviewed
and are sent to Linus for inclusion (without Cc to lkml.)

Btw, I don't really have anything to do with arm or at91, so feel free
to ignore my advise.

Haavard