From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Samuelsson Date: Sun, 11 Feb 2007 20:42:52 +0100 Subject: [U-Boot-Users] AT91 NAND om AT91SAM9260EK References: <47403.127.0.0.1.1171139473.squirrel@localhost><007601c74dfc$13ee7340$01c4af0a@Glamdring> <1defaf580702111004m6759e7f8yd03392a9ab7464c4@mail.gmail.com> Message-ID: <00a901c74e15$5174fe50$01c4af0a@Glamdring> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de > On 2/11/07, Ulf Samuelsson 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