[U-Boot-Users] AT91 NAND om AT91SAM9260EK

[Haavard Skinnemoen]

On 2/11/07, Ulf Samuelsson <ulf at atmel.com> wrote:
> Any duplication causes by this is against code which is not
> yet present in the current source tree, but only against code
> Haavard wants to write.

Ok, I think there's some misunderstanding going on here. I didn't mean
to say that the spi driver _must_ be made common for all chips _now_.
Please disregard my suggestions about a common spi driver for now.
Let's get this stuff moving.

> I do not understand who will be responsible for maintaining
> the spi support for at91 chips if it is rewritten.

I'm responsible for the atmel_spi driver in the Linux kernel which is
on its way into mainstream hopefully any day now (it's been accepted
by the SPI maintainer.) This driver supports AT91RM9200, AT91SAM926x
and AT32AP7000, so I don't see why I can't be responsible for the
u-boot driver as well if nobody else are going to step up.

But let's do it your way for now and move the SPI parts of the
dataflash driver to the CPU directory. We can always change it later,
when support for all boards are in place and it becomes clearer which
parts are shareable and which parts are not.

> Please realize that, while I am providing the patches, I am just taking what
> the Atmel AT91 groups is delivering to the end customers.
> The AT91 group is fed up with zero response
> and has basically given up on trying to get patches approved.

Hmm...that sounds somehow familiar :-P

Hopefully, the new custodian model will improve this.

> I am in no way able to support fully testing significant modifications of
> these
> patches and I belive that if this is done, there will be noone
> accepting responsibility for that these patches actually
> generate U-Boot binaries's which will actually work.

U-boot is a community effort. We depend on an active community to test
non-trivial changes. Michel has already volunteered, that's exactly
what we need.

We can't depend _only_ on the AT91 group to make sure that dataflash
will work on all boards using it, nor can we depend _only_ on the
AVR32 group. As far as I know, none of us are testing any of this on
Blackfin, for example.

Of course, Atmel needs to do testing as well, and it will probably
make sense to offer special "Atmel blessed" versions of u-boot which
have been tested thoroughly on all supported configurations for the
customers that need this. But we can't say that nobody is allowed to
make any changes to the official driver because it has been tested and
we don't want to do it again.

Any changes Atmel does based on such testing should of course be
submitted for inclusion upstream. But for this to work, we do need a
timely response from the upstream maintainers.

> >From what I have seen, the patches from the AT91 group fit closely into the
> current
> way U-Boot is designed, and they should be reviewed by people that
> actually study the patches so that an unbiased opinion is given.

I don't know what you're getting at here, but yes, in order to review
a patch, you _do_ need to study it and give an unbiased opinion. But
it works the other way around too -- if you want review, you _have_ to
be willing to make changes based on that review.

Haavard