From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ulf Samuelsson <ulf@atmel.com>
Date: Sat, 10 Feb 2007 10:29:06 +0100
Subject: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
References: <20070210011509.A2E2E35265F@atlas.denx.de>
Message-ID: <004501c74cf6$7149db80$01c4af0a@Glamdring>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

> In message <010801c74c98$716c2040$01c4af0a@Glamdring> you wrote:
>>
>> > The only thimg I'm not really happy with (whithout having any  better
>> > suggestion)  is  to  move this into drivers - drivers is intended for
>> > general, CPU and board independent  code,  where  this  is  obviously
>> > specific to a certain class of processors.
> ...
>> I think at45.c is CPU independent, but spi.c is closely tied to Atmel
> ...
>> at45.c contains commands which are specific to the at45 series of 
>> dataflash.
>
> Sounds contradictory ;-)
>
> But I agree with the latter statement: at45.c is specific to the at45
> series of dataflash, which in turn is specific to a certain class  of
> processors. You probably cannot find this on PowerPC, MIPS, NIOS, ...
> systems.

No it is not specific to any class processors.
You can add at45 dataflash to any processor.


>
> That's why I wonder if this should not be located somewhere under
> cpu/...
>
>> While the functions in at45.c are called AT91xxx they really do not
>
> Then that naming should be fixed...
>
>> depend on any specific SPI H/W and it can thus be used
>> with any chip which implements the SPI API defined
>> by cpu/arm920t/at91rm9200/spi.c
>
> But we agree that this *is* specific to a certain class of processors
> of the ARM family, right?

No. You can add dataflash to any processor with an SPI
interface or even if you do not have an SPI interface you
can access the device using standard I/O pins.

At the moment, inside U-Boot it is only used by AT91 processors
but that is really not the same thing.

I do believe that it is the guy who wants to use if for more than
AT91 processors that shoudl clean it up.
Please realize that I am not adding code, I am just rearranging code
in a way which will be an improvement of U-Boot.

Are you really against improvements of U-Boot because you want more 
improvement
and rather have a worse U-boot because the improvement is not large 
enough???

>
>> If you let it remain in the board directories as is, then
>> you duplicate this for each board.
>
> This is not what I want, nor what I suggested.
>
>> I think a good place for any driver stuff which is useable
>> both by at91 and ap7xxx chips could be an
>> board/atmel/drivers directory.
>
> No. Not board/... if you are talking about chip specific features.
>
>> An alternative would be a cpu/atmel/drivers directory.
>
> or cpu/atmel/ (without the /drivers  part),  like  we  do  for  other
> processors.


I do not see any such directories.
I only see cpu/<cpu type> directories.

I believe the proper way to proceed is to merge the tested patches
from the Atmel AT91 group which applies cleanly to the
the current tree (with the exception of at45_split and a small
issue on the NAND flash)
We need to split the current at45.c in the board directory
into spi.c and the remainder of at45.c in order not to break
current code.

I would like to suggest we proceed in the following way:

I modify the patch to generate:

cpu/arm920t/at91rm9200dk/spi.c
cpu/atmel/at45.c
and the neccessary hooks in Makefiles/configurations?

Once that is included, I will submit the at91sam926x patch(es)
One of the sam926x patches will then generate
cpu/arm926ejs/at91sam926x/spi.c

Haavard can then, after the sam926x patch set
has applied merge (if it is really desired) the spi.c
with the AVR32 version and put it in cpu/atmel/spi.c
.
He can the "clean up" cpu/atmel/at45.c" making naming conventions
more generic and move it to drivers/at45.c when that is completed.

Agreed?

Best Regards
Ulf Samuelsson