[U-Boot-Users] AT91 NAND om AT91SAM9260EK

[Ulf Samuelsson <ulf@atmel.com>]

> On 2/11/07, Ulf Samuelsson <ulf@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.
>

This is exactly how I want to proceed.
There are a number of patches that needs to be sent
in order to have at91sam926x support.
I would like to submit them, have everything working.
There are changes which I consider reasonable to request.
There are also changes which I consider unreasonable to request.

Requesting me to modify the *contents* of a duplicated file because
I want to have a single file I consider as an unreasonable request.

>> 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.

Yes and we need to have people preparing to test
* SAM9261
* SAM9263
* AT91RM9200DK
* AT91RM9200EK
* AT91RM9200DF
* CMC_PU2
as well.

>
> 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.
>

The blackfin support is not in the main tree as far as I could tell.
It is available on a proprietary home page.

> 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.

No, but I am only asking for two things:

1) that I can apply the complete patchset for the at91sam926x and have that
    accepted before people start this activity
2) That people make sure that they do not destroy the U-boot
    support for at91 by providing untested patches.

> 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.

Yes, I am prepared to put the spi part and the at45 support
parts of at45.c in any suggested directory.
That is a reasonable thing to ask for.

To ask me to modify the *contents* of at45.c
just because I want to remove duplication is out of line, IMHO.
I dont say it is a bad thing, just that it should be done
after the patchset is applied, and then by a group willing to maintain
and test the code.

If I am not allowed to remove the duplication, then there is no possibility
to have a common at45.c and I will be forced to modify the
drivers/at45.c in the at91sam926x patchset to be located

board/at91sam9260ek/at45.c
board/at91sam9261ek/at45.c
board/at91sam9260ek/at45.c

so we will have 5 at45.c instead of 1.
I doubt that patch is going to be accepted.

>
> Haavard
>


Best Regards
Ulf Samuelsson