[PATCH] CPM_UART: Fixed SMC handling for CPM2 processors

[Vitaly Bordug]

On Mon, 6 Nov 2006 22:49:49 +0200 (EET)
Kalle Pokki <kalle.pokki at iki.fi> wrote:

> On Mon, 6 Nov 2006, Vitaly Bordug wrote:
> 
> >> This patch renames these the two existing resources, and introduces a
> >> new one, "pram_base", which is a pointer to the parameter RAM. The
> >> parameter RAM for SMC1 and SMC2 is put in the first 128 bytes of the
> >> DPRAM. This memory was already reserved from the DPRAM memory
> >> allocator for this purpose.
> >>
> > Well just one objection. pram_base should not be a device unless it applies to all the stuff of
> > SoC family which is not the case.
> >
> > For this aim, I'd put what you need into the platform_data, or follow the same approach 8xx stuff having.
> 
> I'm not sure I follow you now. "pram_base" is not a device by itself, but 
> it's just another resource in the PQ2 version of the SMC devices in the 
> platform_data. So the resource is only present when it is needed, and for 
> other platform devices that don't have this resource, the cpm_uart code 
> does nothing (as it should not).
> 
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.

> The only difference to the 8xx version is the new "pram_base" resource, 
> and it is required with PQ2, right?
Prolly, and I actually tried the same when introduced 8xx stuff. It was not permitted because such a thing could not be stuck to one value, and as long as we'll have it compiled into the devices table, others will have to use that offset (yet maybe having the specific dpram required for another purpose).

Hope that clarifies my position...
-- 
Sincerely, 
Vitaly