Jachym Holecek wrote:
> Well, at the moment it's only used by the 405GP/GPr. A quick look at
> AMCCs datasheets suggests that most models could be quite elegantly
> supported with just some header file tweaking (looks like we could
> put most 405s and the 440EP to a single header file without major harm).
> The 440SP/GX/GP are quite different beasts (they'd need some changes at
> the pmap layer AFAIU, so wondering about address space layout sounds
> premature ;-).

440xx have different TLB entries from 405xx.
I think, perhaps we need to prepare another pmap layer.

> One detail that I think could be improved though is to change the opb
> device table from:
> 
>         { IBM405GP,     "com",  IBM405GP_UART0_BASE,     0, 0 },
> 	...
>         { IBM405GPR,    "com",  IBM405GP_UART0_BASE,     0, 0 },
> 
> to something like:
> 
> static int
> cpu_is_405gpx(int pvr)
> {
> 	return (pvr == IBM405GP || pvr == IBM405GPR)
> }
> ..
>         { cpu_is_405gpx,    "com",  IBM405GP_UART0_BASE,     0, 0 },
> 
> so that duplicate entries can be avoided.

Well, it's fine.
405CR and 405GP have the same PVR value.
In that case, we need another detection logic.
Above changes is good.



Thanks,

> A couple of random notes regarding the patch:
>   * powerpc/include/ibm4xx/ibm405gpr.h is a copy of ibm405gp.h
>   * separating GP and GPr doesn't make much sense to me -- the only
>     difference between them is in cache size and clocking frequencies,
>     at least as per AMCCs product brief

I agree if there is no different between GP and GPr on the implemented
parts.

>   * I don't like the way device/PCI-config tables are passed -- I'd just
>     declare 'extern table' in the driver and let ibm${foo}.c provide it
>     in the compile-time case, or use device properties (or whatever it's
>     called now ;) in the runtime case

How to implement to use device properties?
Is it implementing device properties in device_register() function?

I think...
We should provide a device-configuration mechanism both
complile-time and run-time.
People who develop a port can decide which is better for this port.

-- 
Kind Regards,
--- shige
Shigeyuki Fukushima <shige@{FreeBSD,jp.FreeBSD,NetBSD}.org>