From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tolunay Orkun <listmember@orkun.us>
Date: Fri, 01 Jul 2005 11:25:20 -0500
Subject: [U-Boot-Users] cfi_flash is now working with 64 bit port width
In-Reply-To: <20050630235942.CFEDE353A1B@atlas.denx.de>
References: <20050630235942.CFEDE353A1B@atlas.denx.de>
Message-ID: <42C56E70.5060800@orkun.us>
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

Wolfgang Denk wrote:

>>That way, any board with custom data bus (reversed lanes for example) or 
>>address bus (messed up address line) arrangements or specialized 
>>handling (need floating point) as in this case would override them 
>>easily and we would not end up blocks of #if/#elif/#else/#endif etc. in 
>>    
>>
>
>No. The whole idea of the CFI flash driver is to have  standard  code
>for  all  boards.  If  your  design  does  not fit the standard, then
>provide your own non-standard driver. Don't add complexity to the CFI
>driver - it has just a single advantage (being "standard"), so please
>don't drop this.
>  
>

So, you are saying: it is better to have variations of cfi_flash.c in 
board directories and maintenance problems because of code forking of 
cfi_flash.c code is better than having the possibility of board specific 
read/write access functions. By doing this we not only would save the 
day and solve his problem but make cfi_flash.c useful to a broader 
application.

For some reason, my mind works to factor common code. It does not make 
sense for me but you are the boss.


>>the cfi_flash.c. The board would also enable FP unit in its board file 
>>or within these functions if necessary as well.
>>    
>>
>
>"enabling FP" has nothing to do with this. The FPU is never  disabled
>or  so.  It's  just  that  the  compiler is told to never emit any FP
>instructions :-)
>  
>
He had to modify MSR before using FP instructions as well. That was what 
I was pointing to.

Best regards,
Tolunay