kernel 2.6.15: cpm_uart driver broken?

Vitaly Bordug vbordug at
Wed Apr 19 00:21:09 EST 2006

On Tue, 18 Apr 2006 16:05:40 +0200
David Jander <david.jander at> wrote:

> On Tuesday 18 April 2006 15:22, Vitaly Bordug wrote:
> >[..]
> > Well, existing code works just fine on 885ads and 866ads, that use SMC1 and
> > SMC2 as UARTs.
> Interesting.

And for PQ2 I can add 8260 , PQ2fads and 8272ads that had no issues with current driver
> > > I'm pretty sure the following is wrong, but I can't seem to fix it
> > > either. This seems to apply for both PQ and PQ2 type uarts:
> > > from drivers/serial/cpm_uart/cpm_uart_cpm1.c (line 190):
> >
> > That's wrong - cpm_uart_cpm1.c applies to PQ only...
> I know. cpm_uart_cpm2.c contains the same code, so it should be as broken as 
> the cpm_uart_cpm1.c.
pq2 are cache-coherent, so there are no such troubles in there. And allocation routine is different of course.
> >[...]
> > Well, since it works on other boards, and kmalloc stuff seems to sorta work
> > as well, then I guess reason is screwed DMA thing for your board.
> > Check/alter CONFIG_CONSISTENT_* things and see if it will help.
> I did not touch de defaults. What are the rules to change them? What do I have 
> to look out for?
> CONFIG_CONSISTENT_START = 0xff100000 and I suspect a problem here if I was 
> using MTD (currently disabled) since flash is at physical adress 
> 0xfe000000-0xffffffff on my board. Isn't MTD going to io_remap that area to 
> that same virtual adress? How's that supposed to work then?
> I changed CONFIG_CONSISTENT_START to 0xfd100000 and now the system freezes 
> when I write to the serial port :-(

Unfortunately, I know nothing where the correct thing should be pulled from...
But the problem lies in dma stuff from what I can say.

> > And, try to just replace dma_alloc_.. with kmalloc (not changing rx_buf
> > etc.) and reproduce the same behavior you had. BTW, rx_buf and tx_buf are
> > never used actually in the code, hereby there is no difference what values
> > they contain...
> Argh. Code looks obviously broken, but since it isn't used, it just works. 
> That is not good! We should fix that either way then.

The overhaul is on the way, I'll put the cleanup of the unused stuff together with other changes.


More information about the Linuxppc-embedded mailing list