[U-Boot-Users] [rfc] new spiflash subsystem

[Ulf Samuelsson]

> In message <00be01c862d8$9d61a7e0$070514ac at atmel.com> you wrote:
>>
>> >> ==> This is not how the dataflash support is implemented in U-Boot today.
>> >>         Current implementation is using DMA.
>> > 
>> > Note that you are referring to code that is not part  of  the  public
>> > U-Boot tree, and that (as is) will never become a part of it.
>> 
>> No, I am referring to code which does exist in the U-Boot tree.
> 
> You mean the current dataflash implementation uses DMA? Which part of
> the code is this?
> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> When the bosses talk about improving  productivity,  they  are  never
> talking about themselves.
>

Not sure as I do not have a source tree in front of me,
but if I remember correctly, it was in the board specific 
"at45.c" which then was split in two files.
One generic "at45.c" and one CPU specific file "spi.c"
which is located in the cpu/arm920t atmel specific directory,
and the DMA functionality is in the CPU specific part.
(Where it should be)

I think a good SPI implementation should (like today) 
create a command block in a buffer, and request
the CPU specific driver to do a block transfer.

Having a generic driver do the small details of access 
will remove all possibilities for an efficient driver.

There can of course be a driver which sends bytes one by one,
as a fallback , but I think this should be an option that can be overridden
by a driver focusing on efficiency.

Best Regards
Ulf Samuelsson