[U-Boot-Users] Status of the AVR32 u-boot patches

[Haavard Skinnemoen]

On Fri, 25 Aug 2006 19:45:11 +0200
"Ulf Samuelsson" <ulf at atmel.com> wrote:

> > On Fri, 25 Aug 2006 12:42:46 +0200
> > "Ulf Samuelsson" <ulf at atmel.com> wrote:
> >> I have put the AT91 memory drivers
> >> * at45.c->at45dbxxx.c
> > 
> > Hmmm...what's wrong with drivers/dataflash.c?
> 
> You might as well ask why use IP; then you have TCP :-)
> Dataflash.c is on top of at45dbxxx.c

Ok, I see. Now that I look closer, dataflash.c looks awfully
board-specific. I think it would actually make more sense to put the
low-level stuff into drivers (which, if I understand correctly, is what
you want to do) and move some of the code in dataflash.c into boards/foo

For example, it looks to me lilke the area_list[] and cs[] stuff makes
the dataflash.c code unusable for AT32STK1000 and probably other AT91
boards as well.

Maybe it would make sense to move the detection logic into the low-level
driver as well.

> >> Probably, it is a good idea to put most of the Atmel Rousset
> >> peripheral drivers in an "board/atmel/common" directory as well.
> > 
> > I thought drivers were supposed to go in the "drivers"
> > subdirectory? ;)
> 
> Some are in the board directory, some are in the cpu directory and
> some are in the drivers directory today. The lowest level seems to be
> in the CPU directory, but if generic, it makes more sense in
> atmel/common.

That seems to be how it's done in practice, yes. But I don't understand
what the rules are for which drivers go into boards/foo and which go
into drivers. Can someone fill me in?

IMO drivers that are used by more than one board and/or CPU should go
into drivers, but please correct me if I'm wrong.

Haavard