Re: [PATCH] CPM_UART: Fixed SMC handling for CPM2 processors

[Kalle Pokki <kalle.pokki@iki.fi>]

On Tue, 7 Nov 2006, Vitaly Bordug wrote:

> Well, yes, but are you _sure_ pram_base will be the same across all the 
> 82xx PQ2, that happen to have smc wired to Ethernet?
>
> If not I am considering storing it in the platform_data is better approach.

Yes, pram_base is always 0x87fc for SMC1 and 0x88fc for SMC2. This is
for all PowerQUICC II families (8260, 8272, and 8280). I'm not sure how 
PQ2 Pro and PQ3 and handled, but I suspect they don't share these 
definitions.

Anyway, I'm only extending the already existing conventions to the 
platform device approach. These same decisions have already been made in 
the past and are used in the cpm_uart compat mode. It may be that 
Freescale someday releases a microcode patch that relocates the SMC 
parameter RAM, but even in this case it would be better to use the same 
approach with compat mode and platform device mode to avoid confusion.

I could have used the numerical address offsets in the resource 
definition, but I wanted to emphasize the fact that the offsets are 
already defined by the DPRAM memory allocator (this is a little hackish, 
yes) instead of hardware directly requiring these exact values.

This snippet is from cpm2.h:

 	/* Dual Port RAM addresses.  The first 16K is available for almost
 	 * any CPM use, so we put the BDs there.  The first 128 bytes are
 	 * used for SMC1 and SMC2 parameter RAM, so we start allocating
 	 * BDs above that.  All of this must change when we start
 	 * downloading RAM microcode.
 	 */
 	#define CPM_DATAONLY_BASE       ((uint)128)

My patch puts pram_base exactly here.