Re: [PATCH] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-based platforms.

[Laurent Pinchart <laurentp@cse-semaphore.com>]

[-- Attachment #1: Type: text/plain, Size: 2660 bytes --]

On Tuesday 25 March 2008 15:58, Scott Wood wrote:
> On Tue, Mar 25, 2008 at 12:24:40PM +0100, Laurent Pinchart wrote:
> > I was concerned this would break udbg, but udbg doesn't seem to be 
supported
> > on PQ2-based platforms.
> 
> Yes, it is (see arch/powerpc/sysdev/cpm_common.c).

I thought that was for CPM1 only. My bad.
 
> > This patch modifies the device tree address usage to reference the SMC
> > parameter RAM base pointer instead of a pre-allocated RAM section and
> > allocates memory from the CPM dual-port RAM when initialising the SMC 
port.
> > CPM1-based platforms are not affected.
> 
> Please maintain backward compatibility with older device trees (by
> checking the length of the second reg resource).  At the very least,
> update the device trees that are affected.

I haven't seen any CPM2-based board using SMC ports in the device trees 
available in arch/powerpc/boot/dts.

Should I still maintain compatibility with older device trees ? Is there any 
out-of-tree PQ2 boards using udbg and SMC ? What about printing a warning if 
the second reg resource has the wrong size ?

> > +	offset = cpm_dpalloc(PROFF_SMC_SIZE, 64);
> > +	out_be16(pram, offset);
> 
> Up to this point, if we don't reset the CPM prior to any dpalloc calls
> (and if we do, udbg printk breaks), the SMC could be running and
> clobbering some other bit of dpram, which could have been allocated to
> something else.

If udbg uses the parameter RAM allocated by the boot loader, that section of 
DPRAM should be removed from the muram node in the device tree. Otherwise the 
SMC DPRAM will eventually be allocated to something else and the system will 
break.

It should thus be safe to reset the CPM if udbg isn't used, and the device 
tree should explicitely exclude the pre-allocated parameter RAM from the 
muram node when udbg is used.

> After this point, even if you don't reset the CPM, udbg printk is broken
> because you moved pram.  The udbg disabling will have to be moved before
> this.

Moving the SMC pram doesn't break udbg printk in itself. What will break it is 
moving the TX BDs, but the end result is the same, moving pram will result in 
udbg being broken.

The cpm_uart driver disable udbg before allocating the new BDs. What about 
moving that right before moving the parameter RAM ? cpm_uart_request_port(), 
which is called in between, already disables RX and TX on the port, so we 
won't loose any debug message.

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]